Part of my life has been spent in the manufacturing sector working with industrial automation devices, but the discovery of the Stuxnet virus is the first time I’ve ever heard of specifically virus targeting and even rootkitting a PLC (programmable logic controller) or  SCADA (supervisory control and data acquisition) network.

When working in industrial plants, we took the standard precautions with regard to Windows viruses and even started to add virus protection for Linux, but never did it occur to any of us that the industrial automation equipment might be at risk. Whenever the subject was even brought up, which was rare in itself, there were the standard arguments:

• Oh, it’s on a physically separate network (or VLAN configuration), only USB (thumb/flash) drives are allowed and they’re virus checked before use.
• Oh, it’s running a completely different processor/operating system/architecture – there’s no way it can be infected.

The consequences of infection are severe.   These devices run everything from our nuclear power plants to complex manufacturing assembly lines, aircraft controls (FADECs) and chemical refineries, just to name a few.  In its most basic of functions, industrial automation is used for two purposes: to keep humans safe and to produce products for less cost.  Interrupting either of these is going to kill someone or cost a company a large chunk of change.

So, what does this all mean?  It means that industrial automation and PLC vendors had better start hardening their solutions for security vulnerabilities and elevate the quality of their firmware and software components using security vulnerability tools such as Klocwork’s static analysis just as the general computing industry has done for the past 30 years.

For an in-depth analysis and timeline, refer to either Symantec’s whitepaper on their Stuxnet analysis or the work done by ESET on their version of Stuxnet.

With the recent story that the iPad has inherent security vulnerabilities, I thought it might be an appropriate time to delve into the world of software security guidelines…but I must warn you, this blog will contain an abnormal amount of acronyms, and may not be suitable for all audiences.

When talking about software security guidelines, there are really 5 or 6 organizations that are leading the charge, and they include:

-          OWASP

-          SANS Institute

-          MITRE

-          PCI Security Standards Council

-          SEI

Let’s first look at OWASP. OWASP stands for Open Web Application Security Project, which is a not-for-profit charitable organization that is focused on improving the security of application software. They are probably best known for their Top 10 lists from 2004, 2007, and most recently 2010.

Next is the SANS Institute. SANS of course is a FLA that stands for SysAdmin, Audit, Networking, Security. The SANS Institute claims to be the most trusted source for computer security training, certification and research, and have been developing and releasing their Top 20 annually for the past 7 years or so.

The MITRE Corporation is a not-for-profit organization that was founded in the late 50’s, and has over 7,000 very smart dudes (65% have Masters or PhDs). MITRE has come up with their own security guideline as well, that is the CWE (Common Weakness Enumeration) and it provides a common language of discourse for discussing, finding and dealing with the causes of software security vulnerabilities as they are found in code, design, or system architecture. The CWE lists over 800 programming errors, design errors, and architectural errors that can lead to exploitable vulnerabilities. Interestingly, MITRE and SANS decided to collaborate to come up with the CWE Top 25, yet another “Top” list they have been putting together for the last couple of years.

The PCI Security Standards Council was founded by American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa, Inc. and is an open global forum for the ongoing development, enhancement, storage, dissemination and implementation of security standards for account data protection. The PCI SSC has come up with the PCI DSS, “a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. This comprehensive standard is intended to help organizations proactively protect customer account data”.

Finally, there is the SEI (the Software Engineering Institute, which is a federally funded R&D center at CMU, aka Carnegie Mellon University). The SEI is home to CERT which was established in 1988 to address internet security problems and to find ways to reduce the number and impact of security breaches. CERT focuses on protection, detection, and response to attacks on networked computer systems. Surprisingly enough, CERT is not actually an acronym.

Neither PCI nor CERT has received the memo yet that in order to be cool, you have to have a “Top X” list…perhaps next year?

