Secure the MBR, Solution here .....

Secure the MBR from overwriting.

Yes indeed folks, it appears you can, with a little, err, lot of help from Peter Kleissner.

He's done it to help secure Truecrypt, but it must also help prevent nasty Malware writes to the MBR too ?

I'm not sure how to apply this patch, so if anyone can explain that would be nice.


"My “SecureTrueCrypt” patch to secure TrueCrypt: http://peterkleissner.com/?p=11


Thanx Pete.

 

With any Linux Live CD, you can issue the dd command to copy the MBR to an output filename. I have both of my main (WinXP, Linux) MBRs stored on my Linux disk in a subdirectory of my home account - accessible easily from the Live CD environment, and I already had to use it once to replace the WinXP hard drive's MBR to correct a problem.

The output file of the dd command of the full MBR's contents can easily be stored on any other available media, e.g. floppy, CD, etc.

Example: Note: the first 1024 bytes contains the partition table and boot record for the drive /dev/hda
1) To save the MBR
# dd if=/dev/hda of=/tmp/stuff bs=1k count=1
2) To replace the MBR
# dd if=/tmp/stuff of=/dev/hda bs=1k count=1

If the file /tmp/stuff becomes garbage, replacing it back into the MBR will hose the MBR.

Instead of /tmp/stuff, use a new directory, and prefer a file name that identifies what the MBR file is, /MBRs/hdambr instead of using /tmp/stuff from the examples, and don't forget to change the names when you issue the dd commands for real. Better yet, format and store the file to a USB flash drive for easy access from a Live CD environment or USB flash drive bootable environment.

-- Tom

 

hohoho, very keen and cheeky no response so far?

 

Well if you need a reply, the author uses provocative title to evoke responses. What the TrueCrypt guys say is correct - once you have access to the computer locally, game over. And it's true.

As to attacks against TC and anything else - don't get crap installed on your machine and you won't have any attacks. Pure and simple.

Mrk

 

No the only true and bulletproof concept has to be: work secure even in a infected environment.

 

Airflow, take whatever you want. Work secure in infected environment, gimme a break, please. There is thing why executables files are called executable, it's the fact that they need to be executed to execute, hence keep you trigger finger off the mouse and don't click to install crap and you work securely in non-infected environment. Pure magic.
Mrk

 

Encryption is only as secure as the computer it's installed on. There's too much emphasis put on the strength of the encryption algorithm and the encryption software itself. The weak link, the OS itself needs to be equally secure. One missed keylogger, trojan, or rootkit defeats encryption.

The link isn't describing a TrueCrypt problem. It's describing a security policy that's inadequate for the situation. Any PC containing data sensitive enough to require the use of strong encryption should be completely locked down, not running some run of the mill default-permit based security package.

 

Mrkvonic and noone_particular already said it better than I could. They're absolutely right. Encryption doesn't help if the system is infected with something when the user decrypts whatever they had been trying to protect with encryption. Sure, if you never decrypt what you had encrypted - say a file called my_password.txt - then it's fairly impossible for any malware infection to steal that encrypted data in readable form. But if you do decrypt it while the malware is running - or in this case, when something has written itself into your MBR - then the encryption is helpless from that point on.

People who suggest TrueCrypt could do something to completely prevent attacks like this are dreaming, and just do not understand the issue. Don't give malware admin privileges and they can't do anything to your MBR. If you want to give malware admin privileges, don't act surprised and disappointed when it can do anything. That's what admin privileges are for - being able to do anything, with practically no limits. No matter how many bandaids and "fixes" to third party software one installs, admin privileges are still admin privileges, and once a malware gets them, then it can do anything. And don't give people you don't trust physical access to your PC. If you do, then there's all kinds of nastiness they can pull - like, say, just stealing your entire computer, which to me would be a lot more annoying than a silly trick like this "BootKit." Run as a limited user, and physically secure the system, and this is not an issue.

 

What we need is something between admin and non-admin, a installation mode.

 

You have rings 1 and 2 and they are not used, except on OS/2.
Mrk