CS5412: DANGERS OF CONSOLIDATION Lecture XXIII Ken Birman Are - - PowerPoint PPT Presentation

cs5412 dangers of consolidation
SMART_READER_LITE
LIVE PREVIEW

CS5412: DANGERS OF CONSOLIDATION Lecture XXIII Ken Birman Are - - PowerPoint PPT Presentation

CS5412 Sping 2015 1 CS5412: DANGERS OF CONSOLIDATION Lecture XXIII Ken Birman Are Clouds Inherently Dangerous? 2 Gene Spafford, famous for warning that the emperor has no clothes fears that moving critical information to the cloud


slide-1
SLIDE 1

CS5412: DANGERS OF CONSOLIDATION

Ken Birman

1

Lecture XXIII

CS5412 Sping 2015

slide-2
SLIDE 2

Are Clouds Inherently Dangerous?

2

 Gene Spafford, famous for warning that the emperor

has no clothes fears that moving critical information to the cloud could be a catastrophe

 His concern?

 Concentration of key resources creates

a “treasure chest” that adversaries can focus upon and attack

 Risk of a virus spreading like wildfire

 Core issue: Clouds create monocultures

CS5412 Sping 2015

slide-3
SLIDE 3

3

What Constitutes a “Monoculture”?

monoculture: An environment in which the predominance of systems run apparently identical software components for some or all services.

 Such systems share vulnerabilities, hence they are at risk

to rapid spread of a virus or other malware vector.

Cloned plants Cloned babies

CS5412 Sping 2015

slide-4
SLIDE 4

Forms of monocultures

4

 Large numbers of instances of identical programs or

services (includes applications, not just the O/S)

 Wide use of the same programming language or

scripting tool

 Any standard defines a kind of monoculture

CS5412 Sping 2015

slide-5
SLIDE 5

Current example: OpenSSL

CS5412 Sping 2015

5

 SSL (renamed Transport Layer Security: TLS) is a

standard used to negotiate security keys for secure TCP communication

 Involves use of keys from certificate authorities to

encrypt communication, including passwords

 Used for connections to https websites

 Issue: OpenSSL was an open source effort

 And open development: anonymous contributors  One of those contributors introduced a bug in ~2012

slide-6
SLIDE 6

What was the bug?

CS5412 Sping 2015

6

 OpenSSL has a heart beat protocol

 “If you are still there, send me XX bytes to prove it”  Normally XX was small, like 16, but the client could

actually specify the value. Like 64. Or 128K

 With big values a buffer-read overrun caused

OpenSSL to send back a snapshot of XX bytes of its memory…

 And, in that memory area, one could sometimes find

decrypted data including passwords

YELLOW SUBMARINE

slide-7
SLIDE 7

Central lesson learned?

CS5412 Sping 2015

7

 In the cloud community, majority solutions often

dominate and become de-facto standards

 Everyone then uses them: They are “presumed to be

the best (because widely used), hence widely used...

 And if one of those shared elements is buggy, every

system using them is at risk of compromise

slide-8
SLIDE 8

8

Taking the larger view

Three categories of attack

 Configuration attacks.

 Exploit aspects of the configuration. Vulnerability introduced by system

administrator or user who installs software on the target.

 Includes compiling SNDMAIL with the back door enabled

 Technology attacks.

 Exploit programming or design errors in software running on the target.

Vulnerability introduced by software builder.

 Here hacker breaks in via buggy code

 Trust attacks.

 Exploit assumptions made about the trustworthiness of a client or server.

Vulnerability introduced by system or network architect.

 Hacker abuses legitimate access, like a hospital worker who peeks at

Lindsey Lohan’s medical records

CS5412 Sping 2015

slide-9
SLIDE 9

9

Monoculture: A defense for configuration attacks.

A carefully constructed, fixed, system configuration would be an effective defense against configuration attacks.

 System configuration (today) is hard to get right and thus is best done by

  • experts. Having one or a small number of “approved” configurations

would allow that.

 Configuration attacks are considered “low hanging fruit” and thus likely

are the dominant form of attack today.

 Configurations change not only because a system administrator installs

