buffer overflows – some other typical software security...
Transcript of buffer overflows – some other typical software security...
1
• Last week:– buffer overflows
• This week– some other typical software security flaws besides
buffer overflows• other input validation problems• TOCTOU & race conditions
• Next week:– more systematic ways of getting rid of such problems
Software Security
Input ValidationErik Poll
Security of Systems (SoS) groupRadboud University Nijmegen
3
Input validation
• Lack of input validation is the most commonly exploited vulnerability
• Many variants of attacks that exploit this– buffer overflows
• possibly via format string attacks and integer overflow attacks
– Command injection– SQL injection– XSS (Cross site scripting)– ...
4
Input validation
• Buffer overflows– format string attacks– integer overflow
• Command injection• SQL injection• XSS • File name injection• General remarks about input validation
5
Command injection
• A CGI script might contain cat thefile | mail clientadres
• An attack might enter email address [email protected]| rm –fr /
• What happens then ? cat thefile | mail [email protected] | rm –fr /
• Can you think of countermeasures ?– validate input– reduce access rights of CGI script (defense in depth)
6
Command injection
• Code that uses the system interpreter to print to a user-specified printer might include
char buf[1024];
snprintf(buf,"system lpr –P %s",user_input,
sizeof(buf)-1);
system(buf);
How can you attack this? Enter miro;xterm&
7
Command injection
• Vulnerability: many API calls and language constructs in many languages are affected, eg– C/C++ system(), execvp(), ShellExecute(), ..– Java Runtime.exec(), ...– Perl system, exec, open, `, /e, ...– Python exec, eval, input, execfile, ...– ...
• Countermeasures– validate all user input
• whitelist, not blacklist– run with minimal privilige
• doesn't prevent, but mitigates effects
8
Input validation
• Buffer overflows– format string attacks– integer overflow
• Command injection• SQL injection• XSS • File name injection• General remarks about input validation
9
SQL injection
Username
Password
erik ******
10
SQL injection
$result = mysql_query(
“SELECT * FROM Accounts”.
“WHERE Username = ’$username’”.
“AND Password = ’$password’;”);
if (mysql_num_rows($result)>0)
$login = true;
11
SQL injection
Resulting SQL query
SELECT * FROM Accounts
WHERE Username = ’erik’
AND Password = ’geheim’;
12
SQL injection
Username
Password
’OR 1=1;/*’******
13
SQL injection
Resulting SQL query
SELECT * FROM Accounts
WHERE Username = ’’ OR 1=1;/*’
AND Password = ’geheim’;
14
SQL injection
Resulting SQL query
SELECT * FROM Accounts
WHERE Username = ’’ OR 1=1;
/*’AND Password = ’geheim’;
Oops!
15
SQL injection
• Vulnerability: any application in any programming language that connects to SQL database
• NB typical books such as "PHP & MySQL for Dummies" contain examples that with security vulnerabilities!
16
SQL injection
• Countermeasures– input validation– use SQL stored procedures or parameterised
queries, not string concatentation– use language level countermeasures
• eg magic quotes in PHP– apply principle of least privilige:
• minimise rights of web application
17
Input validation
• Buffer overflows– format string attacks– integer overflow
• Command injection• SQL injection• XSS (Cross site scripting) • File name injection• General remarks about input validation
18
XSS (Cross site scripting)
sos Search
No matches found for sos
19
XSS (Cross site scripting)
<h1>sos</h1>
Search
No matches found for
sos
20
XSS (Cross site scripting)
• What can happen if we enter more complicated HTML code as search term ?
<img="http://www.spam.org/advert.jpg">
<script language="javascript">alert('Hoi');</script>
21
XSS (Cross site scripting)
• aka HTML injection
• Vulnerability: user input, possible including executable content
(JavaScript, VBscript, ActiveX, ..) is echoed back in a webpage
• But why is this a security problem?
22
XSS – scenario 1
1. user A injects HTML into a web site, (eg webforum, book review on amazon.com, ....), which is echoed back to user B later
2. this allows website defacement, or tricking user B to follow link to anotheronlinebookshop.com
3. worse still, B's webbrowser will execute any javascript included in the injected HTML...
4. this is done in the context of vulnerable site, ie. using B's cookies for this site...
23
XSS – scenario 2
1. user A crafts a special URL, for a vulnerable web site www.onlineshop.com, including a malicious querystring and javascript in the URL, ...
2. user A tempts user B to click on this link (by sending an email that includes the link, or posting this link on website www.mafia.org)
3. B's webbrowser will execute the script, in the context of vulnerable site, ie. with access to B's cookies for this site...
24
Session Riding
• in scenario 2, an attacker may exploit implicit authentication of user B by onlineshop.com,to carry out actions on this website in B's name, without even using scripts.
• aka Cross Site Request Forgery (CSRF)• eg, getting B to click http://bank.com/transfer.ext?amount=10000
&accountnr=522624234
while B is logged on to his bank might be enough...
• this is not an input validation problem, but an authentication problem, or TOCTOU problem
25
XSS – input vs output validation
• One can say XSS is not due to lack of input validation, but a lack of output validation
26
XSS
• Vulnerability: affects web site, built using any language or technology, that echoes back user input in a webpage
• Countermeasures– input validation (and output validation?)
1. restrict input to valid input only, and/or2. HTML encode the input
– principle of least privilige: turn of scripting languages, restrict access to cookies, don't store sensitive data in cookies,...
27
More input problems for web applications
• Data in web forms, incl. hidden form fields. Hidden form fields, eg <INPUT TYPE=HIDDEN NAME="price" VALUE="50"> are not shown in browser, unless you click View -> Page
Source..., and may be altered• Data in cookies
– cookies, stored client-side, can be altered
• Such data always has to be re-validated– Also, it may leak confidential information
28
Input validation
• Buffer overflows– format string attacks– integer overflow
• Command injection• SQL injection• XSS (Cross site scripting) • File name injection• General remarks about input validation
29
File name injection
• user-supplied file name may be– existing file ../../../etc/passwd– not really a file /var/spool/lpr– file the user can access in other ways /mnt/usbkey, /tmp/file
• this may break– confidentiality (leaking information to the user) – integrity (eg. of file or system)– availability (eg. trying to open print device for reading)
30
File name injection
• File names constructed from user input – eg by string concatenation – are suspect too
– Eg what is "/usr/local/client-info/" ++ name if name is ../../../etc/passwd ?
• aka directory traversal attack• validating file names is difficult: reuse existing code and/or
use chroot jail
31
Input validation
• Buffer overflows– format string attacks– integer overflow
• Command injection• SQL injection• XSS (Cross site scripting) • File name injection• General remarks about input validation
32
Input validation in general
• Input validations problems are the most common vulnerabilities
• Never ever trust any user input– Apart from generic risks dicussed so far (command, SQL,
XSS, filenames,...), there will be additional input risks specific to an application
• Beware of implicit assumptions on user input– eg, that usernames only contain alphanumeric characters
• Think like an attacker!– think how you might abuse a system with weird input
33
OWASP.org top 10 of web application vulnerabilities
1. Unvalidated Input Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backend components through a web application.
2. Broken Access Control 3. Broken Authentication and Session Management4. Cross Site Scripting (XSS) Flaws 5. Buffer Overflows6. Injection Flaws Web applications pass parameters when they access
external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application.
7. Improper Error Handling8. Insecure Storage9. Denial of Service 10. Insecure Configuration Management
34
19 Deadly sins of software security [Howard, LeBlanc, Viega]
1. buffer overruns2. format string problems3. integer overflows4. SQL injection5. command injection6. failing to handle errors7. XSS8. failing to protect network
traffic9. use of magic URLs or
hidden form fields10. improper use of TLS, SSL
1. weak passwords2. failing to store & protect
data securely3. information leakage4. improper file access5. trusting network name
resolution6. race conditions7. unauthenticated key
exchange8. weak random numbers9. poor usability
35
Input validation & design principles
Input validation problems highlight importance ofseveral design principles• be reluctant to trust
– never trust user input • principle of least privilige
– to limit damage that can be done• don't mix data & code
– interpreting concatenated strings is a bad sign• use community resources
– to find out about vulnerabilities– to reuse good input validation code
36
Input validation problems: prevention
• find out about potential vulnerabilities:– use community resources to find out
vulnerabilities of the system/language used• avoid use of unsafe constructs, if possible• make sure all input is validated
– at clear choke-points in code• when doing input validation
– use white-lists, not black-lists• unless you are 100% sure your black-list is complete
– reuse existing input validation code known to be correct
37
Input validation problems: detection
• testing test with inputs likely to cause problems
– for buffer overflow, long inputs (fuzzing); – for SQL injection, inputs with fragments of SQL commands; – ...There are some tools that can help, eg webscarab for XSSNote: web-application returning a page with SQL error message is
a bad sign...• code reviews, possibly using static analysis
source code analysers can check for use of dangerous calls and missing input validation for these calls (using data flow analysis), eg Fortify tool
38
Input validation – Conclusion
• Lack of input validation no #1 problem– in various guises
• Never trust user input!
• Think about, test, and detect malicious inputs!
Software SecurityNon-atomic check and use
40
Non-atomic check and use
• Standard insecurity pattern: also known as– TOCTOU (Time Of Check, Time of Use) – race condition
• Problem: some precondition required for an action is invalidated between the time it is checked and the time the action is performed– An example of such a precondition: access control
condition• The term race condition comes from concurrency
41
Classic example race condition: mkdir on Unix
• mkdir is setuid root, ie. executes as root
• It creates new directory non-atomically, in two steps:1. creates the directory, with owner is root2. sets the owner, to whoever invoked mkdir
• Attack: by creating a symbolic link between steps 1 and 2, attacker can own any file
42
Other classic UNIX race conditions
• lpr – print utility with option to remove file after printing
• but this still happens – CVE-2003-1073
A race condition in the at command for Solaris 2.6 through 9 allows local users to delete arbitrary files via the -r argument with .. sequences in the job name, then modifying the directory structure after at checks permissions to delete the file and before the deletion actually takes place
Combination of race condition with failure to check that file names do not contain ..
43
Example race condition
const char *filename="/tmp/erik";
if (access(filename, R_OK)!=0) {
... // handle error and exit;
}
// file exists and we have access
int fd open (filename, O_RDONLY);
...
Between calls to access and open the file might be removed!
.
44
Race condition & file system
Signs of trouble:• Access to files using filenames rather than file
handles or file descriptors– filenames may point to different files at different
moments in time• Creating files or directories in publicly accessible
place, for instance /tmp
– Esp if these have predictable file names
45
Promising future for data races?
• Trend: more multi-CPU machines– to keep improving computer power in accordance with
Moore's Law, despite physical contraints• Hence: more multi-threaded software
– to take advantage of max. available computing power• Hence: many problems with data races in code
– as programmers cannot cope with concurrency– writing correct concurrent programs is hard[Interesting article to read: "The free lunch is over :a fundamental turn
towardsconcurrency in software by Herb Sutter]