Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Protect against security exploits via system identifier in DTD declaration [SPR-11768] #16390
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
Backported to: 3.2.9
David Jorm commented
I emailed the below to email@example.com on 2014-06-17 and 2014-07-11, and received no reply.
While reviewing the advisory for this issue:
I noticed that the patch commit for 3.2.9:
Does not address external parameter entities. The initial bug for CVE-2013-4152:
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 firstname.lastname@example.org:spring-projects/spring-framework.git
That said, I am unable to exploit this issue on 3.2.9, as the CVE-2014-0225 patch disables entity resolution entirely:
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:
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.
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）.