[PPT] - Simple Overflow 1 #include <stdio.h> int main(void){ PowerPoint Presentation

SLIDE 1

Simple Overflow

1

#include <stdio.h> int main(void){ unsigned int num = 0xffffffff; printf("num is %d bits long\n", sizeof(num) * 8); printf("num = 0x%x\n", num); printf("num + 1 = 0x%x\n", num + 1); return 0; } nova:signed {4} ./ex2 num is 32 bits long num = 0xffffffff num + 1 = 0x0

SLIDE 2

In Integer Overflows

 Exploits range of value integers can store  Ex: signed two-byte in

int stores between -232 and 232-1

 Cause unexpected wrap-around scenarios  Attacker passes int greater than max (positive) ->

value wraps around to the min (negative!)

 Can cause unexpected program behavior, possible buffer

verflow exploits

 Completely crazy from a more abstract point of view

SLIDE 3

Signed/unsigned Confusion

http://phrack.org/issues/60/10.html

SLIDE 4

There’s more: Memory Safety Issues

4

buffer overflow use after free read/dereference of uninitialized

memory

double-free null pointer dereference

SLIDE 5

Memory ry Safety

5

 Computer languages such as C and C++ that

support arbitrary pointer arithmetic, casting, and deallocation are typically not memory safe.

 There is a variety of approaches to fi

find er errors in programs in C/C++.

 C/C++ is too close to hardware and provides little

ut of the box in terms of safe(r) programming

SLIDE 6

Alternatives? Better Languages

6

 Most high-level programming languages avoid the

problem by disallowing pointer arithmetic and casting entirely, and by using garbage coll llection for memory management.

 Generally, elevates the level of vulnerabilities  Buffer overruns are not an issue, but other things

like XSS are

SLIDE 7

Attack Defense Zigzag

7

Stack-based buffer overruns

StackGuard

Heap-based buffer overruns

ALSR and NX

Heap sprays and ROC

Specific defenses

SLIDE 8

Shellshock

 Shellshock is the media-

friendly name for a security bug found in Bash, a command shell

 The bug is what's known as a

Rem emote Cod

de Ex

Executio ion vulnerability



That may al allo low a remote attacker to send you text that you hand over to a Bash script as harmless looking data, only to find that it gets processed as if it were code, or program commands.



This sort of trickery is often known as command injection, because it involves sneaking in operating system commands, hoping that they get run by mistake.

8

SLIDE 9

9

Shellshock

SLIDE 10

Remote Execution?

10 10

 Wait, remote command execution on bash?  How can someone re

remotely execu cute commands on a lo local shell ll?

 The issue starts with mod_cgi and how web servers

interact with CGI programs (written in Perl, PHP, Shell

r any other language).

 The web server passes (environment) user variables to

them so they can do their work.

 In simple terms, this vulnerability allows an attacker to pass

a command as a variable that gets executed by bash.

http://blog.sucuri.net/2014/09/bash-vulnerability-shellshock-thousands-of-cpanel-sites-are-high-risk.html

SLIDE 11

Patch is the Message

11 11

 It means that if you are using mod_cgi on your

webserver and you have a CGI written in shell script, you are in deep trouble. Drop everything now and patch your servers.

 If you have CGI’s written on any other language, but

you are using “system()”, “(backticks)” or executing any commands from the CGI, you are in deep trouble. Drop every rything now and patch your r servers.

 If you don’t know what you have, Drop everything now

and patch your r servers.

SLIDE 12

Patch and Test

#sudo apt-get install bash

or -

#sudo yum update bash

bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' hello

12 12

[root@yourserver ~]# env x='() { :;}; echo vulnerable' bash -c 'echo hello'

SLIDE 13

Try rying This on bicycle.c .cs

13 13

 But someone needs to come in and acti

tively ly patch the machine once the bug is found

 This is too late – the vulnerability may alr

lready have been exp xplo loit ited

SLIDE 14

CSE484/CSE584 ROBUST APPLICATION CODE THROUGH ANALYSIS

Dr. Benjamin Livshits

SLIDE 15

Cost of f Fixing a Defect

15 15

SLIDE 16

How Do We Find Bugs?

16 16

SLIDE 17

Runtime Monitoring

 Instrument code for testing  Heap memory: Purify  Valgrind: http://valgrind.org  Perl tainting (information

flow)

 Java race condition

checking

 Pros:  Easy to reproduce the

bug

 Relatively easy to

implement

 Con

ns:

 Slows down the

program significantly

 10x-40x slowdowns  Test only: cannot be

used in production

 Not all paths executed

17 17

SLIDE 18

Black-box Testing

 Fuzzing and pen

enetration tes estin ting

 Black-box web application security

analysis

 Typically, tries to provide cleverly

crafted unexpected inputs

 Also knows as inputs of death  Example:

 Peach fuzzer

http://peachfuzzer.com/

 antifuzzer, Dfuz, SPIKE, GPF, etc.  Pros:

 Easy to reproduce the

bug

 Don’t need to

understand the code

 Can be done by

someone else

 Con

ns:

 Have no visibility into

program logic

 Has low coverage  Possibly lots of

missing vulnerabilities

18 18

SLIDE 19

Static Analysis

 Static code analysis toos

 Coverity  Tools from Microsoft

like Prefix and Prefast

 FindBugs (for Java)  Fortify (for security)

19 19

 Pros:  Near-perfect code

coverage, exercise all paths

 Can be run,

