EMC Business Continuance

Download Report

Transcript EMC Business Continuance

Chapter 7: OS Security
Instructor: Hengming Zou, Ph.D.
In Pursuit of Absolute Simplicity 求于至简,归于永恒
1
Content
 The security environment
 Basics of cryptography
 User authentication
 Intrusions and attacks
 Protection mechanisms
 Trusted systems
2
Hardware Reality
 Collection of processor, memory, disks, network
interfaces that can be used by anyone to do anything
 Or could turn it off, leaving you with hardware that
won’t do anything for anyone
3
Security Goals and Threats
Goal
Threat
Data Confidentiality
Exposure of data
Data Integrity
Tampering with data
Personal Privacy
Misuse of data
System Availability
Denial of service
Acts of God
4
Security Threats
 Natural or man-made disasters
–fires, floods, earthquake, wars
 Hardware or software errors
–CPU malfunction, bad disk, program bugs
 Human errors
–data entry, wrong tape mounted
 Attacks by intruders or adversaries
–This is where we will focus in this lecture
5
Intrusion Motive
 Casual prying by non-technical users
 Snooping by insiders
 Determined attempt to make money
 Commercial or military espionage
6
Some Example Attacks
 Spoof identity
–pretend to send a message from your IP address
 Man-in-the-middle attack
–Eavesdrop and delete the original message
–Insert new message that pretends to be from original
sender
–Replay old messages
7
Security Elements
 Data security
–not viewed by unauthorized personnel
–data are not tampered
 System security
–Systems do not do things not supposed to do
8
Security Elements
 Static security
–Data stored are not compromised
–Achieved by access control and cryptography
 Dynamic security
–Data in transit is not compromised
–Achieved by secure communication
9
Secure Communication
 Confidentiality:
–Attacker should not be able to understand data
 Authentication:
–Assure receiver that message is from the right sender
 Freshness:
–Attacker should not be able to replay an old request
 Availability:
–No denial-of-service
10
Secure Communication
 How to achieve secure communication?
11
Cryptography
 Cryptography is one of the main tools used to provide
data security, both static and dynamic
–What other ways for secure communication?
 Basic idea
–encrypt (clear text, e-key) = cipher text
–decrypt (cipher text, d-key) = clear text
12
Basics of Cryptography
Encryption key
KD
KE
P
Plaintext In
Encryption
Algorithm
Encryption
Decryption key
C=E(P, KE)
Ciphertext
Decryption
Algorithm
P=D(C, KD)
Plaintext Out
Decryption
Relationship between plaintext and ciphertext
13
Cryptography
 Encrypt and decrypt algorithms are usually public
 Shouldn’t be able to deduce d-key from (clear text,
cipher text) pairs
14
One-Way Functions
 Encryption function should be selected such that
–given formula for f(x)
–easy to evaluate y = f(x)
 But given y
–computationally infeasible to find x
15
Symmetric Key Encryption
 Given e-key, it is easy to find out d-key
 Vice versa (i.e. symmetric)
–Sometimes d-key = e-key!
 Only sender and receiver know the key
 Sometimes this is called “secret key” encryption
–It must not be made public
16
Symmetric Key Cryptography
 Ex: Mono-alphabetic substitution
–each letter replaced by different letter
 ABCDEFGHIJKLMNOPQRSTUVWXYZ
 QWERTYUIOPASDFGHJKLZXCVBNM
 Given e-key
–QWERTYUIOPASDFGHJKLZXCVBNM,
 Easy to d-key:
–KXVMCNOPHQRSZYIJADLEGWBUFT
17
Symmetric Key Encryption
 How do sender and receiver get a shared secret key in
the first place?
18
Symmetric Key Encryption
 Famous Symmetric Key encryption include:
 DES、RC2、RC4、IDEA
 GOST、SAFER、FEAL、Skipjack、Blowfish
19
Public-key Encryption
 Also called asymmetric encryption
 Given e-key, it is virtually impossible to find d-key
–Thus the name asymmetric
 Thus, the encryption key can be made public
–Thus the name public
20
Public-Key Cryptography
 All users pick a public key/private key pair
–publish the public key
–private key not published
 Public key is the encryption key
