A SQL Injection vulnerability exists in Esri ArcGIS Server versions 11.3, 11.4 and 11.5 on Windows, Linux and Kubernetes. This vulnerability allows a remote, unauthenticated attacker to execute arbitrary SQL commands via a specific ArcGIS Feature Service operation. Successful exploitation can potentially result in unauthorized access, modification, or deletion of data from the underlying Enterprise Geodatabase.

Kubernetes api server: build config to a strategy that isn't allowed by policy

External reference: https://github.com/openshift/origin/issues/6556 https://github.com/openshift/origin/pull/6576

This vulnerability exposes a network port in minikube running on macOS with Docker driver that could enable unexpected remote access to the minikube container.

A security issue was discovered in the Kubernetes Image Builder versions <= v0.1.37 where default credentials are enabled during the image build process. Virtual machine images built using the Proxmox provider do not disable these default credentials, and nodes using the resulting images may be accessible via these default credentials. The credentials can be used to gain root access. Kubernetes clusters are only affected if their nodes use VM images created via the Image Builder project with its Proxmox provider.

An incorrect authorization vulnerability exists in Esri Portal for ArcGIS 11.4, 11.5 and 12.0 on Windows, Linux and Kubernetes that did not correctly check permissions assigned to developer credentials.

Esri Portal for ArcGIS versions 12.1 and earlier on Windows, Linux and Kubernetes have a missing authentication for critical function vulnerability allows a remote, unauthenticated attacker to access an unprotected API.

A Weak Password Recovery Mechanism for Forgotten Password exists in Esri Portal for ArcGIS versions 12.1 and earlier on Windows, Linux and Kubernetes. A remote, unauthorized attacker may assume ownership of a user’s account by manipulating this mechanism. ArcGIS Administrators should configure an email server with ArcGIS Enterprise to facilitate user self-service password recovery. The ability for an administrator to reset a user’s password remains unchanged.

In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3, incorrect handling of error responses to proxied upgrade requests in the kube-apiserver allowed specially crafted requests to establish a connection through the Kubernetes API server to backend servers, then send arbitrary requests over the same connection directly to the backend, authenticated with the Kubernetes API server's TLS credentials used to establish the backend connection.

Kubernetes version 1.5.0-1.5.4 is vulnerable to a privilege escalation in the PodSecurityPolicy admission plugin resulting in the ability to make use of any existing PodSecurityPolicy object.

In Kubernetes versions 1.9.0-1.9.9, 1.10.0-1.10.5, and 1.11.0-1.11.1, user input was handled insecurely while setting up volume mounts on Windows nodes, which could lead to command line argument injection.

In Kubernetes versions 1.3.x, 1.4.x, 1.5.x, 1.6.x and prior to versions 1.7.14, 1.8.9 and 1.9.4 containers using subpath volume mounts with any volume type (including non-privileged pods, subject to file permissions) can access files/directories outside of the volume, including the host's filesystem.

A flaw was found in HyperShift's hosted control plane konnectivity-server configuration. The proxy-server is started without the --cluster-ca-cert flag, which means the agent-facing TLS listener is set to tls.NoClientCert and does not request or verify client certificates at all. An attacker with network access to the externally-exposed konnectivity cluster endpoint can connect with an arbitrary or self-signed certificate (or no certificate) and be added to the agent routing pool. Once in the routing pool, the attacker can intercept, modify, or drop control-plane-to-node traffic that the server routes through their connection, including kubectl exec/logs streams, kubelet API calls with pod specs containing secrets, service account tokens, and ConfigMap/Secret data. The fix adds --cluster-ca-cert referencing the existing per-cluster konnectivity CA bundle that is already mounted in the container.

Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.

''' We've discovered a privilege escalation issue in the OpenShift platform.

Conditions for the privilege escalation: - a user must be granted the ability to "update, patch" the "pods/ephemeralcontainers" subresource - by default, NEITHER common users NOR Service Accounts are granted this permission by the platform - with the above permission, a user is able to patch a running pod they've got access to and bypass SCC admission - this means, a user can create a "privileged" container, which allows them obtaining access to the pod's node resources

The step-by-step reproducer is described in https://issues.redhat.com/browse/OCPBUGS-7181.

Affected OpenShift Container Platform versions: 4.10 and newer. Affected component: kube-apiserver (and the platforms that use it)

The bug is located within the apiserver-library-go repository in the following module: https://github.com/openshift/apiserver-library-go/tree/master/pkg/securitycontextconstraints. We are yet to determine how to fix it.

The workaround is to remove the permissions to "update, patch" the "pods/ephemeralcontainers" subresource from any low-privileged users, if there are any that currently hold it. '''

From Stanislav Láznička

A flaw introduced in CRI-O version 1.19 which an attacker can use to bypass the safeguards and set arbitrary kernel parameters on the host. As a result, anyone with rights to deploy a pod on a Kubernetes cluster that uses the CRI-O runtime can abuse the “kernel.corepattern” kernel parameter to achieve container escape and arbitrary code execution as root on any node in the cluster.

A security issue was discovered in ingress-nginx where an actor with permission to create Ingress objects (in the networking.k8s.io or extensions API group) can bypass annotation validation to inject arbitrary commands and obtain the credentials of the ingress-nginx controller. In the default configuration, that credential has access to all secrets in the cluster.

Prior to 3385, the user-controlled role parameter enters the application in the Kubernetes::RoleVerificationsController. The role parameter flows into the RoleConfigFile initializer and then into the Kubernetes::Util.parsefile method where it is unsafely deserialized using the YAML.loadstream method. This issue may lead to Remote Code Execution (RCE). This vulnerability is fixed in 3385.

A security issue was discovered in ingress-nginx where the nginx.ingress.kubernetes.io/rewrite-target Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)

A security issue was discovered in ingress-nginx where a combination of Ingress annotations can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)

A flaw was found in Kubernetes that allows attackers on adjacent networks to reach services exposed on localhost ports, previously thought to be unreachable. This flaw allows an attacker to gain privileges or access confidential information for any services listening on localhost ports that are not protected by authentication.

Node address isn't always verified when proxying

Privilege Escalation in kOps using GCE/GCP Provider in Gossip Mode.

A security issue was discovered in Kubernetes where a user may be able to create a container with subpath volume mounts to access files & directories outside of the volume, including on the host filesystem.

Kubernetes CRI-O version prior to 1.9 contains a Privilege Context Switching Error (CWE-270) vulnerability in the handling of ambient capabilities that can result in containers running with elevated privileges, allowing users abilities they should not have. This attack appears to be exploitable via container execution. This vulnerability appears to have been fixed in 1.9.

In Minikube versions 0.3.0-0.29.0, minikube exposes the Kubernetes Dashboard listening on the VM IP at port 30000. In VM environments where the IP is easy to predict, the attacker can use DNS rebinding to indirectly make requests to the Kubernetes Dashboard, create a new Kubernetes Deployment running arbitrary code. If minikube mount is in use, the attacker could also directly access the host filesystem.

A security issue was discovered in aws-iam-authenticator where an allow-listed IAM identity may be able to modify their username and escalate privileges.

Issue Details A security issue was identified in ingress-nginx where the nginx.ingress.kubernetes.io/configuration-snippet annotation on an Ingress object (in the networking.k8s.io or extensions API group) can be used to inject arbitrary commands, and obtain the credentials of the ingress-nginx controller. In the default configuration, that credential has access to all secrets in the cluster.

This issue has been rated High (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L), and assigned CVE-2023-5043.

Affected Components and Configurations This bug affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running kubectl get po -n ingress-nginx.

If you are running the “chrooted” ingress-nginx controller introduced in v1.2.0 (gcr.io/k8s-staging-ingress-nginx/controller-chroot), command execution is possible but credential extraction is not, so the High severity does not apply.

Multi-tenant environments where non-admin users have permissions to create Ingress objects are most affected by this issue.

Affected Versions <v1.9.0 Versions allowing mitigation v1.9.0 Mitigation Ingress Administrators should set the --enable-annotation-validation flag to enforce restrictions on the contents of ingress-nginx annotation fields.

Detection If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io

Additional Details See ingress-nginx Issue #10571 for more details.

Acknowledgements This vulnerability was reported by suanve

Thank You, CJ Cullen on behalf of the Kubernetes Security Response Committee

A security issue was identified in ingress-nginx where the nginx.ingress.kubernetes.io/permanent-redirect annotation on an Ingress object (in the networking.k8s.io or extensions API group) can be used to inject arbitrary commands, and obtain the credentials of the ingress-nginx controller. In the default configuration, that credential has access to all secrets in the cluster.

Ingress-nginx path sanitization can be bypassed with logformat directive.

A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they include Windows nodes.