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
