6 ms·

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

77 points by rgarcia 14y ago

bingo_cannon 14y ago
> 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".
mh8h 14y ago
The technical details can be found here: https://www.aspectsecurity.com/uploads/downloads/2012/12/Remote-Code-with-Expression-Language-Injection.pdf https://www.aspectsecurity.com/uploads/downloads/2012/12/Rem...
- brown9-2 14y ago
  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.
  - matdrewin 14y ago
    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/ExpressionLanguageInjection.pdf http://www.mindedsecurity.com/fileshare/ExpressionLanguageIn...
mappu 14y ago
I administer some servers running a third-party java application under tomcat. How can i tell whether it uses Spring or a vulnerable template?
- eccp 14y ago
  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.
- andrewcooke 14y ago
  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.
  - 14y ago
andrewcooke 14y ago
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-Framework-bug-haunts-old-code-1786850.html 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)
- andrewcooke 14y ago
  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.
robomartin 14y ago
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.
- rbanffy 14y ago
  > 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.
  - matdrewin 14y ago
    Tons of people have learned to program with Java. Might not be as elegant as other languages but the fundamentals are the same.
    - iso-8859-1 14y ago
      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.
    - rbanffy 14y ago
      > Tons of people have learned to program with Java http://en.wikipedia.org/wiki/Argumentum_ad_populum 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.
  - eranation 14y ago
    Or at least Scala...
bhauer 14y ago
Not sure about the veracity of this, but: https://twitter.com/AlBaker_Dev/status/292415396684918784 https://twitter.com/AlBaker_Dev/status/292415396684918784 "That was fixed in 2011, Spring 3.0.6 and 2.5.6SEC03, enjoy!"
- moondowner 14y ago
  It's valid. Here's more info: http://support.springsource.com/security/cve-2011-2730 http://support.springsource.com/security/cve-2011-2730 And here's an overview for all Spring modules: http://support.springsource.com/security/springsource-all http://support.springsource.com/security/springsource-all
- andrewcooke 14y ago
  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-Framework-bug-haunts-old-code-1786850.html http://www.h-online.com/open/news/item/The-ghost-of-a-Spring...
matdrewin 14y ago
As long as you're not injecting unvalidated request parameters in your JSPs, you will be fine.
- meaty 14y ago
  And if you do this you are a wally anyway...
manishsharan 14y ago
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.
- andrewcooke 14y ago
  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 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/1dc1xxO8UMFaGLOwgkykYdghGWm_2Gn0iCrxFsympqcE/edit?hl=en_US&pli=1 https://docs.google.com/document/d/1dc1xxO8UMFaGLOwgkykYdghG...
  - manishsharan 14y ago
    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-value-of-code-in-springmessage-code http://stackoverflow.com/questions/10981559/how-to-change-va... http://www.coderanch.com/t/489232/Spring/spring-message-tag-labels-java 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!
    - deleted 14y ago
      [deleted]
- 14y ago
nnq 14y ago
...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)
- andrewcooke 14y ago
  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/1dc1xxO8UMFaGLOwgkykYdghGWm_2Gn0iCrxFsympqcE/edit?hl=en_US&pli=1 https://docs.google.com/document/d/1dc1xxO8UMFaGLOwgkykYdghG...
  - andrewcooke 14y ago
    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.
iuguy 14y ago
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.
based2 14y ago
https://github.com/based2/checker-maven-plugin/blob/master/src/main/resources/java_cve.json https://github.com/based2/checker-maven-plugin/blob/master/s...
pootch 14y ago
This article is total bullshit, and I challenge the folks who are partying on the "java is insecure" thread to make a case to people who know more about what an actual exploit is. Like me. I dont code in Java anymore, but I sure as hell know a charlatan when I see one.
tonetheman 14y ago
Meh no worries. If there is a flaw you probably need to write like 5M of XML to exploit it.

77 points by rgarcia 14y ago

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

mh8h 14y ago

The technical details can be found here: https://www.aspectsecurity.com/uploads/downloads/2012/12/Remote-Code-with-Expression-Language-Injection.pdf https://www.aspectsecurity.com/uploads/downloads/2012/12/Rem...

brown9-2 14y ago
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.
- matdrewin 14y ago
  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/ExpressionLanguageInjection.pdf http://www.mindedsecurity.com/fileshare/ExpressionLanguageIn...

mappu 14y ago

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

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

andrewcooke 14y ago

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-Framework-bug-haunts-old-code-1786850.html 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)

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

robomartin 14y ago

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.

rbanffy 14y ago
> 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.
- matdrewin 14y ago
  Tons of people have learned to program with Java. Might not be as elegant as other languages but the fundamentals are the same.
  - iso-8859-1 14y ago
    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.
  - rbanffy 14y ago
    > Tons of people have learned to program with Java http://en.wikipedia.org/wiki/Argumentum_ad_populum 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.
- eranation 14y ago
  Or at least Scala...

bhauer 14y ago

Not sure about the veracity of this, but: https://twitter.com/AlBaker_Dev/status/292415396684918784 https://twitter.com/AlBaker_Dev/status/292415396684918784 "That was fixed in 2011, Spring 3.0.6 and 2.5.6SEC03, enjoy!"

moondowner 14y ago
It's valid. Here's more info: http://support.springsource.com/security/cve-2011-2730 http://support.springsource.com/security/cve-2011-2730 And here's an overview for all Spring modules: http://support.springsource.com/security/springsource-all http://support.springsource.com/security/springsource-all
andrewcooke 14y ago
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-Framework-bug-haunts-old-code-1786850.html http://www.h-online.com/open/news/item/The-ghost-of-a-Spring...

matdrewin 14y ago

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

meaty 14y ago
And if you do this you are a wally anyway...

manishsharan 14y ago

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.

andrewcooke 14y ago
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 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/1dc1xxO8UMFaGLOwgkykYdghGWm_2Gn0iCrxFsympqcE/edit?hl=en_US&pli=1 https://docs.google.com/document/d/1dc1xxO8UMFaGLOwgkykYdghG...
- manishsharan 14y ago
  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-value-of-code-in-springmessage-code http://stackoverflow.com/questions/10981559/how-to-change-va... http://www.coderanch.com/t/489232/Spring/spring-message-tag-labels-java 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!
  - deleted 14y ago
    [deleted]
14y ago

nnq 14y ago

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

andrewcooke 14y ago
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/1dc1xxO8UMFaGLOwgkykYdghGWm_2Gn0iCrxFsympqcE/edit?hl=en_US&pli=1 https://docs.google.com/document/d/1dc1xxO8UMFaGLOwgkykYdghG...
- andrewcooke 14y ago
  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.

iuguy 14y ago

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.

based2 14y ago

https://github.com/based2/checker-maven-plugin/blob/master/src/main/resources/java_cve.json https://github.com/based2/checker-maven-plugin/blob/master/s...

pootch 14y ago

This article is total bullshit, and I challenge the folks who are partying on the "java is insecure" thread to make a case to people who know more about what an actual exploit is. Like me. I dont code in Java anymore, but I sure as hell know a charlatan when I see one.

tonetheman 14y ago

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