Dailydave mailing list archives
Re: VPC
From: "Rodrigo Rubira Branco (BSDaemon)" <rodrigo () kernelhacking com>
Date: Sat, 1 Mar 2008 7:12:25 -0000
Hello Joanna,
Let me point out some issues here:
Sure, tks for that...
1) On slide #13 you refer to me (at least I assume it is me):
Yes, you are the reference in this subject, right?
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.
Hum, indeed... the idea of garantee that all the code are tamper proof is exactly to avoid any hook to be used... as I think you noticed in the presentation, the project itself tries to use the difficult to locate any possible hook to insert random entries to smm...
Another reason for seeking help in hardware, this time when implementing kernel protection (as opposed to detection) is
Again, the project implements protection and detection, in different ways... the smm-hackish is a new thing inserted to garantee another level of security... there are lots of other problems to be solved related to the kernel data itself, since the project does not try to protect user-mode applications, just to grant the kernel itself has not been modified.
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.
I agree in the matter of protection of the system subversion, not in the matter of protect the kernel integrity itself. Also to clarify, I proposed myself hardware additions in some situations, including to do the proposed hackish (see the power architecture portion of the presentation).
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.
For sure it's just about the kernel .text. Also it's a reference to PaX protections.
It seems to me that StMichael focuses more on detecting rootkit's code rather then ensuring system integrity.
Yes. In the presentation I make very clear that what StMichael does is garantee no kernel modification done by rootkits... not to protect applications and the data itself.
Just out of curiosity I would love to see a list of all the places that are checked by StMichael.
For now it's basically the kernel .text and some important structural data. It also protect the LSM and SELinux management structures to garantee no one will insert a rootkit using it or will disable it in runtime (the first I proposed for a Defcon presentation and the second have been done by Spender in his exploit discussed here).
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.
Yeah, I showed that use in my HITB Malaysia presentation...
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?
Well, I already give the motivation, but again: 1-) I started to work on it before virtualization been really spread ;) 2-) Virtualization is not supported by lots of computers
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?
BIOS patching... I did it in my laptop and this is one of the discussed topics in the presentation. Another question is the cost itself to enter smm, verify integrity and everything else, and the timing to do that... It must be discussed/verified deeply... cya, Rodrigo (BSDaemon). -- http://www.kernelhacking.com/rodrigo Kernel Hacking: If i really know, i can hack GPG KeyID: 1FCEDEA1 _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave