CSE484/CSE584 SECURE DESIGN PRINCIPLES, OS, AND RUNTIME SECURITY - - PowerPoint PPT Presentation

CSE484/CSE584

SECURE DESIGN PRINCIPLES, OS, AND RUNTIME SECURITY

• Dr. Benjamin Livshits

Some of f the Common Principles

Minimize attack surface area Principle of Least Privilege Defense-in- Depth Secure the Weakest Link Fail-Safe Stance Secure by Default

Minimize Attack Surface

3

Minimize the Attack Surface

 Expose only limited, well documented interfaces

from your application

 Turn everything else off

ILOVEYOU Worm

5

 Use only the services that your application requires  The Slammer and CodeRed viruses would not have happened if

certain features were not on by default

 ILoveYou (and other viruses) would not have happened if

scripting was disabled

 "LOVE-LETTER-FOR-YOU.txt.vbs“ email attachment  The latter file extension (in this case, 'VBS' - a type of

interpreted file) was most often hidden by default on Windows computers of the time, leading unwitting users to think it was a normal text file. Opening the attachment activated the Visual Basic script

Least Privilege

6

Principle of Least Privilege

 Just enough

authority to get the job done

 Real world

example: Valet Keys: valets can only start car and drive to parking lot

 Highly elevated

privileges unnecessary

Ex: valet key

shouldn’t open glove compartment

Web server Ex: can

read, not modify, html file

Attacker gets more

power, system more vulnerable

Example: qmail

 Compartmentalize  Nine separate modules  If one module

compromised, others not

 Move separate functions

into mutually untrusting programs

 Always validate input

from other modules

Th The e qm qmai ail se securit ity guar uarantee

 In March 1997, I offered $500

to the first person to publish a verifiable security hole in the latest version of qmail

 For example, a way for a user

to exploit qmail to take over another account.

 My offer still stands.  Nobody has found any

security holes in qmail.

http://cr.yp.to/qmail/guarantee.html

Structure of qmail

qmail-smtpd qmail-local qmail-remote qmail-lspawn qmail-rspawn qmail-send qmail-inject qmail-queue Incoming SMTP mail Other incoming mail

Contrast with sendmail

10 10

Web Server Example

 If the server is run under root account, clients could access all

files on system!

 serveFile() method creates FileReader object for

arbitrary pathname provided by user

 GET ../../../../etc/shadow HTTP/1.0  Traverses up to root, /etc/shadow on UNIX contains list

• f usernames & encrypted passwords!

 Attacker can use this to launch a dictionary attack  Need to canonicalize and validate pathname

 Obey Least Privilege: Don’t run server under root!

Apache

12 12

Or www-data

13 13

Why multiple processes?

Defense-in in-Depth

14 14

Defense-in in-Depth in Roman Times

 In the 3rd and early 4th centuries, the

Imperial Roman army's defense strategy mutated from "forward defense" (or "preclusive defense") during the Principate era (30 BC-AD 284) to "defense-in-depth" in the 4th century

 "Forward-" or "preclusive" defense aimed to

neutralize external threats be before they breached the Roman borders

 The barbarian regions neighboring the borders

were envisaged as the theatres of operations.

 In contrast, "defense-in-depth" would not

attempt to prevent incursions into Roman territory, but aimed to neu eutr tralize them on Rom

• man soil
• il

15 15

Prevent, Detect, Contain, and Recover

 Should have mechanisms for preventin

ing attacks

detectin

ing breaches

contain

inin ing attacks in progress, and

recoverin

ing from them

 Detection particularly important for network

security since it may not be clear when an attack is occurring

Most of our focus thus far

Failed Login Attempts with aureport

17 17

http://www.golinuxhub.com/2014/05/how-to-track-all-successful-and-failed.html

Auditing Account Activity

18 18

Ongoing Attack: Shellshock

19 19

http://www.dunbarcybersecurity.com/blog/what-does-a-shellshock-attack-look-like-to-your-website

Ongoing Attack

20 20 http://blog.malwaremustdie.org/2014/10/mmd-0029-2015-warning-of-mayhem.html

Monitor Attack Attempts

21 21

