[sldev] Viewer security vulnerability disclosure group

Tateru Nino tateru.nino at gmail.com
Sun Dec 28 08:10:13 PST 2008


I'd like to know what benefits the non-disclosure agreements provide.
The lab has a history of not enforcing them, so I'm a bit vague on who
benefits from there being NDAs in this circuit and in quite what way,
exactly. Could you expand on that a little more?

Meadhbh Hamrick (Infinity) wrote:
> 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
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>

-- 
Tateru Nino
http://www.massively.com/



More information about the SLDev mailing list