File descriptor leak allows DoS
Bug #83099 reported by
David Watson
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.
Related branches
Changed in upstart: | |
importance: | Undecided → Critical |
status: | Unconfirmed → Confirmed |
Changed in upstart: | |
status: | Confirmed → In Progress |
To post a comment you must log in.
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.