JMol is a library used to create 3D models of molecules in Java, which can be embedded into webpages using the usual applets. JSMol is a Javascript library which is used to provide the Jmol capabilities through the HTML5 technologies, relying on server side computation for some functionality.
Here’s a short story about how I discovered some pretty bad vulnerabilities in the JSMol software, and how it can affect every server which is hosting this software.
Using my university’s moodle installation, I discovered that the JMol/JSMol plugin for moodle was installed and probably misconfigured in some way: it had unusual permissions set in its directory tree.
This made me curious and I wanted to better understand what was going on.
I made some research, and discovered the plugin along with its source code (the project is entirely open source), and started to look at the source of the only PHP file in the JSMol package.
Looking through the code, I discovered a lot of parameters used without proper sanitizing and checks, and quickly discovered two related and pretty serious vulnerabilities.
The first one is a vulnerability which allows an attacker to read the entire filesystem with the PHP process’ privileges. The second is even worse, but it seems it had been fixed in the newer releases of the software, and was about arbitrary execution of commands on the server.
They derived from an insecure use of PHP’s file_get_contents() and exec() functions in combination with badly checked parameters coming from GET and POST variables.
I immediately contacted the developer of the plugin and reported the vulnerability, along with the curator of the JMol plugin of moodle.
As of today, the vulnerability has been fixed by the developer, and should be available in the latest version of the software.
Anyway, some research I’ve made suggests that the vulnerability was present in many websites using the plugin, which I thinks are unlikely to upgrade the software. In particular I analyzed every registered moodle installation from moodle.net (roughly 50k) and discovered that a small fraction (~100) had the plugin installed and was vulnerable.
I would not classify it as a widespread vulnerability, but I think this should remind us of the nature of websites’ security. In fact, I would say that every even small piece of software publicly accessible on a website should be cause of concern when thinking about security.
As is often said, the best thing to do about software security is to firmly believe that you don’t have any.