DoS attacks can usually be prevented or resolved by limiting the user or the amount of resources the user is allowed in some way. When it comes to password file locking, the solution is not straight-forward. The complication exists because the passwd program runs with root privileges. A solution therefore has to run as root and prevent the abuse of privilege. The real problem with password locking is the amount of time that is spent running the passwd program. If the amount of time running the program can be limited in some way, the problem is easy to solve.
Most Unix operating systems have mechanisms in place to prevent the abuse of resources and services. As an example, direct access to resources is allowed only to the super-user, preventing access and abuse by normal users. A feature of most operating systems and shells is to provide a resource management utility that goes a long way to prevent DoS attacks. By imposing a quota on resources, a user attempting to take up all system resources soon hits his quota boundary. The quotas should not be so restrictive that they prevent normal work, but should be strict enough to prevent DoS attacks.
The initial problem of password cracking exists because the Unix password file is in a publicly readable place on the file system and is itself world-readable. The first step in finding a solution therefore may be preventing users from having access to the password file. However, users need to be able to read the password file to find information about their home directories and shells (for example). The only part of the password file that is of use to password crackers is the encrypted password field. A solution is therefore to keep the harmless information in the normal password file but keep encrypted passwords in a root-only read-write file. Programs running as root would therefore be able to verify passwords but user programs would have no access to the encrypted passwords. Legitimate users of the system are not affected as the parts of the password file they are interested in are still available. This solution is called password shadowing and is employed by default on many operating systems, most notably FreeBSD.
A partial solution to the problem of password cracking is choosing 'good' passwords. Some claim that there is no such thing as a good or bad password, just an easily guessable or not easily guessable password. Most Unix password changing programs insist that the passwords be a minimum of six characters in length. This requirement is mostly to get around brute force password attacks. To get around dictionary attacks, it is important that users choose passwords which are not dictionary or widely used used words. Even on non-dictionary words, some rules for lowering the probability of the password being guessed exist. Acquainting oneself with the rules password crackers use to guess passwords is a step towards having non-easily guessable passwords.
This problem is hard to correct. The reason is that if the administrator knew that his configuration of the software would lead to a security problem, he would not configure it that way. As mentioned in our security problems section, software is usually misconfigured in trying to fix something else that may be wrong. The perfect solution to this problem is for the administrator to not misconfigure the software. It should be obvious that it is an unreasonable expectation.
The software that is most dangerous is that which runs as root or with added privilege. Since most of these programs cannot be done away with, another solution to the problem is needed. Extensive testing of the software before and after configuration modification would help curb the potential effects of misconfigured software. The use of scripts such as those presented in the practical part of security problems section to test the security effects of the configuration is needed. Some misconfigurations may not be as easy to notice and fix, especially when some originate from the vendor. This ``solution'' is based on the hope that the only vulnerabilities that intruders would notice are those on the surface level. It is far from a perfect solution. Some security questions do not have straightforward answers, especially when people are involved.
Here we will present two solutions to the problem of buffer overflows, neither of which offer plug-and-play solutions that when plugged in overcome the problem completely. They are both steps in the right direction towards solving the problem. The best solution is to use them together. These solutions are : a non-executable stack and safe programming techniques.
We have covered extensively how buffer overflows work. The non-executable stack makes the stack non-executable. For most buffer overflow exploits, this solution will be adequate. When the return address is overwritten by buffer overflow code, it will still not execute the code at the address the return address was overwritten with. The return address is a magic number that is an invalid return address. When overwritten, this address will point to an existing address on the stack. This will indicate the possibility of a buffer overflow.
As discussed previously, buffer overflows work when we overwrite a small buffer with a bigger one. The best solution to the problem is not to overwrite a small buffer with a bigger one. The problem exists mainly because the data is obtained from the user and is trusted to be only a certain length. By not trusting the user or any data to be above a below a certain size, we can avoid buffer overflows. This is usually implemented by checking the size of the data before copying it to another location. Dynamic memory allocation also has to be sure that the memory allocation has succeed. If the allocation failed, the copying of the buffer still leaves us vulnerable.
Most buffer overflows exploit holes in SUID files. The solutions to buffer overflows therefore also apply to SUID files. Another solution to reduce the vulnerability of SUID files is control. What we mean by control is that only those files that need to be SUID keep the SUID flag. By controlling which files keep the SUID flag, we greatly reduce the risk posed by SUID files to our security. If we are to write our own programs which require the SUID flag set, we need to follow other safe programming techniques and guidelines. These are discussed in detail in [4] and [24].
Since trojan horses are more of a threat to host security than backdoors, a solution to trojanning will probably work with backdoors. We mentioned that trojanning a copy of a system program introduces nothing new to the system, making it harder to notice the intrusion. The solution to the problem of trojanning is using file integrity checkers. On a first run, integrity checkers take a snapshot of the current system files and work checksums out for them and store them. When they are run again, they take another snapshot of system files, work out checksums and compare these to the stored copies. Any inconsistencies are reported. Most of these integrity checkers can be extended to look not only at system files but all files on the system, particularly those which are SUID. When a backdoor is introduced either as a rootshell hidden in some directory or as a trojan of a system utility, the integrity checker will spot and report their presence as anomalies.
For the keystroke logging method that does not require any privilege, solutions are relatively straight-forward. Most of the trojans written to capture usernames and passwords are not written well. By supplying a fake username and password pair, they may exit and allow the normal login program to execute. They may also be used to allow one to gain access to the user running the trojan's home directory. Some do not catch signals such as the suspend signal. If the trojan is well written however, the best solution may be to login remotely, and to check what is running on the console terminal before logging in there. Another solution may be to prevent all logins from the console except for root.
The keystroke logging attack that requires privilege is not easily prevented. Since the attack itself is dependent on privileged access being obtained, that is the first logical place to stop the attack. It is in fact, the only place to stop the attack. After the intruder has gained privileged access, there is no way that he can be prevented from reading your keystrokes.
This attack is also privilege-dependent. A solution to this is also to prevent the intruder getting privileged access. If privileged access is obtained, there is no way to prevent this attack.
There are three solutions to this problem that we will discuss. As part of the problem statement, we mentioned that by setting the DISPLAY variable to an open X display, keystrokes on that server may be read. The first solution therefore remains to not allow connections to the current X display from anywhere except the X sessions currently running. The second solution is to encrypt the X-windows connection. This can be done through the program ssh (Secure Shell). When making use of this method, keystrokes appear as garbage when an attempt to read them is made. The third solution is to use user-based authentication based on cookies.