Exploits: Buffer Overflows, Pathname Attacks, and SQL Injections

Overview

The purpose of this exercise is to introduce you to three kinds of common software vulnerabilities and give you a first-hand opportunity to see them in source code, exploit them, and describe how to patch them. After successfully completing this exercise, you will be able to:

1. Accurately identify and describe:

   1. Buffer Overflows

   2. Pathname attacks

   3. SQL-Injection attacks

2. Identify the above bugs in preexisting code including:

   1. A small webserver written in C

   2. A CGI script written in Perl

   3. A MySQL-based application written in PHP

3. Understand how vulnerabilities lead to:

   1. Software crashes

   2. Remote execution exploits

   3. Unauthorized access to private data

4. Repair simple examples of these kinds of security holes in the above languages

5. Author memos describing in detail your findings and code changes.

Required Reading

Buffer Overflows

Buffer overflows are a unique kind of occurrence enabled by poor programming in certain languages (for example C, C++, and assembly code) that allow the use of fixed memory buffers for storing data and do not include automatic bounds checking. A buffer is a bounded region of memory into which data can be stored. Buffer overflows result when a buffer is assigned more data than it can hold. The buffer "overflows" into the next available memory space, overwriting the data. Strictly speaking, this is not necessarily an error. However, it has historically been the cause of many bugs and security flaws because so much commonly used code is written in these languages, including compilers, interpreters, and operating systems.

Buffers are different from traditional variables in strongly-typed languages because each genuine type is of a fixed, predetermined size. For example, on most computers an 'int' in C is a 32-bit signed integer. By using the keyword 'int', the programmer has declared to the compiler that this variable and associated memory will never need to exceed 32 bits of storage space, and in fact the compiler ensures that this is not possible. (This is why partly why integers "wrap" when they "overflow" -- the other part is two's complement arithmetic, but that's a lecture for a different class.)

Unfortunately, sometimes strong types are inadequate precisely because you don't know exactly how much memory something is going to require. For example, a user entering their birthplace could be from "Orr, Minnesota" (14 bytes), or they could be from "Llanfairpwllgwyngyllgogerychwyrndrobwyll-llantysiliogogogoch, Wales" (67 bytes). You know it's character data, but how many bytes do you need to reserve to store it? Of course, because memory is finite, we are forced to set some upper bound on the size that we hope will be sufficient.

This is where buffers come in. A buffer is allocated with a specified amount of space (the upper bound) and a type (usually char for character data) and are accessed via a pointer to the first byte of the buffer. Furthermore, allocated buffers will have some positional relationship in physical memory depending on how the compiler chooses to optimize the code. In our place name example, if we allocated a buffer of 60 bytes for "city" and then allocated a buffer of 20 bytes for "country" it is possible that they will be adjacent to each other (or perhaps some other buffers or variables). Unfortunately, programmers often neglect to make sure that input from the outside world (or even from the program itself) will fit into the declared size of the buffer. Instead, they often think, "There's no way that X will ever be longer than Y bytes!!1!" Of course, perhaps X is usually shorter than Y, except when there is an error -- or when someone is intentionally trying to disrupt or compromise your system.

In the strictest sense, a "buffer overflow" is when a buffer of size b is assigned data of size c where c > b. Languages like C and C++ in practice will blithely assign the data c to the memory location b, and this means that whatever memory addresses were after b will now be replaced by the overflow of c. If done unintentionally, this will typically cause bizarre data corruption at the very least and very probably segmentation faults if the overflowed memory is read or dereferenced. This can be used to create denial-of-service attacks by crashing applications remotely with bogus input (e.g., the "Ping of Death").

However, with some careful planning, source code inspection and/or experimentation it is often possible to overwrite the function pointer on the stack of the application, in effect controlling the next "step" the program will take after it finishes reading the new input. This can be used to make the program loop back on itself, or to crash the program. Even more insidiously, it is often possible to dynamically rewrite the running program by including new function code in the data payload you use to overflow the buffer and then change the function pointer to point back to the function you just stuffed into memory. The program will finish reading the data, consult the newly assigned function pointer, and jump to the code you just provided. This allows you to remotely execute code with the permissions of the running software. Typical exploit payloads will further compromise the system by creating a new user, changing a privileged password, or performing some other action that makes additional compromise easier. This often leads to a root terminal session on the server, after which point the server must be considered completely compromised.

