ACM Home Page
Please provide us with feedback. Feedback
On the effectiveness of address-space randomization
Full text PdfPdf (194 KB)
Source Conference on Computer and Communications Security archive
Proceedings of the 11th ACM conference on Computer and communications security table of contents
Washington DC, USA
SESSION: Operating systems security table of contents
Pages: 298 - 307  
Year of Publication: 2004
ISBN:1-58113-961-6
Authors
Hovav Shacham  Stanford University
Matthew Page  Stanford University
Ben Pfaff  Stanford University
Eu-Jin Goh  Stanford University
Nagendra Modadugu  Stanford University
Dan Boneh  Stanford University
Sponsors
SIGSAC: ACM Special Interest Group on Security, Audit, and Control
ACM: Association for Computing Machinery
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 14,   Downloads (12 Months): 290,   Citation Count: 24
Additional Information:

abstract   references   cited by   index terms   collaborative colleagues  

Tools and Actions: Review this Article  
Save this Article to a Binder    Display Formats: BibTex  EndNote ACM Ref   
DOI Bookmark: Use this link to bookmark this Article: http://doi.acm.org/10.1145/1030083.1030124
What is a DOI?

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.


REFERENCES

Note: OCR errors may be found in this Reference List extracted from the full text article. ACM has opted to expose the complete List rather than only correct and linked references.

 
1
Aleph One. Smashing the stack for fun and profit. Phrack Magazine 49(14), Nov. 1996. http://www.phrack.org/phrack/49/P49-14
 
2
Anonymous. Once upon a free(). Phrack Magazine 57(9), Aug. 2001. http://www.phrack.org/phrack/57/p57-0x09
 
3
Apache Software Foundation. The Apache HTTP Server project. http://httpd.apache.org
 
4
Apache Software Foundation. ASF bulletin 20020617, June 2002. http://httpd.apache.org/info/security_bulletin_20020617.txt
 
5
Apache Software Foundation.ASF bulletin 20020620, June 2002. http://httpd.apache.org/info/security_bulletin_20020620.txt
6
 
7
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.
 
8
Bulba and Kil3r. Bypassing StackGuard and StackShield. Phrack Magazine 56(5), May 2000. http://www.phrack.org/phrack/56/p56-0x05
 
9
CERT, June 2002. http://www.cert.org/advisories/CA-2002-17.html
 
10
CERT. CERT advisory CA-2002-08: Multiple vulnerabilities in Oracle servers, Mar. 2002. http://www.cert.org/advisories/CA-2002-08.html
 
11
CERT. CERT advisory CA-2003-04: MS-SQLServer worm, Jan. 2003. http://www.cert.org/advisories/CA-2003-04.html
 
12
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.
 
13
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.
 
14
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.
 
15
T. Durden. Bypassing PaX ASLR protect on. Phrack Magazine 59(9),June 2002. http://www.phrack.org/phrack/59/p59-0x09
 
16
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
 
17
FedCIRC. BotNets: Detect on and mitigation, Feb. 2003. http://www.fedcirc.gov/library/documents/botNetsv32.doc
 
18
 
19
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.
 
20
M. Kaempf. Vudo malloc tricks. Phrack Magazine 57(8), Aug. 2001. http://www.phrack.org/phrack/57/p57-0x08
21
 
22
D. Litchfield. Hackproofing Oracle Application Server, Jan. 2002. http://www.nextgenss.com/papers/hpoas.pdf
 
23
 
24
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
 
25
 
26
PaX Team. PaX. http://pax.grsecurity.net
 
27
PaX Team. PaX address space layout randomization (ASLR). http://pax.grsecurity.net/docs/aslr.txt
 
28
Scut/team teso. Exploiting format string vulnerabilities. http://www.team-teso.net 2001.
 
29
Solar Designer. StackPatch. http://www.openwall.com/linux
 
30
Solar Designer."return-to-libc" attack. Bugtraq, Aug. 1997.
 
31
 
32
Vendicator. StackShield. http://www.angelfire.com/sk/stackshield
 
33
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.
 
34
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.
 
35
M. Zalewski. Remote vulnerability in SSH daemon CRC32 compression attack detector, Feb. 2001. http://www.bindview.com/Support/RAZOR/Advisories/2001/adv_ssh1crc.cfm

CITED BY  24
 
 
 
 
 

Collaborative Colleagues:
Hovav Shacham: colleagues
Matthew Page: colleagues
Ben Pfaff: colleagues
Eu-Jin Goh: colleagues
Nagendra Modadugu: colleagues
Dan Boneh: colleagues