Computer Security CS 2110 3 May, 2018.

Slides:



Advertisements
Similar presentations
Buffer Overflows Nick Feamster CS 6262 Spring 2009 (credit to Vitaly S. from UT for slides)
Advertisements

Integrity & Malware Dan Fleck CS469 Security Engineering Some of the slides are modified with permission from Quan Jia. Coming up: Integrity – Who Cares?
Exploring Security Vulnerabilities by Exploiting Buffer Overflow using the MIPS ISA Andrew T. Phillips Jack S. E. Tan Department of Computer Science University.
Ensuring Operating System Kernel Integrity with OSck By Owen S. Hofmann Alan M. Dunn Sangman Kim Indrajit Roy Emmett Witchel Kent State University College.
Using Programmer-Written Compiler Extensions to Catch Security Holes Authors: Ken Ashcraft and Dawson Engler Presented by : Hong Chen CS590F 2/7/2007.
1 Protection Protection = access control Goals of protection Protecting general objects Example: file protection in Linux.
CSE 451: Operating Systems Section 1. Why are you here? 9/30/102.
Concepts of Version Control A Technology-Independent View.
1 Building with Assurance CSSE 490 Computer Security Mark Ardis, Rose-Hulman Institute May 10, 2004.
CMSC 414 Computer and Network Security Lecture 9 Jonathan Katz.
Building Secure Software Chapter 9 Race Conditions.
Processes CS 416: Operating Systems Design, Spring 2001 Department of Computer Science Rutgers University
CS252: Systems Programming Ninghui Li Final Exam Review.
Secure Embedded Processing through Hardware-assisted Run-time Monitoring Zubin Kumar.
Lecture 18 Page 1 CS 111 Online Design Principles for Secure Systems Economy Complete mediation Open design Separation of privileges Least privilege Least.
Security Exploiting Overflows. Introduction r See the following link for more info: operating-systems-and-applications-in-
© G. Dhillon, IS Department Virginia Commonwealth University Principles of IS Security Formal Models.
CS 3204 Operating Systems Godmar Back Lecture 26.
Information Flow Language and System Level 1Dennis Kafura – CS5204 – Operating Systems.
Lecture 8: Buffer Overflow CS 436/636/736 Spring 2013 Nitesh Saxena *Adopted from a previous lecture by Aleph One (Smashing the Stack for Fun and Profit)
1 A Secure Access Control Mechanism against Internet Crackers Kenichi Kourai* Shigeru Chiba** *University of Tokyo **University of Tsukuba.
Processes CS 6560: Operating Systems Design. 2 Von Neuman Model Both text (program) and data reside in memory Execution cycle Fetch instruction Decode.
Improving Xen Security through Disaggregation Derek MurrayGrzegorz MilosSteven Hand.
Operating Systems Security
Introduction Program File Authorization Security Theorem Active Code Authorization Authorization Logic Implementation considerations Conclusion.
Dilip Dwarakanath.  The topic I’m about to present was taken from a paper titled “Apple iOS 4 Security Evaluation” written by Dino A Dai Zovi.  Dino.
Security-Enhanced Linux Eric Harney CPSC 481. What is SELinux? ● Developed by NSA – Released in 2000 ● Adds additional security capabilities to Linux.
Privilege Escalation Two case studies. Privilege Escalation To better understand how privilege escalation can work, we will look at two relatively recent.
Dynamic Taint Analysis for Automatic Detection, Analysis, and Signature Generation of Exploits on Commodity Software Paper by: James Newsome and Dawn Song.
Information Security - 2. A Stack Frame. Pushed to stack on function CALL The return address is copied to the CPU Instruction Pointer when the function.
Security Attacks Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.
Lecture 14 Page 1 CS 111 Summer 2013 Security in Operating Systems: Basics CS 111 Operating Systems Peter Reiher.
SSH/SSL Attacks not on tests, just for fun. SSH/SSL Should Be Secure Cryptographic operations are secure SSL uses certificates to authenticate servers.
Lecture 5 Rootkits Hoglund/Butler (Chapters 1-3).
VM: Chapter 7 Buffer Overflows. csci5233 computer security & integrity (VM: Ch. 7) 2 Outline Impact of buffer overflows What is a buffer overflow? Types.
Beyond Stack Smashing: Recent Advances In Exploiting Buffer Overruns Jonathan Pincus and Brandon Baker Microsoft Researchers IEEE Security and.
Lecture 8 Page 1 CS 236, Spring 2008 Operating System Security CS 236 On-Line MS Program Networks and Systems Security Peter Reiher Spring, 2008.
PREPARED BY: MS. ANGELA R.ICO & MS. AILEEN E. QUITNO (MSE-COE) COURSE TITLE: OPERATING SYSTEM PROF. GISELA MAY A. ALBANO PREPARED BY: MS. ANGELA R.ICO.
Chapter 29: Program Security Dr. Wayne Summers Department of Computer Science Columbus State University
Lec. Waleed Bin Shahid.  You might have noticed a lot of issues related to software implementation.  The ultimate requirement of developer(s) is to.
Memory Management.
Let’s look at an example
Introduction to Operating Systems
Protecting Memory What is there to protect in memory?
Boots Cassel Villanova University
Protecting Memory What is there to protect in memory?
Protecting Memory What is there to protect in memory?
Secure Software Confidentiality Integrity Data Security Authentication
Mechanism: Limited Direct Execution
Operating Systems: A Modern Perspective, Chapter 6
The Security Problem Security must consider external environment of the system, and protect it from: unauthorized access. malicious modification or destruction.
Computer Security CS November, 2017.
Exam Review.
Security mechanisms and vulnerabilities in .NET
CS 465 Buffer Overflow Slides by Kent Seamons and Tim van der Horst
Chapter 2: The Linux System Part 2
Security in Java Real or Decaf? cs205: engineering software
Privilege Separation in Condor
Light-weight Contexts: An OS Abstraction for Safety and Performance
Software Security Lesson Introduction
Light-weight Contexts: An OS Abstraction for Safety and Performance
Lecture Topics: 11/1 General Operating System Concepts Processes
Chapter 29: Program Security
Shielding applications from an untrusted cloud with Haven
PLANNING A SECURE BASELINE INSTALLATION
Understanding and Preventing Buffer Overflow Attacks in Unix
Preventing Privilege Escalation
Outline Introduction Memory protection Buffer overflows
Dirty COW Race Condition Attack
Return-to-libc Attacks
Presentation transcript:

