[BUG-5702] secondlife:///app/chat fails with message about untrusted browser

[sl-service-account]

Steps to Reproduce

trying to use the sl URI feature to chat to channel 66. Here's the output chatted to me:

[13:35] Eye of Odin HUD to wear: secondlife:///app/chat/66/ban Dizzi Sternberg 1000 testing
[13:35] Eye of Odin HUD to wear: /66 ban Dizzi Sternberg 1000 testing

first line if clicked should chat to 66. second line is there for cut and paste since sometimes i have to shout it.

Actual Behavior

I have a tool that given a menu pic, llOwnerSays a URI chat command so that I can click it and issue a complex command to our security system. It has been working for ages. Recently it started issuing a message saying the command cannot be issued because its using an untrusted browser.

I am aware that other URI name space commands, such as teleports, are failing.

Expected Behavior

:) expected not to get the error message and expected the text "ban Dizzi Sternberg 1000 testing" to be chatted on channel 66 per the URI writeup:

http://wiki.secondlife.com/wiki/Viewer_URI_Name_Space

As far as I can tell the chat feature does not work and I suspect others do not as well.

Other information

Can provide more info or a script if needed.

Thanks!

Links

Related

• [BUG-5536] Issue with clicking SL teleport uri's being blocked. #13504
• [BUG-40755] Allow unblocking of "Untrusted Browsers" when certain links are clicked such as app/chat  #12386

Original Jira Fields

Field	Value
Issue	BUG-5702
Summary	secondlife:///app/chat fails with message about untrusted browser
Type	Bug
Priority	Unset
Status	Been Triaged
Resolution	Triaged
Reporter	Janet Rossini (janet.rossini)
Created at	2014-04-10T20:42:49Z
Updated at	2016-10-23T07:27:55Z

{
  'Business Unit': ['Platform'],
  'Date of First Response': '2014-04-10T15:56:18.489-0500',
  "Is there anything you'd like to add?": 'Can provide more info or a script if needed.\r\n\r\nThanks!',
  'System': 'SL Viewer',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': 'I have a tool that given a menu pic, llOwnerSays a URI chat command so that I can click it and issue a complex command to our security system. It has been working for ages. Recently it started issuing a message saying the command cannot be issued because its using an untrusted browser.\r\n\r\nI am aware that other URI name space commands, such as teleports, are failing.',
  'What were you doing when it happened?': "trying to use the sl URI feature to chat to channel 66. Here's the output chatted to me:\r\n\r\n[13:35] Eye of Odin HUD to wear: secondlife:///app/chat/66/ban Dizzi Sternberg 1000 testing\r\n[13:35] Eye of Odin HUD to wear: /66 ban Dizzi Sternberg  1000 testing\r\n\r\nfirst line if clicked should chat to 66. second line is there for cut and paste since sometimes i have to shout it. ",
  'What were you expecting to happen instead?': ':) expected not to get the error message and expected the text "ban Dizzi Sternberg 1000 testing" to be chatted on channel 66 per the URI writeup:\r\n\r\nhttp://wiki.secondlife.com/wiki/Viewer_URI_Name_Space\r\n\r\nAs far as I can tell the chat feature does not work and I suspect others do not as well.',
}

[sl-service-account]

Whirly Fizzle commented at 2014-04-10T20:56:18Z

This was an intended change with https://bitbucket.org/lindenlab/viewer-bear/commits/afaf26767704a94b05d210bbda23571c7ce22754

See BUG-5536 for this issue.

[sl-service-account]

Janet Rossini commented at 2014-04-10T21:41:59Z

So what does this have to do with unwanted teleports? Did you just invalidate the whole secondlife URI feature?

That seems a bit extreme: chat has already been limited off of Channel zero, owing to a bug report back in 2010 or something.

Please revisit this topic and make more judicious changes rather than break the whole thing.

Is there some workaround that I'm not thinking of?

Thanks,

[sl-service-account]

Alexa Linden commented at 2014-04-10T22:45:23Z

Can you reproduce this issue with the project viewer http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/3.7.6.288799 ?

[sl-service-account]

Whirly Fizzle commented at 2014-04-11T12:42:22Z

Repro

• Login on currrent default release Second Life 3.7.5 (288464) Mar 26 2014 06:41:28 (Second Life Release)

• Rez a box and add the following script - this will listen on channel 66
  {code}
  default
  {
  state_entry()
  {
  llListen(66, "", NULL_KEY, "");
  }

  listen(integer channel, string name, key id, string message)
  {
  llInstantMessage(llGetOwner(), name + " said: '" + message + "'");
  }
  }
  {code}

• Type this into nearby chat: secondlife:///app/chat/66/Testing

• Click the link in nearby chat.

Observed: You get the message "A SLurl was received from an untrusted browser and has been blocked for your security."

• Login on https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/3.7.6.288799 (Maintenance-RC)
• Type this into nearby chat: secondlife:///app/chat/66/Testing
• Click the link in nearby chat.

Observed: You get the message "A SLurl was received from an untrusted browser and has been blocked for your security."

• Login on a build that does not have the "MAINT-535 'trust model' is added for secondlife:// URLs in wiki style links. Chat history is marked as untrusted source now." fix in it. (I used Second Life 3.6.9 (282553) Oct 18 2013 06:53:21 (PreFitMesh) just because I already had it installed)
• Type this into nearby chat: secondlife:///app/chat/66/Testing
• Click the link in nearby chat.

Observed: Your channel listener sends you an IM saying: Object: Whirly Fizzle said: 'Testing'
This is the expected behaviour.

[sl-service-account]

Janet Rossini commented at 2014-04-15T23:13:00Z

