Follow up: How to write a Linux virus [LWN.net]

Follow up: How to write a Linux virus

Posted Feb 13, 2009 12:30 UTC (Fri) by tzafrir (subscriber, #11501)
In reply to: Follow up: How to write a Linux virus by etienne_lorrain@yahoo.fr
Parent article: Follow up: How to write a Linux virus

A. how do you get multiple menu items from a single ELF binary?
B. What about other formats?
- #! script
- a.out
- win32
- Java

to post comments

Follow up: How to write a Linux virus

Posted Feb 13, 2009 13:31 UTC (Fri) by efexis (guest, #26355) [Link] (4 responses)

How is this an issue? When does one build their menu out of the actual applications, not links to them? Oh, and win32 (or 'PE' as is the binary object model used for their exe 'n dll's) has containing multiple icons pretty well sorted and used.

Windows just overlays the small arrow icon in the bottom left hand corner to signify that the icon is merely a shortcut to the application rather than the application itself when you're browsing the files. But hey, that's a pretty recent idea...

Follow up: How to write a Linux virus

Posted Feb 13, 2009 14:59 UTC (Fri) by hppnq (guest, #14462) [Link]

But what brilliance, no? To indicate that the icon is an icon, and to use an icon to do that. It's an Escher-icon.

One of the other posters of course hit the nail right on the head: until we have a mechanism that with reasonable security allows a user to validate the purpose of downloaded content, all other suggestions are pointless.

Follow up: How to write a Linux virus

Posted Feb 13, 2009 19:00 UTC (Fri) by vonbrand (guest, #4458) [Link] (2 responses)

Unix (and thus Linux) is a multiuser system. I.e., each of the multiple users might have very well like different graphical interfases (each with its own icon set), or just use their own icons. That Windows (which is still very much a one user operating system, with just one graphical interface) does it differently is completely irrelevant.

Follow up: How to write a Linux virus

Posted Feb 14, 2009 11:08 UTC (Sat) by etienne_lorrain@yahoo.fr (guest, #38022) [Link]

Nobody said that the icon_file_path was an absolute path, it could be "application/textmode/editor/vi.xpm" and prefixed by default with "/usr/X11R6/icon", but can be overwritten by environment variable ICON_PATH pointing to the user directory...

Follow up: How to write a Linux virus

Posted Feb 16, 2009 9:18 UTC (Mon) by dgm (subscriber, #49227) [Link]

Excuse me if I sound rude, but I would give up themeability (sp?) for security any day. Changing the vi icon is not even in my list of desired features.

Follow up: How to write a Linux virus

Posted Feb 13, 2009 16:00 UTC (Fri) by dkite (guest, #4577) [Link] (1 responses)

Scripts, a.out could have a standard icon, as they do now if they show up
in your file listing. And if you click on them permissions are respected. I
suspect that in most cases they don't represent applications that would
show up in a menu.

Java?

Interesting the immediate objection to this. Mustn't bloat the executable.
Lean mean and insecure. Your dpkg or whatever which now contains the icons
and executable would have some files bigger, but less files.

As for anything anyone gets by email or by downloading, that is another
problem. .desktop files are particularly dangerous because they disregard
the permissions scheme, and are opaque in what they run. Downloading a
binary executable now would require setting the executable bit. Downloading
a tar requires extracting the file that could have the executable bit set,
finding it and running it. Having non trivial mechanisms to do that within
the gui would get rid of the non-expert user issue. The real solutions are
probably better handled below the gui level with SElinux or policykit type
stuff. As long as the gui launching respects the permissions, which it
doesn't now.

The problem as it exists is that you are clicking on something that is not
the executable. Essentially the launcher runs a quasi script that is not
subject to the permissions scheme of the os. Note the following link.

http://archive.netbsd.se/?ml=xorg-xdg&a=2006-03&t...

Kinda illustrates why the desire to establish standards is, umm,
counterproductive? We end up with lowest common denominator trash. The
objections end up being something like "this isn't a real solution, so
let's stick with the blatantly insecure".

Derek

Follow up: How to write a Linux virus

Posted Feb 13, 2009 19:26 UTC (Fri) by tzafrir (subscriber, #11501) [Link]

> Scripts, a.out could have a standard icon, as they do now if
> they show up in your file listing

You just removed the icon from all of the Mozilla programs.

Furthermore, replacing a program with a wrapper script is a rather common practice.

Follow up: How to write a Linux virus

Posted Feb 13, 2009 16:08 UTC (Fri) by forthy (guest, #1525) [Link]

What about hard-linking several commands to the same ELF file (distinguish different functions by argv[0]), and have the ELF header in the form icon-<name>, where the original file name is used to find the correct icon?

Other formats: #! scripts could have a formal comment section after the #! which defines icons. win32 files already have embedded icons. Java files are really zip files, you can have an icon subdirectory. Anything more?

The main point however IMHO is that .desktop files can execute arbitrary code, they should not be allowed to do so without +x flag. Thus a user with a noexec /home partition can only symlink to system-provided .desktop files (menu shortcuts and that like), which is probably a reasonable restriction. Just downloaded .desktop files don't execute upon clicking (maybe clicking on them should show up a .desktop editor, telling unexperienced users that this .desktop file has marked as non-executable and might be malicious). It has about the same effect as embedding icons into the executable itself.

Follow up: How to write a Linux virus

Posted Feb 13, 2009 17:17 UTC (Fri) by iabervon (subscriber, #722) [Link] (3 responses)

Have the relevant section name depend on the basename of the executable; that's the usual way of having the same executable do different things when run. You just make a symlink to set it. The filesystem storage costs are probably less than the .desktop file anyway.

Java jars are zip archives with a directory for "what do you actually run". That's especially easy. a.out is hardly supported any more, and win32 goes with its own system (win32 executables depend on having a registry of some sort).

Scripts are kind of annoying, but there's probably an easy enough way to put something in them near the beginning using their native comment syntax plus a special tag.

Follow up: How to write a Linux virus

Posted Feb 13, 2009 19:31 UTC (Fri) by tzafrir (subscriber, #11501) [Link] (2 responses)

Again, please find something that is at least good enough to cover the problems demonstrated in http://lwn.net/Articles/319122/ .

Follow up: How to write a Linux virus

Posted Feb 13, 2009 20:46 UTC (Fri) by iabervon (subscriber, #722) [Link] (1 responses)

Add to the iceape binary these ELF sections:

.desktop.chatzilla:
  options:
    -chat\0\0
.desktop.iceape-addressbook:
  options:
    -addressbook\0\0
.desktop.iceape:
  filearg:
.desktop.iceape-navigator:
  filearg:
  options:
    -browser\0\0

symlink /usr/share/applications/{chatzilla,iceape,iceapi-navagator,etc} to the iceape binary.

In the dynamic linker, check for a .desktop.(basename of $0) section, and rewrite argv to have the given options, if any, between $0 and $1. In the launcher, offer a filename argument if the section has a "filearg" symbol. The launcher could also pull out other information, like icons, names, suitable MIME types, etc. And the launcher actually executes "/usr/share/applications/iceape foo", so if it's looking at isn't executable, it'll get an error.

As a bonus, you can actually execute these from the command line with the same effect that they have in the launcher.

Follow up: How to write a Linux virus

Posted Feb 14, 2009 8:34 UTC (Sat) by ringerc (subscriber, #3071) [Link]

The performance cost of that would be horrifying, as it'd force the linker to do all sorts of unnecessary work whenever it executed any process. Like, say `ps', `ls', `as', `gcc', etc.

You might be able to avoid that by borrowing a spare (if there is one) ELF header flag to indicate "this is a desktop application".

In all honstly, though if you're going to mangle things that much why not take NextSTEP / Apple's approach of .app dirs with self-contained metadata?

Anyway, none of these proposed solutions address things like users wanting to make their own app links, make custom launchers with different arguments to apps, add launchers for apps they've compiled themselves, etc. Making .desktop files require execute permissions would be a big step.