| < Finding & Discussion | BOF Main Page | First Edition BOF Tutorial > |


 

 

 

 

CHAPTER FIVE:

CONCLUSION AND FUTURE WORK

 

 

 

 

 

 

 

What are in this section?

5.1   Research Contribution

5.2   Related Future Work

BOF REFERENCE

 

 

5.1    Research Contribution

 

In this project four main conditions for the buffer overflow to occur have been identified and analyzed while the demonstration shows how it happens. It is obvious this is a programming flaw because the problem can be resolved as early as during the coding stage. However, the buffer overflow effects can be seen until the developed program has been distributed to the end user where the damage already done.

The programs that vulnerable to buffer overflow cover a wide range of applications that include an OS kernel, device driver, database engine, embedded system, networking, user and web applications. This knowledge can be very useful input for the better buffer overflow detection and prevention mechanisms in the design and implementation aspects. Various types of current solution with their respective weaknesses and strengths also were discussed.

The current implementation on buffer detection and protection can be enhanced by stressing the solution more at the coding level, before the damage occurs; the following suggestions also have been proposed and discussed:

 

  1. Incorporating the secure coding topics in any C/C++ programming syllabus or provide pre-training before doing any C/C++ coding.

  2. Enhancing the C/C++ editor to avoid buffer overflow as early as possible such as by improving the intellisense feature.

  3. Implementer should include a comprehensive exception handling and may be proposed to be included in the standard.

 

In order to stress on the knowledge usability, employer should start giving preference to the potential employee which having the secure coding knowledge and/or experiences in their resume. Hopefully, by having a better understanding on how and why the stack-based buffer overflow vulnerability and exploit, programmer that using C or other similar 'unsafe language' can avoid this problem at the earliest stage of their task in developing a program. Having a good knowledge where the buffer overflow vulnerability is possible to happen in the application development for example, will obviously contribute something that can improve the product’s quality, saving cost, man-hour and time. This is also supposed to be beneficial for other languages that use C as their base code so that the buffer overflow problem does not inherited and propagated.

 

5.2    Related Future Work

 

The information provided in this part is actually extracted from the Finding and Discussion section. One future research that can be done is to find the relationship between the program size and speed when we add extra code for buffer overflow protection. This should be specific to buffer overflow codes and should be critical for large program. The effectiveness of the prior secure coding knowledge or training also could be measured when the topics of secure C/C++ coding included in C/C++ syllabus or suitable secure coding training is conducted. This also can be applied when implementing a comprehensive exception handling in C/C++ programming.

Another interesting thing to explore is to enhance the C/C++ editor or compiler with educational info of the buffer overflow problem such as through the intellisense feature. Research can be done to gauge the effectiveness of the implementation on reducing the buffer overflow problem.

This project does not emphasize on the compile and runtime detection and prevention solution other than implementing a comprehensive exception handling because of the many researches (mostly funded) have been carried out as discussed in the Literature Review section. Although it is out of programmer’s control, this does not mean it is not important. For example, the convention used for C function call, the way how the stack frame constructed and destroyed (also how the processor support the mechanism through its execution environment) may be reviewed and changed to the better and safer ways.

 

 

 

 

 

 

 

 

 

 

 

 

 

BOF REFERENCE

 

[1] Eugene H. Spafford, "The Internet Worm Program: An Analysis," Purdue Technical Report CSD-TR-823, December 8, 1988.

[2] CERT Incident Note IN-2001-08, "Exploited buffer overflow vulnerability in IIS Indexing Service DLL," July. 19, 2001.

[3] Gregory Travis, Ed Balas, David Ripley and Steven Wallace, "Analysis of the SQL Slammer worm and its effects on Indiana University and related institutions," Advanced Network Management Lab, Cybersecurity Initiative, Indiana University, May 17, 2007.

[4] Kelly Jackson Higgins, "Buffer Overflows Are Top Threat, Report Says," Darkreading, Nov. 26, 2007.

[5] Cisco Systems, Inc., "Cisco 2007 Annual Security Report," Cisco Public Information, 2007.

[6] Mitre.org, "Vulnerability Type Distributions in CVE," Document version: 1.1, May 22, 2007.

[7] Dr. Bjarne Stroustrup, "C++ Applications," Bjarne Stroustrup's personal homepage, July 5, 2008.

