ABSTRACT
Address-space randomization is a technique used to fortify systems against buffer overflow attacks. The idea is to introduce artificial diversity by randomizing the memory location of certain system components. This mechanism is available for both Linux (via PaX ASLR) and OpenBSD. We study the effectiveness of address-space randomization and find that its utility on 32-bit architectures is limited by the number of bits available for address randomization. In particular, we demonstrate a <i>derandomization attack</i> that will convert any standard buffer-overflow exploit into an exploit that works against systems protected by address-space randomization. The resulting exploit is as effective as the original exploit, although it takes a little longer to compromise a target machine: on average 216 seconds to compromise Apache running on a Linux PaX ASLR system. The attack does not require running code on the stack.
We also explore various ways of strengthening address-space randomization and point out weaknesses in each. Surprisingly, increasing the frequency of re-randomizations adds at most 1 bit of security. Furthermore, compile-time randomization appears to be more effective than runtime randomization. We conclude that, on 32-bit architectures, the only benefit of PaX-like address-space randomization is a small slowdown in worm propagation speed. The cost of randomization is extra complexity in system support.
- Aleph One. Smashing the stack for fun and profit. Phrack Magazine 49(14), Nov. 1996. http://www.phrack.org/phrack/49/P49-14]]Google Scholar
- Anonymous. Once upon a free(). Phrack Magazine 57(9), Aug. 2001. http://www.phrack.org/phrack/57/p57-0x09]]Google Scholar
- Apache Software Foundation. The Apache HTTP Server project. http://httpd.apache.org]]Google Scholar
- Apache Software Foundation. ASF bulletin 20020617, June 2002. http://httpd.apache.org/info/security_bulletin_20020617.txt]]Google Scholar
- Apache Software Foundation.ASF bulletin 20020620, June 2002. http://httpd.apache.org/info/security_bulletin_20020620.txt]]Google Scholar
- E. G. Barrantes, D. H. Ackley, T. S. Palmer, D. Stefanovic, and D. D. Zovi. Randomized instruction set emulation to disrupt binary code injection attacks. In Proc. 10th ACM Conf. Comp. and Comm. Sec. CCS 2003. pages 281--9. ACM Press, Oct. 2003.]] Google ScholarDigital Library
- S. Bhatkar, D. DuVarney, and R. Sekar. Address obfuscation: An efficient approach to combat a broad range of memory error exploits. In V. Paxson, editor, Proc. 12th USENIX Sec. Symp., pages 105--20. USENIX, Aug. 2003.]] Google ScholarDigital Library
- Bulba and Kil3r. Bypassing StackGuard and StackShield. Phrack Magazine 56(5), May 2000. http://www.phrack.org/phrack/56/p56-0x05]]Google Scholar
- CERT, June 2002. http://www.cert.org/advisories/CA-2002-17.html]]Google Scholar
- CERT. CERT advisory CA-2002-08: Multiple vulnerabilities in Oracle servers, Mar. 2002. http://www.cert.org/advisories/CA-2002-08.html]]Google Scholar
- CERT. CERT advisory CA-2003-04: MS-SQLServer worm, Jan. 2003. http://www.cert.org/advisories/CA-2003-04.html]]Google Scholar
- J. S. Chase, H. M. Levy, M. Baker-Harvey, and E. D. Lazowska. How to use a 64-bit address space. Technical Report 92-03-02, University of Washington, Department of Computer Science and Engineering, March 1992.]]Google Scholar
- C. Cowan, S. Beattie, J. Johansen, and P. Wagle. PointGuard: Protecting pointers from buffer over flow vulnerabilities. In V. Paxson, editor, Proc. 12th USENIX Sec. Symp., pages 91--104. USENIX, Aug. 2003.]] Google ScholarDigital Library
- C. Cowan, C. Pu, D. Maier, H. Hinton, P. Bakke, S. Beattie, A. Grier, P. Wagle, and Q. Zhang. StackGuard: Automatic detection and prevention of buffer-overflow attacks. In A. Rubin, editor, Proc. 7th USENIX Sec. Symp., pages 63--78. USENIX, Jan. 1998.]] Google ScholarDigital Library
- T. Durden. Bypassing PaX ASLR protect on. Phrack Magazine 59(9),June 2002. http://www.phrack.org/phrack/59/p59-0x09]]Google Scholar
- H. Etoh and K. Yoda. ProPolice: Improved stack-smashing attack detect on. IPSJ SIGNotes Computer SECurity 014(025), Oct.2001. http://www.trl.ibm.com/projects/security/ssp]]Google Scholar
- FedCIRC. BotNets: Detect on and mitigation, Feb. 2003. http://www.fedcirc.gov/library/documents/botNetsv32.doc]]Google Scholar
- S. Forrest, A. Somayaji, and D. Ackley. Building diverse computer systems. In J. Mogul, editor, Proc. 6th Work. Hot Topics in Operating Sys. HotOS 1997. pages 67--72. IEEE Computer Society, May 1997.]] Google ScholarDigital Library
- D. Geer, R. Bace, P. Gutmann, P. Metzger, C. Pfleeger, J. Quarterman, and B. Schneier. Cybersecurity: The cost of monopoly--how the dominance of Microsoft 's products poses a risk to security. Technical report, Comp. and Comm. Ind. Assn., 2003.]]Google Scholar
- M. Kaempf. Vudo malloc tricks. Phrack Magazine 57(8), Aug. 2001. http://www.phrack.org/phrack/57/p57-0x08]]Google Scholar
- G. S. Kc, A. D. Keromytis, and V. Prevelakis. Countering code-injection attacks with instruction-set randomization. In Proc. 10th ACM Conf. Comp. and Comm. Sec., pages 272--80. ACM Press, Oct. 2003.]] Google ScholarDigital Library
- D. Litchfield. Hackproofing Oracle Application Server, Jan. 2002. http://www.nextgenss.com/papers/hpoas.pdf]]Google Scholar
- L. McLaughlin. Bot software spreads, causes new worries. IEEE Distributed Systems Online 5(6), June 2004. http://csdl.computer.org/comp/mags/ds/2004/06/o6001.pdf]] Google ScholarDigital Library
- Nergal. The advanced return-nto-lib(c)exploits (PaX case study). Phrack Magazine 58(4), Dec. 2001. http://www.phrack.org/phrack/58/p58-0x04]]Google Scholar
- D. Patterson. A simple way to estimate the cost of downtime. In A. Couch, edtor, Proc. 16th Systems Administration Conf. --LISA 2002 pages 185--8. USENIX, Nov. 2002.]] Google ScholarDigital Library
- PaX Team. PaX. http://pax.grsecurity.net]]Google Scholar
- PaX Team. PaX address space layout randomization (ASLR). http://pax.grsecurity.net/docs/aslr.txt]]Google Scholar
- Scut/team teso. Exploiting format string vulnerabilities. http://www.team-teso.net 2001.]]Google Scholar
- Solar Designer. StackPatch. http://www.openwall.com/linux]]Google Scholar
- Solar Designer."return-to-libc" attack. Bugtraq, Aug. 1997.]]Google Scholar
- S. Staniford, V. Paxson, and N. Weaver. How to own the Internet in your spare time. In D. Boneh, editor, Proc. 11th USENIX Sec. Symp., pages 149--67. USENIX, Aug. 2002.]] Google ScholarDigital Library
- Vendicator. StackShield. http://www.angelfire.com/sk/stackshield]]Google Scholar
- J. Xu, Z. Kalbarczyk, and R. Iyer. Transparent runtime randomization for security. In A. Fantechi, editor, Proc. 22nd Symp. on Reliable Distributed Systems --SRDS 2003 pages 260--9. IEEE Computer Society, Oct. 2003.]]Google Scholar
- C. Yarvin, R. Bukowski, and T. Anderson. Anonymous RPC: Low-latency protection in a 64-bit address space. In Proc. USENIX Summer 1993 Technical Conf., pages 175--86. USENIX, June 1993.]]Google Scholar
- M. Zalewski. Remote vulnerability in SSH daemon CRC32 compression attack detector, Feb. 2001. http://www.bindview.com/Support/RAZOR/Advisories/2001/adv_ssh1crc.cfm]]Google Scholar
Index Terms
On the effectiveness of address-space randomization
Recommendations
Breaking Kernel Address Space Layout Randomization with Intel TSX
CCS '16: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications SecurityKernel hardening has been an important topic since many applications and security mechanisms often consider the kernel as part of their Trusted Computing Base (TCB). Among various hardening techniques, Kernel Address Space Layout Randomization (KASLR) ...
Address-space layout randomization using code islands
Best papers of the Sec Track at the 2006 ACM SymposiumAddress-Space Layout Randomization (ASLR) techniques prevent intruders from locating target functions by randomizing the process layout. Prior ASLR techniques defended against single-target brute force attacks, which work by locating a single, ...
Revisiting address space randomization
ICISC'10: Proceedings of the 13th international conference on Information security and cryptologyAddress space randomization is believed to be a strong defense against memory error exploits. Many code and data objects in a potentially vulnerable program and the system could be randomized, including those on the stack and heap, base address of code, ...
Comments