BIND 9 Security Audit
In the aftermath of yesterday’s BIND announcement of seven new CVEs, one of them with a fairly wide impact, BIND users might be wondering why ISC publishes so many security vulnerabilities.Read post
Update: to access the bug database, go to bugs.isc.org, click on the Guest login, and select “bug-list” for either DHCP or BIND 9.
I know what you are thinking.
Every other open source project has had an open bug database for years. What took ISC so long?
First of all, our issue tracker software did not have a “Guest” access feature. We use Request Tracker from Best Practical. It is open source and otherwise meets our needs perfectly. We did spend a couple of years talking about migrating to JIRA, but that is a big project and we didn’t see the payback. Recently we noticed that the CPAN project was using RT and they had some kind of Guest access, so we asked Best Practical to port the module for Guest access to the software version we are using. They were great to work with, and recently delivered the patch. The feature enables us to create a new “public access” ticket queue which is viewable by anonymous guest users.
We do not have any verified, undisclosed security vulnerabilities in our issue tracker.
However, it is possible that someone could mine old crash reports, find something that was never reproduced, or otherwise extrapolate from a bug report and find a vulnerability we missed. We put a LOT of effort into prompt and responsible disclosure of vulnerabilities and we certainly don’t want to inadvertently publish something that could be used against our users. This is why we feel we need to review any previously-reported, unresolved issues before publishing them.
We are also concerned about privacy. Some of our staff have told people posting on our public lists that they could email to our issue tracker if they needed a confidential exchange. Many people have sent in configurations, crash dumps, or explicit information about their network that they understood at the time would not be published. We have to respect past commitments we or former ISC employees may have made.
It is much easier to have an open bug database if you start out that way. At this point, ISC has accumulated 17 years’ worth of embarrassing comments, ToDo list items, unverified and abandoned bug reports, and possible user confidential information in our issue tracker. For example, we have over 7,000 resolved BIND issues, over 800 rejected BIND issues, and several hundred open issues, most of which were created by ISC employees. This is simply much more than we can possibly review or curate at this point.
We don’t have the time to review all these existing issues for publication, but we have decided we aren’t letting that get in the way of opening the bug database.
The solution we have decided upon is to open up the issue tracker for new public reports, by default.
If you submit a bug to firstname.lastname@example.org or email@example.com, or via our web bug report form after July 7th, we will triage it and put it into the open, viewable bugs queue - unless you specifically ask us not to, or it looks like it could be a security vulnerability. In the latter case, we will keep it in a non-public queue. Newly submitted suggestions sent to bind-suggest or firstname.lastname@example.org will go straight into a publicly-viewable queue without triage.
Note that when you submit an issue your email address and any attachments will also be visible. This is why we are announcing this change early - so that we have plenty of time to get the word out to submitters.
ISC employees create most of the issues in our issue tracker. Our development team opens issues for feature development (or any code commit), and to keep track of ideas for future work. Issues can also be opened automatically (e.g. by Coverity, which is scanning for possible regressions), or by our technical support team, reporting a problem on behalf of a support customer. We will obviously not be publishing any specific data provided by ISC support customers, but otherwise, we will try to be open about as many of our own issues as possible.
We are still working on installing and configuring the new software, and re-testing it, to get it ready for July 7th. We are looking forward to sharing this information with our users and technical contributors.
We don’t want to discourage anyone from sending in bug reports, so if you have any concerns about your privacy, just mention in the body of your report, whether you submit it via email or the web, that you prefer that we keep your report confidential, and we will. Every bug report is read by one of our engineers and triaged, so we can simply put your issue into the non-public queue.
What's New from ISC