Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security related issue with System.getenv #2069

Closed
parrt opened this issue Oct 23, 2017 · 0 comments
Closed

Security related issue with System.getenv #2069

parrt opened this issue Oct 23, 2017 · 0 comments

Comments

@parrt
Copy link
Member

parrt commented Oct 23, 2017

Sebastien Lannez informed me...

There is an issue/bad security practice in one of the class. I discovered it because it caused application crashes in one of our secure environment.

ParserATNSimulator.java (line 273)

public static final boolean TURN_OFF_LR_LOOP_ENTRY_BRANCH_OPT = boolean.parseBoolean(System.getenv("TURN_OFF_LR_LOOP_ENTRY_BRANCH_OPT"));

This line should be rewritten such that it catches SecurityException. Acessing environment variables is sometime forbidden in secure environment (like PCI compliant system…). The code change should be as simple as doing:

public static final boolean TURN_OFF_LR_LOOP_ENTRY_BRANCH_OPT = boolean.parseBoolean(getSafeEnv("TURN_OFF_LR_LOOP_ENTRY_BRANCH_OPT"));

and then :

public static String getSafeEnv(String envName) {
   try {
     return = System.getenv("TURN_OFF_LR_LOOP_ENTRY_BRANCH_OPT"));
   } catch(SecurityException e) {
     // do nothing
   }
   return "";
 }

Note that you could also want to catch all Exception…

I can't properly catch the exception and resume execution because it occurs in your library. If I catch it, then I can't resume where it was thrown.

For this particular security issue (retrieving an environment variable), if you are not allowed to do it, then it is just fine to use the default value given it is also the expected behavior when the environment variable is missing.

Only when there is no fallback or default behavior the Security Exception must be handled by the calling app (for example when the lib is trying to access a file that is not located in a permitted folder but required for the lib to execute properly).

@parrt parrt added this to the 4.7.1 milestone Oct 23, 2017
@parrt parrt self-assigned this Oct 23, 2017
@parrt parrt closed this as completed in aaa4250 Oct 23, 2017
parrt added a commit that referenced this issue Oct 23, 2017
Fixes #2069 to catch env var security exception
alecharp added a commit to alecharp/pmd that referenced this issue Oct 20, 2020
A security fix is included in this version. See antlr/antlr4#2069.
bonita-ci pushed a commit to bonitasoft/bonita-engine that referenced this issue Apr 5, 2022
Fixes antlr/antlr4#2069

antlr4-runtime is a transitive dependency of squiggly-filter-jackson
This PR has the same principle as for the Guava update : #2134
bonita-ci pushed a commit to bonitasoft/bonita-engine that referenced this issue Apr 5, 2022
Fixes antlr/antlr4#2069

antlr4-runtime is a transitive dependency of squiggly-filter-jackson
This PR has the same principle as for the Guava update : #2134
bonita-ci pushed a commit to bonitasoft/bonita-engine that referenced this issue Apr 8, 2022
Fixes antlr/antlr4#2069

antlr4-runtime is a transitive dependency of squiggly-filter-jackson
This PR has the same principle as for the Guava update : #2134
bonita-ci pushed a commit to bonitasoft/bonita-engine that referenced this issue Apr 8, 2022
Fixes antlr/antlr4#2069

antlr4-runtime is a transitive dependency of squiggly-filter-jackson
This PR has the same principle as for the Guava update : #2134
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant