Send Dailydave mailing list submissions to
dailydave@lists.immunitysec.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.immunitysec.com/mailman/listinfo/dailydave
or, via email, send a message with subject or body 'help' to
dailydave-requ...@lists.immunitysec.com
You can reach the person managing the list at
dailydave-ow...@lists.immunitysec.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dailydave digest..."
Today's Topics:
1. Announce: PyDbgEng v0.10 (Michael Eddington)
2. Re: Staying on the treadmill. (Matthew Wollenweber)
3. Re: Staying on the treadmill. (Joanna Rutkowska)
4. Re: Staying on the treadmill. (Halvar Flake)
----------------------------------------------------------------------
Message: 1
Date: Tue, 14 Jul 2009 23:22:13 -0700
From: Michael Eddington <medding...@gmail.com>
Subject: [Dailydave] Announce: PyDbgEng v0.10
To: dailydave@lists.immunitysec.com
Message-ID:
<2db0cefa0907142322l2c643040m10cef57c25ac7...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Seems I'm the new maintainer for PyDbgEng, the first (that I'm aware
of) Python wrapper for the WinDbg COM object DbgEng. This new version
includes all the changes I have made while using PyDbgEng with Peach.
This includes removing the native code requirements (now pure python),
adding support for the latest comtypes libraries, and testing with
64bit Python/WinDbg.
PyDbgEng now installs as a normal python module (python setup.py
install) and will locate WinDbg if installed to any semi-normal place.
Should "Just work" for most people. Also included is a py2exe setup
script for the advanced user.
The module has proven stable under heavy use for the last year or so.
Patches and bug fixed always welcome!
http://sourceforge.net/projects/pydbgeng/
mike
------------------------------
Message: 2
Date: Wed, 15 Jul 2009 11:16:59 -0400
From: Matthew Wollenweber <m...@cyberwart.com>
Subject: Re: [Dailydave] Staying on the treadmill.
To: Joanna Rutkowska <joa...@invisiblethingslab.com>
Cc: dailyd...@lists.immunityinc.com, dave <d...@immunityinc.com>
Message-ID:
<5fb633320907150816t78258526o7168e5186be5d...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
>
> 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 <
joa...@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<joa...@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
m...@cyberwart.com
703-395-5036
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.immunitysec.com/pipermail/dailydave/attachments/20090715/44a101d3/attachment-0001.htm
------------------------------
Message: 3
Date: Wed, 15 Jul 2009 17:40:05 +0200
From: Joanna Rutkowska <joa...@invisiblethingslab.com>
Subject: Re: [Dailydave] Staying on the treadmill.
To: Matthew Wollenweber <m...@cyberwart.com>
Cc: dailyd...@lists.immunityinc.com, dave <d...@immunityinc.com>
Message-ID: <4a5df855.8030...@invisiblethingslab.com>
Content-Type: text/plain; charset="iso-8859-1"
Matthew Wollenweber wrote:
> 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 got it backwards! The example of hotel maid stealing your FDE password was
a *simple* attack, for which we already have off-the shelve solutions (e.g.
Bitlocker).
> 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.
But when designing your security, you should assume that this will always happen
on your daily-use browser. It is a mistake to think otherwise.
> So with FDE and understanding heap-overflow ninjitsu he's probably better off
> than waiting for trusted computing.
>
So, how's the heap-overflow nija can help mitigate those browser attacks? By
spending 4543523444234533 days looking at the code of all the applications that
your company uses and finding all possible overflows and other bugs there? ;)
> 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.
>
So, you're saying that fuzzing is the "much preferred" way? Even if we assumed
this to be true (which is not, of course), then still, I'm asking you, why do an
organization need heap overflow ninja? To operate the shaking speaker, errm,
fuzzer? ;)
joanna.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 226 bytes
Desc: OpenPGP digital signature
Url :
http://lists.immunitysec.com/pipermail/dailydave/attachments/20090715/d78508ff/attachment-0001.pgp
------------------------------
Message: 4
Date: 16 Jul 2009 00:23:33 +0200
From: "Halvar Flake" <hal...@gmx.de>
Subject: Re: [Dailydave] Staying on the treadmill.
To: "Joanna Rutkowska" <joa...@invisiblethingslab.com>
Cc: dailyd...@lists.immunityinc.com, dave <d...@immunityinc.com>
Message-ID: <4a5e56e5.6010...@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1
In order to continue my tradition of mostly nonsensical posts:
Joanna wrote:
> No! I highly respect all the people who demonstrated how different things are
> possible. When you show an exploit that attacks things that have never been
> attacked before, it is extremely useful. Remember Solar Designer's JPEG
> Netscape
> *first* public heap overflow? Now, that's what matters.
>
> But coming up with yet-another-one client-side exploit for Browser/PDF
> viewer/etc usually is meaningless. We have seen enough such exploits to
> understand that currently used mitigations do not work (apps code audit, apps
> fuzzing, ASLR, NX), and that we should assume any desktop application that
> takes
> untrusted input can be exploited. And we need to address the problem in a
> different way, with the assumption that even some applications on my desktops
> gets compromised that others still work. Today's OSes do not provide this
> feature.
>
I wholeheartedly agree. It has long been my (and my employers) position
that there are way too many presentations of exploitation techniques. I
therefore propose that we alter this years' Blackhat schedule as follows:
- Remove the John McDonald / Chris Valasek talk
- Remove FX's talk
- Remove the Dowd/Smith/Dewey talk
- Remove Kostya's talk
Instead, I think we should substitute at least two of these with fundamental
talks about trusted computing, one with a talk about homomorphic encryption,
on smartcards and one with a talk about visual spoofing. I would like some
songs, too. And *plenty* of architecture diagrams please, perhaps with a
security proof thrown in.
:-P
> It was joked away, because we are not paid for having fun, but for (trying) to
> solve the actual problems our customers might have. I'm yet to find a company
> that would be advertising their services as "hire us, so *we* could have some
> fun". Have you seen one? Halvar's maybe? Or is it rather "hire us, we will
> help
> you *solve* your problems?"
>
I would prefer to advertise: "You might have some problems that we would
have a ton of fun with. If you make sure we don't starve while having
fun with
these problems, we'll do an excellent job -- we love our work, and take
pride in
it. Would you prefer to hire someone that likes his work, or someone
that gets
paid to pretend to like it ?"
:-)
Holy crap, where has the lightheartedness gone ? Could we *please* all
quit taking
ourselves quite so seriously ?
I am looking forwards to seeing y'all in Vegas in 10 days.
Cheers,
Halvar
------------------------------
_______________________________________________
Dailydave mailing list
Dailydave@lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave
End of Dailydave Digest, Vol 48, Issue 5
****************************************
