mount: unprivileged user can mount partition without updating mtab

Bug #13131 reported by Debian Bug Importer
10
Affects Status Importance Assigned to Milestone
util-linux (Debian)
Fix Released
Unknown
util-linux (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Automatically imported from Debian bug report #296201 http://bugs.debian.org/296201

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Automatically imported from Debian bug report #296201 http://bugs.debian.org/296201

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <email address hidden>
Date: Sun, 20 Feb 2005 15:59:20 -0800
From: Tyler MacDonald <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: mount: unprivileged user can mount partition without updating mtab

Package: mount
Version: 2.12p-2
Severity: grave
Justification: user security hole

If a non-root user mounts media (in my case, a CD-ROM), and attempts to kill
the process (in my case, a mad combination of ^C and ^\), the filesystem can
be mounted, yet not appear in /etc/mtab.

This means that when the user does a "df", it does not show up, and when
they try to unmount it (unless they are root), they are denied, told that
the filesystem is not mounted according to /etc/mtab.

This introduces two security holes:

 1) A malicious user could lock-up removable media for anybody else
that wishes to use the system; or

 2) A user is told that data is not available which actually is,
which could mislead them into leaving it there for others to access.

.. and, of course, in the case of cd-rom's which are usually locked while
moutned, a user without root access or access to the person with root access
can't get his/her CD rom back (without sticking a needle in the little hole,
but we don't want them to do that, do we?)

 - Tyler

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.7-1-k7
Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1)

Versions of packages mount depends on:
ii libblkid1 1.36release-1 block device id library
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii libuuid1 1.36release-1 universally unique id library

-- no debconf information

Revision history for this message
In , Justin Pryzby (justinpryzby-users) wrote : Re: Bug#296201: mount: unprivileged user can mount partition without updating mtab

On Sun, Feb 20, 2005 at 03:59:20PM -0800, Tyler MacDonald wrote:
> Package: mount
> Version: 2.12p-2
> Severity: grave
> Justification: user security hole
>
>
> If a non-root user mounts media (in my case, a CD-ROM), and attempts
> to kill the process (in my case, a mad combination of ^C and ^\),
> the filesystem can be mounted, yet not appear in /etc/mtab.
This is the user inflicting damage on themselves, mostly.

> This means that when the user does a "df", it does not show up, and
> when they try to unmount it (unless they are root), they are denied,
> told that the filesystem is not mounted according to /etc/mtab.

> This introduces two security holes:
>
> 1) A malicious user could lock-up removable media for anybody
> else that wishes to use the system; or
This is a DOS, I guess, but doesn't compromize any data. Potentially,
this could be fixed by writing mtab before calling mount(2), though I
don't know what the implications of that are. Or mount(1) could check
something else (?) after it checks mtab.

Maybe mount needs a signal handler, which sets an "abort" flag, which
is checked after mount(2) is called, which causes unmount to be
called, instead of writing mtab? Hmm. Probably mtab should be open()
before calling mount, if that's not already the case.

> 2) A user is told that data is not available which actually
> is, which could mislead them into leaving it there for others
> to access.
Which isn't a problem, since entering the mount command makes it
accessible anyway. If the user didn't want it to be accessible, then
they shouldn't have entered the command.

> .. and, of course, in the case of cd-rom's which are usually locked
> while moutned, a user without root access or access to the person
> with root access can't get his/her CD rom back (without sticking a
> needle in the little hole, but we don't want them to do that, do
> we?)
If they want the CD back, then they have to have physical access,
which is usually considered as good as root.

Justin

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <20050221141442.GA5754@andromeda>
Date: Mon, 21 Feb 2005 09:14:43 -0500
From: Justin Pryzby <email address hidden>
To: Tyler MacDonald <email address hidden>, <email address hidden>
Subject: Re: Bug#296201: mount: unprivileged user can mount partition without updating mtab

On Sun, Feb 20, 2005 at 03:59:20PM -0800, Tyler MacDonald wrote:
> Package: mount
> Version: 2.12p-2
> Severity: grave
> Justification: user security hole
>
>
> If a non-root user mounts media (in my case, a CD-ROM), and attempts
> to kill the process (in my case, a mad combination of ^C and ^\),
> the filesystem can be mounted, yet not appear in /etc/mtab.
This is the user inflicting damage on themselves, mostly.

> This means that when the user does a "df", it does not show up, and
> when they try to unmount it (unless they are root), they are denied,
> told that the filesystem is not mounted according to /etc/mtab.

