From owner-freebsd-security Sun Apr 20 03:29:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA14926 for security-outgoing; Sun, 20 Apr 1997 03:29:20 -0700 (PDT) Received: from taicom.marine.su (taicom.marine.su [194.84.41.68]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA14920 for ; Sun, 20 Apr 1997 03:29:10 -0700 (PDT) From: engl@online.marine.su Received: from demo.online.marine.su by taicom.marine.su (8.6.9/TAICHU002) id VAA03278; Sun, 20 Apr 1997 21:28:57 -1000 Message-Id: <3.0.32.19970420202439.00687fb4@194.84.41.66> X-Sender: engl@194.84.41.66 (Unverified) Disposition-Notification-To: X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 20 Apr 1997 21:29:45 +1000 To: freebsd-security@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk subscribe freebsd-security From owner-freebsd-security Sun Apr 20 09:15:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA28435 for security-outgoing; Sun, 20 Apr 1997 09:15:43 -0700 (PDT) Received: from cwsys.cwent.com (66@cschuber.net.gov.bc.ca [142.31.240.113]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA28430 for ; Sun, 20 Apr 1997 09:15:37 -0700 (PDT) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.5/8.6.10) id JAA11910; Sun, 20 Apr 1997 09:15:27 -0700 (PDT) Message-Id: <199704201615.JAA11910@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd011907; Sun Apr 20 16:15:26 1997 Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: MH To: igor@alecto.physics.uiuc.edu (Igor Roshchin) cc: Freebsd-security@freebsd.org, cschuber@uumail.gov.bc.ca Subject: Re: Buffer overflow in sperl5.003 (fwd) -- Is this relevant to FreeBSD ? In-reply-to: Your message of "Thu, 17 Apr 1997 23:02:07 CDT." <199704180402.XAA11899@alecto.physics.uiuc.edu> Date: Sun, 20 Apr 1997 09:15:25 -0700 From: Cy Schubert Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On one of my 2.1.6 systems at home, all I got was segmentation violations and bus errors, meaning if the right offset was used this exploit would work. Since sperl5.003 doesn't work on 2.1.x systems you're better off deleting the binary. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." > Hello! > > Does anybody know if this hole exists on FreeBSD ? > > Thanks! > > IgoR > > Forwarded message: > >From owner-bugtraq@NETSPACE.ORG Thu Apr 17 19:40:09 1997 > Approved-By: aleph1@UNDERGROUND.ORG > MIME-Version: 1.0 > Content-Type: MULTIPART/MIXED; BOUNDARY="-242971389-615984271-861311469=:2466 2" > Message-ID: > Date: Thu, 17 Apr 1997 14:11:09 -0700 > Reply-To: Murphy > Sender: Bugtraq List > From: Murphy > Subject: Buffer overflow in sperl5.003 > To: BUGTRAQ@NETSPACE.ORG > > 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 mime@docserver.cac.washington.edu for more info. > > ---242971389-615984271-861311469=:24662 > Content-Type: TEXT/PLAIN; charset=US-ASCII > > > Its came to my attention that there is a buffer overflow bug in > sperl5.003 that will allow local users gain root access, if SUID root. > The exploit and bug was made and brought to my attention by Willy Tarreau > (tarreau@aemiaif.ibp.fr). > Attached is the source for the exploit. Since it requires some work to > be done to the compiled exploit (Stripping of 5 byte at the begining and > end of the binary), the precompiled Linux x86 exploit can be found at > http://www.ecst.csuchico.edu/~jtmurphy/localusers.html. > > PS. Have a nice a day. > > -- > ---------------------------------------------------------------------------- > Jason T. Murphy | Finger for PGP Public Key | jtmurphy@ecst.csuchico.edu > The Linux Security Home Page -> http://www.ecst.csuchico.edu/~jtmurphy > Security buff, Linux Freak, PC Tech @ Chico State, and all around nice guy. > > ---242971389-615984271-861311469=:24662 > Content-Type: APPLICATION/octet-stream; name="sperlexp.tgz" > Content-Transfer-Encoding: BASE64 > Content-ID: > Content-Description: > > H4sIAFcBVTMAA+1a3W7bRhb2rWf3IY6VdCW5FEXq17Wboq5joNk2sRHL6AZt > kY7IkTQIf7TDoSyi6GKBvepF36WPsBd7tcA+xD7G3u05Q0p2ksJuCltG0PkS > WyJneOZwZr7znUMzmwsVtbfuFNDzhkMftgBgOOybT7/XM58VPIBBt9PveF7f > G2Cr7/e7W9C/W7dK5JnmCmALfyvB82v6CZVtwqHNIjPrr1XBo8g1B7c/hu95 > w/416z/sDsr194eDbh/3gt8ddAZb4N2+K2/jd77+D3baY5m0dZDN2APQMwHZ > TEQRJDwWIDOYyoVIYFxAXQSzFFoJuK5bB56EEOPUwViAWPJARwUMIZhxlcFM > KOGgsVRBkeZ1NDbjCwE6hTgN5aQoR9E8eAVjngmYYEc6Vf/y+LAOMsm0ygMt > 0wS/UwOaytJcBdhDLEXg8r1B3cWTL9IcAp5AkM4LaOeZMnciQxqpreO5cVLl > iTmg82Ra8NCF0YzrOt5bmlLn1GXm3mqn6MDZMTw+gWcnIzjHr6PPn5zB6ASO > nh8efQGHcPbibHT81IHPzkfw5/OzEbWNjvHzxcn587NvduhfjWVCw4JH8AgD > 2dBjFzMZCWg8pFMfg9/pec1ywJEqZDIFamBr/w0H+67ndeE7t63m2rQfBFyD > uXvsc7Bainp5xax+4LZFNgeMn9+xT2nsDz9kIgnZzetf8v/58eHjp8d3tceQ > /4OBdw3/O70V/4fdYQdbO37Xt/zfBI5mAnmIPFUw53pmyFhtwSXCgXweco2h > QFdshCxQEnflVckgpjFimtQu0ZI4nwgRAgcKLERIatUzDCjl5S6cmOhgCFxe > CTFPcjRZuOwkgbiADixwyjEOZA6sWeEbVl+SxKEriRi5FhmOp9JUVyGMa4b8 > 67qMjdBtwbNCYMC64MVr/uB/PMxkPMcQpos5RpmYvxJ1F55QjDiN8mnrWes0 > wsv2W03GHqdJHa2kShXAx2muzaTUMjGNRaK5iVsTnke6RgGwNiHum2CKgQai > NJnWIBZZxqcic8kxtKKwR6piDA+ZTDDMXcZHdE6JCyW1xiC8w9hXEucHRuVW > Zazas59yEUsuJ64cz92J+hWsv0TJ/6d4x+Tp3ewx4n/vGv73r+h/x+8T/4de > 1/J/E0DC7QNpBynNSmDYtvtaSshYEAme7LNtFUNrsu6/66aw+zcUYCUYe2CA > ujxCocf9tLbmvJkGIPf2AXi2N4DWeN0NVuKOJojjyILyUqRAnC5KWvRhIhWy > mDr0IeKUgRTE/AuJwYsD2uFITBFKjexrjAVfNNHeE5irdCHDiltlNkF5islK > yFkaJ09CXGNNtmfpBQUWpPkrpCnd1TvCMPWdmHg/KPmPC+oGdzbGDfzvdHqX > /B/2u8T/Tqdv+b8JtHdvDW3W3gU44lGQR5QyXMrYPJWJFooS03yV76O0ISen > iscunBnZQ76FqchIXqEytiAyYxZQYLERYHKi0hjSRKyuJPbyJMWBFCX3a36T > 3JocwDHHlTEldK4SzEpKNyjzwOoF1zVcRQ9TEPAgyBUPCioTBKDAz1HjKVFI > sMfasyrQTEi3MeFIcSD8xFuozAZpgim7SPAnvOomFjeU81eojGFnzWVCDRwn > S5kkIp3g+VC48BVXpmlnx3hUer++GarCzJStjJkoy5OCDEidQa+KkFSVoCOe > Q3kJxTaMUOQp+lvHWoG6l85h6rM2tqqx5pT/lLOkpguTMeVjjdOEobjySKdX > CzuBMyOoeiTPK2PSOJDpECfVfdeAukZl7Hbw24yVadgvG7tFOrEHyIsox139 > MU6aTN3ZJ4xllGMGuBsjiUSYClzaeaMJ3zOAly95Fr982cAMM11E8AG2OB8I > voRa84D9wFiMewwaSEVaxMAx5Trs7tKKlgYoPUUVzOSUdhZefoAnqX8oAh49 > 8uiQzkygQRY+8ZtVC9eppFOLr/1vm1UvvPzRyr2W6UYNE8pmReNP5FvP8Z1y > NzSvbfrhPdDR9xWl/mMyd3/67/e6w3X93xl4Rv+79vnfRnCLAWt3F0mMEnWp > 7KuyGkvLKINVrVw+UkzyeIx6iKpj5MmFzwoMJqZyNqpNtqiFpNdb9nxo1A/r > TbiYSUwEsOJQGCbSJMxQzhLSMMowIjg6PSeNqWHgBBEsa1TFk6UgzaOwlMax > oAeaQlNCgl1xXeHZySk0vOVHXtOBsfESB6XoiPpGqYXJSf6aY3QiW3MUSc3H > ERUS5rlIhuW7Ng8YjL6JSAQmFUjXD0xoSPP4AC8/TIoLXjhQe/LsCI6P/lJb > Zz2YSdBwVH+sTqETybTMaigZqGfoOd6FxArGIWPkwYSShmrCx4onwUxkq4c1 > sQxDdBRnmfITZ5WgmKcfpP/UB8XfJVvst+kgu80dhKL3i6pH0nWdclGTrISH > 8suGfEOT5IFslfOPC5hrMtCgbdU8AMAMoNovJOGoXEupG97vQ3iq+q8qve9m > jJue//hDbxX/+/2eef7T92z83wi2MVWkne9gOGXbS6QOJowO/rDteZ7NwHyL > BAcxXjpfY6fW8Fu2zUOTHjp+52q38tsYvxmjIdoJqgMeOb7Ptomm3nLPY9v3 > fd8WJa7wH0vauxnjJv5D9fefbr8zMLHA79i//24IP/7X/+fpT988/N8//vXH > 07Mf//3zH/7z9/v2yWJzeO39j6lIhJK3Xgje9P5Hf9i78v5Pj1p9r2P5vwlc > ff/j8r2Fj/befm3BW7220Erg+enIvJYA++zh7q95T4HewLjmPYUrb0y8PXSn > t5mhcZg3h+7t3eXQ9732FhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYW > FhYWFhYWFhYW7yf+D4S0HUYAUAAA > ---242971389-615984271-861311469=:24662-- > > From owner-freebsd-security Mon Apr 21 02:30:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA01903 for security-outgoing; Mon, 21 Apr 1997 02:30:58 -0700 (PDT) Received: from atena.eurocontrol.fr (atena.uneec.eurocontrol.fr [147.196.69.10]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id CAA01895 for ; Mon, 21 Apr 1997 02:30:48 -0700 (PDT) Received: by atena.eurocontrol.fr; (5.65v3.2/1.3/10May95) id AA05594; Mon, 21 Apr 1997 11:30:06 +0200 Received: (from roberto@localhost) by caerdonn.eurocontrol.fr (8.8.6.Beta0/caerdonn-1.1) id LAA24193; Mon, 21 Apr 1997 11:30:06 +0200 (CEST) Message-Id: <19970421113006.47852@caerdonn.eurocontrol.fr> Date: Mon, 21 Apr 1997 11:30:06 +0200 From: Ollivier Robert To: freebsd-security@freebsd.org Subject: Fwd: Beta testers wanted for new security tool! Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.67 X-Operating-System: FreeBSD 3.0-CURRENT Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----Forwarded message from Alfred Huger ----- Date: Fri, 18 Apr 1997 18:34:52 -0600 From: Alfred Huger Subject: Beta testers wanted for new security tool! To: BUGTRAQ@NETSPACE.ORG For those of you who are interested in network security auditing tools, SNI (Secure Networks Inc.) is making an open call for Beta testers. The software we are offering for Beta is our upcoming network auditing tool Ballista. Interested parties should view : http://www.secnet.com/beta/opencall.html or FTP to : ftp://ftp.secnet.com/pub/beta/beta-form /************************************************************************* Alfred Huger Phone: 403.262.9211 Secure Networks Inc. Fax: 403.262.9221 **************************************************************************/ -----End of forwarded message----- -- Ollivier ROBERT -=- Eurocontrol EEC/TS -=- Ollivier.Robert@eurocontrol.fr Technical Services Tél : 7290 - CS.01 From owner-freebsd-security Tue Apr 22 12:16:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA06265 for security-outgoing; Tue, 22 Apr 1997 12:16:16 -0700 (PDT) Received: from xkis.kis.ru (dv@xkis.kis.ru [194.87.66.200]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA06046 for ; Tue, 22 Apr 1997 12:15:29 -0700 (PDT) Received: from localhost (dv@localhost) by xkis.kis.ru (8.8.5/8.8.5) with SMTP id XAA12305 for ; Tue, 22 Apr 1997 23:13:57 +0400 (MSD) Date: Tue, 22 Apr 1997 23:13:57 +0400 (MSD) From: Dmitry Valdov To: freebsd-security@freebsd.org Subject: SNI-12: BIND Vulnerabilities and Solutions (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello! Is fbsd 2.2.1 vulnerable? If yes are there any patches available specially for FreeBSD? ---------- Forwarded message ---------- Date: Tue, 22 Apr 1997 04:36:17 -0600 From: Oliver Friedrichs To: BUGTRAQ@NETSPACE.ORG Subject: SNI-12: BIND Vulnerabilities and Solutions -----BEGIN PGP SIGNED MESSAGE----- ###### ## ## ###### ## ### ## ## ###### ## # ## ## ## ## ### ## ###### . ## ## . ######. Secure Networks Inc. AND CORE Seguridad de la Informacion Security Advisory April 22, 1997 BIND Vulnerabilities and Solutions Problem Description ~~~~~~~~~~~~~~~~~~~ This advisory contains descriptions and solutions for two vulnerabilities present in current BIND distributions. These vulnerabilities are actively being exploited on the Internet. I. The usage of predictable IDs in queries and recursed queries allows for remote cache corruption. This allows malicious users to alter domain name server caches to change the addresses and hostnames of hosts on the internet. II. A failure to check whether hostname lengths exceed MAXHOSTNAMELEN in size. This results in potential buffer overflows in programs which expect the BIND resolver to only return a maximum hostname length of MAXHOSTNAMELEN. Problem I. The usage of predictable ID's ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Problem I. - Impact ~~~~~~~~~~~~~~~~~~~ Remote root users can poison BIND and Microsoft Windows NT name server caches by forging UDP packets. We should note that unlike other well documented attacks, in this instance it is NOT necessary for the attacker to take over a DNS server or sniff the target network. Problem I. - Technical Details ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This particular cache corruption attack requires that the target nameserver be configured to allow recursion. Recursion allows a nameserver to handle requests for zones or domains which it does not serve. When receiving a query for a zone or domain which is not served by the name server, the name server will transmit a query to a nameserver which serves the desired domain. Once a response is received from the second nameserver, the first nameserver sends the response back to the requesting party. The following attack is outlined in the paper "Addressing weaknesses in the Domain Name System Protocol" by Christopher Schuba and Eugene Spafford [6]. To the extent of our knowledge, this problem has not been previously addressed. The paper also assumes that the attacker has super-user access to a primary nameserver, here we demonstrate that this is not necessary nor are source routed packets required. Using the recursion feature, one can poison the cache on a name server with the following procedure: Problem I. - The Players ~~~~~~~~~~~~~~~~~~~~~~~~ . HOST.ATTACKER.COM is the attacking host. . DNS.ATTACKER.COM is ATTACKER.COM's nameserver, we presume that this is the only name server for ATTACKER.COM to simplify the description. . DNS.TARGET.COM is the target nameserver which runs BIND. What we will attempt to do is add an A (address) resource record on DNS.TARGET.COM that will resolve WWW.SPOOFED.COM to 127.0.0.1. We are sure that WWW.SPOOFED.COM is not cached in DNS.TARGET.COM's DNS cache. . DNS.SPOOFED.COM is the nameserver for SPOOFED.COM's domain. We have determined this before the attack begins. Once again we just presume its the only one in order to simplify this description. Problem I. - The Attack ~~~~~~~~~~~~~~~~~~~~~~~ A. First a query is sent to DNS.TARGET.COM asking for the address of UNKNOWN.ATTACKER.COM. Our query has the recursion desired bit set, meaning that if the nameserver we are querying has recursion enabled, it will query another nameserver with our query (assuming it does not have the information cached). B. DNS.TARGET.COM will first determine who serves the ATTACKER.COM domain, then it will build a query packet and send it to DNS.ATTACKER.COM. C. We sniff DNS.ATTACKER.COM's local network and retrieve the query packet sent by DNS.TARGET.COM to DNS.ATTACKER.COM. We can then determine the query ID (qid0) used by DNS.TARGET.COM. Chances are that the next queries generated by DNS.TARGET.COM will have query IDs that will fall in the range [qid0,qid0+N] where N is dependent on the amount of queries DNS.TARGET.COM is generating in the period of time on which the attack takes place. N is usually <= 10 for most cases. D. Once we have determined what the next query ID generated will be, we send a query to DNS.TARGET.COM asking for WWW.SPOOFED.COM's address. E. Then we start sending spoofed DNS replies from DNS.SPOOFED.COM, telling DNS.TARGET.COM that WWW.SPOOFED.COM is '127.0.0.1'. F. If we guessed the query ID used by DNS.TARGET.COM in its recursed query and our response is received first, our response will be taken as valid and the address will be cached. Subsequent responses will be discarded as duplicates. We can always send many (N*M) spoofed packets with different IDs in the range (qid0,qid0+N] so we will be sure that at least one of them will hit DNS.TARGET.COM and have the 'right' ID. M is a factor dependent of the amount of UDP packets we expect to lose on their way to DNS.TARGET.COM. Problem I. - The Result ~~~~~~~~~~~~~~~~~~~~~~~ If the attack succeeded, any query to DNS.TARGET.COM asking for WWW.SPOOFED.COM's address, will get 127.0.0.1 as a response. Thus, any user on TARGET.COM's domain will connect to 127.0.0.1 if they try to contact WWW.SPOOFED.COM. The usage of 127.0.0.1 in this description is of course for instructional purposes, any IP address can be used, in particular an attacker could use its own IP address (BADGUY.COM's IP) so all connections to 'host' will go to 'BADGUY'. The attacker can then 'impersonate' WWW.SPOOFED.COM. Given this attack, it is easy to visualize the effects of impersonating a high traffic FTP distribution site. This attack can also be used to intercept email traffic, and bypass address based authentication methods, including TCP wrappers and firewalls. Problem I. - Notes ~~~~~~~~~~~~~~~~~~ This attack depends on a few things to succeed: 1. The attacker has complete control of DNS.ATTACKER.COM's network, he can both spoof and sniff DNS packets there. In particular, he can sniff DNS packets sent to DNS.ATTACKER.COM. 2. Spoofed DNS responses sent from the attacker to DNS.TARGET.COM must be received before the legit response from DNS.SPOOFED.COM. This is very easy to achieve. In testing we have not yet encountered a situation where we could not get our packets to the nameserver first. 3. The name server on DNS.TARGET.COM supports recursion and caches responses. This is common practice. It should be noted that most nameservers allow recursion (unless specifically denied by configuration options). Root name servers, however, do not allow recursion. If DNS.TARGET.COM caches negative responses as well (NCACHE), a denial of service attack can be performed, in this case, spoofed responses sent by the attacker will tell DNS.TARGET.COM that WWW.SPOOFED.COM does not exist (and be authorative on this). The existence of several nameservers for the domains does not alter the basic outline of this attack. The attacker would only need to send DNS responses with source addresses of each of SPOOFED.COM's nameservers. (N*M*I responses, where I is the number of nameservers). Problem I. - Systems Affected ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - All systems using BIND as their domain name server with recursion enabled. - - Windows NT (server) version 3.51 & 4.0 DNS server. Microsoft has been notified and has acknowledged this is a serious problem. No information on a fix is availible. Problem II. Hostname length checking ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Problem II. - Impact ~~~~~~~~~~~~~~~~~~~~ BIND allows passing of hostnames larger than MAXHOSTNAMELEN in size to programs. As many programs utilize buffers of size MAXHOSTNAMELEN and copy the results from a query into these buffers, an overflow can occur. This can allow an attacker to execute arbitrary commands on a remote server in a worst case scenario. Problem II. - Systems Affected ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All systems running BIND. Fix Information ~~~~~~~~~~~~~~~ Obtain BIND version 4.9.5-P1. BIND is availible from ftp.isc.org in the directory /isc/bind/src. Patches to solve both problem I and problem II are included at the end of this advisory. Once BIND has been obtained, follow the following procedure: i. First remove the patches from this text. This can be performed by removing all text in between the "CUT HERE" lines, and saving it to a text file (i.e. /tmp/diffs.txt). ii. Perform the following operations to apply the patches: % gzip -d bind.tar.gz % mkdir bind % cd bind % tar -xvf ../bind.tar % patch < /tmp/diffs.txt iii. Rebuild BIND Attributions ~~~~~~~~~~~~ Ivan Arce Emiliano Kargieman The OpenBSD Project Who found a good solution to problem, developed a solution and performed various tests to ensure its correctness. Individuals involved in this effort were: Theo de Raadt Niels Provos Todd Miller Allen Briggs Further attributions: AUSCERT David Sacerdote Oliver Friedrichs Alfred Huger Additional Information: ~~~~~~~~~~~~~~~~~~~~~~~ [1] Vixie P. , "DNS and BIND security issues". This was originally published in the proceedings of the 5th USENIX Security Symposium and its included in the BIND distribution under the doc/misc directory. [2] Kumar A., Postel J., Neuman C., Danzig P. , Miller S. "RFC1536: Common DNS implementation errors and suggested fixes" Refer to problem 2 for a description of other weaknesses previously found in the recursion scheme. [3] Lottor, M., "RFC1033: Domain administrators operations guide" [4] Mockapetris, P., "RFC1034: Domain names - Concepts and facilities" [5] Mockapetris, P., "RFC1035: Domain Names - Implementation and specification" [6] Schuba Christopher and Spafford Eugene, "Adressing weaknesses in the Domain Name System Protocol", COAST Laboratory, Department of Computer Science, Purdue University. Comments and questions regarding this advisory can be sent to: Ivan Arce Emiliano Kargieman For more information about CORE S.A. contact: core@secnet.com Or visit: http://www.secnet.com/core Encrypted mail can also be sent to encrypted with the following PGP key: Type Bits/KeyID Date User ID pub 1024/9E55000D 1997/01/13 Secure Networks Inc. Secure Networks - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia mQCNAzLaFzIAAAEEAKsVzPR7Y6oFN5VPE/Rp6Sm82oE0y6Mkuof8QzERV6taihn5 uySb31UeNJ4l6Ud9alOPT/0YdeOO9on6eD1iU8qumFxzO3TLm8nTAdZehQSAQfoa rWmpwj7KpXN/3n+VyBWvhpBdKxe08SQN4ZjvV5HXy4YIrE5bTbgIhFKeVQANAAUR tCVTZWN1cmUgTmV0d29ya3MgSW5jLiA8c25pQHNlY25ldC5jb20+iQCVAwUQM1yd EB/bLKAOe7p9AQFptAQAiYpaZCpSmGgr05E698Z3t5r5BPAKUEtgvF53AvZUQLxz ZsYsVU5l5De0qKWJOQ/9LiDyWu1lvKhlTphbLy2RatWD4kO3oQL9v3TpSXm2WQhU uIzyZvj7S5ENodNnKn+gCDIvbou6OMot+7dRbWWgN2oabbru4CSlOxbG++yaTz+J AJUDBRAzTefbtOXez5VgyLkBAd0bA/43eGEgvPOFK+HHWCPpkSWCwtrtDU/dxOVz 9erHnT/CRxeojCI+50f71Qe+kvx9Q1odz2Jl/fLxhnPQdbPnpWblIbu4F8H+Syrj HTilDrl1DWa/nUNgK8sb27SMviELczP1a8gwA1eo5SUCG5TWLLTAzjWOgTxod2Ha OwseUHmqVIkAlQMFEDNOVsr/d6Iw8NVIbQEBxM0D/14XRfgSLwszgJcVbslMHm/B fF6tHoWYojzQle3opOuMYHNN8GsMZRkc1qQ8QuNA9Aj5+qDqEontGjV5IvhBu1fY FM77AhagskaFCZxwqV64Qrk328WDO89NGSd+RuovVNruDdn20TxNCEVuPTHjI0UA 8H+E6FW9jexg6RTHhPXYtCVTZWN1cmUgTmV0d29ya3MgPHNlY3VyaXR5QHNlY25l dC5jb20+iQCVAwUQMtqTKB/bLKAOe7p9AQFw5wQAgUwqJ+ZqfEy/lO1srU3nzxLA X0uHGHrMptRy/LFo8swD6G1TtWExUc3Yv/6g2/YK09b5WmplEJ+Q09maQIw+RU/s cIY+EsPauqIq4JTGh/Nm0Z4UDl2Y1x4GNtm0YqezxUPS0P0A3LHVLJ3Uo5og0G8O gPNrfbVz5ieT14OSCWCJAJUDBRAy2hd2/3eiMPDVSG0BAVNhBACfupfAcNhhnQaq aI03DOOiZSRjvql1xw4V+pPhM+IksdSK3YNUZVJJtANacgDhBT+jAPRaYbBWI3A5 ZMdcSNM8aTG0LWMLIOiOYEm6Lgd3idRBFN0Js08eyITl8mhZ33mDe4I0KQri9UiV ZcPYTbb9CWM6Hv2cMbt6S6kLnFziqIkAlQMFEDLaF0+4CIRSnlUADQEBCLoEAJwt UofDgvyZ4nCDx1KKAPkkXBRaPMWBp46xeTVcxaYiloZfwHfpk1h2mEJAxmAsvizl OtIppHl4isUxcGi/E2mLCLMvis22/IQP/9obPahPvgNaMLVtZljO1Nv3QFEkNciL FEUTNJHR1ko7ibCxkBs4cOpirFuvTMDvWnNaXAf8 =DchE - -----END PGP PUBLIC KEY BLOCK----- Copyright Notice ~~~~~~~~~~~~~~~~ The contents of this advisory are Copyright (C) 1997 Secure Networks Inc and CORE Seguridad de la Informacion S.A., and may be distributed freely provided that no fee is charged for distribution, and that proper credit is given. You can find Secure Networks papers at ftp://ftp.secnet.com/pub/papers and advisories at ftp://ftp.secnet.com/advisories You can browse our web site at http://www.secnet.com You can subscribe to our security advisory mailing list by sending mail to majordomo@secnet.com with the line "subscribe sni-advisories" Patches ~~~~~~~ --- CUT HERE --- diff -cNr ../bind-4.9.5-P1-rel/contrib/host/host.c ./contrib/host/host.c *** ../bind-4.9.5-P1-rel/contrib/host/host.c Sat Oct 12 16:24:42 1996 - --- ./contrib/host/host.c Wed Apr 9 15:27:05 1997 *************** *** 537,543 **** _res.retrans = DEF_RETRANS; /* timeout in secs between retries */ /* initialize packet id */ ! _res.id = getpid() & 0x7fff; /* save new defaults */ new_res = _res; - --- 537,543 ---- _res.retrans = DEF_RETRANS; /* timeout in secs between retries */ /* initialize packet id */ ! _res.id = res_randomid(); /* save new defaults */ new_res = _res; diff -cNr ../bind-4.9.5-P1-rel/named/ns_main.c ./named/ns_main.c *** ../bind-4.9.5-P1-rel/named/ns_main.c Tue Nov 26 03:11:23 1996 - --- ./named/ns_main.c Wed Apr 9 00:24:14 1997 *************** *** 1658,1668 **** } /* ! * These are here in case we ever want to get more clever, like perhaps ! * using a bitmap to keep track of outstanding queries and a random ! * allocation scheme to make it a little harder to predict them. Note ! * that the resolver will need the same protection so the cleverness ! * should be put there rather than here; this is just an interface layer. */ void - --- 1658,1668 ---- } /* ! * This just an interface layer to the random number generator ! * used in the resolver. ! * A special random number generator is used to create non predictable ! * and non repeating ids over a long period. It also avoids reuse ! * by switching between two distinct number cycles. */ void *************** *** 1674,1683 **** u_int16_t nsid_next() { ! if (nsid_state == 65535) ! nsid_state = 0; ! else ! nsid_state++; return (nsid_state); } - --- 1674,1680 ---- u_int16_t nsid_next() { ! nsid_state = res_randomid(); return (nsid_state); } diff -cNr ../bind-4.9.5-P1-rel/res/Makefile ./res/Makefile *** ../bind-4.9.5-P1-rel/res/Makefile Thu Aug 8 16:49:48 1996 - --- ./res/Makefile Wed Apr 9 00:32:13 1997 *************** *** 77,89 **** res_comp.c res_init.c res_mkquery.c res_query.c res_send.c \ getnetbyaddr.c getnetbyname.c getnetent.c getnetnamadr.c \ gethnamaddr.c sethostent.c nsap_addr.c hostnamelen.c inet_addr.c \ ! inet_ntop.c inet_neta.c inet_pton.c inet_net_ntop.c inet_net_pton.c OBJS= base64.o herror.o res_debug.o res_data.o \ res_comp.o res_init.o res_mkquery.o res_query.o res_send.o \ getnetbyaddr.o getnetbyname.o getnetent.o getnetnamadr.o \ gethnamaddr.o sethostent.o nsap_addr.o hostnamelen.o inet_addr.o \ ! inet_ntop.o inet_neta.o inet_pton.o inet_net_ntop.o inet_net_pton.o all: libresolv.a - --- 77,91 ---- res_comp.c res_init.c res_mkquery.c res_query.c res_send.c \ getnetbyaddr.c getnetbyname.c getnetent.c getnetnamadr.c \ gethnamaddr.c sethostent.c nsap_addr.c hostnamelen.c inet_addr.c \ ! inet_ntop.c inet_neta.c inet_pton.c inet_net_ntop.c inet_net_pton.c \ ! res_random.c OBJS= base64.o herror.o res_debug.o res_data.o \ res_comp.o res_init.o res_mkquery.o res_query.o res_send.o \ getnetbyaddr.o getnetbyname.o getnetent.o getnetnamadr.o \ gethnamaddr.o sethostent.o nsap_addr.o hostnamelen.o inet_addr.o \ ! inet_ntop.o inet_neta.o inet_pton.o inet_net_ntop.o inet_net_pton.o \ ! res_random.o all: libresolv.a diff -cNr ../bind-4.9.5-P1-rel/res/res_comp.c ./res/res_comp.c *** ../bind-4.9.5-P1-rel/res/res_comp.c Mon Dec 2 02:17:22 1996 - --- ./res/res_comp.c Fri Apr 18 18:45:02 1997 *************** *** 98,103 **** - --- 98,105 ---- dn = exp_dn; cp = comp_dn; + if (length > MAXHOSTNAMELEN-1) + length = MAXHOSTNAMELEN-1; eom = exp_dn + length; /* * fetch next label in domain name diff -cNr ../bind-4.9.5-P1-rel/res/res_init.c ./res/res_init.c *** ../bind-4.9.5-P1-rel/res/res_init.c Sat Sep 28 00:51:07 1996 - --- ./res/res_init.c Wed Apr 9 00:33:30 1997 *************** *** 197,209 **** if (!(_res.options & RES_INIT)) _res.options = RES_DEFAULT; - - /* - - * This one used to initialize implicitly to zero, so unless the app - - * has set it to something in particular, we can randomize it now. - - */ - - if (!_res.id) - - _res.id = res_randomid(); - - #ifdef USELOOPBACK _res.nsaddr.sin_addr = inet_makeaddr(IN_LOOPBACKNET, 1); #else - --- 197,202 ---- *************** *** 644,655 **** return(0); /* if not using DNS configuration from NetInfo */ } #endif /* NeXT */ - - - - u_int - - res_randomid() - - { - - struct timeval now; - - - - gettimeofday(&now, NULL); - - return (0xffff & (now.tv_sec ^ now.tv_usec ^ getpid())); - - } - --- 637,639 ---- diff -cNr ../bind-4.9.5-P1-rel/res/res_mkquery.c ./res/res_mkquery.c *** ../bind-4.9.5-P1-rel/res/res_mkquery.c Sat Sep 28 00:37:58 1996 - --- ./res/res_mkquery.c Wed Apr 9 00:31:30 1997 *************** *** 107,118 **** #endif /* * Initialize header fields. */ if ((buf == NULL) || (buflen < HFIXEDSZ)) return (-1); bzero(buf, HFIXEDSZ); hp = (HEADER *) buf; ! hp->id = htons(++_res.id); hp->opcode = op; hp->rd = (_res.options & RES_RECURSE) != 0; hp->rcode = NOERROR; - --- 107,123 ---- #endif /* * Initialize header fields. + * + * A special random number generator is used to create non predictable + * and non repeating ids over a long period. It also avoids reuse + * by switching between two distinct number cycles. */ + if ((buf == NULL) || (buflen < HFIXEDSZ)) return (-1); bzero(buf, HFIXEDSZ); hp = (HEADER *) buf; ! hp->id = htons(_res.id=res_randomid()); hp->opcode = op; hp->rd = (_res.options & RES_RECURSE) != 0; hp->rcode = NOERROR; diff -cNr ../bind-4.9.5-P1-rel/res/res_random.c ./res/res_random.c *** ../bind-4.9.5-P1-rel/res/res_random.c Wed Dec 31 17:00:00 1969 - --- ./res/res_random.c Tue Apr 22 02:31:25 1997 *************** *** 0 **** - --- 1,262 ---- + /* $OpenBSD: res_random.c,v 1.3 1997/04/19 10:07:01 provos Exp $ */ + + /* + * Copyright 1997 Niels Provos + * All rights reserved. + * + * Theo de Raadt came up with the idea of using + * such a mathematical system to generate more random (yet non-repeating) + * ids to solve the resolver/named problem. But Niels designed the + * actual system based on the constraints. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by Niels Provos. + * 4. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + + /* + * seed = random 15bit + * n = prime, g0 = generator to n, + * j = random so that gcd(j,n-1) == 1 + * g = g0^j mod n will be a generator again. + * + * X[0] = random seed. + * X[n] = a*X[n-1]+b mod m is a Linear Congruential Generator + * with a = 7^(even random) mod m, + * b = random with gcd(b,m) == 1 + * m = 31104 and a maximal period of m-1. + * + * The transaction id is determined by: + * id[n] = seed xor (g^X[n] mod n) + * + * Effectivly the id is restricted to the lower 15 bits, thus + * yielding two different cycles by toggling the msb on and off. + * This avoids reuse issues caused by reseeding. + * + * The 16 bit space is very small and brute force attempts are + * entirly feasible, we skip a random number of transaction ids + * so that an attacker will not get sequential ids. + */ + + #include + #include + #include + #include + + #if defined(BSD) && (BSD >= 199103) + # include + # include + # include + #else + # include "../conf/portability.h" + #endif + + #define RU_OUT 180 /* Time after wich will be reseeded */ + #define RU_MAX 30000 /* Uniq cycle, avoid blackjack prediction */ + #define RU_GEN 2 /* Starting generator */ + #define RU_N 32749 /* RU_N-1 = 2*2*3*2729 */ + #define RU_AGEN 7 /* determine ru_a as RU_AGEN^(2*rand) */ + #define RU_M 31104 /* RU_M = 2^7*3^5 - don't change */ + + #define PFAC_N 3 + const static u_int16_t pfacts[PFAC_N] = { + 2, + 3, + 2729 + }; + + static u_int16_t ru_x; + static u_int16_t ru_seed; + static u_int16_t ru_a, ru_b; + static u_int16_t ru_g; + static u_int16_t ru_counter = 0; + static u_int16_t ru_msb = 0; + static long ru_reseed; + static u_int32_t tmp; /* Storage for unused random */ + static struct timeval tv; + + static u_int32_t pmod __P((u_int32_t, u_int32_t, u_int32_t)); + static void res_initid __P((void)); + + #ifndef __OpenBSD__ + /* + * No solid source of strong random in the system. Sigh. Fake it. + */ + u_long + arc4random() + { + static char state[256]; + char *savestate; + char *setstate(); + static unsigned seed; + static int count; + u_long datum; + + if (++count == 129837 || seed == 0) { + struct timeval tv; + + count = 0; + gettimeofday(&tv, NULL); + seed = getpid() ^ tv.tv_sec ^ tv.tv_usec; + initstate(seed, state, sizeof state); + } + savestate = setstate(state); + datum = random(); + setstate(savestate); + return (datum); + } + + #endif + + /* + * Do a fast modular exponation, returned value will be in the range + * of 0 - (mod-1) + */ + + static u_int32_t + pmod(gen, exp, mod) + u_int32_t gen, exp, mod; + { + u_int32_t s, t, u; + + s = 1; + t = gen; + u = exp; + + while (u) { + if (u & 1) + s = (s*t) % mod; + u >>= 1; + t = (t*t) % mod; + } + return (s); + } + + /* + * Initalizes the seed and chooses a suitable generator. Also toggles + * the msb flag. The msb flag is used to generate two distinct + * cycles of random numbers and thus avoiding reuse of ids. + * + * This function is called from res_randomid() when needed, an + * application does not have to worry about it. + */ + static void + res_initid() + { + u_int16_t j, i; + int noprime = 1; + + tmp = arc4random(); + ru_x = (tmp & 0xFFFF) % RU_M; + + /* 15 bits of random seed */ + ru_seed = (tmp >> 16) & 0x7FFF; + + tmp = arc4random(); + + /* Determine the LCG we use */ + ru_b = (tmp & 0xfffe) | 1; + ru_a = pmod(RU_AGEN, (tmp >> 16) & 0xfffe, RU_M); + while (ru_b % 3 == 0) + ru_b += 2; + + tmp = arc4random(); + j = tmp % RU_N; + tmp = tmp >> 16; + + /* + * Do a fast gcd(j,RU_N-1), so we can find a j with + * gcd(j, RU_N-1) == 1, giving a new generator for + * RU_GEN^j mod RU_N + */ + + while (noprime) { + for (i=0; i=PFAC_N) + noprime = 0; + else + j = (j+1) % RU_N; + } + + ru_g = pmod(RU_GEN,j,RU_N); + ru_counter = 0; + + gettimeofday(&tv, NULL); + ru_reseed = tv.tv_sec + RU_OUT; + ru_msb = ru_msb == 0x8000 ? 0 : 0x8000; + } + + u_int + res_randomid() + { + int i, n; + + gettimeofday(&tv, NULL); + if (ru_counter >= RU_MAX || tv.tv_sec > ru_reseed) + res_initid(); + + if (!tmp) + tmp = arc4random(); + + /* Skip a random number of ids */ + n = tmp & 0x2f; tmp = tmp >> 6; + if (ru_counter + n >= RU_MAX) + res_initid(); + + for (i=0; i<=n; i++) + /* Linear Congruential Generator */ + ru_x = (ru_a*ru_x + ru_b) % RU_M; + + ru_counter += i; + + return (ru_seed ^ pmod(ru_g,ru_x,RU_N)) | ru_msb; + } + + #if 0 + void + main(int argc, char **argv) + { + int i, n; + u_int16_t wert; + + res_initid(); + + printf("Generator: %d\n", ru_g); + printf("Seed: %d\n", ru_seed); + printf("Reseed at %ld\n", ru_reseed); + printf("Ru_X: %d\n", ru_x); + printf("Ru_A: %d\n", ru_a); + printf("Ru_B: %d\n", ru_b); + + n = atoi(argv[1]); + for (i=0;i Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA02122 for security-outgoing; Wed, 23 Apr 1997 07:19:12 -0700 (PDT) Received: from utopia.nh.ultranet.com (jbowie@this.wanker.is.a.teensysop.org [207.41.158.32]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA02108 for ; Wed, 23 Apr 1997 07:18:54 -0700 (PDT) Received: from localhost (jbowie@localhost) by utopia.nh.ultranet.com (8.8.5/8.8.5) with SMTP id KAA01026; Wed, 23 Apr 1997 10:15:31 GMT X-Authentication-Warning: utopia.nh.ultranet.com: jbowie owned process doing -bs Date: Wed, 23 Apr 1997 10:15:30 +0000 (GMT) From: The Code Warrior X-Sender: jbowie@utopia.nh.ultranet.com To: Dmitry Valdov cc: freebsd-security@FreeBSD.ORG Subject: Re: SNI-12: BIND Vulnerabilities and Solutions (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 22 Apr 1997, Dmitry Valdov wrote: > Hello! > > Is fbsd 2.2.1 vulnerable? If yes are there any patches available specially > for FreeBSD? > > Well, I would have to say it is definitely vulnerable to the first prob- lem presented, as the BIND code is all the same, and the 2.2.1 release has a BIND distro which falls within the version constraints of the exploit, that it would have to be vulnerable. The second vulnerability however might not apply to us. I haven't checked the gethostby* libs, so I'm not sure if the resolver does internal bounds checking, rather than just letting you overflow the stack with a spoofed DNS name. I will look into it this afternoon. -Jon Bowie SysAdmin / Consulting / TeenSysop. 603-436-5698 jbowie@bsdnet.org "...And I still believe that I can not be saved." -Billy Corgan From owner-freebsd-security Wed Apr 23 11:53:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA16740 for security-outgoing; Wed, 23 Apr 1997 11:53:38 -0700 (PDT) Received: from usc.usc.unal.edu.co ([200.21.26.65]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA16723 for ; Wed, 23 Apr 1997 11:53:06 -0700 (PDT) Received: from unalmodem11.usc.unal.edu.co by usc.usc.unal.edu.co (AIX 4.1/UCB 5.64/4.03) id AA702128; Wed, 23 Apr 1997 14:51:55 -0400 Message-Id: <335E75CF.705E@fps.biblos.unal.edu.co> Date: Wed, 23 Apr 1997 13:49:19 -0700 From: Pedro Giffuni X-Mailer: Mozilla 3.0 (Win16; I) Mime-Version: 1.0 To: security@freebsd.org Subject: Possible security hole in 2.2 Release. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Howdy, One of my users reported rlogin didn't ask for a password when he tried to log from a remote box in another faculty. I haven't had the time to check this out (I am sick and in home). The problem was only detected from one Solaris box that doesn't has it's hostname correctly configured. The .rhosts files are from the standard distribution and include a line, "+ +" that may be causing the problem. I closed r* services on this box until I have a chance to check this thoroughly. Pedro. From owner-freebsd-security Wed Apr 23 16:56:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA01476 for security-outgoing; Wed, 23 Apr 1997 16:56:56 -0700 (PDT) Received: from jg.dyn.ml.org (newport-1-13.quick.net [207.212.160.213]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA01469 for ; Wed, 23 Apr 1997 16:56:46 -0700 (PDT) Received: from localhost (soil@localhost) by jg.dyn.ml.org (8.8.5/8.8.5) with SMTP id QAA01398 for ; Wed, 23 Apr 1997 16:56:13 -0700 (PDT) X-Authentication-Warning: jg.dyn.ml.org: soil owned process doing -bs Date: Wed, 23 Apr 1997 16:56:13 -0700 (PDT) From: Josh Gilliam X-Sender: soil@jg.dyn.ml.org To: freebsd-security@freebsd.org Subject: SYN flood on 3.0-CURRENT Message-ID: X-IRC: soil X-Operating-System: FreeBSD 3.0-CURRENT i386 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Today I was SYN flooded with random spoofed address. The SYN flood protection didn't seem to help much. Several real connections timed out and new connections couldn't be established. Here is 100 lines of log. Apr 23 16:37:21 jg /kernel: ipfw: 11 Allow TCP 145.92.80.33:12654 207.212.160.213:25 via tun0 Apr 23 16:37:21 jg /kernel: ipfw: 11 Allow TCP 161.165.92.55:10202 207.212.160.213:23 via tun0 Apr 23 16:37:21 jg /kernel: ipfw: 11 Allow TCP 96.176.190.87:10619 207.212.160.213:25 via tun0 Apr 23 16:37:21 jg /kernel: ipfw: 11 Allow TCP 14.52.164.59:32194 207.212.160.213:23 via tun0 Apr 23 16:37:21 jg /kernel: ipfw: 11 Allow TCP 93.243.245.39:16278 207.212.160.213:25 via tun0 Apr 23 16:37:21 jg /kernel: ipfw: 11 Allow TCP 142.117.224.14:4424 207.212.160.213:23 via tun0 Apr 23 16:37:21 jg /kernel: ipfw: 11 Allow TCP 5.202.117.2:24441 207.212.160.213:23 via tun0 Apr 23 16:37:21 jg /kernel: ipfw: 11 Allow TCP 167.222.144.96:19554 207.212.160.213:25 via tun0 Apr 23 16:37:21 jg /kernel: ipfw: 11 Allow TCP 146.103.220.10:19320 207.212.160.213:23 via tun0 Apr 23 16:37:21 jg /kernel: ipfw: 11 Allow TCP 233.181.38.101:9558 207.212.160.213:25 via tun0 Apr 23 16:37:21 jg /kernel: ipfw: 11 Allow TCP 88.128.217.126:19723 207.212.160.213:23 via tun0 Apr 23 16:37:21 jg /kernel: ipfw: 11 Allow TCP 50.69.168.47:17281 207.212.160.213:25 via tun0 Apr 23 16:37:21 jg /kernel: ipfw: 11 Allow TCP 173.167.96.30:31157 207.212.160.213:23 via tun0 Apr 23 16:37:21 jg /kernel: ipfw: 11 Allow TCP 111.209.221.60:5215 207.212.160.213:25 via tun0 Apr 23 16:37:21 jg /kernel: ipfw: 11 Allow TCP 6.162.16.49:6277 207.212.160.213:23 via tun0 Apr 23 16:37:21 jg /kernel: ipfw: 11 Allow TCP 146.125.202.71:24469 207.212.160.213:23 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 11.108.244.5:15263 207.212.160.213:25 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 60.64.174.58:20925 207.212.160.213:23 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 210.20.33.40:24427 207.212.160.213:23 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 78.172.97.43:13339 207.212.160.213:25 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 110.195.193.86:6248 207.212.160.213:23 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 115.207.132.24:24387 207.212.160.213:25 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 201.91.141.67:17795 207.212.160.213:23 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 126.99.183.70:4938 207.212.160.213:25 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 221.128.146.114:10912 207.212.160.213:23 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 99.68.234.109:18282 207.212.160.213:25 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 126.172.82.102:19512 207.212.160.213:23 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 19.13.34.48:4014 207.212.160.213:25 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 179.242.39.84:29110 207.212.160.213:23 via tun0 Apr 23 16:37:22 jg /kernel: 7.168.201.120:13633 207.212.160.213:23 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 146.49.185.48:11189 207.212.160.213:25 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 216.179.193.91:8406 207.212.160.213:23 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 231.61.241.115:12304 207.212.160.213:25 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 161.140.44.123:23974 207.212.160.213:23 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 64.231.251.60:16862 207.212.160.213:25 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 97.90.128.69:22940 207.212.160.213:23 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 255.127.2.96:21239 207.212.160.213:25 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 193.246.132.101:26676 207.212.160.213:23 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 87.47.155.23:21186 207.212.160.213:25 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 67.171.212.22:24293 207.212.160.213:25 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 160.32.175.8:12599 207.212.160.213:23 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 225.21.114.124:13208 207.212.160.213:25 via tun0 Apr 23 16:37:22 jg /kernel: ipfw: 11 Allow TCP 150.189.128.4:16268 207.212.160.213:23 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 109.4.80.11:21451 207.212.160.213:25 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 125.0.200.34:11819 207.212.160.213:23 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 35.86.131.122:25840 207.212.160.213:25 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 176.54.229.64:4813 207.212.160.213:23 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 231.47.183.87:17244 207.212.160.213:25 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 128.152.99.86:31170 207.212.160.213:23 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 12.23.46.45:18960 207.212.160.213:25 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 215.28.22.58:4608 207.212.160.213:23 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 2.47.218.23:27951 207.212.160.213:25 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 243.242.80.9:15296 207.212.160.213:23 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 178.252.27.75:27216 207.212.160.213:25 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 151.123.214.116:24225 207.212.160.213:23 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 196.109.9.3:21814 207.212.160.213:25 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 149.242.32.106:13930 207.212.160.213:23 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 99.178.230.34:21888 207.212.160.213:25 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 191.222.19.94:28204 207.212.160.213:23 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 129.43.106.119:31557 207.212.160.213:25 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 146.214.218.98:19931 207.212.160.213:23 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 146.108.146.27:16277 207.212.160.213:25 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 193.212.140.94:4433 207.212.160.213:23 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 130.105.74.113:6316 207.212.160.213:25 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 210.170.205.51:14492 207.212.160.213:23 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 116.143.155.11:26967 207.212.160.213:25 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 20.101.68.72:26901 207.212.160.213:25 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 148.140.64.50:10471 207.212.160.213:23 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 170.194.136.15:7362 207.212.160.213:23 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 192.246.253.81:5318 207.212.160.213:25 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 5.168.204.50:4220 207.212.160.213:23 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 225.160.116.119:13620 207.212.160.213:25 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 118.55.121.26:7392 207.212.160.213:23 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 200.201.17.57:2877 207.212.160.213:25 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 116.219.213.11:19762 207.212.160.213:23 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 16.67.114.120:10218 207.212.160.213:25 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 104.109.241.94:9528 207.212.160.213:23 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 42.145.56.0:12777 207.212.160.213:25 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 63.222.254.51:12889 207.212.160.213:23 via tun0 Apr 23 16:37:23 jg /kernel: ipfw: 11 Allow TCP 39.237.167.80:12363 207.212.160.213:25 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 237.212.97.3:24782 207.212.160.213:23 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 105.178.66.6:26084 207.212.160.213:25 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 157.180.36.113:15547 207.212.160.213:23 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 125.206.88.77:3092 207.212.160.213:25 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 187.252.250.101:27967 207.212.160.213:23 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 237.186.225.47:8671 207.212.160.213:25 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 215.118.22.46:2344 207.212.160.213:23 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 16.35.186.74:26246 207.212.160.213:25 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 249.113.179.40:9593 207.212.160.213:23 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 83.66.22.38:7212 207.212.160.213:25 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 158.191.76.58:21988 207.212.160.213:23 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 108.192.49.72:13182 207.212.160.213:25 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 80.177.87.107:32398 207.212.160.213:23 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 11.103.75.2:14694 207.212.160.213:25 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 31.75.87.126:1714 207.212.160.213:23 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 95.8.73.19:11278 207.212.160.213:25 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 62.46.188.76:9683 207.212.160.213:23 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 102.127.57.58:3266 207.212.160.213:25 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 237.96.5.36:17904 207.212.160.213:23 via tun0 Apr 23 16:37:24 jg /kernel: ipfw: 11 Allow TCP 102.95.96.60:3398 207.212.160.213:25 via tun0 -- Josh Gilliam Orange, California, USA soil@quick.net From owner-freebsd-security Wed Apr 23 18:46:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA07088 for security-outgoing; Wed, 23 Apr 1997 18:46:27 -0700 (PDT) Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA07080 for ; Wed, 23 Apr 1997 18:46:24 -0700 (PDT) Received: from apriori.cc.cmu.edu (APRIORI.CC.CMU.EDU [128.2.72.117]) by cmu1.acs.cmu.edu (8.8.2/8.7.3) with SMTP id VAA04516; Wed, 23 Apr 1997 21:45:24 -0400 Date: Wed, 23 Apr 1997 21:45:23 -0400 (EDT) From: Robert N Watson X-Sender: rnw@apriori.cc.cmu.edu To: Pedro Giffuni cc: security@freebsd.org Subject: Re: Possible security hole in 2.2 Release. In-Reply-To: <335E75CF.705E@fps.biblos.unal.edu.co> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk My 2.2.1 default dot.rhosts in /usr/share/skel reads as follows: # $Id: dot.rhosts,v 1.3 1996/09/21 21:35:47 wosch Exp $ # # .rhosts - trusted remote host name and user data base # # see hosts.equiv(5), rsh(1), rlogin(1), rcp(1) # # This file should NOT be group or other readable. # OtherMachine # OtherMachine myFriend This doesn't appear to include + +, which certainly would cause the problem you identify :). BTW, I've read that the "#" at the beginning of the line is a bad idea, as you can pursuade a DNS server to pass back "#" as your host name, and spoof your way in. Do the r* service authentication routines ignore # signs, really? :) ---- Robert Watson On Wed, 23 Apr 1997, Pedro Giffuni wrote: > Howdy, > One of my users reported rlogin didn't ask for a password when he tried > to log from a remote box in another faculty. I haven't had the time to > check this out (I am sick and in home). The problem was only detected > from one Solaris box that doesn't has it's hostname correctly > configured. > The .rhosts files are from the standard distribution and include a line, > "+ +" that may be causing the problem. > I closed r* services on this box until I have a chance to check this > thoroughly. > > Pedro. > From owner-freebsd-security Wed Apr 23 20:10:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA11851 for security-outgoing; Wed, 23 Apr 1997 20:10:20 -0700 (PDT) Received: from usc.usc.unal.edu.co ([200.21.26.65]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id UAA11841 for ; Wed, 23 Apr 1997 20:10:08 -0700 (PDT) Received: from unalmodem15.usc.unal.edu.co by usc.usc.unal.edu.co (AIX 4.1/UCB 5.64/4.03) id AA145306; Wed, 23 Apr 1997 23:08:55 -0400 Message-Id: <335EEA4A.6450@fps.biblos.unal.edu.co> Date: Wed, 23 Apr 1997 22:06:19 -0700 From: Pedro Giffuni X-Mailer: Mozilla 3.0 (Win16; I) Mime-Version: 1.0 To: Robert N Watson Cc: security@freebsd.org Subject: Re: Possible security hole in 2.2 Release. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk My 2.2-Release has as .rhosts : # $Id: dot.rhosts,v 1.3 1996/09/21 21:35:47 wosch Exp $ # # .rhosts - trusted remote host name and user data base # # see hosts.equiv(5), rsh(1), rlogin(1), rcp(1) # # This file should NOT be group or other readable. # OtherMachine # OtherMachine myFriend + + # And here is (in part) the wtmp file: yonny ttyp0 invalid hostname Wed Apr 23 14:27 - 14:27 (00:00) pedro ttyp0 168.176.3.41 Wed Apr 23 14:11 - 14:11 (00:00) yonny ttyp0 invalid hostname Wed Apr 23 12:31 - 12:37 (00:06) yonny ftp invalid hostname Wed Apr 23 12:30 - 12:30 (00:00) yonny ttyp0 invalid hostname Wed Apr 23 11:23 - 11:24 (00:01) pedro ttyp0 168.176.3.43 Wed Apr 23 10:29 - 10:29 (00:00) yonny ttyp0 invalid hostname Wed Apr 23 10:10 - 10:12 (00:01) _______________________________ My .dot file is exactly like yours :(. Either my box was cracked and + + added to all users (two) or this is added someway by default. Pedro. Robert N Watson wrote: > > My 2.2.1 default dot.rhosts in /usr/share/skel reads as follows: > > # $Id: dot.rhosts,v 1.3 1996/09/21 21:35:47 wosch Exp $ > # > # .rhosts - trusted remote host name and user data base > # > # see hosts.equiv(5), rsh(1), rlogin(1), rcp(1) > # > # This file should NOT be group or other readable. > # OtherMachine > # OtherMachine myFriend > > This doesn't appear to include + +, which certainly would cause the > problem you identify :). BTW, I've read that the "#" at the beginning of > the line is a bad idea, as you can pursuade a DNS server to pass back "#" > as your host name, and spoof your way in. Do the r* service > authentication routines ignore # signs, really? :) > > ---- > Robert Watson > > On Wed, 23 Apr 1997, Pedro Giffuni wrote: > > > Howdy, > > One of my users reported rlogin didn't ask for a password when he tried > > to log from a remote box in another faculty. I haven't had the time to > > check this out (I am sick and in home). The problem was only detected > > from one Solaris box that doesn't has it's hostname correctly > > configured. > > The .rhosts files are from the standard distribution and include a line, > > "+ +" that may be causing the problem. > > I closed r* services on this box until I have a chance to check this > > thoroughly. > > > > Pedro. > > From owner-freebsd-security Wed Apr 23 22:42:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA17354 for security-outgoing; Wed, 23 Apr 1997 22:42:21 -0700 (PDT) Received: from insanity.dorm.umd.edu (insanity.dorm.umd.edu [129.2.154.11]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA17349 for ; Wed, 23 Apr 1997 22:42:17 -0700 (PDT) Received: from insanity.dorm.umd.edu (LOCALHOST [127.0.0.1]) by insanity.dorm.umd.edu (8.8.5/8.6.12) with ESMTP id BAA20967 for ; Thu, 24 Apr 1997 01:41:59 -0400 (EDT) Message-Id: <199704240541.BAA20967@insanity.dorm.umd.edu> X-Mailer: exmh version 2.0gamma 1/27/96 To: freebsd-security@freebsd.org Subject: sperl buffer overflow Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Apr 1997 01:41:57 -0400 From: Shadow Lord Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I cvsupped the latest 2.2 release, and it doesn't seem to have any changes for sperl. Is this in the process of being fixed? Cory. PS - I didn't include the exploits because I know people on this list are paranoid about that. ------- Forwarded Message Date: Mon, 21 Apr 1997 16:34:41 PDT Reply-To: Deliver Sender: Bugtraq List From: Deliver Subject: Exploits for FreeBSD sperl4.036 & sperl5.00x To: BUGTRAQ@netspace.org If somebody want to test perl5.00X or perl4.036 buffer overflow exploits there are two for FreeBSD... First works on perl4.036 and the second on perl5.002 ... With a little modyfication of OFFSET value you can overflow all versions up to perl5.003 < exploit omitted> From owner-freebsd-security Thu Apr 24 01:32:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA24056 for security-outgoing; Thu, 24 Apr 1997 01:32:44 -0700 (PDT) Received: from unique.usn.blaze.net.au (unique.usn.blaze.net.au [203.17.53.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA24051 for ; Thu, 24 Apr 1997 01:32:39 -0700 (PDT) Received: from unique.usn.blaze.net.au (local [127.0.0.1]) by unique.usn.blaze.net.au (8.8.5/8.8.5) with ESMTP id SAA29303; Thu, 24 Apr 1997 18:31:45 +1000 (EST) Message-Id: <199704240831.SAA29303@unique.usn.blaze.net.au> X-Mailer: exmh version 2.0gamma 1/27/96 To: Robert N Watson cc: Pedro Giffuni , security@freebsd.org Subject: Re: Possible security hole in 2.2 Release. In-reply-to: Your message of "Wed, 23 Apr 1997 21:45:23 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Apr 1997 18:31:45 +1000 From: David Nugent Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Do the r* service authentication routines ignore # signs, really? :) Yes, they do. Lines commencing with '#' are skipped. From owner-freebsd-security Thu Apr 24 08:15:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA10915 for security-outgoing; Thu, 24 Apr 1997 08:15:37 -0700 (PDT) Received: from sand.sentex.ca (sand.sentex.ca [206.222.77.6]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA10910; Thu, 24 Apr 1997 08:15:34 -0700 (PDT) Received: from gravel (gravel.sentex.ca [205.211.165.210]) by sand.sentex.ca (8.8.5/8.8.3) with SMTP id LAA01437; Thu, 24 Apr 1997 11:20:03 -0400 (EDT) Message-Id: <3.0.1.32.19970424111952.00a1f1e0@sentex.net> X-Sender: mdtancsa@sentex.net X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 24 Apr 1997 11:19:52 -0400 To: freebsd-isp@freebsd.org, security@freebsd.org From: Mike Tancsa Subject: Commercial vs built in firewall capabilities of FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After looking around a lot of the firewall sites and browsing through the firewall list archives, I am still not entirely clear what a commercial firewall costing $10K U.S. would give me over the basic firewalling capabilities in FreeBSD combined with sshd, NAT, proxy servers and or SOCKS v5... Although VPN would be a very nice feature to have to link up remote offices, if this is not necessary, should we reccomend to the client to go out and spend $10K on a commercial firewall solution as opposed to a FreeBSD box ? ---Mike ********************************************************************** Mike Tancsa (mike@sentex.net) * To do is to be -- Nietzsche Sentex Communications Corp, * To be is to do -- Sartre Cambridge, Ontario * Do be do be do -- Sinatra (http://www.sentex.net/~mdtancsa) * From owner-freebsd-security Thu Apr 24 08:58:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA12939 for security-outgoing; Thu, 24 Apr 1997 08:58:39 -0700 (PDT) Received: from phobos.frii.com (phobos.frii.com [204.144.241.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA12928 for ; Thu, 24 Apr 1997 08:58:35 -0700 (PDT) From: gnat@frii.com Received: from elara.frii.com (elara.frii.com [204.144.241.9]) by phobos.frii.com (8.8.5/8.8.4) with ESMTP id JAA22120; Thu, 24 Apr 1997 09:55:24 -0600 (MDT) Received: (from gnat@localhost) by elara.frii.com (8.8.5/8.6.9) id JAA07930; Thu, 24 Apr 1997 09:55:24 -0600 (MDT) Date: Thu, 24 Apr 1997 09:55:24 -0600 (MDT) Message-Id: <199704241555.JAA07930@elara.frii.com> To: Shadow Lord Cc: freebsd-security@freebsd.org Subject: Re: sperl buffer overflow In-Reply-To: <199704240541.BAA20967@insanity.dorm.umd.edu> References: <199704240541.BAA20967@insanity.dorm.umd.edu> Mime-Version: 1.0 (generated by tm-edit 7.103) Content-Type: text/plain; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Shadow Lord writes: > I cvsupped the latest 2.2 release, and it doesn't seem to have any > changes for sperl. Is this in the process of being fixed? As a paid-up memeber of the Perl Porters list, I can safely say that a fix for 5.003 (and a release of 5.004) are highly imminent. By that I mean, a week tops, but most likely within a day or two. Eagle eyed folks are going over the source with a fine-toothed comb looking for other buffer overflows even as we speak. Nat From owner-freebsd-security Thu Apr 24 09:15:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA14043 for security-outgoing; Thu, 24 Apr 1997 09:15:03 -0700 (PDT) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA14024; Thu, 24 Apr 1997 09:14:55 -0700 (PDT) Received: (from karpen@localhost) by ocean.campus.luth.se (8.7.5/8.7.3) id SAA16227; Thu, 24 Apr 1997 18:22:53 +0200 (MET DST) From: Mikael Karpberg Message-Id: <199704241622.SAA16227@ocean.campus.luth.se> Subject: Re: Commercial vs built in firewall capabilities of FreeBSD To: mike@sentex.net (Mike Tancsa) Date: Thu, 24 Apr 1997 18:22:52 +0200 (MET DST) Cc: freebsd-isp@freebsd.org, security@freebsd.org In-Reply-To: <3.0.1.32.19970424111952.00a1f1e0@sentex.net> from Mike Tancsa at "Apr 24, 97 11:19:52 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: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Mike Tancsa: > > After looking around a lot of the firewall sites and browsing through the > firewall list archives, I am still not entirely clear what a commercial > firewall costing $10K U.S. would give me over the basic firewalling > capabilities in FreeBSD combined with sshd, NAT, proxy servers and or SOCKS > v5... Although VPN would be a very nice feature to have to link up remote > offices, if this is not necessary, should we reccomend to the client to go > out and spend $10K on a commercial firewall solution as opposed to a > FreeBSD box ? How's "Firewall1"'s ability to analyze the traffic and such, for example? Like, it can let outgoing UPD go out, and answers to it come back, but nothing else. And it will look into FTP packets and snoop your connections for port setups, and let that port connect, when it comes. Thereby, ftp, archie, or anything else which has problems with firewalls willwork as expected. And... you can make it filter out the ActiveX components of web pages, etc. Plus: You get a real easy to set up, GUI configuration thing, which will by pure eay-to-use factor make your firewall safer, since you wont forget anything so easilly. Sure, you can do that with FreeBSD. Just use divert sockets, and write a program to handle it. Problem is, you'll spend quite a lot of money in developing the same functions. You DO get something for you money, you really do. I'm all for FreeBSD as a firewall, and anything else, basically. However, it's all about what your budget is. If they have the money, I think it's problably worth it. /Mikael From owner-freebsd-security Thu Apr 24 09:29:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA15095 for security-outgoing; Thu, 24 Apr 1997 09:29:34 -0700 (PDT) Received: from biggusdiskus.flyingfox.com (biggusdiskus.flyingfox.com [206.14.52.27]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA15087; Thu, 24 Apr 1997 09:29:30 -0700 (PDT) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.5/8.8.5) id JAA08107; Thu, 24 Apr 1997 09:28:36 -0700 (PDT) Date: Thu, 24 Apr 1997 09:28:36 -0700 (PDT) From: Jim Shankland Message-Id: <199704241628.JAA08107@biggusdiskus.flyingfox.com> To: freebsd-isp@freebsd.org, mike@sentex.net, security@freebsd.org Subject: Re: Commercial vs built in firewall capabilities of FreeBSD Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Part of what you're buying in a commercial firewall is expertise: packaged implicitly in the product, ongoing support services, and in some cases, bundled consulting services with firewall setup. Yes, you can roll a pretty good firewall with FreeBSD, socksv5, ssh, etc. It just takes some expertise and time. Whether you're better off spending that (assuming you have it), or spending the money for a commercial product, is purely a business decision. Jim Shankland Flying Fox Computer Systems, Inc. From owner-freebsd-security Thu Apr 24 09:40:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA15806 for security-outgoing; Thu, 24 Apr 1997 09:40:49 -0700 (PDT) Received: from sand.sentex.ca (sand.sentex.ca [206.222.77.6]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA15801; Thu, 24 Apr 1997 09:40:45 -0700 (PDT) Received: from gravel (gravel.sentex.ca [205.211.165.210]) by sand.sentex.ca (8.8.5/8.8.3) with SMTP id MAA00373; Thu, 24 Apr 1997 12:44:26 -0400 (EDT) Message-Id: <3.0.1.32.19970424124424.00b04100@sentex.net> X-Sender: mdtancsa@sentex.net X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 24 Apr 1997 12:44:24 -0400 To: Mikael Karpberg From: Mike Tancsa Subject: Re: Commercial vs built in firewall capabilities of FreeBSD Cc: freebsd-isp@freebsd.org, security@freebsd.org In-Reply-To: <199704241622.SAA16227@ocean.campus.luth.se> References: <3.0.1.32.19970424111952.00a1f1e0@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 06:22 PM 4/24/97 +0200, Mikael Karpberg wrote: >According to Mike Tancsa: >> >> After looking around a lot of the firewall sites and browsing through the >> firewall list archives, I am still not entirely clear what a commercial >> firewall costing $10K U.S. would give me over the basic firewalling >> capabilities in FreeBSD combined with sshd, NAT, proxy servers and or SOCKS >> v5... Although VPN would be a very nice feature to have to link up remote >> offices, if this is not necessary, should we reccomend to the client to go >> out and spend $10K on a commercial firewall solution as opposed to a >> FreeBSD box ? > First of all, thank you for your response. >How's "Firewall1"'s ability to analyze the traffic and such, for >example? Like, it can let outgoing UPD go out, and answers to it come >back, but nothing else. And it will look into FTP packets and snoop your >connections for port setups, and let that port connect, when it comes. >Thereby, ftp, archie, or anything else which has problems with firewalls >willwork as expected. And... you can make it filter out the ActiveX >components of web pages, etc. Plus: You get a real easy to set up, GUI >configuration thing, which will by pure eay-to-use factor make your firewall >safer, since you wont forget anything so easilly. I think the client in this case doesnt even want to let the remote offices do any sort of web browsing, and they will not be hosting any public information at the satelite offices. The firewalls will merely allow the remote offices to share data on their NT network. I want to present them with as many options as possible from the "Firewall on a shoe string budget" to the deluxo modles out there. For the lower end of the price scale, I was thinking of something like FreeBSD as the gateway with all the attandant security software, combined with SKIP (www.skip.org) to provide the VPN between the many small offices that they have. >You DO get something for you money, you really do. I'm all for FreeBSD as >a firewall, and anything else, basically. However, it's all about what your >budget is. If they have the money, I think it's problably worth it. Yes, I can see how a simplified interface goes a long way to catching potentiall dangerous misconfigurations. However, I am the type of person who does not like to see money needlessly spent. Also, I am looking at this investigation in terms of future reccomendations as well. We have many smaller customers who do not have the capital available to spend lots of money on security, but never the less should have a decent amount... Hell, even at home here... I have a little 2 node network connected to the net through my FreeBSD box. Since I installed the firewall options on it, I have been rather suprised at home many sites want to do SMB negotiations when I have been browsing the web from my NT box... (e.g. http://www.ntsecurity.net/security/ie3-4.htm), and I found this entry rather suprising the other day in my filter logs.... Apr 23 20:33:31 sand /kernel: ipfw: 6000 Deny UDP 205.211.165.210:137 204.216.27.18:137 via tun0 (thats hub.FreeBSD.ORG)... I like having a firewall at home, and I like to have as much security as possible... But of course, I dont have $10K to spend on peace of mind ;-) Thanks again for taking the time to respond... Researching this project has been most interesting! ---Mike ********************************************************************** Mike Tancsa (mike@sentex.net) * To do is to be -- Nietzsche Sentex Communications Corp, * To be is to do -- Sartre Cambridge, Ontario * Do be do be do -- Sinatra (http://www.sentex.net/~mdtancsa) * From owner-freebsd-security Thu Apr 24 10:02:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA17096 for security-outgoing; Thu, 24 Apr 1997 10:02:23 -0700 (PDT) Received: from sand.sentex.ca (sand.sentex.ca [206.222.77.6]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA17088; Thu, 24 Apr 1997 10:02:12 -0700 (PDT) Received: from gravel (gravel.sentex.ca [205.211.165.210]) by sand.sentex.ca (8.8.5/8.8.3) with SMTP id NAA00412; Thu, 24 Apr 1997 13:06:23 -0400 (EDT) Message-Id: <3.0.1.32.19970424130621.00b82320@sentex.net> X-Sender: mdtancsa@sentex.net X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 24 Apr 1997 13:06:21 -0400 To: Jim Shankland , freebsd-isp@freebsd.org, security@freebsd.org From: Mike Tancsa Subject: Re: Commercial vs built in firewall capabilities of FreeBSD In-Reply-To: <199704241628.JAA08107@biggusdiskus.flyingfox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 09:28 AM 4/24/97 -0700, Jim Shankland wrote: >Part of what you're buying in a commercial firewall is expertise: >packaged implicitly in the product, ongoing support services, and >in some cases, bundled consulting services with firewall setup. > >Yes, you can roll a pretty good firewall with FreeBSD, socksv5, >ssh, etc. It just takes some expertise and time. Whether you're >better off spending that (assuming you have it), or spending the >money for a commercial product, is purely a business decision. Thanks for the response. Yes, this is the way my boss and I have looked at it. We decided to investigate the project as much as possible ourselves, because we see this as a potentially new market for us to get into... i.e. low cost security solutions to our customers. For example, we have several non-profit organizations who would like to have some firewalling solutions, but do not have a great deal of money to spend.. So far, FreeBSD+ SKIP to do VPN seems like an enticing solution for *some* situations... We have setup many FreeBSD boxes and can do it quite quickly from scratch now, so the skill set is already there... To go to a new dedicated customer and say "look, we can give you a unit that will act as your gateway, provide decent security for your LAN for basically the cost of the hardware, plus our consulting fee, or you can go with one of these commercial products for $XXX, and will provide you with YYY features that the other solution wont give you", gives us that much more flexibility... I guess what I am really after in asking these questions is a response like "FreeBSD + its security software ? No way! You cant protect against XXXXX attacks... Its crucial!" But so far, I havent seen any show stoppers... One thing I have found somewhat suprising in this research project is the reaction to Microsoft's PPTP RFC, or to be more precise, the lack of reaction to it. I did a search through Dejanews (for those of you who havent tried it, check out http://www.dejanews.com), and found absolutely no mention of in in the FreeBSD mailing lists, or in the newsgroups, and hardly any mention of it even in comp.unix*... Is it because its a Microsoft initiative ? ---Mike ********************************************************************** Mike Tancsa (mike@sentex.net) * To do is to be -- Nietzsche Sentex Communications Corp, * To be is to do -- Sartre Cambridge, Ontario * Do be do be do -- Sinatra (http://www.sentex.net/~mdtancsa) * From owner-freebsd-security Thu Apr 24 11:58:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA24104 for security-outgoing; Thu, 24 Apr 1997 11:58:00 -0700 (PDT) Received: from pinky.junction.net (pinky.junction.net [199.166.227.12]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA24087; Thu, 24 Apr 1997 11:57:53 -0700 (PDT) Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id LAA06549; Thu, 24 Apr 1997 11:57:44 -0700 Received: from localhost (michael@localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id LAA03970; Thu, 24 Apr 1997 11:52:58 -0700 Date: Thu, 24 Apr 1997 11:52:56 -0700 (PDT) From: Michael Dillon To: freebsd-isp@FreeBSD.ORG cc: security@FreeBSD.ORG Subject: Re: Commercial vs built in firewall capabilities of FreeBSD In-Reply-To: <3.0.1.32.19970424130621.00b82320@sentex.net> Message-ID: Organization: Memra Software Inc. - Internet consulting MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 24 Apr 1997, Mike Tancsa wrote: > One thing I have found somewhat suprising in this research project is the > reaction to Microsoft's PPTP RFC, or to be more precise, the lack of > reaction to it. I did a search through Dejanews (for those of you who > havent tried it, check out http://www.dejanews.com), and found absolutely > no mention of in in the FreeBSD mailing lists, or in the newsgroups, and > hardly any mention of it even in comp.unix*... Is it because its a > Microsoft initiative ? It's a proprietary Microsoft protocol and there is an IETF WG working on combining PPTP and Cisco's L2F into a unified L2TP. Michael Dillon - Internet & ISP Consulting Memra Software Inc. - Fax: +1-250-546-3049 http://www.memra.com - E-mail: michael@memra.com From owner-freebsd-security Thu Apr 24 12:06:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA24564 for security-outgoing; Thu, 24 Apr 1997 12:06:18 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA24553; Thu, 24 Apr 1997 12:06:14 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA29033; Thu, 24 Apr 1997 12:04:29 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd029030; Thu Apr 24 19:04:27 1997 Message-ID: <335FAEA4.446B9B3D@whistle.com> Date: Thu, 24 Apr 1997 12:04:04 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Mike Tancsa CC: Jim Shankland , freebsd-isp@freebsd.org, security@freebsd.org Subject: Re: Commercial vs built in firewall capabilities of FreeBSD References: <3.0.1.32.19970424130621.00b82320@sentex.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mike Tancsa wrote: > [...] To go to a new dedicated customer and > say "look, we can give you a unit that will act as your gateway, provide > decent security for your LAN for basically the cost of the hardware, plus > our consulting fee, or you can go with one of these commercial products for > $XXX, and will provide you with YYY features that the other solution wont > give you", gives us that much more flexibility... > > I guess what I am really after in asking these questions is a response like > "FreeBSD + its security software ? No way! You cant protect against XXXXX > attacks... Its crucial!" But so far, I havent seen any show stoppers... > > One thing I have found somewhat suprising in this research project is the > reaction to Microsoft's PPTP RFC, or to be more precise, the lack of > reaction to it. I did a search through Dejanews (for those of you who > havent tried it, check out http://www.dejanews.com), and found absolutely > no mention of in in the FreeBSD mailing lists, or in the newsgroups, and > hardly any mention of it even in comp.unix*... Is it because its a > Microsoft initiative ? > check out www.whistle.com for a FreeBSD based version of what you are talking about. VPNs are not yet implimented and the firewalling is still being improved. but as a drop-in box it does admirably and it's a lot cheaper. > From owner-freebsd-security Thu Apr 24 12:35:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA25926 for security-outgoing; Thu, 24 Apr 1997 12:35:06 -0700 (PDT) Received: from ns2.gamespot.com (ns2.gamespot.com [206.169.18.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA25917; Thu, 24 Apr 1997 12:35:02 -0700 (PDT) Received: from tiramisu.gamespot.com (tiramisu.gamespot.com [206.169.18.119]) by ns2.gamespot.com (8.8.5/8.8.5) with SMTP id MAA20680; Thu, 24 Apr 1997 12:35:00 -0700 (PDT) Message-Id: <3.0.32.19970424123611.008bdb50@mail.gamespot.com> X-Sender: ian@mail.gamespot.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 24 Apr 1997 12:36:12 -0700 To: freebsd-isp@FreeBSD.org, security@FreeBSD.org From: Ian Kallen Subject: Re: Commercial vs built in firewall capabilities of FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk The IETF told Cisco and Microsoft to merge their VPN technology 'cause they were sufficiently similar but not interoperable. I don't know what the implimentation schedule is though. I tried to answer my objection to NT's lack of secure remote administration by using pcAnywhere over a pptp link. No go. Since I couldn't run a tcp/ip capable application over the link, it made me sour on pptp en generale. I don't remotely admin any NT boxes over the net. There's a lot of issues MS has to deal with for NT to be taken seriously as an internet platform, IMO. At 01:06 PM 4/24/97 -0400, Mike Tancsa wrote: >One thing I have found somewhat suprising in this research project is the >reaction to Microsoft's PPTP RFC, or to be more precise, the lack of >reaction to it. I did a search through Dejanews (for those of you who >havent tried it, check out http://www.dejanews.com), and found absolutely >no mention of in in the FreeBSD mailing lists, or in the newsgroups, and >hardly any mention of it even in comp.unix*... Is it because its a >Microsoft initiative ? -- Ian Kallen ian@gamespot.com Director of Technology and Web Administration SpotMedia Communications http://www.gamespot.com/ http://www.videogamespot.com/ From owner-freebsd-security Thu Apr 24 21:16:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA22180 for security-outgoing; Thu, 24 Apr 1997 21:16:19 -0700 (PDT) Received: from mailhub.cns.ksu.edu (grunt.ksu.ksu.edu [129.130.12.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA22175 for ; Thu, 24 Apr 1997 21:16:17 -0700 (PDT) From: joed@ksu.edu Received: from fox (joed@fox.ksu.ksu.edu [129.130.12.11]) by mailhub.cns.ksu.edu (8.8.5/8.8.5/mailhub+tar@ksu.edu) with SMTP id XAA03798 for ; Thu, 24 Apr 1997 23:16:03 -0500 (CDT) Received: by fox (SMI-8.6/1.34) id XAA00719; Thu, 24 Apr 1997 23:16:02 -0500 Message-Id: <199704250416.XAA00719@fox> Subject: What's on Port 1024? To: security@freebsd.org Date: Thu, 24 Apr 1997 23:16:01 -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: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Greetings, I'm currently in the proccess of trying to lock down a FreeBSD workstation as a firewall, and noticed that my FreeBSD machine is listening to port 1024. I'm fairly stumped as to what this might be.. According to the port number database (http://www.sockets.com/services.htm) 1024 is reserved. Any thought as to what's listening to this port? Please CC: replies to me at joed@ksu.edu. Thanks --- Joe Diehl PGP Key: finger joed@unix.ksu.edu From owner-freebsd-security Thu Apr 24 22:40:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA25860 for security-outgoing; Thu, 24 Apr 1997 22:40:56 -0700 (PDT) Received: from dedicavia.inetcan.net (dedicavia.inetcan.net [206.186.215.200]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA25854 for ; Thu, 24 Apr 1997 22:40:53 -0700 (PDT) Received: from localhost (dreamer@localhost) by dedicavia.inetcan.net (8.8.5/8.7.3) with SMTP id XAA00512 for ; Thu, 24 Apr 1997 23:42:54 -0600 Date: Thu, 24 Apr 1997 23:42:52 -0600 (MDT) From: Steven Young Reply-To: dreamer@inetcan.net To: freebsd-security@freebsd.org Subject: NLS hole.. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Greetings! Does anyone know if FreeBSD is vunerable to the NLS problems recently outlined in the CERT advid released just today (or yesterday, depending on where you live ;)? The advisory was less that specific, as CERT data tends to be, and as such it made it kind of hard for one such as I to track down if they're vunerable or not. dreamer From owner-freebsd-security Fri Apr 25 00:55:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA00680 for security-outgoing; Fri, 25 Apr 1997 00:55:45 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA00674 for ; Fri, 25 Apr 1997 00:55:41 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.4/8.8.4) id AAA17278; Fri, 25 Apr 1997 00:55:33 -0700 (PDT) Message-ID: <19970425005533.56693@hydrogen.nike.efn.org> Date: Fri, 25 Apr 1997 00:55:33 -0700 From: John-Mark Gurney To: joed@ksu.edu Cc: security@freebsd.org Subject: Re: What's on Port 1024? References: <199704250416.XAA00719@fox> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199704250416.XAA00719@fox>; from joed@ksu.edu on Thu, Apr 24, 1997 at 11:16:01PM -0500 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2-960801-SNAP i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk joed@ksu.edu scribbled this message on Apr 24: > Greetings, > > I'm currently in the proccess of trying to lock down a FreeBSD workstation > as a firewall, and noticed that my FreeBSD machine is listening to port > 1024. I'm fairly stumped as to what this might be.. According to the > port number database (http://www.sockets.com/services.htm) 1024 is > reserved. > > Any thought as to what's listening to this port? try: lsof | grep 1024 on my machine it returns a line like: xdm 214 root 5u inet 0xf17bbc00 0t0 TCP *:1024 so it looks like the process is xdm.... ttyl.. -- John-Mark Cu Networking Modem/FAX: +1 541 683 6954 Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-security Fri Apr 25 07:40:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA19525 for security-outgoing; Fri, 25 Apr 1997 07:40:33 -0700 (PDT) Received: from cwsys.cwent.com (66@cschuber.net.gov.bc.ca [142.31.240.113]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA19382; Fri, 25 Apr 1997 07:39:41 -0700 (PDT) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.5/8.6.10) id HAA06922; Fri, 25 Apr 1997 07:39:01 -0700 (PDT) Message-Id: <199704251439.HAA06922@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd006918; Fri Apr 25 14:38:51 1997 Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: MH To: security-officer@freebsd.org cc: freebsd-security@freebsd.org Subject: CERT Advisory CA-97.10 - Vulnerability in Natural Language Service Date: Fri, 25 Apr 1997 07:38:50 -0700 From: Cy Schubert Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I remember that FreeBSD had some NLS problems a couple of months ago. Does this CERT advisory apply to FreeBSD too? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." ------- Forwarded Message Received: from localhost (cschuber@localhost) by passer.osg.gov.bc.ca (8.8.5/8.6.10) with SMTP id JAA18088; Thu, 24 Apr 1997 09:42:08 -0700 (PDT) X-UIDL: 861972822.001 Resent-Message-Id: <199704241642.JAA18088@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: cschuber@localhost didn't use HELO protocol Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.5/8.6.10) id JAA17779 for ; Thu, 24 Apr 1997 09:42:07 -0700 (PDT) Received: from orca.gov.bc.ca(142.32.102.25) via SMTP by passer.osg.gov.bc.ca, id smtpdAAAaarnka; Thu Apr 24 09:42:01 1997 Received: from coal.cert.org by orca.gov.bc.ca (5.4R3.10/200.1.1.4) id AA07022; Thu, 24 Apr 1997 09:41:58 -0700 Received: (from cert-advisory@localhost) by coal.cert.org (8.6.12/CERT) id MAA10415 for cert-advisory-queue-5; Thu, 24 Apr 1997 12:30:37 -0400 Date: Thu, 24 Apr 1997 12:30:37 -0400 Message-Id: <199704241630.MAA10415@coal.cert.org> From: CERT Advisory To: cert-advisory@cert.org Subject: CERT Advisory CA-97.10 - Vulnerability in Natural Language Service Reply-To: cert-advisory-request@cert.org Organization: CERT(sm) Coordination Center - +1 412-268-7090 Resent-To: cy@uumail.gov.bc.ca, pblake@uumail.gov.bc.ca Resent-Date: Thu, 24 Apr 1997 09:42:08 -0700 Resent-From: Cy Schubert - ITSD Open Systems Group - -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= CERT* Advisory CA-97.10 Original issue date: April 24, 1997 Last revised: -- Topic: Vulnerability in Natural Language Service - - ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of a buffer overflow condition that affects some libraries using the Natural Language Service (NLS) on UNIX systems. By exploiting this vulnerability, any local user can execute arbitrary programs as a privileged user. There is a possibility (with some old libraries) that the vulnerability can be exploited by a remote user. Exploitation information is publicly available. The CERT/CC team recommends installing patches when they become available. 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 buffer overflow condition affects libraries using the Natural Language Service (NLS). The NLS is the component of UNIX systems that provides facilities for customizing the natural language formatting for the system. Examples of the types of characteristics that can be set are language, monetary symbols and delimiters, numeric delimiters, and time formats. Some libraries that use a particular environment variable associated with the NLS contain a vulnerability in which a buffer overflow condition can be triggered. The particular environment variable involved is NLSPATH on some systems and PATH_LOCALE on others. It is possible to exploit this vulnerability to attain unauthorized access by supplying carefully crafted arguments to programs that are owned by a privileged user-id and that have setuid or setgid bits set. Exploit information involving this vulnerability has been made publicly available. II. Impact Local users (users with access to an account on the system) are able to execute arbitrary programs as a privileged user without authorization. There is a possibility (with some old libraries) that the vulnerability can be exploited by a remote user. III. Solution Install a patch for this problem when one becomes available. Currently, there is no workaround to use in the meantime. Below is a list of vendors who have provided information about this problem. 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, the CERT/CC did not hear from that vendor. Please contact your vendor directly. Berkeley Software Design, Inc. (BSDI) Cray Research - A Silicon Graphics Company Data General Corporation Digital Equipment Corporation Hewlett-Packard Company IBM Corporation Linux Systems NEC Corporation NeXT/Apple The Santa Cruz Operation (SCO) Solbourne Sun Microsystems, Inc. ........................................................................... Appendix A - Vendor Information Below is a list of the vendors who have provided information for this advisory. We will update this appendix as we receive additional information. If you do not see your vendor's name, the CERT/CC did not hear from that vendor. Please contact the vendor directly. Berkeley Software Design, Inc. (BSDI) ===================================== No versions of BSD/OS are vulnerable to this problem. Cray Research - A Silicon Graphics Company ========================================== We're investigating. Data General Corporation ======================== We're investigating. Digital Equipment Corporation ============================= SOURCE: Digital Equipment Corporation Software Security Response Team Copyright (c) Digital Equipment Corporation 1997. All rights reserved. This reported problem is not present for Digital's ULTRIX or Digital UNIX Operating Systems Software. Hewlett-Packard Company ======================= Investigation in process, results -to date- indicate HP not vulnerable. This advisory will be updated when investigation is complete. IBM Corporation =============== All AIX releases are vulnerable to a variation of this advisory. AIX 3.2.5 --------- Apply the following fix to your system: PTFs - U447656 U447671 U447676 U447682 U447705 U447723 (APAR IX67405) To determine if you have these PTFs on your system, run the following command: lslpp -lB U447656 U447671 U447676 U447682 U447705 U447723 AIX 4.1 ------- Apply the following fix to your system: APAR - IX67407 To determine if you have this APAR on your system, run the following command: instfix -ik IX67407 Or run the following command: lslpp -h bos.rte.libc Your version of bos.rte.libc should be 4.1.5.7 or later. AIX 4.2 ------- Apply the following fixes to your system: APAR - IX67377 IX65693 To determine if you have these APARs on your system, run the following command: instfix -ik IX67377 IX65693 Or run the following command: lslpp -h bos.rte.libc Your version of bos.rte.libc should be 4.2.0.11 or later. (APAR IX65693 fixes a problem with the mkgroup command after IX67377 is applied.) To Order -------- APARs may be ordered using Electronic Fix Distribution (via FixDist) or from the IBM Support Center. For more information on FixDist, reference URL: http://service.software.ibm.com/aixsupport/ or send e-mail to aixserv@austin.ibm.com with a subject of "FixDist". IBM and AIX are registered trademarks of International Business Machines Corporation. Linux Systems ============= Linux systems running older C libraries are vulnerable. To check which C library is being used type linux% ldd /bin/ls libc.so.5 => /lib/libc.so.5.3.12 This indicates the machine is using libc 5.3.12. C libraries older than 5.3.12 (that is libc5.2.18, libc5.0.9 etc) are vulnerable to this bug and you should upgrade the C library. The release versions of libc 5.4.x are immune to this attack. If you have libc5.3.12 it is insecure unless it is the modified libc5.3.12 shipped with Red Hat 4.1, or as an upgrade on Red Hat 4.0. You can check this with the package manager: linux# rpm -q libc libc-5.3.12-17 Indicates you have version 17 of the package. This is the safe one. Red Hat 4.0 users who have not already upgraded their libc can obtain this package at ftp://ftp.redhat.com/pub/redhat/old-releases/redhat-4.0/updates/. NEC Corporation =============== NEC platforms are not affected by this vulnerability. NeXT/Apple ========== No versions of NeXTstep of OpenStep/Mach are vulnerable to this problem. The Santa Cruz Operation (SCO) ============================= We are investigating this problem and will provide updated information for this advisory when it becomes available. Solbourne ========= Solbourne is not vulnerable. Sun Microsystems, Inc. ====================== Not vulnerable. - - ----------------------------------------------------------------------------- The CERT Coordination Center staff thanks Wolfgang Ley of DFN-CERT for his 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 http://www.first.org/team-info). CERT/CC Contact Information - - ---------------------------- Email cert@cert.org Phone +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4) and are on call for emergencies during other hours. Fax +1 412-268-6989 Postal address CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 USA Using encryption We strongly urge you to encrypt sensitive information sent by email. We can support a shared DES key or PGP. Contact the CERT/CC for more information. Location of CERT PGP key ftp://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 email to cert-advisory-request@cert.org In the subject line, type SUBSCRIBE your-email-address - - --------------------------------------------------------------------------- Copyright 1997 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. * Registered U.S. Patent and Trademark Office. - - --------------------------------------------------------------------------- This file: ftp://info.cert.org/pub/cert_advisories/CA-97.10.nls http://www.cert.org click on "CERT Advisories" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Revision history - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBM1+AKXVP+x0t4w7BAQEUEgQAw697OwAlTU3RZNYQxX7HLwjOTfdidYHb 3thaI3hGs3dWWEBNrrgtlK1dw/1wpJHFv0fMf7cGYNJAv9tbiD01Z75CTY1majzM 6tb/SNxQAUbzV8iIajFgsAGE+qRREdOfV0ZBPMB+ti3sd32TC/xpUa9iu+O7JTdt Gqv9r0OwK3Y= =lHvi - -----END PGP SIGNATURE----- ------- End of Forwarded Message From owner-freebsd-security Fri Apr 25 07:49:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA20021 for security-outgoing; Fri, 25 Apr 1997 07:49:29 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id HAA19977; Fri, 25 Apr 1997 07:49:02 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wKmIN-0003oC-00; Fri, 25 Apr 1997 08:48:19 -0600 To: cschuber@uumail.gov.bc.ca Subject: Re: CERT Advisory CA-97.10 - Vulnerability in Natural Language Service Cc: security-officer@freebsd.org, freebsd-security@freebsd.org In-reply-to: Your message of "Fri, 25 Apr 1997 07:38:50 PDT." <199704251439.HAA06922@cwsys.cwent.com> References: <199704251439.HAA06922@cwsys.cwent.com> Date: Fri, 25 Apr 1997 08:48:19 -0600 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199704251439.HAA06922@cwsys.cwent.com> Cy Schubert writes: : I remember that FreeBSD had some NLS problems a couple of months ago. Does : this CERT advisory apply to FreeBSD too? No. FreeBSD 2.1.6 had the problem, but 2.1.7 doesn't. There was already a FreeBSD advisory on the problem. Warner From owner-freebsd-security Sat Apr 26 11:18:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA01607 for security-outgoing; Sat, 26 Apr 1997 11:18:20 -0700 (PDT) Received: from thought.calbbs.com (thought.calbbs.com [207.71.213.16]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA01599 for ; Sat, 26 Apr 1997 11:18:16 -0700 (PDT) Received: from localhost (localhost.calbbs.com [127.0.0.1]) by thought.calbbs.com (8.8.5/8.6.12) with SMTP id LAA00291 for ; Sat, 26 Apr 1997 11:17:51 -0700 (PDT) Date: Sat, 26 Apr 1997 11:17:51 -0700 (PDT) From: Brian Buchanan X-Sender: brian@thought.calbbs.com Reply-To: Brian Buchanan To: security@freebsd.org Subject: Lowering securelevel from userland Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Description: On my 2.2.1 system, I was able to lower the securelevel by taking over init with gdb. I compiled a copy of init with debug symbols by using -ggdb in the compile flags, then ran gdb using that for the symbol table and attached to process 1. I was able to execute setsecuritylevel(0) from gdb, although this caused the process to hang. Sending a signal woke it up long enough to let the securelevel get changed from 2 to 0 before init died with a segmentation fault. Even though the system was in an unstable state, I was able to remove the schg flags from /kernel and /sbin/init before rebooting the machine from the command line. Impact: An attacker who has gained superuser privilages can replace the kernel, delete append-only logs, or thrash the disks, even on a system that normally runs in highly secure mode. Exploit: One can do the following as the superuser to gain total control of a machine running at securelevel 1 or 2. gdb /usr/src/sbin/init/init.debug 1 (Attach to process 1, loading symbols from init compiled w/ -ggdb) signal SIGHUP (Process will get SIGHUP when it resumes) call setsecuritylevel(0) (Make init lower the security level) -- Brian Buchanan Mail: brian@calbbs.com UNIX sysadmin, webmaster webmaster@calbbs.com