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!