java deserialization vulnerability for Tomcat 7/8

[satish jupalli <ju...@gmail.com>]

Hi,

Would like to get your opinion on the java deserialization vulnerability
issue for Tomcat. As Jboss seems to have been impacted with, is there a way
to verify wether this vulnerability affects Tomcat as well?

Regards
SJ

Re: java deserialization vulnerability for Tomcat 7/8

[Johan Compagner <jc...@servoy.com>]

don't think tomcat by default ships with commons collections

But of course its not just commons collections its a more generic problem
that could be hit if there are more special classes that do special things
in deserialization.

i do think that tomcat by default (even the manager app or there jmx proxy
servlet) doesn't use java serialization to the outside world
And the jmx port should be default only accessible from localhost



On 11 November 2015 at 13:58, satish jupalli <ju...@gmail.com> wrote:

> Hi,
>
> Would like to get your opinion on the java deserialization vulnerability
> issue for Tomcat. As Jboss seems to have been impacted with, is there a way
> to verify wether this vulnerability affects Tomcat as well?
>
> Regards
> SJ
>



-- 
Johan Compagner
Servoy

Re: java deserialization vulnerability for Tomcat 7/8

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

Johan,

On 11/11/15 8:53 AM, Johan Compagner wrote:
> On 11 November 2015 at 14:44, Christopher Schultz <
> chris@christopherschultz.net> wrote:
> 
>> Tomcat could potentially be
>> used as an attack vector against a system by someone with write-access
>> to the part of the filesystem where Tomcat stores its serialized session
>> objects during a restart
>>
> 
> if you already can do that... then i think there are other problems first ;)

Of course, but it's a way to attack the server using Tomcat's runtime
privileges that does not necessarily require the attacker to already
have Tomcat's runtime privileges.

If the SESSIONS.ser file is stored somewhere like /tmp or has lazy file
permissions, it may be possible to overwrite it. A default Tomcat
installation is trivially "stoppable" by anyone with localhost access...
just send "SHUTDOWN" to port 8005 and the server stops.

So while I think it's not very likely that Tomcat's SESSIONS.ser file is
writable by a non-tomcat user AND of course that already having
localhost access is pretty much game-over, there is the possibility of a
privilege escalation, here.

... and someone could potentially blame Tomcat, because Tomcat is the
one calling ObjectInputStream.readObject, not the application.

I don't see any great mitigations against this kind of thing other than
signing/encrypting the serialized sessions file, but then you have the
problem is protecting the key used for that purpose: you've added no
security, only moved the problem.

Besides, simply not allowing anyone to overwrite SESSIONS.ser is the
proper mitigation, here.

-chris

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

Re: java deserialization vulnerability for Tomcat 7/8

[Johan Compagner <jc...@servoy.com>]

On 11 November 2015 at 14:44, Christopher Schultz <
chris@christopherschultz.net> wrote:

> Tomcat could potentially be
> used as an attack vector against a system by someone with write-access
> to the part of the filesystem where Tomcat stores its serialized session
> objects during a restart
>

if you already can do that... then i think there are other problems first ;)


-- 
Johan Compagner
Servoy

Re: java deserialization vulnerability for Tomcat 7/8

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

Satish,

On 11/11/15 8:10 AM, Christopher Schultz wrote:
> Satish,
> 
> On 11/11/15 7:58 AM, satish jupalli wrote:
>> Would like to get your opinion on the java deserialization vulnerability
>> issue for Tomcat. As Jboss seems to have been impacted with, is there a way
>> to verify wether this vulnerability affects Tomcat as well?
> 
> Are you talking about this one?
> http://www.infoq.com/news/2015/11/commons-exploit
> 
> Tomcat does not deserialize object streams from untrusted sources, so
> Tomcat has no vulnerability, here. Also, Tomcat does not use any of the
> libraries mentioned in the report, though I'm sure that list is now
> exhaustive.
> 
> Applications running on Tomcat may, however, be vulnerable to this
> attack, but the vector isn't Tomcat: it's the application and its
> failure to validate data from an untrusted source before deserializing
> such data.

Let me slightly amend my statement above: Tomcat could potentially be
used as an attack vector against a system by someone with write-access
to the part of the filesystem where Tomcat stores its serialized session
objects during a restart (if that session-saving feature is enabled):

1. Attacker locates an application with commons-collections
   (or a similar library with that kind of capability)
2. Attacker shuts down Tomcat
3. Attacker modifies the serialized session file to include
   a trojan horse

The attacker doesn't even have to restart Tomcat: if an administrator
notices that Tomcat is stopped, the admin might just go ahead and
re-start Tomcat and - boom - your exploit is run.

Now, the above isn't very likely, but it certainly is possible. If you
have an attacker with write access to your files, you have kind of
already lost the battle.

Even if there is no vulnerable application, an attacker with write
access to Tomcat's directories might be able to install
commons-collections (etc.) into Tomcat's lib/ directory and then perform
the same type of attack against the ROOT application.

-chris

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

Re: java deserialization vulnerability for Tomcat 7/8

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

Satish,

On 11/11/15 7:58 AM, satish jupalli wrote:
> Would like to get your opinion on the java deserialization vulnerability
> issue for Tomcat. As Jboss seems to have been impacted with, is there a way
> to verify wether this vulnerability affects Tomcat as well?

Are you talking about this one?
http://www.infoq.com/news/2015/11/commons-exploit

Tomcat does not deserialize object streams from untrusted sources, so
Tomcat has no vulnerability, here. Also, Tomcat does not use any of the
libraries mentioned in the report, though I'm sure that list is now
exhaustive.

Applications running on Tomcat may, however, be vulnerable to this
attack, but the vector isn't Tomcat: it's the application and its
failure to validate data from an untrusted source before deserializing
such data.

-chris

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