Subscribe to:
Post Comments (Atom)
skip to main |
skip to sidebar
Kernel, Hypervisor, Virtualization, Trusted Computing and other system-level security stuff
About Me
Labels
qubes
general
trusted computing
attack
os security
philosophical
fighting for a better world
exploit
company news
trusted execution technology
xen hacking
tpm
chipset
conferences
disk encryption
hypervisor rootkits
smm
virtualization based rootkits
backdoors
bad guys attacking joanna
cloud
rootkits
usb
xen heap exploiting
BIOS
bitlocker
challanges
formal verification
nested virtualization
odyssey
personal
r3
saving-the-world-afterhours
secure architecture
11 comments:
"For me personally, it’s especially important to take a nap during an afternoon"
You are half-Spanish! :-)
Very interesting your approach of Red/Yellow/Green VMs for regular systems.
Deep interview, Alan did a great job indeed. Many thanks for the long explanations and for your valuable thoughts.
This was one of the most interesting interviews I've read in a long time. I'm a computer scientist by education, and a software manager by trade...this article really got me thinking. I was just thinking a few months ago how the CS community as a whole needs to rethink the entire concept of the OS. It's currently really just a set of drivers, UIs, and "common applications" all bundled together. The OS should, imo, be focused just on managing resources, and preferably it should allocate them to separate (isolated) resource pools.
At some point applications need to communicate with one another, but HTTPS seems to be becoming the standard. Most major pieces of middleware can be clustered; SaaS applications deliver from "the cloud"; etc. Therefore, why not have applications on the desktop run completely isolated from one another, and have access only to the drivers they need (better yet: have their own copies of the driver, so they can only harm themselves).
Heterogenous ("mash-up", if you will) applications might challenge this concept, however.
At any rate, thanks again for the excellent interview - very thought-provoking.
@Anonymous: This is basically what o/s'es have been trying to do all the time. Since 80386 (and actually really 80286) quite sophiscated mechanisms have been available in x86 CPU's that would make it theoretically possible to write a both secure and fast operating system, with memory isolation and isolated drivers only able to talk to the ports they need.
While operating systems have been in a bit cheap* on fully utilizing all these features they have by and large used it as intended. Still, because of programming bugs which are probably a fact of life, the promised isolation and malware-free world has never materialized. The same stealth tricks as we saw in the totally open DOS world thrives even to this day, only in different implementations. We have now gotten more sophiscated technology, VT, VT-d and TXT but so far any improvement hasn't materialised (at least for the mainstream) and some these technologies could even turn out to be new stealth vectors, as Johanna and others have shown.
* An important exception is drivers that doesn't seem to have been isolated in any o/s even though the Intel architecture had made provisions for such an isolation. And now some of these provisions, such as the I/O bit permission map in the Task Segment in the CPU has even been removed from AMD64 long mode! The failure to isolate drivers - and other system components - have been responsible for many attack vectors.
@Martin:
An important exception is drivers that doesn't seem to have been isolated in any o/s even though the Intel architecture had made provisions for such an isolation.
This is not true -- for all those years IA32 did not allow for effective driver isolation. Even thought it has been offering 4 modes of privileges (rings) since 80386, up until recently it didn't offer a protection against DMA, which now is offered by IOMMU/VT-d. This is the primary reason why all popular OSes on IA32 never made use of more then 2 rings (ring 0 an ring 3).
VT-d capable hardware became reality only very recently -- e.g. Q35 (end of 2007), Q45 chipsets (end of 2008) on the desktop side, and PM/GM/GS45 chipsets on the laptop sides, AKA "Centrino 2" (2009).
@Joanna: I'm not sure exactly what you're thinking of here... Maybe it's something along the lines of "Driver [possibly compromised] comandeers a device that it rightly controls into doing a DMA operation that overwrites physical memory that driver wasn't allowed to control?". I agree this is a problem, though I would say it is more of a problem of the system architecture (e.g. PCI/chipet) limitation and not in itself a fault of IA32/x86 (of course it's a big problem to the o/s no matter what).
It could also be you're thinking of a different attack vector :)
Regarding IOMMU, yes I'm painfully aware of that. There's not much to choose from if one wants a TXT capable machine. I bought hardware in the spring last year to experiment with TXT. There were only two mainboards available that had the right chipset (Q35) AND the TPM ;) It is still early days, but I hope Intel will do more to promote this technology and include it in all their chips and chipsets (including integrated TPM as has surfaced in later chipsets) so that it is basically available on all (newer) machines. I'm a bit disappointed TXT was not available in the Core i7 :/ Intel could also do more to promote the tech with sample code for demonstrating on-the-fly usage in popular operating systems (and not just boot-time usages which I really doesn't demontrate what the technology is REALLY useful for, namely bootstrapping into a secure state from an insecure state).
What about microkernels? we are talking about monolithic kernels like Linux and Windows and OS-X where drivers and kernel run in the same ring, but I bet that QNX doesn't need any IOMMU to have secure drivers. Of course, you pay in poor perfomance. IMHO, once again hardware is being created to attack a software design limitation.
It is great interview. I am happy as long as this blog is for free.. lol
Anyway, the IA-32 architecture the way it is today is a result of history. however, when it comes to VT-d, there is no such thing as free lunch. IOMMUs will always impose significant impact on DMA performance as a result of the address translation " basically DMA is no longer DMA". There are many OS developers and designers cry for speed and performance the way you cry for "absolute" security.
I think it is time to encrypt/decrypt and verify the execution of every single instruction of the processor ISA, key shouldn't be kept on the same machine lol... it is time where CPUs cannot t trust BIOS firmware and BIOS firmware can never trust user software lol..
Looking forward for the bh-2009.
Great interview Joanna. I had heard of you back when you released bluepill, but never got the chance to actually hear what you had to say. Seriously cutting edge stuff!
So, today is the day for the ring-3. I will now post the sha256sum's of my guesses ;)
4fb6b006b5322e981ecc98a55b0bcc7735de488841af894f1f06e48fc0acd8d1
or
d39baf6b0b411af22d7e0975722599c9047d047813761887e1d84f5599b0d558
Hello, I'm eagerly waiting to see the slides from yesterday's presentation :) From twitter I gather it was an attack on Intel's AMT technology... I suppose this must be the special microcontroller Intel built in to the chipset for this tech... there was even a presentation by Intel last year about how they thought software running here could be used to detect rootkits... not it can apparently harbor them!
I hope the slides will appear soon - it's a long wait ;)
Hi Joanna
This was one of the most amazing interviews great interview. I never think about it it's really new for me.
Thanks
Post a Comment