Computer Security. 04r. Pre-exam 1 Concept Review. Paul Krzyzanowski. Rutgers University. Spring 2018

Similar documents
Advanced Systems Security: Ordinary Operating Systems

OS Security III: Sandbox and SFI

Computer Security. 02. Operating System Access Control. Paul Krzyzanowski. Rutgers University. Spring 2018

Advanced Systems Security: Ordinary Operating Systems

I m paranoid, but am I paranoid enough? Steven M. Bellovin February 20,

Data Security and Privacy. Unix Discretionary Access Control

CS 416: Operating Systems Design April 22, 2015

Operating Systems. Week 13 Recitation: Exam 3 Preview Review of Exam 3, Spring Paul Krzyzanowski. Rutgers University.

Last time. Security Policies and Models. Trusted Operating System Design. Bell La-Padula and Biba Security Models Information Flow Control

Sandboxing Untrusted Code: Software-Based Fault Isolation (SFI)

Last time. User Authentication. Security Policies and Models. Beyond passwords Biometrics

I run a Linux server, so we re secure

Least-Privilege Isolation: The OKWS Web Server

Department of Electrical Engineering and Computer Science MASSACHUSETTS INSTITUTE OF TECHNOLOGY Fall Quiz I Solutions

I m paranoid, but am I paranoid enough? Steven M. Bellovin October 2,

Secure Programming II. Steven M. Bellovin September 29,

Complex Access Control. Steven M. Bellovin September 10,

Module: Program Vulnerabilities. Professor Trent Jaeger. CSE543 - Introduction to Computer and Network Security

This exam contains 7 pages (including this cover page) and 4 questions. Once we tell you to start, please check that no pages are missing.

Operating Systems Design Exam 3 Review: Spring Paul Krzyzanowski

Discretionary Access Control

Access Control. CMPSC Spring 2012 Introduction Computer and Network Security Professor Jaeger.

Computer Security Course. Midterm Review

This exam contains 8 pages (including this cover page) and 4 questions. Once we tell you to start, please check that no pages are missing.

CSE 127: Computer Security. Security Concepts. Kirill Levchenko

CSE 565 Computer Security Fall 2018

Linux Systems Security. Security Design NETS Fall 2016

CSCI 420: Mobile Application Security. Lecture 7. Prof. Adwait Nadkarni. Derived from slides by William Enck, Patrick McDaniel and Trent Jaeger

Architecture. Steven M. Bellovin October 31,

Module: Program Vulnerabilities. Professor Trent Jaeger. CSE543 - Introduction to Computer and Network Security

CS 356 Operating System Security. Fall 2013

CS 161 Computer Security

Software Security and Exploitation

CSE 544 Advanced Systems Security

Access Control Mechanisms

Web Servers and Security

Access Control. Steven M. Bellovin September 13,

Module: Program Vulnerabilities. Professor Trent Jaeger. CSE543 - Introduction to Computer and Network Security

Protection. CSE473 - Spring Professor Jaeger. CSE473 Operating Systems - Spring Professor Jaeger

Operating Systems Design Exam 3 Review: Spring 2011

Secure Architecture Principles

Secure Architecture Principles

Operating system security models

Security Models Trusted Zones SPRING 2018: GANG WANG

Module 4: Access Control

CSE543 - Introduction to Computer and Network Security

Security Enhanced Linux

L1: Computer Security Overview. Hui Chen, Ph.D. Dept. of Engineering & Computer Science Virginia State University Petersburg, VA 23806

Outline. Classic races: files in /tmp. Race conditions. TOCTTOU example. TOCTTOU gaps. Vulnerabilities in OS interaction

CSE Computer Security

Secure Programming I. Steven M. Bellovin September 28,

Advanced System Security: Vulnerabilities

Outline. Security as an economic good. Risk budgeting with ALE. Failure: Risk compensation. Failure: Displacement activity

2 Sadeghi, Davi TU Darmstadt 2012 Secure, Trusted, and Trustworthy Computing Chapter 6: Runtime Attacks

CSE509 Spring 2007 Midterm Exam. Electronic devices, including calculators, cell phones, mp3 players, and laptops are all prohibited.

Access Control. Discretionary Access Control

Web Servers and Security

Access Control Models

Sandboxing. CS-576 Systems Security Instructor: Georgios Portokalidis Spring 2018

CSE543 - Introduction to Computer and Network Security. Module: Operating System Security

