Artem Smotrakov created HTTPCLIENT-1976:
-------------------------------------------
Summary: Unsafe deserialization in DefaultHttpCacheEntrySerializer
Key: HTTPCLIENT-1976
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1976
Project: HttpComponents HttpClient
Issue Type: Bug
Reporter: Artem Smotrakov
Attachments: unsafe_cache_deserialization.patch
(this bug was created after discussing it on [email protected])
Apache HttpClient contains DefaultHttpCacheEntrySerializer class which uses the
default Java serialization mechanism to store cache entries.
DefaultHttpCacheEntrySerializer is used by default by EhcacheHttpCacheStorage
class. It looks like there is a way how malicious data can reach
DefaultHttpCacheEntrySerializer which as a result can lead to arbitrary code
execution. But fortunately there are several pre-conditions for that:
1. CacheConfiguration has to be configured to read cache from a local disk.
Currently this feature is supported only by the enterprise version of Ehcache.
2. An attacker should have access to the local cache file. In other words, the
attacker's process should run on the same machine, and the cache file is stored
in a shared directory such as /tmp (which is of course not recommended). Or,
there should be another vulnerability which allows the attacker to modify the
cache file.
The pre-conditions above (especially #2) make it hard to exploit but
nevertheless I am wondering if HttpClient should address it. I see the
following ways how it may be fixed although it have not tried it out:
1. Add a filter for incoming serialization data [1]. Such filters were
introduced in JDK 6u141, so that HttpClient won't run on previous JDK 6
versions.
2. Use ValidatingObjectInputStream to restrict deserialization to a limited set
of classes. This adds an additional dependency.
Both ways are based on whitelisting of trusted classes which can be stored in
cache. I assume HttpClient is not supposed to store any objects in cache, so
such a set of trusted classes may be built.
I am attaching a test which reproduces this issue. Let me know if you think it
should be fixed, and I can work on a patch.
[1] [https://openjdk.java.net/jeps/290]
[2]
[https://commons.apache.org/proper/commons-io/javadocs/api-2.5/org/apache/commons/io/serialization/ValidatingObjectInputStream.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
