bugGNU GRUB - Bugs: bug #33229, Truecrypt System Volume Header...

 
 

You are not allowed to post comments on this tracker with your current authentification level.

bug #33229: Truecrypt System Volume Header gets overwritten

Submitted by:  Patrick <p55>
Submitted on:  Wed 04 May 2011 04:13:34 PM UTC  
 
Category: Disk & PartitionSeverity: Major
Priority: 5 - NormalItem Group: Action Request
Status: NonePrivacy: Public
Assigned to: NoneOriginator Name: Patrick55
Open/Closed: OpenRelease: 
Release: otherReproducibility: Every Time
Planned Release: None

(Jump to the original submission Jump to the original submission)

Sun 03 Nov 2013 02:28:45 AM UTC, comment #9:

Going through this, this patch probably doesn't work for following reason:
When you install GRUBfor the first time it works since it correctly detects the truecrypt loader, however on second install there is no truecrypt loader to detect, so volume header gets nuked.

Vladimir Serbinenko <phcoder>
Project Administrator
Wed 11 May 2011 03:26:02 PM UTC, comment #8:

Postponing until after 1.99 since (a) patch is for outdated version (b) (most important) changes to this code are dangerous and error-prone.

Vladimir Serbinenko <phcoder>
Project Administrator
Wed 04 May 2011 08:47:32 PM UTC, comment #7:

@Vladimir

> if truecrypt bootloader is in MBR then the user explicitely requested us to replace it. So such check is redundant.


Sorry my bad. Propper explanation: It's not the Bootloader that I want to protect, but only the "Volume Header"
http://www.truecrypt.org/docs/volume-format-specification

I want to replace the TrueCrypt bootloader because I don't want to be forced to press the escape key to boot linux. :-)

But for windows AND linux versions of the truecrypt gui application (you can mount windows drives under linux as well), sector 62 needs to stay in place because it holds the (encrypted) master encryption key for the truecrypt "System Volume".

The truecrypt bootloader of course also needs the volume header but i can "chainload" the bootloader. I store /tcloader -- a multiboot compilant binary -- on the windows boot partition and then do "multiboot (hd0,msdos1)/tcloader".

http://gitorious.org/grub2tc/grub2tc/blobs/master/README

Once the truecrypt boot loader is up it asks for the password. In case the volume header (sector 62) is not there it will fail though: "Wrong password or not a TrueCrypt Volume" ...

Patrick <p55>
Wed 04 May 2011 08:36:05 PM UTC, comment #6:

Patch tested, works fine for me.

The next problem i have is again with grub: Why is it not possible to have "menuentry"s in a embedded config files (in core.img) ???

I totally didn't expect that this wouldn't be possible. Should have read the last sentence in the docu earlier. It's just that I fail to understand why it's not possible. I wanted to install grub with an embedded config and display a menu "Windows/Linux". Then when I choose linux, use "set root=(linux); configfile grub.cfg" and for windows use a different root. The linux root can't be on a windows drive and vice versa because i run one operating system natively and the other virtual. In the Windows VNative case I use VMWare Player and it will not let Linux Virtual (grub) access sectors on a disk that is in use by Windows. Qemu-kvm which I use for Linux Native doesn't have that "problem" but I actually would rather like to avoid accessing mounted filesystems there as well. Which means either unmounting /boot, booting Windows Virtual, mounting /boot again OR having grub not access the files in /boot in the first place by using an embedded "Windows/Linux" selection menu. Which brings us back to the original question.

Patrick <p55>
Wed 04 May 2011 07:15:56 PM UTC, comment #5:

Thanks for the reply Vladimir.

Agree, the data doesn't belong there.

Still then I already crafted a patch by now. Will post as soon as it's fully tested.

I am not in the mood to hack Truecrypt at the moment. :-) It would be too time-consuming now for me to set up the environment. But of course the System Volume Header should probably go somewhere else.

Btw the infrastructure i was talking about is found in a debian patch in http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/natty/grub2/natty . Not sure if it's in gnu's trunk. I couldn't really make use of it because the Truecrypt signature and the affected sector live in different areas of the disk.

Patrick <p55>
Wed 04 May 2011 06:00:49 PM UTC, comment #4:

if truecrypt bootloader is in MBR then the user explicitely requested us to replace it. So such check is redundant.

Vladimir Serbinenko <phcoder>
Project Administrator
Wed 04 May 2011 04:54:08 PM UTC, comment #3:

I didn't find a solution yet. The existence of the truecrypt header would be very probably if the truecrypt bootloader was installed in the mbr. This would be easy to detect... I think this would make sense to check for it's signature in the mbr (in an area not used by grub, right in the first few bytes, there is the string "TrueCrypt"). I'm going to try it that way.

Patrick <p55>
Wed 04 May 2011 04:29:45 PM UTC, comment #2:

I consider this a bug in truecrypt. mbr gap is for usage exclusively by bootloader, not for storing keys. (Having TrueCrypt bootloader there is another story). Also the sector 62 is pretty loved by boot viruses and some malwarelike DRMware (e.g. FlexLM). MBR gap isn't for valuable data but only for system code.
BTW as to necessity of Reed-Solomon: it's necessary exactly because of malwarelike DRMware and misstorage controllers.

Vladimir Serbinenko <phcoder>
Project Administrator
Wed 04 May 2011 04:20:42 PM UTC, comment #1:

Oh. :-) 5 minutes after reporting I realize that the infrastructure is even already there. Impressive. Sadly the truecrypt header has no identifyable signature. It's 512 bytes of random data. (The first 64 bytes are random salt and the rest is encrypted with a key derived from that salt and a password the user is asked to enter...)

What can we do.... ?

Patrick <p55>
Wed 04 May 2011 04:13:34 PM UTC, original submission:

Truecrypt System Volume Header gets overwritten when you install grub on the master boot record of a hard disk with windows 7 installed and truecrypt full system disk encryption set up.

With system disk encryption the truecrypt volume header for the "system partition" - i.e. the one that holds C:windows - is written to the last (512 byte-) sector (62) of the "dos compatibility area" after the master boot record of the disk holding the "system partition". (The small 100mb partition in front of the system partition that windows creates as it's boot partition and where files like "bootmgr" reside is not encryptet, the system partition is usually the second of the four partitions defined in the mbr)

Reference: http://www.truecrypt.org/docs/encryption-scheme
-> point 2., 2nd sentence

I believe this would not really be necessary. The core.img produces by grub-mkimage is usually smaller than 61 sectors. It just gets bloated by the grub_reed_solomon_add_redundancy() function in grub-setup.c

My idea is to modify the pc_partition_map_embed() function to not include sector 62 of the disk - at least not if the offset of the first partition is more than 63 sectors (2048 typically) anyway.

I will try to come up with some patch to implement this functionality.

Suggestions, warnings & wishes are welcome.

Patrick <p55>

 

Attached Files
file #23352:  grub-setup-tcsave.diff added by p55 (867B - text/x-patch - improved warning message)
file #23351:  grub-setup-tcsave.diff added by p55 (847B - text/x-patch - Spare the TrueCrypt System Volume Header in sector 62)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by phcoder (Posted a comment)
  • -unavailable- added by p55 (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 04 May 2011 08:54:29 PM UTCp55Attached File-=>Added grub-setup-tcsave.diff, #23352
    Wed 04 May 2011 08:22:52 PM UTCp55Attached File-=>Added grub-setup-tcsave.diff, #23351

    Back to the top


    Powered by Savane 3.1-cleanup