[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <c91c769394051f886c25f8bf895ec770dce36a73.7b4792d8.7fb8.4b9e.a421.8989e2199636@feishu.cn>
Date: Thu, 24 Jul 2025 11:43:51 +0800
From: "liyajie" <liyajie@...neuler.sh>
To: "Moritz Bechler" <mbechler@...terphace.org>
Cc: <oss-security@...ts.openwall.com>
Subject: Re: CVE-2025-30761：A vulnerability in JDK's Nashorn Allows for Arbitrary Code Execution
Hi Moritz,
I agree with you, based on my understanding, to use Nashorn safely, at least three conditions must be met:
1. Remove objects such as "Java" and "Package" from the Nashorn execution context to prevent direct access to Java classes and methods.
2. Prohibit access to the engine property in the Nahsorn execution context.
3. Prohibit Reflection.
This approach may ensure that the default execution context is secure (excluding scenarios where business code binds a high-risk class/instance to the execution context on its own).
Using both SecurityManager and ClassFilter should meet the above three conditions, but employing SecurityManager in business environments is not an easy task, the SecurityManager has also been marked as deprecated starting from JDK 17.
Best Regards,
Yajie Li
> From: "Moritz Bechler"<mbechler@...terphace.org>
> Date: Mon, Jul 21, 2025, 00:26
> Subject: Re: [oss-security] CVE-2025-30761：A vulnerability in JDK's Nashorn Allows for Arbitrary Code Execution
> To: <oss-security@...ts.openwall.com>, "liyajie"<liyajie@...neuler.sh>
> 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
>
Content of type "text/html" skipped
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.
