sign in sign up
<<
Home , Central Point Software, ComSpec, DOS, Tim Paterson

86-01-35 Counteracting Viruses in MS-DOS Previous screen Systems A. Padgett Peterson Payoff The trapdoors programmed into the first DOS-based personal still persist today, providing relatively easy access for viruses and worms. By learning how malicious software exploits these weaknesses, security managers can develop a coordinated defense to counteract virus attacks now and in the future. This article describes how MS-DOS start- up processes can become exposed to viruses, discusses various intrusion methods, and presents techniques for designing a safe computing environment.

Problems Addressed Today's personal computers still bear striking similarities to the first units created during the 1970s. All of the trapdoors and loopholes developed by systems experts to permit BIOS-level programming in the early stages of development of these systems are still present today, providing easy access for viruses, worms, logic bombs, and Trojan horses. It is alarming that such low-level programs are no longer being fully documented by manufacturers; they are currently treating as proprietary the techniques that were widely disseminated just a few years ago. Administrators and systems managers who are responsible for the millions of dollars of corporate investment in trusted computing systems typically lack an in-depth understanding of these systems. Unfortunately, penetration techniques, though not readily available, are known to an underground of hackers. Although numerous antivirus products have become available, these products are as available to hackers as to legitimate users. Fortunately, defenses are available to the corporate systems manager that cannot be readily compromised by the individual user. A trusted computing environment can be developed that is low in cost and user impact, one that not only has a high degree of reliability but permits natural and easy growth. This article provides a basis for developing such an environment. Focusing on the MS- DOS-based computing environment, the article identifies potential security weaknesses introduced during the development of the IBM PC (and its clones) and the MS-DOS . It reviews methods of intrusion, both current and expected in the near future, and concludes by presenting a set of automated and procedural methods for counteracting these threats.

