Secure Programming, Continued Computer Security Peter Reiher December 4, 2014 - PowerPoint PPT Presentation

Loading...

PPT – Secure Programming, Continued Computer Security Peter Reiher December 4, 2014 PowerPoint presentation | free to download - id: 7149eb-MTZkY



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Secure Programming, Continued Computer Security Peter Reiher December 4, 2014

Description:

Secure Programming, Continued Computer Security Peter Reiher December 4, 2014 – PowerPoint PPT presentation

Number of Views:15
Avg rating:3.0/5.0

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Secure Programming, Continued Computer Security Peter Reiher December 4, 2014


1
Secure Programming, ContinuedComputer Security
Peter ReiherDecember 4, 2014

2
Outline
  • Introduction
  • Principles for secure software
  • Major problem areas

3
Example Problem Areas
  • Buffer overflows
  • Error handling
  • Access control issues
  • Race conditions
  • Use of randomness
  • Proper use of cryptography
  • Trust
  • Input verification
  • Variable synchronization
  • Variable initialization

4
Error Handling
  • Error handling code often gives attackers great
    possibilities
  • Its rarely executed and often untested
  • So it might have undetected errors
  • Attackers often try to compromise systems by
    forcing errors

5
A Typical Error Handling Problem
  • Not cleaning everything up
  • On error conditions, some variables dont get
    reset
  • If error not totally fatal, program continues
    with old values
  • Could cause security mistakes
  • E.g., not releasing privileges when you should

6
Some Examples
  • Remote denial of service attack on Apache HTTP
    server due to bad error handling (2010)
  • Internet Explorer arbitrary code execution flaw
    (2007)
  • Use-after-free bug in script error handling code

7
Checking Return Codes
  • A generalization of error handling
  • Always check return codes
  • A security program manager for Microsoft said
    this is his biggest problem
  • Very dangerous to bull ahead if it turns out your
    call didnt work properly
  • Example Nagios XI didnt check the return value
    of setuid() call, allowing privilege escalation

8
Access Control Issues
  • Programs usually run under their users identity
    with his privileges
  • Some programs get expanded privileges
  • Setuid programs in Unix, e.g.
  • Poor programming here can give too much access

9
An Example Problem
  • A program that runs setuid and allows a shell to
    be forked
  • Giving the caller a root environment in which to
    run arbitrary commands
  • Buffer overflows in privileged programs usually
    give privileged access

10
A Real World Example
  • /sbin/dump from NetBSD
  • Ran setgid as group tty
  • To notify sysadmins of important events
  • Never dropped this privilege
  • Result dump would start program of users choice
    as user tty
  • Allowing them to interact with other users
    terminals

11
What To Do About This?
  • Avoid running programs setuid
  • Or in other OSs high privilege modes
  • If you must, dont make them root-owned
  • Remember, least privilege
  • Change back to the real caller as soon as you can
  • Limiting exposure
  • Use virtualization to compartmentalize

12
Virtualization Approaches
  • Run stuff in a virtual machine
  • Only giving access to safe stuff
  • Hard to specify whats safe
  • Hard to allow safe interactions between different
    VMs
  • VM might not have perfect isolation

13
Race Conditions
  • A common cause of security bugs
  • Usually involve multiprogramming or multithreaded
    programs
  • Caused by different threads of control operating
    in unpredictable fashion
  • When programmer thought theyd work in a
    particular order

14
What Is a Race Condition?
  • A situation in which two (or more) threads of
    control are cooperating or sharing something
  • If their events happen in one order, one thing
    happens
  • If their events happen in another order,
    something else happens
  • Often the results are unforeseen

15
Security Implications of Race Conditions
  • Usually you checked privileges at one point
  • You thought the next lines of code would run next
  • So privileges still apply
  • But multiprogramming allows things to happen in
    between

16
The TOCTOU Issue
  • Time of Check to Time of Use
  • Have security conditions changed between when you
    checked?
  • And when you used it?
  • Multiprogramming issues can make that happen
  • Sometimes under attacker control

17
A Short Detour
  • In Unix, processes can have two associated user
    IDs
  • Effective ID
  • Real ID
  • Real ID is the ID of the user who actually ran it
  • Effective ID is current ID for access control
    purposes
  • Setuid programs run this way
  • System calls allow you to manipulate it

18
Effective UID and Access Permissions
  • Unix checks accesses against effective UID, not
    real UID
  • So setuid program uses permissions for the
    programs owner
  • Unless relinquished
  • Remember, root has universal access privileges

19
An Example
  • Code from Unix involving a temporary file
  • Runs setuid root
  • res access(/tmp/userfile, R_OK)
  • If (res ! 0)
  • die(access)
  • fd open(/tmp/userfile,O_RDONLY)