Hi Alexa, Whirly, and listeners all. I'm assuming that you're on this and have duplicated the issue, and plan to fix it? If that's not the case and/or I can help in any way, please let me know by mentioning my name in a comment. Thanks!

[sl-service-account]

Soft Linden commented at 2014-04-17T19:09:38Z

The chat method has historically been abused in dangerous and embarrassing ways. If this there's a compelling case for bringing it back, it should display a confirmation dialog before each use advising a user of what is about to happen. That dialog could be suppressible ("never show again") but it should be enabled by default so that only users who opt out of protection are affected adversely.

In the example of the HUD above, what's the benefit to having the HUD make the user act as a proxy? It sounds like a really unusual design. Usually a script like this would communicate directly with the target object. If there's concern about impersonation, a script can still display a confirmation dialog. A confirmation dialog introduces no more steps than having the user click a link in chat. If the author of the HUD script is trusted, the communication protocol can include a hash to sign the message and prevent third parties from issuing it, eliminating the additional confirmation step completely.

[sl-service-account]

Janet Rossini commented at 2014-04-17T21:02:09Z

Hi Soft ...

Obviously I'm not privy to all the discussions on this but I want to suggest that killing the whole viewer URI capability is an unnecessary step backwards.

My HUD is used to craft commands which must be spoken by a known avatar to our security system. So to ban someone from NCI, I must say, for example, "/66 ban RandomLongName LongRandomName He is ugly and his mother dresses him funny."

In the course of a griefer attack ... or any time really, typing all this in is difficult and tedious. My HUD lets me type
"/7 ban rand He is ugly and his mother dresses him funny." It presents me a dialog of everyone whose name has rand in it, and I click one and it echoes the extended command with app/chat, and I click the command and the ban system hears me say it.

So my HUD is a helper for the ban system, which is a canned thing that only accepts commands that I, and other duly authorized individuals say. Not a big deal ... but I don't see why all these useful URI features should be disabled in one whack. People I know use them for many different purposes, showing new residents how to block harmful object spam, opening maps for people, and so on. I think the feature should be extended and made more powerful, not just turned off after years of working fine.

I am quite curious how app/chat can be significantly abused. It already won't chat on channel zero, and it won't send an IM, so all someone could do would be cause an ignorant person to say something on a weird channel.

Obviously I can cause the HUD to ownersay the line to me and copy / paste it ... and in fact it has that option because app/chat can't shout so if i am far away from the ban box I have to do that. (I really wish there was a way for a script to put something in my computer's copy buffer. That would be cool. But I digress.)

To me, the Viewer URI a useful capability that, if I understand the "fix" code, was accidentally made not to work in an attempt to change things so that people couldn't be teleported to the wrong place. The secondlife URIs are comprehensive and useful and should not be turned off lightly. If some are problematical, let's fix them. Let's not turn off all the useful things at once.

Thanks for your consideration.

[sl-service-account]

Raven Luna commented at 2014-04-18T02:48:28Z, updated at 2014-04-18T05:06:10Z

I completely agree with Janet. I designed a "builder's coffee cup" (which the owner wears) that identifies objects named "object" on our three University of Washington islands. This scripted cup is used to help us (instructors and mentors) find misnamed objects and assist students in properly naming prims. Part of that script offers the exact location of the misnamed object. Objects, as you may know, can be transparent and not easily found - so the goal of this cup is to offer an exact location in chat so that one of us can TP and either rename or delete the object. Suddenly, this very useful script does not work. As a scripter and an assistant to many students, I would love to know why these features are cut without any notice to scripters - so at least we can make changes or find alternate methods of serving our customers. I look forward to Lindens and residents becoming a true community again - and that this "throwing the baby out with the bathwater" method of security can be mitigated.

[sl-service-account]

Soft Linden commented at 2014-04-22T17:28:20Z

Raven: The ability to click links to TP is reinstated with BUG-5536. Is there any reason the message needs to be chatted from an avatar, and not chatted by the scripted object on the avatar's behalf?

[sl-service-account]

Soft Linden commented at 2014-04-22T17:44:31Z

Janet: Many scripted objects implicitly assume that anything spoken by an avatar was deliberately spoken, and that content predates the secondlife:///app/chat method. This bypasses permission checks if users click a link. Prices can be changed on land rental boxes, security orbs can be altered, scripted attachments can do unexpected things, etc. We heard one example where an avatar's partner's collar unwittingly leashed them to an instructor during a building class because they clicked a link in an IM.

In the case of your device, it looks like there's a simple work around without enabling this viewer feature. The scripted listener could check ownership of objects, and treat messages from objects just as it treats messages from the object owner. A simple implementation might check whether "llGetOwnerKey(id)" is in the permission list rather than just "id." That should be a very small change for the scripter.

If there's worry about malicious trojan objects, a confirmation dialog could be presented when id is an object rather than the object owner (that is, id != llGetOwnerKey(id), as agents own themselves... id == llGetOwnerKey(id)).

[sl-service-account]

Janet Rossini commented at 2014-04-22T20:31:34Z

So your plan is to completely remove the secondlife:::/app capability? That particular feature can't do any of those bad things you mention. Perhaps secondlife:::/app should be excluded from the prohibition, and secondlife:::/app checked to see if any of its features do harm.

Note that the one I'm concerned about just chats to a channel. Since a script can already chat to a channel, there's nothing additionally harmful about app/chat.

I understand that the system to which my object helps me chat could be changed to check object ownership. As it happens we could in principle do that as it is our own system. I might even be in a position to "request" the change. That will not be the case for other uses of this feature or of the other app/various.

I want to respectfully suggest that this change goes too far, cutting off a very useful capability that, since it belongs to LL, can surely be considered to be secure.

Thanks!