Development of MS-DOS-Based Systems The trapdoors introduced by systems experts in the early development of the still remain in the most recent versions of MS-DOS-based systems. To fully understand the vulnerability of today's systems to attack by computer viruses, the security specialist must become familiar with the way these systems were developed. The systems most widely used today are based on the design of the 8086 microprocessor, the successor to the family of microprocessors. When introduced in 1979, the Z-80 and the Intel 8080were the best-known microprocessors; Zylog had also recently announced its 16-bit Z-8000. The reception to the was lackluster at best, despite Intel's promise to port CP/M to the 8086 (as soon as could get around to it) and to provide MASM-86, its macro-assembler. The Air Force had just announced MIL-STD-1750 for 16-bit processors, and the 8086 didn't satisfy this standard. Enter IBM. A large market for was forming, and Big Blue did not Previous screen want to miss out. IBM decided to leapfrog its competition, quietly opening a plan in Boca Raton FL to design a new personal computer targeted for introduction in 1981. This computer was originally planned as an 8-bit machine; IBM's EBCDIC coding protocol was abandoned in favor of ASCII. Intel offered IBM its 8088 microprocessor(an 8086 redesigned to accommodate an 8-bit data ) at a price IBM could not refuse, and a deal was made. Because IBM was a bit out of with single-tasking environments, it contracted with an outside vendor, , for a (DOS). Microsoft did not have a suitable operating system but arranged for a reciprocal agreement with Computer Products for use of 's 86-DOS, a CP/M clone. Microsoft later bought all rights to 86-DOS. Although present-day PC-DOS is much expanded—providing hooks for such functions as the rarely seen Macro-Assembler, Quick-BASIC, FORTRAN, and Pascal—in its underlying architecture, it deviates little from CP/M. In its first personal computers, IBM included a software bit that could be set to make a program executable but not readable or listable—the first protection. Hackers quickly learned how to use the BASIC POKE command to defeat this protection, leading to the first (UN.P) and the attitude that it was open season on software: if you could obtain it, it was yours to run. The open season extended to cloning as well, and copies soon proliferated; some were so well executed that the IBM logo even appeared in their BIOS, leading to the first copyright infringement suits. To market those first personal computers, IBM used an open architecture, supplying applications programmers with in-depth engineering specifications that documented exactly how the computer worked and encouraging them to develop such programs as and word processors. Unfortunately for IBM, the architecture was a bit too open: Microsoft made PC-DOS available to anyone as MS-DOS after changing only a few invisible names, which further heated up the clone wars. Nonetheless, by 1983 the standard created by IBM came to dominate the industry, as it does today. This evolutionary has led to 486-based machines, with mainframe performance, multiuser networking, and multimegabyte memory. Despite such advances, however, that first IBM PC is still seen in every MS-DOS- based machine today (.g., 64K-byte segments and a 640K-byte limitation on main memory). From a security perspective, this apparent strength of the IBM PC (and its clones) has become its most dangerous weakness: there have been no significant deletions from the operating system architecture since 1981. This is not to say that extensions have not been added. For example, with the introduction of MS-DOS 2.0 in 1983, the pervasive high-level INT 21h took over many of the low-level functions of the system. Previously, the BIOS communicated with external devices through the use of 32 , INT 00 through INT 1Fh. Only a few interrupts—for example, INT 10h (the display handler), INT 13h (the disk handler), and INT 16h (the keyboard handler)—had than one function; all had less than 16. In MS-DOS 3.30, INT 21h has more than 100 functions, replacing nearly every low-level interrupt. The low-level interrupts are still supported, however, though not all are documented in the latest DOS technical manual. Most viruses infect systems through these low-level interrupts for one reason: although interrupts INT 20h through INT FFh are loaded by DOS, the BIOS loads INT 00 through INT 1Fh at boot . In any IBM PC(or fully compatible ), these interrupts must be exactly as defined by PC/MS-DOS 1.0. This is why a 1982 Columbia BIOS can run easily with MS-DOS 3.3 and be upgraded to 5.0. This is also why a virus written in 1982 under DOS 1.25 is just as infectious in 1992. A Review of MS-DOS Start-Up Processes Previous screen Because the microcomputer is most vulnerable to infection during start-up, it is important to understand the process that all MS-DOS machines use to wake up, load files, and execute applications. When powered on, the 8086 CPU automatically sets its instruction pointer(IP) to location 0h of memory segment FFFFh, the last segment of memory addressable by the 20 bits available to an 8088/8086microprocessor. (Although the 186, 286, 386, and 486 microprocessors have more bits available, MS-DOS does not recognize them.) This memory area is devoted in every personal computer to the BIOS ROM. The CPU then runs some equipment checks on the system (i.e., the Power-on Self Test [POST] function), zeroing memory while discovering how much available memory is present; stores this amount in the BIOS data table at locations 413h and 414h; defines interrupts 00 through 1Fh in the interrupt table in segment 0, locations 00 to 3FFh; examines even segment addresses from A000 to F000 for ROM extensions; and finally performs an INT 19h to start the DOS boot-up process. This boot process, which is the same one triggered by pressing [CNTRL] [ALT] [] , next attempts to read the first sector (1,024 bytes) of disk drive 0(i.e., drive A—the first diskette drive) into segment 0, locations 7C00h through 7FFFh. If this fails, the BIOS will attempt to read the first sector from drive 2 (i.e., drive C, the fixed disk). Failing this, a true IBM PC will branch to ROM BASIC by executing an INT 18h. Most clones, lacking ROM BASIC, will react to an INT 18h by sending a message requesting a bootable disk; the clone will retry an INT 19h after a keystroke has been entered. Execution is next transferred to the code that was just loaded into location 7C00h. With a hard drive, this information (which is contained in the partition table at physical sector 0) describes the logical disks, including the boot record. The sole purpose of the boot record is to the first of two operating system files containing the rest of DOS (IBMBIO.COM and IBMDOS.COM for PC-DOS; in MS-DOS, these are IO.SYS and MSDOS.SYS), load them into low memory (just above the 400h table values), and transfer control to the operating system for the rest of the configuration. DOS next does some memory swapping and then looks for theCONFIG.SYS file on the default drive (i.e., the drive the was taken from). CONFIG.SYS is the first file encountered during start-up that is both optional—DOS will run just as well without it— and able to be modified by the user. CONFIG.SYS defines the user environment within the machine and allocates such special drivers as the ANSI display driver and the with the SHELLcommand. DOS next invokes the specified , COMMAND.COM, and transfers control to it for execution. User input is processed through the shell-defined command line interpreter. On invocation, COMMAND.COMlooks for a file called AUTOEXEC.BAT. If it is found, control is automatically transferred to this ; the commands found within this file are then executed. If AUTOEXEC.BAT is not found, the familiar query for date and time will be displayed. After completion, operation is passed to the user. The familiar > prompt appears, signaling that the computer is now ready for use.

