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