Secure Programming Joe Testa

Download Report

Transcript Secure Programming Joe Testa

Secure Programming
Joe Testa
●
“It is better to be a Beginner than a Master,
because a Beginner can proceed in any
direction, whereas the Master is entrenched
in old habits.”
●
-- A Chinese proverb
Buffer Overflows
●
●
Buffer overflows are conditions that arise
when
the bounds of a fixed-length buffer are
exceeded.
●
●
They affect programs written in programming
languages that provide direct memory
access.
Buffer Overflows
●
●
They affect a program by overwritting other
variables in memory with attacker-defined
values.
Overflows are an issue only when a program
is interacting with an untrusted user.
Buffer Overflows
●
Example: overflow spilling from one variable
into another.
●
char buffer1[ 8 ];
●
char buffer2[ 8 ];
●
// These 12 'A's will spill into buffer1!
●
strcpy(buffer2, “AAAAAAAAAAAA”);
Buffer Overflows
●
Example: overflows can overwrite other
important data.
●
char buffer[ 8 ];
●
// This will overwrite the saved EIP register!
●
strcpy(buffer, “AAAAAAAAAAAAAAAAA
●
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAA”);
x86 Stack
●
●
●
The stack is the main data structure used by
programs to store temporary information (like
local variables).
Based in high memory, grows backwards.
EBP register holds the Base Pointer
(bottom).
x86 Stack
●
(Note to self: draw stuff on board)
“Dangerous” Functions
●
strcpy(char *dest, const char *src);
●
strcat(char *dest, const char *src);
●
sprintf(char *dest, const char *format, ...);
●
... this is not an exhaustive list!!
“Safe” Functions
●
strncpy(char *dest, const char *src, size_t n);
●
strncat(char *dest, const char *src, size_t n);
●
snprintf(char *str, size_t size,
const char *format, ...);
●
●
... etc ...
“Safe” Functions
●
The “safe” functions still have a problem:
●
The null byte is not written!
Defensive Programming
●
●
●
Lesson 1: ALWAYS ALWAYS ALWAYS use
the strn* functions, EVEN IF YOU DON'T
NEED TO!
You never know who will update your
code, nor what they are adding.
This is a good habit to develop for when you
really need it.
Defensive Programming
●
Lesson 2: Wasting buffer space is good!
●
This protects against off-by-one overflows!
Defensive Programming
●
●
●
Lesson 3: Always nullify free()'ed pointers.
This prevents the insidious 'double-free' class
of buffer overflows.
The popular 'zlib' library fell to this attack.
Defensive Programming
Lesson 4: Use unsigned ints, unless you
have a good reason not to.
This reduces your exposure to integer
overflows.
Apache, the most popular web serving
daemon, fell to this attack.
Defensive Programming
Lesson 5: Make sure that important code is
protected by stringent checks. Do not put
important code in an 'else' block.
Is this Dijkstra's 'Guarded-Else' paradigm?
External Safety Nets
No-exec stack
Stackguard
Pro-Police
W^X
Cyclone
Solution
JAVA
“It is better to be a Beginner than a Master,
because a Beginner can proceed in any
direction, whereas the Master is
entrenched in old habits.”
-- A Chinese proverb