Hacker News Reader

Comment by mappu | Hacker News Reader

I administer some servers running a third-party java application under tomcat. How can i tell whether it uses Spring or a vulnerable template?

View on HN

something like

    find apache-tomcat-7.0.23/ -name "spring*.jar"

should show things like:

    apache-tomcat-7.0.23/webapps/bss/WEB-INF/lib/spring-beans-3.1.1.RELEASE.jar
    apache-tomcat-7.0.23/webapps/bss/WEB-INF/lib/spring-core-3.1.1.RELEASE.jar
    apache-tomcat-7.0.23/webapps/bss/WEB-INF/lib/spring-expression-3.1.1.RELEASE.jar

and you need to worry if those version numbers are 3.0.6 or lower. you only really need to worry about the expression language, which is the last one, but i cannot promise it is named the same in other versions.

also, this assumes that the project was built with maven or otherwise uses standard jar names. if the jar was hand-rolled and named then it could look like anything... (in which case applicationContext.xml, as suggested elsewhere, at least warns you it's spring).

Are you deliberately spamming this board with FUD ?

spring-beans and spring-core are the fundamental building blocks of most Java EE applications and using them in no way causes the aforementioned vulnerability.

The only case that causes this vulnerability is when a JSP page contains this code : <spring:message text="" code="${param['message']}"></spring:message> Any admin can run fgrep or equivalent on all jsps to see if they contain this text <spring:message text="" code="${param

param is not really part of the bug - if I understand correctly, any argument passed to the these tags will be evaluated twice. So you have to check for message/theme/bind/nestedpath/transform tags and ensure no user-influenced data is fed to it.

And if you use a templating engine that uses these tags you'd have to trace whether they are invoked anywhere... So it's not as simple as a grep at all.

I think tomcat can run webapps from packed .wars too, so this isn't a foolproof way to find the negative

Yes, you 'deploy' the .war file in the webapps Tomcat subfolder. But when Tomcat is started, it extracts the file (which is essentialy a .zip arhive) in the same folder.

By default, this is true. However, you can set <Host unpackWARs="false"> so that it runs applications directly from the WAR file without extracting it.

If you have access to the folder where the application is deployed (eg. TOMCAT/webapps/) you can take a look at (TOMCAT/webapps/3rdpartyapp/WEB-INF/) and if you see files called applicationContext.xml or any spring.jar files under WEB-INF/lib, it uses Spring.

Reply on news.ycombinator.com