This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 419421 - (CVE-2007-6283) CVE-2007-6283 bind: /etc/rndc.key has 644 permissions by default
CVE-2007-6283 bind: /etc/rndc.key has 644 permissions by default
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Tkac
impact=moderate,reported=20071211,pub...
: Reopened, Security
Depends On: 423061 423071 423081 423091 429536
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-11 04:40 EST by Denise Dumas
Modified: 2013-04-30 19:37 EDT (History)
5 users (show)

See Also:
Fixed In Version: 9.5.0-20.b1.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-21 05:46:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch (1.50 KB, patch)
2007-12-19 10:55 EST, Adam Tkac
no flags Details | Diff
previous patch has typo (1.50 KB, patch)
2007-12-19 11:06 EST, Adam Tkac
no flags Details | Diff

  None (edit)
Description Florian La Roche 2007-12-11 04:40:22 EST
Description of problem:

/etc/rndc.key is readable for all, so any user can issue named commands
like "rndc stop" to shut named down or other things.

/usr/sbin/rndc is not readable for all users, but we usually then don't
restrict the binary in this way, but keep the binary openly available.
(Does not really count to the above mentioned item, but might be something
to look at for testing purposes.)

regards,

Florian La Roche



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Mark J. Cox (Product Security) 2007-12-11 05:56:43 EST
Confirmed, on a test RHEL5 system without bind-chroot, /etc/rndc.conf is mode 644
Comment 2 Adam Tkac 2007-12-11 07:08:09 EST
Thanks for report. This is pretty bad issue. Anyone could control server with
self-compiled rndc (to bypass 750 rndc perms). I think this should be clone to
z-stream
Comment 3 Tomas Hoger 2007-12-11 07:20:36 EST
This problem only affects bind packages as shipped in Red Hat Enterprise Linux 5
and Fedora.  If only affects system without recommended bind-chroot package
installed, which reconfigures bind to run chrooted in /var/named/chroot
directory.  /var/named/chroot has correct permissions by default (root:named, 750).

Version of bind as shipped with Red Hat Enterprise Linux 2.1, 3, and 4 create
rndc.conf file with sane permissions by default (root:named, 640).

Possible impact - any user with access to system running bind can perform
following actions using rndc:
- stop named
- change logging level of daemon by setting too low (malicious activity will not
  appear in the log) or too high (high disk usage due to lots of debug messages
  being logged) log level value
- request configuration or zone file reload (contents of file is not controlled
  by unprivileged user)
- disable updates of dynamic zone

rndc installed without read and execute permission for other users does not
provide sufficient protection, as described by reporter.
Comment 4 Tomas Hoger 2007-12-11 08:38:02 EST
Possible workarounds for affected systems:

- Manually fix permissions of rndc.key file:

  chmod 640 /etc/rndc.key
  chown root:named /etc/rndc.key

OR

- Install bind-chroot package and run bind chrooted in /var/named/chroot
Comment 5 Florian La Roche 2007-12-11 08:42:14 EST
Since the key could be stolen maybe a new key should get generated for
existing rndc.key files?

regards,

Florian La Roche
Comment 6 Tomas Hoger 2007-12-11 09:03:42 EST
(In reply to comment #5)
> Since the key could be stolen maybe a new key should get generated for
> existing rndc.key files?

If it's possible that rndc key was compromised in the meantime, new one can be
generated using /usr/sbin/dns-keygen .  New key printed on standard output
should be used in rndc.key file as new value for secret keyword and named has to
be restarted / reload for the change to take effect.

Example:
# /usr/sbin/dns-keygen
we2sIj37XBlBC0FslnmOhjVNCx3M4KbAOUpRxYndd7gdRra7ZZ5qdqwmCDVL

Line with "secret" keyword in rndc.conf should be changed to:

  secret "we2sIj37XBlBC0FslnmOhjVNCx3M4KbAOUpRxYndd7gdRra7ZZ5qdqwmCDVL";

Florian, thanks for reminding that.
Comment 8 ivo 2007-12-18 04:57:46 EST
(In reply to comment #3)
> This problem only affects bind packages as shipped in Red Hat Enterprise Linux 5
> and Fedora.

Please report the affected distribution versions of Fedora. Thank you.
Comment 9 Tomas Hoger 2007-12-18 05:10:50 EST
(In reply to comment #8)
> (In reply to comment #3)
> > This problem only affects bind packages as shipped in Red Hat Enterprise 
> > Linux 5 and Fedora.
> 
> Please report the affected distribution versions of Fedora. Thank you.

Sorry, no specific versions were listed as bind packages in all currently
supported Fedora versions (7, 8 and rawhide) were affected by this issue.

Please follow instructions in comment #4 and comment #6 if your configuration is
affected and this issue may cause problems in your environment.
Comment 10 Adam Tkac 2007-12-19 10:55:11 EST
Created attachment 290037 [details]
patch
Comment 11 Adam Tkac 2007-12-19 10:57:36 EST
(In reply to comment #10)
> Created an attachment (id=290037) [edit]
> patch
> 
From F8 branch, other distributions will have appropriate version in trigger.
Comment 12 Adam Tkac 2007-12-19 11:06:44 EST
Created attachment 290038 [details]
previous patch has typo
Comment 13 Fedora Update System 2007-12-20 14:49:20 EST
bind-9.5.0-20.b1.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 16 Vladislav Bogdanov 2008-02-01 10:26:51 EST
Just my 2 cents.
After fixing permissions on /etc/rndc.conf, /usr/sbin/rndc could be freely
installed as root:root 0755 (or as root:named 0750), so any administrator (or
some kind of automated script or daemon, f.e. ldap2dnsd, that is running as the
user in the 'named' group) who has been added to the 'named' group will be able
reload nameserver.

Regards,
Vladislav Bogdanov.
Comment 19 Red Hat Product Security 2008-07-21 05:46:54 EDT
This issue was addressed in:

Red Hat Enterprise Linux:
  http://rhn.redhat.com/errata/RHSA-2008-0300.html

Fedora:
  https://admin.fedoraproject.org/updates/F8/FEDORA-2007-4655


Note You need to log in before you can comment on or make changes to this bug.