Fixing ASLR Leaks

TL;DR

Address Space Layout Randomisation (ASLR) is a cyber security technique that makes it harder for attackers to predict where important parts of your software are loaded in memory. If an attacker can *leak* information about these addresses, they can bypass ASLR and potentially take control of your system. This guide explains how to identify and mitigate common info leak vulnerabilities.

Understanding the Problem

ASLR works by randomly positioning key data areas – like the base of libraries or the stack – each time a program runs. An ‘info leak’ happens when a program unintentionally reveals these memory addresses to an attacker. Common leaks include:

• Direct Address Exposure: Printing addresses directly in error messages, logs, or debugging output.
• Relative Leaks: Revealing the offset of data within a known module (e.g., distance between two functions). Attackers can combine this with a known base address to calculate absolute addresses.
• Timing Attacks: Observing how long certain operations take, which can indirectly reveal address information.

Solution Guide

1. Code Review for Direct Address Exposure
   • Carefully examine your code for any instances where memory addresses are printed or logged. This includes debugging statements that might be left in production code.
   • Look for uses of printf, logging functions, and custom output routines.
   • Example: Avoid printing the address of a variable directly:

     // Bad - leaks address information
     printf("Variable value at %p is %dn", &my_variable, my_variable);
     

     // Good - prints only the value
     printf("Variable value is %dn", my_variable);
     

2. Disable Debug Symbols in Production
   • Debug symbols contain address information that can be useful to attackers. Ensure they are stripped from your production binaries.
   • For GCC, use the -s flag during linking:

     gcc -o my_program my_source.c -s
     

3. Address Sanitizer (ASan) and Memory Sanitizer (MSan)
   • These tools can detect memory errors, including leaks that might indirectly reveal address information. Run your program under ASan/MSan during testing.

     gcc -fsanitize=address my_source.c -o my_program
     ./my_program
     

4. Relative Leak Mitigation
   • Avoid calculating and using offsets between addresses unless absolutely necessary. If you must use them, consider randomising these offsets as well (though this is complex).
   • If relative leaks are unavoidable, make the calculation dependent on a secret value known only to your application.

     // Example - adding a secret offset
     int relative_offset = function2_address - function1_address + secret_key;
     

5. Stack Canaries
   • Stack canaries are values placed on the stack to detect buffer overflows, which can sometimes lead to info leaks. Ensure they are enabled in your compiler settings (usually default).

     gcc -fstack-protector my_source.c -o my_program
     

6. Regular Security Audits and Penetration Testing
   • Have your code reviewed by cyber security professionals to identify potential vulnerabilities, including info leaks.
   • Conduct penetration testing to simulate real-world attacks and uncover weaknesses.

Further Considerations

Keep your compiler and libraries up to date as they often include security fixes that address ASLR bypass vulnerabilities. Consider using a modern operating system with strong ASLR implementation.