Buffer overflows are an excellent example of why input validation is absolutely critical when writing any software. Input validation is the process of programmatically ensuring that all accepted input fits within the logical constraints of the application. This can be as simple as making sure that a social security number has no alphabetic letters (e.g., a fill-in form), or as complex as parsing the input for syntax (e.g., a software compiler).

Ultimately, input validation is a part of the "principle of least privilege." We like to think that our programs can only do what we thought about while we designed them. But in fact, our programs can do (are granted the privilege to do) whatever their code and environment allow. Unvalidated input can often modify the behavior of an application, which directly modifies what the program is given the privilege to do. Thus, good programs always validate their input.

Additional Reading on Buffer Overflows

For more information, including detailed technical explanations, see:

• Smashing the Stack for Fun and Profit, by AlephOne. This is the canonical HOWTO for buffer overflows.

• Buffer Overflow at Wikipedia

• ...or many other online resources about this very popular attack.

Pathname Attacks

Filesystem permissions and pathnames are critical entities for any computer system that places a value on security. If data is to remain secure, filesystem permissions must be properly set and universally obeyed. Perhaps the simplest example of what file permissions are meant to enable is the protection of one user's data from another user. Pathnames are used to address resources on a filesystem, and are usually relative either to the application using the pathname or to the "top level" of the filesystem hierarchy. When combined with system login authentication, filesystem permissions and pathnames create a simple framework for allowing and denying access to various resources.

Unprivileged attackers must typically subvert this system, either by breaking it outright, or by circumventing it. Thanks to the hard work of operating systems designers, It is usually very difficult to successfully break the permissions system of modern operatings systems and do something that is explicitly prohibited. Unfortunately, it is often frighteningly easy to violate the intent of the system permissions while still making permissible requests.

This is loosely analogous to violating our legal "spirit of the law" while still obeying the "letter of the law". While the spirit of the law is infinite, omniscient, and intends to "do the right thing" in every circumstance -- the letter of the law must be finite and pragmatic. As a result, sometimes what might be a crime against the spirit of the law is permissible because of "loopholes" in the letter of the law as it is embodied in the application (e.g., buffer overflows).

A common approach is to use the permissions of an application to take an action on behalf of the attacker. One issue is that while programmers and administrators usually consider user permissions, they often overlook group & other permissions. If a program has been run with certain group permissions, it may have permission to access files completely unrelated to the task at hand. (For example, an application running with wheel group access probably has permission to do lots of unrelated things.)

Because of this, some applications run as a special "non privileged" user as a security measure with the express intention of limiting its privileges, but it is often the case that in reality the "non privileged" user account still has access to private resources, which is especially bad if the application has a public interface. For example, the Apache web server often runs as the user www-data -- which is meant to be a non-login, limited user. However, just like any other-class user, the www-data user has permission to access any files that are world-readable, such as /etc/passwd, many system configuration files, and quite often user home directories! While they may be "world-readable" on the local system, most such files are hardly meant to be seen by the web surfing public.

Also, since the webserver runs as www-data, any files or directories the webserver uses or creates must be readable or writeable by the www-data user. This also means that all web applications on a server run as the same user! One web application (e.g. a webmail program) may be vulnerable to an attack from a different web application on the same server (e.g, an image gallery program) because they run with the same permissions. The webmail program might be well written without security holes, but a hole in the image gallery might allow a user to see data from the webmail program because they are both rwx for the www-data user. Things get worse if the image gallery can be used to modify the webmail program.

An even more critical fact that programmers repeatedly overlook is that sometimes applications run not with the permissions of the calling process, but instead are set to run with the permissions of the program file's user id (the file's owner). This is called "setuid" or SUID, and is usually used if the program must do something with root user privileges such as changing a user password. From the perspective of the operating system, a "setuid root" program has the permission to do anything, and attackers are often able to leverage this permission in unexpected ways.

Pathnames are are also vulnerable to subversion by knowledgeable attackers. While a healthy filesystem hierarchy always has a consistent, canonical representation, there are often infinite ways to express a valid pathname identifying the same resource. Thus, when programs perform input validation, they must make sure that they are capable of properly validating all potential pathnames they could receive, rather than assuming any arbitrary limit on the form or content of pathnames -- otherwise an attacker only needs to find the one pathname attack that isn't defended.

