Bug 213135 - CVE-2008-2544 mounting proc readonly on a different mount point silently mounts it rw if the /proc mount is rw
CVE-2008-2544 mounting proc readonly on a different mount point silently moun...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
bzcl34nup
: Security
Depends On: CVE-2008-2544
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-30 17:12 EST by Martin Cracauer
Modified: 2009-01-13 11:28 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-09 01:59:44 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 Martin Cracauer 2006-10-30 17:12:57 EST
Description of problem:

Here is how to disable all logins with
pam_loginuid(sshd:session): set_loginuid failed opening loginuid

I noticed this problem in FC5 and it is still present in FC6. It does work in
FC4 (and Debian and Ubuntu). All amd64.

I run SETI-like programs in chroot and under a different userid.

So the command looks like this:
nice -n 10 chroot /var/chroot/blah su boinc sh -c "cd BOINC && ./boinc $args

(First, SELinux has to be off, otherwise it will ask for user "boinc"'s
password, even though you are uid 0 and there is no password for that user, so
this can't work. But that's not the topic of this bug report, I have SE off)

If you do this in FC4 it works fine. If you do it in FC5 or FC6, then something
in PAM breaks and no further login is possible:
~(wavehh)% rl nem
Last login: Mon Oct 30 15:54:56 2006 from wavehh.hanse.de
Connection to nem closed.

/var/log/secure says:
Oct 30 15:50:19 nemesis sshd[2905]: Postponed publickey for cracauer from
172.16.30.1 port 46785 ssh2
Oct 30 15:50:19 nemesis sshd[2904]: Accepted publickey for cracauer from
172.16.30.1 port 46785 ssh2
Oct 30 15:50:19 nemesis sshd[2906]: pam_unix(sshd:session): session opened for
user cracauer by (uid=0)
Oct 30 15:50:19 nemesis sshd[2906]: pam_loginuid(sshd:session): set_loginuid
failed opening loginuid
Oct 30 15:50:19 nemesis sshd[2906]: pam_loginuid(sshd:session): set_loginuid failed 
Oct 30 15:50:19 nemesis sshd[2906]: error: PAM: pam_open_session(): Cannot
make/remove an entry for the specified session





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

FC6, no patches, no additional programs, no config changes except network,
SELinux off.

How reproducible:

- create a chroot (I use an AMD64 Debian chroot)
- create user boinc
- as mentioned, SELinux has to be off, or you have to have a password for that user
- excute the above commandline
- afterwards try to ssh into the machine

I can provide the actual chroot that I am using on request.

As mentioned before, it works in FC4, but not FC5 and FC6, although the chroot I
use in all three is precisely the same (rsynced).

  
Actual results:

From the moment you execute that commandline with chroot and su, PAM will not
allow any further logins. If you are lucky you have a root shell open to reboot
soft.

See above for syslog.

Expected results:

PAM should continue to work.

Additional info:

I am happy to prove more info or the actual chroot that I use.
Comment 1 Martin Cracauer 2006-10-30 17:17:08 EST
I should clarity this: "~(wavehh)% rl nem"

"rl" is my alias for "ssh", "men" is the FC6 machine affected. This is the
commandline trying to log into the affected machine (just ssh).

I should also mention it doesn't make a difference whether I use an ssh-agent or
direct password entry, and it doesn't matter which userid I try to log in as.
Comment 2 Tomas Mraz 2006-10-31 09:34:56 EST
After you execute the commandline above, could you issue
"ls -l /proc/self/loginuid ; cat /proc/self/loginuid ; echo" from another root
shell?

What this commandline prints?
Comment 3 Martin Cracauer 2006-10-31 12:49:16 EST
Here you go:

~(nemesis)3# sh -c "ls -l /proc/self/loginuid ; cat /proc/self/loginuid ; echo"
-rw-r--r-- 1 root root 0 Oct 31 12:47 /proc/self/loginuid
4294967295
~(nemesis)4# 

