As we mentioned previously, this year we had a lot of great interviews at Hack in the Box Amsterdam. One of them was with Steven Seeley, a senior security consultant at Stratsec, who identified a few interesting vulnerabilities.
Much of his research has focused on the Windows 7 and Windows 8 heap managers, their security holes, and mitigation strategies that could ensure that the flaws are not easily exploitable.
Steven Seeley: My name is Steven Seeley. I’m a senior security consultant at Stratsec. My job involves penetration testing of client systems and performing security research. Today’s topic will cover the application specific heap meta data attacks that I have been researching.
Softpedia: Can you tell us a few words about the Windows 7 allocator?
Steven Seeley: I think it’s very hard to sum up in a few words because it’s such a complex set of data structures and algorithms, but in terms of security, we’ve seen a serious evolution in strengthened security from the birth of Windows 7 and specially evolving now to Windows 8.
We’ve seen a lot of new changes and variations that really, really prevent a lot of corner case attacks against the Windows heap manager.
Softpedia: So what have you found? What is this “ghost” in the Windows allocator?
Steven Seeley: Basically, when looking at the way that the Windows 7 allocator actually works, I noticed (along with other researchers) that the frontend allocator is using a predictable location to determine where the next chunk will be allocated from and as such, utilizes a first in first out (FIFO) algorithm when also freeing.
This is essentially exploited via other techniques currently available, such as the FreeEntryOffset overwrite technique.
What I’ve actually came up with is the idea that if you can match this FreeEntryOffset value with the NextOffset of the current chunk, then you can force the allocator to actually keep returning the same chunk address back because there is no sanity check during an allocation against the chunk header.
This leads to the ability of an attacker to allocate a heap chunk as an object type and overwrite that chunk, thus, damaging a vftable with controlled, malicious data.
At that point, as an attacker, you can essentially control any function that is called from that object to which, they can then take control of the processes execution path.
In terms of the Windows 8 frontend allocator changes, we’ve seen some new mitigations put in place. The most prevalent being randomized allocation patterns.
Recently, different researchers looked at the ways in which the allocation process can be exploited. One idea that stood out, was the possibility of having an overwrite target the “UserBlocks” header.
So instead of targeting chunks, we’ll now be shifting focus to more predictable data locations, keeping in mind that as long as an attacker can influence an allocation from a buffer overflow reliably, they will defeat modern heap mitigations.
Softpedia: Windows 8 has only been recently launched. How come you managed to discover so much in such a short amount of time?
Steven Seeley: Well, on the face of it, it appears like a lot of discoveries, but I have simply adopted a new method of exploitation under the windows 7 heap manager by extending an already existing attack.
Additionally, I have simply refined Chris Valasek's UserBlocks overwrite attack and detailed how the attack would work from a practical sense. I guess I don’t get too much sleep. I just found it an interesting challenge and I certainly see the motivation for such changes in the latest heap manager from when I started with Windows XP SP1.
Both exploitation attacks are somewhat hypothetical and require a special corner case in which the exploitation primitive can be (ab)used.
Softpedia: Does Microsoft know about it? Did you contact them?
Steven Seeley: I did not contact Microsoft regarding the attacks, as Windows 8 prevents the offset match attack already. Additionally, the observational idea of the UserBlocks overwrite attack that was released by Chris Valasek in his presentation at Syscan was already public knowledge at the time.
Having said that, I simply provided some context to how the technique should probably work. But as time progresses and the technique is applied to real applications, the technique will no doubt be refined further, thus, inadvertently pushing Microsoft to introduce further mitigations in the heap manager.
Softpedia: Do you think they will do anything about this? What can they do about it?
Steven Seeley: I would imagine a prototype mitigation would already be in design against this vector. There are a couple of mitigation strategies they could take.
Probably one of the most important mitigations they could do is to enforce the guard on the UserBlock header for every UserBlocks and have it validated during every allocation. I’m not sure if that would reduce performance for the heap manager itself, but I think it would be the right approach.
Another option maybe, if somehow they could work out a way to also randomize the position of where the UserBlocks are in the LFH Block zone, would also significantly disadvantage these kinds of attacks.
Softpedia: How can this be exploited?
Steven Seeley: I don't think the suggested mitigations could be exploited with a degree of reliability in any context. Having said that, with sufficient research and time, a clever attacker may still defeat the said mitigations.
Softpedia: So users aren’t exposed to any risks, but you want to show the potential dangers that hide behind this?
Steven Seeley: Risk is measured based on the context of a vulnerability by applying it to its environment (in this case, platform). However, with the introduction of Windows 8, the level of risk exposure to users regarding heap exploitation has certainly been reduced. Any exploitation attempts now will most likely not be reliable enough for vast exploitation.
Softpedia: So the main solution would be for Microsoft to handle the issue.
Steven Seeley: Yes, the main solution is for Microsoft to introduce additional mitigation(s) that would prevent the ability for an attacker to overwrite the Userblocks header.
Softpedia: Have you seen anything in that direction?
Steven Seeley: No.
Softpedia: Is there anything else you would like to add?
Steven Seeley: The continuous introduction of randomized memory, whether that be ASLR or heap randomization certainly places heavy strain on advanced exploit writers.
Where possible, other memory allocators created by third-party platform developers need to take a similar approach to security.
Steven Seeley's presentation from HITB 2012 Amsterdam is available here.
Via: Softpedia Exclusive Interview: Steven Seeley on the Ghost in Windows Allocator
Tidak ada komentar:
Posting Komentar