SCADA system vulnerabilities
By Jake Edge
June 11, 2008
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.
Comments (5 posted)
New vulnerabilities
kernel: arbitrary code execution
| Package(s): | kernel |
CVE #(s): | CVE-2008-1673
|
| Created: | June 9, 2008 |
Updated: | November 14, 2008 |
| Description: |
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.
|
| Alerts: |
|
Comments (none posted)
kernel: arbitrary code execution
| Package(s): | kernel |
CVE #(s): | CVE-2008-2358
|
| Created: | June 9, 2008 |
Updated: | August 13, 2008 |
| Description: |
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.
|
| Alerts: |
|
Comments (none posted)
net-snmp: buffer overflow
| Package(s): | net-snmp |
CVE #(s): | CVE-2008-2292
|
| 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). |
| Alerts: |
|
Comments (none posted)
openoffice.org: integer overflow
| Package(s): | openoffice.org |
CVE #(s): | CVE-2008-2152
|
| Created: | June 11, 2008 |
Updated: | September 10, 2008 |
| Description: |
OpenOffice.org has reported an integer overflow vulnerability in rtl_allocateMemory(). |
| Alerts: |
|
Comments (none posted)
snort: detection rules bypass
| Package(s): | snort |
CVE #(s): | CVE-2008-1804
|
| Created: | June 6, 2008 |
Updated: | June 11, 2008 |
| 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. |
| Alerts: |
|
Comments (none posted)
tomcat: insufficient input sanitizing
| Package(s): | tomcat5.5 |
CVE #(s): | CVE-2008-1947
|
| Created: | June 10, 2008 |
Updated: | October 2, 2008 |
| 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. |
| Alerts: |
|
Comments (none posted)
ucd-snmp: possible spoof
| Package(s): | ucd-snmp |
CVE #(s): | CVE-2008-0960
|
| 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. |
| Alerts: |
|
Comments (none posted)
Page editor: Jake Edge
Next page: Kernel development>>