All vulnerability reports

Potential deserialization of untrusted data in Vaadin 7 and 8 when JMX or RMI are enabled

Overview

Certain classes in com.vaadin:vaadin-server and com.vaadin:vaadin-shared version 7 (all versions of Vaadin 7), and com.vaadin:vaadin-compatibility-server and com.vaadin:vaadin-compatibility-shared version 8 (all versions of Vaadin 8) allows attacker to perform unsafe deserialization when JMX or RMI are enabled.

See CWE-502: Deserialization of Untrusted Data

Description

When a Vaadin 7 application (or Vaadin 8 application that uses V7 compatibility package) is running in a Servlet container where JMX or RMI is used, and if an unauthenticated user can trigger the deserialization of a payload crafted by them, and vaadin-server.jar and vaadin-shared.jar are part of the classpath when the deserialization happens, an attacker can achieve an unauthenticated remote code execution.

In practice, the attack can be executed by injecting a payload that will be deserialized and will be accessed by the NestedMethodProperty allowing the execution of malicious code.

The functionality used for the identified chain of deserialization events is no longer included in Vaadin 8 (without the Vaadin 7 compatibility packages) or the Vaadin platform. We still advise users of those products to ensure all access to deserialization facilities is restricted, since we cannot rule out the possibility that a similar attack vector is identified in the future.

Affected products and mitigation

Product version Mitigation
Vaadin 7 If you are using JMX or RMI together with any affected Vaadin version, you should take a look at the references listed below for handling the situation.
Vaadin 8 (with V7 compatibility package)

Artifacts

Maven coordinates Affected version
com.vaadin:vaadin-server 7.*
com.vaadin:vaadin-shared 7.*
com.vaadin:vaadin-compatibility-server 8.*
com.vaadin:vaadin-compatibility-shared 8.*

Credit

This issue was discovered and responsibly reported by Kai Ullrich from Code White GmbH, Ulm, Germany.

References

History

  • 2018-11-13: Initial vulnerability report published