How can I fix deserialization vulnerability?

[林慶龍 Barry Lin <u0...@digiwin.biz>]

Dears:

These days, Everyone talks about the vulnerability in Tomcat, and we found that we had the same problem with “deserialization vulnerability”.

How can I fix deserialization vulnerability in tomcat?

Thanks for your help!





Best regard,

Barry Lin

鼎捷 (鼎新電腦股份有限公司、鼎誠資訊股份有限公司、鼎捷軟件股份有限公司及鼎捷軟件越南有限公司)將善保管您的個人資料，並於合法取得之前提下善意使用，據此本公司僅在營運範圍內之目的與您聯繫，包含鼎捷主辦或協辦之行銷活動、客戶服務、供應商聯繫等，非經由本公司上開目的下之合法授權，所寄發之資訊並不代表本公司 。本電子郵件及附件所載訊息均為保密資訊，受合約保護或依法不得洩漏。其內容僅供指定收件人按限定範圍或特殊目的使用。未經授權者收到此資訊者均無權閱讀、 使用、 複製、洩漏或散佈。若您因為誤傳而收到本郵件或者非本郵件之指定收件人，煩請即刻回覆郵件或並永久刪除此郵件及其附件和銷毀所有複印件。倘若有前述情形或信件誤遞至您的信箱或有相關問題，請透過下列方式聯繫更正；mail：dscmaz@digiwin.biz。謝謝您的合作！

Re: How can I fix deserialization vulnerability?

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark,

On 3/15/16 5:19 AM, Mark Thomas wrote:
> This comes down to the threat scenarios in which Tomcat is intended
> to be secure. A vulnerability is, essentially, when an attacker is
> able to bypass that security in some way.
> 
> Tomcat is not intended to be secure from attacks by malicious
> local users if those local users have write access to any part of
> the Tomcat installation.

Precisely. This is why I was minimizing the impact of this threat.
It's definitely something that ought to be addressed (by users --
there is a mitigation available), but it shouldn't be considered
high-priority or urgent.

> Tomcat is intended to be secure from running malicious web
> applications (they should not be able to view data from other web
> applications or access other data on the server Tomcat is running
> on) providing a SecurityManager is used. Where it gets interesting
> is that you cannot protect against a DoS attack by a malicious web
> application - even when running under a SecurityManager.

Of course. One of the features of a web server is that it's expected
to, you know, serve content when a request is made ;)

> It would probably be a "Good Thing" to document the scenarios in
> which Tomcat is intended to be secure. I think they are reasonably
> well understood by the Tomcat committers - maybe not so much by the
> wider community.

Or, more to the point, document the scenarios under which we think
that security is /not/ achievable -- such as protecting config files
beyond what the filesystem permissions can provide. In general, Tomcat
should be fairly secure out of the box.

I always think it's funny when people want to know about "Hardening
Tomcat". It's pretty "hard" to begin with. Basically, if you want to
harden a Tomcat installation, do whatever you would to harden
anything: don't run as root/admin, lock-down file permissions, remove
unnecessary applications, use TLS. Nothing really Tomcat-specific. The
only thing that's potentially insecure in a stock Tomcat install is
that the examples applications will deploy by default (unless you use
separate CATALINA_HOME/CATALINA_BASE), and there could be a
vulnerability hiding in the examples webapp.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlboPbgACgkQ9CaO5/Lv0PBCdgCfdCStn1my/zUuAUUPPBFcCovm
lscAoLeNWXpp3Jy5nFFhJz7qfCmSHFoy
=8xu9
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: How can I fix deserialization vulnerability?

[Mark Thomas <ma...@apache.org>]

On 14/03/2016 21:01, Christopher Schultz wrote:
> On 3/11/16 4:10 AM, Mark Thomas wrote:
>> On 11/03/2016 01:43, Christopher Schultz wrote:

<snip/>

>>> If you don't have any applications that have known problematic
>>> classes in them (such as the famous commons-collections bug),
>>> then you aren't really in any danger.
> 
>> That statement is dangerously incorrect.
> 
> I disagree, though my statement may easily be misunderstood.
> 
>> The vulnerability is not in Commons Collections or any of the
>> various other libraries that have been leveraged in the various
>> examples that have been made public.
> 
>> The vulnerability is always that an application takes data from an 
>> untrusted source and deserializes it without validation and/or 
>> sanitation. If your application does this then you are almost
>> certainly vulnerable to a deserialization attack of some form.
> 
> The vulnerability is in neither the library (e.g. commons-collections)
> nor the application (Tomcat, in this case). Instead, the vulnerability
> is in the interaction between the two of them.

