Transcript Review: Operating Systems - Nipissing University Word

COSC4607 - Computer
Security
Dr. Haibin Zhu
Assistant Professor
Department of CS and Math, Nipissing University
Room: A124A, Ext.: 4434
Email: [email protected]
URL: http://www.nipissingu.ca/faculty/haibinz
Office Hour: Mon. & Thurs. 2:30pm-4:30pm; or by
appointment
1
Learning Outcomes
On completion of this course you will be able to:
•
•
•
•
•
•
2
Understand a number of basic design principles in computer
security.
Demonstrate an understanding of the importance of security
models with reference to the security of computer systems.
Describe the features and security mechanisms which are
generally used to implement security policies.
Provide examples of the implementation of such features and
mechanisms within a number of particular operating systems.
Display a breadth of knowledge of the security vulnerabilities
affecting computer systems.
Demonstrate an understanding of the main issues relating to
Web security in the context of computer systems.
Schedule
1. Introduction to Computer Security
2. Access Control
3. Security Models
4. Security Mechanisms
5. Linux / Unix Security
6. Windows 2000 Security
7. Computer Virus
8. Software Security
9. Security of Distributed Systems
10. Network Security
11. Cryptography
3
Resources
Notes
Lecturers
Books
The Internet
… and
YOU and YOUR FELLOW
STUDENTS
4
Books
•Textbooks:
•D. Gollmann, Computer Security, John Wiley & Sons, 1999.
•References:
•C.P. Pfleeger, Security in Computing, Prentice-Hall, 1997
(2nd Ed).
•R. Anderson, Security Engineering, Wiley, 2001.
•B. Schneier, Secrets and Lies, Wiley, 2000.
John Viega & Gary McGraw: Building Secure Software,
Addison Wesley, 2001
5
Course Information
http://www.nipissingu.ca/faculty/haibinz
6
Questions ?
7
Review: Operating Systems (1)
•
8
It is useful to have some basic understanding of what an
Operating System is and what it does.
•
An Operating System is an application that “sits”
between users and applications and the computer
hardware. Essentially, it provides a moderately friendly
interface to the hardware.
•
Because computers “think binary” then they are
extremely user-unfriendly! The Operating System
removes some of the pain!
Review: Operating Systems (2)
User
Application
Program
Operating
System
Hardware
9
Review: Operating Systems (3)
A more common version of the previous diagram is given
below:
User
Graphical User
Interface (GUI)
Application
Program
System Services
Operating
System
10
Command
Interpreter
Review: Operating Systems (4)
• The “System Services” layer is the real interface to the Operating
System. It consists of many functions designed to translate an
application request into something the Operating System can handle.
• POSIX is becoming the standard for System Services, mainly driven by
the need to make it easier to port an application from one Operating
System to another.
• So, what does an Operating System actually do?
• The primary functions of an Operating System are given on the next
slide.
• Note that an Operating System must perform all its tasks efficiently and
economically. Resource use by the system, in terms of CPU time,
memory and disk usage must all be acceptable for the users.
11
Review: Operating Systems (5)
•
•
•
•
•
•
•
12
Starting and stopping programs and sharing the CPU between
them
Managing memory:
•
Memory allocation; keeping track of memory usage
Input and Output:
•
Device drivers; “concurrent” handling of I/O devices
File management
Protection (preventing different programs from interfering with
each other – “firewalling”)
Networking (“seamless” communication with other devices)
Error handling (detection, recovery, warning)
Review: Operating Systems (6)
System Service Interface
File
Manager
Process
Manager
I/O Manager
Memory
Manager
Network
Manager
Hardware Interface
13
Security Problems
 Security
and reliability
 Buffer overflows
 Arrays and integers
 Canonical representations
 Race conditions
 Precautions & defences
 Dangers of abstraction
14
Security & Reliability
 On
a PC, you are in control of the software
components sending inputs to each other
 On the Internet, hostile parties can provide input
 To make software more reliable, it is tested
against typical usage patterns: ‘it does not
matter how many bugs there are, it matters how
often they are triggered’
 To make software more secure, it has to be
tested against ‘untypical’ usage patterns (but
there are typical attack patterns)
15
Secure Software
 Software
is secure if it can handle intentionally
malformed input; the attacker picks (the
probability distribution of) the inputs
 Secure software: protect the integrity of the
runtime system
 Secure software ≠ software with security features
 Networking software is a popular target
 intended to receive external input
 involves low level manipulations of buffers
16
Preliminaries
 In
code written in a typical programming language
values are stored in variables, arrays, etc.
 To execute a program, memory sections
(‘buffers’) have to be allocated to variables, etc.
 In programming languages like C or C++ the
programmer allocates and de-allocates memory
 Type-safe languages like Java guarantee that
memory management is ‘error-free’
17
Buffer overflows
 If
the value assigned to a variable exceeds the
size of the buffer allocated to this variable,
memory locations not allocated to this variable
are overwritten
 If the memory location overwritten had been
allocated to some other variable, the value of
that other variable can be changed
 Depending on circumstances, an attacker could
change the value of a protected variable A by
assigning a deliberately malformed value to
some other variable B
18
Buffer overflows
 Unintentional
buffer overflows can make
software crash
 Intentional buffer overflows are a concern if an
attacker can modify security relevant data
 Attractive targets are return address (specifies
the next piece of code to be executed) and
security settings
 In safe languages such errors cannot occur
19
Stack & heap
stack
 Stack:
contains return address,
local variables and function
arguments; it is quite predictable
where a particular buffer will be
placed on the stack
 Heap: dynamically allocated
memory; it is more difficult but
by no means impossible to
predict where a particular buffer
will be placed on the heap
FFFF
memory
0000
heap
20
Stack overflows
Find a buffer on the runtime stack of a
privileged program that can overflow the
return address
 Overwrite the return address with the start
address of the code you want to execute
 Your code is now privileged too

return
address
buffer for
variable A
21
write to A:
value1|
value2|
my_address
my_address
value2
value1
Precautions
 Be
sparing with privileges: if the code attacked
runs with few privileges, the damage is limited
 If feasible, use a type-safe language
 In C and C++ avoid dangerous instructions like
gets() and use instructions like fgets() where the
length of the argument has to be specified;
extensive lists of ‘good’ and ‘bad’ instructions
exist
 Non-executable stack: stack cannot be used to
store attack code
22
Defences
 Canaries:
(random) check values placed before
the return address (StackGuard)
 Before returning, check that the canary still has
the correct value
return
address
canary
buffer for
variable A
23
write to A:
check value
value1|
value2|
my_address
to A
my_address
value2 ≠ check value
value1
attack
detected
Heap overflows
 More
difficult to determine how to overwrite a
specific buffer
 More difficult to determine which other buffers
will be overwritten in the process; if you are an
attacker, you may not want to crash the system
before you have taken over
 Attacks that do not succeed all the time are a
threat
 Heap overflow attacks have started to occur
24
Integers
 Mathematics:
integers form an infinite set
 Programming languages: signed 4-byte integers,
unsigned 4-byte integers, long integers,…
 Truncation (Unix example): input UID as signed
integer, value ≠ 0?, truncate to unsigned short
integer: 0x10000  0x0000 (root!)
 Different interpretation of signed and unsigned
integers: (signed) -1 = 0xFFFF = 216-1 (unsigned)
25
Integers
 Addition:
0xFF00 + 0x0100 = 0x0000: base +
offset < base
 Of course, the runtime may raise an exception
when an overflow occurs on addition
 Ashcraft & Engler [IEEE S&P 2002]: “Many
programmers appear to view integers as having
arbitrary precision, rather than being fixed-sized
quantities operated on with modulo arithmetic.”
26
Arrays
overflow: the
length of an array is not
checked when elements
are written to the buffer
 Wrap-around to lower
addresses: when
arithmetic operations do
not have the result
expected by the
programmer
allocate
4 elements
assign
5 elements
base
base
 Buffer
