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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <00b001cbe97c$37aa5f40$a6ff1dc0$@isatools.org>
Date: Wed, 23 Mar 2011 10:03:22 -0700
From: Jim Harrison <jim@...tools.org>
To: "'Luigi Auriemma'" <aluigi@...istici.org>
Cc: "'Michal Zalewski'" <lcamtuf@...edump.cx>,
	"'J. Oquendo'" <sil@...iltrated.net>, <bugtraq@...urityfocus.com>
Subject: RE: Vulnerabilities in some SCADA server softwares

You appear to assume that because no one else has reported these vulns
publicly that no one else has discovered them.  This is false logic; proof
is not satisfied by a lack of evidence to the contrary.
To be clear, I do appreciate researchers who spend their time seeking and
reporting security issues and sometimes "just bugz" in vendor software -
it's this sort of independent scrutiny that keeps the vendors honest and on
their toes. 

Where I take issue is with the false notion that public reporting leads to
anything more than an increased threat potential for the customers
themselves.  Your argument that SCADA devices are by their nature less
threatened due to their use case is false at best.  If *any* threat exists,
that threat is increased by public exposure of unmitigated attack
methodology; whether that threat is limited to clean rooms or public-facing
services is merely a matter of scale. 

in fact, in many cases where full-disclosure has forced immediate reaction
by a vendor, neither the underlying problems that cause the vulnerability
nor vendor's code response were as fully vetted as they might have been
otherwise, leading to an incomplete solution caused by a rushed effort.
This frequently leads to rework and reissuing of product updates, hardly a
customer-serving process.

As to the question of "bugz for hire", there are at least as many arguments
on either side of that discussion.

HTH,

Jim

-----Original Message-----
From: Luigi Auriemma [mailto:aluigi@...istici.org] 
Sent: Wednesday, March 23, 2011 09:54
To: Jim Harrison
Cc: Michal Zalewski; J. Oquendo; bugtraq@...urityfocus.com
Subject: Re: Vulnerabilities in some SCADA server softwares

> I fundamentally disagree with the idea that public disclosure as a 
> means of vendor notification serves any purpose

no problem, if you don't agree with full-disclosure or how I and the other
researchers like me handle these security vulnerabilities you have the full
power and freedom of finding them by yourself and handling them as you
desire.

so now the question is, why don't all these "good guys" spend their personal
time and skills to find these vulnerabilities and reporting them to the
vendors before me?

the answer is that usually such people don't have the skills or simply don't
like the idea of doing a professional work completely for free and even with
the obligation of doing everything the vendor wants before the releasing of
the patch that can take months or even years...
practically a slave.

or do you think that you can contact the vendor asking funds for the
research you have already found?
it would be logical but it's a non-written rule in the security
community: it's better to go with full-disclosure for free.
the only exceptions are Mozilla and Google with their bug bounty programs
but oh well, they are pioneers.

anyway regarding this particular case of SCADA I didn't like the behaviour
of ICS-CERT at all.
this entity has the full power for handling the security research and the
communication between vendor and researcher with benefits (knowledge, funds
and credits) for both but simply does nothing as resulted from the mails I
exchanged with them covering all these aspects... I even don't understand
what should be its work at this point except saying "there is a bug in this
SCADA" and "now the vendor says it's fixed".


> beyond tooting one's own horn and causing a panic state for the 
> application vendor and users.

my mail was completely neutral and had no alarmism in it, I'm even amazed
that someone noticed it.
as usual the panic is generated by non-technician people or people who have
personal interests in speculating on the thing.

Bugtraq is a technical mailing-list for people in the security field and in
same cases its content may not be ready or correctly filtered for the other
people who could see risks that are different than the reality.


> Anyone who honestly believes that the "bad guys" are not watching the 
> same lists where the "good guys" are communicating is operating far 
> too close to a famous Egyptian river.

be sure that the "bad guys" are already aware of similar problems but you
can't know it.
if I can find these vulnerabilities in some hours without knowledge of SCADA
and with a motivation not much far from the "mah let's try this program"
imagine what can be done by how has strong motivation, time and knowledge.


> IMHO, "public disclosure" only serves to increase the threat for the 
> vendor's customers.

take the following consideration:
SCADA systems are intended to work in isolated private networks so nobody
except the authorized users should be able to even "ping" the machines where
are running the vulnerable softwares.
if this happens means that the security of the company has been already
compromised before.

now that the users of the vulnerable products are aware of the
vulnerabilities they can verify if their network is really safe like it
should be in any case and in the meantime they will wait the patches of the
vendors.


---
Luigi Auriemma
http://aluigi.org


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