White Paper: How to protect your NT system from viruses

The Windows NT system has many features that both protect it from and make it susceptible to virus attack

The Windows NT system has many features that both protect it from and make it susceptible to virus attack

Since NT does not have control of the computer during system boot-up, booting from an infected floppy diskette allows the virus to infect the MBR of any of the physical drives on the system using the usual techniques. This vector of infection is quite common and we can expect to see more of the same.

Dropper programs and multipartite viruses infect the MBR of the hard drive by using BIOS or DOS services to write directly to the hard drive. Since Windows NT prevents all such writes from within Windows NT DOS box, this type of infection will be completely prevented while NT is running. However, if the computer in question also has the ability to boot to DOS or Windows 95, then the user could boot to one of these operating systems and execute the dropper program or multipartite virus normally.

Once a virus is present in the MBR, future system reboots will allow the virus to become memory-resident in the usual fashion. In addition, if the virus contains any type of payload that is triggered during boot-up, this trigger mechanism will function just as it would under a DOS or Windows 95 system. Thus, viruses such as Michelangelo and One-half can still cause significant damage to Windows NT systems.

Upon boot-up, once the virus has installed itself in memory, it passes control to the original system MBR, which then transfers control to the Windows NT boot record. This boot record then loads the Windows NT loader, which loads the rest of the operating system. During this loading process, NT switches into protected mode and installs its own protected-mode disk drivers. These protected-mode drivers are used for all further disk operations. Consequently, the original BIOS disk drivers and any virus that "hooked" into these drivers are never activated or used in any way.

Once Windows NT starts using its own drivers, the resident MBR virus is effectively stopped in its tracks. Furthermore, unlike Windows 95, Windows NT does not support a compatibility mode.

On bootable NTFS partitions, Windows NT places a "boot-strap" operating system loader program on the sectors immediately following the NTFS boot record. When the Windows NT boot record is loaded and executed by the MBR during system boot-up, it immediately re-reads itself and these additional "boot-strap" sectors and transfers control to them. The NTFS boot sector and these additional sectors comprise a "boot-strap" program which is capable of loading and launching the bulk of the Windows NT operating system.

If a boot record virus infects the NTFS boot record, it effectively overwrites the first sector of the multi-sector "boot-strap" program, causing important routines and data to be lost. Consider the NTFS boot-up process with a boot record infection: during the NTFS boot-up, the uninfected MBR loads and transfers control of the active NTFS partition to the viral boot record. The virus then installs itself in memory and transfers control to the original NTFS boot record, which is retrieved from the end of the logical or physical drive where the virus stored it. At this point, a small routine in the NTFS boot record attempts to load the entire NTFS "boot-strap" program (which is comprised of what should be the original NTFS boot record and the following sectors). However, the first sector of the boot strap program has been overwritten by the body of the virus. Thus, a corrupted copy of the "boot-strap" program is loaded and executed. This will result in a system crash and Windows NT will fail to start up.

The bottom line is that most boot record viruses will cause an NTFS-based, Windows NT system to crash during boot-up. However, if the boot record virus has stealthing capabilities, Windows NT may be able to properly load. If the virus has stealth capabilities, when the Windows NT boot record uses these BIOS/virus services to load the NTFS "boot-strap" program, the virus can hide the infected boot record and correctly load the original NTFS boot record along with the other "boot-strap" sectors. Once the proper "boot-strap" program has been loaded, Windows NT can boot-up normally.

During the boot-up process, the uninfected MBR loads and transfers control to the viral boot record of the active NTFS, HPFS or FAT partition. The virus then installs itself in memory and drops any payloads. Finally, the virus boot record loads and transfers control to the original boot record and the boot process continues normally. Once again, Windows NT switches into protected mode and installs its own protected-mode disk drivers. These protected-mode drivers are used for all further disk operations. Consequently, the original BIOS disk drivers and any virus that "hooked" into these drivers are never activated or used in any way. Thus, boot record viruses are disabled in the same fashion as MBR viruses.

Viruses such as Michelangelo and One-half are capable of doing damage during the boot-up process but are completely disabled once Windows NT starts using its protected mode disk drivers. Thus, infection of floppy diskettes or files (in the case of a multipartite virus) will be prevented in all instances (i.e. in DOS boxes, etc.). Viruses that do not save the boot record's BPB information or the MBR's partition table may prevent NT from booting or make certain drives inaccessible. Furthermore, all non-stealthing boot record viruses (such as the Form virus) that infect bootable NTFS partitions will corrupt the operating system "boot-strap" loader and cause Windows NT to crash during boot-up. When booting from an infected floppy diskette, buggy virus infection mechanisms may also cause data loss under all three file systems supported by NT.

