Major flaw in Java-based Spring Framework allows remote-code execution | Hacker News Reader

Major flaw in Java-based Spring Framework allows remote-code execution

networkworld.com

77 pointsrgarcia43 comments

Open articleView on HN

Not sure about the veracity of this, but:

https://twitter.com/AlBaker_Dev/status/292415396684918784

"That was fixed in 2011, Spring 3.0.6 and 2.5.6SEC03, enjoy!"

It's valid. Here's more info: http://support.springsource.com/security/cve-2011-2730

And here's an overview for all Spring modules: http://support.springsource.com/security/springsource-all

3.0.6 and 2.5.6SEC03 require explicit configuration to fix this - they are not safe by default. 3.1 is safe without config.

see http://www.h-online.com/open/news/item/The-ghost-of-a-Spring...

This is needless scaremongering ! If you write a web application that blindly executes/evals the contents of a request parameter or submitted form data, you need to have to have your head examined and not blame the underlying framework for security vulnerability. These security experts wrote a JSP page with a intentionally flawed code that passes an incoming request parameter to an expression evaluation engine: <spring:message text="" code="${param['message']}"> </spring:message>. what did you expect will happen?

No framework is invulnerable against idiot programmers.

you have misunderstood. the problem (afaict - see link below) is that spring may be evaluating where the programmer intended only to display. see my comment at http://news.ycombinator.com/item?id=5083163

the programmer is not evaluating unvalidated text. the programmer is only displaying it. the bug in spring is causing the unexpected, additional evaluation.

see, for example, section 3 of https://docs.google.com/document/d/1dc1xxO8UMFaGLOwgkykYdghG...

No I am not mistaken. I have been using this taglib and EL when renedering JSPs. This is how most people use this EL http://stackoverflow.com/questions/10981559/how-to-change-va...

http://www.coderanch.com/t/489232/Spring/spring-message-tag-... See that ? Nobody is using request parameters because that would be fucking stupid. This is a an Expression Evaluation Engine --- it evaluates expressions. Every programmer who uses this knows this.

Please stop spreading the FUD!

><spring:message text="" code="${param['message']}"> </spring:message>. what did you expect will happen?

I expect ${param['message']} to be evaluated to a string, then the string to be used to look up a message. What I don't expect is the string to be evaluated again... Why would I?

.. because you are feeding it into an evaluation engine. Thats why. If you wanted the expression to be evaluated into a string , then you would use JSP standard way of doing it which is <%=whatever>.

The technical details can be found here: https://www.aspectsecurity.com/uploads/downloads/2012/12/Rem...

So these guys have issued a new report for an issue first announced/reported in 2011?

I'm missing what new discovery they've made, beyond the misleading count of how many people have downloaded the jars from a maven repository.

Yeah, I guess they are just re-interating that a lot of people are still on 3.0.5 and they might want to look at upgrading.

Here's the original article:

http://www.mindedsecurity.com/fileshare/ExpressionLanguageIn...

a rough idea of what is happening here - this is something like sql injection, but for jsp pages. if you use un-sanitized data in a jsp page, evaluated via spring's expression language, then you may execute code, provided by users, on the server.

