| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sat, 27 Sep 2008 13:25:03 -0400 From: Simon Smith <simon@...soft.com> To: AaRoNg11 <aarong11@...il.com> Cc: full-disclosure@...ts.grok.org.uk Subject: Re: To disclose or not to disclose Great replies guys! So lets take this a step further. Lets suppose (again just theory) that the security company did notify the software vendor and did tell the vendor where the security issues were in their technology, how to exploit the issues, provided a proof of concept, and provided clear and actionable methods for remediation. Lets then say that the software vendor flat out, point blank, rejected that information and refused to implement any fixes. Just to make this more interesting, lets say that this all happened over one year ago. Lets also say that the customer who was being tested by the security company and that is using the vulnerable software has yet to address the vulnerability in their own network too. Is it the ethical duity of the security company to release an advisory? Does that advisory put the customer at risk? It is clearly unethical to do nothing and to leave everyone else at risk. How to proceed? AaRoNg11 wrote: > > > On Sat, Sep 27, 2008 at 9:13 AM, AaRoNg11 <aarong11@...il.com > <mailto:aarong11@...il.com>> wrote: > > Hey, this is a situation that occurs quite frequently within the > security industry. (Bad) Vendors often refuse to fix bugs or ignore > them completely until it's too late. > > You should ideally assess each situation on a case by case basis. > Ideally, the first step should be to notify the vendor giving them > as much technical information about the bug as possible. You should > also document the severity of the bug, and give the vendor some > examples of what a malicious user would be able to do. > > If the vendor has not responded within 5 weeks, the second step > should be to create an extremely generic public advisory. This > advisory should explain what the bug allows a malicious user to do, > while not detailing the technical aspects. By doing this, you are > letting the industry know that the software is vulnerable, and it > would be a good idea to start looking at possible alternatives. It > is at this point that you should set a deadline for your public > disclosure of the full advisory. This will put pressure on the > vendor to get a patch out ASAP. > > A few days before the deadline, you should try to release a fix for > the affected product yourself. Obviously this is only possible with > open source software. Most people that use mission critical software > (such as hospitals etc) will be signed up to at least one security > mailing list. By doing this, you give them a chance to patch the bug > before the script kiddies get in. While it may be possible to > recreate the exploit from the patched code, it is unlikely that > anybody will be able to rush anything out in the few days before the > public advisory. > > > On Sat, Sep 27, 2008 at 4:39 AM, Simon Smith <simon@...soft.com > <mailto:simon@...soft.com>> wrote: > > Greetings, > I have a theoretical question of ethics for other security > professionals that participate in this list. This is not an actual > situation, but it is a potentially realistic situation that I'm > interested in exploring and finding an acceptable solution to. > > Supposed a penetration testing company delivers a service > to a > customer. That customer uses a technology that was created by a > third > party to host a critical component of their infrastructure. The > penetration testing company identifies several critical flaws in the > technology and notifies the customer, and the vendor. > > One year passes and the vendor had done nothing to fix > the issue. The > customer is still vulnerable and they have done nothing to > change their > level of risk and exposure. In fact, lets say that the vendor > flat out > refuses to do anything about the issue even though they have been > notified of the problem. Lets also assume that this issue affects > thousands of customers in the financial and medical industry and > puts > them at dire risk. > > What should the security company do? > > 1-) Create a formal advisory, contact the vendor and notify them > of the > intent to release the advisory in a period of "n" days? If the > vendor > refuses to fix the issue does the security company still release the > advisory in "n" days? Is that protecting the customer or putting the > customer at risk? Or does it even change the risk level as their > risk > still exists. > > 2-) Does the security company collect a list of users of the > technology > and notify those users one by one? The process might be very time > consuming but by doing that the security company might not > increase the > risk faced by the users of the technology, will they? > > 3-) Does the security company release a low level advisory that > notifies > users of the technology to contact the vendor in order to gain > access to > the technical details about the issue? > > 4-) Does the security company do something else? If so, what is the > appropriate course of action? > > 5-) Does the security company do nothing? > > I'm very interested to hear what people thin the "responsible" > action > would be here. It appears that this is a challenge that will at some > level create risk for the customer. Is it impossible to do this > without > creating an unacceptable level of risk? > > Looking forward to real responses (and troll responses too... > especially > n3td3v). > > -- > > - simon > > ---------------------- > http://www.snosoft.com > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > > > > > -- > Aaron Goulden > > > > > -- > Aaron Goulden -- - simon ---------------------- http://www.snosoft.com _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists