Possible addon security breach using nearby owner for man in middle attack

[NikkiLacrima]

This is based on a report in OpenCollar group.
A user had an alt nearby and the alt had owner privileges to the collar.
The attacker knew about both the collar wearer and the alts owner status.

After a while the attacker had inserted himself as owner on the collar and changed restrictions.
No dialog popups were visible to the collar wearer, or so she thought.

So how can this possibly be done ? After seeing todays report on temp attachments I thought about the following:

Craft a remotecontrolled remotecontrol, or simply an addon man in the middle relay, Not to hard.

Make this object temp attach to the nearby collar owner ( the alt), as a furniture attached toy perhaps.

This remote controlled remote will now be owned by the collar owner and as such have owner privileges to the wearers collar, without any rlv or collar interaction happening.

Now the remotecontrolled remote can connet to the wearers collar and since its owned by the alt who is collar owner it gains owner status, and the attacker can gain control.

Is this possible and how can we prevent it ??

[mistressohm]

*Simple yet incomplete solution*: Disallow temp objects as OC remotes entirely. *Slightly more complex: *Disallow Access changes via object chat or temp object API calls. All Access changes must be done either via direct click or by local chat, and the source of either of them is validated as an owner before Access menu will spawn. *Coding a new module specifically to guard the Access menu:* Set up an "Access Lock" that can be set by owner, requiring a challenge response such that the 'owner' and the 'wearer' both know that something is wanting to get past the lock (and both agree to allow it)*. No changes are allowed to Access (no added or removed owners or trusted, blocked can be added but not removed) without this challenge. Make it two random words, set up when the Access Lock is established. Owner responds with one word, wearer says another, on a randomized chat channel sent to both of them, both within a short timeframe of when Access Unlock has been invoked. I'm thinking 15 seconds or less, because the default behavior is for the challenge to fail. It's similar to a safety deposit box - both the person whose stuff is in the box, AND the banker, have to unlock it for it to be accessed. * self owned would have to respond with both passwords. I can see this as a potential issue with Self-owned, if they get a temp attachment that someone else can use as an OC remote, this issue would also occur.

…

On Fri, Sep 13, 2024 at 4:12 PM NikkiLacrima ***@***.***> wrote: This is based on a report in OpenCollar group. A user had an alt nearby and the alt had owner privileges to the collar. The attacker knew about both the collar wearer and the alts owner status. After a while the attacker had inserted himself as owner on the collar and changed restrictions. No dialog popups were visible to the collar wearer, or so she thought. So how can this possibly be done ? After seeing todays report on temp attachments I thought about the following: Craft a remotecontrolled remotecontrol, or simply an addon man in the middle relay, Not to hard. Make this object temp attach to the nearby collar owner ( the alt), as a furniture attached toy perhaps. This remote controlled remote will now be owned by the collar owner and as such have owner privileges to the wearers collar, without any rlv or collar interaction happening. Now the remotecontrolled remote can connet to the wearers collar and since its owned by the alt who is collar owner it gains owner status, and the attacker can gain control. Is this possible and how can we prevent it ?? — Reply to this email directly, view it on GitHub <#1098>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALSHY5DM3Q5NDPR5PIMU5C3ZWNILZAVCNFSM6AAAAABOGDHE3CVHI2DSMVQWIX3LMV43ASLTON2WKOZSGUZDKNZQHA4DENQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>