–private key is the decryption key
21
Public-key Encryption
 Encryption/decryption process:
–crypt (clear text, e-key) = cipher-text-1
–crypt (cipher-text-1, d-key) = clear text
–crypt (clear text, d-key) = cipher-text-2
–crypt (cipher-text-2, e-key) = clear text
 In general d-key(e-key(msg))=e-key(d-key(msg))
–But not always!
22
Public-key Encryption
 Note that
–cipher-text-1 != cipher-text-2
–crypt(cipher-text-2, d-key) != clear text
–crypt(cipher-text-1, e-key) != clear text
 e-key is called the “public key”
–Everyone knows the value of everyone’s public keys
23
Public-key Encryption
 d-key is called the “private key”
–Only the sender knows his/her own private key
 Difficult to guess private key
–Even if you know the public key and crypt(),
–and lots of encrypted pairs
24
Public-key Encryption
 Public-key encryption can be used for authentication
 For example: to authenticate sender “zou”, we do:
– “from zou” crypt (message, zou-private)
 Anyone can read this message (no confidentiality)
 Only zou can generate this message
–Others can verify that zou generated the message
–by decrypting with zou-public
25
Public-key Encryption
 Why include “from zou” in the message?
–So that receivers know the message comes from zou
–so that s/he will use zou-public key to decode the text
 This is called a “digital signature”
–Can detect any change to the data
26
Public-key Encryption
 If using public-key encryption for privacy, do
–crypt (message, receiver-public)
 Anyone can send this message (no authentication)
 Only receiver can read it
27
Public-key Encryption
 Using PK encryption for authentication and privacy,
–crypt (“from zou” crypt (msg, zou-private), receiverpublic)
 Only receiver can read this
 Only zou can send it
28
Public-key Encryption
 Does the following work?
– “from zou” crypt (crypt (message, receiver-public),
zou-private)
29
Example Public-key System: RSA
 1978 by Ron Rivest, Adi Shamir, Leonard Adleman
 Principle:
–Multiplication and module is easy
–While factoring is difficult!
30
Example Public-key System: RSA
 Idea:
–Find two large (e.g., 1024-bit) prime numbers P and Q
 Choose
E such that:
–E is greater than 1 but less than PQ,
–E and (P-1)(Q-1) are relatively prime
–which means they have no prime factors in common
31
Example Public-key System: RSA

E does not have to be prime, but it must be odd
–(P-1)(Q-1) can't be prime because it's an even number
 Compute
D such that:
–(DE - 1) is evenly divisible by (P-1)(Q-1)
 Mathematicians write this as
DE = 1 mod (P-1)(Q-1)
–and they call D the multiplicative inverse of E
32
Example Public-key System: RSA
 This is easy to do:
 Simply find an integer X which causes:
–D = (X(P-1)(Q-1) + 1)/E to be an integer
–then use that value of D
33
Example Public-key System
 The encryption function is
 where

C = (T^E) mod PQ
C is the ciphertext (a positive integer)
T is the plaintext (a positive integer)
 ^ indicates exponentiation
 message
T must be less than the modulus PQ
34
Example Public-key System
 The decryption function is
 where

T = (C^D) mod PQ
C is the ciphertext (a positive integer)
T is the plaintext (a positive integer)
 ^ indicates exponentiation
35
Example Public-key System
 Your
public key is the pair (PQ, E)
 Your
private key is the number D (reveal it to no
one).
 The product
PQ is the modulus
–often called N in the literature

E is the public exponent

D is the secret exponent
36
Example Public-key System
 You can publish your public key freely
 because there are no known easy methods of
calculating D, P, or Q given only (PQ, E)
 (your public key)
 If
P and Q are each 1024 bits long, the sun will burn
out before the most powerful computers presently in
existence can factor your modulus into P and Q.
37
RSA Example
 P = 61 <- first prime number
–destroy this after computing E and D
 Q = 53 <- second prime number
–destroy this after computing E and D
 PQ = 3233 <- modulus (give this to others)
 E = 17 <- public exponent (give this to others)
 D = 2753 <- private exponent (keep this secret!)
38
RSA Example

(DE - 1) = 46800

(P-1)(Q-1) = 3120

