From owner-freebsd-security@FreeBSD.ORG Sat Jul 8 21:39:40 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 8738B16A4DF; Sat, 8 Jul 2006 21:39:40 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from proof.pobox.com (proof.pobox.com [207.106.133.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C4AD43D45; Sat, 8 Jul 2006 21:39:39 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id EB15729D52; Sat, 8 Jul 2006 17:39:38 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 465D25F5C1; Sat, 8 Jul 2006 17:39:34 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1FzKWS-000Aiu-GX; Sat, 08 Jul 2006 22:39:32 +0100 Date: Sat, 8 Jul 2006 22:39:32 +0100 From: Brian Candler To: Mikhail Teterin Message-ID: <20060708213932.GA41178@uk.tiscali.com> References: <200607072030.01999.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607072030.01999.mi+mx@aldan.algebra.com> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Mon, 10 Jul 2006 12:53:07 +0000 Cc: freebsd-security@freebsd.org, imp@freebsd.org, net@freebsd.org Subject: Re: strange limitation on rcmd() X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2006 21:39:40 -0000 On Fri, Jul 07, 2006 at 08:30:01PM -0400, Mikhail Teterin wrote: > The manual page says, that rcmd() is only to be used by root's processes. DESCRIPTION The rcmd() function is used by the super-user to execute a command on a remote machine using an authentication scheme based on reserved port num- bers. Note that only root can bind to reserved ports. > On other OSes (Solaris, AIX), trying to call rcmd() without being root simply > fails. > > FreeBSD, however, tries to be helpful and invokes rcmdsh in this case, which > is inefficient and leaves the stderr's filedescriptor (fd2p) unfilled. > > Why? > > My understanding is, this is to make it harder for would-be attackers to > attack machines with .rhosts-based security. But that is nothing more than a > bad band-aid anyway -- attacker's own implementation of rcmd() (without the > geteuid() checks) is trivial... But an attacker who doesn't have root won't be able to use their own implementation of rcmd(). It will just fail. Either the attacker will ask to bind to a privileged port (which will fail at the local host), or they will bind to a non-privileged port (in which case the remote host will reject the request) rsh is a setuid root binary. It is able to bind to privileged ports, whilst performing security checks that the requested access is valid. In the same way, the 'passwd' command lets you change your own password, without letting you change someone else's. > So, without providing any meaningful security improvement (who is relying > on .rhosts for security anyway?!), we are impeding a very useful > functionality. No security improvement is implied. Rather, you just get extra functionality. Instead of a dead failure, certain non-root requests are allowed (i.e. user A on host X can run commands as user A on host Y) > rcmd offers an efficient way to send your data to a command "abroad" and even > has a mechanism for getting the remote's stderr -- assuming, your network is > secure enough for you to trust .rhosts. And the requesting user is running as root, so they can bind to a privileged port. > Why are we duplicating the misguided efforts of commercial Unixes and limiting > it to root only? Because this is exactly how the .rhosts security model works - it accepts requests only from privileged ports, which in turn means that it knows the request only came from root. This mechanism is only valid for trusted hosts, of course. If you allow a random person to put their own PC on the network, they can of course send packets from privileged ports (either by installing Unix with their own root password, or by installing DOS and sending packets which come from privileged ports) HTH, Brian. From owner-freebsd-security@FreeBSD.ORG Mon Jul 10 14:07:11 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 C904716A4DD; Mon, 10 Jul 2006 14:07:11 +0000 (UTC) (envelope-from iang@iang.org) Received: from mx1.sonance.net (mx1.sonance.net [62.116.45.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C13043D46; Mon, 10 Jul 2006 14:07:11 +0000 (GMT) (envelope-from iang@iang.org) Received: from localhost (mf1 [127.0.0.1]) by mx1.sonance.net (Postfix) with ESMTP id A801513EC7; Mon, 10 Jul 2006 16:07:17 +0200 (CEST) Received: from mx1.sonance.net ([127.0.0.1]) by localhost (mf1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30551-09; Mon, 10 Jul 2006 16:07:16 +0200 (CEST) Received: from postix.sonance.net (zentrix [192.168.0.223]) by mx1.sonance.net (Postfix) with ESMTP id 7995E13EC3; Mon, 10 Jul 2006 16:07:16 +0200 (CEST) Received: from localhost (zentrix [127.0.0.1]) by postix.sonance.net (Postfix) with ESMTP id 3DA7417B52E; Mon, 10 Jul 2006 16:07:05 +0200 (CEST) Received: from postix.sonance.net ([127.0.0.1]) by localhost (zentrix [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05225-08; Mon, 10 Jul 2006 16:07:04 +0200 (CEST) Received: from [127.0.0.1] (zentrix [127.0.0.1]) by postix.sonance.net (Postfix) with ESMTP id BC9D817B51D; Mon, 10 Jul 2006 16:07:04 +0200 (CEST) Message-ID: <44B25F0A.5040709@iang.org> Date: Mon, 10 Jul 2006 16:07:06 +0200 From: Iang User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Candler References: <200607072030.01999.mi+mx@aldan.algebra.com> <20060708213932.GA41178@uk.tiscali.com> In-Reply-To: <20060708213932.GA41178@uk.tiscali.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: sonance network anti-spam amavisd-new-20030616-p10 controlled spam X-Virus-Scanned: sonance network anti-spam amavisd-new-20030616-p10 controlled spam Cc: freebsd-security@freebsd.org, Mikhail Teterin , imp@freebsd.org, net@freebsd.org Subject: Re: strange limitation on rcmd() X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iang@iang.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 14:07:11 -0000 Brian Candler wrote: > Note that only root can bind to reserved ports. ... > This mechanism is only valid for trusted hosts, of course. If you allow a > random person to put their own PC on the network, they can of course send > packets from privileged ports (either by installing Unix with their own root > password, or by installing DOS and sending packets which come from > privileged ports) I gather that it is now possible to disable the privileged ports thing on FreeBSD at least. (Thank heavens, I say :) iang From owner-freebsd-security@FreeBSD.ORG Mon Jul 10 14:17:33 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 1221816A4DA; Mon, 10 Jul 2006 14:17:33 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89DF943D5C; Mon, 10 Jul 2006 14:17:31 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id CB8222D4905; Mon, 10 Jul 2006 14:17:30 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 79E851142D; Mon, 10 Jul 2006 16:17:30 +0200 (CEST) Date: Mon, 10 Jul 2006 16:17:30 +0200 From: "Simon L. Nielsen" To: Iang Message-ID: <20060710141729.GF1101@zaphod.nitro.dk> References: <200607072030.01999.mi+mx@aldan.algebra.com> <20060708213932.GA41178@uk.tiscali.com> <44B25F0A.5040709@iang.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YToU2i3Vx8H2dn7O" Content-Disposition: inline In-Reply-To: <44B25F0A.5040709@iang.org> User-Agent: Mutt/1.5.11 Cc: freebsd-security@freebsd.org, Mikhail Teterin , net@freebsd.org, imp@freebsd.org, Brian Candler Subject: Re: strange limitation on rcmd() X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 14:17:33 -0000 --YToU2i3Vx8H2dn7O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2006.07.10 16:07:06 +0200, Iang wrote: > Brian Candler wrote: >=20 > >Note that only root can bind to reserved ports. >=20 > ... >=20 > >This mechanism is only valid for trusted hosts, of course. If you allow a > >random person to put their own PC on the network, they can of course send > >packets from privileged ports (either by installing Unix with their own= =20 > >root > >password, or by installing DOS and sending packets which come from > >privileged ports) >=20 > I gather that it is now possible to disable the > privileged ports thing on FreeBSD at least. >=20 > (Thank heavens, I say :) Actually it is, but it would obviously be a stupid idea to do so any place where privileged ports are required... [simon@zaphod:~] sysctl net.inet.ip.portrange.reservedhigh net.inet.ip.port= range.reservedlow net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.reservedlow: 0 --=20 Simon L. Nielsen --YToU2i3Vx8H2dn7O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEsmF5h9pcDSc1mlERAq7RAJ9mpDSX+M8NDrC5jMScYITwB0eyCwCfd1jp R9tCljciXvIJNmsUKHWtdJU= =R23T -----END PGP SIGNATURE----- --YToU2i3Vx8H2dn7O-- From owner-freebsd-security@FreeBSD.ORG Mon Jul 10 15:47:36 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 7EB6816A4DA; Mon, 10 Jul 2006 15:47:36 +0000 (UTC) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id E88C843D45; Mon, 10 Jul 2006 15:47:35 +0000 (GMT) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan [127.0.0.1]) by aldan.algebra.com (8.13.6/8.13.6) with ESMTP id k6AFlYiO062987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jul 2006 11:47:34 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by aldan.algebra.com (8.13.6/8.13.6/Submit) id k6AFlYOl062986; Mon, 10 Jul 2006 11:47:34 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) From: Mikhail Teterin To: "Simon L. Nielsen" , Brian Candler Date: Mon, 10 Jul 2006 11:47:33 -0400 User-Agent: KMail/1.9.1 References: <200607072030.01999.mi+mx@aldan.algebra.com> <44B25F0A.5040709@iang.org> <20060710141729.GF1101@zaphod.nitro.dk> In-Reply-To: <20060710141729.GF1101@zaphod.nitro.dk> X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" X-Mailman-Approved-At: Tue, 11 Jul 2006 03:03:50 +0000 Cc: Brian Candler , Mikhail Teterin , freebsd-security@freebsd.org, net@freebsd.org, imp@freebsd.org, Iang Subject: Re: strange limitation on rcmd() X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 15:47:36 -0000 On Monday 10 July 2006 10:17, Simon L. Nielsen wrote: = Actually it is, but it would obviously be a stupid idea to do so any = place where privileged ports are required... It would be. But where they are NOT required, it is stupid to check the geteuid() inside the client's rcmd :-) Thank you very much for your explanation, Brian, rsh being an SUID is something I overlooked. What I remain upset about, though, is that the rcmdsh(), which is used by rcmd() ignores the fd2p parameter making it impossible to capture the remote's stderr... Yours, -mi From owner-freebsd-security@FreeBSD.ORG Mon Jul 10 17:51:08 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 EAA2416A4DD; Mon, 10 Jul 2006 17:51:08 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from proof.pobox.com (proof.pobox.com [207.106.133.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87CD443D46; Mon, 10 Jul 2006 17:51:08 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 6571D23937; Mon, 10 Jul 2006 13:51:07 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id D905D61F46; Mon, 10 Jul 2006 13:51:00 -0400 (EDT) Received: from brian by mappit.local.linnet.org with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1FzzuN-0000cO-1F; Mon, 10 Jul 2006 18:50:59 +0100 Date: Mon, 10 Jul 2006 18:50:59 +0100 From: Brian Candler To: Mikhail Teterin Message-ID: <20060710175059.GA2325@uk.tiscali.com> References: <200607072030.01999.mi+mx@aldan.algebra.com> <44B25F0A.5040709@iang.org> <20060710141729.GF1101@zaphod.nitro.dk> <200607101147.34530@aldan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607101147.34530@aldan> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Tue, 11 Jul 2006 03:04:43 +0000 Cc: Mikhail Teterin , "Simon L. Nielsen" , freebsd-security@freebsd.org, net@freebsd.org, imp@freebsd.org, Iang Subject: Re: strange limitation on rcmd() X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 17:51:09 -0000 On Mon, Jul 10, 2006 at 11:47:33AM -0400, Mikhail Teterin wrote: > What I remain upset about, though, is that the rcmdsh(), which is used by > rcmd() ignores the fd2p parameter making it impossible to capture the > remote's stderr... Well, it's probably worth send-pr'ing it. I'd first test whether rsh itself forwards stderr properly. Maybe there's some underlying reason why rcmdsh doesn't have an fd2p argument. From owner-freebsd-security@FreeBSD.ORG Mon Jul 10 18:09:57 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 0819016A4DE; Mon, 10 Jul 2006 18:09:57 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19E1943D45; Mon, 10 Jul 2006 18:09:56 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by aldan.algebra.com (8.13.6/8.13.6) with ESMTP id k6AI9pRM082047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Jul 2006 14:09:52 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from [172.21.130.86] (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k6AI9jtF079185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jul 2006 14:09:46 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: Brian Candler Date: Mon, 10 Jul 2006 14:09:39 -0400 User-Agent: KMail/1.9.1 References: <200607072030.01999.mi+mx@aldan.algebra.com> <200607101147.34530@aldan> <20060710175059.GA2325@uk.tiscali.com> In-Reply-To: <20060710175059.GA2325@uk.tiscali.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200607101409.40651.mi+mx@aldan.algebra.com> Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.88/1590/Mon Jul 10 01:34:09 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Tue, 11 Jul 2006 03:04:55 +0000 Cc: "Simon L. Nielsen" , freebsd-security@freebsd.org, Mikhail Teterin , net@freebsd.org, imp@freebsd.org, Iang Subject: Re: strange limitation on rcmd() X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 18:09:57 -0000 понед╕лок 10 липень 2006 13:50, Brian Candler написав: > Well, it's probably worth send-pr'ing it. The rcmdsh() is taken from OpenBSD, I think, and has no room for the stderr. One would need to reimplement something like rcmdsh2() first :-) > I'd first test whether rsh itself forwards stderr properly. Maybe there's > some underlying reason why rcmdsh doesn't have an fd2p argument. The rsh utility copies its standard input to the remote command, the standard output of the remote command to its standard output, and the standard error of the remote command to its standard error. ssh seems compliant too. The signal-handling is different, though: Interrupt, quit and terminate signals are propagated to the remote command; Whereas with rcmd one just writes the signal number (any signal number) into the fd2 descriptor... I think, rcmd() should just try to connect and leave it to the remote to reject it based on the too-low port number or anything. Another approach would be to use a separate suid utility (Linux has rcmd(1), for example), with semantics more closely matching those of rcmd(3). The reason I like rcmd() is that it lets me send data to a remote machine a) _directly_ from my program; and b) without also implementing the server side. I could achieve both of these with a non-root process by disabling the "isroot" checks inside the rcmd and by configuring the server to accept rcmd from any port. Other approaches require the root's setuid bit on the program, or abandoning the _directness_ of the a) by copying many gigabytes through the client's memory buffers a couple of extra times. -mi From owner-freebsd-security@FreeBSD.ORG Tue Jul 11 19:41:17 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 89EA116A4E0 for ; Tue, 11 Jul 2006 19:41:17 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D4CF43D6D for ; Tue, 11 Jul 2006 19:41:16 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.6/8.13.4) with ESMTP id k6BJfF4G085615 for ; Tue, 11 Jul 2006 15:41:15 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3P/8.13.3) with ESMTP id k6BJfGCK059306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Jul 2006 15:41:16 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.3.4.0.20060711142809.04a6f8e0@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 11 Jul 2006 15:41:33 -0400 To: freebsd-security@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Integrity checking NANOBSD images X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 19:41:17 -0000 We have a number of Soekris devices that we will be deploying remotely in semi- hostile physical environments. The remote links are dialup so I dont have a lot of bandwidth available. I want to do integrity checks of the images so that I can detect any tampering of the flash image. If I upload a static sha256 binary to /tmp on the remote box (which is a RAM disk) and then do something like e.g. # ssh remote1.example.com "mkdir /tmp/rand-directory" # scp /usr/local/bin/sha256 remote1.example.com:/tmp/rand-directory/sha256 # scp /usr/local/bin/dd remote1.example.com:/tmp/rand-directory/dd # ssh remote1.example.com "/tmp/rand-directory/dd if=/dev/ad2s1a bs=4096k | /tmp/rand-directory/sha256" 120+1 records in 120+1 records out 505389056 bytes transferred in 169.727727 secs (2977646 bytes/sec) 955ebad583bfc0718eb28ac89563941407294d5c61a0c0f35e3773f029cc0685 Can I be reasonably certain the image has not been tampered with ? Or are there trivial ways to defeat this check ? The flash is always mounted read-only, so in theory nothing should change with it. Or do I need to cram on tripwire or similar programs onto the nanobsd image ? ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-security@FreeBSD.ORG Tue Jul 11 19:50:57 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 A587016A4E5 for ; Tue, 11 Jul 2006 19:50:57 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07AA143D64 for ; Tue, 11 Jul 2006 19:50:49 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 3685B5DD8; Tue, 11 Jul 2006 15:50:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emKELmLrCh59; Tue, 11 Jul 2006 15:50:48 -0400 (EDT) Received: from [192.168.1.251] (pool-68-161-117-245.ny325.east.verizon.net [68.161.117.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id ECD1E5DBA; Tue, 11 Jul 2006 15:50:47 -0400 (EDT) Message-ID: <44B4010E.7010809@mac.com> Date: Tue, 11 Jul 2006 15:50:38 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Mike Tancsa References: <6.2.3.4.0.20060711142809.04a6f8e0@64.7.153.2> In-Reply-To: <6.2.3.4.0.20060711142809.04a6f8e0@64.7.153.2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org Subject: Re: Integrity checking NANOBSD images X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 19:50:57 -0000 Mike Tancsa wrote: [ ... ] > # ssh remote1.example.com "/tmp/rand-directory/dd if=/dev/ad2s1a > bs=4096k | /tmp/rand-directory/sha256" > 120+1 records in > 120+1 records out > 505389056 bytes transferred in 169.727727 secs (2977646 bytes/sec) > 955ebad583bfc0718eb28ac89563941407294d5c61a0c0f35e3773f029cc0685 > > Can I be reasonably certain the image has not been tampered with ? Or > are there trivial ways to defeat this check ? Checksumming the device image is a fine way of checking the integrity of it, assuming it is read-only. The only thing you might want to do is use two or three checksum algorithms (ie, use sha256 and md5 and something else), so that someone can't create a new image which matches the sha256 checksum of the original. -- -Chuck From owner-freebsd-security@FreeBSD.ORG Tue Jul 11 20:05:56 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 22B9C16A4E1 for ; Tue, 11 Jul 2006 20:05:56 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BCE343D6D for ; Tue, 11 Jul 2006 20:05:55 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id B63851703F; Tue, 11 Jul 2006 20:05:53 +0000 (UTC) To: Chuck Swiger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 11 Jul 2006 15:50:38 -0400." <44B4010E.7010809@mac.com> Date: Tue, 11 Jul 2006 20:05:53 +0000 Message-ID: <77121.1152648353@critter.freebsd.dk> Cc: freebsd-security@freebsd.org Subject: Re: Integrity checking NANOBSD images X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 20:05:56 -0000 In message <44B4010E.7010809@mac.com>, Chuck Swiger writes: >Checksumming the device image is a fine way of checking the integrity of it, >assuming it is read-only. The only thing you might want to do is use two or >three checksum algorithms (ie, use sha256 and md5 and something else), so that >someone can't create a new image which matches the sha256 checksum of the >original. A much better idea is to send a random "salt" to be prepended to the disk image before it is run through sha256, that would prevent the attacker from running sha256 and any other algorithm you could care for on the image, store the results and return them with trojans. Copying the sha256 binary over is no guarantee against a kernel embedded trojan. But then again, how paranoid one has to be is a matter of preference. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-security@FreeBSD.ORG Tue Jul 11 20:18:05 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 BEE5416A4E2 for ; Tue, 11 Jul 2006 20:18:05 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77AE743D78 for ; Tue, 11 Jul 2006 20:18:04 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k6BKHwCx098213; Tue, 11 Jul 2006 16:17:58 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3P/8.13.3) with ESMTP id k6BKI2WV059489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jul 2006 16:18:02 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.3.4.0.20060711161049.04bd37a0@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 11 Jul 2006 16:18:19 -0400 To: "Poul-Henning Kamp" , Chuck Swiger From: Mike Tancsa In-Reply-To: <77121.1152648353@critter.freebsd.dk> References: <77121.1152648353@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Status: Clean Cc: freebsd-security@freebsd.org Subject: Re: Integrity checking NANOBSD images X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 20:18:05 -0000 At 04:05 PM 11/07/2006, Poul-Henning Kamp wrote: >In message <44B4010E.7010809@mac.com>, Chuck Swiger writes: > > >Checksumming the device image is a fine way of checking the > integrity of it, > >assuming it is read-only. The only thing you might want to do is > use two or > >three checksum algorithms (ie, use sha256 and md5 and something > else), so that > >someone can't create a new image which matches the sha256 checksum of the > >original. > >A much better idea is to send a random "salt" to be prepended to >the disk image before it is run through sha256, that would prevent >the attacker from running sha256 and any other algorithm you >could care for on the image, store the results and return them >with trojans. > >Copying the sha256 binary over is no guarantee against a kernel >embedded trojan. > >But then again, how paranoid one has to be is a matter of preference. Hi, Thanks for the responses. I know there are no perfect ways. I guess I want to understand the risk as much as possible and mitigate against tampering as much as possible without designing the requirement for some guy to sit in front of the box with a gun :) With respect to prepending a random salt to the image, can you expand what you mean ? ---Mike >-- >Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >phk@FreeBSD.ORG | TCP/IP since RFC 956 >FreeBSD committer | BSD since 4.3-tahoe >Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-security@FreeBSD.ORG Tue Jul 11 20:22:25 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 61EBD16A4DE for ; Tue, 11 Jul 2006 20:22:25 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0468743D5A for ; Tue, 11 Jul 2006 20:22:24 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 9623F1703F; Tue, 11 Jul 2006 20:22:23 +0000 (UTC) To: Mike Tancsa From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 11 Jul 2006 16:18:19 -0400." <6.2.3.4.0.20060711161049.04bd37a0@64.7.153.2> Date: Tue, 11 Jul 2006 20:22:23 +0000 Message-ID: <77192.1152649343@critter.freebsd.dk> Cc: freebsd-security@freebsd.org Subject: Re: Integrity checking NANOBSD images X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 20:22:25 -0000 In message <6.2.3.4.0.20060711161049.04bd37a0@64.7.153.2>, Mike Tancsa writes: >With respect to prepending a random salt to the image, can you expand >what you mean ? If you just run sha256 on the disk image, and the attacker finds out, he will just run sha256 himself and record the result. Arming a trojan to just do 'sleep 145 ; echo "sha256 = 0248482..."' when you thing you're running sha256 would be trivia. If you take a random hexstring of 16 digits and prepend to the disk-image, then the output of the sha256 is not constant and in order to simulate it, he has to have access to the disk image to feed into sha256 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-security@FreeBSD.ORG Tue Jul 11 20:24:20 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 8719D16A4E1 for ; Tue, 11 Jul 2006 20:24:20 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22CB043D72 for ; Tue, 11 Jul 2006 20:24:20 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 6DC755DDD; Tue, 11 Jul 2006 16:24:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7vzqgRv-MS6; Tue, 11 Jul 2006 16:24:16 -0400 (EDT) Received: from [192.168.1.251] (pool-68-161-117-245.ny325.east.verizon.net [68.161.117.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 7BEA65D79; Tue, 11 Jul 2006 16:24:16 -0400 (EDT) Message-ID: <44B408E7.8070000@mac.com> Date: Tue, 11 Jul 2006 16:24:07 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Poul-Henning Kamp References: <77121.1152648353@critter.freebsd.dk> In-Reply-To: <77121.1152648353@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org Subject: Re: Integrity checking NANOBSD images X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 20:24:20 -0000 Poul-Henning Kamp wrote: > In message <44B4010E.7010809@mac.com>, Chuck Swiger writes: >> Checksumming the device image is a fine way of checking the integrity of it, >> assuming it is read-only. The only thing you might want to do is use two or >> three checksum algorithms (ie, use sha256 and md5 and something else), so that >> someone can't create a new image which matches the sha256 checksum of the >> original. > > A much better idea is to send a random "salt" to be prepended to > the disk image before it is run through sha256, that would prevent > the attacker from running sha256 and any other algorithm you > could care for on the image, store the results and return them > with trojans. That suggestion is a very good point, although trying to find a single trojaned image which matches several checksum methods is supposed to be a highly difficult task. -- -Chuck From owner-freebsd-security@FreeBSD.ORG Tue Jul 11 20:34:16 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 248A516A4DA for ; Tue, 11 Jul 2006 20:34:16 +0000 (UTC) (envelope-from ru@ip.net.ua) Received: from cielago.ip.net.ua (cielago.ip.net.ua [82.193.96.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40D4B43D73 for ; Tue, 11 Jul 2006 20:34:14 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by cielago.ip.net.ua (8.13.6/8.13.6) with ESMTP id k6BKWwlZ053848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jul 2006 23:32:59 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.6/8.13.6) id k6BKYIVs092160; Tue, 11 Jul 2006 23:34:18 +0300 (EEST) (envelope-from ru) Date: Tue, 11 Jul 2006 23:34:18 +0300 From: Ruslan Ermilov To: Mike Tancsa Message-ID: <20060711203417.GJ56190@ip.net.ua> References: <44B4010E.7010809@mac.com> <77121.1152648353@critter.freebsd.dk> <6.2.3.4.0.20060711161049.04bd37a0@64.7.153.2> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IbA9xpzOQlG26JSn" Content-Disposition: inline In-Reply-To: <6.2.3.4.0.20060711161049.04bd37a0@64.7.153.2> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new Cc: freebsd-security@freebsd.org, Poul-Henning Kamp Subject: Re: Integrity checking NANOBSD images X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 20:34:16 -0000 --IbA9xpzOQlG26JSn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 11, 2006 at 04:18:19PM -0400, Mike Tancsa wrote: > At 04:05 PM 11/07/2006, Poul-Henning Kamp wrote: > >In message <44B4010E.7010809@mac.com>, Chuck Swiger writes: > > > >>Checksumming the device image is a fine way of checking the=20 > >integrity of it, > >>assuming it is read-only. The only thing you might want to do is=20 > >use two or > >>three checksum algorithms (ie, use sha256 and md5 and something=20 > >else), so that > >>someone can't create a new image which matches the sha256 checksum of t= he > >>original. > > > >A much better idea is to send a random "salt" to be prepended to > >the disk image before it is run through sha256, that would prevent > >the attacker from running sha256 and any other algorithm you > >could care for on the image, store the results and return them > >with trojans. > > > >Copying the sha256 binary over is no guarantee against a kernel > >embedded trojan. > > > >But then again, how paranoid one has to be is a matter of preference. >=20 >=20 > Hi, > Thanks for the responses. I know there are no perfect ways.=20 > I guess I want to understand the risk as much as possible and=20 > mitigate against tampering as much as possible without designing the=20 > requirement for some guy to sit in front of the box with a gun :) >=20 > With respect to prepending a random salt to the image, can you expand=20 > what you mean ? >=20 It means that every time you want to checksum it, you send some random bits to be prepended to the image, then compute the checksum(s). You then do the same (with the same salt) on a trusted host and compare the results. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --IbA9xpzOQlG26JSn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEtAtJqRfpzJluFF4RAjDQAJ9gguSZD27JPnOvhi8ZQyeIq6Q86ACfU94t OqEG6ZnP18iNNAX/8u7PbTo= =RERb -----END PGP SIGNATURE----- --IbA9xpzOQlG26JSn-- From owner-freebsd-security@FreeBSD.ORG Tue Jul 11 20:45:29 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 0846116A4E8 for ; Tue, 11 Jul 2006 20:45:29 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30304.mail.mud.yahoo.com (web30304.mail.mud.yahoo.com [68.142.200.97]) by mx1.FreeBSD.org (Postfix) with SMTP id 9B70643D7E for ; Tue, 11 Jul 2006 20:45:21 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 80200 invoked by uid 60001); 11 Jul 2006 20:45:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0a97r0Y8dO2mXS56pB2EH/zG9PhWrurxD++jouifTKSZOIvNT1t6Aa7J1YMGWPutUz56v6kUGhySWAC0CzKRiPav7nyWO/vK1w7MzYiP1nO8tQ5Tk03ndiuF/jzFCNfNPPvdY5Js2DN9w0ShzGAWU06G+xY6mE3kfwmUIuF6q9Q= ; Message-ID: <20060711204521.80198.qmail@web30304.mail.mud.yahoo.com> Received: from [213.54.82.225] by web30304.mail.mud.yahoo.com via HTTP; Tue, 11 Jul 2006 13:45:21 PDT Date: Tue, 11 Jul 2006 13:45:21 -0700 (PDT) From: "R. B. Riddick" To: Poul-Henning Kamp , Mike Tancsa In-Reply-To: <77192.1152649343@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-security@freebsd.org Subject: Re: Integrity checking NANOBSD images X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 20:45:29 -0000 --- Poul-Henning Kamp wrote: > Arming a trojan to just do 'sleep 145 ; echo "sha256 = 0248482..."' > when you thing you're running sha256 would be trivia. > But what if the trojan copies its files to the RAM disc and waits for this sha256 binary showing up? And then, when it is there, it removes its changes on the hard disc (those changes certainly must be in unused (formerly zeroed) areas of the hard disc or in the (zeroed) end of certain shell scripts... Or do I miss something? Wasn't is usual some years ago to switch the boot disc hardware to "read only" mode? I dont know how to do that, but my source seemed to be trustworthy (although I never saw him - I just heard his voice...)... ;-)) A switch like on those 1.44'' floppy discs would be good... But then software/OS updates would require physical access to the box... -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-security@FreeBSD.ORG Tue Jul 11 20:50:15 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 E7D3E16A4E0 for ; Tue, 11 Jul 2006 20:50:15 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F16743D60 for ; Tue, 11 Jul 2006 20:50:10 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id B96CA1703F; Tue, 11 Jul 2006 20:50:08 +0000 (UTC) To: "R. B. Riddick" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 11 Jul 2006 13:45:21 MST." <20060711204521.80198.qmail@web30304.mail.mud.yahoo.com> Date: Tue, 11 Jul 2006 20:50:08 +0000 Message-ID: <79705.1152651008@critter.freebsd.dk> Cc: freebsd-security@freebsd.org Subject: Re: Integrity checking NANOBSD images X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 20:50:16 -0000 In message <20060711204521.80198.qmail@web30304.mail.mud.yahoo.com>, "R. B. Rid dick" writes: >Wasn't is usual some years ago to switch the boot disc hardware to "read only" >mode? Some CF cards have that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-security@FreeBSD.ORG Tue Jul 11 20:52:33 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 8A21716A4E6; Tue, 11 Jul 2006 20:52:33 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1568C43D58; Tue, 11 Jul 2006 20:51:56 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k6BKpptv000477; Tue, 11 Jul 2006 16:51:51 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3P/8.13.3) with ESMTP id k6BKptkk059706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jul 2006 16:51:55 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.3.4.0.20060711164431.04bd00f8@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 11 Jul 2006 16:52:11 -0400 To: Ruslan Ermilov From: Mike Tancsa In-Reply-To: <20060711203417.GJ56190@ip.net.ua> References: <44B4010E.7010809@mac.com> <77121.1152648353@critter.freebsd.dk> <6.2.3.4.0.20060711161049.04bd37a0@64.7.153.2> <20060711203417.GJ56190@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Status: Clean Cc: freebsd-security@freebsd.org, Poul-Henning Kamp Subject: Re: Integrity checking NANOBSD images X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 20:52:33 -0000 At 04:34 PM 11/07/2006, Ruslan Ermilov wrote: > > > > > With respect to prepending a random salt to the image, can you expand > > what you mean ? > > >It means that every time you want to checksum it, you send some >random bits to be prepended to the image, then compute the >checksum(s). You then do the same (with the same salt) on a >trusted host and compare the results. OK, but that implies I have a copy of the image locally. We do on occasion make modifications to the config in the field, and sending back a 512MB image over dialup would be difficult for this deployment. ---Mike From owner-freebsd-security@FreeBSD.ORG Tue Jul 11 20:52:50 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 2A35516A505 for ; Tue, 11 Jul 2006 20:52:50 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30313.mail.mud.yahoo.com (web30313.mail.mud.yahoo.com [68.142.201.231]) by mx1.FreeBSD.org (Postfix) with SMTP id 5F58143D69 for ; Tue, 11 Jul 2006 20:52:14 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 16996 invoked by uid 60001); 11 Jul 2006 20:52:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Rm6OLpfRinnzSIHrhnA1Xv2bFnWZg9f7Uofy5PuAdamb20DfTxw01m32xpi5Ff1pRsJYYnEnkuaeRTBYaQCWh/1aGULIxafG4kdSqGbWNt4PPiWozx9YKKcpsV/uCIpOUFW/gMEQ0M/oqZ33BIM1N2lOCteyQyXXmqigguVDtg0= ; Message-ID: <20060711205213.16994.qmail@web30313.mail.mud.yahoo.com> Received: from [213.54.82.225] by web30313.mail.mud.yahoo.com via HTTP; Tue, 11 Jul 2006 13:52:13 PDT Date: Tue, 11 Jul 2006 13:52:13 -0700 (PDT) From: "R. B. Riddick" To: Chuck Swiger , Poul-Henning Kamp In-Reply-To: <44B408E7.8070000@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-security@freebsd.org Subject: Re: Integrity checking NANOBSD images X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 20:52:50 -0000 --- Chuck Swiger wrote: > That suggestion is a very good point, although trying to find a single > trojaned image which matches several checksum methods is supposed to be a > highly difficult task. > If the hash function is cryptographically secure, even a single such hash function/method should be enough... Although there is this birthday paradoxon (or what it is called in english): IIRC it is about 23 people in a room and astonishingly the probability that 2 of them have the same birthday is more or equal to 0.5 under certain simplifying assumptions (e. g. that there are so many people from which the sample can be taken (I mean: A world with only 23 people, which have pairwise different birthdays would be unsuitable for that probabilistic experiment))... But your multi-hash-method idea has still the problem, that the trojan could just send the expected hash values after some delay... -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-security@FreeBSD.ORG Tue Jul 11 20:59:20 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 57B1A16A535 for ; Tue, 11 Jul 2006 20:59:20 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE7DE43EA6 for ; Tue, 11 Jul 2006 20:58:20 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k6BKvYG7000725; Tue, 11 Jul 2006 16:57:34 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3P/8.13.3) with ESMTP id k6BKvcaZ059728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jul 2006 16:57:38 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.3.4.0.20060711165223.04bce500@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 11 Jul 2006 16:57:55 -0400 To: "R. B. Riddick" , Poul-Henning Kamp From: Mike Tancsa In-Reply-To: <20060711204521.80198.qmail@web30304.mail.mud.yahoo.com> References: <77192.1152649343@critter.freebsd.dk> <20060711204521.80198.qmail@web30304.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Status: Clean Cc: freebsd-security@freebsd.org Subject: Re: Integrity checking NANOBSD images X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 20:59:20 -0000 At 04:45 PM 11/07/2006, R. B. Riddick wrote: >--- Poul-Henning Kamp wrote: > > Arming a trojan to just do 'sleep 145 ; echo "sha256 = 0248482..."' > > when you thing you're running sha256 would be trivia. > > >But what if the trojan copies its files to the RAM disc and waits for this >sha256 binary showing up? And then, when it is there, it removes its >changes on >the hard disc (those changes certainly must be in unused (formerly zeroed) >areas of the hard disc or in the (zeroed) end of certain shell >scripts... Or do >I miss something? Yes, sounds possible. Between checks, "undo" the trojan. However, the binary would have to live somewhere on the flash or it would not survive reboots and you would have to tinker with the bootup process to load the trojan at boot time. >Wasn't is usual some years ago to switch the boot disc hardware to "read only" >mode? I dont know how to do that, but my source seemed to be trustworthy >(although I never saw him - I just heard his voice...)... ;-)) > >A switch like on those 1.44'' floppy discs would be good... >But then software/OS updates would require physical access to the box... For this app, the problem is that there might indeed be physical tampering with the box despite some reasonable efforts to lock it up. From owner-freebsd-security@FreeBSD.ORG Tue Jul 11 21:08:56 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 5573816A4E1 for ; Tue, 11 Jul 2006 21:08:56 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30303.mail.mud.yahoo.com (web30303.mail.mud.yahoo.com [68.142.200.96]) by mx1.FreeBSD.org (Postfix) with SMTP id C562C43D6A for ; Tue, 11 Jul 2006 21:08:55 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 972 invoked by uid 60001); 11 Jul 2006 21:08:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YhuLRP15tw9VYlLeGwZN0ksbamcM5i7W3O13Rb4sEKlAmsbsBA3YB70z2tXocuXQ+K1UarZNLXswrCtK+iQ1FLbQWVg/5Wh4C5wUj1KO7dl+P4N7AjK5gshKdpvyzkANEJNakaGVhQxuHCJ5gyKd3+saBNI9+sxxYj9tg0Kr/is= ; Message-ID: <20060711210855.970.qmail@web30303.mail.mud.yahoo.com> Received: from [213.54.82.225] by web30303.mail.mud.yahoo.com via HTTP; Tue, 11 Jul 2006 14:08:55 PDT Date: Tue, 11 Jul 2006 14:08:55 -0700 (PDT) From: "R. B. Riddick" To: Mike Tancsa , Poul-Henning Kamp In-Reply-To: <6.2.3.4.0.20060711165223.04bce500@64.7.153.2> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-security@freebsd.org Subject: Re: Integrity checking NANOBSD images X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 21:08:56 -0000 --- Mike Tancsa wrote: > >But what if the trojan copies its files to the RAM disc and waits for this > >sha256 binary showing up? And then, when it is there, it removes its > >changes on > >the hard disc (those changes certainly must be in unused (formerly zeroed) > >areas of the hard disc or in the (zeroed) end of certain shell > >scripts... Or do > >I miss something? > > Yes, sounds possible. Between checks, "undo" the trojan. However, > the binary would have to live somewhere on the flash or it would not > survive reboots and you would have to tinker with the bootup process > to load the trojan at boot time. > Yes, that is what I mean with "unused" areas... I think many scripts in /etc/rc.d have some space in their end, that is zeroed and unused... So you just have to record their original size... Then u add some trojan software stuff in some start shell script function and u r done (of course those changes must be made, after the check sum procedure is over...; and must be undone before every check sum procedure)... Maybe we should try to make the box physically safer... By an sabotage detection unit... Infrared scanner or ultra-sound movement scanner or so... -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-security@FreeBSD.ORG Tue Jul 11 21:22:42 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 6E3D116A4DE for ; Tue, 11 Jul 2006 21:22:42 +0000 (UTC) (envelope-from jmb@bresler.org) Received: from alnrmhc11.comcast.net (alnrmhc14.comcast.net [204.127.225.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5052143D72 for ; Tue, 11 Jul 2006 21:22:36 +0000 (GMT) (envelope-from jmb@bresler.org) Received: from newgate.bresler.org (bresler.org[68.34.41.237]) by comcast.net (alnrmhc14) with ESMTP id <20060711212235b14002jt8ge>; Tue, 11 Jul 2006 21:22:35 +0000 Received: by newgate.bresler.org (Postfix, from userid 10001) id 0692F25B17; Tue, 11 Jul 2006 17:22:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by newgate.bresler.org (Postfix) with ESMTP id F3F7722979; Tue, 11 Jul 2006 17:22:34 -0400 (EDT) Date: Tue, 11 Jul 2006 17:22:34 -0400 (EDT) From: Jonathan M Bresler To: Mike Tancsa In-Reply-To: <6.2.3.4.0.20060711165223.04bce500@64.7.153.2> Message-ID: <20060711170817.X94314@newgate.bresler.org> References: <77192.1152649343@critter.freebsd.dk> <20060711204521.80198.qmail@web30304.mail.mud.yahoo.com> <6.2.3.4.0.20060711165223.04bce500@64.7.153.2> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-security@freebsd.org, Poul-Henning Kamp , "R. B. Riddick" Subject: Re: Integrity checking NANOBSD images X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 21:22:42 -0000 > >A switch like on those 1.44'' floppy discs would be good... > >But then software/OS updates would require physical access to the box... > > For this app, the problem is that there might indeed be physical > tampering with the box despite some reasonable efforts to lock it up. If the box is subject to tampering and not in a tamper-proof container, then it may be impossible to know whether or not the device has been tampered with or modified. seems to me that it would be possible to replace the device with one that emulates its behavior or rather intercepts connections (using the same ssh keys copied from the device) and relays the data on to the device, relaying responses back to you, all the while copying the cleartext data stream to another device. perhaps, you might consider setting it up so that if the box is opened the flash is zapped. > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > From owner-freebsd-security@FreeBSD.ORG Fri Jul 14 17:47:39 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 B4A1916A4DE; Fri, 14 Jul 2006 17:47:39 +0000 (UTC) (envelope-from ari@suutari.iki.fi) Received: from pne-smtpout3-sn1.fre.skanova.net (pne-smtpout3-sn1.fre.skanova.net [81.228.11.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 216FF43D70; Fri, 14 Jul 2006 17:47:38 +0000 (GMT) (envelope-from ari@suutari.iki.fi) Received: from mato.suutari.iki.fi (80.222.160.17) by pne-smtpout3-sn1.fre.skanova.net (7.2.075) id 44A130990008CC95; Fri, 14 Jul 2006 19:47:37 +0200 Received: from [127.0.0.1] (raisa.suutari.iki.fi [192.168.60.100]) by mato.suutari.iki.fi (8.13.6/8.13.6) with ESMTP id k6EHlYp7047998; Fri, 14 Jul 2006 20:47:34 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Message-ID: <44B7D8B8.3090403@suutari.iki.fi> Date: Fri, 14 Jul 2006 20:47:36 +0300 From: Ari Suutari User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: freebsd-pf@freebsd.org, freebsd-security@freebsd.org References: <44B7715E.8050906@suutari.iki.fi> <20060714154729.GA8616@psconsult.nl> In-Reply-To: <20060714154729.GA8616@psconsult.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0628-5, 14.07.2006), Outbound message X-Antivirus-Status: Clean Cc: Subject: Re: Any ongoing effort to port /etc/rc.d/pf_boot, /etc/pf.boot.conf from NetBSD ? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2006 17:47:39 -0000 Hi, [I have added freebsd-security to recipient list as I consider this issue a security risk] Paul Schenkeveld wrote: > Hello, > > On Fri, Jul 14, 2006 at 01:26:38PM +0300, Ari Suutari wrote: >> Hi, >> >> Does anyone know if there are any plans to bring >> pf boot-time protection (ie. /etc/rc.d/pf_boot and >> related config files) from NetBSD to FreeBSD ? >> >> This would close small (but as far as I understand existing) >> window during boot where firewall is fully open (if using only >> pf). > > I'd prefer to have PF_DEFAULT_BLOCK analogous to IPFILTER_DEFAULT_BLOCK > instead of some magic script closing the hole between driver init and > configuration. Always wondered how the OpenBSD -securety minded- people > have come up with a packet filter that's open by default. There has been discussion about this before. I know that perfect solution would be PF_DEFAULT_BLOCK, but while waiting for that I wonder why we cannot have pf_boot, which closes the boot hole (at least when run with proper filter rules). I would suggest: - first port pf_boot which brings us to same level of security as OpenBSD & NetBSD. - then, work with PF authors to get PF_DEFAULT_BLOCK if it still seems necessary. As pf becomes more and more popular on FreeBSD I see current state of system as security risk (ie. I won't use pf + FreeBSD on company firewalls although I would otherwise like to). Ari S.