[8] Mudge, "How to write buffer overflows," insecure.org, Oct. 20, 1995.

[9] Aleph One, "Smashing the stack for fun and profit," Phrack Magazine, Vol. 7, Issue 49, Aug. 8, 1996.

[10] M. Kaempf, "Smashing The Heap For Fun And Profit," bughunter.net.

[11] Mingo, "Exec Shield," RedHat people, May 11, 2004.

[12] Pandey, S.K. Mustafa, K. and Ahson, S.I., “A checklist based approach for the mitigation of buffer Overflow attacks," in Third International Conference on Wireless Communication and Sensor Networks, Dec. 2007, pp. 115-117.

[13] Zhenkai Liang and Sekar, R., "Automatic generation of buffer overflow attack signatures: An approach based on program behavior models," in Proceedings of the 21st Annual Computer Security Applications Conference, Dec. 2005, pp. 215 - 224.

[14] Smirnov, A. and Tzi-cker Chiueh, "Automatic patch generation for buffer overflow attacks," in Proceedings of the Third International Symposium on Information Assurance and Security 2007, Aug. 2007, pp. 165 - 170.

[15] PaX team, "Homepage of The PaX Team," 2002.

[16] Speirs, W.R., "Making the kernel responsible: a new approach to detecting & preventing buffer overflows," in Proceedings of the Third IEEE International Workshop on Information Assurance, March 2005, pp. 21-32.

[17] J.P. McGregor, D.K. Karig, Z. Shi, and R.B. Lee., "A processor architecture defense against buffer overflow attacks," in Proceedings of the IEEE International Conference on Information Technology, Aug. 2003, pp. 243 – 250.

[18] Nathan Tuck, Brad Calder and George Varghese, "Hardware and binary modification support for code pointer protection from buffer overflow," in Proceedings of the 37th International Symposium on Microarchitecture (MICRO-37’04), Dec. 2004. pp.209 - 220

[19] Zhang Yuhong, Wang Jiebing, Xu Zhihan, Yan Xiaolang and Wang Leyu, "Hardware solution for detection and prevention of buffer overflow attacks," in Proceedings of 5th International Conference on ASIC, vol. 2, Oct. 2003, pp. 1304 - 1307.

[20] H. Ozdoganoglu, C. E. Brodley, T. N. Vijaykumar, B. A. Kuperman and A. Jalote, "SmashGuard: A hardware solution to prevent security attacks on the function return address," IEEE Transactions on Computers, vol. 55, no. 10, pp. 1271 - 1285, November, 2003.

[21] Zili Shao, Chun Xue, Qingfeng Zhuge, Sha, E.H.M. and Bin Xiao, "Efficient array & pointer bound checking against buffer overflow attacks via hardware/software," in Proceedings of the International Conference on Information Technology: Coding and Computing, vol. 1, April 2005, pp. 780 – 785.

[22] Takahiro Shinagawa, "SegmentShield: Exploiting segmentation hardware for protecting against buffer overflow attacks," in 25th IEEE Symposium on Reliable Distributed, 2006, pp. 277 - 288.

[23] Shao, Z. Zhuge, Q. He, Y. Sha and E.H.-M., "Defending embedded systems against buffer overflow via hardware/software," in Proceedings of the 19th Annual Computer Security Applications Conference, Dec. 2003, pp. 352 - 361.

[24] Crispin Cowan, Calton, Dave Maier, Heather, Jonathan, Peat Bakke, Steve Beattie, Aaron Grier, Perry Wagle, and Qian Zhang, "StackGuard: automatic adaptive detection and prevention of buffer-overflow attacks," in Proceedings of the seventh USENIX security conference, 1998, pp. 63-78.

[25] Vendicator, "StackShield: A stack smashing technique protection tool for Linux," Jan. 08, 2000.

[26] Microsoft Corporation, "GS (Buffer security check)," Visual C++ Compiler Options, 2008.

[27] Hiroaki Etoh, "GCC extension for protecting applications from stack-smashing attacks," IBM SSP/ProPolice, Aug. 22, 2005.

[28] Mike Frantzen and Mike Shuey, "StackGhost," Purdue University, 2001.