It is the same number from three different shells currently open.
Comment 4 Tomas Mraz 2006-11-01 12:01:16 EST
Can you attach as minimal chroot as possible with which it still happens?

Also does it still happen when you modify the line to:
nice -n 10 chroot /var/chroot/blah su boinc sh -c "cd BOINC && sleep 1000
Comment 5 Martin Cracauer 2006-11-01 12:17:40 EST
I can give you a login on that machine if that helps before I can minimize the
chroot. Right now it is 214 MB uncompressed.

Your command line looks truncated, I assume you mean "cd BOINC && sleep 1000

 && ./boinc " at the end.

If you do that, then PAM is already broken during the sleep, before the ./boinc.
Comment 6 Tomas Mraz 2006-11-02 06:25:28 EST
OK after trying to diagnose this directly on your machine:

as you wrote to me in a private message the problem is the
mount -r -t proc sdf /var/chroot/sid-amd64-boinc/proc

What happens is that the read only mount of the proc filesystem changes the
/proc mount of the proc filesystem to become read only as well and thus the
pam_loginuid fails. You can get easily back from the broken state with "mount -o
rw,remount -t proc sdf /var/chroot/sid-amd64-boinc/proc". What's much more
strange is that I cannot reproduce this problem on exactly the same kernel on a
different machine. But it is a kernel problem anyway.

[root@nemesis]~# uname -a
Linux nemesis.cons.org 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:39:22 EDT 2006
x86_64 x86_64 x86_64 GNU/Linux

