Obviously, this may be of interest to authors of security software that aims to mitigate exploitation of 0-day: it should be possible to: 1) actively reserve memory regions referenced by such pointers to prevent allocation by an exploit. The additional address space fragmentation should not be a problem for most applications, but I have no data, so you might want to consider: 2) analyze various binaries for their use of magic values, and actively reserve only those memory regions referenced by such pointers. If that still causes problems in some applications: 3) white-/black-list applications for this mitigation.
If any of the authors of EMET are reading this, please let me know so I don't have to write you an email to make sure you have seen it for consideration as an added mitigation. Cheers, SkyLined On 21-06-2016 17:01, Berend-Jan Wever wrote: > (You can read all this information in more detail on > http://blog.skylined.nl) > > Software components such as memory managers often use magic values to > mark memory as having a certain state. These magic values can be used > during debugging to determine the state of the memory, and have often > (but not always) been chosen to coincide with addresses that fall > outside of the user-land address space on 32-bit versions of the > Operating System. This can help detect vulnerabilities by causing an > access violation when such magic value is used as a pointer as well as > mitigate exploitation of such vulnerabilities by making it impossible to > have this "poisoned" pointer refer allocated memory under the attacker's > control. > > For instance, Microsoft's C++ debugging runtime library initializes > stack memory to 0xCCCCCCCC. When an uninitialized object pointer is used > to read the value of a property or call a method of the object, this > reliably causes an access violation on 32-bit versions of Microsoft > Windows and prevents an easy path to exploitation. > > The Wikipedia article on magic values has a list containing some of the > values and when they are used. You will notice how all of the values > used on Windows have their high bit set (i.e. >= 0x80000000). As explain > earlier, this is because on 32-bit versions of Windows these addresses > cannot be used to allocate memory in user-land by default. Windows does > have a /3GB switch that allows you to change the upper limit for > user-land memory to 0xC0000000, but AFAIK this is not used very often > and still excludes a large number of magic values. > > Magic values on 64-bit OS-es > > On 64-bit architectures, there is no need to reserve part of the 32-bit > address space for kernel memory. Consequently, a 32-bit applications > running on 64-bit versions of Windows is able to allocate memory in > almost the entire 32-bit address range. This allows 32-bit applications > to allocate more memory, including at all addresses that these magic > values can reference. Ever since their introduction over 10 years ago, > Javascript heap-sprays in web-browsers in particular offers an attacker > the ability to finely control memory allocations and their content for > use in exploits. > > Proof-of-Concept > > Last year I stumbled upon a two different bugs in two different web > browsers where a magic value was used to mark memory which had not yet > been initialized. Both vulnerabilities allowed me to get the web > browsers to use the memory as a pointer before initializing it to a sane > value. using Javascript, I was able to allocate memory at the magic > value address the web browsers ended up using and store information at > this location that allowed me to exploit both of these two > vulnerabilities. These issues have both been address, so I can discuss > them in more detail. > > CVE-2014-1592 Firefox xul.dll!nsHtml5TreeOperation use of poisoned memory > > Mozilla 1088635 <https://bugzilla.mozilla.org/show_bug.cgi?id=1088635> > covers a bug in Firefox that could it to use data from a freed and > "poisoned" object through specially crafted HTML, which resulted in > access violations around address |0x5a5a5a5a| on x86 systems. The memory > used to back the object was marked with this magic value after it was > freed. Because this magic value resulted in an address can be allocated > even on 32-bit versions of Windows, I suggested in Mozilla 1182002 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1182002> that the value > get updated with something that makes it a little harder to exploit. > This and other reasons for changing the magic values, led to magic > values being changed to |0xe4e4e4e4| for uninitialized memory and > |0xe5e5e5e5| for freed memory. > > verifier!AVrfDebugPageHeapAllocate incorrect memory initialization a.k.a > Google Chrome use of uninitialized FLS pointer > > In August last year, I found what appear to be a thread-safety > vulnerability in Google Chrome when handling audio data, that could lead > to use of an uninitialized pointer. This issue is only visible when > running Chrome with page heap enabled, as the memory used to store the > pointer appears to be set to 0x00000000 after allocation when page heap > is not enabled. This means this NULL pointer will not be used by the > code to reference memory. However, when running Chrome with page heap > enabled, the pointer will be initialized to 0xD0D0D0D0 and gets used in > code that allows at least freeing of arbitrary memory pointers. > > After doing a more thorough analysis, Ricky Zhou explained to me in the > Chromium bug > <https://bugs.chromium.org/p/chromium/issues/detail?id=525288> that the > issue is not in Chromium, but in |verifier.dll|. This DLL is used to > implement page heap on Windows. The problem is that in > |verifier!AVrfDebugPageHeapAllocate|, the |HEAP_ZERO_MEMORY| flag is > sometimes ignored, which in this case caused the memory to get > initialized with the wrong value. I reported this issue to Microsoft at > the end of October last year and after getting the MSRC case number > 31596, I never heard back from them again. > > Mitigating this type of attack > > While working on these issues, I realized that this type of attack is > easy to mitigate by making sure the magic values point to memory that > has been reserved and marked inaccessible. That way there is no risk of > an attacker allocating the memory with data under his/her control for > use in an exploit: whenever the application would attempt to access > memory using a magic value as a pointer, this would reliably cause an > access violation. > > Having a memory allocation at the various addresses represented by > common magic values fragments the address space, reducing the largest > possible continuous allocation and the total amount of memory available > to the application. But most 32-bit applications do not depend on being > able to allocate such large chunks of memory for normal operations, as > this is impossible on 32-bit versions of Windows. Regardless, should one > want to prevent this fragmentation, and at the same time organize the > magic values to be more coherent and intuitive to developers, it might > be useful to create an API that can be used to generate the magic > values, and have the generated values be more similar, closer together > and/or located at either edge of the free memory above address > |0x80000000|. > > I have suggested adding mitigations such as a special API that allows an > application to request magic values that are guaranteed to point to > reserved memory to MSRC and they responded in November 2015 that they > forwarded it to the Windows team for their consideration. > > Cheers, > > SkyLined > > http://twitter.com/berendjanwever > http://blog.skylined.nl _______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
