Open Source Security Concerns

vidroth · **Joined:** Tue Oct 03, 2006 3:25 am **Posts:** 869

Open source is (like any other choice) a curse and a blessing, security-wise.

The curse part is that, because the source is publicly available, you don't need sophisticated tools to attack it. You just read the source and look for holes.

The blessing part is, in the long run, this is WAY more secure. Only a small percentage of people reading the source are out to cause harm. The vast majority are there to use and improve it. And the obvious weaknesses get shored up very quickly.

But the general principle is a security term popularly called "security through obscurity," the hope that by keeping something secret you can keep it safe. That's an amazingly popular fiction, a principle that only barely works with three or four people, and works terribly with several thousand. What's the old phrase? "Three can keep a secret, if two are dead."

The reality of the situation is, every place you depend on a secret, is a place where your security is vulnerable. You can't eliminate all secrets from security, but the fewer of them you depend on, the better. Everywhere you think something is secret, you tend to have "trust." And if the secret gets out, your "trust" lets bad people do bad things.

The first several months of the open source release will see a little bit of attacking and a LOT of security updating, that's just the nature of the thing. But once the first wave dies down, we'll have a very solid system, at least as solid as any other MMO out there, and probably moreso.

MustardJeep · **Posted:** Tue Apr 21, 2009 4:42 am

My only worry is that in the short term we will have a spat of UbiBeta silly scripting from people trying to prove a point.

From everything I understand MOUL updated a lot of the easy routes that were popular back then but there are still openings. A lot of the short term answers all involve better fan based game administration then UU had with, a couple people acting as ResEng's, atleast one good DBA per shard, someone able enough to take a Shard down for Maintenance before it crashes.

Really in truly I don't expect there to be anything as spectacular as UbiBeta was for silly scripting fun but as a matter of principal I worry about a few diehard traditionalists that still hang around. As long as it's fun I don't think to many will care one way or the other where the fun came from, but I am glad we have MOUL instead of UbiUru.

Karkadann · **Posted:** Mon Sep 07, 2009 6:30 pm

Quote:

Only a small percentage of people reading the source are out to cause harm. The vast majority are there to use and improve it. And the obvious weaknesses get shored up very quickly.

One can only hope

Nalates · **Posted:** Tue Sep 08, 2009 12:51 am

Hacking to heard quabs up a tree could be fun...

Paradox · **Posted:** Tue Sep 08, 2009 1:40 am

As some examples of open-source programs which seem to have the security aspect handled quite well include Pidgin Internet Messenger, XMPP chat protocol (Jabber, Google Talk), Firefox Web Browser, and pretty much the entire Linux kernel.

The thing about open-source is not that it is less vulnerable, but when vulnerabilities are pointed out they are often fixed within a day or two. Whereas proprietary software can knowingly leave issues unpatched for years (and actively pursue legal action against those who point out such issues) :roll:

Telbere · **Posted:** Tue Sep 08, 2009 3:48 am

It will all just boil down to sound and fury in the end.

Paradox is right, while I wouldn't rank the Uru Fan Programmer base as able to fix a major problem in a day or two (There just aren't enough programmers here with that kind of time.) I would however think a game ruining bug could be diagnosed and worked around until there is time to fix it.

Karkadann · **Posted:** Tue Sep 08, 2009 4:07 am

Nalates wrote:

Hacking to heard quabs up a tree could be fun...

A pro-pain burner with a pot of boiling water to cook them in would be interesting. or even better to make things a bit more challenging Quab avatars that can be controlled by the Admin with an extra feature so they can turn their claw up at you when you miss kicking them off the island as if their giving you the Birdie

Nalates · **Posted:** Wed Sep 09, 2009 5:42 pm

Karkadann wrote:

Nalates wrote:

Hacking to heard quabs up a tree could be fun...

A pro-pain burner with a pot of boiling water to cook them in would be interesting. or even better to make things a bit more challenging Quab avatars that can be controlled by the Admin with an extra feature so they can turn their claw up at you when you miss kicking them off the island as if their giving you the Birdie

Good one...

agrif · **Joined:** Wed May 31, 2006 4:09 am **Posts:** 20

I am really glad that this discussion steered away from viruses (or other malicious code) in Python files. First of all, while the Python distributed with ages is fairly obscured, it can be unobscured and read, so any funny business will be apparent to anyone who bothers to look. A GoMa check is all that's needed, really. Additionally, the worst a Python file can do, even if malicious code gets through, is fill up the hard drive with random junk. This can be easily avoided (if it isn't already) by hooking the Python "open file" function with some sort of check.

Python (as found in MOUL) cannot sneakily open sockets. The socket functionality in Python is provided by a compiled DLL (on windows) that is not present in MOUL. This functionality cannot be replicated in pure Python, as it needs to be bound directly to operating system calls. The only way an age could use sockets would be if it installed a DLL to the MOUL directory, which no age has any right to do. It would raise a red flag immediately.

Ages are not a concern here.

The client and server security is, but the code we end up getting will not be any more or less secure than the same code that Cyan ran. Just because there may be multiple servers running does not change that. Just make sure you trust where your code is coming from, and who operates the server, and it'll be just as secure as before. We could even implement a simple key system so you can verify you're actually connecting to the server you think you are, really simply, and there may already be such a system in place.

It's really the same situation as browsing the web with Firefox. Do you trust the Mozilla Foundation? Do you trust the HTTP server? Do you trust the web site author? One of these is open-source, the other often is as well, and the last is usually some stranger. We browse anyway.

Deledrius · **Posted:** Fri Feb 19, 2010 2:08 am

