GitLab

I believe this issue does not contain a practically exploitable DoS vector but at least initially am creating the ticket as confidential to give others a chance to comment otherwise if I am missing something.

It's another submission from an ISC Support Customer, who has identified a reachable assertion failure in 9.11.3-S2

Summary

'named' as of BIND-9.11.3-S2 can be crashed by triggering an assertion failure on line 4265 of adb.c: INSIST(adb->atr_discount <= 1.0);

Steps to reproduce

1. configure it with:

fetch-quota-params 1 2 3 2;
forwarders { 8.8.8.8; }; // any forwarder should be okay
forward only;

2. start named
3. dig www.isc.org
4. dig ftp.isc.org
5. dig isc.org

What is the current bug behavior?

Per customer's description:

The critical part is the 'fetch-quota-params'. The 'discount' parameter is set to 2.0 (=2*100/100.0) and passed to dns_adb_setquota() and stored in 'adb->atr_discount'. There's no validation in this process, so it already violates the assumption of the INSIST and should be considered a kind of defect; the above steps just demonstrate that the defect can actually cause a crash.

Possible fixes

One way to prevent this would be add a range check in server:configure_view(). It would be more user-friendly to do this and emit a log message reporting exactly what's wrong. But I also think dns_adb_setquota() should also perform its own validation, since allowing an 'adb' instance to have an invalid value that can cause a crash wouldn't be good in terms of module integrity.

I'd also suggest validating 'low' and 'high' since values for these outside of the [0, 1.0] range have no sense (and quite likely to be a configuration error). I'm not sure if an invalid value for these parameters can cause a crash, but even if not it would be helpful for a user to reject them explicitly as a configuration error.