1. Software Security and Security Engineering (Part 2)
Software Engineering
Sources:
Ian Somerville, Software Engineering, Chapter 14
Computer Security: Arts and Science, Matt Bishop, Addison Wesley, 2003
Chapter 28

2. Security Principals 1975 Saltzer and Schroeder’s
fundamental principles of secure software design
Main goal: restriction with simplicity
Design principles serve these purposes:
raise awareness of security issues
can be used in implementation to prevent loopholes
can be used as the basis of a review checklist
Restriction limits users/processes
Simplicity makes validation easier

3. Least Privilege
A subject should be given only those privileges necessary to complete its task
Function controls assignment
Minimal protection domain
Rights added as needed, discarded after use
This is an example of restriction. Key concepts are:
Function: what is the task, and what is the minimal set of rights needed? “Minimal” here means that if the right is not present, the task cannot be performed. A good example is a UNIX network server that needs access to a port below 1024 (this access requires root).
Rights being added, discarded: if the task requires privileges for only one action, then the privileges should be added before the action and then removed. Going back to the UNIX network server, if the server need not act as root (for example, an SMTP server), then drop the root privileges immediately after the port is opened.
The protection domain statement emphasizes the other two.

4. Fail-Safe Defaults Default action is to deny access
Exclude-fail is better than permit-fail
If unable to complete task, undo
The first is well-known. Add rights explicitly; set everything to deny, and add back. This follows the Principle of Least Privilege. You see a variation when writing code that has security considerations. If you take untrusted data (such as input) that may contain meta-characters. The rule of thumb is to specify the LEGAL characters, and discard all others, rather than to specify the ILLEGAL characters and discard them.
The second is often overlooked, but goes to the meaning of “fail safe”: if something fails, the system is still safe. Failure should never change the security state of the system. Hence, if an action fails, the system should be as secure as if the action never took place.

5. Economy of Mechanism Keep it as simple as possible
Simpler means less can go wrong
KISS principle: “Keep It Simple, Silly” (often stronger pejoratives are substituted for “silly)
Simplicity refers to all dimensions: design, implementation, operation, interaction with other components, even in specification. The toolkit philosophy of the UNIX system is excellent here; each tool is designed and implemented to perform a single task. The tools are then put together. This allows the checking of each component, and then their interfaces. It is conceptually much less complex than examining the unit as a whole. The key, though, is to define all interfaces completely (for example, environment variables and global variables as well as parameter lists).

6. Complete Mediation Check every access No bypass Everytime
The reason for relaxing this one is efficiency: if you do lots of accesses, the checks will slow you down substantially. It’s not clear if that is really true, though.
Exercise: Have a process open a UNIX file for reading. From the shell, delete the read permissions that allow the process to read the file. Then have the process read from the open file. The process can do so. This shows the check is done at the open. If you want to be sure, have the process close the file. Then have the process try to reopen the file for reading. This open will fail.
Note that UNIX systems fail to enforce this principle to any degree on a superuser process, where access permissions are not even checked for an open! This is why people create management accounts (more properly, role accounts) like bin or mail: by restricting processes to those accounts, so access control checking applies. It also is an application of the principle of least privilege.

7. Open Design
Strength of security should not depend on secrecy of design or implementation
Does not apply to information such as passwords or cryptographic keys
Note that source code need not be available to meet this principle. It simply says that your security cannot depend upon your design being a secret. Secrecy can enhance the security, but if the design becomes exposed, the security of the mechanism cannot be affected.
The problem is that people are very good at finding out what secrets protect you. They may figure it out from the way the system works, or from reverse engineering the interface or system, or by more prosaic techniques such as dumpster diving.
This principle does not speak to secrets not involving design or implementation. For example, you can keep crypto keys and passwords secret.

8. Separation of Privilege
Require multiple conditions to grant privilege/access
Separation of duty
You need to meet more than one condition to gain access. Separation of duty says that the one who signs the checks cannot be the one who prints the checks because then a single person could steal money. To make that more difficult, the thief must compromise two people, not one.
This also provides a finer-grained control over a resource than a single condition.
The analogy with non-computer security mechanisms is that of “defense in depth.” To get into a castle, you need to cross the moat, scale the walls, and drop down over the walls before you can get in. That is three barriers (conditions) that must be overcome (met).

