[dns-operations] CVE 2015-8000 actively exploited yesterday

[Paul Vixie]

On Thursday, December 17, 2015 06:28:42 AM Jean-Yves Bisiaux wrote:
> 2015-12-17 0:50 GMT+01:00 Nick Urbanik <nick.urbanik at optusnet.com.au>:
> > BIND really needs to have a better strategy to dealing with unexpected
> > input other than by dying.
> 
> As you probably know, this REQUIRE check is a protection to prevent code
> execution on states interpretation that was not foresee by the code. And
> fortunately, ISC developers wisely take time to put these REQUIRE points in
> the BIND code to keep the algorithm integrity. Excepted to make sure to
> cover all state combinations (not reachable for human now) I don't see
> other option.

i had very little input on the design and architecture of bind9, and none of the code is mine. 
however, after 10 years of maintaining bind4 and rewriting bind4 into bind8 and then 
maintaining bind8, i knew one thing for sure, which i made into an unbreakable law for the 
bind9 team: no remote code execution errors. robert halley then offered an eiffel-styled 
assertion syntax, which was then used everywhere: function entry, function exit, plus 
anywhere else it would fit.

"dealing with unexpected input other than by dying" is hard, since by the time one of these 
assertions is triggered, all the bind9 program knows is that there is a bug somewhere else, 
earlier on the input path, that allowed a bad collection of state variables to accumulate. there 
is no recourse at that point other than to restart the program. "ignore the current packet and 
go back to the main input service loop" is not an option.

i'd like to see bind9 able to call execve() on itself, so that it did not have to live inside a nanny 
script. from an outsider's point of view (that of a sysadmin or remote user) the name server 
should never stop unless told to. i last tried this (successfully) on another name server, in 
2003 or so, and i found that by fork()'ing a copy of myself, then execve()'ing myself and having 
my replacement process use the same file descriptors i was using rather than opening new 
sockets, the replacement process could eventually kill() the forked child. no missed queries. 
total outage time, 50ms. and, same pid!

-- 
P Vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20151216/2f93707a/attachment-0001.html>