Bug 2128858 (CVE-2022-3262)

Summary: CVE-2022-3262 openshift: insecure default DNSPolicy for pods
Product: [Other] Security Response Reporter: Sage McTaggart <amctagga>
Component: vulnerabilityAssignee: Nobody <nobody>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: jburrell, joelsmith, vkumar
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
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.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2106172    

Description Sage McTaggart 2022-09-21 17:26:12 UTC
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.

Comment 1 Sage McTaggart 2022-09-21 17:27:36 UTC
https://redhat.service-now.com/surl.do?n=INC2263871