[
https://issues.apache.org/jira/browse/JUDDI-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex O'Ree resolved JUDDI-1003.
-------------------------------
Resolution: Fixed
> spring-web jar supplied with latest JUDDI distribution has security
> vulnerability
> ---------------------------------------------------------------------------------
>
> Key: JUDDI-1003
> URL: https://issues.apache.org/jira/browse/JUDDI-1003
> Project: jUDDI
> Issue Type: Bug
> Components: juddi-tomcat
> Affects Versions: 3.3.6, 3.3.7
> Reporter: Amol Bhonsle
> Assignee: Alex O'Ree
> Priority: Major
> Fix For: 3.3.8
>
>
> The jar for spring-web (JUDDI 3.3.7 comes with spring-web-3.2.18.RELEASE)
> which is provided in distribution has following Security Vulnerability.
>
> The {{org.springframework:spring-web}} package is vulnerable to
> deserialization of untrusted data leading to Remote Code Execution (RCE).
> The {{readRemoteInvocation}} method in {{HttpInvokerServiceExporter.class}}
> does not properly verify or restrict untrusted objects prior to deserializing
> them. An attacker can exploit this vulnerability by sending malicious
> requests containing crafted objects, which when deserialized, execute
> arbitrary code on the vulnerable system.
>
> The {{spring-core}} and {{spring-web}} modules of Spring Framework are
> vulnerable to a multipart content pollution vulnerability. The
> {{generateMultipartBoundary()}} method in the {{MimeTypeUtils}} class uses a
> predictable method of generating random values to use as boundary values for
> multipart requests to other servers. This means that an attacker may be able
> to predict the boundary values and inject them into requests at unexpected
> locations, causing the recipient server to incorrectly interpret the
> multipart request. This will result in unexpected behavior depending on the
> requests being processed, including privilege escalation if authorization
> data is sent in the multipart request.
> Note:
> {quote}In order for the attacker to succeed, they would have to be able to
> guess the multipart boundary value chosen by server A for the multipart
> request to server B, which requires the attacker to also have control of the
> server or the ability to see the HTTP log of server A through a separate
> attack vector.
> {quote}
>
> Spring Framework is vulnerable to Cross-Site Tracing (XST) attacks. The
> {{HiddenHttpMethodFilter}} class lets an attacker change the HTTP request
> method to {{TRACE}}. An attacker can exploit this behavior with an Cross-Site
> Scripting (XSS) attack by sending a TRACE request and recovering information
> that would not normally be accessible, such as Cookies with the HTTPOnly flag.
>
> Please check and provide fix for this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