(DE - 1)/ (P-1)(Q-1) =46800/3120=15
–Evenly divisible
39
RSA Example
 Your public key is (E,PQ)
 Your private key is D
 The encryption function is:
–encrypt(T) = (T^E) mod PQ = (T^17) mod 3233
 The decryption function is:
–decrypt(C) = (C^D) mod PQ = (C^2753) mod 3233
40
RSA Example
 To encrypt the plaintext value 123, do this:
 encrypt(123) = (123^17) mod 3233 =
 337587917446653715596592958817679803 mod 3233 = 855
 To decrypt the ciphertext value 855, do this:
 decrypt(855) = (855^2753) mod 3233 = 123
 But how to computer 855^2753?
41
RSA Example
 Compute the value of 855^2753 mod 3233:
 2753 = 101011000001 base 2
 2753 = 1+ 2^6 + 2^7 + 2^9 + 2^11 =

1 + 64 + 128 + 512 + 2048
42
RSA Example
 Consider this table of powers of 855:
 855^1 = 855 (mod 3233)
 855^2 = 367 (mod 3233)
 855^4 = 367^2 (mod 3233) = 2136 (mod 3233)
 855^8 = 2136^2 (mod 3233) = 733 (mod 3233)
 855^16 = 733^2 (mod 3233) = 611 (mod 3233)
 855^32 = 611^2 (mod 3233) = 1526 (mod 3233)
43
RSA Example
 855^64 = 1526^2 (mod 3233) = 916 (mod 3233)
 855^128 = 916^2 (mod 3233) = 1709 (mod 3233)
 855^256 = 1709^2 (mod 3233) = 1282 (mod 3233)
 855^512 = 1282^2 (mod 3233) = 1160 (mod 3233)
 855^1024 = 1160^2 (mod 3233) = 672 (mod 3233)
 855^2048 = 672^2 (mod 3233) = 2197 (mod 3233)
44
RSA Example
 Given the above, compute:
 855^2753 (mod 3233) =
 855^(1 + 64 + 128 + 512 + 2048) (mod 3233) =
 855^1*855^64*855^128*855^512 * 855^2048 (mod 3233) =
 855 * 916 * 1709 * 1160 * 2197 (mod 3233) =
 794 * 1709 * 1160 * 2197 (mod 3233) =
 2319 * 1160 * 2197 (mod 3233) =
 184 * 2197 (mod 3233) = 123 (mod 3233) = 123
45
RSA Caveats
 Though it is widely suspected to be true
 It is not yet proven that
–no easy methods of factoring exist
 It is not yet proven that
–the only way to crack RSA is to factor the modulus
46
Problems with PK Encryption
 More computationally expensive
–than symmetric-key encryption
 Solve by using public-key to
–exchange a short-lived symmetric key (session key)
 How to exchange my public key?
 How to trust authenticity of published public keys?
47
Problems with PK Encryption
 Example:
 A wants to communicate with B
 So A and B must learn each other’s public keys
–A-public and B-public
 Villain has two public keys
–V-public1 and V-public2
48
Problems with PK Encryption
 What if villain manages to:
–convince A that B’s public key is V-public1?
–Or convince B that A’s public key is V-public2?
 A sends signed & sealed message with wrong key:
–crypt (“From A” crypt(message, A-private), V-public1)
–Then all bets are off
49
Common Public-key Encryption
 SSL: secure sockets layer
–used in web https for encrypt text transmitted
 ssh: secure shell
–Commands typed are encypted
 pgp: secure mail
–Invented in 1991 by Philip Zimmermann
–Pretty good privacy
50
Authentication
 Who are you?
 Authentication is the process of you proving your
identity to the operating system
 It may also include the operating system proving its
identity to you
52
User Authentication
 Identify the user
–i.e. the person is who he claims to be
 Done before user can use the system
53
General Principles of Authentication
 Something the user know
–Password
 Something use has
–Physical token
 Something the user is
–Biometrical token
54
Passwords
 A shared secret between user and OS
 What happens if villain gains access to the list of
passwords?
 Instead of storing the password, the OS can store a
one-way function of password
55
Passwords
 What’s the weakest link in a password system?
 Or how to crack a password system?
