By Björn Ritzl on Oct 06, 2022
Tagged as: Security
Creating a game engine is not only about building cool features and fixing bugs. Sometimes there’s also a need to work on security related task, either in the engine or tools themselves or in the services provided. As an example we posted a new manual in our Learn section about application security. The goal of the article is to share our security principles and how developers should think about security when using game engines and services in general and also to share some concrete tips on how to improve application security specifically in Defold.
One of the things we brought up in this document was the security of the cloud build servers used when building native extensions and integrating them with the engine core. We wrote the following:
The cloud build servers are hosted with AWS and created according to security best practices. The Defold Foundation does however not guarantee that the cloud build servers will meet your requirements, be free from defects, virus free, secure or error free, or that your use of the servers will be uninterrupted or secure. You can read the fine print in our Terms and Conditions.
If the security and availability of the builds servers are of concern to you we recommend that you set up your own private build servers. Instructions on how to set up your own server can be found in the main readme file of the extender repository on GitHub.
The note above is important because while we always try to write code and design services according to security best practices we can not with absolute certainty say that the software and services we offer are free of problems. We were recently reminded of this fact when were made aware of a security vulnerability in our build servers.
The security vulnerability in the build servers was caused by unsafe use of SnakeYAML, a third-party library for YAML file parsing. The vulnerability was discovered by Eran Vaknin and Alon Boxiner, two independent security researchers, and reported to the Defold Foundation. The researchers found that it was possible to create an extension which would trigger SnakeYAML to perform class loading and instantiation of Java classes containing malicious code.
SnakeYAML is used by the build server to parse the extension manifest files uploaded together with the extension source code and other resurces. The build server uses the
Yaml.loadAs() method from SnakeYAML to load YAML files. When using this method on YAML files from untrusted sources it is recommended to use a
SafeConstructor() mechanism to control which classes that can be instantiated in order to lock down unsafe class instantiation. This was overlooked when implementing the functionality in the build server.
As soon as the vulnerability was reported we started working on log and service analysis in search of evidence that they had been compromised. Fortunately there was no evidence that this vulnerability had been abused at any time.
It is important to mention that no game code or content is uploaded during a native extension build. It is only extension source code, extension resources and the manifest files that are sent to the build server. If a build server had been compromised by the vulnerability it would still not have allowed an attacker to gain access to any game content, except the extensions used by the game.
Below is a timeline of events from vulnerability disclosure to patch being applied to all systems:
If you have found a security vulnerability in any of the software or services we provide we would greatly appreciate if you would let us know by emailing firstname.lastname@example.org.