Security Update: 26 Sept 2008

Linden Lab has released an optional update to the Second Life viewers today to address a potential security issue. Recently an audit identified a possible vulnerability. If a malicious user were able to obtain the IP address and port of a Resident’s viewer, then the malicious user could forge data packets to the Resident’s computer. This could be done in a way to cause the viewer to return enough information about its session to allow the attacker to initiate various server-side operations as if they were the Resident, including L$ transactions.

In the case of L$ transactions, this action would be visible to you: if this were to occur, the viewer would report the transaction after it occurred in the normal blue dialog box. You are also always able to inspect your transaction log. This would allow you to notice and report these actions for violating the Second Life Terms of Service.

This type of malicious action would constitute a violation of the Terms of Service, and would be against the law in some locations. At this time we have no evidence that this vulnerability was ever exploited.

To eliminate this vulnerability, we have now updated the Second Life servers to transmit the messages over an encrypted channel (HTTPS). Now that the server upgrade is complete, we are releasing updated viewers that only accept these messages when transmitted over an encrypted channel. Once you have downloaded the update, if a malicious third party were to attempt to send messages over the old channel (UDP), they would be ignored.

Again, we have no indication to date that this security issue has ever been exploited or is being exploited currently. However, we strongly encourage Second Life Residents to update to the latest viewer with the security patches in place. The viewers are:

* Second Life Release Viewer 1.20.16 (this updates 1.20.15, released on July 24th)
* Second Life Release Candidate Viewer 1.21 RC3 (this updates RC2 and includes additional bug fixes as part of the usual release candidate cycle)

Older viewers (such as the 1.19 series) are not being required to upgrade to version 1.20.16, but we encourage Residents to update if possible to take advantage of the latest bug and security fixes.

The updated source code for these new 1.20 and 1.21 RC viewers is being made available via the usual open source channels.

I know I won't be updating this as it would break my Nicholaz edition viewer which relies on 1.19.1.4 to work which leads me to the question is this really client side necessary (because of the change in the communications protocols). Also could, and would it be feasible, to migrate to a modular approach for this type of thing so that communications protocls could be updated as needed for security or to fit any changes in the architecture without requiring a full client update that would break anything and everything that requires specific version. Of course that would have to come with being able to make custom viewers work just as well without necessarily relying on specific behind the scenes functions being the same, such as the protocols, which a custom client has no real need to change anyway most of the time while of course allowing such changes if needed.

Will this break open grids (OpenSim) that rely on -helperuri for transactions? Most OpenSim installations have no SSL certs at all!

Ramzi, was it possible for somebody to trigger an in-world Buy L$ operation via this?

Oh for gods sake I crash when logging in to this updated version!
Get it right before you do this gezz.

tbh this needs to be mandatory
detailed directions on how to use this to steal anyones money has been public for a while on both the pn wiki and the secondlifeharold.com for a few weeks




Mandatory for your protection

Mandatory for your life

So far as I know the only way to get someones IP address via SL is to run a shoutcast server, darwin or apache and use the media or audio streams to get people to connect. I think you're relatively safe so long as you only attend reputable clubs and don't walk around with your audio and/or media playing constantly (or in that evil automatic mode). I'm not going to say make it mandatory, but a blurb on the official blog and perhaps a mass-mailing announcement are in order?

---Edit
Just checked the Harold, so nice of them to post the source code for this hack. Disabling streaming audio and video in the older clients would be a good security measure when you're not at home or in a familiar club.

Mandatory for my protection and my life? I hardly think it is that dire. Geez, even if I lost all of my L$, it might amount to 10-15 US $. I just don't think that we need someone trying to force protection of a possible threat on us. Their blog indicates the problem has been there for some time and as far as they know it has never been exploited.

Personally, I detest the more recent viewers and have every intention of staying with Nicholaz BE-w and 1.18.5.3 for as long as possible.

Why is the viewer accepting incoming connections from arbitary hosts? Or even, at all?

It's not - it's UDP and waits for packet returns from the expected SL host on a certain port. It doesn't care about the SL host's IP, just the port. What can happen is somebody could try to forge a return packet from the expected UDP port and the client would accept it. Similar to the July DNS exploit.

