Re: VPC

[Joanna Rutkowska <joanna () invisiblethings org>]

-----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