- #Bind to blueservice failed Patch#
- #Bind to blueservice failed software#
- #Bind to blueservice failed code#
As there was no way for BIND to tell that the content of the variable was pointing to discarded data, as opposed to valid data, BIND took the safer course and terminated. The error lay in the fact that the variable was not reset to NULL before the second call. However, a corner case (which amazingly, seems never to have been reached in 15 years of use) required the returned data to be discarded and the function called a second time. In this particular case the variable had been set to NULL and the function called. For this reason, BIND was written to terminate should that state of affairs occur. Should this be the case, overwriting the variable might lead to invalid data being used and a possible compromise. Passing a non-NULL variable to the function might indicate that the programmer had made a mistake and that the variable was already pointing to valid data. The reasoning for this was that in order to use the function, the programmer should be aware that the contents of the variable will be modified, and should signal that awareness by ensuring that it was NULL before calling the function. empty), and included an assertion to that effect. Here, a function in BIND required that the variable into which it was going to place a pointer to data should be NULL (i.e. Instead, assertions are made about the way the program is operating.Ī good example of this is the problem (CVE-2015-5477) that resulted in the release of BIND versions 9.9.7-P2 and 9.10.2-P3 in July 2015.
Note that the assertions are not concerned with the data received by BIND (either in the form of DNS requests or responses) - BIND has no control over that. There are thousands of such assertions scattered throughout the BIND source code. If these are violated, BIND will do a controlled termination rather than continuing with possibly corrupted data.
#Bind to blueservice failed code#
In this approach, assertions are made throughout the code as to the state of variables at certain points. To catch programming errors that could lead to such a compromise, BIND was created using a “design by contract” paradigm. A flaw that allowed an attacker to control the information returned in response to queries opens the way for fraudulent and illegal activities process termination, although a denial of service, was judged to be less harmful. They considered a security hole that allows a compromise of the machine on which the name server is running (for example, by allowing remote code execution) to be worse than one that causes the program to exit. When writing BIND 9, the authors were very mindful of security.
Although underlying reasons can be different, many of these advisories report the cause as the issue “triggering an assertion in BIND, after which BIND exits.” So what are assertions, and why do they cause BIND to crash?
#Bind to blueservice failed software#
If we think the reported issue is serious enough, we will issue a release of the software containing the fix, and a security advisory explaining the problem. ISC has a formal process for handling reports of security bugs.
#Bind to blueservice failed Patch#
With the recent spate of patch releases of BIND due to security issues, I thought that it was worth putting fingers to keyboard to shed some light on the sources of these problems and what ISC is doing about them.