9. Least Common Mechanism
Mechanisms/Resources should not be shared
Information can flow along shared channels
Isolation prevents communication, and communication with something—another process or a resource—is necessary for a breach of security. Limit the communication, and you limit the damage. So, if two processes share a resource, by coordinating access, they can communicate by modulating access to the entire resource.
Examples: percent of CPU used. To send a 1 bit, the first process uses 75% of the CPU; to send a 0 bit, it uses 25% of the CPU. The other process sees how much of the CPU it can get and from that can tell what the first process used, and hence is sending. Variations include filling disks, creating files with fixed names, and so forth.
Approaches to implementing this principle: isolate each process, via virtual machines or sandboxes (a sandbox is like a VM, but the isolation is not complete).

10. Psychological Acceptability
Security mechanisms should not add to difficulty of accessing resource
Hide complexity introduced by security mechanisms
Ease of installation, configuration, use
This recognizes the human element. General rules are:
Be clear in error messages. You don’t need to be detailed (e.g., did the user mistype the password or login name) but you do need to state the rules for using the mechanism (in the example, that the user must supply both password and login name).
Use (and compilation, installation, etc.) must be straightforward. It’s okay to have scripts or other aids to help here. But, for example, data types in the configuration file should either be obvious or explicitly stated. A “duration” field does not indicate if the period of time is to be expressed in hours, minutes, seconds, or something else, nor whether fractional units are allowed (a float) or not (an integer). The latter is actually a common bug. If duration is in minutes, then does “0.5” mean 30 seconds (as a float) or 0 seconds (as an integer)? If the latter, an error message should be given (“invalid type”).
This is usually interpreted as meaning the mechanism must not impose an onerous burden. Strictly speaking, passwords violate this rule (because it’s not as easy to access a resource by giving a password as accessing the resource without a password), but the password is considered a minimal burden.

11. Design guidelines for secure systems engineering
Security guidelines
Base security decisions on an explicit security policy
Avoid a single point of failure
Fail securely
Balance security and usability
Log user actions
Use redundancy and diversity to reduce risk
Validate all inputs
Compartmentalize your assets
Design for deployment
Design for recoverability

12. Mapping of Design guidelines with SS Principals
Security guidelines
Base security decisions on an explicit security policy
Avoid a single point of failure
Fail securely
Balance security and usability
Log user actions
Use redundancy and diversity to reduce risk
Validate all inputs
Compartmentalize your assets
Design for deployment
Design for recoverability
Economy of Mechanism
Open Design
Complete Mediation
Fail Safe Defaults
Separation of Privilege
Least Privilege
Least Common Mechanism
Psychological Acceptability

13. Design guidelines 1-3 Base decisions on an explicit security policy
Define a security policy for the organization that sets out the fundamental security requirements that should apply to all organizational systems.
Avoid a single point of failure
Ensure that a security failure can only result when there is more than one failure in security procedures. For example, have password and question-based authentication.
Fail securely
When systems fail, for whatever reason, ensure that sensitive information cannot be accessed by unauthorized users even although normal security procedures are unavailable.

14. Design guidelines 4-6 Balance security and usability Log user actions
Try to avoid security procedures that make the system difficult to use. Sometimes you have to accept weaker security to make the system more usable.
Log user actions
Maintain a log of user actions that can be analyzed to discover who did what. If users know about such a log, they are less likely to behave in an irresponsible way.
Use redundancy and diversity to reduce risk
Keep multiple copies of data and use diverse infrastructure so that an infrastructure vulnerability cannot be the single point of failure.

15. Design guidelines 7-10 Validate all inputs
Check all inputs so that unexpected inputs cannot cause problems.
Compartmentalize your assets
Organize the system so that assets are in separate areas and users only have access to the information that they need rather than all system information.
Design for deployment
Design the system to avoid deployment problems
Design for recoverability
Design the system to simplify recoverability after a successful attack.

16. Common security-related programming problems
Improper choice of initial protection domain
Improper isolation of implementation detail
Improper change in file contents
Improper naming
Improper deallocation, deletion
Improper validation
Improper indivisibility
Improper sequencing
Improper choice of operand or operation
Programmers are human. We make mistakes because for carelessness or unawareness. These mistakes can have dangerous consequences specially for safeguarding the systems against harms.
Errors in implementation can propagate to errors in installation/configuration/operation.

