address space layout randomization

The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities
by Justin Schuh
Published 20 Nov 2006

Although these mechanisms are a step in the right direction, heap overflows can still be exploited by manipulating application data rather than heap structures. Address Space Layout Randomization When an application is launched in most contemporary operating systems, the loader organizes the program and required libraries into memory at the same locations every time. Customarily, the program stack and heap are put in identical locations for each program that runs. This practice is useful for attackers exploiting a memory corruption vulnerability; they can predict with a high degree of accuracy the location of key data structures and program components they want to manipulate or misuse. Address space layout randomization (ASLR) technologies seek to remove this advantage from attackers by randomizing where different program components are loaded at in memory each time the application runs.

…

In general, this protection mechanism makes exploiting protected systems more difficult, but sophisticated attackers can usually find a way around it. With a little creativity, the existing code can be spliced, diced, and coerced into serving the attacker’s purpose. Address Space Layout Randomization Address space layout randomization (ASLR) is a technology that attempts to mitigate the threat of buffer overflows by randomizing where application data and code is mapped at runtime. Essentially, data and code sections are mapped at a (somewhat) random memory location when they are loaded. Because a crucial part of buffer overflow exploitation involves overwriting key data structures or returning to specific places in memory, ASLR should, in theory, prevent reliable exploitation because attackers can no longer rely on static addresses.

…

See ASP (Active Server Pages) Active X controls, 749, 753-754 COM (Component Object Model), security, 749-754 kill bit, 752 signing, 750 site-restricted controls, 752 threading, 753 ActiveX Data Objects (ADO), 1113-1115 address space layout randomization (ASLR). See ASLR (address space layout randomization) addresses IP addresses, 832-834 maintaining state with, 1029-1030 subnet addresses, 834 AdjustTokenGroups( ) function, 643 AdjustTokenPrivileges( ) function, 643 ADO (ActiveX Data Objects), 1113-1115 ADT (abstract data type), stacks, 169 Age header field (HTTP), 1018 Aitel, Dave, 158 AIX, 460 AJAX (Asynchronous JavaScript and XML), 1085 algorithms analyzing, CC (code comprehension), 116 encryption, 41-42 block ciphers, 42 common vunerabilities, 43-45 exchange algorithms, 43 IV (initialization vector), 42 stream ciphers, 42 hashing algorithms, 326 software design, 26-27 alloc( ) function, 318 allocating 0 bytes, 370-371 allocation functions, auditing, 369-377 allocation-check-copy (ACC) logs.

Engineering Security
by Peter Gutmann

scid=kb;en-us;307091. [276] “Local Administrator/Power User Non support of Patching/UAC Hall of Shame”, http://www.threatcode.com/. [277] “The Security Cost of Cheap User Interaction”, Rainer Bőhme and Jens Grossklags, Proceedings of the 2011 New Security Paradigms Workshop (NSPW’11), September 2011, to appear. [278] “Security in Longhorn: Focus on Least Privilege”, Keith Brown, April 2004, http://msdn2.microsoft.com/en-us/library/aa480194.aspx. [279] “Microsoft: Vista feature designed to ‘annoy users’”, Tom Espiner, 11 April 2008, http://news.zdnet.com/2100-9590_22-197085.html. [280] “Data Execution Prevention”, MSDN, http://msdn.microsoft.com/enus/library/aa366553%28VS.85%29.aspx. [281] “Address Space Layout Randomization in Windows Vista”, Michael Howard, 26 May 2006, http://blogs.msdn.com/b/michael_howard/archive/2006/05/26/address-space-layout-randomization-in-windowsvista.aspx. [282] “DEP / ASLR Neglected in Popular Programs”, Carsten Eiram / Secunia, 1 July 2010, http://secunia.com/blog/105. [283] “Top Apps Largely Forgo Windows Security Protections”, Brian Krebs, 1 July 2010, http://krebsonsecurity.com/2010/07/top-apps-largely-forgowindows-security-protections/.

…

TrustZone is accessed from supervisor mode via secure monitor call (SMC) instructions. As with other security products that were secure by executive fiat rather than by actual practice, the TrustZone kernel contained no security mitigations like DEP (data execution prevention), ASLR (address space layout randomization), non-executable heap or stack, or anything else that’s been applied in mainstream OSes for the last decade or so. Combined with unsafe programming practices like the use of strncpy(), it was possible to “exploit like it’s 1999” [48]. Finding various exploits 60 Making this even more apropos is the fact that Drew works in forensics and not cryptography. 248 Threats inside the trusted kernel was relatively simple, and at that point all of the cryptography became irrelevant.

Fancy Bear Goes Phishing: The Dark History of the Information Age, in Five Extraordinary Hacks
by Scott J. Shapiro

Before the Morris Worm, the internet community naively believed that malicious behavior would be minor and outbreaks could be contained. After the Worm, the community realized that an end-to-end internetworking system can survive only if they hardened the end points. Harden the end points they did. Consider how Linux dealt with buffer overflows. In 2002, Linux implemented ASLR, short for “address space layout randomization.” The stack, that temporary scratch pad that Robert Morris Jr. used to implant malicious code on Finger servers, usually sits at the very top of the computer’s memory space. When ASLR is turned on, the operating system moves the stack to a random part of the memory space. Thus ASLR hides the stack to prevent hackers from injecting code through overflows.