Secure Design Principles

1
CSC 382 Computer Security

• Secure Design Principles

2
Administrivia

• Can you login to Sun account (zappa)?
• How much C/C experience do you have?

3
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

4
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.

5
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.

6
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.

7
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.

8
Software Security

• More than just coding!
• Security in every phase of development
• Requirements
• Design
• Implementation
• Testing

9
Why is Software Security poor?

1. Security is seen as something that gets in the
   way of software functionality.
2. Security is difficult to assess and quantify.
3. Security is often not a primary skill or interest
   of software developers.
4. Time spent on security is time not spent on
   adding new and interesting functionality.

10
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?

11
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

12
Meta Principles

• Simplicity
• Fewer components and cases to fail.
• Fewer possible inconsistencies.
• Easy to understand.
• Restriction
• Minimize access.
• Inhibit communication.

13
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

14
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.

15
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 lt 1024.
• Solution
• Web server runs as root user.
• How does this solution violate the Principle of
  Least Privilege and how could we fix it?

16
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.?

17
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.

18
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?

19
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?

20
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.

21
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?

22
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

23
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.

24
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 225, which
  takes only a few seconds.

25
Closed Source

• Security through obscurity.
• Assumes code in binary cant be read
• what about disassemblers?
• what about decompilers?
• what about debuggers?
• what about strings, lsof, truss, /proc?
• Reverse engineering.

26
Open Source

• Linus Law Given enough eyeballs, all bugs are
  shallow.
• Not so effective for security
• More incentives to add features than security.
• Few people have skills to find security holes.
• Having source eliminates a barrier to entry for
  crackers.

27
Separation of Privilege

• Require multiple conditions to grant access.
• Separation of duty.
• Compartmentalization.
• Defence in depth.

28
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.

29
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?

30
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.

31
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.

32
Least Common Mechanism

• Mechanisms used to access resources should not be
  shared.
• Information can flow along shared channels.
• Covert channels.
• Contradicts Economy of Mechanism?

33
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.

34
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.

35
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

36
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?

37
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

38
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?it2016

39
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.

40
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.

41
Legacy Issues Maintenance

• How can you avoid adding new security flaws when
  performing code maintenance?
• Before looking at a code maintenace procedure,
  what design principles could have prevented the
  Sun tar flaw?

42
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
4. Dont violate the spirit of the design.
5. Dont introduce new trust relationships.

43
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

44
Key Points

• Categories of Security Flaws
• Architecture/design
• Implementation
• Operational
• Secure Design Principles
• Retrofitting and Maintaining Secure Design

45
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, 2nd edition, Micorosft 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-progra
   ms/Secure-Programs-HOWTO/index.html, 2003.