The short version: If you’re running the Swift web framework Kitura, update to the latest version as soon as possible. The fixed versions are 2.3.2 and, from older branches, 2.2.3, 2.1.5, 2.0.4 and 1.7.11. They were released on May 21 and May 22. If you run an older version, anybody can read all files that the server process can access, over the network and without authentication. This can leak credentials, the machine code of your server, and everything else that might be found on your production servers. The issue reaches a CVSS v3.0 severity rating of 7.5 (High).

And now for the long version… A while back, when I was trying out frameworks for server-side Swift apps, I did a test run with the Kitura framework, built primarily by the Swift team at IBM. While experimenting with it, I got suspicious when I saw a path along the lines of /@@Kitura-router@@/path/to/file.png in the URL of some assets of the default website. Seeing a path in an URL that corresponds to a path in the filesystem can be a sign of a path traversal vulnerability where a client can not only request files inside a designated directory of the server but also outside of it, often by just inserting one or more ../ into the path to go up one or multiple directories. There’s more on this issue in the OWASP wiki: Path Traversal.

Proof of concept: Just run an arbitrary Kitura project with a vulnerable version of Kitura and copy the following command into a terminal:

curl --path-as-is
'http://localhost:8080/@@Kitura-router@@/../../../../../../../../../../etc/passwd'

You might need to vary the number of ../ elements because it depends on how deeply nested your project is inside your filesystem. When you finally succeed, the contents of /etc/passwd should be printed. The --path-as-is option is necessary to prevent curl from normalizing the path, which would ruin the exploit.

On Linux, it might also be instructive to explore the /proc/self/ hierarchy. Here, you can find the list of environment variables in /proc/self/environ. When deploying on Heroku, for example, database credentials are passed into the server instance via environment variables, so that full access to the database would be granted by this means. Another relevant pseudo-file is /proc/self/exe which returns the binary of the server process, revealing its machine code to the attacker. I think that these vectors underline the severity of the issue and the need to patch your servers quickly.

I reported my findings to IBM’s Product Security Incident Response Team (PSIRT) on April 19th, along with proof of concept code. I received a mostly generic answer within a few hours, telling me that they would investigate my information and that by sending my email, I had granted IBM an irrevocable and quite comprehensive intellectual property license to everything I sent them – strange (and most probably not enforcible in sane jurisdictions). And then, there was silence. After about two weeks, I noticed a fresh commit on Kitura’s GitHub repository that fixes the issue. However, no release including the fix had been published yet, so that most users would still be vulnerable. A month after my initial email, I sent a follow-up to IBM, asking about the progress of releasing the fix. They replied with a note that the PSIRT doesn’t handle Kitura issues because Kitura is not an IBM product. Within 48 hours of my email, however, things got rolling and the fixed versions listed above were released, which is what I aimed for in the first place, so no hard feelings towards IBM. The only thing I’m not happy with is that there’s still no announcement of these security-critical releases, at least none that I noticed.

So, to repeat: Please upgrade to the latest version of Kitura (2.3.2 or newer, or another patched version as listed at the top) to secure your web app.