Software Security CSM27 Computer Security Dr Hans Georg Schaathun - - PowerPoint PPT Presentation

Software Security

CSM27 Computer Security Dr Hans Georg Schaathun

University of Surrey

Autumn 2009 – Week 9

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 1 / 30

The session

Outline

1

The session

2

Examples

3

Overflows

4

Coding Practices

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 2 / 30

The session

Session objectives

Be aware of implementation errors leading to security vulnerabilities Discuss dangers of broken abstraction

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 3 / 30

The session

Source

Most of this material is due to Robert C Seacord Examples from Secure Coding in C and C++ Practices from

https://www.securecoding.cert.org/confluence/ display/seccode/Top+10+Secure+Coding+Practices

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 4 / 30

The session

Security or Useability

This chapter is largely about software bugs

Is this security? . . . or is it useability?

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 5 / 30

The session

Security or Useability

This chapter is largely about software bugs

Is this security? . . . or is it useability?

Answer is yes

Bugs are user (programmer) mistakes – useability. Many bugs cause security vulnerabilities.

Useability is a prerequisite of security.

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 5 / 30

The session

Security or Useability

This chapter is largely about software bugs

Is this security? . . . or is it useability?

Answer is yes

Bugs are user (programmer) mistakes – useability. Many bugs cause security vulnerabilities.

Useability is a prerequisite of security.

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 5 / 30

Examples

Outline

1

The session

2

Examples

3

Overflows

4

Coding Practices

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 6 / 30

Examples

Why is this code insecure?

bool IsPasswordOkay ( void ) { char Password [12] ; gets ( Password ) ; i f ( ! strcmp ( Password , " goodpass " ) ) return true ; else return ( false ) ; } void main ( void ) { bool PwStatus ; puts ( " Enter password : " ) ; PwStatus = IsPasswordOkay ( ) ; i f ( PwStatus == false ) { puts ( " Access denied " ) ; e x i t (−1) ; } else puts ( " Access granted " ) ; }

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 7 / 30

Examples

String handling

Why is this insecure? int main ( int argc , char∗ argv [ ] ) { char a [16] ; char b [16] ; char c [32] ; strcpy ( a , " 0123456789abcdef " ) ; strcpy ( b , " 0123456789abcdef " ) ; strcpy ( c , a ) ; s t r c a t ( c , b ) ; p r i n t f ( "a = %s \ n" , a ) ; return 0 ; }

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 8 / 30

Examples

String handling

A C string is an array of characters (bytes).

represented by pointer to start of array

0 byte marks the end of the string.

E.g. 16-character string requires 17 bytes

Easy to forget.

Hard bug to spot.

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 9 / 30

Overflows

Outline

1

The session

2

Examples

3

Overflows

4

Coding Practices

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 10 / 30

Overflows

Integer Overflows

Integers in mathematical terms is an infinite set {−∞, . . . , −2, −1, 0, 1, 2, . . . , ∞} Integers in computing terms is a finite set

8-bit: {0, 1, 2, 3, . . . , 254, 255} 32-bit: {0, 1, 2, 3, . . . , 232 − 2, 232 − 1}

This is (often) a broken abstraction

What is 212 + 64? Using 8-bit integers in C, we get 20! Safe languages would raise an exception (run-time).

If your language has no built-in protection

you have to make your own protection manually

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 11 / 30

Overflows

Integer Overflows

Integers in mathematical terms is an infinite set {−∞, . . . , −2, −1, 0, 1, 2, . . . , ∞} Integers in computing terms is a finite set

8-bit: {0, 1, 2, 3, . . . , 254, 255} 32-bit: {0, 1, 2, 3, . . . , 232 − 2, 232 − 1}

This is (often) a broken abstraction

What is 212 + 64? Using 8-bit integers in C, we get 20! Safe languages would raise an exception (run-time).

If your language has no built-in protection

you have to make your own protection manually

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 11 / 30

Overflows

Integer Overflows

Integers in mathematical terms is an infinite set {−∞, . . . , −2, −1, 0, 1, 2, . . . , ∞} Integers in computing terms is a finite set

8-bit: {0, 1, 2, 3, . . . , 254, 255} 32-bit: {0, 1, 2, 3, . . . , 232 − 2, 232 − 1}

This is (often) a broken abstraction

What is 212 + 64? Using 8-bit integers in C, we get 20! Safe languages would raise an exception (run-time).

If your language has no built-in protection

you have to make your own protection manually

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 11 / 30

Overflows

Stack Overrun

argument a argument b argument c Return address Saved frame pointer local variable x local variable y Original stack frame

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 12 / 30

Overflows

Stack Overrun

argument a argument b argument c Return address Saved frame pointer local variable x local variable y Original stack frame argument a argument b argument c Bad return address . . . . . . . . . Overrun

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 12 / 30

