[sldev] Viewer security vulnerability disclosure group

[Henri Beauchamp]

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.