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!

[wegylexy]

Wish it support OIDC in a way that we can simply connect an IdP like authentik or keycloak to manage access rights and groups, etc. SwarmUI will simply take the user profile and roles/groups from the id_token claims without offering UI and complex logic or database.

[simcop2387]

Yep, I'm looking foward to this too. I run keycloak for managing SSO on my own systems so that i get a lot of other stuff for free like passkeys, mfa, forgot password, etc. all for the cost of setting things up one time. Completely understand though that you kinda need the basic building blocks in here first though before the external providers are even possible to implement.

[wegylexy]

I mean at a minimum, trust the id_token and the app entitlement in it, for just the current session with PKCE, so no need for another database and stuff.

[mcmonkey4eva]

This thread to be clear is a public call for security researchers to help validate the security of SwarmUI's authenticated mode. The discussion of account structure and providers is a separate feature request that isn't a great idea to add at all until after the security model is decently well validated.

[mcmonkey4eva]

so no need for another database and stuff.
Swarm has to have its own account database regardless. How else can it track your user settings, presets, etc?

[simcop2387]

This thread to be clear is a public call for security researchers to help validate the security of SwarmUI's authenticated mode. The discussion of account structure and providers is a separate feature request that isn't a great idea to add at all until after the security model is decently well validated.

Not entirely but fair enough to discuss it else-where. I'd make the argument that the way authenticated mode works or needs to work to be able to accommodate that in the future absolutely affects how security and the attack surface for authentication needs to be tested and validated, or you're going to need to do this process again as soon as you want to add this in, if you ever do.

[simcop2387]

Finally had a chance to start looking at the code, there might be an issue with your password storage (P2 area as you call it), depending on what kind of risks you're willing to accept.

https://github.com/mcmonkeyprojects/SwarmUI/blob/master/src/Utils/Utilities.cs#L1255

You're using PBKDF2 which isn't broken but doesn't offer some advantages that more modern schemes will, like memory or asic hardness. But that's not the only thing I see:

1. You've hard coded the number of iterations, that's fine for today but it does mean that number of iterations will become less and less useful as time goes on, reality is that this probably isn't a big deal but it really needs to be configurable.

2. You're not really doing yourself any favors by storing the hashes directly like this, you've already got a scheme in there with the __swarmdoprehash business, this is not going to work well in the future if you need to fix #1, or if you want to adopt a different hashing strategy. Look into how the modular crypt format works and adopt it, there should be libraries that will do all the hard work for you in C#, https://passlib.readthedocs.io/en/stable/modular_crypt_format.html, the biggest thing is that this will let users change their default settings for security hardness, and allow adopting new hashing algorithms in the future WiTHOUT having to have users reset all their passwords or do crazy tricks like hashing the old hash and trying previous formats and other shenanigans i've seen people do over time.

I'd personally recommend at least bcrypt for the hashing algorithm these days but my personal preference is Argon2id for the memory and gpu hardness it can help provide, since we're obviously dealing with users that are going to have access to more powerful GPUs (either themselves or by putting in a malicious extension into comfyui to try to break user's hashes in-situ, as this might not be a direct security issue for SwarmUI, it would mean that password re-use in Swarm could lead to a bad actor breaking into other services that a user has.

[simcop2387]

And while this is certainly far far more theoretical, I believe using SequenceEqual technically could be leaking some information about the hashes themselves in a timing side-channel attack. It'd be pretty difficult to do and leave some massive fingerprints in the logs due to failed login attempts but it might let someone slowly work out the bytes of the stored hash if they're clever enough. But i'd personally consider this to be too theoretical to worry about at this stage.

[mcmonkey4eva]

Some fair points there. For now, I've added a versioning prefix to allow easier future alterations, and swapped to a slow-equals. For the rest ... refer to "p2 non-concerns" section in the post above.
Also ftr I have zero interest in adding an entire external lib dedicated to adding 10,000 lines of security-relevant code, to replace 5 lines of string processing. The colon based format is overly simple, but very simple is also very hard to break.

[simcop2387]

My point about bad passwords and the pbkdf2 is that you're not being safe. Current recommendations for pbkdf2 are above 600000 iterations for security due to the fact that hardware out there can easily do millions (1.1m/sec on a 5090) to billions of checks a second once your stored database is leaked. This doesn't stop users from reusing passwords and bad practices with them but does mean that you're about to be a weak link in the chain once a nalicious comfyui or swarmui exfiltrates the database.

https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

The reality is that when user controllable code is involved then you have to make the assumption that the database is already compromised and needs to be safe even then, and your design right now is not that.

[mcmonkey4eva]

I will reiterate again that arguing over hashing functions is not the purpose of this post as expressed in p2 non-concerns

[simcop2387]

I did find some more questions, after digging through the session handling code that may just be me missing where things are happening since it's just a first pass:

• This session lookup should probably be enforcing checks for expiration times on sessions, along with checking that the user is still valid. It looks like it's only used to check that a session exists with that ID during validation of API calls, with no other validation checks happening at that time.

https://github.com/mcmonkeyprojects/SwarmUI/blob/master/src/Accounts/SessionHandler.cs#L349
https://github.com/mcmonkeyprojects/SwarmUI/blob/master/src/WebAPI/API.cs#L86

Might not be a huge deal but it could be leading to a race condition with expiring sessions during clean up, or a sessions being valid even after being expired because clean-up failed.

Likely fixable by just adding a method on the session class that does a quick check for expiration and that the user it holds is still valid in the rest of the system and calling that before returning true.

I believe that this also means that CleanOldSessions() should also be cleaning up and checking the Sessions ConcurrentDictionary and cleaning that up too? I suspect right now though with things hard coded to 31 day sessions and frequency of updates it's not a huge issue anyway as people won't be leaving the software running incredibly long but it could mean that a sessions seems to stay up until the next restart if this is missed.
https://github.com/mcmonkeyprojects/SwarmUI/blob/master/src/Accounts/SessionHandler.cs#L248

[mcmonkey4eva]

The expiration times are just to prevent the database filling up with unused data, not relevant at runtime

[simcop2387]

Ah that would be why I wasn't finding anything that looked like expiring them for security. I can't say I'm experienced enough myself to say if that's a security issue or not but it's probably something to note for anyone else researching into the system for comments then.