On Nov 4, 2006, at 8:30 AM, Wesley Shields <wxs@atarininja.org> 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.htmlOne 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
On Nov 7, 2006, at 11:22 PM, Alexander Leidinger wrote:> Quoting Wes Peters <wes@opensail.org> (from Tue, 7 Nov 2006 > 20:19:40 -0800): > >> --- /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. ;^) > > Did you try this? I didn't, but I would expect to see this message > _every time_ (because of minor timecounter rate changes).Yes, but only once, and then forced a change by re-running it. Maybe I just got 'lucky.' Feel free to suggest 'better' tests, or parts to throw out of dmesg.boot before the test. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com
Quoting Wes Peters <wes@opensail.org> (from Tue, 7 Nov 2006 20:19:40 -0800):> --- /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. ;^)Did you try this? I didn't, but I would expect to see this message _every time_ (because of minor timecounter rate changes). Bye, Alexander. -- In those days he was wiser than he is now -- he used to frequently take my advice. -- Winston Churchill http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Apparently Analagous Threads
- [PATCH] p2v: Send physical server 'dmesg' output to debug dir on conversion server.
- Reducing the need to compile a custom kernel
- [PATCH 0/3] p2v, v2v: Ensure the full version is always available in several places.
- Proper use of LD_LIBRARY_PATH for Linux progs?
- MOAB advisories