The Samba-Bugzilla – Attachment 16441 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 with more explanatory text.
0001-CVE-2020-27840-ldb_dn-avoid-head-corruption-in-ldb_d.patch (text/plain), 3.98 KB, created by
Douglas Bagnall
on 2021-02-11 02:25:10 UTC
(
hide
)
Description:
patch with more explanatory text.
Filename:
MIME Type:
Creator:
Douglas Bagnall
Created:
2021-02-11 02:25:10 UTC
Size:
3.98 KB
patch
obsolete
>From 531f361ede50c9a9b9575a8969e3843acfd64250 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 001fcad621f..cce5ad5b2ff 100644 >--- a/lib/ldb/common/ldb_dn.c >+++ b/lib/ldb/common/ldb_dn.c >@@ -570,6 +570,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