20
Whats (Supposed to Be) Going on Here?
  • Checked access on /tmp/userfile to make sure user
    was allowed to read it
  • User can use links to control what this file is
  • access() checks real user ID, not effective one
  • So checks access permissions not as root, but as
    actual user
  • So if user can read it, open file for read
  • Which root is definitely allowed to do
  • Otherwise exit

21
Whats Really Going On Here?
  • This program might not run uninterrupted
  • OS might schedule something else in the middle
  • In particular, between those two lines of code

22
How the Attack Works
  • Attacker puts innocuous file in
  • /tmp/userfile
  • Calls the program
  • Quickly deletes file and replaces it with link to
    sensitive file
  • One only readable by root
  • If timing works, he gets secret contents

23
The Dynamics of the Attack
Lets try that again!
One more time!
Success!

/tmp/userfile
/etc/secretfile
  • Run program

2. Change file
res access(/tmp/userfile, R_OK) if (res !
0) die(access) fd open(/tmp/userfile,O_R
DONLY)
24
How Likely Was That?
  • Not very
  • The timing had to be just right
  • But the attacker can try it many times
  • And may be able to influence system to make it
    more likely
  • And he only needs to get it right once
  • Timing attacks of this kind can work
  • Google Chrome had one in 2011
  • The longer between check and use, the more
    dangerous

25
Some Types of Race Conditions
  • File races
  • Which file you access gets changed
  • Permissions races
  • File permissions are changed
  • Ownership races
  • Who owns a file changes
  • Directory races
  • Directory hierarchy structure changes

26
Preventing Race Conditions
  • Minimize time between security checks and when
    action is taken
  • Be especially careful with files that users can
    change
  • Use locking and features that prevent
    interruption, when possible
  • Avoid designs that require actions where races
    can occur

27
Randomness and Determinism
  • Many pieces of code require some randomness in
    behavior
  • Where do they get it?
  • As earlier key generation discussion showed, its
    not that easy to get

28
Pseudorandom Number Generators
  • PRNG
  • Mathematical methods designed to produce strings
    of random-like numbers
  • Actually deterministic
  • But share many properties with true random
    streams of numbers

29
Attacks on PRNGs
  • Cryptographic attacks
  • Observe stream of numbers and try to deduce the
    function
  • State attacks
  • Attackers gain knowledge of or influence the
    internal state of the PRNG

30
An Example
  • ASF Softwares Texas HoldEm Poker
  • Flaw in PRNG allowed cheater to determine
    everyones cards
  • Flaw in card shuffling algorithm
  • Seeded with a clock value that can be easily
    obtained

31
Another Example
  • Flaw in Android random number generator in 2013
  • Left Bitcoin wallets in that platform vulnerable
    to theft
  • By making it much easier to deduce a secret key
    that used the RNG

32
How to Do Better?
  • Use hardware randomness, where available
  • Use high quality PRNGs
  • Preferably based on entropy collection methods
  • Dont use seed values obtainable outside the
    program

33
Proper Use of Cryptography
  • Never write your own crypto functions if you have
    any choice
  • Another favorite piece of advice from industry
  • Never, ever, design your own encryption algorithm
  • Unless thats your area of expertise
  • Generally, rely on tried and true stuff
  • Both algorithms and implementations

34
Proper Use of Crypto
  • Even with good crypto algorithms (and code),
    problems are possible
  • Proper use of crypto is quite subtle
  • Bugs possible in
  • Choice of keys
  • Key management
  • Application of cryptographic ops

35
An Example
  • An application where RSA was used to distribute a
    triple-DES key
  • Seemed to work fine
  • Someone noticed that part of the RSA key exchange
    was always the same
  • Thats odd . . .

36
What Was Happening?
  • Bad parameters were handed to the RSA encryption
    code
  • It failed and returned an error
  • Which wasnt checked for
  • Since it couldnt fail
  • As a result, RSA encryption wasnt applied at all
  • The session key was sent in plaintext . . .

37
Trust Management
  • Dont trust anything you dont need to
  • Dont trust other programs
  • Dont trust other components of your program
  • Dont trust users
  • Dont trust the data users provide you

38
Trust
  • Some trust required to get most jobs done
  • But determine how much you must trust the other
  • Dont trust things you can independently verify
  • Limit the scope of your trust
  • Compartmentalization helps
  • Be careful who you trust

39
Two Important Lessons
  • Many security problems arise because of
    unverified assumptions
  • You think someone is going to do something he
    actually isnt
  • Trusting someone doesnt just mean trusting their
    honesty
  • It means trusting their caution, too

40
Input Verification
  • Never assume users followed any rules in
    providing you input
  • They can provide you with anything
  • Unless you check it, assume theyve given you
    garbage
  • Or worse
  • Just because the last input was good doesnt mean
    the next one will be

