[ 
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)

Reply via email to