> This introduces two security holes:
>
> 1) A malicious user could lock-up removable media for anybody
> else that wishes to use the system; or
This is a DOS, I guess, but doesn't compromize any data. Potentially,
this could be fixed by writing mtab before calling mount(2), though I
don't know what the implications of that are. Or mount(1) could check
something else (?) after it checks mtab.

Maybe mount needs a signal handler, which sets an "abort" flag, which
is checked after mount(2) is called, which causes unmount to be
called, instead of writing mtab? Hmm. Probably mtab should be open()
before calling mount, if that's not already the case.

> 2) A user is told that data is not available which actually
> is, which could mislead them into leaving it there for others
> to access.
Which isn't a problem, since entering the mount command makes it
accessible anyway. If the user didn't want it to be accessible, then
they shouldn't have entered the command.

> .. and, of course, in the case of cd-rom's which are usually locked
> while moutned, a user without root access or access to the person
> with root access can't get his/her CD rom back (without sticking a
> needle in the little hole, but we don't want them to do that, do
> we?)
If they want the CD back, then they have to have physical access,
which is usually considered as good as root.

Justin

Revision history for this message
In , Justin Pryzby (justinpryzby-users) wrote :

On Mon, Feb 21, 2005 at 09:14:42AM -0500, pryzbyj wrote:
> On Sun, Feb 20, 2005 at 03:59:20PM -0800, Tyler MacDonald wrote:
> > Package: mount
> > Version: 2.12p-2
> > Severity: grave
> > Justification: user security hole
> >
> >
> > If a non-root user mounts media (in my case, a CD-ROM), and attempts
> > to kill the process (in my case, a mad combination of ^C and ^\),
> > the filesystem can be mounted, yet not appear in /etc/mtab.
I can't reproduce this. mount.c:856 blocks all signals, then tries to
mount the fs, then updates mtab, then unblocks signals. I tested and
this appears to ensure atomicity of the mount,mtab block WRT signals.

Justin

Revision history for this message
In , Tyler MacDonald (tyler-yi) wrote :

Justin Pryzby <email address hidden> wrote:
> I can't reproduce this. mount.c:856 blocks all signals, then tries to
> mount the fs, then updates mtab, then unblocks signals. I tested and
> this appears to ensure atomicity of the mount,mtab block WRT signals.

 Jason, I just did it again:

 - Put cd in tray;
 - in one window, "mount /dev/hdc"

 - while tray is loading, as the same user mounting the device, find
the mount process in other window (ps ax | grep mount) and kill it (kill -9
26669)

 - Mounting window shows "Killed".
 - df doesn't show filesystem
 - ls /cdrom shows filesystem's contents
 - Umount /dev/hdc shows:
   umount: /dev/hdc is not mounted (according to mtab)
 - umount /dev/hdc as root says "not mounted", but umount
/media/cdrom0 (which doesn't work as a regular user in this situation) works
as root.

 I just repoed this twice in a row. The second time, I had to "kill
-9" the mount process twice, but it still worked.

 - Tyler

Revision history for this message
In , Andreas Barth (aba) wrote :

* Justin Pryzby (<email address hidden>) [050221 16:40]:
> I can't reproduce this. mount.c:856 blocks all signals, then tries to
> mount the fs, then updates mtab, then unblocks signals. I tested and
> this appears to ensure atomicity of the mount,mtab block WRT signals.

This won't help if you e.g. manage that the oom-killer kills the
process - or someone does a kill -9 on it, or so. But well, probability
is too low, and unix just doesn't offer some begin-commit-action for
syscalls :)

Cheers,
Andi
--
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <20050221152552.GA6258@andromeda>
Date: Mon, 21 Feb 2005 10:25:53 -0500
From: Justin Pryzby <email address hidden>
To: Tyler MacDonald <email address hidden>, <email address hidden>
Subject: Re: Bug#296201: mount: unprivileged user can mount partition without updating mtab

On Mon, Feb 21, 2005 at 09:14:42AM -0500, pryzbyj wrote:
> On Sun, Feb 20, 2005 at 03:59:20PM -0800, Tyler MacDonald wrote:
> > Package: mount
> > Version: 2.12p-2
> > Severity: grave
> > Justification: user security hole
> >
> >
> > If a non-root user mounts media (in my case, a CD-ROM), and attempts
> > to kill the process (in my case, a mad combination of ^C and ^\),
> > the filesystem can be mounted, yet not appear in /etc/mtab.
I can't reproduce this. mount.c:856 blocks all signals, then tries to
mount the fs, then updates mtab, then unblocks signals. I tested and
this appears to ensure atomicity of the mount,mtab block WRT signals.