Hacking Blind BROP. Presented by: Brooke Stinnett. Article written by: Andrea Bittau, Adam Belay, Ali Mashtizadeh, David Mazie`res, Dan Boneh

CMPSC 497 Attack Surface

Access Control. Steven M. Bellovin September 2,

Confinement (Running Untrusted Programs)

Secure Architecture Principles

CS 161 Computer Security

CS 361S - Network Security and Privacy Spring Homework #2

Department of Electrical Engineering and Computer Science MASSACHUSETTS INSTITUTE OF TECHNOLOGY Fall Quiz I

Outline. Operating System Security CS 239 Computer Security February 23, Introduction. Server Machines Vs. General Purpose Machines

cs642 /introduction computer security adam everspaugh

Introduction to Systems Security

3/7/18. Secure Coding. CYSE 411/AIT681 Secure Software Engineering. Race Conditions. Concurrency

Security Architecture

Information Security Theory vs. Reality

SELinux. Don Porter CSE 506

6.858 Lecture 4 OKWS. Today's lecture: How to build a secure web server on Unix. The design of our lab web server, zookws, is inspired by OKWS.

Linux Capability Exploration Lab

Program Security and Vulnerabilities Class 2

Hackveda Training - Ethical Hacking, Networking & Security

Buffer overflow background

Lecture 08 Control-flow Hijacking Defenses

Wrapup. CSE497b - Spring 2007 Introduction Computer and Network Security Professor Jaeger.

Introduction to Computer Security

Architecture. Steven M. Bellovin October 27,

Intrusion Detection Types

Introduction. CS3026 Operating Systems Lecture 01

OS Security. Authorization. Radboud University Nijmegen, The Netherlands. Winter 2015/2016

Secure Architecture Principles

C and C++ Secure Coding 4-day course. Syllabus

Access control models and policies. Tuomas Aura T Information security technology

Computer Security. 02r. Assignment 1 & Access Control Review. Paul Krzyzanowski David Domingo Ananya Jana. Rutgers University.

Exercise 4: Access Control and Filesystem Security

Department of Electrical Engineering and Computer Science MASSACHUSETTS INSTITUTE OF TECHNOLOGY Fall 2011.

CSE 565 Computer Security Fall 2018

Symlink attacks. Do not assume that symlinks are trustworthy: Example 1

DAC vs. MAC. Most people familiar with discretionary access control (DAC)

Software Security II: Memory Errors - Attacks & Defenses

A Survey of Access Control Policies. Amanda Crowell

Discretionary Vs. Mandatory

Operating System Security

Transcription:

Computer Security 04r. Pre-exam 1 Concept Review Paul Krzyzanowski Rutgers University Spring 2018 February 15, 2018 CS 419 2018 Paul Krzyzanowski 1

Key ideas from the past four lectures February 15, 2018 CS 419 2018 Paul Krzyzanowski 2

Computer security What computer security addresses: Confidentiality Allow only authorized users to access data & resources Privacy: limit what information will be shared with others Privacy is a reason for confidentiality Integrity: trustworthiness of data & resources Data integrity: data hasn t been corrupted Origin integrity/destination integrity: validate who is sending and who is receiving System integrity: system works properly and has not been subverted Availability The system is available for use and performs properly February 15, 2018 CS 419 2018 Paul Krzyzanowski 3

No easy answers Security is hard Software is incredibly complex Systems are complex: cloud + local; 3 rd party components; multiple admins If it was easy, we wouldn t have massive security breaches year after year No magic solutions February 15, 2018 CS 419 2018 Paul Krzyzanowski 4

Security goals Prevention: prevent attackers from violating security policy Implement mechanisms that users cannot override Example: ask for a password Detection: detect & report attacks Important when prevention fails Indicates & identifies weaknesses with prevention Also: detect attacks even if prevention is successful Recovery: stop the attack, repair damage Or continue to function correctly even if attack succeeds Forensics: identify what happened so you can fix it Example: restoration from backups February 15, 2018 CS 419 2018 Paul Krzyzanowski 5

Policies & Mechanisms Policy: description of what is or is not allowed E.g., users must have a password Mechanisms: implement and enforce policies E.g., password entry & authentication February 15, 2018 CS 419 2018 Paul Krzyzanowski 6

Definitions Vulnerability A weakness in the implementation or operation of a system Bugs, bad configuration, lack of access controls Attack A means of exploiting a vulnerability E.g., buffer overflow, social engineering Threat An adversary that is capable of attacking Trusted Computing Base (TCB) All hardware & software of a computing system critical to its security Example: operating system & system software If the TCB is compromised, you have no assurance that any aspect of the system is secure February 15, 2018 CS 419 2018 Paul Krzyzanowski 7

Threat categories Disclosure: Unauthorized access to data Snooping (wiretapping) Deception: Acceptance of false data Injection of data, modification of data, denial of receipt Disruption: Interruption or prevention of correct operation Modification of the system, denial of service, delays Usurpation: Unauthorized control of some part of a system Modification, spoofing an identity, escalation of privileges February 15, 2018 CS 419 2018 Paul Krzyzanowski 8

Access Control February 15, 2018 CS 419 2018 Paul Krzyzanowski 9

Protection & Access Control Protection The mechanism that provides and enforces controlled access of resources to processes A protection mechanism enforces security policies Access control Ensure that authorized users can do what they are permitted to do and no more February 15, 2018 CS 419 2018 Paul Krzyzanowski 10

The Operating System Protect the OS from applications Make sure it stays in control Basic OS mechanisms Hardware timer periodically gives control to the OS Scheduler decides which process gets to run Memory Management Unit (MMU) provides private memory spaces and memory protection (read/write/execute access) User & kernel mode execution only the kernel can access privileged instructions February 15, 2018 CS 419 2018 Paul Krzyzanowski 11

Access control: subjects & objects Subject: the thing that needs to access resources Often the user Object: the resource the subject may access Access control: defines how subjects may access objects February 15, 2018 CS 419 2018 Paul Krzyzanowski 12

Unix (POSIX) access control Each object (file, device) has An owner and a group Read, write, and/or execute permissions for the owner, group, and other (everyone else) Each subject (user) has One user ID Membership in one or more groups For directories Execute permission = search permission Write access = you can create/delete files or directories within that directory February 15, 2018 CS 419 2018 Paul Krzyzanowski 13

POSIX file operations chmod: set file permissions chown: change file ownership of a file chgrp: change group ownership of a file setuid: permission bit that causes an executable file to run with the ID of the file owner, not the user who is executing the file WARNING! Many set UID programs run as root (administrator) and are attractive targets. If you can take control of that program then you have administrative privileges February 15, 2018 CS 419 2018 Paul Krzyzanowski 14

Principle of least privilege Principle of least privilege At each abstraction layer, every element (user, process, function) should be able to access only the resources necessary to perform its task Privilege separation Divide a program into multiple parts: high & low privilege components February 15, 2018 CS 419 2018 Paul Krzyzanowski 15

Access control matrix Access control lists vs. capability lists objects objects domains of protection (subjects) F 0 F 1 Printer D 1 D 2 D 0 read readwrite read-writeexecute readexecute read print D 3 read print D 4 print F 0 F 1 Printer D 1 D 2 D 0 read readwrite read-writeexecute readexecute read print D 3 read print D 4 print Access control list Capability list February 15, 2018 CS 419 2018 Paul Krzyzanowski 16

DAC vs. MAC DAC = Discretionary Access Control Users get to set access permissions MAC = Mandatory Access Control Administrators set access permissions that users cannot overwrite February 15, 2018 CS 419 2018 Paul Krzyzanowski 17

Multi-Level Security Models The Bell-LaPadula model is all about confidentiality Simple security property: You cannot read data from higher clearance levels than you are Star *-property: You cannot create data that is a lower clearance level than you are Discretionary security property Users can control access with ACLs only after MAC is enforced The Biba model is similar but is all about integrity Simple integrity property: You cannot read an object from a lower integrity level than you are Example: A process will not read a system configuration file created by a lowerintegrity-level process Star *-property: You cannot write to an object of a higher integrity level than you are Example: A web browser may not write a system configuration file February 15, 2018 CS 419 2018 Paul Krzyzanowski 18

Other MAC models Type Enforcement (TE) Model Another access control matrix that gets checked first Subjects assigned to domains; objects assigned to types Matrix defines domain-domain and domain-type transitions Role-Based Access Control (RBAC) model Users are assigned roles (job functions) Access permissions are granted to roles February 15, 2018 CS 419 2018 Paul Krzyzanowski 19

Multilateral Security In addition to levels, a level may have compartments You can only access resources if you have been granted access to that compartment E.g., {Top Secret, Elvis} can access {Top Secret}, {Secret, Elvis}, {Secret} Cannot access {Top Secret, UFO}, {Secret, UFO} Lattice model Directed graph that defines access rights among clearance levels and compartment labels February 15, 2018 CS 419 2018 Paul Krzyzanowski 20

Chinese Wall Model Defines conflict classes: groups of competing companies Designed for businesses where employees have to avoid conflict of interest Basic rule A subject can access objects from a company as long as it never accessed objects from competing companies. February 15, 2018 CS 419 2018 Paul Krzyzanowski 21

Program Hijacking February 15, 2018 CS 419 2018 Paul Krzyzanowski 22

Stack-based buffer overflow Buffer limits not checked Often because unsafe functions like strcpy, strcat, and sprintf are used Overflow overwrites frame pointer & stack pointer If the stack pointer is changed, the return address is changed Write code into the buffer Overflow the buffer to set the return address When the function returns, it branches to the new code February 15, 2018 CS 419 2018 Paul Krzyzanowski 23

Off-by-one Buffer Overflows An off-by-one stack overflow can only modify one byte of the top of the stack, which holds the frame pointer When a function returns, the modified frame pointer becomes the reference point for all local variables It also becomes the new stack pointer when a new function is called (see homework assignment) February 15, 2018 CS 419 2018 Paul Krzyzanowski 24

Heap & text segment overflows A buffer overflow can overwrite adjacent variables that are allocated in higher memory The program will use these modified variables February 15, 2018 CS 419 2018 Paul Krzyzanowski 25

Printf format attacks If an attacker can change the printf format string Read the stack Read any address on the stack (using %x, for example) If you don t supply arguments, printf will match %x with the next item on the stack Modify memory Use %x to set where we write in memory: each %x skips one word on the stack Use %.Nx to generate N bytes of output this allows you to set the value you will write Use %n to write the value it prints the # of bytes output so far February 15, 2018 CS 419 2018 Paul Krzyzanowski 26

Defenses Data Execute Protection (DEP) Operating system turns off execute permission for stack and heap memory Attacks: return-to-libc: overflow a return address to a desired point in the C library Return-Oriented-Programming (ROP): overflow a stack of return addresses to various points in libraries or the program the return from one function takes you to the next entry point Address Space Layout Randomization (ASLR) Load programs and libraries into different memory locations so addresses are different each time Stack Canaries Compiler places a random # on the top of the stack and checks it before returning from a function February 15, 2018 CS 419 2018 Paul Krzyzanowski 27

SQL Injection Attacks If user input becomes part of a SQL query, it can change the type of query or add additional commands SELECT * from logininfo WHERE username = paul AND password = 'abcde' SELECT * from logininfo WHERE username = paul AND password = '' OR 1=1 -- ;' Validate all input! Safest prevention = use parameterized queries don t make user input part of the command February 15, 2018 CS 419 2018 Paul Krzyzanowski 28

Shell injection attacks IFS internal field separator: change the definition of how the shell parses arguments (it doesn t have to be whitespace) Use of system() and popen() in programs These invoke the shell. Same risk as SQL injection if user input is part of the command PATH variable: change the order in which the shell looks for programs LD_PRELOAD: preload libraries, possibly overriding functions that the program uses with your own LD_LIBRARY_PATH: similar attack tell the OS where to look for libraries February 15, 2018 CS 419 2018 Paul Krzyzanowski 29

App-level name parsing Parsing pathnames to make sure a user-supplied name stays within a subdirectory can be trickly http://poopybrain.com/../../../etc/passwd Escaped unicode characters make it harder Single-byte characters have multi-byte equivalents: / = 0x2f = 0xc0af Homograph Attacks Not an injection attack but a social engineering one confuses users Similar characters may be represented in different languages or different symbols in Unicode: you can often write the same text using different characters February 15, 2018 CS 419 2018 Paul Krzyzanowski 30

TOCTTOU Attack Time Of Check To Time Of Use If you check the condition and then do something, you may introduce a race condition An attacker may change something after you check the condition but before you do the operation Example: change a link to a user-readable file to a privileged file February 15, 2018 CS 419 2018 Paul Krzyzanowski 31

RASQ The more a program interacts with its environment (users, files, networks), the more opportunities there are for attack Relative Attack Surface Quotient A metric Microsoft created to estimate how vulnerable a system might be Each type of attack gets a bias a risk assessment Roughly, sum up all possible interactions with each interaction multiplied by its bias February 15, 2018 CS 419 2018 Paul Krzyzanowski 32

App confinement chroot: change root directory for a process & its children If an attacker becomes root, he may be able to escape by creating a device file that gives access to the disk or to memory FreeBSD Jails Same namespace protection like chroot But you can take power away from root for processes in the jail No ability to create devices, raw sockets, mounting filesystems Way more secure February 15, 2018 CS 419 2018 Paul Krzyzanowski 33

App confinement Linux namespaces Provide a private namespace for directory structure, network, process ID, user/group IDs, IPC, hostname Linux capabilities Selectively take away power if a process becomes root. Disallow file owner changes, permission changes, sending signals, creating raw sockets, changing root, etc. Linux control groups Limit how much resources a process can use (CPU, memory, files, network) February 15, 2018 CS 419 2018 Paul Krzyzanowski 34

The end February 15, 2018 CS 419 2018 Paul Krzyzanowski 35