Onderwerp: Re: What is the point here?

On Mon, Jan 19, 2004 at 05:49:15PM -0500, ken kousky wrote:
| But with all that as background, showing off with better exploits isn't
| helping the cause or our defense strategies.

I've cut things down not because I disagree, but because I think that
this particular claim isn't usually examined, and I'd like to do so.

Good exploit code is fundamental to research. Not only the research
of "Is system X that I've deployed vulnerable to some form of attack
Y," but rather research of the form "Does this tool I've invented to
block attack vector A effective against a zoo of attack code?"

That's an important question which vexes researchers building things
like stack smashing defenses--there is no high quality repository of
"vulnerable code, exploit code, fixed code" which allows you to decide
what fraction of exploits your tool prevents.

If the POC code is poor quality, then it can not be used in such a
test. If we're going to move away from being bug hunter-gatherers and
patch distributors, we need to test the tools that take us away from
there. (Quick demonstration: There are about half a dozen
StackGuard-inspired systems out there. Which is best? Prove it.)

Now, does quality POC code need to come out in the days after the bug?
Probably not, based on the argument I've outlined above. (I'm taking
no position right now on its use by admins to test their own systems.)

However, there's the question of motivation: Why does someone spend
time to fix or improve the POC? There's reputation issues, they may
be paid to do so, or they might be altruistic. If there's reputation
at stake, then first to release wins. If someone's being paid, it
makes broad sense to split the work, and share the exploits--everyone
(in the club) gets exploit code for less money. But companies don't
like forming such clubs, while hackers do. So they argue for
disclosure policies that allow them to share the code. Thus, I think
it's unlikely that we'll see improved POC released later, as
attractive as that is to some sysadmins. (There are ways to
structure a market to make that later release more attractive to the
participants, but that's getting off topic.)

Adam


--
"It is seldom that liberty of any kind is lost all at once."
-Hume

On Sun, 18 Jan 2004, Alun Jones wrote:

> And the moderators for this mailing list need to take some responsibility
> (ooh, that's going to get my post rejected, for sure!), and start rejecting
> "updated" POCs unless they serve some security _improvement_ purpose. For
> instance, if the vendor disclaims the presence of the bug, downplays it, or
> uses the POC's tie to one OS or another to claim that other OSes are safe.

That's dangerously subjective. Rather than putting the weight on the
moderators, how about the posters show some responsibility? Most posts
are doing it for the publicity -- if it's negative perhaps they'll learn
to be more responsible in the future.

> Posting exploits is _not_ a measure of first-resort. Exploits should be
> used as proof of concept in the last-resort, when vendors or admins have
> entirely ignored a problem that you have tried to warn them about. Exploits
> should be released as proof of concept _after_ a successful patch has been
> released, so that admins can test that the patch fixes the hole (of course,
> that would mean they'd want to test the exploit on an unpatched machine
> first), or so that they can verify that the patch applies a full fix.

I agree completely. Let the company release a patch, and release a POC
shortly after so admins can test the fix.

> I'd like to think that Bugtraq positions itself as something more than a
> semi-sneaky, behind-the-back-of-the-vendors rant group, or an assembly point
> for root-kit starters. Moderators, please stop accepting posts where the
> poster has stated specifically that they have not yet notified the vendor,
> or where the only new thing that is contributed is a more insidious version
> of an existing exploit. And posters, please consider carefully before you
> post whether what you post is going to contribute to an increase in security
> or a decrease in security. If you cannot claim that your post will help to
> improve security, then do us a favour and take it somewhere else.

Um, no. As a system administrator, I would love for these POC posts to
not exist, but if the code is written, I want to see it. The entire
purpose of bugtraq (in my eyes) is to inform sysadmins of the existence
of exploit codes. If they're rejected from here, it's not going to stop
their distribution in IRC. It's just going to give sysadmins a false
sense of security.

Damian Menscher [braces himself for the flood of vacation messages]
--
-=#| Physics Grad Student & SysAdmin @ U Illinois Urbana-Champaign |#=-
-=#| 488 LLP, 1110 W. Green St, Urbana, IL 61801 Ofc217)333-0038 |#=-
-=#| 4602 Beckman, VMIL/MS, Imaging Technology Group217)244-3074 |#=-
-=#| <menscher@uiuc.edu> www.uiuc.edu/~menscher/ Fax217)333-9819 |#=-

On Sun, 18 Jan 2004, Alun Jones wrote:

> I've been meaning to say something about this for some considerable time
> now, on various exploits and "proofs of concept" that have been posted to
> this list.
>
> Fine, I get the idea of posting a sample exploit, or a POC, as a means to
> spurring on developers (and administrators) to fix and patch systems against
> attack. But really, unless there's a 'fix' that turns out not to be a fix,
> what is the point of posting a "second version" of a sample exploit or POC?
> [Maybe there's a good example in this case, but the poster never mentioned
> what the change was from the standpoint of getting the hole fixed]
>
> What is the point of cleaning up a sample exploit? What is the point of
> posting more and "better" POCs? What is the point of admitting such to this
> list? I know it's a moderated list, because I've seen my own share of
> rejected messages, so I'm going to ask what the point is of the moderation?
>
> We've seen several POCs posted to this list with absolutely no attempt made
> to contact the developers, and we've seen people take other POCs and "fix
> them", so that they install a remote shell without alerting the
> administrators of the machine. Why?
>
> If full disclosure in the name of protecting systems is what we're about,
> then we need to be contacting vendors of systems we breech, and we need to
> be posting code that goes only as far as is necessary to demonstrate the
> breech - _not_ far enough to be the source for the next root kit.
>
(...blah blah...)

If you make a BT a list that filters out the exploits there will appear a
lot other lists or distributions channels that spread exploits/PoC (no
matter what they are).
The result is: Admins reading BT will think that the BUG just mentioned
is hardly, or not exploitable as they seen no exploit, while the exploit
is distributed among blackhats.

It's been discussed here many, maaaaaany times. We don't see a need to
quote it again.

Rgrds,

--
Mariusz Wo³oszyn
Internet Security Specialist, GTS - Internet Partners

Aloha, Alun.

You do a very good job of describing the purpose of vulnerability
disclosure as a means of achieving better information security. You draw
the conclusion that the things you've described are *bad* -- many other
people draw the conclusion that these things are *good* and in
particular find it important to remind vendors that they cannot expect
the public to accept marketing propaganda in lieu of the truth.

The point really is to make vendors, users, admins, and others who
desire real security aware of the fact that there are resources
available to them where good people post the exploits that bad people
otherwise develop and keep to themselves. We cannot prevent bad people
from sharing exploit information.

Do you honestly prefer not to know that your software is flawed and that
those flaws are being exploited to cause your customers harm?

How many times will your customers be harmed between the time that a
vulnerability in your product is first discovered and exploited and the
time that you are notified or find it yourself and then 1) release a
fix, 2) communicate the need for the fix to your customers, and 3)
achieve 100% install base for the update?