Justin

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Mon, 21 Feb 2005 07:35:27 -0800
From: Tyler MacDonald <email address hidden>
To: Justin Pryzby <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#296201: mount: unprivileged user can mount partition without updating mtab

Justin Pryzby <email address hidden> wrote:
> I can't reproduce this. mount.c:856 blocks all signals, then tries to
> mount the fs, then updates mtab, then unblocks signals. I tested and
> this appears to ensure atomicity of the mount,mtab block WRT signals.

 Jason, I just did it again:

 - Put cd in tray;
 - in one window, "mount /dev/hdc"

 - while tray is loading, as the same user mounting the device, find
the mount process in other window (ps ax | grep mount) and kill it (kill -9
26669)

 - Mounting window shows "Killed".
 - df doesn't show filesystem
 - ls /cdrom shows filesystem's contents
 - Umount /dev/hdc shows:
   umount: /dev/hdc is not mounted (according to mtab)
 - umount /dev/hdc as root says "not mounted", but umount
/media/cdrom0 (which doesn't work as a regular user in this situation) works
as root.

 I just repoed this twice in a row. The second time, I had to "kill
-9" the mount process twice, but it still worked.

 - Tyler

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Mon, 21 Feb 2005 16:47:40 +0100
From: Andreas Barth <email address hidden>
To: Justin Pryzby <email address hidden>,
 <email address hidden>
Cc: Tyler MacDonald <email address hidden>
Subject: Re: Bug#296201: mount: unprivileged user can mount partition without updating mtab

* Justin Pryzby (<email address hidden>) [050221 16:40]:
> I can't reproduce this. mount.c:856 blocks all signals, then tries to
> mount the fs, then updates mtab, then unblocks signals. I tested and
> this appears to ensure atomicity of the mount,mtab block WRT signals.

This won't help if you e.g. manage that the oom-killer kills the
process - or someone does a kill -9 on it, or so. But well, probability
is too low, and unix just doesn't offer some begin-commit-action for
syscalls :)

Cheers,
Andi
--
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

Revision history for this message
In , Thomas Hood (jdthood-aglu) wrote : Not RC, IMHO

mount has its shortcomings, but I think it is stretching it to
describe the reported behavior as a "secutiry hole".

It isn't likely that this problem would be allowed either to delay
the release or to force the removal of mount from the release.
Also, assuming the shortcoming exists in all versions of mount, it
shouldn't prevent new versions of mount from migrating to testing.

Therefore I suggest that the severity of this report be downgraded.

--
Thomas
Hood

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <email address hidden>
Date: Wed, 23 Feb 2005 15:44:41 GMT
From: <email address hidden>
To: <email address hidden>
Subject: Not RC, IMHO

mount has its shortcomings, but I think it is stretching it to
describe the reported behavior as a "secutiry hole".

It isn't likely that this problem would be allowed either to delay
the release or to force the removal of mount from the release.
Also, assuming the shortcoming exists in all versions of mount, it
shouldn't prevent new versions of mount from migrating to testing.

Therefore I suggest that the severity of this report be downgraded.

--
Thomas
Hood

Revision history for this message
In , Stephan Niemz (st-n) wrote : Re: Bug#296201: mount: unprivileged user can mount partition without updating mtab

There is quite a simple solution to this problem:

  ln -sf ../proc/mounts mtab

    Maybe this could be added to postinst or similar. Of course this
only works when procfs is mounted to /proc, but is anyone really not
doing this nowadays?

The other advantage is that "mount" and "df" show the correct file
systems even when "/" is mounted read-only, e. g. in single user mode.

Cheers,

    - Stephan.

Revision history for this message
In , Andreas Barth (aba) wrote :

severity 296201 important
tags 296201 + unreproducible
thanks

* Stephan Niemz (<email address hidden>) [050223 22:40]:
> There is quite a simple solution to this problem:
>
> ln -sf ../proc/mounts mtab
>
> Maybe this could be added to postinst or similar. Of course this
> only works when procfs is mounted to /proc, but is anyone really not
> doing this nowadays?

