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:45:00 UTC
[jira] [Comment Edited] (HTTPCLIENT-1976) Unsafe deserialization in
DefaultHttpCacheEntrySerializer
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16801786#comment-16801786 ]
Artem Smotrakov edited comment on HTTPCLIENT-1976 at 3/26/19 2:44 PM:
----------------------------------------------------------------------
I attached unsafe_cache_deserialization.patch which updates DefaultHttpCacheEntrySerializer with a whitelisting mechanism. Another option may be adding a new implementation of HttpCacheEntrySerializer which checks classes during deserialization and deprecate DefaultHttpCacheEntrySerializer. But in this case DefaultHttpCacheEntrySerializer may be still dangerous to use. DefaultHttpCacheEntrySerializer is part of public APIs, some application may use it.
If the patch look fine, I can finalize it and create a pull request.
was (Author: asmotrakov):
I attached unsafe_cache_deserialization.patch which updates DefaultHttpCacheEntrySerializer with a whitelisting mechanism. Another option may be adding a new implementation of HttpCacheEntrySerializer which checks classes during deserialization and deprecate DefaultHttpCacheEntrySerializer. But in this case DefaultHttpCacheEntrySerializer may be still dangerous to use. DefaultHttpCacheEntrySerializer is part of public APIs, some application may use it.
> 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: test.tar.gz, 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