From owner-freebsd-security@FreeBSD.ORG Wed Nov 8 04:19:45 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 CB69A16A415 for ; Wed, 8 Nov 2006 04:19:45 +0000 (UTC) (envelope-from wes@opensail.org) Received: from softweyr.homeunix.net (cpe-24-161-160-202.san.res.rr.com [24.161.160.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8096843D53 for ; Wed, 8 Nov 2006 04:19:43 +0000 (GMT) (envelope-from wes@opensail.org) Received: from [204.68.178.34] (gulliver.softweyr.com [204.68.178.34]) (authenticated bits=0) by softweyr.homeunix.net (8.13.6/8.13.6) with ESMTP id kA84JeKC017973 for ; Tue, 7 Nov 2006 20:19:42 -0800 (PST) (envelope-from wes@opensail.org) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <20061104163000.30D2516A7A6@hub.freebsd.org> References: <20061104163000.30D2516A7A6@hub.freebsd.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0C344F30-40A1-4B08-A1C7-3F8CD536244D@opensail.org> Content-Transfer-Encoding: 7bit From: Wes Peters Date: Tue, 7 Nov 2006 20:19:40 -0800 To: freebsd-security@freebsd.org X-Mailer: Apple Mail (2.752.2) X-Scanned-By: MIMEDefang 2.57 on 204.68.178.2 Subject: Re: freebsd-security Digest, Vol 184, Issue 2 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: Wed, 08 Nov 2006 04:19:45 -0000 On Nov 4, 2006, at 8:30 AM, Wesley Shields wrote: > > On Fri, Nov 03, 2006 at 07:54:59AM -0800, Ricardo A. Reis wrote: > [...] >> In the II COLARIS - Joanna Rutkowska alert the possible >> new technology of Malware's using hardware virtualization, present >> in AMD and INTEL new processor. >> >> I've two questions ... >> >> 1) How is possible detect if my system is moved inside a VM on the >> fly ? > > She has discussed various solutions for this problem, and why she > believes they may or may not work. The one most people suggest is to > time how long it takes for various instructions to run, but this > can be > tricked by the VMM-rootkit. I'd suggest reading: > > http://theinvisiblethings.blogspot.com/2006/08/blue-pill- > detection.html One thing that leaps immediately to mind is a startup check to see if this 'dmesg.boot' differs from the previous one. Rather than overwriting the previous one, move it to a backup, create the new one, and log something if they differ. I hacked this up in a couple of minutes: --- /etc/rc.d/dmesg Sat May 6 21:00:26 2006 +++ dmesg Tue Nov 7 20:17:47 2006 @@ -19,8 +19,10 @@ do_dmesg() { - rm -f ${dmesg_file} + mv -f ${dmesg_file} ${dmesg_file}.prev ( umask 022 ; /sbin/dmesg $rc_flags > ${dmesg_file} ) + cmp -s ${dmesg_file} ${dmesg_file}.prev || \ + logger -p security.warn 'dmesg.boot changed from previous boot' } load_rc_config $name If you like that, I'm willing to discuss it further, and/or commit it and let the howling tell if it's a keeper or not. ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com