Thema

In brief, the situation.

I You develop software.

I People use your software.

Coda

The situation, in brief.

I You develop software that is certainly broken.

I People are going to exploit it.

Bugs Ex Ante

Kristaps Dzonsons

September 27, 2014

Or: how to protect system resources from the weakest link of thesystem: the developer.

Coda

I write defensive code, use a team of auditors, QA

I use up-to-date, audited libraries with a history of attention tosecurity

I use a language with formal underpinnings and constructproofs of correctness

I run on systems supporting your defensive strategy

I ride your unicorn to work every day.

Adjustment: Expense

I write “defensive” code , use a team of auditors, QA

I use up-to-date , audited libraries with a history of attention tosecurity

I use a language with formal underpinnings and constructproofs of correctness

I run on systems supporting your defensive strategy

Adjustment: time

I write “defensive” code , use a team of auditors, QA

I use up-to-date , audited libraries with a history of attention tosecurity

I use a language with formal underpinnings and constructproofs of correctness C

I run on systems supporting your defensive strategy

Don’t Bring a Dog to a Cat Show

Invariants:

I economics

I buggy software

Variables:

I valuable resources

Minimising the Goal Function

How do we do this?

resources ← software→ users

resources → software← users

Resource constraint:

resources ←software→ users

resources →software← users

Consider how it’s been done to date. In the beginning. . .

A Brief History of Restraint

1961 File Permissions (CTSS)

1964 Segment Permissions (Multics)

1969 Security Kernel (RC-4000)

1971 Access Control Lists (Lampson)

1972 Discretionary Access Controls (Project MAC,Multics)

1973 Bell-LaPadula Model

1975 Capabilities (Hydra)

1975 Access Isolation Mechanism (Project Guardian,Multics)

CAP, System/38, MITRE, SRI, KSOS, Secure UNIX, . . .

CTSS (IBM 7094)

Figure : Credit: Wikimedia, ArnoldReinhold

File Permissions (CTSS)

Each U.F.D. contains information about the locationand contents of the various files which the user hascreated. The U.F.D. is associated with a problemnumber and a programmer number. Also associatedwith certain problem numbers are “common files” – filedirectories which contain files of common interest and aredirectly accessible to all users on the problem number.

Certain of the common files associated with thesystem programmers’ problem number (M1416) containinformation of general utility and are accessible to allusers.

–CTSS Programmer’s Guide (AA.2 12/69): October 1965, MIT.

Multics (GE-645)

Figure : Credit: Tom Van Vleck, Multicians

Segment Positions (Multics)

Storage is logically organized in separately nameddata storage segments Associated with each segment isan access control list, an open-ended list of names ofusers who are permitted to reference the segment.. . . Whenever the process attempts to access a segmentor other object cataloged by the storage system, theprincipal identifier of the process is compared with thoseappearing in the access control list of the object; if nomatch is found access is not granted.

–Jerry Saltzer, Protection and the Control of Information Sharingin Multics: 1974, MIT.

Access Isolation (Multics)

Figure : Credit: Tom Van Vleck, Multicians

–B2 Certification “Orange Book”, 1983.

Hydra (PDP-11)

Figure : Credit: Unknown Author

Capabilities (Hydra)

First, we must assume that any user-level programcontains bugs and may even be malevolent. We thereforecannot allow any single user or application to“commandeer” the system to the detriment of others. Byimplication, we must prevent programs which definepolicies direct access to hardware or data which could be(mis)used to destroy another program. That is–suchprograms must execute in a protected environment.

–R. Levin et al., Policy/Mechanism Separation in Hydra: CMU,1975.

Unfortunately...

Figure : Paul Karger and Roger Schell, 1984. Credit: Tom Van Vleck

. . . They tried to break Multics security on the MITGE-645 that we all used as our timesharing utility anddevelopment build & exposure site.

And break it they did. . . (1972–1974)

What Went Wrong? (Multics)

The large number of programs, as well as the veryhigh internal intricacy level, frustrates line-by-lineauditing for errors, misimplementation, or intentionallyplanted trapdoors.

Economics. . . a function could be implemented morecheaply [than] in the most protected region.

Rush to get on the air.

Lack of understanding.

–Jerry Saltzer, Protection and the Control of Information Sharingin Multics: 1974, MIT.

What Went Wrong? (Hydra)

Subsystem construction still suffers from being adhoc, there being inadequate software support formanaging the programs, data structures, anddocumentation which comprise the subsystem.

–W. Wulf and S. Harbison, Reflections in a pool of processors–Anexperience report on C.mmp/Hydra: CMU, 1978.

What about UNIX?

In many ways, UNIX is a very conservative system.Only a handful of its ideas are genuinely now. In fact, agood case can be made that it is in essence a modernimplementation of M.I.T.’s CTSS system.

The UNIX system kernel and much of the softwarewere written in a rather open environment, so thecontinuous, careful effort required to maintain a fullysecure system has not always been expended; as a result,there are several security problems.

–D. M. Ritchie, The UNIX Time-Sharing System: A Retrospective:1976, AT&T Bell Labs.

Bugs Ex Ante

Kristaps Dzonsons

September 27, 2014

Or,

UNIX: “As Times Goes By”

1971 chmod(2), setuid(2) (V1 UNIX)

1979 chroot(2) (V7 UNIX)

1982 setrlimit(2) (4.1cBSD)

2000 jail(8) (FreeBSD 4.0)

2002 systrace(4) (OpenBSD?)

2003 POSIX.1e (FreeBSD 5.0, Mac OS X 10.4)

2007 kauth(9) (NetBSD 4.0)

2007 sandbox init(3) (Mac OS X 10.4)

2012 Capsicum (FreeBSD 9.0)

Concepts

