-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Apologies for length of this mail but the issue is not simple... I am getting the impression that the *NIX community is moving into new territory here and some of the discussion does seem to show a lack of awareness of the nature of the current threat in terms of Linux and Windows. This is a little ironic as some of the original inspiration for the early DOS viruses came from some of the antics of early UNIX hackers, and some of the original (legitimate?) research on self replicating automata was also performed on the platform. Many years ago (just after the Flood ) I was a minor part of the group charged with assessing AV products for recommendation to the UK academic community, So I know a little about the subject. To start, three points... Firstly there is no bulletproof way to determine whether a system has been compromised by a virus or other malware. Secondly, the virus, or trojan (or worm) to really worry about is the one you do not know about. Thirdly AV protection is more about avoiding the embarrassment of being caught out by something we do know about than anything else. When one is told a system is virus free what really is being said that nothing that we know about has been detected. Even then the most reliable results on determining whether a system has been compromised are only to be found on a cold system examined by a read only trusted bootable media booted from that media (a cold scan). Compromises with stealth capabilities are unlikely to be detected reliably on a running system and can be dangerous to attempt to remove while the system is running. BTW If one is connecting a writeable device to an untrusted machine without cold scanning it first, you will always be a taking a risk. (I am still slightly bemused by the number of experienced technical support people who bypass this precaution). Signature based scanning has had its critics for quite some time, and the first weaknesses showed up with the early polymorphic and stealth viruses in the early 90s. Heuristic scanning that looks for code patterns which may not be benign rather than strings of bytes has the potential to detect potential new threats (at the cost of a slightly higher risk of false positives). The two approaches used in conjunction give a very good chance of recognising code that may not be benign, but usually have a somewhat heavier performance payload. Tools such as AppArmor have a part in a non development environment but have the potential to be problematic in a development environment. The role this tool is somewhat different in any case. If one looks at the classes of virus that exist and the normal vectors for those viruses in the context of *NIX systems one can get an overview of the probable real risks involved. Binary viruses are usually OS specific and new variants are relatively rare nowadays. However, there is no reason that these cannot be developed for Linux systems. As binary viruses require good technical knowledge and are hard to write 'script kiddies' are unlikely to have either the skills or patience to write these when easier options are available. Professional criminal authors are a different story. Macro viruses are almost exclusively application specific, early on M$, WordPerfect, CA, Lotus and others incorporated mechanisms for office applications to interact with the host OS and filesystem with a script autoloading facility. It took a little while to realise what a big mistake some of this was. Unfortunately, by the time the mistake had been realised it proved to be difficult for the genie to be put back in the bottle for a variety of reasons. Macro viruses will be a problem across platforms *iff* system calls are generalised and things like path naming are standardised. (Open Office is moving down this route). With the advent of malware scripting toolkits the number of script based viruses has exploded (but AFAIK most of the toolkits have signature components that can be used identify the results of their products). These are the preferred tools of 'script kiddies' and the criminal community because of the ease of production, but the product is potentially easier to identify. In the M$ world the scripting component of a compromise is more usually a dropper which changes COM configuration and registry settings, the script does not normally propagate itself but is propagated by the components it installs. This is also the architectural vulnerability most often exploited by most known mail WORM or browser based attacks. (M$ have taken some measures to block these particular holes but in such a manner that some of their user community seem to spend a lot of effort circumventing the effects of this protection). The *NIX architecture is radically different and does not have an equivalent security hole and the usual constraints on the privileges afforded to scripts are such that the threat should be minimal, but that is not to say that a dropper script is not a theoretical possibility with *NIX. The ability for these viruses to compromise a Linux system at the system level would be more related to bad security practices or malicious intent by someone already on the system rather than any weakness inherent to the *NIX system model. Using a Linux to host Windows clients networked filestore is in this context a very good idea as the server if properly secured will effectively be in a position to perform a cold scan of Windows files. (Something that would be questionable on a Windows Server). But on-access scanning ideally should be restricted to the results of write operations on the windows client filestore (some admins apply on-access scanning in a fairly indiscriminate manner). The scanner software selected should also have been properly assessed by an independent body, and at this moment in time one of the most popular linux based scanners (ClamAV) appears to have never been submitted to such an assessment. The comments on the ClamAV website about this are not very reassuring. see http://www.clamav.net/index.php?s=linuxworld (It does do other things but as an AV tool at this moment in time it is of questionable value and probably should be supplemented with something else). Boot sector viruses are a very different issue, on server class machines which are rarely rebooted or booted from untrusted media the risk is probably minimal. On client workstations (particularly multi-boot systems) these still have the potential to be a major threat. One surprise is that AFAIK no-one has written a successful compromise to GRUB or LILO (but give it time). As boot sector virus payload become active before the OS takes control of the system, the system can potentially be compromised before the OS and its security provisions are in place. (Conventional BIOS related protection which always has been weak is unlikely to be useful in more complex modern partitioning setups in blocking this particular attack). The original vector for infection is by having infected media on a device which is checked in the boot sequence (and the infected media does not itself have to be bootable). This can usually be easily blocked by changing the boot sequence. However, there was and is a class of multi-vector viruses in the DOS world which propagated by both boot sector and file infections so there are other possible routes for this type of infection to occur. (The NT bootloader sequence was in theory less vulnerable to this type of attack, but I do recall that at least one proof of concept was produced). Again cold scanning is probably the only way of assuring that such an infection has not occurred, however as the contents the boot records should be well defined this should be bulletproof for this threat. It should be noted file system based viruses are something that can be a problem but they are no longer the most serious security threat. Far more dangerous and damaging are the various SQL injection attacks and the resultant compromised web sites dropping or running damaging scripts and applications on client workstations. These are often the result of poor security awareness by non technically orientated PHP web developers. Most linux browsers default settings can make such attacks more difficult on the platform, but only if those in front of the screen act with some sense. - -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIdhFIasN0sSnLmgIRAox7AKDv69GHr2i6GI6bO/KHVXn0I9CW9wCdHJQ0 5zpeXpfaxJp3Y9XhKT9pudo= =Jcfv -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org