Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Protect against security exploits via system identifier in DTD declaration [SPR-11768] #16390

Closed
spring-issuemaster opened this issue May 8, 2014 · 4 comments

Comments

@spring-issuemaster
Copy link
Collaborator

commented May 8, 2014

Rossen Stoyanchev opened SPR-11768 and commented

A DTD declaration contains a system identifier, which can be exploited for example to scan for valid URLs gauged by the response time (quick response=valid, slower response=not valid) or can potentially be further combined with other vulnerabilities where simply accessing a URL can have side effects.

Example DTD declaration:

<!DOCTYPE html SYSTEM "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Affects: 3.2.8, 4.0.4

Attachments:

Backported to: 3.2.9

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 22, 2014

David Jorm commented

I emailed the below to security@gopivotal.com on 2014-06-17 and 2014-07-11, and received no reply.

While reviewing the advisory for this issue:

http://www.gopivotal.com/security/cve-2014-0225

I noticed that the patch commit for 3.2.9:

c6503eb

Does not address external parameter entities. The initial bug for CVE-2013-4152:

#15432

Notes advice from the OWASP XXE guide, which until I edited it in June, contained no guidance on disabling external parameter entity resolution. It looks like this is not disabled in any of the spring-framework code:

$ git clone git@github.com:spring-projects/spring-framework.git
$ cd spring-framework
$ grep -R parameter-ent *
Binary file gradle/jdiff/xerces.jar matches
$

That said, I am unable to exploit this issue on 3.2.9, as the CVE-2014-0225 patch disables entity resolution entirely:

xmlReader.setEntityResolver(NO_OP_ENTITY_RESOLVER);

A side-affect of this is that it also blocks parameter entity attacks. I have been able to reproduce a full XXE attack against 3.2.8. This attack can exfiltrate data using only parameter entities, as per the technique shown on page 15:
http://2013.appsecusa.org/2013/wp-content/uploads/2013/12/WhatYouDidntKnowAboutXXEAttacks.pdf

I think that either this flaw needs its own CVE ID, or the description and severity rating of CVE-2014-0225 should be expanded to state that full XXE attacks are possible in unpatched versions of the spring framework, not just server side request forgery.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 14, 2014

Nebula commented

XEE,my papers http://drops.wooyun.org/papers/1911 ,Without this scene, a small hazard(spring mvc JAXB xml to pojo unMarshaller)

DTD can also XEE , Can form many types of security vulnerabilities,For example: XXE,SSRF(Server-side Request Forgery,for example: http ,ftp Protocol SSRF),DoS....,Fix one is enough.

"not just server side request forgery." ,This is not right, for large application vulnerability risks SSRF than XXE (For example:cloud application's internal network).

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 15, 2014

Nebula commented

XEE ---> XXE

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 15, 2014

Nebula commented

Because the request is initiated by the current application, so it can be used to bypass the front-end WAF.

Use very much, not limited to those

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.