Public Call For Security Researchers -- Swarm Multi User System

[mcmonkey4eva]

_{If you found this link from elsewhere, you can learn about Swarm in the readme here}

Swarm recently added early experimental 'friends and family' multi-user system. That is: a system where you can homehost your SwarmUI, and your friends/family can connect and log in to their own separate accounts and share the UI, separately.

The long term goal of this system is to expand to a 'general open' multi-user system, one you could confidently host on the open internet and grant randos account access to.

I'm relatively experienced in cybersecurity, and have a general idea what I'm doing, but as anyone in cybersec would confirm: the first lesson of knowing cybersec is you don't know enough about cybersec to verify a non-trivially-sized system is 'safe'. And the second rule is nothing is truly 'safe', just sometimes the zero-days haven't been found yet.

So, in the interest of at least minimizing the risk of people getting hurt by trying to host Swarm as much as possible, I'm putting out a public call for those with cybersecurity & software dev experience to look over SwarmUI's multi-account system and hosting, to
(A) identify and fix issues before we suggest anything is ready to host for real, and
(B) try to determine robust recommendations for how less-technically-experienced users can share their personal Swarm instance without getting pwned (eg containerization).

If you have relevant experience, please do poke around and comment below.

Swarm does not currently recommend anyone set this up to the actual public, so network security issues do not (currently) need to be kept private. After there are any recommended public setups, I'll replace this notice with direction towards private security issue reporting.

