lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <65a701cd-fdf3-6de7-2dc3-838c03aa5892@gmail.com> Date: Wed, 22 Jun 2016 20:02:37 +0200 From: Berend-Jan Wever <berendjanwever@...il.com> To: fulldisclosure@...lists.org, bugtraq@...urityfocus.com Subject: Re: [FD] Magic values in 32-bit processes on 64-bit OS-es and how to exploit them I've released a Proof-of-Concept html page that uses Javascript typed arrays in 32-bit Chrome and Firefox on 64-bit Windows to allocated address 0xDEADBEEF and store the value 0xBADC0DED there. You can find this and details on the implementation at http://blog.skylined.nl/20160622001.html. That page also contains a write-up on CVE-2014-1736; a vulnerability in 32-bit Chrome on 64-bit Windows that allows arbitrary read&write that was caused by the fact that that 64-bit Windows allows allocations of memory at address 0x80000000 and up. On 21-06-2016 19:45, Berend-Jan Wever wrote: > 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/
Powered by blists - more mailing lists