Re: VPC

["Rodrigo Rubira Branco (BSDaemon)" <rodrigo () kernelhacking com>]

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