Unrestricted Python in 1.2?

[allefant]

After mentioning it in IRC, it seems that I'm not the only one who is a bit worried about unrestricted Python in Wesnoth 1.2. Basically, as is also mentioned in the old Python thread, there is no 100% secure restricted execution model for Python: The Python interpreter is linked to libc, and you can dynamically change about any aspect of the standard interpreter at runtime - so it's never really secure, even if using the existing rexec module. I'm not an expert on this, but it's what google suggests.

This means, someone could upload a malicious script to the campaign server, and implement a Python AI which does something bad like deleting your root directory.

As solution for after 1.2, we probably should provide a way to mark campaigns on the campaign server as trusted. That is, a number of people would have special access to the campaign server, and could mark campaigns as trusted. Each new campaign would start as untrusted. And only trusted campaigns would be allowed to execute .py files.

So, like, a new campaign appears on the server from nowhere - it may not use Python. Someone from the forums uploads a campaign with a Python AI, then someone with CS access marks it as allowed, and it can now execute the .py files. (Or maybe the CS would not even send the .py files otherwise).

It's how e.g. Blender/GIMP scripts work - you download them from sites where you expect no malicious code, even though any such script has complete access to your whole file system.

Anyway, the solutions I see for 1.2:

• Do nothing. It's quite unlikely someone will actually construct a malicious Python AI and upload to the campaign server. But then, a lot of users will download 1.2, and can never know..
• Disallow AI scripts in campaigns. That is, only .py files manually copied into <userdir>/data/ais appear in the multiplayer dialog, but never .py files directly downloaded from the campaign server. This would mean, until trusted files are implemented, campaigns can't use Python AIs. And to run a Python AI, you would yourself have to place it in a certain directory.
• Compile without Python support by default, and specifically, put no Python support into the official 1.2 binaries. It would mean, all downloaded versions would be safe, and it also requires no code change. Python would not be available to general users until something is done about trusted files.
• Implement trusted files on the CS.. but not enough time to do for 1.2 I guess.
• Actually attempt restricted execution of the Python code (i.e. override "file" and "sys.*" and so on, very easy to do). That still makes it possible to break out of it (would need some Python expert for more info here), but at least you would need to be able to do some Python black magic (or copy&paste it from somewhere) first in order to do bad things

[ILikeProgramming]

I don't think Python ai's are a problem because:
a) I doubt many exist
b) Wesnoth is easily hackable anyway (At least I think so, I never tried).

[zookeeper]

I don't think Python ai's are a problem because:
a) I doubt many exist

That is not related at all to the problem. If we know that campaigns from the campaign server can do anything to people's computers, we can't encourage people to use Python AI's - which sort of destroys the whole point of their existence. Also, I really do not want to have to worry about some malicious code whenever I download something from the server.

I don't know whether you could use buggy WML or something to get arbitrary code executed.

As harsh as it sounds, I'd say we simply move to some other language (something that has a proper restricted execution model) if we can't have a safe way of running arbitrary Python scripts.

[Tux2B]

IMO, Python AI's should be restricted, though the question is : how to do that?

I don't know very well how Python AIs work, but I think that marking campaigns "untrusted" is using a python AI that is a good but temporary solution.

Are C++ AI somehow restricted? If so, I the method could be applied to Python too, I guess. Maybe you could, in order to do so, ask people making Python AI's to send them to a dev first, so it gets checked first, who will put the campaign after checking it. Maybe there could be a simple way to implement a bot in Wesnoth going through the AI file, but it may not be as secure as the other solution, and it needs a considerable amount of work and it will slow things down quite a lot, I'm afraid.

[Yogibear]

b) Wesnoth is easily hackable anyway (At least I think so, I never tried).

Well, of course it is, since the source code is free. But you would have the problem of distributing your code. The official downloads are safe and normal users won't use anything else.

[Dave]

b) Wesnoth is easily hackable anyway (At least I think so, I never tried).

Do you mean hackable or crackable?

Hackable means that it is easy to modify Wesnoth.

Crackable means that it is possible to do malicious things to the computers of people who have Wesnoth installed and running.

We hope that Wesnoth is hackable. We hope that Wesnoth is not crackable. We don't believe it is easily crackable besides this issue.

David

[Sapient]

Dave - like it or not, one of the definitions of hacker is now cracker. We can thank the mainstream media for this confusion.

I think the easiest solution is to warn the user when they're about to download a campaign with a python script, listing the author, risks, etc... then let them decide whether or not they wish to trust it. If the script has been reviewed by a wesnoth developer and unchanged since the review, it could be listed as "certified" by that developer in the dialog.

[ILikeProgramming]

b) Wesnoth is easily hackable anyway (At least I think so, I never tried).

Do you mean hackable or crackable?

Hackable means that it is easy to modify Wesnoth.

Crackable means that it is possible to do malicious things to the computers of people who have Wesnoth installed and running.

We hope that Wesnoth is hackable. We hope that Wesnoth is not crackable. We don't believe it is easily crackable besides this issue.

David

I can easily get WML to take up infinite memory...

The problem with the "certified" system is that open source allows people to check how the campaigns are verified. Therefore, people can upload that code to the server and they can now do something evil.

I think the easiest solution is to warn the user when they're about to download a campaign with a python script, listing the author, risks, etc... then let them decide whether or not they wish to trust it.

