Find, fix and prevent vulnerabilities in your code.

Overview

org.jenkins-ci.plugins:script-security is a package that allows Jenkins administrators to control what in-process scripts can be run by less-privileged users.

Affected versions of this package are vulnerable to Access Restriction Bypass due to property assignments performed implicitly by the Groovy language runtime when invoking map constructors not being executed in a sandbox.This allows users with permissions to define and run sandboxed scripts to execute arbitrary code in the context of the Jenkins controller JVM.

Remediation

A fix was pushed into the master branch but not yet published.

References

• GitHub Commit
• Jenkins Security Advisory

Overview

org.jenkins-ci.plugins:junit provides a publisher that consumes XML test reports generated during the builds and provides some graphical visualization of the historical test results.

Affected versions of this package are vulnerable to XML External Entity (XXE) Injection in files it parses as part of the build process. It allows attackers with user permissions in Jenkins to extract secrets from the Jenkins master, perform server-side request forgery, or denial-of-service attacks.

Details

XXE Injection is a type of attack against an application that parses XML input. XML is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. By default, many XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. When an XML document is being parsed, the parser can make a request and include the content at the specified URI inside of the XML document.

Attacks can include disclosing local files, which may contain sensitive data such as passwords or private user data, using file: schemes or relative paths in the system identifier.

For example, below is a sample XML document, containing an XML element- username.

<?xml version="1.0" encoding="ISO-8859-1"?>
   <username>John</username>
</xml>

An external XML entity - xxe, is defined using a system identifier and present within a DOCTYPE header. These entities can access local or remote content. For example the below code contains an external XML entity that would fetch the content of /etc/passwd and display it to the user rendered by username.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
   <username>&xxe;</username>
</xml>

Other XXE Injection attacks can access local resources that may not stop returning data, possibly impacting application availability and leading to Denial of Service.

Remediation

Upgrade org.jenkins-ci.plugins:junit to version 1.24 or higher.

References

• Jenkins Security Advisory
• GitHub Commit

Overview

Affected versions of this package are vulnerable to Cross-site Scripting (XSS) due to converting HTTP(S) URLs in test report output to clickable links, by allowing attackers with Item/Configure permission to exploit this vulnerability.

Details

A cross-site scripting attack occurs when the attacker tricks a legitimate web-based application or site to accept a request as originating from a trusted source.

This is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.

Injecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.

Escaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, < can be coded as &lt; and > can be coded as &gt; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses < and > as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.

The most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware.

Types of attacks

There are a few methods by which XSS can be manipulated:

Affected environments

The following environments are susceptible to an XSS attack:

• Web servers
• Application servers
• Web application environments

How to prevent

This section describes the top best practices designed to specifically protect your code:

• Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches.
• Convert special characters such as ?, &, /, <, > and spaces to their respective HTML or URL encoded equivalents.
• Give users the option to disable client-side scripts.
• Redirect invalid requests.
• Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.
• Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.
• Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.

Remediation

A fix was pushed into the master branch but not yet published.

References

• GitHub Commit
• Jenkins Security Advisory

Overview

org.jenkins-ci.plugins:script-security is a package that allows Jenkins administrators to control what in-process scripts can be run by less-privileged users.

Affected versions of this package are vulnerable to Use of Weak Hash by checking approved scripts against their SHA-1 hashes only, which is not sufficiently secure.

Remediation

A fix was pushed into the master branch but not yet published.

References

• GitHub Commit
• Jenkins Security Advisory

Overview

org.jenkins-ci.plugins.workflow:workflow-support is a plugin that provides APIs that are used by core Pipeline plugins for features such as persistence and step visualization.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS) due to not sanitizing or properly encoding URLs of hyperlinks in build logs.

Details

A cross-site scripting attack occurs when the attacker tricks a legitimate web-based application or site to accept a request as originating from a trusted source.

This is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.

Injecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.

Escaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, < can be coded as &lt; and > can be coded as &gt; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses < and > as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.

The most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware.

Types of attacks

There are a few methods by which XSS can be manipulated:

Affected environments

