[
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 [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]
