A word on Log4J
Some days before Christmas, a security problem was found in the widely used Java Library LOG4J. In short: If an attacker was able to bring an application to log a specific text content (an URL), it could lead to remote code execution. This is specifically a problem for all online services, which deal with a everyone around the world accessing them and a lot of services got emergency patches the next days.
Genesis uses Log4J too and up to version 7.0.3 is vulnerable. But unlike online services, it is not running around the clock and not remotely accessed – it logs activity while you use it. To exploit the Log4J vulnurability in Genesis, you must find a way to log an exploit URL – and this could only be achieved, by entering it in specific input fields while using Genesis.
In short: You would need to hack yourself!
Because of this, I am pretty relaxed about Log4J in Genesis. Yes, we just prepared a version 7.0.4 which updates the Log4J versions, but it is not due security concerns, but to avoid unnecessary trouble with security scanners that warn about Genesis being vulnurable (to self-hacking).
While we are at it
Some of you may have experienced warnings (Windows Defender, Smart Screen, etc.) during installation. This is likely because of three reasons:
- Genesis is not a signed application
A code signing certificate, which could be used to certify that the application is from me and that are responsible person for the software is known, costs several hundred dollar per year – or at least ~ $70 in a less secure version. I am not willing to invest that money in a “for free” application - The Genesis main application executes remote code
The Log4J vulnurability is about remote code execution and Genesis is basically doing that everytime you fire it up. As soon as the updater detects updated code for your RPG and loads it to execute it, you don’t know what you get. Of course, this is the intended behaviour. - Genesis is designed to be modular and extendable
I once envisioned that other developers would contribute plugins to Genesis and build it around the possibility to load third party code. While some developers started projects, but never finished, the possibility of code injection remains.
So, basically Genesis itself is rather open by design and there are easier (intended) ways to let it execute your code, than by using the Log4J vulnurability (which would require that you hack yourself). But since Genesis is a very uncommon application regarding to applications used by humankind, it is not likely that some attacker tries to manipulate Genesis – especially since it isn’t an 24/7 running application.