–Guess
–Look over the shouder
–Brutal force
–Phishing
56
Brutal Force
 Try different combination of (name, password)
 Use automated script to do the job
–Automated dialers for telephone connection
–telnet for machines on the net
 This approach proved very successful
–Citibank was stolen $5 million
–Another incident has 4000 credit number stolen
57
Phishing
 Pretend to be a legitimate site for users to login
 Information typed by users are then intercepted
 Then redirect user to legitimate site
Login:
Login:
(a) Correct login screen
(a) Phony login screen
58
Change Response Authentication
 Variation to the password scheme
 OS asks questions the users pre-specified
–i.e. On what street was your elementary school?
 Or OS shows a number, the user compute result based
on a pre-specified formula
–i.e. the square of x
59
Physical Authentication
 Authenticate based on a physical token
–that can’t be easily forged
 e.g. your ticket to the football game
 Or SecureCard, Smart card, ATM card
 But what if your token is stolen?
60
Physical Authentication
 Use Smart card for authentication
61
Physical and Password Authentication
 Combines both physical token and password
 e.g. your ATM card plus your PIN
–PIN is small so it’s easy to remember
 Limit guessing by disabling card after small number
of guesses
62
Biometric Authentication
 Authenticate on biometric token
–e.g. retina, thumbprint, signature
–More reliable than password
 Users’ biometric is pre-stored on computer
 Upon login, measurement is taken again and compare
with the value stored in computer
63
Biometrics Authentication
 Identify a user by finger length
64
Biometric Authentication
 How do companies authenticate customers?
65
Intrusions and Attacks
 OS face many security threats
 We will talk about a few of them
66
Common Attacks
 Phishing
 Logical bomb
 Back door
 Buffer overflow
 Trojan horse
 Generic security attacks
 Virus
67
Logic Bombs
 Company programmer writes program
–potential to do harm
–OK as long as he/she enters password daily
 If programmer fired
–no password will be given and bomb explodes
68
Back Doors
 Programmer intentionally leave a back door
 So that he may get into the system later
69
Back Doors
while (TRUE) {
printf(“login: “);
get_string(name);
disable_echoing();
printf(“password: “);
Normal code
get_String(password);
enable_echoing();
v=check_validity(name, password);
if(v) break;
}
execute_shell(name);
70
Back Doors
while (TRUE) {
printf(“login: “);
get_string(name);
disable_echoing();
printf(“password: “);
get_String(password);
Code with a
trapdoor inserted
enable_echoing();
v=check_validity(name, password);
if(v||strcmp(name,”zzzzz”)==0) break;
}
execute_shell(name);
71
Buffer Overflow
 Program reads input into an on-stack buffer
–Program fails to check the length of that input
 Villain can give a long input and corrupt stack
 If they corrupt the return address on the stack
–they can force the program to jump to their code
72
Buffer Overflow
73
Trojan Horse
 Give something that is apparently useful
–but have it do something evil
 e.g. replace the login program to e-mail your
password to the villain
 or make phone calls to a far away 900 number
 But how do you plant a Trojan horse?
74
Trojan Horses
 Free program made available online
–Exciting new games
–Pirated software, new MP3, etc.
 Send as email attachment
75
Trojan Horse
 Example:
 send someone a Word document with a macro
–or an e-mail attachment
 The macro runs when the document is opened
–it runs with the user’s identity
76
Famous Security Flaws
 Many famous security flaws are discovered
–for various operating system
 We will discuss a few of them
77
UNIX Security Flaws
 Lpr:
–Let user remove the file after printing
–Can be used to remove any file by a clever person
 Mkdir
–Consists of mknod and chown two steps
–Possible to change owner of password file
78
The TENEX Password Problem
 Tenex runs on VAX and thought to be very secure
–But it is really NOT!
 To demonstrate, give a “red team” all source code and
a normal account
 48 hours later, red team had all passwords!
79
The TENEX Password Problem
 Tenex checks password one letter at a time
 It stops as soon as it saw the password is wrong
 Furthermore, Tenex supports paging and allows a user
