Swagger Codegen Vulnerability Addressed

  June 29, 2016

On June 22 2016, a report was made public regarding a vulnerability in Swagger Codegen which enabled "Remote code execution via Swagger Parameter Injection". This particular issue allowed malicious and carefully crafted OpenAPI definitions to be used to create invalid and possibly harmful code through the Swagger Codegen project. The issue is not with the OpenAPI definition itself, rather the usage of the definition inside the Swagger Codegen project when generating certain clients and servers.

A fix from @sdavis-r7 was made in the swagger-codegen project and merged after testing by Swagger Codegen core contributor William Cheng (@wing328). A new release of Swagger Codegen is pending testing and additional tests and support for edge cases by the Swagger Codegen core team.

As with any vulnerability disclosure, it's important to act quickly and also explain both the severity and applicability to real world situations. In this case, the issue is that some very carefully crafted, malicious OpenAPI definitions _may_ trigger an issue in the code generation. Essentially some variable substitutions were unchecked, and depending on how a variable is used in the template, it could expose the issue.

In reality, this not only has an incredibly miniscule chance of ever being triggered, but it would be an extremely strange workflow to generate, say a PHP based server, then run it, unchanged, as ROOT without looking at the code. Why? Because regardless of how powerful the Swagger Codegen project is, it cannot write business logic for you, and there will almost always need to be some aspect of coding involved.

However, finding and addressing both common and uncommon issues is a very important part of the evolution of any project, open-source or not. So the reported vulnerability has been patched thanks to the Swagger community.

If you're looking for an example of how this vulnerability can be triggered, here you go:

Imagine you have an API with a `path` such as `/foo`:

paths:

/foo:

A generated client, in Java for example, would do something like this in the template:

String localVarPath = "";

Thus, the generated code, after substitution would become:

String localVarPath = "/foo";

So if you were a terrible person, and wanted to do something like this:

paths:

/foo\";System.out.println("have a nice day!");:

You could create a substitution like such:

String localVarPath = "/foo";System.out.println("have a nice day!");;

or more clearly:

String localVarPath = "/foo";

System.out.println("have a nice day!");;

Which can obviously create unwanted effects in your code. Note the ability to escape from the intended template logic _is_ as contrived as in the above example--you would need to intentionally want to break the template logic with your ill-crafted OpenAPI definition.

The solution is simple to this, and has been applied to the swagger-codegen project, which is undergoing final testing prior to release. The latest code can always be pulled from the `master` branch if you are concerned about this issue, or you can await a release announcement.

We always welcome issue identification and fixes in our Open Source projects!

https://github.com/swagger-api

Swagger Team