Restrict/remove "say" function — security risk

[dgw]

Recently, my users discovered that they can make Bucket "say" fantasy commands to abuse the bot's channel privileges and kick/ban/op others/themselves.

For now I've just deleted the function entirely from my instance, but here are the options:

• Remove function completely (strongest protection, at the expense of altering the current feature set)
• Add setting to disable function if desired (just as strong; default to current behavior)
• Restrict function to ops only (strong protection; still disruptive to feature set)
• Strip leading punctuation from message (weaker protection, but mostly keeps feature set intact)

In my own channels I can simply deny Bucket the right to use fantasy commands with the "FLAGS" access system, but as the bot is privileged in other channels that use less granular access control I simply couldn't allow "say" commands to be used for their sake.

@zigdon is this function used a lot on XKCD IRC? In my experience it's usually discovered by accident, toyed with for a few minutes, and then abandoned.

[dgw]

Updated OP because I forgot to include a fourth option, adding a setting.

[ephphatha]

Honestly it seems like a terrible idea to give privileges on a network that provides fantasy commands to a bot whose entire purpose is to provide user submitted responses to keywords/phrases.

I presume you can get the exact same result via a factoid response using <reply>?

[zigdon]

I'm not sure what the risk is here? In general, yeah, giving Bucket privs seems like a bad idea, especially in a system that acts on messages sent, and not commands.

'say' is enabled in #xkcd, is there an issue I am missing here?

I think the best solution, if it's an issue, would be to move 'say' to a plugin, so that it can be easily enable or disabled.

[dgw]

I'll work on moving 'say' into a plugin, as practice for creating a #89 plugin, whether merged or not.

I presume you can get the exact same result via a factoid response using <reply>?

Yes, but the difference is that 'say' is easily discovered by accident. Users don't discover <reply> without either reading the documentation or seeing someone who knows how to do so teach/dump out factoids that use it.

[ephphatha]

Security through tenuous obscurity :P. Splitting the functionality into a plugin is a good idea in general but given your original report the only way to mitigate that risk is to not give the bot privileges. You've still got substitutions (ex > sex, -ass > ass-) to worry about since they can be "discovered" naturally.

Why does your instance of the bot need higher privs than voice?

[dgw]

My instance of Bucket is combined through ZNC with a Sopel instance that has games requiring the ability to kick players. Kind of a unique situation, I know. But fantasy commands aren't an issue in my channels, only in other channels where I've been invited to bring the bot. So the risk is ultimately on the people who gave my bot access. I also have a decent team of Bucket ops who pretty swiftly delete any abusive factoids. 'say' is unique because it doesn't have to be taught before use.

I can't see any potential for abusing ex_to_sex, the_fucking, or x-ass y to call fantasy commands, but I'm happy to be proven wrong.

Frankly I'd like to stop being responsible for the security and order of other people's channels, but at this point the bot is entrenched in enough channel cultures that I'm probably stuck with it.

[ephphatha]

I haven't looked at the source to confirm (GPL) but I presume this is a possibility:

user: !KICK user testing the fucking theory
bucket: !KICK user testing fucking the theory

(repeat for hyphen and ex_to_sex)

[zigdon]

Security-by-obscurity, that's a great plan you got there :)

Perhaps a different plugin, that can just disallow tidbits that start with
'!' (or whatever the control character is?)

On Thu, Oct 20, 2016 at 3:44 PM dgw [email protected] wrote:

I'll work on moving 'say' into a plugin, as practice for creating a #89
#89 plugin.

I presume you can get the exact same result via a factoid response using
?

Yes, but the difference is that 'say' is easily discovered by accident.
Users don't discover without either reading the documentation or
seeing someone who knows how to do so teach/dump out factoids that use it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#90 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACtVO3MTgIswft5eqh53g1H_Yu72Bsdks5q1-7RgaJpZM4Kbu61
.

[dgw]

I wrote a 'nosay' plugin today. It's a start… Will probably put it up in a PR after I've had it running in production for a while. That will also give me time to possibly make it into a fuller-featured 'bucket-of-privileges' module to nip the other core functions that can potentially give unprivileged users access to fantasy commands.

It's about time I got around to writing more Perl. Been living in Python land full time for quite a while now…

[zigdon]

Yeah, same here. Been almost tempted to try and rewrite bucket in python, but that seems like a lot of work for little payoff :) Maybe in go, as a way to learn the language <_<

…

On Wed, Apr 5, 2017 at 5:13 PM dgw ***@***.***> wrote: I wrote a 'nosay' plugin today. It's a start… Will probably put it up in a PR after I've had it running in production for a while. That will also give me time to possibly make it into a fuller-featured 'bucket-of-privileges' module to nip the other core functions that can potentially give unprivileged users access to fantasy commands. It's about time I got around to writing more Perl. Been living in Python land full time for quite a while now… — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#90 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACtVGv2V-xW1WplgoU1wwIVOwLMQN2Uks5rtC4ogaJpZM4Kbu61> .