Re: Multiple firewalls ruleset bypass through FTP. Again. (CERT VU#328867)

["Paul D. Robertson" <proberts () patriot net>]

On Tue, 8 Oct 2002, R. DuFresne wrote:

> On Tue, 8 Oct 2002, Paul D. Robertson wrote:
[snip]

> In a better world I think many researchers would take a stance as Mikael,
> or be willing to adopt the RFP policy in disclosure <it looks to have
> been updated to a newer version recently?>.  Exploits prior to
> warning/patches are certainly not a good thing<TM>.  Yet, one has too look

They're worse than "not a good thing," they're mostly _very_bad_things.
They turn innocent 3rd parties into victims.  If you're creating victims, 
you're part of the problem.  Rarely do we see anyone espousing "full 
disclosure" coding up patches, fixes, or anything other than attacks.

> at vendors outside those that only produce security products on which
> their reputations hinge in looking at the full disclosure issue.  I know
> it's been tackled here and elsewhere alot, and quite a bit recently in
> various formats.  But, when a major OS/hardware vendor threatens to use
> the DCMA to go after a security consulting/research site for disclosing
> issues they <the major vendor> have held under their belts for years, if
> not months, then we have a totally different situation then that was faced

Well, part of that is how you approach the vendor[1], and part of it has 
to do with the fact that DMCA is a *Bad Law*.  If you're not supporting 
the current legislation to modify DMCA, you're part of the problem.  This 
particular case took months- some of that was directly my fault.  Because 
there wasn't a magic clock ticking, we were able to coordinate fixes, 
testing, discussion... while taking time to get it right, ensure 
everyone was included, etc.

> here.  It seems folks that produce security products and code might well
> understand the consequences of not acknowledging potential risks to their
> name and ventures when exploitable issues are found with their offerings,
> and are willing to work with researchers in addressing those issues then
> some of the larger vendors in the OS/hardware realms often are.  Getting

I think this is for the most part not true.  I see quite a bit of stuff 
that goes to OS vendors outside of public mailing lists, and I have yet to 
see anything that hasn't gotten addressed eventually.  I'm not saying that 
there aren't cases where vendors haven't fixed things, I'm just saying 
they're rare in the space of software I've seen reports for, even outside 
of the security product community.

> vendors to work with researchers in such instances would be a grand
> thing<TM> as opposed to reckless threats of legal retribution after they
> have been advised of the issues by the researcher<s> who discovered the

How many threats of legal retribution have there been versus attempts at 
extortion or threats at compromise?  While I'm certainly not a vendor 
spokesperson (I tend to prefer Open Source solutions myself) there are two 
sides to each and every coin.  One side is getting a bunch of attention 
these days, and the other side isn't.  "You have 14 days to explain to me 
how you're going to fix this and to produce a fix or I'll unleash the 
world against your customers" isn't productive to positive dialog.

> issues.  While times have changed in this realm with a number of vendors,
> it has well been slow work with some in the industry.  Afterall, bugtraq
> was founded with good reason, no mater their shifts of disclosure policies
> as they have been grown and been acquired in the recent economic

Yes, let's look at Bugtraq- care to guess how many companies have been 
"saved" versus how many exploited victims there are for the history of the 
list back when it was more open?  I know where my bet would go.

> understimulas.  I certainly feel that many researchers would take a more
> reasonable approach to disclosure issues if they did not find vendors
> constantly ignoring matters that have been disclosed to them with their
> offerings, and when sitting for periods doing nothing to fix the issue,
> then making threats to sue or otherwise damage the researchers for finally
> disclosing the problems for others to mitigate on their own or pressure
> their offending vendors to deal with the problems with their products.

Part of it has to do with how it's approached, and part of it certainly 
has to do with the market.  In our case, we have NDAs with all the 
vendors, so working with them all at once without worrying about someone 
trying to gain a competative advantage for a short time is relatively 
easy.  

> Do not get me wrong here, I'm not a proponent of 0day code being released
> hither and tither, but, I'm also wary of not knowing what my adversaries
> might know, and feel that if at least one or more researchers know, as
> well as the vendor, there are great chances that others might well know
> what I've not had time to find on my own.  I know many here, as I myself
> have observed, changes in disclosure policies of various researchers and
> mailing lists over the years.  And I've seen alot of information hit those

But let's look at my favorite posterchild of full disclosure, RDS.  RDS 
was fixed by MS- yet it was the #1 attack vector for IIS servers for 
years after it was fixed (RFP's exploit came out after the shipping at 
the time version of IIS didn't have the problem.)  People who'd already 
upgraded their servers OR configured them conservatively weren't 
vulnerable.  Producing the exploit didn't "force MS to fix the problem" 
it created victims.

> venues of information sharing without the older tendency to *require* a
> 0day sploit to prove the point of the information disclosure.  Granted
> there is not total compliance in this, there's alot of mistrust and lack of
> patience and cooperation still permeating the IT world at large.  Afterall
> the little guys all know the bigger fish are out to get em.  And we

First, do no harm.

Paul
[1] ICSA Labs has a unique advantage in the security product space.  But 
when I've personally approached vendors with security issues, I've always 
seen fixes happen, so I'm not sure it's rocket science in most cases.
[1b] If anyone wants to try to drive a vendor to fix a problem, I'd be 
happy to work with them to contact the vendor and go through the process.
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts () patriot net      which may have no basis whatsoever in fact."
probertson () trusecure com Director of Risk Assessment TruSecure Corporation

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