Advanced Operating Systems: Lecture 43 - Mr. Farhan Zaidi

CS703 ­ Advanced 
Operating Systems
By Mr. Farhan Zaidi

 

 


Lecture No. 
43


Overview of today’s lecture









Types of buffer overflow attacks
Methods for fighting buffer overflows
StackGuard and PointGuard
Libsafe
Address obfuscation
Viruses and worms
Mobile code security & sandboxing
Java security

Causing program to exec attack code


Stack smashing attack:




Function pointers:





Override return address in stack activation record by
overflowing a local buffer variable.
(used in attack on Linux superprobe)

Heap
Overflowing
buf will override function
FuncPtr pointer.or
             buf[128]
stack

Longjmp buffers: longjmp(pos)     (used in attack on  Perl 5.003)


Overflowing buf next to pos overrides value of pos.


Finding buffer overflows


Hackers find buffer overflows as follows:







Run web server on local machine.
Issue requests with long tags.
All long tags end with “$$$$$”.
If web server crashes,
search core dump for “$$$$$” to find
overflow location.

Some automated tools exist. (eEye Retina, ISIC).


Preventing buf overflow attacks


Main problem:





strcpy(), strcat(), sprintf() have no range checking.
“Safe” versions strncpy(), strncat() are misleading
 strncpy() may leave buffer unterminated.

Defenses:






Type safe languages (Java, ML). Legacy code?
Mark stack as non-execute.
Static source code analysis.
Run time checking: StackGuard, Libsafe, SafeC, (Purify).
Black box testing (e.g. eEye Retina, ISIC ).


Marking stack as non­execute


Basic stack exploit can be prevented by marking
stack segment as non-executable or
randomizing stack location.




Problems:






Code patches exist for Linux and Solaris.

Does not block more general overflow exploits:
 Overflow on heap: overflow buffer next to func pointer.
Some apps need executable stack (e.g. LISP interpreters).

Patch not shipped by default for Linux and Solaris.


Run time checking: StackGuard


Many many run-time checking techniques …



Solutions 1: StackGuard (WireX)



Run time tests for stack integrity.
Embed “canaries” in stack frames and verify their

integrity prior to function return.
Frame 2

local

canary

sfp ret str

Frame 1
local

canary

sfp ret str

top
of
stack


Canary Types


Random canary:







Choose random string at program startup.
Insert canary string into every stack frame.
Verify canary before returning from function.
To corrupt random canary, attacker must learn current
random string.

Terminator canary:
Canary = 0, newline, linefeed, EOF



String functions will not copy beyond terminator.
Hence, attacker cannot use string functions to corrupt
stack.


StackGuard (Cont.)


StackGuard implemented as a GCC patch.


Program must be recompiled.



Minimal performance effects: 8% for Apache.



Newer version: PointGuard.






Protects function pointers and setjmp buffers by placing
canaries next to them.
More noticeable performance effects.

Note: Canaries don’t offer full protection.


Some stack smashing attacks can leave canaries
untouched.


Run time checking: Libsafe


Solutions 2: Libsafe (Avaya Labs)



Dynamically loaded library.
Intercepts calls to strcpy (dest, src)
 Validates sufficient space in current stack frame:

|frame-pointer – dest| > strlen(src)
 If so, does strcpy.
Otherwise, terminates application.


More methods …


Address obfuscation.






(Stony Brook ’03)

Encrypt return address on stack by XORing with random
string. Decrypt just before returning from function.
Attacker needs decryption key to set return address to
desired value.

Randomize location of functions in libc.


Attacker cannot jump directly to exec function.


Viruses and worms






External threat
 code transmitted to target machine
 code executed there, doing damage
Goals of virus writer
 quickly spreading virus
 difficult to detect
 hard to get rid of
Virus = program can reproduce itself
 attach its code to another program
 additionally, do harm


How Viruses Work (1)
Virus written in assembly language
 Inserted into another program






use tool called a “dropper”

Virus dormant until program executed




then infects other programs
eventually executes its “payload”


How Viruses Work






An executable program
With a virus at the front
With the virus at the end
With a virus spread over free space within program


How Viruses Spread
Virus placed where likely to be copied
 When copied







infects programs on hard drive, floppy

may try to spread over LAN

Attach to innocent looking email


when it runs, use mailing list to replicate


Antivirus and Anti­Antivirus 
Techniques
Signature based







Integrity checkers
Behavioral checkers
Virus avoidance
 good OS
 install only shrink-wrapped software
 use antivirus software
 do not click on attachments to email
 frequent backups
Recovery from virus attack
 halt computer, reboot from safe disk, run antivirus

Mobile Code (1) Sandboxing

(a) Memory divided into 1-MB sandboxes
(b) One way of checking an instruction for validity


Mobile Code (2)

Applets can be interpreted by a Web browser


Mobile Code (3)

How code signing works


Java Security (1)




1.
2.
3.
4.
5.

A type safe language
compiler rejects attempts to misuse variable
Checks include …

Attempts to forge pointers
Violation of access restrictions on private class members
Misuse of variables by type
Generation of stack over/underflows
Illegal conversion of variables to another type