[EU GDPR] [Feature Request] Fallback-DNS (Google) should be removed as it is incompatible with GDPR, PCI-DSS, most company policies, doesn't follow secure coding practices etc. #47541
Description
Description
Feature-Request
The automatic fallback to Google's DNS servers 8.8.8.8, 8.8.4.4, 2001:4860:4860::8888, 2001:4860:4860::8844 should be:
- Removed completely
OR - Disabled by default and possible to enable via a dedicated config-flag for those who actually need it
OR - Possible to disable in such a way that any other configuration-changes on the host will never risk re-enabling the behavior while still allowing for dynamic DNS-configuration of the host
("Disabling" it by configuring a static dns-server in docker daemon's config is not a valid workaround as it's easy to forget and it goes against any reasonable design-practices since it will "fail-open".)
Feature-request vs Security-issue
This is a feature request as and not a security issue as the current behavior is clearly the intended (although flawed) behavior of docker.
Background
The current hard coded DNS fallback implemented in Docker injects "Google's" DNS servers into containers seemingly "at random" (I tried figuring out exactly when this happens but after digging through the code for a couple hours i'm still not certain).
It is "automatic" - meaning it's also "silent" and most people won't notice anything wrong unless they start digging through Docker's logs to find a log-message like this:
Mar 09 08:37:05 <hostname> dockerd[169401]: time="2024-03-09T08:37:05.693129370Z" level=info msg="No non-localhost DNS nameservers are left in resolv.conf. Using default external servers: [nameserver 8.8.8.8 nameserver 8.8.4.4]"
Or enter the containers and notice that something isn't right with the DNS setup:
root@1f8e57d83ea1:/# cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888
nameserver 2001:4860:4860::8844
Discussion
This "hacky solution" bypasses any well-known dynamic-configuration methods of DNS servers like DHCP (something many / most servers use these days) and the only way to "disable" this feature seems to be to configure static DNS-servers in daemon.json which overrides all dns-servers, but this replaces the behavior with another and isn't the right way to go, it's also very easy to forget to do this on every host you manage.
In practice the effect from this is that most systems out there might at some point redirect DNS traffic from containers to those hard coded IP's without notifying anyone about it and it could be triggered by an unrelated change outside of the host.
Any DNS-requests issued from such a container will be sent towards public internet with no regard for the potentially confidential information it might contain (end-user ip's, authentication system adresses) or who the receiver of that request is. The adresses might belong to Google administratively but DNS hijacking is common and few people, if any, are aware when such hijacks takes place. Is it really Google on the other end or is it "Google" you're sending your users traffic to?
The fact that this fallback happens automatically and nothing explodes for users when their DNS configuration is wrong means that there are probably a lot of docker-users out there who aren't even aware that they're "leaking" private / sensitive / confidential information to whoever happens to be on the other end at the moment.
For all we know it might as well be some attacker who managed to hijack the prefix due to some lazy filtering at your local ISP and then Docker suddenly decides to ask the attackers DNS-server where some authentication-server is, not a very helpful or secure fallback-behavior from Docker.
Incompatible with GDPR
- According to GDPR, any information that can be used to identify an end-user is "Personally Identifiable Information" (PII).
- An IP address can be used to identify a user; therefore IP addresses are considered PII.
- DNS resolves to IP addresses (A, AAAA) or from IP addresses (PTR). If a DNS request (like a PTR request) can be used to identify an end user's actions, then it's also PII.
- Anyone intercepting or receiving this request can (usually correctly) assume that the end-user communicated with the service around that time.
- PII can only be shared with third parties with the user's approval - trying to "fake it into being legal" by pointing to some general terms of service of Google's DNS is a no-go.
- The end-user would need to approve/accept that Google processes their PII, and most businesses aren't even aware that they're risking sending their PII to Google by simply running Docker.
- Each organization using Docker with its "magic fallback" would need a contract with Google regarding the processing of PII if they intend to send PII to them.
- There aren't even any guarantees that it's actually Google on the other end and why even trust Google?
Why is a company who's main source of income is from selling advertising considered trustworthy?
- PII must be protected, the confidentiality of the end-user needs to be guaranteed, it's never okay to share PII over insecure channels and DNS is, by design, an insecure channel.
- DNS can only guarantee data integrity (dnssec), not confidentiality.
ChatGPT's view aligns with mine
Q: Based on GDPR make a detailed technical argument about the practice of using third-party software which has hard coded fallbacks to public DNS Servers with references to the relevant GDPR paragraphs.
ChatGPT
The General Data Protection Regulation (GDPR) aims to protect the personal data of European Union (EU) citizens by regulating its processing and ensuring the rights of individuals. When discussing the practice of using third-party software with hardcoded fallbacks to public DNS servers, several GDPR principles and provisions come into play.
- Lawfulness, fairness, and transparency (Article 5(1)(a)): The GDPR requires that personal data be processed lawfully, fairly, and transparently. Hardcoding fallbacks to public DNS servers may lead to the transmission of users' personal data without their explicit consent or knowledge. This lack of transparency violates the principle of fairness and transparency, as users are not adequately informed about the potential processing of their data.
- Purpose limitation (Article 5(1)(b)): Personal data should be collected for specified, explicit, and legitimate purposes and not further processed in a manner that is incompatible with those purposes. Using third-party software with hardcoded fallbacks to public DNS servers may result in the unintentional collection and processing of personal data for purposes beyond what users consented to. This violates the principle of purpose limitation, as the data may be processed for unintended purposes without the users' knowledge or consent.
- Data minimization (Article 5(1)(c)): Personal data should be adequate, relevant, and limited to what is necessary in relation to the purposes for which they are processed. Hardcoding fallbacks to public DNS servers may lead to the unnecessary transmission of personal data, as the software may query these servers even when it's not essential for the service provided. This violates the principle of data minimization, as the software may collect and transmit more data than necessary for its intended purpose.
- Security of processing (Article 32): Data controllers and processors are required to implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk. Hardcoding fallbacks to public DNS servers may expose personal data to security risks, as these servers are publicly accessible and may not provide adequate protection for the data transmitted to them. This could lead to unauthorized access, disclosure, or alteration of personal data, thereby violating the security of processing requirement.
- Accountability and governance (Article 5(2)): Data controllers are responsible for demonstrating compliance with the principles relating to processing of personal data. Using third-party software with hardcoded fallbacks to public DNS servers without adequate safeguards or mechanisms to protect users' personal data demonstrates a lack of accountability. Data controllers should implement measures such as data protection impact assessments (DPIAs) and privacy by design and by default to ensure compliance with the GDPR principles.
In conclusion, the practice of using third-party software with hardcoded fallbacks to public DNS servers raises significant concerns regarding compliance with the GDPR. It violates several key principles and provisions, including lawfulness, fairness, and transparency; purpose limitation; data minimization; security of processing; and accountability and governance. Data controllers must ensure that any software they use complies with the GDPR and adequately protects users' personal data. Failure to do so may result in significant legal and financial consequences.
Considered a security risk in PCI-DSS
I let ChatGPT write an explanation for this.
The practice of using third-party software with hard-coded fallbacks to public DNS servers introduces significant security risks and may result in non-compliance with multiple PCI-DSS requirements.
Q: Based on PCI-DSS make a detailed technical argument about the practice of using third-party software which has hard coded fallbacks to public DNS Servers with references to the relevant PCI-DSS requirements.
ChatGPT
Using third-party software with hard-coded fallbacks to public DNS servers poses significant security risks and may lead to non-compliance with several PCI-DSS (Payment Card Industry Data Security Standard) requirements. PCI-DSS is a set of security standards designed to ensure that all companies that accept, process, store, or transmit credit card information maintain a secure environment. Let's delve into the technical argument:
Requirement 1: Install and maintain a firewall configuration to protect cardholder data: By using third-party software with hard-coded fallbacks to public DNS servers, you're potentially bypassing your organization's firewall rules. This can expose your network to unauthorized access and compromise cardholder data.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters: Hard-coded fallbacks to public DNS servers often involve default configurations provided by the software vendor. These defaults may include insecure settings or credentials, making it easier for attackers to exploit vulnerabilities and gain unauthorized access to cardholder data.
Requirement 4: Encrypt transmission of cardholder data across open, public networks: Public DNS servers are part of the public network infrastructure and may not provide adequate encryption for transmitting sensitive cardholder data. By relying on these servers as fallbacks, you increase the risk of data interception and compromise during transmission.
Requirement 6: Develop and maintain secure systems and applications: Hard-coded fallbacks to public DNS servers represent poor software design and development practices. Secure applications should allow for configurable DNS settings and avoid relying on external services that are beyond your organization's control.
Requirement 8: Identify and authenticate access to system components: Third-party software with hard-coded fallbacks may introduce unauthorized access points into your network. These access points could be exploited by attackers to gain unauthorized access to cardholder data and compromise the integrity of your payment processing systems.
Requirement 10: Track and monitor all access to network resources and cardholder data: By using third-party software with hard-coded fallbacks to public DNS servers, you may overlook important network traffic that bypasses your organization's monitoring and logging mechanisms. This blind spot can hinder your ability to detect and respond to security incidents in a timely manner.
Requirement 11: Regularly test security systems and processes: Hard-coded fallbacks to public DNS servers should be identified and tested as part of your organization's vulnerability management program. Regular testing can help uncover potential security weaknesses and ensure that appropriate controls are in place to mitigate risks effectively.
In summary, the practice of using third-party software with hard-coded fallbacks to public DNS servers introduces significant security risks and may result in non-compliance with multiple PCI-DSS requirements. Organizations should prioritize the use of secure software that allows for configurable DNS settings and adheres to best practices for secure application development and deployment.
Leaking confidential information from organizations to Internet
The current design with the automagic "Google-DNS-hack" also conflicts with the confidentiality requirements most organizations/businesses have. I'm fairly certain that most businesses have not made a decision to share sensitive / internal information like where the secrets are stored or what Amazon-buckets they use publicly, yet Docker might just decide to share it for them via its DNS-"fallback".
It's relatively simple to figure out a lot of information about a client, mapping an organization's internal infrastructure, usage patterns etc based on the DNS queries that a client sends. If the other end is a malicious attacker then it might even be a severe security-risk for the users.
- System-/Service-Names for most internal/external services
- Build-systems
- Storage-systems
- VM/Container env
- Databases
- Authentication providers/secrets management
- Service-discovery scheme/scheduler in use
- etc.
Summary
- The current design might "randomly" leak GDPR PII data unencrypted over the public Internet to an unauthorized third-party putting organizations at risk of Violating GDPR regulation.
- The current design is incompatible with GDPR and places the risk of Violating GDPR on the user and most aren't even aware that they're leaking privacy/confidential data publicly.
- The current design introduces significant security risk according to PCI-DSS and may result in non-compliance with multiple PCI-DSS requirements.
- The current design might "randomly" leak internal confidential data from organizations to the public internet/competitors etc.
- The design should be changed so that it's possible to disable the fallback DNS hack completely so it's never used.