Free Whitepapers from the Avaya IP Telephony and Mobility Center WHITEPAPER : Understanding VoIP—Leveraging Technology for a Competitive Edge See how converging your traditional voice and data networks can save money and increase efficiency and productivity. WHITEPAPER : The Converged IT Organization A best practices approach for ensuring success with IP telephony WHITEPAPER : Migrating to Converged Networks and IP Telephony Applications Lower the risks associated with the migration to IP telephony. Reliability, Availability and Serviceability for the Always-on Enterprise Downtime is not an option for systems at the core of enterprise computing. Intel® processor-based platforms provide the robust foundation needed for the always-on enterprise, meeting the highest quality standards and providing a wide array of sophisticated reliability, availability, and serviceability (RAS) features. From dual-processor systems to mainframe-class platforms, with Intel built-in you get the flexibility and reliability you need to succeed. Learn more. >   Stay Ahead with the New Dual-Core Intel Xeon Platforms Intel® Xeon® processors give your enterprise the power to evolve in manageable ways. Now with dual-core technology, servers based on Intel Xeon processors provide the built-in standards, stability, and scalability your infrastructure needs to move your business forward.  Learn more. >   Free Yourself from RISC The high-cost, lack of choice, and inflexibility of RISC-based infrastructures can significantly degrade competitive advantage and slow business momentum. It's time to free yourself from RISC and move to Intel® Itanium® 2 processor-based solutions. Based on industry standards and with worldwide support from leading OSVs, OEMs and ISVs, Itanium® 2-based server systems provide greater choice and mainframe-class reliability at a lower cost than proprietary-based systems.Learn more. >   Intel Server Resource Center Preventing Buffer Overflow Exploits, Part 1

ServerWatch > Tutorials

January 26, 2006
Preventing Buffer Overflow Exploits, Part 2
By Ibrahim Haddad

The troubling  thing about buffer overflow exploits is that good programming practices could wipe out even potential exploits; however, that simply has not happened. The defense against such exploits should revolve around controlling access to sensitive systems, installing software updates that replace exploitable software, and being aware of what a buffer overflow exploit looks like when your system is the intended victim.

Since buffer overflow exploits are one of the most popular attacks, there were many ways to try to prevent them.

1. The first solution is to write correct code where the programmer checks the size of the buffer; for instance, using strncpy instead of strcpy. In Part 1's Listing 3 (vulnerable.c), the strncpy function should be used instead the strcpy function. However, since one cannot expect that the code to be always written correctly, there is a need for system solutions.
2. Buffer overflow exploits depend on an executable stack. One obvious solution is to make the stack segment non-executable; such kernel patches are available for Linux. This approach prevents buffer overflow exploits; however, it will create problems in the signal handling procedures. Signal handler returns in Linux require an executable stack. Furthermore, signal handlers are crucial in an operating system; thus, a temporary executable stack for signal handlers must be implemented. By removing stack execution from the system kernel, buffer overflow exploits can be prevented. However, this approach suffers from the code being non-portable, and operating system handling behavior is modified and may be unpredictable. Another approach is the PaX project. The goal of the PaX project is to research various defense mechanisms against the exploitation of software bugs that give an attacker arbitrary read/write access to the attacked task's address space. This class of bugs contains among others various forms of buffer overflow bugs (be they stack or heap based), user supplied format string bugs, and so on.
3. Buffer overflow exploits are possible on processors on which the stack grows down. By moving more of the data then a function’s local buffer can store, a return address can be overwritten. This situation cannot be achieved on the processors with the stack growing up because the return address has the lower address than the local buffer. Therefore, the strcpy function moves data to higher addresses and never reaches the return address. It can happen that some other part of the stack can be overwritten but not the return address. Therefore, it is impossible to jump to our shell code. Another solution would be to make the stack gown up.
4. Other solutions are implemented in compilers. A random extra field is placed on the stack when the function is called. After exiting from call, this field is checked for corruption. This solution can be used at compile time. However, we must recompile all existing programs, and problem arise when dealing with binaries and source code that is not available.
5. The solutions to be discussed in this article are implemented in the kernel and are based on the mandatory security and Linux Security Module (LSM) hooks.
   1. One solution is offered by the National Security Agency (NSA) and is called the Security Enhanced Linux (SE Linux)
   2. The other solution is offered by Ericsson Research Open Systems Lab and is called the Distributed Security Module (DSM). At the time of writing, the stable version is DSI 0.3. DSI 0.4 is the beta version with ongoing development work.

   Both solutions are similar in principle because they are based on the same hooks in the Linux kernel. However, they differ in the actual implementation, and the security policies, performance, and usability. We did not try to configure SE Linux for the purpose of this exercise since the policy setting is a bit more complex.

   For the purposes of this article, we will describe how the DSM module guards against buffer overflow exploits.

News iSeries Comes to the SMB Space [February 3, 2006] Big Blue gave its midrange systems a speed bump and added various efficiency measures to the line. Tutorials Deploying Windows Server 2003, Using ADS [February 2, 2006] If you're in the process of installing Windows Server 2003, being familiar with Automated Deployment Services is critical. Stats December 2005 Security Space Survey Results [January 10, 2006] Security Space's Web Server Survey breaks out Web server usage on the Internet for 86 domains. Data for the December survey was gathered from responses received from more than 16.7 million Web sites. About half are .com domains. Reviews ManageEngine Takes Manageability to New Levels [January 13, 2006] ManageEngine's OpManager delivers affordable, out-of-the-box management for a wide variety of devices and software applications, ranging from printers to database applications to server hardware.