Clojurians Log v2

You know, since slack has these bugs where people can send unauthenticated javascript code to everybody in a channel... And slack runs on electron, which has full access to your system... There's a good chance that sufficiently angry adversaries could do bad things on massive networks

I doubt anyone is that angry with us. But just our size alone on here makes us a target

Does this depend on what client you're using?

I’m curious if that would be sufficient motivation for public communities to abandon slack.

The web client ought to be sandboxed to the browser

I'm not sure how far the electron client app will go to sandbox things... Electron is on a node based system, I believe. Which is decidedly not a sandbox.

In fact, any electron app that pulls arbitrary js from the internet and runs it arbitrarily... might be the most insecure situation possible.

I'll have to look into electrons security model a bit more

lol In fact, the most popular Electron apps (Atom, Slack, Visual Studio Code, etc) display primarily local content (or trusted, secure remote content without Node integration) – if your application executes code from an online source, it is your responsibility to ensure that the code is not malicious. - https://electronjs.org/docs/tutorial/security#security-native-capabilities-and-your-responsibility

That's obviously not true re slack... Unless you're connected to a fully trusted community on slack.

If anyone finds discussion/explanation of the specific measures slack takes to ensure javascript is neither received or executed, please drop it it here.

So sending js around is not the way the current spam/impersonation-attacks are done?

I've heard both.. that attackers are doing it that way. And I've heard they're not.

Because of that attack we know that Slack won’t do anything about it right

ah, ok

I've heard that as well

using it as public community (16k subscribers and counting) while Slack assumes a trusted team is a massive liability independent of any technicality of the used platform IMO

Right. If slack WontFix because their threat model does not include our situation, that's a problem for us

(and as it’s closed source we can only guess/hope how they use a platform…)

The security hole is that Slack does the @ permissions check on the sender's client so the sender can override that via JS in their console. Slack doesn't execute "JS code" sent in messages so, no, attackers can't run malicious code on your system.

You actually have to decide to execute received code yourself.

^ @john

