Skip to content

Latest commit

 

History

History
125 lines (100 loc) · 8.02 KB

mitigations.md

File metadata and controls

125 lines (100 loc) · 8.02 KB

Mitigation Strategies Analysis for jenkinsci/job-dsl-plugin

Mitigation Strategy: Principle of Least Privilege (DSL Script Execution Context)

Description:

  1. Create a dedicated Jenkins user specifically for executing Job DSL scripts. Do not use an existing administrative or highly privileged user.
  2. Navigate to "Manage Jenkins" -> "Manage Users" -> "Create User".
  3. Provide a username and password for the new user.
  4. Navigate to "Manage Jenkins" -> "Configure Global Security".
  5. Ensure that a security realm is configured (e.g., "Jenkins’ own user database").
  6. Under "Authorization", select either "Matrix-based security" or "Role-Based Strategy" (requires the Role-based Authorization Strategy plugin). Do not use "Anyone can do anything".
  7. If using "Matrix-based security":
    • Add the newly created DSL user to the matrix.
    • Grant only the following permissions to this user: Job/Create, Job/Configure, Job/Read, Job/Build, View/Create, View/Configure, View/Read. Explicitly deny all other permissions. Carefully consider whether Job/Build is truly needed.
  8. If using "Role-Based Strategy":
    • Create a new role (e.g., "dsl-executor").
    • Assign only the necessary permissions (listed above) to this role.
    • Assign the newly created DSL user to this role.
  9. In the "Process Job DSLs" build step configuration of your seed job, ensure that the "Run as" option is set to the dedicated DSL user. This is a direct configuration of the Job DSL plugin.

Threats Mitigated:

  • Arbitrary Code Execution (High Severity): If a malicious actor injects code into the DSL script (which is Groovy executed by the plugin), the damage is limited to the permissions of the restricted user.
  • Privilege Escalation (High Severity): Prevents an attacker from leveraging a compromised DSL script to gain administrative privileges via the plugin's execution context.
  • Data Exfiltration (High Severity): Limits the attacker's ability to access sensitive data stored within Jenkins, which the DSL script might try to access.
  • System Compromise (High Severity): Prevents the attacker from using the DSL script to execute arbitrary commands on the Jenkins server, as the script runs with limited OS-level permissions.

Impact:

  • Arbitrary Code Execution: Risk significantly reduced. Impact limited to the restricted user's permissions.
  • Privilege Escalation: Risk almost entirely mitigated.
  • Data Exfiltration: Risk significantly reduced.
  • System Compromise: Risk significantly reduced.

Currently Implemented:

  • Partially implemented. A dedicated user dsl_user exists. Matrix-based authorization is used. However, dsl_user currently has Overall/Administer permission.

Missing Implementation:

  • The dsl_user needs to have its permissions drastically reduced. Overall/Administer must be revoked.

Mitigation Strategy: Sandboxing the DSL Script Execution

Description:

  1. In your seed job configuration, navigate to the "Process Job DSLs" build step provided by the Job DSL Plugin.
  2. Check the box labeled "Use Groovy Sandbox". This is a direct setting within the Job DSL Plugin's configuration.
  3. After enabling the sandbox, run the seed job.
  4. Monitor the Jenkins UI for "Script Approval" requests (also a feature directly related to the Job DSL Plugin's sandbox).
  5. For each script approval request:
    • Carefully examine the requested method or class.
    • Research the method/class.
    • Determine if the access is absolutely necessary.
    • Approve or deny based on necessity and safety. Never blindly approve.
  6. Regularly review the approved scripts.

Threats Mitigated:

  • Arbitrary Code Execution (High Severity): The sandbox provided by the Job DSL Plugin restricts the capabilities of the Groovy code.
  • System Compromise (High Severity): Prevents the DSL script from executing arbitrary system commands.
  • Data Exfiltration (High Severity): Limits the script's ability to access sensitive data.
  • Plugin Interaction (Medium Severity): Prevents unauthorized interaction with other plugins, a common target of malicious DSL scripts.

Impact:

  • Arbitrary Code Execution: Risk significantly reduced.
  • System Compromise: Risk significantly reduced.
  • Data Exfiltration: Risk significantly reduced.
  • Plugin Interaction: Risk reduced.

Currently Implemented:

  • The "Use Groovy Sandbox" option is enabled. A few initial script approvals have been granted.

Missing Implementation:

  • A thorough review of all existing script approvals is needed. Ongoing monitoring is crucial.

Mitigation Strategy: Input Validation and Sanitization (Seed Job Configuration)

Description:

  1. Identify all parameters accepted by your seed job that are used within the DSL script processed by the Job DSL Plugin.
  2. For each parameter:
    • Define the expected data type, format, allowed values, and acceptable ranges.
  3. Implement validation checks before the parameter values are used within the DSL script.
  4. Reject invalid input and provide a clear error message.
  5. Use a templating engine (e.g., StringTemplate) to separate the DSL script logic from the user-provided data that will be processed by the Job DSL Plugin.
  6. If direct embedding is unavoidable, use appropriate escaping or encoding.

Threats Mitigated:

  • Code Injection (High Severity): Prevents attackers from injecting malicious Groovy code into the DSL script that is executed by the Job DSL Plugin.
  • Cross-Site Scripting (XSS) (Medium Severity): If the DSL script generates output displayed in the UI, this helps.
  • Unexpected Behavior (Low Severity): Prevents the DSL script from behaving unexpectedly.

Impact:

  • Code Injection: Risk significantly reduced.
  • Cross-Site Scripting (XSS): Risk reduced.
  • Unexpected Behavior: Risk significantly reduced.

Currently Implemented:

  • Minimal implementation. The seed job accepts a repositoryUrl parameter, but there is no validation.

Missing Implementation:

  • Comprehensive input validation and sanitization are missing for the repositoryUrl parameter.

Mitigation Strategy: Avoid using readFileFromWorkspace and similar methods without strict validation (within the DSL Script)

Description:

  1. Identify all instances within your DSL scripts where readFileFromWorkspace, archiveArtifacts, or similar methods (provided by Jenkins core but used within the DSL script processed by the Job DSL Plugin) are used.
  2. For each instance:
    • Ensure the file path is constructed using only trusted data.
    • Sanitize user input before incorporating it into the file path.
    • Use relative paths and avoid absolute paths.
    • Consider a dedicated subdirectory.
    • Validate that the file path does not contain path traversal sequences.
    • Log all file access attempts.

Threats Mitigated:

  • Path Traversal (High Severity): Prevents attackers from accessing arbitrary files via the DSL script's execution.
  • Data Exfiltration (High Severity): Limits the attacker's ability to read sensitive files.
  • System Compromise (High Severity): Prevents reading system files.

Impact:

  • Path Traversal: Risk significantly reduced.
  • Data Exfiltration: Risk significantly reduced.
  • System Compromise: Risk significantly reduced.

Currently Implemented:

  • Not applicable. The current DSL scripts do not use these methods.

Missing Implementation:

  • If these methods are introduced, the described mitigation steps must be implemented. Code reviews should check for this.