Comment 7 Bug Zapper 2008-04-04 00:17:08 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 8 Tomas Mraz 2008-04-04 05:46:57 EDT
Seems to be OK with current F8 kernels although the new mounts of proc are just
kept rw although ro mount is requested. But that is probably tolerable.
Comment 9 Martin Cracauer 2008-04-04 11:36:39 EDT
(In reply to comment #8)
> Seems to be OK with current F8 kernels although the new mounts of proc are just
> kept rw although ro mount is requested. But that is probably tolerable.

The whole point of this is that it should *actually* be readonly. It works fine
on other distributions.

If you have a chroot for security reasons, having a read/write mounted /proc
makes the whole exercise pointless.

Silently converting the requested ro mount to a rw mount, if that is what you
say is happening now, is completely unacceptable.

What kind of info do you need from me specifically?
Comment 10 Tomas Mraz 2008-04-04 12:16:15 EDT
Actually you're right that the current behavior can have security implications.
kernel-2.6.24.4-64.fc8 x86_64

What distributions with what kernel versions work fine for you?
Comment 11 Martin Cracauer 2008-04-04 12:25:46 EDT
(In reply to comment #10)
> Actually you're right that the current behavior can have security implications.
> kernel-2.6.24.4-64.fc8 x86_64
> 
> What distributions with what kernel versions work fine for you?

Debian and Ubuntu, but I use stock (kernel.org) kernels there, so it's really
not distribution-specific.

Overall, I know that this is a result of other security features in Fedora. 

However, this effectively disables readonly /proc mounts and hence it makes
chroots useless unless you happen to have applications in there that don't need
/proc at all. That's not the case for many applications you want to cage in. As
I said, most distributed computing projects need this, and my Firefox chroot
needs it, too.

Thanks for the update
Martin
Comment 12 Dave Jones 2008-04-04 13:26:46 EDT
We don't change anything intentionally in the Fedora kernel which could affect
mount permissions afaik, so I'm not sure why this would be different.

Could you test a stock kernel on F8 and see if it still happens ? That would
rule out whether it is actually something we apply.   Use the same config
options from /boot/config-2.6.24.4-64.fc8 and just run make oldconfig

Thanks.
Comment 13 Martin Cracauer 2008-04-04 15:16:07 EDT
Weeeeell...

So, actually trying this I see that the stock kernel now also silently ignores
the fact that the second /proc is mounted readonly.

I'd have to try on an older kernel so see if and when the support for actual
readonly second mounts has been removed.
Comment 14 Tomas Mraz 2008-04-04 15:48:50 EDT
I think that this behavior switched from the original buggy behavior (silent ro
remount of /proc when proc is mounted somewhere else ro) to the current (silent
rw mount on the secondary mount point). I don't think this ever worked right (at
least in 2.6.x kernels).
Comment 15 Tomas Hoger 2008-06-01 06:16:22 EDT
Martin, may I ask which threats are you trying to address by read-only proc
mount?  Have you managed to get one rw and one ro proc mount on some distro /
kernel?
Comment 16 Warren Togami 2008-06-01 22:32:20 EDT
Perhaps read-only /proc could work with mount --bind readonly support added in
2.6.26-rc?
Comment 17 Jan Lieskovsky 2008-06-04 09:49:57 EDT
This behavior seems to be specific only for the /proc filesystem.
Have tried sysfs and tmpfs -- giving "Read-only file system" error
message even on F9 kernel (2.6.25.3-18.fc9.x86_64).

The sysfs case:  (2.6.25.3-18.fc9.x86_64)

[root@host dev]# chroot /var/lib/mock/fedora-9-x86_64/root/ mount -t sysfs -r
sys home/boinc/fakeext3

[root@host dev]# cat
/var/lib/mock/fedora-9-x86_64/root/home/boinc/fakeext3/class/misc/network_latency/uevent
MAJOR=10
MINOR=62


[root@host dev]# echo -e "MAJOR=15\nMINOR=62" >
/var/lib/mock/fedora-9-x86_64/root/home/boinc/fakeext3/class/misc/network_latency/uevent
-bash:
/var/lib/mock/fedora-9-x86_64/root/home/boinc/fakeext3/class/misc/network_latency/uevent:
Read-only file system


The tmpfs case:  (2.6.25.3-18.fc9.x86_64)

[root@host dev]# chroot /var/lib/mock/fedora-9-x86_64/root/ umount
home/boinc/fakeext3

[root@host dev]# chroot /var/lib/mock/fedora-9-x86_64/root/ mount -t tmpfs -r
tmp home/boinc/fakeext3 

[root@host dev]# touch /var/lib/mock/fedora-9-x86_64/root/home/boinc/fakeext3/hello
touch: cannot touch
`/var/lib/mock/fedora-9-x86_64/root/home/boinc/fakeext3/hello': Read-only file
system

Seems the /proc filesystem used to behave in the same way till
2.6.23.1-42.fc8. Starting from 2.6.24.*, it silently mounts /proc rw even
when explicit ro mount option is used.
Comment 18 Bug Zapper 2008-11-26 02:03:47 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 19 Bug Zapper 2009-01-09 01:59:44 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 20 Eugene Teo (Security Response) 2009-01-11 23:03:57 EST
Hmm, while F8 is already EOL, this doesn't seem to be fixed in F9 and F10 because there is no fix in upstream yet. Dave/Chuck, take note.
Comment 21 Martin Cracauer 2009-01-12 14:32:01 EST
This is definitely not fixed.

Here is a summary of the issue.  From memory, some details might be out of focus.

1) when using a chroot for any kind of non-trivial application, including web browsers and seti-at-home type applications you need a /proc, let's say you mount it to /chroot/proc.

2) of course a read-write mounted /chroot/proc will instantly turn security into a joke (as all processes, files and devices are accessible by anybody becoming root in the chroot).  But most of these applications, while requiring a /proc, can live with a readonly /proc.

So people like me want two procfs mounts:
- /proc read-write
- /chroot/proc read-only

This is b0rked.

3) the Linux kernel, stock or Redhat, does not support multiple mounts of procfs with different permissions

4) in the mainline kernel, if you have an existing read-write mount to /proc and make a mount request to a read-only /chroot/proc, it will ignore the readonly flag silently and give you a read-write mounted /chroot/proc instead.

5) in redhat/fedora kernels around the time of my initial bug report, and presumably today: given an existing read-write mount to /proc and  a mount request to a read-only /chroot/proc, it will downgrade /proc to read-only, effectively disabling the base system.

I think the solution for this must be some kind of "wrapper" filesystem that can put a read-only layer on top of an existing filesystem.

In any case, both behaviors as described in 4) and 5) are unacceptable.  Silently giving read-write permissions on a read-only mount request is as wrong as silently downgrading an existing mount.

%%

I strongly urge somebody who is running a recent Fedora to re-open this bug report after confirming which behavior it is showing now.  I had cut'n'pasteable reproducing commands in my original bug report and can supply them again.
Comment 22 Tomas Hoger 2009-01-13 03:03:00 EST
(In reply to comment #21)
> 2) of course a read-write mounted /chroot/proc will instantly turn security
> into a joke (as all processes, files and devices are accessible by anybody
> becoming root in the chroot).  But most of these applications, while requiring
> a /proc, can live with a readonly /proc.

If anybody in the chroot becomes root, she can escape chroot trivially without /proc mounted at all.  Read-only vs. read-write /proc mount does not influence that much.

> I strongly urge somebody who is running a recent Fedora to re-open this bug
> report after confirming which behavior it is showing now.

Has this been fixed, or is this test incorrect?

# uname -r
2.6.27.9-159.fc10.x86_64

# mkdir -p /chroot/proc

# mount -o ro -t proc proc /chroot/proc/

# cat /proc/mounts | grep '/proc proc'
/proc /proc proc rw 0 0
proc /chroot/proc proc ro 0 0

# echo 1 > /proc/sys/net/ipv4/ip_forward

# echo 1 > /chroot/proc/sys/net/ipv4/ip_forward
bash: /chroot/proc/sys/net/ipv4/ip_forward: Read-only file system
Comment 23 Tomas Mraz 2009-01-13 03:55:10 EST
Yes, it seems to be fixed in current kernels. I've tested it with the 2.6.29-0.18.rc0.git9.fc11.x86_64 kernel and it is fixed there too.
Comment 24 Martin Cracauer 2009-01-13 11:28:54 EST
(In reply to comment #22)
> (In reply to comment #21)
> > 2) of course a read-write mounted /chroot/proc will instantly turn security
> > into a joke (as all processes, files and devices are accessible by anybody
> > becoming root in the chroot).  But most of these applications, while requiring
> > a /proc, can live with a readonly /proc.
> 
> If anybody in the chroot becomes root, she can escape chroot trivially without
> /proc mounted at all.  Read-only vs. read-write /proc mount does not influence
> that much.
> 
> > I strongly urge somebody who is running a recent Fedora to re-open this bug
> > report after confirming which behavior it is showing now.
> 
> Has this been fixed, or is this test incorrect?
> 
> # uname -r
> 2.6.27.9-159.fc10.x86_64
> 
> # mkdir -p /chroot/proc
> 
> # mount -o ro -t proc proc /chroot/proc/
> 
> # cat /proc/mounts | grep '/proc proc'
> /proc /proc proc rw 0 0
> proc /chroot/proc proc ro 0 0
> 
> # echo 1 > /proc/sys/net/ipv4/ip_forward
> 
> # echo 1 > /chroot/proc/sys/net/ipv4/ip_forward
> bash: /chroot/proc/sys/net/ipv4/ip_forward: Read-only file system

This looks good.

I don't have FC anymore.  My mainline 2.6.26.3 is still broken:

mount -o -ro -t proc proc /mnt/tmp
echo 1 >  /mnt/tmp/sys/net/ipv4/ip_forward
# no complaints

Any idea whether this is a 2.6.27 or a Redhat/Fedora fix?

Thanks
Martin

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