41
Treat Input as Hostile
  • If it comes from outside your control and
    reasonable area of trust
  • Probably even if it doesnt
  • There may be code paths you havent considered
  • New code paths might be added
  • Input might come from new sources

42
For Example
  • Shopping cart exploits
  • Web shopping carts sometimes handled as a cookie
    delivered to the user
  • Some of these werent encrypted
  • So users could alter them
  • The shopping cart cookie included the price of
    the goods . . .

43
What Was the Problem?
  • The system trusted the shopping cart cookie when
    it was returned
  • When there was no reason to trust it
  • Either encrypt the cookie
  • Making the input more trusted
  • Can you see any problem with this approach?
  • Or scan the input before taking action on it
  • To find refrigerators being sold for 3 cents

44
Variable Synchronization
  • Often, two or more program variables have related
    values
  • Common example is a pointer to a buffer and a
    length variable
  • Are the two variables always synchronized?
  • If not, bad input can cause trouble

45
An Example
  • From Apache web server
  • cdata is a pointer to a buffer
  • len is an integer containing the length of that
    buffer
  • Programmer wanted to get rid of leading and
    trailing white spaces

46
The Problematic Code
  • while (apr_isspace(cdata))
  • cdata
  • while (len-- gt0
  • apr_isspace(cdatalen))
  • continue
  • cdatalen1 /0
  • len is not decremented when leading white spaces
    are removed
  • So trailing white space removal can overwrite
    end of buffer with nulls
  • May or may not be serious security problem,
    depending on whats stored in overwritten area

47
Variable Synchronization and Heartbleed
  • Heartbleed was essentially a variable
    synchronization bug
  • One variable was an array of characters
  • A second variable was supposedly the length of
    the array
  • Bug depended on not verifying that the provided
    length matched the array size

48
Variable Initialization
  • Some languages let you declare variables without
    specifying their initial values
  • And let you use them without initializing them
  • E.g., C and C
  • Why is that a problem?

49
A Little Example
  • main()
  • foo()
  • bar()
  • foo()
  • int a
  • int b
  • int c
  • a 11
  • b 12
  • c 13
  • bar()

50
Whats the Output?
  • lever.cs.ucla.edu9./a.out
  • aa 11
  • bb 12
  • cc 13
  • Perhaps not exactly what you might want

51
Why Is This Dangerous?
  • Values from one function leak into another
    function
  • If attacker can influence the values in the first
    function,
  • Maybe he can alter the behavior of the second one

52
Variable Cleanup
  • Often, programs reuse a buffer or other memory
    area
  • If old data lives in this area, might not be
    properly cleaned up
  • And then can be treated as something other than
    what it really was
  • E.g., bug in Microsoft TCP/IP stack
  • Old packet data treated as a function pointer
  • Part of the Heartbleed problem, too
  • Buffer not currently in use (but addressable)
    contained old keys and passwords

53
Some Other Problem Areas
  • Handling of data structures
  • Indexing errors in DAEMON Tools, Oracle JRE
  • Arithmetic issues
  • Integer overflow in Microsoft Office graphics
    library
  • Signedness error in XnView
  • Errors in flow control
  • Samba error that causes loop to use wrong
    structure
  • Off-by-one errors
  • Denial of service flaw in Clam AV

54
Yet More Problem Areas
  • Memory management errors
  • Use-after-free error in Internet Explorer
  • Null pointer dereferencing
  • Xarrow SCADA system denial of service
  • Side effects
  • Punctuation errors
  • There are many others

55
Why Should You Care?
  • A lot of this stuff is kind of exotic
  • Might seem unlikely it can be exploited
  • Sounds like it would be hard to exploit without
    source code access
  • Many examples of these bugs probably unexploitable

56
So . . .?
  • Well, thats what everyone thinks before they get
    screwed
  • Nobody will find this bug
  • Its too hard to figure out how to exploit this
    bug
  • It will get taken care of by someone else
  • Code auditors
  • Testers
  • Firewalls

57
Thats What They Always Say
  • Before their system gets screwed
  • Attackers can be very clever
  • Maybe more clever than you
  • Attackers can work very hard
  • Maybe harder than you would
  • Attackers may not have the goals you predict

58
But How to Balance Things?
  • You only have a certain amount of time to design
    and build code
  • Wont secure coding cut into that time?
  • Maybe
  • But less if you develop code coding practices
  • If you avoid problematic things, youll tend to
    code more securely

59
Some Good Coding Practices
  • Validate input
  • Be careful with failure conditions and return
    codes
  • Avoid dangerous constructs
  • Like C input functions that dont specify amount
    of data
  • Keep it simple
About PowerShow.com