Introduced protections against system command injection
This change hardens all instances of Runtime#exec() to offer protection against attack.
Left unchecked, Runtime#exec() can execute any arbitrary system command. If an attacker can control part of the strings used to as program paths or arguments, they could execute arbitrary programs, install malware, and anything else they could do if they had a shell open on the application host.
Our change introduces a sandbox which protects the application:
+ import io.github.pixee.security.SystemCommand;
...
- Process p = Runtime.getRuntime().exec(command);
+ Process p = SystemCommand.runCommand(Runtime.getRuntime(), command);
The default restrictions applied are the following:
- Prevent command chaining. Many exploits work by injecting command separators and causing the shell to interpret a second, malicious command. The
SystemCommand#runCommand()attempts to parse the given command, and throw aSecurityExceptionif multiple commands are present. - Prevent arguments targeting sensitive files. There is little reason for custom code to target sensitive system files like
/etc/passwd, so the sandbox prevents arguments that point to these files that may be targets for exfiltration.
There are more options for sandboxing if you are interested in locking down system commands even more.
More reading
Powered by: pixeebot (codemod ID: pixee:java/harden-process-creation)
Hi zcarroll4,
We are updating Stirling-PDF's license to MPL 2.0 (Mozilla Public License Version 2.0) to continue fostering our open-source commitment while introducing more flexible usage of the project.
What We Need From You:
In order to transition to the MPL 2.0 license, we need the explicit consent of all our contributors.
- If you're comfortable relicensing your contributions for this specific PR under MPL 2.0, please respond with:
I, zcarroll4, grant permission to relicense my contributions from this PR to Stirling-PDF under the Mozilla Public License 2.0. - If you'd prefer to give blanket permission for all of your contributions to Stirling-PDF (be it through pull requests, commits, or any other form of contribution) rather than on a PR-by-PR basis, please respond with:
I, zcarroll4, grant permission to relicense all my contributions to Stirling-PDF under the Mozilla Public License 2.0.
What does this do and why?
As your old code was contributed under a different license it legally cannot move to a new license without your permission, and since we dont want to lose your code we wanted to reach out. Remember this project is remaining open-source!.
Deadline:
If we dont receive a response, or if you decline, unfortunately, we will have to remove your contributions from Stirling-PDF before the license change, which is scheduled in coming months.
Thank You!
Your contributions are invaluable, and we hope to continue having them in Stirling-PDF under the new license. Feel free to ask if you have any questions or concerns about this change.
Best, Frooodle Stirling-PDF Maintainer
@Frooodle I, zcarroll4, grant permission to relicense all my contributions to Stirling-PDF under the Mozilla Public License 2.0.