Re: Staying on the treadmill.

[Matthew Wollenweber <mjw () cyberwart com>]

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

Several years ago I was an intern at nasa. One of the things they like to do
to interns is give them senseless tours. During one such tour I learned that
they were very excited about updating computers going into space with a 386
processor. It had taken them more than 10 years to evaluate and reduce risk
to acceptable levels. Even then, I was told there were 2 backups -- just in
case.

My point is that you can have a fetish for esoteric attacks where the hotel
maid is stealing fde passwords and spend years developing mitigations. You
can even go further trying to build 'secure systems' or 'trusted computing',
but if you can do it within a time period applicable to people or before the
uses cases and attack vectors completely shift, I'd be truly surprised.
Building something that will withstand anything that goes wrong is
exponentially more complicated and time consuming than refining systems that
minimizes evolving known risks.

The much more probable attacks are that the researchers laptop is lost,
stolen, or that while online it's compromised be a heap-overflow ninja with
an IE/Firefox/whatever exploit. So with FDE and understanding heap-overflow
ninjitsu he's probably better off than waiting for trusted computing.

Then again, I much preferred the portion of the tour with the room size
speaker that shook satellites to see what would fall off and break. When it
did, they determined the problem and fixed it... much like the exploit
writers. When an exploit is part of a process then it's much more than
simply demonstrating a problem -- it's iteratively finding and fixing the
weak spots.

On Tue, Jul 14, 2009 at 11: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


-- 
Matthew Wollenweber
mjw () cyberwart com
703-395-5036

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave