ソフトウェアエンジニアの技術ブログ：Software engineer tech blog

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

Buffer overflows that occur in the heap data area
-typical heap manipulation function: malloc()/free()

Higher Address: Stack
Lower Address: Heap

char* p = malloc(256);
memset(p, 'A', 1024);

Overwrite the function pointer in the adjacent buffer
Before heap overflow, after heap overflow

Programming language choice is crucial
the language…
should be strongly typed
should do automatic bounds checks
should do automatic memory management
Examples of safe languages: Java, C++, Python

Defense Against Buffer Overflow Attacks
why are some languages safe?
buffer overflow becomes impossible due to runtime system checks
the drawback of secure languages
possible performance degradation

Using unsafe languages:
check input (All input is EVIL)
use safer functions that do bounds checking
use automatic tools to analyze code for potential unsafe funtions

Defense Against buffer Overflow attacks
Analysis tools…
can flag potentially unsafe functions/contructs
can help mitigate security lapses, but it is really hard to eliminate all buffer overflows

We type a correct password of less than 12 characters:
The login request is allowed.
Now let us type “BadPassWd” when we are asked to provide the password:
The login request is rejected.

We can carefully overflow the return address so it contains the value of an address where we put some code we want executed.

ShellCode
create a shell which allows it to execute any code the attacker wants

Whose privileges are used when attacker code is executed?
-the host program’s
-system service or OS root privileges

National Vulnerability Database(NVD)

Variations of buffer overflow
-return-to-libc: the return address is overwritten to point to a standard library function
-heap overlows: 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.

-software vulnerabilities and how attackers explit them
-defenses against attacks that try to exploit buffer overflows
-secure programming: code “defensively”, expecting it to be exploited. Do not trust the “inputs” that come from user of the software system.

e.g. Buffer overflow – a common and persistent vulnerability
stack buffer overflows,
stacks are used… in function/procedure calls, for allocation of memory for local variables, parameters, control information(return address)

#include <stdio.h>
#include <strings.h>

int main(int argc, char *argv[]){
	int allow_login = 0;
	char pwdstr[12];
	char targetpwd[12] = "MyPwd123";
	gets(pwdstr);
	if (strncmp(pwdstr, targetpwd, 12) == 0)
		allow_login = 1;
	if (allow_login == 0)
		printf("Login request rejected");
	else
		printf("Login request allowed");
}