<html>
<head>
<base href="https://bugzilla.rosalinux.ru/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Platform</th>
<td>2021.1
</td>
</tr>
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_CONFIRMED "
title="CONFIRMED - [CVE 21] cxf 3.1.6 CVEs found"
href="https://bugzilla.rosalinux.ru/show_bug.cgi?id=13510">13510</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[CVE 21] cxf 3.1.6 CVEs found
</td>
</tr>
<tr>
<th>Classification</th>
<td>ROSA-based products
</td>
</tr>
<tr>
<th>Product</th>
<td>ROSA Fresh
</td>
</tr>
<tr>
<th>Version</th>
<td>All
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>URL</th>
<td>CVE-2017-12624, CVE-2017-5653, CVE-2017-5656, CVE-2018-8039, CVE-2019-12406, CVE-2019-12423, CVE-2020-13954, CVE-2020-1954, CVE-2021-22696, CVE-2021-30468, CVE-2022-46363, CVE-2022-46364,
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>CONFIRMED
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>Normal
</td>
</tr>
<tr>
<th>Component</th>
<td>System (kernel, glibc, systemd, bash, PAM...)
</td>
</tr>
<tr>
<th>Assignee</th>
<td>bugs@lists.rosalinux.ru
</td>
</tr>
<tr>
<th>Reporter</th>
<td>y.tumanov@rosalinux.ru
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>bugs@lists.rosalinux.ru
</td>
</tr>
<tr>
<th>CC</th>
<td>e.kosachev@rosalinux.ru, s.matveev@rosalinux.ru, y.tumanov@rosalinux.ru
</td>
</tr>
<tr>
<th>Target Milestone</th>
<td>---
</td>
</tr>
<tr>
<th>Flags</th>
<td>secteam_verified?
</td>
</tr></table>
<p>
<div>
<pre>Please patch CVEs for package cxf version 3.1.6
INFO (CVEs are): cxf 3.1.6
cves found
CVE-2017-12624
Desc: Apache CXF supports sending and receiving attachments via either the
JAX-WS or JAX-RS specifications. It is possible to craft a message attachment
header that could lead to a Denial of Service (DoS) attack on a CXF web service
provider. Both JAX-WS and JAX-RS services are vulnerable to this attack. From
Apache CXF 3.2.1 and 3.1.14, message attachment headers that are greater than
300 characters will be rejected by default. This value is configurable via the
property "attachment-max-header-size".
Link: <a href="https://nvd.nist.gov/vuln/detail/CVE-2017-12624">https://nvd.nist.gov/vuln/detail/CVE-2017-12624</a>
Severity: MEDIUM
CVE-2017-5653
Desc: JAX-RS XML Security streaming clients in Apache CXF before 3.1.11 and
3.0.13 do not validate that the service response was signed or encrypted, which
allows remote attackers to spoof servers.
Link: <a href="https://nvd.nist.gov/vuln/detail/CVE-2017-5653">https://nvd.nist.gov/vuln/detail/CVE-2017-5653</a>
Severity: MEDIUM
CVE-2017-5656
Desc: Apache CXF's STSClient before 3.1.11 and 3.0.13 uses a flawed way of
caching tokens that are associated with delegation tokens, which means that an
attacker could craft a token which would return an identifer corresponding to a
cached token for another user.
Link: <a href="https://nvd.nist.gov/vuln/detail/CVE-2017-5656">https://nvd.nist.gov/vuln/detail/CVE-2017-5656</a>
Severity: HIGH
CVE-2018-8039
Desc: It is possible to configure Apache CXF to use the com.sun.net.ssl
implementation via 'System.setProperty("java.protocol.handler.pkgs",
"com.sun.net.ssl.internal.www.protocol");'. When this system property is set,
CXF uses some reflection to try to make the HostnameVerifier work with the old
com.sun.net.ssl.HostnameVerifier interface. However, the default
HostnameVerifier implementation in CXF does not implement the method in this
interface, and an exception is thrown. However, in Apache CXF prior to 3.2.5
and 3.1.16 the exception is caught in the reflection code and not properly
propagated. What this means is that if you are using the com.sun.net.ssl stack
with CXF, an error with TLS hostname verification will not be thrown, leaving a
CXF client subject to man-in-the-middle attacks.
Link: <a href="https://nvd.nist.gov/vuln/detail/CVE-2018-8039">https://nvd.nist.gov/vuln/detail/CVE-2018-8039</a>
Severity: HIGH
CVE-2019-12406
Desc: Apache CXF before 3.3.4 and 3.2.11 does not restrict the number of
message attachments present in a given message. This leaves open the
possibility of a denial of service type attack, where a malicious user crafts a
message containing a very large number of message attachments. From the 3.3.4
and 3.2.11 releases, a default limit of 50 message attachments is enforced.
This is configurable via the message property "attachment-max-count".
Link: <a href="https://nvd.nist.gov/vuln/detail/CVE-2019-12406">https://nvd.nist.gov/vuln/detail/CVE-2019-12406</a>
Severity: MEDIUM
CVE-2019-12423
Desc: Apache CXF ships with a OpenId Connect JWK Keys service, which allows a
client to obtain the public keys in JWK format, which can then be used to
verify the signature of tokens issued by the service. Typically, the service
obtains the public key from a local keystore (JKS/PKCS12) by specifing the path
of the keystore and the alias of the keystore entry. This case is not
vulnerable. However it is also possible to obtain the keys from a JWK keystore
file, by setting the configuration parameter "rs.security.keystore.type" to
"jwk". For this case all keys are returned in this file "as is", including all
private key and secret key credentials. This is an obvious security risk if the
user has configured the signature keystore file with private or secret key
credentials. From CXF 3.3.5 and 3.2.12, it is mandatory to specify an alias
corresponding to the id of the key in the JWK file, and only this key is
returned. In addition, any private key information is omitted by default. "oct"
keys, which contain secret keys, are not returned at all.
Link: <a href="https://nvd.nist.gov/vuln/detail/CVE-2019-12423">https://nvd.nist.gov/vuln/detail/CVE-2019-12423</a>
Severity: HIGH
CVE-2020-13954
Desc: By default, Apache CXF creates a /services page containing a listing of
the available endpoint names and addresses. This webpage is vulnerable to a
reflected Cross-Site Scripting (XSS) attack via the styleSheetPath, which
allows a malicious actor to inject javascript into the web page. This
vulnerability affects all versions of Apache CXF prior to 3.4.1 and 3.3.8.
Please note that this is a separate issue to CVE-2019-17573.
Link: <a href="https://nvd.nist.gov/vuln/detail/CVE-2020-13954">https://nvd.nist.gov/vuln/detail/CVE-2020-13954</a>
Severity: MEDIUM
CVE-2020-1954
Desc: Apache CXF has the ability to integrate with JMX by registering an
InstrumentationManager extension with the CXF bus. If the
‘createMBServerConnectorFactory‘ property of the default
InstrumentationManagerImpl is not disabled, then it is vulnerable to a
man-in-the-middle (MITM) style attack. An attacker on the same host can connect
to the registry and rebind the entry to another server, thus acting as a proxy
to the original. They are then able to gain access to all of the information
that is sent and received over JMX.
Link: <a href="https://nvd.nist.gov/vuln/detail/CVE-2020-1954">https://nvd.nist.gov/vuln/detail/CVE-2020-1954</a>
Severity: MEDIUM
CVE-2021-22696
Desc: CXF supports (via JwtRequestCodeFilter) passing OAuth 2 parameters via a
JWT token as opposed to query parameters (see: The OAuth 2.0 Authorization
Framework: JWT Secured Authorization Request (JAR)). Instead of sending a JWT
token as a "request" parameter, the spec also supports specifying a URI from
which to retrieve a JWT token from via the "request_uri" parameter. CXF was not
validating the "request_uri" parameter (apart from ensuring it uses "https) and
was making a REST request to the parameter in the request to retrieve a token.
This means that CXF was vulnerable to DDos attacks on the authorization server,
as specified in section 10.4.1 of the spec. This issue affects Apache CXF
versions prior to 3.4.3; Apache CXF versions prior to 3.3.10.
Link: <a href="https://nvd.nist.gov/vuln/detail/CVE-2021-22696">https://nvd.nist.gov/vuln/detail/CVE-2021-22696</a>
Severity: HIGH
CVE-2021-30468
Desc: A vulnerability in the JsonMapObjectReaderWriter of Apache CXF allows an
attacker to submit malformed JSON to a web service, which results in the thread
getting stuck in an infinite loop, consuming CPU indefinitely. This issue
affects Apache CXF versions prior to 3.4.4; Apache CXF versions prior to
3.3.11.
Link: <a href="https://nvd.nist.gov/vuln/detail/CVE-2021-30468">https://nvd.nist.gov/vuln/detail/CVE-2021-30468</a>
Severity: HIGH
CVE-2022-46363
Desc: A vulnerability in Apache CXF before versions 3.5.5 and 3.4.10 allows an
attacker to perform a remote directory listing or code exfiltration. The
vulnerability only applies when the CXFServlet is configured with both the
static-resources-list and redirect-query-check attributes. These attributes are
not supposed to be used together, and so the vulnerability can only arise if
the CXF service is misconfigured.
Link: <a href="https://nvd.nist.gov/vuln/detail/CVE-2022-46363">https://nvd.nist.gov/vuln/detail/CVE-2022-46363</a>
Severity: HIGH
CVE-2022-46364
Desc: A SSRF vulnerability in parsing the href attribute of XOP:Include in MTOM
requests in versions of Apache CXF before 3.5.5 and 3.4.10 allows an attacker
to perform SSRF style attacks on webservices that take at least one parameter
of any type.
Link: <a href="https://nvd.nist.gov/vuln/detail/CVE-2022-46364">https://nvd.nist.gov/vuln/detail/CVE-2022-46364</a>
Severity: CRITICAL</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>