Overflows

The finger bug

Command Argument Meaning push1 $68732f push ’/sh,<nul>’ push1 $6e69622f push ’/bin’ mov1 sp, r10 save address of start of string push1 $0 push 0 (argument 3) push1 $0 push 0 (argument 2) push1 r10 push string address (arg. 1) push1 $3 push argument count mov1 sp, ao set argument pointer chmk $3b make execve kernel call Executes execve("/bin/sh",0,0) on return

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 13 / 30

Overflows

The finger bug

Command Argument Meaning push1 $68732f push ’/sh,<nul>’ push1 $6e69622f push ’/bin’ mov1 sp, r10 save address of start of string push1 $0 push 0 (argument 3) push1 $0 push 0 (argument 2) push1 r10 push string address (arg. 1) push1 $3 push argument count mov1 sp, ao set argument pointer chmk $3b make execve kernel call Executes execve("/bin/sh",0,0) on return

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 13 / 30

Coding Practices

Outline

1

The session

2

Examples

3

Overflows

4

Coding Practices

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 14 / 30

Coding Practices

• 1. Validate input

Validate input from all untrusted data sources. Proper input validation can eliminate the vast majority of software vulnerabilities. Be suspicious of most external data sources, including

command line arguments network interfaces environmental variables user controlled files

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 15 / 30

Coding Practices

• 1. Validate input

Validate input from all untrusted data sources. Proper input validation can eliminate the vast majority of software vulnerabilities. Be suspicious of most external data sources, including

command line arguments network interfaces environmental variables user controlled files

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 15 / 30

Coding Practices

Example: path names

Suppose you write an application, where users upload files

The user can specify a filename, e.g. holiday.jpg, ... and you prepend a directory name, e.g. /public/images/

How can this be exploited? Suppose the users use filename /../../etc/passwd. How do we avoid this? Input checking is possible;

../ is an illegal string.

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 16 / 30

Coding Practices

Example: path names

Suppose you write an application, where users upload files

The user can specify a filename, e.g. holiday.jpg, ... and you prepend a directory name, e.g. /public/images/

How can this be exploited? Suppose the users use filename /../../etc/passwd. How do we avoid this? Input checking is possible;

../ is an illegal string.

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 16 / 30

Coding Practices

Example: path names

Suppose you write an application, where users upload files

The user can specify a filename, e.g. holiday.jpg, ... and you prepend a directory name, e.g. /public/images/

How can this be exploited? Suppose the users use filename /../../etc/passwd. How do we avoid this? Input checking is possible;

../ is an illegal string.

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 16 / 30

Coding Practices

Character Encoding

Vulnerabilities in Unicode

Unicode collects characters for (almost) every language UTF-8 is the most common encoding of Unicode Variable length characters

ASCII (American 7-bit character set) uses one byte

Ensuring compatibility.

Western European (non-ASCII) characters use two bytes More exotic characters require 3 or 4 bytes

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 17 / 30

Coding Practices

Unicode encoding

Each byte has a prefix

0 – one-byte character 110 – first byte of two-byte character 1110 – first byte of three-byte character 11110 – first byte of four-byte character 10 – second or later byte of multi-byte character

Remaining bits contain a unicode character number

1 byte : 7 bits 2 bytes : 11 bits (5+6) 3 bytes : 16 bits (4+6+6) 4 bytes : 21 bits (3+6+6+6)

Only shortest possible representation is legal

but illegal representations are often accepted

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 18 / 30

Coding Practices

Exploiting it

Your application bans filenames containing ../ But there are many ways to write /

/ is Unicode 0010 1111

1 byte : 0010 1111 2 byte : 1100 0000 1010 1111 3 byte : 1110 0000 1000 0000 1010 1111 4 byte : 1111 0000 1000 0000 1000 0000 1010 1111

So if your system accepts multi-byte forms, ... your input checking has to ban all representations of /.

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 19 / 30

Coding Practices

Canonical Representation

UTF-8 is an example of the use of canonical representations Several equivalent forms are defined Only the shortest form is canonical Before a safe comparison can be made . . . data should be converted into canonical form

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 20 / 30

Coding Practices

Example: Napster filenames

Napster was ordered by court to block certain songs Solutions

filter downloads based on filename

Napster users by-passed this control

using equivalent (variations of) the song titles

Almost impossible to control

title equivalence is defined by the users...

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 21 / 30

Coding Practices

• 2. Heed compiler warnings

Compile code using the highest warning level eliminate warnings by modifying the code

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 22 / 30

Coding Practices

• 2. Heed compiler warnings

Compile code using the highest warning level eliminate warnings by modifying the code

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 22 / 30

Coding Practices

• 3. Architect and design for security policies.

Create and design systems to allow security policies E.g. if your system requires different privileges at different times,

