2005. Programming Languages Security - A Survey, страница 11

This could beeither by prevention, detection, mitigation or containment.ContraPoliceHeap overflows occur on buffers that are dynamically allocated on the heap, e.g. by calling functions from themalloc() family. ContraPolice [51], which is an extensionfor libc, attempts to protect applications from heap smashing attacks, by protecting memory allocated on the heap frombuffer overflows.ContraPolice places a decoy (analogous to a canary value)before and after the allocated memory in the heap. It alsomaintains a list of all memory blocks that were dynamicallyallocated, including their base address and size.

When a newmemory block is requested, besides being first allocated viamalloc(), it is also added to the list of dynamically allocated memory blocks.Before exiting a library function handling buffers, the address of the buffer that is currently being handled is lookedup to see whether it is registered in the list of dynamicallyallocated memory regions. If it is, a function is invoked tocheck if the decoy values before and after the allocated memory match. If they do not an error message is printed andthe execution of the program is halted.

Decoy values are randomly generated.Since ContraPolice is an extension for libc, it is bound to acertain libc implementation and (depending on the libc) to aplatform. Currently, there is only a reference implementationfor dietlibc (a small libc for Linux) available.5ConclusionsEnforcing security at the programming language level is ofprime importance to systems security, as majority of attacksseek to exploit vulnerabilities in language constructs and implementation. A vast majority of programming language researchers maintain that the most effective way to address thesecure programming issues is by restricting the usage of C insecurity-sensitive projects due to the overwhelming evidencethat it is an unsafe language and hence a bad choice. They recommend the use of the aforementioned safe languages to enforce that certain programming semantics are preserved during execution [85].Type-safe programming languages ensure that security exploits caused by memory misuse, such as malicious code execution, are prevented.

They guarantee this via a numberof complementary safety properties, including memory safety(programs can only access intended memory locations) andflow safety (programs can only transfer execution-flow to relevant program points).Even so, most current type-safe languages are not the bestchoice for systems programming, as they do not fulfill the demanding operational requirements required for these tasks –performance, explicit memory management and control overlow-level data structures.

Furthermore, porting or adaptinglegacy code into these safe languages could be prohibitivelyexpensive.Moreover when it comes to programmer productivity, experience is a major factor, switching to safe programming languages could add costs in terms of training and productivityloss (at least till programmers are comfortable with the newsystem).A safe efficient language with the same data and controlabstractions as C, with tools to facilitate porting, would bean acceptable alternative. Within C, a more robust standardstring library that performs automatic bounds and type checking would be a great boon.Finally, new techniques such as OS virtualization, are becoming ever more pervasive in deployed systems.

By isolating applications from each other the security of the system asa whole can be increased, preventing an attacker from exploiting resources other than the ones being used by the compromised application. Therefore by taking advantage of the novelalternatives offered by modern systems, i.e. by combining virtualization with secure programming languages and/or staticFormatGuardFormatGuard [17] is a patch to glibc that tries to preventformat string attacks by calculating the sum of arguments thata format string expects and compares this to the sum of arguments that were actually passed. If the passed number is lessthan the expected number, it is assumed to be an exploit andthe program is terminated.FormatGuard implements a wrapper around calls to unsafelibrary functions.

