[sldev] Viewer security vulnerability disclosure group

Tateru Nino tateru.nino at gmail.com
Fri Dec 26 22:31:25 PST 2008



Gordon Wendt wrote:
>
>     On Fri, Dec 26, 2008 at 2:40 PM, Gordon Wendt
>     <GordonWendt at gmail.com <mailto:GordonWendt at gmail.com>> wrote:
>     > If it's
>     > something without a quick fix that can be fixed or even just
>     mitigated
>     > client side I trust Nicholaz and the other 3rd party viewer
>     makers more than
>     > LL to get a good patch out to their users.
>
>     I'm confused at the distinction here.  If I take "without a quick fix"
>     to mean something like "LL thinks the ETA for the fix is far enough in
>     the future that sending separate disclosure to third-party viewer
>     maintainers makes sense", this sounds a lot like an early disclosure
>     group to me.  What's the difference?
>
>     Celierra
>
>  
> My bad for not being more clear, by disclosing the problem I meant to
> everyone not just to the "select" group of people.  If LL can't get a
> fix out in time and especially if it's something that can be mitigated
> then everyone should know about it so that they can at least do their
> best to mitigate their exposure to it and  if it's a client side issue
> possibly patch it themselves before LL can.
What are people's thoughts on issues that cannot be mitigated by the
user? While there's a lot of people couldn't manage to disable quicktime
on their own (and perhaps half of SL users have never even heard of that
exploit), there's still a whole class of security issues about which the
user may be able to do nothing (some examples were dealt with recently).

Pending any better information, I'm guessing the Lab's best effort
response to a serious viewer security exploit would be 48-72 hours. The
exploit needs to be confirmed and found; options to fix it have to be
discussed; any concomitant factors need to be taken into account; the
fix has to be *tested* to make sure it actually fixes the exploit and
any obvious variations. Then formal QA starts to make sure that the
viewer still works properly in all other ways - because, heck, the fix
may have had an unforseen side-effect.

Somewhere around the time this last QA phase begins, I'm guessing is
when it is proposed that the third-parties on the disclosure list get
notified, which would have their own viewers ready around the same time
that Linden Lab finishes its QA pass on the first-party viewer.

During all this time, exploiters will presumably be sharing information
about the exploit with other exploiters and exploring variations of the
exploit to see if other flaws can be .. well, exploited by similar means.

Most of the information actually in circulation among the users about
(imagined) current exploits is largely incorrect - of the order of urban
myths, and the penetration of knowledge of actual exploits and how to
mitigate them (where that is possible) rarely spreads very far among the
user-population. Paradoxically, security updates cause more anger and
resentment than any other feeling.

Actually, that brings me almost full circle. Let's assume that there is
an exploit which can be mitigated by users, but is quite severe.
(something of the order of the quicktime exploit for mitigation). Assume
that this is fully disclosed when discovered. Roughly 65% of active
users (which is a guess, but an educated one, so it's a pretty solid
number) either won't become aware of it, or won't apply any mitigation
(there are a number of factors involved there).

Does that present a problem, if the majority of the users do nothing
when exploit details become fully public? I think it does.


More information about the SLDev mailing list