[jira] [Commented] (JUDDI-1003) spring-web jar supplied with latest JUDDI distribution has security vulnerability

["Alex O'Ree (Jira)" <ju...@ws.apache.org>]

    [ https://issues.apache.org/jira/browse/JUDDI-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17016482#comment-17016482 ] 

Alex O'Ree commented on JUDDI-1003:
-----------------------------------

thanks for the report, any idea what CVE this is or where you got the info from? from the post, i'm not sure what the fix version is

> 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
>            Priority: Major
>
> 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)