| |||||||||||||
Garrett: UEFI secure bootingGarrett: UEFI secure bootingPosted Sep 21, 2011 17:00 UTC (Wed) by imgx64 (guest, #78590)Parent article: Garrett: UEFI secure booting
I'm not really sure what's the point of this; it sounds more like a solution looking for a problem. What was the last significant malware that targeted the boot process? (I remember MBR viruses in the DOS days, are there any of those today?)
Admittedly, I don't have time to watch a 1-hour video by Microsoft engineers, so I apologize if this was already discussed.
(Log in to post comments)
Garrett: UEFI secure booting Posted Sep 22, 2011 1:51 UTC (Thu) by kevinb (guest, #80386) [Link]
The boot process is a common target. This is a recent example, that takes it one step further and gets into the BIOS:
http://it.slashdot.org/story/11/09/14/1621230/New-BIOS-Ex...
Garrett: UEFI secure booting Posted Sep 22, 2011 4:14 UTC (Thu) by imgx64 (guest, #78590) [Link]
> that takes it one step further and gets into the BIOS
Technically speaking, this is not a step further, but a step *back* in the boot process. This malware modifies the BIOS (or in the future, UEFI), so UEFI checking the OS for a signature is too late to stop it.
The only way to stop the above malware is to disable the ability to flash the ROM from inside the OS (a misfeature that was added, like most other misfeatures, for "convenience").
Garrett: UEFI secure booting Posted Sep 22, 2011 10:47 UTC (Thu) by etienne (subscriber, #25256) [Link]
I wonder if standard Linux boot-loader should in some way check the BIOS FLASH content, like displaying/saving the last CRC32 of that FLASH.
It is very difficult to lie (i.e. intercept requests) to a boot-loader running in real mode, using only physical addresses, and it is easy to detect that you are in fact in virtual mode instead or real mode. The problem is that this CRC32 may change when the user changes BIOS options, probably some of them are not stored in the RTC battery backed RAM anymore because of size problems. Also determining the size and location of the FLASH for whatever PC may be difficult.
Garrett: UEFI secure booting Posted Sep 23, 2011 1:27 UTC (Fri) by hamish (subscriber, #6282) [Link]
This just means that the malware would run the boot-loader in an emulation and only show it what it expected to see.
Garrett: UEFI secure booting Posted Sep 23, 2011 10:20 UTC (Fri) by etienne (subscriber, #25256) [Link]
You can't "emulate" real mode with 4 Gbytes segments (which is needed to read that FLASH) with any x86 processor, even with SMM.
It is quite easy to detect that you are on real hardware, and I would say quite difficult to write the real-mode software so that it also runs inside a simulation.
Garrett: UEFI secure booting Posted Sep 30, 2011 9:00 UTC (Fri) by robbe (guest, #16131) [Link]
As I understand it EFI does away with real mode as well. So your bootloader would run in protected or long mode, both of which can be virtual.
Garrett: UEFI secure booting Posted Oct 3, 2011 11:14 UTC (Mon) by etienne (subscriber, #25256) [Link]
I was speaking of "standard Linux boot-loader", they will not work in protected or long mode, without extensive modifications.
For instance, even if Gujin can work in an emulation (i.e. DOS running EMM386 virtual memory management) it has to load the kernel at a physical memory address and uses HIMEM services for that, knowing that HIMEM has to use physical addresses because it was used by some old drivers to manage DMA buffers. It has also to detect it is not running in real mode and disable trying to access VESA2 video memory directly (disable 4 Gb segments). Also, LOADLIN could be used with EMM386 memory, but had to have a hook just after entering protected mode to relocate each kernel/initrd page. Basically, BIOS bootloader are mostly dealing with physical addresses and assume they own all memory over 1 Mbyte, loading the kernel just after that boundary and the initrd just before the end of memory. As such they could do a checksum/SHA of at least the first Mbyte of the FLASH if it were always located at 0xFFF00000, but newer PC probably have more FLASH than that. IHMO EFI mostly solves Windows problems, I fail to see which Linux problem is solved.
Garrett: UEFI secure booting Posted Oct 3, 2011 18:05 UTC (Mon) by raven667 (subscriber, #5198) [Link] IHMO EFI mostly solves Windows problems, I fail to see which Linux problem is solved. That's kind of amusing since AFAIK EFI has been mostly used for and presumably designed for booting UNIX systems, HPUX and then MacOSX, with Windows support being a distant afterthought.
Garrett: UEFI secure booting Posted Sep 27, 2011 6:47 UTC (Tue) by ssmith32 (subscriber, #72404) [Link]
No, it's not that common. Not at all.
Mebroot or whatever name you use is the only one that has come out in _years_ ... but it is a scary.
Mebroot was done in a fairly professional manner (with an update system, and even, I believe, a tracking system to let them trace crashes, etc), and then most likely sold on the underground market to other malware authors. And I believe the most common payload it delivers is bank account stealers, and it does well to stay under the radar (as in, it does a good job, and it's good that it does that - from the perspective of the bad guys, at least ;) ).
OTOH, most A/V vendors detect this (there are ways), and there are no signs this is a growing trend (no new malware is coming out and installing in the MBR).
In the end, MBR malware doesn't buy you that much more than a normal kernel-level rootkit. It's a little harder to deal with, but it can be dealt with. And it's gonna be much harder to write, and write well (Even Mebroot hewed pretty closely to the eEye PoC, early on). Even Mebroot moved away from depending on the MBR as it's only infection vector, I believe..
So I would say Microsoft's whole thing about doing it to block malware is a bunch of BS. There are no trends that indicate that this is growing threat.. the cost/benefit trade off for malware authors going to the MBR is just not there. Keep in mind, you want your malware to spread, and (I think) MBR code can be fairly specific to some hardware at times..
Although, given that there is actual malware out there, it's not quite the smoke and mirrors as the blue pill was ;)
Yay! my first not so trollish post. I'm learning ;)
|
|||||||||||||