In most cases, memory-resident file viruses will stay memory-resident within the confines of a Windows NT DOS box. Once the virus is resident within a given DOS box, it can infect any programs accessed or executed within that DOS box, assuming the user who launched the virus has write access to the target program. The virus will be unable to spread to other DOS boxes as each DOS box has its own protected memory space. However, nothing prevents a user from executing infected programs in several DOS boxes. Thus, several independent copies of the virus can be active and infectious at once. Windows NT faithfully emulates most DOS functionality within its DOS boxes, and in some ways provides more compatible support than Windows 95 DOS boxes. Memory-resident viruses that "hook into" the DOS system services within a DOS box can gain control and infect files any time the system services are used by DOS or other programs.

For example, when a user executes a DOS program on a standard DOS machine (that is, one that does not run Windows AIT or Windows 95), the command shell (for example, COMMAND.COM or NDOS.COM) generates an "EXECUTE PROGRAM" system service request to the DOS kernel. Many viruses intercept this system service to infect program files as they are executed by the user. Windows NT faithfully provides the same functionality in its DOS boxes and allows viruses to intercept this system service and infect at will.

Furthermore, Windows NT allows users to launch native Windows applications directly from the DOS box's command line. Under the NDOS command shell, any Windows program that is launched from the DOS box's command line will cause the NDOS command interpreter to generate an "EXECUTE PROGRAM" system service request. Thus, if a memory-resident virus were to hook into the EXECUTE system service, it could potentially infect these Windows programs as they are executed. However, most DOS viruses are incapable of correctly infecting native Windows executable programs. Interestingly, the default command shell (CMD.EXE) that ships with Windows NT does not generate the "EXECUTE" system service request when Windows executables are launched from a DOS box; thus, memory-resident computer viruses will be unable to infect native Windows programs launched from a "COMMAND.COM"-based NT DOS box.

Windows NT does provide file-level access control that will prevent protected files from becoming modified by DOS-based file viruses. The access control provided by Windows NT is significantly more robust than DOS's simple read-only attribute and cannot be bypassed by DOS programs. However, if an infected program is run by a system operator with root privileges, or the Windows NT system is set up without access control, the virus can modify all files to which the operator has access.

If we assume that the typical Windows NT configuration does not employ Windows NT's security features, then viruses will be able to damage files just as they did on a standard MS-DOS system. For instance, viruses that corrupt program files unintentionally during the infection process will still be able to do so under Windows NT DOS boxes. However, file viruses that attempt to "trash" the hard drive using direct disk access will be thwarted under Windows NT, since all direct access to hard drives is prevented by Windows NT.

While Windows NT does prevent DOS programs from writing directly to hard drives, it does not prevent DOS programs from directly writing to floppy diskettes. Thus, multipartite DOS viruses, launched from within a DOS box, may infect or damage floppy diskettes. However, most multipartite viruses, when launched from an infected DOS program, attempt to infect the hard drive's MBR or boot record to gain control during boot-up. Since Windows NT will prevent these direct disk writes from within a DOS box, these viruses are likely be neutered.

Should one of the files responsible for Windows NT boot-up become infected with a DOS-based computer virus, Windows NT will most likely be unable to load properly. This is because DOS-based viruses require the DOS kernel and other "real-mode" data structures to function and these data structures are necessarily absent during Windows NT boot-up (since NT does not use DOS in its operation). The absence of the DOS kernel during the boot-up process will probably cause any infected executable to crash once the virus begins executing.

Most DOS file viruses should propagate under Windows NT DOS boxes, just as they do on standard DOS systems. The built-in Windows NT file and directory protection will prevent infection of protected files. However, the system must be explicitly configured to provide this protection. Unfortunately, many users may be unaware of or inconvenienced by this protection and disable it.

Multipartite viruses (viruses that infect both files and boot sectors) will no longer be able to infect hard drive boot records or master boot records from within DOS boxes. If the virus relies upon this behavior for propagation, it will be neutered by Windows NT's direct-disk access restrictions. However, multipartite file viruses will still be able to infect floppy diskette boot records if they are so inclined (although this behavior is rare).

DOS file viruses will function only within DOS boxes. While it is possible that native Windows NT system files may become infected (by direct-action viruses that go searching for files all over the hard drive), the infected system files will most likely fail to function properly and crash the machine during Windows NT boot-up.

