Outline

1
?????????

• ?????????
• ???

2
Outline

• Background
• Software Attack Basic
• Software Process Vulnerability
• Software Exploitability
• Dynamic and Static Defense
• Conclusion

3
(No Transcript)
4
Software Engineering and Worms

• 1968 (conference on software crisis after IC
  invention, with more complex software)
• 1988 (Nov 2) Internet Worm
• 2001 (July 19) Code Red Worm (after 1988)
• 2003 (Aug 11) Blaster Worm (impact MS)
• 2005
• Worms Anywhere and Anytime
• Microsoft Software auto-updates more frequently

5
Software Attack Basic
6
The Strength of Cryptography

• 128-bit keys mean strong security, while 40-bit
  keys are weak
• triple-DES is much stronger than single DES
• 2,048 RSA is better than 1,024 bit RSA
• lock your front door with four metal pins, each
  of which in one of 10 positions. There will be
  10,000 possible keys almost impossible to break
  in
• NO !!!

7
Strength of Cryptography

• Burglars wont try every possible keys or pick
  the lock.
• They smash windows, kick in doors, and use
  chainsaw to the house wall.
• Most of us design, analyze and break
  cryptographic system. Few try to do research on
  published algorithms, protocols and actual
  products.

8
From Bruce Schneier

• We dont have to try every possible key or even
  find flaws in the algorithms.
• We exploit
• errors in design,
• errors in implementation, and
• errors in installation.
• Sometimes we invent a new trick to break a
  system, but most of the time we exploit the same
  old mistakes that designers make over and over
  again.

9
(No Transcript)
10
Security Attack

• Dynamic Event occur during the execution of a
  piece of software.
• Attack made possible
• weaknesses must exist in the system
• sequence of weakness exploiting input signals to
  the system is required

11
Threat

• threat an agent outside of a software system to
  exploit a vulnerability through attacks

12
Vulnerability

• potential defect or weakness in an information
  system
• knowledge required to exploit the defect

13
State Space Vulnerability

• System state current configuration of the
  entities in the system
• Authorized or unauthorized state given initial
  state using a set of state transitions defined by
  security policy
• Vulnerability state authorized state from which
  an unauthorized state can be reached using
  authorized state
• Compromised state the authorized state above
• Attack begins in vulnerability state

14
State Space Attack
Attack
Unauthorized State
Vulnerability State
Authorized State(compromised by the attack)
15
????????

• ????????
• ????(Y2K,malicious buffer overflow)
• ???????????
• ????????(Web Internet Platform Security)
• ????????????

16
Software Process Vulnerability

• Imprecise Requirement Specification
• Design Vulnerability
• Implementation Flaws
• Mismatch between development and run-time
  environment
• Improper Configuration and Application

17
Software Attacks

• Implementation flaws Buffer Overflow Attacks
• Stack Overflow
• Heap Overflows
• Data Segment, Shared Memory Segment
• Environment mismatch Type System Attacks
• type containment not sound
• mismatch between dynamic loaded library and
  actual arguments

18
Buffer Overflow Attacks

• Internet Worm fingerd in Nov 2, 1988.
• Overflow the buffer of a remote daemon or a
  setuid program
• inject malicious machine code to the programs
  address space
• overwrite the return address of some function
• Lack of a good string or buffer data type in C
  and misuse of the standard C librarys string
  function.

19
Overflow Attack Made Possible whenever Software
Fault (bugs) not removed

• Deviation between process transition
  (inter-process) and Phase inconsistency between
  analysis, design, implementation and application.
• Inter-process inconsistency communication flaws
  when requirement analysis, language type
  inconsistency when program implementation,improper
  configuration when in application

20
?????????

• ??????
• ????????
• ???????????
• ???????????? (Web security and Type system attack)

21
Problems

• Interface Compatibility
• Semantics of linking differed between distributed
  environment
• Semantic Gap between security protocols and
  implementation

22
Environment Transition
Restriction A program can only change its type
context , to a new type context in a way such
that the new context is a consistent extension of
the original context.
Component Composition what is the consistent
extension of component environment ?
23
Security Problems Related to Software Quality

• System Exploitability the system can be
  compromised from an authorized state to any
  unauthorized states
• Any System exploitable ? How to exploit it?
• Any System Failure exploitable ? How to do it?
• If the crash site detected, is the system
  exploitable ? How to do it?
• If the corrupt site detected, is the system
  exploitable ? How to do it?

24
Imagination

• We dont have solutions to the above problems,
  but can have a partial exploitation method with
  constraints.
• Once I captured Microsoft window crash site
  information, a computer aided exploitation tool
  can be employed to test it.
• To the bad
• Once any Windows AP failed and waw caught,
  Microsoft will sit on thorns. (remember the RPC
  flaw, the Blaster worm, and the Sasser Worm ?)
• To the good
• We can better understand the system failures.

25
Thoughts

• Though most COTS software have been tested, there
  are still vulnerabilities inside and that cause
  the software crashed, even to be exploited.
• We may find the root cause of the vulnerabilities
  from the crash site.

26
Security Breach due to Quality Problems

