Finding bugs and publishing advisories - the Core Security way
In this presentation I will talk about some lessons that we've learned conducting vulnerability research activities and handling the publication of advisories in Core over the last 14 years. I will focus on the more original --and hopefully inspiring-- aspects of the way that we drive this research.
1) How do we find bugs? In this part of the talk, I'll present some statistics about which activities led to the finding of bugs and which methodologies were used (fuzzing, source code audit, etc.) The principal bughunting activity is what we call the Bugweek: the whole technical staff of the company dedicates one week to look for bugs in common applications. Organizing a research activity of this size is a particularly interesting challenge.
2) How do we deal with bugs in the bug reporting and publication process? Anyone who has once reported a security bug knows some of the pitfalls that arise in the process. In particular I'll dive into the discussion about why we publish advisories in the first place; and how much technical information should be included in the advisories.
3) I will release some tools that we have developed to improve our process. To document the bugs we use an XML format, that we call the "Open Advisory Format", from which other formats can be easily generated. This format helps to write the technical description of the bugs and the advisory timeline -- a section that we write with special care, since it helps to make the publication process more transparent. A structured XML timeline also allows the extraction of more detailed statistics, something that we need as a community to better understand the life and death cycle of the bugs.
4) I'll enter into the details of some stories of bugs found and published, taken from the pool of 140 advisories released by Core, that illustrate some of the ideas previously discussed.
For more information about the conference, see http://www.h2hc.org.br/