[29] Crispin Cowan, Steve Beattie, John Johansen and Perry Wagle, "Pointguard: protecting pointers from buffer overflow vulnerabilities," in Proceedings of the 12th conference on USENIX Security Symposium, August 2003, pp. 91–104.

[30] Rinard, M. Cadar, C. Dumitran, D. Roy and D.M. Leu, T., "A dynamic technique for eliminating buffer overflow vulnerabilities (and other memory errors)," in Proceedings of the 20th Annual Computer Security Applications Conference, 2004, pp. 82 - 90.

[31] N. Dor, M. Rodeh, and M. Sagiv., "CSSV: Towards a realistic tool for statically detecting all buffer overflows in C," in Proceedings of the ACM Conference on Programming Language Design and Implementation, June 2003, vol. 38, no. 5, pp 55 - 167.

[32] Tsai, T. and Singh, N., "Libsafe: Transparent system-wide protection against buffer overflow attacks," in Proceedings of the International Conference on Dependable Systems and Networks, 2002, pp. 541.

[33] Nikolai Joukov, Aditya Kashyap, Gopalan Sivathanu, and Erez Zadok, "Kefence: An electric fence for kernel buffers," in Proceedings of the first ACM International Workshop on Storage Security and Survivability (StorageSS 2005), in conjunction with the 12th ACM Conference on Computer and Communications Security (CCS 2005), pp. 37-43, November 2005.

[34] Madan, B.B., Phoha, S. and Trivedi, K.S., "StackOFFence: A technique for defending against buffer overflow attacks," in Proceedings of the International Conference on Information Technology: Coding and Computing, April 2005, vol. 1, pp. 656 - 661.

[35] Zhu, G. and Tyagi, A., "Protection against indirect overflow attacks on pointers," in Proceedings of the Second IEEE International Information Assurance Workshop, April 2004, pp. 97- 106.

[36] Nishiyama, H., "SecureC: Control-flow protection against general buffer overflow attack," in Proceedings of the 29th Annual International Computer Software and Applications Conference, July 2005, pp. 149 - 155.

[37] Lei Wang, Cordy, J.R. and Dean, T.R., "Enhancing security using legality assertions," in Proceedings of the 12th Working Conference on Reverse Engineering, Nov. 2005, pp. 35 - 44.

[38] Benjamin A. Kuperman, Carla E. Brodley, Hilmi Ozdoganoglu, T. N. Vijaykumar and Ankit Jalote, "Detection and prevention of stack buffer overflow attacks," in Source Communications of the ACM, Nov. 2005, vol. 48, no. 11, pp. 50 - 56

[39] C. Cowan, P. Wagle, C. Pu, S. Beattie and J. Walpole, "Buffer overflows: attacks and defenses for the vulnerability of the decade," in Proc. of the DARPA Information Survivability Conference and Expo, 1999.

[40] Kelly Jackson Higgins, "Four different tricks to bypass StackShield and StackGuard protection," CoreSecurity, 2002.

[41] Peter Silberman and Richard Johnson, "A comparison of buffer overflow prevention implementations and weaknesses," BlackHat, USA, 2004.

[42] Steven Alexander, "Defeating Compiler-level Buffer Overflow Protection, ";login: The USENIX Magazine, vol. 30, no. 3, June 2005.

[43] Wikipedia, "NX bit," Wikipedia.org, July 1, 2001.

[44] Mastropaolo, "Buffer overflow attacks bypassing DEP (NX/XD bits) - part 1: Simple Call," mastropaolo.com, June 4, 2005.

[45] Skape and Skywing, "Bypassing Windows Hardware-enforced Data Execution Prevention," Uninformed Journal, Oct. 2, 2005.

[46] Sebastian Krahmer, "x86-64 buffer overflow exploits and the borrowed code chunks exploitation technique," Suse.de, Sept. 28, 2005.

[47] ISO/IEC JTC1 SC22 WG14 Committee, "ISO/IEC TR 24731, Extensions to the C Library, Part I: Bounds-checking interfaces," March 2007.

[48] ISO/IEC JTC1 SC22 WG14 Committee, "ISO/IEC PDTR 24731-2, Extensions to the C Library, Part II: Dynamic Allocation Functions,” August 2007.

[49] cert.org, "CERT C Secure Coding Standard," Jul. 16, 2008.

