Java AWT Whitelist

Isaac

New Member
Contributor
World
GUI
Terasology currently whitelists the entire java.awt package in ExternalApiWhitelist.java, which might lead to some modules posing a security risk.

Taking a look at the list of classes in the awt package here, these are the potentially unsafe classes in the package:
  • Robot - allows for the simulation of native keyboard and mouse input events
  • Desktop - allows the launching of associated applications registered on the desktop to handle a URI or file, such as the web browser, mail client and other registered applications
  • FileDialog - allows the module to display a dialog from which the user can select a file. This might be unsafe when combined with java.awt.Robot.
  • SystemTray - allows the module to manipulate (add and remove) tray icons from the system tray
  • KeyboardFocusManager - allows the module to manage active and focused windows, potentially allowing them to initiate changes in focus
  • PrintJob - allows the module to initiate and execute printing. This is probably not exactly 'unsafe' but I thought that I would just include it since it involves interaction with an external device.
  • AWTPermission - Permissions are defined in the policy file which modules should not have access to, but still a good thing to take note of.
The rest of the classes in the package are mostly related to graphics and UI elements and should be safe to be whitelisted.

Here is a list of awt classes currently in use by some of Terasology's larger modules (and their dependencies):

Josharias Survival:
java.awt.Color
java.awt.Image

Light and Shadow:
java.awt.Color
java.awt.Stroke
java.awt.Graphics2D
java.awt.BasicStroke

Gooey's Quests with CoreGameplay:
works fine without any awt classes

Medieval Cities:
works fine without any awt classes as well, although I did face a NPE which repeatedly occurs until I leave the game (even with the whole awt package enabled) - https://hastebin.com/ewoqidufej.swift

P.S. Also found this comment about exploitable Java methods if anyone is interested :) http://stackoverflow.com/a/4351516
 
Last edited:

smsunarto

Federal Gooey of Investigation
Art
Logistics
Related: https://github.com/MovingBlocks/Terasology/issues/2531

Some class that is used by other modules such as JoshariasSurvival, LightAndShadow, GooeysQuests, MedievalCities are:
  • java.awt.Image
  • java.awt.Stroke
  • java.awt.Color
  • java.awt.Graphics2D
  • java.awt.BasicStroke
So we need to make sure those classes are whitelisted so that those classes can function properly. There also seems nothing that can be exploited from those classes.

A class that caught my attention to being somewhat scary is java.awt.robot it can generate native system input (Type, Move Cursor) and also take a screen capture. I also cant think of any significant usage of it for Terasology. So I think we should blacklist this class.

java.awt.Desktop could also be somewhat harmful, but there would be some problems later if we actually block this class. Because then, Hyperlink UI won't be 'clickable' since we can't launch a web browser through the class. One solution to this is by whitelisting the usage of the class, but whenever it tries to open something, it requires a confirmation from the user. (Like what minecraft did to URL/HYPERLINK)

java.awt.PrintJob is another class that could be for malicious purposes. Although by malicious, as far as it can goes is a little prank that dries up your ink. This class basically prints. I can't see any future implementation of this in Terasology. So we can safely blacklist this class.

While we are at it, might want to check java.awt.Toolkit it seems to be just some connecting part of other classes, but some method queries to the system directly. (It can do also do a beep!) :D

There might be some other potentially harmful classes, I'll update this post if I found those other classes.
 
Last edited:

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Thanks! Added a link to this thread from the issue so we have the research available when somebody can get around to preparing a PR to take AWT off the whitelist.

Simply being off the whitelist is then blacklisted by default, so we don't need to go out of the way to suppress the killer Robots.

Rather than research deeper into what AWT could do I would try simply taking AWT off the game whitelist and see what crashes :D Ideally after readding the few safe classes we know for sure we need.
 
Top