Skip to main content

ShareScan Apache Tomcat 6.3 vulnerabilities

Article # 3026333 - Page views: 450




Is ShareScan Tomcat 9.0.36 vulnerable?






1. Vulnerabilities that belongs to Apache Tomcat 9.0.0.M1 < 9.0.37 Multiple Vulnerabilities



  • 1.a) Moderate: HTTP/2 DoS CVE-2020-13934


    • Description: An h2c direct connection did not release the HTTP/1.1 processor after the upgrade to HTTP/2. If a sufficient number of such requests were made, an OutOfMemoryException could occur leading to a denial of service.


    • Fixed in 9.0.37


    • Affects: 9.0.0.M5 to 9.0.36


    • Conclusion: This type of vulnerability does not affect eCopy since we do not support HTTP/2.


  • 1.b)Important: WebSocket DoS CVE-2020-13935


    • Description: The payload length in a WebSocket frame was not correctly validated.


    • Invalid payload lengths could trigger an infinite loop. Multiple requests with invalid payload lengths could lead to a denial of service.


    • Fixed in 9.0.37


    • Affects: 9.0.0.M1 to 9.0.36


    • Conclusion: ECopy does not use websockets therefore this therefore such vulnerability does not affect us.


2. Vulnerabilities that belongs to Apache Tomcat 8.5.x < 8.5.58 / 9.0.x < 9.0.38 HTTP/2 Request Mix-Up



  • 2.a)Moderate: HTTP/2 request mix-up CVE-2020-13943


    • If an HTTP/2 client exceeded the agreed maximum number of concurrent streams for a connection (in violation of the HTTP/2 protocol), it was possible that a subsequent request made on that connection could contain HTTP headers - including HTTP/2 pseudo headers - from a previous request rather than the intended headers. This could lead to users seeing responses for unexpected resources


    • Fixed in 9.0.38


    • Affects: 9.0.0.M1 to 9.0.37
  • Conclusion: This type of vulnerability does not affect eCopy since we do not support HTTP/2.


3. Vulnerabilities that belongs to Apache Tomcat 9.x < 9.0.40 Information Disclosure



3.a)Important: Information disclosure CVE-2021-24122

    • When serving resources from a network location using the NTFS file system it was possible to bypass security constraints and/or view the source code for JSPs in some configurations. The root cause was the unexpected behaviour of the JRE API File.getCanonicalPath() which in turn was caused by the inconsistent behaviour of the Windows API (FindFirstFileW) in some circumstances.


    • Fixed in 9.0.40


    • Affects: 9.0.0.M1 to 9.0.39


    • Conclusion: eCopy does not provide JSP pages, so there isn't any source that would be affected


  • 3.b)Moderate: HTTP/2 request header mix-up CVE-2020-17527


    • While investigating issue 64830 it was discovered that Apache Tomcat could re-use an HTTP request header value from the previous stream received on an HTTP/2 connection for the request associated with the subsequent stream. While this would most likely lead to an error and the closure of the HTTP/2 connection, it is possible that information could leak between requests.


    • Fixed in 9.0.40


    • Affects: 9.0.0-M1 to 9.0.39


    • Conclusion: This type of vulnerability does not affect eCopy since we do not support HTTP/2.


4. OWASP quidence regarding Apache Tomcat Default Files



·         Conclusion:



o   the ROOT default index page has never been deleted but the underlaying links and references are, therefore the existence of index page could not cause any security issues



o   example JSP and other servlet pages are already deleted



o   the default error page is not being used



o   after all I think we comply to OWASP guides



5. Request mix-up with h2c CVE-2021-25122



·         Fixed in Tomcat 9.0.43



·         Affects: Tomcat 9.0.36



Detailed description: When responding to new h2c connection requests, Apache Tomcat could duplicate request headers and a limited amount of request body from one request to another meaning user A and user B could both see the results of user A's request.



·         From Tomcat docs



HTTP/2 is support is provided for TLS (h2), non-TLS via HTTP upgrade (h2c) and direct HTTP/2 (h2c) connections. To enable HTTP/2 support for an HTTP connector the following UpgradeProtocol element must be nested within the Connector with a className attribute of org.apache.coyote.http2.Http2Protocol.



Risk to customer (conclusion): The customer is not affected by this security vulnerability. The risk cannot be exploited as we do not use the connection type highlighted in the CVE.



 6.) CVE-2021-25329



·         Fixed in Tomcat 9.0.43



·         Affects: Tomcat 9.0.36



 Detailed description:



The fix for CVE-2020-9484 was incomplete. When using Apache Tomcat 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41, 8.5.0 to 8.5.61 or 7.0.0. to 7.0.107 with a configuration edge case that was highly unlikely to be used, the Tomcat instance was still vulnerable to CVE-2020-9494. Note that both the previously published prerequisites for CVE-2020-9484 and the previously published mitigations for CVE-2020-9484 also apply to this issue.



When you look up CVE-2020-9484






 When using Apache Tomcat versions 10.0.0-M1 to 10.0.0-M4, 9.0.0.M1 to 9.0.34, 8.5.0 to 8.5.54 and 7.0.0 to 7.0.103 if



a) an attacker is able to control the contents and name of a file on the server; and
b) the server is configured to use the PersistenceManager with a FileStore; and
c) the PersistenceManager is configured with sessionAttributeValueClassNameFilter="null" (the default unless a SecurityManager is used) or a sufficiently lax filter to allow the attacker provided object to be deserialized; and
d) the attacker knows the relative file path from the storage location used by FileStore to the file the attacker has control over; then, using a specifically crafted request, the attacker will be able to trigger remote code execution via deserialization of the file under their control. Note that all of conditions a) to d) must be true for the attack to succeed.



Risk to customer (conclusion): The risk to customer is low. Mainly, it can't happen. The risk requires a specific configuration and set of circumstances that are not likely. For example the hacker requires access to the server and must be able to control files on the server which they wont have.

















Applies to:  

Product Version
Kofax eCopy ShareScan 6.3



  • Was this article helpful?