When your security products are insecure: Takeaways from the Symantec disclosure

Tavis Ormandy, a member of Google’s Project Zero initiative, recently discovered a series of vulnerabilities in Symantec’s security products that he describes as “as bad as it gets.” Affecting both the company’s consumer and enterprise products, these vulnerabilities are far-reaching and can’t all be patched with automatic updates.

Ormandy writes of these vulnerabilities, “They don’t require any user interaction, they affect the default configuration, and the software runs at the highest privilege levels possible. In certain cases on Windows, vulnerable code is even loaded into the kernel, resulting in remote kernel memory corruption.”

Although an insecure security product might seem like a shocking development, our research has found security software to be notoriously insecure. Which means, even though the security software is protecting against some attacks, it also carries its own vulnerabilities that open up the system the software is installed on to additional attacks.

We’ve also found third-party software in general to be rife with vulnerabilities. In turn, if your application security plan only applies to the code you’re developing internally, you’re making cyberattackers’ lives a lot easier. All software, internally developed or vendor sourced, adds risk to your organization and needs to be part of your risk management process.

The insecurity of security products

It might seem like an oxymoron, but insecure security products are indeed reality. Our past research found security software to be the second-to-worst category of software for application security.

Why is security software frequently more insecure than other software? For one, it’s typically written in C/C++, which has more critical vulnerabilities like buffer overflows and integer overflows than languages like Java, C# or Javascript. In addition, the operations security software performs often require complex parsing and pattern detections, which are typically complex and involve bug-prone code.

Finally, security software’s access level makes it more appealing to cyberattackers. Security software typically runs at a higher privilege level so it can inspect the data going to and from other applications.  When a vulnerability is exploited, it means complete system compromise. 

For example, the vulnerable code found in Symantec’s products was part of a commercial packing software component that Symantec uses to analyze files scanned for malware. Symantec was running this component in the operating system’s kernel, under the highest privilege available. A vulnerability in this component gives an attacker a free pass to full control over the system without the need for a second exploit to escalate access.

All these things add up to making security software an attractive target for attackers.  Vulnerabilities are plentiful, and the software is running with elevated privileges.  Frankly, I’m surprised we don’t see more disclosures around security software.  Perhaps more bug bounties are needed in the security software marketplace.

What to do about it

This disclosure highlights the fact that you cannot assume the software you buy is secure and, in fact, you should assume it’s insecure — including, and maybe even especially, security software.

Assuming the security of third-party software is especially risky because the it’s the operator of the software that retains all liability, not the software vendor. If you’re compromised due to a vulnerability in the software you’re running, you can’t seek compensation from your vendors because they have disclaimed liability in their EULA (End User License Agreement).

Some of the most damaging recent breaches stemmed from vulnerabilities in third-party software. And it was the enterprises that suffered the monetary and brand damage, not the vendors. 65 percent of a typical enterprise application portfolio comes from third parties (source: Quocirca), yet 90 percent of third-party code does not comply with enterprise security standards such as the OWASP Top 10 (source: Veracode State of Software Security Report, Enterprise Testing of Software Supply Chain).

What can you do? First, you should hold third-party software to the same security standards your internally developed software needs to meet. Many organizations rely on questionnaire-based assessments to vet the security of third-party software. But these questionnaires rarely deliver an accurate picture of a product’s security, and in fact, the Symantec vulnerabilities would not have been revealed through these questionnaires.

A more solid option is to engage an outside application security specialist who can work directly with your vendors – on your behalf — to assess and work with them to remediate their code. The latter is important. You don’t want to shame your suppliers. You want to purchase and operate a secure version of their product.

The bottom line is that you can’t leave security in the hands of your software vendors, not even security software vendors. The Symantec disclosure makes that abundantly clear. Take steps to ensure the security of all your applications, including those you build, assemble … and buy.