locked
Latest EMET and “Bottom-up Rand” allocations RRS feed

  • Question

  • Does anyone know what the “Bottom-up Rand” is mitigating [1]? Perhaps threats that use a loose process DACL (VM_PROCESS_READ, VM_PROCESS_WRITE and friends) [2] combined with deterministic base addresses? That is, a bad guy opening a process and reading a secret (such as a key, mutex name, or event name) at a known location?

    Jeff

    [1] http://blogs.technet.com/b/srd/archive/2011/05/18/new-version-of-emet-is-now-available.aspx
    [2] http://msdn.microsoft.com/en-us/library/ms684880(v=vs.85).aspx



    • Edited by Jeffrey Walton Friday, May 20, 2011 9:52 AM Added link to announcement
    Friday, May 20, 2011 6:05 AM

All replies

  • Upvoted for interesting question. 
    My idea of a party is a virtualization server and a room of TechNet DVDs
    Friday, May 20, 2011 4:34 PM
  • From the user's guide...
     
    ---
    Bottom-up randomization
    This mitigation randomizes (8 bits of entropy) the base address of bottom-up allocations (including heaps, stacks, and other memory allocations) once EMET has enabled this mitigation but not for previous allocations.

    --

    In few words, once in place it will randomize things a little bit. Please note this mitigation will influence future heaps, stacks, etc... not for already requested ones.

    Friday, May 20, 2011 6:39 PM
  • Hey Jeff,

    The Windows heap allocates/reuses in such a way that it can sometimes be very predictable. Many remote exploits rely on a predictable address for jumping/sliding to executable code. Randomizing the base address of bottom-up memory allocations makes it slightly less predictable. To be perfectly honest I don't think it will not have much of an impact.

    Best Wishes,

    -David Delaune

    Sunday, May 22, 2011 6:52 PM
  • The BottomupRand mitigation is not compatible with Windows Live Messenger. Whenever I tried to open a chat window, WLM crashed. Turning off this mitigation made it work.

    Friday, May 27, 2011 10:17 AM