Viruses in GNU / Linux: Fact or Myth?

Whenever the debate over Virus y GNU / Linux it doesn't take long for the user to appear (usually Windows) what does it say:

«In Linux there are no viruses because the creators of these malicious programs do not waste time doing something for an Operating System that almost nobody uses »

To which I have always replied:

"The problem is not that, but the creators of these malicious programs will not waste time creating something that will be corrected with the first update of the system, even in less than 24 hours"

And I was not wrong, as this excellent article published in the Issue 90 (Year 2008) from Todo Linux Magazine. His actor david santo orcero provides us in a technical way (but easy to understand) the explanation why GNU / Linux lacks this type of malicious software.

100% recommended. Now they will have more than convincing material to silence anyone who speaks without a solid basis on this subject.

Download Article (PDF): Myths and Facts: Linux and Viruses

EDITED:

Here is the transcribed article, as we consider that it is much more comfortable to read in this way:

================================================== ======================

The Linux and virus debate is not new. Every so often we see an email on a list asking if there are viruses for Linux; and automatically someone answers affirmatively and claims that if they are not more popular it is because Linux is not as widespread as Windows. There are also frequent press releases from antivirus developers saying that they release versions of Linux viruses.

Personally, I have had the occasional discussion with different people by mail, or by distribution list, regarding the issue of whether or not viruses exist in Linux. It is a myth, but it is complex to demolish a myth or, rather, a hoax, especially if it is caused by economic interest. Someone is interested in conveying the idea that if Linux does not have these kinds of problems, it is because very few people use it.

At the time of publishing this report I would have liked to write a definitive text on the existence of viruses in Linux. Unfortunately, when superstition and economic interest run rampant, it is difficult to build something definitive.
However, we will try to make a reasonably complete argument here to disarm the attacks of anyone who wants to argue.

What is a virus?

First of all, we are going to start by defining what a virus is. It is a program that copies and runs automatically, and that aims to alter the normal functioning of a computer, without the user's permission or knowledge. To do this, viruses replace executable files with others infected with their code. The definition is standard, and is a one-line summary of the Wikipedia entry on viruses.
The most important part of this definition, and the one that differentiates the virus from other malware, is that a virus installs itself, without the user's permission or knowledge. if it does not install itself, it is not a virus: it could be a rootkit, or a Trojan.

A rootkit is a kernel patch that allows you to hide certain processes from user area utilities. In other words, it is a modification of the kernel source code whose purpose is that the utilities that allow us to see what is running at any given time do not display a certain process, or a certain user.

A Trojan is analogous: it is a modification to the source code of a specific service to hide certain fraudulent activity. In both cases, it is necessary to obtain the source code of the exact version installed on the Linux machine, patch the code, recompile it, obtain administrator privileges, install the patched executable, and initialize the service –in the case of the Trojan– or the operating system. complete - in the case of
rootkit–. The process, as we see, is not trivial, and no one can do all this "by mistake". Both of them require in their installation that someone with administrator privileges, consciously, execute a series of steps making decisions of a technical nature.

Which is not an unimportant semantic nuance: for a virus to install itself, all we have to do is run an infected program as a common user. On the other hand, for the installation of a rootkit or a Trojan it is essential that a malicious human personally enters the root account of a machine, and in a non-automated way, performs a series of steps that are potentially detectable. a virus spreads quickly and efficiently; a rootkit or a trojan needs them to go after us specifically.

Virus transmission on Linux:

The transmission mechanism of a virus, therefore, is what really defines it as such, and is the basis for their existence. an operating system is more sensitive to viruses the easier it is to develop an efficient and automated transmission mechanism.

Suppose we have a virus that wants to spread itself. Suppose it has been launched by a normal user, innocently, when launching a program. This virus has exclusively two transmission mechanisms:

• Replicate itself by touching the memory of other processes, anchoring itself to them at runtime.
• Opening the filesystem executables, and adding their code –payload– to the executable.

All viruses that we can consider as such have at least one of these two transmission mechanisms. O The two. There are no more mechanisms.
Regarding the first mechanism, let's remember the virtual memory architecture of Linux and how intel processors work. These have four rings, numbered from 0 to 3; the fewer the number, the greater the privileges that the code that runs in that ring has. These rings correspond with states of the processor, and, therefore, with what can be done with a system being in a specific ring. Linux makes use of ring 0 for the kernel, and ring 3 for processes. there is no process code that runs on ring 0, and there is no kernel code that runs on ring 3. There is only a single entry point to the kernel from ring 3: the 80h interrupt, which allows jumping from the area where it is the user code to the area where the kernel code is.

