From owner-freebsd-security@FreeBSD.ORG Sun Sep 26 00:52:07 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7506D16A4CF for ; Sun, 26 Sep 2004 00:52:07 +0000 (GMT) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C70A43D4C for ; Sun, 26 Sep 2004 00:52:07 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from speck.loki.lan (c-24-21-241-225.client.comcast.net [24.21.241.225]) by mail.bitfreak.org (Postfix) with ESMTP id DE8C219F3C; Sat, 25 Sep 2004 17:53:07 -0700 (PDT) Received: from spud (d2.loki.lan [172.21.42.22]) by speck.loki.lan (Postfix) with ESMTP id 916F73250; Sat, 25 Sep 2004 17:52:03 -0700 (PDT) From: "Darren Pilgrim" To: "'Antony Mawer'" , "'Chris Ryan'" Date: Sat, 25 Sep 2004 17:51:55 -0700 Message-ID: <001001c4a363$07f6c880$162a15ac@spud> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <414CE5E8.6000103@mawer.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal cc: 'Frankye - ML' cc: freebsd-security@freebsd.org Subject: RE: Attacks on ssh port X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2004 00:52:07 -0000 > -----Original Message----- > From: owner-freebsd-security@freebsd.org=20 > [mailto:owner-freebsd-security@freebsd.org] On Behalf Of Antony Mawer > Sent: Saturday, September 18, 2004 6:51 PM > To: Chris Ryan > Cc: Frankye - ML; freebsd-security@freebsd.org > Subject: Re: Attacks on ssh port >=20 >=20 > Chris Ryan wrote: > > protection - with the appropriate active firewall that > > blocks their IP address after x failed attempts > > permanently.... >=20 > Has anyone found any good scripts or utilities for automating=20 > this kind=20 > of thing? I too have been subject to these probings, and my initial=20 > thought was to firewall off any address after any number of incorrect=20 > attempts. >=20 > While I could write a script to parse the ipfilter logs, I didn't want = > to go re-inventing the wheel for something which I was sure someone=20 > would have already attempted. >=20 > Anyone have any suggestions? There's three factors: wasted bandwidth, a successful intrusion and log noise. Filtering mitigates bandwidth wastage. But unless you can place the = filter out at the point where the Big Fat Pipe feeds into your comparatively = small pipe (i.e., the ISP's router), it's pointless--the scans will still eat = your bandwidth. IP Filtering is at best a tertiary security measure. It = should not replace proper configuration and maintenance, which is what you're seeking to accomplish. Check out the DenyUsers sshd_config keyword. With it OpenSSH will block = any login attempt with an account listed by DenyUsers. DenyUsers-listed accounts produce logging sooner (upon receipt of the username, rather = than after four bad passwords) and have different log entries than normal password failures. Cutting down the log noise is then a simple matter = of adding a filter to 800.loginfail or whatever else you may be using to = read auth.log. From owner-freebsd-security@FreeBSD.ORG Sun Sep 26 08:33:04 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54A0416A4CE for ; Sun, 26 Sep 2004 08:33:04 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D4BD43D3F for ; Sun, 26 Sep 2004 08:33:04 +0000 (GMT) (envelope-from david.downey@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so3085326rnk for ; Sun, 26 Sep 2004 01:33:03 -0700 (PDT) Received: by 10.38.163.10 with SMTP id l10mr17725rne; Sun, 26 Sep 2004 01:33:02 -0700 (PDT) Received: by 10.38.82.69 with HTTP; Sun, 26 Sep 2004 01:33:02 -0700 (PDT) Message-ID: <6917b78104092601339f77948@mail.gmail.com> Date: Sun, 26 Sep 2004 04:33:02 -0400 From: "David D.W. Downey" To: Alex de Kruijff In-Reply-To: <20040924214909.GA784@alex.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <414C2798.7060509@withagen.nl> <6917b781040918103077c76f0c@mail.gmail.com> <20040924214909.GA784@alex.lan> cc: "freebsd-security@FreeBSD.ORG" Subject: Re: Attacks on ssh port X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "David D.W. Downey" List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2004 08:33:04 -0000 On Fri, 24 Sep 2004 23:49:09 +0200, Alex de Kruijff wrote: > > > > Then you can still see the attempts (and thus log the IP information > > for contacting the abuse@ for the responsible IP controller) while > > limiting your log sizes. > > This only logs the first tree catches (when the log attribuut is set) > per rule. You may want to set this a little higher like 100. > while I agree my example of 3 was low (meant only to instruct) I would say more along the lines of 25. if someone is hitting you 25 times in a row and getting tagged by that rule, you can bet your butt it's not a client of your's. -- David D.W. Downey From owner-freebsd-security@FreeBSD.ORG Sat Sep 25 14:02:48 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 165DD16A4CE for ; Sat, 25 Sep 2004 14:02:48 +0000 (GMT) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4191B43D1D for ; Sat, 25 Sep 2004 14:02:47 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from gothmog.gr (patr530-a233.otenet.gr [212.205.215.233]) i8PE2h2v013931; Sat, 25 Sep 2004 17:02:44 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.1/8.13.1) with ESMTP id i8PE2gVg078557; Sat, 25 Sep 2004 17:02:42 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.13.1/8.13.1/Submit) id i8PE2gWl078556; Sat, 25 Sep 2004 17:02:42 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Sat, 25 Sep 2004 17:02:42 +0300 From: Giorgos Keramidas To: Steve Shorter Message-ID: <20040925140242.GB78219@gothmog.gr> References: <20011107211316.A7830@nomad.lets.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011107211316.A7830@nomad.lets.net> Phone: +30-2610-312145 Mobile: +30-6944-116520 X-Mailman-Approved-At: Sun, 26 Sep 2004 16:08:09 +0000 cc: freebsd-security@freebsd.org cc: dwbear75@gmail.com Subject: Re: sharing /etc/passwd X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2004 14:02:48 -0000 On 2001-11-07 21:13, Steve Shorter wrote: > On Wed, Nov 07, 2001 at 07:02:09PM -0700, David Bear wrote: > > I need to sync /etc/passwd and /etc/group among multiple machines. I was > > thinking ldap would be a good method but am concerned about > > > > 1) the most secure way to do it > > 2) the most stable > > 3) things I don't know about this but should... > > > > any pointers to man pages/docs would be appreciated. > > Hmm... how about rsync? /usr/ports/net/rsync > -steve After reading a nice paper by Val Henson[1] I'm not so sure I'd trust sensitive information like password data to rsync without making sure that compare-by-hash is disabled if at all possible. There are other ways to use a common authentication server, shared by many machines. Kerberos and NIS or NIS+ are good examples. At least better than a ``blind copy'' of password files with rsync. Giorgos. --- References --- [1] Val Henson, "An Analysis of Compare-by-hash". In Proceedings of "HotOS IX: The 9th Workshop on Hot Topics in Operating Systems", pp. 13-18. [ http://www.nmt.edu/~val/review/hash.html ] From owner-freebsd-security@FreeBSD.ORG Sun Sep 26 11:11:07 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E043816A4CE for ; Sun, 26 Sep 2004 11:11:07 +0000 (GMT) Received: from mail.webmonster.de (datasink.webmonster.de [194.162.162.209]) by mx1.FreeBSD.org (Postfix) with SMTP id BB37243D5D for ; Sun, 26 Sep 2004 11:11:06 +0000 (GMT) (envelope-from karsten@rohrbach.de) Received: (qmail 48994 invoked by uid 1000); 26 Sep 2004 11:11:27 -0000 Date: Sun, 26 Sep 2004 13:11:05 +0200 From: "Karsten W. Rohrbach" To: Benjamin Krueger , postmaster@asu.edu Message-ID: <20040926111127.GA48155@mail.webmonster.de> Mail-Followup-To: "Karsten W. Rohrbach" , Benjamin Krueger , postmaster@asu.edu, dwbear75@gmail.com, Jeff Palmer , freebsd-security@FreeBSD.ORG References: <4.3.2.7.2.20020417230144.032ad390@nospam.lariat.org> <200204171923.g3HJNga58899@freefall.freebsd.org> <4.3.2.7.2.20020418095356.024354c0@nospam.lariat.org> <012901c1e725$da237e90$0286a8c0@jeffrey> <20020418154338.D23267@rain.macguire.net> <20020419014351.M60925@mail.webmonster.de> <20020418171454.E23267@rain.macguire.net> <15551.28671.448890.421578@caddis.yogotech.com> <20020418182442.H23267@rain.macguire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020418182442.H23267@rain.macguire.net> User-Agent: Mutt/1.4.2.1i X-Arbitrary-Number-Of-The-Day: 42 X-URL: http://www.rohrbach.de./ X-Work-URL: http://webmonster.de./ X-Work-Address: webmonster.de - Karsten W. Rohrbach; Mainzer Str. 106; 64293 Darmstadt; Germany" X-Work-Phone: +49 (0)171 8915569 X-Mailman-Approved-At: Sun, 26 Sep 2004 16:08:09 +0000 cc: freebsd-security@FreeBSD.ORG cc: dwbear75@gmail.com cc: Jeff Palmer Subject: Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2004 11:11:08 -0000 Fun, fun. I suggest checking the corresponding MTA configuration :) Return-Path: Delivered-To: rohrbach@mail.webmonster.de Received: (qmail 56434 invoked by uid 801); 24 Sep 2004 15:51:37 -0000 Delivered-To: vrohrbach-karsten@rohrbach.de Received: (qmail 56429 invoked from network); 24 Sep 2004 15:51:36 -0000 Received: from post5.inre.asu.edu (129.219.110.120) by mail.webmonster.de with SMTP; 24 Sep 2004 15:51:36 -0000 Received: from conversion.post5.inre.asu.edu by asu.edu (PMDF V6.1-1X6 #30769) id <0I4J00A01YI3KS@asu.edu> for karsten@rohrbach.de; Fri, 24 Sep 2004 08:46:51 -0700 (MST) Received: from smtp.asu.edu (smtp.asu.edu [129.219.110.107]) by asu.edu (PMDF V6.1-1X6 #30769) with ESMTP id <0I4J00939YI2VB@asu.edu>; Fri, 24 Sep 2004 08:46:51 -0700 (MST) Received: from moroni.pp.asu.edu (moroni.pp.asu.edu [129.219.69.200]) by smtp.asu.edu (8.12.10/8.12.10/asu_smtp_relay,nullclient,tcp_wrapped) with ESMTP id i8OFkj71012427; Fri, 24 Sep 2004 08:46:45 -0700 (MST) Received: by moroni.pp.asu.edu (Postfix, from userid 500) id 22F1CE6B; Fri, 24 Sep 2004 08:46:27 -0700 (MST) ^^^^^^^^^^^^^^ uh-hu Received: from post1.inre.asu.edu (post1.inre.asu.edu [129.219.110.72]) by imap1.asu.edu (8.11.0/8.11.0/asu_cyrus,tcp_wrapped) with ESMTP id g3J1QrE21233 for ; Thu, 18 Apr 2002 18:26:53 -0700 (MST) ^^^^^^^^^^^^^^ you certainly must be joking ;-) Received: from conversion.post1.inre.asu.edu by asu.edu (PMDF V6.1 #40110) id <0GUS00H01K0UZT@asu.edu> for iddwb@IMAP1.ASU.EDU (ORCPT david.bear@asu.edu) ; Thu, 18 Apr 2002 18:26:54 -0700 (MST) Received: from mx2.freebsd.org (mx2.FreeBSD.org [216.136.204.119]) by asu.edu (PMDF V6.1 #40110) with ESMTP id <0GUS00H2SK0USU@asu.edu> for iddwb@IMAP1.ASU.EDU (ORCPT david.bear@asu.edu); Thu, 18 Apr 2002 18:26:54 -0700 (MST) Received: from hub.freebsd.org (hub.FreeBSD.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id B3C4E55EDB; Thu, 18 Apr 2002 18:26:49 -0700 Received: by hub.freebsd.org (Postfix, from userid 538) id B1EBB37B419; Thu, 18 Apr 2002 18:26:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 5F4F62E801A; Thu, 18 Apr 2002 18:26:44 -0700 (PDT) Received: by hub.freebsd.org (bulk_mailer v1.12); Thu, 18 Apr 2002 18:26:44 -0700 Received: from rain.macguire.net (sense-sea-MegaSub-1-125.oz.net [216.39.144.125]) by hub.freebsd.org (Postfix) with ESMTP id 71A3737B405 for ; Thu, 18 Apr 2002 18:26:40 -0700 (PDT) Received: (from roo@localhost) by rain.macguire.net (8.11.6/8.11.6) id g3J1OgG38989; Thu, 18 Apr 2002 18:24:42 -0700 (PDT envelope-from roo) Date: Thu, 18 Apr 2002 18:24:42 -0700 From: Benjamin Krueger Subject: Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip In-reply-to: <"from nate"@yogotech.com> Sender: owner-freebsd-security@FreeBSD.ORG To: dwbear75@gmail.com Cc: Benjamin Krueger , "Karsten W. Rohrbach" , Jeff Palmer , freebsd-security@FreeBSD.ORG Message-id: <20020418182442.H23267@rain.macguire.net> [...] remainder removed. Regards, /k -- > Modern cyberspace is a deadly, festering swamp, teeming with dangerous > programs such as "viruses," "worms," "Trojan horses" and "licensed > Microsoft software" that can take over your computer and render it useless. > --Dave Barry webmonster.de -- InterNetWorkTogether -- built on the open source platform http://www.webmonster.de/ - ftp://ftp.webmonster.de/ - http://www.rohrbach.de/ GnuPG: 0xDEC948A6 D/E BF11 83E8 84A1 F996 68B4 A113 B393 6BF4 DEC9 48A6 Please do not remove my address from To: and Cc: fields in mailing lists. 10x From owner-freebsd-security@FreeBSD.ORG Sun Sep 26 21:36:43 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D937E16A4CE for ; Sun, 26 Sep 2004 21:36:43 +0000 (GMT) Received: from freebee.digiware.nl (dsl439.iae.nl [212.61.63.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 681F943D48 for ; Sun, 26 Sep 2004 21:36:42 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from [212.61.27.71] (dual [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with ESMTP id i8QLad9S093611; Sun, 26 Sep 2004 23:36:40 +0200 (CEST) (envelope-from wjw@withagen.nl) Message-ID: <41573667.6080509@withagen.nl> Date: Sun, 26 Sep 2004 23:36:39 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David D.W. Downey" References: <414C2798.7060509@withagen.nl> <6917b781040918103077c76f0c@mail.gmail.com> <20040924214909.GA784@alex.lan> <6917b78104092601339f77948@mail.gmail.com> In-Reply-To: <6917b78104092601339f77948@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: "freebsd-security@FreeBSD.ORG" Subject: Re: Attacks on ssh port X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2004 21:36:44 -0000 David D.W. Downey wrote: >On Fri, 24 Sep 2004 23:49:09 +0200, Alex de Kruijff > wrote: > > >>>Then you can still see the attempts (and thus log the IP information >>>for contacting the abuse@ for the responsible IP controller) while >>>limiting your log sizes. >>> >>> >>This only logs the first tree catches (when the log attribuut is set) >>per rule. You may want to set this a little higher like 100. >> >> >> > >while I agree my example of 3 was low (meant only to instruct) I would >say more along the lines of 25. if someone is hitting you 25 times in >a row and getting tagged by that rule, you can bet your butt it's not >a client of your's. > It is even simpler: Anybody trying to use root as user for ssh-login is not a customer of mine.... And if he has not figured out that he's doing something wrong after 3 tries, little chance that he is really just making a mistake. --WjW From owner-freebsd-security@FreeBSD.ORG Mon Sep 27 00:25:49 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FAFF16A4CE; Mon, 27 Sep 2004 00:25:49 +0000 (GMT) Received: from pd2mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0992C43D1D; Mon, 27 Sep 2004 00:25:49 +0000 (GMT) (envelope-from cperciva@wadham.ox.ac.uk) Received: from pd5mr6so.prod.shaw.ca (pd5mr6so-qfe3.prod.shaw.ca [10.0.141.182]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I4O007ASBULTDB0@l-daemon>; Sun, 26 Sep 2004 18:25:33 -0600 (MDT) Received: from pn2ml1so.prod.shaw.ca ([10.0.121.145]) by pd5mr6so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I4O008ELBUL4SK0@pd5mr6so.prod.shaw.ca>; Sun, 26 Sep 2004 18:25:33 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.233.42])2003)) with ESMTP id <0I4O001C1BUL2I@l-daemon>; Sun, 26 Sep 2004 18:25:33 -0600 (MDT) Date: Sun, 26 Sep 2004 17:25:32 -0700 From: Colin Percival In-reply-to: <20040925140242.GB78219@gothmog.gr> To: Giorgos Keramidas Message-id: <41575DFC.9020206@wadham.ox.ac.uk> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: <20011107211316.A7830@nomad.lets.net> <20040925140242.GB78219@gothmog.gr> User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040922) X-Mailman-Approved-At: Mon, 27 Sep 2004 12:31:04 +0000 cc: freebsd-security@freebsd.org Subject: compare-by-hash (was Re: sharing /etc/passwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2004 00:25:49 -0000 Giorgos Keramidas wrote: > After reading a nice paper by Val Henson[1] I'm not so sure I'd trust > sensitive information like password data to rsync without making sure > that compare-by-hash is disabled if at all possible. If you're going to disable compare-by-hash, you might as well just use rcp; but there's no theoretical justification for disabling compare-by-hash. Henson's paper points out a number of cases where hashing causes problems, but none of these are issues with hashing itself; rather, the problems arise from using hashing with an insufficient number of bits. Obviously if you're searching for SHA1 collisions, you shouldn't index your data by SHA1 hash... you shouldn't use a 160 bit hash *any* time that you're doing O(2^80) work. The above notwithstanding, rsync's choice of hash function leaves something to be desired; MD4 is completely broken, and (while it is still adequate for random inputs) it is easy to construct files which rsync will incorrectly synchronize. (It's also trivial to construct files which consume ~100 times more cpu time on the server than normal -- unfortunately, this is an unavoidable consequence of using a fixed rolling hash function.) Colin Percival From owner-freebsd-security@FreeBSD.ORG Mon Sep 27 09:17:14 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60B1416A4CF for ; Mon, 27 Sep 2004 09:17:14 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91B2A43D49 for ; Mon, 27 Sep 2004 09:17:13 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from orion.daedalusnetworks.priv (host5.bedc.ondsl.gr [62.103.39.229])i8R9HAtN026657; Mon, 27 Sep 2004 12:17:11 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) i8R9HABa001751; Mon, 27 Sep 2004 12:17:10 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost)i8R9HAZv001750; Mon, 27 Sep 2004 12:17:10 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Mon, 27 Sep 2004 12:17:10 +0300 From: Giorgos Keramidas To: Colin Percival Message-ID: <20040927091710.GC914@orion.daedalusnetworks.priv> References: <20011107211316.A7830@nomad.lets.net> <20040925140242.GB78219@gothmog.gr> <41575DFC.9020206@wadham.ox.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41575DFC.9020206@wadham.ox.ac.uk> X-Mailman-Approved-At: Mon, 27 Sep 2004 12:31:04 +0000 cc: freebsd-security@freebsd.org Subject: Re: compare-by-hash (was Re: sharing /etc/passwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2004 09:17:14 -0000 On 2004-09-26 17:25, Colin Percival wrote: > Giorgos Keramidas wrote: > >After reading a nice paper by Val Henson[1] I'm not so sure I'd trust > >sensitive information like password data to rsync without making sure > >that compare-by-hash is disabled if at all possible. > > If you're going to disable compare-by-hash, you might as well just use > rcp; but there's no theoretical justification for disabling > compare-by-hash. Henson's paper points out a number of cases where > hashing causes problems, but none of these are issues with hashing > itself; rather, the problems arise from using hashing with an > insufficient number of bits. Err, no. Henson notes that since there's no absolutely guaranteed proof that there are *no* collisions with a given hashing algorithm, comparing by hash value might result in two data blocks treated as identical even though they really are not. Increasing the number of bits the hash key uses will decrease the possibility of a collision but never eliminate it entirely, AFAICT. What I pointed out was that when a non-zero possibility of two data blocks comparing as equal (even though they are no) exists, the method in question should not be used for password data or other sensitive bits of information. A larger hash key will never yield a possibility of zero, so it doesn't mean that you can sleep untroubled at night while the rsync server overwrites /etc/*pwd.db files periodically. From owner-freebsd-security@FreeBSD.ORG Mon Sep 27 14:45:13 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D9D916A4CE; Mon, 27 Sep 2004 14:45:13 +0000 (GMT) Received: from bas.flux.utah.edu (bas.flux.utah.edu [155.98.60.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A88343D46; Mon, 27 Sep 2004 14:45:12 +0000 (GMT) (envelope-from danderse@flux.utah.edu) Received: from bas.flux.utah.edu (localhost [127.0.0.1]) by bas.flux.utah.edu (8.12.9/8.12.5) with ESMTP id i8REjC1f015734; Mon, 27 Sep 2004 08:45:12 -0600 (MDT) (envelope-from danderse@bas.flux.utah.edu) Received: (from danderse@localhost) by bas.flux.utah.edu (8.12.9/8.12.5/Submit) id i8REjBr4015733; Mon, 27 Sep 2004 08:45:11 -0600 (MDT) Date: Mon, 27 Sep 2004 08:45:11 -0600 From: "David G. Andersen" To: Giorgos Keramidas Message-ID: <20040927084511.E75411@cs.utah.edu> References: <20011107211316.A7830@nomad.lets.net> <20040925140242.GB78219@gothmog.gr> <41575DFC.9020206@wadham.ox.ac.uk> <20040927091710.GC914@orion.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040927091710.GC914@orion.daedalusnetworks.priv>; from keramida@freebsd.org on Mon, Sep 27, 2004 at 12:17:10PM +0300 cc: freebsd-security@freebsd.org cc: Colin Percival Subject: Re: compare-by-hash (was Re: sharing /etc/passwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2004 14:45:13 -0000 Giorgos Keramidas just mooed: > > What I pointed out was that when a non-zero possibility of two data > blocks comparing as equal (even though they are no) exists, the method > in question should not be used for password data or other sensitive bits > of information. A larger hash key will never yield a possibility of > zero, so it doesn't mean that you can sleep untroubled at night while > the rsync server overwrites /etc/*pwd.db files periodically. P(hash collision) << p(gamma ray memory bit-flip) also << p(disk block error) also << p(undetected network error w/TCP) You're worried about the wrong thing. Unless you're talking about malicious hash collision generation with a broken hash function, the random hash collision probability, particularly with something like sha-1, really is small enough as to be insignificant. The section in the paper dealing with this is pure bunk. _everything_ is a probability -- it's just a matter of how much you're willing to spend (bandwidth, computation, storage) to drive that probability low. Illustrative example from the paper: "The empirically observed rate of undetected errors in TCP packets is about 0.0000005% ... or we could slightly worsen that rate by sending only the hash" What's the error rate when sending only the hash? Since the probabilities are small, we can effectively add them. P(undetected TCP error) = 0.000000005 P(hash collision) = 1/1208925819614629174706176 =~ 0.00000000000000000000001 "Worsening" = 0.00000000500000000000001 Now, if I were a smart programmer, I'd look at that and say, "If I'm worried about reliability, then TCP is my enemy. Hashes are my friend -- because I can send _two_ different hashes of the same data for _way_ less then the cost of sending the data, and that way I can protect myself against undetected TCP errors!" -dave -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me. From owner-freebsd-security@FreeBSD.ORG Mon Sep 27 15:04:17 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53B1816A4CE; Mon, 27 Sep 2004 15:04:17 +0000 (GMT) Received: from bas.flux.utah.edu (bas.flux.utah.edu [155.98.60.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18F3043D54; Mon, 27 Sep 2004 15:04:17 +0000 (GMT) (envelope-from danderse@flux.utah.edu) Received: from bas.flux.utah.edu (localhost [127.0.0.1]) by bas.flux.utah.edu (8.12.9/8.12.5) with ESMTP id i8RF4G1f016424; Mon, 27 Sep 2004 09:04:16 -0600 (MDT) (envelope-from danderse@bas.flux.utah.edu) Received: (from danderse@localhost) by bas.flux.utah.edu (8.12.9/8.12.5/Submit) id i8RF4GD8016423; Mon, 27 Sep 2004 09:04:16 -0600 (MDT) Date: Mon, 27 Sep 2004 09:04:16 -0600 From: "David G. Andersen" To: Giorgos Keramidas Message-ID: <20040927090416.B16227@cs.utah.edu> References: <20011107211316.A7830@nomad.lets.net> <20040925140242.GB78219@gothmog.gr> <41575DFC.9020206@wadham.ox.ac.uk> <20040927091710.GC914@orion.daedalusnetworks.priv> <20040927084511.E75411@cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040927084511.E75411@cs.utah.edu>; from danderse@cs.utah.edu on Mon, Sep 27, 2004 at 08:45:11AM -0600 cc: freebsd-security@freebsd.org cc: Colin Percival Subject: Re: compare-by-hash (was Re: sharing /etc/passwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2004 15:04:17 -0000 David G. Andersen just mooed: > > What's the error rate when sending only the hash? Since the > probabilities are small, we can effectively add them. > > P(undetected TCP error) = 0.000000005 > P(hash collision) = 1/1208925819614629174706176 > =~ 0.00000000000000000000001 > > "Worsening" = 0.00000000500000000000001 (btw, I wasn't really being fair to compare-by-hash in this example. Assuming you're synchronizing a "moderate" file with rsync, it's going to split it into, say, S/1k chunks. So let's be nasty and say that it's a 1Tb file. The chances of any one block colliding with any of the other blocks in the file is (again, because our probabilities are really small) 2^30 / 2^160 =~ 1/2^130. In the example above, I used a very conservative value of 1/2^80. So the actual worsening is probably from 0.0000005 to 0.000000500000000000000000000000000000001 I'll take those odds any day. Even if you send each data packet 3x with a non-hashed rcp, your chances of death per-packet are still 0.000000000000000000125 or thereabouts... -Dave -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me. From owner-freebsd-security@FreeBSD.ORG Mon Sep 27 15:21:59 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F50B16A4D0 for ; Mon, 27 Sep 2004 15:21:59 +0000 (GMT) Received: from smtp17.wxs.nl (smtp17.wxs.nl [195.121.6.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA4AB43D39 for ; Mon, 27 Sep 2004 15:21:55 +0000 (GMT) (envelope-from freebsd@akruijff.dds.nl) Received: from kruij557.speed.planet.nl (ipd50a97ba.speed.planet.nl [213.10.151.186]) by smtp17.wxs.nl (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I4P00GI2HCGKX@smtp17.wxs.nl> for freebsd-security@freebsd.org; Mon, 27 Sep 2004 17:21:54 +0200 (CEST) Received: from alex.lan (localhost [127.0.0.1]) by kruij557.speed.planet.nl (8.12.10/8.12.10) with ESMTP id i8RFKlPT000578; Mon, 27 Sep 2004 17:21:46 +0200 Received: (from akruijff@localhost) by alex.lan (8.12.10/8.12.10/Submit) id i8QNiIoc011534; Mon, 27 Sep 2004 01:44:18 +0200 Content-return: prohibited Date: Mon, 27 Sep 2004 01:44:18 +0200 From: Alex de Kruijff In-reply-to: <41573667.6080509@withagen.nl> To: Willem Jan Withagen Message-id: <20040926234418.GA1077@alex.lan> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: Mutt/1.4.2.1i References: <414C2798.7060509@withagen.nl> <6917b781040918103077c76f0c@mail.gmail.com> <20040924214909.GA784@alex.lan> <6917b78104092601339f77948@mail.gmail.com> <41573667.6080509@withagen.nl> X-Authentication-warning: alex.lan: akruijff set sender to freebsd@akruijff.dds.nl using -f cc: "freebsd-security@FreeBSD.ORG" cc: "David D.W. Downey" Subject: Re: Attacks on ssh port X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2004 15:21:59 -0000 On Sun, Sep 26, 2004 at 11:36:39PM +0200, Willem Jan Withagen wrote: > David D.W. Downey wrote: > > >On Fri, 24 Sep 2004 23:49:09 +0200, Alex de Kruijff > > wrote: > > > > > >>>Then you can still see the attempts (and thus log the IP information > >>>for contacting the abuse@ for the responsible IP controller) while > >>>limiting your log sizes. > >>> > >>> > >>This only logs the first tree catches (when the log attribuut is set) > >>per rule. You may want to set this a little higher like 100. > >> > >> > >> > > > >while I agree my example of 3 was low (meant only to instruct) I would > >say more along the lines of 25. if someone is hitting you 25 times in > >a row and getting tagged by that rule, you can bet your butt it's not > >a client of your's. The way I understand it was that the rule doesn't discriminate on the basis of IP. It juist counts them all to gether. But I could be wrong about this. > > > It is even simpler: > Anybody trying to use root as user for ssh-login is not a customer > of mine.... > And if he has not figured out that he's doing something wrong after > 3 tries, little chance that he is really just making a mistake. This is the perspective of sshd. IPFW can't see this and this value is set for all rules. I use the loggin facility mainly as a debugging tool. If I want a certain appliction to work that is being blocked by ipfw, then I flush the rule counters, run the app, check the log file, then add rules based on my findings and then do it all again until I can run the app. My fear is that don't catch te rules you want to catch, if you set this value to low, while with a large(r) value, you still stop the logging. -- Alex Articles based on solutions that I use: http://www.kruijff.org/alex/FreeBSD/ From owner-freebsd-security@FreeBSD.ORG Mon Sep 27 17:27:06 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C60B16A4CE for ; Mon, 27 Sep 2004 17:27:06 +0000 (GMT) Received: from dfmm.org (walter.dfmm.org [66.180.195.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 674DF43D54 for ; Mon, 27 Sep 2004 17:27:06 +0000 (GMT) (envelope-from freebsd-security@dfmm.org) Received: (qmail 1328 invoked by uid 1000); 27 Sep 2004 17:27:06 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 27 Sep 2004 17:27:06 -0000 Date: Mon, 27 Sep 2004 10:27:04 -0700 (PDT) From: Jason Stone X-X-Sender: jason@walter To: Giorgos Keramidas In-Reply-To: <20040927091710.GC914@orion.daedalusnetworks.priv> Message-ID: <20040927095906.I79820@walter> References: <20040925140242.GB78219@gothmog.gr> <20040927091710.GC914@orion.daedalusnetworks.priv> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-security@freebsd.org Subject: Re: compare-by-hash (was Re: sharing /etc/passwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2004 17:27:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Henson notes that since there's no absolutely guaranteed proof that > there are *no* collisions with a given hashing algorithm, true - quite the opposite, in fact - with a finite hash length and an infinite number of inputs, you are guaranteed an infinite number of collisions in any hashing algorithm - you're just going to have to spend longer than the lifetime of the universe to find them.... > What I pointed out was that when a non-zero possibility of two data > blocks comparing as equal (even though they are no) exists, the method > in question should not be used for password data well, when you consider that sha1 has a 160-bit hash length and the total expected lifetime of the universe (by most cosmological theories) is "only" about 2^60 seconds, that means that if you generated and compared a million hashes per second, you would only find one collision in the entire lifetime of the universe. when you consider the case of trying to match a given input (ie, your passwd file) then you have to do the full 2^160 hashes to generate a collision. this would require you to hash and compare 2^100 inputs per second for the entire lifetime of the universe to find just one collision. for a little bit of perspective, hashing and comparing 2^100 inputs per second would require a 1,180,591,620,717,411,303,424 Ghz computer to do both the hash and the compare in just one clock cycle. the point is that it's so not worth while to consider the collision rate in these kinds of applications - the probability of your computer bursting into flames and killing you is (absolutely literally) way way higher. the probability of the earth opening up and swallowing your datacenter is (absolutely literally) way way higher. or, more practically speaking, the probability of your computer getting hacked or your data lost/damaged in some other, much more mundane way is infinitely higher, so spend your time worrying about that instead. -Jason -------------------------------------------------------------------------- Freud himself was a bit of a cold fish, and one cannot avoid the suspicion that he was insufficiently fondled when he was an infant. -- Ashley Montagu -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQFBWE1qswXMWWtptckRAnY6AKC3B9sWK5zlSAC8FsljTKyEj43E4wCbBgv/ ogxLESxZzJXr8G8yY2lvj0g= =kZmz -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Sep 28 09:05:56 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D34316A4CE for ; Tue, 28 Sep 2004 09:05:56 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id A35C143D62 for ; Tue, 28 Sep 2004 09:05:55 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from orion.daedalusnetworks.priv (host5.bedc.ondsl.gr [62.103.39.229])i8S95rMO001835; Tue, 28 Sep 2004 12:05:53 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) i8S95q4B001845; Tue, 28 Sep 2004 12:05:52 +0300 (EEST) (envelope-from keramida@linux.gr) Received: (from keramida@localhost)i8S95pxg001844; Tue, 28 Sep 2004 12:05:51 +0300 (EEST) (envelope-from keramida@linux.gr) Date: Tue, 28 Sep 2004 12:05:51 +0300 From: Giorgos Keramidas To: Colin Percival Message-ID: <20040928090551.GA1800@orion.daedalusnetworks.priv> References: <20011107211316.A7830@nomad.lets.net> <20040925140242.GB78219@gothmog.gr> <41575DFC.9020206@wadham.ox.ac.uk> <20040927091710.GC914@orion.daedalusnetworks.priv> <41582024.2080205@wadham.ox.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41582024.2080205@wadham.ox.ac.uk> cc: freebsd-security@freebsd.org Subject: Re: compare-by-hash (was Re: sharing /etc/passwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 09:05:56 -0000 On 2004-09-27 07:13, Colin Percival wrote: > Giorgos Keramidas wrote: > >Increasing the number of bits the hash key uses will decrease the > >possibility of a collision but never eliminate it entirely, AFAICT. > > How small does a chance of error need to be before you're willing to > ignore it? That's a good question. I'm not sure I have a definitive answer, but the possibility of a collision is indeed scary. Especially since I haven't seen a study of the real probability of a collition is, given the fact that passwords aren't (normally) random binary data but a much smaller subset of the universe being hashed. > If an appropriately strong hash is used (eg, SHA1), then the probability > of obtaining an incorrect /etc/*pwd.db with a correct hash is much > smaller than the probability of a random incorrect password being > accepted. Remember, passwords are stored by their MD5 hashes, so a > random password has a 2^(-128) chance of working. I was probably being unreasonably paranoid about 'modified' passwords that don't get detected as modified, but what you describe is also true. From owner-freebsd-security@FreeBSD.ORG Tue Sep 28 09:14:14 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70FAA16A4CE for ; Tue, 28 Sep 2004 09:14:14 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F99743D2F for ; Tue, 28 Sep 2004 09:14:13 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from orion.daedalusnetworks.priv (host5.bedc.ondsl.gr [62.103.39.229])i8S9E6d1005905; Tue, 28 Sep 2004 12:14:10 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) i8S9E6RP001924; Tue, 28 Sep 2004 12:14:06 +0300 (EEST) (envelope-from keramida@linux.gr) Received: (from keramida@localhost)i8S9E5IS001923; Tue, 28 Sep 2004 12:14:05 +0300 (EEST) (envelope-from keramida@linux.gr) Date: Tue, 28 Sep 2004 12:14:05 +0300 From: Giorgos Keramidas To: Jason Stone Message-ID: <20040928091405.GB1800@orion.daedalusnetworks.priv> References: <20011107211316.A7830@nomad.lets.net> <20040925140242.GB78219@gothmog.gr> <41575DFC.9020206@wadham.ox.ac.uk> <20040927091710.GC914@orion.daedalusnetworks.priv> <20040927095906.I79820@walter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040927095906.I79820@walter> cc: freebsd-security@freebsd.org Subject: Re: compare-by-hash (was Re: sharing /etc/passwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 09:14:14 -0000 On 2004-09-27 10:27, Jason Stone wrote: > > Henson notes that since there's no absolutely guaranteed proof that > > there are *no* collisions with a given hashing algorithm, > > true - quite the opposite, in fact - with a finite hash length and an > infinite number of inputs, you are guaranteed an infinite number of > collisions in any hashing algorithm - you're just going to have to spend > longer than the lifetime of the universe to find them.... There is one difference between ``looking for collisions'' and being bitten by undetected collisions though. If the probability of a collision just happening with random user data is 1/(2^128) we can't be sure that it will necessarily take the transfer of an average number of 2^127 blocks before a collision happens. You might get one at the very first pair of blocks and then no collisions ever after until the Sun burns out. Using two different hashes for the same set of input data, which David G. Andersen proposed, seems like a nice idea though. - Giorgos From owner-freebsd-security@FreeBSD.ORG Mon Sep 27 14:13:58 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68CC716A4CE; Mon, 27 Sep 2004 14:13:58 +0000 (GMT) Received: from pd2mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E27E043D3F; Mon, 27 Sep 2004 14:13:57 +0000 (GMT) (envelope-from cperciva@wadham.ox.ac.uk) Received: from pd3mr4so.prod.shaw.ca (pd3mr4so-qfe3.prod.shaw.ca [10.0.141.180]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I4P005D6E79FS70@l-daemon>; Mon, 27 Sep 2004 08:13:57 -0600 (MDT) Received: from pn2ml6so.prod.shaw.ca ([10.0.121.150]) by pd3mr4so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I4P00FZFE79MNM0@pd3mr4so.prod.shaw.ca>; Mon, 27 Sep 2004 08:13:57 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.233.42])2003)) with ESMTP id <0I4P001ZHE78W7@l-daemon>; Mon, 27 Sep 2004 08:13:57 -0600 (MDT) Date: Mon, 27 Sep 2004 07:13:56 -0700 From: Colin Percival In-reply-to: <20040927091710.GC914@orion.daedalusnetworks.priv> To: Giorgos Keramidas Message-id: <41582024.2080205@wadham.ox.ac.uk> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: <20011107211316.A7830@nomad.lets.net> <20040925140242.GB78219@gothmog.gr> <41575DFC.9020206@wadham.ox.ac.uk> <20040927091710.GC914@orion.daedalusnetworks.priv> User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040922) X-Mailman-Approved-At: Tue, 28 Sep 2004 15:12:26 +0000 cc: freebsd-security@freebsd.org Subject: Re: compare-by-hash (was Re: sharing /etc/passwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2004 14:13:58 -0000 Giorgos Keramidas wrote: > Increasing the number of bits the hash key uses will decrease the > possibility of a collision but never eliminate it entirely, AFAICT. How small does a chance of error need to be before you're willing to ignore it? > What I pointed out was that when a non-zero possibility of two data > blocks comparing as equal (even though they are no) exists, the method > in question should not be used for password data or other sensitive bits > of information. A larger hash key will never yield a possibility of > zero, so it doesn't mean that you can sleep untroubled at night while > the rsync server overwrites /etc/*pwd.db files periodically. If an appropriately strong hash is used (eg, SHA1), then the probability of obtaining an incorrect /etc/*pwd.db with a correct hash is much smaller than the probability of a random incorrect password being accepted. Remember, passwords are stored by their MD5 hashes, so a random password has a 2^(-128) chance of working. If, on the other hand, you're concerned about accidentally locking yourself out of the server as a result of an undetected mangling of the password database... you should be more worried about the server, and all your backups, being simultaneously hit by lightning. :-) Colin Percival From owner-freebsd-security@FreeBSD.ORG Tue Sep 28 09:25:53 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9977E16A4CE for ; Tue, 28 Sep 2004 09:25:53 +0000 (GMT) Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 836FD43D1D for ; Tue, 28 Sep 2004 09:25:53 +0000 (GMT) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id AC35367503 for ; Tue, 28 Sep 2004 09:25:52 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.11/8.12.11) with ESMTP id i8S9PkDX091228; Tue, 28 Sep 2004 19:25:46 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200409280925.i8S9PkDX091228@drugs.dv.isc.org> To: Giorgos Keramidas From: Mark Andrews In-reply-to: Your message of "Tue, 28 Sep 2004 12:14:05 +0300." <20040928091405.GB1800@orion.daedalusnetworks.priv> Date: Tue, 28 Sep 2004 19:25:46 +1000 Sender: Mark_Andrews@isc.org X-Mailman-Approved-At: Tue, 28 Sep 2004 15:12:26 +0000 cc: Jason Stone cc: freebsd-security@freebsd.org Subject: Re: compare-by-hash (was Re: sharing /etc/passwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 09:25:53 -0000 > On 2004-09-27 10:27, Jason Stone wrote: > > > Henson notes that since there's no absolutely guaranteed proof that > > > there are *no* collisions with a given hashing algorithm, > > > > true - quite the opposite, in fact - with a finite hash length and an > > infinite number of inputs, you are guaranteed an infinite number of > > collisions in any hashing algorithm - you're just going to have to spend > > longer than the lifetime of the universe to find them.... > > There is one difference between ``looking for collisions'' and being > bitten by undetected collisions though. > > If the probability of a collision just happening with random user data > is 1/(2^128) we can't be sure that it will necessarily take the > transfer of an average number of 2^127 blocks before a collision > happens. You might get one at the very first pair of blocks and then > no collisions ever after until the Sun burns out. > > Using two different hashes for the same set of input data, which David > G. Andersen proposed, seems like a nice idea though. Assuming the hashes are independent all it does is multiply the probabilities. If the hashes are not independent you won't get as much improvement. In either case all you are doing is creating yet another hash function. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From owner-freebsd-security@FreeBSD.ORG Tue Sep 28 09:40:07 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9753F16A4CE for ; Tue, 28 Sep 2004 09:40:07 +0000 (GMT) Received: from pd3mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B264A43D1D for ; Tue, 28 Sep 2004 09:40:06 +0000 (GMT) (envelope-from cperciva@wadham.ox.ac.uk) Received: from pd2mr8so.prod.shaw.ca (pd2mr8so-qfe3.prod.shaw.ca [10.0.141.11])2004))freebsd-security@freebsd.org; Tue, 28 Sep 2004 03:39:50 -0600 (MDT) Received: from pn2ml7so.prod.shaw.ca ([10.0.121.151]) by pd2mr8so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I4Q00GRTW6DWDI0@pd2mr8so.prod.shaw.ca> for freebsd-security@freebsd.org; Tue, 28 Sep 2004 03:39:50 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.233.42])2003)) freebsd-security@freebsd.org; Tue, 28 Sep 2004 03:39:49 -0600 (MDT) Date: Tue, 28 Sep 2004 02:39:49 -0700 From: Colin Percival In-reply-to: <20040928091405.GB1800@orion.daedalusnetworks.priv> To: Giorgos Keramidas Message-id: <41593165.10406@wadham.ox.ac.uk> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: <20011107211316.A7830@nomad.lets.net> <20040925140242.GB78219@gothmog.gr> <41575DFC.9020206@wadham.ox.ac.uk> <20040927091710.GC914@orion.daedalusnetworks.priv> <20040927095906.I79820@walter> <20040928091405.GB1800@orion.daedalusnetworks.priv> User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040922) X-Mailman-Approved-At: Tue, 28 Sep 2004 15:12:26 +0000 cc: Jason Stone cc: freebsd-security@freebsd.org Subject: Re: compare-by-hash (was Re: sharing /etc/passwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 09:40:07 -0000 Giorgos Keramidas wrote: > There is one difference between ``looking for collisions'' and being > bitten by undetected collisions though. True. But if the best known collision-finding algorithm takes f(p) operations in order to achieve a probability p of having found a collision, and you've performed less than f(p) operations, then either the chance of you being bitten by an undetected collision is less than p, or you've managed to improve upon the best-known collision-finding algorithm. For f(p) = 2^80 * sqrt(p), none of us are ever going to perform enough operations to make the chance of stumbling across a collision by accident a significant risk. Colin Percival From owner-freebsd-security@FreeBSD.ORG Tue Sep 28 15:16:06 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C69516A4CE for ; Tue, 28 Sep 2004 15:16:06 +0000 (GMT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 380B043D49 for ; Tue, 28 Sep 2004 15:16:06 +0000 (GMT) (envelope-from nectar@celabo.org) Received: from localhost (localhost [127.0.0.1]) by gw.celabo.org (Postfix) with ESMTP id A3A625487E; Tue, 28 Sep 2004 10:16:05 -0500 (CDT) Received: from gw.celabo.org ([127.0.0.1]) by localhost (hellblazer.celabo.org [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 20254-04; Tue, 28 Sep 2004 10:15:55 -0500 (CDT) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (not verified)) by gw.celabo.org (Postfix) with ESMTP id 0A95354861; Tue, 28 Sep 2004 10:15:55 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id CA24D6D46D; Tue, 28 Sep 2004 10:15:41 -0500 (CDT) Date: Tue, 28 Sep 2004 10:15:41 -0500 From: "Jacques A. Vidrine" To: Giorgos Keramidas Message-ID: <20040928151541.GF23453@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Giorgos Keramidas , Jason Stone , freebsd-security@freebsd.org References: <20011107211316.A7830@nomad.lets.net> <20040925140242.GB78219@gothmog.gr> <41575DFC.9020206@wadham.ox.ac.uk> <20040927091710.GC914@orion.daedalusnetworks.priv> <20040927095906.I79820@walter> <20040928091405.GB1800@orion.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040928091405.GB1800@orion.daedalusnetworks.priv> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: Jason Stone cc: freebsd-security@freebsd.org Subject: Re: compare-by-hash (was Re: sharing /etc/passwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 15:16:06 -0000 On Tue, Sep 28, 2004 at 12:14:05PM +0300, Giorgos Keramidas wrote: > There is one difference between ``looking for collisions'' and being > bitten by undetected collisions though. > > If the probability of a collision just happening with random user data > is 1/(2^128) we can't be sure that it will necessarily take the > transfer of an average number of 2^127 blocks before a collision > happens. You might get one at the very first pair of blocks and then > no collisions ever after until the Sun burns out. > > Using two different hashes for the same set of input data, which David > G. Andersen proposed, seems like a nice idea though. If you buy the "logic" of the paper, this would not make much difference. After all, composing two hashes just gives you another hash with a longer bit length. This paper needs a lot more peer review, although I'm not sure that many take it seriously enough to bother. Cheers, -- Jacques A Vidrine / NTT/Verio nectar@celabo.org / jvidrine@verio.net / nectar@FreeBSD.org From owner-freebsd-security@FreeBSD.ORG Tue Sep 28 16:14:02 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0C0D16A4CE; Tue, 28 Sep 2004 16:14:02 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45AD443D4C; Tue, 28 Sep 2004 16:14:02 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.12.10) with ESMTP id i8SGDx6G022460; Tue, 28 Sep 2004 12:13:59 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id i8SGDxpc022459; Tue, 28 Sep 2004 12:13:59 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Tue, 28 Sep 2004 12:13:59 -0400 From: David Schultz To: Colin Percival Message-ID: <20040928161359.GA22274@VARK.MIT.EDU> Mail-Followup-To: Colin Percival , Giorgos Keramidas , freebsd-security@freebsd.org References: <20011107211316.A7830@nomad.lets.net> <20040925140242.GB78219@gothmog.gr> <41575DFC.9020206@wadham.ox.ac.uk> <20040927091710.GC914@orion.daedalusnetworks.priv> <41582024.2080205@wadham.ox.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41582024.2080205@wadham.ox.ac.uk> cc: freebsd-security@FreeBSD.ORG cc: Giorgos Keramidas Subject: Re: compare-by-hash (was Re: sharing /etc/passwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 16:14:02 -0000 On Mon, Sep 27, 2004, Colin Percival wrote: > If an appropriately strong hash is used (eg, SHA1), then the probability > of obtaining an incorrect /etc/*pwd.db with a correct hash is much > smaller than the probability of a random incorrect password being > accepted. Remember, passwords are stored by their MD5 hashes, so a > random password has a 2^(-128) chance of working. > > If, on the other hand, you're concerned about accidentally locking > yourself out of the server as a result of an undetected mangling of the > password database... you should be more worried about the server, and > all your backups, being simultaneously hit by lightning. :-) One thing to keep in mind is that the collision-resistance of SHA-1 is an unproven conjecture. Back in the dark ages of cryptography, Rivest conjectured that MD4 and MD5 were also collision-resistant, and this turned out not to be true. In fact, recent results have raised some concerns about SHA-1 (http://eprint.iacr.org/2004/146/). There's some speculation that SHA-1 is broken in the sense that you are likely to find a collision after computing far fewer than 2^80 hashes; however, people still seem to consider it good enough for SSL/TLS and numerous other protocols. If they're wrong, of course, I think people will be much more concerned about digital signatures than rsync. From owner-freebsd-security@FreeBSD.ORG Tue Sep 28 16:27:34 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCE5A16A4CE; Tue, 28 Sep 2004 16:27:34 +0000 (GMT) Received: from pd4mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BB3A43D2D; Tue, 28 Sep 2004 16:27:34 +0000 (GMT) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from pd5mr3so.prod.shaw.ca (pd5mr3so-qfe3.prod.shaw.ca [10.0.141.144]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I4R005HDF1Y6PA0@l-daemon>; Tue, 28 Sep 2004 10:27:34 -0600 (MDT) Received: from pn2ml6so.prod.shaw.ca ([10.0.121.150]) by pd5mr3so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I4R003VLF1YLHK0@pd5mr3so.prod.shaw.ca>; Tue, 28 Sep 2004 10:27:34 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.233.42])2003)) with ESMTP id <0I4R0031NF1XD6@l-daemon>; Tue, 28 Sep 2004 10:27:34 -0600 (MDT) Date: Tue, 28 Sep 2004 09:27:33 -0700 From: Colin Percival In-reply-to: <20040928161359.GA22274@VARK.MIT.EDU> To: David Schultz Message-id: <415990F5.4040505@wadham.ox.ac.uk> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: <20011107211316.A7830@nomad.lets.net> <20040925140242.GB78219@gothmog.gr> <41575DFC.9020206@wadham.ox.ac.uk> <20040927091710.GC914@orion.daedalusnetworks.priv> <41582024.2080205@wadham.ox.ac.uk> <20040928161359.GA22274@VARK.MIT.EDU> User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040928) cc: freebsd-security@freebsd.org Subject: Re: compare-by-hash (was Re: sharing /etc/passwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 16:27:35 -0000 David Schultz wrote: > ... In fact, recent results have > raised some concerns about SHA-1 (http://eprint.iacr.org/2004/146/). I have yet to hear any justification for claims that the SHA-0 attack implies a weakness in SHA-1. The paper you cite even says "Due to the additional rotate instruction, the results of this paper are not applicable to SHA-1". Colin Percival From owner-freebsd-security@FreeBSD.ORG Tue Sep 28 20:09:37 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9731216A4CE for ; Tue, 28 Sep 2004 20:09:37 +0000 (GMT) Received: from dfmm.org (walter.dfmm.org [66.180.195.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6562543D46 for ; Tue, 28 Sep 2004 20:09:37 +0000 (GMT) (envelope-from freebsd-security@dfmm.org) Received: (qmail 72571 invoked by uid 1000); 28 Sep 2004 20:09:37 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Sep 2004 20:09:37 -0000 Date: Tue, 28 Sep 2004 13:09:35 -0700 (PDT) From: Jason Stone X-X-Sender: jason@walter To: freebsd-security@FreeBSD.ORG In-Reply-To: <20040928161359.GA22274@VARK.MIT.EDU> Message-ID: <20040928125056.C79820@walter> References: <20040925140242.GB78219@gothmog.gr> <20040927091710.GC914@orion.daedalusnetworks.priv> <20040928161359.GA22274@VARK.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: compare-by-hash (was Re: sharing /etc/passwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 20:09:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > One thing to keep in mind is that the collision-resistance of SHA-1 is > an unproven conjecture. sure, I was going to mention that - indeed, md4 is the algorithm used in rsync, and it _has_ been shown to be less collision-resistant than the full 128-bits would imply. which means that instead of finding only one collision in the entire lifetime of the universe, you'll find four. it doesn't change the fact that the probability of your computer catching fire and killing you, in an absolutely real and literal sense, is many millions of times higher, and that the time you spend worrying about this would be much, much better spent backing up your data offsite and wearing kevlar pants. also, excellent point someone made about passwords already using md5 in freebsd - this means that there are already an infinite number of passwords that will let someone into your box as root, right now, this very instant. so using rsync, you're hardly worse off.... -Jason -------------------------------------------------------------------------- Freud himself was a bit of a cold fish, and one cannot avoid the suspicion that he was insufficiently fondled when he was an infant. -- Ashley Montagu -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQFBWcUBswXMWWtptckRAi3rAJ4tyujyV0XyT7nC2VpdntVA5KjIbwCdHkpZ OSGmWnJPtrb4DLrwNz0HaEA= =UZOZ -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Sep 28 22:19:09 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AA5C16A4CF for ; Tue, 28 Sep 2004 22:19:09 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id F404743D31 for ; Tue, 28 Sep 2004 22:19:08 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.12.10) with ESMTP id i8SMJ48m024627; Tue, 28 Sep 2004 18:19:04 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id i8SMJ4J8024626; Tue, 28 Sep 2004 18:19:04 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Tue, 28 Sep 2004 18:19:04 -0400 From: David Schultz To: Jason Stone Message-ID: <20040928221904.GA24296@VARK.MIT.EDU> Mail-Followup-To: Jason Stone , freebsd-security@FreeBSD.ORG References: <20040925140242.GB78219@gothmog.gr> <20040927091710.GC914@orion.daedalusnetworks.priv> <20040928161359.GA22274@VARK.MIT.EDU> <20040928125056.C79820@walter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040928125056.C79820@walter> cc: freebsd-security@FreeBSD.ORG Subject: Re: compare-by-hash (was Re: sharing /etc/passwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 22:19:09 -0000 On Tue, Sep 28, 2004, Jason Stone wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > One thing to keep in mind is that the collision-resistance of SHA-1 is > > an unproven conjecture. > > sure, I was going to mention that - indeed, md4 is the algorithm used in > rsync, and it _has_ been shown to be less collision-resistant than the > full 128-bits would imply. > > which means that instead of finding only one collision in the entire > lifetime of the universe, you'll find four. No, md4 and md5 are broken, in the sense that it's known how to feasibly generate collisions. For example: das@VARK:~> cmp md4* md4c_1 md4c_2 differ: char 8, line 1 das@VARK:~> cmp md5* md5c_1 md5c_2 differ: char 20, line 1 das@VARK:~> openssl md4 md4* MD4(md4c_1)= 4d7e6a1defa93d2dde05b45d864c429b MD4(md4c_2)= 4d7e6a1defa93d2dde05b45d864c429b das@VARK:~> openssl md5 md5* MD5(md5c_1)= a4c0d35c95a63a805915367dcfe6b751 MD5(md5c_2)= a4c0d35c95a63a805915367dcfe6b751 das@VARK:~> hexdump md4c_1 0000000 9c83 4d7a 927a 56cb a578 b9d5 a5ee 57a7 0000010 8a3c de74 66b3 dcc3 a020 b683 5d9f 3b2a 0000020 71b3 c69d 9198 f9e9 805e d79f b2e8 a63b 0000030 8e31 45dd 1fe5 97e3 bf08 2794 c3e9 b9e8 0000040 das@VARK:~> hexdump md4c_2 0000000 9c83 4d7a 927a d6cb a578 29d5 a5ee 57a7 0000010 8a3c de74 66b3 dcc3 a020 b683 5d9f 3b2a 0000020 71b3 c69d 9198 f9e9 805e d79f b2e8 a63b 0000030 8e31 45dc 1fe5 97e3 bf08 2794 c3e9 b9e8 0000040 das@VARK:~> hexdump md5c_1 0000000 31d1 02dd e6c5 c4ee 3d69 069a af98 5cf9 0000010 ca2f 87b5 4612 ab7e 0440 3e58 fbb8 897f 0000020 ad55 0634 f409 02b3 e483 8388 7125 5a41 0000030 5108 e825 cdf7 9fc9 1dd9 f2bd 3780 5b3c 0000040 0b96 d11d 41dc 9c7b d8e4 f497 655a d555 0000050 7335 c79a ebf0 0cfd 2930 66f1 09d1 8fb1 0000060 2775 797f d530 eb5c e822 baad cc79 5c15 0000070 74ed ddcb c55f 6dd3 9bb1 d80a cc35 e3a7 0000080 das@VARK:~> hexdump md5c_2 0000000 31d1 02dd e6c5 c4ee 3d69 069a af98 5cf9 0000010 ca2f 07b5 4612 ab7e 0440 3e58 fbb8 897f 0000020 ad55 0634 f409 02b3 e483 8388 f125 5a41 0000030 5108 e825 cdf7 9fc9 1dd9 72bd 3780 5b3c 0000040 0b96 d11d 41dc 9c7b d8e4 f497 655a d555 0000050 7335 479a ebf0 0cfd 2930 66f1 09d1 8fb1 0000060 2775 797f d530 eb5c e822 baad 4c79 5c15 0000070 74ed ddcb c55f 6dd3 9bb1 580a cc35 e3a7 0000080 (Acknowledgement: The md5 data comes from the page http://www.freedom-to-tinker.com/archives/000663.html, and the md4 data from an email.) From owner-freebsd-security@FreeBSD.ORG Tue Sep 28 22:51:00 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2F6016A4CF for ; Tue, 28 Sep 2004 22:51:00 +0000 (GMT) Received: from venom.ai.net (venom.ai.net [205.134.161.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F50F43D1D for ; Tue, 28 Sep 2004 22:51:00 +0000 (GMT) (envelope-from deepak@ai.net) Received: from [10.246.38.112] ([141.156.111.75]) by venom.ai.net (8.12.6/8.12.8) with ESMTP id i8SLI13t030754; Tue, 28 Sep 2004 17:18:01 -0400 (EDT) (envelope-from deepak@ai.net) Message-ID: <4159EABF.3030004@ai.net> Date: Tue, 28 Sep 2004 18:50:39 -0400 From: Deepak Jain User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cjclark@alum.mit.edu References: <200109081052.f88AqRG30016@sheol.localdomain> <20010908141700.A53738@fump.kawo2.rwth-aachen.de> <20010908072542.A57605@sheol.localdomain> <20010908143231.A53801@fump.kawo2.rwth-aachen.de> <20010908074445.A77252@sheol.localdomain> <20010908181537.A840@ringworld.oblivion.bg> <20010908102816.B77764@sheol.localdomain> <20010908183728.D840@ringworld.oblivion.bg> <20010908105308.A78138@sheol.localdomain> <20011004023034.U8391@blossom.cjclark.org> In-Reply-To: <20011004023034.U8391@blossom.cjclark.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 29 Sep 2004 12:30:06 +0000 cc: freebsd-security@FreeBSD.ORG cc: dwbear75@gmail.com cc: Alexander Langer Subject: Re: Kernel-loadable Root Kits X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 22:51:00 -0000 Thanks for the module, I think its a good idea to commit it to FreeBSD for a few reasons: 1) Some folks just prefer more static kernels. 2) Securelevel is a great thing, but can be a pain to do upgrades around remotely. [A lot of folks use FreeBSD simply because its a breeze to run remotely]. 3) Until someone writes code to add modules to a kernel via /dev/mem and releases it to the script kiddie world, the bar has been effectively raised for 99% of the miscreants out there. 4) Marketing-wise, it will make folks who don't understand the issues very deeply more comfortable. And as in #3, that is probably a 99% accurate feeling. 5) For those of us using automatic updating systems, having modules and kernels out of sync is bad potentially, so NO_KLD helps keep that from being an issue. Just my thoughts, we will be patching roughly 5,000 machines for this in our first round of deployments. Deepak Jain AiNET Crist J. Clark wrote: > On Sat, Sep 08, 2001 at 10:53:08AM -0500, D J Hawkey Jr wrote: > >>On Sep 08, at 06:37 PM, Peter Pentchev wrote: >> >>>>Q: Can the kernel be "forced" to load a module from within itself? That >>>>is, does a cracker need to be in userland? >>> >>>Yes, certainly; all kldload(8) does is invoke the kldload(2) syscall, >>>nothing more, nothing userspace-magical. >>>All a kernel routine needs to do is either invoke that syscall, or >>>call the internal kernel functions that kldload(2) calls, like e.g. >>>linker_find_file_by_name() and linker_load_file() in sys/kern/kern_linker.c >> >>Ah. Well then, as I wrote to Kris, the kernel has to deny KLD loading >>altogether, it should be a build-time option, and it should have nothing >>to over-ride this. >> >>Or am I still being too simplistic? I haven't been using KLD- or LKM- >>aware systems very long (~one year), but so far I've had little use for >>them (the modules). I get a box, I configure the kernel to it, and that's >>that. If the box changes, I build a new kernel. At least for the servers >>I've set up, this works fine. Now, a development or users' box, well... > > > Yes, I am still catching up on email almost a month old. > > I went in and made a very simple kernel-build option which disables > the use of kldload(2) (and kldunload(2)) at all times. This is not as > good as raising securelevel(8) since root can still write to > /dev/mem. However, a lot of people in this thread still seem to want > this ability. Since you can still write to /dev/mem, it is only raises > the bar a bit for an attacker. But it does raise the bar enough to > possibly foil a skr1pt k1ddi3 or two. > > To use the patches, > > # cd /usr/src > # patch < /path/to/sys_patch > > Add the line, > > options NO_KLD > > To your kernel configuration and build it in the usual manner. > > Have fun. Unless there is outpouring from people who love the idea, > I'm not going to commit these to FreeBSD. > > > ------------------------------------------------------------------------ > > Index: sys/conf/options > =================================================================== > RCS file: /export/ncvs/src/sys/conf/options,v > retrieving revision 1.191.2.36 > diff -u -r1.191.2.36 options > --- sys/conf/options 2001/09/15 00:50:35 1.191.2.36 > +++ sys/conf/options 2001/10/04 08:21:10 > @@ -464,3 +464,6 @@ > FDC_DEBUG opt_fdc.h > PCFCLOCK_VERBOSE opt_pcfclock.h > PCFCLOCK_MAX_RETRIES opt_pcfclock.h > + > +# Disable loading and unloading of kernel modules > +NO_KLD opt_kern_linker.h > Index: sys/kern/kern_linker.c > =================================================================== > RCS file: /export/ncvs/src/sys/kern/kern_linker.c,v > retrieving revision 1.41.2.2 > diff -u -r1.41.2.2 kern_linker.c > --- sys/kern/kern_linker.c 2000/07/16 13:13:32 1.41.2.2 > +++ sys/kern/kern_linker.c 2001/10/04 08:10:05 > @@ -27,6 +27,7 @@ > */ > > #include "opt_ddb.h" > +#include "opt_kern_linker.h" > > #include > #include > @@ -648,6 +649,10 @@ > int > kldload(struct proc* p, struct kldload_args* uap) > { > +#ifdef NO_KLD > + /* Always return error. */ > + return EPERM; > +#else > char* filename = NULL, *modulename; > linker_file_t lf; > int error = 0; > @@ -685,11 +690,16 @@ > if (filename) > free(filename, M_TEMP); > return error; > +#endif > } > > int > kldunload(struct proc* p, struct kldunload_args* uap) > { > +#ifdef NO_KLD > + /* Always fail. */ > + return EPERM; > +#else > linker_file_t lf; > int error = 0; > > @@ -716,6 +726,7 @@ > > out: > return error; > +#endif > } > > int > > > ------------------------------------------------------------------------ > > Index: sys/conf/options > =================================================================== > RCS file: /export/ncvs/src/sys/conf/options,v > retrieving revision 1.295 > diff -u -r1.295 options > --- sys/conf/options 2001/09/29 22:32:00 1.295 > +++ sys/conf/options 2001/10/04 08:07:37 > @@ -526,3 +527,6 @@ > > # ed driver > ED_NO_MIIBUS opt_ed.h > + > +# Disable loading and unloading of kernel modules > +NO_KLD opt_kern_linker.h > Index: sys/i386/conf/NOTES > =================================================================== > RCS file: /export/ncvs/src/sys/i386/conf/NOTES,v > retrieving revision 1.961 > diff -u -r1.961 NOTES > --- sys/i386/conf/NOTES 2001/09/29 22:31:57 1.961 > +++ sys/i386/conf/NOTES 2001/10/04 08:07:51 > @@ -106,6 +106,10 @@ > # > options ROOTDEVNAME=\"ufs:da0s2e\" > > +# This prevents KLDs from being loaded at all. For those who want the > +# added security but cannot run at an elevated securelevel(8). > +#options NO_KLD > + > > ##################################################################### > # SMP OPTIONS: > Index: sys/kern/kern_linker.c > =================================================================== > RCS file: /export/ncvs/src/sys/kern/kern_linker.c,v > retrieving revision 1.69 > diff -u -r1.69 kern_linker.c > --- sys/kern/kern_linker.c 2001/09/12 08:37:44 1.69 > +++ sys/kern/kern_linker.c 2001/10/04 07:47:05 > @@ -27,6 +27,7 @@ > */ > > #include "opt_ddb.h" > +#include "opt_kern_linker.h" > > #include > #include > @@ -685,6 +686,10 @@ > int > kldload(struct thread* td, struct kldload_args* uap) > { > +#ifdef NO_KLD > + /* Always fail */ > + return EPERM; > +#else > char *kldname, *modname; > char *pathname = NULL; > linker_file_t lf; > @@ -727,6 +732,7 @@ > free(pathname, M_TEMP); > mtx_unlock(&Giant); > return (error); > +#endif > } > > /* > @@ -735,6 +741,10 @@ > int > kldunload(struct thread* td, struct kldunload_args* uap) > { > +#ifdef NO_KLD > + /* Always fail */ > + return EPERM; > +#else > linker_file_t lf; > int error = 0; > > @@ -764,6 +774,7 @@ > out: > mtx_unlock(&Giant); > return (error); > +#endif > } > > /* From owner-freebsd-security@FreeBSD.ORG Wed Sep 29 01:55:48 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA90616A4CE for ; Wed, 29 Sep 2004 01:55:48 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39B7843D41 for ; Wed, 29 Sep 2004 01:55:48 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so40204rnk for ; Tue, 28 Sep 2004 18:55:47 -0700 (PDT) Received: by 10.38.59.51 with SMTP id h51mr1445230rna; Tue, 28 Sep 2004 18:55:47 -0700 (PDT) Received: by 10.38.13.17 with HTTP; Tue, 28 Sep 2004 18:55:47 -0700 (PDT) Message-ID: <84dead7204092818555acdeffd@mail.gmail.com> Date: Wed, 29 Sep 2004 07:25:47 +0530 From: Joseph Koshy To: Ralph Huntington In-Reply-To: <20011126084254.I54163-100000@mohegan.mohawk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200111261334.fAQDY4c95306@star.rila.bg> <20011126084254.I54163-100000@mohegan.mohawk.net> X-Mailman-Approved-At: Wed, 29 Sep 2004 12:30:06 +0000 cc: freebsd-hackers@freebsd.org cc: dwbear75@gmail.com cc: freebsd-security@freebsd.org Subject: Re: Strange FTPD behavior X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joseph Koshy List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2004 01:55:48 -0000 You could use ktrace(1) to determine what the ftpd daemon is actually doing. rh> Is the user's shell listed in /etc/shells? It must be there for ftpd to rh> let them in. vt> I run FreeBSD 4.3-STABLE machine. I use ftpd for ftp server daemon. It has vt> very strange behavior with one of user accounts on my machine. Every one user From owner-freebsd-security@FreeBSD.ORG Wed Sep 29 14:51:56 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0CE016A4CE for ; Wed, 29 Sep 2004 14:51:56 +0000 (GMT) Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15EFA43D3F for ; Wed, 29 Sep 2004 14:51:56 +0000 (GMT) (envelope-from d.m.pick@qmul.ac.uk) Received: from xi.css.qmw.ac.uk ([138.37.8.11]) by mail2.qmul.ac.uk with esmtp (Exim 4.14) id 1CCfo7-0006AE-8P; Wed, 29 Sep 2004 15:51:51 +0100 Received: from localhost ([127.0.0.1] helo=xi.css.qmw.ac.uk) by xi.css.qmw.ac.uk with esmtp (Exim 3.34 #1) id 1CCfo7-000Kb9-00; Wed, 29 Sep 2004 15:51:51 +0100 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Deepak Jain In-reply-to: Your message of "Tue, 28 Sep 2004 18:50:39 EDT." <4159EABF.3030004@ai.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Sep 2004 15:51:51 +0100 From: David Pick Message-Id: X-Sender-Host-Address: 138.37.8.11 X-QM-Scan-Virus: virusscan says the message is clean X-QM-Scan-Virus: ClamAV says the message is clean cc: freebsd-security@FreeBSD.ORG cc: dwbear75@gmail.com cc: cjclark@alum.mit.edu cc: Alexander Langer Subject: Re: Kernel-loadable Root Kits X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2004 14:51:56 -0000 > > Thanks for the module, I think its a good idea to commit it to FreeBSD > for a few reasons: > > 1) Some folks just prefer more static kernels. > > 2) Securelevel is a great thing, but can be a pain to do upgrades around > remotely. [A lot of folks use FreeBSD simply because its a breeze to run > remotely]. > > 3) Until someone writes code to add modules to a kernel via /dev/mem and > releases it to the script kiddie world, the bar has been effectively > raised for 99% of the miscreants out there. > > 4) Marketing-wise, it will make folks who don't understand the issues > very deeply more comfortable. And as in #3, that is probably a 99% > accurate feeling. > > 5) For those of us using automatic updating systems, having modules and > kernels out of sync is bad potentially, so NO_KLD helps keep that from > being an issue. 6) securelevel *is* a great thing but sysadmins are tied to the hierarchy of levels chosen by the project, and one size does *not* fit all. As a more general mechanism I would suggest that there is a kernel-build option for *each* facility that can be locked by securelevel, which geves the level at which that facility becomes locked. Then, someone who builds a kernel can choose the hierarchy for themselves. Of course, the defaults for the options would give the existing behaviour. The net result would be a much more flexible mechanism that would allow someone to choose just which facilities they want available or not at run-time. Just as an example I would like to allow firewall rule-sets to be changed but disallow module loading (after bootup). Think of it as a kernel-build-time capability system. -- David Pick From owner-freebsd-security@FreeBSD.ORG Wed Sep 29 23:50:44 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D29416A4CE for ; Wed, 29 Sep 2004 23:50:44 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 419EE43D41 for ; Wed, 29 Sep 2004 23:50:44 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.12.10) with ESMTP id i8TNoUxE031896; Wed, 29 Sep 2004 19:50:30 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id i8TNoTRO031895; Wed, 29 Sep 2004 19:50:29 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Wed, 29 Sep 2004 19:50:29 -0400 From: David Schultz To: David Pick Message-ID: <20040929235029.GA31828@VARK.MIT.EDU> Mail-Followup-To: David Pick , Deepak Jain , freebsd-security@FreeBSD.ORG, dwbear75@gmail.com, cjclark@alum.mit.edu, Alexander Langer References: <4159EABF.3030004@ai.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: freebsd-security@FreeBSD.ORG cc: Alexander Langer cc: dwbear75@gmail.com cc: cjclark@alum.mit.edu cc: Deepak Jain Subject: Re: Kernel-loadable Root Kits X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2004 23:50:44 -0000 On Wed, Sep 29, 2004, David Pick wrote: > 6) securelevel *is* a great thing but sysadmins are tied to the > hierarchy of levels chosen by the project, and one size does *not* > fit all. As a more general mechanism I would suggest that there > is a kernel-build option for *each* facility that can be locked > by securelevel, which geves the level at which that facility > becomes locked. Great idea. See mac(4). From owner-freebsd-security@FreeBSD.ORG Thu Sep 30 04:50:41 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AC7D16A4CE for ; Thu, 30 Sep 2004 04:50:41 +0000 (GMT) Received: from buexe.b-5.de (buexe.b-5.de [80.148.32.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24CBD43D46 for ; Thu, 30 Sep 2004 04:50:40 +0000 (GMT) (envelope-from lupe@lupe-christoph.de) Received: from antalya.lupe-christoph.de (antalya.lupe-christoph.de [172.17.0.9])i8U4oSFJ011126; Thu, 30 Sep 2004 06:50:30 +0200 Received: from localhost (localhost [127.0.0.1]) by antalya.lupe-christoph.de (Postfix) with ESMTP id 46F0FB886; Thu, 30 Sep 2004 06:50:24 +0200 (CEST) Received: from antalya.lupe-christoph.de ([127.0.0.1]) by localhost (antalya [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06058-03; Thu, 30 Sep 2004 06:50:24 +0200 (CEST) Received: by antalya.lupe-christoph.de (Postfix, from userid 1000) id 29A99B885; Thu, 30 Sep 2004 06:50:24 +0200 (CEST) Date: Thu, 30 Sep 2004 06:50:24 +0200 To: David Pick , Deepak Jain , freebsd-security@FreeBSD.ORG, dwbear75@gmail.com, cjclark@alum.mit.edu, Alexander Langer Message-ID: <20040930045024.GB13852@lupe-christoph.de> Mail-Followup-To: David Pick , Deepak Jain , freebsd-security@FreeBSD.ORG, dwbear75@gmail.com, cjclark@alum.mit.edu, Alexander Langer References: <4159EABF.3030004@ai.net> <20040929235029.GA31828@VARK.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040929235029.GA31828@VARK.MIT.EDU> User-Agent: Mutt/1.5.6+20040722i From: lupe@lupe-christoph.de (Lupe Christoph) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lupe-christoph.de Subject: Re: Kernel-loadable Root Kits X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2004 04:50:41 -0000 On Wednesday, 2004-09-29 at 19:50:29 -0400, David Schultz wrote: > Great idea. See mac(4). I suppose this gives more than "No manual entry for mac" when you run FreeBSD 5.x? Lupe Christoph -- | lupe@lupe-christoph.de | http://www.lupe-christoph.de/ | | "... putting a mail server on the Internet without filtering is like | | covering yourself with barbecue sauce and breaking into the Charity | | Home for Badgers with Rabies. Michael Lucas | From owner-freebsd-security@FreeBSD.ORG Thu Sep 30 04:59:52 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4664616A4CE for ; Thu, 30 Sep 2004 04:59:52 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12C7843D54 for ; Thu, 30 Sep 2004 04:59:52 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8U53V4S000384; Wed, 29 Sep 2004 22:03:31 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8U53Vf9000383; Wed, 29 Sep 2004 22:03:31 -0700 Date: Wed, 29 Sep 2004 22:03:31 -0700 From: Brooks Davis To: David Pick , Deepak Jain , freebsd-security@FreeBSD.ORG, dwbear75@gmail.com, cjclark@alum.mit.edu, Alexander Langer Message-ID: <20040930050331.GA31490@odin.ac.hmc.edu> References: <4159EABF.3030004@ai.net> <20040929235029.GA31828@VARK.MIT.EDU> <20040930045024.GB13852@lupe-christoph.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <20040930045024.GB13852@lupe-christoph.de> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Subject: Re: Kernel-loadable Root Kits X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2004 04:59:52 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 30, 2004 at 06:50:24AM +0200, Lupe Christoph wrote: > On Wednesday, 2004-09-29 at 19:50:29 -0400, David Schultz wrote: >=20 > > Great idea. See mac(4). >=20 > I suppose this gives more than "No manual entry for mac" when you run > FreeBSD 5.x? Yes. You can find the manpage in question at: http://www.freebsd.org/cgi/man.cgi?query=3Dmac&apropos=3D0&sektion=3D4&manp= ath=3DFreeBSD+5.2.1-RELEASE+and+Ports&format=3Dhtml -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBW5OiXY6L6fI4GtQRAkXiAJ45c9acYhOlwZLgWZe339j+IQjTgQCfcVO9 nKMGbEpG+htZdk1Y25L1iRE= =SJyY -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- From owner-freebsd-security@FreeBSD.ORG Wed Sep 29 22:23:51 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8A1116A4CE for ; Wed, 29 Sep 2004 22:23:51 +0000 (GMT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 754B043D41 for ; Wed, 29 Sep 2004 22:23:51 +0000 (GMT) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (c-24-6-187-112.client.comcast.net[24.6.187.112]) by comcast.net (sccrmhc12) with ESMTP id <20040929222350012009gcife>; Wed, 29 Sep 2004 22:23:50 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.11/8.12.8) with ESMTP id i8TMNmpl090771; Wed, 29 Sep 2004 15:23:48 -0700 (PDT) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.11/8.12.11/Submit) id i8TMNkYM090770; Wed, 29 Sep 2004 15:23:46 -0700 (PDT) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Wed, 29 Sep 2004 15:23:46 -0700 From: "Crist J. Clark" To: David Pick Message-ID: <20040929222346.GB90690@blossom.cjclark.org> References: <4159EABF.3030004@ai.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-URL: http://people.freebsd.org/~cjc/ X-Mailman-Approved-At: Thu, 30 Sep 2004 12:36:46 +0000 cc: freebsd-security@FreeBSD.ORG cc: dwbear75@gmail.com cc: Alexander Langer cc: Deepak Jain Subject: Re: Kernel-loadable Root Kits X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cjclark@alum.mit.edu List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2004 22:23:51 -0000 Before anyone takes this thread any farther, the mail of mine that started it is a THREE YEAR OLD message some MTA with a very, very long queue-lifetime belched back to the list. Now-a-days, if you want super-hardcore security, as of the 5 branch, go MAC, http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac.html -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-security@FreeBSD.ORG Thu Sep 30 01:02:53 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1459916A4CE for ; Thu, 30 Sep 2004 01:02:53 +0000 (GMT) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id A796F43D49 for ; Thu, 30 Sep 2004 01:02:52 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from localhost ([192.168.0.5]) (authenticated bits=0) by pittgoth.com (8.12.10/8.12.10) with ESMTP id i8U12aex006584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Sep 2004 21:02:36 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Wed, 29 Sep 2004 21:03:18 -0400 From: Tom Rhodes To: David Schultz Message-Id: <20040929210318.5c9c2ba1@localhost> In-Reply-To: <20040929235029.GA31828@VARK.MIT.EDU> References: <4159EABF.3030004@ai.net> <20040929235029.GA31828@VARK.MIT.EDU> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 30 Sep 2004 12:36:46 +0000 cc: dwbear75@gmail.com cc: freebsd-security@FreeBSD.org cc: David Pick cc: Deepak Jain cc: Alexander Langer cc: cjclark@alum.mit.edu Subject: Re: Kernel-loadable Root Kits X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2004 01:02:53 -0000 On Wed, 29 Sep 2004 19:50:29 -0400 David Schultz wrote: > On Wed, Sep 29, 2004, David Pick wrote: > > 6) securelevel *is* a great thing but sysadmins are tied to the > > hierarchy of levels chosen by the project, and one size does *not* > > fit all. As a more general mechanism I would suggest that there > > is a kernel-build option for *each* facility that can be locked > > by securelevel, which geves the level at which that facility > > becomes locked. > > Great idea. See mac(4). And don't forget to read the MAC chapter in the FreeBSD Handbook. :) -- Tom Rhodes From owner-freebsd-security@FreeBSD.ORG Thu Sep 30 20:45:20 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D85F416A4D3 for ; Thu, 30 Sep 2004 20:45:20 +0000 (GMT) Received: from mx2.nersc.gov (mx2.nersc.gov [128.55.6.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id B72BA43D1F for ; Thu, 30 Sep 2004 20:45:20 +0000 (GMT) (envelope-from dart@nersc.gov) Received: by mx2.nersc.gov (Postfix, from userid 4002) id 7B8AA774C; Thu, 30 Sep 2004 13:45:20 -0700 (PDT) Received: from mx2.nersc.gov (localhost [127.0.0.1]) by localhost.nersc.gov (Postfix) with ESMTP id 5BA51775C for ; Thu, 30 Sep 2004 13:45:17 -0700 (PDT) Received: from gemini.nersc.gov (gemini.nersc.gov [128.55.16.111]) by mx2.nersc.gov (Postfix) with ESMTP id 14B92774C for ; Thu, 30 Sep 2004 13:45:17 -0700 (PDT) Received: from gemini.nersc.gov (localhost [127.0.0.1]) by gemini.nersc.gov (Postfix) with ESMTP id EB577F987 for ; Thu, 30 Sep 2004 13:45:16 -0700 (PDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: freebsd-security@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1016627792P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 30 Sep 2004 13:45:16 -0700 From: Eli Dart Message-Id: <20040930204516.EB577F987@gemini.nersc.gov> X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mx2.nersc.gov Subject: apache2 port X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2004 20:45:21 -0000 --==_Exmh_-1016627792P Content-Type: text/plain; charset=us-ascii Hi all, There has been another vulnerability [1] discovered in apache2. This affects only version 2.0.51 (where it was introduced). The ports tree is frozen, pending 5.3-R, so I assume that an update of the apache2 port to 2.0.52 is not forthcoming any time soon. The question is this -- since the apache2 in the ports tree is 2.0.50 plus patches, does the version in the ports tree have this vulnerability? It seems that it only would if the patches to 2.0.50 introduced the vulnerability... Does anyone know? Thanks! --eli --==_Exmh_-1016627792P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) Comment: Exmh version 2.5 07/13/2001 iD8DBQFBXHBcLTFEeF+CsrMRAjtmAJ9ClRARO8wY1TbRkr+pdhiGsEQf7ACfW8HO g4c92+XqeA75fQVTnuLu8i8= =XVxW -----END PGP SIGNATURE----- --==_Exmh_-1016627792P-- From owner-freebsd-security@FreeBSD.ORG Thu Sep 30 20:55:35 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CAF716A514 for ; Thu, 30 Sep 2004 20:55:33 +0000 (GMT) Received: from cowbert.2y.net (d46h180.public.uconn.edu [137.99.46.180]) by mx1.FreeBSD.org (Postfix) with SMTP id 891C643D3F for ; Thu, 30 Sep 2004 20:55:03 +0000 (GMT) (envelope-from sirmoo@cowbert.net) Received: (qmail 72668 invoked by uid 1001); 30 Sep 2004 20:55:03 -0000 Date: Thu, 30 Sep 2004 16:55:03 -0400 From: "Peter C. Lai" To: Eli Dart Message-ID: <20040930205503.GS243@cowbert.net> References: <20040930204516.EB577F987@gemini.nersc.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040930204516.EB577F987@gemini.nersc.gov> User-Agent: Mutt/1.5.6i cc: freebsd-security@freebsd.org Subject: Re: apache2 port X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2004 20:55:36 -0000 no. you can tell by PORTVERSION in the Makefile. On Thu, Sep 30, 2004 at 01:45:16PM -0700, Eli Dart wrote: > Hi all, > > There has been another vulnerability [1] discovered in apache2. This > affects only version 2.0.51 (where it was introduced). The ports > tree is frozen, pending 5.3-R, so I assume that an update of the > apache2 port to 2.0.52 is not forthcoming any time soon. > > The question is this -- since the apache2 in the ports tree is 2.0.50 > plus patches, does the version in the ports tree have this > vulnerability? It seems that it only would if the patches to 2.0.50 > introduced the vulnerability... Does anyone know? > > Thanks! > > --eli > > > > -- Peter C. Lai University of Connecticut Dept. of Molecular and Cell Biology Yale University School of Medicine SenseLab | Research Assistant http://cowbert.2y.net/