A random number generator is used in Akka Remoting for TLS (both classic and Artery
Remoting). Akka allows to configure custom random number generators. For historical reasons,
Akka included the
AES256CounterSecureRNG random number
generators. The implementations had a bug that caused the generated numbers to be repeated
after only a few bytes.
The custom RNG implementations were not configured by default but examples in the documentation showed (and therefore implicitly recommended) using the custom ones.
This can be used by an attacker to compromise the communication if these random number generators are enabled in configuration. It would be possible to eavesdrop, replay or modify the messages sent with Akka Remoting/Cluster.
To protect against such attacks the system should be updated to Akka 2.5.16 or later, or the default configuration of the TLS random number generator should be used:
# Set `SecureRandom` RNG explicitly (but it is also the default) akka.remote.classic.netty.ssl.random-number-generator = "SecureRandom" akka.remote.artery.ssl.config-ssl-engine.random-number-generator = "SecureRandom"
Please subscribe to the akka-security mailing list to be notified promptly about future security issues.
The CVSS score of this vulnerability is 5.9 (Medium), based on vector AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N/E:U/RL:O/RC:C.
Rationale for the score:
akka.remote.netty.ssl.random-number-generator = "AES128CounterSecureRNG" akka.remote.netty.ssl.random-number-generator = "AES256CounterSecureRNG" akka.remote.artery.ssl.config-ssl-engine.random-number-generator = "AES128CounterSecureRNG" akka.remote.artery.ssl.config-ssl-engine.random-number-generator = "AES256CounterSecureRNG"
Akka 2.4.x versions are not affected by this particular bug. It has reached
end-of-life since start of 2018. If you still run on Akka 2.4, we still
recommend to use the default
SecureRandom implementation for the reasons
given below. Please check your configuration files not to configure the
We have prepared patches for the affected versions, and have released the following version which resolve the issue:
Binary and source compatibility has been maintained for the patched releases so the upgrade procedure is as simple as changing the library dependency.
The exact historical reasons to include custom RNG implementations could not be reconstructed but it was likely because RNGs provided by previous versions of the JDK were deemed too slow.
Including custom cryptographic components in your library (or application) should not be done lightly. We acknowledge that we cannot prove that the custom RNGs that Akka provides or has been providing are generally correct or just correct enough for the purposes in Akka.
The reporter of this vulnerability, Rafał Sumisławski, kindly provided us with fixes for the custom RNGs in Akka. However, as we cannot thoroughly verify the correctness of the algorithm we decided to remove custom RNGs from Akka.
If the “AES128CounterSecureRNG” and “AES256CounterSecureRNG” configuration values are still used with Akka 2.5.16
they will be ignored and the default
SecureRandom is used and a warning is logged. This is to avoid accidental
use of these unverified and possibly insecure implementations. The deprecated implementations are not recommended,
but they can be enabled by using configuration values “DeprecatedAES128CounterSecureRNG” or “DeprecatedAES256CounterSecureRNG”
during the transition period until they have been removed.
DeprecatedAES256CounterSecureRNG have been removed since Akka 2.5.19.
We would like to thank Rafał Sumisławski at NetworkedAssets for bringing this issue to our attention and providing a patch.