[
https://issues.apache.org/jira/browse/LANG-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17895552#comment-17895552
]
Marcus Berndt commented on LANG-1748:
-------------------------------------
As libraries start to implement workarounds for this issu, is there any plan to
fix this in a future release?
Liquibase Fix:
[https://github.com/liquibase/liquibase/pull/6179|https://github.com/liquibase/liquibase/pull/6179)]
> RandomStringUtils.random() drains the systems entropy pool and blocks
> ---------------------------------------------------------------------
>
> Key: LANG-1748
> URL: https://issues.apache.org/jira/browse/LANG-1748
> Project: Commons Lang
> Issue Type: Bug
> Affects Versions: 3.15.0
> Environment: *java -version*
> openjdk version "17.0.9" 2023-10-17
> OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
> OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode,
> sharing)
> */proc/version*
> Linux version 3.10.0-1160.119.1.el7.x86_64
> ([email protected]) (gcc version 4.8.5 20150623 (Red Hat
> 4.8.5-44) (GCC) ) #1 SMP Tue Jun 4 14:43:51 UTC 2024
> */etc/centos-release*
> CentOS Linux release 7.9.2009 (Core)
> */sys/devices/virtual/misc/hw_random/rng_available* is empty
> Reporter: Kim Hage
> Priority: Major
>
> Since we upgraded to Version 3.15 of commons-lang we have experienced
> performance problems and timeout issues during deployments. Our analysis
> suggests that this is due to issues introduced with [this
> change|https://github.com/apache/commons-lang/pull/1250], namely the use of
> {{{}SecureRandom.{}}}{{{}getInstanceStrong(){}}} in
> {{{}src/main/java/org/apache/commons/lang3/RandomUtils.java{}}}.
> SecureRandom.getInstanceStrong() uses /{{{}dev/random{}}} instead of
> {{/dev/urandom}} on linux systems. which leads to terrible performance when
> little entropy is available on the system.
> Here is what seems to happen in our case
> * Our deployments use Liquibase for database schema migrations
> * [Liquibase uses RandomStringUtils to generate internal
> identifiers|https://github.com/liquibase/liquibase/blob/e854a6e18c29651da0d51265a28c58f22ef3248b/liquibase-standard/src/main/java/liquibase/Scope.java#L154],
> and it generates quite a few of them. (This might be a strange decision on
> their side as well, but probably not the issue here)
> * Each call to RandomStringUtils.random() takes a few bytes out of the
> systems entropy pool. This can be traced by calling {{{}cat
> /proc/sys/kernel/random/entropy_avai{}}}l on the linux shell.
> * The systems entropy pool gets drained quickly and when it is empty, calls
> to RandomStringUtils.random() will block until new entropy becomes available.
> Since we are running on a virtual machine, new bytes are added very slowly to
> the systems entropy pool (about 3-4 bytes per second)
> * Ultimately, our deployments fail with a timeout because Liquibase was
> unable to finish in time
> I am not a security expert, but the general consensus on the internet seems
> to be that using /dev/urandom instead of /dev/random should be equally secure
> for almost all use cases.
> Maybe the call to {{SecureRandom.getInstaceStrong()}} in {{RandomUtils}}
> could be replaced with {{{}new SecureRandom(){}}}. Calls to
> RandomStringUtils.random(...) should then be no longer blocking (probably).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
