I like where you're going. And I agree that limiting the places in which you can talk to the server will help. In terms of "spoofing" we really need to list the kinds of attacks that we're trying to prevent:alterecco wrote:However, I still find it hard to see how to make it completely spoofproof. Most
of the data I can see these functions sending would be gathered from various
sources, including globally accessible data (that is, stuff that is variable).
This means that anyone with a debug console, or a minimum of modding ability
can change those values (using other mods to affect global state). I can not
see any way around that. If it was just the console, we could rule out
debugmode, but since I can just create a mod that runs a piece of script
whenever I want it too, there is no real way of hiding from this vulnerability.
1. DoS attack on the neurohack.com server (e.g., an extension decides to write massive amounts of data). This can be handled by quotas on the server; it also helps to be able to trace this back to a developer ID.
2. An attacker creates an extension that clobbers another extension's data. To prevent this we need isolation across extensions (and/or a developer ID so that a developer can grant appropriate permission to an extension).
3. An attacker modifies (or creates) an extension to clobber data on the server. To prevent this we need to sign extensions so that we can trust that an extension has the right to touch its storage.
4. An attacker calls the server directly (without the Transcendence engine) to clobber data on the server. This requires the Transcendence engine to also have a secret key; and we have to validate the secret key when talking to the server.
5. An attacker clobbers their own local data with another extension (or with debug console). To prevent this we need control over the extensions used in a game. Imagine that an adventure can specify the set of extensions that it will allow. [And of course, an adventure should specify if it allows the debug console.]
6. An attacker clobbers their own local data with a memory tool (which then get written back up to the server). One way to mitigate this is to have user IDs that you use in the game (which I think we need anyway). If someone does this, we can ban the user. Another way to mitigate this attack is to put logic on the server itself. This is also a possibility, though more difficult. Basically, an extension could define some code blocks that live on the server. The extension would invoke those code blocks remotely.
