软体品质与资讯安全.ppt

軟體品質與資訊安全,交通大學資訊工程系 黃世昆,Outline,Background Software Attack Basic Software Process Vulnerability Software Exploitability Dynamic and Static Defense Conclusion,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,Software Attack Basic,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 !,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.,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.,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,Threat,threat: an agent outside of a software system to exploit a vulnerability through attacks,Vulnerability,potential defect or weakness in an information system knowledge required to exploit the defect,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,State Space Attack,Vulnerability State,Authorized State(compromised by the attack),Unauthorized State,Attack,軟體系統缺陷運用,軟體發展過程差異 狀態溢寫（Y2K，malicious buffer overflow) 密碼模組設計與實作弱點 可執行內涵的安全（Web Internet Platform Security) 網路伺服應用軟體缺陷利用,Software Process Vulnerability,Imprecise Requirement Specification Design Vulnerability Implementation Flaws Mismatch between development and run-time environment Improper Configuration and Application,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,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.,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,環境差異的安全問題,有缺陷的軟體 有缺陷的軟體環境 編譯環境與程式庫的差異 執行環境與發展環境的差異 (Web security and Type system attack),Problems,Interface Compatibility Semantics of linking differed between distributed environment Semantic Gap between security protocols and implementation,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 ?,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?,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.,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.,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.,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,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,Searching for Vulnerabilities,Tracing tool:truss 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,Using Disassembler,disassemble watching for referencing to vulnerable library functions, If found then goto 5. search for sub esp, . (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,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,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.,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,Corrupt Site Detection,normal,corruption,Exception handler,crash,Kernel32-main-.,?-.,Kerner32-exception handler-.,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,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,COTS Software Security,Related Works,Anomaly Detection Using Call Stack Information, IEEE S&P03 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,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. ),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 fo