Re: [Freeciv-Dev] (PR#39957) multiple bugs in HACK handling
http://bugs.freeciv.org/Ticket/Display.html?id=39957 > Jason Dorje Short wrote: > http://bugs.freeciv.org/Ticket/Display.html?id=39957 > > > William Allen Simpson wrote: > >> Madeline, where is your code? The AUTH code here is cryptologically >> unsound. Did the AUTH code come from someplace special? Is there any >> reason to be backward compatible with anything? > > The auth code was written by mike or per as a quick fix to get the > client to auto-launch the server. There is little need for it to be > backward-compatible even among the same version of freeciv I think. > > And, how is it cryptologically unsound? My mistake, I misread - the above reply is about the HACK test code, not the auth code. About the auth code, I don't see why it's needed outside of pubserver. If pubserver is replaced universally with GGZ then it could be dropped completely. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39957) multiple bugs in HACK handling
http://bugs.freeciv.org/Ticket/Display.html?id=39957 > William Allen Simpson wrote: > Madeline, where is your code? The AUTH code here is cryptologically > unsound. Did the AUTH code come from someplace special? Is there any > reason to be backward compatible with anything? The auth code was written by mike or per as a quick fix to get the client to auto-launch the server. There is little need for it to be backward-compatible even among the same version of freeciv I think. And, how is it cryptologically unsound? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39957) multiple bugs in HACK handling
http://bugs.freeciv.org/Ticket/Display.html?id=39957 > Madeline Book wrote: > I am slightly confused here in that you change subject to the database > auth code (i.e. server/auth.[ch]) - I assume you meant the hack > mechanism. > No, I was looking at the auth code. > ... I have on more than one occasion been tempted to add a > dependence on libssl, e.g. so that even the server operator could > be considered an "untrusted party". > That would be better in some ways, but SSL/TLS involves a different problem space. I'm doubtful that we need encrypted communications, with a complete Diffie-Hellman key agreement protocol. If we did, I'd add Photuris instead In this case, CHAP will be OK. > With respect to preserving the hack mechanism, it is unlikely that > someone would only upgrade their client and not also their server, > so it would be safe to remove for future versions. ... > Since 2.1 clients will never be able to access 2.2 servers (they will die() on the unrecognized terrain land and water), that's a good time to introduce a replacement. Thanks you for your background information. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39957) multiple bugs in HACK handling
http://bugs.freeciv.org/Ticket/Display.html?id=39957 > Jason Dorje Short wrote: > But the point is that having HACK access allows you to write directly to > the filesystem, through the /save command among others. HACK access > should only be given when you do not mind the user having write access. > That is why the hack check is done the way it is now and the client is > supposed to be able to write to the file to get it. > AFAICT, there is no check in the server code that the client has write access, nor that the file was properly deleted. And the mask isn't properly set, either. There is no security reason for the process. Madeline, where is your code? The AUTH code here is cryptologically unsound. Did the AUTH code come from someplace special? Is there any reason to be backward compatible with anything? ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39957) multiple bugs in HACK handling
http://bugs.freeciv.org/Ticket/Display.html?id=39957 > William Allen Simpson wrote: > http://bugs.freeciv.org/Ticket/Display.html?id=39957 > > > Jason Dorje Short wrote: >> Also the whole point of the HACK check is that the client SHOULD have >> permission to delete the file created. If the client cannot write to >> that file then it should not be granted hack access. > > Speaking as an Internet security expert, that's just plain wrong. It's > merely a token, used as a shared-secret. It's bad enough that it's used > as a plaintext password. > > For security, the files should be controlled and updated by the server. > The client should have no more than read access, especially as the > current scheme is designed for multiple clients accessing the server > installed in a common directory. > > Moreover, in a properly designed protocol, the client should be able to > access the server at various control levels remotely. For 2.2 or 2.3 > > For 2.1, I'm just fixing the wrongly sent packets! But the point is that having HACK access allows you to write directly to the filesystem, through the /save command among others. HACK access should only be given when you do not mind the user having write access. That is why the hack check is done the way it is now and the client is supposed to be able to write to the file to get it. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39957) multiple bugs in HACK handling
http://bugs.freeciv.org/Ticket/Display.html?id=39957 > Jason Dorje Short wrote: > Also the whole point of the HACK check is that the client SHOULD have > permission to delete the file created. If the client cannot write to > that file then it should not be granted hack access. Speaking as an Internet security expert, that's just plain wrong. It's merely a token, used as a shared-secret. It's bad enough that it's used as a plaintext password. For security, the files should be controlled and updated by the server. The client should have no more than read access, especially as the current scheme is designed for multiple clients accessing the server installed in a common directory. Moreover, in a properly designed protocol, the client should be able to access the server at various control levels remotely. For 2.2 or 2.3 For 2.1, I'm just fixing the wrongly sent packets! ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39957) multiple bugs in HACK handling
http://bugs.freeciv.org/Ticket/Display.html?id=39957 > William Allen Simpson wrote: > http://bugs.freeciv.org/Ticket/Display.html?id=39957 > > > server/gamehand.c >handle_single_want_hack_req() > Sent send_ruleset_choices() when HACK is not successful. > Redundant send_conn_info() when HACK is not successful. > > client/connectdlg_common.c >handle_single_want_hack_reply() > File should be deleted by server, client doesn't always have permission. > > Implies every client request should have different file? > > Really need different paradigm for 2.2, perhaps the AUTH system? The purpose of a file-driven HACK check was always to make sure that the local connection was given hack access when the client launches the server. It will also give you hack access when you launch client and server separately from the same computer (and account); whether this is needed I'm not sure. The former case could be handled more cleanly using environment variables. The client sets the FREECIV_HACK_PASSWORD environment variable to some large bit of pseudo-random garbage. On connecting it passes this bit of garbage to the server which is then used to verify the connection and provide HACK access. The only problem is that this will ONLY work if the client controls the server's environment - i.e., when the client launches the server. Also the whole point of the HACK check is that the client SHOULD have permission to delete the file created. If the client cannot write to that file then it should not be granted hack access. And yes, a separate file is needed for each connection. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
