File descriptor leak allows DoS

Bug #83099 reported by David Watson
258
Affects Status Importance Assigned to Milestone
upstart
Fix Released
Critical
Scott James Remnant (Canonical)
Ubuntu
Edgy
Invalid
Undecided
Ubuntu Security Team
upstart (Ubuntu)
Fix Released
Critical
Unassigned

Bug Description

Package: 0.2.7-7 (edgy)

I've noticed that upstart leaks its inotify descriptor to spawned processes on
file descriptor 6. This allows ordinary users to delete init's watch
descriptors and thus prevent it from recognizing changes to its
configuration, or to exhaust the per-user watch descriptor limit for root,
preventing all root processes from creating new watch descriptors.

I noticed this because I'm using kdm, which (unlike gdm and console logins)
passes extraneous descriptors straight through to the user session. However,
the descriptor is also available through cron, and so I presume a default
installation would have this problem as well.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Attached a proof exploit code that can be run with:

  'echo ./upsploit > upsploit.txt 2>&1' | atd now

This demonstrates that we can obtain the inotify instance descriptor, and with it, remove and add watches.

Once run, upstart is unable to notice changes to /etc/event.d

Normally the leaked watch and the new one created will not have the same descriptor, in this case upstart will simply discard the messages from the unknown watch descriptor.

However in the rare case where the old and new descriptors are the same, it's possible for upstart to receive events for a different directory and handle them as if it were its own configuration directory.

Fortunately upstart always prepends the known directory name to the front, so after this exploit, creating /tmp/tty1 actually causes upstart to re-read /etc/event.d/tty1.

The worst you can do is make upstart read a file again, or one that doesn't exist; both of which are completely safe.

It's not possible to inject new entries into the inotify queue.

Upstart ignores delete and move events, so it's not possible to cause it to forget about a job that exists in /etc/event.d

Adding many watches can cause upstart to hit the maximum number of watches per instance limit; however this limit is per instance, and not global -- so it doesn't adversely affect any other process.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Attached is a patch for upstart 0.2.7, as found in edgy.

It marks the inotify instance file descriptor to be closed on exec.

The same patch should apply to 0.3.0 and 0.3.1.

0.3.2 will be released with the rewritten inotify code, which is not affected by this bug.

Changed in upstart:
assignee: nobody → keybuk
importance: Undecided → Critical
status: Unconfirmed → Fix Committed
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Fix released in 0.3.2

Changed in upstart:
status: Fix Committed → Fix Released
Changed in upstart:
importance: Undecided → Critical
status: Unconfirmed → Confirmed
Revision history for this message
Martin Pitt (pitti) wrote :

After discussing this, we decided that the potential impact on Edgy is negligible, thus we will treat this as a normal bug fix.

Changed in upstart:
status: Confirmed → In Progress
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Fixed with upload of 0.3.5 to Ubuntu

Changed in upstart:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

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