Comment 1 for bug 83099

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.