4 ms·

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.

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).

0x0 14y ago
I think tomcat can run webapps from packed .wars too, so this isn't a foolproof way to find the negative
- moondowner 14y ago
  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.
  - btgeekboy 14y ago
    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.
manishsharan 14y ago
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
- Anderkent 14y ago
  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.

0x0 14y ago

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

moondowner 14y ago
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.
- btgeekboy 14y ago
  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.

manishsharan 14y ago

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

Anderkent 14y ago
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.