Rcon Authorization

[Silicone_Milk]

I haven't poked around the rcon code very much yet but something has been bugging me for the past few days.

When I send an rcon command to a server without putting in the password first I get the "Bad Rcon Password" message back from the server.

When I enter the password then send the rcon command the server executes normally as expected.

What I'm wondering is, how does the server know that I'm the admin and that the other players are still not authorized to use the commands? Does it keep a tally on its side saying "ok, Silicone_Milk knows the password is = this string so commands from his ID are good for execution only for the current session. If he disconnects, he's no longer ok."

If this is the case, what keeps a determined individual from crafting some packets and claiming to be me (who has been authorized) so that the server is tricked into letting that person execute rcon commands as well?

[^misantropia^]

Nothing of the sort. Your client inserts the value of the rconpassword cvar in every rcon command you send.

[Silicone_Milk]

Very interesting. Simpler than I could have imagined.

Thanks for the swift response Misantropia

[a13n]

After all, it's a communication via udp, hence no session can be managed.
It's kind of odd that such a person like Silicon_Milke asks this kind of question.

[^misantropia^]

After all, it's a communication via udp, hence no session can be managed.

Utter nonsense.

[Silicone_Milk]

What do you mean by "such a person"?

[a13n]

Utter nonsense.

Correct me, if I'm wrong.

What do you mean by "such a person"?

such a tech person

[^misantropia^]

Correct me, if I'm wrong.

Alright. You're wrong.

[a13n]

Can you prove it?

[^misantropia^]

I can.

[AnthonyJ]

Can you prove it?

Well, its not really that hard to prove it really. Q3 only uses UDP for all communications with its clients. If it wasnt able to associate data with specific clients the game would be unworkable. See SV_PacketEvent() for how Q3 matches UDP packets up to clients in the game, therefore maintaining state for that client throughout the session (game).

It'd be fairly easy to modify q3 to work the way Silicone Milk thought - change it so that SVC_RemoteCommand does a similar thing with matching the netadr_t's, and if they're a client in the game you can easily mark them as an admin so that they dont need the correct password in the future. Its potentially a useful change to be able to tell who has rcon access - eg highlight them differently in the scoreboard (as CPMA does with referee status players, f.ex).

If you wanted, you could even extend it so that it maintains a session for non-client netadr_t's too, just maintain a list of "active rconners" (with timeouts etc), although SM's original post suggested he was assuming it was a special case for players on the server.

[a13n]

ouch!
apology for my stupidity