Re: Undetectable Rootkits using Virtualization

[Paul E Condon <pecondon@xxxxxxxxxxxxxxxx>]

On Sat, Jul 01, 2006 at 06:27:49PM -0600, Neal McBurnett wrote:
> On Fri, Jun 30, 2006 at 10:07:15AM -0600, Paul E Condon wrote:
> > 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.
> 
> Unfortunately, this is not true given that the BIOS itself can be
> reflashed on all or most of the systems out there.  And control of
> bios can lead to control of the higher-level functions of the
> computer.  This was the central finding of the "Hursti II" report that
> I forwarded a few weeks ago.
> 
>  http://www.nytimes.com/2006/05/12/us/12vote.html
>  http://www.bbvforums.org/cgi-bin/forums/board-auth.cgi?file=/1954/27675.html
>  http://www.blackboxvoting.org/BBVtsxstudy.pdf
> 
> And even in the absence of a BIOS takeover, novel rootkits or other
> attacks on the operating system or application software might excape
> detection by existing forensic test beds.  Especially when the people
> doing the forensic analysis have as little experience as the typical
> county clerk....
> 

I certainly had no intention of implying that county clerks were, or could
ever be, competant to do to kind of forensics that I envisioned. I think it
is not good to say something is impossible. 

Saying that a project is not feasible has had very little traction in
the political discussion of a missle defense system. It is better, in
my opinion, to discuss realistically what is required, and then put a
price on doing it, and then decide whether some other way of voting is
cheaper as well as better, e.g. hand counted paper ballots or
something else not currently being discussed.

As to BIOS takeover: the chip in which it is recorded can be removed from the
motherboard and its contents read in a chip reader. There must be a master
copy of what should be on that chip, and that master copy must be available to
the investigators. Any difference between the official master copy and the

chip contents is pretty good evidence of tampering, in my opinion. 

The motherboard can be electrically checked for tampering, etc. 

'Good enough for gumint work' really isn't good enough.

I repeat, we need to really sweat the details, or at least, find people who 
are sweating the details and read and publish their findings.

The hot links you gave show that there is a serious problem, but not serious
enough to simply give a luddite 'no' at this time.

I hope that the 'authorities' take the results you cite seriously enough to
start being nasty about claims of the proprietary nature of the software. 
It needs to be Open, with a real capital O. Published on the web, with 
published MD5s, etc. 

One approach to the problem would be to have the whole design of voting
machines given over to NTIS. Manufacturers could build to the NTIS drawings,
and load the box with NTIS software. NTIS is charged with producing a secure
design which includes serious test points for electrical test discovery
of tampering. If NTIS is slow in producing, we use paper in the interim.

Your third hotlink contains a very interesting report which has a
number of redactions, and a request to refrain from speculation that
contains 'inappropriate technical details'. But the report makes it pretty
clear that there is a serious security problem within the context of 
current conventional wisdom as to what is 'fair' in bashing commercial
products.  It appears, from my reading of press reports, that many 
clerks hope to use these systems this year with only paliative measures.
Would breaking the silence of redaction help keep them from doing this?
Where is our Daniel Elsworth?

-- 
Paul E Condon           
pecondon@xxxxxxxxxxxxxxxx