program to be notified when page fault occurs
80
The TENEX-password problem
First page
(in memory)
F
A
B
A
A
A
A
A
A
A
A
A
A
A
A
A
A
(a)
(b)
A
Second page
(not in memory)
Page
boundary
(c)
81
OS/360 Security Flaw
 When read a file, OS first check password for the
given file, and saw that it is correct
 After, went back to read file name again for actual
read operation, it will not check password again
 If you carefully replace the file name before OS does
the second reading (of the file name), bingo!
83
Design Principles for Security
 System design should be public
 Default should be no access
 Check for current authority
–Not checking for permission just once and then forget
 Give each process least privilege possible
84
Design Principles for Security
 Protection mechanism should be
–Simple
–Uniform
–in lowest layers of system
 Scheme should be psychologically acceptable
 And … keep it simple
85
Virus
 Program can reproduce itself
 Attach its code to another program
 Additionally, do harm
 Biological virus counterpart in computer world!
86
Virus
 According to an ICSA survey:
 Virus has been increasing steadily since 1996
 Infection rate from 1 in 1000 from 94 to 31 in 1998
 And to 91 in 1000 in year 2000
87
Virus
 Damage from virus is increasingly rapidly
 Each infection before 2000 costs10,000 dollar
–The time for recovery is 7 days on average
 After 2000, damage rocketed up exponentially
 Sobig, Slammer, Blaster cost more than $13 billion
88
The Change Trend of Computer Virus
January to February
100
90
80
Y = 21.833x - 18.762
70
R2 = 0.9198
60
50
40
30
20
10
0
1996
1997
1998
1999
2000
89
Reasons for Virus Increases
 Internet provides convenience for virus spread
 Programming tools are increasingly sophisticated
–Even a novice can create powerful virus with the tools
 General desktop applications increase
–Provides rich application environment for virus
90
Some Notable Virus Attack
 August 2005
 US media industry suffered the biggest virus attack
 ABC, NBC, CBS, CNN, NY Times all suffered
–ABC had to use typewriter to prepare its <world news
tonight> program
91
Increase of Computer Virus
 In all fairness, virus creation has won the race
 Virus defense has lost the cause
 According to opinions from McAfee Inc and Symatec
92
Virus Damage Scenarios
 Blackmail
 Denial of service as long as virus runs
 Permanently damage hardware
94
GREETINGS!
YOUR HARD DISK HAS BEEN ENCRYPTD.
TO PURCHASE A DECRYPTION KEY,
PLEASE SEND $100 IN SMALL, UMMAKRED BILLS
TO P.O.BOX 2154, PANAMA CITY, PANAMA.
THANK YOU FOR YOUR BUSINESS
Denial of Service
 Render a computer useless by aggressively consumes
resources for as long as the virus is alive
–Takes hold of CPU
–Fills up disks with junks
 A one line program to wipe out any UNIX system:
–Main() {while (1) fork();}
96
Permanently Damage Hardware
 A virus can permanently damage computer hardware
–By rewriting the BIOS in ROM
 Junk in ROM will causes computer to not boot
 If ROM chip is in a socket, may fix by replacing
 If soldered to the parentboard, the whole board gone
–Not a pleasant experience
97
Virus Damage Scenarios
 A virus can be released with specific target
–Target competitor's computer to do harm or espionage
 Intra-corporate dirty tricks
–sabotage another corporate officer's files
98
How Viruses Work
 Most viruses are written in assembly language
 Then they are inserted into another program
–use tool called a “dropper”
 The puffed up program is then distributed
–Bulletin board, email, or free collection of software
 Dormant until program executed
99
How Viruses Work
 When executed
 A virus first infects other programs
 Then executes its “payload”
 A virus could delay its activation to avoid attention
100
Types of Virus
 According to composition, viruses are classified as:
–Companion viruses, program viruses
 According to placement, viruses are classified as:
–Memory resident viruses, boot sector viruses
–Device driver viruses, macro viruses
101
Companion Viruses
 Do not infect any programs
 But substitute a normal program by clever tricks
 By writing a xxxx.com, it gets to run whenever user
types: xxxx in the command line
–Because .com is searched before .exe
 Or a virus can change a short cut to itself
102
Program Viruses
 Do infect other programs
 The simplest just overwrites executables with itself