17. Improper Choice of Initial Protection Domain
Arise from incorrect setting of permissions or privileges
Process privileges
Assumptions
Memory protection

18. Process Privileges
Least privilege principle
Implementation Rule:
Structure the process so that all sections requiring extra privileges are modules.
The modules should be as small as possible and should perform only those tasks that require those privileges.
Example:
When implementing authentication module
privileges acquired only when needed, and relinquished once immediate task is complete
Insufficient privilege: can cause disruption
Excessive privilege: attacker can exploit to cause harm
If extra privileges are limited to modules, then, once the module has completed its task, the privileges can be taken away. This limits attack time and scope.
Keeping these modules compact and dedicated, makes testing/debugging easier and limits exposure of attack surface.
For example, if you are developing authentication module where your code validates user’s password with “previously known” passwords, then the module may require elevated privileges to access the password file. The authentication module should relinquish privilege as soon as it is done with validating.
Question is can we have privileged modules in our environment?
No; this is typically a function of the OS
Cannot acquire privileges after start, unless process started with those privileges
So, program can start with root privileges
Authentication module is called and it needs these privileges to read password file
Privileges released by root switching to user role

19. Assumptions
Incorrect or flawed assumption can open opportunity for exploitation
Implementation Rule:
Ensure that any assumptions in the program are validated.
If this is not possible, document them for the installers and maintainers, so they know the assumptions that attackers will try to invalidate.
Example:
Document importance of integrity control for the password file that is used by the authentication module
Authentication module in the previous example assumes that the password file is correct and have not been tampered with. However if an attacker was able to change password for a given user, then the attacker would be authenticated successfully by the module.
So, this assumption must be documented so that people who are in charge of protecting the password file, are conscious and careful about it.

20. Memory Protection Shared memory Least common mechanism principle
If two processes have access, one can change data other relies upon, or read data other considers secret
Least common mechanism principle
Implementation Rule
Ensure that the program does not share objects in memory with any other program, and that other programs cannot access the memory of a privileged process.
Example
Declare variables that should not be changed in program as const
As program runs, it depends on values of variables/objects in memory. So protecting memory is very critical.
If 2 processes share the same file and one alters data erroneously that the other one uses, results will be unpredictable. So, interactions must be synchronized between processes.
Also if 2 processes share the same memory space, memory dump by one can potentially reveal sensitive data used by another.

21. Memory Protection cont.
Implementation Rule:
If a process interacts with other processes, the interactions should be synchronized. In particular, all possible sequences of interactions must be known and, for all such interactions, the process must enforce the required security policy.

22. Memory Protection cont.
Executable memory
With Buffer Overflow attack (active learning exercise), one can overflow buffer to overwrite memory with malicious code, which when executed could cause potential harm.
Least privilege principle
Implementation Rule
Whenever possible, data that the process trusts and data that it receives from untrusted sources (such as input) should be kept in separate areas of memory. If data from a trusted source is overwritten with data from an untrusted source, a memory error should occur
Check size of user input
Treat user input as untrusted data (not executable code)
Check that values are valid
Do not reuse variables used for data input
Any out-of-bounds reference should invoke exception handler
Overflow not the problem
Changes to variables, state caused by overflow is the problem
Malcode that is introduced is the problem
Trusted data can be affected by untrusted data
Least privilege ensures that data is treated as data only and not given permission to execute

23. Improper Isolation of Implementation Detail
Look for errors, failures of mapping from abstraction to implementation
Usually error messages should capture these
Fail safe default principle
Implementation Rule:
The error status of every function must be checked.
Do not try to recover unless the cause of the error, and its effects, do not affect any security considerations. The program should restore the state of the system to the state before the process began, and then terminate.
Example:
Carefully thought out error messages
When authentication fails for some reason, do not give out exactly why.. aids attackers
If DB query fails, do not give out error messages with info on DB schema
Not falling back to default with unexpected situation
Problem arises when abstraction (concept) is improperly mapped into implementation details (improperly implemented).
One has to catch errors in such cases.
Careful analysis of abstraction and implementation mapping should be used to design error messages that are informative but at the same time should not have any security implications.
Examples:
If a database query failed to return result, error messages should denote why but keep the messages abstract enough not to reveal database schema to potential attackers.
If authentication module failed to return any result because of error in implementation (maybe the password file could not be found), then need to make sure such situation is accounted for and system denies permission instead of reverting to any default permission.
If a certain task cannot be carried out in completion, it should undo the intermediate tasks and restore to original state to preserve integrity of system. Example, if transferring from X to Y account cannot be completed fully after withdrawing money from X and while depositing to Y, then X should be retuned to previous state.

