[sldev] Viewer security vulnerability disclosure group

Meadhbh Hamrick (Infinity) infinity at lindenlab.com
Sun Dec 28 10:37:49 PST 2008


like all things managed by contract, it is not the contract that is  
important, but the reasonable expectation of both party's behaviors.

when Linden discovers a vulnerability in our software that is not  
being exploited, we're not in a hurry to alert the constellation of  
exploit generators out on the fringes of the net. Well... at least not  
until we have a working fix.

this may be upsetting to some people, but we have a non-insignificant  
obligation to our community to do what we can to prevent fraud, asset  
theft and abuse, and part of our behavior in support of this  
obligation is we don't tell the "bad guys" about vulnerabilities until  
a patch has been applied. unfortunately, it is very difficult to tell  
who is a "good guy" and who is a "bad guy." we currently resolve this  
issue by not telling anyone outside the lab.

but

for reasons previously mentioned, this can be irritating to the  
community of 3rd party software developers we are trying to support  
and encourage. the NDA would provide a legal framework describing  
action we would take should a 3rd party software developer disclose  
information deemed to be sensitive.

in short, it's the paper that tells you, the third party developer,  
that if we tell you that you can do something bad by manipulating the  
right packets in and out of the system, and you tell "bad guys" or  
people who will tell "bad guys", we're at least going to stop telling  
you about new vulnerabilities we discover.

there may be a different process for vulnerabilities that are already  
widely publicized.

there may be a different process for vulnerabilities discovered by a  
3rd party.

i think this process is in keeping with industry best practices.

-cheers
-infinity

On Dec 28, 2008, at 8:10 AM, Tateru Nino wrote:

> 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