A cross-site request forgery vulnerability in Jenkins Maven Release Plugin 0.14.0 and earlier in the M2ReleaseAction#doSubmit method allowed attackers to perform releases with attacker-specified options.

This advisory announces vulnerabilities in the following Jenkins deliverables:

*   Amazon EC2 Plugin
*   Configuration as Code Plugin
*   Google Kubernetes Engine Plugin
*   Maven Integration Plugin
*   Maven Release Plug-in Plugin
*   Pipeline: Deprecated Groovy Libraries Plugin
*   Script Security Plugin
*   Skytap Cloud CI Plugin

**Descriptions****Sandbox bypass through type casts in Script Security Plugin**

**SECURITY-1465 (1) / CVE-2019-10355**  
**Severity (CVSS):** High  
**Affected plugin: script-security**  
**Description:**

Sandbox protection in Script Security Plugin could be circumvented by casting crafted objects to other types. This allowed attackers able to specify sandboxed scripts to invoke constructors that weren’t approved.

Additionally, this could be used to read arbitrary files on the Jenkins controller.

Casting collections to other types as an alternative syntax for constructor invocation is now only allowed when the collection type is defined in java.util, and prohibited otherwise. Casting files and enums to arrays is now intercepted by the sandbox and treated as the invocation of an equivalent method.

**Sandbox bypass through method pointer expressions in Script Security Plugin**

**SECURITY-1465 (2) / CVE-2019-10356**  
**Severity (CVSS):** High  
**Affected plugin: script-security**  
**Description:**

Sandbox protection in Script Security Plugin could be circumvented through crafted subexpressions used as arguments to method pointer expressions. This allowed attackers able to specify sandboxed scripts to execute arbitrary code in the context of the Jenkins controller JVM.

Method pointer subexpressions are now subject to sandbox protection.

**Missing permission check in Pipeline: Deprecated Groovy Libraries Plugin**

**SECURITY-1422 / CVE-2019-10357**  
**Severity (CVSS):** Medium  
**Affected plugin: workflow-cps-global-lib**  
**Description:**

Pipeline: Deprecated Groovy Libraries Plugin provides form validation to determine whether the revision (e.g. commit, tag, or branch name) specified for a global library exists in the repository. This form validation method lacked a permission check, allowing attackers with Overall/Read access to determine whether an attacker-specified revision exists in an SCM repository configured for use in an existing shared library.

Pipeline: Deprecated Groovy Libraries Plugin now performs the appropriate permission check.

**Maven Integration Plugin did not mask sensitive values in module build logs**

**SECURITY-713 / CVE-2019-10358**  
**Severity (CVSS):** Medium  
**Affected plugin: maven-plugin**  
**Description:**

Maven Integration Plugin did not apply build log decorators from the Build Environment configuration to module builds. This could prevent sensitive content in module build logs from being masked.

Maven Integration Plugin now applies build log decorators from the Build Environment configuration to module builds.

**CSRF vulnerability in Maven Release Plug-in Plugin**

**SECURITY-1098 / CVE-2019-10359**  
**Severity (CVSS):** Medium  
**Affected plugin: m2release**  
**Description:**

Maven Release Plug-in Plugin did not require that requests sent to the endpoint used to initiate the release process use POST. This resulted in a cross-site request forgery vulnerability that allows attackers to perform releases.

Maven Release Plug-in Plugin now requires that these requests be sent via POST.

**Stored XSS vulnerability in Maven Release Plug-in Plugin**

**SECURITY-1184 / CVE-2019-10360**  
**Severity (CVSS):** Medium  
**Affected plugin: m2release**  
**Description:**

Maven Release Plug-in Plugin did not properly escape variables in multiple views, resulting in a stored cross-site scripting vulnerability.

Variables on affected views are now escaped.

**Maven Release Plug-in Plugin stored credentials in plain text**

**SECURITY-1435 / CVE-2019-10361**  
**Severity (CVSS):** Low  
**Affected plugin: m2release**  
**Description:**

Maven Release Plug-in Plugin stored credentials unencrypted in its global configuration file org.jvnet.hudson.plugins.m2release.M2ReleaseBuildWrapper.xml on the Jenkins controller. These credentials could be viewed by users with access to the Jenkins controller file system.

Maven Release Plug-in Plugin now stores credentials encrypted.

**Configuration as Code Plugin failed to mask secrets in system log messages**

