Common Attacks in Apache (Page 1 of 6 )
Because Apache is complex, coding errors are possible. Fortunately, Apache is mature enough that this is not a frequent occurrence, and occasionally, overlooked errors are found and fixed. This chapter covers some basics of Apache’s vulnerabilities and recent known security problems. (From
Hardening Apache by Tony Mobily, Apress, 2004, ISBN: 1590593782.)
Because of its complexity (and the inherent complexity of Internet technologies), the Apache software provides numerous opportunities for coding errors to be made, and sometimes they are. Fortunately, Apache is mature enough that this is not a frequent occurrence, and occasionally, overlooked errors are found and fixed.
In this chapter, I explain some basic terminology to help you understand Apache’s vulnerabilities. I then show some of the known security problems that have affected Apache over the last 24 months. The goal of these descriptions is not to understand these specific problems, but so you can see what kind of vulnerabilities Apache can have, how to research them, and where you can find and read the advisories (and understand them).
Common Terms In this section, I will introduce some key words often used in security advisories. These words are often misunderstood by less-experienced system administrators.
Exploits An exploit is a simple program used to show how to take advantage of a server’s vulnerability. Exploits can be quite dangerous, because they allow less experienced people (sometimes called script kiddies) to use them blindly and break into many servers on the Internet illegally. Many commercial companies do not like exploits at all and would like to make their publication illegal.
However, having an exploit “out in the wild” is also extremely important because:
- If companies know that an exploit is available, they will be more likely to release a patch to the problem as soon as possible, because their cus tomers are effectively easy targets.
- Exploits prove that a vulnerability is actually there and needs fixing. Sometimes software vendors are skeptical and deny that a vulnerability actually exists.
- Exploits are very useful in learning about computer security. They usually explain where the problem came from (that is, which piece of code was buggy in the original piece of software) and show you exactly how to exploit it.
Many different tricks have been used in order to discourage people from misusing exploits: some were intentionally published with errors so that they can only be used by programmers who understand what the code is doing; others were published in a kind of cryptic format, requiring the user to write a small program to decode the source file of the exploit itself, and so on.
Buffer Overflows Most programs allocate a reasonable amount of memory to the storage of information provided by the user. If a user deliberately tries to use more than the allocated amount of memory, he or she can damage the program, or even execute malicious code. For example, look at the following program (you should be able to understand it even with very little programming experience):
#include <stdio.h>
main(int argc, char **argv){
/* Was it the right number of parameters? */
if(argc != 2){
fprintf(stdout,"Usage: %s PARAMETERn",argv[0]);
exit(1);
}
/* OK, display the parameter! */
display_stuff(argv[1]);
}
/* Function called from main(), used to display the parameter */
int display_stuff(char *parameter){
/* copy_of_parameter is a buffer of 256 bytes */
char copy_of_parameter[80];
/* This means copy_of_parameter=parameter */
/* And yes, this is very insecure */
strcpy(copy_of_parameter,parameter);
/* Print out the parameter! */
printf("The parameter was: %sn",copy_of_parameter);
}
Assuming that you named your file example.c, you can compile it by typing:
[merc@localhost ch_3]$ cc -o example example.c All the program does is display the parameter that was passed to it:
[merc@localhost ch_3]$ ./example this_is_the_parameter
The parameter was: this_is_the_parameter
[merc@localhost ch_3]$
This program seems fine, but it actually isn’t, because the program assumes that the user won’t pass a parameter longer than 79 characters. So, if the user types the following:
[merc@localhost ch_3]$ ./example 12345678901234567890123456789012345678901234567890
123456789012345678901234567890123 The parameter was: 1234567890123456789012345678901234567890123456789012
3456789012345678901234567890123 Segmentation fault
[merc@localhost ch_3]$
the program crashes (note the “segmentation fault” message). In this program, the problem is in the function show_parameter(), which created a buffer 80 bytes long:
char copy_of_parameter[80];
Then, it copied whatever the user passed as a parameter to the program into that buffer:
/* This means copy_of_parameter=parameter */
strcpy(copy_of_parameter,parameter);
The programmer (wrongly) assumed that nobody would ever run the program passing such a long parameter through the command line. For this reason, the program copied the content of the variable parameter into copy_of_parameter, without checking if parameter would actually fit in it. Many Internet vulnerabilities are based on this problem.
NOTE In some cases, you might have to make the input line a little longer to get the program to crash (in my case, it was 83 characters, only 3 characters longer than allocated). |
In the code shown here the user can pass a very long parameter, and therefore overwrite a chunk of memory he or she is not supposed to be able to access. It is possible to organize the extra information so that it rewrites parts of the CPU code the program is made up of, in order to execute an arbitrary piece of assembler code. Doing so requires some knowledge, but it’s not as complicated as it may seem.
 This chapter is from Hardening Apache, by Tony Mobily. (Apress, 2004, ISBN: 1590593782). Check it out at your favorite bookstore today. Buy this book now.
|
Next: Types of Attacks >>
More Apache Articles
More By Apress Publishing
/ 14 
