Every time a player connects to an on-line game, that player trusts that the game presenter will not send any code that will do damage to the player's computer. In the case of Uru we were trusting Cyan. There was no way to inspect anything I downloaded, but I didn't need to and never had a problem.

Now... who's looking into security? We have lots of people writing Ages, and there will be multiple sources. Perhaps there will be multiple shards, or perhaps servers scattered around the world, and players may not even know which "shard" they're connected to. Who will be responsible for making sure the files sent to clients will be free of piggybacking viruses and such? Will there be any simple tools that players can use to check Ages, to make sure nothing has been added to them?

I don't know. My personal plan is that if the Open Source experiment does happen, I will run it only on a computer whose integrity doesn't matter. Nothing else important will be kept on it, and it will have no connection to other computers in the house.

I figure very few people will be interested in nefarious code, but as with sand sculpture on the beach it only takes one problematic person to ruin things. We need tools to make sure such people are stopped before they get started.

_________________
Want to learn more about the D'ni? Look here: http://www.dpwr.net/

Well, if everything will be open-source, including the changes from fans, then there's nothing to worry, because the developers can check that there's nothing harmful in the code. Just like you can safely install a program like Mozilla Firefox (just to name something).

_________________
URU blog | Archives of the Restoration

Ooooh… Lord Chaos has a point.

Erick, having the source code does not really remove the problem. As I see it someone like GoW could know what is in the source they are using. But, would they know what is in the source I’m using or any shard but theirs? If the networked servers making up a shard are remote and GoW (or whoever) only sees the working copies of the age files, it could be a problem. Someone would have to look at Python scripts in each new age to prevent a Trojan.

