Kea 2.0 - Performance, Stability and Security
We are very proud to announce that we have just posted a new stable branch of Kea, Kea 2.Read post
On February 16th, news reached ISC about CVE-2015-7547, a serious defect in the getaddrinfo() library call in glibc. This defect allows an attacker to cause buffer overflow to occur, creating the possibility of remote code execution in some circumstances. ISC has been asked by several of our customers and partners to comment on whether this vulnerability should be of concern to operators using our products.
As general advice
Of course this should be of concern to anyone operating a system which uses glibc. A common system call containing a bug which potentially permits remote code execution calls for immediate patching and the best solution is to immediately seek a patched version of glibc which has been secured to prevent this vulnerability.
Speaking specifically about ISC’s products and their exposure
In response to requests from our customers, we have examined our BIND, ISC DHCP, and Kea products to assess the risk this vulnerability poses to customers using those products to provide services.
Static and dynamic linking
On most systems, programs which are built as part of the ISC products are configured to be dynamically linked, making use of system libraries which are found at runtime. However, it is possible to deliberately build statically linked binaries in which library routines are incorporated into the binary images produced at compile time. If you have built statically linked versions of ISC programs you must fix your system library first and then rebuild and relink the ISC products to ensure that you are now using the corrected library. Most users, however, are using dynamically linked libraries (which are the default build option) and need only fix their libraries and then stop and restart the ISC product – re-linking is not usually necessary for those who have built using the default options.
The CVE-2015-7547 announcement contains, as do a number of additional articles which are circulating concerning the vulnerability, a list of recommended countermeasures intended to prevent successful exploitation of the defect. Among the recommendations are such proposed countermeasures as blocking UDP packets that are larger than 512 bytes, limiting the permitted size of TCP replies, and discouraging the use of EDNS0. ISC would like to advise customers that we recommend caution when applying such measures as they can interfere with DNS operations, causing problems of their own.
Responses that require more than 512 bytes are legal and normal in DNS and proper EDNS0 operation is important for DNSSEC validation and other critical DNS functionality.
We continue to recommend that the best course of action is to replace the vulnerable library on affected systems but if you must, for some reason, adopt any of the countermeasures we counsel closely monitoring your DNS for signs of problems which may be created or exacerbated by the specified measures.
What's New from ISC