Re: java deserialization vulnerability for Tomcat 7/8
Johan, On 11/11/15 8:53 AM, Johan Compagner wrote: > On 11 November 2015 at 14:44, Christopher Schultz < > ch...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: java deserialization vulnerability for Tomcat 7/8
On 11 November 2015 at 14:44, Christopher Schultz < ch...@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
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: java deserialization vulnerability for Tomcat 7/8
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: java deserialization vulnerability for Tomcat 7/8
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 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
java deserialization vulnerability for Tomcat 7/8
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