Large-Scale Monitoring

22 22

Don’t Forget Containment

 Preventive techniques not perfect; treat

malicious traffic as a fact, not exceptional condition

 Should have containment procedures planned

• ut in advance to mitigate damage of an

attack that escapes preventive measures

Design, practice, and test containment plan Ex: If a thief removes a painting at a museum, the

gallery is locked down to trap him.

Containment

24 24

Removal

25 25

Defense-In-Depth: Password Security Example

 Sys admins can require users to choose strong

passwords to prevent guessing attacks

 To detect, can monitor server logs for large # of failed

logins coming from an IP address and mark it as suspicious

 Contain by denying logins from suspicious IPs or

require additional checks (e.g. cookies)

 To recover, monitor accounts that may have been

hacked, deny suspicious transactions

Weakest Link

27 27

Securing the Weakest Link

 One-third of users choose a password that

could be found in the dictionary

 Attacker can employ a dictionary attack and

will eventually succeed in guessing someone’s password

 By using Least Privilege, can at least mitigate

damage from compromised accounts

Password Cracking Tool

29 29

Not all passwords can be recovered in a reasonable time using these approaches. If you have difficulties, use the guaranteed password reset function from commercial software.

Social Engineering Attacks

 Employees could fall

for phishing attacks

 (e.g. someone calls

them pretending to be the “sys admin” and asks for their password)

 Especially a problem for

larger companies

Back-Doors

 Malicious developers

(aka insider threats)

Can put back doors into

their programs

Should employ code

review

Or static analysis

 Untrustworthy libraries  Is open source better here?

31 31

Fail-Safe

32 32

Fail-Safe Stance

 Expect & Plan for System Failure  Common world example: Elevators  Designed with expectation of power failure  In power outage, can grab onto cables or guide rails  Ex: If firewall fails, let no traffic in  Deny access by default  Don’t accept all (including malicious), because that gives

attacker additional incentive to cause failure

Fail Safely, Not Like This

34 34

isAdmin = true; try { codeWhichMayFail(); isAdmin = isUserInRole( “Administrator” ); ... } catch (Exception ex) { log.write(ex.toString()); }

Security Through Obscurity

 Security Through Obscurity

(STO) is the belief that a system of any sort can be secure so long as nobody

• utside of its implementation

group is allowed to find out anything about its internal mechanisms.

 Hiding account passwords in

binary files or scripts with the presumption that "nobody will ever find it" is a prime case of STO.

 Security through obscurity

would be bury ryin ing your money under a tree.

 The on

• nly th

thin ing that makes it safe is no one knows it's there.

 Real security is putting it behind

a loc lock or in in a a sa safe.

 You can put

t th the sa safe on

• n th

the str treet corner because what makes it secure is that no one can get inside it but you.

35 35

Key Design Principles

 Avoid elevated privileges  Use layered defense (prevention, detection,

containment, and recovery)

 Secure weakest links  Have fail-safes, i.e. crash gracefully  Don’t enable unnecessary features  Keep design simple, usable  Security features can’t compensate for bugs

Break

37 37

Unix Security

38 38

Access Control in Unix

 Process has user id

 Inherit from creating process  Process can change id

 Restricted set of options

 Special “root” id

 Bypass access control

restrictions

 File has access control list (ACL)

 Grants permission to user ids  Owner, group, other

File 1 File 2 … User 1 read write

• User 2

write write

• User 3
• read

… User m Read write write

Unix File ACLs

 Each file has an owner and a gr

group

 Permissions set by owner

 Read, write, execute  Owner, group, other  Represented by vector of

four octal values

 Only owner, root can change permissions  This privilege cannot be delegated or shared

rwx rwx rwx

• wnr

grp

• thr

setid

Unix File Permissions and Owner

41 41

setuid programming

 Be Careful with Setuid 0 !

 Root can do anything; don’ t get tricked  Principle of least privilege – change EUID when root

privileges no longer needed

 "sudo" (super user does operations) is used widely  This is a key limitation of the model main limitation

 Too tempting to use root privileges  No way to assume some root privileges without all root

privileges

(based on slides from John Mitchell)

Java Security Basics

