Adjust the score for the serialization vulnerability

* and some additional clarifications
* and some cleanup of wrong rst format

(cherry picked from commit a79bfbf941e5129fcf21d8a9e29d1ae1c55e39a0)

akka-docs/rst/java/cluster-usage.rst

@@ -85,7 +85,7 @@ An actor that uses the cluster extension may look like this:
 The actor registers itself as subscriber of certain cluster events. It receives events corresponding to the current state
 of the cluster when the subscription starts and then it receives events for changes that happen in the cluster.
 
-    The easiest way to run this example yourself is to download `Lightbend Activator <http://www.lightbend.com/platform/getstarted>`_
+The easiest way to run this example yourself is to download `Lightbend Activator <http://www.lightbend.com/platform/getstarted>`_
 and open the tutorial named `Akka Cluster Samples with Java <http://www.lightbend.com/activator/template/akka-sample-cluster-java>`_.
 It contains instructions of how to run the ``SimpleClusterApp``.
 

akka-docs/rst/java/remoting-artery.rst

@@ -264,6 +264,8 @@ It should be protected by network security, such as a firewall. There is current
 so if network security is not considered as enough protection the classic remoting with
 :ref:`TLS and mutual authentication <remote-tls-java>`  should be used.
 
+Best practice is that Akka remoting nodes should only be accessible from the adjacent network.
+
 It is also security best-practice to :ref:`disable the Java serializer <disable-java-serializer-java-artery>` because of 
 its multiple `known attack surfaces <https://community.hpe.com/t5/Security-Research/The-perils-of-Java-deserialization/ba-p/6838995>`_.
 

akka-docs/rst/java/remoting.rst

@@ -424,6 +424,10 @@ An ``ActorSystem`` should not be exposed via Akka Remote over plain TCP to an un
 It should be protected by network security, such as a firewall. If that is not considered as enough protection
 :ref:`TLS with mutual authentication <remote-tls-java>`  should be enabled.
 
+Best practice is that Akka remoting nodes should only be accessible from the adjacent network. Note that if TLS is 
+enabled with mutual authentication there is still a risk that an attacker can gain access to a valid certificate by
+compromising any node with certificates issued by the same internal PKI tree.
+
 It is also security best-practice to :ref:`disable the Java serializer <disable-java-serializer-java>` because of 
 its multiple `known attack surfaces <https://community.hpe.com/t5/Security-Research/The-perils-of-Java-deserialization/ba-p/6838995>`_.
 
@@ -488,6 +492,9 @@ a certificate from the connecting peer. Without this mode only the client side i
 While Akka is a peer-to-peer technology, each connection between nodes starts out from one side (the "client") towards 
 the other (the "server").
 
+Note that if TLS is enabled with mutual authentication there is still a risk that an attacker can gain access to a valid certificate 
+by compromising any node with certificates issued by the same internal PKI tree.
+
 See also a description of the settings in the :ref:`remote-configuration-scala` section.
 
 .. note::

akka-docs/rst/java/stream/stages-overview.rst

@@ -894,7 +894,7 @@ Similar to ``Flow.fromSinkAndSource`` however couples the termination of these t
 E.g. if the emitted ``Flow`` gets a cancellation, the ``Source`` of course is cancelled,
 however the Sink will also be completed. The table below illustrates the effects in detail:
 
-+-------------------------------------------------+-----------------------------+---------------------------------+
++=================================================+=============================+=================================+
 | Returned Flow                                   | Sink (in)                   | Source (out)                    |
 +=================================================+=============================+=================================+
 | cause: upstream (sink-side) receives completion | effect: receives completion | effect: receives cancel         | 

akka-docs/rst/scala/remoting-artery.rst

@@ -264,7 +264,9 @@ It should be protected by network security, such as a firewall. There is current
 so if network security is not considered as enough protection the classic remoting with
 :ref:`TLS and mutual authentication <remote-tls-scala>`  should be used.
 
-It is also security best-practice to :ref:`disable the Java serializer <disable-java-serializer-java-artery>` because of 
+Best practice is that Akka remoting nodes should only be accessible from the adjacent network.
+
+It is also security best practice to :ref:`disable the Java serializer <disable-java-serializer-java-artery>` because of 
 its multiple `known attack surfaces <https://community.hpe.com/t5/Security-Research/The-perils-of-Java-deserialization/ba-p/6838995>`_.
 
 Untrusted Mode

akka-docs/rst/scala/remoting.rst

@@ -519,6 +519,9 @@ a certificate from the connecting peer. Without this mode only the client side i
 While Akka is a peer-to-peer technology, each connection between nodes starts out from one side (the "client") towards 
 the other (the "server").
 