Your own story of discovering BugTraq the hard way shows that prompt
disclosure to the public created instant security hardening, without
your involvement or consent, of systems running your vulnerable software.

Why do you expect to be the only person responsible for your customers'
security? That is just emotional nonsense-thought driven by a system of
values that you acquired from Microsoft without realizing it. I've been
in contact with you on an irregular basis for almost a decade, such as
when I wrote about your software in "Setting Up An Internet Site For
Dummies" -- and in many ways my professional path resembles your own. I
can tell you from personal experience, and from the experience of
watching you and people like you struggle to comprehend information
security after-the-fact, that your opinions on this subject have been
shaped by the way that Microsoft discovered information security
after-the-fact. You have been spoon-fed knowledge of infosec through
pain and suffering, just like every other Windows user/developer/admin.

What you still don't realize is that other vendors' customers, Linux
houses, etc. didn't go through such a long and difficult learning curve
to arrive at awareness of security. How much longer will it take for us
defected Windows professionals to achieve the level of understanding of
and concern for security that the rest of our industry has possessed for
decades? I don't know the answer to this question, but I do know that
it's amazing anyone paid us to do work at all during the 1990's because
on the whole we did them harm through our lack of awareness.

It sure is a good thing that legal product liability does not exist in
the software business.

Sincerely,

Jason Coombs
jasonc@science.org


Alun Jones wrote:
....
> I really don't know why _you_ signed up for Bugtraq. Me, I signed up
> because someone posted an exploit for my software here some time ago, and
> didn't bother to tell me about it first. I'd like to think that isn't
> Bugtraq's purpose.
....