This is the multi-page printable view of this section.
Click here to print.
Return to the regular view of this page.
Security Bulletins
NOTE: Kiali takes security seriously and encourages users to report security concerns.
If you run a security scan on Kiali software that automatically generates a list of potential vulnerabilities and would like to report this security scan report to the Kiali team, we ask that you first verify that your scan is correctly validating the latest release and that the list of results is valid, contains no duplicates, and the reported vulnerabilities truly affect Kiali. Security report investigation often takes priority over scheduled work and can be time consuming for the Kiali maintainers to research and validate. So, please verify that your submitted report accurately reflects the Kiali software being scanned, and that the reported security issue(s) actually affect Kiali or one of its dependencies.
Kiali releases every three weeks and so generally resolves CVEs in new releases only. Golang vulnerabilities are typically resolved in a timely way, as the Go version for release builds increments fairly often. Occasionally, critical CVEs may be resolved in patch releases for supported versions. Additionally, not every CVE reported against a Kiali dependency is actually a vulnerability. For reported CVEs that are proven not to affect Kiali, see the table below:
| CVE |
Description |
Notes |
| CVE-2024-2961 |
The iconv() function in the GNU C Library versions 2.39 and older may overflow the output buffer passed to it by up to 4 bytes when converting strings to the ISO-2022-CN-EXT character set |
Kiali is not affected. ISO-2022-CN-EXT has been removed. To confirm, run the validation command `podman run -it --rm --entrypoint '' quay.io/kiali/kiali:v2.2.0 iconv -l | grep -E 'CN-?EXT'`. See https://access.redhat.com/security/cve/CVE-2024-2961 |
| CVE-2023-37920 |
A flaw was found in the python-certifi package. This issue occurs when the e-Tugra root certificate in Certifi is removed, resulting in an unspecified error that has an unknown impact and attack vector. |
Kiali is not affected. This was fixed in RHEL9 base images with RHBA-2024:5691. Per the CVE page, these certs are included and marked as 'don't trust', but will not be removed until Mozilla removes them. Browsers are most at risk, which already understand and parse 'don't trust after'. Furthermore, note that Microsoft has not removed the certificate from their code-signing CA list that are merged with Mozilla's CA list, so the certificate is still there marked as trusted for code signing. See: https://access.redhat.com/security/cve/cve-2023-37920 and https://access.redhat.com/errata/RHBA-2024:5691 |
| CVE-2022-27191 |
golang.org/x/crypto/ssh allows an attacker to crash a server in certain circumstances involving AddHostKey |
Kiali does not use the AddHostKey API; furthermore, neither Kiali nor its dependencies import this component. Thus Kiali is not susceptible to this vulnerability. |
| CVE-2022-1996 |
github.com/emicklei/go-restful |
Despite the package dependency Kiali is not susceptible to this vulnerability |
| CVE-2019-1010022 |
GNU Libc current is affected by: Mitigation bypass. |
This is a disputed CVE. According to upstream, it is not a security issue. For details, please see https://sourceware.org/bugzilla/show_bug.cgi?id=22850 and https://security-tracker.debian.org/tracker/CVE-2019-1010022 |
For Kiali-specific vulnerabilities there will be releases made as needed. At release time a security bulletin will be release as well. For prior bulletins see below:
1 - KIALI-SECURITY-003 - Installation into ad-hoc namespaces
Description
A vulnerability was found in the Kiali Operator allowing installation of a specified image into any namespace.
Kiali users are exposed to this vulnerability if all the following conditions are met:
- Kiali operator is used for installation.
- Kiali CR was edited to install an image into an unapproved namespace.
This vulnerability is filed as
CVE-2021-3495
Mitigation
If you can update:
- Update to Kiali Operator v1.33.0 or later.
If you can not update:
- Ensure only trusted individuals can create or edit a Kiali CRs (resources of kind “kiali”).
2 - KIALI-SECURITY-002 - Authentication bypass when using the OpenID login strategy
Description
A vulnerability was found in Kiali allowing an attacker to bypass the
authentication mechanism. The vulnerability lets an attacker build forged
credentials and use them to gain unauthorized access to Kiali.
Kiali users are exposed to this vulnerability if all the following conditions are met:
- Kiali is setup with the
openid authentication strategy.
- As a result of configurations in both Kiali and your OpenID server, Kiali uses the
implicit flow of the OpenID specification to negotiate authentication.
- Kiali is setup with RBAC turned off.
This vulnerability is filed as
CVE-2021-20278
Mitigation
If you can update:
- Update to Kiali v1.31.0 or later.
- If you need an earlier version, only Kiali 1.26.3 and 1.29.2 are fixed.
If you are locked with an older version of Kiali, you have three options:
- Configure Kiali to use the authorization code flow of the OpenID specification; or
- Configure Kiali to use the implicit flow of the OpenID specification and enable RBAC; or
- Configure Kiali to use any of the other available authentication mechanisms.
3 - KIALI-SECURITY-001 - Authentication bypass using forged credentials
Description
A vulnerability was found in Kiali allowing an attacker to bypass the
authentication mechanism. Currently, Kiali has four authentication mechanisms:
login, token, openshift and ldap. All are vulnerable.
The vulnerability lets an attacker build forged credentials and use them to
gain unauthorized access to Kiali.
Additionally, it was found that Kiali credentials were not being validated
properly. Depending on the authentication mechanism configured in Kiali, this
could facilitate unauthorized access into Kiali with forged and/or invalid
credentials.
These vulnerabilities are filed as
CVE-2020-1762
and
CVE-2020-1764
Detection
Use the following bash script to check if you are vulnerable:
KIALI_VERSION=$(kubectl get pods -n istio-system -l app=kiali -o yaml | sed -n 's/^.*image: .*:v\(.*\)$/\1/p' | sort -u)
kubectl get deploy kiali -n istio-system -o yaml | grep -q LOGIN_TOKEN_SIGNING_KEY
TEST_KEY_ENV=$?
kubectl get cm kiali -n istio-system -o yaml | grep signing_key | grep -vq kiali
TEST_KEY_CFG=$?
VERSION_ENTRIES=(${KIALI_VERSION//./ })
echo "Your Kiali version found: ${KIALI_VERSION}"
[ ${VERSION_ENTRIES[0]} -lt "1" ] || ([ ${VERSION_ENTRIES[0]} -eq "1" ] && (\
[ ${VERSION_ENTRIES[1]} -lt "15" ] || ([ ${VERSION_ENTRIES[1]} -eq "15" ] && ( \
[ ${VERSION_ENTRIES[2]} -le "0" ])))) && echo "Your Kiali version is vulnerable"
[ $TEST_KEY_ENV -eq 1 ] && [ $TEST_KEY_CFG -eq 1 ] && echo "Your Kiali configuration looks vulnerable"
The script output will be similar to this:
Your Kiali version found: 1.14.0
Your Kiali version is vulnerable
Your Kiali configuration looks vulnerable
Mitigation
- Update to Kiali 1.15.1 or later.
Alternatively, if you cannot update to version 1.15.1, mitigation is possible by
setting a secure signing key
when deploying Kiali. If you installed via Kiali operator, you could use the following bash script:
SIGN_KEY=$(chars=abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890; for i in {1..20}; do echo -n "${chars:RANDOM%${#chars}:1}"; done; echo)
kubectl get kiali -n $(kubectl get kiali --all-namespaces --no-headers -o custom-columns=NS:.metadata.namespace) -o yaml | sed "s/spec:/spec:\n login_token:\n signing_key: $SIGN_KEY/" | kubectl apply -f -
If you installed via Istio helm charts or istioctl command, you could use the following bash script:
KIALI_INSTALL_NAMESPACE=istio-system
SIGN_KEY=$(chars=abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890; for i in {1..20}; do echo -n "${chars:RANDOM%${#chars}:1}"; done; echo)
kubectl get cm kiali -n $KIALI_INSTALL_NAMESPACE -o yaml | sed "s/server:/login_token:\\n signing_key: $SIGN_KEY\\n server:/" | kubectl apply -f -
kubectl delete pod -l app=kiali -n $KIALI_INSTALL_NAMESPACE