Labelling: limit access only to labelled environment.

I POSIX.1e

I chmod(2), setuid(2)

Containers: limit the environment.

I chroot(2)

I setrlimit(2)

I jail(8)

Capabilities: limit access to the environment.

I systrace(4)

I Capsicum

There’s lots of overlap.

chmod(2), setuid(2)

I part of the original UNIX V1

I forms the basis of privsep/privdrop (along with fork(2) etal.)

On privilege separation...

Doable in simple programs

Requires complicated and very detailed programming

–Theo de Raadt: OpenCON, 2005

chroot(2)

chroot()

{

if (suser())

chdirec(&u.u_rdir);

}

1981 BSD commit by Bill Joy. . .

if (dp == u.u_rdir && u.u_dent.d_name[0] == ’.’ &&

u.u_dent.d_name[1] == ’.’ && u.u_dent.d_name[2] == 0)

goto cloop;

setrlimit(2)

Establish limits on resources, originally:

I CPU time

I data segment size

I stack segment size

I core file size

I physical memory size

Now also (OpenBSD-current):

I largest file size

I maximum open files

I maximum size of locked memory

I maximum simultaneous processes for user

These can be set and unset at will, so an attacker with arbitrarypower can simply change the resource limits himself.

jail(8)

System interface by Poul-Henning Kamp in FreeBSD 4.0, furtherextended in FreeBSD 5.1 (jail attach(2)) and FreeBSD 8.0(jail set(2)).Extends the chroot(2) concept into a constrained view of users,network, files, etc.Must be root. Cannot be recursive.

systrace(4)

Developed by Neils Provos (Improving Host Security with SystemCall Policies, USENIX Security 2003), now only in OpenBSD.Found vulnerable by Robert Watson, Exploiting ConcurrencyVulnerabilities in System Call Wrappers, WOOT 2007.Uses the /dev/systrace device (open(2), ioctl(2), read(2))to set a resource limitation policy (white-list, black-list) on processand process children.Must be root; can only be applied to children or other processes.(See privsep.)

POSIX.1e: ACL

Organised under TrustedBSD, April 2000, merged into FreeBSD5.0 and Darwin 10.6.

acl(3) File-system (VFS) access control. FreeBSD, Darwin.(Slightly differing.)

setfacl(3) POSIX-compliant (not yet?) version.

POSIX.1e: MAC

Derived from TrustedBSD, April 2000, merged into FreeBSD 5.0and Darwin 10.6 (and indirectly into NetBSD’s kauth(9 andsecmodel(9)).

mac(3), mac(4) FreeBSD interface. Full policy framework forMLS, Biba, etc. Manuals inspired by the Voynichmanuscript.

sandbox init(3) Darwin 10.6 one-function entry into MACsandbox. Manuals inspired by haiku.

kauth(9)

In-kernel authorisation framework (like FreeBSD’s mac(9), etc.).Inspired by Mac 10.4. Not exposed to user-land, but would enablea user-land equivalent to mac(4), sandbox init(3), etc.

sandbox init(3)

Mandatory access control interface introduced in Darwin 10.6.Based on FreeBSD and POSIX.1e.Almost no documentation. See OpenSSH’s sandbox-darwin.c

for some significant “gotchas”.Limitation profiles available: kSBXProfileNoInternet,kSBXProfileNoNetwork, kSBXProfileNoWrite,kSBXProfileNoWriteExceptTemporary,kSBXProfilePureComputation.

Capsicum

Recent capabilities (see rights(4)) innovation on FreeBSD,inherited from TrustedBSD.Sits between systrace(4) and sandbox init(3) in terms ofcomplexity: requires consideration of each resource, but (in theory)doesn’t need a fork(2) for processing children (except for processlimitations, pdfork(2)).Used in bspatch(1), bsdiff(1), tcpdump(1), fetch(1),bzip2(1), syslogd(8), . . .Requires a significant addition of functions: prfork(2), . . .

Case Study: OpenSSH

Designing software resistent to developer bugs is hard. Too hard.Consider one of the canonical sandboxed applications, OpenSSH(5.8).

Introduce sandboxing of the pre-auth privsep childusing an optional sshd config(5)

“UsePrivilegeSeparation=sandbox” mode that enablesmandatory restrictions on the syscalls the privsep childcan perform. This intention is to prevent a compromisedprivsep child from being used to attack other hosts (byopening sockets and proxying) or probing local kernelattack surface.

One Step Ahead, Two Steps Behind

% wc -l *sandbox*

122 sandbox-capsicum.c

98 sandbox-darwin.c

72 sandbox-null.c

97 sandbox-rlimit.c

240 sandbox-seccomp-filter.c

200 sandbox-systrace.c

24 ssh-sandbox.h

853 total

This is ridiculously complicated!

Methodology

Sandbox method for systrace(4):

1. parent fork(2) a child, wait for child to SIGSTOP

2. child emits a SIGSTOP

3. parent prepare systrace(4) policy for child

4. parent sends SIGCONT to child

5. child continues in sandbox

Sandbox method on other platforms:

1. parent fork(2) a child

2. child prepares sandbox environment

3. child continues in sandbox

Case Study: kcgi

% wc -l sandbox*

72 sandbox-darwin.c

249 sandbox-systrace.c

366 sandbox.c

687 total

Methodology

Inherit structure of OpenSSH.Work around CGI environment: not a root process, already in achroot(2, unknown number of file descriptors already open.

Questionable Morals

The moral is obvious. You can’t trust code that youdid not totally create yourself. (Especially code fromcompanies that employ people like me.) No amount ofsource-level verification or scrutiny will protect you fromusing untrusted code.

–Ken Thompson, Reflections on Trusting Trust, 1984.

Thank You!

Figure : Credit: unknown author