Disclosures, Updates, and Patches: the Cycle of Life in Cybersecurity

This week saw a public disclosure of a flaw in a cybersecurity company’s software (ESET), that would allow remote code execution and privilege isolation on Apple macOS computers running ESET Endpoint Antivirus 6 software. Whenever I see something like this, there are a number of things that I think about. The first is to thank the people who discover these types of vulnerabilities and follow a responsible disclosure process. This enabled ESET to fix the issue and have a patch available to its customers before the disclosure occurred. How fast the patches are adopted, and how easy it is to upgrade is a story for another day.

The second interesting point about this disclosure is that it is for macOS. For many years, the level of vulnerabilities and disclosures for macOS software has trailed Windows software, even as the marketshare for Apple and macOS has grown. It will be interesting and important to watch the Apple security space over the next year or two, as the Mac becomes an increasingly appealing target, to see if Apple’s security measures will be enough to keep it ahead of the threat curve and preserve a safe computing environment.

The third and most important point is that you are only as strong as your weakest link, and in the case of application software that is often third-party libraries. Applications today can be developed quickly and easily by taking advantage of existing libraries to avoid unnecessary reinvention. A complex application may consume dozens of these libraries, and those may include additional libraries in turn. In the ESET example, the Antivirus software used a POCO XML library which was based on an older version of the Expat parsing library which has a publicly known XML parsing vulnerability.

In many cases, fully expanding a dependency tree can result in a hundred or more dependencies for a complicated application. Depending on how those dependencies are managed, you might need to wait for the open source project or vendor to integrate an update and release a new (verified) package before you can pick it up and include it in your release. Staying on top of library and platform updates isn’t just “important,” it’s VITAL.

While all application developers are at risk of this type of vulnerability, security companies make for particularly appealing targets. As a security company, we are (and should be) expected to understand what the implications of including a library are, and to be the best in the world at integrating and releasing components that include fixes for all known vulnerabilities. The teams that I’ve worked with at McAfee devote a significant amount of time to keeping libraries up to date, expanding dependency trees, and generally sweating the details of the code.

However, the responsibility its not entirely on the application vendor. The cycle encompasses everyone and moves quite quickly. There is typically only a few weeks from a patch being available to a public disclosure of a vulnerability, and one study[1] found that almost half of disclosed vulnerabilities are exploited within a month. As soon as the disclosure happens, the attack countdown clock starts ticking. If an organization is not aware of the exploit, or is not able to deploy the fix for one reason or another, the vulnerability’s existence is much worse than when it was unknown. So, a plea from a security vendor to our customers … please, stay up to date! Help us help you. And while vulnerabilities can and will happen to everyone, continue to hold us accountable for getting fixes to you as quickly and safely as possible.

[1] Leyla Bilge and Dumitras Tudor. “Before We Knew It: An Empirical Study of Zero-Day Attacks in the Wild.” Proceedings of the 2012 ACM conference on Computer and Communications Security. October 2012. https://users.ece.cmu.edu/~tdumitra/public_documents/bilge12_zero_day.pdf

 

Leave a Comment

11 − six =