Ramzi, would you please clarify this statement for us? Does this mean that the older viewers are not vulnerable or that you are allowing the users the choice to remain vulnerable at their own risk?

Hi Kathy,
This statement means to say that we have not applied the security patch to versions older than 1.20. We are allowing these Residents the choice to upgrade to the current viewer.

The older viewers 1.19 / 1.19.1 still rely on a message from the simulator sent via UDP, which yes, is theoretically susceptible to such an exploit. I should mention that trying to utilize the vulnerability is extremely technically difficult to accomplish and is not something that is possible with remote code-execution. In other words an attacker needs to be actively engaging with your avatar to even begin to attempt the vulnerability. This would also be traceable on the server.

We believe the risk is very low. We have provided these 1.20 / 1.21 viewer updates to close this vulnerability and so that all Residents may benefit from the latest bug and security fixes.

Hi Sindy- The answer is no, it was not possible. A Buy L$ operation would have required secure information from a viewer beyond the limited session information that a malicious user could have "hacked" to obtain from your viewer.

Thank you Ramzi. Makes it easier to understand now.

Hi Zoomie-
We believe the risk is extremely, extremely low. Since the servers have already been updated and now the majority of viewers will be upgraded voluntarily, the available targets for such an attacker has just been prohibitively reduced. I should mention that trying to utilize the vulnerability is enormously technically difficult to accomplish and is not something that is possible with remote code-execution. In other words an attacker needs to be actively engaging with your avatar to even begin to attempt the vulnerability. This would also be traceable on the server.

We have provided these 1.20 / 1.21 viewer updates to close this vulnerability completely and so that all Residents may benefit from the latest bug and security fixes.

Nothing relevant other than a big thankies for Ramzi for starting a forum thread on this, and more importantly checking back to answer everyone's concerns.

It's a very pleasant change .

Yeah well I like the old interface too much (could never get used to the newer interfaces) so I stick to my Nicholaz version based on 1.19 whatever the potential risks

Awesome. TY for the clarifications & details, Ramzi.

Is there some sort of "telltale sign" we can look for, other than the blue dialog? (remember that payment dialogs can be disabled in preferences). Can you more clearly define "Actively engaging with your Avatar?".. Are we talking "physical" co-location of avatars? or IMs? Group IMs? If the Avatar needs to be in proximity to the target, are we talking withing a certain distance? or anyplace on the same parcel? Or anywhere in the same region? or perhaps we're talking about anyplace in the same estate? (that would be pretty huge for mainland).

Is Parcel media involved at all? or perhaps Voice? would disabling these improve anyone's chances?

Personally, I've downloaded the latest version.. but I know a lot of people who won't.. so the question becomes one of "what other steps can they take to protect themselves?"

One thing is for sure.. People should make sure that payment notices aren't disabled.

The new viewer is ... interesting. Mine now crashes after I have been about 15 seconds. Both the 1.20 and 1.21 versions.

hi,

it broke opensim compatibility. i can't see, enter or tp other regions.



tx Oh

does it has a release note somewhere?

tx Oh

Hmmmm, on this latest viewer so far i see that there is something wrong in Camera Controls! Anyone?
In 1.9... viewer camera controls work just great, so i may go back to it.

But guys, don't forget we do have tear off menus now.....


Does this mean this very very low risk exploit, isn,t the sky falling afterall?

I'm besumed that to cure this potential exploit, we have to upgrade the RC client, which is optional and very buggy, yet all those that prefer the somewhat stable 1.19 client, which is not a mandatory upgrade, are left to the potential wolves?

If you going to broadcast the sky is falling, at least make sure everyone upgrades to fix it.. not leave it as a 'choice'. If you are custodians of our IP rights, you should always make security bug fixes madatory, not a 'we told you so'.. event.

Personally, there are so many variations of clients used in the Grid, including some of the less buggy 3rd party clients, only a mandatory update will ever close any security fixes. I believe the stance of not forcing updates, is mainly due to the many issues with the current batch of RC clients, that it would cause meltdown to LL support if mandatory.

Thanks Ramzi for the info and works.
Both RC and main seem to work fine for me.