_{Bear in mind, Swarm is 100% free and open source software. If you'd like a reward for helping with security validation, I'm happy to give you public thanks or link your page or anything, but there's no money involved. I understand that no money isn't awesome, but I don't get paid for this either. Thus the public call for help instead of hiring someone.}

All the notes below are a preliminary writeup, there's probably things I'm missing. Please do suggest any you think of.

---

Testing/Config Notes

The only upfront config that matters is:

• default role permissions (it's not a security issue that if you give User role access to comfy, comfy can be hacked. I know it can, I can't fix that, that's why the permission is off by default)
• Server config AuthorizationRequired enabled (obviously)
• No other network software applied. Optionally apache/nginx reverse proxies, but ofc proxy config errors aren't bugs in Swarm.
• Attacker has no account, or has User or lower role access. (Obviously admins can wreak havoc, powerusers can too. I know.)
• Generally most things default. If an attack requires a server config change, it's only relevant if that change would make sense for an instance owner to do (no special crafted attacker ... server config settings. If you got server config you got everything anyway).
• No nonbuiltin extensions (we want extensions to be secure, but, like, handle em separately.)
• Attacks that happen entirely in the standard UI are the worst case, but attacks that require scripted network calls or whatever are very much relevant concerns.

Validation Priority One: Basic Network Connection

The most important initial baseline is: let's say you host a SwarmUI instance publicly, with account systems enabled, and a random external attacker connects with no account knowledge / no login. What can they do?

P1 Areas of Main Concern

• Basic network stack. SwarmUI uses C#/dotnet8/razor with its default web server stack. Are there vulnerabilities upstream? Are there configuration issues? Does behavior problematically differ between host OS (Windows vs Linux)? Is there an easy way to DoS?
• "Permission Firewall". SwarmUI uses a 'permission' system to block access to things that shouldn't be accessible, a user without an account login has basically nothing. Is this well enforced? Are there any bypasses or escalations possible?
• server config AllowLocalhostBypass: can a user trick Swarm into thinking they're localhost, when they're not? Notably including when using a reasonably-configured nginx/apache reverse proxy setup (which might resemble localhost, Swarm should be able to identify this is not the case from X-Forwarded-For).

P1 Known Issues

• None atm, but honestly I don't know what's inside the dotnet stack that deeply, so it scares me.

P1 Non-Concerns

• DDoS: overloads that would overwhelm any common network stack will of course overload Swarm too. A DoS is only a concern if it's trivial (eg connect 100 websocket requests and now the servers dead would be a problem, cause any script kiddie can do that. If you need 100 machines spewing packets, that's out of scope)

Validation Priority Two: Account Engine

Naturally, the second factor to consider is the account system itself. When logging in / messing with user accounts, what risks are there?

P2 Areas of Main Concern

• Logins. Is a user login sufficiently validated? Is there sufficient ratelimiting? Can an attacker use brute force attacks or other common tricks to get into an account too easily?
• "Permission Firewall": Are users only able to access exactly what they should be?
• Escalation: can users 'escalate' access in any way, eg change their own account roles?
• Password storage: is the password hashing solid?

P2 Known Issues

• Two-Factor not yet implemented

P2 Non-Concerns

• Bad passwords. I know, people will give stupid passwords to powerful accounts. Can't fix that other than education.
• Social engineering. I know, people can be tricked. Can't fix that other than education.
• "rabble rabble rabble hash technique x better than technique y" I've seen the endless debates about hashing technique specifics. Don't need perfection. Unless pbkdf2 has a surprise zero day or something it's probably not a big deal. I know my mixed salting is silly, but it's not dangerous, it's fine. We're looking for security issues, not "ah but this is redundant therefore bad" shush redundancy is fine.
• "rabble rabble rabble client prehash rabble" I know somebody's going to get mad at me for implementing client prehash (a single hash over the password clientside, then the hash is sent to server, and the server runs the real full hash over top of that client hash). I stand by that decision. The server owners are random people (ie who knows if there's network interception or anything happening, who knows if they'll report a breach), and the users are probably noobs (ie probably reusing passwords between services), the prehash exists to serve as a nuisance to anyone grabbing passwords over network trying to stuff them elsewhere. I know it's not magic, I know it can be beaten, but I'd rather have that weak wall than none at all there. It's not serving as the real server hash or anything, it's not doing anything naughty, just chill.
• Non-security issues: I've seen enough sec research debating that I feel the need to emphasize this repeatedly. "Oh but what if a user changes their name, then the password is invalidated and things break" yeah that's wonky but it's not security-relevant, doesn't belong in the security thread.
• Non-dangerous side-channel monitoring. Users can figure out if other users are generating and wotnot, that will be difficult to prevent. (But if a user can tell what another user is generating, that's a problem)

Validation Priority Three: User-Accessibles

Next up: all that stuff a default user account can access. Is it safe?

P3 Areas of Main Concern

• Sanity of the permission list: is there anything in there that doesn't belong?
• Enforcement of the permission list: egcomfy workflows are off by default, is there a way to slip a manual workflow in anyway?
• Comfy workflow generation and processing: can a user craft parameters such that they brute muck the comfy json generator? eg image processing gets quite hacky
• Param validation: can a user slip a dangerously wrong value to a parameter?
• Prompt syntax magic: prompts are quite powerful, not to mention raw text inputs. Can they break stuff when sent down to comfy? Notably eg comfy has syntax for embedding:xyz that does insufficiently secure file access, does Swarm properly forbid writing that without going through whitelisted checks (<embedding: swarm syntax)? Are there other syntaxes or sus file inputs?)
• Param perms: are there parameters that need permission locks that don't currently have them?
• Model whitelist/blacklist: can users access metadata or usage of models that they're not supposed to? Worst case scenario is a business hosts a public swarm, and they have a private/NDA'd model in their instance, they need to be confident that Swarm won't leak model info to users. More realistic risk is a user has NSFW models and doesn't want most user to be able to see those.

P3 Known Issues

• wide surface area of attack here so I expect there's gonna be some
• Overloads. Users can easily overload the system or trigger errors in a way that's a nuisance to other users. This isn't an issue for friends-and-family (go slap the dude that caused a problem) but might be annoying for a hypothetical future large swarm instance. That's more of a general software design topic than security though.

P3 Non-Concerns

• Anything that requires non-default user permissions. I know comfy params are terrifying. They're off by default for a reason.

Priority Four: Config Recommendations

How does a user set up a sufficiently secure system?

I have a setup guide for Swarm in Docker, is that docker setup sufficiently secure? (Answer: probably not, due to eg the network config in particular.)

we need a dedicated "Set up a secure public instance" guide that configures things like docker networking to more security-maxed setups, so that less-experienced users can host an instance safely.

_{("Just don't run it if you're not an expert" is a classic response but not helpful here)}

[voronaam]

Hello! Have you found a person to help with this one? If not or if you would not mind another set of eyes on this one, I would love to try it out. I come from Linux/Java application security background and my analysis will likely be incomplete, but I might be able to spot something of interest.

[mcmonkey4eva]

Please do!