**SECURITY-1279 / CVE-2019-10343**  
**Severity (CVSS):** Medium  
**Affected plugin: configuration-as-code**  
**Description:**

Configuration as Code Plugin logs the changes it applies to the Jenkins system log. Secrets such as passwords should be masked (i.e. replaced with asterisks) in that log to prevent accidental disclosure.

Between Configuration as Code Plugin 0.8-alpha and 1.0, log messages contained values if the values were specified using properties in the YAML file (SECURITY-929).

Since Configuration as Code Plugin 1.1, log messages in Configuration as Code Plugin instead mask values of type Secret, which is used in Jenkins to store the values encrypted on disk. This did not work in many instances, as plugins could use the Secret type to store credentials encrypted on disk while not having the Secret type appear in their Java API.

Configuration as Code Plugin now inspects the type and looks for a field, getter, or constructor argument corresponding to the property, making the secret detection much more robust for the purpose of log message masking.

As a workaround, administrators can configure the logging level of the logger io.jenkins.plugins.casc.Attribute to a level that does not include INFO messages. See the logging documentation for details.

**Configuration as Code Plugin allowed users without Overall/Administer permission to access documentation**

**SECURITY-1290 / CVE-2019-10344**  
**Severity (CVSS):** Medium  
**Affected plugin: configuration-as-code**  
**Description:**

Configuration as Code Plugin provides a generated schema and reference documentation for the configuration options supported on the current Jenkins instance. These URLs did not perform additional permission checks, resulting in their content being available to users with Overall/Read access. This included detailed information about installed plugins that may not be available otherwise.

Access to these URLs is now restricted to users with Overall/Administer permission.

**Configuration as Code Plugin did not mask proxy credentials**

**SECURITY-1303 / CVE-2019-10345**  
**Severity (CVSS):** Low  
**Affected plugin: configuration-as-code**  
**Description:**

Configuration as Code Plugin provides a custom configurator for the Jenkins proxy configuration.

This feature did not mask the password for logging or encrypt it in the export.

Configuration as Code Plugin 1.20 and newer mask the Jenkins proxy password when logged and only store it encrypted in the export.

**Configuration as Code Plugin evaluated variable references when importing a previously exported configuration**

**SECURITY-1446 / CVE-2019-10362**  
**Severity (CVSS):** Medium  
**Affected plugin: configuration-as-code**  
**Description:**

Configuration as Code Plugin allows exporting the live Jenkins configuration, as well as importing and applying a configuration provided in the same format. One of the features of the import is that it allows specifying variable references (e.g. ${VARIABLE_NAME}) in the configuration YAML file. These will be replaced by the value of the corresponding environment variable (or other source of secrets) during import (interpolation). If such a value should not be interpolated, the escape character ^ can be used before (e.g. ^${VARIABLE_NAME}).

Exporting did not add ^ escape characters to exported strings, such as various entity descriptions. This allowed attackers with permission to configure certain entities, such as credentials or agents, to specify crafted descriptions containing variable references. These would be replaced by the corresponding environment variable’s value during a subsequent import.

The export now adds ^ escape characters to exported strings as needed to prevent them from being interpolated during import. Previously exported configurations may require manual cleanup by Jenkins admins before being imported.

**Configuration as Code Plugin exported secret values in plain text**

**SECURITY-1458 / CVE-2019-10363**  
**Severity (CVSS):** Medium  
**Affected plugin: configuration-as-code**  
**Description:**

Configuration as Code Plugin allows to export the current Jenkins configuration as a YAML file. Secrets such as passwords should be exported in their encrypted form to prevent accidental disclosure.

Configuration as Code Plugin did not reliably detect which values in the exported YAML file need to be considered sensitive (e.g. credentials and other secrets), as plugins could use the Secret type to store credentials encrypted on disk while not having the Secret type appear in their Java API. This resulted in credentials being exported in plain text in some cases.

Configuration as Code Plugin now inspects the type and looks for a field, getter, or constructor argument corresponding to the property, making the secret detection much more robust for the purpose of exporting encrypted secrets.

**Amazon EC2 Plugin leaked beginning of private key in system log**

**SECURITY-673 / CVE-2019-10364**  
**Severity (CVSS):** Medium  
**Affected plugin: ec2**  
**Description:**

Amazon EC2 Plugin printed a log message that contained the beginning of the private key to the Jenkins system log.

The log message no longer includes the beginning of the private key.

**Google Kubernetes Engine Plugin stored temporary secret in a user accessible location**

