[sldev] Viewer security vulnerability disclosure group

[Meadhbh Hamrick (Infinity)]

thx, henri... i think you understand what i'm trying to communicate.

but... let me take a stab at trying to recapitulate boy lane's concerns:

"LL discovering a vulnerability in the viewer code and not disclosing  
to people who enhance the SL community by building on top of the  
viewer is irritating and possibly immoral."

because... it puts LL in the position of being able to produce a  
vulnerability free viewer, disclose the vulnerability and then have  
the rest of the community scrambling to try to fix their products.

or maybe it's the... information wants to be free / there should be no  
asymmetric information concept.

so.. getting back to Rob's original post...

"do you think it's acceptable for Linden to REQUIRE members of the 3rd  
party viewer community to sign a non-disclosure agreement as a  
precondition of receiving early disclosure notices?"

and if not, why?

On Dec 27, 2008, at 11:44 AM, Henri Beauchamp wrote:

> On Fri, 26 Dec 2008 19:16:47 -0800 (PST), Boy Lane wrote:
>
>>> so... this is just a long winded discussion to support the following
>>> statement:
>>>
>>> "telling everybody about a security vulnerability before  
>>> remediation is
>>> available is bad."
>>
>> And this is simply wrong. Not only wrong but unacceptable.
>>
>> We don't need to go through a long list of historical events or  
>> personal
>> experiences. Let's just keep it down to the facts.
>>
>> LL decided to put the SecondLife code into open source, available for
>> everyone everywhere. As such any approach of security through  
>> obscurity
>> is doomed to fail.
>
> It is not as much as ensuring "security via obscurity", than to avoid
> giving to script kiddies, wannabe hackers and griefers an easy recipe
> for hacking SL before the vulnerability is plugged.
>
>> .../...
>> I'd expect LL to provide regular security bulletins in an organized  
>> way,
>> accessible to all users who would be interested in them. That does  
>> not
>> mean a detailed piece of code, but a clear description of the
>>  vulnerability and the risk.
>
> Mind you, a very large number of Open Source project (I could cite the
> Linux kernel itself !) sometimes do delay the publication of a
> vulnerability so to prevent major security risks. Describing what
> feature is flawed is just a pointer to where to lok at in the code,
> so even if you don't give a piece of code as a proof of concept to
> demonstrate how someone could exploit a vulnerability, you still
> give directions to hackers as to where to search. Admitedly, this
> would only permit to true hackers to find out a proper exploit,
> but it is still a big risk to take.
>
>> A good distribution list reaching dedicated people would indeed be
>> the SLDev mailing list. So that developers can decide what to do,
>> perhaps help to fix it in faster way than LL would be able to or
>> is unwilling to do, or if this is not possible to provide
>> recommendations such as not to use a particular version of the  
>> viewer.
>
> Depending on the vulnerability and what risk it involves, this list
> is indeed good enough. Even the SL grid status blog could do...
>
> Examples:
>
> 1.- A vulnerability is discovered in the viewer that allows people
> to crash it via a particular set of parameters (in a prim, a media,
> etc).
>
> There is no big risk here, but for "standard" griefing which can
> easily be dealt with or worked around (by muting the griefer for
> example).
>
> In this case, the vulnerability and the work around should be made
> public on the grid status blog so that everyone is aware of it
> and knows what to do should the vulnerability hit them before a
> definitive fix is published.
>
> 2.- A vulnerability is discovered that would allow a clever hacker
> using their own hacked simulator (on an OpenSim grid) to rob money
> to people visiting their sim.
>
> The risk higher, here, and it is best to restrict the audience of
> people who will be aware of how to exploit the vulnerability.
> Publishing the details on the sldev list would be fine, and a
> warning shall also be published on the SL and OpenSim blogs to
> warn people and ask them to avoid connecting to OpenSim servers
> they don't trust till a new version of the viewer is published.
>
> 3.- A vulnerability is discovered internally by LL that would allow
> to steal money on the SL grid via a particular set of parameters
> (in a prim, a media, etc).
>
> This is a very high risk vulnerability (it does not even involve
> hacking a server, but only providing a crafted asset in a standard
> sim), and it is likely that only LL is aware of it so far.
>
> I do think such a vulnerability shall *not* be disclosed until
> a proper fix id found, possibly associating trusted third parties
> developpers.
> Once the fix is found, all the developpers of the third parties
> viewers should recieve the patch and some time should be left for
> them to publish updated versions of their viewers, time during which
> LL would publish their own official version.
> Only then, should the vulnerability be disclosed to the public.
>
>> I remember that last security disaster in the 1.20.17 version. LL
>> decided to work behind closed doors. Even though a fix was internally
>> available it was not provided in source / patch form to 3rd party
>> developers,
> This is not entirely true... LL did indeed not tell anyone about
> the vulnerability until they had fixed it, but then the updated code
> was provided to third parties developpers. Admitedly, this latter
> part could have been optimized and this is exactly what Rob proposed
> with the dedicated vulnerability list.
>
>> leaving 10's if not 100's of thousand users vulnerable.
>
> Partially true: but till a fix is found, anyone is vulnerable anyway.
> Not disclosing the vulnerability at least prevented script kiddies
> and wannabe hackers to exploit it... so, I personally thing it was
> the right thing to do.
>
>> It was only made available several days later through obscure
>> channels to a handful of developers who asked for.
>
> Here again, not entirely true: an announce was publiches on this
> list, asking to third parties developpers to contact Rob.
> Admitedly, this was not the fastest and easiest of the processes,
> thus the interest of a list.
>
>> And it was half hearted as LL decided not to backport the security
>> patches to the 1.19 pre-windlight viewers but left that task
>> completely to the developers of alternative viewers.
>
> Yes, I did the backport to v1.19. But although I regret (and tell
> it on every occasion, like now) that LL does not maintain a viewer
> with the legacy renderer any more (thus letting people with 3 years
> old computers without a usable and resonably fast viewer for their
> machine), I cannot blame them for not providing a fix to a
> discontinued branch of the viewer...
> Take Firefox... v1 has been discontinued even though it's the only
> version that can run reasonnably fast on old, i586 computers (thanks
> to GTK+ v1 which is much less bloated than v2 and runs twice or thrice
> faster). Firefox v2 will soon be discontinued too... there are no
> security fix for discontinued Firefox branches: that's life...
>
>> The only way to mitigate the risk was to tell people not to use in
>> our case the Cool Viewer as the vulnerability and risks were unknown.
>
> The Linux version of the Cool SL Viewer (both v1.19 and v1.20) was
> fixed within 24 hours of the release of the official LL viewer...
> Not that dramatic, but a dedicated mailing list would definitely help
> reducing such delays down to 0.
>
>
> So, to summarize, I'll just say that:
>
> There is no simple rule as to whether or not all vulnerabilities
> shall be disclosed. It all depends on how severe is the vulnerability,
> on who discovered it, and whether there is an existing work around or
> not.
>
> If the vulnerability is severe, *and* was discovered internally by LL
> *and* has no work around, then it is definitely safer for everyone to
> fix it internally, publish the patch only to third parties vewiers
> makers, and only after everything is pluged, tell everyone else about
> it and ask them to update immediately.
>
> Henri.
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting  
> privileges