Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am interested to hear what the community's thoughts are on detail provided by a software vendor along with a fix and a security advisory.

For example, let's say that some kind of severe vulnerability was privately brought to a vendor's attention. It was fixed it, a new release made, patches and published a security advisory published.

In this security advisory, how much information would you expect the vendor to disclose?

In my mind two things need to be weighed up:

  1. Going into too much detail and giving a scent to the black hat world as to the existence of the flaw and how to find it, who may react quicker than the vendor's customers
  2. Providing detail in the name of transparency and customers wanting to know exactly how severe this thing is

Is #1 a valid concern, or is it a case of...

That'll do the trick

share|improve this question

closed as primarily opinion-based by Terry Chia, Lucas Kauffman, Xander, Adi, TildalWave Jul 17 '13 at 18:11

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Vote to close as primarly opinion based. Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. – Lucas Kauffman Jul 17 '13 at 15:00

The "normal" way of doing things is:

  1. Whoever finds out the flaw contacts the vendor.
  2. Vendor makes the patch, and publishes it, pushing it to customers with a vague but scary description ("fixes a flaw allowing for remote code execution").
  3. A few weeks later, details are published. If all went well, the initial discoverer makes the publication, in full agreement with the vendor, so that due credits are attributed; and the vendor adds a link to the publication details in his own documentation.

For instance, this is what happened with the SSL-related flaw dubbed "CRIME": browser vendors were warned several weeks in advance, and pushed patches. Occasionally, the vague description can be enough for some people to guess what is happening a few days before actual publication. The dance is a matter of delicacy, especially with opensource software, because patch source code is often quite revealing about the exact nature of the issue.

One psychological side of the issue is that vulnerability hunters are a tough crowd who may react, sometimes, in somewhat heated emotional ways, if they feel that vendors don't react appropriately or fast enough. Software vendors would usually prefer to keep flaws secret, but if they have to accept publication, then, at least, they really prefer to have some advance warning. The "due credits for prior warning" barter is an arrangement which has a high probability of convincing most bug-hunters not to push the exploit right away on public channels, so software vendors will support this "normal way".

Ultimately, when the dust has settled, all details should be published, because full disclosure is a great foundation for trust.

share|improve this answer

The main observation I would make on this is that if someone is able to write exploit code to deal with many such flaws, they are also likely able to analyze the patch itself to identify the flaw. Knowing the details of where a flaw exists and even how the flaw generally works doesn't necessarily give a lot to go on for implementing it.

It's still necessary to analyze the system in question and figure out how an exploit would have to be implemented. This is the same skill set as needed to analyze what a patch is changing and removes all the noise, so the risk of public disclosure of a fair bit of detail probably isn't bad as long as it isn't enough to make a working exploit without that skill set.

That said, this varies based on the type of vulnerability. If there is a SQL injection vulnerability for example, it's likely far easier to exploit than say a buffer overflow. So the nature of the vulnerability also has to be taken in to account.

The key is to give enough information that users understand their exposure and can take appropriate measures while also trying to ensure that you aren't giving a clever attacker more details on how to implement a working attack than the patch itself would give them.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.