HPE Software is now Micro Focus
HPE Software is now Micro Focus
Security Research

There and back again: a journey through bounty award and disclosure

There and back again: a journey through bounty award and disclosure


In February, 2015, we announced a team of researchers from the HP Zero Day Initiative won $125K from the Microsoft Mitigation Bypass Bounty and Blue Hat Bonus for Defense. Today at the RECon conference in Montreal, the team is disclosing full details of the Microsoft Internet Explorer research submitted after receiving confirmation that Microsoft does not intend to patch the Address Space Layout Randomization (ASLR) flaw involved. We are also releasing a white paper with the technical details of the attacks, including those against default IE configurations, and suggestions for improving IE’s defenses.


Releasing this level of detail about an unfixed bug is not something we normally do, nor do we do it lightly. To be very clear, we are not doing this out of spite or malice. We would prefer to release this level of detail only after the bug is patched. However, since Microsoft confirmed in correspondence with us they do not plan to take action from this research, we felt the necessity of providing this information to the public. We do so in accordance with the terms of our own ZDI vulnerability-disclosure program.


TippingPoint IPS customers are protected against this vulnerability by Digital Vaccine protection filter IDs 16917, 16918, and 16919. For any further questions regarding the signatures, please reach out to HP TippingPoint TAC.


The road so far…


Disclosing a security bug to a vendor can be an interesting journey. Not all vendors respond well when you tell them their flagship product has a problem; in some cases, it can be like telling a parent their baby is ugly. This is one of the benefits of reporting bugs through ZDI – we deal with the vendor so you don’t have to. However, companies that run their own bug bounty programs are generally different. By running their own bounty program, they are actively requesting bug reports in their products and rewarding those who report them. In theory, the vendor fixes the disclosed bugs, making their product more secure and benefiting their customers.


Back in February, we announced that three of our Zero Day Initiative (ZDI) team members -- Brian Gorenc, AbdulAziz Hariri, and Simon Zuckerbraun -- won the Microsoft Mitigation Bypass Bounty and Blue Hat Bonus for Defense. The submission outlined techniques and steps to attack the Isolated Heap and MemoryProtection functions in the latest version of IE. It further describes how an attacker can use MemoryProtection as an oracle to completely bypass ASLR. The resulting $125,000 award was donated to educational organizations with a strong STEM (science, technology, engineering, math) emphasis. 


The February announcement came after the 120-day disclosure timeline had passed, but at the time, we did not disclose further details in the best interests of the ecosystem at large. In other words, Microsoft hadn’t fixed all of the bugs yet, and we wanted to give them a little more time. We were working under the assumption that a fix for all reported bugs was being worked. Unfortunately, Microsoft eventually informed the team a complete fix was not forthcoming.


A bump in the road


Why not produce a patch? Microsoft has given two primary reasons for not addressing these bugs. 

  • “64-bit versions of IE would benefit the most from ASLR” 

To recap why ASLR matters, ASLR came into being at a time when many exploits relied on static memory address values. Adding some randomness to the memory layout increased the difficulty for attackers and caused many basic exploits to fail. From the beginning of ASLR, methods existed to bypass the protection. For example, on Linux, a return-to-libc attack will calculate the offset of system() from usleep() in order to bypass the randomization. ASLR has also improved over the years, with Windows adding features such as high entropy randomization, bottom-up and top-down randomization, and Address Space Information Disclosure Hardening.


In this situation, Microsoft’s statement is technically correct – 64-bit versions do benefit from ASLR more than 32-bit versions. A 64-bit system has a much larger address space than a 32-bit system, which makes ASLR that much more effective. However what is lost here is that the bypass described and submitted also works for 32-bit systems, which is the default configuration on millions of systems. To demonstrate this, we have released proof-of-concept (PoC) code to demonstrate this bypass on Windows 7 and Windows 8.1. 

  • “MemoryProtect has led to a significant overall decrease of IE case submissions”

That’s not a bad thing. In our original announcement, the team noted Microsoft’s recent work on mitigations is incredibly important – not merely for the security of individual users but for the safety of people and entities on and off the Internet. That’s one of the reasons we find fixing these attacks to be in the best interest of all IE users. This bypass can be used to defeat ASLR in default configurations of IE. Think of it as surgical tools for working around the affects of Memory Protection where possible. MemoryProtection only fully mitigates a subset of use-after-free (UAF) vulnerabilities. Is an ineffective ASLR mitigation worth a “slight decrease” in UAF vulnerability submissions to Microsoft? It seems that for Microsoft, the answer is yes. UAF vulnerabilities still exist in IE and the ease at which ASLR can be broken only makes IE a more attractive target for attackers.


The following video shows an example of the bypass:


Why disclose?


Since Microsoft feels these issues do not impact a default configuration of IE (thus affecting a large number of customers), it is in their judgment not worth their resources and the potential regression risk. We disagree with that opinion and are releasing the PoC information to the community in the belief that concerned users should be as fully informed as possible in order to take whatever measures they find appropriate for their own installations. As I wrote in my earlier Security Briefing, in order to effectively protect a system, defenders must fully understand the threat. We feel it’s important to let everyone know about the threat so that they could better understand the actual risk to their network.


The journey continues


At ZDI, we’ve handled vulnerabilities and vendor responses for nearly 10 years. This is hardly the first time a vendor has decided not to fix a problem we think they should. I’m guessing it won’t be the last time either. When this happens, we inevitibly come back to the discussion of when to disclose and how much information we provide. In the coming days, we’ll have more to say on that topic. Until then, take a look at the whitepaper and determine if this bug impacts the risk to your systems. The journey through disclosing a bug to a vendor can take many paths. However, if we walk together as a community to strengthen our defenses, you won’t have to walk it alone.

0 Kudos
About the Author


I am a senior security content developer with Hewlett Packard Enterprise Security Research. In this role, I write and edit security analysis and supporting content from researchers. I am also responsible for providing insight into the threat landscape; competitive intelligence to the research team; and providing guidance on the social media roadmap. Part of my role includes speaking publicly and promoting the research and technology of HPE Enterprise Security Products .


Holy **bleep**house! I seriously love ZDI :)

Filter by Labels