軟體品質與資訊安全

1. 軟體品質與資訊安全 交通大學資訊工程系 黃世昆

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

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 won’t 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 don’t 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.

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 program’s 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 library’s 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 don’t 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 • 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

30. Using Disassembler • disassemble • watching for referencing to vulnerable library functions, • If found then goto 5. • search for 'sub esp, <big number>'. (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 buf[10] ; …….. statements to corrupt stack sprintf(buf,”%s”,input); call Function A(…); Further Operations ; } Corrupt Site Crash Site

34. Corrupt Site Detection Kernel32->main->…. crash normal corruption Exception handler ??????->…. Kerner32->exception handler->…. Consideration: 1. The process of Corruption won’t 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: Can’t 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 S&P’03 • 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 • (It’s the software, stupid! security scanner) • Scanning C,C++. 145 items. • http://www.cigital.com/its4/

44. 軟體安全已成為軟體工程研究重要的課題 • 軟體有缺陷就像堅固的房屋開一扇脆弱的玻璃窗。 • 在堆疊覆寫攻擊中可見粉碎堆疊（smashing the stack）就像打破門窗一樣容易。 • 一旦密碼模組有此缺失，不管用多長的金鑰都鎖不住資料。 • 網路服務程式有此弱點，形同大開網路安全漏洞。 • 系統程式若有此問題，系統安全認證也將猶如虛設。