|Summary:||bind-chroot directory permissions allow inappropriate write access for the named user.|
|Product:||[Fedora] Fedora||Reporter:||Ralph Durkee <ralph>|
|Component:||bind||Assignee:||Jason Vas Dias <jvdias>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Ben Levenson <benl>|
|Fixed In Version:||bind-9.3.1-14_FC4||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-12-20 21:18:11 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
|Bug Blocks:||170359, 170360|
Description Ralph Durkee 2005-09-07 01:28:37 UTC
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 21:18:11 UTC
This bug was fixed a while ago with 9.3.1-12.FC4 - closing out.
Comment 2 Aleksandar Milivojevic 2006-02-20 16:07:54 UTC
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 16:29:10 UTC
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 17:17:08 UTC
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.