C++ For Dummies (2014)

---

Understanding Code Injection

Code injection occurs when the user entices your program to execute some piece of user-created code. “What? My program would never do that!” you say. Consider the most common and, fortunately for us, easiest to understand variant of this little scam: SQL injection.

Examining an example SQL injection

Let me start with a few facts about SQL:

· SQL (often pronounced “sequel”) stands for Structured Query Language.

· SQL is the most common language for accessing databases.

· SQL is used almost universally in accessing relational databases.

· SQL is not the subject of this book.

This last bullet is important because I have no intent of teaching you SQL just so you can follow the examples presented here. If you don't already know SQL, it's sufficient to say that SQL is often interpreted at runtime. Very often, C++ statements will send an SQL query to a separate database server and then process and display whatever the server sends back. A typical SQL query within a C++ program might look like the following:

char* query = "SELECT * FROM transactions WHERE accountID='123456789';"
results = submit(query);

This code says, “SELECT all of the fields FROM the transactions table WHERE the accountID (presumably one of the fields in the transaction table) is equal to 123456789 (the user's account id).” The submit() library function might send this query off to the database server. The database server would respond with all of the data it has on every transaction that the user has ever made on this account, which would get stored into the collection results. The program would then iterate through results, probably displaying the transactions in a table with each transaction on a separate row.

The user probably doesn't need that much data. Maybe just those transactions between startDate and endDate, two variables that the program reads from the user's query page. This more selective C++ program might contain a statement like the following:

char* query = "SELECT * FROM transactions WHERE accountID='123456789'"
" AND date > '" + startDate + "' AND date < '" + endDate + "';";

If the user enters 2013/10/1 for a startDate and 2013/11/1 for endDate, then the resulting query that gets sent to the database is the following:

SELECT * FROM transactions WHERE accountID='123456789' AND
date > '2013/10/1' AND date < '2013/11/1';

In other words, show all the transactions made in the month of October 2013. That makes sense. What's the problem?

The problem arises if the program just accepts whatever the user enters as start and end dates and plugs them into the query. It doesn't do any checking to make sure that the user is entering just a date and nothing but a date. This program is far too trusting.

What if a hacker were to enter 2013/10/1 for the startDate, but for the endDate he were to enter something like 2013/11/1' OR accountID='234567890. (Notice the unbalanced single quotes.) Now the combined SQL query that gets sent to the database server would look like

SELECT * FROM transactions WHERE accountID='123456789' AND
date > '2013/10/1' AND date < '2013/11/1' OR
accountID='234567890';

This says, “Show me all the transactions for the account 123456789 for the month of October 2013, plus all the transactions for some other account 234567890 that I don't own for any date.”

This little example may raise a few questions in the reader's mind: “How did the hacker know that he could enter SQL statements in place of dates?” He doesn't know — he just tries entering bogus SQL into every field that accepts character text and sees what happens. If the program complains, “That's not a legal date,” then the hacker knows that the program checks to make sure that input dates are valid and SQL injection won't work here. If, on the other hand, the program displays an error message like Illegal SQL statement, then the hacker knows that the program accepted the bogus input and shipped it off to the database server which then kicked it back. Success! Now all he has to do is formulate the query just right.

So how did the hacker know that the account ID was called accountID? He didn't know that either, but how long would it take to guess that one? Hackers are very persistent.

Finally, how did the hacker know that 234567890 was a valid account number? Again, he didn't — but do you really think that the hacker's going to stop there? Heck no. He's going to try every combination of digits he can think of until he finds some really big accounts with really big balances that are worth stealing from.

Let me assure you of three things:

· SQL injection was very common years ago.

· It was just this simple.

· With a better knowledge of SQL and some really tortured syntax, a good hacker can do almost anything he wants with an SQL injection like this.

So how can the programmer avoid this hack?

Avoiding code injection

The first rule of avoiding code inject is never, ever, allow user input to be processed by a general-purpose language interpreter. The error with the SQL-injection example was that the program accepted user input as if it were always a date and inserted it into an SQL query that it then shipped off to the database engine for processing.

The safest and most user-friendly approach would have been to provide the user a calendar graphic from which he could select the start and end dates. The program would then create a date based on what the user clicked. If this is not possible, then the program should have carefully checked the input to make sure that the input was in the proper format for a date, in this case yyyy/mm/dd — in other words, four digits followed by a slash followed by two digits and a slash and finally two more digits. Nothing else should be considered acceptable input.

Sometimes you can't be that specific about the format. If you must allow the user to enter flexible text, then you can at least avoid special characters. For example, it's pretty much impossible to do SQL code injection without using either a single or double quote. You can't insert HTML tags without using a less than (<) and greater than (>) sign. Or you could just take the approach that anything other than ASCII text will not be tolerated:

// check some string 's' to make sure it's straight ASCII
size_type off = s.find_first_not_of(
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890_");
if (off != string::npos)
{
cerr << "Error\n";
}

This code searches the string s for a character that's not one of the characters A through Z, a through z, 0 through 9, or underscore. If it finds such a character, then the program rejects the input.

If you allow only the Latin characters shown here, your application will not be useable in many foreign markets such as those that don't use English character sets (such as Arabic, Chinese, Hebrew, or Russian, to name just a few). You may have to take the opposite approach and just look for the bad characters.

Overflowing Buffers for Fun and Profit

The second common hacker method that I present is the dreaded buffer overflow. First you'll see a very small program with a very big vulnerability. You'll see how this vulnerability comes about and how it can be exploited by a hacker. Then you'll see a number of different ways to mitigate the vulnerability.

Can I see an example?

Consider the smallest, simplest hackable program that I could devise:

// BufferOverflow - this program demonstrates how a
// program that reads data into a fixed
// length buffer without checking can be
// hacked
#include <cstdio>
#include <cstdlib>
#include <fstream>
#include <iostream>
#include <cstring>
#include <string>

using namespace std;

// getString - read a string of input from the user prompt
// and return it to the caller
char* getString(istream& cin)
{
char buffer[64];

// now input a string from the file
char* pB;
for(pB = buffer;*pB = cin.get(); pB++)
{
if (cin.eof())
{
break;
}
}
*pB = '\0';

// return a copy of the string to the caller
pB = new char[strlen(buffer) + 1];
strcpy(pB, buffer);
return pB;
}

int main(int argc, char* pArgv[])
{
// get the name of the file to read
cout <<"This program reads input from an input file\n"
"Enter the name of the file:";
string sName;
cin >> sName;

// open the file
ifstream c(sName.c_str());
if (!c)
{
cout << "\nError opening input file" << endl;
exit(-1);
}

// read the file's content into a string
char* pB = getString(c);

// output what we got
cout << "\nWe successfully read in:\n" << pB << endl;

cout << "Press Enter to continue..." << endl;
cin.ignore(10, '\n');
cin.get();
printf("Done!");
exit(0);
return 0;
}

This program starts by prompting the user for the name of a file. The program then opens that file and passes the open file handle to the function getString(). This function does nothing more than read the contents of the file into a buffer, create a copy of that buffer in a memory block that it allocates off of the heap, and then returns that chunk of heap memory to the caller.

The output from a sample run of this program appears as follows:

This program reads input from an input file
Enter the name of the file:OK_File.txt

We successfully read in:
This is benign input.
Press Enter to continue...

Here the user told the program to read the file OK_File.txt and display the results, which it did.

Code::Blocks for Windows opens the console application in the project directory so all you need to enter is the file name OK_File.txt as shown. Code::Blocks for Macintosh opens the console window in your user directory so you need to enter the entire path to the file:Desktop/CPP_Programs_from_Book/Chap28/BufferOverflow/OK_File.txt (assuming that you installed the source files in the default location). This same tip is applicable to every file in this chapter.

The problem with this program lies in getString(). The programmer was told that each input file contains a short string of not more than 20 characters. Not wanting to be stingy, she allocated a 64-character buffer just to make sure that there was enough room to hold the file contents. The file OK_File.txt contains the string This is benign input. which may have been a little longer than the promised 20 characters but fits comfortably within the 64-character buffer. But let's try the program again with the file Big_File.txt; the output of this run is shown in Figure 28-1.

Figure 28-1: The result of executing the BufferOverflow program on Big_File.txt.

When presented this new file, the BufferOverflow program crashed rather than generating any reasonable output.

What you don't know is that the file Big_File.txt contains the following:

ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
abcdefghijklmnopqrstuvwxyz0123456789
ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
abcdefghijklmnopqrstuvwxyz0123456789
ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
abcdefghijklmnopqrstuvwxyz0123456789
ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
abcdefghijklmnopqrstuvwxyz0123456789

“Wait a minute!” you say. “That's not fair. That file contains more than 20 characters.” True. And it contains more than 64 characters, and for some reason that caused the program to crash. Hackers don't play fair.

How does a call stack up?

This entire section is fairly technical. You can skip it if you're not into the details of computer memory.

Consider how computer memory is laid out: There are variables known as global variables that are accessible to all functions. These variables reside at fixed memory locations so that everyone can find them. But most variables are declared within the scope of a single function. The memory for these variables is allocated when the function is called and is deallocated when the function returns. Computers do this through a mechanism known as the stack.

The stack pointer (which in assembly language parlance normally carries the name ESP) points to the next available location on the stack. A function can invoke a PUSH instruction to save a value in a register to the stack. This automatically decrements the ESP so that the memory isn't used for something else. A corresponding POP instruction restores the value to the register and increments the ESP back to its original pre-PUSH location.

Another value that gets pushed onto the stack is the return address whenever a function is called. The 80x86's instruction CALL getString pushes the next address onto the stack and then jumps to the address of the getString() function. This is shown graphically as a busy but interesting capture from the Code::Blocks debugger in Figure 28-2.

Figure 28-2: The ESP and the stack memory immediately before the call to getString().

The program is stopped at the beginning of the call to getString() (which you can tell by the yellow arrows in Figure 28-2, both in the right source view that shows only the C++ source and in the left mixed disassembly view that shows the C++ source and the 80x86 assembly language that was generated.) Notice on the left that the instruction after the CALL to getString() is 0x0046AA6C. The CPU Registers window shows that the value of the ESP is 0x0028FDC0.

Figure 28-3 shows the same windows immediately after the call to getString(). Notice that the ESP has been decremented by 4 bytes (the size of a return address) to 0x0028FDBC and that the ESP now points to the value 0x0046AA6C, the address of the next instruction after the CALL. This is called the return address.

What you actually see on the stack in Figure 28-3 is 6C-AA-46-00. This is because the 80x86 processor stores all values with the least significant byte at the smallest address. This is called Little Endian.

Figure 28-3: The ESP and the stack memory immediately after the call to getString().

Figure 28-4 shows the situation immediately after a successful return from getString(). The small yellow arrow in the disassembly window shows that the instruction pointer is indeed pointing to the instruction immediately after the CALL and the ESP has returned to its former value of0x0028FDC0.

That's all very nice, but so what? Well, C++ also stores locally defined variables on the stack. For example, the 64-byte buffer in getString() is stored on the stack. As long as the program writes only 64 bytes (or less) into this buffer, everything is fine; but if the program tries to write more data into buffer than buffer can hold, the remaining data spills over and starts overwriting other data. If the program writes far enough, it will eventually overwrite the return address. This is exactly what happened when getString() read the oversized Big_File.txt. This is shown in Figure28-5.

Figure 28-4: The ESP and the stack memory immediately after the return from getString().

Figure 28-5: The return address on the stack are overwritten when getString() tries to read Big_File.txt.

You can see that the location 0x0028FDC0 no longer contains the return address, but rather the value 0x46454443, which happens to be the ASCII characters “FEDC”, which you can also see along with many of the other characters from Big_File.txt on the right of Figure 28-5.

Remember to read the bytes from right to left since the 80x86 is Little Endian.

This doesn't cause a problem as long as the program is processing through getString(), but when the program tries to return, the return address that’s on the stack is not a return address at all. Instead, it points to some illegal address, and the program crashes as soon as it executes the RETstatement at the end of getString().

Hacking BufferOverflow

The BufferOverflow program crashed because the contents of Big_File.txt overflowed buffer and overwrote the return address within the function getString(). When the function attempted to execute a return instruction, control passed to some garbage address, and the program crashed.

But what if you could engineer the text file so that it overwrote the return address not with crazy ASCII characters, but with the address of some code that you wanted to force the program to execute? When getString() executed a RET, it wouldn't crash, it would go off and execute the code you want it to.

But where could you put this extra code? What better place than within the text that's already been read into buffer? So the hack goes like this:

1. Create a machine language program that does whatever you want the program to do and insert it into the input file first.

2. Make sure that the input overflows the buffer just far enough that the return address gets overwritten with the address of buffer itself.

3. When the program reads the text into the buffer, it will in effect load the hacker code into buffer and then overwrite the return address.

4. When getString() tries to return to where it was called in main(), control will pass to the beginning of buffer, where the hacker code gets executed.

This sounds pretty tricky, and actually, it is. But remember that the hacker can execute your program as often as he wants. When executed with a good debugger, he can figure out how big to make the buffer and what address to use for buffer.

Just to show you that such a thing is possible, check out the following run:

C:\CPP_Programs\Chap28\BufferOverflow>BufferOverflow
This program reads input from an input file
Enter the name of the file:BO_File.txt
You've been hacked!
C:\CPP_Programs\Chap28\BufferOverflow>

Here the program starts out like normal by prompting the user for an input file. This time the user entered the file name BO_File.txt. In response, the program didn't output the contents of the file as you might expect, nor did it crash. Instead, in response to this file, the program output the ominous message “You've been hacked!” and exited. Notice in particular that the program didn't output the normal “Press Enter to continue…”. This program went directly to Jail, didn't pass Go, and didn't collect $200! Control never returned from getString() back to main().

In fact, the file BO_File.txt (which stands for Buffer Overflow File, by the way) contains a small machine language program that outputs the message “You've been hacked!” and then calls exit(0) to exit normally. In addition, it's crafted in just such a way that it overwrites the return address with the beginning of the buffer to cause this program to be executed when getString() attempts to return, just as described earlier.

The details of a hack like this are very specific to exactly how the executable file is laid out in memory. This particular version of BO_File.txt works on only versions of BufferOverflow built for Windows with a particular version of gcc. This is not a limitation of the overflow hack itself — I could create a version of BO_File.txt for Linux or Macintosh and for a different version of gcc. Since you may not be using the same version of gcc that I am, I have included the .exe executable in the BufferOverflow directory right next to the source code. To execute this version, you will need to open a console in Windows, navigate to the proper directory (in my case, C:\CPP_Programs_from_Book\Chap28\BufferOverflow), and enter the command BufferOverflow.