**SECURITY-1345 / CVE-2019-10365**  
**Severity (CVSS):** Medium  
**Affected plugin: google-kubernetes-engine**  
**Description:**

Google Kubernetes Engine Plugin created a temporary file named .kube…config containing a temporary access token in the project workspace. This allowed the file to be accessed via workspace browsers, or accidentally archived, disclosing the token.

This temporary file is now created outside the regular project workspace.

**Skytap Cloud CI Plugin stored credentials in plain text**

**SECURITY-1429 / CVE-2019-10366**  
**Severity (CVSS):** Medium  
**Affected plugin: skytap**  
**Description:**

Skytap Cloud CI Plugin stored credentials unencrypted in job config.xml files on the Jenkins controller. These credentials could be viewed by users with Extended Read permission, or access to the Jenkins controller file system.

Skytap Cloud CI Plugin now stores credentials encrypted.

**Severity**

*   SECURITY-673: Medium
*   SECURITY-713: Medium
*   SECURITY-1098: Medium
*   SECURITY-1184: Medium
*   SECURITY-1279: Medium
*   SECURITY-1290: Medium
*   SECURITY-1303: Low
*   SECURITY-1345: Medium
*   SECURITY-1422: Medium
*   SECURITY-1429: Medium
*   SECURITY-1435: Low
*   SECURITY-1446: Medium
*   SECURITY-1458: Medium
*   SECURITY-1465 (1): High
*   SECURITY-1465 (2): High

**Affected Versions**

*   **Amazon EC2 Plugin** up to and including 1.43
*   **Configuration as Code Plugin** up to and including 1.24
*   **Google Kubernetes Engine Plugin** up to and including 0.6.2
*   **Maven Integration Plugin** up to and including 3.3
*   **Maven Release Plug-in Plugin** up to and including 0.14.0
*   **Pipeline: Deprecated Groovy Libraries Plugin** up to and including 2.14
*   **Script Security Plugin** up to and including 1.61
*   **Skytap Cloud CI Plugin** up to and including 2.06

**Fix**

*   **Amazon EC2 Plugin** should be updated to version 1.44
*   **Configuration as Code Plugin** should be updated to version 1.25
*   **Google Kubernetes Engine Plugin** should be updated to version 0.6.3
*   **Maven Integration Plugin** should be updated to version 3.4
*   **Maven Release Plug-in Plugin** should be updated to version 0.15.0
*   **Pipeline: Deprecated Groovy Libraries Plugin** should be updated to version 2.15
*   **Script Security Plugin** should be updated to version 1.62
*   **Skytap Cloud CI Plugin** should be updated to version 2.07

These versions include fixes to the vulnerabilities described above. All prior versions are considered to be affected by these vulnerabilities unless otherwise indicated.

**Credit**

The Jenkins project would like to thank the reporters for discovering and reporting these vulnerabilities:

*   **Alex Earl (@alexcearl), Marvell Semiconductor, Inc., and Daniel Beck, CloudBees, Inc.** for SECURITY-1422
*   **Daniel Beck, CloudBees, Inc.** for SECURITY-1184
*   **David Fiser of Trend Micro Nebula working with Trend Micro's Zero Day Initiative** for SECURITY-1429, SECURITY-1435
*   **Jesse Glick, CloudBees, Inc.** for SECURITY-713, SECURITY-1345
*   **Mikaël Barbero (Eclipse Foundation)** for SECURITY-1290
*   **Oleg Nenashev, CloudBees, Inc.** for SECURITY-1098
*   **Wadeck Follonier, CloudBees, Inc.** for SECURITY-1446

CVE-2019-10359: Jenkins Security Advisory 2019-07-31

A Polymorphic Typing issue was discovered in FasterXML jackson-databind 2.x through 2.9.9. When Default Typing is enabled (either globally or for a specific property) for an externally exposed JSON endpoint and the service has JDOM 1.x or 2.x jar in the classpath, an attacker can send a specifically crafted JSON message that allows them to read arbitrary local files on the server.

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

Labels

CVE

Issues related to public CVEs (security vuln reports)

**Comments**

 cowtowncoder changed the title Block yet another gadget type (CVE to be requested) Block yet another gadget type (CVE-2019-12814)

Jun 14, 2019

Fixed in 2.7, 2.8, 2.9, 2.10 and master branches for likely release in 2.9.9.1 and 2.10.0.

When can we expect a 2.9.9.1 release?

