You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Henri Biestro (Apache)" <he...@apache.org> on 2022/10/24 16:02:58 UTC
JEXL Security
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. :-)
Thanks
Henrib
Re: JEXL Security
Posted by Henri Biestro <he...@apache.org>.
> You have to consider the software in the context it is intended to be
> used.
Thank you for clarifying and illustrating those notions. We are in agreement about JEXL intended usage and where the responsibility lies wrt security choices.
But even in its usage context, with authenticated users, whether you allow files to be created or read or processes to be created should carefully be pondered and reflect a functional necessity. Security guys will say that authenticated users can still have a nefarious intent so users should only be allowed to access and use what is required to perform their duties...
> 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.
Considering how complex and complicated software can be, I know I've been daft (on occasion hopefully) by lack of knowledge. A more secure default would avoid the daft configuration error, the one where you don't even know you are making a bad choice because you don't know enough yet. The goal is that we make it harder to ignore JEXL security configuration and if you do, we try and prevent the obvious security holes.
With no explicit security configuration, as-is, 'System.exit()' is callable; surely, a better default should be proposed.
Henri
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: JEXL Security
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: JEXL Security
Posted by Henri Biestro <he...@apache.org>.
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.
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.
Isn't this the resolution strategy we used for the latest log4j2 and text CVEs - Avoid defauit configurations that are too permissive ?
>
> 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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: JEXL Security
Posted by Mark Thomas <ma...@apache.org>.
On 26/10/2022 08:58, Henri Biestro wrote:
> Fair points, thank you. They seem to lead into the point of view that JEXL (or any scripting solution?) should not expose any feature that could be considered security-related avoiding the CVE potential turmoils alltogether. Trusted sanitised input is expected and required so this is a moot discussion.
>
> In the EPM field at least, there are real world users who would like to have ways to express a computation, a formula, a label, - anything from a one line expression, snippet to script -through the platform/application they use daily - rather than depend and wait for IT/consultants/software-vendors to implement it. I'm not saying it is reasonable or achievable but is desired. The latest low-code hype is probably fuelled by the same functional needs.
>
> Anyhow, it seems reasonable - at least useful - to help control the danger of allowing 'scripting' in a platform. It seems we reduce little of that issue if our stance on security is 'the only scripts you should run are scripts that are trusted'. Even a 'trusted user' can have a nefarious intent...
> A 'sanitised input' can only be enforced by configuring precisely the (JEXL) engine (JexlPermissions, JexlFeatures, JexlOptions). Even if we rightfully reject any CVE due to a poorly configured engine, we can probably avoid the obvious ones in the first place.
>
> Wether security should be addressed by some features seems to be the underlying chasm... Interesting conundrum :-)
Indeed.
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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: JEXL Security
Posted by Henri Biestro <he...@apache.org>.
Fair points, thank you. They seem to lead into the point of view that JEXL (or any scripting solution?) should not expose any feature that could be considered security-related avoiding the CVE potential turmoils alltogether. Trusted sanitised input is expected and required so this is a moot discussion.
In the EPM field at least, there are real world users who would like to have ways to express a computation, a formula, a label, - anything from a one line expression, snippet to script -through the platform/application they use daily - rather than depend and wait for IT/consultants/software-vendors to implement it. I'm not saying it is reasonable or achievable but is desired. The latest low-code hype is probably fuelled by the same functional needs.
Anyhow, it seems reasonable - at least useful - to help control the danger of allowing 'scripting' in a platform. It seems we reduce little of that issue if our stance on security is 'the only scripts you should run are scripts that are trusted'. Even a 'trusted user' can have a nefarious intent...
A 'sanitised input' can only be enforced by configuring precisely the (JEXL) engine (JexlPermissions, JexlFeatures, JexlOptions). Even if we rightfully reject any CVE due to a poorly configured engine, we can probably avoid the obvious ones in the first place.
Wether security should be addressed by some features seems to be the underlying chasm... Interesting conundrum :-)
>
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: JEXL Security
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org