The architecture of Unix in general and Linux in particular does not make the spread of viruses feasible.

The kernel by using virtual memory makes each process believe that it has all the memory to itself. A process –which works in ring 3– can only see the virtual memory that has been configured for it, for the ring in which it operates. It is not that the memory of the other processes is protected; is that for one process the memory of the others is outside the address space. If a process were to beat all memory addresses, it would not even be able to reference a memory address of another process.

Why can't this be cheated?
To modify what has been commented –for example, generate entry points in ring 0, modify interrupt vectors, modify virtual memory, modify LGDT… - it is only possible from ring 0.
That is, for a process to be able to touch the memory of other processes or the kernel, it should be the kernel itself. And the fact that there is a single entry point and that the parameters are passed through registers complicates the trap - in fact, what is to be done is passed by register, which is then implemented as a case in the attention routine. the 80h interruption.
Another scenario is the case of operating systems with hundreds of undocumented calls to ring 0, where this is possible - there can always be a poorly implemented forgotten call on which a trap can be developed - but in the case of an operating system with such a simple step mechanism, it is not.

For this reason, the virtual memory architecture prevents this transmission mechanism; no processes - not even those with root privileges - have a way to access the memory of others. We could argue that a process can see the kernel; it has it mapped from its logical memory address 0xC0000000. But, because of the processor ring that it runs on, you can't modify it; would generate a trap, since they are memory areas that belong to another ring.

The "solution" would be a program that modifies the kernel code when it is a file. But the fact that these are recompiled makes it impossible. The binary cannot be patched, as there are millions of different binary kernels in the world. Simply that when recompiling it they had put or removed something from the kernel executable, or they had changed the size of one of the labels that identify the compilation version - something that is done even involuntarily - the binary patch could not be applied. The alternative would be to download the source code from the Internet, patch it, configure it for the appropriate hardware, compile it, install it, and reboot the machine. All this should be done by a program, automatically. Quite a challenge for the field of Artificial Intelligence.
As we can see, not even a virus as root can jump this barrier. The only solution left is the transmission between executable files. Which does not work either as we will see below.

My experience as an administrator:

In more than ten years that I have been managing Linux, with installations on hundreds of machines in data centers, student laboratories, companies, etc.

• I have never gotten a virus
• I have never met someone who has
• I have never met someone who has met someone who has

I know more people who have seen the Loch Ness Monster than have seen Linux viruses.
Personally, I admit that I have been reckless, and I have launched several programs that the self-proclaimed "specialists" call "viruses for Linux" - from now on, I will call them viruses, not to make the text pedantic -, from my usual account against my machine, to see if a virus is possible: both the bash virus that circulates around there - and which, by the way, did not infect any files - and a virus that became very famous, and appeared in the press. I tried to install it; and after twenty minutes of work, I gave up when I saw that one of his demands was to have the tmp directory on a partition of the MSDOS type. Personally, I don't know of anyone who creates a specific partition for tmp and formats it to FAT.
In fact, some so-called viruses that I have tested for Linux require a high level of knowledge and the root password to be installed. We could qualify, at the very least, as "crappy" a virus if it needs our active intervention to infect the machine. Furthermore, in some cases they require extensive knowledge of UNIX and the root password; which is quite far from the automatic installation that it is supposed to be.

Infecting executables on Linux:

On Linux, a process can simply do what its effective user and effective group allow. It is true that there are mechanisms to exchange the real user with cash, but little else. If we look at where the executables are, we will see that only root has write privileges both in these directories and in the contained files. In other words, only root can modify such files. This has been the case in Unix since the 70s, in Linux since its origins, and in a file system that supports privileges, no error has yet appeared that allows other behavior. The structure of the ELF executable files is known and well documented, so it is technically possible for a file of this type to load the payload in another ELF file ... as long as the effective user of the first or the effective group of the first have access privileges. reading, writing and execution on the second file. How many filesystem executables could it infect as a common user?
This question has a simple answer, if we want to know how many files we could "infect", we launch the command:

$ find / -type f -perm -o=rwx -o \( -perm -g=rwx -group `id -g` \) -o \( -perm -u=rwx -user `id -u` \) -print 2> /dev/null | grep -v /proc