Computer Security CS 2110 3 May, 2018

Computer Science

Computer Security

Computer Security Security is about making sure that computers behave correctly A secure system should: Do what it is supposed to do Not do anything else

What might go wrong public class ObjectStore { private Object[] objects; public ObjectStore(int len){ objects = new Object[len]; } public Object read(int i){ return objects[i]; public void store(int i, Object o){ objects[i]= o;

OpenSSL struct { HeartbeatMessageType type; uint16 payload_length; opaque payload[HeartbeatMessage.payload_length]; opaque padding[padding_length]; } HeartbeatMessage;

Heartbleed

What might go wrong public class ObjectStore { private Object[] objects; public ObjectStore(int len){ objects = new Object[len]; } public Object read(int i){ return objects[i]; public void store(int i, Object o){ objects[i]= o;

Memory Stack Heap ObjectStore OS = new ObjectStore(10); ... 12 o Ret ptr Stack ptr o objects[i]= o; exploit code Heap Statics Code 0x00000000

Skype Vulnerability May 2017 Microsoft Skype v7.2, v7.3.5 & v7.3.6 on Windows XP, 7, 8, or 10 exploits vulnerability in copy function; carefully constructed cat photo will trigger overflow, overwrite return pointer, and allow arbitrary code execution

What might go wrong Thread 2 Thread 1 Initially, i = 0 tmp = load i; Load 0 from memory Load 0 from memory tmp = load i; tmp = tmp + 1; store tmp to i; Store 1 to memory tmp = tmp + 1; store tmp to i; Store 1 to memory time

Copy-on-write (COW) Common resource optimization When someone copies a file, it doesn't really get copied If/when someone modifies the "copy" the original file gets copied and modified

Privilege Escalation October 2016 privilege escalation vulnerability discovered in Linux A bug in the copy-on-write (COW) mechanism allowed any installed application to gain root level access. At a high level, the exploit works by opening a root-owned executable as read-only and memory mapping it into the user-level process’s address space. The user-level process then runs two threads: one of which repeatedly uses madvise() to tell the kernel it doesn’t intend to use that memory and one of which repeatedly overwrites some of its own memory that’s mapped to the root-owned executable. A race condition bug results in writes updating the mapping copy instead of writing to a private copy; these changes are subsequently committed by the kernel to storage. This technique can be exploited to alter a root-owned setuid binary so that it, for example, spawns a root-owned shell, allowing the user-level process to operate with root privileges.

So how do we fix this? Testing Bug finding tools White-hat hacking

So how do we fix this?

Security by Design Build secure, trustworthy computer systems/applications/etc. Define what the system is supposed to do Make sure it does that (and only that)

Engineering Security Attacks are perpetrated by threats that cause incorrect behavior by exploiting vulnerabilities which are controlled by countermeasures.

How do we specify what systems are and are not supposed to do?

Example: Data Privacy Lots of data: by one estimate, 2.5 exabytes of data are produced every day This data has lots of potential uses the problem: what happens with the data isn’t always what you want => user’s don’t consent, legal restrictions

What is Privacy? discuss Warren/Brandeis (right to be left alone) Privacy as confidentiality Nissenbaum (contextual integrity)

Use-Based Privacy Privacy viewed as restrictions on uses [Cate02] Captures modern privacy goals express restrictions in presence of necessary sharing Medical Data Social Network Data Then need a language for privacy policies, then need to express security goals in language

Policy Language [{"curr":"1", "states":{"1":{"name":"s1-1", "permissions":{"aggregate":true}, "transitions":{"aggregate":"s2-1"}, "defaultPermission":false}, "2":{"name":"s2-1", "permissions":{"fulfill":true}, "transitions":{}, "defaultPermission":true}}}, {"curr":"2", "states":{"1":{"name":"s1-2", "permissions":{"aggregate":true}, "transitions":{"aggregate":"s2-2"}, "defaultPermission":false}, "2":{"name":"s2-2", "permissions":{"fulfill":true}, "transitions":{}, "defaultPermission":true}}}] aggregate fulfill aggregate

Engineering Security Attacks are perpetrated by threats that cause incorrect behavior by exploiting vulnerabilities which are controlled by countermeasures.

What are the threats?

Threat Models Capabilities, Resources, Motivation

Threat Models

Example: Threat Model for Data Privacy DS In our context, adversaries are service providers. adversarial accountable

Engineering Security Attacks are perpetrated by threats that cause incorrect behavior by exploiting vulnerabilities which are controlled by countermeasures.

How do we design countermeasures

Classes of Countermeaures thentication: mechanisms that bind principals to actions thorization: mechanisms that govern whether actions are permitted dit: mechanisms that record and review actions

Approaches to security Axiomatic security You trust someone else to get it right

Approaches to security Axiomatic security You trust someone else to get it right Constructive security E.g., compiler checks, automated proofs

Approaches to security Axiomatic security You trust someone else to get it right Constructive security E.g., compiler checks, automated proofs Synthetic security Modify the code to add checks (e.g., monitoring) Code Monitor Code

Approaches to security Axiomatic security You trust someone else to get it right Constructive security E.g., compiler checks, automated proofs Synthetic security Modify the code to add checks (e.g., monitoring) Deterrence through accountability Make sure you'll notice if something goes wrong

Example: Data Privacy from SGX Agent Authenticator Data Source Data Store Policy Store data->pol Policy enforcement implemented by external monitor that runs on DHs monitor can send/receive values from DS monitor shares values with authorized programs co-located at DH auth decisions based on credentials unauthorized values are cryptographically sealed with associated policy to prevent authorized use monitor maintains taint for each program, automatically derives policies for derived values Data Handler Taints pid -> pol CredentialAuthent. Decision Engine Program Agent

Security [{"curr":"1", "states":{"1":{"name":"s1-1", "permissions":{"aggregate":true}, "transitions":{"aggregate":"s2-1"}, "defaultPermission":false}, "2":{"name":"s2-1", "permissions":{"fulfill":true}, "transitions":{}, "defaultPermission":true}}}]