[jira] [Commented] (LANG-1748) RandomStringUtils.random() drains the systems entropy pool and blocks

["Patrick Heusser (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LANG-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870214#comment-17870214 ] 

Patrick Heusser commented on LANG-1748:
---------------------------------------

Did stumble upon the same issue. Great analysis. I could imagine more and more people will come across that, probably not only Liquibase... 

Just for the reference, for me it did show up quite fuzzy. I also use liquibase in a container. On my PC with docker desktop as well on my Macbook in a container all worked well. However when running the same container on my Synology NAS the startup of the app took hours instead of seconds. All the draining entropy as nicely by [~kim_hage] .

I did not look deep into the code... Strong entropy surely is important, but may be it could be narrowed on the initial seed rather than getting it over and over again. So, may be adding some static initialiser to the class as the default behaviour, and a special method if one really needs "fresh" entropy on request? 

> 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 (mockbuild@kbuilder.bsys.centos.org) (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)