We exclude the / proc directory because it is a virtual filesystem that displays information about how the operating system works. The file type files with execution privileges that we will find do not pose a problem, since they are often virtual links that appear to be read, written and executed, and if a user tries it, it never works. We also discard errors, plentiful - since, especially in / proc and / home, there are many directories where a common user cannot enter -. This script takes a long time. In our particular case, in a machine where four people work, the answer was:

/tmp/.ICE-unix/dcop52651205225188
/tmp/.ICE-unix/5279
/home/irbis/kradview-1.2/src
/kradview

The output shows three files that could be infected if a hypothetical virus were run. The first two are Unix socket type files that are deleted at startup –and cannot be affected by a virus–, and the third is a file of a development program, which is deleted every time it is recompiled. The virus, from a practical point of view, would not spread.
From what we see, the only way to spread the payload is by being root. In this case, for a virus to work, users must always have administrator privileges. In that case, it can infect files. But here's the catch: to spread the infection, you need to take another executable, mail it to another user who only uses the machine as root, and repeat the process.
In operating systems where it is necessary to be an administrator for common tasks or to run many daily applications, this can be the case. But in Unix it is necessary to be an administrator to configure the machine and modify the configuration files, so the number of users that the root account uses as a daily account is small. It's more; some Linux distributions don't even have the root account enabled. In almost all of them, if you access the graphical environment as such, the background changes to intense red, and constant messages are repeated to remind you that this account should not be used.
Finally, everything that has to be done as root can be done with a sudo command without risk.
For this reason, in Linux an executable cannot infect others as long as we are not using the root account as the common use account; And although antivirus companies insist on saying that there are viruses for Linux, really the closest thing that can be created in Linux is a Trojan in the user area. The only way that these Trojans can affect something on the system is by running it as root and with the necessary privileges. If we usually use the machine as ordinary users, it is not possible for a process launched by a common user to infect the system.

Myths and lies:

We found a lot of myths, hoaxes, and just plain lies about viruses in Linux. Let's make a list of them based on a discussion that took place some time ago with a representative of a manufacturer of antivirus for Linux who was very offended by an article published in this same magazine.
That discussion is a good reference example, as it touches on all aspects of viruses in Linux. We are going to review all these myths one by one as they were commented on in that specific discussion, but which has been repeated so many times in other forums.

Myth 1:
"Not all malicious programs, particularly viruses, need root privileges to infect, especially in the particular case of executable viruses (ELF format) that infect other executables".

Answer:
Whoever makes such a claim does not know how the Unix privilege system works. In order to affect a file, a virus needs the privilege of reading –it must be read to modify it–, and writing –it must be written for the modification to be valid– on the executable file it wants to execute.
This is always the case, without exceptions. And in each and every one of the distributions, non-root users do not have these privileges. Then simply with not being root, the infection is not possible. Empirical test: In the previous section we saw a simple script to check the range of files that can be affected by an infection. If we launch it on our machine, we will see how it is negligible, and with respect to system files, null. Also, unlike operating systems such as Windows, you do not need administrator privileges to perform common tasks with programs commonly used by normal users.

Myth 2:
"Nor do they need to be root to enter the system remotely, in the case of Slapper, a worm that exploiting a vulnerability in Apache's SSL (the certificates that allow secure communication), created its own network of zombie machines in September 2002".

Answer:
This example does not refer to a virus, but a worm. The difference is very important: a worm is a program that exploits a service for the Internet to transmit itself. It does not affect local programs. Therefore, it only affects servers; not to particular machines.
The worms have always been very few and of negligible incidence. The three really important ones were born in the 80s, a time when the Internet was innocent, and everyone trusted everyone. Let's remember that they were the ones that affected sendmail, fingerd and rexec. Today things are more complicated. Although we cannot deny that they still exist and that, if left unchecked, they are extremely dangerous. But now, reaction times to worms are very short. This is the case of the Slapper: a worm created on a vulnerability discovered - and patched - two months before the appearance of the worm itself.
Even assuming that everyone using Linux had Apache installed and running all the time, simply updating the packages monthly would have been more than enough to never run any risk.
It is true that the SSL bug that Slapper caused was critical - in fact, the biggest bug found in the entire history of SSL2 and SSL3 - and as such was fixed within hours. That two months after this problem was found and solved, someone made a worm on a bug that has already been corrected, and that this is the most powerful example that can be given as a vulnerability, at least it reassures.
As a general rule, the solution to worms is not to buy an antivirus, install it and waste computing time keeping it resident. The solution is to make use of the security update system of our distribution: having the distribution updated, there will be no problems. Running only the services we need is also a good idea for two reasons: we improve the use of resources, and we avoid security problems.