Ages will have Python scripts. Python can open ports, serial, TCP, UDP, IP, etc. (http://docs.python.org/3.0/genindex-O.html Reference). Whether they can do that inside the MOUL client I’m not sure. I would bet one could. If so, I suspect it would be reasonably easy to add a Trojan to an age. AV software is not likely to catch a program you have already OK’d to connect to the net. One could hope whatever the Trojan pulls through is caught. But GoMa will be checking and testing ages. So, there is at least that layer of protection.

It may be possible to setup a Trojan shard just as Trojan web sites are setup. Fortunately it will be far more complicated an effort. Since a fake age would have to get past the GoMa testing, setting up a fake shard would be about the only way. Some type of control over which shards are listed here, at GoW, or wherever the list is kept would reduce the possibilities of Trojan shards. Because if an independent shard operator decided to add a standalone Trojan shard, I doubt anyone would know there was a problem until it was too late. So, letting shards on the list is where to control it.


I think it unlikely to be a problem. But it should be part of the age testing. Passing that testing should be part of the criteria to allow an age on any responsible shard.

So, as I see it, the direct answer to Chaos’ question is security is likely going to be handled by GoMa, shard operators and each of us in how we choose a shard.

_________________
Nalates - GoC - 418 - MOUL: KI#00 379 343 - Second Life: Nalates Urriah
Guild of Cartographers

Nalates wrote:

Since a fake age would have to get past the GoMa testing, setting up a fake shard would be about the only way.

Not to detract from the rest of the post, that particular sentence is making a bit of an assumption: There's nothing within Open Source that mandates that GoMa must test all ages for them to be fit - that decision is up to the shard operator and the age developer. So you wouldn't necessarily need a "fake shard" to have a non-GoMa approved age going live. In any case, I would imagine that a "GoMa seal of approval" would only tell you that the age was free from major bugs: Some subtly coded event triggered malware could easily go undetected.

_________________

Mac - KI#00004826
In the interests of the environment, this post has been constructed entirely from recycled electrons.

_________________
ô¿ô......All URU need is love!......ô¿ô

Mac_Fife wrote:

Some subtly coded event triggered malware could easily go undetected.

This was brought up way back when we (GoMa) were first getting organized; and again when we were working on the FCAL; and it will probably be brought up again as we (the community) get more information about everything going on and can start some concrete planning.

However, like you said, there is nothing GoMa can do to stop people from loading uninspected/unapproved Ages to their shard. We are just a fan group trying to provide a service; if people choose not to use that service, so be it.

_________________
Frisky Badger
Guild Member
Guild of Maintainers

My opinions are my own and not necessarily those of the Guild of Maintainers.

KI# 02916326

Python scrips are hosted in a private instance in MOUL. You could easily disable anything in the host that's insecure that Cyan hasn't already disabled. Do that and as long as you get your client from a reputable source you won't have any problems.

_________________
Can you withstand the gaze of the Eye of Eternity?

Nalates wrote:

Ages will have Python scripts. Python can open ports, serial, TCP, UDP, IP, etc. (http://docs.python.org/3.0/genindex-O.html Reference). Whether they can do that inside the MOUL client I’m not sure.

This is an interesting question... has anyone ever tried importing these kinds of libraries into age python scripts and seeing if they run properly? Just how flexible is the python engine embedded into MOUL?

Besides python there may also be bugs in the client that can be exploited in more subtle ways ... buffer overflows and such.

Though I would expect any reputable server to remove such ages as soon as they are discovered

EDIT: It seems SCGreyWolf has answered my question about the Python

_________________
KI: 06935508

Kenguin wrote:

Nalates wrote:

Ages will have Python scripts. Python can open ports, serial, TCP, UDP, IP, etc. (http://docs.python.org/3.0/genindex-O.html Reference). Whether they can do that inside the MOUL client I’m not sure.

This is an interesting question... has anyone ever tried importing these kinds of libraries into age python scripts and seeing if they run properly? Just how flexible is the python engine embedded into MOUL?

Besides python there may also be bugs in the client that can be exploited in more subtle ways ... buffer overflows and such.

Though I would expect any reputable server to remove such ages as soon as they are discovered

EDIT: It seems SCGreyWolf has answered my question about the Python

Uru's python does not include many of the standard Python modules (including the socket modules listed above). As well, every Python script runs in its own instance of the runtime and cannot interact with files outside of the game directory.

Also keep in mind that any firewall software would ask you to confirm the connection, likely even if you had already confirmed the main UruExplorer.exe file.

_________________
Proud Uru, Myst V, and MOUL Hacker
Vancouver "Mini-Mysterium" 2010?

_________________
ô¿ô......All URU need is love!......ô¿ô

Paradox wrote:

Also keep in mind that any firewall software would ask you to confirm the connection, likely even if you had already confirmed the main UruExplorer.exe file.

Not exactly true.

My Firewall(Radial Point) can work in two ways.

It will ask me everytime, "only" if I have not ticked the "ok" option box for this connection.

These are definitely good concerns to have. Fortunately, much of the concern is related to the trustworthiness of the shard operator - if you have to download a custom client to connect to a shard, you're trusting the shard operator (a) not to hose you with embedded malware and (b) not to introduce vulnerabilities into the code (that is, of course, unless you inspect and compile the client yourself).

Hopefully, this won't be a big problem, but for the paranoid and/or cautious, this might be reason enough to stick with the "official" shard and other shards that use the exact same client.

Of course, the maintainers of the "official" source will have to make sure that there are no vulnerabilities as well, particularly in terms of vulnerabilities that age creators could exploit.

Artic_Wagon wrote:

Paradox wrote:

Also keep in mind that any firewall software would ask you to confirm the connection, likely even if you had already confirmed the main UruExplorer.exe file.

Not exactly true. My Firewall(Radial Point) can work in two ways. It will ask me everytime, "only" if I have not ticked the "ok" option box for this connection.

It sounds to me like the firewall would still do its job, as the discussed concern (adding modules to Uru's copy of the python interpreter) would open up new connections, as each interpreter instance is a separate service.

_________________
quahog42 | theclam | lazugod

Mozilla unfortunately is not a very good example. It has lots of bugs and only very timely response by the developers prevent the worst consequences. And it is not really Firefox itself which has the problems but the openness of Javascript which when allowed to run can have all sorts of unforeseen side effects. As another example any Web application which interfaces to a database has potential problems with SQL injection if the web interface is not very carefully written. In that way MO with Python as user scripting language is sort of similar. It will take a lot of careful code examination to prevent potentially dangerous things to happen. I don't have much experience with Python, if it is similar to the Java (as in NOT Javascript) sandbox which by design secures file and network access then there may be hope.

_________________
93 93 620

Mac_Fife wrote:

Nalates wrote:

Since a fake age would have to get past the GoMa testing, setting up a fake shard would be about the only way.

Not to detract from the rest of the post, that particular sentence is making a bit of an assumption: There's nothing within Open Source that mandates that GoMa must test all ages for them to be fit - that decision is up to the shard operator and the age developer. So you wouldn't necessarily need a "fake shard" to have a non-GoMa approved age going live. In any case, I would imagine that a "GoMa seal of approval" would only tell you that the age was free from major bugs: Some subtly coded event triggered malware could easily go undetected.

True, but...I was not clear... A person wanting to place a Trojan would need to write an age to put a Trojan in. A fake age, as I was thinking of it, would be almost nothing... a shell... as little as possible. It would be just enough to let the game system link to it and hold the Trojan. I can’t see that getting past any testing or shard operator.

A substantial age that a Trojan could hide in is a bunch of work to build. I do not think it likely a black hat is going to put out that much effort. Because of the testing ages are likely to go through before a GoW or OU or other responsible operator allows them in, 'fake ages' in that sense are unlikely.

Also, ripping off someone’s age and renaming it to bury a Trojan in is unlikely to make it into shard.

Anyone the community does not know that wants to add an age… I’m not sure how easily they will be accepted. I would want to see an age from an unknown writer and test it before I popped it into a server. People writing ages are likely going to be known to the community. Those planting Trojans will want to remain very anonymous. I think it would be easier to remain anonymous with an entire bogus shard than an age. After all they would just need only one age load… But, it is still a lot of work.

My point is that with some care the community offers a good layer of protection just by its nature.

_________________
Nalates - GoC - 418 - MOUL: KI#00 379 343 - Second Life: Nalates Urriah
Guild of Cartographers