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/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.
+* AC:M - Any one in the adjacent network can launch the attack with non-special access privileges.
-* 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.
+* 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