incrementally as part of development process

 Cons:  Can be imprecise  Can scale poorly  Can produce results

that are tough to interpret

SLIDE 20

From Coverity

20 20

SLIDE 21

From CPyChecker

21 21

SLIDE 22

From FxCop

22 22

SLIDE 23

From PVS-Studio

23 23

SLIDE 24

From Visual Lint

24 24

SLIDE 25

XSS Detect

25 25

SLIDE 26

Visual Studio

26 26

SLIDE 27

Outline

 General discussion of static analysis tools

 Goals and limitations  Approach based on abstract states

 More about one specific approach

 Property checkers from Engler et al., Coverity  Sample security-related results

Slides from: S. Bugrahe, A. Chou, I&T Dillig, D. Engler, J. Franklin, A. Aiken, Mitchll …

SLIDE 28

Entry 1 2 3 4

Software

Exit

Behaviors

Entry 1 2 4 Exit 1 2 4 1 2 4 1 3 4 1 2 4 1 3 4 1 2 3 1 2 4 1 3 4 1 2 4 1 2 3 1 3 4 1 2 3 1 2 3 1 3 4 1 2 4 1 2 4 1 3 4

. . .

1 2 4 1 3 4

Manual testing

nly examines

small subset of behaviors

Static Analysis Coverage Advantage

SLIDE 29

Program Analyzers

Code

Report Type Line 1 mem leak 324 2 buffer oflow 4,353,245 3 sql injection 23,212 4 stack oflow 86,923 5 dang ptr 8,491 … … … 10,502 info leak 10,921

Program Analyzer Spec potentially reports many warnings may emit false alarms analyze large code bases

false alarm false alarm

SLIDE 30

Static Analysis Goals

 Bug fi

finding: identify code that the programmer wishes to modify or improve

 Correctness: Verify the absence of certain

classes of errors

SLIDE 31

Soundness and Completeness

Property Definition

Soundness If the program contains an error, the analysis will report a warning.

“Sound for reporting correctness”

Completeness If the analysis reports a warning, the program will contain an error.

“Complete for reporting correctness”

SLIDE 32

Complete Incomplete Sound Unsound

Reports all errors Reports no false alarms Reports all errors May report false alarms

Undecidable Decidable Decidable

May not report all errors May report false alarms

Decidable

May not report all errors Reports no false alarms

Decidable?

SLIDE 33

Software

. . .

Behaviors

Sound Over-approximation of Behaviors False Alarm Reported Error

approximation is too coarse… yields too many false alarms

Modules

Over- and Underapproximations

SLIDE 34

entry X  0 Is Y = 0 ? X  X + 1 X  X - 1 Is Y = 0 ? Is X < 0 ? exit crash yes no yes no yes no

Does This Program Ever Crash?

SLIDE 35

entry X  0 Is Y = 0 ? X  X + 1 X  X - 1 Is Y = 0 ? Is X < 0 ? exit crash yes no yes no yes no

infeasible path!

verly imprecise

… program will never crash

Does This Program Ever Crash?

SLIDE 36

entry X  0 Is Y = 0 ? X  X + 1 X  X - 1 Is Y = 0 ? Is X < 0 ? exit crash yes no yes no yes no X = 0 X = 0 X = 1 X = 1 X = 1 X = 1 X = 1 X = 2 X = 2 X = 2 X = 2 X = 2 X = 3 X = 3 X = 3 X = 3 non-termination! … therefore, need to approximate

Try Analyzing Without Approximation

SLIDE 37

X  X + 1 f din dout

dout = f(din)

X = 0 X = 1 dataflow elements transfer function dataflow equation

Dataflow Analysis Framework

SLIDE 38

X  X + 1 f1 din1

dout1 = f1(din1)

Is Y = 0 ? f2 dout2 dout1 din2

dout1 = din2 dout2 = f2(din2)

X = 0 X = 1 X = 1 X = 1

Applying the Dataflow Approach

SLIDE 39

dout1 = f1(din1) djoin = dout1 ⊔ dout2 dout2 = f2(din2)

f1 f2 f3 dout1 din

1

din

2

dout

2

djoin din3 dout3

djoin = din3 dout3 = f3(din3)

least upper bound operator Example: union of possible values

What is the space of dataflow elements, ? What is the least upper bound operator, ⊔?

Meet/Join Operator ⊔

SLIDE 40

entry X  0 Is Y = 0 ? X  X + 1 X  X - 1 Is Y = 0 ? Is X < 0 ? exit crash yes no yes no yes no X = 0 X = 0 X = pos X = T X = neg X = 0 X = T X = T X = T

terminates... … but reports false alarm … therefore, need more precision

lost precision X = T

Try Analyzing with “Signs” Approximation…

SLIDE 41

X = T X = pos X = 0 X = neg X =  X  neg X  pos true Y = 0 Y  0 false X = T X = pos X = 0 X = neg X =  signs lattice Boolean formula lattice refined signs lattice

Lattices

SLIDE 42

entry X  0 Is Y = 0 ? X  X + 1 X  X - 1 Is Y = 0 ? Is X < 0 ? exit crash yes no yes no yes no X = 0 true X = 0 Y=0 X = pos Y=0 X = neg Y0 X = pos Y=0 X = neg Y0 X = pos Y=0 X = pos Y=0 X = neg Y0 X = 0 Y0

terminates... … no false alarm … soundly proved never crashes

no precision loss refinement

Try Analyzing with “Path-sensitive signs”