Commits on Source (14)
-
Object-specific access checks refer to a specific section of the MS-ADTS, and the code closely matches the spec. We need to extend this logic to properly handle the Control-Access Right (CR), so it makes sense to split the logic out into its own function. This patch just moves the code, and should not alter the logic (apart from ading in the boolean grant_access return variable. BUG: https://bugzilla.samba.org/show_bug.cgi?id=13434 Signed-off-by:
Tim Beale <timbeale@catalyst.net.nz> Reviewed-by:
Andrew Bartlett <abartlet@samba.org> Reviewed-by:
Gary Lockyer <gary@catalyst.net.nz>
-
Reading the spec and then reading the code makes sense, but we could comment the code more so it makes sense on its own. BUG: https://bugzilla.samba.org/show_bug.cgi?id=13434 Signed-off-by:
Tim Beale <timbeale@catalyst.net.nz> Reviewed-by:
Andrew Bartlett <abartlet@samba.org> Reviewed-by:
Gary Lockyer <gary@catalyst.net.nz>
-
Adds tests that assert that a confidential attribute cannot be guessed by an unprivileged user through wildcard DB searches. The tests basically consist of a set of DB searches/assertions that get run for: - basic searches against a confidential attribute - confidential attributes that get overridden by giving access to the user via an ACE (run against a variety of ACEs) - protecting a non-confidential attribute via an ACL that denies read- access (run against a variety of ACEs) - querying confidential attributes via the dirsync controls These tests all pass when run against a Windows Dc and all fail against a Samba DC. BUG: https://bugzilla.samba.org/show_bug.cgi?id=13434 Signed-off-by:
Tim Beale <timbeale@catalyst.net.nz> Reviewed-by:
Andrew Bartlett <abartlet@samba.org> Reviewed-by:
Gary Lockyer <gary@catalyst.net.nz>
-
Currently Samba is a bit disclosive with LDB_OP_PRESENT (i.e. attribute=*) searches compared to Windows. All the acl.py tests are based on objectClass=* searches, where Windows will happily tell a user about objects they have List Contents rights, but not Read Property rights for. However, if you change the attribute being searched for, suddenly the objects are no longer visible on Windows (whereas they are on Samba). This is a problem, because Samba can tell you about which objects have confidential attributes, which in itself could be disclosive. This patch adds a acl.py test-case that highlights this behaviour. The test passes against Windows but fails against Samba. Signed-off-by:
Tim Beale <timbeale@catalyst.net.nz> Reviewed-by:
Andrew Bartlett <abartlet@samba.org> Reviewed-by:
Gary Lockyer <gary@catalyst.net.nz>
-
It is perfectly legal to search LDAP for an attribute that is not part of the schema. That part of the query should simply not match. BUG: https://bugzilla.samba.org/show_bug.cgi?id=13434 Signed-off-by:
Gary Lockyer <gary@catalyst.net.nz> Reviewed-by:
Andrew Bartlett <abartlet@samba.org>
-
An 'Object Access Allowed' ACE that assigned 'Control Access' (CR) rights to a specific attribute would not actually grant access. What was happening was the remaining_access mask for the object_tree nodes would be Read Property (RP) + Control Access (CR). The ACE mapped to the schemaIDGUID for a given attribute, which would end up being a child node in the tree. So the CR bit was cleared for a child node, but not the rest of the tree. We would then check the user had the RP access right, which it did. However, the RP right was cleared for another node in the tree, which still had the CR bit set in its remaining_access bitmap, so Samba would not grant access. Generally, the remaining_access only ever has one bit set, which means this isn't a problem normally. However, in the Control Access case there are 2 separate bits being checked, i.e. RP + CR. One option to fix this problem would be to clear the remaining_access for the tree instead of just the node. However, the Windows spec is actually pretty clear on this: if the ACE has a CR right present, then you can stop any further access checks. BUG: https://bugzilla.samba.org/show_bug.cgi?id=13434 Signed-off-by:
Tim Beale <timbeale@catalyst.net.nz> Reviewed-by:
Andrew Bartlett <abartlet@samba.org> Reviewed-by:
Gary Lockyer <gary@catalyst.net.nz>
-
So we can re-use the same logic laster for checking the search-ops. BUG: https://bugzilla.samba.org/show_bug.cgi?id=13434 Signed-off-by:
Tim Beale <timbeale@catalyst.net.nz> Reviewed-by:
Andrew Bartlett <abartlet@samba.org> Reviewed-by:
Gary Lockyer <gary@catalyst.net.nz>
-
Flip the dirsync check (to avoid a double negative), and use a helper boolean variable. BUG: https://bugzilla.samba.org/show_bug.cgi?id=13434 Signed-off-by:
Tim Beale <timbeale@catalyst.net.nz> Reviewed-by:
Andrew Bartlett <abartlet@samba.org> Reviewed-by:
Gary Lockyer <gary@catalyst.net.nz>
-
This better reflects the special case we're making for dirsync, and gets rid of a 'if-else' clause. BUG: https://bugzilla.samba.org/show_bug.cgi?id=13434 Signed-off-by:
Tim Beale <timbeale@catalyst.net.nz> Reviewed-by:
Andrew Bartlett <abartlet@samba.org> Reviewed-by:
Gary Lockyer <gary@catalyst.net.nz>
-
A user that doesn't have access to view an attribute can still guess the attribute's value via repeated LDAP searches. This affects confidential attributes, as well as ACLs applied to an object/attribute to deny access. Currently the code will hide objects if the attribute filter contains an attribute they are not authorized to see. However, the code still returns objects as results if confidential attribute is in the search expression itself, but not in the attribute filter. To fix this problem we have to check the access rights on the attributes in the search-tree, as well as the attributes returned in the message. Points of note: - I've preserved the existing dirsync logic (the dirsync module code suppresses the result as long as the replPropertyMetaData attribute is removed). However, there doesn't appear to be any test that highlights that this functionality is required for dirsync. - To avoid this fix breaking the acl.py tests, we need to still permit searches like 'objectClass=*', even though we don't have Read Property access rights for the objectClass attribute. The logic that Windows uses does not appear to be clearly documented, so I've made a best guess that seems to mirror Windows behaviour. BUG: https://bugzilla.samba.org/show_bug.cgi?id=13434 Signed-off-by:
Tim Beale <timbeale@catalyst.net.nz> Reviewed-by:
Andrew Bartlett <abartlet@samba.org> Reviewed-by:
Gary Lockyer <gary@catalyst.net.nz>
-
The acl_read.c code contains a special case to allow dirsync to work-around having insufficient access rights. We had a concern that the dirsync module could leak sensitive information for deleted objects. This patch adds a test-case to prove whether or not this is happening. The new test case is similar to the existing dirsync test except: - We make the confidential attribute also preserve-on-delete, so it hangs around for deleted objcts. Because the attributes now persist across test case runs, I've used a different attribute to normal. (Technically, the dirsync search expressions are now specific enough that the regular attribute could be used, but it would make things quite fragile if someone tried to add a new test case). - To handle searching for deleted objects, the search expressions are now more complicated. Currently dirsync adds an extra-filter to the '!' searches to exclude deleted objects, i.e. samaccountname matches the test-objects AND the object is not deleted. We now extend this to include deleted objects with lastKnownParent equal to the test OU. The search expression matches either case so that we can use the same expression throughout the test (regardless of whether the object is deleted yet or not). This test proves that the dirsync corner-case does not actually leak sensitive information on Samba. This is due to a bug in the dirsync code - when the buggy line is removed, this new test promptly fails. Test also passes against Windows. BUG: https://bugzilla.samba.org/show_bug.cgi?id=13434 Signed-off-by:
Tim Beale <timbeale@catalyst.net.nz> Reviewed-by:
Andrew Bartlett <abartlet@samba.org> Reviewed-by:
Gary Lockyer <gary@catalyst.net.nz>
-
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13453 CVE-2018-10858: Insufficient input validation on client directory listing in libsmbclient. Signed-off-by:
Jeremy Allison <jra@samba.org> Reviewed-by:
Ralph Boehme <slow@samba.org>
-
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13453 CVE-2018-10858: Insufficient input validation on client directory listing in libsmbclient. Signed-off-by:
Jeremy Allison <jra@samba.org> Reviewed-by:
Ralph Boehme <slow@samba.org>
-
samba (2:4.5.12+dfsg-2+deb9u3) stretch-security; urgency=high * Non-maintainer upload by the Security Team. * Confidential attribute disclosure from the AD LDAP server (CVE-2018-10919) * Insufficient input validation on client directory listing in libsmbclient (CVE-2018-10858)
debian/patches/CVE-2018-10858-4.6.patch
0 → 100644
debian/patches/CVE-2018-10919.patch
0 → 100644
This diff is collapsed.
This diff is collapsed.