Buffer Overflow Exploits

A buffer overflow exploit is an attack that leverages a programming error made in an application's source code whereby the size of a buffer is insufficient to accommodate the amount of data copied into it; hence the term overflow is used when adjacent memory locations are overwritten. For stack-based buffer overflows, a successful exploit overwrites the function return address (which is on the stack) so that it points into code provided by the attacker. This, in turn, allows the attacker to control the execution of the process thenceforth. Another class of buffer overflow attacks applies to memory regions that are dynamically allocated from the heap.

Buffer overflow vulnerabilities are commonly introduced into C or C++ applications through improper use of certain library functions that do not automatically implement bounds checking. Examples of such functions include strcpy(), strcat(), sprintf(), gets(), and scanf(), and

3 The Snort community refers to its signatures as rules, but the intrusion detection community also embraces the term signature as the mechanism for describing attacks to intrusion detection systems. In this book, the two terms are used interchangeably—nothing limits a signature to a single simple pattern, and therefore it is just as valid to refer to complex attack descriptions as signatures.

mismanagement of memory regions allocated from the heap via functions such as malloc() and calloc().

NOTE You will find an excellent description of how to write buffer overflow attacks in the widely referenced paper "Smashing the Stack for Fun and Profitby Aleph One (see http://irisecure.org/stf/smashstack.html). Jon Erickson's Hacking: The Art of Exploitation (No Starch Press, 2007) is another excellent source of technical information on developing buffer overflow exploits.

In the context of network-based attacks, there is no generic way to detect buffer overflow attempts. However, for applications that transmit data over encrypted channels, an attack that fills a buffer with, say, 50 instances of the unencrypted character A, would be awfully suspicious. (Encrypted protocols don't usually send the same character over and over again.)

If such an attack exists and it is shared in the underground, it may be worth adding an iptables rule to look for such behavior. For example, the following rule would be used for SSL communications. Notice the string of A characters:

[iptablesfw]# iptables -I FORWARD 1 -p tcp --dport 443 -m state --state ESTABLISHED -m string --string "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA" -j LOG --log-prefix "SSL OVERFLOW "

Because exploit code can change the filler character A to any other character, the above rule is easily circumvented by a trivial modification to the exploit code. However, exploit code is sometimes used by automated worms without modification, so the above strategy can be effective in some cases.

While the Snort signature set contains many signatures for overflow attacks, these signatures usually detect attacks in ways that do not require seeing specific filler bytes. Sometimes the size alone of data supplied as arguments to certain application commands indicates an overflow attack. For example, the following is a signature for an overflow against the chown command in an FTP server. It looks for at least 100 bytes of data following the chown command in an FTP session.

alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP SITE CHOWN overflow attempt"; flow:to_server,established; content:"SITE"; nocase; content:"CHOWN"; distance:0; nocase; isdataat:l00,relative; pcre:"/ASITE\s+CHOWN\s[A\n]{l00}/smi"; reference:bugtraq,2l20; reference:cve,200l-0065; classtype:attempted-admin; sid:l562; rev:ll;)

Although there is no regular expression engine available to iptables (having one would allow the pcre condition in bold above to be expressed within an iptables rule directly), we can produce a good iptables approximation of this Snort signature. For example, the iptables rule below searches for the site and chown strings and uses the length match to search for at least 140 byte packets. (Because the length match begins at the network layer header instead of at the application layer, we allow 20 bytes for the IP header and 20 bytes for the TCP header.)

[iptablesfw]# iptables -I FORWARD 1 -p tcp --dport 21 -m state --state ESTABLISHED -m string --string "site" --algo bm -m string --string "chown" --algo bm -m length --length 140 -j LOG --log-prefix "CHOWN OVERFLOW "

Was this article helpful?

0 0

Post a comment