Here are the slides about Trusted Computing I used for my presentations at the EuSecWest today, and at the Confidence conference last week.
As this was supposed to be a keynote, the slides are much less technical then our other slides, and also there are no new attacks presented there. Still, I hope they might be useful as some sort of an "alternative" introduction to Trusted Computing :)
A cool presentation I saw today was about PCI-based backdoors by Christophe Devine and Guillaume Vissian. They basically took a general-purpose FPGA programmable PC-card (AKA PCMCIA), flashed it with an FPGA "program" that implemented a simple state machine. The purpose of the state machine was to wait until its DMA engine gets initialized and then to modify certain bytes in the host memory, that happened to be part of the winlogon.exe process (IIRC they changed XOR AL, AL into MOV AL, 1, or something like that, at the end of some password verification function inside the winlogon.exe process). The slides should be available soon on the conference website. I also hope they will publish all the source code needed to flash your own personal "winlogon unlocker".
The live demo was really impressive — they showed a winlogon screen, tried to login a few times with wrong passwords, of course all the attempts failed, then they inserted their magic, $300 worth, PC-card, and… 2 seconds later they could log in using any password they wanted.
While not necessary being a breakthrough, as everybody has known such things could be done for years, I think it is still important that somebody eventually implemented this, discussed the technical details (FPGA-related), and also showed how to implement it with a cheap generic "reflashable" hardware without using a soldering iron.
Of course I have also discussed in my presentation how to prevent PCI-based backdoors (like the one discussed here) using VT-d, but this defense is currently only available if you use Xen 3.3 or later, and also requires that you manually create driver domain partitions and come up with a reasonable scheme for assigning devices to driver domains. All in all 99.9% of users are not (and will not be anytime soon) protected against such attacks. Oh, wait, there is actually a relatively simple software-based workaround (besides putting a glue into your PC-card slot, which is not a very subtle one)… I wonder who else will find out :)
Replacing Winlogon or hooking the affected function should solve the problem. *g*
ReplyDeleteThank you Joanna. Will give it a read once home. Good stuff as usual. Keep 'em coming ;)
ReplyDelete@Kumat:
ReplyDeleteReplacing winlogon.exe or hooking some winlogon functions is only a temporary workaround against specific version of the attack. The French guys who made this PCMICA card said they are currently working on building a small RISC-like processor using FPGA on this card to be able to conduct more sophisticated attacks (e.g. search memory for password, etc).
I've has in mind much more generic method that would work against *any* type of PC-card-based attack. So, sorry, but you don't score a point ;)
Well i guess your refering to your Presentation: "Beyond The CPU: Defeating Hardware Based RAM Acquisition" && the upcomeing IOMMUs.
ReplyDeleteAnyway thanks for your presentations, they realy help me alot to improve my knowledge. After I finisehd understanding the whole BP code I'll take a look at the topic Firewire/PCMCIA/PCI in combination with DMA, seems pretty interesting.
Thinking of embedding a microprocessor on such a hardware based RAM acquisition board is a pretty interesting idea. Anybody thought of building a PC inside your PC ;)
&KumaT: no, I referred to a software-only solution that doesn't require any chipset support.
ReplyDeleteHm so when your saying its a software only solution, and detouring/bouncing DMA is not the solution there is not much left. As far as I did understand, the attacks using PC-cards do theoretically work without any driver support (Blocking drivers from loading does not help). Considering that under this circumstances the RAM is not protectable (at least with no technique i currently know of), the only possible solutions i can think of would be:
ReplyDelete1. Encrypt the related memory ares using the password as decryption key.
2. Turn off DMA/the related BUS (glue is a better soultion than this one...)
3. Keep the data in the cache (Memory Cloaking) or on disk.
Well I'm excited to get the right answer, but I'll probably have to wait ;)