diff --git a/akka-docs/rst/java/cluster-usage.rst b/akka-docs/rst/java/cluster-usage.rst index 14fcaa6d5b..f7ef257843 100644 --- a/akka-docs/rst/java/cluster-usage.rst +++ b/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 `_ +The easiest way to run this example yourself is to download `Lightbend Activator `_ and open the tutorial named `Akka Cluster Samples with Java `_. It contains instructions of how to run the ``SimpleClusterApp``. diff --git a/akka-docs/rst/java/remoting-artery.rst b/akka-docs/rst/java/remoting-artery.rst index c51455c8b8..0fa0e6c383 100644 --- a/akka-docs/rst/java/remoting-artery.rst +++ b/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 ` 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 ` because of its multiple `known attack surfaces `_. diff --git a/akka-docs/rst/java/remoting.rst b/akka-docs/rst/java/remoting.rst index 49d264734c..c75b0c5b57 100644 --- a/akka-docs/rst/java/remoting.rst +++ b/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 ` 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 ` because of its multiple `known attack surfaces `_. @@ -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:: diff --git a/akka-docs/rst/java/stream/stages-overview.rst b/akka-docs/rst/java/stream/stages-overview.rst index fb6e6fca42..65d11c3b34 100644 --- a/akka-docs/rst/java/stream/stages-overview.rst +++ b/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 | diff --git a/akka-docs/rst/scala/remoting-artery.rst b/akka-docs/rst/scala/remoting-artery.rst index 90f90ea2fc..66e842482b 100644 --- a/akka-docs/rst/scala/remoting-artery.rst +++ b/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 ` should be used. -It is also security best-practice to :ref:`disable the Java serializer ` 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 ` because of its multiple `known attack surfaces `_. Untrusted Mode diff --git a/akka-docs/rst/scala/remoting.rst b/akka-docs/rst/scala/remoting.rst index 4cdb48b6ad..29918dc8cd 100644 --- a/akka-docs/rst/scala/remoting.rst +++ b/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:: diff --git a/akka-docs/rst/scala/stream/stages-overview.rst b/akka-docs/rst/scala/stream/stages-overview.rst index 1cc5d6bd6b..8b3ffcf882 100644 --- a/akka-docs/rst/scala/stream/stages-overview.rst +++ b/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 | diff --git a/akka-docs/rst/security/2017-02-10-java-serialization.rst b/akka-docs/rst/security/2017-02-10-java-serialization.rst index c42ba54574..7960765721 100644 --- a/akka-docs/rst/security/2017-02-10-java-serialization.rst +++ b/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 `_ to attacks when attacker can provide arbitrary types. @@ -30,13 +31,13 @@ Please subscribe to the `akka-security `_ 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 `_. +The `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 `_. 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. \ No newline at end of file +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. \ No newline at end of file diff --git a/akka-docs/rst/security/index.rst b/akka-docs/rst/security/index.rst index aff893029f..d7a48f318b 100644 --- a/akka-docs/rst/security/index.rst +++ b/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