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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
