Building secure systems
This presentation is the property of its rightful owner.
Sponsored Links
1 / 74

Building Secure Systems PowerPoint PPT Presentation


  • 113 Views
  • Uploaded on
  • Presentation posted in: General

GENERALLY ACCESSIBLE. Building Secure Systems. Plattform Security – Isolation, Privileges and Server Security. Walter Kriha, Computer Science and Media Faculty August 2, 2006. Overview: Plattform-level Methods for Secure Systems. Different privilege levels

Download Presentation

Building Secure Systems

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Building secure systems

GENERALLY ACCESSIBLE

Building Secure Systems

Plattform Security – Isolation, Privileges and Server Security

Walter Kriha, Computer Science and Media Faculty

August 2, 2006


Overview plattform level methods for secure systems

Overview: Plattform-level Methods for Secure Systems

  • Different privilege levels

  • Isolation of components (virtual memory, micro kernels)

  • Interception with Wrappers

  • Virtual Machines

  • Inversion of Control, Dependency Injection Architectures

  • Capabilities

  • Name Spaces, Services and Components

  • Trusted Computing Bases

  • Sandboxes

  • Jails

  • Funnels

  • Code Verification


Current problems and approaches

Current Problems and Approaches


Building secure systems

Distributed, after-the-fact security for home computers

Security Specialists

security tools

SMS based code control

Directory

update

PC with tracking SW

Analysis

report

MS-Data Center

Admins

PC with tracking SW

home

office


The sandbox access domain

All resources the user has a right to access (ACL)

The Sandbox (Access Domain)

Program started by user

object

object

User A

Sandbox

object Z

CODE

service Y

service

Sandbox Policy:

Program X is allowed to use

service Y and Object Z

User rights:

May do everything!

Reference Monitor

service

A Sandbox restricts a users rights! It needs a description containing the rules for a specific domain (constrained program). A reference monitor reads those rules. Every access by the code is intercepted by the monitor and the rules are applied. If the rules do not match the intended access it is blocked. No matter how powerful the users rights are, the code cannot escape the sandbox as long as the reference monitor is not bypassed.


Building secure systems

Main(string FileName = „foo“)

Process

Mapping string to resource

Open(fileName)

All Files

File named „foo“

User has rights for all those files. Process needs the same rights as it does not know which one the user would like to process


Building secure systems

Main(FileDescriptor) for open file „foo“

Process

No mapping from string to resource!

Read(FileDescriptor)

„foo“ file

User has rights for all those files. Process needs NO rights to open user files. Gets open stream as a capability


Building secure systems

Server Rechte

Benötigte Rechte für Aufgabe

User F Rechte

Ambient Authority

Sandbox


System architecture and security consequences

System Architecture and Security Consequences


Immutable laws of security