The exploit is that Slack trust users not to override their client-side security(!) which is fine for company use but not so great for community use -- and they know about it and won't fix it because community use isn't their target audience (they want such communities to "go away" I'm sure).

Folks are welcome to move to the Clojurians Zulip any time. Or they can stay here. Or they can do both. Just like they can use Discord, or Matrix/Riot, or IRC, or whatever they want. You can't "force" 16K people to change their workflow -- especially since I suspect a lot of them use Slack at work and therefore already have this community open at work _and won't want to run another Electron client (which is what I assume Zulip is?) or any other desktop clients (which is pretty much every non-Slack chat system out there).

while I’m all for choose-your-own-chat, the question is whether it’s ok to send newcomers en-masse (via the official clojure/script-websites) to a platform that’s actually not suitable for it.

the main websites are not “sending” people anywhere - none of these are official Clojure channels (except the google group mailing list)

(and by “official” I mean - not administered or moderated by the Clojure core team)

true - it’s not official

Our Slack community is nearly four years old 🙂

@seancorfield a, k. The exploit is that Slack trust users not to override their client-side security(!)

That's what gives me pause

If you're relying on client side security to prevent unintended effects on remote hosts, what other effects on remote hosts are you not fully protecting against?

The interaction is between the client and Slack. Not between the client and any other remote client. Have you actually looked at the Slack API?

not beyond exploring some hooks a few times

Slack already escapes any code sent in messages -- otherwise we wouldn't be able to share code fragments in the first place. This is all about how the client behaves when you try to @-everyone or @-channel etc -- they check it there so the client can pop up the warning about what it does (or prevent the message from being sent). Yes, sure, they should also check on the server -- since they clearly have to do some @ processing to decide which clients to sent notifications to -- but for their intended audience it's not a big deal.

Like I say, anyone who isn't happy with Slack is very welcome to move to any or all of the alternatives that have Clojure communities.

I see you are signed up to Zulip @john but it shows you as not online -- what client are you using for Zulip?

(and, as a general FYI for folks here, this channel is mirrored to Zulip via @zulip-mirror-bot -- which you can invite to any channel here in order to mirror that channel to Zulip)

I've been using the web client for zulip. TBH, I like the slack interface the best. I'm just worried about Slack's threat model, since they claim security issues related to our use case are not applicable to their model.

And since it's an internet connected node app, with access the filesystem etc, it could be pretty easy for something to go wrong.

We also use slack here for work. So it's super convenient to just use one thing.

I may just move to using clojurians on the web client slack

Isn’t that a pretty big leap to suggest that users essentially exploiting client side permissions like window.permissions.can_at_everyone = true therefore allows them to remotely execute code on every machine running the client? An exploit like that would affect their core business and potentially their servers where as this issue only affects open communities.

not in my opinion

If you're that worried about Slack's threat model, maybe you should persuade your company not to use it? 🙂

Well, we don't let just anybody on our slack 🙂

If remote execution is a concern, the Slack web client isn't going to be safe for you either.

cross-community exploits notwithstanding

Well, at least the web client doesn't have access to the full node system APIs, right?

if a piece of js manages to run, can it run require('fs')? I know there's a front and backend architecture to electron, but I'm not sure.

https://slack.engineering/building-hybrid-applications-with-electron-dc67686de5fb

> The WebView Tag While we generally trust the local Slack application to run with full access to the desktop and Node.js, allowing remote content to directly access desktop features and Node.js is insecure — if someone were to Man-In-The-Middle Slack, they would have full control over user computers! To prevent this, we use a feature of Electron ported from Chrome Apps called the WebView element (unrelated to Apple’s WebView view mentioned above).

allowing remote content worries me. Webview or not. All content sent between users should be non-dynamic and decidable. Otherwise all bets are off.

> allowing remote content to directly access desktop features and Node.js is insecure As in they don’t allow it.

Meaning, they allow it in their webview

Meaning, js can be slung between clients

I'm not saying they haven't implemented a perfectly secure system... they might have

But the article suggests they have addressed both vectors > Conceptually, this HTML element is similar to an iframe, in that it includes another site inline as a block element > One thing that we can do in our preload script is set a key on the window object. This allows us to expose an API to the webapp side of Slack. Since we define this API, we can set up a Security Boundary that only grants the webapp certain methods.

though public communities are not the typical a supported stakeholder…

@jayzawrotny that article makes me feel a little better. It sounds like the front end is being sandboxed, accessed through their custom API. Nevertheless, I'm sure there are years worth of remote code exploits yet to be reported in their implementation.

But, in general, I just don't believe node was designed to be a sandboxed thing... and since electron runs js on both the front and back, I'm just not getting much of a warm and fuzzy from the situation

Nothing to do with JS gives me the warm fuzzies, so I sympathize, but I trust that Slack has done due diligence in this area (since they've publicly explained their security model).

They have to, to get ISO 27000. But that stuff is mostly talk, IMO

I respect your caution, and it did happen before https://twitter.com/slackhq/status/955889573313368066?lang=en but I am concerned this kind of debate can drain enthusiasm for healthy discussion and necessary actions to resolve it. Instead of addressing the actual issues this community has to deal with we may get stuck continuing this debate for the existence of unreported platform attack vectors, that are evidenced only by the lack of evidence to support the contrary. If those attack vectors in electron do get discovered I’d rather rely on Slack’s commercial success to quickly fund fixes and campaign core Electron updates over a similar product with a slower moving team with less resources and community pull.

That's fair reasoning IMO. On the other hand, Slack's corporate size may work in the opposite direction. Meaning, they may be more lazy wrt exploits that don't concern their target customer base. But my caution shouldn't be alarming anybody... We all use apps every day that are probably less secure than Slack. I'm def not trying to drain any enthusiasm.

I guess I just wish we as programmers used the best tools for the job. Maybe culture/market forces make that not practical though.

Perfection is the enemy of the good. Worse is Better. There are plenty of reasons to use "tools that work" as opposed to trying to find "the best". Besides, your "best" could well be someone else's "worst", and vice versa.

That's why I say that everyone should use what works for them.

Four years ago, this community was started as an experiment. It's been ridiculously more successful than anyone imagined. It quickly gained an order of magnitude more members than IRC ever had for #clojure and eventually surpassed even the Clojure Google Group. There are plenty of alternatives. Some have traction, some don't.

If someone doesn't want to use Slack, that's fine -- go use one of the alternatives 🙂

You beat me to it. Was just about to say I can choose the best tool for myself, I can make recommendations to a small team, but I don’t think I can choose the best tool for 15k people.

Which is why I chose to propose that bot to help with moderation, I don’t think the perfect platform exists. Instead, I want to try and make this one better and if there’s ever a community and technology to help achieve that: It’s this one 😄

While I dislike porn spam, it doesn't scare me. Using client side constraints for global security does.

I don't think a bot can mitigate that

We can circularly debate the implications of that issue all day, but we’re not going to arrive anywhere actionable. 15k people decided slack was the best tool for them and for the most part it works. If someone bypasses the client side restrictions and only posts relevant Clojure questions and answers is it a problem for this community?

I disagree vociferously!

lol just kidding 😉