Vulnerabilities

According to an April 15 advisory from Rancher, a vulnerability in go-getter may “expose the configured SSH private key secret if Fleet fails to download the git repo.” The advisory rates the severity as Low, despite the potential of a complete takeover of any cluster managed by the affected repository if an exposure leaks the key to a malicious user. More interesting, though, is Rancher’s finger pointing at go-getter to the tune of going to MITRE as a CNA of Last Resort to assign a CVE. In my opinion, the vulnerability is not in go-getter but in how Rancher Fleet handles errors returned by go-getter. I am the researcher that disclosed the original vulnerability to Rancher, and this is the story of that disclosure.

Longhorn has a vulnerability (CVE-2021-36780 ) in all versions of the 1.2.x branch prior to v 1.2.3 and in all versions prior to v.1.1.3 that allows unauthenticated attackers to access data in a Longhorn replica. An attacker with access to a cluster’s internal network can:

• read data in any Longhorn volume
• write data to any Longhorn volume

This vulnerability was discovered while investigating the vulnerability disclosed in CVE-2021-36779.

Longhorn , Rancher’s distributed block storage for Kubernetes, has a remote-code execution vulnerability (CVE-2021-36779 ) in versions in the v1.2.x branch prior to v1.2.3 and in all versions prior to v1.1.3. An unauthenticated attacker with access to the Longhorn network services can:

• execute, as root, any binary on the host machine or in the Longhorn container
• copy arbitrary data, including executable scripts or binaries, to the host machine or Longhorn container
• enumerate and read all files on the host machine, such as private keys and stored credentials

Because Longhorn is deployed as a DaemonSet, it is present on every node in the cluster, enabling an attacker to gain root access to every node.

A hard-coded signing key in Kiali prior to version 1.15.1 allowed attackers to craft valid authentication tokens if Kiali was configured for password-based authentication. The hard-coded key could be overridden in by configuration, but Kiali’s documentation and website did not mention the option. Red Hat has issued CVE-2020-1764 and the Kiali developers have published a security advisory .

CVE-2020-1762 was discovered during the investigation of CVE-2020-1764, and I’ll do a longer write up for that vulnerability. In short, though, Kiali did not check token expirations prior to v1.15.1. When using password-based authentication, users’ sessions would be based on a JWT token that would effectively never expire. Kiali offers several authentication mechanisms, and I did not take the time to fully investigate the impact of this vulnerability on other authentication mechanisms.