hilmarf, daniel-schel, victor7437, zageyiff, lbourdages, dannil, lbalmaceda, j-tim, jactor-rises, emmberk, and 37 more reacted with thumbs up emoji

This was referenced

Jun 22, 2019

I appreciate the hard work being done by the jackson-databind developers, but 3 days later, I have to repeat @antalindisguise's question again: Why isn't 2.9.9.1 released yet? Those of us who use the OWASP Dependency Check plugin in our projects now have failing builds because of CVE-2019-12814, without a proper remedy. I really don't like adding a suppression for a legitimate security issue. 😕

@volkert-fastned if it helps, you've had a legitimate security issue for ages already, you just didn't know about it until today. Plus, if you don't have JDOM then it would be a legitimate suppression,

@OrangeDog Thanks. I read it in the CVE description as well.

So when the following commands return no results, the project should be unaffected, correct?

    # Maven project
    mvn dependency:tree | grep -i jdom
    
    # Gradle project
    ./gradlew dependencies | grep -i jdom
    

> @OrangeDog Thanks. I read it in the CVE description as well.
> 
> So when the following commands return no results, the project should be unaffected, correct?
> 
>     # Maven project
>     mvn dependency:tree | grep -i jdom
>     
>     # Gradle project
>     ./gradlew dependencies | grep -i jdom
>     

Well you would also have to "enableDefaultTyping" (either globally or for a specific property :)

For me, the problem is that our pipeline checks for dependencies with known issues and abort the process if a problem is found. You can argue that the problem is in the previous versions, but if the problem is solved why not just release?

@mpbalmeida in general you cannot expect every dependency to release a fix as soon as a vulnerability is known. If your pipeline relies on that, then you need to make changes.

@volkert-fastned

> So when the following commands return no results, the project should be unaffected

What's on the classpath when your code runs is not simply the list of project dependencies. You need to audit your systems and be aware of what's happening.

We can manually trigger to rebuild, but I thought the problem was already solved because there were no open issues in 2.9.9.1 milestone

I don't know the details of how this issue was discovered or originally disclosed (insert grain of salt)  
But IMHO, It would be nice to release the fix before disclosing the vuln.

> @volkert-fastned
> 
> > So when the following commands return no results, the project should be unaffected
> 
> What's on the classpath when your code runs is not simply the list of project dependencies. You need to audit your systems and be aware of what's happening.

In the specific case of CVE-2019-12814, one of the prerequisites for being vulnerable (kind of a weird way to put it, but you know what I mean) is "the service has JDOM 1.x or 2.x jar **in the classpath**". Source: https://nvd.nist.gov/vuln/detail/CVE-2019-12814

By the way, it's kind of odd how an XML dependency such as JDOM would trigger a JSON-related vulnerability.

> @volkert-fastned if it helps, you've had a legitimate security issue for ages already, you just didn't know about it until today. Plus, if you don't have JDOM then it would be a legitimate suppression,

It is worth noting that JDOM2 comes as a dependency within the latest version of **Spring-Boot-Starter-Parent 2.1.6**  
https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-parent/2.1.6.RELEASE  
_(edited to reflect a mistake i made by saying spring-boot when I meant spring-boot-starter-parent)  
Thanks @benjamin Asbach for making me recheck and finding my mistake_

If you run the cmd:  
mvn help:effective-pom -Doutput=effective.xml  
and then search for JDOM you can see it's there at version <jdom2.version>2.0.6</jdom2.version>

Really hoping version 2.9.9.1 is released soon, this is causing me head aches.

> It is worth noting that JDOM2 comes as a dependency within the latest version of SpringBoot 2.1.6
> 
> If you run the cmd:  
> mvn help:effective-pom -Doutput=effective.xml  
> and then search for JDOM you can see it's there at version <jdom2.version>2.0.6</jdom2.version>
> 
> Really hoping version 2.9.9.1 is released soon, this is causing me head aches.

Really??? I thought mvn dependency:tree also showed all **transitive** dependencies. Yet another thing you can't rely on. 😕

Thanks for sharing this method, @andr3w-hilton.

And again, not to be ungrateful to the developers, but what's holding up the 2.9.9.1 release right now? Is it undergoing a final rigorous code audit and/or pentest? Because in that case, I completely understand and support the current holdup.

@volkert-fastned @cowtowncoder has simply taken a break lol - nothing more nothing less.  
Perhaps assist by having a PR ready for when he gets back?

Well, to be fair, everybody deserves a good vacation every now and then. 🙂

