On Sat, Nov 16, 2002 at 05:48:32PM -0500, Ragnar Paulson wrote:

> Thanks everyone for the clarifications.  I recognize that trusting to be
> protected by the recursion restriction alone is not a good plan.   We have
> in fact started working with Bind 9 and found the conversion remarkably
> painless (in fact no pain at all so far ... this is pleasantly startling,
> actual backwards compatibility :-).

	I think I found relatively few gotchas and those were pretty
esoteric.  I think I was originally caught up on not having default
TTL values in some of my zone files and that was about it.  But that
was some time ago.

> I think the whole security issues could be handled better.  The ISS
> announcement left much to be desired in describing the exposure in bind.  As
> an admin I need to know if a problem is one that has to be addressed
> immediately "you better not go home", "high priority during regular business
> hours", "at the next major software upgrade" or "when you get to it".

	We described it as best we could (I'm the Senior Researcher on
the X-Force at ISS, so I really do mean "we").  There is a delicate
balance we always have to walk.  Too many "details" and people find more
and more exceptions and "errors".  Hell is when you get into one of these
never ending "What if we do this.  So how about this.  We'll if we avoid
this and we do that and we stand on our heads, are we still vulnerable?"
All to avoid upgrading and leaving the vulnerable software in place.
Yes, I'm aware of the issues of scheduling and getting software installed
and not breaking reproducible configurations.  There's just now way out
of it except by covering what we know as precisely as we know it.  In
this case, there was no way to describe each and every way to avoid this,
simply because each way has numerous workarounds and gotchas.  If we
described a workaround and then someone found a way to work around
the workaround (happens more often than not once they get the smell)
then we look bad.  We gave a couple of very generic workarounds, turn
off recursion or limit tcp access.  Beyond that, the variables escalate
beyond control and there is no way to quantify it.  So we don't try.

	By the same token...  Most often, we can't judge what your
setup is.  Is it a "don't go home till it's fixed problem" or a
"wait till the vendor publishes a patch" problem or a "get a good
nights sleep and pick it up in the next software rev problem".  We
can't say, in most cases.  It depends too much on you and your
environment.  To say "Danger Will Robinson, Danger" you must fix
now, drop everything runs the risk that the majority of the readers
are not going to give a flip because it isn't applicable to their
environments and then they ignore us the next time when it really is.
I tell people at the office, it's a no win situation where the best we
can hope for is everyone on BOTH sides of us equally pissed at us.  In
this case, we worked with ISC for two weeks and released on the schedule
that they agreed to and with the wording that we agreed to.  They could
have had more time, had they asked for it, but it wouldn't have made
any difference from the view of everyone else.

	As a footnote...  It can always be handled better.  And when it
is, it's generaly worse.  Because the conditions in a previous advisory
that make a change seem like a good thing leads to bad things in the
next advisory.  Way it goes.  Other than the miscue and confusion over
the availability of the patches, I don't see it get much better and
I have seen times when it's been a heck of a lot worse.  I had one
vendor ignore me and give me the run around for months until they came
in and found a CNN News crew in their lobby (really happened).  That
was a bitch for everyone concerned.  Working with ISC was actually
pretty darn nice.

> The only way I can make that decision is by understanding the exploit well
> enough to judge "my" exposure.  Which may not be the same as the person
> making the announcement.  I don't need details of the lines of code in
> error, or how to write an exploit, but i need to know the few details I
> asked for above ... how to trigger the fault, and the results.

	Again, I don't know how we could have provided that level of
detail without actually publishing an exploit, and you don't want that.
The far extreme is when you are so snowed under in details and complexity
that you STILL can't evaluate your exposure (this would have been one of
those cases) and the kiddie poos have a ready made attack before your
ready.

	Some people say we should have released more information.  Some
people say we shouldn't have released THAT information until the patches
had fully worked down through the chain.  But the later never happens
(still got people using 4.x, ya know).  So we're in the middle as best
we can be...

	Sorry...  This was longer than I meant...  :-)

> Ragnar Paulson

	Regards,
	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

-- Attached file included as plaintext by Ecartis --

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iQCVAwUBPdbojeHJS0bfHdRxAQGnpwQAmj7/xi+FT2Vz4oEpFLIjh3KZTpH0LzpZ
Uow8G4iT5GR68Gv4Y0UpUvfrfKWNwuH24l1Cl4o8pEWSkBkNBDIzaxjiAwikFwCB
p+/6FA3ozbzwT8fywQhUOau6VbVWIW+pFGJHhv5WE1J0LECLEJH2hz7VwszNQgpn
TwXIrGpfLOc=
=mAu8
-----END PGP SIGNATURE-----