I think this is actually the best solution.

[Dave]

I can easily get WML to take up infinite memory...

I don't think anyone would consider that to be anything other than a minor annoyance. It doesn't seriously compromise the security of the user's system. It's just a very very weak denial-of-service attack.

The problem with the "certified" system is that open source allows people to check how the campaigns are verified. Therefore, people can upload that code to the server and they can now do something evil.

The idea of the 'certified' system is to have programmers review code to make sure it's not malicious.

Dave - like it or not, one of the definitions of hacker is now cracker. We can thank the mainstream media for this confusion.

Sure....and because of that the way the term was being used is confusing. Wesnoth is not easily crackable, and we want to keep it that way.

David

[irrevenant]

I think the easiest solution is to warn the user when they're about to download a campaign with a python script, listing the author, risks, etc... then let them decide whether or not they wish to trust it.

I think this is actually the best solution.

Unfortunately this is an irresponsible solution. In effect it's deliberately offloading the problem onto a large group of people who we know in many cases won't have the basic technical skills to make a wise decision.

The same thing will happen as always happens with warning messages: If the user doesn't know the right choice they'll look bewildered for a second then hit 'OK'.

Annoying as it is, the responsible and safe solutions seem to be:

(1) vet each and every Python AI that's posted to the campaign server; or
(2) disallow Python AIs on the campaign server and include them with the main game download instead once they're vetted.

In both cases people are still free to develop and use Python AIs on their own machine and distribute them informally but they won't have the legitimacy that being hosted on the Wesnoth campaign server would give them.

[allefant]

I just committed a solution to trunk which is somehow between those two, here is the commit message:

Code: Select all

<CIA-19> elias * r13566 /trunk/src/ (ai_python.cpp campaign_server/campaign_server.cpp): 
<CIA-19> Simple addition for now to never execute unchecked Python files downloaded from the campaign server:
<CIA-19> - Only files ending in ".py" can be executed as Python AI.
<CIA-19> - The campaign server will rename all *.py files to *.py.unchecked before sending.
<CIA-19> - This means, Python files are not executed anymore without manually removing the .unchecked.
<CIA-19> - If a campaign has a python="allowed" property on the CS, the renaming is not done (so someone with direct CS access could already mark trusted campaigns - a better interface might be needed though).

It's a quite minimal change, and if it is also applied to 1.2, then the problem should be solved: No more .py files are executed. And in the (probably not very likely) case we actually will see a demand for campaigns with Python AI for Wesnoth 1.2, then a trusted campaign already could manually be marked (or users could rename the files).

Of course, the safety of this relies now on if nothing was overlooked in the patch..

[ILikeProgramming]

I just committed a solution to trunk which is somehow between those two, here is the commit message:

Code: Select all

<CIA-19> elias * r13566 /trunk/src/ (ai_python.cpp campaign_server/campaign_server.cpp): 
<CIA-19> Simple addition for now to never execute unchecked Python files downloaded from the campaign server:
<CIA-19> - Only files ending in ".py" can be executed as Python AI.
<CIA-19> - The campaign server will rename all *.py files to *.py.unchecked before sending.
<CIA-19> - This means, Python files are not executed anymore without manually removing the .unchecked.
<CIA-19> - If a campaign has a python="allowed" property on the CS, the renaming is not done (so someone with direct CS access could already mark trusted campaigns - a better interface might be needed though).

It's a quite minimal change, and if it is also applied to 1.2, then the problem should be solved: No more .py files are executed. And in the (probably not very likely) case we actually will see a demand for campaigns with Python AI for Wesnoth 1.2, then a trusted campaign already could manually be marked (or users could rename the files).

Of course, the safety of this relies now on if nothing was overlooked in the patch..

This would make campaigns unplayable and might cause some new players to quit trying to get add-ons.

Even worse: a new version is downloaded, but the old *.py file is kept when downloading unchecked python. This may cause a bunch of errors.

[allefant]

This would make campaigns unplayable and might cause some new players to quit trying to get add-ons.

True. The idea was, that some users who know what they do could manually rename the files - so it actually makes sense that you can download the campaign even though it is unplayable at first.

Even worse: a new version is downloaded, but the old *.py file is kept when downloading unchecked python. This may cause a bunch of errors.

Well, no campaigns with python AIs exist currently on the CS (AFAIK), so this can't happen.

The difficulty will mainly be for campaign developers who want to use Python AIS - they need to first be known on the forum as trusted people, then convince someone with direct CS access to mark their campaigns as safe - before users will then actually get the un-renamed .py files. (Python AIs outside of the CS are completely unaffected by this btw.)

[ILikeProgramming]

Even worse: a new version is downloaded, but the old *.py file is kept when downloading unchecked python. This may cause a bunch of errors.

Well, no campaigns with python AIs exist currently on the CS (AFAIK), so this can't happen.

The difficulty will mainly be for campaign developers who want to use Python AIS - they need to first be known on the forum as trusted people, then convince someone with direct CS access to mark their campaigns as safe - before users will then actually get the un-renamed .py files. (Python AIs outside of the CS are completely unaffected by this btw.)

By this I ment ais renamed by the user, or previous versions marked as "trusted" though the new one isn't.

[allefant]

Ah, I see. I guess, once a campaign is marked trusted, it should stay trusted.