Bug 449089 (CVE-2008-2544) - CVE-2008-2544 kernel: mounting proc readonly on a different mount point silently mounts it rw if the /proc mount is rw
Summary: CVE-2008-2544 kernel: mounting proc readonly on a different mount point silen...
Alias: CVE-2008-2544
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 455686
Blocks: 213135
TreeView+ depends on / blocked
Reported: 2008-05-30 11:24 UTC by Jan Lieskovsky
Modified: 2019-09-29 12:24 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-04-17 05:02:52 UTC

Attachments (Terms of Use)

Description Jan Lieskovsky 2008-05-30 11:24:39 UTC
Description of problem:

Martin Cracaucer (more info in BZ#213135) has reported the following

Mounting /proc filesystem via chroot command silently mounts it in readwrite
mode. See Steps To Reproduce command for more details.


The user could bypass the chroot environment and gain write access to
files, he would never have otherwise.

Affected kernel versions:

2.6.24.+ kernels as released in the Fedora distro (the case of
is sane).

Comment 1 Jan Lieskovsky 2008-05-30 11:42:09 UTC
Steps To Reproduce:

1, Create chroot environment for unprivileged user (have used that one
provided by the "mock" tool) - F8 case

a, root@host] yum install / update mock
b, root@host] adduser -G mock boinc
c, root@host] passwd boinc

From another tty:
d, ssh boinc@host
e, boinc@host] mock init
   (This will create the needed chroot environment for us -- root in
   /var/lib/mock/fedora-development-x86_64/root/ in this case).
f, ^D

Return to the first tty:

g, root@host] userdel -r boinc
h, root@host] mkdir /var/lib/moc/fedora-development-x86_64/root/home/boinc
i, root@host] chown boinc.boinc
j, root@host] adduser -G mock -d
/var/lib/moc/fedora-development-x86_64/root/home/boinc boinc
k, root@host] passwd boinc

Return to the second tty -- check the work of the chroot environment:

l, ssh boinc@host
m, boinc@host] pwd
   (The output of this command should be the same as the directory used
    after the -d option, in the above "useradd -G mock-d ... boinc" command).
n, boinc@host] mkdir sdf 

2, Mount the root /proc filesystem via the chroot command readonly:

a, chroot /var/lib/mock/fedora-development-x86_64/root/ mount -t proc -r proc

3, Check if sdf is mounted:

   boinc@host] cd sdf && ls 
   (There should be a couple of files listed in the output..)

4, Now try to write from root account some value to some file contained in the 
   chrooted mounted /proc environment (of course select such one, not
   to cause kernel panic):

   a, root@host] # cat

32768   61000

   b, root@host] # echo "32768   60000" >
   (There you can see /proc is mounted in readwrite mode, not in readonly
    mode as it should). To check this fact perform the command

   c, root@host]# cat

32768   60000

Additional information:

When the system wouldn't be vulnerable, the output of the last above command
would look like this:

c, root@host] 
# echo "32768   60000" >
Read-only file system

Comment 9 Eugene Teo (Security Response) 2008-10-31 01:53:40 UTC
Martin, are you still experiencing this problem on recent versions of Fedora? Will you be able to help us reproduce the problem?

Thanks, Eugene

Comment 14 Martin Cracauer 2008-10-31 17:41:27 UTC
I haven't used any newer FCs.

However, it is my understanding that the kernel (before Redhat/Fedora changes) poses the original problem, you cannot have procfs mounted multiple times with different readonly or read-write status.

I would very much like to see this bug fixed (I think it counts as a bug, in particular since it happens silently). Security in a chroot is more of a joke than normal due to the read-write mounted /proc.  

The only alternative is to not give the chroot any /proc, but way too many applications depend on it by now. In my environment the example is Adobe Flash. I choot my Firefox chain including plugins and Flash won't do without /proc. But it only needs readonly /proc, so if this bug was fixed that would work nicely.

Anyway, as I said, this is a general kernel issue and not a Fedora/Redhat issue. Fedora/Redhat changes the default behavior which made me report this bug against Redhat, but that was just messing with the symptoms, Redhat didn't break it.

If Redhat has the engineering resources to contribute kernel changes to allow multiple procfs mounts with different permissions I believe that would be well-invested security work.

Comment 22 Eugene Teo (Security Response) 2009-04-17 05:02:52 UTC
It turns out that this is a non-issue. vfsmounts are separate, while superblock is shared. If you want your vfsmount to be read-only, you need to:

mount -o remount,ro --bind <your mount point>

Filesystem itself will remain r/w (it *is* shared with the entire system), but any write access to it via that mount will fail with EROFS until you remount it rw on vfsmount level (as above, with s/ro/rw/).

To mount this read-only, you need to do this:
# mount -t proc none /tmp/proc
# mount -o remount,ro --bind /tmp/proc 
# mount | grep tmp.proc
none on /tmp/proc type proc (ro,bind)
# grep tmp.proc /proc/mounts 
none /tmp/proc proc ro 0 0
# echo 1 > /tmp/proc/sys/kernel/vsyscall64 
-bash: vsyscall64: Read-only file system

This is documented in mount(2).


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