secure design principles - northern kentucky university issues in legacy code case study: sendmail...

1

Secure Design Principles

CSC 482/582: Computer Security Slide #1


Topics

Categories of Security Flaws

Architecture/Design

Implementation

Operational

Software Security: More than Just Coding


Design Issues in Legacy Code

Case Study: Sendmail vs. Postfix


Categories of Security Flaws1. 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.

2


Architecture/Design FlawsRace 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 that’s 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.


Implementation FlawsBuffer 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 doesn’t 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.


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

3


Software Security More than just coding!

Security in every phase of development:

Requirements

Design

Implementation

Testing


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.


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?

4


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


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


Meta Principles

Simplicity

Fewer components and cases to fail.

Fewer possible inconsistencies.

Easy to understand.

Restriction

Minimize access.

Inhibit communication.

5


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.


Least Privilege ExampleProblem: 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?


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

6


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.


Fail Safe Defaults ExampleProblem: 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?


Fail Safe Defaults ExampleProblem: 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.

Don’t 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?

7


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., don’t write your own cryptography.


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?


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

8


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.


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.


Separation of PrivilegeRequire multiple conditions to grant access.

Separation of duty

Compartmentalization

Defence in depth

9


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.


CompartmentalizationProblem: 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?


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.

10


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.


Least Common Mechanism

Mechanisms to access resources should not be shared.

Information can flow along shared channels.

Covert channels.

Contradicts Economy of Mechanism?


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.

11


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


Psychological Acceptability

Users will not read documentation.

Make system secure in default configuration.

Users will not read dialog boxes.

Don’t offer complex choices.

example: Mozilla/IE certificate dialogs.

Privacy vs Usability

example: one-click shopping


Psychological Acceptability Example

Problem: Your workstation is myws, but you log into

green every day to do other tasks and don’t want to

type your password.

Solution: Let green trust myws.

Create ~/.rhosts file on green that lists myws as trusted host, then rlogin greenwill allow access without a password.

Does this solution violate other principles?

Is there a more secure alternative solution?

12


Legacy Issues

How can you design security into legacy applications without source code?

Wrappers

Interposition

What is the best way to fix security f laws in an existing application?

Code Maintenance Techniques


Retrofitting: WrappersMove 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


Retrofitting: InterpositionInterpose 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.

13


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 doesn’t zero out memory. In earlier versions, other memory allocations

were between reading passwd and block read alloc.


Legacy Issues: Maintenance

How can you avoid adding new security f laws when performing code maintenance?

Before looking at a code maintenance procedure, what design principles could have prevented the Sun tar

f law?


Legacy Issues: Maintenance1. 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. Don’t violate the spirit of the design.

2. Don’t introduce new trust relationships.

14


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


Key Points

Categories of Security Flaws

Architecture/design

Implementation

Operational


Least Privilege

Compartmentalization

Psychological Acceptability

Retrofitting and Maintaining Secure Design


References1. Bishop, Matt, Introduction to Computer

Security, Addison-Wesley, 2005.2. Graff, Mark and van Wyk, Kenneth, Secure

Coding: Principles & Practices, O’Reilly, 2003.3. Howard, Michael and LeBlanc, David, Writing

Secure Code, 2nd 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







secure design principles - northern kentucky university issues in legacy code case study: sendmail...

Documents