Reporting security issue
If you wish to report a possible security issue please either fill an issue and please make sure you tick the checkbox labeled "This issue is confidential and should only be visible to team members with at least Reporter access.", or by emailing to firstname.lastname@example.org. If you want to encrypt the email, you can use the ISC Security Officer's Public Key.
Notifications are received by the BIND Engineering Team members. We engage resources within ISC to start the investigation and prioritisation.
We will determine the risk of each issue, taking into account our experience dealing with past issues, versions affected, common defaults, and use cases. We use Common Vulnerability Scoring System v3.0 to assess the severity of the security vulnerability as a rough guide for the vulnerability classification.
We use the following severity categories:
- CRITICAL Severity (CVSS Score 9.0 - 10.0). This affects common configurations and which are also likely to be exploitable. Examples include significant disclosure of the contents of server memory (potentially revealing user details), vulnerabilities which can be easily exploited remotely to compromise server or where remote code execution is considered likely in common situations. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to address these as soon as possible.
- HIGH Severity (CVSS Score 7.0 - 8.9). This includes issues that are of a lower risk than critical, perhaps due to affecting less common configurations, or which are less likely to be exploitable. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to keep the time these issues are private to a minimum; our aim would be no longer than a month where this is something under our control.
- MEDIUM Severity (CVSS Score 4.0 - 6.9). This includes issues like crashes in client applications, flaws in protocols that are less commonly used, and local flaws. These will in general be kept private until the next release, and that release will be scheduled so that it can roll up several such flaws at one time.
- LOW Severity (CVSS Score 0.1 - 3.9). This includes issues such as those that only affect the BIND 9 command line utility, unlikely configurations, or hard to exploit attacks. These will in general be fixed immediately in latest development versions, and may be backported to older versions that are still getting updates. We will update the vulnerabilities page and note the issue CVE in the changelog and commit message, but they may not trigger new releases.
Where we are planning an update that fixes security issues we will use the procedure described in ISC Software Defect and Security Vulnerability Disclosure Policy.
This section describes the preferred ways of handling the security issues for the BIND Engineering Team.
The GitLab issues that describes security problem in the BIND code MUST be marked as Confidential.
This means that either the original submitter would mark the issue as confidential, or when anybody from the team finds out this might a security issue, he or she would be mark the issue as confidential.
The issue title MUST be changed to begin with [CVE-YYYY-NNNNN] when the CVE number is assigned by Security Officer or other party.
The work on CRITICAL-MEDIUM priority issues MUST be commenced in a private git repository that is open only to the BIND Team members. The Merge Requests for CRITICAL-MEDIUM priority issues MUST NOT be merged until prior to the release.
After fixed versions of BIND are released to the general public, the issue describing a security vulnerability is made public for a full disclosure. We at ISC believe that transparency is valuable in open-source projects.