The wrapper parses the format string to determine if there is a difference in the expected number of arguments and number of arguments demanded for by the formatstring.FormatGuard is no longer available.SummaryTable 1 summarizes the different countermeasures. A checkedvulnerability column against a specific tool does not necessar21```Stack-basedVulnerability``````Tool`` buffer overflows√SplintITS4RATSBOONPurifyValgrindSystraceSFIProgramShepherdingSCCFail-SafeANSI-C compilerStackGuardProPoliceRADPointGuardBhatkar et al.Solar Designer’sStack PatchPaXLibsafe LibverifyContraPoliceFormatGuardDangling pointerdereferences√√√√Heap-Basedbuffer overflows√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√Format stringAttacks√√√Integererrors√√√√√√√√√√√√√√Table 1: Tools vs.

Vulnerabilities they attempt to counteract.and dynamic analysis tools, an improved assortment of secureapplications could be developed.conference on Programming language design andimplementation, pages 290–301, New York, NY, USA, 1994.ACM Press.http://doi.acm.org/10.1145/178243.178446.16Acknowledgments[3] A. Baratloo, N.

Singh, and T. Tsai. Transparent run-timedefense against stack smashing attacks. In Proc. of the 2000Usenix Annual Technical Conference, Jun 2000.http://www.usenix.org/publications/library/proceedings/usenix2000/general/full papers/baratloo/baratloo.pdf. 20The authors are grateful to Michael J. Fromberger for his inputs and insightful comments. We would also like to thankRobert Brentrup and Scott Rotondo for reviewing and providing feedback on the paper.

We are also grateful to Sun Microsystems for their support of this project. This paper doesnot necessarily represent the views of our sponsors.[4] S. Bhatkar, D.C. DuVarney, and R. Sekar. Addressobfuscation: An efficient approach to combat a broad rangeof memory error exploits. In Proc.

of the 12th UsenixSecurity Symposium, Aug 2003.http://www.usenix.org/events/sec03/tech/full papers/bhatkar/bhatkar.pdf. 19References[1] Aleph One. Smashing The Stack For Fun And Profit.Phrack, 7(49), November 1996.http://www.phrack.org/phrack/49/P49-14. 2[5] blexim. Basic Integer Overflows. Phrack, 11(60), December2002. http://www.phrack.org/phrack/60/p60-0x0a.txt. 3[2] Todd M. Austin, Scott E. Breach, and Gurindar S.

Sohi.Efficient detection of all pointer and array access errors. InPLDI ’94: Proceedings of the ACM SIGPLAN 199422[6] Hans Boehm and Mark Weiser. Garbage Collection in anUncooperative Environment. Software Practice andExperience, pages 807–820, September 1988. 4[7] BOON - Buffer Overrun detectiON.http://www.cs.berkeley.edu/∼daw/boon/. 12[19][8] Derek Bruening, Evelyn Duesterwald, and SamanAmarasinghe. Design and Implementation of a DynamicOptimization Framework for Windows. In ACM Workshopon Feedback-Directed and Dynamic Optimization, Austin,Texas, December 2001. http://cag.lcs.mit.edu/commit/papers/01/RIO-FDDO.pdf. 16[9] Derek Bruening, Timothy Garnett, and Saman Amarasinghe.An Infrastructure for Adaptive Dynamic Optimization.

InInternational Symposium on Code Generation andOptimization, San Francisco, March 2003.http://cag.lcs.mit.edu/commit/papers/03/RIO-adaptive-CGO03.pdf. 16[20][21][10] Bulba and Kil3r. Bypassing Stackguard and Stackshield.Phrack, 10(56), May 2000.http://www.phrack.org/phrack/56/p56-0x05.2[22][23][11] C− >Haskell, An Interface Generator for Haskell.http://www.cse.unsw.edu.au/∼chak/haskell/c2hs/. 8[24][12] CCured Documentation.http://manju.cs.berkeley.edu/ccured/. 4[13] CERT/CC Statistics 1988-2005. http://www.cert.org/stats/cert stats.html. 1[25][14] Tzi cker Chiueh and Fu-Hau Hsu.

RAD: A Compile-TimeSolution to Buffer Overflow Attacks. In ICDCS, pages409–417, 2001. http://www.computer.org/proceedings/icdcs/1077/10770409abs.htm. 18[26][15] Jeremy Condit, Matthew Harren, Scott McPeak, George C.Necula, and Westley Weimer. CCured in the real world. InPLDI ’03: Proceedings of the ACM SIGPLAN 2003conference on Programming language design andimplementation, pages 232–244, New York, NY, USA, 2003.ACM Press.http://doi.acm.org/10.1145/781131.781157.5[27][28][16] Matt Conover. w00w00 on Heap Overflows.http://www.w00w00.org/files/articles/heaptut.txt, 1999. 2[29][17] C. Cowan, M. Barringer, S. Beattie, G.

Kroah-Hartman,M. Frantzen, and J. Lokier. FormatGuard: Automaticprotection from printf format string vulnerabilities. In Proc.of the 10th Usenix Security Symposium, Aug 2001.http://www.usenix.org/events/sec01/full papers/cowanbarringer/cowanbarringer.pdf. 3, 21[30][31][18] C. Cowan, S. Beattie, J. Johansen, and P. Wagle.PointGuardTM : Protecting pointers from buffer overflow23vulnerabilities. In Proc.