Logic Errors

The aspect of computer vulnerabilities often thought of first are logic errors - mistakes in the programming or design of the software that allows a security breach. Many computer operators in the "golden days" of computers remember software that was so poorly written that if you told it you were the administrator, you became the administrator. One would suspect that with modern technology, enhanced design, and strict standards that such security problems would become a thing of the past. However, the complexity of programming, operating systems, and security designs has increased the overall security risk. Furthermore, convenience for users is convenience for intruders as well, and good intentions often create gigantic security holes.

The most notable aspects of logic errors is that they require extremely short periods of time to interact with the computer to compromise security and require very little human influence to activate. Many of logic errors can become "canned" by writing a single program that handles the intrusion process automatically. These programs are often called "scripts" because they are usually programmed in a script language such as "shell script" or PERL, and can be found on numerous public Internet web sites.

The aspect that definitively separates the logic errors from weakness are that logic errors are an absolute lacking of security - the security either was incorrectly done or was completely absent in the design. The aspect that separates logic errors from social engineering is that logic errors don't require feedback from the victim - all the functions necessary to carry out the vulnerability are present on the victim's computer or network.

Because of the high speeds and low interaction time, logic errors arguably make up the most dangerous of computer security problems. These problems, once discovered, can usually be kept secret, preventing administrators from knowing what "trick" the hacker used to promote their access. The Computer Emergency Response Team (CERT), as well as other worldwide computer emergency planning groups, collect and release information about vulnerabilities the public needs to be aware of. However, there are thousands of new reported vulnerabilities appearing each year, but less than 100 are "officially" reported by such agencies.

Most logic errors are catalogued by fault, and at this level there is very little need for vague descriptions as everything has a technical answer. Although there are only four "examples" listed on the Vulnerability Map, there are many different types of logic errors that fit all over. However, lets investigate the logic error examples as given by the Vulnerability Map.

Operating System Vulnerabilities

All software inherits vulnerabilities from the operating system. Although it's a common assumption that poor administration is what really allows hackers easy entry to computers, sometimes it isn't the fault of the administrator. Hundreds (if not thousands) of security problems are easily traced back to flaws which exist in the operating system itself. If one considers the "buffer overflow" attack, which results in "force feeding" the computer instructions due to faulting bounds checking, if the operating system handled the overflows correctly the problem would not even exist. If the same program were "ported" to an operating system with better overflow handling, the problem would disappear.

Application Operating Specific System

Logic Errors

Operating System Vulnerabilities are the most direct methods of attack, having near-instant reaction times, and very predictable results. Furthermore, the same problem is likely to exist in all of the computer systems of the same type, making them nearly universal in nature. Vulnerabilities of this sort usually command the highest priorities by response teams.

Here is an example of an operating system vulnerability in Ultrix 4.4. This vulnerability was packaged with the operating system and supplied with the basic toolkit. Before it was patched, if an intruder found an Ultrix 4.4 computer, it was very likely this problem would be present.

Sample Vulnerability [chroot, Discoverer: Unknown, Ultrix 4.4]

The chroot function can be used to change your access to root access by creating a new password file and supplying a null password for the "root" account and then "su"ing to administrator access.

As stated, this problem has a simple cause-effect result and can easily be obtained in seconds, and even be completely automatable. There are some steps to the process which have been left out, but can easily be added (such as creating a new device to point to the hard drive, mounting the file system from that device, and then modifying the "root" of the file-system bypassing the effect of chroot.)

Application Specific Vulnerabilities

A specific application can be anything from a video game to a web server. Masters can write these programs or they could be written by amateurs, one is never quite sure. For every operating system there is a user with a different set of needs, so application vulnerabilities typically don't affect everybody. However, this doesn't mean millions of people still cannot be effected (consider a flaw in Microsoft Internet Explorer, and how many people that would effect.)

Flaws in applications, like flaws in operating systems, are of the highest speed of execution but require a more personalized touch than does straight operating system vulnerabilities. Sometimes the flaw might not manifest itself until a condition of use occurs, making actual automation difficult. However, the critical interaction required by the attacker is locating specifically which computers run the targeted application.

Here is an example of an application (in this case, the LARN game that comes bundled with many versions of the BSD operating system), programmed accidentally with a vulnerability, that allows administrator access to the host.

Sample Vulnerability [LARN bug, Discoverer: Snocrash, BSD 4.4]

If a person scores 263 point in larn,   it causes the system to mail the user.   The process of mailing the user causes a potential IFS vulnerability which can be used to exploit root access.

This attack is not "instant" although this particular example was meant to show that non-automated situations do exist. Keep in mind that the Vulnerability Map is an approximation of expected time and interaction.

Network Protocol Design

In many cases, the actual communication between layers is difficult to design properly. Most of the network protocols are highly trusting of other computers and "spoofing" becomes simple. Here is an example of such a problem:

Sample Vulnerability [PCNFSD, Discoverer: John McDonald, OpenBSD]

The get_pr_status function uses popen()  directly,  as opposed to calling the su_popen()   function.    The OpenBSD implementation of rpc.pcnfsd does not check if the supplied printer name is a valid printer; it only checks if the name is suspicious.   Thus, a printer name can be provided such that remote commands can be executed as root.

Keep in mind this particular area of computer security is pretty vast right now with a lot of affected parties, and people are attempting to solve these problems without disrupting the existing "free access" organization of the Internet. These will probably be among the most hotly contested areas of necessary computer security changes.

Forced Trust Violations

The "Trust Web" is considered to be the biggest problem in computer security. If you know someone who trusts you, whom also is trusted by someone you want to target, then they are vulnerable by association. Many people trust others completely, but if the attacker compromises one person, they are very likely to compromise others in their trust web.

The trust web, however, doesn't just extend to person-to-person interactions. The "root" access account handles system level functions, which allows lower lever accesses permission to do functions such as "access the hard drive", "write to the console", etc. The management of these processes involves its own trust web. There are a number of faults, such as race conditions or failure to check symlinks, which exist between two different levels of access that can be exploited. Here is a quick example:

Sample Vulnerability [ppl, Discoverer: Scriptors of Doom, HPUX 10.x]

ppl generates a log file that follows symbolic links,  and can overwrite /.rhosts with a "+ +" line.

To understand this particular flaw, the ppl program is "setuid root", which means it runs with administrator permissions. It creates a log file that, if someone else were to place a symbolic link in the /tmp directory in which it resides with the same file name, it will overwrite whatever file the symbolic link points to. If the file is pointed to /.rhosts, then not only would the attacker be violating a trust between user and administrator at the system level, but creating a new trust between the system and all the systems on the network (in the .rhosts file, "+ +" means trust every computer, trust every user.)

Computer Vulnerabilities