Re: Staying on the treadmill.

[Don Bailey <don.bailey () gmail com>]

I agree with Johanna here. Everyone that knows me would expect me to bang on
the importance of exploits over and over. However, in the past year, I've
come to realize that it's really about the threat model around the
vulnerability you're exploiting. We can get as granular as we want into how
to bypass X, Y, and Z, mitigation technology. At the end of the day it
really comes down to securing the design, not the vulnerability. The fact
that I can write a NULL kernel dereference exploit in (literally) 15 minutes
has nothing to do with how cool NULL pointer exploits are or how insecure
the operating system is. Rather, what it has to do with is the fact that I'm
attacking a design flaw. Banging on the importance of protecting from
NULL/Userland/Whatever-you-want-to-call-it-today dereference attacks isn't
the point. The point is addressing it with defense in depth by integrating
protection into the product design.

Although, I do agree that understanding exploit strategy is an imperative
when designing a secure system. If you don't know that X strategy exists,
how do you protect it? While I do agree that generally you can build a
threat model around unknowns and apply mitigation techniques that can
compartmentalize potential threat sources that have exploited a given risk,
I think that it may be easier to do this if the developer team knows about
as many strategies as possible. So, I think there must be a balance. Your
favorite kernel developer may not know understand heap feng shui, but I bet
they understand heap overflow basics and know more about designing a proper
heap abstraction than most exploit developers.

D
On Tue, Jul 14, 2009 at 8:29 AM, Joanna Rutkowska <
joanna () invisiblethingslab com> wrote:

> nnp wrote:
> > Protection mechanisms being written by people who don't understand
> > exploits is surely the reason many are broken within about 43 seconds
> > of being released.
>
> Sure, but there is a difference between "understanding exploits" and being
> an
> exploit fetishist.
>
> Some time ago I attended a security conference well known for having very
> technical audience. I was told the majority of those people are up to date
> with
> all the recent advances in exploitation techniques -- heap overflows,
> getting
> around ASRL/NX, etc. But when I started my lecture, which was about Trusted
> Computing, it turned the number of people who knew how TPM works was...
> close to
> zero! And we're talking about some real basic stuff here, nothing fancy
> like
> TXT. Just what a PCR register is, and what are the advantages of trusted
> boot.
>
> I actually read recently an interview with a well know researcher, who I
> actually respect myself, who happily announced that he's protecting his
> laptop
> using an FDE software, and, to make it more secure, he's powering it down
> as
> often as possible (in order to mitigate possibility of cold-boot attacks).
> Interestingly, he didn't realize he actually makes it much easier for even
> a
> hotel maid to get his encryption key... This is so basic and yet have
> nothing to
> do with advanced exploit understanding.
>
> Now, who do you think can provide more security into an organization, like
> e.g.
> a bank -- a heap-overflow ninja that can bypass ASLR on the most recent
> Vista,
> or a person who would realize that maybe it is worth buying a
> trusted-boot-supported full disk encryption (FDE) software, as otherwise it
> would be trivial for the *real* adversary to get around it? Or a person
> that can
>  tell you that your employees should use 2 different desktop computers and
> would
> be able to decide how to split tasks and activities between the two?
>
> Sure, experience in exploit writing is sometimes crucial. Probably it is of
> the
> utmost important to e.g. OS kernel architects, who might attempt to build
> in all
> the anti-exploitation technologies into the OS (which is what they do in
> fact).
> Or to processor and chipset vendors. This requires great understanding of
> possible workarounds.
>
> It is also important for governments for obvious reasons.
>
> But very few people are OS kernel architects and governments offensive
> teams.
> And the further you go, the less you need those extreme skills, which is
> exploit
> writing as it is today. If you are only a *consumer* of computer products
> (e.g.
> a bank, or an airport), then I really see no reason why you should even be
> able
> to understand the difference between a heap overflow vs. stack overflow.
> You
> just need to understand what a shellcode is and what it can potentially do
> (i.e.
> everything). You should understand that SELinux will not provide you all
> the
> promised features, because it has big monolithic TCB (the Linux kernel)
> that
> represents a huge attack vector. But you don't need to know how to write an
> exploit for SELinux. etc.
>
> joanna.
>
>
> > On Tue, Jul 14, 2009 at 3:07 PM, Joanna
> > Rutkowska<joanna () invisiblethingslab com> wrote:
> > > dave wrote:
> > > > People (this means you) like to think hard about game changing events
> in
> > > > the world of hacking. But just staying on the treadmill of exploit
> after
> > > > exploit can be a game changing event.
> > > >
> > > > For example, today you may have noticed that Intevydis
> > > > (http://www.intevydis.com/vulndisco.shtml) released as part of their
> > > > latest exploit pack, some exploits for all the major access
> > > > point/mini-router firmwares. Not CSRF "exploits" or XSS "exploits". I
> > > > mean "Here's a shell, now you get to install new programs and muck with
> > > > the router's configuration" exploits.
> > > >
> > > > For a lot of people (not you) it's hard to care about such things. The
> > > > inevitable ennui sets in: "oh, not another one", "that one is similar
> to
> > > > one I found in 1992AD", "well, if you had good patch management that's
> > > > the best you can do!", etc. etc.
> > > >
> > > > The magic is in finding each one of these things unique and special and
> > > > worth of attention.
> > > ... or, instead of being an exploit fetishist, one might try to design
> their
> > > network in such a way that a compromise of your network devices is not
> fatal.
> > > Same for PDF viewers, browsers, etc. and how you design your computer
> system.
> > > Sure, it's cool to write exploits -- that always impresses people. We
> also do
> > > that at ITL. E.g. we will be showing a couple of VM escape exploits
> during our
> > > upcoming virtualization training (and we really are excited about those
> > > exploits!), but the whole point is to illustrate how a good design (in
> that
> > > particular case of your hypervisor) and new technologies (e.g. VT-d or
> TXT) can
> > > mitigate a problem of exploits, even if we cannot find and patch them
> all.
> > > I think one should not forget that an exploit, no matter how cool, is
> only an
> > > illustration of a problem. The actual solutions often have nothing to do
> with
> > > how exploits are written. Do you really think VT-d designers were
> heap-overflow
> > > ninjas? I doubt.
> > >
> > > joanna.
> > >
> > >
> > > _______________________________________________
> > > Dailydave mailing list
> > > Dailydave () lists immunitysec com
> > > http://lists.immunitysec.com/mailman/listinfo/dailydave
>
>
> --
> Joanna Rutkowska
> Founder/CEO
> Invisible Things Lab
> http://invisiblethingslab.com/
>
>
> _______________________________________________
> Dailydave mailing list
> Dailydave () lists immunitysec com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave