CVE-2022-3262: High severity red hat openshift vulnerability

Published Sep 21, 2022
·
Updated

A flaw was found in Openshift. A pod with a DNSPolicy of "ClusterFirst" may incorrectly resolve the hostname based on a service provided. This flaw allows an attacker to supply an incorrect name with the DNS search policy, affecting confidentiality and availability.

Other sources

Pods with the default DNSPolicy of "ClusterFirst" (or pods with host network and DNSPolicy "ClusterFirstWithHostNet") would have search paths like "<namespace>.svc.cluster.local svc.cluster.local cluster.local <cluster domain>".

If a user had a namespace "com" with a service "google", then we expect these pods would look up "google.com" by trying "google.com.<namespace>.svc.cluster.local" which would fail, and then "google.com.svc.cluster.local", which would resolve to the service address of the service from the "com" namespace.

DNS policies can be set on a per-Pod basis. By default, a client Pod's DNS search list includes the Pod's own namespace and the cluster's default domain.

DNS settings are supposed to be provided using the dnsConfig field in the Pod Spec.

These policies are specified in the dnsPolicy field of a Pod Spec:

-

"Default": The Pod inherits the name resolution configuration from the node that the Pods run on. -

"ClusterFirst": Any DNS query that does not match the configured cluster domain suffix, such as "www.kubernetes.io", is forwarded to the upstream nameserver inherited from the node. Cluster administrators may have extra stub-domain and upstream DNS servers configured. -

"ClusterFirstWithHostNet": For Pods running with hostNetwork, you should explicitly set its DNS policy "ClusterFirstWithHostNet". -

"None": It allows a Pod to ignore DNS settings from the Kubernetes environment. All

If dnsPolicy is not explicitly specified, then "ClusterFirst" is used.

Workaround:

USER:

DNS queries may be expanded using the Pod's /etc/resolv.conf. Kubelet sets this file for each Pod. For example, a query for just google may be expanded to google.com.svc.cluster.local where com is the name of the namespace.

The values of the search option in /etc/resolv.conf. are used to expand DNS queries.

In the case that /etc/resolv.conf contains expended search

nameserver 10.1.0.10

search <namespace>.svc.cluster.local svc.cluster.local cluster.local

options ndots:5

There will be a lookup for google.<namespace>.svc.cluster.local (where the namespace is com)

And also the DNSPolicy set to "ClusterFirst", an internal bad user will be able to forward all google.com into his POD.

So the customer should check and change the default DNS configuration.

OCP:

Change the default configuration to not include expended search, and that the ClusterFirst is not set by default.

Check if there is an option to prevent giving TLD names for namespaces and services in OCP.

Red Hat

Affected Software

1 affected component
redhat Openshift=4.9

Event History

Sep 21, 2022
Data Sourced
via Red Hat·05:26 PM
DescriptionSeverityAffected Software
Dec 8, 2022
CVE Published
via MITRE·12:00 AM
Data Sourced
via MITRE·12:00 AM
DescriptionWeakness
Data Sourced
via NVD·04:15 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What is CVE-2022-3262?

CVE-2022-3262 is a vulnerability found in Openshift that allows an attacker to supply an incorrect name with the DNS search policy, affecting confidentiality and availability.

2

How does CVE-2022-3262 affect Openshift?

CVE-2022-3262 affects Openshift by allowing a pod with a DNSPolicy of "ClusterFirst" to incorrectly resolve the hostname based on a service provided.

3

What is the severity of CVE-2022-3262?

CVE-2022-3262 has a severity rating of high with a CVSS score of 8.1.

4

How can CVE-2022-3262 be exploited?

CVE-2022-3262 can be exploited by supplying an incorrect name with the DNS search policy in a pod with a DNSPolicy of "ClusterFirst".

5

Are there any references related to CVE-2022-3262?

Yes, there are references available for CVE-2022-3262. You can find them at the following links: [Red Hat Service Now](https://redhat.service-now.com/surl.do?n=INC2263871) and [Red Hat Bugzilla](https://bugzilla.redhat.com/show_bug.cgi?id=2128858).

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203