Core Security’s CoreLabs group achieved a significant accomplishment this week, issuing its one-hundredth public security advisory – a bulletin detailing a newly discovered security flaw in Microsoft’s Internet Explorer Web browsing software, one of the most ubiquitous technologies in the world.
Over a period of almost 13 years at Core I’ve been lucky enough to be involved in the discovery, reporting and publication of every one of these 101 security advisories, sometimes in the role of researcher, and more often as reporter, coordinator or advisor during the reporting process.
We promptly followed up with security advisory 101 – a bug in the DX Studio player, a graphics creation plug-in for Mozilla’s Firefox, the world’s second most used Web browser.
As a member of Core’s Security Advisories team of five, with a portion of our work-time assigned to the process of documenting, reporting and following up with all internal and external stakeholders when new vulnerabilities are discovered, I’ve collected countless stories and anecdotes that have contributed to my vision of this process.
Publication of Core’s advisories numbers 100 and 101 seemed like a good excuse to contribute an initial blog post that reflects on some of those stories and the impression they’ve left on me. I’ve been learning about the thrills and perils of looking for, finding, reporting and fixing security bugs in someone else’s software ever since the first vulnerability discovered by Core was reported and published: a problem of predictability in the “id” field of DNS queries of BIND, the most used DNS server software… Ring a bell? It should!
In the years following that publication I’ve learned that making technical details available in our advisories frequently helps our peers discover variations of the same types of problems, or even related issues, and that doing so may ultimately contribute to collectively improving the security posture of many more users of insecure technologies.
When it all comes together right, the innovative work of researchers like those within CoreLabs is validated when vulnerable users are able to learn and understand the risks that they are exposed to and make rational decisions about how to manage them. It is even better if, in the process, the vendor of the vulnerable technology is given the chance to address the problem and takes advantage of this unique opportunity to demonstrate due-diligence and responsibility.
And while the process involved in working with vendors to confirm the existence and exploitability of the problems we discover is often lengthy and complicated, all of the effort is worth it to achieve the desired results. And truthfully, the routine has become easier over the years as greater numbers of developers have embraced the idea that securing their products must be a priority.
Looking back at the 101 advisories that CoreLabs has produced over the last thirteen years, there are a number that stand out for their technological significance, whether that be related to the types of vulnerabilities they addressed or the breeds of products in which they were found – as well as for the ancillary effect that they had in further establishing Core as a thought leader in the vulnerability research arena.
Each one of them has a story of its own, and many left a mark on the history of our company and the individual researchers that found them. Some have also helped us gain a clearer and more direct understanding of the true nature of different vulnerability classes and their exploitation, and of the potential effects if they are found in emerging technologies.
In a series of follow-up posts I will comment about the specific details of some of the vulnerabilities in our past advisories and the lessons we learned from their unique stories.
-Ivan Arce, CTO