RE: This mornings Security Wire Perspectives - Ira's proof of concept code article.

[robert () dyadsecurity com]

Julio Patel(smerdyakovv () gmail com)@Mon, Nov 29, 2004 at 11:13:55AM -0500:
> > So are gun makers, and the Sharpie pen company, spray paint
> > manufacturers, baseball bat makers, etc. etc.  The tools have dual
> > purposes.  Security Researchers are not responsible for the criminal
> > actions of others.
>
> Upper Bound.  Lower Bound.  Anyone wanna shoot for something in between?

First off, let me say thank you for responding.  I enjoy
feedback/conversations.

I was merely demonstrating absurdity by being absurd.

> > I think proof of concept code and advisories should come out before a
> > patch is available.  Who is the security research community serving ..
> > the end user or the vendor? As an information owner, I would ideally
> > know my risks as soon as possible. Remember folks, the problem is still
> > there whether I know about it yet or not.  Just because a "good guy" was
> > willing to share the security problem they found doesn't mean that it
> > wasn't already found by a "bad guy".  I am far more concerned about
> > directed malice than I am worms.
>
> Are you talking for all the end users?  Oddly, I might want the patch
> before the exploit code...it depends on the situation.

Can't speak for everyone.  My contention is that if the person is on the
ball enough to know about patches and to install them in a timely manner
then they are on the ball enough to take other security precautions if
needed.  The way the current vulnerability information disclosure scheme
works results in an extended period of time for a vulnerability to be
exploited in malicious directed attacks.  It also lowers responsibility
on the vendors to make quality software and lowers the pressure to make
a solution available.

As an informed end user I want the extra information.  Uninformed end
users are going to be compromised with or without a patch being made
available.

> > I'm reminded of a childhood experience.  When I was 6 my parents bought
> > me a bike.  I had a chain to lock up my bike when I was away from home.
> > One day my little sister was playing with the lock and broke it.  I was
> > angry with her for finding this vulnerability in my security system
> > until my father pointed out that if my little sister could easily break
> > my lock, then so could a person who wanted to steal my bike.  Sometimes
> > it's better to know your risks so you don't make uninformed decisions
> > based on a perception of security.
>
> HAHA.  Yeah, but you woulda been pissed if your sister broke the lock
> and then told the other kids about it before giving you the chance to
> put it in the garage with daddy's beemer.

I grew up thinking everyone had to work on their car on the weekends. 
We had one Volkswagen Micro Bus as the family car.  We could barely
afford the bike on a super sale from toys r us.  I know you're just
joking around, but you don't know me, and shouldn't make a wealth
assumption like that :).

Also, if the other kids and I were notified at the same time, I'd still
have an opportunity to secure my bike.

> > People who follow this advice clearly have no concept of what their
> > automated scanners are doing or even how they are developed.
>
> apparently, neither do you.  You do know that many scanners check for
> package versions, registry keys, dlls, etc. locally, right?  I'm not
> saying that all scanners and all checks use local access.  I am saying
> that many do include the ability to do the 'scanning' this way.  Ira
> took an extreme, you've taken up the flag for the other extreme, and
> the truth....well, it's out there somewhere.

Turns out I know a little bit about security testing and security
scanners :).  Consult http://www.osstmm.org and
http://www.unicornscan.org

> hmmm.  i took Ira's statement to mean that if you're a pen-tester
> worth half a chit, you'll be able to come up with a way to test for
> the vuln on your own.  Note that I'm not saying that Ira is worth half
> a chit...but, if you're contracted to scan a newtork and can't come up
> with your own stuff, then your precentage of chit is on the decline.

On a recent test we had to take an Apache vulnerability and modify it in
order to exploit an IBM molested version of apache.  We at least had
enough of a base to start from in the middle of a test.  On the same
test we had to tell them to consult IBM for another identified
vulnerability that had very little technical details published other
than the version of the vulnerable application.  In the middle of a test
you don't have time to rediscover every hole and write custom exploits
for every problem.  We don't need working code, but we need a technical
enough discussion where we understand what the problem is in order to
test for it.  We never use straight example POC code in tests... but we
do find it to be helpful as a starting point.

> > I'd like to throw the "monoculture" crap back at you on this one.  If
> > the attack payload is easily identifiable and reused, then the gateway
> > devices should be able to mitigate the risk.  I've never been a fan of
> > IDS or IPS systems as I don't believe they are properly labeled.  They
> > do not detect or prevent intrusions.  However they are getting
> > particularly good at detecting and in some cases preventing (at the
> > gateways) worms.  This is where your Worm Prevention System (WPS/WDS)
> > can help you... that is of course until a vulnerability is distributed
> > to attack them :).
>
> one, you're contradicting yourself above.
>
> two, this is about as silly as the 'encrypting email' post.  re-read
> what you just posted.  are you saying that gateway devices should be
> doing signature matching on known exploits?

I think you misunderstood my point. I am not advocating IPS solutions as
a valid security defense. :)

See http://www.dyadsecurity.com/papers/rbac.html for a more detailed
view into my thoughts on that stuff. 

Robert

-- 
Robert E. Lee
CTO, Dyad Security, Inc.
W - http://www.dyadsecurity.com
E - robert () dyadsecurity com
M - (949) 394-2033
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
https://lists.immunitysec.com/mailman/listinfo/dailydave