You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Artem Smotrakov (JIRA)" <ji...@apache.org> on 2019/03/26 14:28:00 UTC
[jira] [Updated] (HTTPCLIENT-1976) Unsafe deserialization in
DefaultHttpCacheEntrySerializer
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Artem Smotrakov updated HTTPCLIENT-1976:
----------------------------------------
Attachment: unsafe_cache_deserialization.patch
> 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
> Attachments: unsafe_cache_deserialization.patch
>
>
> (this bug was created after discussing it on security@apache.org)
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org