Month: June 2017

-As password length and complexity increases, usability suffers
-Phishing and social engineering – users do not authenticate who is asking for a password
-Once a password is stolen, it can be used many times
-> This is why there are policies that say passwords be changed frequenty
-Humans have a hard time remembering lots of passwords. Usable passwords are easy to guess.

Sys Administrators:
– Never store passwords in the clear
– Store only hashed values generated with a random salt and limit acess to them
– Avoid general purpose fast hash functions

Users:
– Use password managers

Other Authentication Methods
– you must have them
– May require additional hardware (e.g., readers)
– How does it implement authentication (challenge/response)
– Cost and misplaced trust(RSA SecureID master key breach)

Various biometrics
– Fingerprints(finger swipes)
– Keystroke dynamics
– Voice
– Retina scans

Password -> H(password) -> A string of fixed length

Hash Functions & Threads
– We assume a one-way property for hash functions
– If we know common passwords, we can determine their hash
– For dictionary and offline attacks, we have hash values and plenty of time to test for matches

Brute Force Guessing of Passwords
– Publicly available software can do 10^8 MD5 hashes/sec on a GPU
– Six random upper case/lower case/digits then 62^6 possible passwords, about 10 minutes
– Eight random characters increases it to about six days

Passwords are not really random
To reduce the work required for a brute force attack:
– Try the popular passwords first
– Create a rainbow table

– Add a random salt before hashing
– Store the salt with the hashed value
– Check by using the salt with the typed password

Brute Force Guessing of Passwords
User ID, Salt, Hash code

A number of online banking systems send a limited lifetime PIN to your smartphone for you to be able to authenticate yourself to the bank.

Thread modeling of the password method
– guessing the password for a given user allows impersonation
– impersonating a real login program
– Keylogging to steal a passdword

Importance of a Trusted Path
Hardware/OS must provide a trusted path:
– Windows CNTL-ALT-DEL
– Keyboard and display must have trusted paths to OS
– Special kind of display under OS control
– Do users pay attention?

Store a list of passwords, one for each user in the system file.
– The file is readable only by the root/admin account
– What if the permissions are set incorrectly?
– Why shold admin know passwords?
– if security is breached, the passwords are exposed to attacker.

Use a one-way hash function and store the result
The password file is readable only for root/admin

Authentication : Who are you? prove it.
-> Authorization : Does this person have permission to access the requested resources?
-> Resources

OS(TCB) needs to know who makes a request for a protected resorce
A process that makes the request does it on behalf of a certain user, subject or principal
Authentication helps us answer the question: on whose behalf the requesting process runs?
Includes claims about an identity and verification of the claimed identitiy of the user who wants to gain access to system and resource

Authentication Goals
User/principal associated with an identity should be able to successfully authenticate itself
– Availability
– No false negatives

User/principal not associated with the dentity should not be able to authenticate itself
– Authenticity
– No false positives

How is Authentication implemented?
– something a user knows, something a user has, something a user is

OS is large and complex, even different operating systems may be desired by different customers
Compromise of an OS impacts all applications

Use: Hypervisor, virtual machines, guest OS and applications
Compromise of OS in VM1 only impacts applications running on VM1

Do your taxes in on VM1 while browsing potentially dangerous places on the web on VM2

Compromise of OS(TCB) means an attacker has access to everything.
Getting the TCB right is extreamly important
Smaller and simpler(hypervisor only partitions physical resource among VMs and let us guest OS handle management)
Secure coding is really important when writing the OS which typically is written in languages that are not type safe

No think, how can we do a non-executable stack to help prevent code injection via stack buffer?
– used by windows, os X, Linux

OS(Kernel) resides in a portion of each process’s address space
True for each process, processes can cross the fence only in controlled/limited ways.

32-bit Linux: Lower 3GB for user code/data, top 1GB for kernel
Corresponds to x86 privilege ring transitions
Windows and OS X similar
DOS had no such fence, any process could alter DOS and viruses could spread by hooking DOS interrupt handlers via kernel changes.

Linux User/Kernel Memory Split
Kernel Mode Space/ User Mode Space

Complete Mediation
-Make sure that no protected resource could be accessed without going through the TCB
-TCB acts as a reference monitor that cannot be bypassed
-Privileged instructions

User code cannot access OS part of address space without changing to system mode
User code cannot access physical resources because they require privileged instructions (e.g. servicing interrupts) which can only be executed in system mode.

OS virtualizes physical resources and provides and API for virtualized resources
File for storing persistent data on disk
Virtual resource must be translated to physical resource handle whch cn only be done by OS, which ensures complete mediation

Going from user to OS code
System calls used to transfer control between user and system code
– such calls come through “call gates” and return back to user code. The processor execution mode or privilege ring changes when call and return happen.
– x86 Systenter/ sysexit instructions

Isolating user processes from each other
How do we meet the user/user isolation and separation?
OS uses hardware support for memory protection to ensure this.

Processes view memory as contiguous often larger than available physical memory
– usually 2^32 or 2-64 addresses
– each process has its own mapping

Operating system maps logical virtual addresses or pages onto physical memory frames

OS will not map a virtual page of process A to a physical page of process B unless explicit sharing is desired.
– process A cannot access process B’s memory because it has no way to name/reach its memory.
– page tables managed by OS.

Process Protection through Memory Management
– processor memory management unit(MMU) uses page tables to resolve virtual addresses to physical addresses.
– RWX bits on pages lilmit type of access to addressable memory

Applications, OS, Hardware

Operating System:
-Provides easier to use and high level abstractions for resources such as address space for memory and files for disk blocks
-Provides controlled access to hardware resources
-Provides isolation between different processes and between the processes running untrusted/application code and the trusted operating system.

What requirements must it meet to be trusted?
TCB Requirements:
1. Tamper-proof,
2. Complete mediation
3. Correct

TCB and Resource Protection
TCB Controls access to protected resources
must establish the source of a request for resource(authentication is how we do it)
authorization or access control
mechanisms that allow various policies to be supported

Isolating OS from untrusted user code
how do we meet the first requirement of TCB
– hardware support for memory protection
– processor execution modes(system AND user modes, execution rings)
– privileged instructions which can only be executed in system model
– system calls used to transfer control between user and system code

Shell Code: creates a shell which allows it to execute any code the attacker wants.

Whose privileges are used when attacker code is executed?
・The hose program’s
・System service or OS root privileges

Return-to-libc: the return address is overwritten to point to a standard library function.

Heap Overflows: data stored in the heap is overwritten, data can be tables of function pointers.

OpenSSL Heartbleed Vulnerability: read much more of the buffer than just the data, which may include sensitive data.

Canary for tamper detection
– injected code, return address, canary, passwordok, userid, password
No code execution on stack

Thwarting Buffer Overflow Attacks
– Address space layout randomization(ASLR)
randomizes stack, heap, libc, etc. This makes it harder for the attacker to find important locations(e.g., libc function address).

Use a non-executable stack coupled with ASLR. This solution uses OS/hardware support.

argc, argv, return address, allowlogin, pwdstr, targetpwd