W.C.A. Wijngaards
2014-12-08 16:00:12 UTC
The CVE number for this vulnerability is CVE-2014-8602.
== Summary
The resolver can be tricked into following an endless series of
delegations, this consumes a lot of resources. A patch is available
that limits the number of fetches performed for a query.
== Description
Resolvers fetch the content for domain names by sending queries to
authority servers on the internet. One of the responses that authority
servers can return is a referral response, which points to further
servers to continue the lookup. To continue the lookup, resolvers
may have to perform recursion, where new names, called glue, from the
referral response have to be looked up to continue the query resolution.
The issue here is a lack of limiting on the recursion fetches performed
to figure out a particular query. The authority server is a special
set-up that responds with an infinite amount of glue. This then causes
the resolver to spend a lot of resources diving into the infinite glue
looking up names, only find out it needs to look up even more names.
== Impact
The impact for unbound is fairly low, combined with a tricky to
exploit vulnerability. The packet rate, however, can be fairly high.
The exploit needs a lot specific glue setup on the authority server,
or even a special-purpose trick-authority-server. A trigger query
has to be sent to unbound. Unbound will spend a lot of resources on
this query, and this will impact unbound's cpu and network resources.
Unbound may therefore lose some ability or timeliness for the service
of customer queries (a denial of service). Unbound will continue to
respond normally for cached queries.
== Remote Exploit
This is not a remote code execution exploit, this vulnerability consumes
CPU and network resources.
== Remedy
A very simple workaround is to ignore the problem and let existing
anti-DoS systems in unbound deal with the issue. It will consume a lot
of resources, but other customers will (most likely) continue to get
service.
If affected, unbound-control flush_requestlist provides temporary
relief, but the issue could resume (immediately). Putting the
maliciously sent query in local-data, or using access-control to block
the malicious query sending IP would workaround that exploit set-up.
The config statement do-not-query-address: IPorNetblock can be used to
block a specific authority server.
The proper fix is a patch, which is available:
http://unbound.net/downloads/patch_cve_2014_8602.diff
== Solution
The solution is a code patch, apply this patch with
patch -p0 < the_patch_file. Then recompile and install unbound.
== Acknowledgement
Florian Maury (ANSSI)
== Summary
The resolver can be tricked into following an endless series of
delegations, this consumes a lot of resources. A patch is available
that limits the number of fetches performed for a query.
== Description
Resolvers fetch the content for domain names by sending queries to
authority servers on the internet. One of the responses that authority
servers can return is a referral response, which points to further
servers to continue the lookup. To continue the lookup, resolvers
may have to perform recursion, where new names, called glue, from the
referral response have to be looked up to continue the query resolution.
The issue here is a lack of limiting on the recursion fetches performed
to figure out a particular query. The authority server is a special
set-up that responds with an infinite amount of glue. This then causes
the resolver to spend a lot of resources diving into the infinite glue
looking up names, only find out it needs to look up even more names.
== Impact
The impact for unbound is fairly low, combined with a tricky to
exploit vulnerability. The packet rate, however, can be fairly high.
The exploit needs a lot specific glue setup on the authority server,
or even a special-purpose trick-authority-server. A trigger query
has to be sent to unbound. Unbound will spend a lot of resources on
this query, and this will impact unbound's cpu and network resources.
Unbound may therefore lose some ability or timeliness for the service
of customer queries (a denial of service). Unbound will continue to
respond normally for cached queries.
== Remote Exploit
This is not a remote code execution exploit, this vulnerability consumes
CPU and network resources.
== Remedy
A very simple workaround is to ignore the problem and let existing
anti-DoS systems in unbound deal with the issue. It will consume a lot
of resources, but other customers will (most likely) continue to get
service.
If affected, unbound-control flush_requestlist provides temporary
relief, but the issue could resume (immediately). Putting the
maliciously sent query in local-data, or using access-control to block
the malicious query sending IP would workaround that exploit set-up.
The config statement do-not-query-address: IPorNetblock can be used to
block a specific authority server.
The proper fix is a patch, which is available:
http://unbound.net/downloads/patch_cve_2014_8602.diff
== Solution
The solution is a code patch, apply this patch with
patch -p0 < the_patch_file. Then recompile and install unbound.
== Acknowledgement
Florian Maury (ANSSI)