The fix for CVE-2023-4408 introduced a regression in the message
parser, which could cause a crash if an rdata type that can only
occur in the question was found in another section.
(cherry picked from commit 510f1de8a6)
the fix for CVE-2023-4408 introduced a regression in the message
parser, which could cause a crash if duplicate rdatasets were found
in the question section. this commit ensures that rdatasets are
correctly disassociated and freed when this occurs.
(cherry picked from commit 4c19d35614)
To prevent allocating large hashtable in dns_message, we need to
backport the improvements to isc_ht API from BIND 9.18+ that includes
support for case insensitive keys and incremental rehashing of the
hashtables.
(cherry picked from commit a4baf32415)
When parsing messages use a hashtable instead of a linear search to reduce
the amount of work done in findname when there's more than one name in
the section.
There are two hashtables:
1) hashtable for owner names - that's constructed for each section when we
hit the second name in the section and destroyed right after parsing
that section;
2) per-name hashtable - for each name in the section, we construct a new
hashtable for that name if there are more than one rdataset for that
particular name.
(cherry picked from commit b8a9631754)
The old code was not thread safe w.r.t. to the use of these variable.
We now only set them at the start of execution and copy them to
the message structure so they can be safely updated. This is the
minimal change to make them thread safe.
Shifting (signed) integer left could trigger undefined behaviour when
the shifted value would overflow into the sign bit (e.g. 2048).
The issue was found when using AFL++ and UBSAN:
message.c:2274:33: runtime error: left shift of 2048 by 20 places cannot be represented in type 'int'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior message.c:2274:33 in
(cherry picked from commit a347641782)
When parsing message with DNS_MESSAGE_BESTEFFORT (used exclusively in
tools, never in named itself) if we hit an invalid SIG(0) in wrong
place we continue parsing the message, and put the sig0 in msg->sig0.
If we then hit another sig0 in a proper place we see that msg->sig0
is already 'taken' and we don't free name and rdataset, and we don't
set seen_problem. This causes an assertion failure.
This fixes that issue by setting seen_problem if we hit second sig0,
tsig or opt, which causes name and rdataset to be always freed.
(cherry picked from commit 51a55ddbb7)
up until now, message->tsigkey could only be set during parsing
of the request, but gss-tsig allows one to be created afterward.
(cherry picked from commit 879fc0285e)
4643. [security] An error in TSIG handling could permit unauthorized
zone transfers or zone updates. (CVE-2017-3142)
(CVE-2017-3143) [RT #45383]
(cherry picked from commit 581c1526ab)
Petr ŠpačekandNicki Křížek
Mark AndrewsandMichał Kępień
Evan HuntandMichał Kępień
Ondřej SurýandMichał Kępień
Diego FronzaandOndřej Surý
Ondřej Surý
Witold KręcickiandMark Andrews
Matthijs MekkingandEvan Hunt
Mukund Sivaraman
Tinderbox User
wpk