Skip to content
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.

Sign up for GitHub

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

Jump to bottom

BRAVO-666 - Create release artifact after creating the release #1

Merged
merged 27 commits into from
Jun 18, 2020
Merged

BRAVO-666 - Create release artifact after creating the release #1

merged 27 commits into from
Jun 18, 2020

Conversation

jrgarlick
Copy link
Contributor

@jrgarlick jrgarlick commented Jun 11, 2020 •
edited
Loading

Summary

This change adds a Github Workflow to publish the artifact after a release

Submitter's Pledge

Reviewers, I have verified the following to the best of my knowledge:

  • I have added unit test cases for the changes where applicable.
  • I have updated CHANGELOG.md with the new target version (or with the Unreleased tag) and updated the version comparison url in the file.
  • I have updated documentation in README.md at the repo root and all of the applicable README.md files under docs/** along with necessary version change for code samples in those docs where applicable.
  • I have read and fully understand the process for submitting a pull request to the codebase.

@jrgarlick jrgarlick requested a review from a team as a code owner June 11, 2020 17:21
@jrgarlick jrgarlick changed the base branch from develop to master June 11, 2020 17:24
@NickLiffen
Copy link

I think we also need to do a CHANGELOG update 👍 Thoughts?

@NickLiffen
Copy link

Keep me honest here but shouldn't the release a package only happen when a GitHub Release/Pre-Release has been made? Or is this process going to be creating a GitHub Release which is therefore going to go and deploy our DSL to GitHub Packages? 🤔 I would have thought I would have seen event type release/pre-release instead of on merge to develop, master, etc. (IMO). Whats' your thoughts?

@NickLiffen
Copy link

I would envision something like every time we merge into master it goes and automatically makes a GitHub Release which then triggered another workflow which actually handles the release of the package to GitHub Packages, if that makes sense?

delvindefoe
delvindefoe previously approved these changes Jun 11, 2020
View reviewed changes
@jrgarlick
Copy link
Contributor Author

@NickLiffen - There are two package deployments here. One is a SNAPSHOT build after a merge to master. That is a transient build that gives us the ability to make builds of the Lilly DSL before we make a full-blown release. The second deployment is done after creating a release from within Github. The deployment uses the Github release version as the artifact version. I didn't want to do an automatic release after merging to master because I want to maintain control our version numbering. If we want to do a hotfix, we can check out a certain release tag, make a fix, and release from the fix branch with a patch version. Let me know what you think.

@Cirrus-Heroku-Github-Integration
Copy link

✅ Build Results

4 Tests. 4 Pass, 0 Fail. (0 Warning.)

✅ Build Config Check Results

Build Config Check Results

group: com.lilly.opensource.edat - OK
name: jenkinsdsl - OK
version: 1.0.0-SNAPSHOT - OK
✅ Version Check Results

Version Check Results

Checking the package version [1.0.0-SNAPSHOT] on Artifactory!
The specified package version [1.0.0-SNAPSHOT] does not yet exist in Artifactory.
✅ Package Dependency Scan Results

Package Dependency Scan Results

Snyk severity failure level is not set.
This build stage will pass whether or not vulnerabilities are found.
Set the snyk_fail_severity to low, medium, or high in jenkins.yml
to fail this build stage if vulnerabilities of the specified severity
or higher are found.

Snyk test report

June 12th 2020, 4:25:49 am

Scanned the following path:

  • /home/jenkins/agent/workspace/jenkinsdsl_PR-1 (gradle)

81 known vulnerabilities

353 vulnerable dependency paths

157 dependencies

Deserialization of Untrusted Data

high severity

Detailed paths

Overview

com.fasterxml.jackson.core:jackson-databind is a library which contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor.

Affected versions of this package are vulnerable to Deserialization of Untrusted Data. When Default Typing is enabled for an externally exposed JSON endpoint, the service has the mysql-connector-java jar in the classpath. An attacker can host a crafted MySQL server reachable by the victim and send a crafted JSON message that allows them to read arbitrary local files on the server. This occurs due to missing com.mysql.cj.jdbc.admin.MiniAdmin validation.

Details

Serialization is a process of converting an object into a sequence of bytes which can be persisted to a disk or database or can be sent through streams. The reverse process of creating object from sequence of bytes is called deserialization. Serialization is commonly used for communication (sharing objects between multiple hosts) and persistence (store the object state in a file or a database). It is an integral part of popular protocols like Remote Method Invocation (RMI), Java Management Extension (JMX), Java Messaging System (JMS), Action Message Format (AMF), Java Server Faces (JSF) ViewState, etc.

Deserialization of untrusted data (CWE-502), is when the application deserializes untrusted data without sufficiently verifying that the resulting data will be valid, letting the attacker to control the state or the flow of the execution.

Java deserialization issues have been known for years. However, interest in the issue intensified greatly in 2015, when classes that could be abused to achieve remote code execution were found in a popular library (Apache Commons Collection). These classes were used in zero-days affecting IBM WebSphere, Oracle WebLogic and many other products.

An attacker just needs to identify a piece of software that has both a vulnerable class on its path, and performs deserialization on untrusted data. Then all they need to do is send the payload into the deserializer, getting the command executed.

Developers put too much trust in Java Object Serialization. Some even de-serialize objects pre-authentication. When deserializing an Object in Java you typically cast it to an expected type, and therefore Java's strict type system will ensure you only get valid object trees. Unfortunately, by the time the type checking happens, platform code has already created and executed significant logic. So, before the final type is checked a lot of code is executed from the readObject() methods of various objects, all of which is out of the developer's control. By combining the readObject() methods of various classes which are available on the classpath of the vulnerable application an attacker can execute functions (including calling Runtime.exec() to execute local OS commands).

  • Apache Blog

The vulnerability, also know as Mad Gadget

Mad Gadget is one of the most pernicious vulnerabilities we’ve seen. By merely existing on the Java classpath, seven “gadget” classes in Apache Commons Collections (versions 3.0, 3.1, 3.2, 3.2.1, and 4.0) make object deserialization for the entire JVM process Turing complete with an exec function. Since many business applications use object deserialization to send messages across the network, it would be like hiring a bank teller who was trained to hand over all the money in the vault if asked to do so politely, and then entrusting that teller with the key. The only thing that would keep a bank safe in such a circumstance is that most people wouldn’t consider asking such a question.

  • Google

Remediation

Upgrade com.fasterxml.jackson.core:jackson-databind to version 2.9.9, 2.8.11.3, 2.7.9.6 or higher.

References

More about this vulnerability

Deserialization of Untrusted Data

high severity

Detailed paths

Overview

com.fasterxml.jackson.core:jackson-databind is a library which contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor.

Affected versions of this package are vulnerable to Deserialization of Untrusted Data due to an incomplete black list (incomplete fix for CVE-2017-7525). This is exploitable by sending maliciously crafted JSON input to the readValue method of the ObjectMapper, bypassing a blacklist that is ineffective if the Spring libraries are available in the classpath.

Details

Serialization is a process of converting an object into a sequence of bytes which can be persisted to a disk or database or can be sent through streams. The reverse process of creating object from sequence of bytes is called deserialization. Serialization is commonly used for communication (sharing objects between multiple hosts) and persistence (store the object state in a file or a database). It is an integral part of popular protocols like Remote Method Invocation (RMI), Java Management Extension (JMX), Java Messaging System (JMS), Action Message Format (AMF), Java Server Faces (JSF) ViewState, etc.

Deserialization of untrusted data (CWE-502), is when the application deserializes untrusted data without sufficiently verifying that the resulting data will be valid, letting the attacker to control the state or the flow of the execution.

Java deserialization issues have been known for years. However, interest in the issue intensified greatly in 2015, when classes that could be abused to achieve remote code execution were found in a popular library (Apache Commons Collection). These classes were used in zero-days affecting IBM WebSphere, Oracle WebLogic and many other products.

An attacker just needs to identify a piece of software that has both a vulnerable class on its path, and performs deserialization on untrusted data. Then all they need to do is send the payload into the deserializer, getting the command executed.

Developers put too much trust in Java Object Serialization. Some even de-serialize objects pre-authentication. When deserializing an Object in Java you typically cast it to an expected type, and therefore Java's strict type system will ensure you only get valid object trees. Unfortunately, by the time the type checking happens, platform code has already created and executed significant logic. So, before the final type is checked a lot of code is executed from the readObject() methods of various objects, all of which is out of the developer's control. By combining the readObject() methods of various classes which are available on the classpath of the vulnerable application an attacker can execute functions (including calling Runtime.exec() to execute local OS commands).

  • Apache Blog

The vulnerability, also know as Mad Gadget

Mad Gadget is one of the most pernicious vulnerabilities we’ve seen. By merely existing on the Java classpath, seven “gadget” classes in Apache Commons Collections (versions 3.0, 3.1, 3.2, 3.2.1, and 4.0) make object deserialization for the entire JVM process Turing complete with an exec function. Since many business applications use object deserialization to send messages across the network, it would be like hiring a bank teller who was trained to hand over all the money in the vault if asked to do so politely, and then entrusting that teller with the key. The only thing that would keep a bank safe in such a circumstance is that most people wouldn’t consider asking such a question.

  • Google

Remediation

Upgrade com.fasterxml.jackson.core:jackson-databind to version 2.8.11, 2.9.4 or higher.

References

More about this vulnerability

Deserialization of Untrusted Data

high severity

Detailed paths

Overview

com.fasterxml.jackson.core:jackson-databind is a library which contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor.

Affected versions of this package are vulnerable to Deserialization of Untrusted Data due to an incomplete black list (incomplete fix for CVE-2017-7525 and CVE-2017-17485). This is exploitable via two different gadgets that bypass a blacklist.

Details

Serialization is a process of converting an object into a sequence of bytes which can be persisted to a disk or database or can be sent through streams. The reverse process of creating object from sequence of bytes is called deserialization. Serialization is commonly used for communication (sharing objects between multiple hosts) and persistence (store the object state in a file or a database). It is an integral part of popular protocols like Remote Method Invocation (RMI), Java Management Extension (JMX), Java Messaging System (JMS), Action Message Format (AMF), Java Server Faces (JSF) ViewState, etc.

Deserialization of untrusted data (CWE-502), is when the application deserializes untrusted data without sufficiently verifying that the resulting data will be valid, letting the attacker to control the state or the flow of the execution.

Java deserialization issues have been known for years. However, interest in the issue intensified greatly in 2015, when classes that could be abused to achieve remote code execution were found in a popular library (Apache Commons Collection). These classes were used in zero-days affecting IBM WebSphere, Oracle WebLogic and many other products.

An attacker just needs to identify a piece of software that has both a vulnerable class on its path, and performs deserialization on untrusted data. Then all they need to do is send the payload into the deserializer, getting the command executed.

Developers put too much trust in Java Object Serialization. Some even de-serialize objects pre-authentication. When deserializing an Object in Java you typically cast it to an expected type, and therefore Java's strict type system will ensure you only get valid object trees. Unfortunately, by the time the type checking happens, platform code has already created and executed significant logic. So, before the final type is checked a lot of code is executed from the readObject() methods of various objects, all of which is out of the developer's control. By combining the readObject() methods of various classes which are available on the classpath of the vulnerable application an attacker can execute functions (including calling Runtime.exec() to execute local OS commands).

  • Apache Blog

The vulnerability, also know as Mad Gadget

Mad Gadget is one of the most pernicious vulnerabilities we’ve seen. By merely existing on the Java classpath, seven “gadget” classes in Apache Commons Collections (versions 3.0, 3.1, 3.2, 3.2.1, and 4.0) make object deserialization for the entire JVM process Turing complete with an exec function. Since many business applications use object deserialization to send messages across the network, it would be like hiring a bank teller who was trained to hand over all the money in the vault if asked to do so politely, and then entrusting that teller with the key. The only thing that would keep a bank safe in such a circumstance is that most people wouldn’t consider asking such a question.

  • Google

Remediation

Upgrade com.fasterxml.jackson.core:jackson-databind to version 2.8.11, 2.9.4 or higher.

References

More about this vulnerability

Deserialization of Untrusted Data

high severity

Detailed paths

Overview

com.fasterxml.jackson.core:jackson-databind is a library which contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor.

Affected versions of this package are vulnerable to Deserialization of Untrusted Data. It allows unauthenticated remote code execution because of an incomplete fix for the CVE-2017-7525 deserialization flaw. This is exploitable by sending maliciously crafted JSON input to the readValue method of the ObjectMapper, bypassing a blacklist that is ineffective if the c3p0 libraries are available in the classpath.

Details

Serialization is a process of converting an object into a sequence of bytes which can be persisted to a disk or database or can be sent through streams. The reverse process of creating object from sequence of bytes is called deserialization. Serialization is commonly used for communication (sharing objects between multiple hosts) and persistence (store the object state in a file or a database). It is an integral part of popular protocols like Remote Method Invocation (RMI), Java Management Extension (JMX), Java Messaging System (JMS), Action Message Format (AMF), Java Server Faces (JSF) ViewState, etc.

Deserialization of untrusted data (CWE-502), is when the application deserializes untrusted data without sufficiently verifying that the resulting data will be valid, letting the attacker to control the state or the flow of the execution.

Java deserialization issues have been known for years. However, interest in the issue intensified greatly in 2015, when classes that could be abused to achieve remote code execution were found in a popular library (Apache Commons Collection). These classes were used in zero-days affecting IBM WebSphere, Oracle WebLogic and many other products.

An attacker just needs to identify a piece of software that has both a vulnerable class on its path, and performs deserialization on untrusted data. Then all they need to do is send the payload into the deserializer, getting the command executed.

Developers put too much trust in Java Object Serialization. Some even de-serialize objects pre-authentication. When deserializing an Object in Java you typically cast it to an expected type, and therefore Java's strict type system will ensure you only get valid object trees. Unfortunately, by the time the type checking happens, platform code has already created and executed significant logic. So, before the final type is checked a lot of code is executed from the readObject() methods of various objects, all of which is out of the developer's control. By combining the readObject() methods of various classes which are available on the classpath of the vulnerable application an attacker can execute functions (including calling Runtime.exec() to execute local OS commands).

  • Apache Blog

The vulnerability, also know as Mad Gadget

Mad Gadget is one of the most pernicious vulnerabilities we’ve seen. By merely existing on the Java classpath, seven “gadget” classes in Apache Commons Collections (versions 3.0, 3.1, 3.2, 3.2.1, and 4.0) make object deserialization for the entire JVM process Turing complete with an exec function. Since many business applications use object deserialization to send messages across the network, it would be like hiring a bank teller who was trained to hand over all the money in the vault if asked to do so politely, and then entrusting that teller with the key. The only thing that would keep a bank safe in such a circumstance is that most people wouldn’t consider asking such a question.

  • Google

Remediation

Upgrade com.fasterxml.jackson.core:jackson-databind to version 2.8.11.1, 2.9.5 or higher.

References

More about this vulnerability

Deserialization of Untrusted Data

high severity

Detailed paths

Overview

com.fasterxml.jackson.core:jackson-databind is a library which contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor.

Affected versions of this package are vulnerable to Deserialization of Untrusted Data. 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.

Remediation

Upgrade com.fasterxml.jackson.core:jackson-databind to version 2.9.9.1, 2.8.11.4, 2.7.9.6 or higher.

References

More about this vulnerability

Deserialization of Untrusted Data

high severity

Detailed paths

Overview

com.fasterxml.jackson.core:jackson-databind is a library which contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor.

Affected versions of this package are vulnerable to Deserialization of Untrusted Data which allows attackers to have a variety of impacts by leveraging failure to block the logback-core class from polymorphic deserialization. Depending on the classpath content, remote code execution may be possible.

Details

Serialization is a process of converting an object into a sequence of bytes which can be persisted to a disk or database or can be sent through streams. The reverse process of creating object from sequence of bytes is called deserialization. Serialization is commonly used for communication (sharing objects between multiple hosts) and persistence (store the object state in a file or a database). It is an integral part of popular protocols like Remote Method Invocation (RMI), Java Management Extension (JMX), Java Messaging System (JMS), Action Message Format (AMF), Java Server Faces (JSF) ViewState, etc.

Deserialization of untrusted data (CWE-502), is when the application deserializes untrusted data without sufficiently verifying that the resulting data will be valid, letting the attacker to control the state or the flow of the execution.

Java deserialization issues have been known for years. However, interest in the issue intensified greatly in 2015, when classes that could be abused to achieve remote code execution were found in a popular library (Apache Commons Collection). These classes were used in zero-days affecting IBM WebSphere, Oracle WebLogic and many other products.

An attacker just needs to identify a piece of software that has both a vulnerable class on its path, and performs deserialization on untrusted data. Then all they need to do is send the payload into the deserializer, getting the command executed.

Developers put too much trust in Java Object Serialization. Some even de-serialize objects pre-authentication. When deserializing an Object in Java you typically cast it to an expected type, and therefore Java's strict type system will ensure you only get valid object trees. Unfortunately, by the time the type checking happens, platform code has already created and executed significant logic. So, before the final type is checked a lot of code is executed from the readObject() methods of various objects, all of which is out of the developer's control. By combining the readObject() methods of various classes which are available on the classpath of the vulnerable application an attacker can execute functions (including calling Runtime.exec() to execute local OS commands).

  • Apache Blog

The vulnerability, also know as Mad Gadget

Mad Gadget is one of the most pernicious vulnerabilities we’ve seen. By merely existing on the Java classpath, seven “gadget” classes in Apache Commons Collections (versions 3.0, 3.1, 3.2, 3.2.1, and 4.0) make object deserialization for the entire JVM process Turing complete with an exec function. Since many business applications use object deserialization to send messages across the network, it would be like hiring a bank teller who was trained to hand over all the money in the vault if asked to do so politely, and then entrusting that teller with the key. The only thing that would keep a bank safe in such a circumstance is that most people wouldn’t consider asking such a question.

  • Google

Remediation

Upgrade com.fasterxml.jackson.core:jackson-databind to version 2.9.9.1, 2.8.11.4, 2.7.9.6 or higher.

References

More about this vulnerability

Deserialization of Untrusted Data

high severity

Detailed paths

Overview

com.fasterxml.jackson.core:jackson-databind is a library which contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor.

Affected versions of this package are vulnerable to Deserialization of Untrusted Data. SubTypeValidator.java mishandles default typing when ehcache is used, leading to remote code execution.

Description

Serialization is a process of converting an object into a sequence of bytes which can be persisted to a disk or database or can be sent through streams. The reverse process of creating object from sequence of bytes is called deserialization. Serialization is commonly used for communication (sharing objects between multiple hosts) and persistence (store the object state in a file or a database). It is an integral part of popular protocols like Remote Method Invocation (RMI), Java Management Extension (JMX), Java Messaging System (JMS), Action Message Format (AMF), Java Server Faces (JSF) ViewState, etc.

Deserialization of untrusted data (CWE-502), is when the application deserializes untrusted data without sufficiently verifying that the resulting data will be valid, letting the attacker to control the state or the flow of the execution.

Java deserialization issues have been known for years. However, interest in the issue intensified greatly in 2015, when classes that could be abused to achieve remote code execution were found in a popular library (Apache Commons Collection). These classes were used in zero-days affecting IBM WebSphere, Oracle WebLogic and many other products.

An attacker just needs to identify a piece of software that has both a vulnerable class on its path, and performs deserialization on untrusted data. Then all they need to do is send the payload into the deserializer, getting the command executed.

Developers put too much trust in Java Object Serialization. Some even de-serialize objects pre-authentication. When deserializing an Object in Java you typically cast it to an expected type, and therefore Java's strict type system will ensure you only get valid object trees. Unfortunately, by the time the type checking happens, platform code has already created and executed significant logic. So, before the final type is checked a lot of code is executed from the readObject() methods of various objects, all of which is out of the developer's control. By combining the readObject() methods of various classes which are available on the classpath of the vulnerable application an attacker can execute functions (including calling Runtime.exec() to execute local OS commands).

  • Apache Blog

The vulnerability, also know as Mad Gadget

Mad Gadget is one of the most pernicious vulnerabilities we’ve seen. By merely existing on the Java classpath, seven “gadget” classes in Apache Commons Collections (versions 3.0, 3.1, 3.2, 3.2.1, and 4.0) make object deserialization for the entire JVM process Turing complete with an exec function. Since many business applications use object deserialization to send messages across the network, it would be like hiring a bank teller who was trained to hand over all the money in the vault if asked to do so politely, and then entrusting that teller with the key. The only thing that would keep a bank safe in such a circumstance is that most people wouldn’t consider asking such a question.

  • Google

Remediation

Upgrade com.fasterxml.jackson.core:jackson-databind to version 2.9.9.2, 2.8.11.4, 2.7.9.6 or higher.

References

More about this vulnerability

Deserialization of Untrusted Data

high severity

Detailed paths

Overview

com.fasterxml.jackson.core:jackson-databind is a library which contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor.

Affected versions of this package are vulnerable to Deserialization of Untrusted Data. A Polymorphic Typing issue was discovered as com.zaxxer.hikari.HikariDataSource was not blocked. Note: This is a different vulnerability than CVE-2019-14540.

Details

Serialization is a process of converting an object into a sequence of bytes which can be persisted to a disk or database or can be sent through streams. The reverse process of creating object from sequence of bytes is called deserialization. Serialization is commonly used for communication (sharing objects between multiple hosts) and persistence (store the object state in a file or a database). It is an integral part of popular protocols like Remote Method Invocation (RMI), Java Management Extension (JMX), Java Messaging System (JMS), Action Message Format (AMF), Java Server Faces (JSF) ViewState, etc.

Deserialization of untrusted data (CWE-502), is when the application deserializes untrusted data without sufficiently verifying that the resulting data will be valid, letting the attacker to control the state or the flow of the execution.

Java deserialization issues have been known for years. However, interest in the issue intensified greatly in 2015, when classes that could be abused to achieve remote code execution were found in a popular library (Apache Commons Collection). These classes were used in zero-days affecting IBM WebSphere, Oracle WebLogic and many other products.

An attacker just needs to identify a piece of software that has both a vulnerable class on its path, and performs deserialization on untrusted data. Then all they need to do is send the payload into the deserializer, getting the command executed.

Developers put too much trust in Java Object Serialization. Some even de-serialize objects pre-authentication. When deserializing an Object in Java you typically cast it to an expected type, and therefore Java's strict type system will ensure you only get valid object trees. Unfortunately, by the time the type checking happens, platform code has already created and executed significant logic. So, before the final type is checked a lot of code is executed from the readObject() methods of various objects, all of which is out of the developer's control. By combining the readObject() methods of various classes which are available on the classpath of the vulnerable application an attacker can execute functions (including calling Runtime.exec() to execute local OS commands).

  • Apache Blog

The vulnerability, also know as Mad Gadget

Mad Gadget is one of the most pernicious vulnerabilities we’ve seen. By merely existing on the Java classpath, seven “gadget” classes in Apache Commons Collections (versions 3.0, 3.1, 3.2, 3.2.1, and 4.0) make object deserialization for the entire JVM process Turing complete with an exec function. Since many business applications use object deserialization to send messages across the network, it would be like hiring a bank teller who was trained to hand over all the money in the vault if asked to do so politely, and then entrusting that teller with the key. The only thing that would keep a bank safe in such a circumstance is that most people wouldn’t consider asking such a question.

  • Google

Remediation

Upgrade com.fasterxml.jackson.core:jackson-databind to version 2.10.0.pr3, 2.9.10 or higher.

References

More about this vulnerability

Deserialization of Untrusted Data

high severity

Detailed paths

Overview

com.fasterxml.jackson.core:jackson-databind is a library which contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor.

Affected versions of this package are vulnerable to Deserialization of Untrusted Data. A Polymorphic Typing issue was discovered as com.zaxxer.hikari.HikariConfig was not blocked. Note: This is a different vulnerability than CVE-2019-16335.

Details

Serialization is a process of converting an object into a sequence of bytes which can be persisted to a disk or database or can be sent through streams. The reverse process of creating object from sequence of bytes is called deserialization. Serialization is commonly used for communication (sharing objects between multiple hosts) and persistence (store the object state in a file or a database). It is an integral part of popular protocols like Remote Method Invocation (RMI), Java Management Extension (JMX), Java Messaging System (JMS), Action Message Format (AMF), Java Server Faces (JSF) ViewState, etc.

Deserialization of untrusted data (CWE-502), is when the application deserializes untrusted data without sufficiently verifying that the resulting data will be valid, letting the attacker to control the state or the flow of the execution.

Java deserialization issues have been known for years. However, interest in the issue intensified greatly in 2015, when classes that could be abused to achieve remote code execution were found in a popular library (Apache Commons Collection). These classes were used in zero-days affecting IBM WebSphere, Oracle WebLogic and many other products.

An attacker just needs to identify a piece of software that has both a vulnerable class on its path, and performs deserialization on untrusted data. Then all they need to do is send the payload into the deserializer, getting the command executed.

Developers put too much trust in Java Object Serialization. Some even de-serialize objects pre-authentication. When deserializing an Object in Java you typically cast it to an expected type, and therefore Java's strict type system will ensure you only get valid object trees. Unfortunately, by the time the type checking happens, platform code has already created and executed significant logic. So, before the final type is checked a lot of code is executed from the readObject() methods of various objects, all of which is out of the developer's control. By combining the readObject() methods of various classes which are available on the classpath of the vulnerable application an attacker can execute functions (including calling Runtime.exec() to execute local OS commands).

  • Apache Blog

The vulnerability, also know as Mad Gadget

Mad Gadget is one of the most pernicious vulnerabilities we’ve seen. By merely existing on the Java classpath, seven “gadget” classes in Apache Commons Collections (versions 3.0, 3.1, 3.2, 3.2.1, and 4.0) make object deserialization for the entire JVM process Turing complete with an exec function. Since many business applications use object deserialization to send messages across the network, it would be like hiring a bank teller who was trained to hand over all the money in the vault if asked to do so politely, and then entrusting that teller with the key. The only thing that would keep a bank safe in such a circumstance is that most people wouldn’t consider asking such a question.

  • Google

Remediation

Upgrade com.fasterxml.jackson.core:jackson-databind to version 2.10.0.pr2, 2.9.10 or higher.

References

More about this vulnerability

Deserialization of Untrusted Data

high severity

Detailed paths

The auto-generated report is too large to display in this PR. See the full report here. (Jenkins access required.)

✅ Build Results

Build Results

> Task :compileJava NO-SOURCE
> Task :compileGroovy
> Task :processResources NO-SOURCE
> Task :classes

> Task :groovydoc
Trying to override old definition of task fileScanner
[ant:groovydoc] /home/jenkins/agent/workspace/jenkinsdsl_PR-1/build/tmp/groovydoc contains source files in the default package, you must specify them as source files not packages.

> Task :groovydocJar
> Task :jar
> Task :sourcesJar
> Task :assemble
> Task :compileTestJava NO-SOURCE
> Task :compileTestGroovy
> Task :processTestResources NO-SOURCE
> Task :testClasses
> Task :test
> Task :jacocoTestReport

> Task :codeCoverageInfo
Parsing code coverage data ...
Code Coverage[INSTRUCTION]: 54.72317%
Code Coverage[BRANCH]: 52.787163%
Code Coverage[LINE]: 74.10714%
Code Coverage[COMPLEXITY]: 43.746223%
Code Coverage[METHOD]: 49.291786%
Code Coverage[CLASS]: 71.69811%

> Task :check
> Task :build

BUILD SUCCESSFUL in 1m 17s
9 actionable tasks: 9 executed

@NickLiffen NickLiffen added the enhancement New feature or request label Jun 15, 2020
delvindefoe
delvindefoe previously approved these changes Jun 18, 2020
View reviewed changes
@jrgarlick jrgarlick merged commit e6ee839 into master Jun 18, 2020
@jrgarlick jrgarlick deleted the feature/BRAVO-666_releaseWorkflow branch June 18, 2020 14:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jarrettalexander77 jarrettalexander77 jarrettalexander77 approved these changes

@NickLiffen NickLiffen NickLiffen approved these changes

@lavanyach1 lavanyach1 Awaiting requested review from lavanyach1

@delvindefoe delvindefoe Awaiting requested review from delvindefoe

Assignees

@jrgarlick jrgarlick

Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@jrgarlick @NickLiffen @Cirrus-Heroku-Github-Integration @delvindefoe @jarrettalexander77