(expression language can be used elsewhere, but it's not so common and much less likely to received user-supplied parameters)

also, this article http://www.h-online.com/open/news/item/The-ghost-of-a-Spring... is much clearer about affected versions (3.0.5 and below are bad; 3.0.6 can be fixed via config; 3.1 is ok)

i'm worried the above may have confused and incorrectly reassured people, given the other comments here.

this does not require explicit evaluation. it can occur when you were only trying to display the data.

it is a serious bug, not a stupid programming mistake.

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

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.

...how is this different for complaining that "SQL is unsafe because of injection possibilities"?

...do real world Spring web apps really use unsanitized user input with "expression language" queries? (or am I totally missing the point? - not a Spring guy, I admit, but it all reads weird to me)

the point is that spring's el was evaluating things TWICE.

if i give my name as "$account.increment" then the worst you would expect to happen is that when my name is displayed it appears as "$account.increment". right?

in steps:

  the jsp page contains <cout value="$user">

  el looks at $user and finds the text "$account.increment" and *displays* that.

this is completely ok and does not require input sanitization. the code does not appear unsafe.

but no - there is the possibility that instead of simply displaying the value, spring will (may - i don't understand exactly when this is triggered) evaluate it. in steps:

  the jsp page contains <cout value="$user">

  el looks at $user and finds the text "$account.increment".

  el *evaluates* $account.increment and increments the account.  PLOP!

  el displays the result of evaluating the account.

again: this occurs when the programmer was only intending to display the value. because spring (by mistake) has a second round of evaluation (first is $user to contents; second is contents to incrementing account), text that should simply be displayed can be evaluated.

see, for example https://docs.google.com/document/d/1dc1xxO8UMFaGLOwgkykYdghG...

an update (edit window is past). it's more complex than i explained above. only a restricted number of tags (spring ones) are affected and you have to be doing fairly stupid things (using user parameters in strange ways). the normal use case of displaying a value is not a risk. sorry.

https://github.com/based2/checker-maven-plugin/blob/master/s...

I get quite upset when I see companies scaremonger for PR rather than try to help those who are actually doing things.

It seems to follow a particular pattern. Find a bug or bug class in $product. Then start screaming from the rooftops about how the sky is falling without telling people how to stop it or what the problem is. Finally release limited fix info via a mailing list or conference. In the end, everyone loses.

Is there an up-to-date document of Java security issues somewhere, preferably with explanations?

I don't use Java much these days but I am teaching my kids OOP using Java. I'd like to also take the opportunity to show him where the warts are.

In the service of "teach him to walk prior to attempting to teaching him to run", maybe you could start with a discussion of software security, and then show him an example of how bad guys can use good code that looks trivial to do things you don't want them to do. You can come up with numerous vulnerabilities in application code using any reduced subset of Java which he understands. Without that background, he'd have to learn an awful lot of Deep Magick about J2EE to understand what is happening here.

For a simple example, write a bare bones web server where localhost/dir/file.html serves documentroot/dir/file.html.

Extend it with directory browsing, if you want.

Then, show them the joy of localhost/../../secret/mydiary.txt

> I am teaching my kids OOP using Java.

I'd suggest doing it with Smalltalk, Ruby or Python. If I had to learn to program with Java, I'd open a restaurant.

Tons of people have learned to program with Java. Might not be as elegant as other languages but the fundamentals are the same.

Why not use something nice if you have the chance? Using your arguments about fundamentals, it's not even necessary to treat him computer science, he could just learn maths and he has all the foundations he needs.

> Tons of people have learned to program with Java

http://en.wikipedia.org/wiki/Argumentum_ad_populum

> the fundamentals are the same.

Only if all your fundamentals are restricted to what Java implements. A student that knows only Java may have trouble using multiple inheritance, first-class functions or prototype-based inheritance. I've seen a lot of Java programmers who cannot grasp these ideas and get utterly lost. It's not fun to watch.

Or at least Scala...

Not quite sure Scala is a good language to learn in. Learning curve is higher than other languages.

I'm biased as I already knew Java when I learned Scala, but Scala, if you ignore the crazy parts (e.g. don't look at the scala own sources for example) then it's quite a simple language. Much simpler than Java in my very humble opinion, it feels a lot like Ruby / Python to me actually. Another advantage I find in Scala, is that for new learners, they get the safeguard of a typed language and all the protection that comes with it, if you write incorrect syntax, you get an immediate feedback, and for new learners, I think it's a great feedback loop. Although I really like Python, I found that implementing things in it for the Udacity CS courses for example, is much harder for me (just because I'm less familiar with Python probably) than Scala, I tried implementing the same homework in Scala, and it was much more intuitive, especially collection handling, and writing "functional style" code, and I didn't have to go to the web and read the docs every seconds because of the notorious, loved to be hated, heavy but yet spoiling comfort of the IDE's content assist. Anyway, it's a matter of taste, and I like the Scala flavor. But here I am spending more time on the Ruby tutorial than on the Play framework tutorial, so I guess the language itself is not all that matters...

Not sure that showing them security vulnerabilities in the JVM is going to do much good if they are still in the learning phase.

http://www.metasploit.com/modules/framework/search?utf8=%E2%... is a good start.

That's a nice site, thanks.

> While the vulnerability that Aspect Security uncovered is not "trivial to exploit," acknowledged Williams, he has no doubt that determined attackers will do so.

The quotes should cover 'not' as well i.e. "not trivial to exploit".

As long as you're not injecting unvalidated request parameters in your JSPs, you will be fine.

And if you do this you are a wally anyway...

Meh no worries.

If there is a flaw you probably need to write like 5M of XML to exploit it.

Reply on news.ycombinator.com