There are multiple reasons why this is a bad idea - and even if not,
this is definitly not a change appropriate at the latest minute before
sarge.

It is still not proven that this error can be reproduced w/o using root
privileges - and even than, it's at maximum possible to deny some
service. For this reason, I'll lower priority now, and add
unreproducible.

Cheers,
Andi
--
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 23 Feb 2005 22:28:14 +0100
From: Stephan Niemz <email address hidden>
To: Andreas Barth <email address hidden>
Cc: Justin Pryzby <email address hidden>,
 <email address hidden>, Tyler MacDonald <email address hidden>
Subject: Re: Bug#296201: mount: unprivileged user can mount partition without updating mtab

--jI8keyz6grp/JLjh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

There is quite a simple solution to this problem:

  ln -sf ../proc/mounts mtab

    Maybe this could be added to postinst or similar. Of course this
only works when procfs is mounted to /proc, but is anyone really not
doing this nowadays?

The other advantage is that "mount" and "df" show the correct file
systems even when "/" is mounted read-only, e. g. in single user mode.

Cheers,

    - Stephan.

--jI8keyz6grp/JLjh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: This is a digitally signed email. See http://gnupg.org/ for details.

iD8DBQFCHPVuD4jPIYfdYgoRArTlAJ4882Fuw94wn2kSPf8Sec9pOtkq4ACffEFR
MTG34SOKEPUpacnL1Amj9CU=
=Ljrj
-----END PGP SIGNATURE-----

--jI8keyz6grp/JLjh--

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 23 Feb 2005 22:43:45 +0100
From: Andreas Barth <email address hidden>
To: Stephan Niemz <email address hidden>, <email address hidden>
Cc: Justin Pryzby <email address hidden>,
 Tyler MacDonald <email address hidden>
Subject: Re: Bug#296201: mount: unprivileged user can mount partition without updating mtab

severity 296201 important
tags 296201 + unreproducible
thanks

* Stephan Niemz (<email address hidden>) [050223 22:40]:
> There is quite a simple solution to this problem:
>
> ln -sf ../proc/mounts mtab
>
> Maybe this could be added to postinst or similar. Of course this
> only works when procfs is mounted to /proc, but is anyone really not
> doing this nowadays?

There are multiple reasons why this is a bad idea - and even if not,
this is definitly not a change appropriate at the latest minute before
sarge.

It is still not proven that this error can be reproduced w/o using root
privileges - and even than, it's at maximum possible to deny some
service. For this reason, I'll lower priority now, and add
unreproducible.

Cheers,
Andi
--
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

Revision history for this message
In , Stephan Niemz (st-n) wrote :

> * Stephan Niemz (<email address hidden>) [050223 22:40]:
> > ln -sf ../proc/mounts mtab

Am Wed, 23. February 2005 um 22:43:45 +0100 schrieb Andreas Barth:
> There are multiple reasons why this is a bad idea - and even if not,

I'm curious, what are these multiple reasons? I've had no problems doing
this yet.

> this is definitly not a change appropriate at the latest minute before
> sarge.

Isn't sarge "last minute" for about a year now? ;-)

    Anyway, I have no problem with not doing this change. That only
means that I have to keep setting this symlink by hand. But maybe a
comment in README.Debian or similar would help.

Cheers,

    - Stephan.

Revision history for this message
In , Tyler MacDonald (tyler-yi) wrote :

> It is still not proven that this error can be reproduced w/o using root
> privileges -

 To repo - I have done this *4* times now:

 - Get a cdrom with "user" mount permissions in fstab.

 - Put a cd in the tray. Leave the tray open so you have some extra
time.

 - Open two terminals.

 - In terminal #1, type "killall -9 mount", but do not press enter.

 - In terminal #2, type "mount /cdrom" (or whatever), and press enter.

 - In terminal #1, press enter, then up-arrow, then enter, then
up-arrow, etc.

 Each time I have tried this, the problem has been reproduced.

  - Tyler

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 23 Feb 2005 23:24:52 +0100
From: Stephan Niemz <email address hidden>
To: Andreas Barth <email address hidden>
Cc: <email address hidden>, Justin Pryzby <email address hidden>,
 Tyler MacDonald <email address hidden>
Subject: Re: Bug#296201: mount: unprivileged user can mount partition without updating mtab

--4Ckj6UjgE2iN1+kY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

> * Stephan Niemz (<email address hidden>) [050223 22:40]:
> > ln -sf ../proc/mounts mtab

Am Wed, 23. February 2005 um 22:43:45 +0100 schrieb Andreas Barth:
> There are multiple reasons why this is a bad idea - and even if not,

I'm curious, what are these multiple reasons? I've had no problems doing
this yet.

> this is definitly not a change appropriate at the latest minute before
> sarge.

Isn't sarge "last minute" for about a year now? ;-)

    Anyway, I have no problem with not doing this change. That only
means that I have to keep setting this symlink by hand. But maybe a
comment in README.Debian or similar would help.

Cheers,

    - Stephan.

--4Ckj6UjgE2iN1+kY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: This is a digitally signed email. See http://gnupg.org/ for details.

iD8DBQFCHQK0D4jPIYfdYgoRAu8aAKCZaDlpw8u+LNckSUAybZZdYGy8vwCfY75x
zBqcuUIS1Tezf4cETEOFZ6o=
=e1yt
-----END PGP SIGNATURE-----

--4Ckj6UjgE2iN1+kY--

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 23 Feb 2005 14:59:21 -0800
From: Tyler MacDonald <email address hidden>
To: Andreas Barth <email address hidden>
Cc: Stephan Niemz <email address hidden>, <email address hidden>,
 Justin Pryzby <email address hidden>
Subject: Re: Bug#296201: mount: unprivileged user can mount partition without updating mtab

> It is still not proven that this error can be reproduced w/o using root
> privileges -

 To repo - I have done this *4* times now:

 - Get a cdrom with "user" mount permissions in fstab.

 - Put a cd in the tray. Leave the tray open so you have some extra
time.

 - Open two terminals.

 - In terminal #1, type "killall -9 mount", but do not press enter.

 - In terminal #2, type "mount /cdrom" (or whatever), and press enter.

 - In terminal #1, press enter, then up-arrow, then enter, then
up-arrow, etc.

 Each time I have tried this, the problem has been reproduced.

  - Tyler

Revision history for this message
In , Stephan Niemz (st-n) wrote :

tags 296201 - unreproducible
tags 296201 + patch
thanks

This *is* reproducible, although I think one should always avoid doing a
"kill -9" if not really really absolutely necessary.

And I have suggested a patch in a previous message.

Cheers,

    - Stephan.

Am Wed, 23. February 2005 um 14:59:21 -0800 schrieb Tyler MacDonald:
> To repo - I have done this *4* times now:
[...]

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Thu, 24 Feb 2005 08:29:29 +0100
From: Stephan Niemz <email address hidden>
To: Tyler MacDonald <email address hidden>
Cc: Andreas Barth <email address hidden>, <email address hidden>,
 Justin Pryzby <email address hidden>
Subject: Re: Bug#296201: mount: unprivileged user can mount partition without updating mtab

--vtzGhvizbBRQ85DL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

tags 296201 - unreproducible
tags 296201 + patch
thanks

This *is* reproducible, although I think one should always avoid doing a
"kill -9" if not really really absolutely necessary.

And I have suggested a patch in a previous message.

Cheers,

    - Stephan.

Am Wed, 23. February 2005 um 14:59:21 -0800 schrieb Tyler MacDonald:
> To repo - I have done this *4* times now:
[...]

--vtzGhvizbBRQ85DL
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: This is a digitally signed email. See http://gnupg.org/ for details.

iD8DBQFCHYJZD4jPIYfdYgoRAhMkAJ9GPVo2KjqtVk7+X2vcs6fhUCl7GwCeLD4y
LlL5WQGJZQiAYwGrQPHyn3U=
=c/At
-----END PGP SIGNATURE-----

--vtzGhvizbBRQ85DL--

Revision history for this message
In , Andreas Barth (aba) wrote :

* Tyler MacDonald (<email address hidden>) [050224 00:25]:
> > It is still not proven that this error can be reproduced w/o using root
> > privileges -
>
> To repo - I have done this *4* times now:
>
> - Get a cdrom with "user" mount permissions in fstab.
>
> - Put a cd in the tray. Leave the tray open so you have some extra
> time.
>
> - Open two terminals.
>
> - In terminal #1, type "killall -9 mount", but do not press enter.

Can a normal user kill mount, or do you need superuser privileges for
that?

Cheers,
Andi
--
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Thu, 24 Feb 2005 11:41:16 +0100
From: Andreas Barth <email address hidden>
To: Tyler MacDonald <email address hidden>
Cc: Stephan Niemz <email address hidden>, <email address hidden>,
 Justin Pryzby <email address hidden>
