Fix ModelManager Uncontrolled command line dependencyPath

[odaysec]

serve/frontend/server/src/main/java/org/pytorch/serve/wlm/ModelManager.java

Line 332 in 62c4d6a

processBuilder.directory(dependencyPath);

serve/frontend/server/src/main/java/org/pytorch/serve/wlm/ModelManager.java

Lines 383 to 389 in 62c4d6a

	if (dependencyPath
	.toPath()
	.normalize()
	.startsWith(FileUtils.getTempDirectory().toPath().normalize())) {
	return true;
	}
	return false;

Code that passes user input directly to Runtime.exec, or some other library routine that executes a command, allows the user to execute malicious code. The following shows code that takes a shell script that can be changed maliciously by a user, and passes it straight to Runtime.exec without examining it first.

class Test {
    public static void main(String[] args) {
        String script = System.getenv("Pwned");
        if (script != null) {
            // BAD: The script to be executed is controlled by the user.
            Runtime.getRuntime().exec(script);
        }
    }
}

fix the issue must ensure that user-controlled input is properly sanitized and validated before it is used in a command execution context. Specifically:

1. Restrict the dependencyPath to known-safe directories:

   • Expand the validation in isValidDependencyPath() to ensure that the path resolves to a pre-approved, hard-coded directory (e.g., within a specific application-controlled directory tree).

2. Reject symbolic links and enforce canonical paths:

   • Ensure that dependencyPath does not point to a symbolic link or any unintended location. Use File.getCanonicalPath() for validation.

3. Construct the command using only sanitized paths:

   • Use validated and canonicalized paths when constructing the ProcessBuilder command.

4. Log and handle invalid paths appropriately:

   • If the dependencyPath validation fails, throw an exception and log the issue.

References

IDS07-J. Sanitize untrusted data passed to the Runtime.exec() method
Command Injection

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

Feature/Issue validation/testing

Please describe the Unit or Integration tests that you ran to verify your changes and relevant result summary. Provide instructions so it can be reproduced.
Please also list any relevant details for your test configuration.

• Test A
  Logs for Test A

• Test B
  Logs for Test B

Checklist:

• Did you have fun?
• Have you added tests that prove your fix is effective or that this feature works?
• Has code been commented, particularly in hard-to-understand areas?
• Have you made corresponding changes to the documentation?

[odaysec]

/ping merged:master