-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everybody! dfranke lately spotted several possible security issues in our code. That is of those findings, so far two led us to the conclusion "serious enough for official reporting" so that Rhonda submitted two new CVE for us: 1) CVE-2009-0366 was submitted for bug #13037 [1] 2) CVE-2009-0367 was submitted for bug #13048 [2]
The "interesting" question is how to fix those issues. From IRC conversations it looks like silene will have a look at the first one (not sure though...). More interesting is the second problem which allows python scripts to "escape" our sandbox. In IRC we came to two possible solutions for the soon planned 1.6 release. For post 1.7.x and later stuff we should have a closer look at all this stuff anyway... Here are the two possible (short term) solutions: 1) Limit PythonAI usage to stuff only available in the data/ main tree, nothing from userdata. 2) Completely deactivate Python for the 1.6 series. This means not even allowing it to be compiled into the binary via the build systems. Currently python only allows to write scripts for AI stuff, nothing else. It seems to not be widely used at all. In mainline we do ship some AI scripts for multiplayer, but they seem to not be too well maintained and even non functional at the moment[3]. Until today there was a PythonAI for a scenario in DiD but it was removed now and Dragonking will work on implementing something that "actually works" in FormulaAI. This are all PythonAI usages in mainline. Beside this users seem to not have created much using PythonAI even though it is already possible to use it since 1.2.x days. So what would the benefits for users be if it was possible to load Python stuff from the main dir? Probably not much at all. It would be possible to create AIs themselves, but this option is basically unused. As zookeeper pointed out in IRC today, it is just too difficult to really make use of it (at least at the moment). The benefit of removing Python support from ingame for 1.6 all together would be that no security problems in this module were possible at all and that the dependencies would be reduced a little (this should save several MB in the package size for OSX...). For post 1.6 we should have a closer look at allowing better scripting facilities in Wesnoth to allow content creators more flexibility. Adding "real" support for some way of scripting will be needed and we will have to have a look at "what works best" as in the aspects of "is it secure enough?". "do we have someone to implement it?" and "will content creators be able to use it?". Possible candidates for this are lua (there is some patch already by silene for some "basic stuff", we will have to evaluate how much sandboxing is possible there) and maybe python, though there we will have problems with sandboxing and atm this seems to be a field of research, so rather problematic for us to solve in a good was. Beside this FormulaAI should be further extended to make it really useful, too. Long mail cut short: What about 1.6? Should we got for 1) or for 2)? Or does anyone of you have even a better idea what we should do? Personally I vote for 2) since PythonAI is not really used and it would reduce the (possible) security problems with it to zero (not to speak about the positive impact on packagers with less dependencies). Please reply to this mail, so that we can come to a decision soon. Cheers, Nils Kneuper aka Ivanovic [1]https://gna.org/bugs/index.php?13037 [2]https://gna.org/bugs/index.php?13048 [3]https://gna.org/bugs/index.php?13047 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmhhn8ACgkQfFda9thizwXbzwCfRk0wrJn7oYILx5Ls4hFvd1L1 jJMAn0woJ+e/Dl4EBIqvPLFe4efy2mou =xgMM -----END PGP SIGNATURE----- _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
