#kubernetes

## Impact Containers launched through containerd's CRI implementation (through Kubernetes, crictl, or any other pod/container client that uses the containerd CRI service) that share the same image may receive incorrect environment variables, including values that are defined for other containers. If the affected containers have different security contexts, this may allow sensitive information to be unintentionally shared. If you are not using containerd’s CRI implementation (through one of the mechanisms described above), you are not vulnerable to this issue. If you are not launching multiple containers or Kubernetes pods from the same image which have different environment variables, you are not vulnerable to this issue. If you are not launching multiple containers or Kubernetes pods from the same image in rapid succession, you have reduced likelihood of being vulnerable to this issue ## Patches This vulnerability has been fixed in containerd 1.3.10 and containerd 1.4.4. Users...

### Impact In runc 1.1.11 and earlier, due to an internal file descriptor leak, an attacker could cause a newly-spawned container process (from `runc exec`) to have a working directory in the host filesystem namespace, allowing for a container escape by giving access to the host filesystem ("attack 2"). The same attack could be used by a malicious image to allow a container process to gain access to the host filesystem through `runc run` ("attack 1"). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes ("attack 3a" and "attack 3b"). Strictly speaking, while attack 3a is the most severe from a CVSS perspective, attacks 2 and 3b are arguably more dangerous in practice because they allow for a breakout from inside a container as opposed to requiring a user execute a malicious image. The reason attacks 1 and 3a are scored higher is because being able to socially engineer users is treated as a given for UI:R ...

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

This is the fourth part of Vincent Danen’s “Patch management needs a revolution” series.Patch management needs a revolution, part 1: Surveying cybersecurity’s lineagePatch management needs a revolution, part 2: The flood of vulnerabilitiesPatch management needs a revolution, part 3: Vulnerability scores and the concept of trustOne of the biggest concerns with modern patch management is that we haven’t truly challenged our thinking around “patching everything” over the past 40 years. Today, we are still inundated with customer requests to patch everything, despite the available ev

### Summary Dex 2.37.0 is serving HTTPS with insecure TLS 1.0 and TLS 1.1. ### Details While working on https://github.com/dexidp/dex/issues/2848 and implementing configurable TLS support, I noticed my changes did not have any effect in TLS config, so I started investigating. https://github.com/dexidp/dex/blob/70d7a2c7c1bb2646b1a540e49616cbc39622fb83/cmd/dex/serve.go#L425 is seemingly setting TLS 1.2 as minimum version, but the whole tlsConfig is ignored after "TLS cert reloader" was introduced in https://github.com/dexidp/dex/pull/2964. Configured cipher suites are not respected either, as seen on the output. ### PoC Build Dex, generate certs with `gencert.sh`, modify `config.dev.yaml` to run on https, using generated certs. ```console issuer: http://127.0.0.1:5556/dex storage: type: sqlite3 config: file: dex.db web: https: 127.0.0.1:5556 tlsCert: examples/k8s/ssl/cert.pem tlsKey: examples/k8s/ssl/key.pem <rest as default> ``` Run dex `bin/dex serve config.dev...

Since version 5.2.0, when using deferrable mode with the path of a Kubernetes configuration file for authentication, the Airflow worker serializes this configuration file as a dictionary and sends it to the triggerer by storing it in metadata without any encryption. Additionally, if used with an Airflow version between 2.3.0 and 2.6.0, the configuration dictionary will be logged as plain text in the triggerer service without masking. This allows anyone with access to the metadata or triggerer log to obtain the configuration file and use it to access the Kubernetes cluster. This behavior was changed in version 7.0.0, which stopped serializing the file contents and started providing the file path instead to read the contents into the trigger. Users are recommended to upgrade to version 7.0.0, which fixes this issue.

Red Hat Security Advisory 2024-0337-03 - Updated images are now available for Red Hat Advanced Cluster Security 4.2.4. The updated images includes security fixes.

Red Hat Security Advisory 2024-0293-03 - Red Hat OpenShift Container Platform release 4.14.10 is now available with updates to packages and images that fix several bugs and add enhancements.

Red Hat Security Advisory 2024-0292-03 - Red Hat build of MicroShift release 4.14.10 is now available with updates to packages and images that fix several bugs.

Red Hat Security Advisory 2024-0290-03 - Red Hat OpenShift Container Platform release 4.14.10 is now available with updates to packages and images that fix several bugs and add enhancements.