Patrik Nordwall 3efc1c2877

Disable Java serialization by default, #22333 (#27285 )

* akka.actor.allow-java-serialization = off
* Moved primitive (Long, Int, String, ByteString) serializers
  from akka-remote to akka-actor since they had no dependency
  and are useful also in local systems, e.g. persistence.
  * e.g. needed for persistence-tck
  * less allow-java-serialization=on in tests
* CborSerializable in Jackson/test module for ease of use
* JavaSerializable for Java serialization in tests, already in akka-testkit,
  but misconfigured
* Made tests pass
  * allow-java-serialization=on in akka-persistence
  * allow-java-serialization=on in classic remoting tests
  * JavaSerializable and CborSerializable in other remoting tests
* Added serialization for
  * Boolean
  * java.util.concurrent.TimeoutException, AskTimeoutException
* support for testing serialization with the inmem journal
* utility to verifySerialization, in SerializationTestKit
* remove AccountExampleWithCommandHandlersInState becuase not possible to serialize State when it's not static
  * Effect() is factory in EventSourcedBehavior  class
* test the account examples
* SharedLeveldbJournal.configToEnableJavaSerializationForTest
* support for exceptions from remote deployed child actors
  * fallback to akka.remote.serialization.ThrowableNotSerializableException
    if exception is not serializable when wrapped in system messages from
    remote deployed child actors and Status.Failure messages
  * it's implemented in `WrappedPayloadSupport.payloadBuilder`
* update reference documentation
* serialize-messages=off in most places, separate ticket for
  improving or removing that feature
* migration guide, including description of rolling update

* fix 2.13 compiler error

* minor review feedback

2019-07-11 14:04:24 +02:00

3.1 KiB

Raw Blame History

Java Serialization, Fixed in Akka 2.4.17

Date

10 February 2017

Description of Vulnerability

An attacker that can connect to an ActorSystem exposed via Akka Remote over TCP can gain remote code execution 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.

Akka Remoting uses Java serialiser as default configuration which makes it vulnerable in its default form. The documentation of how to disable Java serializer was not complete. The documentation of how to enable mutual authentication was missing (only described in reference.conf).

To protect against such attacks the system should be updated to Akka 2.4.17 or later and be configured with disabled Java serializer. Additional protection can be achieved when running in an untrusted network by enabling @ref:TLS with mutual authentication.

Please subscribe to the akka-security mailing list to be notified promptly about future security issues.

Severity

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: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

Akka 2.4.16 and prior
Akka 2.5-M1 (milestone not intended for production)

Fixed Versions

We have prepared patches for the affected versions, and have released the following versions which resolve the issue:

Akka 2.4.17 (Scala 2.11, 2.12)

Binary and source compatibility has been maintained for the patched releases so the upgrade procedure is as simple as changing the library dependency.

It will also be fixed in 2.5-M2 or 2.5.0-RC1.

Acknowledgements

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.

3.1 KiB Raw Blame History