Core Security released a security advisory on 11 June that details a fairly pedestrian stack-based buffer overflow vulnerability. This is similar to hundreds or thousands of this kind of flaw reported over the years except for one thing: it was found in large industrial control systems for things like power and water utility companies. That there is a vulnerability is not surprising—there are certainly many more—but it does give one pause about the dangers of connecting these systems to the internet.
The bug was found in a Supervisory Control and Data Acquisition—better known as SCADA—system and could be exploited to execute arbitrary code. Given that SCADA systems run much of the world's infrastructure, an exploit of a vulnerable system could have severe repercussions. The customers of Citect, the company that makes the affected systems, include "organizations in the aerospace, food, manufacturing, oil and gas, and public utilities industries."
Makers of SCADA systems nearly uniformly tell their customers to keep those systems isolated from the internet. But as Core observes: "the reality is that many organizations do have their process control networks accessible from wireless and wired corporate data networks that are in turn exposed to public networks such as the Internet." So, the potential for a random internet bad guy to take control of these systems does exist.
None of that should be particularly surprising when you stop to think about it, but it is worrying. Many SCADA systems—along with various other control systems—were designed and developed long before the internet started reaching homes and offices everywhere. They were designed for "friendly" environments, with little or no change for the hostile environment that characterizes today's internet. Also, as we have seen, security rarely gets the attention it deserves until some kind of ugly incident occurs.
Even for systems that were designed recently, there are undoubtedly vulnerabilities, so it is a bit hard to believe that they might be internet-connected. According to the advisory, though, SCADA makers do not necessarily require that the systems be physically isolated from the network, instead customers can "utilize technologies including firewalls to keep them protected from improper external communications."
Firewalls—along with other security techniques—do provide a measure of protection, but with the stakes so high, it would seem that more caution is required. It is probably convenient for SCADA users to be able to connect to other machines on the LAN, as well as to the internet, but with that convenience comes quite a risk. Even systems that are just locally connected could fall prey to a disgruntled employee exploiting a vulnerability to gain access to systems they normally wouldn't have.
One can envision all manner of havoc that could be wreaked by a malicious person (or government) who can take over the systems that control nuclear power plants, enormous gas pipelines, or some chunk of the power grid. Unfortunately, it will probably take an incident like that to force these industries into paying as much attention to their computer security as they do to their physical security.
|Created:||June 9, 2008||Updated:||November 14, 2008|
From the Debian advisory:
Wei Wang from McAfee reported a potential heap overflow in the ASN.1 decode code that is used by the SNMP NAT and CIFS subsystem. Exploitation of this issue may lead to arbitrary code execution. This issue is not believed to be exploitable with the pre-built kernel images provided by Debian, but it might be an issue for custom images built from the Debian-provided source package.
|Created:||June 9, 2008||Updated:||August 13, 2008|
From the Debian advisory:
Brandon Edwards of McAfee Avert labs discovered an issue in the DCCP subsystem. Due to missing feature length checks it is possible to cause an overflow they may result in remote arbitrary code execution.
|Created:||June 11, 2008||Updated:||December 4, 2008|
|Description:||From the CVE entry: Buffer overflow in the __snprint_value function in snmp_get in Net-SNMP 5.1.4, 5.2.4, and 5.4.1, as used in SNMP.xs for Perl, allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a large OCTETSTRING in an attribute value pair (AVP).|
|Created:||June 11, 2008||Updated:||September 10, 2008|
|Description:||OpenOffice.org has reported an integer overflow vulnerability in rtl_allocateMemory().|
|Created:||June 6, 2008||Updated:||December 11, 2009|
|Description:||From the CVE entry: preprocessors/spp_frag3.c in Sourcefire Snort before 2.8.1 does not properly identify packet fragments that have dissimilar TTL values, which allows remote attackers to bypass detection rules by using a different TTL for each fragment.|
|Created:||June 10, 2008||Updated:||February 17, 2009|
|Description:||From the Debian advisory: It was discovered that the Host Manager web application performed insufficient input sanitizing, which could lead to cross-site scripting.|
|Created:||June 10, 2008||Updated:||December 4, 2008|
|Description:||From the Red Hat advisory: A flaw was found in the way ucd-snmp checked an SNMPv3 packet's Keyed-Hash Message Authentication Code (HMAC). An attacker could use this flaw to spoof an authenticated SNMPv3 packet.|
Page editor: Jake Edge
Next page: Kernel development>>
Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds