Elgato_dark/Terasology
1
0
Fork 0
mirror of https://github.com/MovingBlocks/Terasology synced 2026-05-24 09:28:22 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
Terasology/docs/Module-Security.md
Tobias Nett 2d8ef61e80
doc: move wiki content to docsify page (#5155) 
* rename docs to docs-pre-merge
* add wiki content based on commit e4d4b10424f24eed6583ea0e998da8aa32a27a3f
* replace wikilinks with markdown links in _sidebar
* use sidebar link text as title via ` autoHeader: true` 
* rename files with `:` or `,` in the name
* use the wiki Home page as entry point instead of the repo README
2023-10-31 14:46:35 +01:00

3.7 KiB
Raw Blame History

Testing

  • The Malicious module executes its malicious tests when its system is initialized. Look for messages from this class in the Terasology log file.
  • The Sample module provides a ReallyCrashGameBlock that attempts unauthorized use of System.out when you use it.
    • use the console to give ReallyCrashGameBlock
    • place the block on the ground
    • hit the Use key

Threat Models

Threats from local execution of untrusted modules

Accessing a local resource

For example:

  • a local file
  • capture your desktop (outside the game window)
  • snoop on local devices (keyboard, webcam, USB drives)

Accessing your local network

  • smartphones and other computers
  • printers and other Internet-connected Things

Exfiltration and Exploitation of Remote Networks

  • uploading data to a third-party server
  • using network resources to attack a remote target

⚠ A module will send data to the game server you are connected to. The thing to prevent is sending information to a third party without the consent of either client or server.

Threats from network input from untrusted clients

The game creates new objects and executes methods on them in response to network input. An attacker may attempt to craft a message that tricks the server in to executing an unsafe method.

Security Mechanisms

Terasology relies on Gestalt Module Sandboxing to protect from these risks of running untrusted JVM code. However, it's up to the application to make sure the sandbox is configured and applied correctly.

ClassLoaders

  • ModuleManager.setupSandbox configures a PermissionProviderFactory with modules and the allowable packages and classes.
  • ModuleManager.loadEnvironment constructs a gestalt.module.ModuleEnvironment with that PermissionProviderFactory.

Java Security Manager

o.t.engine.core.ModuleManager.setupSandbox installs the gestalt ModuleSecurityPolicy and ModuleSecurityManager.

The restrictions of ModuleSecurityPolicy apply to classes which were loaded using a ModuleClassLoader.

⚠ This API is proposed for removal from a future version of the JDK (JEP 411). If it's first deprecated in JDK 17, it will be quite a while yet before it's removed entirely, but eventually will come a time when we'll want the features of a new JDK and the Security Manager is no longer available.

Type Registry

  • The nui-reflect TypeRegistry uses lists of allowable classes and packages to guard against ⎵⎵⎵⎵⎵.
  • an o.t.persistence.typeHandling.TypeHandlerLibrary makes use of both a nui-reflect TypeRegistry and a gestalt ModuleEnvironment.

Related:

Threats not addressed

  • local denial of service attack (excessive CPU and RAM consumption)
  • exploiting local computing resources (crypto mining)
  • …?