Backdoors! But wait, there's more...

You recently heard our CTO, Chris Wysopal discuss in his blog post the warnings issued by ICS-CERT on backdoors in a standard network module for control systems. The type of equipment was the Schneider Electric Quantum Ethernet Module. You can read more about the full warning here. Chris went on to discuss how this warning was consistent with what we observed in our recently released State of Software Security report where we found that backdoors were present in 3% of software vendor developed code (Schnieder’s module being an example of this type of commercial code).

However, the vulnerability categories that we observed in the Top 10 for commercial software and not other types of software (e.g. internally developed) don’t just stop at backdoors. We also saw a higher presence of remote code execution vulnerabilities in commercial software than other types of software we analyzed.

So, what is a remote code execution vulnerability? Before I elaborate on that let me ask you – do you remember ‘Operation Aurora’ that caused a breach at Google and several other prominent US companies? Well, that attack exploited a remote code execution vulnerability in Microsoft IE 6. So, a remote code execution vulnerability is one that is really bad to have in your software. More specifically we characterize vulnerabilities such as buffer management errors, buffer overflows, and integer overflows as classes of remote code execution vulnerabilities due to the potential for an attacker to exploit them to gain command over the target system and execute

arbitrary code on it. It was interesting to observe that these made it to the Top 10 for commercial software but not other software types (4% of vulnerabilities in commercial software were buffer management errors and 3% were buffer overflows). We think that the reason for this is that internal software development continues to shift to managed code languages and scripting languages which don’t fall victim to many of these serious vulnerability types. However, commercial software continues to make use of non-typesafe languages (such as compiled C/C++ and Objective C) where it is easy to get sizes of buffers mixed up and end up with these problems. In fact, we reported in State of Software Security report that 15% of commercial applications made use of C/C++ as compared to only 4% for internally developed.

So, what’s to be done? There is a role to be played by both the software producers creating the commercial code and software purchasers that are buying it for deployment in their organizations. Software producers should provide training to their development teams on how to prevent and fix these types of issues and test for their presence before shipping their code. Software purchasers should make sure that their security due diligence on commercial vendors includes a detection capability for these types of serious vulnerabilities.

My next post in this series will be after the New Year, so until then - have a happy and safe holiday season!

About Sam King

Sam King is the executive vice president of strategy and corporate development and General Manager of the mobile division at Veracode. In this role, Ms. King oversees product management, corporate development and execution, M&A activities, and building key industry and strategic alliances as well as the overall direction of the Veracode’s mobile product line.

Comments (0)

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.