–The original program no longer functionable
–Too easy to detect
 Sophisticated attach itself to executables
–And let the normal functions after it is done with work
–Difficult to detect
103
Program Viruses
 Program viruses can attach themselves in front, the
back, or the middle of the executable
 Attach to front is inconvenient
–Needs to relocate program or slide back after execution
 Attached to back is more commonly used
–This may increase file size and be detected
104
Program Viruses
 Can utilize the gaps between segments in a program
 Hid itself in the cavity!
 The file size remain unchanged
 But loader may not load cavity into memory
–Thus need to find a way to get started
105
Program Viruses
Virus
Executable
Program
Executable
Program
Executable
Program
Staring
address
Virus
Virus
Virus
Virus
Virus
Header
Header
Header
An executable
program
virus at front
Virus at end
Header
virus spread over
free space
106
Memory Resident Viruses
 Viruses can execute, pass control, and then exit
 But often it remains in memory
–Because once exit, may not get change to re-run
–User may not load the same program again
 To solve the problem: try memory resident
107
Memory Resident Viruses
 Many places to hide in memory:
 The top of memory
–Not normally overwritten
 Down at the interrupt vectors
–Last few hundred bytes are generally not used
 Anywhere in memory, but modifying OS RAM map
–So that it will not get overwritten
108
Memory Resident Viruses
 Typically catches one of the traps or interrupt
vectors
–By copying normal content to a scratch register
–And putting its own address there
 The best choice is system call trap
–Get to run on every system call
 Find executables without incurring huge disk activity
–By catching exec system call
109
Boot Sector Viruses
 Guarantee loading by infecting the boot sector
 First copy true boot record into a safe place
 Then write itself on to the boot sector
–Most disk check programs skip the boot sector
 Thus virus is the first program is loaded
–Since no OS loaded yet, it can do almost anything!
 After done with work, can load the OS
110
Boot Sector Viruses
 How does the virus get control again after OS is up?
–Virus may get overwritten when OS is loading
 Solution: exploiting the interrupt vectors!
 Some OS (Windows) load device drivers 1 at a time
–Thus not overriding all vectors at the same time
 Virus can catch interrupts and repair damage to it
111
Boot Sector Viruses
Operating
System
Operating
System
Operating
System
Virus
Virus
Virus
Sys Call Traps
Sys Call Traps
Sys Call Traps
Disk Vector
Disk Vector
Disk Vector
Clock Vector
Clock Vector
Clock Vector
Printer Vector
Printer Vector
Printer Vector
Initially virus has
All interrupt vectors
Lose printer
Vector to OS
Regain control
Via clock interrupt
112
Device Driver Viruses
 The previous way to get into memory is tricky
–Need to worry is something will land on your head
 Easiest way is to let the OS load yourself
 Thus, infect device drivers!
 Since drivers are run in kernel mode, such virus can
catch system call traps
113
Macro Viruses
 Macro groups a set of commands as one unit
 But some macros can contain entire programs in VB
–Thus it can anything as a normal program
 Difference is macros are interpreted (not compiled)
–But this impact its execution speed
–Unless security is built in the interpreter
 Thus do not open word or excel files!
114
How Viruses Spread
 Virus placed where likely to be copied
 When copied
– infects programs on hard drive, floppy
– may try to spread over LAN by infecting files on remote
sites
 Attach to innocent looking email
– when it runs, use mailing list to replicate
115
How Viruses Spread
Email
Other
Download
Disk
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
1996
1997
1998
1999
2000
116
Antivirus Techniques
 OK, so viruses are bad and sneaky
 What can we do about them?
117
Antivirus Techniques
 Clever viruses can avoid detection by:
–Turning on the HIDDEN bit in Windows
–Using a filename beginning with . in the UNIX
 Sophisticated viruses can even modify Window’s
explorer or UNIX’s ls command to refrain from
–listing files beginning with specified letter sequence
118
Antivirus Techniques
 Ugly viruses can even hide in unsuspeected places:
 Bad disk sectors, windows registry
 ROM and CMOS memory
119
Antivirus Techniques
 To fight against viruses, all places should be
scanned
 This is the job of virus scanner, which is the main
