Re: [SC-L] Disclosure: vulnerability pimps? or super heroes?
Based on my general impressions in day-to-day operations for CVE (around 150 new vulns a week on average), maybe 40-60% of disclosures happen without any apparent attempt at vendor coordination, another 10-20% with a communication breakdown (including "they didn't answer in 2 days"), and the rest coordinated. A bit of a guess there, though. The only remotely relevant survey that I can think of was by me and Barbara Pease, 6 years ago in 2001, and we were reduced to qualitative analysis because data collection turned out to be too expensive, and this was focused on vendor acknowledgement (which holds steady at 50% no matter what the year). But disclosure timelines are thankfully more prevalent these days, so an updated study would be more illuminating. I'm looking forward to Richard Forno's study of vuln researchers whenever it comes out. For obligatory SC-L content: this is one reason why I think vendor development/maintenance processes need to be prepared for non-coordinated disclosures. - Steve ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Disclosure: vulnerability pimps? or super heroes?
On Tue, 6 Mar 2007, Kenneth Van Wyk wrote: > While a simple strcpy-->strncpy (or similar) src edit takes just > moments, and shouldn't impact the functionality and reliability of any > software, patches are rarely that simple. Agreed, but this needs to change. The threat environment has provably worsened, so that it can be incredibly damaging to an organization if they rely on software that takes months to fix. From my outsider (non-developer's) point of view, the development lifecycle needs to be able to handle emergency situations. The so-called "pimps" are unintentionally highlighting this problem; what happens when 0-days become more the norm and the time-to-patch hasn't changed? > consumer advocacy. But, I'm convinced that we need to find a process > that better balances the needs of the consumer against the secure > software engineering needs. This assumes that there is widespread interest in helping the consumer, which some researchers simply do not have, and certainly not the genuinely malicious parties. Not that I've given up on "responsible disclosure" but there will be a community of people who won't follow any recommendations that are put out, and hobbyists/independent researchers are also left out. In some ways, I view the current state of affairs as a symptom - when software gets strong enough that someone has to spend a lot of time/resources to find a vulnerability and code an exploit, people won't be so willing to just toss it out to the public willy-nilly. It's just too easy to "grep and gripe" for vulns in typical software. Last year, a 14 year old researcher gave us vuln DB's a headache by finding about 500 vulnerabilities in the course of a few months, using blatantly obvious 10-minute tests on demo versions of software that went for $100 to $500 a pop. That was one of the biggest unreported news stories of the year, as far as I'm concerned. Such blatantly insecure software should not be that widespread. He's not disclosing to the public anymore, just to his own private group, and I don't think I prefer it that way. Interestingly, he was only interested in the "challenge," not the fame. - Steve ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Disclosure: vulnerability pimps? or super heroes?
Kenneth Van Wyk wrote: > So, I applaud the public disclosure model from the standpoint of > consumer advocacy. But, I'm convinced that we need to find a process > that better balances the needs of the consumer against the secure > software engineering needs. Some patches can't reasonably be produced > in the amount of time that the "vulnerability pimps" give the vendors. >From the outside, it looks like the vast majority of the patches take as long as the vendor feels like taking. With a small percentage of vulnerabilities being released with no vendor warning at all. It's relatively unusual that I see bulletins where the researcher releases saying that the vendor took too long, so they are releasing now. But that's just going from memory, I haven't done a proper survey or anything. BB ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Disclosure: vulnerability pimps? or super heroes?
On Mar 5, 2007, at 9:30 PM, Gary McGraw wrote: I think some vendors have come around to the economics argument. In every case, those vendors with extreme reputation exposure have attempted to move past penetrate and patch. Microsoft, for one, is trying hard, but (to use my broken leg analogy) they had a sever case of osteoporosis and must take lots of calcium to build up bone mass. The financial vertical, led by the credit card consortiums is likewise making good progress. Other vendors with less brand exposure (or outright apathy from users) are slower on the uptake. Having spent several years on the incident handling side of this argument at CMU's CERT/CC, US. Dept. of Defense, etc., I thought I'd chime in here as well. It's encouraging to me to see that many vendors now recognize the reputation exposure and economics argument. I know that in my years at CERT (1989-1993), we were more than once threatened by uncooperative vendors, saying that they would sue us if we published information about their product's vulnerabilities. We spent years developing those vendor relationships and building up some level of mutual trust. It's not always an easy path. In the "full disclosure" years, it's been my observation that many vendors get forced into publishing patches when the "vulnerability pimps" (as Marcus calls them) call them out in public. Without a doubt, that's lead many vendors to respond more quickly and more publicly than they otherwise might have. At the same time, (and to try to bring this thread back to *software security*) I'm concerned about the software security ramifications of being bullied into patching something too quickly. While a simple strcpy-->strncpy (or similar) src edit takes just moments, and shouldn't impact the functionality and reliability of any software, patches are rarely that simple. When software producers are forced to develop patches in unnaturally rushed situations, bigger problems (IMHO) will inevitably be introduced. So, I applaud the public disclosure model from the standpoint of consumer advocacy. But, I'm convinced that we need to find a process that better balances the needs of the consumer against the secure software engineering needs. Some patches can't reasonably be produced in the amount of time that the "vulnerability pimps" give the vendors. Cheers, Ken - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com PGP.sig Description: This is a digitally signed message part ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Disclosure: vulnerability pimps? or super heroes?
Right. And while you're calculating costs, don't forget to factor in the costs of all of the opiates that the McGraw automaton is now faced with eating as he wiles away his "patching time" on the orange chair. The break was severe indeed. I think some vendors have come around to the economics argument. In every case, those vendors with extreme reputation exposure have attempted to move past penetrate and patch. Microsoft, for one, is trying hard, but (to use my broken leg analogy) they had a sever case of osteoporosis and must take lots of calcium to build up bone mass. The financial vertical, led by the credit card consortiums is likewise making good progress. Other vendors with less brand exposure (or outright apathy from users) are slower on the uptake. Ultimately, the economic decision will rule the day. gem P.S. I would rush out and buy some ice remover, but the weather has warmed up and I am currently immobile. company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com -Original Message- From: Stuart Moore [mailto:[EMAIL PROTECTED] Sent: Mon Mar 05 21:18:03 2007 To: SC-L@securecoding.org Cc: Steven M. Christey Subject:Re: [SC-L] Disclosure: vulnerability pimps? or super heroes? Though I share Steve's sentiments on the anti-researcher bias, and I agree with Gary's yin-yang conclusion, I really hate the question itself. The disclosure question itself *presumes* that the current state of the industry (defective products) is economically efficient. The premise absolves vendors *and* customers of any role or responsibility in improving efficiency [I'm of the opinion that organic security would be economically beneficial]. The question presumes that The Issue with vulnerabilities is either squelching the researchers (the researcher as pimp view) or promoting detailed disclosures (the researcher as super hero view). I am much more interested in why vendors make defective products and why customers accept this level of quality, and lots of related questions. So, in reference to Gary's "breaking story," why was the Gary McGraw automaton not able to deal with the icy walk? Is the severe structural damage and hours of surgical correction more cost effective than what any anti-ice protections would have cost? Those are the Good Questions. Asking whether the disclosure of the icy exploit is good or bad is the Wrong Question. Stuart -- Stuart Moore SecurityTracker.com Steven M. Christey wrote: > On Tue, 27 Feb 2007, J. M. Seitz wrote: > >> Always a great debate, I somewhat agree with Marcus, there are plenty of >> "pimps" out there looking for fame, and there are definitely a lot of them >> (us) that are working behind the scenes, taking the time to help the vendors >> and to stay somewhat out of the limelight. > > Do the people who write the books to avoid the vulns, sell the tools, and > give talks at conferences stay out of the limelight as well? What about > all those podcasts? They should be discounted too, since they're clearly > pimping something. They must have ulterior motives. Don't get me started > on those rabble-rousers who complain about voting machine security. > > Not that I don't have issues with how disclosure happens sometimes, but > the anti-researcher sentiment that castigates them based on "looking for > fame" by people who are themselves "famous" strikes me as a bit > hypocritical. Why do we know that Marcus designed the White House's first > firewall? 'cause he told us, that's why. > > We're very lucky that assumed fame-hunters like Cesar Cerrudo and David > Maynor have decided that they won't bother telling the vendor about vulns > they find because of all the trouble it gets them into. It's quite > unfortunate that Litchfield has almost single-handedly dared to question > Oracle's claim that it's unbreakable. Perhaps we would prefer that these > pimpers stop giving us disclosure timelines that show that they notified > vendors about issues months or YEARS before the vendors actually got > around to fixing them. We can go back to security through obscurity, the > old fashioned way, by lawsuits and threats. Like what happened at Black > Hat last week, but with less press. > > Basically, I have an issue with the criticism of this aspect of researcher > "pimpage" when it's usually the pot calling the kettle black, when most of > us are getting paid one way or another for this work, and there's a > pervasive inability to recognize that many such researchers feel forced to > disclose when the vendor still does nothing. And many researchers aren'
Re: [SC-L] Disclosure: vulnerability pimps? or super heroes?
Though I share Steve's sentiments on the anti-researcher bias, and I agree with Gary's yin-yang conclusion, I really hate the question itself. The disclosure question itself *presumes* that the current state of the industry (defective products) is economically efficient. The premise absolves vendors *and* customers of any role or responsibility in improving efficiency [I'm of the opinion that organic security would be economically beneficial]. The question presumes that The Issue with vulnerabilities is either squelching the researchers (the researcher as pimp view) or promoting detailed disclosures (the researcher as super hero view). I am much more interested in why vendors make defective products and why customers accept this level of quality, and lots of related questions. So, in reference to Gary's "breaking story," why was the Gary McGraw automaton not able to deal with the icy walk? Is the severe structural damage and hours of surgical correction more cost effective than what any anti-ice protections would have cost? Those are the Good Questions. Asking whether the disclosure of the icy exploit is good or bad is the Wrong Question. Stuart -- Stuart Moore SecurityTracker.com Steven M. Christey wrote: > On Tue, 27 Feb 2007, J. M. Seitz wrote: > >> Always a great debate, I somewhat agree with Marcus, there are plenty of >> "pimps" out there looking for fame, and there are definitely a lot of them >> (us) that are working behind the scenes, taking the time to help the vendors >> and to stay somewhat out of the limelight. > > Do the people who write the books to avoid the vulns, sell the tools, and > give talks at conferences stay out of the limelight as well? What about > all those podcasts? They should be discounted too, since they're clearly > pimping something. They must have ulterior motives. Don't get me started > on those rabble-rousers who complain about voting machine security. > > Not that I don't have issues with how disclosure happens sometimes, but > the anti-researcher sentiment that castigates them based on "looking for > fame" by people who are themselves "famous" strikes me as a bit > hypocritical. Why do we know that Marcus designed the White House's first > firewall? 'cause he told us, that's why. > > We're very lucky that assumed fame-hunters like Cesar Cerrudo and David > Maynor have decided that they won't bother telling the vendor about vulns > they find because of all the trouble it gets them into. It's quite > unfortunate that Litchfield has almost single-handedly dared to question > Oracle's claim that it's unbreakable. Perhaps we would prefer that these > pimpers stop giving us disclosure timelines that show that they notified > vendors about issues months or YEARS before the vendors actually got > around to fixing them. We can go back to security through obscurity, the > old fashioned way, by lawsuits and threats. Like what happened at Black > Hat last week, but with less press. > > Basically, I have an issue with the criticism of this aspect of researcher > "pimpage" when it's usually the pot calling the kettle black, when most of > us are getting paid one way or another for this work, and there's a > pervasive inability to recognize that many such researchers feel forced to > disclose when the vendor still does nothing. And many researchers aren't > in it for the fame, which is the assumption that the pimpage argument is > based on. > > Sorry, must be a case of the Mondays combined with this building up over a > year or two. The vuln researchers are the only parts of this business who > get no respect. > > - Steve ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Disclosure: vulnerability pimps? or super heroes?
On Tue, 27 Feb 2007, J. M. Seitz wrote: > Always a great debate, I somewhat agree with Marcus, there are plenty of > "pimps" out there looking for fame, and there are definitely a lot of them > (us) that are working behind the scenes, taking the time to help the vendors > and to stay somewhat out of the limelight. Do the people who write the books to avoid the vulns, sell the tools, and give talks at conferences stay out of the limelight as well? What about all those podcasts? They should be discounted too, since they're clearly pimping something. They must have ulterior motives. Don't get me started on those rabble-rousers who complain about voting machine security. Not that I don't have issues with how disclosure happens sometimes, but the anti-researcher sentiment that castigates them based on "looking for fame" by people who are themselves "famous" strikes me as a bit hypocritical. Why do we know that Marcus designed the White House's first firewall? 'cause he told us, that's why. We're very lucky that assumed fame-hunters like Cesar Cerrudo and David Maynor have decided that they won't bother telling the vendor about vulns they find because of all the trouble it gets them into. It's quite unfortunate that Litchfield has almost single-handedly dared to question Oracle's claim that it's unbreakable. Perhaps we would prefer that these pimpers stop giving us disclosure timelines that show that they notified vendors about issues months or YEARS before the vendors actually got around to fixing them. We can go back to security through obscurity, the old fashioned way, by lawsuits and threats. Like what happened at Black Hat last week, but with less press. Basically, I have an issue with the criticism of this aspect of researcher "pimpage" when it's usually the pot calling the kettle black, when most of us are getting paid one way or another for this work, and there's a pervasive inability to recognize that many such researchers feel forced to disclose when the vendor still does nothing. And many researchers aren't in it for the fame, which is the assumption that the pimpage argument is based on. Sorry, must be a case of the Mondays combined with this building up over a year or two. The vuln researchers are the only parts of this business who get no respect. - Steve ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Disclosure: vulnerability pimps? or super heroes?
On 2/28/07, Gary McGraw <[EMAIL PROTECTED]> wrote: Hi all, The neverending debate over disclosure continued at RSA this year with a panel featuring Chris Wysopl and others rehashing old ground. There are points on both sides, with radicals on one side (say marcus ranum) calling the disclosure people "vulnerability pimps" and radicals on the other saying that computer security would make no progress at all without disclosure. I've always sought some kind of middle ground when it comes to disclosure. The idea is to minimize risk to users of the broken system while at the samne time learning something about security and making sure the system gets fixed. I think havning extremists is a good thing. Forces people to re-evaluate their position and actually do things, instead of having a disucssion about it. Without that there would be middle grounders sitting around wondering about the best approach. With the extremists these middlegrounders have to react, or at least companies do. Which is only good. Disclosure is the subject of my latest Darkreading column: http://www.darkreading.com/document.asp?doc_id=118174 What do you think? Should we talk about exploits? Should we out vendors? Is there a line to be drawn anywhere? I think if you find an exploit do what you personally want. If I had time to research them, I'd probably be pimping them out for as much as I could; why not? I can decide. I found it. Same to you, with what you found. The only line will come if some authority in some country makes it illegal to sell them. And obviously there would be incredible difficulties in isolating that, IMHO. gem company www.cigital.com podcast www.cigital.com/silverbullet book www.swsec.com -- mike (s1, s2, s3) ; ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Disclosure: vulnerability pimps? or super heroes?
J. M. Seitz wrote: > On a related note, does anyone have an example where Company A was > disclosing vulnerabilities about competing Company B's product and got into > trouble over it? Is this something that could be litigated? In fact, Tom Ptacek found a hole in one of Marcus' products while working for a competitor. I suspect Tom reported it properly, though. This research pissed MJR off to no end, which he made clear at one Black Hat talk he gave, with Tom standing at the back of the room. I suspect this was a key point in MJR's life when his code got touched in an inappropriate way, and has led to his current level of curmudgeonry. Or, for a more contemporary example, witness Symantec researchers looking for holes in just about everything. I fail to see any merit for a legitimate lawsuit. Of course, in the US, you can sue whomever you please. BB ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Disclosure: vulnerability pimps? or super heroes?
Always a great debate, I somewhat agree with Marcus, there are plenty of "pimps" out there looking for fame, and there are definitely a lot of them (us) that are working behind the scenes, taking the time to help the vendors and to stay somewhat out of the limelight. The ying-yang is very fitting. On a related note, does anyone have an example where Company A was disclosing vulnerabilities about competing Company B's product and got into trouble over it? Is this something that could be litigated? JS -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gary McGraw Sent: Tuesday, February 27, 2007 11:24 AM To: SC-L@securecoding.org Subject: [SC-L] Disclosure: vulnerability pimps? or super heroes? Hi all, The neverending debate over disclosure continued at RSA this year with a panel featuring Chris Wysopl and others rehashing old ground. There are points on both sides, with radicals on one side (say marcus ranum) calling the disclosure people "vulnerability pimps" and radicals on the other saying that computer security would make no progress at all without disclosure. I've always sought some kind of middle ground when it comes to disclosure. The idea is to minimize risk to users of the broken system while at the samne time learning something about security and making sure the system gets fixed. Disclosure is the subject of my latest Darkreading column: http://www.darkreading.com/document.asp?doc_id=118174 What do you think? Should we talk about exploits? Should we out vendors? Is there a line to be drawn anywhere? gem company www.cigital.com podcast www.cigital.com/silverbullet book www.swsec.com This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
[SC-L] Disclosure: vulnerability pimps? or super heroes?
Hi all, The neverending debate over disclosure continued at RSA this year with a panel featuring Chris Wysopl and others rehashing old ground. There are points on both sides, with radicals on one side (say marcus ranum) calling the disclosure people "vulnerability pimps" and radicals on the other saying that computer security would make no progress at all without disclosure. I've always sought some kind of middle ground when it comes to disclosure. The idea is to minimize risk to users of the broken system while at the samne time learning something about security and making sure the system gets fixed. Disclosure is the subject of my latest Darkreading column: http://www.darkreading.com/document.asp?doc_id=118174 What do you think? Should we talk about exploits? Should we out vendors? Is there a line to be drawn anywhere? gem company www.cigital.com podcast www.cigital.com/silverbullet book www.swsec.com This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___