Myth 3:
"I don't think the core is invulnerable. In fact, there is a group of malicious programs called LRK (Linux Rootkits Kernel), which are based precisely on the fact that they exploit vulnerabilities in kernel modules and replace the system binaries.".

Answer:
A rootkit is basically a kernel patch that allows you to hide the existence of certain users and processes from the usual tools, thanks to the fact that they will not appear in the / proc directory. The normal thing is that they use it at the end of an attack, in the first place, they will exploit a remote vulnerability to gain access to our machine. Then they will undertake a sequence of attacks, to escalate privileges until they have the root account. The problem when they get it is how to install a service on our machine without being detected: that's where the rootkit comes in. A user is created that will be the effective user of the service that we want to hide, they install the rootkit, and they hide both said user and all the processes belonging to said user.
How to hide the existence of a user is useful to a virus is something that we could discuss at length, but a virus that uses a rootkit to install itself seems fun. Let's imagine the mechanics of the virus (in pseudocode):
1) The virus enters the system.
2) Locate the kernel source code. If it is not, he installs it himself.
3) Configure the kernel for the hardware options that apply to the machine in question.
4) Compile the kernel.
5) Install the new kernel; modifying LILO or GRUB if necessary.
6) Reboot the machine.

Steps (5) and (6) require root privileges. It is somewhat complicated that steps (4) and (6) are not detected by the infected. But the funny thing is that there is someone who believes that there is a program that can do step (2) and (3) automatically.
As a culmination, if we meet someone who tells us "when there are more Linux machines there will be more viruses", and recommends "having an antivirus installed and updating it constantly", possibly it is related to the company that markets the antivirus and updates . Be wary, possibly the same owner.

Antivirus for Linux:

It is true that there are good antivirus for Linux. The problem is, they don't do what antivirus advocates argue. Its function is to filter the mail that passes from malware and viruses to Windows, as well as to verify the existence of Windows viruses in folders exported via SAMBA; so if we use our machine as a mail gateway or as a NAS for Windows machines, we can protect them.

Clam-AV:

We will not finish our report without talking about the main antivirus for GNU / Linux: ClamAV.
ClamAV is a very powerful GPL antivirus that compiles for most of the Unix available on the market. It is designed to analyze attachments to mail messages passing through the station and filter them for viruses.
This application integrates perfectly with sendmail to allow the filtering of viruses that can be stored in the Linux servers that provide mail to companies; having a virus database that is updated daily, with digital support. The database is updated several times a day, and it is a lively and very interesting project.
This powerful program is capable of analyzing viruses even in attachments in more complex formats to open, such as RAR (2.0), Zip, Gzip, Bzip2, Tar, MS OLE2, MS Cabinet files, MS CHM (HTML Coprinted), and MS SZDD.
ClamAV also supports mbox, Maildir, and RAW format mail files, and Portable Executable files compressed with UPX, FSG, and Petite. The Clam AV and spamassassin pair are the perfect pair to protect our Windows clients from Unix mail servers.

CONCLUSION

To the question Are there vulnerabilities in Linux systems? the answer is certainly yes.
No one in their right mind doubts it; Linux is not OpenBSD. Another thing is the vulnerability window that a Linux system has that is properly updated. If we ask ourselves, are there tools to take advantage of these security holes, and exploit them? Well, yes, but these are not viruses, they are exploits.

The virus must overcome several more difficulties that have always been put as a Linux flaw / problem by Windows defenders, and that complicate the existence of real viruses - kernels that are recompiled, many versions of many applications, many distributions, things that they are not automatically passed transparently to the user, etc.–. The current theoretical "viruses" must be installed manually from the root account. But that cannot be considered a virus.
As I always tell my students: don't believe me, please. Download and install a rootkit on the machine. And if you want more, read the source code of the "viruses" on the market. The truth is in the source code. It is difficult for a "self-proclaimed" virus to keep naming it that way after reading its code. And if you don't know how to read code, a single simple security measure that I recommend: use the root account only to manage the machine, and keep security updates up to date.
Only with that it is impossible for viruses to enter you and it is very unlikely that worms or someone will attack your machine successfully.