Re: Undetectable Rootkits using Virtualization

[Paul E Condon <pecondon@xxxxxxxxxxxxxxxx>]

More comments:

On Sun, Jul 02, 2006 at 12:28:29PM -0600, Pete Klammer wrote:
> Political technology is presently making the following a naïve assumption:
> 
> > But if one can physically remove the disk drive and investigate it on a
> proper forensic test bed, ...
> 
> Because the "trusted computing" initiatives spurred by corporate media thugs
> are forcing hardware vendors to embed cryptologically-secure "agents" into
> our PCs, below the BIOS, and into the hard drives themselves.
> 
> Read more at "http://arstechnica.com/news.ars/post/20060214-6178.html"; or
> Google for "trusted hard drive" yourself.  Consider this quote:
> 
> "The new hard drives will allow the creation of "trusted storage units,"
> areas of the drive where only approved applications will be able to read and
> write data." 
> 

I'm sure there are people who want badly to make this become a
reality, but the keys will have to be in the hands of the CIA, NSA,
FBI, and the Chinese govt.  And several other players on the
international technical scene. It will not work without it also being
known that it exists. So, it will not work as advertised, namely in
secret.

There will be a black market in hardware that is non-compliant with
the rules because it is manufactured according to old designs, and
then a second black market in hardware that is non-compliant, but
fakes compliance. (I don't intend to participate in any such market. I
just predict it will develop because of my understanding of human
nature.)

> So what is an "approved" application?  First of all, it's not the owner.
> Under this euphemistic "trusted computing" cover, your PC (or your voting
> system) can establish a cryptologically snoop-proof channel between the CPU
> and hard drive, and will be able to execute programs totally out of your
> view or control (beyond pulling the plug).  The "trusted computing module"
> can spy on your habits, can disable your programs or corrupt your data, and
> can "phone home" with encrypted reports whenever there's an internet
> connection available.  All beyond the reach of anti-malware or "forensic"
> tools.

Snoop-proof generally means that one can't read the data being
transfered by tapping into the channel, not that the fact of transfer
is entirely undetectable. You can know the transfer is happening, if only
because you can hear the clicks of disk seeks. If it matters to you, you
will be motivated to participate in the black market. Or you maybe won't
commit certain 'bad' thought to text files on your computer.

But I thought I made it clear that I was writing about technical possibility
of detecting malware, etc. I do not believe that detecting malware will ever
be easy for an individual working alone in his basement, or attic. 

> 
> So when you assert, "here no way malware can go undetected," I would say all
> you will be able to say is, "there's something there," but the vendors will

I think that detecting tampering will result in political action,
eventually. The system can be made to work.

> insist, "it's good for you, it's anti-virus, TRUST US!"
> 



> Who will hold the keys?

> 
> --
> Pete Klammer, P.E. / ACM(1970), IEEE, ICCP(CCP), NSPE(PE), NACSE(NSNE)
> 3200 Routt Street / Wheat Ridge, Colorado 80033-5452
> (303)233-9485 / Fax:(303)274-6182 / Mailto:PKlammer@xxxxxxx
>  "Idealism doesn't win every contest; but that's not what I choose it for."
> 
> 
> -----Original Message-----
> From: Paul E Condon [mailto:pecondon@xxxxxxxxxxxxxxxx] 
> Sent: Friday, June 30, 2006 10:07 AM
> To: cvv-discuss@xxxxxxxxxxxxxxxxx
> Subject: Re: Undetectable Rootkits using Virtualization
> 
> Root kit can be very hard to detect if one assumes that one must also
> keep the computer running while doing the investigation, or that there
> are limits imposed by owner privacy, or software vendor proprietary
> rights. But if one can physically remove the disk drive and
> investigate it on a proper forensic test bed, and if the design
> documentation of the manufacturer of the disk drive is available,
> there no way malware can go undetected.
> 
> I think that there is a real problem with software security on
> computers that are used in elections, but these problems would largely
> be resolved if the official record were the paper ballot as marked by
> the voter, and the computer use were confined to processing steps that
> could easily be repeated on different computers using different
> operating systems, and if this repeating were frequently done as a
> matter of course, not something confined to a court ordered recount.
> 
> But most of all, we should really 'sweat the details' of how the use
> of computers should be regulated and the regulations enforced. I see
> little room for proprietary, secret software in a realistic system.
> 
> 
> On Thu, Jun 29, 2006 at 11:19:09PM -0600, Joe Pezzillo wrote:
> > 
> > If you thought the security problems in existing systems were bad,  
> > check this out:
> > 
> > http://theinvisiblethings.blogspot.com/2006/06/introducing-blue- 
> > pill.html
> > 
> > 
> > "Now, imagine a malware (e.g. a network backdoor, keylogger, etc...)  
> > whose capabilities to remain undetectable do not rely on obscurity of  
> > the concept. Malware, which could not be detected even though its  
> > algorithm (concept) is publicly known. Let's go further and imagine  
> > that even its code could be made public, but still there would be no  
> > way for detecting that this creature is running on our machines...
> > 
> > Over the past few months I have been working on a technology code- 
> > named Blue Pill, which is just about that - creating 100%  
> > undetectable malware, which is not based on an obscure concept."
> > 
> > 
> > [Note: this is not a script kiddie writing this, it's a world-class  
> > security researcher who will be presenting her work at the Black Hat  
> > conference at the end of July, comments on the blog indicate that a  
> > similar exploit for Intel's virtualization technology is also going  
> > to be presented]
> > 
> > 
> 
> -- 
> Paul E Condon           
> pecondon@xxxxxxxxxxxxxxxx
> 

-- 
Paul E Condon           
pecondon@xxxxxxxxxxxxxxxx