Comment 59 for bug 321176

Mr Jo-Erlend Schinstad,

Virus is an application that forces computer not to work properly. Notice that most Windows viruses nowdays are not copying itself to other executables, they're just starting when computer starts (they're placed in registry - HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/Run if I remember correctly).

Recipe for virus:

Write a Firefox extension that will contain malicious code using this bug, use _UNPROTECTED_ .bashrc file in user's directory and start this app by doing:

sleep 10; DISPLAY=:0 ./virus_start

With this trick someone can hang user's desktop 10 seconds after he logs in. User only needs to download this extension (and this is possible to create such file because it's possible to save wallpaper in user's home directory from Firefox).

Of course this code needs to be injected to .bashrc, which is not write-protected (normal user can modify his own bashrc file). So this IS clearly a security issue. You see, most Windows computers are infected because of users installing software from P2P networks. Anyone can even post an application on GnomeFiles.org, no one checks these. If someone will install such app (even from DEB package) on his computer, you known what can happen. So IMHO this should be fixed immediately! With this trick, someone can make user's computer unusable. Before someone figures out to check .bashrc, user will reinstall Linux or install Windows. You can even name the virus instead of "virus_start" something like "gnome-session" or similiar. Any app from Gnomefiles or Firefox extension can make the executable working by doing "chmod +x virus". See? No need to infect other executables in order to destroy a system.

If someone will post that "this app on Gnomefiles makes computer hang on every boot", virus could activate for example on 1st of September. That's why I think that bug with hanging desktop should be fixed with nr 1 priority.

But there's another thing:

This X11-hanging bug happens in Fedora 11 too, so it's not Ubuntu-specific. I am trying to reproduce this bug by writing a test case, no luck though.