Writing Secure Programs

Program Security CSCE Farkas/Eastman - Fall Program Flaws Taxonomy of flaws: how (genesis) when (time) where (location) the flaw was introduced into the system

Program Security CSCE Farkas/Eastman - Fall Security Flaws by Genesis Genesis Intentional Inadvertent

Program Security CSCE Farkas/Eastman - Fall Intentional Genesis Malicious: Trojan Horse, Trapdoor, Logic Bomb, covert channels Non-malicious

Program Security CSCE Farkas/Eastman - Fall Inadvertent Genesis Validation error Domain error Serialization error Identification/authentication error Other error

Program Security CSCE Farkas/Eastman - Fall Program Security Topics Today Faults, flaws, and failures (Terminology) Nonmalicious program errors Covert channels Controls against program threats

Program Security CSCE Farkas/Eastman - Fall Security Terminology Terms used in software engineering and security communities not consistent Vulnerability, threat, attack, control, flaw A threat is blocked by control of a vulnerability A flaw may result in a vulnerability An attack exploits a vulnerability

Program Security CSCE Farkas/Eastman - Fall IEEE Standard 729 for Software “Bugs” Error – Human mistake Fault – Incorrect code Failure – Incorrect system behavior Errors may (or may not) cause faults One error may generate many faults Faults may (or may not) cause failures

Program Security CSCE Farkas/Eastman - Fall Nonmalicious Program Errors Buffer overflows Incomplete mediation Time-of-check to time-of-use errors

Program Security CSCE Farkas/Eastman - Fall Buffer Overflows Probably most publicized class of nonmalicious program errors Result from attempt to write too much data into a buffer without checking size May simply interfere with user program or allow system to be taken over

Program Security CSCE Farkas/Eastman - Fall Mediation Mediators facilitate communication among two or more parties Mediators attempt to resolve differences Mediation may be final Intermediaries are also “go-betweens” Usage close but not exactly the same in computer security

Program Security CSCE Farkas/Eastman - Fall Incomplete Mediation Complete mediation – all data accesses handled by an intermediary Required for a trusted computing system Incomplete mediation allows incorrect data into the system, which may not be able to handle it

Program Security CSCE Farkas/Eastman - Fall Incomplete Mediation Example Things.com Customer order returned to company system as url &total=205 User changes total to 25 Real (unidentified) company

Program Security CSCE Farkas/Eastman - Fall Time-of-Check to Time-of-Use Errors TOCTTOU Time interval between checking that a data item is valid and actually using it Value changed during that time period Serialization or synchronization flaw Must ensure that check/use is handled as a transaction

Program Security CSCE Farkas/Eastman - Fall Indirect Information Flow Channels Covert channels – unintended channels of communication Inference channels – determining sensitive data using nonsensitive data A kind of covert channel

Program Security CSCE Farkas/Eastman - Fall Communication Channels Overt Channel: designed into a system and documented in the user's manual Covert Channel: not documented. Covert channels may be deliberately inserted into a system, but most such channels are accidents of the system design.

Program Security CSCE Farkas/Eastman - Fall Covert Channel Timing Channel: based on system times Storage channels: not time related communication Can be turned into each other

Program Security CSCE Farkas/Eastman - Fall Covert Channel Need: Two active participants Encoding schema Example: sender modulates the CPU utilization level with the data stream to be transmitted Sender: repeat get a bit to send if the bit is 1 wait one second (don't use CPU time) else busy wait one second (use CPU time) endif until done

Program Security CSCE Farkas/Eastman - Fall Covert Channels Noise Synchronization Protection (user state, system state) Removal Slow down Audit

Program Security CSCE Farkas/Eastman - Fall Wells and Eastman Examined a covert channel involving patterns of access to encrypted database blocks stored as a B-tree Can determine tree structure, given a sufficient access log Can not determine actual data values simply from access log However, given some data values can guess values for others

Program Security CSCE Farkas/Eastman - Fall Inference Channels + Meta-data Sensitive Information Non-sensitive information =

Program Security CSCE Farkas/Eastman - Fall Inference Channels Statistical Database Inferences General Purpose Database Inferences Will return to inference channels later in course

Program Security CSCE Farkas/Eastman - Fall Controls Against Program Threats Good software engineering Applications Systems programs Good project management Good system management No silver bullet

Program Security CSCE Farkas/Eastman - Fall Developmental Controls Modularity, encapsulation, and information hiding Peer reviews Hazard analysis Testing Good design Prediction Static analysis Configuration management Analysis of mistakes

Program Security CSCE Farkas/Eastman - Fall Peer Reviews Have been shown to be one of the most effective ways to find and correct software faults Distinguish different kinds of peer review Review (informal) Walk-through (systematic examination of code/documentation) Inspection (use checklist)

Program Security CSCE Farkas/Eastman - Fall Hazard Analysis Set of systematic techniques to identify and manage potential hazards Form of risk analysis Most effective approaches include HAZOP – Hazard and operability studies FMEA – Failure modes and effects analysis FTA – Fault tree analysis

Program Security CSCE Farkas/Eastman - Fall Prediction Not clearly separated from hazard analysis Predict the risks involved in building and using the system OCTAVE approach to security involves identifying most important risks and concentrating on those

Program Security CSCE Farkas/Eastman - Fall Good Design Concepts addressed here are fault detection and fault tolerance Passive vs. active fault detection Fault tolerance – retry, correct, restore Defensive driving!!

Program Security CSCE Farkas/Eastman - Fall Code Examination Static analysis Proofs of program correctness

Program Security CSCE Farkas/Eastman - Fall Static Analysis Control flow structure Data structure Data flow structure

Program Security CSCE Farkas/Eastman - Fall Proofs of Correctness Proving that the program performs exactly as specified is also equivalent to the halting problem (and thus not possible) Program verification – sometimes limited to analysis of preconditions and postconditions Formal methods

Program Security CSCE Farkas/Eastman - Fall Software Development Practices Learn from mistakes Keep track of mistakes!! Systematic approach to documenting and using information about problems and what was done about them Negative information useful Why we didn’t do it this way

Program Security CSCE Farkas/Eastman - Fall Operating System Controls Trusted software Mutual suspicion Confinement Access logs More later

Program Security CSCE Farkas/Eastman - Fall Administrative Controls Standards of program development Security audits Separation of duties More later

Program Security CSCE Farkas/Eastman - Fall CSCE 548: Building Secure Software Construction of software systems resistant to vulnerabilities and attacks. Cryptographic tools. Language, operating system, and network security. Case studies. Development of best practices through programming assignments Prereq: CSCE 510 or consent of instructor