Tweet
Common Attacks in Apache
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);
}
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);
}
Comment