Information

Security

Chapter 02:
Software & OS
Security

Nguyễn Đăng Quang

Contents
Bad software is
Program flaws
ubiquitous

Software Security Defensive/Secure

issues Programming

Buffer Overflow
 • The European Space Agency’s
Ariane 5 Flight 501 was
destroyed 40 seconds after

Bad Software is takeoff (June 4, 1996).

Ubiquitous • The US$1 billion prototype
rocket self-destructed due to a
bug in the on-board guidance
software
 A bug in the code controlling
the Therac-25
radiation therapy machine
Bad Software is
was directly responsible for at
Ubiquitous
least five patient deaths in the
1980s when it administered
excessive quantities of X-rays
 The software error of a MIM-104
Patriot, caused its system clock to
drift by one third of a second over
a period of one hundred hours —
Bad Software is  resulting in failure to locate and
Ubiquitous intercept an incoming missile. The
Iraqi missile impacted in a military
compound in Dhahran, Saudi
Arabia (February 25, 1991), killing
28 Americans
 Complexity – Lines Of Code

System Lines of Code (LOC)

Netscape 17 million
Space Shuttle 10 million
Linux kernel 2.6.0 5 million
Windows XP 40 million
Mac OS X 10.4 86 million
Boeing 777 7 million

A new car contains more LOC than was required to land

the Apollo astronauts on the moon
 Conservative estimate: 5 bugs/10,000 LOC
• Typical: 3k EXE’s of 100k LOC each.
• Conservative estimate: 50 bugs/EXE.
• Implies about 150k bugs per computer.
Lines of • A 30000-node network has 4.5 billion bugs
code & Bugs • Maybe only 10% of bugs security-critical
and only 10% of those remotely
exploitable.
• Then “only” 45 million critical security
flaws!
IEEE Quality Terminology
IEEE Standard 729 defines quality-related terms:
• Errors: A human mistake in performing some
software-related activity, such as specification
or coding.
• Fault: An incorrect step, command, process or
data definition in a piece of software (internal
to program)
• Failure: A departure from the system’s desired
behavior

error fault failure

 • The code has an error
• This error might cause a fault
• Incorrect internal state
• If a fault occurs, it might lead to a failure
• Program behaves incorrectly (external)

Example • The term flaw is used for all of the above

 Program Security Flaws

Taxonomy:
An undesired program behavior
caused by a program vulnerability. How (genesis)
When (time)
Where (location)
 Flaws by Genesis

Unintentional Intentional
(Program flaws) (Malicious software)
• SQL Injection • Viruses
• Buffer overflow • Worms
• Incomplete • Other breeds of
mediation malware
Flaws by Time

• During development
• Requirement/specification/design
• Source code
• Object code
• During maintenance
• During operation
Flaws by location

• Software
• OS: System initialization, memory management,
process management, file management,
authentication..., privilege
• Hardware
• CPU design ➔ spectre, meltdown attacks
 ❑ Two questions:
1. How do we keep programs free
from flaws?
2. How do we protect computing
resources against programs with
flaws?
❑ Early idea was to attack the finished
Basic Ideas program to reveal faults, and then
patch errors → not effective and tend
to introduce new faults
❑ More modern approach: careful
specification and compare behavior
with the expected.
 ❑ Insecure Interaction between components
o SQL Injection
o OS Command Injection
o Cross-site Scripting
o CSRF
Software o URL Redirection to Untrusted Site
Security ❑ Risky Resource Management
Issues o Buffer copy without checking input size
o Download of code without Integrity
check
o Use of potentially dangerous function
o Uncontrol format string
o ...

CWE/SANS TOP 25 Most Dangerous Software Errors (2011)

 Defensive Programming

❑ A form of defensive design to ensure continued function of

software despite unforeseen usage.
❑ Requires attention to all aspects of program execution,
environment, data processed.
❑ An approach to improve software and source code, in term of:
• General quality (reducing the number of SW bugs and problems.
• Making source code comprehensive (readable and
understandable).
• Making the SW behave in a predictable manner despite
unexpected inputs or user actions.
Example

Buffer overflow

Defensive programming
Defensive
coding
example
 Best practices

❑ Data input validation

❑ Authentication and password management
❑ Cryptographic Practices
❑ Error Handling and Logging
❑ Data Protection
❑ Communication Security
❑ Adopt a secure coding standard
 The Art

1 2 3 4
Never trust user Don’t reinvent the Don’t trust Use immutable
input wheel (Intelligent developers instead of
code reuse) mutable object
 Secure Software

❑ In software engineering, try to ensure that a

program does what is intended
❑ Secure software engineering requires that software
does what is intended…
…and nothing more
❑ Absolutely secure software? Dream on…
Absolute security anywhere is impossible
❑ Manage software risks
Buffer Overflow
Program memory layout
High Address Args and env vars Parameters or environment variables
Stack
| Stack memory
V
Unused memory

^
Dynamic variables(Ex: C-malloc() or C++-
|
new())
Heap
Uninitialized Data
Global uninitialized variables
Segment (bss)
Initialized Data
Global initilalized variables
Segment
Low Address Text Segment Code
 Secure Software

❑ In software engineering, try to ensure that a

program does what is intended
❑ Secure software engineering requires that software
does what is intended…
…and nothing more
❑ Absolutely secure software? Dream on…
Absolute security anywhere is impossible
❑ Manage software risks
Simple Buffer Overflow
• Consider boolean flag for
authentication
• Buffer overflow could
overwrite flag allowing
anyone to authenticate

buf

flag
ebp
eip
Smashing the stack

• Return address (eip) is overwritten.

buf
• Crash is likely

flag
ebp
new eip
ret addr
Smashing the stack – Better idea

• Evil code is injected into the buf

• Return address (eip) is overwritten with Evilbuf
code
address of evil code
• The evil code then activated with the new return
address flag
ebp
new eip
ret addr
Practice

or

$gcc vuln.c –o vuln -fno-stack-protector -m32 -g

 1. Safer Functions: Use strncpy, snprintf, strncat, fgets
instead of strcpy, sprintf, strcat, gets.
2. Program Static Analyzer: this type of solution warns
Buffer Overflow developers of the patterns in code that may potentially
Countermeasures lead to buffer overflow vulnerabilities.
3. Programming Language: Choose the language itself can
do some check against buffer overflow like Java or
Python (safer for development) [OSWAP, 2014]
Buffer Overflow Countermeasures
4. Compiler:
• StackGuard: Save a copy of the
return address at a safer place

implemented in compiler (gcc)

automatically (canary)
canary is stored at gs:20 which
pointed to a memory region
isolated from the stack
-fno-stack-protector disable this
feature
 5. Operating System:
implemented in OS loader program: ASLR
(Address Space Layout Randomization)
Buffer Overflow Set ASLR
Countermeasures echo 0 > /proc/sys/kernel/randomize_va_space
or
sudo sysctl –w kernel.randomize_va_space = 0 (1,2)
Buffer Overflow Countermeasures

6. Hardware Architecture:
Modern CPUs support NX-bit (No-eXecute) feature:
memory areas when marked as non executable, the CPU will
refuse to execute any code residing in these areas of
memory.
gcc -z execstack option turning off this feature.
Buffer Overflow • A major security threat yesterday,
today, and tomorrow
• The good news?
• It is possible to reduce overflow
attacks (safe languages, NX bit,
ASLR, education, etc.)
• The bad news?
• Buffer overflows will exist for a
long time
• Why? Legacy code, bad
development practices, clever
attacks, etc.