Ultimately, these vulnerabilities illuminate the fact that a program running on a system is a direct extension of the entity with whose permissions the program is running. Because of this, your mail client is an extension of you and your authentication level -- this is why it can display your mail and attach your files to messages you send. This is both a blessing and a curse; the permissions that allow the mail client to do its job are the same permissions that make it a desirable target for attack.

History shows us that it is often possible for an unauthorized user to subvert a program running with some desired permissions and encourage it to read and present data that would otherwise be inaccessible to the attacker. This is an access control violation in spirit even though the system has performed correctly and thus can lead to privileged information being divulged which can be costly in many different ways.

Therefore, because it is impossible to absolutely trust the underlying system permissions, it is critical in software design to make sure that a program is only able to access exactly what it needs to function properly and nothing more. This is another aspect of the "principle of least privilege". However, computers and software systems are typically granted access to anything not specifically prohibited, and this usually means that secure software must include code dedicated to enforcing additional limitations on the software that the underlying permission system does not impose. (This is like police officers wearing bullet-proof vests because their underlying bodies do not impose restrictions on bullets.)

These additional limitations (such as input validation) are especially critical for security if software is able to receive arbitrary input, and often have the beneficial side-effect of making software more robust.

Additional Reading

• Directory Traversal at Wikipedia

• Canonicalization at Wikipedia

• Old GNU tar directory traversal vulnerability report

• A nice article on hand-crafting HTTP requests and CGI parameters

SQL Injection Description

SQL -- or the Structured Query Language -- "is a computer language designed for the retrieval and management of data in relational database management systems, database schema creation and modification, and database object access control management"[2]. Put simply, it's a database query language. SQL (pronounced "sequel" or S-Q-L) has been around since the 1970s, and was standardized by ANSI in 1986. SQL is ubiquitous -- practically all current relational databases in use today speak some vendor-specific variant of SQL, and most enterprise web applications use a relational database on the back end. Furthermore, scripting languages such as Python, Perl, Ruby, and PHP are often used for web development and all have robust, easy to use SQL modules. In fact, the combination of Linux servers, the Apache http daemon, the MySQL relational database, and the PHP scripting language are so popular for web development today that they have their own acronym -- LAMP.

SQL is valuable because it frees programmers from the tedious job of creating a customized data storage system (which is very likely to have its own bugs and shortcomings). Even more valuable is that SQL allows programmers to ignore the particulars of the database internals. Instead, they can use a (mostly) standardized query language to access the data they need, remaining largely independent of the database application, database memory management, and physical storage. This modularity makes maintenance and portability easier.

For example, an online retailer might have a database table for all their inventory with the columns product number, name, price, and number in stock. The programmer can craft a database query requesting all products whose names' second letter is an "x", filtering out the 10 with the cheapest price, and alphabetizing the result. This result will typically be returned from SQL to the programming language as a list (array) or similar data structure. The programmer can then work with the list in her favorite language, make further queries, or return the data to some display function. In executing queries like this, the SQL database, not the application, performs the selection, filtering, and alphabetization.

Big database applications like MySQL are a win, because the performance critical code (the database) is written in a fast language like C/C++, while the interface can be created with a slower, user-friendly scripting language. This is especially important when databases contain millions of entries because the slower scripting languages quickly become prohibitively expensive if they are fully responsible for database mechanics. A related benefit of centralizing databases in this way is that SQL servers can be installed on dedicated hardware and accessed via the network, increasing efficiency and adding other benefits (like easier backups).

As we have already seen in this exercise, simple programming mistakes and omissions often result in unexpected negative security effects. Unfortunately, SQL-based applications are vulnerable to some of these kinds of problems. While generally immune to buffer overflows in user software, PHP is every bit as vulnerable to filesystem and directory traversal exploits as is Perl or Python because these vulnerabilities are a product of the underlying execution environment, not the language being used. Furthermore, these kinds of violations (and other unintended consequences such as crashes) often occur because of a lack of input validation. Rather than attempting to verify its validity, input is trusted to be valid and not malicious. Additionally, sometimes valid input still represents a security violation because it exercises more privilege than the application requires to properly operate.

