[asterisk-dev] Re: Security Through Obscurity

[Matthew Rubenstein]

On Sun, 2007-03-04 at 22:44 -0700, asterisk-dev-request at lists.digium.com
wrote:
> Date: Sun, 04 Mar 2007 23:11:39 -0600
> From: "Kevin P. Fleming" <kpfleming at digium.com>
> Subject: [asterisk-dev] Re: Security Through Obscurity
> To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
> Message-ID: <45EBA68B.6050601 at digium.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Matthew Rubenstein wrote:
> >       This security reality is well known in the programming
> industry. I'm
> > disappointed to see Digium acting as if it weren't.
> 
> What is obscured? We clearly stated that the vulnerability existed,
> the
> patch to fix it was public, the release that contained that patch was
> public.

	As you yourself have stated, what was obscured was the specific nature
of the exploit. The "why", AFAICT, is that "x version is insecure".


> You would prefer that we enable people who don't have a clue how to
> write an exploit to write one anyway by giving them instructions? How
> does that benefit anyone? Your comments imply that we are denying that
> the problem exists, or hiding what the fix was. Nothing could be
> further
> from the truth.
> 
> Every single vulnerability we have corrected since I joined Digium
> (which, I believe, is now five) was reported to us privately, fixed
> quickly with an open-source patch as we always do, and then (except
> for
> this last one) the company that found the vulnerability made a press
> release/security advisory detailing what the flaw was and documenting
> when/how it was fixed, what versions were affected, and what users
> should do to protect themselves.
> 
> In this case, we took the action to document that it was fixed and
> told
> users they should upgrade (and why), because I don't believe this
> particular issue was reported by an auditing company so there won't be
> an independent release about it. If you want someone to post an
> analysis
> of what the problem was and show you how to exploit it, contact them
> (they seem to be interested in getting paid for fixing people's
> systems
> anyway <G>).

	The previous exploits were handled the way that the industry recognizes
minimizes risk for everyone (except for the bad guys). This one left the
users without knowing how the exploit would affect our systems, and what
specific tradeoffs (if any) might be made in patching. Like perhaps
whether our firewalls or usage (eg. outbound connections only + callfile
origination only + blocked pings) might protect us until a more
convenient time to stop a running server for a while to patch/test
(possibly rollback, etc).

	You've already acknowledged the proper complete protocol. Which is the
standard industry practice. Why are we debating whether a diversion from
full disclosure is not riskier?
-- 

(C) Matthew Rubenstein