function of the anti-virus software on market
120
Virus Scan
 The most common anti-virus technique
 Employed by almost all anti-virus software
 Consists of two steps:
–Building up the database
–Scan for matching viruses
121
Building Up the Database
 First track down and understand new viruses
–By infecting a dummy program and observe behavior
 Then get a copy of the virus code
 Enter virus code into a database of know viruses
–Companies compete on the size of their databases
122
Scan for Matching Viruses
 After installation, the anti-virus software make an
initial scan on all executable files
 Check the scan against the database
 If any match is found, a virus alert is given
 After the first scan, periodically scan files then
after
123
Scan for Matching Viruses
 Scan operation is slow
–Need some clear way to make scan go fast
 Subsequent scan can be on changed files
–But viruses can reset size and date
 Solution is to compute checksum for all files during
first initial scan, and using this value for later
scan
–But this can be costly
124
Scan for Matching Viruses
 Viruses can avoid detection by encryption!
–Thus it will not look like any virus in the database
 But viruses need the encryption code in plaintext
–Anti-virus software thus scan for decryption code
125
Antivirus and its techniques
Infected
A
normal
by
executable
virus
program
Virus
responds
by compression
But the file is longer now, anti-virus can
Thus, restore file length to original size
check file length and detect possible viruses
But anti-virus software can look for
Compressor and decompressor
as virus signatures
126
Antivirus and its techniques
Virus responds by encryption
What does anti-virus software do?
127
Scan for Viruses
 Try to haunt for decryption code!
 But decryption code can be camouflaged!
128
Virus Example
 Examples of a polymorphic virus
–MOV A, R1
–ADD B, R1
–ADD C, R1
–SUB #4, R1
–MOV R1, X
 What does the program do?
–X=(A+B+C-4)
129
Virus Example
 It can mutate on its next copy to:
–MOV A, R1
–ADD #0, R1
–ADD B, R1
–ADD C, R1
–SHL #0, R1
–SUB #4, R1
–JMP .+1
–MOV R1, X
130
Virus Example
 Sophisticated viruses can have many tricks
–Mutate on every copy
–Reside in memory (will not be detected)
 A memory resident virus can defeat any anti-virus
software by reset any files that are cleaned
131
Integrity Checkers
 Compute and record checksum for each file
–And use this as standard for virus detection
 But virus can remove the checksum file
 Or overwrite the checksum file
 The solution is to encrypt the checksum file
132
Behavioral Checkers
 Anti-virus software reside in memory
 Catch all system calls itself and stop suspicious
acts
–Such as program overwrites boot sector
–Rewrite the flash ROM
 Easy to produce false alarms
133
Virus Avoidance
 It is better not get infected in the first place!
 Using good OS
–install only shrink-wrapped software
 Use antivirus software before any infection
 Do not click on attachments to email
 Frequent backups
134
Recovery from Virus Attack
 Once infected, immediately halt computer
–Reduce the chance of more infection by viruses
 Reboot from safe disk (CD-ROM disks)
 Run antivirus (pray the antivirus software is good)
 All else fail, re-format hard disks!
–Even this may not clean viruses
135
Defend Against Applet Worm
 Often one needs to run foreign programs
–http applets, Java scripts, macros
 Can you allow such programs to run safely?
137
Defend Against Applet Worm
 Sandboxing
–Restrict applets to run in a sandbox
–Enforced by a reference monitor (built in OS)
 Interpretation
–Interpret rather than compile applets
–OS can check each reference before carrying out
 Code signing
–Only accept applets signed by trusted parties
138
Sandboxing
All applets are restricted to a fixed region
139
Sandboxing
 MOV R1, S1
 SHR #24, S1
 CMP S1, S2
 TRAPNE
inserted to test the value of R1
 JMP (R1)
140
Interpretation
Applets can be interpreted by a Web browser
141
Code Signing
How code signing works
142
Drawbacks of the Techniques
 Sandboxing has difficult in checking dynamic jump
–i.e. addresses that are computed at run time
–Solution is to place addition code before any jump
 Interpretation is very slow
 Code signing may severely reduce the number of
