Filtered by vendor Linuxfoundation
Subscribe
Total
272 CVE
CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
---|---|---|---|---|---|
CVE-2020-1760 | 5 Canonical, Debian, Fedoraproject and 2 more | 6 Ubuntu Linux, Debian Linux, Fedora and 3 more | 2024-11-21 | 4.3 MEDIUM | 5.8 MEDIUM |
A flaw was found in the Ceph Object Gateway, where it supports request sent by an anonymous user in Amazon S3. This flaw could lead to potential XSS attacks due to the lack of proper neutralization of untrusted input. | |||||
CVE-2020-1759 | 3 Fedoraproject, Linuxfoundation, Redhat | 5 Fedora, Ceph, Ceph Storage and 2 more | 2024-11-21 | 5.8 MEDIUM | 6.4 MEDIUM |
A vulnerability was found in Red Hat Ceph Storage 4 and Red Hat Openshift Container Storage 4.2 where, A nonce reuse vulnerability was discovered in the secure mode of the messenger v2 protocol, which can allow an attacker to forge auth tags and potentially manipulate the data by leveraging the reuse of a nonce in a session. Messages encrypted using a reused nonce value are susceptible to serious confidentiality and integrity attacks. | |||||
CVE-2020-1699 | 2 Linuxfoundation, Redhat | 2 Ceph, Ceph Storage | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
A path traversal flaw was found in the Ceph dashboard implemented in upstream versions v14.2.5, v14.2.6, v15.0.0 of Ceph storage and has been fixed in versions 14.2.7 and 15.1.0. An unauthenticated attacker could use this flaw to cause information disclosure on the host machine running the Ceph dashboard. | |||||
CVE-2020-15687 | 1 Linuxfoundation | 1 Acrn | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
Missing access control restrictions in the Hypervisor component of the ACRN Project (v2.0 and v1.6.1) allow a malicious entity, with root access in the Service VM userspace, to abuse the PCIe assign/de-assign Hypercalls via crafted ioctls and payloads. This attack results in a corrupt state and Denial of Service (DoS) for previously assigned PCIe devices to the Service VM at runtime. | |||||
CVE-2020-15257 | 3 Debian, Fedoraproject, Linuxfoundation | 3 Debian Linux, Fedora, Containerd | 2024-11-21 | 3.6 LOW | 5.2 MEDIUM |
containerd is an industry-standard container runtime and is available as a daemon for Linux and Windows. In containerd before versions 1.3.9 and 1.4.3, the containerd-shim API is improperly exposed to host network containers. Access controls for the shim’s API socket verified that the connecting process had an effective UID of 0, but did not otherwise restrict access to the abstract Unix domain socket. This would allow malicious containers running in the same network namespace as the shim, with an effective UID of 0 but otherwise reduced privileges, to cause new processes to be run with elevated privileges. This vulnerability has been fixed in containerd 1.3.9 and 1.4.3. Users should update to these versions as soon as they are released. It should be noted that containers started with an old version of containerd-shim should be stopped and restarted, as running containers will continue to be vulnerable even after an upgrade. If you are not providing the ability for untrusted users to start containers in the same network namespace as the shim (typically the "host" network namespace, for example with docker run --net=host or hostNetwork: true in a Kubernetes pod) and run with an effective UID of 0, you are not vulnerable to this issue. If you are running containers with a vulnerable configuration, you can deny access to all abstract sockets with AppArmor by adding a line similar to deny unix addr=@**, to your policy. It is best practice to run containers with a reduced set of privileges, with a non-zero UID, and with isolated namespaces. The containerd maintainers strongly advise against sharing namespaces with the host. Reducing the set of isolation mechanisms used for a container necessarily increases that container's privilege, regardless of what container runtime is used for running that container. | |||||
CVE-2020-15163 | 1 Linuxfoundation | 1 The Update Framework | 2024-11-21 | 4.9 MEDIUM | 8.7 HIGH |
Python TUF (The Update Framework) reference implementation before version 0.12 it will incorrectly trust a previously downloaded root metadata file which failed verification at download time. This allows an attacker who is able to serve multiple new versions of root metadata (i.e. by a person-in-the-middle attack) culminating in a version which has not been correctly signed to control the trust chain for future updates. This is fixed in version 0.12 and newer. | |||||
CVE-2020-15157 | 3 Canonical, Debian, Linuxfoundation | 3 Ubuntu Linux, Debian Linux, Containerd | 2024-11-21 | 2.6 LOW | 6.1 MEDIUM |
In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a “foreign layer”), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources. Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. | |||||
CVE-2020-13794 | 1 Linuxfoundation | 1 Harbor | 2024-11-21 | 4.0 MEDIUM | 4.3 MEDIUM |
Harbor 1.9.* 1.10.* and 2.0.* allows Exposure of Sensitive Information to an Unauthorized Actor. | |||||
CVE-2020-13788 | 1 Linuxfoundation | 1 Harbor | 2024-11-21 | 4.0 MEDIUM | 4.3 MEDIUM |
Harbor prior to 2.0.1 allows SSRF with this limitation: an attacker with the ability to edit projects can scan ports of hosts accessible on the Harbor server's intranet. | |||||
CVE-2020-12831 | 1 Linuxfoundation | 1 Free Range Routing | 2024-11-21 | 4.3 MEDIUM | 5.3 MEDIUM |
An issue was discovered in FRRouting FRR (aka Free Range Routing) through 7.3.1. When using the split-config feature, the init script creates an empty config file with world-readable default permissions, leading to a possible information leak via tools/frr.in and tools/frrcommon.sh.in. NOTE: some parties consider this user error, not a vulnerability, because the permissions are under the control of the user before any sensitive information is present in the file | |||||
CVE-2020-12059 | 2 Canonical, Linuxfoundation | 2 Ubuntu Linux, Ceph | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
An issue was discovered in Ceph through 13.2.9. A POST request with an invalid tagging XML can crash the RGW process by triggering a NULL pointer exception. | |||||
CVE-2020-11093 | 1 Linuxfoundation | 1 Indy-node | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
Hyperledger Indy Node is the server portion of a distributed ledger purpose-built for decentralized identity. In Hyperledger Indy before version 1.12.4, there is lack of signature verification on a specific transaction which enables an attacker to make certain unauthorized alterations to the ledger. Updating a DID with a nym transaction will be written to the ledger if neither ROLE or VERKEY are being changed, regardless of sender. A malicious DID with no particular role can ask an update for another DID (but cannot modify its verkey or role). This is bad because 1) Any DID can write a nym transaction to the ledger (i.e., any DID can spam the ledger with nym transactions), 2) Any DID can change any other DID's alias, 3) The update transaction modifies the ledger metadata associated with a DID. | |||||
CVE-2020-11090 | 1 Linuxfoundation | 1 Indy-node | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
In Indy Node 1.12.2, there is an Uncontrolled Resource Consumption vulnerability. Indy Node has a bug in TAA handling code. The current primary can be crashed with a malformed transaction from a client, which leads to a view change. Repeated rapid view changes have the potential of bringing down the network. This is fixed in version 1.12.3. | |||||
CVE-2020-11081 | 1 Linuxfoundation | 1 Osquery | 2024-11-21 | 4.4 MEDIUM | 5.3 MEDIUM |
osquery before version 4.4.0 enables a privilege escalation vulnerability. If a Window system is configured with a PATH that contains a user-writable directory then a local user may write a zlib1.dll DLL, which osquery will attempt to load. Since osquery runs with elevated privileges this enables local escalation. This is fixed in version 4.4.0. | |||||
CVE-2020-10753 | 5 Canonical, Fedoraproject, Linuxfoundation and 2 more | 6 Ubuntu Linux, Fedora, Ceph and 3 more | 2024-11-21 | 4.3 MEDIUM | 5.4 MEDIUM |
A flaw was found in the Red Hat Ceph Storage RadosGW (Ceph Object Gateway). The vulnerability is related to the injection of HTTP headers via a CORS ExposeHeader tag. The newline character in the ExposeHeader tag in the CORS configuration file generates a header injection in the response when the CORS request is made. Ceph versions 3.x and 4.x are vulnerable to this issue. | |||||
CVE-2020-10750 | 1 Linuxfoundation | 1 Jaeger | 2024-11-21 | 2.1 LOW | 7.1 HIGH |
Sensitive information written to a log file vulnerability was found in jaegertracing/jaeger before version 1.18.1 when the Kafka data store is used. This flaw allows an attacker with access to the container's log file to discover the Kafka credentials. | |||||
CVE-2020-10749 | 3 Fedoraproject, Linuxfoundation, Redhat | 4 Fedora, Cni Network Plugins, Enterprise Linux and 1 more | 2024-11-21 | 6.0 MEDIUM | 6.0 MEDIUM |
A vulnerability was found in all versions of containernetworking/plugins before version 0.8.6, that allows malicious containers in Kubernetes clusters to perform man-in-the-middle (MitM) attacks. A malicious container can exploit this flaw by sending rogue IPv6 router advertisements to the host or other containers, to redirect traffic to the malicious container. | |||||
CVE-2020-10736 | 1 Linuxfoundation | 1 Ceph | 2024-11-21 | 5.2 MEDIUM | 8.0 HIGH |
An authorization bypass vulnerability was found in Ceph versions 15.2.0 before 15.2.2, where the ceph-mon and ceph-mgr daemons do not properly restrict access, resulting in gaining access to unauthorized resources. This flaw allows an authenticated client to modify the configuration and possibly conduct further attacks. | |||||
CVE-2019-5736 | 13 Apache, Canonical, D2iq and 10 more | 19 Mesos, Ubuntu Linux, Dc\/os and 16 more | 2024-11-21 | 9.3 HIGH | 8.6 HIGH |
runc through 1.0-rc6, as used in Docker before 18.09.2 and other products, allows attackers to overwrite the host runc binary (and consequently obtain host root access) by leveraging the ability to execute a command as root within one of these types of containers: (1) a new container with an attacker-controlled image, or (2) an existing container, to which the attacker previously had write access, that can be attached with docker exec. This occurs because of file-descriptor mishandling, related to /proc/self/exe. | |||||
CVE-2019-3990 | 1 Linuxfoundation | 1 Harbor | 2024-11-21 | 4.0 MEDIUM | 4.3 MEDIUM |
A User Enumeration flaw exists in Harbor. The issue is present in the "/users" API endpoint. This endpoint is supposed to be restricted to administrators. This restriction is able to be bypassed and information can be obtained about registered users can be obtained via the "search" functionality. |