[SCADASEC] Implications of SuiteLink's flaw

Brodsky, Jake jBrodsk at wsscwater.com
Fri May 9 10:37:23 CDT 2008


I've been extremely busy all week and unable to respond to this issue
properly.  

Here is my take on the SuiteLink flaw:  This isn't just a denial of
service.  It's a denial of service that can be perpetrated through
firewalls using well crafted packets designed so that the slssvc process
will fault.  So we're not just talking about clogging a WAN or LAN with
a broadcast storm, we're talking about something that even at low
bandwidths will be significant because it will cause the process to fall
on the floor.  

Many seem all in favor of "public disclosure."  I'm not.  

What we have here is an argument of what IS versus what SHOULD BE.
Industry SHOULD BE watching these public notice places, but they don't.
Unless we're dealing with a large organization, it's unlikely they'll
have anyone who knows how to read these things, knows what products are
in use, and knows what to do with them.  

Another point: even if the ISAC organizations are just news clipping
services, they SHOULD BE screaming this at the industry from the
rooftops.  I just checked WaterISAC-BASIC and they had NOTHING about
this disclosure.  This is still more reason why industrial users aren't
going to find out about this stuff.  

How in the world is anyone going to act on this if they don't know to
look for it?  Why are we publishing this?  To make it easier for red
teams to look up this flaw and write software for it?  

Most of the arguments on the merits for public disclosure seem
predicated on the notion that there are sufficient people out there who
will see this notice and to make a difference.  With nothing more than
my personal experience on the inside of this business, I have serious
doubts that this case for public disclosure is a reality.  Again, this
is not what SHOULD BE; this is what IS.  

It would have been nice if we could have flagged this software as
Control System specific in some way.  If we could build a list of major
industrial control systems users, engineers, IT managers, etcetera, then
we could quietly disclose this flaw with the provision that after one
year it will go public.  That will give the industry time to react to it
without giving the high school kids or the news media something to play
with.  

The reason I use a one year time frame is because some installations may
take a month to validate a patch in their environment, and several more
months schedule an update.  We want to make sure that there is
sufficient opportunity for users/asset owners to get around to updating
their critical assets.  Initially, a year seems appropriate.  Later it
might be shortened to as little as six months.  Anything less than that
could expose major SCADA systems to attack.  

Going public also works better if you have a patch distribution system
in your infrastructure.  That does not exist in most control systems
either.  I guess once again, we can argue that it SHOULD BE.  However,
there isn't a safe way to do this.  Restoring a backup of the previous
version isn't going to clean up the threat to life and limb or the
physical mess this could make on the factory floor.  

Jake Brodsky




More information about the scadasec mailing list