But I don't think any PRs are necessary anymore. The actual issues have already been resolved. It's just that we're still waiting for the 2.9.9.1 release that contains these fixes: https://github.com/FasterXML/jackson-databind/milestone/97

By the way, It's somewhat worrisome how such a crucial library like jackson-databind apparently has so few developers maintaining it, that the vacation of one person would block a release with an important security fix. One obviously can't blame any individual developers or maintainers for that. This is a problem that needs to be solved at an organizational level.

xD

Not really, usually all deploys are held monitored and approved by a single person?

There's a few maintainers hey, I know Tatu is getting ready for 2.10 and doing the min jdk8 impl, i'm doing the jpms impl, I know a few others are doing a few bits as well.  
Also what organization do you believe is running this project? :)

Naw, the way it is now is correct, the single point for final approve and deployment definitely is correct. and yea I think he is allowed a break for as long as needed. Rather wait patiently and get a refreshed mind doing it. There also seems to be people complaining about dropping jdk 6 support (but 2.10 drops jdk 7 support), so I believe there's that consideration for 2.9.10 as well for some security fixes (although the jdk has more holes than any library), so there's a lot going on

> all deploys are held monitored and approved by a single person?

If (hopefully not) the one person who can do that gets hit by a car while on holiday, does that mean that there will never be another release of Jackson? There needs to be multiple people who can do it, both to deal with that situation, and with this one.

> I thought mvn dependency:tree also showed all transitive dependencies.

It does. @andr3w-hilton is mistaken and looking at the <dependencyManagement> section, not the <dependencies>.

This was referenced

Feb 4, 2022

This was referenced

Mar 11, 2022

This was referenced

Mar 12, 2022

This was referenced

Mar 31, 2022

This was referenced

May 10, 2022

This was referenced

Apr 28, 2023

This was referenced

Aug 29, 2023

This was referenced

Sep 7, 2023

Labels

CVE

Issues related to public CVEs (security vuln reports)

CVE-2019-12814: Block yet another gadget type (jdom, CVE-2019-12814) · Issue #2341 · FasterXML/jackson-databind

Spark's Apache Maven-based build includes a convenience script, 'build/mvn', that downloads and runs a zinc server to speed up compilation. It has been included in release branches since 1.3.x, up to and including master. This server will accept connections from external hosts by default. A specially-crafted request to the zinc server could cause it to reveal information in files readable to the developer account running the build. Note that this issue does not affect end users of Spark, only developers building Spark from source code.

**Reporting security issues**

Apache Spark uses the standard process outlined by the Apache Security Team for reporting vulnerabilities. Note that vulnerabilities should not be publicly disclosed until the project has responded.

To report a possible security vulnerability, please email security@spark.apache.org. This is a non-public list that will reach the Apache Security team, as well as the Spark PMC.

**Known security issues****CVE-2022-31777: Apache Spark XSS vulnerability in log viewer UI Javascript**

Severity: Medium

Vendor: The Apache Software Foundation

Versions Affected:

*   3.2.1 and earlier
*   3.3.0

Description:

A stored cross-site scripting (XSS) vulnerability in Apache Spark 3.2.1 and earlier, and 3.3.0, allows remote attackers to execute arbitrary JavaScript in the web browser of a user, by including a malicious payload into the logs which would be returned in logs rendered in the UI.

Mitigation:

*   Upgrade to Spark 3.2.2, or 3.3.1 or later

Credit:

*   Florian Walter (Veracode)

**CVE-2022-33891: Apache Spark shell command injection vulnerability via Spark UI**

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:

*   3.0.3 and earlier
*   3.1.1 to 3.1.2
*   3.2.0 to 3.2.1

Description:

The Apache Spark UI offers the possibility to enable ACLs via the configuration option spark.acls.enable. With an authentication filter, this checks whether a user has access permissions to view or modify the application. If ACLs are enabled, a code path in HttpSecurityFilter can allow someone to perform impersonation by providing an arbitrary user name. A malicious user might then be able to reach a permission check function that will ultimately build a Unix shell command based on their input, and execute it. This will result in arbitrary shell command execution as the user Spark is currently running as.

Mitigation

*   Update to Spark 3.1.3, 3.2.2, or 3.3.0 or later

Credit:

*   Kostya Torchinsky (Databricks)

**CVE-2021-38296: Apache Spark™ Key Negotiation Vulnerability**

Severity: Medium

Vendor: The Apache Software Foundation

