Scribd
Upload
50 views

Buffer Overflow Attacks, SQL Injection Attacks

This document discusses buffer overflow attacks and SQL injection attacks. It provides techniques for preventing these attacks, including input validation, safe programming practices, and defense-in-depth strategies. Specific examples are given of how SQL injection and buffer overflow attacks work. The document recommends validating all input, avoiding unsafe string functions, and using prepared statements to defend against SQL injection attacks.

Uploaded by

Raymond
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
50 views

Buffer Overflow Attacks, SQL Injection Attacks

This document discusses buffer overflow attacks and SQL injection attacks. It provides techniques for preventing these attacks, including input validation, safe programming practices, and defense-in-depth strategies. Specific examples are given of how SQL injection and buffer overflow attacks work. The document recommends validating all input, avoiding unsafe string functions, and using prepared statements to defend against SQL injection attacks.

Uploaded by

Raymond
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 42

Buffer overflow attacks, SQL

injection attacks
Buffer overflows
HW3
 Out shortly…
 Buffer overflow attacks
– Will need to use gdb
Using gdb
Input validation
 Buffer overflows can be viewed as an example of
improper input validation
 Other notable examples:
– Format string vulnerabilities
more later
– SQL injection attacks
 Two general mechanisms to prevent attacks
– Better input validation
– Safe programming techniques; techniques for detecting
potential buffer overflows in code; …
Defenses (briefly!)
 Secure programming techniques
 Penetration testing
 Static analysis
 Dynamic analysis
Secure programming techniques
 Validate all input
 Avoid buffer overflows (use safe string
manipulation functions, careful length checking,
etc., …)
Validating input
 Determine acceptable input, check for match ---
don’t just check against list of “non-matches”
– Limit maximum length
– Watch out for special characters, escape chars.
 Check bounds on integer values
– Check for negative inputs
– Check for large inputs that might cause overflow!
Validating input
 Filenames
– Disallow *, .., etc.
 Command-line arguments
– Even argv[0]…
 Commands
– E.g., SQL (see later)
 URLs, http variables
– E.g., cross site scripting, more
– Next lecture
Avoiding buffer overflows
 Use arrays instead of pointers

 Make buffers (slightly) longer than necessary to


avoid “off-by-one” errors

 Careful length checking


Avoid strcpy, …
 We have seen that strcpy is unsafe
– strcpy(buf, str) simply copies memory contents into buf
starting from *str until “\0” is encountered, ignoring the
size of buf
 Avoid strcpy(), strcat(), gets(), etc.
– Use strncpy(), strncat(), instead
– Even these are not perfect… (e.g., no null termination)
– Always a good idea to do your own validation when
obtaining input from untrusted source
– Still need to be careful when copying multiple inputs
into a buffer
Does range checking help?
 strncpy(char *dest, const char *src, size_t n)
– No more than n characters will be copied from *src to *dest
• Programmer has to supply the right value of n!

 Bad:
… strcpy(record,user);
strcat(record,”:”);
strcat(record,cpw); …

 Published “fix” (do you see the problem?):


… strncpy(record,user,MAX_STRING_LEN-1);
strcat(record,”:”);
strncat(record,cpw,MAX_STRING_LEN-1); …
Off-by-one overflow
 Consider the following code:
char buf[512]; int i;
for (i=0; i <= 512; i++)
buf[i] = input[i];

 1-byte overflow: can’t change return address, but


can change pointer to previous stack frame
– On little-endian architecture, make it point into buffer
Static/dynamic analysis
 Static analysis: run on the source code prior to
deployment; check for known flaws
– E.g., flawfinder, cqual
 Dynamic analysis: try to catch (potential) buffer
overflows during program execution
 Comparison?
– Static analysis very useful, but not perfect
– Dynamic analysis can be better (in tandem with static
analysis), but can slow down execution
Dynamic analysis: Libsafe
 Intercepts all calls to, e.g., strcpy (dest, src)
– Validates sufficient space in current stack frame:
|frame-pointer – dest| > strlen(src)
– If so, executes strcpy; otherwise, terminates application
Preventing buffer overflows
 Basic stack exploit can be prevented by marking
stack segment as non-executable, or randomizing
stack location
 Problems:
– Does not defend against `return-to-libc’ exploit
• Overflow sets ret-addr to address of libc function
– Some apps need executable stack
– Does not prevent general buffer overflow flaws, or heap
overflow
StackGuard
 Embed random “canaries” in stack frames and
verify their integrity prior to function return

 This is actually used!


– Helpful, but not foolproof…

Frame 2 Frame 1
local canary sfp ret str local canary sfp ret str
More methods …
 Address obfuscation
– Encrypt return address on stack by XORing with
random string. Decrypt just before returning from
function
– Attacker needs decryption key to set return address to
desired value
More input validation flaws
Format string vulnerabilities
 What is the difference between
printf(buf);
and
printf(“%s”, buf);
?
 What if buf holds %x ?
 Look at memory, and what printf expects…
What happens?
 printf(“%x”) expects an additional argument…
“%x”

ret Frame of the


ebp addr buf calling function

args Will print the value


sitting here

 What if we could write that value instead?


– See “Blended attacks…”
Other input validation bugs
 Say a program reads from a user-specified file
 Program running in directory /secure, but only
allows access to files in /secure/pub
– Checks that the filename supplied by the user begins
with /pub
 What if the user supplies the filename
“/pub/../top_secret” ?
Other input validation bugs
 Integer overflow…
 Consider the code:
strncpy(msg+offset, str, slen);
where the adversary may control offset
 By setting the value high enough, it will wrap
around and be treated as a negative integer!
SQL injection attacks
 Affect applications that use untrusted input as part
of an SQL query to a back-end database
 Specific case of a more general problem: using
untrusted input in commands
SQL injection: example
 Consider a browser form, e.g.:

 When the user enters a number and clicks the button, this
generates an http request like
https://www.pizza.com/show_orders?month=10
Example continued…
 Upon receiving the request, a java script might
generate an SQL query as follows:
sql_query
= "SELECT pizza, quantity, order_day "
+ "FROM orders "
+ "WHERE userid=" + session.getCurrentUserId()
+ " AND order_month= "
+ request.getParameter("month");

 A normal query would look like:


SELECT pizza, quantity, order_day
FROM orders
WHERE userid=4123
AND order_month=10
Example continued…
 What if the user makes a modified http request:
https://www.pizza.com/show_orders?month=0%20OR%201%3D1

 (Parameters transferred in URL-encoded form,


where meta-characters are encoded in ASCII)
 This has the effect of setting
request.getParameter(“month”)
equal to the string
0 OR 1=1
Example continued
 So the script generates the following SQL query:

SELECT pizza, quantity, order_day


FROM orders
WHERE(userid=4123
AND order_month=0)OR 1=1

 Since AND takes precedence over OR, the above


always evaluates to TRUE
– The attacker gets every entry in the database!
Even worse…
 Craft an http request that generates an SQL query
like the following:

SELECT pizza, quantity, order_day


FROM orders
WHERE userid=4123
AND order_month=0 OR 1=0
UNION SELECT cardholder, number, exp_date
FROM creditcards

 Attacker gets the entire credit card database as


well!
More damage…
 SQL queries can encode multiple commands,
separated by ‘;’
 Craft an http request that generates an SQL query
like the following:
SELECT pizza, quantity, order_day
FROM orders
WHERE userid=4123
AND order_month=0 ;
DROP TABLE creditcards

 Credit card table deleted!


– DoS attack
More damage…
 Craft an http request that generates an SQL query
like the following:
SELECT pizza, quantity, order_day
FROM orders
WHERE userid=4123
AND order_month=0 ;
INSERT INTO admin VALUES (‘hacker’, ...)

 User (with chosen password) entered as an


administrator!
– Database owned!
May need to be more clever…
 Consider the following script for text queries:

sql_query
= "SELECT pizza, quantity, order_day "
+ "FROM orders "
+ "WHERE userid=" + session.getCurrentUserId()
+ " AND topping= ‘ "
+ request.getParameter(“topping") + “’”

 Previous attacks will not work directly, since the


commands will be quoted
 But easy to deal with this…
Example continued…
 Craft an http request where
request.getParameter(“topping”)
is set to
abc’; DROP TABLE creditcards; --

 The effect is to generate the SQL query:


SELECT pizza, quantity, order_day
FROM orders
WHERE userid=4123
AND toppings=‘abc’;
DROP TABLE creditcards ; --’
 (‘--’ represents an SQL comment)
Second order attacks
 Attack where two consecutive queries cause the
attack
 E.g., query1 = “INSERT INTO users(name,passwd)
VALUES (‘” + uname + “’,‘”
+ password + “’)” ;

query2 = “UPDATE users SET passwd=‘” +


+ new_password + “’ WHERE name=‘”
+ uname + “’” ;

 What if a user sets uname = admin’ -- ?


– (uname = admin causes a conflict)
Source: http://xkcd.com/327/
Solutions?
 Defense-in-depth…
– Use several solutions, as appropriate

 Blacklisting
 Whitelisting
 Prepared statements/bind variables
 Mitigate the impact of SQL injection
Blacklisting?
 I.e., searching for/preventing ‘bad’ inputs
 E.g., for previous example:
sql_query
= "SELECT pizza, quantity, order_day "
+ "FROM orders "
+ "WHERE userid=" + session.getCurrentUserId()
+ " AND topping= ‘ "
+ kill_chars(request.getParameter(“topping"))
+ “’”

 …where kill_chars() deletes, e.g., quotes and


semicolons
Drawbacks of blacklisting
 How do you know if/when you’ve eliminated all
possible ‘bad’ strings?
– If you miss one, could allow successful attack
 Does not prevent first set of attacks (numeric
values)
– Although similar approach could be used, starts to get
complex!
 May conflict with functionality of the database
– E.g., user with name O’Brien
Whitelisting
 Check that user-provided input is in some set of
values known to be safe
– E.g., check that month is an integer in the right range

 If invalid input detected, better to reject it than to


try to fix it
– Fixes may introduce vulnerabilities
– Principle of fail-safe defaults
Prepared statements/bind variables
 Prepared statements: static queries with bind
variables
– Variables not involved in query parsing

 Bind variables: placeholders guaranteed to be data


in correct format
Example (Java)
PreparedStatement ps =
db.prepareStatement(
"SELECT pizza, quantity, order_day "
+ "FROM orders WHERE userid=?
AND order_month=?");

ps.setInt(1, session.getCurrentUserId());
ps.setInt(2,
Integer.parseInt(request.getParameter("month")));
ResultSet res = ps.executeQuery();

Bind variables
Mitigating the impact
 Limit privileges
– I.e., allow SELECT queries on the orders database, but
no queries on creditcards database
– Can limit commands, or tables to which access is given
(or both)
– Principle of least privilege
– Not a complete fix, but it helps
 Encrypt sensitive data stored in database
– E.g., orders in the clear but credit card numbers
encrypted

You might also like