Methods of Intrusion An intrusion program must generally be executed to have any effect. A user may introduce the action without an executable file (e.g., PROFS Christmas Card), but this still requires initiating a procedure, such as the used to change colors on Lotus, Version 1A. Such boot sector infectors as the Pakistani Brain, Joshi, and , through annoying, are easy to detect even before execution because their signatures are known and physical intervention is required (i.e., they must be loaded from an infected disk). If not detected in advance, however, boot sector infectors can be quite dangerous because they can alter the computing environment, thus rendering themselves invisible. The Pakistani Brain, in particular, is considered an elegant piece of software because of the pains it takes to avoid detection; this virus not only creates a cache for itself in high memory and hides it Previous screen from DOS, it also hides its infection of the disk. The classical method of checking a diskette for infection is to read the boot sector; to avoid detection, the Brain saves the original boot sector in a different location, intercepts any boot sector call, and transmits the normal return code. The Joshi and Stoned viruses may be even more dangerous than the Brain, because the code in the partition table they infect executes very early, making it difficult to detect them. To hide, however, these viruses must become memory resident, and this is easily detectable. With a well-defined, stable environment, software analysis of the system on boot would take milliseconds (e.g., using a software package such as Symantec's NOVI); such analysis, however, is seldom performed. Viruses that infect files rather than systems take two general forms: overwriters and appenders. Overwriters are the simplest to write but have distinct limitations. The target must be a specific, well-known file so that the infiltrator knows exactly where to insert its code to avoid affecting the operation of the overwritten file. In this way, the virus avoids early detection. The Lehigh COMMAND.COM virus is a good example of an overwriter. This virus attacks only files named COMMAND.COM, rewriting the stack space in the program code to add two functions:

á Infect any file named COMMAND.COM it can find. á After four infections, wipe out all available FAT sectors on the disk where the virus resides. This virus is considered to be relatively crude—for example, the programmer did not even bother to avoid updating the program date, resulting in the change being visible on execution on a command. Although the Lehigh virus can be completely blocked by use of the resident COMSPEC definition, this action is rarely performed. There are also nonselective overwriters—for example, the 405and Leprosy viruses. There are easy to spot because the infected file no longer runs properly. The other class of replicants comprises those routines known as appenders. VIRDEM.COM, a virus demonstration program designed by Ralf Burger, provides a graphic example of how a Trojan horse can propagate itself like a virus. Typically, the changes introduced by such a replicant are transparent to end users. However, because the virus first saves the overwritten portion of the file it infects and then copies itself onto the program, the program size invariably grows. The change in program size can be detected. A new generation of stealth software has been developed recently, the first of which was the 4096 followed by the Fish-6 and 1253.Although file sizes grow on disk, when resident in memory, viral code is stripped off before files are presented to DOS; therefore, signature authenticators see only the original file. This of software quickly becomes resident in memory—for example, the 4096 attacks COMMAND.COM first, thus going resident almost immediately on boot unless counteracting measures are taken. To the observant user, however, system changes are unmistakable (e.g., a marked decrease in the amount of free memory). The key element in an intrusion of any type, whether or not it is replicating, is that a change in the environment must occur for there to be an effect. The two major requirements for a trusted computer are the ability to detect an intrusion attempt as it is taking place and the ability to detect a changed environment if infection has occurred. An elegant system will accomplish these requirements without the users being aware of it. Designing a Safe Computing Environment Previous screen The design of a safe computing environment requires two components: automated methods for virus detection and prevention, and the users' awareness of and effective response to such an event. This section reviews several automated techniques that can be useful in combating viruses. Subsequent sections address how the organization can respond to this challenge through support of awareness programs and the creation of response teams.

Technical Solutions Just as it is impossible to make a car completely theftproof, it is impossible to make a computer totally secure without also making it impossible to use. What can be done is to design an environment that is difficult to penetrate, that if penetrated has means to prevent infection, and that if infected will detect the infection before damage occurs. To accomplish this, a layered defense is necessary. Difficulty of penetration can be most easily achieved by denial of access. One of the most theftproof cars in the world used to be the Land Rover, and not because it was armored—many cannot even be locked—but because the starter button (the ignition key doesn't activate the starter) is located under the front seat. Similarly, a protection package, if loaded with CONFIG.SYS, need not even have a .COM, .EXE., or .SYS extension. At the simplest level, merely designating the diskette drive as drive B rather than drive A would prevent the system from ever from a diskette, thus blocking classic boot sector and partition table intrusion. (This can be accomplished by a simple cable change on a single-diskette system.) If a second diskette is needed, this could be assigned as drive F (with drive C as the program disk, D as the user disk, and E as the COMSPEC disk). This would, however, be a nonstandard system. For a standard system, detection is best ensured by a program that mimics as neighborhood police officer who knows the occupants of each house and what they look like. The key element is to have a stable neighborhood, not a transient one, so that any unwarranted changes or additions can be readily detected. A safe system can be designed by confining executable files to a stable environment. In this case, a 40M-byte fixed disk can be partitioned into two drives, C and D. The C drive is the program disk, containing all applications in multiple subdirectories. The PATH and APPEND functions can be used to access C drive files and executables from the D user disk drive. Using this method, the C drive file configuration need change only when programs are added or modified. (Because the corporate processing environment is usually quite stable, this is not an unreasonable solution.) Because a stable environment exists, a single backup of the C drive may be sufficient for most machines. Futhermore, because all executables are on a single partition, signatures can be maintained and checked by a small (less than 10K-byte)terminate-and-stay-resident (TSR) function on invocation. A number of software products can be used to check this. Of course, this is not a foolproof solution; many viruses are designed to target the boot and partition tables so that they become resident before signature checking occurs. Consequently, an effective prevention package must do more than just scan files; it must determine whether any malicious software has become resident in the system. Currently, there are two effective ways this can be done:

á As discussed in the section on MS-DOS start-up processes, following the POST function, the BIOS checks the address area above DOS for additional ROM programs. Hardware can be inserted into the system to assume this address area, causing protection software to take effect before any potentially damaging software can be invoked. á Because there are at least two locations malicious software can attack before invocation Previous screen of CONFIG.SYS (the partition table and boot record), the earlier integrity management software starts before invocation of CONFIG.SYS the better. This software should verify the integrity of the system after BIOS has completed its start-up operations and before MS-DOS is invoked. For the foreseeable future, MS-DOS machines can be adequately protected from malicious software with software protection solutions. This is possible when such software, installed in a clean, stable system, can recognize the signature of the clean environment, including all software resident when the protection package is loaded, memory allocations and available memory, checks on the partition table, hidden or unused sectors (e.g., physical sectors 2 through 17on track 0 of a standard drive are unused by DOS), the boot record, and FATs for bad block count. Once the environment has been authenticated, corporate managers have a : either require that software upgrades and additions be installed only by authorized personnel or permit users to add and change software. The second option creates the risk that malicious software may be introduced into the system. An effective protection package should be able to detect a virus if it tries to modify the sytem; however, there is the added risk that the user will inadvertently permit the modification. With such viruses as the 4096, the user receives only one warning. Management must therefore weigh the added risks of an open environment against its advantages. Because each microcomputer may be configured differently, this decision may be left up to department managers. (It should be noted that the techniques discussed in this section have been tested on several systems. However, given the incredible diversity of machines, it is not possible to guarantee that every machine will work in the manner described here.)

The Organizational Response Any safe environment must begin with system users. Too often, the employee is just given a machine with a stack of manuals and told to go to work. Those with mainframe experience never realize that the background tasks necessary to preserve a mainframe from intrusion do not exist in a DOS-based microcomputer. In fact, DOS will load and attempt to run any program presented to it, as long as it has an executable extension. (For example, in a mixed environment, it is common to see a VAX user download a VMS.COM file and tell DOS to run it—and it will.) Security Awareness Programs. Security awareness must be an integral part of the user's mind-set. Although it is not necessary for each employee to be a virus expert, employees must know safe computing practices (e.g., never run unscreened software), how to recognize the signs of infection (e.g., slowdowns, odd displays, unusual disk activity, and messages out of context), and how to respond to an infection. Generally, this training can be accomplished in less than an hour. When supported by periodic alerts and reminders, the user becomes the best defense against malicious software. Corporations have one major advantage over the educational institutions from which much of the malicious software emerges: the people in corporations are employees who usually take pride in their jobs and wish to preserve their employment. If the dangers of installing unauthorized software and performing unsafe practices are explained well, most employees will adhere to a reasonable software protection policy. One of the quickest ways for a corporation to suffer a major attack is to take the attitude that “it can't happen here.” It is essential that senior management make a commitment to support the awareness program. Management should also consider including recovery from an infection by malicious software as part of its disaster recovery plan. An attack by the 4096, perhaps made worse by the loss of files when uneducated users try to recover, can Previous screen be more devastating to data than a fire or an earthquake. Response Teams. One of the advantages of a corporate environment is economies of scale. When the number of microcomputers exceeds a few hundred, a dedicated support staff becomes both necessary and economically feasible. To be cost-effective, the response team must perform several functions, of which repair is just one. The team should be able to answer these questions: á Is newly acquired software free of malicious code? á Is the software we send out clean? á Will new software work properly with existing machines? á What malicious software has been reported, and how can it be detected and eradicated? á Do existing machines meet users' needs? á What must we do today to address future problems, both in the short term and the long term? The response functions should be handled by a central organization. If it is found that individual departments are being forced to handle one or more of these items, something is wrong. The response team should be organized to quickly respond to problems, using a layered hierarchy, from the technicians who first answer trouble calls to the scientists who respond to unusual cases. The team must be available 24hours a day, seven days a week. Several information resources should be monitored so that new threats can be properly evaluated. Among the best known is Virus-L on Internet, which is maintained by the computer emergency response team at Carnegie Mellon University.

Future Threats Although the methods presented in this article provide effective protection against today's threats, undoubtedly the future will bring new ones. For example, earlier it was said that the BIOS is safe from alteration because it is contained in ROM. Although the ROM itself is safe, the Intel 80386 and 80486 microprocessors allow memory mapping of the BIOS into fast RAM. When the processor acceses the BIOS in these machines, the active memory is read/write and therefore is exposed to subversion in at least two ways. Current protection software does not validate this part of memory; therefore, the BIOS data areas are susceptible to attack. Currently, microcomputers are usually attacked by viruses, whereas mainframes are attacked by worms. The reason: miscreants pick whichever is easier to write. In a mainframe, the multitasking operations make it easy for a standalone program, such as a worm, to hide. Furthermore, mainframe operating system authentication methods, often contained in the file header or directory listings, make it difficult for viruses to infect existing programs. Because these processes and protection methods do not exist in PC- DOS-based systems, it is easier at the moment to infect them with viruses. However, as multitasking microcomputers become available, offering more rigorous authentication and increased network communications paths, worms are likely to become more prevalent in the microcomputer environment. Recommended Course of Action Previous screen A layered defense against malicious software and other threats to the corporation's systems requires four elements: a management committed to providing safe computing; a trusted, aware employee base; a well-equipped response team; and software or hardware protection mechanisms. Management must first define a level of acceptable risk, a plan to achieve this level of risk with fallbacks based on worst-case scenarios, and a method of implementing a computing environment that is commensurate with this goal. Control in a microcomputer environment is not an impossible or even difficult task. It relies primarily on reversing the philosophy of open computing, an idea that disappeared from the mainframe environment about the time punched card decks began to be used. This philosophical change is best brought about through training in which employees are educated in the moral responsibilities that go along with computer use. The next layer of defense is a staff of trained technicians equipped with the software tools necessary to accurately diagnose and correct problems. Last, the right mix of integrity management software must be added to each machine to cover security weaknesses in the microcomputer architecture. This task need be neither difficult nor laborious. Several effective software packages exist, including Enigma Logic's SafeWord Virus-Safe, McAfee Associates' ViruScan, 's AntiVirus for DOS, and Symantec's AntiVirus (NAV). Author Biographies A. Padgett Peterson A. Padgett Peterson, P.E., is security manager for the technical computing center at Martin-Marietta Missiles, Information, and Electronics Group, Orlando FL. He is a regular contributor to the Internet Virus-L news group and a member of the European Computer Anomaly Research Organization.