#docker

### Impact Two malicious build steps running in parallel sharing the same cache mounts with subpaths could cause a race condition that can lead to files from the host system being accessible to the build container. ### Patches The issue has been fixed in v0.12.5 ### Workarounds Avoid using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing cache mounts with `--mount=type=cache,source=...` options. ### References https://www.openwall.com/lists/oss-security/2019/05/28/1

### Impact A malicious BuildKit frontend or Dockerfile using `RUN --mount` could trick the feature that removes empty files created for the mountpoints into removing a file outside the container, from the host system. ### Patches The issue has been fixed in v0.12.5 ### Workarounds Avoid using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing `RUN --mount` feature. ### References

### Impact In addition to running containers as build steps, BuildKit also provides APIs for running interactive containers based on built images. It was possible to use these APIs to ask BuildKit to run a container with elevated privileges. Normally, running such containers is only allowed if special `security.insecure` entitlement is enabled both by buildkitd configuration and allowed by the user initializing the build request. ### Patches The issue has been fixed in v0.12.5 . ### Workarounds Avoid using BuildKit frontends from untrusted sources. A frontend image is usually specified as the `#syntax` line on your Dockerfile, or with `--frontend` flag when using `buildctl build` command. ### References

Multiple security vulnerabilities have been disclosed in the runC command line tool that could be exploited by threat actors to escape the bounds of the container and stage follow-on attacks. The vulnerabilities, tracked as CVE-2024-21626, CVE-2024-23651, CVE-2024-23652, and CVE-2024-23653, have been collectively dubbed Leaky Vessels by cybersecurity vendor Snyk. "These container

### Description: When the application is password-protected (deployed with the `ACCESS_CODE` option), it is possible to access plugins without proper authorization (without password). ### Proof-of-Concept: Let’s suppose that application has been deployed with following command: ```sudo docker run -d -p 3210:3210 -e OPENAI_API_KEY=sk-[REDACTED] -e ACCESS_CODE=TEST123 --name lobe-chat lobehub/lobe-chat``` Due to the utilization of the `ACCESS_CODE`, access to the chat is possible only after entering the password:  However, it is possible to interact with chat plugins without entering the `ACCESS_CODE`. Example HTTP request: ``` POST /api/plugin/gateway HTTP/1.1 Host: localhost:3210 Content-Length: 1276 {"apiName":"checkWeatherUsingGET","arguments":"{\n \"location\": \"London\"\n}","identifier":"WeatherGPT","type":"default","manifest":{"api":[{"description":"Get current weather information","name"...

### Impact Nodes and servers get a ssh config by default that permits root login with password authentication. In a proper deployment, the SSH service is not exposed so there is no risk, but not all deployments are ideal. The default should therefore be less permissive. We will probably opt to completely remove the ssh option as it is only used for debugging. Later, we can add a debug mode where we can activate it if necessary. ### Workarounds Remove the ssh part from the docker file and build your own docker image

### Summary The password reset functionality sends to the the user requesting a password change an email containing an URL to reset its password. The URL sent contains a unique token, valid during 24 hours, allowing the user to reset its password. This token is highly sensitive ; as an attacker able to retrieve it would be able to resets the user's password. It was identified during the audit that the reset-password URL is crafted using the "Host" HTTP header of the request sent to request a password reset. This way, an external attacker could send password requests for users, but specify a "Host" header of a website that they control. If the user receiving the mail clicks on the link, the attacker would retrieve the reset token of the victim and perform account takeover. ### Details This attack required the server to serve Pimcore on arbitrary "Host". This configuration would be plausible if the attacker is already behind the reverse proxy. During the assessment of my client, th...

Jenkins has a built-in command line interface (CLI) to access Jenkins from a script or shell environment. Since Jenkins 2.217 and LTS 2.222.1, one of the ways to communicate with the CLI is through a WebSocket endpoint. This endpoint relies on the default Jenkins web request authentication functionality, like HTTP Basic authentication with API tokens, or session cookies. This endpoint is enabled when running on a version of Jetty for which Jenkins supports WebSockets. This is the case when using the provided native installers, packages, or the Docker containers, as well as when running Jenkins with the command java -jar jenkins.war. Jenkins 2.217 through 2.441 (both inclusive), LTS 2.222.1 through 2.426.2 (both inclusive) does not perform origin validation of requests made through the CLI WebSocket endpoint, resulting in a cross-site WebSocket hijacking (CSWSH) vulnerability.

This Metasploit module exploit takes advantage of the StringSubstitutor interpolator class, which is included in the Commons Text library. A default interpolator allows for string lookups that can lead to remote code execution. This is due to a logic flaw that makes the script, dns and url lookup keys interpolated by default, as opposed to what it should be, according to the documentation of the StringLookupFactory class. Those keys allow an attacker to execute arbitrary code via lookups primarily using the script key. In order to exploit the vulnerabilities, the following requirements must be met: Run a version of Apache Commons Text from version 1.5 to 1.9, use the StringSubstitutor interpolator, and the target should run JDK versions prior to 15.

By Deeba Ahmed Quarkslab Discovers "PixieFail" Vulnerabilities: Critical Flaws in Open Source UEFI Code Require Immediate Patching. This is a post from HackRead.com Read the original post: Critical “PixieFail” Flaws Expose Millions of Devices to Cyberattacks