Secure Operating Systems

John Mitchell

CS 155 May 3, 2005

Last Lecture This lecture

Access Control Concepts• Matrix, ACL, Capabilities• Multi-level security (MLS)

OS Mechanisms• Multics

– Ring structure

• Amoeba– Distributed, capabilities

• Unix– File system, Setuid

• Windows– File system, Tokens, EFS

• SE Linux– Role-based, Domain type enforcement

Secure OS• Stronger mechanisms• Some limitations

Assurance• Orange Book, TCSEC• Common Criteria• Windows 2000

certification

Cryptographic File Systems

Embedded OS• Some issues in Symbian

security

Software Patches

What makes a “secure” OS?

Extra security features (compared to last lecture)• Stronger authentication mechanisms

– Example: require token + password

• More security policy options– Example: only let users read file f for purpose p

• Logging and other features More secure implementation

• Apply secure design and coding principles• Assurance and certification

– Code audit or formal verification

• Maintenance procedures– Apply patches, etc.

Sample Features of “Trusted OS”

Mandatory access control• MAC not under user control, precedence over DAC

Object reuse protection• Write over old data when file space is allocated

Complete mediation• Prevent any access that circumvents monitor

Audit• Log security-related events and check logs

Intrusion detection• Anomaly detection

– Learn normal activity, Report abnormal actions

• Attack detection– Recognize patterns associated with known attacks

DAC and MAC

Discretionary Access Control• Restrict a subject's access to an object

– Generally: limit a user's access to a file– Owner of file controls other users' accesses

Mandatory Access Control• Needed when security policy dictates that:

– protection decisions must not be left to object owner

– system enforces a security policy over the wishes or intentions of the object owner

Jack, Kack, Lack, Mack, Nack, Ouack, Pack and Quack

DAC vs MAC

DAC• Object owner has full

power• Complete trust in

users• Decisions are based

only on user id and object ownerships

• Impossible to control information flow

MAC• Object owner CAN

have some power• Only trust in

administrators• Objects and tasks

themselves can have ids

• Makes information flow control possible

Information flow

High

Low

High

Low

inputs

inputs

outputs

outputs

Process

Controlling information flow

MAC policy• Information from one object may only flow to an

object at the same or at a higher security level

Conservative approach• Information flow takes place when an object

changes its state or when a new object is created

Implementation as access policy• If a process reads a file at one security level, it

cannot create or write a file at a lower level• This is not a DAC policy, not an ACL policy

SELinux

Security-enhanced Linux system (NSA)• Enforce separation of information based on

confidentiality and integrity requirements • Mandatory access control incorporated into the major

subsystems of the kernel– Limit tampering and bypassing of application security

mechanisms – Confine damage caused by malicious applications

Why Linux? Open source• Already subject to public review• NSA can review source, modify and extend

– Assurance methods later in lecture …

http://www.nsa.gov/selinux/

Problem: crypto module

Signing

key

Input Output

Signing algorithm

Actual hope: low security output does not reveal high security input

Information flow analysis

First guess• Mark expressions as high or low

– Some resemblance to Perl tainting

• Check assignment for high value in low location

But consider if (xhigh > 0) ylow = 0;

else ylow = 1;

State of the art• Much research on type systems and program

analysis to determine software information flow• Still not ready for prime time

Covert Channels

Butler Lampson• Difficulty achieving confinement (paper on

web)

• Communicate by using CPU, locking/unlocking file, sending/delaying msg, …

Gustavus Simmons• Cryptographic techniques make it impossible

to detect presence of a covert channel

Example

The Two-Server Trojan Horse:• Device P can chose from two Key Servers• P is expected to choose randomly, to balance load• But reveals key one bit at a time

Observations• Information flow easily detected by noninterference

analysis of the algorithm• More subtle if choice based on random seed known to

external attacker

P S1

S2

key

[McLean]

Also: DNS lookup, SSL nonce, …

Sample Features of Trusted OS

Mandatory access control• MAC not under user control, precedence over DAC

