[
https://issues.apache.org/jira/browse/JCR-5260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCR-5260:
--------------------------------
Description:
*_Use of Externally-Controlled Input to Select Classes or Code vulnerability in
Apache Jackrabbit's WebDAV/Davex client._*
*_A malicious WebDAV/DavEx server, or an attacker able to intercept the
connection, can cause the client to instantiate arbitrary classes from its
classpath, which can lead to arbitrary file creation or truncation._*
*_Only applications that use jackrabbit-spi2dav (directly or through
jackrabbit-jcr2dav) to connect to a remote repository are affected. Jackrabbit
servers are not affected._*
*_Category: unsafe reflection on wire data (HIGH)._*
The WebDAV remoting layer currently marshals arbitrary Java exceptions into
HTTP response payloads instead of restricting them strictly to
javax.jcr.RepositoryException and its subclasses.
Why this breaks clients expecting javax.jcr.RepositoryException:
Clients only have JCR and Jackrabbit client JARs on their classpath. If the
server serializes a server-only exception, client deserialization fails with
ClassNotFoundException, hiding the real cause.
Client code expects to catch javax.jcr.RepositoryException. Unmapped runtime
exceptions bypass these catch blocks and cause unexpected application crashes.
Serializing arbitrary exceptions exposes internal server stack traces and
dependency details over the wire.
Client compatibility becomes tied to the server's internal classpath and
library dependencies.
was:
The WebDAV remoting layer currently marshals arbitrary Java exceptions into
HTTP response payloads instead of restricting them strictly to
javax.jcr.RepositoryException and its subclasses.
Why this breaks clients expecting javax.jcr.RepositoryException:
Clients only have JCR and Jackrabbit client JARs on their classpath. If the
server serializes a server-only exception, client deserialization fails with
ClassNotFoundException, hiding the real cause.
Client code expects to catch javax.jcr.RepositoryException. Unmapped runtime
exceptions bypass these catch blocks and cause unexpected application crashes.
Serializing arbitrary exceptions exposes internal server stack traces and
dependency details over the wire.
Client compatibility becomes tied to the server's internal classpath and
library dependencies.
> DavEx client runs Class.forName + (String)-constructor on server-controlled
> error bodies (Uncaught non-RepositoryException types in HTTP responses break
> JCR clients)
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JCR-5260
> URL: https://issues.apache.org/jira/browse/JCR-5260
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr2dav
> Affects Versions: 2.20.17, 2.22.4, 2.23.5
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Critical
> Fix For: 2.20.18, 2.23.6, 2.22.5
>
>
> *_Use of Externally-Controlled Input to Select Classes or Code vulnerability
> in Apache Jackrabbit's WebDAV/Davex client._*
> *_A malicious WebDAV/DavEx server, or an attacker able to intercept the
> connection, can cause the client to instantiate arbitrary classes from its
> classpath, which can lead to arbitrary file creation or truncation._*
> *_Only applications that use jackrabbit-spi2dav (directly or through
> jackrabbit-jcr2dav) to connect to a remote repository are affected.
> Jackrabbit servers are not affected._*
> *_Category: unsafe reflection on wire data (HIGH)._*
> The WebDAV remoting layer currently marshals arbitrary Java exceptions into
> HTTP response payloads instead of restricting them strictly to
> javax.jcr.RepositoryException and its subclasses.
> Why this breaks clients expecting javax.jcr.RepositoryException:
> Clients only have JCR and Jackrabbit client JARs on their classpath. If the
> server serializes a server-only exception, client deserialization fails with
> ClassNotFoundException, hiding the real cause.
> Client code expects to catch javax.jcr.RepositoryException. Unmapped runtime
> exceptions bypass these catch blocks and cause unexpected application crashes.
> Serializing arbitrary exceptions exposes internal server stack traces and
> dependency details over the wire.
> Client compatibility becomes tied to the server's internal classpath and
> library dependencies.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