Subject: Re: Bug#296201: mount: unprivileged user can mount partition without updating mtab

* Tyler MacDonald (<email address hidden>) [050224 00:25]:
> > It is still not proven that this error can be reproduced w/o using root
> > privileges -
>
> To repo - I have done this *4* times now:
>
> - Get a cdrom with "user" mount permissions in fstab.
>
> - Put a cd in the tray. Leave the tray open so you have some extra
> time.
>
> - Open two terminals.
>
> - In terminal #1, type "killall -9 mount", but do not press enter.

Can a normal user kill mount, or do you need superuser privileges for
that?

Cheers,
Andi
--
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

Revision history for this message
In , Tyler MacDonald (tyler-yi) wrote :

Andreas Barth <email address hidden> wrote:
> Can a normal user kill mount, or do you need superuser privileges for
> that?

 Andi,
  I repoed this, including killing mount, as a normal user.

  - Tyler

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Thu, 24 Feb 2005 08:36:12 -0800
From: Tyler MacDonald <email address hidden>
To: Andreas Barth <email address hidden>
Cc: Stephan Niemz <email address hidden>, <email address hidden>,
 Justin Pryzby <email address hidden>
Subject: Re: Bug#296201: mount: unprivileged user can mount partition without updating mtab

Andreas Barth <email address hidden> wrote:
> Can a normal user kill mount, or do you need superuser privileges for
> that?

 Andi,
  I repoed this, including killing mount, as a normal user.

  - Tyler

Revision history for this message
In , Justin Pryzby (justinpryzby-users) wrote :

On Wed, Feb 23, 2005 at 02:59:21PM -0800, Tyler MacDonald wrote:
> > It is still not proven that this error can be reproduced w/o using root
> > privileges -
>
> To repo - I have done this *4* times now:
Indeed, I heard you the first two times, as, I suspect, did the other
83 people on the -rc ML.

It is sometimes difficult to describe all the conditions leading up to
a problem, so we appreciate your patience.

I have guessed that your /etc/mtab is a file, and not a symlink;
indeed, many people, myself included, have mtab => /proc/mounts, and
this bug almost certainly depends on mount detecting that mtab is a
regular file and not a symlink.

Could you confirm that your mtab is a regular file?

Yes, I can confirm that one can kill mount as a normal user.

And, yes, I can confirm having reproduced the reported problem. Note,
also, this very weird behaviour:

pryzbyj@andromeda:~$ ls /cdrom/
pryzbyj@andromeda:~$ ls /cdrom/
Classic Rock

That is inconsistent at the VFS level, as best I know. The first `ls`
required the drive to spin up, the second did not. The first one,
however, was fully spun up when it returned.

getdents64(3, /* 0 entries */, 4096) = 0

The second ls has:

getdents64(3, /* 3 entries */, 4096) = 80

pryzbyj@andromeda:~$ grep cdrom /proc/mounts;
/dev/hdc /cdrom iso9660 ro,nosuid,nodev,noexec 0 0
pryzbyj@andromeda:~$ grep cdrom /etc/mtab
pryzbyj@andromeda:~$

Justin

Revision history for this message
In , Tyler MacDonald (tyler-yi) wrote :

Justin Pryzby <email address hidden> wrote:
> Indeed, I heard you the first two times, as, I suspect, did the other
> 83 people on the -rc ML.
>
> It is sometimes difficult to describe all the conditions leading up to
> a problem, so we appreciate your patience.

 Having to repeat things a few times is a small price to pay for
software perfection. :)

> I have guessed that your /etc/mtab is a file, and not a symlink;
> indeed, many people, myself included, have mtab => /proc/mounts, and
> this bug almost certainly depends on mount detecting that mtab is a
> regular file and not a symlink.
>
> Could you confirm that your mtab is a regular file?

 It is.

$ ls -l /etc/mtab
-rw-r--r-- 1 root root 436 2005-02-21 22:25 /etc/mtab

 - Tyler

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <20050224201240.GA2202@andromeda>
Date: Thu, 24 Feb 2005 15:12:40 -0500
From: Justin Pryzby <email address hidden>
To: Tyler MacDonald <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#296201: mount: unprivileged user can mount partition without updating mtab

On Wed, Feb 23, 2005 at 02:59:21PM -0800, Tyler MacDonald wrote:
> > It is still not proven that this error can be reproduced w/o using root
> > privileges -
>
> To repo - I have done this *4* times now:
Indeed, I heard you the first two times, as, I suspect, did the other
83 people on the -rc ML.

It is sometimes difficult to describe all the conditions leading up to
a problem, so we appreciate your patience.

I have guessed that your /etc/mtab is a file, and not a symlink;
indeed, many people, myself included, have mtab => /proc/mounts, and
this bug almost certainly depends on mount detecting that mtab is a
regular file and not a symlink.

Could you confirm that your mtab is a regular file?

Yes, I can confirm that one can kill mount as a normal user.

And, yes, I can confirm having reproduced the reported problem. Note,
also, this very weird behaviour:

pryzbyj@andromeda:~$ ls /cdrom/
pryzbyj@andromeda:~$ ls /cdrom/
Classic Rock

That is inconsistent at the VFS level, as best I know. The first `ls`
required the drive to spin up, the second did not. The first one,
however, was fully spun up when it returned.

getdents64(3, /* 0 entries */, 4096) = 0

The second ls has:

getdents64(3, /* 3 entries */, 4096) = 80

pryzbyj@andromeda:~$ grep cdrom /proc/mounts;
/dev/hdc /cdrom iso9660 ro,nosuid,nodev,noexec 0 0
pryzbyj@andromeda:~$ grep cdrom /etc/mtab
pryzbyj@andromeda:~$

Justin

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Thu, 24 Feb 2005 12:23:12 -0800
From: Tyler MacDonald <email address hidden>
To: Justin Pryzby <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#296201: mount: unprivileged user can mount partition without updating mtab

Justin Pryzby <email address hidden> wrote:
> Indeed, I heard you the first two times, as, I suspect, did the other
> 83 people on the -rc ML.
>
> It is sometimes difficult to describe all the conditions leading up to
> a problem, so we appreciate your patience.

 Having to repeat things a few times is a small price to pay for
software perfection. :)

> I have guessed that your /etc/mtab is a file, and not a symlink;
> indeed, many people, myself included, have mtab => /proc/mounts, and
> this bug almost certainly depends on mount detecting that mtab is a
> regular file and not a symlink.
>
> Could you confirm that your mtab is a regular file?

 It is.

$ ls -l /etc/mtab
-rw-r--r-- 1 root root 436 2005-02-21 22:25 /etc/mtab

 - Tyler

Revision history for this message
In , Justin Pryzby (justinpryzby-users) wrote : gdb break

Anyone know why gdb breakpoint on mount(2) shows stack corruption?
Even if I run gdb as root with mount mode 0755.

Justin

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <20050225204616.GA8908@andromeda>
Date: Fri, 25 Feb 2005 15:46:16 -0500
From: Justin Pryzby <email address hidden>
To: <email address hidden>
Subject: gdb break

Anyone know why gdb breakpoint on mount(2) shows stack corruption?
Even if I run gdb as root with mount mode 0755.

Justin

Revision history for this message
Matt Zimmerman (mdz) wrote :

I'm not convinced that this is a security issue. Martin, what do you think?

Revision history for this message
Martin Pitt (pitti) wrote :

(In reply to comment #17)
> I'm not convinced that this is a security issue. Martin, what do you think?

I tried for ten minutes now, I can't reproduce this either. I can kill mount
either before it mounts/writes mtab, or not at all.

I think its a relatively nasty bug, but since it is truly local (physical
access) I don't think it is security relevant. FWIW, this only affects CD-ROMs
anyway, all pmount-handled devices are not affected since pmount already checks
/proc/mounts in addition.

<rant>/etc/mtab should just die. The very concept is broken.</rant> *sigh*

Revision history for this message
Martin Pitt (pitti) wrote :

Unassigning. Not reproducible, and will keep track of this through Debian.

Changed in util-linux:
assignee: pitti → nobody
Revision history for this message
rusivi2 (rusivi2-deactivatedaccount) wrote :

Thank you for reporting this bug.

Does this occur in Lucid?

Changed in util-linux (Ubuntu):
status: Confirmed → Incomplete
Changed in util-linux (Debian):
status: New → Fix Released
Revision history for this message
Thomas Hotz (thotz-deactivatedaccount) wrote :

This bug is fixed in util-linux 2.20.1-1 which is in Ubuntu 12.04 LTS.

Changed in util-linux (Ubuntu):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.