Object reuse protection• Write over old data when file space is allocated

Complete mediation• Prevent any access that circumvents monitor

Audit• Log security-related events and check logs

Intrusion detection• Anomaly detection

– Learn normal activity, Report abnormal actions

• Attack detection– Recognize patterns associated with known attacks

Interesting risk: data lifetime

Recent work• Shredding Your Garbage: Reducing Data Lifetime

Through Secure Deallocation by Jim Chow, Ben Pfaff, Tal Garfinkel, Mendel

Rosenblum

Example• User types password into web form• Web server reads password• Where does this go in memory?

– Many copies, on stack and heap– Optimizing compilers may remove “dead”

assignment/memcopy– Presents interesting security risk

Sample Features of Trusted OS

Mandatory access control• MAC not under user control, precedence over DAC

Object reuse protection• Write over old data when file space is allocated

Complete mediation• Prevent any access that circumvents monitor

Audit• Log security-related events and check logs

Intrusion detection (cover in another lecture)

• Anomaly detection– Learn normal activity, Report abnormal actions

• Attack detection– Recognize patterns associated with known attacks

Kernelized Design

Trusted Computing Base• Hardware and software for

enforcing security rules

Reference monitor• Part of TCB • All system calls go

through reference monitor for security checking

• Most OS not designed this way

User space

Kernel space

User proces

s

OS kernel

TCB

Reference monitor

Audit

Log security-related events Protect audit log

• Write to write-once non-volatile medium

Audit logs can become huge• Manage size by following policy

– Storage becomes more feasible– Analysis more feasible since entries more meaningful

• Example policies– Audit only first, last access by process to a file– Do not record routine, expected events

• E.g., starting one process always loads …

Assurance methods

Testing• Can demonstrate existence of flaw, not

absence

Formal verification• Time-consuming, painstaking process

“Validation”• Requirements checking• Design and code reviews

– Sit around table, drink lots of coffee, …

• Module and system testing

Rainbow Series

DoD Trusted Computer Sys Evaluation Criteria (Orange Book) Audit in Trusted Systems (Tan Book) Configuration Management in Trusted Systems (Amber Book)Trusted Distribution in Trusted Systems (Dark Lavender Book) Security Modeling in Trusted Systems (Aqua Book) Formal Verification Systems (Purple Book) Covert Channel Analysis of Trusted Systems (Light Pink Book)… many more

http://www.radium.ncsc.mil/tpep/library/rainbow/index.html

Orange Book Criteria (TCSEC)

Level D• No security requirements

Level C For environments with cooperating users• C1 – protected mode OS, authenticated login,

DAC, security testing and documentation (Unix)

• C2 – DAC to level of individual user, object initialization, auditing (Windows NT 4.0)

Level B, A• All users and objects must be assigned a security

label (classified, unclassified, etc.)• System must enforce Bell-LaPadula model

Levels B, A (continued)

Level B• B1 – classification and Bell-LaPadula• B2 – system designed in top-down modular way,

must be possible to verify, covert channels must be analyzed

• B3 – ACLs with users and groups, formal TCB must be presented, adequate security auditing, secure crash recovery

Level A1• Formal proof of protection system, formal proof

that model is correct, demonstration that impl conforms to model, formal covert channel analysis

Common Criteria

Three parts• CC Documents

– Protection profiles: requirements for category of systems• Functional requirements• Assurance requirements

• CC Evaluation Methodology• National Schemes (local ways of doing evaluation)

Replaces TCSEC, endorsed by 14 countries• CC adopted 1998 • Last TCSEC evaluation completed 2000

http://www.commoncriteria.org/

Protection Profiles

Requirements for categories of systems• Subject to review and certified

Example: Controlled Access PP (CAPP_V1.d)• Security functional requirements

– Authentication, User Data Protection, Prevent Audit Loss

• Security assurance requirements– Security testing, Admin guidance, Life-cycle support, …

• Assumes non-hostile and well-managed users• Does not consider malicious system developers