27
base
Scripting
In scripting languages, executables can be
passed as arguments
 Escape characters indicate that an argument
is an executable
 ‘Unescaping’ (making input non-executable)
can protect code from malicious input
 Filters for escape characters have to know
the escape characters and the character set
in use [CA-2000-2]

28
Canonical
Representations
 File
names, URLs, IP addresses, … can be
written in more than one way
 Directory traversal: c:\x\data = c:\y\z\..\..\x\data =
c:\y\z\%2e%2e\%2e%2e\x\data
 Dotless IP: a.b.c.d  a224 + b216 + c28 + d
 Symbolic link: file name pointing to another file
 Canonicalization computes the standard
representation
 When access right depends on location, you
better get the location right; do not rely on the
names received as input
29
Race conditions
 Multiple
computations access shared data in a
way that their results depend on the sequence of
accesses
 Multiple
processes accessing the same variable
 Multiple threads in multi-threaded processes (as in
Java servlets)
 An
attacker can try to change a value after it has
been checked but before it is being used
 TOCTTOU (time-to-check-to-time-of-use) is a
well-known security issue
30
Example – CTSS
(1960s)
 Once
the message of the day was the password
file
 Every user had a unique home directory; when a
user invoked the editor, a scratch file with fixed
name SCRATCH was created in this directory
 Several users working as system manager:
 system manager one starts to edit message
of the day:
SCRATCH  MESS
 system manager two starts to edit the
password file:
SCRATCH  PWD
 system manager two stores the edited file:
MESS  PWD
31
Defences – Code
inspection
 Code
inspection is tedious: we need automation
 K. Ashcroft & D. Engler: Using ProgrammerWritten Compiler Extensions to Catch Security
Holes, IEEE S&P 2002
 Meta-compilation for C source code; ‘expert
system’ incorporating rules for known issues:
untrustworthy sources  sanitizing checks 
trust sinks; raises alarm if untrustworthy input
gets to sink without proper checks
 Code analysis to learn new design rules: Where
is the sink that belongs to the check we see?
 Applied to Linux and OpenBSD kernels
32
Defences – Black-box
testing
 Black-box
testing when source code is not
available
 You do not need the source code to observe
how memory is used or to test whether inputs
are properly checked
 Oulu University Secure Programming Group:
PROTOS project (Juha Röning,
http://www.ee.oulu.fi/research/ouspg/)
 Syntax testing of protocols based on formal
interface specification, valid cases, anomalies
 Applied to SNMP implementations
33
Defences – Type-safety
 Type
safety: guarantees absence of untrapped
errors
 Cardelli: Practitioners who invented type safety
often meant just “memory integrity”, while
theoreticians always meant “execution integrity”,
and it’s the latter that seems more relevant now.
 A language does not have to be typed to be
safe: LISP
 Safety guaranteed by static checks and by
runtime checks
34
Type-safety
 Marketing
ploy: “We are type safe, therefore we
are secure”
 Type safety is difficult to prove completely
 Proofs are conducted in an abstract model,
problems may hide in the actual implementation
(e.g. SUN Security Bulletin #00218)
 PROTOS: Also software in Java were shown to
have buffer overflows in native code sections
 Type safety is a useful property to have for
security but type safety does not imply security
35
Keeping up-to-date
 Sources
of information: CERT advisories, BugTraq
at www.securityfocus.com, security bulletins from
software vendors
 Hacking tools have attack scripts that automatically
search for and exploit known type of vulnerabilities
 Analysis tools following the same ideas will cover
most real attacks
 Patching vulnerable systems in not easy: you have
to get the patches to the users and avoid
introducing new vulnerabilities through the patches
36
number of intrusions
Intrusion patterns
disclosure
attack scripts released
Time
patch
released
W. Arbaugh, B. Fithen, J. McHugh: Windows of Vulnerability:
A Case Study Analysis, IEEE Computer, 12/2000
37
The wider picture
 We
could treat all these problems individually
and look for specific solutions, often limited to a
given programming language or runtime system
(penetrate-and-patch at a meta-level)
 Overall, a general pattern: familiar programming
abstractions
 variable, array, integer, data & program,
address (resource locator), atomic
transaction, …
 are
implemented in a way that can break the
abstraction
38
Summary of Security
Problems
 Many
of the problems listed may look trivial
 There is no silver bullet
 Code-inspection:
better at catching known problems,
may raise false alarms
 Black-box testing: better at catching known problems
 Type safety: guarantees from an abstract (partial)
model need not carry over to the real system
 Experience
in high-level programming
languages may be a disadvantage when writing
low level network routines
39
Introduction to Computer
Security
 Security
objectives
 Security strategies
 Distributed systems security =
computer & communications security
 Aspects of computer security
 Fundamental design principles for
 computer security
40
Security objectives
 Confidentiality:
prevent unauthorized
disclosure of information
 Integrity: prevent unauthorized modification of
Information
 Availability: prevent unauthorized withholding
of information or resources
 Other aspects: accountability, authenticity
41
Confidentiality
 Historically,
security and secrecy were
closely related; sometimes, security
and confidentiality are used as
synonyms
 Prevent
unauthorized disclosure of
information (prevent unauthorized reading)
Privacy: protection of personal data
 Secrecy: protection of data belonging
to an organization

42
Integrity
 ITSEC
Definition: The property that prevents
unauthorized modification of information
(prevent unauthorized writing)
 Orange Book (US Trusted Computer Systems
Evaluation Criteria):
 Data
Integrity - The state that exists when
computerized data is the same as that in the
source document and has not been exposed to
accidental or malicious alteration or destruction
(integrity synonymous for external consistency)
 In
communications: detection and correction
of intentional and accidental modifications of
transmitted data
43
Availability
IS 7498-2 ( Basic Reference Model for Open
Systems Interconnection (OSI) Part 2:
Security Architecture): The property of being
accessible and usable upon demand by an
authorized entity
 Denial of Service (DoS): The prevention of
authorized access of resources or the
delaying of time-critical operations
 Distributed denial of service (DDoS) is
receiving a lot of attention and systems are
now designed to be more resilient against
these attacks

44
Accountability
 Audit
information must be selectively
kept and protected so that actions
affecting security can be traced to the
responsible party.
45
Dependability
 The
property of a computer system
such that reliance can justifiably be
placed on the service it delivers. Here,
the service delivered by a system is its
behavior as it is perceived by its users;
a user is another system which
interacts with the former.
46
A Remark on Terminology


Definition: Computer security deals with the
prevention and detection of unauthorized actions by
users of a computer system.
There is no single definition of security



Resources:



47
When reading a document, be careful not to confuse your
own notion of security with that used in the document
A lot of time is being spent - and wasted – trying to define
an unambiguous notation for security
http://www.radium.ncsc.mil/tpep/process/faq.html
http://www.cesg.gov.uk/assurance/iacs/itsec/index.htm
ftp://ftp.cse-cst.gc.ca/pub/criteria/CTCPEC
Security strategies
 Prevention:
take measures that prevent
your assets from being damaged
 Detection: take measures so that you
can detect when, how, and by whom an
asset has been damaged
 Reaction: take measures so that you
can recover your assets or to recover
from a damage to your assets
48
Example 1– Private Property
Prevention: locks at doors, window bars,
walls round the property
 Detection: stolen items are missing, burglar
alarms, closed circuit (cable) TV
 Reaction: call the police, replace stolen
items, make an insurance claim …
 Footnote: Parallels to the physical world can
illustrate aspects of computer security but
they can also be misleading

49
Example 2 – E-Commerce
 Prevention:
encrypt your orders, rely on
the merchant to perform checks on the
caller, don’t use the Internet (?) …
 Detection: an unauthorized transaction
appears on your credit card statement
 Reaction: complain, request new card
number, etc.
50
Security Policies
Organizational security policy: Laws, rules,
and practices that regulate how an
organization manages and protects
resources to achieve its security policy
objectives.
 Automated security policy: Restrictions and
properties that specify how a computing
system prevents violations of the
organizational security policy.

 D.
F. Sterne: On the Buzzword ‘Security Policy’,
1991 IEEE Symposium on Research in Security
and Privacy, pages 219-230
51
Distributed systems
security
Distributed systems: computer systems
connected by a network Communications
(network) security: deals with security
aspects of the communications links
 Computer security: deals with security
aspects related to the end systems; today,
this is the difficult part
 Application security: relies on both to provide
services securely to end users

52
Other Computer Security
Aspects

Access control (authorization): prevention
and detection of unauthorized actions by
users of a computer system
 How
to design access control systems
 How to support application security policies

53
Secure software: software that can cope with
malicious inputs (important paradigm shift
from the PC world to the Internet)
Principles of Computer
Security

54
The Dimensions of Computer Security
1st - Where to focus security

The focus may be on data – operations –
users e.g. integrity requirements may refer to
rules on
 Format
and content of data items (internal
consistency): account balance is an integer
 Operations that may be performed on a data item:
credit, debit, transfer, …
 Users who are allowed to access a data item (
authorized access): account holder and bank
clerk have access to account
55
2nd -Where to place
security controls?
56
3rd-Complexity or Assurance?
 The
location of a security mechanism
on the man-machine scale is often
related to its complexity
 Generic mechanisms are simple,
applications clamor for feature-rich
security functions
 Do you prefer simplicity - and higher
assurance - to a feature-rich security
environment?
57
The Fundamental Dilemma of
Computer Security
 Security-unaware
users have
specific security requirements but
no security expertise.
 Simple
generic mechanisms may not
match specific security requirements. To
choose the right features from a rich
menu, you have to be a security expert.
 Security unaware users are in a no-win
situation
58
Security Evaluation




59
To check whether a system delivers the security
services promised, one has to state the function of
the security system and the required degree of
assurance (trust) in its security
To gain high assurance, the security system has to
be examined in close detail
There is a trade-off between complexity and
assurance. The higher an assurance level you aim
for, the simpler your system ought to be.
Feature-rich security and high assurance do not
match easily
4th-Central or
Decentralized Control?



60
Within the domain of a security policy, the same
rules should be enforced.
With a single entity in charge of security, it is easy to
achieve uniformity but this central entity may
become a performance bottleneck. Distributed
solutions may be more efficient but added care has
to be taken to guarantee that different components
enforce a consistent policy.
Should the tasks of defining and enforcing security
be given to a central entity or should they be left to
individual components in a system?
5th-Blocking access to the
layer below
Every protection mechanism defines a
security perimeter (boundary).
 The parts of the system that can disable the
mechanism lie within the perimeter, the parts
of the system that can malfunction without
compromising the mechanism lie outside.
 Attackers try to bypass protection
mechanisms; corollary to the second design
decision:

 How
do you stop an attacker from getting access
to a layer below your protection mechanism?
61
The Layer Below Examples
Recovery tools like Norton Utilities recover
data by reading memory directly and then
restoring the file structure. Such a tool can
be used to circumvent logical access control
as it does not care for the logical memory
structure
 Unix treats I/O devices and physical memory
devices like files. If access permissions are
defined badly, e.g. if read access is given to
a disk containing read protected files, then
an attacker can read the disk contents and
reconstruct the files.

62
More examples
 Object
reuse: in a single processor system,
when a new process becomes active, it gets
access to memory positions used by the
previous process. You have to avoid storage
residues, i.e. data left behind in the memory
area allocated to the new process.
 Backup: whoever has access to a backup tape
has access to all the data on it. Logical access
control is of no help and backup tapes have to
be locked away safely to protect the data.
 Core dumps: same story again
63
Summary
Security terminology is ambiguous with many
overloaded terms
 Distributed systems security builds on
communications security and on computer
security
 In computer security, two major challenges
are the design of access control systems that
fit the requirements of the Internet and the
design of secure software
 In security, understanding the problem is
more difficult than finding the solution

64