software but also from a user visiting web sites or interacting with web services that cause software downloads.

 To rule-out such downloads could be a serious limitation on system

  • functionality. Such downloads often bring vulnerabilities, though.

CS5412 Sping 2015

slide-10
SLIDE 10

So monocultures help… for one case

10

 Question becomes: what percent of attacks

leverage configuration mistakes?

 … nobody knows!  But gray-hat hackers assure us that things like standard

passwords are a very common problem

CS5412 Sping 2015

slide-11
SLIDE 11

Viruses love monocultures

11

 Earliest Internet Worm was launched at Cornell!

 A brief episode of notoriety for us  Worm exploited variety of simple mechanisms to break

into computer systems, then used them as a springboard to find other vulnerable systems and infect them

 It had a simple trick to prevent itself from reinfecting an

already infected system: checked for a “lock” file

 But even if present, reinfected with a small probability  Idea was to jump back onto systems that might have been

fixed by system admin team but who left the lock in place

CS5412 Sping 2015

slide-12
SLIDE 12

Monocultures are a known risk

12

 Vast majority of computer viruses and worms

  • perate by exploiting software bugs

 For example, failure to check boundaries on arrays  Very common in code written in C++ or C because

those languages check automated boundary checks

 Nothing stops an input from overrunning the end of the

array

 What lives beyond the end

  • f an array?

CS5412 Sping 2015

slide-13
SLIDE 13

Beyond the end...

13

 Two cases to consider

 Array is on the stack (local to some active method)  Array is in the program’s data or BSS area, or was

allocated from the heap

CS5412 Sping 2015

slide-14
SLIDE 14

Stacks grow “downwards...”

14

Target array registers, return PC locals registers, return PC foo(1, 2, 3) direction of stack growth Other locals

CS5412 Sping 2015

slide-15
SLIDE 15

Stacks grow “downwards...”

15

Target array registers, return PC locals registers, return PC foo(1, 2, 3) Other locals unreasonably long input string

  • verwrites the

locals and registers and the return PC

CS5412 Sping 2015

slide-16
SLIDE 16

Stacks grow “downwards...”

16

registers, return PC locals foo(1, 2, 3)

PC points into data on the stack Compromised content includes virus code

Attacker replaced the return PC with an address in the middle of the injected string

CS5412 Sping 2015

slide-17
SLIDE 17

Why does this attack work?

17

 Attacker needs to be able to predict

 Where the target string lives in memory  How the stack is arranged  What the code that reads the string will do

 Trick is to get the code to jump into the data read

from the attacker

CS5412 Sping 2015

slide-18
SLIDE 18

Bootstrapping concept

18

 The hacker doesn’t have much “room” for instructions  So typically this logic is very limited: often just code

to read a longer string from the network and then execute that longer code

 In effect, the initial attack is a bootstrap program  It loads and launches a more serious program

CS5412 Sping 2015

slide-19
SLIDE 19

Example

19

 String loads code that simply allocates a much

bigger object, reads from the same input source into it, and jumps to the start

 Allows the attacker to send a multi-GB program

that would be way too large to “fit” within the stack

 Trick is to take over but not trigger exceptions  If the attack causes the program to throw an exception,

someone might notice

CS5412 Sping 2015

slide-20
SLIDE 20

What about data/heap?

20

 Here attacker might be in a position to overwrite other

adjacent variables on which the program is dependent

 This does assume some “predictability” in memory layout!  We could perhaps replace a filename it reads or one it

writes with filenames the attacker would prefer that it use instead, or with network URLs

 Of course the program will now be a very sick puppy but it

might last just long enough to do the I/O for the attacker

 That I/O becomes a “point of leverage” that the attacker

exploits like the first domino in a long line...

CS5412 Sping 2015

slide-21
SLIDE 21

Example “attack opportunity”

21

 Any program that works with strings in C or C++ is at risk

even if we length-check inputs

void unsafe(char *a, char *b) { char tmp[32]; strcpy(tmp, a); strcat(tmp, b); return(strcmp(tmp, “foobar”)); }

 Problem here isn’t with the input length per-se but with the

