Chapter Two
Chapter Two
Dilla University
CHAPTER TWO
Program Security Overview
By:Shewangizaw Liulseged
OBJECTIVES
To learn the concept of secure programming
Programming errors with security implications:
buffer overflows, incomplete access control
Malicious code: viruses, worms, Trojan horses
Controls against malicious code and vulnerabilities
Controls against program flaws in execution
PROGRAM SECURITY
Why we need security at the program level?
Because programs constitute most to a computing system and
Protecting programs is the heart of computer security.
All kinds of programs, from apps via OS, DBMS, networks
How can we achieve it?
Issues:
1. How do we keep programs free from flaws?
2. How do we protect computing resources against programs that
contain flaws?
SECURE PROGRAMS
Security implies some degree of trust that the program
enforces expected confidentiality, integrity, and
availability.
What is “Program security?”
Depends on who you ask
user -fit for his task
programmer -passes all “his/her” tests
manager -conformance to all specs
FAULT TOLERANCE TERMINOLOGIES
Bug–mistake in interpreting a requirement, syntax error
Error–human made mistake , may lead to a fault
Fault–misinterpreted requirements may lead to several faults in the
coding and testing phases. Seen by “insiders” (e.g., programmers)
Failure-system malfunction caused by fault, can be discovered
before or after system delivery. Seen by “outsiders” (e.g.,
independent testers, users)
Error/fault/failure example:
Programmer’s indexing error, leads to buffer overflow fault
Buffer overflow fault causes system crash (a failure)
FIXING FAULTS
Software that has many faults early on is likely to have many
others still waiting to be found.
Earlier paradigm to judge s/w security: penetrate and patch
Red Team /Tiger Team tries to crack s/w
If software withstands the attack => security is good
• Is this true?-Rarely.
Too often developers try to quick-fix problems discovered by
Tiger Team
FIXING FAULTS
Quick patches often introduce new faults due to:
Pressure –causing narrow focus on fault, not context
Non-obvious side effects
Fixing one problem often caused a failure somewhere else
system performance requirements not allowing for security
overhead
UNEXPECTED BEHAVIOR
Compare program requirements with behavior to identify program
security flaws
Flaw is either a fault or failure
Vulnerability is a class of flaws (e.g. buffer overflows)
Therefore we categorize the faults into inadvertent human errors and
intentionally induced faults.
There are 2 reasons for not addressing all program security flaws:
Program controls apply at the level of the individual program and programmer.
Programmer concentrates on “Should do” checklist and least bother about “shouldn’t
do” checklist.
Programming and software engineering techniques evolve more rapidly than
computer security techniques.
TYPES OF FLAWS
Intentional
Malicious
Non malicious
Inadvertent
Validation error (incomplete / inconsistent) : permission checks
Domain error : controlled access to data
Serialization and aliasing: program flow order
Inadequate identification and authentication : basis for authorization
Boundary condition violation : failure on first and last case
VIRUSES AND OTHER MALICIOUS CODE
Work done by a program is invisible to users and they will not
be aware of any malicious activity.
Example:
1. When is the last time you saw a bit?
2. Do you know in what format a document file is stored?
3. If a document is stored on a disk, can you tell the exact location where is it
residing?
4. Which programs execute when we start our computer and how they are
executed?