A vulnerability was found during in the CubeFS master component that could allow an untrusted attacker to steal user passwords by carrying out a timing attack. The root case of the vulnerability was that CubeFS used raw string comparison of passwords.

The vulnerable part of CubeFS was the UserService of the master component. The UserService gets instantiated when starting the server of the master component.

CubeFS has not seen any evidence of this being exploited in the wild. The vulnerability was found during a security audit conducted by Ada Logics in collaboration with OSTIF and the CNCF.

The issue has been patched in v3.3.1. For impacted users, there is no other way to mitigate the issue besides upgrading.

CubeFS is an open-source cloud-native file storage system. Prior to version 3.3.1, CubeFS used an insecure random string generator to generate user-specific, sensitive keys used to authenticate users in a CubeFS deployment. This could allow an attacker to predict and/or guess the generated string and impersonate a user thereby obtaining higher privileges. When CubeFS creates new users, it creates a piece of sensitive information for the user called the “accessKey”. To create the "accesKey", CubeFS uses an insecure string generator which makes it easy to guess and thereby impersonate the created user. An attacker could leverage the predictable random string generator and guess a users access key and impersonate the user to obtain higher privileges. The issue has been fixed in v3.3.1. There is no other mitigation than to upgrade.

A vulnerability was found in CubeFS that could allow users to read sensitive data from the logs which could allow them escalate privileges.

CubeFS leaks configuration keys in plaintext format in the logs. These keys could allow anyone to carry out operations on blobs that they otherwise do not have permissions for. For example, an attacker that has succesfully retrieved a secret key from the logs can delete blogs from the blob store.

The attacker can either be an internal user with limited privileges to read the log, or it can be an external user who has escalated privileges sufficiently to access the logs. There is no evidence of this vulnerability being exploited in the wild. It was found during an ongoing security audit carried out by Ada Logics in collaboration with OSTIF and the CNCF.

The vulnerability has been patched in v3.3.1. There is no other mitigated than upgrading.

CubeFS is an open-source cloud-native file storage system. CubeFS prior to version 3.3.1 was found to leak users secret keys and access keys in the logs in multiple components. When CubeCS creates new users, it leaks the users secret key. This could allow a lower-privileged user with access to the logs to retrieve sensitive information and impersonate other users with higher privileges than themselves. The issue has been patched in v3.3.1. There is no other mitigation than upgrading CubeFS.

CubeFS through 3.2.1 allows Kubernetes cluster-level privilege escalation. This occurs because DaemonSet has cfs-csi-cluster-role and can thus list all secrets, including the admin secret.

A security vulnerability was found in CubeFS HandlerNode that could allow authenticated users to send maliciously-crafted requests that would crash the ObjectNode and deny other users from using it. The root cause was improper handling of incoming HTTP requests that could allow an attacker to control the ammount of memory that the ObjectNode would allocate. A malicious request could make the ObjectNode allocate more memory that the machine had available, and the attacker could exhaust memory by way of a single malicious request.

An attacker would need to be authenticated in order to invoke the vulnerable code with their malicious request and have permissions to delete objects. In addition, the attacker would need to know the names of existing buckets of the CubeFS deployment - otherwise the request would be rejected before it reached the vulnerable code. As such, the most likely attacker is an inside user or an attacker that has breached the account of an existing user in the cluster. There is no evidence of this attack being exploited in the wild. The vulnerability was found during a security audit carried out by Ada Logics in collaboration with OSTIF and the CNCF.

The issue has been patched in v3.3.1. There is no other mitigation besides upgrading.