[dns-operations] CVE 2015-8000 actively exploited yesterday
paul at redbarn.org
Thu Dec 17 05:50:27 UTC 2015
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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dns-operations