If you use Linux on your desktop, you may wonder if you're susceptible to those pesky software infections known as viruses, worms, and trojans. Well, like the doctor says, "There's good news, and there's bad news." Read this feature to learn your prognosis.
If you use GNU/Linux as your desktop (GNU/Linux because most distributions include the Linux kernel and countless other applications and utilities), you may have wondered from time to time, “Am I safe from viruses?” Well, as your doctor might say, there’s good news and bad news.
The good news is that your Linux system is largely safe from “infection.” You certainly don’t need to run out and buy an anti-virus product for your distro. (Yes, there are a few such products available. For example, Lindows offers VirusSafe by Vexira/Central Command and a subscription for virus signature updates for about thirty bucks.)
The bad news is that GNU/Linux isn’t bulletproof. Some viruses have targeted GNU/Linux, and crackers have found ways to exploit vulnerabilities in some significant software packages such as Apache.
Let’s take a look at viruses, examine how they work, and learn how to practice “safe computing.” With just a few simple steps, you can inoculate your computer and your data against whatever’s goin’ around.
Malware, Trojans, and “I Love You”
When most people think of viruses, software nasties like “I Love You” come to mind. While “I Love You” was indeed a virus, malicious software or malware comes in a number of different forms and serves many different purposes.
Typically, a program is classified a virus when it infects other executables directly, spreads automatically to other files or even to other systems, and carries a payload. The virus payload can do something fairly harmless, like print a message to the screen on a particular date, or it can be more malicious, destroying data or capturing and transmitting sensitive information to the creator of the virus. Infection, replication, and payload are the hallmarks of viruses.
Trojans, named after the famous Trojan Horse, are malicious programs intentionally disguised as harmless or innocuous. At face value, trojans may have some useful purpose, but their real intent is far more insidious. For example, a screen saver could be beautiful, but could also contain a secondary application that compromises your system whenever the screen saver runs.
Worms are yet another form of malware and are the baddies you need to be most concerned with when using GNU/ Linux. Worms are a type of virus that don’t actually have to infect a file or program to sneak their way into your system. Instead, they exploit weaknesses in running services like Apache or sendmail, then spread to other systems using the compromised service as a conduit.
Also becoming increasingly popular, at least on Windows, is what many people call annoyware and spyware. Annoyware is any application (or trojan) that throws pop-ups at you (or otherwise annoys you) while you’re surfing. Spyware is software that usually runs in the background and sends information about you — maybe your surfing habits or information about your system — back to a third-party.
Autopsy of A Successful Virus
Even as recently as ten years ago, viruses spread almost solely through physical media, say, a floppy disk or a CD-ROM. Back then, viruses propagated when a gullible or careless user (or business) unwittingly transferred an infected file from one system to another. Surely, an infected system could be catastrophic, but even when a system did get infected, the damage was usually localized — after all, most computers of that time were largely disconnected from one another.
However, with the increasing popularity of the Internet and “always-on” connections, malware now propagates around the globe just as easily as it runs rampant around one office. Viruses that target and infect remote systems are now the norm.
One of the most infamous viruses was “Slapper,” a worm, and the only malware (yet) to have a major impact on GNU/ Linux systems.
Slapper exploited a buffer overflow vulnerability in the OpenSSL libraries on systems running Apache with mod_ssl. Slapper didn’t exploit GNU/Linux per se; it exploited a popular piece of software commonly found on GNU/Linux systems. Other services that used the same versions of the OpenSSL libraries were also theoretically vulnerable.
The goal of Slapper was to infect a system and then re-use that system in subsequent distributed denial of service (DDoS) attacks. (Actually, there were three variations of Slapper; see the sidebar “Corrupt Cargo” for more information.) Of course, Slapper also aimed to propagate itself: once a system was infected with Slapper, it looked for other systems to infect by sending an HTTP request on port 80 to random IP addresses. If the HTTP response indicated that a system was vulnerable, Slapper would begin an attack on port 443, the port used for HTTPS. (Besides a vulnerable mod_ssl, Slapper also required a C compiler; otherwise, the worm would fail to compile itself and replicate.)
After being infected, compromised systems would wait for commands from a central “worm control” to carry out DDoS attacks, and would also retransmit “orders” to other infected hosts. The DDoS attacks included TCP, DNS, and UDP flooding of targeted hosts.
Slapper was incredibly successful — rather, nefarious — because it targeted a vulnerable software package that was widely deployed, and because it spread autonomously.
Viruses spread in a number of different ways. For a while, SMTP viruses were very popular, spreading themselves via vulnerable mail clients (usually Outlook) to infect other machines and propagate themselves further. The “SQL Slammer” worm (not to be confused with the similar-sounding Slapper) that plagued Microsoft SQL Server machines used vulnerable versions of SQL Server to spread to other SQL Server machines that were also vulnerable.
Slapper and Slammer each exploited a vulnerability in a program with a relatively large installed base. Without a large enough breeding ground, a virus can’t be very successful. The reason that exploits against Outlook have been so successful is not just because the program itself is vulnerable. It’s also because Outlook is so ubiquitous, giving Outlook viruses a perfect breeding ground. To contrast, imagine a piece of malware that exploits a vulnerability in workstations running OS/2 Warp. Assuming that the goal of the virus writer is to attack a large number of machines, there’s very little payoff in writing a virus to attack OS/2.
In addition to a breeding ground, a virus can be successful only if it can spread its payload relatively quickly, before word about the infection and antidotes also spreads. Consider the Slapper worm. It managed to infect a fair number of machines in a short period of time before the community became widely aware of the problem. A virus that spreads too slowly will be nipped in the bud before it can infect a sizeable number of machines.
GNU/Linux server farms are a potential breeding ground for GNU/Linux viruses if a virus is able to exploit Apache or another popular server application. On the other hand, Linux desktop users are fairly secure. Why? The simple answer is diversity. While many people complain about too many window managers, desktop environments, mail clients, browsers, and so forth — the fact is that the diversity of Linux desktop systems makes it much harder to write exploits that can infect a large installed base of Linux machines. An exploit that targets Evolution, for example, isn’t likely to have any effect against Kmail, Pine, or Mutt.
Corrupt Cargo: Slapper’s Payload
Some viruses are harmless, while some can wreak serious damage. Slapper could have been a serious threat.
There were at least three known variants of Slapper: the payloads of each variant were very different.
* One variant had no discernable payload, perhaps just a proof of concept to make sure that the worm worked before the author added a significant payload.
* The second variant would overwrite files on the system and schedule the virus to run every so often. This particular variant would also collect information about the system it’d infected and send it to an e-mail address.
* The final variant attempted to provide a shell to a remote attacker.
The latter variant is a worst-case scenario: a worm that provides a backdoor for another, perhaps human, attacker to creep in.
Don’t Forget Your Shots: Protecting Yourself from Viruses
GNU/Linux viruses are fairly uncommon, but viruses are only one form of exploit, so there’s no reason to take chances.
Here are some “eat your vegetables,” common sense tips for “safe computing:”
* First and foremost, if you’re a desktop user, resist the temptation to use your system as root at all times. If you’re root, you’re just begging for trouble — even without the threat of viruses and other malware.
* Next, download packages only from trusted sources, and be sure to check MD5 sums and GPG/PGP signatures (when available). It is possible to compromise an FTP server and upload a trojan package that contains a vulnerability or worse. Checking MD5 sums is the best way to avoid trojans. When you download a package, most sites will have a MD5 sum that should match up with the package. If you download from a mirror, be sure that the mirror and the official site (say, Red Hat’s website) agree on the MD5 sum for the package. Then, run md5sum packagename and wait a few seconds. If the sum doesn’t match what’s posted on the official site, you don’t want to use that package.
* Shut down any service that you don’t need. If you don’t need a web server, don’t run Apache; if you don’t serve your own domain names, don’t have BIND running; and so forth. Make sure that xinetd (or inetd) doesn’t provide insecure or unnecessary services. After all, a service that isn’t running and isn’t available can’t be exploited.
* Be sure to block all ports that aren’t in use. This suggestion may seem like “Security 101,” but it’s also something that keeps tripping people up.
* If you’re running a server, remove the compilers from the system after you’ve finished configuring it. For example, if you’re running a web server on a particular system, remove gcc from that system after you’ve installed and configured everything. Remove it so that even if an attacker gains access, he or she (or it) won’t be able to compile anything to help further subvert the system.
* Finally, instead of installing anti-virus software, you might consider an intrusion detection system (IDS). Instead of trying to scan for files that might contain a virus, an IDS monitors the system for changes and reacts in a number of ways if something suspicious happens. An IDS is an early warning system that alerts you to attacks on your system — in many cases, an IDS can alert you before an attack has been successful. There are a number of IDS for Linux, though Tripwire seems to be one of the most popular choices.
You may also want to configure your mail server to strip out attachments that are likely to contain viruses — particularly if you’re on a mixed network with Windows machines or if you’re running something like CodeWeavers Wine. (Can your system be compromised via Wine? See the sidebar, “Any Weakness in Wine?” for details.) It’s possible that a Word document, for example, that contains a macro virus might just work under Wine as well as under Windows. While that might be a technical success for CodeWeavers, it’s not fun for you.
Almost every Linux distribution has a security mailing list to alert users to security exploits and security patches. Whether you administer one Linux machine or one hundred, make absolutely sure you sign up for that list and pay attention to the announcements. Read the security advisories, and patch your machines — all your machines — when a serious exploit is fixed.
Use Common Sense
Most precautions against infection are common sense and are general security measures that should be implemented regardless. Don’t forget that viruses aren’t the only security threat to a computer. Just because an exploit doesn’t lend itself to viral distribution, that doesn’t mean it doesn’t exist, or that it’s not dangerous.
Also, viruses are usually distributed in part to make a kind of public statement. If someone wants to leverage an exploit to break into a system and steal credit card numbers (for example), he or she may do that very quietly, without trying to draw attention.
So, if you’re using, or are thinking about using Linux on the desktop, don’t sweat viruses and don’t spend your hard earned cash on an anti-virus solution you’re unlikely to need. Instead, take an hour or two to make sure you’re practicing safe computing. If you system has had all of its shots, you needn’t worry about pesky viruses.
The Wine project is trying to create an implementation of the Windows API on top of X and Unix-type operating systems (not just GNU/Linux). To make Windows applications run correctly, Wine must emulate the behavior of Windows perfectly — even the bugs. So, does that mean that GNU/ Linux and Wine are vulnerable to the same malware that Windows is vulnerable to?
The answer, unfortunately, is yes — to some extent. If a virus exploits a vulnerability in a Windows application, take Outlook for example, it’s possible that it may work when running Outlook on GNU/Linux. The effects may be different, depending on what the virus was designed to do, what services it exploits and what its payload is, but just running an application on GNU/Linux under Wine doesn’t make it secure automatically. Unfortunately.
The “Sir Cam” virus, for example, runs under Wine. However, Sir Cam can’t quite operate the same way as it works on Windows, because it can’t create registry entries to launch itself when a machine reboots. However, that doesn’t mean that future viruses won’t find a way around the problem.
If you’re running Windows applications under Wine, be cautious of opening attachments, just as you would when using Windows.
Joe “Zonker” Brockmeier is a freelance technology journalist who’s been using GNU/Linux since 1996, and has been writing about it nearly as long. Zonker has contributed to several books on GNU/Linux and Open Source-related projects, and writes regularly for
Linux Magazine, UnixReview.com and a number of other publications. You can contact Zonker at http://www.dissociatedpress.net.
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62