assumption in “unsafe” that the combined string fits in tmp

CS5412 Sping 2015

slide-22
SLIDE 22

Why not just fix the compiler?

22

 People have modified C to check array bounds

 This only helps in limited ways

 C and C++ and Fortran are unsafe by design because

  • f pointer aliasing

 They let us treat an object of one type as if it was of some

  • ther type

 And they impose no real boundary checking at all

 Fixing the language would break many programs that

are in wide use: we would need to fix them too

CS5412 Sping 2015

slide-23
SLIDE 23

Other examples of attacks

CS5412 Sping 2015

23

 Back doors, such as debug or maintenance features  Passwords left with their default values  Automated file or patch download features that can

be tricked into overwriting system files

 Code that has built-in features that can be misused

to trick the program into executing unusual logic

 … in fact the list is really endless!

slide-24
SLIDE 24

Broader problem

24

 We simply don’t have a good way to create things

that are correct, by construction, ground up

 Lacking those, trying to find problems in existing code is

like trying to plug a leak in a dam

 At best we can prove properties of

  • ne thing or another but the

assemblage invariably has holes!

 Or they sneak in over time

CS5412 Sping 2015

slide-25
SLIDE 25

Cloud “permissiveness”

25

 Anyhow, it makes no sense to imagine that we would tell

people how to build cloud applications

 With EC2 we just hand Amazon an executable

 How will it know if the binaries were compiled using the

right compiler?

 What if the version of the compiler matters?  Generally not viewed as a realistic option

 In fact when C and C++ run on .NET many of these

  • verflow issues are caught, but “managed” C or C++

will reject all sorts of classic programs as buggy

CS5412 Sping 2015

slide-26
SLIDE 26

How to attack a cloud

26

 A good firewall can block many kinds of attacks  But something will get through eventually, we can’t

avoid every possible risk and close every possible virus exploit

 And once the virus breaks in, it compromises every

single accessible instance of the same code

CS5412 Sping 2015

slide-27
SLIDE 27

What can we do about these issues?

27

 Today: Focus on these kinds of viral attacks  Thursday: Look at the bigger picture

CS5412 Sping 2015

slide-28
SLIDE 28

First, let’s stop the stack attack...

28

 How can we do that?

 The attacker is taking advantage of knowledge of the

program behavior and flaws

 An “unpredictable” program would have crashed but

not been so easy to compromise

 Can we take a program written in C or C++ and make

it behave less predictably without causing it to crash?

CS5412 Sping 2015

slide-29
SLIDE 29

Stack randomization

29

 Idea is simple:

 Modify the runtime to randomly allocate chunks of memory

(unpredictable size) between objects on stack

 We can also add a chunk of unpredictable size to the

bottom of the stack itself

 Attacker countermeasures?

 May be possible to use a “block” of jump instructions, no-

  • ps to create code that can run in a “position independent

manner”

 Or might guess the offset and try, try again... If the

datacenter doesn’t notice the repeated crashes a few hundred tries might suffice to break in

CS5412 Sping 2015

slide-30
SLIDE 30

.NET has automated diversity

30

 If enabled, a wide variety of randomization

mechanisms will be employed

 Just a bit in the runtime environment you can set  But important to retest programs with stack

randomization enabled

 Some programs depend on bugs, other issues!

CS5412 Sping 2015

slide-31
SLIDE 31

More recent work on diversity

CS5412 Sping 2015

31

 Diverse OS can scramble the number of system calls  Placement of segments in memory can be varied  Code can be dynamically relinked to reorder the

placement of compiled code and data elements

slide-32
SLIDE 32

But this can’t stop all attacks

32

 For example, database “code injection” attacks have a

