[web] master update

Kurt Roeckx kurt at openssl.org
Sun May 12 21:44:35 UTC 2019

The branch master has been updated
       via  b506b4fae6ec2661f12c2ae522c83c2f4fc051b3 (commit)
       via  947d03ee10750815f8cf7a2e597dfb6441857295 (commit)
      from  5ea7530ac9bea4482635ec821e5babff35aec8c7 (commit)

- Log -----------------------------------------------------------------
commit b506b4fae6ec2661f12c2ae522c83c2f4fc051b3
Author: Kurt Roeckx <kurt at roeckx.be>
Date:   Sat Dec 8 20:12:01 2018 +0100

    Update security policy

commit 947d03ee10750815f8cf7a2e597dfb6441857295
Author: Mark J. Cox <mark at awe.com>
Date:   Thu Nov 29 15:27:27 2018 +0000

    Discussed at the OMC face to face that we should make it clear what things we consider in and out of scope of being OpenSSL vulnerabilities and therefore what we will assign a CVE for


Summary of changes:
 policies/secpolicy.html | 45 ++++++++++++++++++++++++++++++++++-----------
 1 file changed, 34 insertions(+), 11 deletions(-)

diff --git a/policies/secpolicy.html b/policies/secpolicy.html
index 3a298d4..d54fcc6 100644
--- a/policies/secpolicy.html
+++ b/policies/secpolicy.html
@@ -12,7 +12,7 @@
 	    <h2>Security Policy</h2>
-	      Last modified 16th May 2018
+	      Last modified 12th May 2019
 	  <div class="entry-content">
@@ -21,11 +21,11 @@
             If you wish to report a possible security issue in OpenSSL
-            please <a href="/community/#securityreports">notify us</a>.  
+            please <a href="/community/#securityreports">notify us</a>.
             <h2>Issue triage</h2>
             Notifications are received by a group of OpenSSL Management Committee
             members.  We engage resources within
@@ -38,12 +38,35 @@
+	    <h2>Threat Model</h2>
+            <p>Certain threats are currently considered outside of the scope of the OpenSSL threat model.
+              Accordingly, we do not consider OpenSSL secure against the following classes of attacks:</p>
+              <ul>
+                <li>same physical system side channel</li>
+                <li>CPU/hardware flaws</li>
+                <li>physical fault injection</li>
+                <li>physical observation side channels (e.g. power consumption, EM emissions, etc)</li>
+              </ul>
+             <p>Mitigations for security issues outside of our threat scope may
+               still be addressed, however we do not class these as OpenSSL vulnerabilities
+               and will therefore not issue CVEs for any mitigations to address these issues.</p>
+             <p>We are working towards making the same physical system side
+               channel attacks very hard.</p>
+             <p>Prior to the threat model being included in this policy, CVEs
+               were sometimes issued for these classes of attacks. The
+               existence of a previous CVE does not override this policy going
+               forward.</p>
 	    <h2>Issue severity</h2>
 	    <p>We will determine the risk of each issue,
 	    taking into account our experience dealing with past
 	    issues, versions affected, common defaults, and use cases.
-	    We use the following severity categories:</p>
+            We use the following severity categories:</p>
               <li><em><a name="critical">CRITICAL</a> Severity.</em>
@@ -51,8 +74,8 @@
               be exploitable. Examples include significant disclosure of the
               contents of server memory (potentially revealing user details),
               vulnerabilities which can be easily exploited remotely to
-              compromise server private keys (excluding local, theoretical or
-              difficult to exploit side channel attacks) or where remote code
+              compromise server private keys
+              or where remote code
               execution is considered likely in common situations.  These
               issues will be kept private and will trigger a new release of
               all supported versions.  We will attempt to address these as
@@ -67,7 +90,7 @@
               versions.  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</li>
 	      <em><a name="moderate">MODERATE</a> Severity.</em>
 	      This includes issues like crashes in client applications,
@@ -75,12 +98,12 @@
 	      and local flaws.  These will in general be kept private until
 	      the next release, and that release will be scheduled so that it
 	      can roll up several such flaws at one time.</li>
 	      <em><a name="low">LOW</a> Severity.</em>
 	      This includes issues such as those that only affect the
-	      openssl command line utility, unlikely configurations, or hard
-	      to exploit timing (side channel) attacks.  These will in general
+	      openssl command line utility, or unlikely configurations.
+	      These will in general
 	      be fixed immediately in latest development versions, and may be
 	      backported to older versions that are still getting updates.  We
 	      will update the vulnerabilities page and note the issue CVE in
@@ -118,7 +141,7 @@
             <p>The policy above is guided by our security principles:</p>
 	      <li>It's in the best interests of the Internet as a whole to get
 	      fixes for OpenSSL security issues out quickly. OpenSSL embargoes

More information about the openssl-commits mailing list