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