24. Improper Change in File Contents
May happen when multiple processes have access to same file or when dynamic libraries are used
Implementation Rule:
Do not use components that may change between the time the program is created and the time it is run.
Example
Dynamic libraries
Dynamic libraries are not part of the executable and they are loaded as needed in the program. Dynamic files can change for genuine upgrades or if not well protected, they can be changed for malicious reasons. Any change can cause side effects. So, programs that use dynamic libraries always have some risks.

25. Improper Naming Program must control context of interpretation of name
Ambiguity in identifying object name
Names are interpreted in context
Unique objects cannot share names within same context
Context includes:
Character set composing name
Process, file hierarchies
Network domains
Customizations such as search path
Implementation Rule:
The process must ensure that the context in which an object is named identifies the correct object.
Example:
Use of absolute path names like c:/secret/names.txt instead of names.txt
Program must control context of interpretation of name
Otherwise, the name may not refer to the expected object

26. Improper Deallocation, Deletion
Sensitive information can be exposed if object containing it is reallocated
Erase data, then deallocate
Implementation Rule:
When the process finishes using a sensitive object (one that contains confidential information or one that should not be altered), the object should be erased, then deallocated or deleted. Any resources not needed should also be released.
Once a process is finsihed with resource, that resource should be erased (overwritten with dummy content) and deallocated so that other processes can properly reuse the resource without security implications. E.g., if data is not erased and allocated again, the data when reused is now owned by another process. So, if sensitive (like password), confidentiality/integrity is compromised.

27. Improper Validation
Something not checked for consistency or correctness
Bounds checking
Type checking

28. Bounds Checking Improper bounds results in overwriting
Implementation Rule:
Ensure that all array references access existing elements of the array. If a function that manipulates arrays cannot ensure that only valid elements are referenced, do not use that function. Find one that does, write a new version.
Example:
strcpy never checks bounds; too dangerous
Use strncpy where you can specify bound
Check Indices: off-by-one, signed vs. unsigned
Careful with Pointers: no good way to check bounds automatically
strcpy(x,y) copies array content of y to x
strncpy(x,y) copies n array elements of y to x

29. Type Checking Ensure arguments, inputs, and such are of the right type
Interpreting floating point as integer, or shorts as longs will generate erroneous results
Implementation Rule:
Check the types of functions and parameters.

30. Designing for Validation
Some validations are impossible due to structure of language or other factors
Example: in C, one can test for NULL pointer, but not for a “valid” pointer
So avoid situations where pointers are passed and must be validated
Implementation Rule:
Create data structures and functions in such a way that they can be validated.
Design, implement data structures in such a way that they can be validated

31. Improper Indivisibility
Problems arise when operations that should be indivisible are divisible
Separation of privilege principle
Implementation Rule:
If two operations must be performed sequentially without an intervening operation, use a mechanism to ensure that the two cannot be divided.
Example: if there is lag between when permission is checked and when permission is used, someone can change permission in between and results will be unexpected. The checking and using should be considered as one operation. Both are working together to accomplish one goal.

32. Improper Sequencing
Operations performed in incorrect order can produce undesired results (active learning exercise)
Implementation Rule:
Describe the legal sequences of operations on a resource or object. Check that all possible sequences of the program(s).

33. Improper Choice of Operand or Operation
Erroneous selection of operation or operand (active learning exercise)
Implementation Rule:
Validate if operands or operations are yielding desired behavior as per security policy.
Operands should be of appropriate type and value
Operations should be selected to perform desired functions.

34. Qu es ti ons? The End ______________________ Devon M. Simmonds
Computer Science Department
University of North Carolina Wilmington
____________________________________________ _________________