On Tue, 8 Oct 2002, Paul D. Robertson wrote: > 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. I've noticed change in this area. Though not all researchers have bought into the current state, and the bugtraq/security focus/symatec shift in it's interpretation of 'full disclosure with at least a modicum of responsibility', many of the more serious researchers are trying to work with vendors prior to information release, and their advisories have been following a degree of outlined compliance in such information being included as vendor contact dates, vendors response <when available>, a CVE variety of risk level of the potential vulnerability, as well as some patches for open source coded products <the DCMA again here limits what patches folks are willing to attempt to closed source code>, and work arounds when patches are not included <though admittedly, these are sometimes very strict and will make some systems/services unusable until a fix from the vendors is released, and this is not entirely a bad thing<TM>>. I think we all have to admit there has been a change in focus in more recent times, and those refusing to adapt are perhaps widening the lines between researchers, hackers, and 'cracker' hat crowds.[1: see below] > > > 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. > [1] And art of it is the vast amounts of code people use that is not longer maintained, as well as the issues that a couple of folks at mitre.org outlined two years ago: <quote> Title: An informal analysis of vendor acknowledgement of vulnerabilities Authors: Steve Christey (coleyat_private) Barbara Pease (bjpat_private) Date: March 11, 2001 [SNIP] In anticipation of the Guardent/eWeek vulnerability summit in early November 2000, we conducted an informal experiment in which we tried to obtain the following information: 1) Whether the vendor publicly showed awareness of an announced vulnerability, and admitted that the problem was real ("vendor acknowledgement," also referred to as confirmation). 2) Whether the vendor provided contact information for security problems. [SNIP] Basic Conclusions ----------------- 1) Without a standard location for security vulnerability information on vendor web sites, it is often extremely difficult to even find the appropriate page where vulnerability and patch information might be discussed. 2) Without a standard contact name for asking questions about vulnerabilities, it is difficult for a security analyst to find out which individuals or groups at a vendor web site have the information needed. This problem also makes it difficult for the vulnerability researcher to reach the right people. 3) The customer-focused nature of vendor web sites often makes it difficult for security analysts to access vulnerability information, even if the site has that information. Security analysts normally are not the vendor's customers. 4) Frequently, there is no apparent public acknowledgement of the vulnerability, or the web site is too difficult to navigate. 5) In some cases, the vendor may or may not have acknowledged the vulnerability, but the vendor's information is too vague to be certain. 6) When the researcher's original report did not include detailed vendor and product information (such as URLs and version numbers), it made it more difficult for the security analyst to find the proper vendor web page to examine for acknowledgement. </quote> These remain real world issue to date. Much less so in the security products available, but, are still issues researchers have to wade through in dealing with issues they discover. The security focus lists are ripe with requests from people asking others for input for points of contact in some attempts to be more responsible in disclosure mechanics they are involved in. Thus, while, and let me reiterate, I'm not promoting blanket "full disclosure" and certainly not promoting the open release of sploits for each and every 0day found, I can understand the degrees of frustration others feel in trying to adapt to a more responsible disclosure policy. As for 'bad laws' we all know that getting a law reversed once it's become something of real relevance to the legal beagle crowd is alot tougher then trying to rid a home of roaches. > > 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. > Agreed, this is getting better, there are still crack in the system such as the recent vendors espousing the DCMA legislation to threaten a group of researchers as mentioned before. > > 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. The responsible disclosures policies I've seen, including the couple that have been up and down for RFC consideration as well as RFP's revisions put forth more a premise that the researcher be kept in the informational loop. And I don't see that as a bad thing<TM> at all. Keeping the researcher in the loop was the responsible thing ICSA labs did ere with Mikeal. And of course, I'll put forth that the researcher also has to keep themselves in the loop here, to work with the vendors in trying to mitigate the issue to resolution. Which includes sharing all their information collected on the issue and if they have developed a working sploit, to provide it to the vendor to help them understand the degree of the problem they <the vendor> are trying to resolve. The point I make her, is that it's a two way street. Vendors needs to make themselves available to researchers finding issues with their code and appliances, and the researchers needs to also make themselves available to the vendors. And if the vendors would give the researchers credit when they then together with or without orgs like CERT, release the information to the public, give the researchers their hard earned credit for that cyber-slap-on-the-back, and something to stuff in a resume to sweeten their glamour to hiring reps, we'd perhaps see far less of the irresponsible disclosure that has permeated the industry over the years. > > > 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. > Yes, and been bitten here too in this regard. I recall a number of years back seeing an exploit released that affected linux systems tcp/ip stacks at about 3am central time <we were Midwestern back then, not of the 'eastern' persuasion>. Saved the sploit and patch info, and decided it was far too early to worry about and slipped off to get some sleep. Wake at 6am to the sounds of some of my systems bouncing up and down, due to the sploit already being perpetrated upon the Internet community. We went into fast fix mode and in less then 15 Minutes had the local systems fixed, then flew out the door to take care of the production systems at work. This was my bad, I had the information and decided I had some leeway time to mitigate the issue on my end, when in fact I hadn't. Yet, I do recall in years past, on the eves of large holidays like x-mas whence sploits were pushed one after another into the public streams like bugtraq in irresponsible manners often resulting in no well deserved time off for those responsible in their work. This is indeed not in compliance with responsibility in any sense of the term, you'll get no argument from me. > > 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. > The same might be made for the cases of Nimda and the code reds, or even the M$sql worms still wrecking havoc on bandwidth and systems though. Part of the responsibility here lies again with the vendors making sure their customers know the issues at hand and how to correct them, and finally with the customers and admins of those sploitable systems still in service, long after fixes have been available. we are even seeing the results of slacking administration, be they home users or those in public venues in a production realm, on opensource, folks are not patching their ssl aware apache systems from the recent worm variants slithering through the wires as I write. Granted the code writers have a large part of responsibility to take for releasing such into the public domain, but, the edge of the responsible sword cuts back at those with unpatched systems months and years after patches and fixes have been widely available. > > 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. Cool, we have our own hypocratic<SP?> oath! <grin> and perhaps it should be forced to be sworn to in the various security certification schemas out there! Agreed, and makes the point that if my cohorts in the industry have systems infested with viri and worm code, that is affecting the bandwidth of my clients to connect to my production systems, or filling my logs with malicious attempts of exploit, I'm more apt though to vent my frustration at and end of the means, towards their irresponsible policies of not dealing with the issues at hand. I'm going to get more results this way then some search for the writers or the malicious code or venting at the person that disclosed the issue that propagated this worm at this point. I hope I have made the points I intended, that responsibility is not a finger one points at all others without first cleaning the glass in ones own house. Responsibility, like security, is an issue that everyone has to do their part in, vendors, researchers, and ends users/admins. Thanks, Ron DuFresne -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ admin & senior security consultant: sysinfo.com http://sysinfo.com "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart testing, only testing, and damn good at it too! _______________________________________________ firewall-wizards mailing list firewall-wizardsat_private http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
This archive was generated by hypermail 2b30 : Wed Oct 09 2002 - 14:27:48 PDT