Security issue

[Kevin Darcy]

David Forrest wrote:
> On Wed, 29 Oct 2008, Chris Buxton wrote:
>
>   
>> On Oct 29, 2008, at 10:59 AM, David Forrest wrote:
>>     
>>> Currently /etc/update-keys has mode 600, which, because dhcpd runs as 
>>> root appears to do the same as using a common group. I am just 
>>> considering what havoc could result from a hacked named by allowing the 
>>> rogue user named to read the secret and poison an internal view zone 
>>> file.  I do not use nsupdate on my external view zones as they haven't 
>>> changed in years and I can put up with the [rndc freeze; vi <zone>; 
>>> rndc thaw] procedure. I'm thinking the hacker could not do much as user 
>>> named with nsupdate anyway but just asking, "Is it wise?"
>>>       
>> Your name server needs to be able to read the keys. Period. You can't
>> avoid this, other than not using keys (not recommended).
>>
>> It's true that an attacker who broke in through the named process
>> could then read the keys and perform mischief thereafter with your
>> zone data. The only thing you can do to mitigate this beyond running a
>> current version of named is to try to stop someone from breaking in
>> through named. That means using hardening tools such as an intrusion
>> prevention system (IPS), a mandatory access control system (MAC), and
>> hardening compiler tools when building named (including enabling PIC
>> in the ./configure step).
>>
>> However, named itself is pretty secure, and there haven't been many
>> code-execution exploits in recent years. That isn't to say one won't
>> be discovered and exploited before you have a chance to update, only
>> that it isn't a common occurrence.
>>
>> Chris Buxton
>> Professional Services
>> Men & Mice
>>     
>
> I understand.  I went to using the update-keys file to avoid putting 
> the key in plaintext in named.conf.  I thought bind read the conf file 
> before it dropped root privileges and changed to the user with the -u 
> option.  It seems that reading it after becoming an unprivileged user 
> negates some of the advantages of keeping the key secret.
You can make the key file readable only by the unprivileged user under 
which named runs, and then emasculate the loginid (lock the password, 
assign it a non-existent shell, etc.). Not all of the security eggs need 
be placed in the superuser basket.

In any case, if someone breaks into your named, chances are they can 
modify the DNS data directly, and wouldn't even need the update key.

- Kevin