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 probertsat_private which may have no basis whatsoever in fact." probertsonat_private Director of Risk Assessment TruSecure Corporation _______________________________________________ firewall-wizards mailing list firewall-wizardsat_private http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
This archive was generated by hypermail 2b30 : Tue Oct 08 2002 - 14:40:36 PDT