Message-ID: <4A7FF65A.9010108@gmx.de>
Date: Mon, 10 Aug 2009 12:28:42 +0200
From: Marc Ballarin <Ballarin.Marc@gmx.de>
MIME-Version: 1.0
References: <20090808132614.GA29656@fancy-poultry.org>	<4A7D91A8.5080902@gmx.de>	<20090808153635.GA31434@fancy-poultry.org>	<20090810061245.GA9508@maude.comedia.it>
	<20090810071046.GA7462@fancy-poultry.org>
In-Reply-To: <20090810071046.GA7462@fancy-poultry.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dm-crypt] LUKS/dm-crypt vulnerable?
To: dm-crypt@saout.de

Heinz Diehl schrieb:

> ..which is not true, of course. I can e.g. have a copy of the boot
> sector/MBR on a memory stick, together with a checksum file of /boot.
> Copying the first 512 bytes and checking it against the checksum of the
> known good bootsector on the memory stick will detect any manipulation immediately.
> A simple "dd if=mbr_copy of=/dev/sda bs=512 count=1" will cure the problem.

If the integrity of the system is compromised this won't help.

What if the trojan itself did "an dd if=/dev/sda of=hidden_mbr_copy..." 
and redirected all future read-access to the original MBR to this backup 
file?

The same would be true for manipulated kernels. They could keep the 
original kernel image in a hidden file and redirect all system calls 
aimed on the manipulated image to this good image.
Alternatively they could simply manipulate md5sum, sh1sum or whatever 
and add logic like:
if filename==name of corrupted kernel
   print md5 of good kernel
else
   print true md5

Only booting from a trustworthy medium would help and the same is true 
in the case of truecrypt.


Marc