Filtered by vendor Linuxfoundation
Subscriptions
Total
277 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-9798 | 1 Linuxfoundation | 2 Api Mediation Layer, Zowe Api Mediation Layer | 2024-11-25 | 5.3 Medium |
| The health endpoint is public so everybody can see a list of all services. It is potentially valuable information for attackers. | ||||
| CVE-2024-9802 | 1 Linuxfoundation | 2 Api Mediation Layer, Zowe Api Mediation Layer | 2024-11-25 | 5.3 Medium |
| The conformance validation endpoint is public so everybody can verify the conformance of onboarded services. The response could contain specific information about the service, including available endpoints, and swagger. It could advise about the running version of a service to an attacker. The attacker could also check if a service is running. | ||||
| CVE-2024-5187 | 1 Linuxfoundation | 1 Onnx | 2024-11-21 | 8.8 High |
| A vulnerability in the `download_model_with_test_data` function of the onnx/onnx framework, version 1.16.0, allows for arbitrary file overwrite due to inadequate prevention of path traversal attacks in malicious tar files. This vulnerability enables attackers to overwrite any file on the system, potentially leading to remote code execution, deletion of system, personal, or application files, thus impacting the integrity and availability of the system. The issue arises from the function's handling of tar file extraction without performing security checks on the paths within the tar file, as demonstrated by the ability to overwrite the `/home/kali/.ssh/authorized_keys` file by specifying an absolute path in the malicious tar file. | ||||
| CVE-2024-23656 | 1 Linuxfoundation | 1 Dex | 2024-11-21 | 7.5 High |
| Dex is an identity service that uses OpenID Connect to drive authentication for other apps. Dex 2.37.0 serves HTTPS with insecure TLS 1.0 and TLS 1.1. `cmd/dex/serve.go` line 425 seemingly sets TLS 1.2 as minimum version, but the whole `tlsConfig` is ignored after `TLS cert reloader` was introduced in v2.37.0. Configured cipher suites are not respected either. This issue is fixed in Dex 2.38.0. | ||||
| CVE-2024-22424 | 3 Argoproj, Linuxfoundation, Redhat | 3 Argo Cd, Argo-cd, Openshift Gitops | 2024-11-21 | 8.4 High |
| Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. The Argo CD API prior to versions 2.10-rc2, 2.9.4, 2.8.8, and 2.7.15 are vulnerable to a cross-server request forgery (CSRF) attack when the attacker has the ability to write HTML to a page on the same parent domain as Argo CD. A CSRF attack works by tricking an authenticated Argo CD user into loading a web page which contains code to call Argo CD API endpoints on the victim’s behalf. For example, an attacker could send an Argo CD user a link to a page which looks harmless but in the background calls an Argo CD API endpoint to create an application running malicious code. Argo CD uses the “Lax” SameSite cookie policy to prevent CSRF attacks where the attacker controls an external domain. The malicious external website can attempt to call the Argo CD API, but the web browser will refuse to send the Argo CD auth token with the request. Many companies host Argo CD on an internal subdomain. If an attacker can place malicious code on, for example, https://test.internal.example.com/, they can still perform a CSRF attack. In this case, the “Lax” SameSite cookie does not prevent the browser from sending the auth cookie, because the destination is a parent domain of the Argo CD API. Browsers generally block such attacks by applying CORS policies to sensitive requests with sensitive content types. Specifically, browsers will send a “preflight request” for POSTs with content type “application/json” asking the destination API “are you allowed to accept requests from my domain?” If the destination API does not answer “yes,” the browser will block the request. Before the patched versions, Argo CD did not validate that requests contained the correct content type header. So an attacker could bypass the browser’s CORS check by setting the content type to something which is considered “not sensitive” such as “text/plain.” The browser wouldn’t send the preflight request, and Argo CD would happily accept the contents (which are actually still JSON) and perform the requested action (such as running malicious code). A patch for this vulnerability has been released in the following Argo CD versions: 2.10-rc2, 2.9.4, 2.8.8, and 2.7.15. The patch contains a breaking API change. The Argo CD API will no longer accept non-GET requests which do not specify application/json as their Content-Type. The accepted content types list is configurable, and it is possible (but discouraged) to disable the content type check completely. Users are advised to upgrade. There are no known workarounds for this vulnerability. | ||||
| CVE-2024-21626 | 3 Fedoraproject, Linuxfoundation, Redhat | 10 Fedora, Runc, Enterprise Linux and 7 more | 2024-11-21 | 8.6 High |
| runc is a CLI tool for spawning and running containers on Linux according to the OCI specification. In runc 1.1.11 and earlier, due to an internal file descriptor leak, an attacker could cause a newly-spawned container process (from runc exec) to have a working directory in the host filesystem namespace, allowing for a container escape by giving access to the host filesystem ("attack 2"). The same attack could be used by a malicious image to allow a container process to gain access to the host filesystem through runc run ("attack 1"). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes ("attack 3a" and "attack 3b"). runc 1.1.12 includes patches for this issue. | ||||
| CVE-2023-6944 | 2 Linuxfoundation, Redhat | 3 Backstage, Red Hat Developer Hub, Rhdh | 2024-11-21 | 5.7 Medium |
| A flaw was found in the Red Hat Developer Hub (RHDH). The catalog-import function leaks GitLab access tokens on the frontend when the base64 encoded GitLab token includes a newline at the end of the string. The sanitized error can display on the frontend, including the raw access token. Upon gaining access to this token and depending on permissions, an attacker could push malicious code to repositories, delete resources in Git, revoke or generate new keys, and sign code illegitimately. | ||||
| CVE-2023-47090 | 1 Linuxfoundation | 1 Nats-server | 2024-11-21 | 6.5 Medium |
| 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. | ||||
| CVE-2023-46742 | 1 Linuxfoundation | 1 Cubefs | 2024-11-21 | 4.8 Medium |
| 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. | ||||
| CVE-2023-46741 | 1 Linuxfoundation | 1 Cubefs | 2024-11-21 | 4.8 Medium |
| 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. | ||||
| CVE-2023-46740 | 1 Linuxfoundation | 1 Cubefs | 2024-11-21 | 6.5 Medium |
| 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. | ||||
| CVE-2023-46739 | 1 Linuxfoundation | 1 Cubefs | 2024-11-21 | 6.5 Medium |
| CubeFS is an open-source cloud-native file storage system. A vulnerability was found during in the CubeFS master component in versions prior to 3.3.1 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. The issue has been patched in v3.3.1. For impacted users, there is no other way to mitigate the issue besides upgrading. | ||||
| CVE-2023-46738 | 1 Linuxfoundation | 1 Cubefs | 2024-11-21 | 6.5 Medium |
| 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. | ||||
| CVE-2023-43637 | 2 Lfedge, Linuxfoundation | 2 Eve, Edge Virtualization Engine | 2024-11-21 | 7.8 High |
| Due to the implementation of "deriveVaultKey", prior to version 7.10, the generated vault key would always have the last 16 bytes predetermined to be "arfoobarfoobarfo". This issue happens because "deriveVaultKey" calls "retrieveCloudKey" (which will always return "foobarfoobarfoobarfoobarfoobarfo" as the key), and then merges the 32byte randomly generated key with this key (by takeing 16bytes from each, see "mergeKeys"). This makes the key a lot weaker. This issue does not persist in devices that were initialized on/after version 7.10, but devices that were initialized before that and updated to a newer version still have this issue. Roll an update that enforces the full 32bytes key usage. | ||||
| CVE-2023-43636 | 1 Linuxfoundation | 1 Edge Virtualization Engine | 2024-11-21 | 8.8 High |
| In EVE OS, the “measured boot” mechanism prevents a compromised device from accessing the encrypted data located in the vault. As per the “measured boot” design, the PCR values calculated at different stages of the boot process will change if any of their respective parts are changed. This includes, among other things, the configuration of the bios, grub, the kernel cmdline, initrd, and more. However, this mechanism does not validate the entire rootfs, so an attacker can edit the filesystem and gain control over the system. As the default filesystem used by EVE OS is squashfs, this is somewhat harder than an ext4, which is easily changeable. This will not stop an attacker, as an attacker can repackage the squashfs with their changes in it and replace the partition altogether. This can also be done directly on the device, as the “003-storage-init” container contains the “mksquashfs” and “unsquashfs” binaries (with the corresponding libs). 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. | ||||
| CVE-2023-43635 | 1 Linuxfoundation | 1 Edge Virtualization Engine | 2024-11-21 | 8.8 High |
| Vault Key Sealed With SHA1 PCRs The measured boot solution implemented in EVE OS leans on a PCR locking mechanism. Different parts of the system update different PCR values in the TPM, resulting in a unique value for each PCR entry. These PCRs are then used in order to seal/unseal a key from the TPM which is used to encrypt/decrypt the “vault” directory. This “vault” directory is the most sensitive point in the system and as such, its content should be protected. This mechanism is noted in Zededa’s documentation as the “measured boot” mechanism, designed to protect said “vault”. The code that’s responsible for generating and fetching the key from the TPM assumes that SHA256 PCRs are used in order to seal/unseal the key, and as such their presence is being checked. The issue here is that the key is not sealed using SHA256 PCRs, but using SHA1 PCRs. This leads to several issues: • Machines that have their SHA256 PCRs enabled but SHA1 PCRs disabled, as well as not sealing their keys at all, meaning the “vault” is not protected from an attacker. • SHA1 is considered insecure and reduces the complexity level required to unseal the key in machines which have their SHA1 PCRs enabled. An attacker can very easily retrieve the contents of the “vault”, which will effectively render the “measured boot” mechanism meaningless. | ||||
| CVE-2023-43632 | 2 Lfedge, Linuxfoundation | 2 Eve, Edge Virtualization Engine | 2024-11-21 | 9 Critical |
| 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. | ||||
| CVE-2023-43631 | 1 Linuxfoundation | 1 Edge Virtualization Engine | 2024-11-21 | 8.8 High |
| 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. | ||||
| CVE-2023-43630 | 1 Linuxfoundation | 1 Edge Virtualization Engine | 2024-11-21 | 8.8 High |
| PCR14 is not in the list of PCRs that seal/unseal the “vault” key, but due to the change that was implemented in commit “7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4”, fixing this issue alone would not solve the problem of the config partition not being measured correctly. Also, the “vault” key is sealed/unsealed with SHA1 PCRs instead of SHA256. This issue was somewhat mitigated due to all of the PCR extend functions updating both the values of SHA256 and SHA1 for a given PCR ID. However, due to the change that was implemented in commit “7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4”, this is no longer the case for PCR14, as the code in “measurefs.go” explicitly updates only the SHA256 instance of PCR14, which means that even if PCR14 were to be added to the list of PCRs sealing/unsealing the “vault” key, changes to the config partition would still not be measured. An attacker could modify the config partition without triggering the measured boot, this could result in the attacker gaining full control over the device with full access to the contents of the encrypted “vault” | ||||
| CVE-2023-39951 | 2 Linuxfoundation, Opentelemetry | 2 Opentelemetry Instrumentation For Java, Opentelemetry-java-instrumentation | 2024-11-21 | 6.5 Medium |
| OpenTelemetry Java Instrumentation provides OpenTelemetry auto-instrumentation and instrumentation libraries for Java. OpenTelemetry Java Instrumentation prior to version 1.28.0 contains an issue related to the instrumentation of Java applications using the AWS SDK v2 with Amazon Simple Email Service (SES) v1 API. When SES POST requests are instrumented, the query parameters of the request are inserted into the trace `url.path` field. This behavior leads to the http body, containing the email subject and message, to be present in the trace request url metadata. Any user using a version before 1.28.0 of OpenTelemetry Java Instrumentation to instrument AWS SDK v2 call to SES’s v1 SendEmail API is affected. The e-mail content sent to SES may end up in telemetry backend. This exposes the e-mail content to unintended audiences. The issue can be mitigated by updating OpenTelemetry Java Instrumentation to version 1.28.0 or later. | ||||