Re: recent disclosure debates

[Adam Shostack <adam () homeport org>]

On Mon, Dec 16, 2002 at 06:30:21PM -0500, Paul Robertson wrote:
| On Mon, 16 Dec 2002, Adam Shostack wrote:
| [Once again, this is my personal opinion, and not the position of
| TruSecure.]

Ok, well this is my opinion, and I'll happily sell it to the highest
bidder. ;)

| > ISS has released 22 or so advisories this year.[1] They messed up on
| > one of them.  There's always a last minute flurry of stuff that
| > happens in these coordinated releases.  Vendors who have been silent
| > pop up asking for extra time.  Someone realizes that the text of
| > announcements is out of whack.  Exploit code surfaces outside.  Etc.
| 
| By ISS' admission at the time, no 3rd party exploit code seemed to exist.

I didn't say that that happened this time, I said that there's a
flurry of activity as you release, and people make mistakes.

| > While it was painful for everyone who runs bind to have a disjoint
| > release, ISS's error rate is under 10% for the year.  Redhat has also
| > jumped the gun, and I'm sure others have, and will again.
| 
| We're talking about a product that has lots of ties into OS vendors, none 
| of whom had time to ship new releases.  Error rate doesn't make a whole 
| bunch of difference when you're talking critical infrastructure.  Error 
| rate doesn't matter for the victims of attacks who have no protection and 
| can't replace shipping vendor versions without voiding support 
| contracts...  We should expect better of the security community.

I'm going to recapsulate because I can't easily divide up those
sentences.  I think you have three main points here.  Firstly, that
the vendors who re-distribute ISC code didn't get enough time.
Second, that errors are not acceptable, and third, we should do
better.  

Regarding point 1: From the earlier postings in this thread, which I'm
taking at face value, ISS and ISC had agreed to a coordinated release
on that day, and then ISS messed up.  If ISC hadn't agreed to the date
in question, then we'd have to get into the how much time is enough
question.

Regarding your second point, errors are inevitable.  We must start
designing systems to be resilient when errors happen, because in the
real world, errors happen.  I don't think its right to overly blame
the people who point out that the system is vulnerable, especially
when they told the vendor about the problem, when they got agreement
from the vendor as to a date to talk about the problem, and then
failed to check that the patches were available.  Not that I'd ever
say ISS is blameless, but I think in this instance they're not overly
at fault.

How to make BIND more resilient?  Make chroot, run as dns the default.
Make a little itsy bitsy listener that you can run if you don't need
to run a server that does thousands of queries per second.  Make the
error messages useful in terms of what directory you're in.  (I think
I filed this bug when trying to debug bind 9 chroot, setuid.)

| If it's worth it for ISS to not just let ISC give them credit, and follow 
| up with that, then it's worth it for them to take responsibility for the 
| results of their actions.  Bad marketing decisions _should_ cost you- 
| especially when those marketing decisions put thousands at risk.

Again, I respectfully disagree.  The marketing decision was not what
put anyone at risk, an error in execution was what put people at
risk.  And yes, ISS ought to do better.  They ought to have checklists
of how to do this stuff, and "check that the patches are available and
fix the problem" ought to be on that checklist.

| > I think a more important issue is ISC's possible use of a problem in
| > their free software to get people to buy into a consortia.  ISS made a
| > mistake, ISC may be using their position to differentially allow users
| > of their software to secure themselves.  That's a business choice, and
| > I think it's a bad one for a maker of free software.
| 
| Indeed, I wholeheartedly agree with you.  But this isn't an OR condition, 
| it's an AND condtion, and both parties need to do better if they're going 
| to be seen as responsible entities.  

I'll buy that its an AND, but I really don't agree that ISS deserves
to be dragged through the mud.  (When I was competing with them, I
might have said differently ;) The reason I don't think so is ISS is
being too close-mouthed about vulnerability information.  I think its
a shame that they're not releasing their old sploit code (at a
low-controversy 12 or 18 month lag.)  Vulnerability information is
important for doing research, like the types of problems work that
Steve Christey of Mitre has done recently.  We need good vulnerability
information to drive research.  And beating up ISS for releasing a
vulnerability notice creates pressure to release less information.
Having less information hurts us all.  ISS's mistimed release doesn't
include exploit information, and does include a workaround.

They made a mistake.  They owned up to it as much as I'd expect a
publicly traded company to.  They released their disclosure policies.
It's fair to give ISS a hard time over giving their customers
information one day after vendor notification, but they're a
for-profit company, unlike ISC.

| I'm going through the pain of switching to djbdns for my personal systems 
| because of ISC's handling of this incident.  It certainly worries me more 
| than ISS's culpability, but I don't think that gives them absolution from 
| criticism.  I also think that ISC has made their position clear in the 
| past, and ISS seemed to be going against the formal disclosure policy they 
| seem to have agreed to- it seems to me that was the basis of Russ' 
| comments that Ron pointed to.  

Yes, and I think that it was a mistake, and the reaction to that
mistake is gonig to carry serious consequences in the disclosure
debate.


Adam

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


_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards