![]() ![]() ISC has a formal process for handling reports of security bugs. 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. When writing BIND 9, the authors were very mindful of security.Īlthough 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 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. 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. To catch programming errors that could lead to such a compromise, BIND was created using a “design by contract” paradigm. In this approach, assertions are made throughout the code as to the state of variables at certain points. If these are violated, BIND will do a controlled termination rather than continuing with possibly corrupted data. There are thousands of such assertions scattered throughout the BIND source code. 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. 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. 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. empty), and included an assertion to that effect. ![]() 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. 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. Should this be the case, overwriting the variable might lead to invalid data being used and a possible compromise. In this particular case the variable had been set to NULL and the function called.įor this reason, BIND was written to terminate should that state of affairs occur. 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. The error lay in the fact that the variable was not reset to NULL before the second call. 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. ![]()
0 Comments
Leave a Reply. |