The function of the expert is not to be more right than other people, but to be wrong for more sophisticated reasons. | |
| Dr. David Butler, British psephologist |
Writing a program that inserts code into another program file is one thing. Writing that program so that it can be injected itself is a very different art. Although this document shows a lot of code and technique, it is far from being a "Construction Kit For Dummies". You can't build a working virus just by copying whole lines from this text. Instead I'll try to show how things work. Translation of infecting code to a assembly is left as (non-trivial) exercise to the reader.
An astonishing number of people think that viruses require secret black magic. Here you will find simple code that patches other executables. It is not hard to write a virus - once you have a good understanding of assembler, compiler, linker and operating system. [1] It's just hard to let it make any impact.
Regular users can't overwrite system files (at least under serious operating systems). So you need root permissions. You can either trick the super user to run your virus. Or combine it with a root-exploit. But since all popular distributions come with checksum mechanisms, a single command can detect any modification. Unless you implement kernel-level stealth functionality…
I do believe that free software is superior, at least in regard to security. And I strongly oppose the argument that Linux viruses will flourish once it reaches a critical mass of popularity. On the contrary I question the credibility of people whose income relies on widespread use of ridiculously insecure operating systems.
This document is my way to fight the FUD. [2] Use the information presented here in any way you like. I bet that Linux will only grow stronger. [3]
The plural of virus is neither viri nor virii, nor even vira nor virora. It is quite simply viruses, irrespective of context. [4]
The jargon files contain a good definition. For my purposes it is not technical enough, though.
A virus [5] is a program that infects other programs stored in inactive form. This document concentrates on copying the executable code of the virus into another file. Other possible targets are boot sectors and programmable ROMs.
A worm [6] is a program that penetrates other running programs. Penetration means to copy the executable code of the worm into the active process image of the host.
A trojan program [7] is deliberately started by a user because of advertised features, but performs covert malicious actions.
The jargon files include programs infected by a virus into their definition of trojan. I don't consider this helpful. The survival strategy of viruses is to stay below the level of perception of humans, operating systems or scanners. But trojans don't hide. They obfuscate their real intend by delivering a good show. Good advertising can persuade the user to install necessary system components, deactivate security checks, and throw overboard all common sense.
The jargon files also claim that "a virus cannot infect other computers without assistance". Widespread use of write-enabled network shares has made this a bold statement. It is correct that patching an executable file over the net is meaningless if that program is not executed somewhere. But I want to stress that it's not the media containing the target that distinguishes worms from viruses. A virus polluting a RAM-disk is still a virus. A worm saved to disk by the hibernation feature of a laptop is still a worm.
The main difference between worms and viruses is persistence and speed. Modifications to files are usually permanent and remain after reboot. On the other hand a virus attached to a host can get active only when that host program is started. A worm takes immediate control of a running process and thus can propagate very fast. [8] [9]
Usually these techniques are combined to effectively cause mischief. Viruses can get resident, i.e. attach themselves to a part of the system that runs independent of the infected executable. Worms can modify system files to leave permanent back doors. [10] And tricking the user into executing the very first infector is a lot easier than finding and exploiting [11] buffer overflows. [12]
But Unixes have traditional concepts to limit the possible damage of a malicious process. Network services can be run under the access permissions of a non-privileged account. File systems can be mounted read-only (e.g. /usr) or as noexec (e.g. /home). Some file systems have extended attributes that can prohibit access even when ls -l tells otherwise. [13] Probably the strongest defense is chroot.
>Every single one of these techniques can stop a vandalizing human, virus or worm to take over the entire machine. But while it is easy to control viruses, it is very hard to stop worms. To exploit a vulnerable network service a worm needs permissions for an incoming connection. To compromise the next machine on the network it needs an outgoing network connection. Nothing else.
I will now put on a black hat and an evil grin. Using material already published on the net, contributions sent to me, and all documentation available, I will try to build a virus to do in ELF for good. All concepts, ideas and experiments - along with enough working code to prove my conclusions - will be released to public ridicule through this document.
Should the quest fail this may have a few reasons:
I am incompetent.
Nobody cared to sent in evidence for #1.
It already has been done, but They will prevent #2 to maintain #1.
Optimistic readers could think that the inevitable big mistake of developers and distributors will be released soon, but just isn't available right now.
Even more adventurous spectators might say that design, development model, or distribution concept make Linux immune against a direct attack.
This is just one of the meaningless episodes in the matrix.
Anyway, it is not a problem if we, or someone using this document, succeeds. The correct name for that situation is opportunity. Should you happen to take this document - and especially above agenda - too seriously, the story of "Osama bin virus" [14] can help.
This text written under influence of an evil grin.
This document, The ELF Virus Writing HOWTO, is copyrighted (c) 2002 by Alexander Bartolich.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1, or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts.
All accompanying source code, build scripts and makefiles is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
All copyrights are held by their respective owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark.
Naming of particular products or brands should not be seen as endorsements.
No liability for the contents of this documents can be accepted. Use the concepts, examples and other content at your own risk. As this is a new edition of this document, there may be errors and inaccuracies, that may of course be damaging to your system. Proceed with caution, the author does not take any responsibility.
All software is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.
Who am I kidding? This is dangerous stuff! Stop reading immediately or risk lethal pollution of your systems!
You are strongly recommended to take a backup of your system before major installations and backups at regular intervals.
Everything in this document is either plain obvious or has been written by someone else long time ago. My meager contribution is nice formatting, reproducibility and the idea to take the subject to mainstream media. But I'm certainly not innovative.
To my knowledge, VLAD [15] magazine #7 [16] contains the oldest published virus infecting ELF executables on Linux/i386. Quantum (the author) called his creation Stoag. [17] It is written in raw assembler with few comments. I yet have to read the code.
Silvio Cesare <silvio@big.net.au> Founder of the trade. He used to have classic pieces at his site [18] but removed it for some unknown reason.
John Reiser <jreiser@BitWagon.com> Found one bug and two superfluous bytes in The language of evil[ABC]. Proved that I can't code a straight 23 byte "Hello World".
paddingx Contributed technical details and implementation for Additional code segments[ABC] and Doing it in C[ABC].
Rick Moen <rick@linuxmafia.com> Has a very inspiring site. [19] And I shamelessly quote him in the abstract.
SourceForge.net "The world's largest Open Source software development website" [20] . Their compile farm is dreams come true.
A lot of people helped me shape language and ethical position of this document (sorted by perl, blame Larry): Charles Curley, Dave Wreski, David Merrill, Gary Lawrence Murphy, Greg Ferguson, Harald Wagener, Ian Turner, Marinho Paiva Duarte, Martin Wheeler, QuickFox of kuro5hin, Steve Sanfratello.
Feedback is most certainly welcome for this document. Please send your additions, comments, criticisms, flames and "contributions" to the following email address: <alexander.bartolich@gmx.at>
A few people sent me executables for that other operating system. I am very grateful for this kindness. But you should know that this document is about ELF only.
| [1] | This document also uses a lot shell scripts to automate things. "Rute User's Tutorial and Exposition" includes a fast introduction: http://rute.sourceforge.net/node23.html Excellent stuff is "Advanced Bash-Scripting Guide": http://en.tldp.org/LDP/abs/html/index.html |
| [2] | |
| [3] | This is not a prediction on the future of FreeBSD and Solaris. I doubt that viruses will have much influence on their fate, though. |
| [4] | |
| [5] | |
| [6] | |
| [7] | http://www.catb.org/~esr/jargon/html/entry/Trojan-horse.html |
| [8] | The most famous worm ever was coded by R. H. Morris. The story of "The Internet Worm of 1988" is at http://world.std.com/~franl/worm.html. Another batch of files is at ftp://coast.cs.purdue.edu/pub/doc/morris_worm. |
| [9] | Does history repeat itself? http://online.securityfocus.com/archive/1/308306/2003-01-22/2003-01-28/0, http://www.techie.hopto.org/sqlworm.html and http://www.cs.berkeley.edu/~nweaver/sapphire/. There are speculations that this worm without serious payload was deliberately released to force worldwide application of the patch Microsoft released a full six months ago. http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=2877978&forum_id=37780 (German) |
| [10] | |
| [11] | |
| [12] | http://www.catb.org/~esr/jargon/html/entry/buffer-overflow.html |
| [13] | On ext2 file systems this is chattr. On FreeBSD there is chflags. |
| [14] | |
| [15] | VLAD (Virus Laboratory And Distribution), a group originating in Australia, dissolved in 1996. See http://vx.netlux.org/dat/gv05.shtml |
| [16] | |
| [17] | |
| [18] | |
| [19] | |
| [20] |