Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 528
    • Issues 528
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 95
    • Merge requests 95
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source Projects
  • BINDBIND
  • Issues
  • #362
Closed
Open
Created Jun 25, 2018 by Michael McNally@McNally

'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

  1. configure it with:
fetch-quota-params 1 2 3 2;
forwarders { 8.8.8.8; }; // any forwarder should be okay
forward only;
  1. start named
  2. dig www.isc.org
  3. dig ftp.isc.org
  4. 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.

Edited Dec 04, 2018 by Ondřej Surý
Assignee
Assign to
Time tracking