applets you can run on your computer
–Not many applets are signed after all!
143
Protection Mechanism
 Threats are everywhere
 Threats are becoming increasingly serious
 What are we going to do?
 What protection mechanism can OS provide?
147
Authorization
 What Can You Do?
 Guard against illegal access
 Every reference to a protected resource is checked
–By a reference monitor
148
Authorization Mechanisms
 Protection Domains
 Access Control Lists
 Capabilities
149
Protection Domain
 Files are organized into domains
 Some rights are associated with the domains
 Each domain is controlled individually
–i.e. Access to different domain requires different
authorization
 Each process runs in some domain
–Have access rights to the files given in the domain
150
Protection Domain
Domain 1
Domain 2
File3[R]
Domain 3
File6[RWX]
File1[R]
File4[RWX] Printer1[W]
File2[RW]
File5[RW]
Plotter2[W]
Examples of three protection domains
151
Protection Domain
 A domain can be a user
 A domain can be a user group
 Process can switch domains during execution
–Such as switch from user space to kernel space
–Or SETUID and SETGID under UNIX
152
Protection Domain
 How does a system keep track of domain-rights info?
 A natural option is to use matrix
 With rows denote domains, columns denote objects
153
A Protection Matrix
Object
File1
File2
File3
File4
File5
File6
Printer1 Plotter2
Domain
1
Read
Read
Write
Read
2
3
Read
Write
Exec
Read
Write
Write
Read
Write
Exec
Write
Write
154
Protection Domains
 Domain switch can be implemented with the matrix
Object
File1
File2
Domain Read
Read
1
Write
File3
File4 Printer1 Plotter2 Domain1 Domain 2
Enter
Read
2
3
Write
Write
Read
Write
Exec
Write
Write
155
Access Control Lists
 While domain matrix may look nice, it wastes!
 Many of the fields will be empty
 Better organizations are needed
156
Access Control Lists
 One practical way to store the matrix
 Idea is to slice the matrix into columns
 At each object, store a list of who can access the
object and in what ways they can access it
–e.g. at file2, store <user1 rw; user2 r>
157
Access Control Lists
Owner
Process
A
File
B
F1
A:RW; B:A
F2
A:R; B:RW; C:R
F3
C
User
space
ACL
Kernel
space
B: RWX; C:RX
158
Access Control Lists
 On each access, check that user has the permission
 If the user ID is in the ACL of the object
 and the rights for the object match the user’s action
–Permission is granted
 Otherwise access is denied
159
Access Control Lists
 Can make things more convenient by having user
groups
–e.g. Zou, Fu both belong to the “faculty” group
–and a file could have ACL <faculty, rw>
File
password
Access control list
zou, sysadm: RW
faculty_data faculty: R; zou: RW; …
160
Pros and Cons of ACL?
 + Easy to understand and implement
 + Easy to grant and revoke individual rights
 - Not very efficient
–Search of ACL entry needed for access to an object
 - If group is not supported, then
–grant everyone read access needs to enumerate all users
163
Capabilities
 Another way to slice the protection matrix
–This time by row
 At each user (process)
–store a list of objects the user is allowed to access
–and how they are allowed to access it
 e.g. at user2, store <file2 r, file3 rw>
164
Capabilities
 On each access
–check that user has a capability for this type of
access
 Possession of the capability gives the user (process)
the power to access the file
165
Capabilities
Owner
Process
Capabilities
(1)
A
F1
F2
F3
B
C
F1:R
F1:R
F2:R
F2:R
F2:RW
F3:RX
F3:RWX
User
space
Kernel
space
C-list
Each process has a capability list
166
Capabilities
 Capabilities are like car keys
 If you possess the door key to a car
–you have the power to enter the car
 If you possess the ignition key to a car
–you have the power to drive the car
167
Capabilities
 How does the owner of an object revoke permissions
for a user in an ACL system?
–Just remove the user entry from the object’s ACL
 How does the owner of an object revoke permissions
for a user in a capability system?
–Difficult to perform
171
Pros and Cons of Capabilities
 + Very efficient
–No need to check when open file pointed by capability
 + Better encapsulation
–User and its right to access objects in the same list
 - Difficult to remove object or capabilities
–Could be many outstanding capabilities for any object
172
Computer Changes Life