DNS replies with very many resource records might be processed very inefficiently, in extreme cases taking even several CPU seconds for each such uncached message. For example, a few thousand A records can be squashed into one DNS message (limit is 64kB). To execute an attack it is enough to: + own a rogue authoritative server or utilize an existing name with a huge RRset, and + trigger DNS query for that name from the resolver to be attacked References: https://gitlab.labs.nic.cz/knot/knot-resolver/tags/v4.3.0
From upstream: Most of the issue can be mitigated by updating libknot dependency to >= 2.9.1. Otherwise a complete fix will be released in Knot Resolver 4.3.0, which also does not require libknot update. The attached patches are applicable to recent releases (when doc diff is stripped).
Created attachment 1641993 [details] big-rrset.patch
Created attachment 1641994 [details] cname-limit.patch
Public via: https://www.openwall.com/lists/oss-security/2019/12/04/4 https://seclists.org/oss-sec/2019/q4/119 Lifting embargo.
Created knot-resolver tracking bugs for this issue: Affects: fedora-all [bug 1780511]
Created knot-resolver tracking bugs for this issue: Affects: epel-7 [bug 1780513]
This CVE Bugzilla entry is for community support informational purposes only as it does not affect a package in a commercially supported Red Hat product. Refer to the dependent bugs for status of those individual community products.