[3824] in bugtraq

home help back first fref pref prev next nref lref last post

Re: CERT/AUCERT

daemon@ATHENA.MIT.EDU (Yuri Volobuev)
Thu Dec 19 23:05:35 1996

Date: 	Thu, 19 Dec 1996 20:08:32 -0600
Reply-To: Yuri Volobuev <volobuev@t1.chem.umn.edu>
From: Yuri Volobuev <volobuev@t1.chem.umn.edu>
X-To:         itudps <itudps@ntx.city.unisa.edu.au>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
In-Reply-To:  <Pine.SOL.3.94.961220092356.25910R-100000@ntx.city.unisa.edu.au>

> I politely asked CERT about this. "Not our policy to acknolwedge", to
> paraphrase the response. Then I pointed out that they *always* bend over
> backwards to acknowledge computer companies and the other CERT (whichever
> one is doing the announce) to the point of effusiveness at times. No reply
> since, did I offend them? This really isn't a game of responsible CERTs vs
> dirty crackers, its just a matter of professionals sharing valuable
> knowledge. Knowledge which is significant enough to be worth a lot of
> money to a lot of people, regardless of intellectual property laws.They
> should be far more careful, and apply common decency besides.
>
> It seems to me that they might have a case for not acknowledging when all
> that was posted was an exploit, not a fix. However when both are posted
> together it smacks of plagurism to me to repost another version of the fix
> without acknowledgement. By this logic the author of the recent SGI stuff
> should get a mention but SOD should not, since SOD don't (as far as I can
> recollect) publish fixes as well.

We had a little discussion on that subject with AUSCERT.  They think that
full disclosure is bad, period.  So if one posts an exploit, he'll never be
acknoledged.  The rest is irrelevant.  That's a matter  of opinion, though.
For professionals who understand what they are doing, full disclosure is the
best way to understand the problem and figure what they need to do to fix
it.  For people with less clue who consider reading security lists a luxury,
it's pure evil.  One of the blames put of authors of exploits is that they
make possible creation of "root kits".  No one mentions, though, that root
kit which only contains published exploits is harmless to people who keep
themselves informed.  At any rate, question of relative merits of full
disclosure is far too complex to treat it in any simple way, like xCERT do.
However, the way I understand it, giving a credit for this kind of
information remains purely a question of professional courtesy, I don't
think any legal implications can be seriously considered.

As for supplementing an exploit with a fix, it's not a point whatsoever.
For commercial Unices where no source code is available, workaround could
only be as much as stripping suid bit or making a simple wrapper.  Any
knowlegdable sysadmin would be able to come up with ideas as bright as those
by his/her own.  So what SOD et al. are doing is not much different from me
reminding people to remove that suid bit.  Real fixes in many cases are also
simple: check buffer bounds, do lstat before write, never ever use system(),
and such (which doesn't make some vendors react any quicker, of course).
Trick is to find a weakness.

cheers,

yuri

home help back first fref pref prev next nref lref last post