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

[Olivier Baur]

(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)


Best,

-- Olivier