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


• 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


WHERE Username = ’’ OR 1=1;/*’

AND Password = ’geheim’;

14

SQL injection

Resulting SQL query


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


• 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


<h1>sos</h1>

Search

No matches found for

sos

20


• 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


• 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



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



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]

buffer overflows – some other typical software security...

Documents