If a resident DOS file virus is launched from within a DOS box, only files referenced from within the infected DOS box can potentially become infected. Thus, any Windows NT anti-virus product that executes outside of a DOS box (such as a 32-bit Windows application) can safely scan the computer without the possibility of infecting clean files; memory scanning is not necessary to properly detect and repair virus infections.

Most of the native Windows 3.1 viruses will function under Windows NT as they do under Windows 3.1.

At least one Windows 3.1 virus uses DPMI (DOS Protected Mode Interface) to hook into the standard Windows system services and establish itself as a memory-resident Windows TSR. The "Ph33r" virus hooks into the Windows 3.1 "EXECUTE PROGRAM" system service and is notified every time a program is executed by the user or another Windows 3.1 process. Upon notification, the "Ph33r" virus can infect the Windows 3.1 executable file before it is executed.

Viruses that hook into these services will also function under Windows NT as they do under Windows 3.1. However, under Windows NT, the Windows 3.1 TSR virus described above will only be notified about the execution of standard Windows 3.1 executables. Furthermore, Windows NT allows the user to specify whether each Windows 3.1 application is launched in a common memory area or in its own separate memory area. This functionality was provided so that users could prevent misbehaved Windows 3.1 applications from interfering with each other. If the user loads an infected Windows 3.1 application in its own memory area, then the resident virus will not receive notification of system service requests from other Windows 3.1 applications.

All macro viruses written for applications that run on Windows 3.1 or Windows 95 will function correctly under Windows NT if the host application works correctly under Windows NT. For example, since Word for Windows version 6.0+ works both on Windows 95 and Windows NT, the Win Word Concept virus works correctly under both platforms as well. The file-level protection provided by Windows NT can be used to prevent unauthorised use of documents (limiting potential infection); however, these macro viruses can still be spread through electronic mail or publicly accessible files. The bottom line is that macro viruses will continue to propagate under Windows NT systems. Given the necessity of information sharing in the enterprise environment, the macro viruses may surpass their DOS cousins as the most common viral threat.

Windows NT presents a much greater challenge for virus writers. First, the basic Windows NT operating system requires at least 12 megabytes of conventional RAM, a high-speed microprocessor and tens of megabytes of hard drive space. Most machines sold today are not powerful enough to provide a bare-bones Windows NT setup for software development. In other words, virus writers (who are often teenagers) may not be able to afford the appropriate hardware to develop native Windows NT viruses.

In addition to the Windows NT hardware requirements, the native Windows NT and Windows 95 executable file formats are also more complex than those found in DOS. Windows 3.1 also employs similar executable file formats that may account for the lower number of native Windows viruses. Furthermore, far less documentation is available on these file formats, requiring virus writers to spend time reverse-engineering their file structure.

The Windows NT operating system is definitely susceptible to DOS-based computer viruses. In many instances, Windows NT will prevent viruses from spreading as they would under DOS or Windows 95. However, these same viruses can still intentionally, or unintentionally, cause significant damage to the Windows NT operating system, its programs and data. As described above, DOS-based viruses can be split into two categories: boot record viruses and file viruses.

The Windows NT architecture severely limits the functionality of boot viruses, should the MBR or boot record of the hard drive become infected. If Windows NT is able to start up on an infected system, the infecting boot virus is never activated because the Windows NT protected-mode disk drivers are used instead of the viral disk drivers. Thus, standard boot viruses will be unable to propagate under the Windows NT operating system. Unfortunately, these viruses can still cause serious damage to NT systems.

If Windows 95 and Windows NT do become the predominant operating systems on PCs, we can expect to see a reduction in the number of boot virus infections, since these operating systems subvert their primary method of infection. However, for the time being, these viruses can still cause serious damage to Windows NT systems and traditional tools may not be able to recover from infection.

Most of the DOS-based and Windows 3.1-based file viruses will function properly under Windows NT. Under the NTFS file system, Windows NT does allow the user to protect files on a per-file or per-directory basis. However, this security feature may have little effect on DOS/Windows 3.1-based file viruses:

FAT-based partitions cannot be safeguarded by this type of protection

The typical end user will have no reason to enable this protection

A virus executed in a user's account can still infect all files owned by that user, even though those files may be protected and inaccessible to other users of the Windows NT system

Currently, DOS/Windows 3.1 file viruses are unable to infect native Windows NT executable files, although they may unknowingly try to do so and cause damage. In addition, there is no reason why a hybrid file virus could not be written to infect both DOS and Windows NT executable files. In fact, this basic concept has already been observed. The recently released "Ph33r" virus can infect both DOS and Windows 3.1 executable files.

(c) www.symantec.com

Compiled by Rachel Hodgkins

Read more on Operating systems software