BIND Version checker/reporter
ISC needs some general idea how many instances of BIND are running which software versions. We frequently have to guesstimate this in order to assess the relative impact of a bug or vulnerability on our user base. We do not have any useful information from downloads, because our open source is published on so many sites, including many we do not control. Having this information would enable us to make better decisions about how many installations might be impacted and about what sort of fix is appropriate.
At the same time, we also need some mechanism to alert users who are running software that is EOL or subject to a known, published CVE. We should be able to provide unobtrusive but visible feedback to the operator when that is detected.
Users are wary of any feature that reports software information that could be used to identify and target them, or that carries any potential for side-channel data leakage. We must make it very transparent exactly what information is sent and what information we retain. Some users will wish to disable whatever version checker we implement, and we should make it easy to do so. However, if we do not enable this feature by default, it is unlikely that we will get enough data to be useful.
- We need a utility that will periodically (define) contact some system at ISC and report what BIND version it is running and check to see if that is a supported version clear of published CVEs.
- The message or lookup from the version checker should consume a very modest amount of bandwidth. UDP should be adequate, retries and failure messages are not indicated if the lookup fails or is blocked. We want to be careful not to create a DDOS on the server.
- The version checker does not need to check frequently - a period of daily might be ok and might be easiest to implement, weekly is adequate however.
- The version checker should be enabled by default.
- We might have one check that happens on startup and an identifiably different check that happens say, weekly after that. This is to address the issue of test systems, ephemeral dockers biasing the statistics.
- TBD. It might be useful to initiate the 'ongoing' checker only when some level of regular query traffic is reached, to eliminate systems that are unused or 'toy' systems, again to reduce those systems biasing the statistics. The problem is that some of these systems we might regard as 'toy' systems could still be important to their users and we would be denying them the benefit of the alerts that their system is compromised. Also, some systems with a lot of query traffic could simply be, e.g. unmanaged open resolvers that are pounded with abuse traffic.
- It must be relatively easy to disable the version checker. It should be possible to disable it without rebuilding the image and without restarting the daemon.
- Some operating system packagers are going to want to disable the version checker, or possibly to 'redirect' it to check some facility of their own. This should not be unnecessarily difficult for them to do.
- This feature should be added to the development branch of BIND.
- It is TBD whether we should backport it to the most recent stable branch.
The version checker should insert a log message in the configured default bind logging facility if the running version is EOL or if it is subject to a known published CVE.
- The log message should state the CVE status (clear, vulnerable, EOL, unrecognized version)
- **TBD. **If there is adequate room, this message could provide any of the following
- the date of the planned EOL for this version
- a link to get more information
- a link to download a new version
- a link to the vulnerability report
- a link to the CVE matrix
depending on what is feasible and reasonable given the space available.
- TBD whether the log message should be at the Warning level or the Informational level
- TBD whether the version checker should log that it ran, and checked the version and the response is ok. Some users might want this, but since it is not very useful and adds more chaff to the log, if it is logged it should be at a low level, info or debug.
Version Status Responder
- ISC should stand up a system that the version checker can check
- The responder should be identified by a FQDN. We will have to maintain this facility for a long time, and using a FQDN will make it easier for packagers to substitute their own responder if they choose.
- The responder should have information on known BIND versions with support status and CVE status.
- It should be possible for anyone who can publish a BIND CVE or post a BIND release to add or edit the known versions, CVE status and support status so we can easily keep this up to date, given we are releasing multiple new versions monthly.
- The responder should log the time and version number the checker looks up, but it should not log the IP address the requests comes from or.... anything else.
- TBD. How can we effectively identify package versions where the BIND version does not map to the ISC releases, such as when a packager backports CVE fixes?
- TBD Should we make the census information public?