Versions Affected:

*   Apache Spark 3.1.2 and earlier

Description:

Apache Spark supports end-to-end encryption of RPC connections via spark.authenticate and spark.network.crypto.enabled. In versions 3.1.2 and earlier, it uses a bespoke mutual authentication protocol that allows for full encryption key recovery. After an initial interactive attack, this would allow someone to decrypt plaintext traffic offline. Note that this does not affect security mechanisms controlled by spark.authenticate.enableSaslEncryption, spark.io.encryption.enabled, spark.ssl, spark.ui.strictTransportSecurity.

Mitigation:

*   Update to Spark 3.1.3 or later

Credit:

*   Steve Weis (Databricks)

**CVE-2020-9480: Apache Spark™ RCE vulnerability in auth-enabled standalone master**

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:

*   Apache Spark 2.4.5 and earlier

Description:

In Apache Spark 2.4.5 and earlier, a standalone resource manager’s master may be configured to require authentication (spark.authenticate) via a shared secret. When enabled, however, a specially-crafted RPC to the master can succeed in starting an application’s resources on the Spark cluster, even without the shared key. This can be leveraged to execute shell commands on the host machine.

This does not affect Spark clusters using other resource managers (YARN, Mesos, etc).

Mitigation:

*   Users should update to Spark 2.4.6 or 3.0.0.
*   Where possible, network access to the cluster machines should be restricted to trusted hosts only.

Credit:

*   Ayoub Elaassal

**CVE-2019-10099: Apache Spark™ unencrypted data on local disk**

Severity: Important

Vendor: The Apache Software Foundation

Versions affected:

*   All Spark 1.x, Spark 2.0.x, Spark 2.1.x, and 2.2.x versions
*   Spark 2.3.0 to 2.3.2

Description:

Prior to Spark 2.3.3, in certain situations Spark would write user data to local disk unencrypted, even if spark.io.encryption.enabled=true. This includes cached blocks that are fetched to disk (controlled by spark.maxRemoteBlockSizeFetchToMem); in SparkR, using parallelize; in Pyspark, using broadcast and parallelize; and use of python udfs.

Mitigation:

*   1.x, 2.0.x, 2.1.x, 2.2.x, 2.3.x users should upgrade to 2.3.3 or newer, including 2.4.x

Credit:

*   This issue was reported by Thomas Graves of NVIDIA.

**CVE-2018-11760: Apache Spark™ local privilege escalation vulnerability**

Severity: Important

Vendor: The Apache Software Foundation

Versions affected:

*   All Spark 1.x, Spark 2.0.x, and Spark 2.1.x versions
*   Spark 2.2.0 to 2.2.2
*   Spark 2.3.0 to 2.3.1

Description:

When using PySpark, it’s possible for a different local user to connect to the Spark application and impersonate the user running the Spark application. This affects versions 1.x, 2.0.x, 2.1.x, 2.2.0 to 2.2.2, and 2.3.0 to 2.3.1.

Mitigation:

*   1.x, 2.0.x, 2.1.x, and 2.2.x users should upgrade to 2.2.3 or newer
*   2.3.x users should upgrade to 2.3.2 or newer
*   Otherwise, affected users should avoid using PySpark in multi-user environments.

Credit:

*   Luca Canali and Jose Carlos Luna Duran, CERN

**CVE-2018-17190: Unsecured Apache Spark™ standalone executes user code**

Severity: Low

Vendor: The Apache Software Foundation

Versions Affected:

*   All versions of Apache Spark

Description:

Spark’s standalone resource manager accepts code to execute on a ‘master’ host, that then runs that code on ‘worker’ hosts. The master itself does not, by design, execute user code. A specially-crafted request to the master can, however, cause the master to execute code too. Note that this does not affect standalone clusters with authentication enabled. While the master host typically has less outbound access to other resources than a worker, the execution of code on the master is nevertheless unexpected.

Mitigation:

Enable authentication on any Spark standalone cluster that is not otherwise secured from unwanted access, for example by network-level restrictions. Use spark.authenticate and related security properties described at https://spark.apache.org/docs/latest/security.html

Credit:

*   Andre Protas, Apple Information Security

**CVE-2018-11804: Apache Spark™ build/mvn runs zinc, and can expose information from build machines**

Severity: Low

Vendor: The Apache Software Foundation

Versions Affected

*   2.1.x release branch and earlier
*   2.2.x release branch before Spark 2.2.3
*   2.3.x release branch before Spark 2.3.3

