CVE-2017-1000353

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