Guild of Writers

Chacal wrote:How secure is MOUL's secure Python loading? I can't inject code in an already downloaded file? I can't intercept the file before it gets to the client and modify it on the fly?

I know someone claiming that he could modify the Python at will, even with the closed client we have now (no, it's not me, I'm not really good at that kind of stuff).

D'Lanor wrote:Actually it is that way in UU as well with prp files. If the client tries to load a prp that is not in the server side age file nothing in that prp file can be interacted with. And trying to interact with clickables in the "rogue" prp will even silently crash the client. So combined with MOULs secure Python loading this is a reasonably safe system.

So, the server has all the prp files, too? When I set up a UU server I never had to upload them...

No, but you had to include an [agename].age file (contains a list of all prp files belonging to an Age), and if I recall correctly either an [agename].sum or a manifest file.
The actual prp files weren't needed for comparison, just the names and checksums (and some other random info iirc)

Well, that is like Alcugs does it then, the server can only check if the client loads a file that is not specified at all (Alcugs will kick the client immediately then, even if it loads a page from another age - which is how I noticed that Pahts loaded aprts of Ahnonay Sphere 4). But that does not really help, one could still change an already existing prp file and do everything.

That would be where the checksums come in. The client should send a checksum of the prp file through for verification.
Of course, that doesn't prevent a modified client from sending in a valid checksum and then using a modified prp file.

That's gonna be the primary security concern of OSS Uru in my eyes: The ease with which a client can be modified to circumvent those measures.

diafero wrote:But that does not really help, one could still change an already existing prp file and do everything.

No, because the dataserver overwrites it. AFAIK MOUL does not allow the dataserver to be disabled.

Trylon wrote:That would be where the checksums come in. The client should send a checksum of the prp file through for verification.
Of course, that doesn't prevent a modified client from sending in a valid checksum and then using a modified prp file.

Exactly, and that makes the send-checksums-to-server a total waste of resources, just like redownload-python-each-startup.

Trylon wrote:That's gonna be the primary security concern of OSS Uru in my eyes: The ease with which a client can be modified to circumvent those measures.

I would not spend a minute on that - as you pointed out, the way Uru works (with all the actual computation being done on the client, and the server just forwarding messages) is unfixable unless you re-write the protocol - assuming that MOUL still works mostly like UU/Alcugs. So I would spend my efforts on the server, hardening it against malicious clients. The clients only needs to make sure people don't accidentally circumvent the dataserver, something which can easily happen in UU. And of course, it needs to behave in a defined way if it gets messages from a malicious client the server could not filter out.

D'Lanor wrote:No, because the dataserver overwrites it. AFAIK MOUL does not allow the dataserver to be disabled.

That's true, but only works if the client is closed - I mostly have the potential open source client in my mind as we won't influence the other one anyway. And even then, I would not hold my breath if this can not also be circumvented by some wrapper library between Uru and the file system (like running it with a custom wine).

diafero wrote:

Trylon wrote:That would be where the checksums come in. The client should send a checksum of the prp file through for verification.
Of course, that doesn't prevent a modified client from sending in a valid checksum and then using a modified prp file.

Exactly, and that makes the send-checksums-to-server a total waste of resources, just like redownload-python-each-startup.

Actually, NO, it doesn't make it a total waste of resrouces. In fact it plays a vital role in ensuring that unmodified clients are synchronized to the prps and python files that the server uses.
With multiple servers going online there are bound to be a number that run different versions of specific content. If those aren't properly synchronized it will be disaster.
(Note 1: I'm not talking about a difference in plasma versions. I'm assuming that whatever will happen there will be some sort of "standardized" client/server that most people will use, just like what happens on most OSS projects)
(Note 2: I agree that the re-downloading of python files is utterly pointless. It should just be verified the same way as the prp files)
(Note 2: I don't really care if the server checks the checksums or the client. The latter would be better for server performance I guess.)

diafero wrote:So I would spend my efforts on the server, hardening it against malicious clients. The clients only needs to make sure people don't accidentally circumvent the dataserver, something which can easily happen in UU. And of course, it needs to behave in a defined way if it gets messages from a malicious client the server could not filter out.

Yes, I totally agree on that. It's unmistakable that there will be some attempts to gain illegitimate control over servers, but their impact should be minimized server-wise..

Though I do believe that Uru provides a lot less incentive for malicious hacking than e.g. Runescape or SL. With there no being any economy or notable property in URU and all....

Trylon wrote:Though I do believe that Uru provides a lot less incentive for malicious hacking than e.g. Runescape or SL. With there no being any economy or notable property in URU and all....

That and a lack of popularity is what keeps Uru safe^^

diafero wrote:So I would spend my efforts on the server, hardening it against malicious clients. The clients only needs to make sure people don't accidentally circumvent the dataserver, something which can easily happen in UU. And of course, it needs to behave in a defined way if it gets messages from a malicious client the server could not filter out.

This. There is a need for strict validation of inputs by the server.
For example, it should not be possible to crash a server by using flymode.

Short of modifying the server code itself, a proxy could be added in front of it, for filtering and sanity-checking of the data sent by clients. A kind of application-level firewall, if you will. It could be configured with some baselines, so that, in the above example about flymode, it would detect an abnormal volume of netforced position updates from the same client and drop them or even disconnect it.

ddb174 wrote:That and a lack of popularity is what keeps Uru safe^^

Ah yes, the Apple security model.

During my drive home today, a thought came to me that I thought I'd share with you all. Something that I think would be neat to see added would be a web-browser of sorts in to the KI. Or, maybe, if we were able to add that functionality to an age.

I was thinking it would be cool to make a movie theatre in Ahra Pahts. If there was a way to stream video to a viewer, writers could even use a program like Fraps to make URU films. The avatars already have lots of animations, so we could "virtually" act out movies. If the data could be streamed directly to the Client software, negating the Server. If so, perhaps the functionality could be added (someday) without putting a huge strain on the Servers. Is this even theoretially feasible, or am I wasting time brainstorming a dumb idea?

Sorry, I know this probably sounds stupid - but it's just a thought.