Immutable Laws of Security?

  • 1. If the data hasn’t crossed a trust boundary, you don’t really care about it.

  • 2. If the threat requires that the attacker is ALREADY running code on the client at your privilege level, you don’t really care about it.

  • 3. If your code runs with any elevated privileges (even if your code runs in a restricted svchost instance) you need to be concerned.

  • 4. If your code invalidates assumptions made by other entities, you need to be concerned.

  • 5. If your code listens on the network, you need to be concerned.

  • 6. If your code retrieves information from the internet, you need to be concerned.

  • 7. If your code deals with data that came from a file, you need to be concerned (these last two are the inverses of rule #1).

  • 8. If your code is marked as safe for scripting or safe for initialization, you need to be REALLY concerned.


Os architecture and security mechanisms

OS-Architecture and Security Mechanisms


Cpu protection levels

CPU Protection Levels

State of protected mode bit:

1 = protected/kernel mode

0 = application/user mode

0/1

Sensing operations (I/O)

Control operations (halt, memory mgmt.)

Regular compute operations (add, mul)

Most CPUs offer a simple protetion scheme. Dangerous operations (sensing, control) are only allowed when the CPU has been put in kernel mode (protection bit is set). Applications can NOT change the state of the CPU arbitrarily. They MUST use certain controlled gates (software interrupts) to change the mode. From then on, operating system code runs!


Switching to kernel mode

Switching to Kernel Mode

Application

Application stack used

User Mode, CPU doing harmless things

C Language Library

System Call Library

Software Interrupt – Kernel Trap

(CPU instruction)

Kernel Mode, CPU doing critical things

Operating System

Kernel stack used

Hardware (CPU, I/O)

Only in kernel mode will the CPU allow critical instructions. The application will be terminated if it tries to execute critical instructions without changing through kernel traps into protected mode.


Security properties of privilege modes

Security Properties of Privilege Modes

Rights/Authority

Trick code into extending callers privileges

code

code

code

Attack code on same level

code

code

code

code

code

code

Turn off privileged mode

code


Security properties of privilege modes1

Security Properties of Privilege Modes

  • Rights organized as privilege levels typically lead to ambient authority for code pieces because no sectors are possible within the levels. Most code pieces would need a different segmentation of rights.

  • On the same level each piece of code is a threat to all others (same privileges, no sep.)

  • Every mode change needs to be undone later. Software needs to make sure that on the way back the privilege mode gets reversed to the old value. There cannot be a bypass of this piece of code

  • The mode change needs to be authorized

  • The privileged code needs to interpret arguments carefully to avoid extending the callers privileges in an unwanted way (confused deputy)


Address isolation

Address Isolation

CPU

000000000000000000000000000000

256 MB

Random

Access

Memory

(physical)

Application 2: all addresses in same range as every other app.

Memory

Management

Unit (MMU)

Same! Virtual Address

32 bit address register

Application 1: all addresses in same range as app 1.

page table

Process A

page table

Process B

Physical Address Process A

Physical Address Process B


Monolithic kernels

Monolithic Kernels

runtime loadable

Application 1

device

driver

firewall

module

audio

driver

User Mode

compiletime

Kernel Functions

Data

memory managment

Kernel Mode

file management

process management

device drivers

Fast access to functions and shared kernel data


Microkernels

Microkernels

Application 1

process management server

Device Driver

file management server

security management server

memory managment server

Device Driver

User Mode

Interprocess comm.

basic memory management

Kernel Mode

Context switching

Interrupt handling

basic security

Clock driver

Fast access to functions and shared kernel data

Interprocess Communication or system calls


Building secure systems

From: G.Heiser, Virtualization of Embedded Systems


Armored monolithic kernels

Armored Monolithic Kernels

User Mode

Wrapper gurantees transactional updates

compiletime

Data

memory managment

Kernel Mode

audio

driver

file management

Kernel functions

device drivers

process management

Data

Intercepted and controlled calls to and from kernel

Temporary Copy of kernel data

Modified page table to restrict driver to certain kernel addresses


Vm armored micro kernels

VM Armored Micro Kernels

Data

memory managment

device drivers

file management

Kernel functions

User Mode

process management

Inter Kernel Communication

Inter Kernel Communication

VM

VM

Microkernel (e.g. L4)

Kernel Mode


The secure extension problem

The Secure Extension Problem


Building secure systems

Device Driver

Kernel

Driver Controller

driverControl()

Extern ProcTab tab;

Extern int criticalFunc()

Init()

Read()

Write()

IOCtrl()

HandleInt()

Gobal:

ProcTab

criticalFunc()

Resolved at runtime or linktime


Building secure systems

Device Driver

Kernel

Dependency injection

Driver Controller

driverControl()

private ProcTab tab;

private int criticalFunc()

Init(ProctTab, crit.Function)

Read()

Write()

IOCtrl()

HandleInt()

Gobal:

ProcTab

criticalFunc()

criticalFunc()

criticalFunc()


Building secure systems

  • Der Driver kann ausschließlich über die Argumente und deren Methoden auf Kernel-Daten oder Funktionen zugreifen. Es gibt keine andere Möglichkeit, auch nicht durch die Navigation von globalen Verzeichnissen oder durch sog. Composite Objects (Design Pattern), die über ihre Tree-Navigation Zugriffe auf viele andere Objekte gestatten.

  • Der Treiber macht eigene Abhängigkeiten und Bedürfnisse im Interface der init-Methode sichtbar: Dort steht, was der Treiber vom Kernel benötigt, um zu funktionieren.

  • Der Kernel ist in der Lage, Proxy Objekte oder speziell für den Treiber zugeschnittene Closures (das sind initialisierte higher-order Functions oder deren objektorientiertes Äquivalent bzw. deren Simulationen durch Command Patterns) herzustellen und an den Treiber zu übergeben. Damit kontrolliert der Kernel komplett die Ausführungsumgebung des Drivers.


Building secure systems

Plug-in

Framework

Inject dependency (DI principle)

Declare dependency

Init(Node)

Read()

Write()

Initiate Call (IOC principle)

Use reference (object capability principle)

Node

Node

Node

Node does not allow traversal and so plug-in cannot access parent node. The plug-in declares ist dependencies in ist interface


Modes and privileges

Modes and Privileges


Building secure systems

Same runtime environment for all applications

Cycle stealing applications create a problem for near-realtime multimedia applications

A common, navigable filesystem with ambient authority

Application

Server

(privileged)

Global Administrator

Dangerous accounts, single audit and log features

Tons of unsafe but privileged scripts and utilities (setUid)

Common Filesystem

Lots of unverified system libraries with memory leaks etc.

Privileged Utilities

>300 complex system calls

Huge Libraries

Incomplete quota administration

System call Interface

Countless dynamically loadable modules

Attacks on random number generation

Module

Legacy OS

Module

Driver

Driver

Driver

Unsafe kernel languages (memory)

>100.000 drivers for windows

Hardware (CPU etc.)

Covered channels (cache, bios, CPU)

Huge TCB, 2 modes only

Network scans (IP seq.)


Building secure systems

Driver.c:

If (uid = 0) {

// do something harmless

}

// run as root now!


Building secure systems

Interprocess communication

Para-virtualisierung

Trusted Computing Base


Rules for virtualization guest operating systems

Rules for Virtualization/Guest Operating Systems

VMs (die gewöhnlich unter privilegierten Accounts arbeiten) sollen wie andere kompromittierbare Dienste behandelt werden, d.h. am Besten unter Verwendung von Isolationstechniken wie chroot, systrace, ACLs, sowie POLA Regeln.

Die Virtuellen Maschinen wie die Gast-Betriebssysteme sollten so schmal wie möglich konfiguriert sein. Ungenutzte Hardware-Treiber oder Services sind auch beim Gast zu entfernen.

Die Integrität der Gastsysteme ist genauso zu sichern wie die der Trägermaschinen durch regelmässige Updates, Privilegieneinschränkungen der Gast-Applikationen etc.

Systeme die mehrere unterschiedliche Privilegienzonen ermöglichen sind vorteilhaft (XEN). Sicherheitslevel von Plattformen (z.B. Berkeley Security Levels) sind zu nutzen. [Orm]

Ressources: Ormandy


Software based isolation singularity

Software-based Isolation: Singularity


Singularity features

Singularity Features

Die Kapselung beruht auf leichtgewichtigen Prozessen

Kernel, Applikationen, Treiber und System-Server sind allesamt Prozesse

Ein Prozess ist ein geschlossener Object-Space, der keine Referenzen in andere Prozesse hinein besitzt

IPC ist durch ein Kanalkonzept realisiert, das sich durch streng typisierte Kommunikation, definiert durch State-Machines, auszeichnet

Objekte können an andere Prozesse übertragen werden, wechseln dann jedoch den Besitzer, so dass keine cross-process synchronization Probleme oder zentrale Garbage Collection nötig sind.

Ein kleiner Teil Code ist unverified und trusted, der große Rest von Microkernel und Applikationen etc. ist verifiably trusted, d.h. er wurde vom sicheren Compiler erzeugt.

Es sind keine dynamischen Erweiterungen von Prozessen (Code laden) erlaubt. Jede Erweiterung muss ein eigener Prozess sein.

Jede Softwarekomponente ist durch Meta-Daten umfangreich beschrieben und wird ohne eigenen Installer installiert.


Building secure systems

Small, light-weight processes

No cross object space sharing

p2

Safe interprocess communication (separation)

One virtual address space

p1

Individual runtimes (GC, libraries)

Trusted, not verifiably safe


Building secure systems

Eheap

Typed channels with state-machines for IPC

Application

Code

Extension

Code

CLR Lib.

CLR Lib.

Runtime

Runtime

No common, shared variables between both object spaces


Building secure systems

public contract NamespaceContract : ServiceContract {

in message Bind(char[] in path, ServiceContract.Exp:Start exp);

out message AckBind();

out message NakBind(ServiceContract.Exp:Start exp);

in message Notify(char[] in pathSpec, NotifyContract.Imp:Start imp);

out message AckNotify();

out message NakNotify(NotifyContract.Imp:Start imp);

in message Find(char[] in pathSpec);

out message AckFind(FindResponse[] in results);

out message NakFind();

out message Success();

override state Start: one {

Success! -> Ready; }

state Ready: one {

Bind? -> ( AckBind! or NakBind! ) -> Ready;

Find? -> ( AckFind! or NakFind! ) -> Ready;

Notify? -> ( AckNotify! or NakNotify! ) -> Ready; }}

Als eingebettete Klassen eines Kanals werden jeweils ein exporter bzw. importer definiert, die die entsprechenden Messages des Kontrakts zugeordnet bekommen. Will ein Prozess einen Kanal eröffnen, dann erzeugt er Instanzen von exporter und importer und schickt die exporter-Instanz über einen existierenden Kanal an den Empfänger. Danach können beide miteinander kommunizieren.


Building secure systems

<manifest>

<application identity="S3Trio64" />

<assemblies>

<assembly filename="S3Trio64.exe" />

<assembly filename="Namespace.Contracts.dll" version="1.0.0.2299„ />

<assembly filename="Io.Contracts.dll" version="1.0.0.2299" /> …..

<assembly filename="ILHelpers.dll" version="1.0.0.2299" />

<assembly filename="Singularity.V1.ill" version="1.0.0.2299" />

</assemblies>

<driverCategory>

<device signature="/pci/03/00/5333/8811" />

<ioMemoryRange baseAddress="0xb8000" rangeLength="0x8000„ fixed="True" />

<ioPortRange baseAddress="0x4ae8" rangeLength="0x2" fixed="True" /> ….

<extension startStateId="3" contractName="Microsoft.Singularity-.Extending.ExtensionContract" endpointEnd="Exp„ assembly="Namespace.Contracts" />

<serviceProvider startStateId="3" contractName="Microsoft-.Singularity.Io.VideoDeviceContract" endpointEnd="Exp„ assembly="Io.Contracts" /> </driverCategory> </manifest>

A manifest file describes the physical structure of an application and its installation needs. Control is never passed to the application for installation purposes (no setup.exe)


Building secure systems

/bin/sshd @ /users/ted (+ {/grp/pathrole})* + /bin/ms/office/word

Compound Principal


Building secure systems

Tracked data structures with ownership transfer

When creating a TRef<T>, the constructor requires an object of type T as an argument. The caller must have ownership of the object at the construction site. After the construction, ownership has been passed to the newly allocated TRef. The Acquire method is used to obtain the contents of a TRef. If the TRef is full, it returns its contents and transfers ownership to the caller of Acquire. Afterwards, the TRef is said to be empty. Release transfers ownership of a T object from the caller to the TRef. Afterwards, the TRef is full. TRefs are thread-safe and Acquire operations block until the TRef is full.


Privilege reduction vs capabilities

Privilege Reduction vs. Capabilities


Building secure systems

Privilege Restriction and Separation with Rights Reduction vs Capabilities

additive Model (default is deny)

Subtractive Model

Root

Directory

capability

Change runtime environment to jail

Change owner

User

change identity to user

User

Hand directory capability to unprivileged user process. Without capabilities user process cannot access resources

Jails strips off other rights


Building secure systems

Classic *-properties

Vista Integrity Levels

L2

L2

Write-down

Write-down

Write-up

Write-up

Read-down

Read-down

Read-up

Read-up

L1

L1

L1

Vista: Lower level unprotected against upper level attacks. Upper level open to luring attacks and data exposure. Ambient authority through queries and messages


Systrace in openbsd

Systrace in OpenBSD

wrapper (etc/systrace)

Application

System Call:

open(/tmp/foo, mode);

/etc/systrace (policies)

Operating System

Systrace

Interceptor

policy_for_application:

native_read filename match

„/tmp/*“ then permit

Systrace intercepts system calls and evaluates them according to specified policies. By wrapping user shells, applications and daemons most code can be easily sandboxed.


Building secure systems

Privilege Restriction and Separation with Identities or ACLs

MakeMeAdmin

DecreaseMyRights

User

User

Rights

Admin Rights

Extend

Roles etc.

start

Reduce

Roles etc.

start

Privilege Starter

Prog.

Program

Rights

Admin Rights vector

start

Program

Admin Rights vector


Polaris

Polaris

The file is edited in the context of a powerless dummy user and then copied back. The application gets the file via the so called „powerbox“ – a GUI component that distributes capabilities upon user request.


Building secure systems

„Sandbox“

Polaris

Secure

Desktop

Running mail program

Running Excel program

open attachment

Execute with macros enabled

Copy over

Excel file

With macros

Excel file

With macros

Copy back

Dummy user session with restricted rights

Real user session

Windows Operating System


Secure server design and reduction of exposure by software architecture

Secure Server Design and Reduction of Exposure by Software-Architecture


Building secure systems

  • Sicherheitsprinzipien beim Server-Design

  • Isolierung der Server-Prozesse durch chroot oder jails

  • Server-Prozesse laufen als unprivilegierte User

  • Der Zugriff auf die Datenbank sollte minimale Rechte besitzen

  • Verschiedene Funktionalitäten sollten auf verschiedene Prozesse verteilt werden

  • Nach: Maxwell Krohn, Building Secure High-Performance Web Services with OKWS


Building secure systems

ServerSocket ss = new ServerSocket(port);

for(;;) {

Socket client = ss.accept();

BufferedReader in = new BufferedReader(

new InputStreamReader(client.getInputStream()));

PrintWriter out = new PrintWriter(client.getOutputStream());

while((line = in.readLine()) != null) {

// read command (or filename) from network

// execute command

}

out.print(result);

}

David Flanagan, Java Examples in a Nutshell (shortened)


Building secure systems

VO

Realm

Task oriented

Company

Realm

App.

Realm

Task1

administrative

DB

Realm

Task2

Cell

Realm

technical

Appl.

DB

OS

File

Resource

Network

Resource

OS

Realm


Danger of server applications

Danger of Server Applications

  • Server sind einfach zu erstellen, bieten aber immer potenzielle Einfallstore für Angreifer.

  • Selbstgebaute Authentisierungen können gefährlich sein.

  • Hohe Rechte für den Server sind gefährlich im Fehlerfall.

  • In den Systemen ist meist viel Ambient Authority verfügbar.

  • Server irren sich bei den Zugriffsrechten (Confused Deputy Problem).

  • Server machen Fehler bei der Umsetzung von Eingabestrings in Ressourcen.

  • Manche Server implementieren sehr verschiedene Funktionen, die es schwierig machen, das gesamte Gefahrenpotential abzuschätzen.

  • Server müssen teilweise privilegierte Operationen ausführen und brauchen daher spezielle Rechte, zumindest für gewisse Zeit. Dies ergibt Angriffsmöglichkeiten.

  • Falls der Aufrufer nicht gegen die Betriebssystem-Registry autorisiert wurde, haben die Betriebssysteme keine Möglichkeit die Aktionen des Servers intern zu kontrollieren.

  • Die Rechte der Aufrufer können weit mehr umfassen, als die Server-Applikation eigentlich benötigen würde. Ohne Sandbox-artige Einschränkung der Server Applikationen existiert auch dadurch Ambient Authority.


Building secure systems

„Server“

Process

(execution

Environment)

Service

Code

Server components

User

State

All User Data


Building secure systems

„Server“

Process

Process

Service Y

Service Y

User B State

User C State

One Process per User- too expensive? (idle users?)


Building secure systems

„Server“

Process

Service Y

User F State

User A State

Process is either single-threaded, event-driven or multithreaded.

One Process per Service.


Building secure systems

„Server“

Process

Service Y

Service X

One Process

Many Services

Many User (States)

User State

User State

User State

User State

User State

User State

User State

User State


Building secure systems

SAP „Server“

Process

(execution

Environment)

Service X

Code/Data

User A

Session Data

Memory mapped into Process or Virtual Machine


Building secure systems

SAP VM


Authority restriction with secure software entities

Authority Restriction with Secure Software Entities


Building secure systems

http requests

root

Config

Server

Loader

Dispatcher

Child P.

Child P.

jail

jail

request

Child Process

Child Process

Child process

Log Service

Web

Service A

Web

Service B

Log request

jail

authentication

machine

DB

Proxy

DB

Proxy

Service A partition

Service B

partition


Building secure systems

Data in Database

Compromised

Process which

Serves

Service C

User A data

User F data

Service C partition


Building secure systems

Data in Database

Compromised

Process which

Serves

Service C

User A data

User F data

Service C partition


Building secure systems

Data in Database

Data relevant for

User A + Service C

User A data

Data relevant for

User F + Service C

User F data

Service C partition


Building secure systems

Data in Database

User A data

Compromised

Data User F/Serv. C

User F data

Service C partition


Database views to reduce exposure and use backend access control

Database Views to reduce exposure and use backend access control

Authorized: Service A

View for

Service A

Table with users and

Services

Authorized: Service B

View for

Service B


Building secure systems

Administration and Race Conditions

Not atomic!

Root

Change runtime environment to jail

Change owner

change identity to user

User

Jails strips off other rights


Malicious code

Malicious Code

All resources the user has a right to access (ACL)

object

what the user wanted

object

Program started by user

object

CODE

service

service

what the code did

service

User A

All the resources have an attached ACL which says that user A may access the object. This allows malicious code once started by a user to access and abuse all resources the user has access to.


Building secure systems

  • Principles and Patterns:

  • POLA,

  • Authority + Designation

  • No side-effects

  • Closures

  • Forced Interceptors

  • Usability

Access Rights (Roles or Identity based

Vs. Capability based)

Application/Server Architecture

(Runtime Authority, Modularity)

Security Libraries and Frameworks

Computer Languages and VM‘s

(Type Safety)

Operating System and Kernel

(Device Drivers, Rights Management)

Hardware (e.g. Crypto Processors)


Building secure systems

Threats:

  • Buffer Overflow Attack on Server Application (external)

  • Administrator rights abuse

  • Kernel Network stack vulnerability

  • Weak keys in application (e.g. SSO)

  • Race condition attack on admin scripts

  • shatter attack (windows)

  • root-kit placement from CD or DVD

  • resource hogging application (cycle stealer)

  • Input validation problem in application

  • Bad device drivers (stability, malicious code)


Building secure systems

  • Teure Adressraum-Umschaltungen

  • Grosse TCBs

  • Effiziente IPC

  • IO (speziell DMA) nicht virtualisierbar auf manchen Plattformen

  • Cache Management (coloring)

  • Wenig Privilegien-Schichten auf manchem Plattformen


Building secure systems

OSGI

Mission Critical Security

  • Java Code Security (Protection domain = Codebase, Signature, Principal)

  • Added permissions for administration and service management

  • Service registry and service interfaces to control export/import and use of services and packages with the help of the class loader

OSGI is a first step towards a reliable, type-safe platform for mission critical applications in homes, cars and industries. But it is not perfect: class loaders are a terrible way to achieve isolation. Service management is coarse grained and not expressive enough (e.g. if there are two similiar services available I‘d like number A). The difficulty is to allow the addition or removal of services ANY TIME. Interesting combinations of OSGI and Peer-to-Peer technologies (JXTA) are currently investigated.


Objcect capabilities

Objcect Capabilities

Fine-Grained Authority Reduction

Each application or module gets only as much authority as it needs for the job. This allows safe plug-ins like the renderer for a mail type. From the DARPA browser study (www.combex.org)


  • Login