Dailydave mailing list archives
Re: VPC
From: Joanna Rutkowska <joanna () invisiblethings org>
Date: Fri, 29 Feb 2008 19:17:43 +0100
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rodrigo Rubira Branco (BSDaemon) wrote: | StMichael running in SMM tries to accomplish the same in architectures where | virtualization is not supported: | http://www.kernelhacking.com/rodrigo/docs/H2HCIV.pdf | Let me point out some issues here: 1) On slide #13 you refer to me (at least I assume it is me): "Joanna said we need a new hardware-help [to protect against kernel compromises], really?" and then on slide #21 you explain: "That's [i.e. protecting against protector's code tampering] the motivation in the Joanna's comment about we need new hardware helping us..." So, let me explain, that the biggest problem with kernel compromise detection I have been talking about for at least 2 years now, is the fact that we don't know all the possible hooking places (type II hooking places) that an attacker might use, *not* the problem of tamper proof detector code. Another reason for seeking help in hardware, this time when implementing kernel protection (as opposed to detection) is that for an effective protection we need to move drivers (or groups of drivers) into separate domains/address spaces. We can not effectively do that without IOMMU/VT-d. 2) On slides #54 you write: "The idea of putting the entire kernel as read-only seems good". Let me just point out that there is no such thing as "read-only kernel" -- kernel is a program, and as every program it also needs to use and operate on *data* that change all the time and cannot be made read-only by definition. So even if you can force the kernel *code* to be read-only (which is a good idea indeed and digital signatures are useful in actually verifying this property), the kernel as a whole, is always read/write. It seems to me that StMichael focuses more on detecting rootkit's code rather then ensuring system integrity. Just out of curiosity I would love to see a list of all the places that are checked by StMichael. 3) While the whole idea of putting own code into SMM seems interesting, I see it much more useful for writing kernel malware rather then security tools. I really don't see a reason why to use this "hack" instead of using the virtualization technology, which was designed just for such tasks among others? 4) BTW, AFAIK modern laptops have their SMRAM locked down just after it is initialized by SMM. Are you going to bypass this locking mechanism in order to install your protection system? Cheers, joanna. -----BEGIN PGP SIGNATURE----- iQEVAwUBR8hMRcwG7MOLAMOlAQKLUQgArbD+tQXRM5PRC6ovv1jUVvrj6EPXhXNv 8+QI/C9AVYRMOmtbZnFqEd8b/ZHn1F9alaMJ9It1FFnNs+cNrNjxf1RtBbctKJfc Wck+rTuJsZsbMTO4knQez2/5SODiBJn6cWAkhFaV5OxmnTQviXTpuk4JysxrBrC9 lXKAzkisrCAbAvLjL8ttr3VHhQaijlPhTV34Omzh0TtwPm+uWh/4O3GC53frLM26 F0ruywJpO+HHyVPF/sxye4iOgfSB07bO+fsY0Ps6N+5vaQhkKW4pJ9IWDQKll7w7 efGH7SukYgoFkdbnDP1qRHvrqb1t7gxMJUHqLOsV/DRENeosIDOL/A== =CCaj -----END PGP SIGNATURE----- _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave