Ubuntu
initramfs-tools package

mountall is lying about /run's noexec

Bug #1152744 reported by Kees Cook
266
This bug affects 2 people
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
Fix Released
Medium
Unassigned
Precise
Fix Released
Undecided
Marc Deslauriers
Quantal
Fix Released
Undecided
Marc Deslauriers
Saucy
Fix Released
Undecided
Unassigned
Trusty
Fix Released
Medium
Unassigned

Bug Description

It looks like /run got mounted without noexec and the mtab write lies about it:

$ grep -m1 /run /etc/mtab /proc/mounts
/etc/mtab:tmpfs /run tmpfs rw,noexec,nosuid,size=10%,mode=0755 0 0
/proc/mounts:tmpfs /run tmpfs rw,nosuid,relatime,size=1618980k,mode=755 0 0

For completeness, /run should _actually_ be mounted noexec, even if it's root:root 0755.

Marc Deslauriers (mdeslaur)
information type: Private Security → Public Security
Changed in mountall (Ubuntu):
status: New → Confirmed
Revision history for this message
Steve Langasek (vorlon) wrote :

This is a result of /run being mounted from the initramfs. mountall doesn't attempt to remount any filesystems that are already mounted, it just records them in /etc/mtab with 'mount -f'. This has previously been reported as bug #1039887.

I think having the wrong default mount options for /run is an initramfs-tools bug, rather than a mountall bug; initramfs-tools should get the mount options right without us having to remount anything.

affects: mountall (Ubuntu) → initramfs-tools (Ubuntu)
Changed in initramfs-tools (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package initramfs-tools - 0.103ubuntu0.7

---------------
initramfs-tools (0.103ubuntu0.7) raring; urgency=low

  * src/wait-for-root.c: Set udev monitor socket to blocking, as we want to
    wait for events. (LP: #1154813)
 -- Martin Pitt <email address hidden> Thu, 14 Mar 2013 07:08:06 +0100

Changed in initramfs-tools (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
ski (skibrianski) wrote :

This problem still exists on 12.04 LTS, current as of March 12. Given its security nature, the fix should be backported.

Changed in initramfs-tools (Ubuntu):
assignee: nobody → ski (skibrianski)
assignee: ski (skibrianski) → nobody
Marc Deslauriers (mdeslaur)
Changed in initramfs-tools (Ubuntu Saucy):
status: New → Fix Released
Changed in initramfs-tools (Ubuntu Precise):
status: New → Confirmed
Changed in initramfs-tools (Ubuntu Quantal):
status: New → Confirmed
Changed in initramfs-tools (Ubuntu Precise):
assignee: nobody → Marc Deslauriers (mdeslaur)
Changed in initramfs-tools (Ubuntu Quantal):
assignee: nobody → Marc Deslauriers (mdeslaur)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package initramfs-tools - 0.99ubuntu13.5

---------------
initramfs-tools (0.99ubuntu13.5) precise-security; urgency=medium

  * SECURITY UPDATE: incorrect tmpfs mount options (LP: #1152744)
    - init: Sync the mount options for /run from /lib/init/fstab.
 -- Marc Deslauriers <email address hidden> Fri, 21 Mar 2014 12:40:40 -0400

Changed in initramfs-tools (Ubuntu Precise):
status: Confirmed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package initramfs-tools - 0.103ubuntu0.2.2

---------------
initramfs-tools (0.103ubuntu0.2.2) quantal-security; urgency=medium

  * SECURITY UPDATE: incorrect tmpfs mount options (LP: #1152744)
    - init: Sync the mount options for /run from /lib/init/fstab.
 -- Marc Deslauriers <email address hidden> Fri, 21 Mar 2014 12:45:59 -0400

Changed in initramfs-tools (Ubuntu Quantal):
status: Confirmed → Fix Released
Revision history for this message
ski (skibrianski) wrote :

Thanks Marc. Confirmed working on my 12.04 install.

Revision history for this message
KennoVO (kenno-xs4all) wrote :

Sorry for the naive question, but how severe are the security implications of this? Does there exist a CVE, or otherwise a discussion of the implications?

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

it's more security hardening than an actual vulnerability, and even then then only reason it got fixed is because the mtab was listing it wrong. If an administrator is specifically mounting certain partitions noexec, they may have been thinking that /run was noexec also even though it wasn't.

Revision history for this message
KennoVO (kenno-xs4all) wrote :

Thanks Marc! I suspected as much, but I thought I'd ask to be sure. Since it's just released, sysadmins will be happy to find the above clarification in this thread, which helps planning reboots.

To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.
Subscribing...

Other bug subscribers

Remote bug watches

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