The following environments are susceptible to an XSS attack:

• Web servers
• Application servers
• Web application environments

How to prevent

This section describes the top best practices designed to specifically protect your code:

• Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches.
• Convert special characters such as ?, &, /, <, > and spaces to their respective HTML or URL encoded equivalents.
• Give users the option to disable client-side scripts.
• Redirect invalid requests.
• Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.
• Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.
• Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.

Remediation

A fix was pushed into the master branch but not yet published.

References

• GitHub Commit
• Jenkins Security Advisory

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling. An attacker can cause indefinite amounts of memory to be used by inputting a string of modest size. This can lead to a Denial of Service.

PoC

package orgjsonbug;

import org.json.JSONObject;

/**
 * Illustrates a bug in JSON-Java.
 */
public class Bug {
  private static String makeNested(int depth) {
    if (depth == 0) {
      return "{\"a\":1}";
    }
    return "{\"a\":1;\t\0" + makeNested(depth - 1) + ":1}";
  }

  public static void main(String[] args) {
    String input = makeNested(30);
    System.out.printf("Input string has length %d: %s\n", input.length(), input);
    JSONObject output = new JSONObject(input);
    System.out.printf("Output JSONObject has length %d: %s\n", output.toString().length(), output);
  }
}

Remediation

Upgrade org.json:json to version 20231013 or higher.

References

• GitHub Commit
• GitHub Issue
• GitHub Issue

Overview

Affected versions of this package are vulnerable to Denial of Service (DoS) when trying to initialize a JSONArray object and the input is [. This will cause the jvm to crash with StackOverflowError due to non-cyclical stack overflow.

PoC

new JSONArray("[")

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade org.json:json to version 20180130 or higher.

References

• GitHub Commit
• GItHub Issue
• GitHub PR

Overview

Affected versions of this package are vulnerable to Denial of Service (DoS) in the XML.toJSONObject component via crafted JSON or XML data.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade org.json:json to version 20230227 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Issue
• GitHub Issue

Overview

org.jenkins-ci.plugins:script-security is a package that allows Jenkins administrators to control what in-process scripts can be run by less-privileged users.

Affected versions of this package are vulnerable to Protection Mechanism Failure due to a sandbox bypass vulnerability involving crafted constructor bodies and calls to sandbox-generated synthetic constructors. Exploiting this vulnerability allows attackers with permission to define and run sandboxed scripts, including Pipelines, to bypass the sandbox protection and execute arbitrary code in the context of the Jenkins controller JVM.

Remediation

A fix was pushed into the master branch but not yet published.

References

• GitHub Commit
• GitHub PR
• Jenkins Release Notes
• Jenkins Release Notes
• Jenkins Security Advisory

Overview

org.jenkins-ci.plugins:script-security is a package that allows Jenkins administrators to control what in-process scripts can be run by less-privileged users.

Affected versions of this package are vulnerable to Protection Mechanism Failure when various casts performed implicitly by the Groovy language runtime were not intercepted by the sandbox. Exploiting this vulnerability allows attackers with permission to define and run sandboxed scripts, including Pipelines, to bypass the sandbox protection and execute arbitrary code in the context of the Jenkins controller JVM.

Remediation

A fix was pushed into the master branch but not yet published.

References

• GitHub Commit
• Jenkins Release Notes
• Jenkins Release Notes
• Jenkins Security Advisory

Overview

org.jenkins-ci.plugins:script-security is a package that allows Jenkins administrators to control what in-process scripts can be run by less-privileged users.

Affected versions of this package are vulnerable to Protection Mechanism Failure when casting an array-like value to an array type, per-element casts to the component type of the array are not intercepted by the sandbox. Exploiting this vulnerability allows attackers with permission to define and run sandboxed scripts, including Pipelines, to bypass the sandbox protection and execute arbitrary code in the context of the Jenkins controller JVM.

Remediation

A fix was pushed into the master branch but not yet published.

References

• GitHub Commit
• GitHub PR
• Jenkins Release Notes
• Jenkins Release Notes
• Jenkins Security Advisory