Evaluation Assurance Levels 1 – 4

EAL 1: Functionally Tested• Review of functional and interface specifications• Some independent testing

EAL 2: Structurally Tested• Analysis of security functions, incl high-level design• Independent testing, review of developer testing

EAL 3: Methodically Tested and Checked• Development environment controls; config mgmt

EAL 4: Methodically Designed, Tested, Reviewed• Informal spec of security policy, Independent testing

Evaluation Assurance Levels 5 – 7

EAL 5: Semiformally Designed and Tested• Formal model, modular design• Vulnerability search, covert channel analysis

EAL 6: Semiformally Verified Design and Tested• Structured development process

EAL 7: Formally Verified Design and Tested• Formal presentation of functional specification• Product or system design must be simple• Independent confirmation of developer tests

Example: Windows 2000, EAL 4+

Evaluation performed by SAIC Used “Controlled Access Protection Profile” Level EAL 4 + Flaw Remediation

• “EAL 4 … represents the highest level at which products not built specifically to meet the requirements of EAL 5-7 ought to be evaluated.”

(EAL 5-7 requires more stringent design and development procedures …)

• Flaw Remediation

Evaluation based on specific configurations• Produced configuration guide that may be useful

Is Windows is “Secure”?

Good things• Design goals include security goals• Independent review, configuration guidelines

But …• “Secure” is a complex concept

– What properties protected against what attacks?

• Typical installation includes more than just OS– Many problems arise from applications, device drivers– Windows driver certification program

• Security depends on installation as well as system

Secure attention sequence (SAS)

CTRL+ALT+DEL• “… can be read only by Windows, ensuring that the

information in the ensuing logon dialog box can be read only by Windows. This can prevent rogue programs from gaining access to the computer.”

How does this work?• Winlogon service responds to SAS • DLL called GINA (for Graphical Identification 'n'

Authentication) implemented in msgina.dll gathers and marshals information provided by the user and sends it to the Local Security Authority (LSA) for verification

• The SAS provides a level of protection against Trojan horse login prompts, but not against driver level attacks.

Encrypted File Systems (EFS, CFS)

Store files in encrypted form• Key management: user’s key decrypts file• Useful protection if someone steals disk

Windows – EFS• User marks a file for encryption• Unique file encryption key is created• Key is encrypted, can be stored on smart card

Unix – CFS [Matt Blaze]• Transparent use• Local NFS server running on "loopback" interface • Key protected by passphrase

Q: Why use crypto file system?

General security questions• What properties are provided?• Against what form of attack?

Crypto file system• What properties?

– Secrecy, integrity, authenticity, … ?

• Against what kinds of attack?– Someone steals your laptop?– Someone steals your removable disk?– Someone has network access to shared file system?

Depends on how file system configured and used

Encrypted file systems Several possible designs

• Block based systems• Disk based systems• Network loopback based systems• Stackable file systems • Application based encryption

Some references• A cryptographic file system for unix

– Matt Blaze• Cryptographic File Systems Performance

– Charles Wright, Jay Dave and Erez Zadok• Cryptoloop HowTo

– Dennis Kaledin et. al• Ncryptfs: A secure and convenient cryptographic file system

– Wright et. al

Block Based

Encrypt one disk block at a time• Not dependent on underlying file system• Can write to raw device or preallocated file

Sample block-based implementation

Cryptoloop• Uses Linux loopback device driver, CryptoAPI

– Linux kernel CryptoAPI exports an interface to encryption functions and hash functions

• Can write to a raw device or to a preallocated file – Preallocated file effectively cuts buffer cache in half                    

Other block-based file systems CGD (Cyptographic disk driver)

• For NetBSD• raw device only

BestCrypt• Commercial product for Linux and windows• preallocated file for storage

vncrypt• For FreeBSD: uses the vn device driver• preallocated file for storage

vnd• For OpenBSD: uses the Vnode disk driver (vnd)• preallocated file for storage

                   

