[Freeciv-Dev] (PR#11851) Hack request should verify userid in addition t
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Subject: |
[Freeciv-Dev] (PR#11851) Hack request should verify userid in addition to random string |
From: |
"Ed Overton" <edoverton@xxxxxxxxxx> |
Date: |
Fri, 7 Jan 2005 21:24:29 -0800 |
Reply-to: |
bugs@xxxxxxxxxxx |
<URL: http://bugs.freeciv.org/Ticket/Display.html?id=11851 >
> [kauf - Sat Jan 08 02:27:55 2005]:
> Your patch doesn't solve that however as user B can simply log in as
> user A.
I may be confused about what "log in" you mean here.
Unless I misunderstand user_username(), it's giving the host userid, not
the the player's game username. So if person X logs in to the host as
host userid A, then yes - X's client would then get hack level, but
that's because the client has been invoked by host userid A.
In the case where host userid B logs into the game as game username A,
then user_username() will return host userid B, not game username A.
There's no match in that case, and the hack elevation does not take
place (which is what we want - client host userid B does not match
server host userid A).
Having said all that, it's still pretty trivial to get around this
proposed host userid check since user_username() can be tricked into
thinking you're some other host userid (simply by defining the $USER
environment variable). That could be improved somewhat by moving the
$USER check after the getpwuid and GetUserName calls (I didn't feel
confident about the possible side effects of that change to add it to
the patch - I'm assuming the $USER check was placed first intentionally).
As written, the patch won't stop someone who knows the $USER trick, but
I do believe it is a small step in a more secure direction. With the
re-ordering change to user_username(), that'd be another step. It still
wouldn't be perfect from the server side, though, since someone could
hack the client code to issue a faked userid for the hack request challenge.
Perhaps another way to tackle this issue would be to have the server
normally deny any hack cmdlevel elevations. A server command line
option could be used to enable the elevation, in which case the existing
checks would process as usual. (Obviously, when the client is used to
invoke a server, that command line option would be applied.)
Ed
- [Freeciv-Dev] Re: (PR#11851) Hack request should verify userid in addition to random string, Mike Kaufman, 2005/01/07
- [Freeciv-Dev] (PR#11851) Hack request should verify userid in addition to random string,
Ed Overton <=
- [Freeciv-Dev] Re: (PR#11851) Hack request should verify userid in addition to random string, Vasco Alexandre da Silva Costa, 2005/01/08
- [Freeciv-Dev] Re: (PR#11851) Hack request should verify userid in addition to random string, Vasco Alexandre da Silva Costa, 2005/01/08
- [Freeciv-Dev] (PR#11851) Hack request should verify userid in addition to random string, Ed Overton, 2005/01/08
- [Freeciv-Dev] Re: (PR#11851) Hack request should verify userid in addition to random string, Vasco Alexandre da Silva Costa, 2005/01/08
- [Freeciv-Dev] (PR#11851) Hack request should verify userid in addition to random string, Ed Overton, 2005/01/08
- [Freeciv-Dev] (PR#11851) Hack request should verify userid in addition to random string, Ed Overton, 2005/01/10
- [Freeciv-Dev] Re: (PR#11851) Hack request should verify userid in addition to random string, Vasco Alexandre da Silva Costa, 2005/01/10
- [Freeciv-Dev] (PR#11851) Hack request should verify userid in addition to random string, Ed Overton, 2005/01/11
- [Freeciv-Dev] Re: (PR#11851) Hack request should verify userid in addition to random string, Vasco Alexandre da Silva Costa, 2005/01/11
- [Freeciv-Dev] (PR#11851) Hack request should verify userid in addition to random string, Ed Overton, 2005/01/14
|
|