Viruses and Other Software Threats › Understanding Software Threats › What Is a Virus?

What Is a Virus?

Not all experts agree on the definition of a virus. Some feel the term should be reserved for programs that need a host to replicate and spread to other programs. Others think that a virus can either self‑replicate or use a host program to spread to other computer systems. Some use the term worm to describe a self‑replicating program that does not need to attach itself to another program. In this guide, virus means any type of contaminated software that can replicate and spread to another program or computer system. This definition includes both self‑replicating worms and host‑dependent subroutines.

Viruses come in various degrees of technical sophistication. A PC virus that emulates a 3270‑type terminal suggests a relatively large, complex PC virus program. A virus that brings down an entire z/OS system by submitting thousands of spurious jobs through the internal reader and flooding all job queues is significantly less technical. Viruses can suspend innocent user IDs by submitting jobs with valid user IDs and randomly chosen passwords. MOUNT commands issued through JCL could disrupt production processing. RESERVEs issued against the online shared disk packs would disrupt the entire data center.

Viruses can function in a z/OS operating system at an application or a system level. Application viruses attack the files, libraries, and storage areas that the victim can update. System‑level viruses, however, have no such limitations; they can infect the z/OS operating system itself. They can attack all programs, files, and libraries, and even your access control software. In fact, a well‑designed virus can enter your system at an application level and then transform itself into a virus that attacks the system when the opportunity presents itself.

Because most z/OS systems have access control software, viruses must find a way to bypass the security system and avoid alerting the data center’s security officer to its presence. It is usually easier for an unsuspecting victim to authorize the virus. All the virus has to do is wait patiently for a victim who has update access privileges to an Authorized Program Facility (APF) library.

By executing under the authority of a victim with APF update capabilities, the virus can place itself in an APF library. This fulfills one of the requirements for becoming APF‑authorized. Another requirement is marking itself with an authorization code, which z/OS does not restrict in any way. All the virus has to do then is to issue the MODESET supervisor call to become APF‑authorized. Therefore, by controlling access to an APF library, you can control whether a virus becomes APF‑authorized.

Because most security software products let their users list information about their IDs, viruses can test their victims for the proper access privileges. For example, a virus that runs in a RACF‑controlled system can use the LISTUSER command to determine the characteristics of the user profile under which it is executed. The OPERATIONS privilege would let the virus update APF libraries. Unless their use is restricted, CA ACF2 provides the LIST and CHANGE subcommands for similar purposes. CA Top Secret uses the LIST, ADDTO, and PERMIT commands to perform these functions. For more information, see APF‑Authorized Libraries in the “System Installation Choices” chapter.

After a z/OS APF library is compromised, the virus can obtain supervisor state and the master storage protection key (key 0). A virus so authorized then operates at the more dangerous system level. With these powers, the virus can circumvent all security mechanisms and move around the system at will. An APF‑authorized virus could quickly identify the various locations in the z/OS environment into which it could copy or link edit parts of itself. System modules, compilers, utility programs, and even TSO CLISTs are likely candidates.

Although it is more likely to be self‑contained, a virus does not have to reside in one contiguous load module. In fact, a virus distributed throughout a number of distinct modules probably makes more sense to a criminal because it is more difficult to detect and dissect. Very small and highly specialized, destructive modules could be placed into system utilities such as language translators, the linkage editor, and other utilities that provide services for application programs. In reality, the virus does not have to contain these destructive modules. Instead, it could consist of instructions that act only as bomb detonators.

Regardless of the technique, the virus usually attempts to place itself in a location where a potential victim executes it. The virus can then spread to other parts of the system or remain where it is and implant logic bombs into application programs. The virus could propagate to other systems through any mechanism that moves load modules or source modules to other computers. JES networks, batch transmission facilities (for example, BDT), public domain software, and dial‑in terminals with upload and download facilities are the most likely means of propagation.