Disk Based

Encrypt data at the file system level

Disk Based

EFS (Encryption File System)• Extension to NTFS based on NT kernel. • Uses windows access control and authentication

libraries though located in the kernel, its tightly coupled with user space dlls to do encryption and user authentication.

• Encryption keys are stored on the disk, encrypted with user password

StegFS • A file system that employs encryption and

steganography• Inspection of system will not reveal content or extent

of hidden data• uses modified ext2 kernel driver• Very slow and hence impractical

Network Based

CFS• User level crypto NFS server

– Performance hampered by many context switches and data copies between user and kernel space

• Data appears in user space in cleartext

Network Based

TCFS• modified kernel mode nfs client• works with normal nfs server• keys are stored on the filesystem

Stackable Systems

Ncryptfs• Can operate on top of any file system.

Application based encryption

Applications like pgp, SafeHouse allow users to encrypt/decrypt files

File may be in cleartext on the disk while the user is editing and saving it

Encrypted file system

Complete file system encryption is feasible in real time• Crypto operations are not a big bottleneck• Performance study: with single processor,

I/O is limiting factor• Caching plays a big role in performance of

encrypted systems

Embedded operating systems

Symbian History• Psion released EPOC32 in 1996

– based on 1989 EPOC OS– EPOC32 was designed with OO in C++

• Symbian Ltd. formed in 1998– Ericsson, Nokia, Motorola and Psion– EPOC renamed to Symbian OS– Currently ~30 phones with Symbian,15 licensees

• Current ownership Nokia 47.5% Panasonic 10.5% Ericsson 15.6% Siemens 8.4% SonyEricsson 13.1% Samsung 4.5%

See: Symbian phone security, Job de Haas, BlackHat, Amsterdam 2005

Symbian UI

Two main version Series60 UIQ

Architecture

Multitasking, preemptive kernel MMU protection of kernel and process spaces Strong Client–Server architecture Plug-in patterns Filesystem in ROM, Flash, RAM and on SD-card

Symbian Development

Emulator on x86 runs most of native code base• Compiled to x86 (so not running ARM cpu)• Emulator is one windows process

Limited support for on-target debugging• It does not work on all devices• Uses a gdb stub• Metrowerks provides MetroTRK• Future: v9 will move to ARM Real View (RVCT)

and the EABI standard

Mobile phone risks Toll fraud:

• Auto dialers.• High cost SMS/MMS.• Phone Proxy

Loss or theft:• Data loss.• Data compromise.• Loss of Identity (caller ID)

Availability:• SPAM.• Destruction of the device

(flash)• Destruction of data.

Risks induced by usage:• Mobile banking.• Confidential e-mail,

documents.• Device present at confidential

meetings: snooping

Attack vectors• Executables• Bluetooth• GPRS / GSM• OTA• IrDa• Browser• SMS / MMS• SD card• WAP• E-mail• Too many entry points to list

all

Symbian security features Crypto:

• Algorithms• Certificate framework• Protocols: HTTPS, WTLS, …

Symbian signed:• Public key signatures on

applications• Root CA’s in ROM

Separation• Kernel vs. user space;• process space• Secured ‘wallet’ storage

Access controls• SIM PIN, device security code• Bluetooth pairing

Artificial Limitations / patches• Prevent loading device

drivers in the kernel (Nokia).• Disallow overriding of ROM

based plug-ins

Limitations• No concept of roles or users.• No access controls in the file

system.• No user confirmation

needed for access by applications.

• User view on device is limited: partial filesystem, selected processes.

• Majority of interesting applications is unsigned.

Are attacks prevented?• Fraud: user should not

accept unsigned apps• Loss/theft: In practice,

little protection• Availability: any

application can render phone unusable (skulls trojan).

Symbian attacks

What goes wrong?• All known attacks need user confirmation.

Often more than once.• People loose a lot devices

Skulls Trojan:• Theme that replaces all icons and cannot be de-

installed

Caribe:• Installs itself as a ‘Recognizer’ to get activated at

