'named' can trigger an assertion failure in adb.c due to bad fetch-quota-params
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
- configure it with:
fetch-quota-params 1 2 3 2;
forwarders { 8.8.8.8; }; // any forwarder should be okay
forward only;- start named
- dig www.isc.org
- dig ftp.isc.org
- 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.