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