consider dividing the system into distinct intercommunicating subsystems, each with an appropriate privilege set.

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 23 / 30

Coding Practices

• 3. Architect and design for security policies.

Create and design systems to allow security policies E.g. if your system requires different privileges at different times,

consider dividing the system into distinct intercommunicating subsystems, each with an appropriate privilege set.

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 23 / 30

Coding Practices

• 4. Keep it simple.

Keep the design as simple and small as possible. Complex designs makes it harder to avoid implementation errors. Complex systems are harder to evaluate.

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 24 / 30

Coding Practices

• 4. Keep it simple.

Keep the design as simple and small as possible. Complex designs makes it harder to avoid implementation errors. Complex systems are harder to evaluate.

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 24 / 30

Coding Practices

• 5. Default deny.
• 6. Adhere to the principle of least privilege.

Base access decisions on permission rather than exclusion. By default, access is denied Policies have to identify conditions where access is necessary (and thus granted) Purpose Limit the damage.

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 25 / 30

Coding Practices

• 5. Default deny.
• 6. Adhere to the principle of least privilege.

Base access decisions on permission rather than exclusion. By default, access is denied Policies have to identify conditions where access is necessary (and thus granted) Purpose Limit the damage.

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 25 / 30

Coding Practices

• 7. Sanitize data sent to other systems.

Sanitize all data passed to complex subsystems

e.g. command shells, relational databases, and commercial

• ff-the-shelf (COTS) components

injection attacks may exploit unused features of these systems

SQL injection, command injection

not necessarily an input validation problem

subsystem does not understand the context

calling process has the context

hence it has the responsibility

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 26 / 30

Coding Practices

• 7. Sanitize data sent to other systems.

Sanitize all data passed to complex subsystems

e.g. command shells, relational databases, and commercial

• ff-the-shelf (COTS) components

injection attacks may exploit unused features of these systems

SQL injection, command injection

not necessarily an input validation problem

subsystem does not understand the context

calling process has the context

hence it has the responsibility

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 26 / 30

Coding Practices

The rlogin bug

rlogin(1) used to allow remote login access to Unix systems

rlogin [-luser] hostname

The rlogin client contacts a remote host which runs login(1)

Running rlogin -l css1hs kyle, would . . . on kyle, cause the running of login css1hs.

Now, login(1) has many uses,

login -froot is a forced login (as root) ... no password prompt

rlogin -l -froot kyle – what happens?

login -froot – superuser login without password Unused functionality is exploited. ... unless rlogin sanitises the input

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 27 / 30

Coding Practices

The rlogin bug

rlogin(1) used to allow remote login access to Unix systems

rlogin [-luser] hostname

The rlogin client contacts a remote host which runs login(1)

Running rlogin -l css1hs kyle, would . . . on kyle, cause the running of login css1hs.

Now, login(1) has many uses,

login -froot is a forced login (as root) ... no password prompt

rlogin -l -froot kyle – what happens?

login -froot – superuser login without password Unused functionality is exploited. ... unless rlogin sanitises the input

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 27 / 30

Coding Practices

The rlogin bug

rlogin(1) used to allow remote login access to Unix systems

rlogin [-luser] hostname

The rlogin client contacts a remote host which runs login(1)

Running rlogin -l css1hs kyle, would . . . on kyle, cause the running of login css1hs.

Now, login(1) has many uses,

login -froot is a forced login (as root) ... no password prompt

rlogin -l -froot kyle – what happens?

login -froot – superuser login without password Unused functionality is exploited. ... unless rlogin sanitises the input

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 27 / 30

Coding Practices

• 8. Practice defense in depth.

multiple defensive strategies,

have a safety net – in case one defence breaks

For example, combine

secure programming techniques secure runtime environments

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 28 / 30

Coding Practices

• 8. Practice defense in depth.

multiple defensive strategies,

have a safety net – in case one defence breaks

For example, combine

secure programming techniques secure runtime environments

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 28 / 30

Coding Practices

• 9. Use effective quality assurance techniques.

quality assurance techniques can be effective

identify and eliminate vulnerabilities

Penetration testing, fuzz testing, and source code audits Independent reviews

external reviewers bring an independent perspective e.g. identify and correct invalid assumptions

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 29 / 30

Coding Practices

• 9. Use effective quality assurance techniques.

quality assurance techniques can be effective

identify and eliminate vulnerabilities

Penetration testing, fuzz testing, and source code audits Independent reviews

external reviewers bring an independent perspective e.g. identify and correct invalid assumptions

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 29 / 30

Coding Practices

• 10. Adopt a secure coding standard.

Develop and/or apply a secure coding standard for your target development language and platform.

Dr Hans Georg Schaathun Software Security Autumn 2009 – Week 9 30 / 30