BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
What’s worse, bad software or malicious software? In fact, what’s the difference?
Unfortunately, bad software and malicious software are often confused—sometimes even by grizzled security veterans. In this column I will attempt to tease the two apart and demonstrate the symbiotic relationship between them.
Is there any good news, you ask? Sure; eradicating bad software will help contain the malicious software problem.
Bad software (aka badware)
Everyone these days understands that software defects lead to a majority of computer security problems. A quick review of the badware “bug parade” reveals an entire procession of problems we’ve all heard plenty about: buffer overflows, race conditions, cross-site scripting (XSS), SQL injection, cross-site request forgery (CSRF), and so many more that the non-celebrity bug pile tops out now somewhere in the multiple thousands (see the CWE for one of the biggest bad software lists). And don’t forget the flaws (that is, design problems), which account for the remaining 50% of serious software security defects.
About the [In]security column:
This monthly security column by Gary McGraw started life in print in IT Architect and Network magazines and was originally called “[In]security.” That was back in October 2004. The column then transitioned into Web content at several publications before finding a home at SearchSecurity. You can always find pointers to the complete [In]security series on McGraw’s writing page. Your feedback on the column is greatly appreciated.
The important thing to understand about these bugs and flaws (for the purposes of this article anyway) is that they are most likely in existence as the result of oversight, ignorance or general security cluelessness among developers and architects. Although we have trained thousands of developers over the years about software security basics, there are many more software people with no security training at all, than there are software people who have participated in one course or picked up and read a software security book.
The good news is developers hate bugs and architects hate flaws, so if we continue to educate them about the nature of these defects, they are likely to stop making new ones. Add to that trend the growing arsenal of static analysis tools for reviewing code, architectural risk analysis for finding flaws, and other software security Touchpoints and you can see we’re making some headway.
I’ve said it before and I will say it again, software security is working and we are getting better at it.
Here’s my main point though; most bugs are not intentionally put into software by evil developers bent on total world destruction through crappy software creation. They are mistakes; accidents; problems with bad consequences, but not problems seeded with evil intent.
Malicious software (aka malware)
Viruses, worms, Trojan Horses, spyware, adware, rootkits and (Baskin-Robbins flavor of the day) advanced persistent threats (APTs) are all types of malicious software. Malicious software is code that is intentionally designed to do bad things, on purpose, by the person or people who create it. This is worth repeating; malware is different from badware in many ways, and the number one differentiator is the intent of the person doing the writing.
Many viruses and worms (but not all), make use of defects in the systems that they are attacking. The Java security problems that Ed Felten and I wrote about back in the mid-‘90s (badware) were ripe for exploit by attackers writing exploit code (malware). The Zeus Trojan leverages both particular bugs in a browser and browser design flaws to infect a target browser and carry out an insidious attacker-in-the-middle attack (mostly against financial services firms). Zeus is malware. The problems that allow it to get a foothold—badware. The Stuxnet worm is malware. It is intentionally designed to attack process control systems of the sort that control centrifuges in Iran. Stuxnet leverages insecurities in the design of Siemens programmable logic controllers (badware). Note that Siemens is not in the malware business, and it is working hard on improving software security.
This tight connection between badware and malware has led some people to conflate them. So, how are they related anyway?
Badware as a vector for malware
Vector is one of those words with lots of meanings. In math, a vector is a line with magnitude and direction. In epidemiology, a vector is an organism that transmits infections from one host to another.
Using the second definition, we can conceptualize software defects (and the resulting badware) as a vector for malicious code.
Why is this important? Because going after the root of the malware problem necesarily involves going after badware. This is epidemiology 101. Remove the vector. Know why eradicating mosquitos is critical to defeating malaria? Because mosquitos are a vector. Kill off mosquitos and you directly impact the spread of malaria.
All of the things that we do to improve software security are aimed explicitly at the badware problem. Because of that, they also help control the malware problem.
When badware is malware, or evil developers gone wild
Uh oh, bet you thought we had this all straight. But this is computer security, so of course there are some special cases to consider if we put on our “bad person thinking caps.” Here’s one: imagine a developer with evil intent who purposefully seeds bugs in the software she is creating so she can sell the zero-days to bad actors after the code ships. And another: Imagine an evil developer who inserts a time bomb Trojan Horse into some code that he is writing and later uses the existence of the time bomb to blackmail the company counting on the code to carry out essential business processes. And a third: Imagine an evil developer who intentionally writes code to use up all available computational resources so the computer running the program slows to a crawl. And a super elite modern fourth one: Imagine a developer who creates a simple game app for mobile phones that appears to be harmless and fun but actually exports user data from the phone and sends it off to the attacker. The possibilities are as endless as they are concerning.
Which brings into focus the question of whether there is anything we can do to look for Trojans and intentionally placed bugs like this in source code. Can we combat the evil developer? There may be some hope.
First things first: In some situations, knowing whether you can trust the developers is so critical that it is instituted in policy. For example, the NSA in the Unites States has published Guidance for Addressing Malicious Code Risk (.pdf) aimed squarely at this problem. In some cases, large multi-natonal banks have similar rules; there is technology as well. Cigital consultant Marina Khainson has been exploring the idea of detecting what she calls “elements of malicious design” using standard issue static-analysis techniques. Her recent NoVA OWASP talk Malicious Code Detection: BRIC Breaking Through Static Analysis (.pdf) discusses early work in malicious code detection with static analysis, using Trojan functionality in Android mobile phone apps as an example.
Basic ideas? Look for certain static strings that may be iffy, such as “chmod 777” or for globs of high entropy data (which indicate cyrpted stuff). Watch out for calls to weird packages or high-privilege system calls that seem unnecessary. Some of these queries can be automated (running strings over binary, for example, can yield items of interest). Others may require manual analysis. Results are encouraging.
Fight badware everywhere
Talking about malware may be more fun and entertaining than talking about endless security bugs, but if we’re going to combat malware we have to start with the badware vector. Most developers aren’t evil anyway, right?
About the author:
Gary McGraw, Ph.D., is CTO of Cigital Inc. a software security consulting firm. He is a globally recognized authority on software security and the author of eight best selling books on this topic. Send feedback on this column to firstname.lastname@example.org