Slashdot Mirror
Boot Record Rootkit Threatens Vista, XP, NT
Paul sends us word on a new exploit seen in the wild that attacks Windows systems completely outside of the control of the OS. "Unfortunately, all the Windows NT family (including Vista) still have the same security flaw — MBR [Master Boot Record] can be modified from usermode. Nevertheless, MS blocked write-access to disk sectors from userland code on VISTA after the pagefile attack, however, the first sectors of disk are still unprotected... At the end of 2007 stealth MBR rootkit was discovered by MR Team members (thanks to Tammy & MJ) and it looks like this way of affecting NT systems could be more common in near future if MBR stays unprotected."
That'd require changes to the partition table, which is protected from NT's usermode IIRC.
Yeah, like something that could fit in a 512 byte MBR...
Why bother?
That's what this does. It modifies the MBR to load the virus as a driver out of a pair of sectors.
This already does whatever it wants. And the "files open" comment is non-sensical, the pre-boot environment has no concept of "open files", it's just a little 512 byte loader.
There isn't much Windows (or any) OS can do when it isn't running.
If you read the article (it contains scary things like x86 assembly, I know, but you can skip that) you'd see that the describe this hooks into the load routines used by Windows. By intercepting these calls and redirecting them, it prevents you from overwriting the MBR or even detecting that it's changed (to a degree). To fix this you have to open a clean environment (like the recovery console off the Windows CD) and have it fix the MBR.
Amazing how even with all we've got, things go back to the same kind of viruses that were written back in the days of DOS 2.
I wonder if this would be so easily possible with EFI based booting. OS X uses it. Vista SP1 supports booting using EFI off disks don't partitioned with the old DOS partition format.
PS: Whoever modded the parent as informative either doesn't know what they're talking about, is drunk, or is in cahoots.
PPS: Sorry. I've been looking for an excuse to use the word "cahoots" all day.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Alright, I get the defense in depth concept, but I don't consider it to be a severe vulnerability that the MBR is writable while Windows is running. I consider that to be a feature, one I wish Microsoft did more of -- for example, I can install Linux from a Linux LiveCD, or I can install a second copy of it on another partition, etc. As far as I can tell, OS X is similarly flexible -- it forces you to type your password, but it can deliver a firmware update from within the OS -- think equivalent to a BIOS update, so even earlier than the MBR.
So, to clarify: It's writable from userland, which is not the same as being writable by any user. If they have Admin access (which means you already clicked a "This program wants to modify your Master Boot Record, are you sure?"), you're already screwed -- kind of like how, on Linux, if they have root, you're already screwed.
In other words, it's possible to modify your Master Boot Record without rebooting your computer. This is a good thing.
What's more, this is not new. All that's new is that it's both in the wild (Blue Pill does the same thing), and that it's a rootkit (MBR Viruses have been around for a very long time now). If someone was trying to apply for a patent, you'd be jumping all over them with prior art...
Don't thank God, thank a doctor!
Almost all BIOSes released in the past 5 years had MBR protection. Install your OS, turn on MBR protection and let the virus try.
I hated it at first, Linux installs failing as LILO not getting to write to the MBR until you turned it off.
Do not look at laser with remaining good eye.
... to write to the MBR.
For all other sectors Vista prevents writes to raw disk sectors even with admin permissions.
Users withouts admin permissions/without elevation cannot write to the MBR in Vista.
Yes. That's all LILO, GRUB, NTLDR, and such do. They call the BIOS functions to read partition tables and such, load code from a specific place, and execute it.
You could easily install LILO on the last sector of a disk (or anywhere else, just a free sector you can protect from being used). Write a little tiny program that does nothing but read that sector into memory (having known the address ahead of time, finding that code is what makes GRUB and NTLDR slightly more complex than this), and execute it. LILO would then continue having no idea what happened before it.
Amazing little things, boot loaders. Check out the Wikipedia article on Master Boot Records. They talk about NTLDR where until XP/2K (when it got support for non-english error messages), the code was just a scant 139 bytes.
Read about some of them. LILO is simple (and kind of stupid) and fits in 512 bytes. GRUB is smarter, and works by loading more code that it finds using it's first stage (which is under 512 bytes). It's a little tiny OS that only uses BIOS calls to load another OS. That's why you can edit entires, add new ones, etc. That couldn't fit in 512 bytes (and still be useful on most computers).
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
As I know, most 3rd party motherboards offer "anti-virus" or the "write protect MBR" options. Even if available I doubt they will work when using onboard RAID features.
Basically, you leaves these options off when installing the OS. Once you're finished, you can safely turn them on. I'm not sure how often NTFS needs access to the MBR, but I know I've never had trouble leaving these features enabled with FAT32.
Life is not for the lazy.
Two-word noun phrases are only hyphenated when used in adjective form. For instance:
Gamma rays are a type of ionizing radiation.
but
The gamma-ray burst released 4.3 blargajoules of energy.
Actually, it's a bit less. The first sector of a hard disk contains the MBR code and the partition table.
The partition table takes 64 bytes (16 bytes x 4 entries), and there's a two-byte signature that the BIOS checks to ensure the MBR is valid.
That gives you roughly 446 bytes of code that you can actually run. Most MBR code basically reads the partition table, finds a partition with the "active" flag set, then loads the first sector of that partition into memory. The partition loader then copies more sectors from disk so it can load the OS.
That's why you can install GRUB and LILO into either the partition or MBR. The MBR version basically overwrites the existing MBR to always load LILO or GRUB regardless of what the partition table says. The partition version relies on the MBR code passing it control.
Of course, having the first cylinder of a disk unused makes it convenient to stash away the extra code you need.
No. LILO, GRUB and (joking aside) the Microsoft bootloader are not malicious (the microsoft one is stupid, but not malicious). If the 512 bytes does something else - like, oh, jump to the main part of the virus stashed in the filesystem, then it's a problem. The real craziness here is windows letting userspace write to the MBR without so much as a "uh, you sure you want to do that?". It'll pop up 50 UAC requesters asking about trivialities, but when it comes to something that can totally hose your system's ability to restart in a fraction of a second? Not a peep.
Now, linux will actually let you do that as root, too, but not otherwise. The problem is most people run windows as the equivalent of root.
If a person wanted to be sure, couldn't you burn a boot loader onto a CD, have the CD boot first, and have that direct the loading? IANLWK (I am no Linux Whiz Kid), but in my imperfect knowledge of the world, that seems like it would completely defend against this type of attack. I yearn for correction of my ways if this wouldn't work.
Or better yet, a USB key - an key that lets you start your computer. No key, no start. Faster than a CD, no moving parts, etc. Me likes.
The cure is worse than the disease.
The real issue here is not whether an exploit like this would work with lilo or grub, the issue, as noted by TFA, is that "Unfortunately, all the Windows NT family (including VISTA) still have the same security flaw - MBR can be modified from usermode. Nevertheless, MS blocked write-access to disk sectors from userland code on VISTA after the pagefile attack, however, the first sectors of disk are still unprotected !"
Note: MBR can be modified from usermode, the first sectors of disk are still unprotected
Yikes!!!
I can't imagine that would make any difference. The computer needs to boot somehow, there are legitimate reasons for modifying the boot code (such as installing a new OS, or fixing flaws in it) so you can't just block it wholesale, and any program that runs at the boot stage will necessarily have complete control of your computer. About the best you can do is require the user to confirm before overwriting the MBR - something I thought windows already did (and if it doesn't, there's really no excuse for it not to) - but that's far from foolproof.
I think most modern Bios's have MBR/boot sector virus protection options. Basically you set the option in the BIOS and it either prevents MBR access (through the on-chip IDE controller, duno about off-board cards or scsi devices) or interrupts the system and displays an alert screen (similar to an overheat warning some do). To use it, you turn it off, install your OS with boot loader of choice, then go turn it on. Anything trying to write MBR data gets rejected or notifies you in pretty ASCII colors on screen with beeps. I know its prevented me from installing lilo a couple times.Tm
Support TBI Research: http://www.raisinhope.org
In all the years of virus hunting and gathering, /MBR in the startup sequence.
/MBR then turn it back on in the bios. )
I only got a boot sector virus once. Now, I just fdisk
I may have had anynumber of boot sector viruses. I dont know. They all disappear
before I have a chance to detect them.
Windows cannot protect the MBR if windows is running or not AND THEY SHOUDLNT.
Its really up to the hardware vendors.
Put it into BIOS or have a jumper on the drive.
( Simple effortless fix, vs MAJOR CLUSTER F*** )
( I used to turn it off, and then fdisk
I always thought it was a nice feature. Where the hell did it go?
I don't know about US usage, but in British usage there's no such rule, according to both Partridge's "Usage and Abusage" and Fowler's "Modern English Usage" (arguably two of the three most influential prescriptive grammars of the 20th century, the third being Fowler's "The King's English", which I don't have to hand).
As Partidge points out, "In the life of a compound word there are three stages: (1) two separate words (cat bird); (2) a hyphenated compound (cat-bird); (3) a single word (catbird)."
Apart from a few cases where the form is forced by a risk of ambiguity, whether a compound is hyphenated is determined by how far along that progression the compound has gone, and there is no rule to determine it. For example, in the same article Partridge uses "Dog-show" as a compound noun, thus hyphenated. And as an example of where a hyphen is forced, Partridge compares "The author's tense-sequence is defective in this passage" (see the hyphenated noun phrase used as a noun there?) with "A tense sequence of events succeeded a dull sequence". Clearly two-word noun phrases are not only hyphenated when used in adjective form.
So you're right that "grammar Nazi" does not have to be hyphenated, but for the wrong reason.
Quidnam Latine loqui modo coepi?
Whether EFI or BIOS, this is a (small) part of what TCPA is intended to defeat. The idea is that the EFI or BIOS hands a copy of the boot sector to the TPM before loading it, and the TPM hashes it into a state register. The boot sector code sends a copy of the boot loader code to the TPM for hashing before it loads, then the boot loader sends a copy of the OS kernel to the TPM before it loads, and so on.
Any piece of code along the way, or even user-level code after boot, can check the state register to decide if the boot code integrity is intact. Also, decryption keys can be bound to register states, so you can ensure that if malicious code does somehow get into the boot process, it cannot access data encrypted with those keys.
I fiddled for a while with a TPM-enabled GRUB to allow whole disk encryption keys (dm-crypt) to be bound to the boot state. It's a nice setup in that you have whole-disk encryption without having to enter a boot passphrase or attach a USB key or anything, and it ensures that any malicious modification of loader or kernel disables access to the data on the drive. Unfortuanately, it also loses access to the drive data when any non-malicious modification occurs. It's not terribly difficult to address that issue, but it really needs to be integrated into the package management system and thought through very carefully to ensure that no sort of failure during upgrade can leave your system inaccessible -- and yet the process must also not allow malicious code to do the same sort of "upgrades".
Of course, this is somewhat less of an issue on *nix, because write access to the MBR requires root privs.
One other thought about this situation: Although I'm generally a fan of TCPA for all of the good things it can be used for, I'm also leery of the evil that Microsoft can do with it. My paranoid side wonders if MS doesn't have a hand in this MBR virus -- and more to come -- as justification for pushing universal TPM deployment. TPMs are useful in machines that have high security requirements, but in consumer machines there's little value and lots of risk.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.