Bug 12977 - [SECURITY ADVISORY][Fixed in 4.7] An RODC can access GetNCChanges info it shouldn't
Summary: [SECURITY ADVISORY][Fixed in 4.7] An RODC can access GetNCChanges info it sho...
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.5.12
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks: 12946
  Show dependency treegraph
 
Reported: 2017-08-21 01:24 UTC by Tim Beale
Modified: 2019-06-11 22:52 UTC (History)
5 users (show)

See Also:


Attachments
A related change which potentially highlights this problem (7.23 KB, patch)
2017-08-23 05:17 UTC, Tim Beale
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Beale 2017-08-21 01:24:18 UTC
We noticed that an RODC can bypass the GetNCChanges REPL_SECRET permissions checks in some cases. For example, If the RODC sends an acceptable GetNCChanges request (e.g. with the DRSUAPI_DRS_SPECIAL_SECRET_PROCESSING flag set), this builds up a cached array of object GUIDs that will be used for subsequent GetNCChanges requests. If the RODC then sends a GetNCChanges request with a follow-on highwater-mark, but the REPL_SECRET exop set, the cached objects are returned without doing the REPL_SECRET permissions checks first.

This only affects Samba 4.5. The problem does not ocur on Samba 4.6 and later releases.
Comment 1 Tim Beale 2017-08-21 01:28:34 UTC
Created attachment 13484 [details]
Adds a test case for Samba 4.5 to demonstrate the problem
Comment 2 Garming Sam 2017-08-21 21:55:46 UTC
From the original Samba 4.6 WHATSNEW page in terms of problems fixed in that release:

Improved Read-Only Domain Controller (RODC) Support
---------------------------------------------------

Support for RODCs in Samba AD until now has been experimental. With this latest
version, many of the critical bugs have been fixed and the RODC can be used in
DC environments requiring no writable behaviour. RODCs now correctly support
bad password lockouts and password disclosure auditing through the
msDS-RevealedUsers attribute.

The fixes made to the RWDC will also allow Windows RODC to function more
correctly and to avoid strange data omissions such as failures to replicate
groups or updated passwords. Password changes are currently rejected at the
RODC, although referrals should be given over LDAP. While any bad passwords can
trigger domain-wide lockout, good passwords which have not been replicated yet
for a password change can only be used via NTLM on the RODC (and not Kerberos).

The reliability of RODCs locating a writable partner still requires some
improvements and so the 'password server' configuration option is generally
recommended on the RODC.
Comment 3 Garming Sam 2017-08-21 22:08:06 UTC
It seems we have our version numbers confused. RODC support was introduced properly in 4.7 so the issue is not present in the newest release, but does affect 4.5 and 4.6.
Comment 4 Andrew Bartlett 2017-08-21 22:31:40 UTC
(Opening this up to our vendors for comment)

Samba 4.7 is the first Samba release to have support for hosting or being a RODC.  This may have appeared to work in previous releases, but was discussed in this bug it was not secure, nor as per the release notes to 4.7 (in comment #2) was it reliable.  

As well as the ability the sync all passwords, not just the restricted set, key features missing included password lockout.

I've spoken to Jeremy on the phone and his view is that we do NOT propose to make a security fix or request a CVE.  A backport of the affected code is non-trivial, and pointless (due to the other missing features). 

Users wishing to use Samba with RODCs are advised to use the upcoming Samba 4.7.  We may (depending on feedback from vendors and the team) issue a security advisory to this point, or just extend the WHATSNEW text for the 4.7 release.

NOTE WELL: Only administrators can create an RODC in the first place. 

Please let me know your thoughts. 

Thanks,
Comment 5 Tim Beale 2017-08-23 05:17:29 UTC
Created attachment 13490 [details]
A related change which potentially highlights this problem

FYI, I want to deliver the attached patch to Samba master. It doesn't really help to fix this problem on Samba 4.5 or 4.6. To be clear, it's the RODC auditing (i.e. updating the 'msDS-RevealedUsers' attribute) that avoids this problem on Samba 4.7. The attached patch just fixes some slightly buggy behaviour.

The attached patch is what led me to find this problem. Once it gets posted to the public Samba mailing list, it could potentially lead malicious attackers to find the problem too. If anyone has concerns over this issue, please let me know. Otherwise, I'll post my patches to the mailing list on Friday.
Comment 6 Andrew Bartlett 2017-08-28 09:25:26 UTC
Tim,

I'll post these publicly. 

I'm opening this up now and proposing a WHATSNEW addition.  I'll drop samba-vendor from the CC so we don't keep spamming our vendors, if you want to follow this further just CC yourself.
Comment 7 Andrew Bartlett 2017-08-28 09:54:44 UTC
Tim,

The patch as is doesn't apply to 4.7 or master, I think it probably builds on the rest of the GetNCChanges patches.  Can you post the full series for review to the list?

Thanks,
Comment 8 Stefan Metzmacher 2017-09-16 00:13:50 UTC
(In reply to Andrew Bartlett from comment #7)

What's the status here regarding 4.7.0?
Comment 9 Andrew Bartlett 2017-09-16 03:06:20 UTC
(In reply to Stefan Metzmacher from comment #8)
Tim's analysis is that Garming's changes in Samba 4.7 for auditing the secret replication to the RODC cause Samba 4.7 not to be vulnerable.

Samba master contains and 4.8 will include a tested and complete fix.
Comment 10 Tim Beale 2019-06-11 22:52:40 UTC
Closing this as the problem doesn't affect any releases where we actually support RODC properly, the affected releases are all now EOL'd, and we've since made improvements to the robustness around this in master, i.e.
https://git.samba.org/?p=samba.git;a=commit;h=2d0766a48b3a62de15a