Surely you understand the concept of obfuscated malicious code? GoMa looking it over does not guarantee safety, no matter how meticulous they are.

I agree a modicum of sanity is better than crazed paranoia, but the tone of your post suggests a nonchalant dismissal of some very real concerns.

agrif · **Joined:** Wed May 31, 2006 4:09 am **Posts:** 20

Deledrius wrote:

Surely you understand the concept of obfuscated malicious code? GoMa looking it over does not guarantee safety, no matter how meticulous they are.

I agree a modicum of sanity is better than crazed paranoia, but the tone of your post suggests a nonchalant dismissal of some very real concerns.

Ack, that's not quite what I was going for but looking at my post again I see what you mean.

Obfuscated code certainly wouldn't help, but some things will always have the same name. File opening can only be done through "open( ... )", calling executables is always "os.system" (or "popen.*"), and other things also have set names. You could rename them in code, but the name would have to show up at least once, and renaming them is already grounds for suspicion.

Code obfuscation at all should be suspicious to begin with, and Python, by it's very nature as a scripting language, is easy to check for malicious intent. Just do a global search for "open" and the scarier of the default modules and make sure they're not being used, or that they're used properly. It helps that MOUL doesn't include most of these powerful modules.

I shouldn't have said I don't think Age security is an issue... I just don't think it's a problem after some simple precautions.

Client/Server security I am concerned with, but no more than with anything I do involving the internet. I certainly think work should be done on Uru's net security, but I'm just trying to cool some of the more panicked opinions here.

(also, it was mentioned before that a virus age would most likely be empty, which is not convincing as an actual age. To be convincing enough to be distributed, it would have to have an interesting age built in as well, which takes a huge effort. It seems more likely that a would-be virus writer would choose some easier vector for infection.)

Nalates · **Posted:** Fri Feb 19, 2010 6:56 pm

I think most of the security will come from knowing who is doing what.

Just as we don't open strange emails we won't visit strange shards. When an age comes from someone we don't know that alone is a flag.

Exactly what GoMa and others will do to find malicious code we don't know. But, the code does not have to be in the server, client or age. Just having the ports open creates opportunities for problems.

I agree with Deledrius, somewhere there is a balance point between hysterical paranoia and ignoring the possible problems.

Keikoku · **Posted:** Fri Feb 19, 2010 9:01 pm

agrif wrote:

Deledrius wrote:

Code obfuscation at all should be suspicious to begin with, and Python, by it's very nature as a scripting language, is easy to check for malicious intent. Just do a global search for "open" and the scarier of the default modules and make sure they're not being used, or that they're used properly.

Unfortunately, it's nowhere near this simple.

The problem with obfuscation isn't with JavaScript-style obfuscation, i.e. blatantly obfuscated strings being "decrypted" and fed to eval(), but more in the sense of the Underhanded C Contest, where code can look perfectly safe yet contain an exploitable bug which is likely to be overlooked.

And it isn't just (or even particularly) malice which is a problem, but carelessness. A simple bug in client-side code could result in the game basically becoming a botnet, where anyone who knows how to exploit the bug can execute arbitrary code on players' computers.

At one time, there was a project to provide a restricted execution environment for Python. It was abandoned because the problem was simply too hard, particularly when the language wasn't designed this way to begin with.

Personally, I would suggest migrating age scripting to a more restricted language such as Lua or JavaScript. Both of these were designed for embedding, and as such have a very minimal "baseline" environment. Scripts can't do anything which the hosting environment doesn't explicitly choose to support.

With Python, there's a huge standard library available by default, and restricting access to it requires restricting all of the different ways that access could be obtained (i.e. not just "importing" a module directly but relying upon other modules inadvertently re-exporting features from the modules which they import, modules evaluating caller-supplied expressions in their local namespace, etc).

belford · **Joined:** Thu Jun 08, 2006 7:01 pm **Posts:** 1890

I've run into this in a different Python project that I work on. It's a nuisance, and indeed, Python provides no good solution.

Since the Uru client comes with its own Python executable, it *could* solve the problem at that level: ship a cut-down version of the Python binary, with all the dangerous bits cut out. No "open" function, etc.

However, I don't know how difficult it is to do that to Python. I suspect it's all intertwined in there.

The "right" solution is probably Javascript. (My teeth hurt when I say those words...)

It might not even be totally stupid to switch to Javascript incrementally. Have both a Python interpreter and a Javascript interpreter in the client; use the existing Ages as they stand, and write new Ages in Javascript. This avoids the problem of having to rewrite all of Cyan's code (on day 1, anyhow).

Keikoku · **Posted:** Sat Feb 20, 2010 11:41 am

belford wrote:

It might not even be totally stupid to switch to Javascript incrementally. Have both a Python interpreter and a Javascript interpreter in the client; use the existing Ages as they stand, and write new Ages in Javascript. This avoids the problem of having to rewrite all of Cyan's code (on day 1, anyhow).

That's certainly an option. There are Python wrappers for Spidermonkey (Mozilla's JavaScript interpreter) and Lua, which might be easier than integrating multiple scripting languages into the engine. It would certainly be easier if JavaScript/Lua code needed access to features which are currently implemented in Python.

But so long as support for Python scripts is required, there is the issue of determining whether a specific age is allowed to use Python. Code signing is problematic in a project such as this. HMAC relies upon the client knowing the key but keeping it a secret. RSA only requires the client to have the public key, but there are legal issues with distributing cryptographic code. If the servers are trusted, they can just set a flag to indicate whether an age is "trusted", but that won't work when anyone can run a server.

Open Source Security Concerns

Who is online