On 24/10/2022 17:02, Henri Biestro (Apache) wrote:
Hello Commons;
JEXL-381 is an attempt at making JEXL's default more secure or at least
less 'permeable' wrt to the application/platform/JVM/file-system/host that
runs it. Based on JexlPermissions - a crude security visibility manager -,
this restricts the *default* behavior of what is visible to JEXL scripts to
the basics (lang, math, text, collection,...).
This does prevent a future crude test of some kind leading to a CVE stating
that JEXL poses a security risk since it can create processes or read the
whole file-system (cf JEXL-223).
I'd like opinions on this idea - assuming it is not a bad one - and how to
best expose it. Although JEXL 3.3 is compatible with JEXL 3.2, the runtime
behavior might break due to these new default security restrictions.
The net-cost is that current users (people actually using JEXL for its
intended purpose) will have to actively decide how much permeability they
need if they want to upgrade to JEXL 3.3 and retain functionality. They
will probably gain at least some insight about their platform/product
security. Note that the basic mitigation - being as permeable as JEXL 3.2 -
costs only a line of code..
Ideas on how to best warn/expose/explain this to users and any element
pertaining to this subject is welcome. :-)
This sort of functionality is only required if an application is passing
untrusted / unsanitised input to JEXL. That seems an extremely dangerous
thing to do to me. Do we have any indications that any real world users
are doing this?
If the project starts down the road of being "secure by default for
untrusted input" then rather than the project avoiding future CVEs, it
opens itself up to a long stream of future CVEs as researchers find ways
to bypass the restrictions put in place.
My recommended approach for projects like JEXL would to be clearly
document that all input is expected to be trusted and then reject any
vulnerability reports based on processing untrused input.
If there are users that need to process untrusted input then I'd suggest
starting with asking how they are currently validating / sanitising that
input.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
