Tristan reports: DNS Pre-Auth Prerequisite Check Information Oracle ================================================== CVSS 3.1: 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) CWE: CWE-863 (Incorrect Authorization) Auth: None (pre-auth) Version: Samba 4.24.3 and prior, master (2026-06-25) File: source4/dns_server/dns_update.c, lines 867-873 Root Cause: The DNS dynamic update handler evaluates prerequisite conditions before performing the authorization check. The prerequisite check returns distinct error codes (NXDOMAIN, NXRRSET, YXDOMAIN) that reveal whether specific DNS records exist, enabling pre-auth enumeration. // dns_update.c:867-873 werror = check_prerequisites(zone, updates, r->in.update); if (!W_ERROR_IS_OK(werror)) { return werror; // leaks record existence BEFORE auth check } // Authorization check happens AFTER: werror = dns_update_allowed(dns, r, zone, ...); Data Flow: Unauthenticated attacker sends DNS UPDATE with prerequisite section -> check_prerequisites() queries zone data, returns specific error: NXDOMAIN (name does not exist), NXRRSET (name exists, type missing), YXDOMAIN (name exists) -> error returned to client BEFORE dns_update_allowed() is called -> attacker learns record existence without credentials Impact: Unauthenticated attackers can enumerate internal DNS records in AD-integrated zones. In Active Directory environments, this reveals internal hostnames, service locations (SRV records), and infrastructure topology. The RFC 2136 prerequisite mechanism is intended for authenticated clients only. Lab verified: code trace confirmed prerequisite-before-auth ordering.
Checking the prerequisites first causes a few of our existing tests to fail.
Also, our current behaviour matches what Windows Server 2025 does. So if this is a bug, it is a bug in Windows as well.
Isn't the same information available to everybody via normal dns queries?
(In reply to Stefan Metzmacher from comment #3) Normal DNS queries do reveal record existence in default configurations, but the issue is specifically about the authorization gate ordering in the dynamic update code path. When AD-integrated zones are configured with "Secure dynamic updates only" (the default), the expectation is that unauthenticated clients are rejected before any zone data is processed. Currently, check_prerequisites() queries the zone and returns differentiated results (NXDOMAIN/NXRRSET/YXDOMAIN) to the client before dns_update_allowed() is reached. This is a separate code path from normal DNS queries -- zone or record-level ACLs that restrict query access do not cover the UPDATE prerequisite path. Both BIND 9 and PowerDNS deliberately check authorization before evaluating prerequisites. BIND's update.c (line 1632) includes an explicit comment about this: "Update message processing can leak record existence information so check that we are allowed to query this zone." (https://github.com/isc-projects/bind9/blob/main/lib/ns/update.c#L1631) BIND rejects unauthorized updates with REFUSED before any prerequisite evaluation occurs. PowerDNS does the same when dnsupdate-require-tsig is set. (In reply to Jennifer Sutton from comment #2) Microsoft's own documentation for secure dynamic updates describes a flow where the server refuses the unsigned update at step 2, before any prerequisite or update processing occurs. The TKEY negotiation and prerequisite evaluation only happen after authentication is established. Without a packet capture proving otherwise, the "Windows does it too" claim would need verification. Regarding the test failures from comment #1: the existing tests may be sending unauthenticated UPDATE requests and relying on prerequisite evaluation succeeding without auth. If "Secure dynamic updates only" is the intended default, those tests should be authenticating their UPDATE requests. RFC 2136's section ordering (prerequisites at 3.2, permissions at 3.3) predates any authentication mechanism for DNS UPDATE -- TSIG (RFC 2845) and secure dynamic update (RFC 3007) came four years later. The 2018 IETF DNSOP thread on this exact question (Mukund Sivaraman) discussed why the RFC sequences prerequisites before permissions, with the consensus being that it was a performance optimization for the pre-authentication era. Modern implementations have corrected this ordering.
(In reply to TristanInSec from comment #4) We start with passing system_session() to samdb_connect(), so all DNS queries by anonymous client are done as system, so any client can ask for any name/dnsRecord. handle_updates() changes the credentials to the ones from the tkey->session_info and that is called after dns_update_allowed() in order to check the permissions for the write access to the database. All read access to the database is done as system, so what is the security aspect of this bug, I don't see one. And saying there are hidden names, is not really useful, why would anyone do that?
(In reply to Stefan Metzmacher from comment #5) Thank you for the detailed explanation. If all DNS reads go through system_session() regardless of the client, then the prerequisite path does not expose anything beyond what a normal query already provides. The BIND precedent applies to BIND's architecture (where per-zone query ACLs exist and the prerequisite path could bypass them), but not to Samba's model where all reads are system-level. No security issue here. Happy to close this.
Putting as a dependency of our "Non-security bugs on their way out" bug.
Closing as INVALID per the discussion.