[50] Yingbo Song, Michael E. Locasto, Angelos Stavrou, Angelos D. Keromytis and Salvatore J. Stolfo, "On the infeasibility of modeling polymorphic shellcode," in Proceedings of the 14th ACM conference on Computer and Communications security, 2007, pp. 541 - 551.

[51] K2, "ADMmutate," Security, Jan. 2002.

[52] Metasploit LLC, "The Metasploit Project," 2003.

[53] Next Generation Security Technologies, "Polymorphic Shellcodes vs. Application IDSs," Jan. 21, 2002.

[54] Pasupulati, A., Coit, J., Levitt, K., Wu, S.F., Li, S.H., Kuo, J.C., Fan, K.P., "Buttercup: on network-based detection of polymorphic buffer overflow vulnerabilities," in Network Operations and Management Symposium, April 2004, vol. 1, pp. 235 - 248.

[55] Hsiang-Lun Huang, Tzong-Jye Liu, Kuong-Ho Chen, Chyi-Ren Dow, Lih-Chyau Wuu, "A polymorphic shellcode detection mechanism in the network,” in Proceedings of the 2nd international conference on Scalable information systems, Article no. 64, Vol. 304, 2007.

[56] Intel.com, "Intel® 64 and IA-32 Architectures Software Developer's Manuals," 2008.

[57] Fedora Linux FTP Repository, "Fedora 9 i386 debug info download," RedHat.com, 2008.

[58] Debian Hardening Wiki, "Using Hardening Options," Debian.org, 2008.

[59] Kerry Thompson, "How to Disable SELinux," 2008.

[60] Michael L. Scott, Programming language pragmatic, 2nd Edition. San Francisco:  Morgan Kaufmann Publishers, 2006.

[61] Alfred V. Aho, Monica S. Lam, Ravi Sethi, and Jeffrey D. Ullman, Compilers: principles, techniques, & tools. 2nd ed. Boston, MA: Pearson Education, 2007.

[62] 1hall, "Introduction to Writing Shellcode," milw0rm.com, April, 2006.

[63] The GNU C Library, "Setuid Program Example," 2008.

[64] Adam Shostack, "Home page - Adam Shostack’s SETUID man page" 2008.

[65] Kevin F. Quinn, "Stack protector, switches and macros," Mail archive of the gcc@gcc.gnu.org mailing list for the GCC project, Dec. 2005.

[66] The GNU’s GCC, "GCC Command Options, Options That Control Optimization," 2008.

[67] Fedora Linux FTP Repository, "Fedora 9 i386 Packages download," RedHat.com, 2008.

[68] The SEED Project, "Instructional Laboratories for Computer Security Education," Syracuse University, 2008.

[69] Vim.org, "An improved vi editor version," vim.org, 2008.

[70] Ravi Shankar, and Madan Ganesh, "Vim Intellisense," 2008.

[71] Microsoft Corp, "Structured Exception Handling," MSDN Library, Sept. 2008.

[72] Matt Pietrek, "A Crash Course on the Depths of Win32 Structured Exception Handling," Microsoft Systems Journal, Jan. 1997 issue.

 

 

 

 

IMPORTANT ABBREVIATIONS

 

 

 

 

 

 

 

 

 

 

 

 

 

 

AMD Advance Micro Device
ASLR Address Space Layout Randomization
CERT Computer Emergency Response Team
CPU Central Processing Unit
CVE Common Vulnerabilities and Exposures
DEP Data Execution Prevention
DLL Dynamic Link Library
EBP/ebp extended base pointer
EIP/eip extended instruction pointer
ESP/esp extended stack pointer
GCC GNU Compiler Collection
gdb GNU Debugger
GOT Global Offset Table
IDE Integrated Development Environment
IDS Intrusion Detection System
IEC International Electrotechnical Commission
IOS Internetwork Operating System
ISO International Organization for Standardization
NOEXEC No Execute
NOP No Operation
NX No Execute
OS Operating System
POC Proof-Of-Concept
SEH Structured Exception Handling
SP Service Pack
SQL Structured Query Language
SSP Stack-Smashing Protector
XD Execute Disable

 

 

 

 

 

 

 


 

| < Finding & Discussion | BOF Main Page | First Edition BOF Tutorial > |