[nsd-users] nsd as bind slave (xfer problem)

[Greg A. Woods; Planix, Inc.]

On 17-Feb-2009, at 3:58 AM, Matthijs Mekking wrote:
>
> The reason for this is, is that it is required to re-read the
> configuration file. The decision was to not read the configuration  
> file
> while running in order to minimalize security vulnerabilities.

While I don't see any really pressing need to change this behaviour, I  
would be interested to learn of any real threats that have been  
identified here and what risk has been estimated.

The worst I can think is that even if nsd is running chrooted then an  
attacker could still easily force it to load an entirely different  
configuration.  However I suspect the _additional_ risk there is  
rather low so long as all the code to read and parse said  
configuration remains in executable memory.  Even then the additional  
risk is still relatively low since if the attacker can change  
executable memory enough (and perhaps more than once) then anything's  
possible.

The real question would be what could be gained by such a complex and  
more difficult attack -- if the attacker can alter the running code  
sufficiently, and their goal is to have the compromised program  
continue to answer DNS queries, then they can make it answer with  
anything they want without first having to find write-able filesystem  
space in which to store the new configuration and zone files and then  
having to make it jump through hoops to read those new files files.

-- 
					Greg A. Woods; Planix, Inc.
					<woods at planix.ca>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20090217/cb27aabb/attachment.bin>