• Programs crash occasionally.
• Vulnerabilities inside cause the program crashed
• To find if we can Exploit this crash
• Could runtime execution auditing be helpful to
  exploit this crash?
• Instance crash due to stack and heap overrun
• The situation of stack overrun still exists.
• Detect these situations systematically.
• Possible to develop exploitive attacks in general.

27
Crash-Only Software

• Software is destined to fail
• We can proof the existence of a bug
• We cannot proof the inexistence of all bugs
• Software Bugs Faults and Failures
• Faults not conform to system specifications
• Failures control flow crash, indefinite hang,
  panic resource access
• Exploitability Testing to test if crash-type
  failures are exploitable

28
Steps for Exploitation

• Phase I how to lead the program crash?
• Idea using the test driver to feed the input
  data systematically.
• Brute force testing using instrument tool
• Phase II Is the crash site caused by buffer
  overrun? Crash Site Approximation Find out the
  crash site as precisely as possible.
• Phase III How to exploit?
• Dealing with non-executable stack and one-bye
  overrun
• Forging Payload

29
Searching for Vulnerabilities

• Tracing
• tooltruss in solaris, strace in linux,
• FileMon, RegMon in Windows
• Watching the program interacting with OS.
• Debuggers
• Guideline-Based Auditing
• Watching for difference with design document or
  spec
• Sniffers
• Watching the interaction between the server and
  client.
• nm, objdump

30
Using Disassembler

• disassemble
• watching for referencing to vulnerable library
  functions,
• If found then goto 5.
• search for 'sub esp, ltbig numbergt'. (find local
  variable)
• If found then goto 5.
• look for heap overflows and logic errors
• figure out how to get execution into your
  vulnerable function

31
What do we need?

• Execution path to vulnerable function
• Crash site approximation by stack checkpoint
• Where is the malicious input?
• I/O interception by system call wrapper/Input
  Pollutant Tracer
• Buffer size
• Exploit payload

32
Corrupt Site Detection

• Considerations
• Limitation of Debugger( such as gdb) cannot get
  the call stack from the core file if the crash is
  caused by corruption of call stack( EBP, return).
• We could use tools to checkpoint the call stack
  periodically to discover whether if buffer
  overrun occurs.

33
Corrupt site and Crash site
Function A() Function B() call
Function A() Function C() call Function
B()
Function crash-here(input) char buf10
.. statements to corrupt stack
sprintf(buf,s,input) call Function
A() Further Operations
Corrupt Site
Crash Site
34
Corrupt Site Detection
Kernel32-gtmain-gt.
crash
normal
corruption
Exception handler
??????-gt.
Kerner32-gtexception handler-gt.
Consideration 1. The process of Corruption wont
be too long, 2. It is a challenge to fine
calibrate the granularity of stack checkpoint 3.
Another Solution Function call wrapper

• IDEA stack invariant detection
• 1. In normal situations, call stack can be traced
  
• back to the main function.
• 2. Invariant Violation Cant be traced back to
  main
• Stack Corrupted or
• Interrupted, or
• Enter exception handler

35
COTS Software Security
36
Related Works

• Anomaly Detection Using Call Stack Information,
  IEEE SP03
• HEALERS A Toolkit for Enhancing the Robustness
  and Security of Existing Applications, IEEE DSN
  2003
• Run-Time Detection of Heap-based Overflows,
  USENIX LISA 2003

37
Related Work

• Instrumenting
• StackGuard (A Compiler for stack protection from
  smashing attacks)
• ProPolice(GCC extension for protecting from
  stack-smashing attacks )
• StackShield(A "stack smashing" technique
  protection tool for Linux )
• Fat-pointers
• Cyclone(A Safe Dialect of C)
• CCured(A source-to-source translator for C to
  prevent all memory safety violations. )

38
Related Work

• Purify (memory corruption and leak detection)
• Valgrind(a memory debugger)
• Bidirectional Debugging
• Bitan Biswas and R. Mall, Reverse Execution of
  Programs, ACM SIGPLAN Notices, Apr, 1999
• Bob Boothe, Efficient Algorithms for
  Bidirectional Debugging, PLDI 2000

39
Stack Guard

• canary
• random canary
• terminator canary

40
Stack Shield

• Global ret stack
• array of 256 entries
• saved return addr when function all
• overwrite when function return
• Ret range check
• Protection of function pointer
• a global variable as boundary address

41
ProPolice

• Rearrange local variables

42
Libsafe

• wrap vulnerable function
• strcpy, strcat, getwd, gets, scanf, realpath,
  sprintf
• safe boundary
• Libverify
• adding return address check

43
Source level security auditing tools

• RATS (Rough Auditing Tool for Security)
• Locate potential vulnerabilities in C,
  C,Python,PHP, and Perl
• 200 items
• http//www.securesw.com/rats/
• Flawfinder written in Python
• Scanning C and C code. 40 entries
• http//www.dwheeler.com/flawfinder
• ITS4
• (Its the software, stupid! security scanner)
• Scanning C,C. 145 items.
• http//www.cigital.com/its4/

44
??????????????????

• ??????????????????????
• ??????????????(smashing the stack)???????????
• ??????????,???????????????
• ??????????,???????????
• ?????????,?????????????