Security

vulnerabilities
and penetration
testing
Dr Phillip James
 Last week we explored the first phases of system
Recap and hacking:
today • Passwords
• Network access
• Root kits

Today we will begin to look at security

vulnerabilities.

Smashing the stack

But first, gdb and assembly.

C in one slide
Hello world

Result:

Hello, World!
Assembly

Memory address, number of bytes from start of

function, opcode, parameters.
 1. Push value of base pointer onto stack.
Line by line 2. Move previous stack pointer into base pointer.
3. Copy location of variable + offset to RDI
register.
4. Set accumulator to 0 (ready for return value).
5. Call printf function.
6. Set accumulator to 0 (ready for return value).
7. Pop value off stack and store in base pointer
register.
8. Jump back to return address as popped from
stack (hence usually ebp+4).
In memory Previous stack
Stack frame
pointer Locals for function

Base
pointer Saved base pointer
Return address

Arguments

.
.
.
 Notice we see:

Registers rbp/ebp – base pointer (points to start of stack)

rsp/esp – stack pointer (points to top of stack)
rip/eip – instruction pointer (next instruction)
rax/eax – accumulator (used by opcodes to store
intermediate results, represents return values)

Also:

rsi/esi – source index

rdi/edi – destination index
used as locations in store/load operations

(I skipped a few: counter, data, base…)

gdb
‘gnu debugger’
 GDB, the GNU Project debugger, allows you to see
what is going on `inside' another program while it
Power is evil executes.

YES.

Features from webpage:

• Start your program, specifying anything that might
affect its behavior.
• Make your program stop on specified conditions.
• Examine what has happened, when your program
has stopped.
• Change things in your program, so you can
experiment with correcting the effects of one bug
and go on to learn about another.
 Command Description
gdb <program> <args> Start gdb on program with args
Useful cheat run Run the program to be debugged
sheet step Execute to next instruction
break <where> Set breakpoint at pointer
clear Delete breakpoints
x/nfu <address> Display memory at given address.
n – number of units, f – format, u – unit (see below).
disas <where> Disassemble given function
info locals Print information of local variables
info registers Print information on registers
info args Print information on arguments
Set {type}<address>=value Sets memory at given address to given value (type
indicates e.g. char)
• Formats include a: pointer, c: integer, x: hex…
• Units include: b: byte, w: word, g: giant byte…
Demo
Buffer overflows
 Ages old, became popular after 1996:
My buffer
runneth over

“Smashing The Stack For Fun & Profit” by Aleph One

(I recommend you take a look at the Phrack Magazine)

Basic idea: put more data into a variable than the

space has space to hold. It leaks out, overwriting
other stuff in an interesting manner.
Result: Alteration of data or execution of arbitrary
code!
 Takes advantage of the way code & data are mixed
in memory and of how the function call stack is
Stack based organised.

Compiled code sits in memory as machine code:

• Instructions are indistinguishable from data,
essentially.
• Instruction Pointer register holds address of next
instruction.
• Leads to requirement to keep a stack of ‘frames’
representing the function call stack.
 void broken() {
Example: foo char foo[50];
bar char bar[10];
printf("What is your name?");
gets(foo);
strcpy(bar, foo);
printf("Hello, %s\n", bar);
}
int main() {
broken();
return 0;
}
And the stack
 What happens if a user enters a string longer that
Long strings.. 49 Chars?
• Fills foo & ‘Clobbers’ whatever comes next.
• Overwrites saved frame pointer, possibly return pointer,
args, . . . possibly goes into stack frame below!
• Provided it doesn’t go too far, gets() ‘succeeds’.

What happens if a use enters a string longer than 9

chars?
• Fits inside foo, but…
• Strycpy() Overflows bar, corrupting foo.
 If return pointer is overwritten, program’s control
flow is altered.
The crux
If this happens accidentally, it probably contains
junk.
• Probably contains address outside process’ space.
• Segmentation fault.

What if the overflow is carefully crafted?

• Overwrite data with malicious code.
• Overwrite return pointer with address of that code.
• That code gets executed when function ‘returns’.
Smashing the
stack
Defence: be Don’t allow them to happen! Be vigilant!
vigilant!
• Every operation must be incapable of overflowing
buffer.
• Some functions are just dangerous with untrusted
data.
• A great argument in favour of higher level
languages:
• isolation from the stack frame.
• management of dynamic resources for you.
• but not always possible!
 Canaries or canary words are known values that are
placed between a buffer and control data on the
Defence: stack to monitor buffer overflows.
compiler tricks

When the buffer overflows, the first data to be

corrupted will usually be the canary, and a failed
verification of the canary data is therefore an alert
of an overflow, which can then be handled.
 Mark the stack as non executable.

Defence: DEP Done.

Data execution prevention, not …

Johnny.

But wait, perhaps I can get my return pointer to

point to an executable area of memory (much
harder, but possible).

Also does not stop heap overflows.

Defence: ASLR Randomize where things are stored in memory
including:
• stack
Address space layout
randomization • heap
Randomize address layout space • libraries, etc

Can still be overcome in some cases, but is really

really hard.
So why are we
learning this?
 ssh [email protected] -p 2226
password: nairiepecu

Demo gdb ./narnia2

disas main

Play around with inputs, trying to overwrite return address.

This input will give us a shell:

run `python -c 'print "A"*48 +
"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x89\x
c1\x89\xc2\xb0\x0b\xcd\x80\x31\xc0\x40\xcd\x80"
+ "B" * 56 +
"\xec\xd5\xff\xff”’`
 We have explored a fairly technical vulnerability:
Summary • C and assembly
• Memory layouts and pointers
• gdb
Noun: a brief statement or account
of the main points of something. • Buffer overflows
• Techniques to overcome them

Lab: Guess... Buffer overflows!

Next week: Web application vulnerabilities.