[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Distributed Processing (Was: [Bug-gnubg] Sound support on Mac OS X)

From: Olivier Baur
Subject: Re: Distributed Processing (Was: [Bug-gnubg] Sound support on Mac OS X)
Date: Wed, 9 Jul 2003 17:35:09 +0200

(since security matters are tough issues, I've forwarded this answer to the bug-gnubg list, so we can benefit from all opinions out there)

Le mercredi, 9 juil 2003, à 16:59 Europe/Paris, Holger a écrit :

(about using gnubg masters/slaves on the Internet)

One question I have, though. What about security implications? If gnubg suddenly turns out to be a server that other people can connect to... Does it accept any (recognized) command? If not there might still be buffer overruns or the like. Could this be an issue?

Yes, security is always a big issue.

There are no gnubg commands exchanged (so no risk for commands like "!do-something-very-bad"); the session protocol is just about task requests being sent from master to slave and results being sent back from slave to master (as bunches of gnubg structs in binary format).

However, even without talking about buffer overrun bugs (like what happened on MS Windows http servers), there are some concerns about people setting up fake gnubg slaves that could send back corrupted results to masters (either corrupting net results or crashing the masters,) or overflow masters with notifications, or whatever.

Please note that slaves don't connect to masters; a master will connect to a slave when instructed by its user; so the only risk is for masters that listen to all availability notifications they receive from the Internet -- these guys could connect to someone who's not the good helping slave he pretends to be...

I've already been thinking about some security locks; for example, masters could set up a list of authorized slaves, based either on IP address or username/password authorization. There is also an IP-mask filter feature, to restrict masters to listening only to a specific IP sub-network; this is not yet implemented in the GTK interface, but can be set up using "set pu remote mask <ip-mask>".

As far as slaves are concerned, the problem is the same, but the other way round: they could be used by fake masters that could likewise crash them (eg, by giving them rollout structs with ridiculous data, like Not-A-Number floats, etc) or flood them with connect requests; so the solution would likewise be for the slave to set up a list of authorized masters (the IP-mask feature described above also works for slaves)


-- Olivier

reply via email to

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