search

matterhorn-chat / matterhorn

A feature-rich Unix terminal client for the Mattermost chat system
BSD 3-Clause "New" or "Revised" License
1.05k stars 77 forks source link

Allow scripts to send `/` commands #825

Closed pstumpf closed 3 months ago

pstumpf commented 8 months ago

When a script invoked by /sh outputs a string beginning with /, it is sent as a message. I think it should simply be interpreted as a command instead. This would allow to set your /status from a script.

jtdaugherty commented 8 months ago

Thanks for the suggestion!

jtdaugherty commented 3 months ago

Thinking about this more, I'm afraid I must decline. Doing this would introduce a potentially significant security risk because scripts could run untrusted programs whose output could invoke arbitrary server-side commands. While I can certainly understand that this would be valuable for innocent things like /away, it would be problematic enough from a security standpoint that I think we need to keep things as they are. Thanks!

jtdaugherty commented 3 months ago

(I actually got all the way through the implementation before realizing this, as you can see the from commits above.)

pstumpf commented 3 months ago

I’m afraid I don’t follow, at all. Yes, scripts might run any server-side command, just as the user may do manually. What type of attack do you have in mind? Or is this just about potentially buggy scripts?

jtdaugherty commented 3 months ago

Scripts could be buggy, and another angle is that scripts could either be malicious or run programs that are. But the more general issue that I'm concerned about is that scripts would effectively run commands without the user's consent, but at the user's privilege level, because the user would have no way to first see the command before it is run. Servers can have all sorts of commands even beyond the built-in ones that have administrative side effects, and unless users are willing to inspect the scripts they run (which is not likely in the general case) then they won't know what's going to happen and would need to trust the script's author.

pstumpf commented 3 months ago

On Tue, 27 Aug 2024 08:17:20 -0700, Jonathan Daugherty wrote:

Scripts could be buggy, and another angle is that scripts could either be malicious or run programs that are. But the more general issue that I'm concerned about is that scripts would effectively run commands without the user's consent, but at the user's privilege level, because the user would have no way to first see the command before it is run. Servers can have all sorts of commands even beyond the built-in ones that have administrative side effects, and unless users are willing to inspect the scripts they run (which is not likely in the general case) then they won't know what's going to happen and would need to trust the script's author.

That reasoning is completely backwards.

If you run untrusted scripts, you've lost. Simple as that.

Even as it stands now, matterhorn's /sh feature will run arbitrary commands from any script it is fed, as will notification scripts. Which might run rm -rf $HOME, remap your keyboard, or worse.

-- Reply to this email directly or view it on GitHub: https://github.com/matterhorn-chat/matterhorn/issues/825#issuecomment-2312851395 You are receiving this because you authored the thread.

Message ID: @.***>

jtdaugherty commented 3 months ago

That reasoning is completely backwards.

This statement really isn't helpful in this discussion. If you're frustrated that I'm not giving you what you want, I could definitely understand.

If you run untrusted scripts, you've lost. Simple as that.

I'm in agreement that running untrusted scripts would be a problem, but I'm not in agreement that it is as simple as that. This might not be the best venue to have a more nuanced discussion about the issue, though.

Even as it stands now, matterhorn's /sh feature will run arbitrary commands from any script it is fed, as will notification scripts.

Yes, that's true; and the extent of the impact of a bad-acting script is only one's local system and what it's capable of, rather than using commands which can directly impact the server state. I'm not saying that's good, but at least then the user's decision to run something they don't adequately trust impacts something they can take responsibility for, which would not be the case if a script ran a destructive server command without their consent.

pstumpf commented 3 months ago

I am skipping the non-technical chatter on purpose.

On Tue, 27 Aug 2024 10:28:16 -0700, Jonathan Daugherty wrote:

That reasoning is completely backwards.

This statement really isn't helpful in this discussion. If you're frustrated that I'm not giving you what you want, I could definitely understand.

If you run untrusted scripts, you've lost. Simple as that.

I'm in agreement that running untrusted scripts would be a problem, but I'm not in agreement that it is as simple as that. This might not be the best venue to have a more nuanced discussion about the issue, though.

Even as it stands now, matterhorn's /sh feature will run arbitrary commands from any script it is fed, as will notification scripts.

Yes, that's true; and the extent of the impact of a bad-acting script is only one's local system and what it's capable of, rather than using commands which can directly impact the server state. I'm not saying that's good, but at least then the user's decision to run something they don't adequately trust impacts something they can take responsibility for, which would not be the case if a script ran a destructive server command without their consent.

If a client is able to run a 'destructive server command', via script or not, that is a bug in the server. And it really is as simple as that.

Are you aware of bugs in the Mattermost server software of this nature?

-- Reply to this email directly or view it on GitHub: https://github.com/matterhorn-chat/matterhorn/issues/825#issuecomment-2313137386 You are receiving this because you authored the thread.

Message ID: @.***>

jtdaugherty commented 3 months ago

If a client is able to run a 'destructive server command', via script or not, that is a bug in the server.

In the context of this discussion, by "destructive" I mean generally "any command that can make a modification." So, for example, a command that can remove a user from a channel, delete a channel, change settings, etc.