[jira] [Updated] (AMQ-7279) Security Vulnerabilities in Libraries - jackson-databind-2.9.8.jar, tomcat-servlet-api-8.0.53.jar, tomcat-websocket-api-8.0.53.jar, zookeeper-3.4.6.jar, guava-18.0.jar, jetty-all-9.2.26.v20180806.jar, scala-library-2.11.0.jar

["Jean-Baptiste Onofré (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AMQ-7279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Baptiste Onofré updated AMQ-7279:
--------------------------------------
    Fix Version/s: 5.15.11
                   5.16.0

> Security Vulnerabilities in Libraries - jackson-databind-2.9.8.jar, tomcat-servlet-api-8.0.53.jar, tomcat-websocket-api-8.0.53.jar, zookeeper-3.4.6.jar, guava-18.0.jar, jetty-all-9.2.26.v20180806.jar, scala-library-2.11.0.jar
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-7279
>                 URL: https://issues.apache.org/jira/browse/AMQ-7279
>             Project: ActiveMQ
>          Issue Type: Bug
>    Affects Versions: 5.15.9
>            Reporter: Vipin
>            Assignee: Jean-Baptiste Onofré
>            Priority: Major
>              Labels: security, security-issue, vulnerabilities, vulnerability
>             Fix For: 5.16.0, 5.15.11
>
>
> ||Library||Sev||Description||NewVersion
> |jackson-databind-2.9.8.jar|SEV-2|FasterXML contains a flaw in jackson-databind jsontype/impl/SubTypeValidator.java related to EHCache that is triggered as user-supplied JavaScript content is insecurely deserialized. This may allow a remote attacker to potentially execute arbitrary code. - VulnDB-209928|2.9.9.2
> |tomcat-servlet-api-8.0.53.jar|SEV-3|Apache Tomcat 7.x through 7.0.70 and 8.x through 8.5.4, when the CGI Servlet is enabled, follows RFC 3875 section 4.1.18 and therefore does not protect applications from the presence of untrusted client data in the HTTP_PROXY environment variable, which might allow remote attackers to redirect an application's outbound HTTP traffic to an arbitrary proxy server via a crafted Proxy header in an HTTP request, aka an "httpoxy" issue. NOTE: the vendor states "A mitigation is planned for future releases of Tomcat, tracked as CVE-2016-5388"; in other words, this is not a CVE ID for a vulnerability. - CVE-2016-5388|9.0.22
> |tomcat-websocket-api-8.0.53.jar|SEV - 4|Apache Tomcat contains a flaw that is due to the program using insecure default settings for the CORS filter. This may potentially cause a system to be left in an insecure state if these settings have not been changed by an administrator. - VulnDB-180717|9.0.22
> |zookeeper-3.4.6.jar|SEV-4|Two four letter word commands "wchp/wchc" are CPU intensive and could cause spike of CPU utilization on Apache ZooKeeper server if abused, which leads to the server unable to serve legitimate client requests. Apache ZooKeeper thru version 3.4.9 and 3.5.2 suffer from this issue, fixed in 3.4.10, 3.5.3, and later. - CVE-2017-5637|3.5.5
> |zookeeper-3.4.6.jar|SEV-4|No authentication/authorization is enforced when a server attempts to join a quorum in Apache ZooKeeper before 3.4.10, and 3.5.0-alpha through 3.5.3-beta. As a result an arbitrary end point could join the cluster and begin propagating counterfeit changes to the leader. - CVE-2018-8012|3.5.5
> |zookeeper-3.4.6.jar|SEV-4|An issue is present in Apache ZooKeeper 1.0.0 to 3.4.13 and 3.5.0-alpha to 3.5.4-beta. ZooKeeper?s getACL() command doesn?t check any permission when retrieves the ACLs of the requested node and returns all information contained in the ACL Id field as plaintext string. DigestAuthenticationProvider overloads the Id field with the hash value that is used for user authentication. As a consequence, if Digest Authentication is in use, the unsalted hash value will be disclosed by getACL() request for unauthenticated or unprivileged users. - CVE-2019-0201|3.5.5
> |zookeeper-3.4.6.jar|SEV-4|Apache ZooKeeper contains an overflow condition in the cli_st and cli_mt C client shells that is triggered when handling 'cmd:' batch mode syntax input commands. This may allow a local attacker to cause a buffer overflow and potentially execute arbitrary code. - VulnDB-144410|3.5.5
> |zookeeper-3.4.6.jar|SEV-4|Buffer overflow in the C cli shell in Apache Zookeeper before 3.4.9 and 3.5.x before 3.5.3, when using the "cmd:" batch mode syntax, allows attackers to have unspecified impact via a long command string. - CVE-2016-5017|3.5.5
> |guava-18.0.jar|SEV-4|Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - CVE-2018-10237|23.0
> |jetty-all-9.2.26.v20180806.jar|SEV-4|In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), transfer-encoding chunks are handled poorly. The chunk length parsing was vulnerable to an integer overflow. Thus a large chunk size could be interpreted as a smaller chunk size and content sent as chunk body could be interpreted as a pipelined request. If Jetty was deployed behind an intermediary that imposed some authorization and that intermediary allowed arbitrarily large chunks to be passed on unchanged, then this flaw could be used to bypass the authorization imposed by the intermediary as the fake pipelined request would not be interpreted by the intermediary as a request. - CVE-2017-7657|??
> |jetty-all-9.2.26.v20180806.jar|SEV-4|In Eclipse Jetty Server, versions 9.2.x and older, 9.3.x (all non HTTP/1.x configurations), and 9.4.x (all HTTP/1.x configurations), when presented with two content-lengths headers, Jetty ignored the second. When presented with a content-length and a chunked encoding header, the content-length was ignored (as per RFC 2616). If an intermediary decided on the shorter length, but still passed on the longer body, then body content could be interpreted by Jetty as a pipelined request. If the intermediary was imposing authorization, the fake pipelined request would bypass that authorization. - CVE-2017-7658|??
> |jetty-all-9.2.26.v20180806.jar|SEV-4|In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), HTTP/0.9 is handled poorly. An HTTP/1 style request line (i.e. method space URI space version) that declares a version of HTTP/0.9 was accepted and treated as a 0.9 request. If deployed behind an intermediary that also accepted and passed through the 0.9 version (but did not act on it), then the response sent could be interpreted by the intermediary as HTTP/1 headers. This could be used to poison the cache if the server allowed the origin client to generate arbitrary content in the response. - CVE-2017-7656|??
> |jetty-all-9.2.26.v20180806.jar|SEV-4|Jetty through 9.4.x is prone to a timing channel in util/security/Password.java, which makes it easier for remote attackers to obtain access by observing elapsed times before rejection of incorrect passwords. - CVE-2017-9735|??
> |jetty-all-9.2.26.v20180806.jar|SEV-4|In Eclipse Jetty Server, all 9.x versions, on webapps deployed using default Error Handling, when an intentionally bad query arrives that doesn't match a dynamic url-pattern, and is eventually handled by the DefaultServlet's static file serving, the bad characters can trigger a java.nio.file.InvalidPathException which includes the full path to the base resource directory that the DefaultServlet and/or webapp is using. If this InvalidPathException is then handled by the default Error Handler, the InvalidPathException message is included in the error response, revealing the full server path to the requesting system. - CVE-2018-12536|??
> |jetty-all-9.2.26.v20180806.jar|SEV-4|In Eclipse Jetty version 9.2.26 and older, 9.3.25 and older, and 9.4.15 and older, the server is vulnerable to XSS conditions if a remote client USES a specially formatted URL against the DefaultServlet or ResourceHandler that is configured for showing a Listing of directory contents. - CVE-2019-10241|??
> |jetty-all-9.2.26.v20180806.jar|SEV-4|In Eclipse Jetty version 7.x, 8.x, 9.2.27 and older, 9.3.26 and older, and 9.4.16 and older, the server running on any OS and Jetty version combination will reveal the configured fully qualified directory base resource location on the output of the 404 error for not finding a Context that matches the requested path. The default server behavior on jetty-distribution and jetty-home will include at the end of the Handler tree a DefaultHandler, which is responsible for reporting this 404 error, it presents the various configured contexts as HTML for users to click through to. This produced HTML includes output that contains the configured fully qualified directory base resource location for each  - CVE-2019-10247|??
> |scala-library-2.11.0.jar|SEV-4|The compilation daemon in Scala before 2.10.7, 2.11.x before 2.11.12, and 2.12.x before 2.12.4 uses weak permissions for private files in /tmp/scala-devel/${USER:shared}/scalac-compile-server-port, which allows local users to write to arbitrary class files and consequently gain privileges. - CVE-2017-15288|2.12.8



--
This message was sent by Atlassian Jira
(v8.3.4#803005)