Re: CERT Advisory - wuarchive ftpd Trojan Horse

[ole!rwing!pat () nwnexus wa com (Pat Myrto)]

"In the previous message, David Dyer-Bennet said..."
>  
> In article <3454 () rwing UUCP> you write:
>  
> > I don't really think that the 8lgm stuff was all fresh, unknown to
> > anybody stuff.  Betcha that it was ALL well-known to the 'pivileged
> > few'.  And whether it was reported to CERT is irrelevant.  With the
> > recent behavior of CERT, they would be one of the LAST people I would
> > report a problem I became aware of to (if I wanted to get as many sites
> > secured against it as possible as quickly as possible).  They might be
> > appropriate if I wanted to claim "I reported it" yet ensure a maximum
> > delay in fixing it, to ensure as many sites remain vulnerable as long
> > as possible for cracker buddies...
>  
> I think CERT should always be included on the mailing list of people you
> report a problem to (I mean, if you want to be a good guy and want to get it
> fixed).  Doing so denies them the out of saying "We didn't know about it."
> And who knows, perhaps the horse will learn to sing.

Well, I think that CERT is more of a waste of time entity - kinda like
mailing to /dev/null.  The sort of outfit one can send to if wants to
claim they tried to alert people, when in fact one really didn't want
to alert the 'good guys'.

> I understand the IETF has started an activity to set the operational
> parameters of a CERT-replacement.  They didn't put it quite so bluntly.  

Who/what is IETF?  Is this a list I should be interested in?

> I agree with you about the importance of spreading the information.  A few
> basic things like not doing public disclosure just before a day that most
> commercial admins will be away are probably justifable, but basically I'm in
> favor of letting out the information.

Assuming I discover a nasty hole, and know how to exploit it:

What I have always advocated is a three step procedure.  Step one is to
let the affected vendor know.  How subsequent steps are handled are
dependent on the response of the vendor, mostly in the area of influencing
time frames.  The vendor would be told that disclosure will be happening
in a general form, followed by enough info that people can check out
their sites.  Step two being to give out bare minimums to the net - for
example "A serious security problem exists in rdist.  Strongly recommend
disabling the service for the time being, and contacting your vendor
for a patch.   Details adequate to test and perhaps devise your own
workaround/fix in one or two weeks.  Suggest you obtain freeware sources
from one of the archive sites and get it ported sufficient to get it to
compile in the interim, so applying a fix will be as easy as possible."
Then step three is to fire off the full details late Sunday night or
early Monday morning a week or two later (depending), to ensure it is
in the news spool or mailbox about when the admin gets there in the
morning.

This would get the info out, and not blind-side anybody.  If the vendor
came across as really sincere, and asked me to sit on it longer since
they were really going to make a fix available, I would tend to comply
WITHIN REASON.  I would contact them before I was ready to disclose and
ask them about the status of their fix.  If I got the feeling that they
weren't going to do anyting but sit on it, or otherwise stall, I would
tell them thats not acceptable, and let them know they got <whatever
time interval, determined by complexity> left, as I intend to disclose.
As with anything, variations on this basic procedure would be determined
by common sense.  Something that is due to the design of some major
component of the system, being harder to fix, would get a longer delay
than somehting that only requires fixing a typo in the source.

This would also apply to other problems - like some procedure by which
a user could reliably cause a panic and crash, corruption of data,
or whatever.  But the knowlege that disclosure WOULD occur acts as
a disincentive for a vendor to drag their feet on the problem.  Otherwise,
why hurry, says the vendor - nobody knows about it...

I think that is about as balanced an approach as possible.  It gives
vendors a chance to act, yet doesn't allow anybody to put the problem
into a black hole so they don't have to do anything.  If someone has
a better basic procedure, sound off.

The problem is, that invariably it is the larger, high profile sites
that will usually spot the holes, since there are more people accessing
it, and it is a more lucrative target for crackers to break, and there
are more people on the staff to spot a bug.  The problem arises because
all too often a fair number of the larger site admins know each other,
and will trade info privately, perhaps drop a line to the vendor, and
tend to disregard the smaller sites and the rest of the world, figuring
'the vendor or CERT will take care of it' since they generally will get
the Red Carpet treatment from CERT, so to THEM CERT appears as if its
a useful service.  They cover THEIR butts, and tend to say 'to hell with
everyone else'.  These types are easy to recognize - they are the ones
who oppose any disclosure (except to them, of course), or only advocate
disclosure a couple of decades later....

- --  
pat@rwing  [If all fails, try:  rwing!pat () ole cdac com]  Pat Myrto - Seattle WA
"No one has the right to destroy another person's belief by demanding
empirical evidence."  --   Ann Landers, nationally syndicated advice columnist
and Director at Handgun Control Inc.