9

I have been hearing this word the whole day long. Can any one give me a brief intro? How does it differ from ASLR?

Polynomial
  • 132,208
  • 43
  • 298
  • 379
kiran
  • 193
  • 6
  • 1
    It's a Microsoft marketing gimmick. The original Windows ASLR implementation had some shortcomings. The latest version of Windows contains improvements to try to address some of those problems and make ASLR even stronger. But at the end of the day, it's still just ASLR, just done a bit better. – D.W. Nov 05 '12 at 19:55

1 Answers1

11

HiASLR is a term that represents the improved ASLR in Windows 8. The "hi" part refers to the improvement in entropy generated by the increased number of random bits that the stack and heap can be offset by. Microsoft also included randomisation to various system heaps, system tables, etc. to make the possibility of using a NOP sled or information leak more difficult.

The following table is taken from Ken Johnson and Matt Miller's "Exploit Mitigation Improvements in Win8" talk at BlackHat USA 2012.

Entropy (in bits)      |    Windows 7    |           Windows 8         |
per region             | 32-bit | 64-bit | 32-bit | 64-bit | 64-bit HE |
-----------------------|--------+--------|--------+--------|-----------|
Bottom-up allocations* | 0      | 0      | 8      | 8      | 24        |
    Stacks             | 14     | 14     | 17     | 17     | 33        |
    Heaps              | 5      | 5      | 8      | 8      | 24        |
Top-down allocations*  | 0      | 0      | 8      | 17     | 17        |
    PEBs / TEBs        | 4      | 4      | 8      | 17     | 17        |
EXE images             | 8      | 8      | 8      | 17**   | 17**      |
DLL images             | 8      | 8      | 8      | 19**   | 19**      |
Non-ASLR DLL images*   | 0      | 0      | 8      | 8      | 24        |

* opt-in, either via flag in module or system option
** 64-bit DLLs based below 4GB get 14 bits, EXEs below 4GB get 8 bits.

Note that the final column represents High Entropy, which is the official name for HiASLR.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • 1
    Why was it ever "low entropy"? Who thought that was a good idea? – rook Nov 05 '12 at 16:57
  • @Rook There were limitations in the implementation to maintain backward compatibility with old memory management operations used by various drivers. Also, the HE method has a side-effect of forcing ASLR on for all modules in all processes, which can crash old legacy apps. – Polynomial Nov 05 '12 at 21:14
  • i think you are confusing `ForceASLR` with High Entropy ASLR. related: http://blogs.msdn.com/b/ie/archive/2012/03/12/enhanced-memory-protections-in-ie10.aspx – rook Nov 05 '12 at 22:41
  • @Rook Ah, you're right, I misunderstood. I'd heard somewhere that the high entropy flag requires ForceASLR to be enabled, but it looks like that's not the case. – Polynomial Nov 06 '12 at 06:59
  • @polynomial Thanks for editing my question . Does increasing the entropy requires increasing the virtual memory space over which randomization is done ? I have read in the wikipedia article that increasing entropy can be done by either increasing the code space or decreasing the period over which entropy is imparted.Does it affect performance in anyway (as vm is increased) – kiran Nov 06 '12 at 11:44
  • 2
    @kiran The randomisation requires a negligible amount of extra physical memory to store the offsets, as part of the kernel structures that represent processes, modules, threads, heaps, etc. In the big picture, it's a minuscule amount of memory. Remember that ASLR randomises the *virtual* memory space of processes, and virtual memory pages are mapped, so two pages at `0102b000` and `8f000000` in the same process might be mapped to `7fffffff:0e000000` and `7fffffff:0e001000` in physical memory - no extra memory is needed. – Polynomial Nov 06 '12 at 11:53
  • 1
    @kiran The complexity comes in when randomising heap allocations, since the virtual memory space may become fragmented if lots of small allocations and deallocations are made. In reference to the legacy problem, some badly written non-ASLR-aware applications assume that two heap allocations made in sequence are given predictable contiguous virtual addresses (which was common on Windows XP), and crash when ASLR is force-enabled. – Polynomial Nov 06 '12 at 11:57
  • 1
    @kiran There are some memory overheads in kernel ASLR, but HiASLR is about user-mode ASLR. Kernel ASLR doesn't deal with virtual addresses, so any randomisation has to either map an allocation to a random physical address (potentially causing physical memory fragmentation problems) or allocate more memory and offset the "real" allocation at a random position in that memory block. The latter is common in stack randomisation. There are tricks to make kernel heap randomisation more manageable (e.g. size-category allocation pools) but these are beyond the scope of this question. – Polynomial Nov 06 '12 at 12:02
  • I'm wondering what is meant with `Non-ASLR DLL images` - why do they get more entropy than `DLL images` (which are presumably those which have the ASLR flag set?)? – Voo Sep 02 '15 at 15:40
  • @Voo I believe what "Non-ASLR DLL images (opt-in)" refers to is DLLs without the NX compatible flag in their header (i.e. no compile-time support) but with the opt-in mitigations enabled for the process, via one of the options listed in slide 39. – Polynomial Sep 02 '15 at 15:48
  • @Polynomial So basically if I compile my dlls *without* /DYNAMICBASE and then force it on via the exe or the registry setting, I get an additional 5 bit entropy for free? How weird. Why? Backcomp seems unlikely (any dll that can handle 19bit ASLR should work with 24bit too). – Voo Sep 02 '15 at 16:00
  • 1
    @Voo Come to think of it, I don't understand that one either. I've emailed Matt Miller to see if I can get some clarification. – Polynomial Sep 02 '15 at 16:20