boot time and starts broadcasting itself over Bluetooth

Example vulnerability

February 23, 2005 notice on Nokia site:

Proposed workaround

User confirmation

This is what appears on the screen when an untrusted application is loaded:

Installing patches

Many attacks occur after patch released• Applies to OS and applications

Case study: patches for Open SSL• Recall: Secure Socket Layer (SSL) protocol

provides authentication and confidentiality between two communicating applications

• OpenSSL is a open source implementation– Remote buffer overflow in OpenSSL server

• Case study by Eric Rescorla, RTFM, Inc.

Server Side SSLv2 Vulnerability

During a handshake with the server, the client can send a overly long CLIENT-MASTER-KEY for SSLv2.

Resulting in heap overflow.

Client Server

challenge, cipher_specs

connection-id, server_certificate, cipher_specs{master_key} server_public_key

verification and finalization

“No Session Identifier” Handshake for Remote Connections

Server Side SSLv2 Vulnerability

char MSG-CLIENT-MASTER-KEYchar CIPHER-KIND[3]char CLEAR-KEY-LENGTH-MSBchar CLEAR-KEY-LENGTH-LSBchar ENCRYPTED-KEY-LENGTH-MSBchar ENCRYPTED-KEY-LENGTH-LSBchar KEY-ARG-LENGTH-MSBchar KEY-ARG-LENGTH-LSBchar CLEAR-KEY-DATA[MSB<<8|LSB]char ENCRYPTED-KEY-DATA[MSB<<8|LSB]char KEY-ARG-DATA[MSB<<8|LSB]

• All block ciphers used in OpenSSL use 8 byte key • OpenSSL allocates fixed 8-byte buffer for KEY-ARG-DATA• Specifying a larger key length with KEY-ARG-DATA overflow the heap• OpenSSL uses a lot of function pointers that heap overflow can exploit

Structure of CLIENT-MASTER-KEY message

Ethical Probing for Fixes

Patched servers close connection if key length too big Unpatched servers accept KEY-ARG-LENGTH > 8

• Rescorla set KEY-ARG-LENGTH = 9• Overwrites next field in the heap, master_key_length (MKL)• MKL not used anywhere else, so no real damage

struct CLIENT MASTER KEY MKL

struct CLIENT MASTER KEY

Timeline

30th July 2002• Initial announcement of vulnerability• OpenSSL 0.9.6e available for download (bug fixed)• Patches for other versions released• Major OS vendors (Debian, Trustix, Engarde, Gentoo) announce• Posting of vulnerability to SlashDot

31st July 2002• FreeBSD announces

2nd August 2002• Apple announces. NetBSD announces

9th August 2002• OpenSSL 0.9.6g released

13th September 2002• Slapper worm released (More than 60% still vulnerable)

July August September

30 31 2 9 13

Patches and upgrades over 30 days

23% of the servers are fixed within first week of announcement More than 60% of servers still vulnerable when the Slapper worm

which exploited the bug was released 6 weeks later

% vulnerable

days

Vulnerable Servers over a 30 Days Period

Graphs ends at

60% vulnerable

Second wave after worm exploit

Some administrators only patch/upgrade when exploit shows up

% vulnerable

days

Vulnerable Servers after Slapper was releasedGraphs starts at

60% vulnerable

Summary 1/3 upgrade when advisory released 1/3 upgrade when exploit released 1/3 do not bother

OS Security lectures

Access Control Concepts• Matrix, ACL, Capabilities• Multi-level security (MLS)

OS Mechanisms• Multics

– Ring structure

• Amoeba– Distributed, capabilities

• Unix– File system, Setuid

• Windows– File system, Tokens, EFS

• SE Linux– Role-based, Domain type enforcement

Secure OS• Stronger mechanisms• Some limitations

Assurance• Orange Book, TCSEC• Common Criteria• Windows 2000

certification

Cryptographic File Systems

Embedded OS• Some issues in Symbian

security

Software Patches