+Note that if TLS is enabled with mutual authentication there is still a risk that an attacker can gain access to a valid certificate
+by compromising any node with certificates issued by the same internal PKI tree.
+
 See also a description of the settings in the :ref:`remote-configuration-scala` section.
 
 .. note::

akka-docs/rst/scala/stream/stages-overview.rst

@@ -883,7 +883,7 @@ Similar to ``Flow.fromSinkAndSource`` however couples the termination of these t
 E.g. if the emitted ``Flow`` gets a cancellation, the ``Source`` of course is cancelled,
 however the Sink will also be completed. The table below illustrates the effects in detail:
 
-+-------------------------------------------------+-----------------------------+---------------------------------+
++=================================================+=============================+=================================+
 | Returned Flow                                   | Sink (in)                   | Source (out)                    |
 +=================================================+=============================+=================================+
 | cause: upstream (sink-side) receives completion | effect: receives completion | effect: receives cancel         | 

akka-docs/rst/security/2017-02-10-java-serialization.rst

@@ -15,6 +15,7 @@ capabilities in the context of the JVM process that runs the ActorSystem if:
 * ``JavaSerializer`` is enabled (default in Akka 2.4.x)
 * and TLS is disabled *or* TLS is enabled with ``akka.remote.netty.ssl.security.require-mutual-authentication = false``
   (which is still the default in Akka 2.4.x)
+* or if TLS is enabled with mutual authentication and the authentication keys of a host that is allowed to connect have been compromised, an attacker gained access to a valid certificate (e.g. by compromising a node with certificates issued by the same internal PKI tree to get access of the certificate)
 * regardless of whether ``untrusted`` mode is enabled or not
 
 Java deserialization is `known to be vulnerable <https://community.hpe.com/t5/Security-Research/The-perils-of-Java-deserialization/ba-p/6838995>`_ to attacks when attacker can provide arbitrary types.
@@ -30,13 +31,13 @@ Please subscribe to the `akka-security <https://groups.google.com/forum/#!forum/
 Severity
 ~~~~~~~~
 
-The `CVSS <https://en.wikipedia.org/wiki/CVSS>`_ score of this vulnerability is 3.6 (Low), based on vector `AV:A/AC:H/Au:N/C:P/I:P/A:P/E:F/RL:OF/RC:C <https://nvd.nist.gov/cvss.cfm?calculator&version=2&vector=%28AV:A/AC:H/Au:N/C:P/I:P/A:P/E:F/RL:OF/RC:C%29>`_.
+The `CVSS <https://en.wikipedia.org/wiki/CVSS>`_ score of this vulnerability is 6.8 (Medium), based on vector `AV:A/AC:M/Au:N/C:C/I:C/A:C/E:F/RL:TF/RC:C <https://nvd.nist.gov/cvss.cfm?calculator&version=2&vector=(AV:A/AC:M/Au:N/C:C/I:C/A:C/E:F/RL:TF/RC:C)>`_.
 
 Rationale for the score:
 
 * AV:A - Best practice is that Akka remoting nodes should only be accessible from the adjacent network, so in good setups, this will be adjacent.
-* AC:H - In order to exploit, you first need to be able to connect to the Akka system.  This will usually mean exploiting some other system that connects to it first.
-* C:P, I:P, A:P - Partial impact for each of confidentiality, integrity and availability, due to the already high impact to these that being able to connect to a remote actor system in the first place has.
+* AC:M - Any one in the adjacent network can launch the attack with non-special access privileges.
+* C:C, I:C, A:C - Remote Code Execution vulnerabilities are by definition CIA:C.
 
 Affected Versions
 ~~~~~~~~~~~~~~~~~
@@ -58,4 +59,4 @@ It will also be fixed in 2.5-M2 or 2.5.0-RC1.
 Acknowledgements
 ~~~~~~~~~~~~~~~~
 
-We would like to thank Alvaro Munoz & Adrian Bravo for their thorough investigation and bringing this issue to our attention.
+We would like to thank Alvaro Munoz at Hewlett Packard Enterprise Security & Adrian Bravo at Workday for their thorough investigation and bringing this issue to our attention.

akka-docs/rst/security/index.rst

@@ -13,7 +13,7 @@ Reporting Vulnerabilities
 
 We strongly encourage people to report such problems to our private security mailing list first, before disclosing them in a public forum.
 
-Following best-practice, we strongly encourage anyone to report potential security 
+Following best practice, we strongly encourage anyone to report potential security 
 vulnerabilities to security@akka.io before disclosing them in a public forum like the mailing list or as a Github issue.
 
 Reports to this email address will be handled by our security team, who will work together with you