#docker

Apache James prior to version 3.7.5 and 3.8.0 exposes a JMX endpoint on localhost subject to pre-authentication deserialisation of untrusted data. Given a deserialisation gadjet, this could be leveraged as part of an exploit chain that could result in privilege escalation. Note that by default JMX endpoint is only bound locally. We recommend users to:  - Upgrade to a non-vulnerable Apache James version  - Run Apache James isolated from other processes (docker - dedicated virtual machine)  - If possible turn off JMX

### Impact A vulnerability has been identified which may lead to sensitive data being leaked into Rancher's audit logs. [Rancher Audit Logging](https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-api-audit-log) is an opt-in feature, only deployments that have it enabled and have [AUDIT_LEVEL](https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-api-audit-log#audit-log-levels) set to `1 or above` are impacted by this issue. The leaks might be caught in the audit logs upon these actions: - Creating cloud credentials or new authentication providers. It is crucial to note that **all** [authentication providers](https://ranchermanager.docs.rancher.com/pages-for-subheaders/authentication-config#external-vs-local-authentication) (such as AzureAD) and [cloud providers](https://ranchermanager.docs.rancher.com/pages-for-subheaders/set-up-cloud-providers) (such as Google) are impacted. - Downloading a kubeconfig file from a downstream...

runc versions 1.1.11 and below, as used by containerization technologies such as Docker engine and Kubernetes, are vulnerable to an arbitrary file write vulnerability. Due to a file descriptor leak it is possible to mount the host file system with the permissions of runc (typically root). Successfully tested on Ubuntu 22.04 with runc 1.1.7-0ubuntu1~22.04.1 using Docker build.

When it comes to open-source innovation, Red Hat is committed to pushing technological boundaries and enhancing the capabilities of cutting-edge solutions. As we look back at 2023, we’ll discuss Red Hat's role in advancing Extended Berkeley Packet Filter (eBPF) technology, from collaborative contributions to the Linux kernel to strategic implementations within Red Hat's portfolio, and explore the intersection of innovation, performance, security capabilities and networking within the evolving landscape of eBPF.Kernel upstream collaborationsRed Hat engineers actively collaborated with the Lin

### Impact Snyk has discovered a vulnerability in all versions of runc <=1.1.11, as used by the Docker engine, along with other containerization technologies such as Kubernetes. Exploitation of this issue can result in container escape to the underlying host OS, either through executing a malicious image or building an image using a malicious Dockerfile or upstream image (i.e., when using FROM). This issue has been assigned the CVE-2024-21626. ### Patches `runc` runtime was updated to 1.1.12 in Talos v1.5.6 and v1.6.4. ### Workarounds Inspect the workloads running on the cluster to make sure they are not trying to exploit the vulnerability. ### References * [CVE-2024-21626](https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv) * [Vulnerability: runc process.cwd and leaked fds container breakout](https://snyk.io/blog/cve-2024-21626-runc-process-cwd-container-breakout/)

The classic builder cache system is prone to cache poisoning if the image is built `FROM scratch`. Also, changes to some instructions (most important being `HEALTHCHECK` and `ONBUILD`) would not cause a cache miss. An attacker with the knowledge of the Dockerfile someone is using could poison their cache by making them pull a specially crafted image that would be considered as a valid cache candidate for some build steps. For example, an attacker could create an image that is considered as a valid cache candidate for: ``` FROM scratch MAINTAINER Pawel ``` when in fact the malicious image used as a cache would be an image built from a different Dockerfile. In the second case, the attacker could for example substitute a different `HEALTCHECK` command. ### Impact 23.0+ users are only affected if they explicitly opted out of Buildkit (`DOCKER_BUILDKIT=0` environment variable) or are using the `/build` API endpoint (which uses the classic builder by default). All users on versions ...

### Summary When someone creates an access key, it inherits the permissions of the parent key. Not only for `s3:*` actions, but also `admin:*` actions. Which means unless somewhere above in the access-key hierarchy, the `admin` rights are denied, access keys will be able to simply override their own `s3` permissions to something more permissive. Credit to @xSke for sort of accidentally discovering this. I only understood the implications. ### Details / PoC We spun up the latest version of minio in a docker container and signed in to the admin UI using the minio root user. We created two buckets, `public` and `private` and created an access key called `mycat` and attached the following policy to only allow access to the bucket called `public`. ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:*" ], "Resource": [ "arn:aws:s3:::public", "arn:aws:s3:::public/*" ] } ] } ``` We then set an alias in mc: `mcli ali...

Exposed Docker API endpoints over the internet are under assault from a sophisticated cryptojacking campaign called Commando Cat. "The campaign deploys a benign container generated using the Commando project," Cado security researchers Nate Bill and Matt Muir said in a new report published today. "The attacker escapes this container and runs multiple payloads on the

## Impact A bug was found in Moby (Docker Engine) where the data directory (typically `/var/lib/docker`) contained subdirectories with insufficiently restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and execute programs. When containers included executable programs with extended permission bits (such as `setuid`), unprivileged Linux users could discover and execute those programs. When the UID of an unprivileged Linux user on the host collided with the file owner or group inside a container, the unprivileged Linux user on the host could discover, read, and modify those files. ## Patches This bug has been fixed in Moby (Docker Engine) 20.10.9. Users should update to this version as soon as possible. Running containers should be stopped and restarted for the permissions to be fixed. ## Workarounds Limit access to the host to trusted users. Limit access to host volumes to trusted containers. ## Credits The Moby project would li...

An issue was discovered in Docker Moby before 17.06.0. The Docker engine validated a client TLS certificate using both the configured client CA root certificate and all system roots on non-Windows systems. This allowed a client with any domain validated certificate signed by a system-trusted root CA (as opposed to one signed by the configured CA root certificate) to authenticate.