Full Disclosure mailing list archives
Re: To disclose or not to disclose
From: AaRoNg11 <aarong11 () gmail com>
Date: Sat, 27 Sep 2008 09:13:41 +0100
On Sat, Sep 27, 2008 at 9:13 AM, AaRoNg11 <aarong11 () gmail 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 () snosoft 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
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- To disclose or not to disclose Simon Smith (Sep 26)
- Message not available
- Re: To disclose or not to disclose AaRoNg11 (Sep 27)
- Re: To disclose or not to disclose Simon Smith (Sep 27)
- Re: To disclose or not to disclose . (Sep 27)
- Re: To disclose or not to disclose AaRoNg11 (Sep 27)
- Re: To disclose or not to disclose AaRoNg11 (Sep 27)
- Message not available
- Re: To disclose or not to disclose Pavel Kankovsky (Sep 28)
- Re: To disclose or not to disclose M . B . Jr . (Sep 28)
- Re: To disclose or not to disclose Tonnerre Lombard (Sep 28)
- <Possible follow-ups>
- Re: To disclose or not to disclose Elazar Broad (Sep 27)
- Re: To disclose or not to disclose Simon Smith (Sep 27)
- Re: To disclose or not to disclose Elazar Broad (Sep 28)