CSC 482/582: Computer SecuritySlide #2 Topics Categories of
Security Flaws Architecture/Design Implementation Operational
Software Security: More than Just Coding Secure Design Principles
Design Issues in Legacy Code Case Study: Sendmail vs. Postfix
Slide 3
CSC 482/582: Computer SecuritySlide #3 Categories of Security
Flaws 1. Architectural/design-level flaws: security issues that
original design did not consider or solve correctly. 2.
Implementation flaws: errors made in coding the design. 3.
Operational flaws: problems arising from how software is installed
or configured.
Slide 4
CSC 482/582: Computer SecuritySlide #4 Architecture/Design
Flaws Race Condition Application checks access control, then
accesses a file as two separate steps, permitting an attacker to
race program and substitute the accessible file for one thats not
allowed. Replay Attack If an attacker can record a transaction
between a client and server at one time, then replay part of the
conversation without the application detecting it, a replay attack
is possible. Sniffing Since only authorized users could directly
access network in original Internet, protocols like telnet send
passwords in the clear.
Slide 5
CSC 482/582: Computer SecuritySlide #5 Implementation Flaws
Buffer overflow Application with fixed-size buffer accepts
unlimited length input, writing data into memory beyond buffer in
languages w/o bounds checking like C/C++. Input validation
Application doesnt check that input has valid format, such as not
checking for ../ sequences in pathnames, allowing attackers to
traverse up the directory tree to access any file. Back door
Programmer writes special code to bypass access control system,
often for debugging or maintenance purposes.
Slide 6
CSC 482/582: Computer SecuritySlide #6 Operational Flaws Denial
of service System does not have enough resources or ability to
monitor resources to sustain availability under large number of
requests. Default accounts Default username/password pairs allow
access to anyone who knows default configuration. Password cracking
Poor passwords can be guessed by software using dictionaries and
permutation algorithms.
Slide 7
CSC 482/582: Computer SecuritySlide #7 Software Security More
than just coding! Security in every phase of development:
Requirements Design Implementation Testing
Slide 8
CSC 482/582: Computer SecuritySlide #8 Why is Software Security
poor? Security is seen as something that gets in the way of
software functionality. Security is difficult to assess and
quantify. Security is often not a primary skill or interest of
software developers. Time spent on security is time not spent on
adding new and interesting functionality.
Slide 9
CSC 482/582: Computer SecuritySlide #9 How can design securely?
What about using checklists? Learn from our and others mistakes.
Avoid known errors: buffer overflow, code injection, race
conditions, etc. Too many known problems. What about unknown
problems?
Slide 10
CSC 482/582: Computer SecuritySlide #10 How can design
securely? Think about security from the beginning. Evaluate threats
and risks in requirements. Once we understand our threat model,
then we can begin designing an appropriate solution. Apply Secure
Design Principles Guidelines for security design. Not a guarantee
of security. Tradeoffs between different principles
Slide 11
CSC 482/582: Computer SecuritySlide #11 Security Design
Principles 1. Least Privilege 2. Fail-Safe Defaults 3. Economy of
Mechanism 4. Complete Mediation 5. Open Design 6. Separation of
Privilege 7. Least Common Mechanism 8. Psychological
Acceptability
Slide 12
CSC 482/582: Computer SecuritySlide #12 Meta Principles
Simplicity Fewer components and cases to fail. Fewer possible
inconsistencies. Easy to understand. Restriction Minimize access.
Inhibit communication.
Slide 13
CSC 482/582: Computer SecuritySlide #13 Least Privilege A
subject should be given only those privileges necessary to complete
its task. Function, not identity, controls. Rights added as needed,
discarded after use. Minimal protection domain. Most common
violation: Running as administrator or root. Use runas or sudo
instead.
Slide 14
CSC 482/582: Computer SecuritySlide #14 Least Privilege Example
Problem: A web server. Serves files under /usr/local/http. Logs
connections under /usr/local/http/log. HTTP uses port 80 by
default. Only root can open ports < 1024. Solution: Web server
runs as root user. How does this solution violate the Principle of
Least Privilege and how could we fix it?
Slide 15
CSC 482/582: Computer SecuritySlide #15 How do we run with
least privilege? List required resources and special tasks Files
Network connections Change user account Backup data Determine what
access you need to resources Access Control model Do you need
create, read, write, append, etc.?
Slide 16
CSC 482/582: Computer SecuritySlide #16 Fail-Safe Defaults
Default action is to deny access. When an action fails, system must
be restored to a state as secure as the state it was in when it
started the action.
Slide 17
CSC 482/582: Computer SecuritySlide #17 Fail Safe Defaults
Example Problem: Retail credit card transaction. Card looked up in
vendor database to check for stolen cards or suspicious transaction
pattern. What happens if system cannot contact vendor? Solution: No
authentication, but transaction is logged. How does this system
violate the Principle of Fail-Safe Defaults?
Slide 18
CSC 482/582: Computer SecuritySlide #18 Fail Safe Defaults
Example Problem: MS Office Macro Viruses. MS office files can
contain Visual Basic code (macros.) MS Office automatically
executes certain macros when opening a MS Office file. Users can
turn off automatic execution. Dont mix code and data! Solution: MS
Office XP has automatic execution of macros turned off by default.
While the solution is a fail-safe default, does it follow least
privilege too?
Slide 19
CSC 482/582: Computer SecuritySlide #19 Economy of Mechanism
Keep it as simple as possible (KISS). Use the simplest solution
that works. Fewer cases and components to fail. Reuse known secure
solutions i.e., dont write your own cryptography.
Slide 20
CSC 482/582: Computer SecuritySlide #20 Economy of Mechanism
Example Problem: SMB File Sharing Protocol. Used since late 1980s.
Newer protocol version protects data integrity by employing packet
signing technique. What do you do about computers with older
versions of protocol? Solution: Let client negotiate which SMB
version to use. How does this solution violate economy of
mechanism?
Slide 21
CSC 482/582: Computer SecuritySlide #21 Complete Mediation
Check every access. Usually checked once, on first access: UNIX:
File ACL checked on open(), but not on subsequent accesses to file.
If permissions change after initial access, unauthorized access may
be permitted. bad example: DNS cache poisoning
Slide 22
CSC 482/582: Computer SecuritySlide #22 Open Design Security
should not depend on secrecy of design or implementation. Popularly
misunderstood to mean that source code should be public. Security
through obscurity Refers to security policy and mechanism, not
simple user secrets like passwords and cryptographic keys.
Slide 23
CSC 482/582: Computer SecuritySlide #23 Open Design Example:
Problem: MPAA wants control over DVDs. Region coding, unskippable
commercials. Solution: CSS (Content Scrambling System) CSS
algorithm kept secret. DVD Players need player key to decrypt disk
key on DVD to descript movie for playing. Encryption uses 40-bit
keys. People w/o keys can copy but not play DVDs. What happened
next? CSS algorithm reverse engineered. Weakness in algorithm
allows disk key to be recovered in an attack of complexity 2 25,
which takes only a few seconds.
Slide 24
CSC 482/582: Computer SecuritySlide #24 Separation of Privilege
Require multiple conditions to grant access. Separation of duty
Compartmentalization Defence in depth
Slide 25
CSC 482/582: Computer SecuritySlide #25 Separation of Duty
Functions are divided so that one entity does not have control over
all parts of a transaction. Example: Different persons must
initiate a purchase and authorize a purchase. Two different people
may be required to arm and fire a nuclear missile.
Slide 26
CSC 482/582: Computer SecuritySlide #26 Compartmentalization
Problem: A security violation in one process should not affect
others. Solution: Virtual Memory Each process gets its own address
space. In what ways is this solution flawed? i.e., how can the
compartments communicate? How could we improve compartmentalization
of processes?
Slide 27
CSC 482/582: Computer SecuritySlide #27 Defence in Depth
Diverse defensive strategies Different types of defences.
Protection Detection Reaction Different implementations of
defences. If one layer pierced, next layer may stop. Avoid crunchy
on the outside, chewy on the inside network security. Contradicts
Economy of Mechanism Think hard about more than 2 layers.
Slide 28
CSC 482/582: Computer SecuritySlide #28 Defence in Depth
Example Problem: Bank. How to secure the money? Solution: Defence
in depth. Guards inside bank. Closed-circuit cameras monitor
activity. Tellers do not have access to vault. Vault has multiple
defences: Time-release. Walls and lock complexity. Multiple
compartments.
Slide 29
CSC 482/582: Computer SecuritySlide #29 Least Common Mechanism
Mechanisms to access resources should not be shared. Information
can flow along shared channels. Covert channels. Contradicts
Economy of Mechanism?
Slide 30
CSC 482/582: Computer SecuritySlide #30 Least Common Mechanism
Problem: Compromising web server allows attacker access to entire
machine. Solution: Run web server as non-root user. Attacker still
gains other access to filesystem. Run web server in chroot
jail.
Slide 31
CSC 482/582: Computer SecuritySlide #31 Psychological
Acceptability Security mechanisms should not add to the difficulty
of accessing a resource. Hide complexity introduced by security
mechanisms. Ease of installation, configuration, and use. Human
factors critical here.
Slide 32
CSC 482/582: Computer SecuritySlide #32 Psychological
Acceptability Users will not read documentation. Make system secure
in default configuration. Users will not read dialog boxes. Dont
offer complex choices. example: Mozilla/IE certificate dialogs.
Privacy vs Usability example: one-click shopping
Slide 33
CSC 482/582: Computer SecuritySlide #33 Psychological
Acceptability Example Problem: Your workstation is myws, but you
log into green every day to do other tasks and dont want to type
your password. Solution: Let green trust myws. Create ~/.rhosts
file on green that lists myws as trusted host, then rlogin green
will allow access without a password. Does this solution violate
other principles? Is there a more secure alternative solution?
Slide 34
CSC 482/582: Computer SecuritySlide #34 Legacy Issues How can
you design security into legacy applications without source code?
Wrappers Interposition What is the best way to fix security flaws
in an existing application? Code Maintenance Techniques
Slide 35
CSC 482/582: Computer SecuritySlide #35 Retrofitting: Wrappers
Move existing application to special location. Replace old
application with wrapper that: Performs access control check.
Performs input checks. Secures environment. Logs invocation of
application. Invokes legacy application from new location. Example:
AusCERT overflow_wrapper
http://www.auscert.org.au/render.html?it=2016
Slide 36
CSC 482/582: Computer SecuritySlide #36 Retrofitting:
Interposition Interpose software between two programs we cannot
control. Add access control. Filter communication. Example: Network
proxy Router blocks all direct client/server connections. Client
connects to proxy server, who makes connection to remote server on
behalf of client. Access Control: disallow certain clients and/or
servers. Filtering: scan for viruses, worms, etc. Auditing: all
connections can be logged.
Slide 37
CSC 482/582: Computer SecuritySlide #37 Maintenance: Sun tar
flaw 1993: Every tar file produced under Solaris 2.0 contained
fragments of /etc/passwd file. Tar reads and writes fixed size
blocks. Last block written has contents of memory block that were
not overwritten by disk read. Tar reads /etc/passwd to obtain user
info. Immediately before it allocates the block read buffer. Heap
allocation doesnt zero out memory. In earlier versions, other
memory allocations were between reading passwd and block read
alloc.
Slide 38
CSC 482/582: Computer SecuritySlide #38 Legacy Issues:
Maintenance How can you avoid adding new security flaws when
performing code maintenance? Before looking at a code maintenance
procedure, what design principles could have prevented the Sun tar
flaw?
Slide 39
CSC 482/582: Computer SecuritySlide #39 Legacy Issues:
Maintenance 1. Understand security model and mechanisms already in
place. 2. Learn how the program actually works. Read design docs,
code, and profile the program. 3. When designing and coding the
fix: 1. Dont violate the spirit of the design. 2. Dont introduce
new trust relationships.
Slide 40
CSC 482/582: Computer SecuritySlide #40 Case Study: Postfix vs
Sendmail Sendmail monolithic program with root privileges Postfix
separate programs with different privileges smptd: listens to
network (port 25) sendmail: accepts local mail postdrop: setgid
drops in maildrop directory pickup: retrieves mail from
maildrop
Slide 41
CSC 482/582: Computer SecuritySlide #41 Key Points Categories
of Security Flaws Architecture/design Implementation Operational
Secure Design Principles Least Privilege Compartmentalization
Psychological Acceptability Retrofitting and Maintaining Secure
Design
Slide 42
CSC 482/582: Computer SecuritySlide #42 References 1. Bishop,
Matt, Introduction to Computer Security, Addison-Wesley, 2005. 2.
Graff, Mark and van Wyk, Kenneth, Secure Coding: Principles &
Practices, OReilly, 2003. 3. Howard, Michael and LeBlanc, David,
Writing Secure Code, 2 nd edition, Microsoft Press, 2003. 4. Viega,
John, and McGraw, Gary, Building Secure Software, Addison-Wesley,
2002. 5. Wheeler, David, Secure Programming for UNIX and Linux
HOWTO, http://www.dwheeler.com/secure- programs/Secure-Programs-
HOWTO/index.html, 2003. http://www.dwheeler.com/secure-
programs/Secure-Programs- HOWTO/index.html
