OpenSSL to prenotify distros of severe security fixes

The OpenSSL project has unveiled its first security policy on how the project will handle security fixes, and to whom it will disclose vulnerabilities prior to releases.

Given the blowback from the Heartbleed vulnerability revealed earlier this year, the OpenSSL project has released its first security policy that details how the project handles security issues.

The policy says that the project classifies security issues into three categories of severity: High, moderate, and low.

For an issue to gain the high rating, it must be likely to exploit common configurations of OpenSSL, examples given being the launching of a denial of service attack, a memory leak, or remote code execution. Upon reporting to the project, the policy states that the issue will be keep private amongst the OpenSSL development team, with a number of Linux and BSD distributions given details and patches in order for them to prepare packages for users and to provide feedback.

"These [high severity] issues will be kept private and will trigger a new release of all supported versions," the policy states. "We will attempt to keep the time these issues are private to a minimum; our aim would be no longer than a month where this is something under our control, and significantly quicker if there is a significant risk or we are aware the issue is being exploited."

If a distribution leaks issues, or does not "add value" in the form of feedback, test results, or corrections, the OpenSSL project is reserving the right to withdraw notification for future issues.

For issues deemed to be of moderate severity, it will be kept private and rolled into the next OpenSSL release which is intended to fix a number of such issues.

Low severity issues will be patched immediately in the development branch of the project, and maybe backported to older, supported versions of OpenSSL. They will not cause a new release, the policy says.

Despite committing itself to transparency on security issues, OpenSSL said it was key that issues be kept under wraps until a fix is ready to be shipped.

"The more people you tell in advance the higher the likelihood that a leak will occur," it said. "We have seen this happen before, both with OpenSSL and other projects."

The project said that it had, in the past, attempted to use third parties such as CPNI, oCERT, or CERT/CC, to handle issue notification, but none were suitable.

"It's in the best interests of the Internet as a whole to get fixes for OpenSSL security issues out quickly," the policy states. "OpenSSL embargoes should be measured in days and weeks, not months or years."

The concept of users being able to pay for advance notification of issues was dismissed by OpenSSL.

"It is not acceptable for organisations to use advance notice in marketing as a competitive advantage," the project said.

"We strongly believe that the right to advance patches/info should not be based in any way on paid membership to some forum."