Default configuration is vulnerable to challstr replay attack, granting shell access.

[jClaireCodesStuff]

The following attack is plausible if Charlie's server is running with the default configuration:

• Alice wants console access on Charlie's server
• Alice opens a guest connection with Charlie and remembers the challstr
• Alice socially engineers Bob, a sysop, to log on and help with "something"
• Her server replays the challstr to Bob
• Bob gets an assertion with userType 3
• Alice forwards the assertion to Charlie
• Charlie hasn't set Config.legalhosts because it's undocumented
• Charlie hasn't changed Config.backdoor because the README doesn't give him any warning
• Alice sends /eval or /bash to Charlie's server as if she's Bob

Possible fixes include:

• Set backdoor = false by default because it's the right thing to do
• Add a command-line option to enable backdoor and help beginners
• Consider using PKI to authenticate sysops
• Document legalhosts and set it to only localhost by default
• Encourage using Docker, Podman, etc. for easily launching testing servers.

I can work on the last one at least. I haven't taught myself containers yet and it's a good excuse.

[Zarel]

Awkward. We'll have to assess how to best deal with this problem.

Unfortunately, none of your suggested solutions appear to fully fix the problem (not even backdoor = false). It's relevant to note that we're already using PKI.

Requiring legalhosts to exist would work, but it seems really user-unfriendly and is more work than we usually expect of server operators.

I'll have to think about how to best solve this problem. Can you talk to us on https://psim.us/devdiscord ?

[Slayer95]

We already check for the date in which the login was originally performed, and thus can rely on it to minimize the impact of exploitability. It's likely that this was already considered when the login system was first designed, but the time window allowed is a bit larger than 1 day, which, is not very useful given the large impact this issue would have if exploited.

Also note that this issue requires Alice to act as MITM. We could, and should, make sysop logins valid just once(*), but eavesdropping opens the door to acquiring sysop powers even if the login data were valid for a unique time.

• I agree with disabling Config.backdoor by default. Every serious 3rd party server has always done it anyway, and it's not like sysops are available on call in #showdown like yesteryear. Instructing server admins to type a command /backdoortrust zarel or whatever aptly named command is probably useful and simple enough for those rare circumstances.

• (*) Sysop signed assertions should be stored and blacklisted in users.ts after being used. Note that the cache is cleared after restart, so saving to disk would be need for full measure.

Going further, this would apply to the server own sysops as well. But it has always been standard practice that people with such high level of system access in informatic systems shouldn't be logging in all the time, so... loss of "login remember" feature for them shouldn't be that big of a deal? Just switch to an alt?

[Zarel]

I discussed this with @xfix and we agreed that the best mitigation would be to use IP validation if Config.legalhosts isn't set. We should also document Config.legalhosts.

[Zarel]

We could, and should, make sysop logins valid just once

That wouldn't do anything for this vuln, which is a MitM attack across two different servers, which would have non-shared blacklists (and non-shareable: one of the servers is an untrusted attacker).

I agree with disabling Config.backdoor by default. Every serious 3rd party server has always done it anyway, and it's not like sysops are available on call in #showdown like yesteryear. Instructing server admins to type a command /backdoortrust zarel or whatever aptly named command is probably useful and simple enough for those rare circumstances.

Sysops are often necessary to deal with problems in servers where the server admin is afk, and no one around has the ability to use /backdoortrust zarel or whatever.

If there were a vulnerability specific to the sysop backdoor, I would consider defaulting it to off, but this vuln is unrelated to the sysop backdoor.

[Zarel]

There seems to be a misunderstanding about what the backdoor is for. It's for situations like this:

• We get a report of someone doxxing or spamming illegal porn on a server, but the server admin is asleep
• If the backdoor is enabled: We log onto the server and ban the user
• If the backdoor is disabled: We have to ban the server, there's nothing else we can do

We prefer for escalations that aren't literally "ban the server" to exist.

Security-wise, it's identical to promoting my account to admin for your server. By itself, it's not a vulnerability and there's no way for it to be a vulnerability.

[KamilaBorowska]

I do wonder, I'm somewhat concerned about sysops having console access, could that permission be removed? If a sysop were to be compromised they could run rm -rf / on a server or something. If necessary, it could be added back with a command like /backdoortrust (which would be inaccessible with sysop permissions alone, but accessible to admins without console access).

Principle of least privilege, pretty much, I don't think sysops need to run arbitrary code on other servers without server admins knowing about it, and their accounts can be compromised still, even considering we do have 2FA for sysops.