Poorly written applications that interface with SQL are no different. A common class of attacks are called "SQL injection attacks" which -- like directory traversal and buffer overflow vulnerabilities -- are the result of trusting non-validated input and implicitly granting applications privilege they do not require. In this case, the non-validated input actually contains SQL statements and relies on the application to naively insert the user input into the application's own request.

For example, imagine a fatally flawed web interface for the Social Security Administration where you enter your Social Security number (123006789) and the system displays a summary of your account and personal information. Using MySQL and PHP, the application might include code like this:

$ssn = $_POST['ssn'];                                      // get ssn from web form POST data
$query = "SELECT * FROM personal WHERE ssn LIKE '$ssn'";   // construct query (notice embedded $ssn variable)
$result = mysql_query($query);                             // execute query
echo "$result\n";                                          // output result

After the application constructs the query, the executed SQL statement might look something like this:

SELECT * FROM personal WHERE ssn LIKE '123006789'

The query is executed, and the result is your personal data.

Now imagine that instead of entering your Social Security number, you enter an SQL wildcard. The application foolishly takes your input as valid and blithely plugs it in to the SQL statement:

SELECT * FROM personal WHERE ssn LIKE '%'

This would return the personal information of everyone in the table with a Social Security number!

In reality, this is a dangerously negligent application and a terrible SQL statement for at least two reasons. One reason is an example of unnecessary privilege -- since everyone has a unique Social Security number, there is no chance that a glob match (enabled by LIKE in SQL) will be required and in fact LIKE allows the wildcard operator to function. At the very least, the above code should have used the exact match test = (equals sign) instead of LIKE, which would have returned an error when it was given a wildcard to match. A more fundamental reason this application is flawed is the total lack of input validation -- since all Social Security numbers are 9 digits, there is no chance that a legitimate user would ever need to enter anything but 9 digits into the SSN field; punctuation, letters, and everything else should have been immediately flagged as an error before the SQL statement was even assembled.

Unfortunately, strict matching with = is not enough to stop knowledgeable attackers, because there are other ways to fool applications, including escaping SQL characters, using comments, cleverly extending SQL queries, using non-ASCII character sets like Unicode and UTF-8, and many others. The only response to this kind of vulnerability is to write code with the least privilege and comprehensive and correct validation of all input.

The above example exploit is extremely simple. The FCCU code and exploit will require multiple steps and a more creative approach.

Additional Reading on SQL Injection

For more information, see these articles:

• SQL on Wikipedia

• SQL Injection on Wikipedia

• SQL Injection article by Chris Shiflett

... for additional information, search online -- numerous resources and SQL tutorials exist.

Software Tools

This section will describe some tools you may need to complete this exercise.

telnet: cleartext remote shell

TELNET (TELe-NETwork) is a cleartext remote terminal protocol. On its face, telnet is very simple; the user issues commands over a TCP socket, and the server replies with the results of those commands and waits for more input. In practice, this is complicated with various network and terminal emulation layers. Still, telnet is one of the simplest and oldest network protocols still in use. Due to its cleartext nature and low level access to the system, telnet is incredibly insecure -- it was common in the past for system administrators to log in as root using telnet on a hub network connection that could be sniffed by any sufficiently prepared attacker.

Thanks to the advent of Secure Shell (ssh), active use of telnet servers has died off except for some specialized uses. One place where telnet lives on is debugging character based network services. For example, web pages can be retrieved by telnetting to HTTP servers, and emails can be sent by telnetting to SMTP servers.

Telnetting to a suspected open port is still one of the fastest ways to see if a service is available or reachable. In this exercise, we'll use telnet to explore the vulnerable HTTP server in Part 1. Here's an example of how to use telnet to access a web page:

$ telnet yahoo.com 80

Trying 66.94.234.13...
Connected to yahoo.com.
Escape character is '^]'.
GET /
...

<html><head> 
...[web page data] ...
</body>
</html>

Connection closed by foreign host.

$ cat attackscript.txt | netcat receiver 10000

:set fileformat=dos

$ mysql -uroot -pzubaz99

mysql> use fccu; # selects fccu database
mysql> select * from accounts; # print all accounts information

mysql> select * from accounts where id > 50;

$ sudo /etc/init.d/servername restart

$ sudo /etc/init.d/fhttpd.init restart

$ sudo ./fhttpd portnumber