The Samba-Bugzilla – Attachment 16449 Details for
Bug 14595
CVE-2020-27840 [SECURITY] Unauthenticated remote heap corruption via bad DNs
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
[patch]
patch for unsupported Samba 4 versions
CVE-2020-27840-patch-for-obsolete-versions.patch (text/plain), 3.99 KB, created by
Douglas Bagnall
on 2021-02-11 22:51:05 UTC
(
hide
)
Description:
patch for unsupported Samba 4 versions
Filename:
MIME Type:
Creator:
Douglas Bagnall
Created:
2021-02-11 22:51:05 UTC
Size:
3.99 KB
patch
obsolete
>From 7531cc5e0f5d9a8f3b1b79b585842f3cadefa327 Mon Sep 17 00:00:00 2001 >From: Douglas Bagnall <douglas.bagnall@catalyst.net.nz> >Date: Fri, 11 Dec 2020 16:32:25 +1300 >Subject: [PATCH] CVE-2020-27840 ldb_dn: avoid head corruption in > ldb_dn_explode > >A DN string with lots of trailing space can cause ldb_dn_explode() to >put a zero byte in the wrong place in the heap. > >When a DN string has a value represented with trailing spaces, >like this > > "CN=foo ,DC=bar" > >the whitespace is supposed to be ignored. We keep track of this in the >`t` pointer, which is NULL when we are not walking through trailing >spaces, and points to the first space when we are. We are walking with >the `p` pointer, writing the value to `d`, and keeping the length in >`l`. > > "CN=foo ,DC= " ==> "foo " > ^ ^ ^ > t p d > --l--- > >The value is finished when we encounter a comma or the end of the >string. If `t` is not NULL at that point, we assume there are trailing >spaces and wind `d and `l` back by the correct amount. Then we switch >to expecting an attribute name (e.g. "CN"), until we get to an "=", >which puts us back into looking for a value. > >Unfortunately, we forget to immediately tell `t` that we'd finished >the last value, we can end up like this: > > "CN=foo ,DC= " ==> "" > ^ ^ ^ > t p d > l=0 > >where `p` is pointing to a new value that contains only spaces, while >`t` is still referring to the old value. `p` notices the value ends, >and we subtract `p - t` from `d`: > > "CN=foo ,DC= " ==> ? "" > ^ ^ ^ > t p d > l ~= SIZE_MAX - 8 > >At that point `d` wants to terminate its string with a '\0', but >instead it terminates someone else's byte. This does not crash if the >number of trailing spaces is small, as `d` will point into a previous >value (a copy of "foo" in this example). Corrupting that value will >ultimately not matter, as we will soon try to allocate a buffer `l` >long, which will be greater than the available memory and the whole >operation will fail properly. > >However, with more spaces, `d` will point into memory before the >beginning of the allocated buffer, with the exact offset depending on >the length of the earlier attributes and the number of spaces. > >What about a longer DN with more attributes? For example, >"CN=foo ,DC= ,DC=example,DC=com" -- since `d` has moved out of >bounds, won't we continue to use it and write more DN values into >mystery memory? Fortunately not, because the aforementioned allocation >of `l` bytes must happen first, and `l` is now huge. The allocation >happens in a talloc_memdup(), which is by default restricted to >allocating 256MB. > >So this allows a person who controls a string parsed by ldb_dn_explode >to corrupt heap memory by placing a single zero byte at a chosen >offset before the allocated buffer. > >An LDAP bind request can send a string DN as a username. This DN is >necessarily parsed before the password is checked, so an attacker does >not need proper credentials. The attacker can easily cause a denial of >service and we cannot rule out more subtle attacks. > >The immediate solution is to reset `t` to NULL when a comma is >encountered, indicating that we are no longer looking at trailing >whitespace. > >Found with the help of Honggfuzz. > >BUG: https://bugzilla.samba.org/show_bug.cgi?id=14595 > >Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz> >--- > lib/ldb/common/ldb_dn.c | 1 + > 1 file changed, 1 insertion(+) > >diff --git a/lib/ldb/common/ldb_dn.c b/lib/ldb/common/ldb_dn.c >index 3fa5ab57056..20e613c9b09 100644 >--- a/lib/ldb/common/ldb_dn.c >+++ b/lib/ldb/common/ldb_dn.c >@@ -574,6 +574,7 @@ static bool ldb_dn_explode(struct ldb_dn *dn) > /* trim back */ > d -= (p - t); > l -= (p - t); >+ t = NULL; > } > > in_attr = true; >-- >2.25.1 >
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Raw
Actions:
View
Attachments on
bug 14595
:
16365
|
16366
|
16383
|
16441
|
16442
|
16444
|
16445
|
16446
|
16447
|
16448
| 16449 |
16460
|
16461
|
16462
|
16463
|
16464
|
16530
|
16547