Now, not to be left out of the fun, the NCSD (National Cyber Security Division) of the DHS (Department of Homeland Security) has their own strategic initiative called BSI (Build Security In). The NCSD obviously wants to cover pretty much all the bases since, in addition to their own BSI, they also sponsor pretty much all of the other guidelines.

I would be remiss if I didn’t at least acknowledge a few other notables with respect to software security guidelines, and to make it more interesting, I will only provide the acronym. I challenge you to come up with the full name. So, a few others involved in security guidelines are NIST (who run a project called SAMATE, and also run an event called SATE, which BTW is also sponsored by DHS NCSD), WASC, and finally STIG. For fun, I’ll throw in CVE, even though it is not a guideline, but more of a dictionary or list that was put together by MITRE, and shockingly is sponsored by DHS NCSD. I’m starting to think that DHS wants to be everyone’s BFF.

Hopefully you’ve learned a little more about the alphabet soup of security guidelines out there. If you’re scratching your head thinking WTF, you’re probably not alone…

As Google Chrome climbs out of obscurity in the browser market and expands into a light-weight but fully functional OS, security seems to have become a top of mind issue over at chromium headquarters.

In the Chromium Blog, Chris Evans of Chrome Security announced a cash for bugs initiative, paying between 500 and 1337 USD depending on the severity for any previously undiscovered flaw.  I am glad to see Google encouraging the community at large to participate in hardening my current browser of choice.  As Chris points out, Mozilla was one of the first to embark on this type of program, but I am happy to see Chrome following suit.  Me and my online transactions appreciate it.

Hmm.  Maybe I should roll-up the sleeves and  invoke the  ”I’m gonna write me a minivan” approach and get the driveway cleared for the armored cash trucks.

But seriously, if you’re interested in helping out and getting a small reward for your efforts, visit the Chromium Security project.

I have always been fascinated by the whole area of code vulnerabilities and security exploits and how hackers turn those issues into real-world problems for the rest of us.

Jeremy Brown posted an interesting article on Jeremy’s Computer Security blog where he uses his security know-how to draw a straight line between a software vulnerability found with static analysis and a real 0day exploit on an open source project called gAlan.

Jeremy takes us on a short journey where he finds an unprotected buffer with static analysis, creates an exploit payload to cause a buffer overrun, rewrites the instruction pointer and executes a telnet session, demonstrating how easy it is to turn a run of the mill application into a tunnel into the OS.

One of my colleagues did a similar presentation like this a few years back with a Firefox vulnerability but this is a much better example! Very cool work Jeremy.

Enjoy…

My first day at the SWA forum was actually the 3^rd day at the conference, and from all accounts it has been a very productive and relevant first 2 days. Today was no different as it was kicked off with a panel discussion on the Evolution of Software Assurance Processes, and included speakers from Lockheed Martin, Waters Edge LLC, SEI/CERT, and SafeCode. I thought it was an entertaining discussion from a group definitely passionate about the topic. Something seemed missing though as I came out of it hoping for something more…Some good questions rounded out the first session.

Next was my turn to be on stage. I was speaking as part of the “Understanding Technology Stakeholders: Their Progress and Challenges” panel which was made up of John Giligan (The Giligan Group), Djenana Campara (KDM), Bruce Weimer (US Army), and Sean Barnum (Cigital)…and myself. It was an interesting mix of speakers representing various sectors of the software assurance community including assurance ‘consulting’ stakeholders, assurance ‘standards’ stakeholders, assurance ‘consumer’ stakeholders, and assurance ‘tool’ vendor stakeholders. My basic message was that the DHS Forum had done a great job of communicating their message to the assurance community (including a large number of our customers), but fundamentally flawed in a number of other ways.  Unfortunately, the panel part went long, so the Q&A with the Plenary was shortened. The feedback I received was all positive, and that it was refreshing that we didn’t sugar-coat our thoughts.

As I mentioned earlier, there just seems to be something missing from the sessions I’m attending. Perhaps it is too much talk, and not enough action…not sure yet. Hopefully the next two days will leave me with a more positive feeling on this.

