Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2005:
[Freeciv-Dev] (PR#11851) Hack request should verify userid in addition t

[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: >

> [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.)


[Prev in Thread] Current Thread [Next in Thread]