On 31/10/2022 14:03, Henri Biestro wrote:
Let's restrict this discussion to the case of 'authenticated and authorised
users' of an 'enterprise platform'.
When we talk about 'unsafe input' vs 'safe input', I'm still confused about
what this actually entails. Let's assume we want those users to enter a (JEXL)
expression to express their functional need (think of an enterprise spreadsheet
of some kind with some built-in constraints). Is this considered an 'unsafe
input' by essence ? If so, we need to 'sanitise' it to ensure it is 'harmless'
- that being a broad definition.
If the users that can edit the JEXL are authenticated and authorised
then then that is pretty much the definition of trusted input.
So, what does it mean to 'sanitise' such an input ? You can not do it by an
external mean (external to JEXL); well, you could, but then there is almost no
point in using JEXL then since you'd already done most of the hardwork of
syntactic and semantic checks.
Assuming then that the only practical way to control what a script can do is
through JEXL itself; splitting the platform scripting feature using different
classes/modules/jars still requires configuring these environments properly.
And we cannot do this through JEXL jars since we can't know those environment
constraints before hand.
My proposal of enforcing a default configuration with a very narrow
permeability is meant to ensure the platform developers at least realise they
have to think about what they expose to whom.
Quoting from the project's home page:
"Its goal is to expose scripting features usable by technical operatives
or consultants working with enterprise platforms."
I read that as the typical/expected usage scenario is with trusted
input. I don't think we should break the typical usage to benefit an
atypical one.
Isn't this the resolution strategy we used for the latest log4j2 and text CVEs
- Avoid defauit configurations that are too permissive ?
Too permissive for what?
You have to consider the software in the context it is intended to be
used. We don't consider Java to have an RCE because System.exec()
exists. If an application developer was daft enough to expose
System.exec() functionality to untrusted users, it would be treated as
an application vulnerability, not as a Java issue.
The same consideration applies when considering JEXL. How is it intended
to be used? / How is it typically used? Everything I have seen suggests
that the intended / typical usage is with trusted input.
Mark
The primary driver for my thinking is observation of projects that have
tried to separate safe and unsafe functions via configuration and the
steady stream CVEs raised against those projects as security researchers
find ways to bypass the filtering. If there is a requirement to support
unsafe input then I think a stronger separation is required.
One solution would be different scripting engines for the two use cases
(trusted and untrusted) but that is likely to result in duplicate code
of some form - something else that I don't like.
Not knowing JEXL at all, would it be possible to have a "safe" JAR that
only provided features for untrusted input and an "extension" JAR you
could add to enable all the "dangerous" features for use with trusted input?
Mark
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