similar approach and yet don’t rely on array overflow:

 Intended code

 SELECT * FROM users WHERE name = '" + userName + "';"  Limits query to data for this user

 Attacker sends a “faulty” name argument:

 ' or '1'='1  SELECT * FROM users WHERE name = ` ’ or ‘1’=1;  There are many examples of this kind because many

programs exchange messages that involve application- specific programming languages

CS5412 Sping 2015

slide-33
SLIDE 33

Blocking SQL query injection?

33

 This is easy:

 Read the input  Then “clean it up”  Then pass it in to the application

 As long as the developer uses the right tools these

issues don’t arise

 But not every developer cooperates

CS5412 Sping 2015

slide-34
SLIDE 34

Other ideas: Castro and Costa

34

 One project at Microsoft monitors program crashes

 Each time a crash happens they look to see what input

caused the program to fail

 In one project they create virus “signatures”  In another they automatically combine these to create a

pattern, more and more selective, for blocking the input strings that cause the problem

 Use gossip, rapidly and robustly disseminate the fix

together with a “proof” of the bug that triggers it

Manuel Costa, Jon Crowcroft, Miguel Castro, Antony Rowstron, Lidong Zhou, Lintao Zhang, and Paul Barham, Vigilante: End-to-End Containment of Internet Worms, in ACM Symposium on Operating Systems Principles (SOSP), Brighton, UK, Oct 2005

CS5412 Sping 2015

slide-35
SLIDE 35

What kind of “proof”?

35

 Before installing a patch, verify that problem is real

 Proof: Example of an input that will cause a crash or

some other form of compromise

 Verification: Try it inside a virtual machine

 One issue: if the filter is too broad, it might block

legitimate inputs that wouldn’t cause a crash

 We want to block the attack but not legitimate users

CS5412 Sping 2015

slide-36
SLIDE 36

Back door attacks

36

 Some attacks don’t actually compromise a program

 For example, the early Internet worm operated by

exploiting a feature in the original SNDMAIL program

 Code was written by Eric Allman and was unstable for

the first few years

 So he needed ways to see what the problem was  Included a debug feature allowing him to use SNDMAIL as a

kind of remote FTP program to access files on remote system… and SNDMAIL runs with elevated priority…

 Internet worm used this “feature” as one of its attack vectors

CS5412 Sping 2015

slide-37
SLIDE 37

Stack diversity doesn’t stop these…

37

 Backdoor attacks use legitimate features of a

program, or perhaps debug features, to ask program to do things it was programmed to do!

 The program isn’t really malfunctioning or compromised  But it still does things for us that allow breakin  For example, can use SNDMAIL to copy a modified

program on top of /etc/init in Linux

 This modified program might work normally, but always

allow logins from Evil.Hacker with password “Gotcha”

 Better compiler won’t help…

CS5412 Sping 2015

slide-38
SLIDE 38

Neither would better checking tools

38

 A back door is a problem with the specification

 The program shouldn’t have functionality that replaces

arbitrary files with code downloaded from the network,

  • r copied from other places, or even with code

“created” within the program itself

 Yet it is very hard to pin down the rules we need to

check to achieve confidence!

CS5412 Sping 2015

slide-39
SLIDE 39

The ultimate back door

Who is this man? Do you trust his Software?

39

Photo from http://culturadigitalbau.wikispaces.com/ file/view/thompson.c1997.102634882.lg.jpg/212982274/thompson.c1997.102634882.lg.jpg

slide-40
SLIDE 40

The ultimate back door

Ken Thompson Co-Creator of UNIX and C Turing Award: 1983

40

slide-41
SLIDE 41

The ultimate back door

41

 Ken Thompson discussed hidden back doors in a

famous Turing Award lecture

 He considered the Unix login program  Showed how a macro substitution could insert a back

door

 Then pointed out that the macro preprocessor could

have a back door that does the macro substitution

 Then he applied this to the macro preprocessor itself  Ended up with a vanilla-looking Unix system that would

always allow him to log in but where those lines of code could only be discovered by examining the byte code

CS5412 Sping 2015

slide-42
SLIDE 42

The ultimate back door

42

Compiler

011001001111010

slide-43
SLIDE 43

The ultimate back door

43

Compiler

011001001111010

... if(program == “login”) add-login-backdoor(); if(program == “compiler”) add-compiler-backdoor();

slide-44
SLIDE 44

The ultimate back door

Ken Thompson Co-Creator of UNIX and C Turing Award: 1983

44

slide-45
SLIDE 45

The ultimate back door

45

 In general, covert “virtualized” platforms lurk in many

settings

 Virus could virtualize your machine  Attacker with serious resources could sneak a monitoring

component into your printer or the disk drive itself

 Even the network could potentially “host” a covert computing

device and its own stealth network!

 Very hard to really secure modern computing systems.

Cloud actually helps because many operators have resources to build their own specialized hardware

CS5412 Sping 2015

slide-46
SLIDE 46

Recent concern

CS5412 Sping 2015

46

 Even common devices can have backdoors

 Line printers often have a wide variety of network APIs  Network routers and firewalls  The virtualization platforms that operate the cloud  Web browsers…

 We seem to be surrounded by insecure components

slide-47
SLIDE 47

What about virtualization as a tool?

47

 By running the user’s code in a virtual machine the

cloud gives us a way to firewall the user from other users

 We share a machine but I can’t see your work and you

can’t see mine

 Virtualization code needs to block things like putting the

network into promiscuous mode (“monitoring” mode)

 Forces us to trust the VM hypervisor and the hardware

that supports virtualization, but gives “containment”

 Now a virus can only harm the user that “let it in”

CS5412 Sping 2015

slide-48
SLIDE 48

Other forms of diversity

48

 Run different products that offer equivalent

functionality, like two versions of an email server

 Strange finding: researchers have shown that for many

applications, even versions created separately share bugs!

 Consider morphing the system calls: code would need to

be compiled on a per-instance basis but would protect against attacks that require attacker to know local system call numbering

 Vary thread scheduling order dynamically

CS5412 Sping 2015

slide-49
SLIDE 49

Combining multiple methods

49

 This is sometimes called “defense in depth”  The first line of defense is the dynamically

managed firewall: ideally, attack won’t get in

 But if it does, randomization has some chance of

defeating the attack one step later

 Each new obstacle is a hurdle for the attacker

 Will this stop attacks? Only simple ones... but most

attacks use simple methods!

CS5412 Sping 2015

slide-50
SLIDE 50

Defense in depth

50

CS5412 Sping 2015

slide-51
SLIDE 51

… but talented attackers still win

51

CS5412 Sping 2015

slide-52
SLIDE 52

How can anyone trust the cloud?

52

 The cloud seems so risky that it makes no sense at

all to trust it in any way!

 Yet we seem to trust

it in many ways

 This puts the fate of your

company in the hands of third parties!

CS5412 Sping 2015

slide-53
SLIDE 53

For all its virtues, the cloud is risky!

53

 Categories of concerns

 Client platform inadequacies, code

download, browser insecurities

 Internet outages, routing problems,

vulnerability to DDoS

 Cloud platform might be operated by an untrustworthy third

party, could shift resources without warning, could abruptly change pricing or go out of business

 Provider might develop its own scalability problems  Consolidation creates monoculture threats  Cloud security model is very narrow and might not cover

important usage cases

CS5412 Sping 2015

slide-54
SLIDE 54

But the cloud is also good in some ways

54

 With a private server, DDoS attacks often succeed

 In contrast, it can be hard to DDoS a cloud  The DDoS operator spends real money and won’t want

to waste the cash

 Thus because cloud is hard to DDoS, cloud emerges as

a very good response to DDoS worries

CS5412 Sping 2015

slide-55
SLIDE 55

More good news

55

 Diversity can compensate for monoculture worries  Elasticity is a unique capability not seen in other

settings

 Ability to host and compute on massive data sets is

very valuable

 Obviously, only of value if task is suited this style of

massive parallism, but many do fit the model

 ... the list goes on

CS5412 Sping 2015

slide-56
SLIDE 56

So the cloud is tempting

56

 And cheaper, too!  What’s not to love?

 Imagine that you work for a large company that is

healthy and has managed its own story in its own way

 Now the cloud suddenly offers absolutely unique

  • pportunities that we can’t access in any other way

 Should you recommend that your boss drink the potion?

CS5412 Sping 2015

slide-57
SLIDE 57

To cloud, or not cloud…

CS5412 Sping 2015

57

 … maybe that’s the question  … or maybe there is no other choice anymore