« The OWASP AppSec USA 2011 Call for Papers (CFP) | Main | NIST publishes 50kish vulnerable code samples in Java/C/C++, is officially krad »

How not to publish SCADA security advisories

"Luigi Auriemma" has posted an interesting series of SCADA vulnerabilities to the bugtraq security list this morning. From his email

"The following are almost all the vulnerabilities I found for a quick experiment some months ago in certain well known server-side SCADA softwares still vulnerable in this moment.

In case someone doesn't know SCADA (like me before the tests): it's just one or more softwares (usually a core, a graphical part and a database) that allow people to monitor and control the various hardware sensors and mechanisms located in industrial environments like nuclear plants, refineries, gas pipelines, airports and other less and more critical fields that go from the energy to the public infrastructures and obviously also the small "normal" industries.

In technical terms the SCADA software is just the same as any other software used everyday, so with inputs (in this case they are servers so the input is the TCP/IP network) and vulnerabilities: stack and heap overflows, integer overflows, arbitrary commands execution, format strings, double and arbitrary memory frees, memory corruptions, directory traversals, design problems and various other bugs."

As is indicated in bold above, this is interesting because these vulns are more targeted towards critical infrastructure systems, rather than your mom's PC. The Stuxnet worm exploited attacks against systems just like this and are believed to be used to slow down Iran's nuclear weapons program. So while many of the issues are just other examples of known attacks and weaknesses, the scope of abuse is considerably different.

A few folks replied asking if he had contacted the vendors, and the reply indicated that they became aware of the issue as the post hit bugtraq. If you're ever worked in a software shop before you'll know that depending on the issue (or issues in this case) that

  • It can take a day or two to identify/apply the fix depending on how many OS's are supported and dependencies exist
  • Could take a couple of days to test the fix against all applicable product use cases
  • Another day to publish the fix and advisory
  • Days to weeks to properly notify all effected customers (press releases, phonecalls, emails, etc)

Given that the author is using their real name (to get credit), and are fully aware of what SCADA is used for, I'm surprised that they'd knowingly jeopardize systems which could influence critical infrastructure.

To be clear I'm ok with people publishing advisories (with proper vendor notification), and I also believe that some vendors blow you off until an issue is public. When it comes to vendors blowing you off/refusing to acknowledge a problem I think that judgement should be used on a case by case basis. In this case however based on the public reply the vendors had no chance to work with the disclosure of this issue in advance to fix any issues.




Feed You can follow this conversation by subscribing to the comment feed for this post.

All Comments are Moderated and will be delayed!

To be clear I'm ok with vendors blowing off security (with proper risk management), and I also believe that all vulnerability researchers should support the No More Free Bugs campaign. When it comes to vendor outreach and hiring appsec consulting companies, I think that governance should be used. In this case however based on the lack of vendor outreach/governance, the vulnerability researcher had no chance to work with the disclosure of this issue in advance to fix any issues.