I disagree. The vulnerability, in this case, is in Tomcat since Tomcat
is taking the untrusted data and treating it as trusted.

> Specifically, if you are using an application (Tomcat) that is
> "vulnerable" (because it unsafely de-serializes untrusted streams) but
> no "vulnerable" library is present, then it is not possible to exploit
> this vulnerability.

The problem is that you cannot prove that there is no code that can be
leveraged by the attacker. More ways to do this are being found all the
time. I suspect it is only a matter of time before one is found in the JRE.

<snip/>

>> If you aren't running Tomcat under a security manager web
>> applications can do whatever they like so this vulnerability is
>> irrelevant.
> 
> I disagree. If you aren't running under a SecurityManager, it's still
> possible (yet unlikely) for an attacker to inject a Trojan Horse into
> Tomcat's session store. For example, a local user might be able to
> escalate their privileges if they only have write access to the
> session store. A SecurityManager might not help protect against such a
> Trojan Horse, so the vulnerability IMO is definitely important even
> under a SM.

If you give an untrusted local user write access to the work directory
(where Tomcat persists the sessions) then there are a whole bunch of
ways you can compromise a Tomcat installation - none of which I would
consider security vulnerabilities. They would all be classed as
configuration errors. I do agree that such a scenario is pretty unlikely.

This comes down to the threat scenarios in which Tomcat is intended to
be secure. A vulnerability is, essentially, when an attacker is able to
bypass that security in some way.

Tomcat is not intended to be secure from attacks by malicious local
users if those local users have write access to any part of the Tomcat
installation.

Tomcat is intended to be secure from running malicious web applications
(they should not be able to view data from other web applications or
access other data on the server Tomcat is running on) providing a
SecurityManager is used. Where it gets interesting is that you cannot
protect against a DoS attack by a malicious web application - even when
running under a SecurityManager.

It would probably be a "Good Thing" to document the scenarios in which
Tomcat is intended to be secure. I think they are reasonably well
understood by the Tomcat committers - maybe not so much by the wider
community.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: How can I fix deserialization vulnerability?

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark,

On 3/11/16 4:10 AM, Mark Thomas wrote:
> On 11/03/2016 01:43, Christopher Schultz wrote:
>> 林慶龍,
>> 
>> On 3/10/16 8:07 PM, 林慶龍 Barry Lin wrote:
>>> These days, Everyone talks about the vulnerability in Tomcat,
>>> and we found that we had the same problem with “deserialization
>>>  vulnerability”.
>> 
>>> How can I fix deserialization vulnerability in tomcat?
>> 
>> If you don't have any applications that have known problematic
>> classes in them (such as the famous commons-collections bug),
>> then you aren't really in any danger.
> 
> That statement is dangerously incorrect.

I disagree, though my statement may easily be misunderstood.

> The vulnerability is not in Commons Collections or any of the
> various other libraries that have been leveraged in the various
> examples that have been made public.
> 
> The vulnerability is always that an application takes data from an 
> untrusted source and deserializes it without validation and/or 
> sanitation. If your application does this then you are almost
> certainly vulnerable to a deserialization attack of some form.

The vulnerability is in neither the library (e.g. commons-collections)
nor the application (Tomcat, in this case). Instead, the vulnerability
is in the interaction between the two of them.

Specifically, if you are using an application (Tomcat) that is
"vulnerable" (because it unsafely de-serializes untrusted streams) but
no "vulnerable" library is present, then it is not possible to exploit
this vulnerability.

