| |||||||||||||
|
| |||||||||||||
How to write a Linux virus in 5 easy stepsHow to write a Linux virus in 5 easy stepsPosted Feb 11, 2009 21:21 UTC (Wed) by ledow (guest, #11753)Parent article: How to write a Linux virus in 5 easy steps
Well, after reading the article, I'm not "shocked" or "surprised". I just nodded and went... "Yes, and?"
"How to write a Linux virus in 5 easy steps" is a false title. It should be called:
"How to write a text file which, when downloaded deliberately and placed into a certain location, and then double-clicked, could potentially execute code within the context of the user account that ran it."
That's called a bash script, or even a rogue Makefile, or a malicious line of C code. In fact, all of my suggestions are simpler and more likely and the last two don't need eXecution rights either. I hide a rogue line of script inside one of those, get you to download my software and try to install it and bam... instant compromise (and an awful lot of people compile as root!).
The problem of viruses is NOT that the user that runs them might lose their files or be bombarded by ads. They were a moron to run the program and it could do anything they have permission to, otherwise the system wouldn't work. The problem is that the virus can self-propogate, cause damage, be difficult to remove and compromise the MACHINE. This is almost impossible as anything other than a superuser on Linux. This is the difference between Linux and Windows.
Users run stupid things all the time. "rm -f" comes to mind and causes a lot of damage. Anybody with access to a compiler from their user account can cause merry hell without even meaning to. The point is that after a reboot, or a removal of their user area and a kill of their processes, there is NOTHING left to affect any other user of that machine. That's just not true of Windows.
This isn't a Linux, KDE, Gnome problem. It's a user-is-an-idiot-and-did-something-that-could-trash-HIS-files problem. I get *those* every day.
(Log in to post comments)
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 0:12 UTC (Thu) by tbrownaw (guest, #45457) [Link] The problem is that the virus can self-propogate, cause damage, be difficult to remove and compromise the MACHINE. I thought the ones that could self-propagate were called "worms".
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 3:30 UTC (Thu) by nlucas (subscriber, #33793) [Link]
Both can self-propagate. The difference between a virus and a worm is that the first needs to "attach" itself to some other program to be run, while the worm IS the program.
Basic example, a bash virus runs, look for other bash scripts and inserts itself at the start of the existing script (eventually first checking if it was already infected). It may now check if it's time to do it's think ("rm -rf ~/*") or just exit and wait the user to make it run again by executing an infected script.
A worm runs by itself. Doesn't need a "host" program to run, but off course it needs some way of start running, and that can possibly be by adding itself to be called at the end of .bashrc/.profile/.whatever.
In the old days, the difference was that virus were writen in assembly, because they couldn't use something like libc, while worms, being a full programs, could be written in anything (and so, could be more powerful, like using system network libraries for infection).
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 10:43 UTC (Thu) by efexis (guest, #26355) [Link]
Just like in biology! A virus masks as healthy DNA code so that host cells will copy it, whereas worms are host cells in their own right... of course this means one can actually use viruses to fight worms (bacteriophages), which is something that's used both in treating bacterial infections, and shutting down botnets (by using the botnet to spread the code that later kills itself). Aside from the damage all of this causes in the world of data and flesh, it's all rather cool!
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 11:31 UTC (Thu) by cortana (subscriber, #24596) [Link]
> That's called a bash script, or even a rogue Makefile, or a malicious line
> of C code. In fact, all of my suggestions are simpler and more likely and > the last two don't need eXecution rights either. I hide a rogue line of > script inside one of those, get you to download my software and try to > install it and bam... instant compromise (and an awful lot of people > compile as root!).
Saving a bash script or Makefile from a web browser or email client, and then double-clicking the resulting file, will result in the file being opened in a text editor.
Doing the same to an ELF binary will (at least on my GNOME 2.24 system) result in a dialog box saying: "Cannot open $FILE. There is no application installed for this file type".
This is because web browsers, email clients, etc, will save the evil file out, but will not mark the file as executable. Without being executable, these files are harmless text and binary files and are treated as such.
The loophole here is that if the user extracts files from a tar or zip archive, the archiver will mark evil files executable if the archive says so. In fact, for some reason I cannot fathom, unzip will mark *all* extracted files as executable! In my opinion, all files extracted by archivers should not have their permissions restored unless the user specifically requests it.
Note that I do not address bugs in file viewing programs themselves; e.g., a vulnerability in a PDF reader or imgae displayer that causes it to execute arbitrary code embedded in an evil file.
Anyway, to return to my point; the special processing that allows a .desktop file to appear with any arbitrary file name and icon, and that allows them to execute any arbitrary code should be disabled for .desktop files that are not executable. That simple change eliminates this problem.
The first public discussion of this problem that I could find occured in 2006; Unfortunately, the freedesktop.org people simply don't seem to care that they have created such serious security problems by ignoring the security features inherited from Unix so many years ago; essentially reducing the security level of the Linux desktop to that of Windows 3.
It is a shame that implementors (GNOME, KDE, etc.) have not taken matters into their own hands and disabled special processing for non-executable .desktop files themselves; and in turn, that distributors (Debian, etc.) have not acted where implementors have failed to do so.
How to write a Linux virus in 5 easy steps Posted Feb 13, 2009 2:28 UTC (Fri) by k8to (subscriber, #15413) [Link]
By default, unzip does not mark files as executable.
Info-zip added an extra informational header that allowed permissions to be described in zip files. If your zip files have this informational field, and it says the files should be executable, they are created as such.
The problem is that there are some retarded zip programs out there that mark everything executable.
How to write a Linux virus in 5 easy steps Posted Feb 21, 2009 23:16 UTC (Sat) by miketrim (guest, #54570) [Link] In Ubuntu/GNOME, any automounted FAT/NTFS drives are mounted with umask=0077 which results in all files being executable. This was something I found rather annoying when I migrated from Windows, as all my files that I copied over were initially marked +x, resulting in Nautilus always asking if I wanted to view or execute them.However, this could just as easily be a security issue as it means that Nautilus will happily execute files stored on a USB drive for example. (Double-clicking on a +x binary will execute it without any confirmation, and the same can apply to a +x text file if Nautilus is configured to do so -- or if the user doesn't understand the difference between 'run' and 'view'.) https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/14335
|
|
||||||||||||