[
https://issues.apache.org/jira/browse/HTTPCLIENT-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski resolved HTTPCLIENT-1976.
-------------------------------------------
Resolution: Fixed
Fix Version/s: 5.0 Beta4
4.5.9
> 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
> Priority: Major
> Fix For: 4.5.9, 5.0 Beta4
>
> Attachments: test.tar.gz, unsafe_cache_deserialization.patch,
> unsafe_cache_deserialization_v1.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]
