logo
DATABASE RESOURCES PRICING ABOUT US

CVE-2017-1000353

Description

Jenkins versions 2.56 and earlier as well as 2.46.1 LTS and earlier are vulnerable to an unauthenticated remote code execution. An unauthenticated remote code execution vulnerability allowed attackers to transfer a serialized Java `SignedObject` object to the Jenkins CLI, that would be deserialized using a new `ObjectInputStream`, bypassing the existing blacklist-based protection mechanism. We’re fixing this issue by adding `SignedObject` to the blacklist. We’re also backporting the new HTTP CLI protocol from Jenkins 2.54 to LTS 2.46.2, and deprecating the remoting-based (i.e. Java serialization) CLI protocol, disabling it by default. **Recent assessments:** **space-r7** at September 11, 2020 5:56pm UTC reported: The `readFrom` method within the `Command` class in the Jenkins CLI remoting component deserializes objects received from clients without first checking / sanitizing the data. Because of this, a malicious serialized object contained within a serialized `SignedObject` can be sent to the Jenkins endpoint to achieve code execution on the target. This is a fairly old vulnerability, so it’s _unlikely_ that there are many, if any vulnerable installations on the web today, but I rated this vulnerability based on what it _could_ give an attacker if they were to find a vulnerable installation online today. This vulnerability is yet another Java deserialization vulnerability that I would define as critical given a number of reasons: 1. Unauthenticated code execution 2. There is no special / proprietary protocol that will hinder exploitation ( you just send the object in the body of a POST request ) 3. A proof of concept exists and has for some time Again, this is an unlikely target given the date of the vulnerability, but I think an attacker would definitely aim to exploit this if it was spotted online. Assessed Attacker Value: 4 Assessed Attacker Value: 4Assessed Attacker Value: 4


Related