Description:

Spark’s Apache Maven-based build includes a convenience script, ‘build/mvn’, that downloads and runs a zinc server to speed up compilation. This server will accept connections from external hosts by default. A specially-crafted request to the zinc server could cause it to reveal information in files readable to the developer account running the build. Note that this issue does not affect end users of Spark, only developers building Spark from source code.

Mitigation:

*   Spark users are not affected, as zinc is only a part of the build process.
*   Spark developers may simply use a local Maven installation’s ‘mvn’ command to build, and avoid running build/mvn and zinc.
*   Spark developers building actively-developed branches (2.2.x, 2.3.x, 2.4.x, master) may update their branches to receive mitigations already patched onto the build/mvn script
*   Spark developers running zinc separately may include “-server 127.0.0.1” in its command line, and consider additional flags like “-idle-timeout 30m” to achieve similar mitigation.

Credit:

*   Andre Protas, Apple Information Security

**CVE-2018-11770: Apache Spark™ standalone master, Mesos REST APIs not controlled by authentication**

Severity: Medium

Vendor: The Apache Software Foundation

Versions Affected:

*   Spark versions from 1.3.0, running standalone master with REST API enabled, or running Mesos master with cluster mode enabled; suggested mitigations resolved the issue as of Spark 2.4.0.

Description:

From version 1.3.0 onward, Spark’s standalone master exposes a REST API for job submission, in addition to the submission mechanism used by spark-submit. In standalone, the config property spark.authenticate.secret establishes a shared secret for authenticating requests to submit jobs via spark-submit. However, the REST API does not use this or any other authentication mechanism, and this is not adequately documented. In this case, a user would be able to run a driver program without authenticating, but not launch executors, using the REST API. This REST API is also used by Mesos, when set up to run in cluster mode (i.e., when also running MesosClusterDispatcher), for job submission. Future versions of Spark will improve documentation on these points, and prohibit setting spark.authenticate.secret when running the REST APIs, to make this clear. Future versions will also disable the REST API by default in the standalone master by changing the default value of spark.master.rest.enabled to false.

Mitigation:

For standalone masters, disable the REST API by setting spark.master.rest.enabled to false if it is unused, and/or ensure that all network access to the REST API (port 6066 by default) is restricted to hosts that are trusted to submit jobs. Mesos users can stop the MesosClusterDispatcher, though that will prevent them from running jobs in cluster mode. Alternatively, they can ensure access to the MesosRestSubmissionServer (port 7077 by default) is restricted to trusted hosts.

Credit:

*   Imran Rashid, Cloudera
*   Fengwei Zhang, Alibaba Cloud Security Team

**CVE-2018-8024: Apache Spark™ XSS vulnerability in UI**

Severity: Medium

Versions Affected:

*   Spark 2.1.0 through 2.1.2
*   Spark 2.2.0 through 2.2.1
*   Spark 2.3.0

Description:

In Apache Spark 2.1.0 to 2.1.2, 2.2.0 to 2.2.1, and 2.3.0, it’s possible for a malicious user to construct a URL pointing to a Spark cluster’s UI’s job and stage info pages, and if a user can be tricked into accessing the URL, can be used to cause script to execute and expose information from the user’s view of the Spark UI. While some browsers like recent versions of Chrome and Safari are able to block this type of attack, current versions of Firefox (and possibly others) do not.

Mitigation:

*   2.1.x users should upgrade to 2.1.3 or newer
*   2.2.x users should upgrade to 2.2.2 or newer
*   2.3.x users should upgrade to 2.3.1 or newer

Credit:

*   Spencer Gietzen, Rhino Security Labs

**CVE-2018-1334: Apache Spark™ local privilege escalation vulnerability**

Severity: High

Vendor: The Apache Software Foundation

Versions affected:

*   Spark versions through 2.1.2
*   Spark 2.2.0 to 2.2.1
*   Spark 2.3.0

Description:

In Apache Spark up to and including 2.1.2, 2.2.0 to 2.2.1, and 2.3.0, when using PySpark or SparkR, it’s possible for a different local user to connect to the Spark application and impersonate the user running the Spark application.

Mitigation:

*   1.x, 2.0.x, and 2.1.x users should upgrade to 2.1.3 or newer
*   2.2.x users should upgrade to 2.2.2 or newer
*   2.3.x users should upgrade to 2.3.1 or newer
*   Otherwise, affected users should avoid using PySpark and SparkR in multi-user environments.