43 43

Java Implementation Principles

 Compiler and Virtual Machine  Compiler produces bytecode  Virtual machine loads classes on demand, verifies bytecode

properties, interprets bytecode

 Why this design?  Bytecode interpreter/compilers used before  Pascal “pcode”  Smalltalk compilers use bytecode  Minimize machine-dependent part of implementation  Do optimization on bytecode when possible  Keep bytecode interpreter simple  For Java, this gives portability  Transmit bytecode across network

A.class A.java

Java Compiler

B.class Lo Loader Verifie ier Lin Linker Bytecode In Interpreter Java Virtual Machine Compile le so source code

Java Virtual Machine Architecture

JVM Memory Areas

 Java program has one or more threads  Each thread has its own stack  All threads share same heap

method area heap Java stacks PC registers native method stacks

Class Loaders

 Runtime system loads

classes as needed

 When class is

referenced, loader searches for file of compiled bytecode instructions

 Default loading

mechanism can be replaced

 Define alternate

ClassLoader object

 Extend the abstract

ClassLoader class and implementation

 ClassLoader does not

implement abstract method loadClass, but has methods that can be used to implement loadClass

JVM Linker and Verifier

 Li

Linker

 Adds compiled class or

interface to runtime system

 Creates static fields and

initializes them

 Resolves names

 Checks symbolic

names and replaces with direct references

 Verifier

 Check bytecode of a

class or interface before loaded

 Throw VerifyError

exception if error occurs

Verifier Design

 Bytecode may not come from standard compiler

 Evil hacker may write dangerous bytecode

 Verifier checks correctness of bytecode

 Every instruction must have a valid operation code  Every branch instruction must branch to the start of some

• ther instruction, not middle of instruction

 Every method must have a structurally correct signature  Every instruction obeys the Java type discipline  This is fairly complicated and tricky

Towards Memory Safety

 Perform run-time checks

such as array bounds

 All casts are checked to

make sure type safe

 All array references are

checked to make sure the array index is within the array bounds

 References are tested to

make sure they are not null before they are dereferenced.

 No pointer arithmetic  Automatic garbage

collection

If program accesses memory, that memory is allocated to the program and declared with correct type

Java and Native Interactions

 Possible to compile

bytecode class file to native code

 JITs are used for

performance

 Java programs can call

native methods, typically functions written in C

 C# and .NET take C/C++

interop very seriously

51 51 class PlatformInvokeTest { [DllImport("msvcrt.dll")] public static extern int puts(string c); [DllImport("msvcrt.dll")] internal static extern int _flushall(); public static void Main() { puts("Test"); _flushall(); } }

Java Security Mechanisms

 Sandboxing

 Run program in restricted

environment

 Analogy: child’s sandbox with

• nly safe toys

 This term refers to features of

loader, verifier, interpreter that restrict program

 Code signing

 Use cryptography to establish

• rigin of class file

 This info can be used by security

manager

 Class loader

 Separate namespaces for separate class loaders  Associates protection domain with each class

 Verifier and JVM run-time tests

 NO unchecked casts or other type errors  NO buffer/array overflows  Preserves private, protected visibility levels

 Security Manager

 Called by library functions to decide if request is

allowed

 Uses protection domain associated with code, user

policy

 Coming up in a few slides: stack inspection

Security Manager

 Java library functions call Security Manager  Security manager object answers at run time

 Decide if calling code is allowed to do operation  Examine protection domain of calling class

 Signer: organization that signed code before loading  Location: URL where the Java classes came from

 Uses the system policy to decide access permission

Sample Security Manager Methods

checkExec Checks if the system commands can be executed. checkRead Checks if a file can be read from. checkWrite Checks if a file can be written to. checkListen Checks if a certain network port can be listened to for connections. checkConnect Checks if a network connection can be created. checkCreate ClassLoader Check to prevent the installation of additional ClassLoaders.

Stack Inspection

 Permission depends on

 Permission of calling method  Permission of all methods

above it on stack

 Up to method that is trusted

and asserts this trust

java.io.FileInputStream method f method g method h

Java: Things Didn’t Quite Go According to Plan

56 56