[conspire] Autorun in GNOME/Nautilus
rick at linuxmafia.com
Tue Sep 27 14:32:19 PDT 2011
Quoting Nick Moffitt (nick at zork.net):
> To be fair, the autostart brainworms described here are pretty
> universally disabled on any major OS.
I appreciate hearing this. Because I recently loaded Ubuntu 11.10
Oneiric Ocelot Beta 2 into a virtual machine out of curiosity, I
attempted, this morning, to see if they _had_ disabled autostart.
Unfortunately, the inert blotchy mess that is the Unity desktop has at
least temporarily defeated my efforts to investigate (i.e., I have no
idea, yet, where in the hell are the controls), and apparently Beta 2
doesn't default-provide GNOME Shell packages any more.
I remain concerned about distro-packaged GNOME in at least the recent
past, even if no longer. I keep finding distro-specific pages like this
...not to mention this 2006 bug filed on package gnome-volume-manager
complaining about _failure_ to autorun at mount time, and which was
reported to be 'fixed' by down-revving the udev package.
An Ubuntu bug also grappled with the issue in 2006, and waffled:
But 2006 is of course quite a while ago. Apparently, g-v-m is now dead
upstream and has been replaced by gio/gvfs and Nautilus automount.
Anyhow, I don't have time at the moment to test-install an entire
current GNOME-based distro and check, so please tell me: Are you saying
that current distros have, via their security teams or otherwise, a
policy of 'Please ignore the upstream Freedesktop.org / GNOME spec about
autostart at mount time. They're morons'? (E.g., always require user
confirmation before autostart, which policy I've seen discussed.)
That would be certainly A Good Thing, but still amounts to quite an
indictment of FDO.
> The autorun problem that *actually* exists is the image thumbnailer in
> nautilus. If you can generate a file that can exploit the thumbnailer
> somehow, you have a path toward executing arbitrary code.
That's actually generic threat model against image viewers. People need
to be careful about what code they allow to handle public data, and
image files are certainly no exception. However, even though there's
been a history of people being able to craft Jpeg, png, gif, whatever
images able to segfault handling software insufficiently good at
anticipating aberrant input data, turning that into arbitrary code
execution is orders of magnitude more difficult.
I'd actually be a lot more worried about lusers who insist on installing
Adobe Acroread instead of using xpdf/Evince/Okular. Acroread has inline
furnished by standard Adobe bug-crafting.
More information about the conspire