If there is a lesson to be learned from the recent news that several Symantec enterprise and consumer endpoint security products have serious vulnerabilities, it is that even security tools have exploitable flaws — caveat emptor and all that.
Travis Ormandy, of Google’s Project Zero team, said the vulnerabilities in Symantec’s code are “as bad as it gets.” Most of the flaws were in the Decomposer component, which parses various file formats, including archive files like .rar and .zip. Symantec unpacked archives right in the kernel using “the highest privilege levels possible,” which means malware compressed into one of these archives is opened in the most sensitive part of the operating system. This could lead to remote code execution and be used to create worms that execute and spread through local networks without user interaction.
The list of affected products includes all versions of Symantec Endpoint Protection, Symantec Email Security, Symantec Protection Engine, Symantec Protection for SharePoint Server, Norton Security, Norton 360, and other legacy Norton products. Symantec has fixed the flaws, but enterprise administrators should make sure the products are updated to receive the fixes. The automatic signature updates do not update the actual software application.
“It is not the time to punish Symantec for releasing problematic code or for its design decision to unpack files in the kernel instead of adopting a sandbox as a more secure alternative. The problem is much more pervasive throughout the security industry, and reflects the broader challenge organisations face when writing secure code”
Second strike
The problems are bad, especially since this is the second time Ormandy has dinged Symantec for security issues, but the company is not the only offender. Ormandy and other members of the Project Zero team have uncovered several serious vulnerabilities in antivirus products over the past few months, including offerings from Kaspersky Lab, ESET, FireEye, Trend Micro, Sophos, McAfee, and Comodo.
But this is not the time for enterprise customers to punish Symantec for releasing problematic code or for its design decision to unpack files in the kernel instead of adopting a sandbox as a more secure alternative. The problem is much more pervasive throughout the security industry, and reflects the broader challenge organisations face when writing secure code.
“Writing secure software is tough, but the OS vendors (such as Microsoft, and even Apple) have made great strides in recent years to harden their code — so why can’t others in the security industry do the same?” said Patrick Wardle, director of research at Synack.
In Symantec’s case, the developers didn’t utilise common compiler-level mitigations, such as -fstack-protector on Linux, said Wardle.
Among the worst
The State of Software Security v3 report from application security vendor Veracode found that security software was the second-worst category of software for application security. Many applications are still written in C and C++, which means developers can make mistakes leading to more critical vulnerabilities like buffer and integer overflows than they would if they were using languages like Java, C#, or JavaScript.
Security software frequently runs with higher privileges than average software, as it needs to inspect data going to and from other applications and needs deep access to the operating system. The operations often require complex parsing and pattern detection, which typically result in complex and bug-prone code, said Chris Wysopal, CTO and co-founder of Veracode. As a result, exploitable vulnerabilities in security software typically leads to complete system compromise.
Ultimate sin
The biggest sin in the Symantec story is using outdated third-party libraries containing known vulnerabilities and not updating those libraries with newer, more secure versions. Unfortunately, though it is best practice to use the latest versions of third-party libraries, it does not always happen. The updated libraries and packages may break existing functionality or may depend on deprecated functionality, which would require changes to the software. Considering the nested nature of software development, where libraries use other third-party components, developers often don’t even realise that they are relying on older and vulnerable code within their applications.
Open source security company SourceClear has a tool to help developers identify what open source libraries they are using and what vulnerabilities exist so that they can identify and fix known and emerging security threats. Black Duck Software’s platform also detects and alerts for issues on Linux subcomponents when they are used to build applications and containers. But the development teams need to use those tools or take other steps to keep libraries and packages up-to-date.
Just because software comes from a security vendor does not automatically mean it was written by a team of developers well-versed in security.
“Security software vendors hire from the same pool of developers who in general have had no security training in college or on the job security training,” said Wysopal.
Tested and secure
Enterprise expects products from large vendors and well-known brands to be tested and secure, but vulnerabilities can be found in any application. Relying on any one application or technology for security is a losing proposition. Antivirus software and endpoint security products are often considered mandatory elements of a good enterprise security environment. While there is a growing realisation that they are not enough, there is still a lack of awareness that the software itself could act as the doorway for attackers.
There is the social engineering aspect, where attackers craft malware specifically to bypass specific types of antivirus, and users let down their guard when they see the malware because they figure the antivirus would have stopped it if it was really bad.
Then there are the vulnerabilities themselves. If attackers find the vulnerabilities and figure out a way to exploit them, they would have an enormous victim pool to target.
Defence in-depth
A defence-in-depth strategy, where additional layers of security technologies block threats that squeak past front-line defences, is essential for any enterprise. More important, organisations have to make sure they are not simply applying the same level of security across the board. The more effective approach is to consider the risks, identify where the most sensitive systems and data reside in the local network, and make sure appropriate security measures are applied.
Security isn’t a product, but a process, which means organisations have to continually assess risk and update their defences.
IDG News Service
Ltd