>> You can disable session serialization, but if you don't trust
>> the files on your own disk then you probably have bigger
>> problems.
>> 
>> You can disable clustering, but if you don't trust the other
>> members of your cluster, then you probably have bigger problems.
>> 
>> You can disable session persistence, but if you don't trust your 
>> database, then you probably have bigger problems.
> 
> In 99.99% if use cases none of the above will be a problem since
> the data is trusted.
> 
> The vulnerability *only* applies when running untrusted web
> applications under a security manager (think hosting provider that
> only allows users to host WARs and uses a security manager to limit
> what those WARs can do). Because serialization and deserialization
> is performed by trusted code, it was possible for an untrusted web
> application to place a malicious object in the session that would,
> on deserialization, execute some code that would normally be
> blocked by the SecurityManager. If effect, this was a way for an
> untrusted app to bypass the constraints imposed by the
> SecurityManager.
> 
>> The reality is that this "deserialization vulnerability" is
>> wildly overblown. Yes, it should be mitigated, but the attack
>> vectors are very, very narrow.
> 
> Agreed.
> 
>> As of Tomcat 8.0.32, the session resumption "vulnerability" has
>> been mitigated in Tomcat itself if you configure it properly.
>> It's covered under "CVE-2016-0714" on this page: 
>> https://tomcat.apache.org/security-8.html
>> 
>> You need to either run Tomcat under a SecurityManager (in which
>> case, you'll get a non-null default value for this configuration
>> setting), or you need to set sessionAttributeValueClassNameFilter
>> on your <Manager> element in server.xml. 
>> https://tomcat.apache.org/tomcat-8.0-doc/config/manager.html
> 
> If you aren't running Tomcat under a security manager web
> applications can do whatever they like so this vulnerability is
> irrelevant.

I disagree. If you aren't running under a SecurityManager, it's still
possible (yet unlikely) for an attacker to inject a Trojan Horse into
Tomcat's session store. For example, a local user might be able to
escalate their privileges if they only have write access to the
session store. A SecurityManager might not help protect against such a
Trojan Horse, so the vulnerability IMO is definitely important even
under a SM.

>> (I admit I find the use of that CVE a little confusing, here, but
>> the patches for that CVE are the ones that also fix the
>> de-serialization vulnerability.)
> 
> What do you find confusing? I've re-read the CVE description and I 
> really can't see where it is unclear but given I wrote it pointers
> to what is unclear would be welcome.

