Bug 167682 - bind-chroot directory permissions allow inappropriate write access for the named user.
bind-chroot directory permissions allow inappropriate write access for the na...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Ben Levenson
NA
: Security
Depends On:
Blocks: 170359 170360
  Show dependency treegraph
 
Reported: 2005-09-06 21:28 EDT by Ralph Durkee
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: bind-9.3.1-14_FC4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-20 16:18:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ralph Durkee 2005-09-06 21:28:37 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Description of problem:
The default directory permission for bind-chroot rpm should not allow group write access for the named group for the following directories.

chmod g-w /var/named/chroot/
chmod g-w /var/named/chroot/var
chmod g-w /var/named/chroot/etc
chmod g-w /var/named/chroot/dev

Allowing write access for "named" to these directories would allow an exploit of the named server to rename and recreate files and directories, which would effectively provide write access to named configuration files, and the master zone files.

Of course administrators can fix the permissions themselves, however it would be best of a secure by default configuration would be provided. Other subdirectories such as var/run/named are expected to be writable, of coure, but the top level directories muct not be writable. 

I'm working a security benchmark for BIND with the Center for Internet Security, which will be published soon. If there is going to be a fix for this it would be helpful to include a mention of it in the document. 

Thank you!

Ralph Durkee, CISSP, GSEC, GCIH
Principal Consultant
USA 585-624-9551
http://rd1.net

Version-Release number of selected component (if applicable):
bind-chroot-9.3.1-10_FC4

How reproducible:
Always

Steps to Reproduce:
1.yum install bind-chroot
2.ls -al /var/named/chroot/
3.
  

Actual Results:  # ls -al /var/named/chroot/
total 40
drwxrwx---   6 root named 4096 Aug 22 16:33 .
drwxr-x---   5 root named 4096 Sep  6 21:09 ..
drwxrwxr--   2 root named 4096 Sep  6 21:09 dev
drwxrwx---   2 root named 4096 Sep  6 21:09 etc
dr-xr-xr-x  64 root root     0 Sep  1 14:39 proc
drwxrwx---   5 root named 4096 Sep  6 21:09 var


Expected Results:  # ls -al /var/named/chroot/
total 40
drwxr-x---   6 root named 4096 Aug 22 16:33 .
drwxr-x---   5 root named 4096 Sep  6 21:09 ..
drwxr-xr--   2 root named 4096 Sep  6 21:09 dev
drwxr-x---   2 root named 4096 Sep  6 21:09 etc
dr-xr-xr-x  64 root root     0 Sep  1 14:39 proc
drwxr-x---   5 root named 4096 Sep  6 21:09 var


Additional info:
Comment 1 Jason Vas Dias 2005-12-20 16:18:11 EST
This bug was fixed a while ago with 9.3.1-12.FC4 - closing out.
Comment 2 Aleksandar Milivojevic 2006-02-20 11:07:54 EST
Has this bug been fixed for RHEL4 too?  If not, this bug should be reopened.

The current bind-chroot package (9.2.4-2) seems to still have wrong permissions.

I'll add couple of observations not present in original bug report.

Discovery of any flaw in bind could lead to potential access to any file on
disk.  Attacker can create any device node and access file systems outside of
chroot jail (since there are writtable directories in chroot jail).  The
complete fix would be mounting /var with nodev option, mounting
/var/named/chroot/dev as tmpfs, and creating device nodes from init.d/named.

In addition to permissions, the ownerships are wrong too.  In /var/named/chroot,
the chroot itself, etc, dev and var directories should be owned by root:root,
not by root:named (all files and directories should reflect ownerships and
permissions of "real" directories and files outside of chroot jail.

I don't know if there is new bind package in the making for update 3.  However
since this is security related problem, I guess an update is in order even
before update 3 is to be released.
Comment 3 Bob Johnson 2006-04-11 12:29:10 EDT
This issue is on Red Hat Engineering's list of planned work items 
for the upcoming Red Hat Enterprise Linux 3.8 release.  Engineering 
resources have been assigned and barring unforeseen circumstances, Red 
Hat intends to include this item in the 3.8 release.
Comment 4 Bob Johnson 2006-04-11 13:17:08 EDT
This issue is on Red Hat Engineering's list of planned work items 
for the upcoming Red Hat Enterprise Linux 4.4 release.  Engineering 
resources have been assigned and barring unforeseen circumstances, Red 
Hat intends to include this item in the 4.4 release.

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