Are LL Services Vunerable to the OpenSSL Bug?

[Toysoldier Thor]

Considering LL is a company that beleives in OpenSource, I will assume LL's servers and systems would be using the OpenSSL to execute their encryption.  Has there been any word from LL that they have checked all their systems and they are or are not using the vunerable versions of OpenSSL?

Since at minimum all SL accounts log in securely, we need to know LL has confirmed they and we are not at risk.

LL should also be checking ALL HW SW that has a deployed instance of this vunerable version of code - not just the website login (like what it took to log in to these forums for me to post this message).  Their routers, inter-sim communications, etc. should also be checked.

If their systems are currently vunerable, when will the patches be put in place?  Changing our passwords to a new SL password prior to these patches going into place would be useless.

[Phoebe Avro]

I was just going to make a thread on the subject when i saw yours

[TrinityRaine]

is there a way to contact them to ask this information? I was just wondering the same as you both 

[Toysoldier Thor]

I heard through grapevine that the SL website was tested as safe but I would want to hear this directly as a BLOG / SL GRID STATUS statement from LL that they have checked and confirmed their systems are all NOT vulnerable from the OpenSSL.

(this would mean all systems - not just the front facing website)

If its good news, then LL should be making this statement ASAP.  If its not good news, then I suspect we won't hear from LL until they have patched all their vulnerable systems.

BUT.. ATTENTION LL ... if you had vulnerabilities and patched them... YOU MUST TELL US AFTER THE FACT and recommend all SL customer perform a password change.

Fixing the vulnerable systems and not telling us after exposes all LL customer's to the risk that our passwords or more has been compromised.

[Toysoldier Thor]

I guess we could open up a ticket.  But you would think LL would be taking this serious and being proactive.  Again, until they perform a full system wide check of all their systems, I would think they will not respond to any questions like this.

[Phoebe Avro]

A Sec Project Jira will get attension fast i should think

[Phoebe Avro]

I opened a Sec Project jira

[Phoebe Avro]

Ok LL got back to me on the Jira and assure me that LL DO NOT have a vulnerable version of openssl on the websites, and will post about it later today

[CarloAntonio Negulesco]

Do you have a link to your Jira?

 

Thanks!

[Phoebe Avro]

No one but the person that opens a Sec Project Jira and LL can see it!

[Toysoldier Thor]

---

Phoebe Avro wrote:

No one but the person that opens a Sec Project Jira and LL can see it!

---

Well that is good to hear and wise for them to publicly post this on the Blog and Grid Status.

I thought the JIRA was open for all to read - but I guess SEC PROJECTS are restricted?

 

[Phoebe Avro]

Yes Toy for obvious reasons if some one reports an exploit etc, they don't want details of it being spread about untill LL can patch it lol ^^

[Asil Ares]

Thanks for posting this. I tested SecondLife.com and https://id.secondlife.com via the Heartbleed test site (http://filippo.io/Heartbleed/) and they show as fixed (or uneffected).  But that's just two domains and only show the current state, not what came before. 

[CarloAntonio Negulesco]

Well, ok. Please let us know if they respond.

 

Thanks!

[Toysoldier Thor]

---

Asil Ares wrote:

Thanks for posting this. I tested SecondLife.com and

https://id.secondlife.com

via the Heartbleed test site (

http://filippo.io/Heartbleed/)

and they show as fixed (or uneffected).  But that's just two domains and only show the current state, not what came before. 

---

Thanks Asil,

And yes... its very important for LL to formally state that they were NEVER IMPACTED by the vulnerability as opposed to they were but they patched the bugs. If it was that they recently fixed the bug then SL users should change their passwords (which they should do frequently as good practice).

Also, I would hope LL reports that they have checked their entire system (all components - not just the common front facing secondlife.com domains and respective web servers).  The code should be removed from any system that uses the openSLL for encryption - especially those exposed to the internet in any way.

[Neural Blankes]

I'd like to know, also, if things were never vulnerable in the first place, or if they have only recently been fixed.

[Phoebe Avro]

Hopefully LL will make a statment soon but i was told by LL that they had not been using a vulnerable version before the 'bug' was found so i guess they were using a modded version already

[Toysoldier Thor]

---

Phoebe Avro wrote:

Hopefully LL will make a statment soon but i was told by LL that they had not been using a vulnerable version before the 'bug' was found so i guess they were using a modded version already

---

OR.... LL is so far behind keeping their software up to date that they never updated their OpenSSL code in about 2 years and are using a version prior to version 1.0.1.  That would not surprise me.

[Phoebe Avro]

lol

[nikita Jefferson]

I ran secondlife .com through my VPN providers test for vulnerabilty of websites.

I tested secondlife .com and got this come back.

 

All good, secondlife.com seems fixed or unaffected !

 

So it would seem all is ok

[Soft Linden]

I asked the blog team to post this:

http://community.secondlife.com/t5/Tools-and-Technology/Account-Safety-and-the-Heartbleed-OpenSSL-Bug/ba-p/2619322

The short of it is your password is fine unless you were reusing your password on another non-SL site. If you were, please change your password to something unique to SL.

Yes, the reason the authentication sites were not vulnerable is because they were on old versions of software. Only security fixes were backported, while new features like Heartbeat were not added without a chance to mature. Jumping to the newest version of server software isn't always the best practice. In fact, that practice is the very reason why so many sites were vulnerable. You can read more about this security philosophy here:

https://www.debian.org/security/faq#version

https://www.debian.org/security/faq#oldversion

Thank you for your interest in keeping SL safe. In the future, don't hesitate to file a security JIRA if you worry we've missed anything critical. We watch those 24/7.

[Phoebe Avro]

Thank you Soft!

[Toysoldier Thor]

Good news Soft. Thanks for publicly informing us on the status of this bug.

[Darien Caldwell]

---

Toysoldier Thor wrote:

Considering LL is a company that beleives in OpenSource, I will assume LL's servers and systems would be using the OpenSSL to execute their encryption.  Has there been any word from LL that they have checked all their systems and they are or are not using the vunerable versions of OpenSSL?

Since at minimum all SL accounts log in securely, we need to know LL has confirmed they and we are not at risk.

LL should also be checking ALL HW SW that has a deployed instance of this vunerable version of code - not just the website login (like what it took to log in to these forums for me to post this message).  Their routers, inter-sim communications, etc. should also be checked.

If their systems are currently vunerable, when will the patches be put in place?  Changing our passwords to a new SL password prior to these patches going into place would be useless.

---

OpenSSL is by no means the only open source SSL implementation. In fact, out of the 11 major libraries, all but one are open source:

http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations#Overview

So, there's a 1 in 10 chance they were using OpenSSL, 1 in 11 if they used something not open source (which they sometimes do). Of course that assume an equal distribution, and that's unlikely. Each implementation probably has a unequal market share of users. Sadly I was unable to find any data on the popularity of varous implementations.