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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sat, 27 Sep 2008 09:13:41 +0100
From: AaRoNg11 <aarong11@...il.com>
To: "Simon Smith" <simon@...soft.com>, full-disclosure@...ts.grok.org.uk
Subject: Re: To disclose or not to disclose

On Sat, Sep 27, 2008 at 9:13 AM, AaRoNg11 <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> 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

Content of type "text/html" skipped

_______________________________________________
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