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.
CubeFS is an open-source cloud-native file storage system. A vulnerability was found in CubeFS prior to version 3.3.1 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 they can be an external user who has escalated privileges sufficiently to access the logs. The vulnerability has been patched in v3.3.1. There is no other mitigation than upgrading.
CubeFS is an open-source cloud-native file storage system. A security vulnerability was found in CubeFS HandlerNode in versions prior to 3.3.1 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. The issue has been patched in v3.3.1. There is no other mitigation besides upgrading.
In aee, there is a possible escalation of privilege due to a missing permission check. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07909204; Issue ID: ALPS07909204.
A timing condition in Harbor 2.6.x and below, Harbor 2.7.2 and below, Harbor 2.8.2 and below, and Harbor 1.10.17 and below allows an attacker with network access to
create jobs/stop job tasks and retrieve job task information.
NATS nats-server before 2.9.23 and 2.10.x before 2.10.2 has an authentication bypass. An implicit $G user in an authorization block can sometimes be used for unauthenticated access, even when the intention of the configuration was for each user to have an account. The earliest affected version is 2.2.0.
In apusys, there is a possible out of bounds write due to an integer overflow. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07713478; Issue ID: ALPS07713478.
In wlan firmware, there is a possible firmware assertion due to improper input handling. This could lead to remote denial of service with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07932637; Issue ID: ALPS07932637.
As noted in the “VTPM.md” file in the eve documentation, “VTPM is a server listening on port
8877 in EVE, exposing limited functionality of the TPM to the clients.
VTPM allows clients to
execute tpm2-tools binaries from a list of hardcoded options”
The communication with this server is done using protobuf, and the data is comprised of 2
parts:
1. Header
2. Data
When a connection is made, the server is waiting for 4 bytes of data, which will be the header,
and these 4 bytes would be parsed as uint32 size of the actual data to come.
Then, in the function “handleRequest” this size is then used in order to allocate a payload on
the stack for the incoming data.
As this payload is allocated on the stack, this will allow overflowing the stack size allocated for
the relevant process with freely controlled data.
* An attacker can crash the system.
* An attacker can gain control over the system, specifically on the “vtpm_server” process
which has very high privileges.
On boot, the Pillar eve container checks for the existence and content of
“/config/authorized_keys”.
If the file is present, and contains a supported public key, the container will go on to open
port 22 and enable sshd with the given keys as the authorized keys for root login.
An attacker could easily add their own keys and gain full control over the system without
triggering the “measured boot” mechanism implemented by EVE OS, and without marking
the device as “UUD” (“Unknown Update Detected”).
This is because the “/config” partition is not protected by “measured boot”, it is mutable, and
it is not encrypted in any way.
An attacker can gain full control over the device without changing the PCR values, thus not
triggering the “measured boot” mechanism, and having full access to the vault.
Note:
This issue was partially fixed in these commits (after disclosure to Zededa), where the config
partition measurement was added to PCR13:
• aa3501d6c57206ced222c33aea15a9169d629141
• 5fef4d92e75838cc78010edaed5247dfbdae1889.
This issue was made viable in version 9.0.0 when the calculation was moved to PCR14 but it was not included in the measured boot.