I speak again on Friday when I share my experiences and observations on the Static Analysis Tool Exposition 2009. I guess it will be another ‘refreshing’ session…

Next week I’m heading out to the Software Assurance Forum (use SOF96945 for the conference code) in Washington D.C. (well, actually Arlington, Virginia, but D.C. sounds more glamorous). If you’re not familiar with what the SWA is, in a nutshell, its key objective is to encourage software developers to raise overall software quality and security from the start, rather than relying on applying patches to systems after vulnerabilities are discovered.

Anyways, while I’m there, I’ll be taking part in 2 speaking opportunities. The first will be as part of a 6 person panel discussion entitled “Understanding Technology Stakeholders: Their Progress and Challenges” (10:30 – 12:00 on Wednesday). The panel is made up of stakeholders from varying disciplines such as industry, academia, standards, and government. A good well rounded panel should provide for an interesting and entertaining hour and a half.

My second session (Friday at 2:20) will see me fly solo as I discuss our (Klocwork’s) experiences and observations as they relate to SATE. I’m not given much time, so I’ll be revving up the motor mouth to make sure I get our points across. I have a sneaking suspicion I just *may* go a little OT.

So, is anyone out there also going to this event? If so, drop me a line either by email (todd.landry@klocwork.com), or Twitter (@todd_landry) and perhaps we can get together to chat. Look for my next blog next Thursday, as I will recap the panel discussion and the other sessions I attend at this event.

Truepath Analysis

Ever been faced with that glassy-eyed expression, the look of unthinking, unwholesome fear when some long, incomprehensible word escapes your geeky mouth and upsets the maiden aunts around the once-a-year, wear-your-best-tie, try-not-to-die-before-the-cake’s-all-gone tea table? OK, so this paper won’t help you in that situation whatsoever, but if you replace your maiden aunts with a bunch of your best geek friends, and replace the tea with a sturdy helping of Dew, knowing how a real whole program analysis solution works might just conceivably come in handy. Some day. “Dude, I was totally stoked when I read this thing, trust me it’s ahh-some.” Maybe.

Anyway, in the best traditions of self-serving corporate PR blogs everywhere, I give you… drum roll please… Whole Program Analysis, the Klocwork Way.

Enjoy.

Here’s a short blog review of Klocwork Solo by Jeanne Boyarsky. Klocwork Solo is a downloadable Eclipse plug-in for Java. Aside from a few installation hiccups, it’ s a good review with kudos for the range of checkers we provide in the default configuration.

Try it out yourself and let us know what you think.

JSR-305 is a Java Specification Request intended to improve the effectiveness of static analysis tools operating in Java 5+ environments. The idea here is that one can use special purpose annotations in order to provide static analysis tools with hints regarding the behaviour and side effects of methods.

An example of such annotations can be found in the presentation ‘Annotations for Software Defect Detection’ by William Pugh, who is masterminding the whole spec. Here we go:

 1: void test() {
 2:    if (spec != null) fFragments.add(spec);
 3:    if (isComplete(spec)) fPreferences.add(spec);
 4: }
 6:
 5: boolean isComplete(AnnotationPreferences spec) {
 6:    return spec.getColorPreferenceKey() != null
 7:        && spec.getColorPreferenceValue() != null
 8:        && spec.getTextPreferenceKey() != null
 9:        && spec.getOverviewRulerPreferenceKey() != null;
10: }

What’s wrong with the snippet above? Well, the check for null on line 2 shows that the developer expects that the value of ‘spec’ can potentially be null, but it is still passed to method ‘isComplete’. Later, ‘isComplete’ attempts to dereference the value, which causes a NullPointerException.

According to Dr. Pugh, the best way to detect this issue statically is to force a developer to add the annotation @Nonnull to the method signature like this:

5: boolean isComplete(@Nonnull AnnotationPreferences spec) {

In this way, a basic static analysis tool that can minimally track ‘spec’ as a potential suspect for ‘null’ can issue a warning when the @Nonnull annotation is contradicted (that is, when ‘spec’ is passed to ‘isComplete’ as a parameter).

There are two problems with this approach:

• it forces the developer to do work that rightly should be performed by a static analysis engine
• it takes time to write the annotation for static analysis, but it takes even more effort to maintain the annotations and the actual code base in a consistent state.

In reality, the proposals behind JSR-305 exist to enable a tool intended for single function analysis (so-called intra-procedural analysis) to act as if it were performing whole program analysis by requiring the developer to state expected behaviour up front (whether or not that behaviour is actually expressed correctly in the developer’s code).

In contrast, this same scenario is supported by a whole program static analysis tool (so-called inter-procedural analysis) without developer intervention:

1. First, a complete call-graph of the system is built, and then all the methods are ordered so that called methods are processed prior to callers — such an ordering allows the tool to generate all the necessary information about, in this instance, the method ‘isComplete’ by the time the analysis of the method ‘test’ begins.
2. During the analysis of ‘isComplete’, the tool records the fact that the incoming argument ‘spec’ is dereferenced.
3. Next, the method ‘test’ is analyzed. In this method, the variable ‘spec’ is checked for null, so it is tracked as a potential suspect for an exception. Using the information generated about ‘isComplete’ the tool can reliably issue a warning on line 3, since it already knows that ‘isComplete’ dereferences the incoming argument.

So that example applies to a simple unconditional dereference scenario. In more complicated cases, Dr. Pugh proposes to use the annotation parameter ‘when’, with one of the following values:

• ALWAYS

• NEVER

• MAYBE

• UNKNOWN

For example: ‘@Nonnull(when=When.NEVER)’ means that a value is always null in the given context.

This specification seems to be a compromise between the amount of information provided by a developer to a static analysis tool and the amount of effort a developer has to put into it, a compromise that does not seem to be a particularly good solution here. First of all, the amount of information provided in such a manner is insufficient to provide accurate analysis, and secondly this seems to be too much work for the developer, especially when this work can be avoided.

Let’s examine how conditional value dereferencing is supported by whole program static analysis tools:

 1: void test() {
 2:     entity.qualifiedName = null;
 3:     saveName(entity, false);
 4: }
 5:
 6: boolean    saveName(Entity entity, boolean qualified) {
 7:    String name;
 8:    if (qualified)
 9:        name = entity.qualifiedName.trim();
10:    else
11:        name = entity.name.trim()
12:
13:     save(name);
14: }

In this example, an inter-procedural static analysis tool would first analyze the method ‘saveName’. A good analysis engine should be able to record the fact that this method only dereferences ‘entity.qualifiedName’ if the second parameter, ‘qualified’, is set to ‘true’. This, it would appear, is a deal more detailed than one can practically achieve by adding @Nonnull(when=When.XXX) annotations, even with all the work the annotation implies for the developer.

Next, the method ‘test’ would be analyzed. A good static analysis tool will naturally keep track of ‘entity.qualifiedName’ because of the assignment to ‘null’ on line 2 and its therefore potential use in an exception causing context. However, given that the actual call to ‘saveName’ on line 3 uses ‘false’ as its second argument, such a tool will not issue a warning that would in reality be a false positive, since the knowledge gained from analyzing ‘saveName’ disqualifies any potential warning due to the conditional relationship between arguments.

In summary, JSR-305 proposes a whole roster of interesting ideas for using annotations to enhance static analysis of Java code, and NPE detection seems to be only one aspect of this specification request. In upcoming blog posts, we shall continue the discussion of proposed annotations as well as offering our own ideas about how and when annotations should be used in static analysis.

Another year, another list of the most obvious things that competent developers should already know how to avoid? This one even has the NSA backing it, as well as the usual laundry list of pimping vendors attempting to make PR out of anything remotely related to homeland security… Quick, where do I sign up?

OK, perhaps that’s a bit cynical, but I have to say that my usual reaction to any web application-centric security laundry list is that most developers in that space write crap code, so why should we be surprised, or expect that a new list of world-ending doom and gloom will make any difference? I mean, why the heck is SQL Injection still a cause for concern? Haven’t we learned to write prepared statements yet? According to the widely quoted experts, SQL Injection and input validation alone comprised 1.5M exploits last year. Sigh…

Was nice to see some level-headed reporting in amongst all the hyperbole, however. My favorite quote of the day comes from the BBC article linked above, with Patrick Lincoln from SRI International saying:

“The real dedicated serial attacker will probably find a way in even if all these errors were removed. But a high school hacker with malicious intent – ankle-biters if you will – would be deterred from breaking in.”

Ankle-biters. Oh, the irony… All this money being spent on what? A barrier to deter script kiddies…

Maybe it’s just me, but I can’t help myself reflecting back to 1999. If you had code you’d written properly, that wasn’t lazy, that was expected to be around for a while, you simply weren’t cool enough to grab the big Y2K contracts. You weren’t cool enough to be worried about airplanes falling out of the sky. You were just a decent programmer doing a decent job.

Now of course, all the cool kids are worried about web site security. Why? Well as with everything that sounds noble and just on the outside, it probably has something to do with money, let’s face it. And cool-looking eye glasses with those little wire frames (oh yeah, you know you want them…). Because now you’re not a maintenance coder, you’re a code forensics expert. You’re not patching up some piece of garbage that should never have left the test server, you’re implementing cutting-edge perimeter security measures. You’re not hiding your head in shame about just how misguided our industry has become, you’re trumpeting it on the front page of every news outlet in the world…

And if you’re really cool you’re already fitting yourself out for your Steve Jobs lookalike outfit, because now, people, now we have the NSA telling us that the world is going to hell in a hand-basket, but if we’re quick enough, if we throw enough buzzwords around, maybe we’ll land ourselves a cushy gig as a maintenance programmer. Err.. I mean an architecturally-motivated, build-security-in, leading-from-the-trenches, application security infrastructuralizer kind of guy. Yeah, that sounds about right…

OK, don’t get me wrong… buzzwords aside, CWE is an awesome endeavor being run by some very smart and motivated people. And hey, this list will probably help me sell more of my software, which is always good, right?

But will this list of the Top 25 “dumb mistakes” change the world? Will it lead to a greater comfort for those of us waiting for the next terrorist attack to scare us senseless? Somehow I doubt it… But maybe, just maybe, it’ll stop grandma’s password making its way to the Ukraine next month. And that’s kind of the point. Web sites don’t run the world, but they can ruin it for you in a very personal way. Missiles aren’t going to fall out of the sky if your web site is vulnerable to path injection (or at least, let’s really hope not), but if your bank account is suddenly not yours anymore they might just as well have done.

But much as Hollywood’s brief dalliance with attempting to relate to developers by having some idiot repeatedly generate a 404 while “hacking the man” was obviously insane, hoping that a new list (“Larger and now with added scare factor!!!”) will have much impact on the security of things outside of web sites (like embedded device controller logic, or missile guidance systems, or air traffic management environments, or stop lights, or stuff that really, you know, matters) seems to this consumer to be equally off-base.

As an educational instrument I wish it all the success in the world. Better web applications would make lots of peoples’ lives easier. I’d really like to be able to visit any old web site and think that my personal details (“likes rock climbing, sushi and long beach walks…”) aren’t automatically open season for anybody with half a brain and too much time on their hands.

But here’s the bottom line: you don’t get security by enforcing a list. CWE is way, way bigger than this list of “Most Dangerous Programming Errors.” And it needs to be. So don’t go buying that shiny new product because it “Conforms to CWE 25” (or whatever this thing lands up being called). And don’t use the Top 25 to interview your new security consultant. Because what’s outside that list is just as important as what made the cut. Security is a big deal, it’s not a list.