Security

Andrew Whitaker

CSE451

Motivation: Internet Worms

“On July 19th, 2001, a self-propagating program, or worm, was released into the Internet. The worm, dubbed Code-Red v2, probed random Internet hosts for a documented vulnerability in the popular Microsoft IIS Web server. As susceptible hosts were infected with the worm, they too attempted to subvert other hosts, dramatically increasing the incidence of the infection. Over fourteen hours, the worm infected almost 360,000 hosts, reaching an incidence of 2,000 hosts per minute before peaking [1]. The direct costs of recovering from this epidemic (including subsequent strains of Code-Red) have been estimated in excess of $2.6 billion [2]”

Source: Internet Quarantine: Requirements for Self-Propagating CodeDavid Moore, Colleen Shannon, Geoffrey M. Voelker, Stefan Savage

Motivation

What’s happening here?

0

20000

40000

60000

80000

100000

120000

140000

160000

1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003# CERT reported security incidents

Why Has Security Gotten So Bad?

The InternetExtensibilityComplexity

An enormous trusted computing base

Grandma

Outline

Protection Defining what is allowed

Security Enforcing a protection policy

In the face of adversaries

Protection systems

Protection: controlling who gets access to what Key concepts:

Objects (the “what”) Principles (the “who”, user or program) Actions: (the “how”, or operations)

A protection system dictates whether an action is allowed for a principle, object e.g., you can read or write your files, but others cannot e.g., your can read /etc/motd but cannot write

Model for Representing Protection

Protection can be modeled with a matrixTwo implementation strategies

Access control lists (rights stored with objects) Capabilities (rights stored with principals)

/etc/passwd /home/gribble /home/guest

root rw rw rw

andrew r rw r

guest r

principals

objects

ACL

capability

More on UNIX-style protection

Not a full access-control list Can only specify owner, group, world permissions

Owner has the power to change access control This is called discretionary access control

There is an all-power “super-user” called root Root acts as an owner for all files

All programs run as a particular user The user must have “execute” privilege

A program can change its user by invoking a setuid command

Setuid

Each process has three user IDs: Real: the user who invoked the process Effective: the user for access control Saved: a previous user ID

Setuid changes the effective user Which is the one that matters for security

Two ways to invoke setuid() system call setuid bit

Changes the effective user to the file owner

Setuid Root

Many programs run as “setuid root” Can be invoked by anybody But, run as root

Example: passwd Passwords stored in a file Users do not have access to this file But, they need the ability to change a password

setuid root is extremely dangerous A compromised setuid program can basically do

anything

Principle of Least Privilege

Each program should be given the minimum privilege to accomplish its task

setuid root is a flagrant violation of this Least privilege for passwd: read and write the

password file Privilege afforded by root: modify any file in the

system; inspect kernel memory; access any I/O device; etc.

Why Can’t We Enforce Least Privilege?The policy is too complex

Which files can a web browser access? Which files can a web server access?

The mechanisms are not sufficient For example, no way to control network

accesses

In the end, usability wins out over security

Research: System Call Policies

Observation: UNIX file access control is not sufficient

Approach: Add a policy language for inspecting system calls In principle, this allows us to completely

quarantine an application

Example System Call Policy Language

Policy: /usr/sbin/named, Emulation: native native-sysctl: permit native-accept: permit native-bind: sockaddr match "inet-*:53" then permit native-break: permit native-chdir: filename eq "/" then permit native-chdir: filename eq "/namedb" then permit native-chroot: filename eq "/var/named" then permit native-close: permit native-connect: sockaddr eq "/dev/log" then permit

Source: Improving Host Security with System Call Policies

Niels Provos

Open question: where do the policies come from?

Other Security Principles

Least PrivilegeKeep it simpleFail-safe defaultsUse the best (or better) languages and

toolsThink about the end-user

Principle of Fail-Safe Defaults

Policy should list what is allowed, not what is denied security configuration should deny all access by default allow only that which has been explicitly permitted oversights show up as “false negatives”

users will quickly complain

Counterexample: Irix OS shipped with “xhost +” by default

Allows the world to open windows on your screen and grab the keystrokes you type

Use Better Languages and Tools

Many software vulnerabilities stem from the use of unsafe languages (mostly C)

int main (int argc, char* argv[]) { char buffer[256]; strcpy(buffer,argv[1]); return 0;}

This is a potential buffer overflowThe attacker can write arbitrarydata onto the stack

Think About the End User

Many security problems stem from poor user interface design

Famous paper: “Why Johnny Can’t Encrypt” found that ordinary users could not setup encrypted email

Ongoing research: graphical passwords, biometrics, etc.