Credit:

*   Nehmé Tohmé, Cloudera, Inc.

**CVE-2017-12612 Unsafe deserialization in Apache Spark™ launcher API**

JIRA: SPARK-20922

Severity: Medium

Vendor: The Apache Software Foundation

Versions Affected:

*   Versions of Apache Spark from 1.6.0 until 2.1.1

Description:

In Apache Spark 1.6.0 until 2.1.1, the launcher API performs unsafe deserialization of data received by its socket. This makes applications launched programmatically using the launcher API potentially vulnerable to arbitrary code execution by an attacker with access to any user account on the local machine. It does not affect apps run by spark-submit or spark-shell. The attacker would be able to execute code as the user that ran the Spark application. Users are encouraged to update to version 2.1.2, 2.2.0 or later.

Mitigation:

Update to Apache Spark 2.1.2, 2.2.0 or later.

Credit:

*   Aditya Sharad, Semmle

**CVE-2017-7678 Apache Spark™ XSS web UI MHTML vulnerability**

JIRA: SPARK-20393

Severity: Medium

Vendor: The Apache Software Foundation

Versions Affected:

*   Versions of Apache Spark before 2.1.2, 2.2.0

Description:

It is possible for an attacker to take advantage of a user’s trust in the server to trick them into visiting a link that points to a shared Spark cluster and submits data including MHTML to the Spark master, or history server. This data, which could contain a script, would then be reflected back to the user and could be evaluated and executed by MS Windows-based clients. It is not an attack on Spark itself, but on the user, who may then execute the script inadvertently when viewing elements of the Spark web UIs.

Mitigation:

Update to Apache Spark 2.1.2, 2.2.0 or later.

Example:

Request:

    GET /app/?appId=Content-Type:%20multipart/related;%20boundary=_AppScan%0d%0a--
    _AppScan%0d%0aContent-Location:foo%0d%0aContent-Transfer-
    Encoding:base64%0d%0a%0d%0aPGh0bWw%2bPHNjcmlwdD5hbGVydCgiWFNTIik8L3NjcmlwdD48L2h0bWw%2b%0d%0a
    HTTP/1.1
    

Excerpt from response:

    <div class="row-fluid">No running application with ID Content-Type: multipart/related;
    boundary=_AppScan
    --_AppScan
    Content-Location:foo
    Content-Transfer-Encoding:base64
    PGh0bWw+PHNjcmlwdD5hbGVydCgiWFNTIik8L3NjcmlwdD48L2h0bWw+
    </div>
    

Result: In the above payload the BASE64 data decodes as:

    <html><script>alert("XSS")</script></html>
    

Credit:

*   Mike Kasper, Nicholas Marion
*   IBM z Systems Center for Secure Engineering

CVE-2018-11804: Security | Apache Spark

From version 1.3.0 onward, Apache Spark's standalone master exposes a REST API for job submission, in addition to the submission mechanism used by spark-submit. In standalone, the config property 'spark.authenticate.secret' establishes a shared secret for authenticating requests to submit jobs via spark-submit. However, the REST API does not use this or any other authentication mechanism, and this is not adequately documented. In this case, a user would be able to run a driver program without authenticating, but not launch executors, using the REST API. This REST API is also used by Mesos, when set up to run in cluster mode (i.e., when also running MesosClusterDispatcher), for job submission. Future versions of Spark will improve documentation on these points, and prohibit setting 'spark.authenticate.secret' when running the REST APIs, to make this clear. Future versions will also disable the REST API by default in the standalone master by changing the default value of 'spark.master.rest.enabled' to 'false'.

CVE-2018-11770: Security | Apache Spark

Apache Axis 1.x up to and including 1.4 is vulnerable to a cross-site scripting (XSS) attack in the default servlet/services.

**Details**

*   **Type: ** Bug
    
*   **Status:** Resolved
    
*   **Priority: ** Major
    
*   **Resolution:** Fixed
    
*   **Affects Version/s:** None
    
*   **Fix Version/s:** None
    
*   **Component/s:** None
    
*   **Labels:**
    
    None
    

**Description**

I built the trunk and can confirm the fix. See below:

r1831943 | veithen | 2018-05-20 14:10:32 -0600 (Sun, 20 May 2018) | 1 line

Correctly escape namespace URIs in namespace declarations.

Trunk link with maven builds:

https://travis-ci.org/apache/axis1-java 

**Attachments**

**Activity**

Tag

#maven