I'm sorry, I must have been reading the wrong CVE. Re-checking them,
they are entirely accurate. (I had initially read the Tomcat
documentation saying something about a problem with the "Tomcat
manager", which wasn't the case). Apologies for the noise.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlbnJpoACgkQ9CaO5/Lv0PDiIgCgtPM6gqprqDsIWy2pQTNj/EkW
5kEAnR5MBH+97zrdkwjJKLjuk6+Her6X
=zim9
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: How can I fix deserialization vulnerability?

[Mark Thomas <ma...@apache.org>]

On 11/03/2016 01:43, Christopher Schultz wrote:
> 林慶龍,
> 
> On 3/10/16 8:07 PM, 林慶龍 Barry Lin wrote:
>> These days, Everyone talks about the vulnerability in Tomcat, and
>> we found that we had the same problem with “deserialization 
>> vulnerability”.
> 
>> How can I fix deserialization vulnerability in tomcat?
> 
> If you don't have any applications that have known problematic classes
> in them (such as the famous commons-collections bug), then you aren't
> really in any danger.

That statement is dangerously incorrect.

The vulnerability is not in Commons Collections or any of the various
other libraries that have been leveraged in the various examples that
have been made public.

The vulnerability is always that an application takes data from an
untrusted source and deserializes it without validation and/or
sanitation. If your application does this then you are almost certainly
vulnerable to a deserialization attack of some form.

> You can disable session serialization, but if you don't trust the
> files on your own disk then you probably have bigger problems.
> 
> You can disable clustering, but if you don't trust the other members
> of your cluster, then you probably have bigger problems.
> 
> You can disable session persistence, but if you don't trust your
> database, then you probably have bigger problems.

In 99.99% if use cases none of the above will be a problem since the
data is trusted.

The vulnerability *only* applies when running untrusted web applications
under a security manager (think hosting provider that only allows users
to host WARs and uses a security manager to limit what those WARs can
do). Because serialization and deserialization is performed by trusted
code, it was possible for an untrusted web application to place a
malicious object in the session that would, on deserialization, execute
some code that would normally be blocked by the SecurityManager. If
effect, this was a way for an untrusted app to bypass the constraints
imposed by the SecurityManager.

> The reality is that this "deserialization vulnerability" is wildly
> overblown. Yes, it should be mitigated, but the attack vectors are
> very, very narrow.

Agreed.

> As of Tomcat 8.0.32, the session resumption "vulnerability" has been
> mitigated in Tomcat itself if you configure it properly. It's covered
> under "CVE-2016-0714" on this page:
> https://tomcat.apache.org/security-8.html
> 
> You need to either run Tomcat under a SecurityManager (in which case,
> you'll get a non-null default value for this configuration setting),
> or you need to set sessionAttributeValueClassNameFilter on your
> <Manager> element in server.xml.
> https://tomcat.apache.org/tomcat-8.0-doc/config/manager.html

If you aren't running Tomcat under a security manager web applications
can do whatever they like so this vulnerability is irrelevant.

> (I admit I find the use of that CVE a little confusing, here, but the
> patches for that CVE are the ones that also fix the de-serialization
> vulnerability.)

What do you find confusing? I've re-read the CVE description and I
really can't see where it is unclear but given I wrote it pointers to
what is unclear would be welcome.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: How can I fix deserialization vulnerability?

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

林慶龍,

On 3/10/16 8:07 PM, 林慶龍 Barry Lin wrote:
> These days, Everyone talks about the vulnerability in Tomcat, and
> we found that we had the same problem with “deserialization 
> vulnerability”.
> 
> How can I fix deserialization vulnerability in tomcat?

If you don't have any applications that have known problematic classes
in them (such as the famous commons-collections bug), then you aren't
really in any danger.

You can disable session serialization, but if you don't trust the
files on your own disk then you probably have bigger problems.

You can disable clustering, but if you don't trust the other members
of your cluster, then you probably have bigger problems.

You can disable session persistence, but if you don't trust your
database, then you probably have bigger problems.

The reality is that this "deserialization vulnerability" is wildly
overblown. Yes, it should be mitigated, but the attack vectors are
very, very narrow.

As of Tomcat 8.0.32, the session resumption "vulnerability" has been
mitigated in Tomcat itself if you configure it properly. It's covered
under "CVE-2016-0714" on this page:
https://tomcat.apache.org/security-8.html

You need to either run Tomcat under a SecurityManager (in which case,
you'll get a non-null default value for this configuration setting),
or you need to set sessionAttributeValueClassNameFilter on your
<Manager> element in server.xml.
https://tomcat.apache.org/tomcat-8.0-doc/config/manager.html

(I admit I find the use of that CVE a little confusing, here, but the
patches for that CVE are the ones that also fix the de-serialization
vulnerability.)

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlbiIsMACgkQ9CaO5/Lv0PDbsACdEATTK7tFmAgw3Q8f43ZSTZYQ
GIsAoMNJOOSkpGmF+GPNKbgkbN93Okaw
=v0tc
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: How can I fix deserialization vulnerability?

[Rob Gansevles <rg...@gmail.com>]

Barry,

The deserialization-vulnerability for RMI endpoints in your webapp can be
mitigated using our library at https://github.com/Servoy/rmi-whitelist
Add it to the tomcat system library and classes like the
commons-collections can no longer be used in the serialisation attacks over
RMI.

Rob

2016-03-11 2:07 GMT+01:00 林慶龍 Barry Lin <u0...@digiwin.biz>:

> Dears:
>
> These days, Everyone talks about the vulnerability in Tomcat, and we found
> that we had the same problem with “deserialization vulnerability”.
>
> How can I fix deserialization vulnerability in tomcat?
>
> Thanks for your help!
>
>
>
>
>
> Best regard,
>
> Barry Lin
>
> 鼎捷
> (鼎新電腦股份有限公司、鼎誠資訊股份有限公司、鼎捷軟件股份有限公司及鼎捷軟件越南有限公司)將善保管您的個人資料，並於合法取得之前提下善意使用，據此本公司僅在營運範圍內之目的與您聯繫，包含鼎捷主辦或協辦之行銷活動、客戶服務、供應商聯繫等，非經由本公司上開目的下之合法授權，所寄發之資訊並不代表本公司
> 。本電子郵件及附件所載訊息均為保密資訊，受合約保護或依法不得洩漏。其內容僅供指定收件人按限定範圍或特殊目的使用。未經授權者收到此資訊者均無權閱讀、
> 使用、
> 複製、洩漏或散佈。若您因為誤傳而收到本郵件或者非本郵件之指定收件人，煩請即刻回覆郵件或並永久刪除此郵件及其附件和銷毀所有複印件。倘若有前述情形或信件誤遞至您的信箱或有相關問題，請透過下列方式聯繫更正；mail：
> dscmaz@digiwin.biz。謝謝您的合作！
>