lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 23 Mar 2011 13:03:51 -0600
From: Theo de Raadt <deraadt@....openbsd.org>
To: "J. Oquendo" <sil@...iltrated.net>
Cc: Jim Harrison <jim@...tools.org>,
	"'Luigi Auriemma'" <aluigi@...istici.org>,
	"'Michal Zalewski'" <lcamtuf@...edump.cx>, bugtraq@...urityfocus.com
Subject: Re: Vulnerabilities in some SCADA server softwares

> On 3/23/2011 2:13 PM, Theo de Raadt wrote:
> >> If *any* threat exists,
> >> that threat is increased by public exposure of unmitigated attack
> >> methodology
> > I think you have it wrong.
> >
> > Public exposure increases the visibility, and therefore customers
> > install the patches quicker.
> >
> > Without public visibility, they will keep running the old code.
> 
> You're flawed in your response: "Public exposure increases the
> visibility, and therefore customersinstall the patches quicker." ...
> When someone "full discloses" a vulnerability, there is no patch to
> install quicker.

With public involvement, the timeline goes a bit like this:

1 - Full disclosure
2 - Publically, the vendor looks bad to customers
3 - A fix is crafted immediately; tested rapidly, then released to
    customers.
4 - Publically, customer and vendor would look bad if they did not
    install the fix immediately -- as soon as it is available

I am very well aware of what is going on out there in industry:
Customers do not install patches unless they have to, because various
realities of the environment make it hard.  That does not make
deferring the repairs acceptable.  The public eye can help improve
this situation.

> This is obvious because there is no patch until either
> the vendor releases one, or staff using the product are capable of
> creating a work-around.

No, it is not obvious that no patch is available.  Quite often patches
or upgrades do exist, but it has not been deployed.  Sometimes the
SCADA vendor is responsible for trying to charge more, also.

> In the case of the SCADA environment, we (again)
> are not talking about the potential of a defacement, blue screen, silly
> shell, we're talking about sensor, gears and often so much automation
> that it would be absurd for a SCADA engineer to "go it alone" and try
> create their own patch. Many of these systems don't have the option of
> failing or being taken offline. You also state: "Without public
> visibility, they will keep running the old code" the reality is, no one
> is going to outright replace some of these systems in these
> environments. These are not applications and or systems one can plop
> onto donated boxes. They have no choice BUT to run the code.

Oh give me a break.  You are talking to me as if I am a child, which
means you don't know who I am.

The people involved in selling and re-selling these broken SCADA
system software are the children.  For financial or other reasons they
have assumed that the same "quality control failure leads to bugs
leads to exploits" game that has affected generations of software
would not apply to them.

It happened to the Unix environment.  Then it happened to the
Microsoft environment.  Then it happened to the Linux environment.
And then it happened to the browser environment.  Currently it is
happening to the cell phone environment.  You expect me to believe it
will not eventually happen to the SCADA environment?

And it does not make an ounce of difference how much the defenders of
the SCADA world whine about full disclosure being evil.  I expect a
surge of published exploits against SCADA software, and whining about
"full disclosure" will not stop it.  You might think you are all
creative with your arguments, but we've heard it all before.

And yes, I think someday soon we are going to start having the same
arguments about software in use at hospitals, and I think full
disclosure will happen about those too.  As it should.

Quality controls do not get strong until the risks are visible.  So go
ahead, talk about the risks but do not blame messengers.

Yes, with SCADA there is tremendous danger to our infrastructure -
from a safety perspective and from a financial perspective.  But is
the browser situation any different, for the public, if you total
potential financial losses?  (It is fair, a utility with a massive
SCADA failure would eventually socialize the losses after conversion
to dollars and cents).

If there is danger, why are the vendors not getting ahead of the
curve?  We know they are not getting ahead of the curve.  If you use
SCADA software, go read your contracts to gauge where the liability
lands.  I suspect you already know.  And I suspect all the people
arguing against full disclosure work on "that side" of the industry.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