Java, PHP, NodeJS, and Ruby Tools Compromised By Severe Swagger Vulnerability (threatpost.com)

"Researchers have discovered a vulnerability within the Swagger specification which may place tools based on NodeJS, PHP, Ruby, and Java at risk of exploit," warns ZDNet's blog Zero Day, adding "the severe flaw allows attackers to remotely execute code." Slashdot reader msm1267 writes: A serious parameter injection vulnerability exists in the Swagger Code Generator that could allow an attacker to embed executable code in a Swagger JSON file. The flaw affects NodeJS, Ruby, PHP, Java and likely other programming languages. Researchers at Rapid7 who found the flaw disclosed details...as well as a Metasploit module and a proposed patch for the specification. The matter was privately disclosed in April, but Rapid7 said it never heard a response from Swagger's maintainers.

Swagger produces and consumes RESTful web services APIs; Swagger docs can be consumed to automatically generate client-server code. As of January 1, the Swagger specification was donated to the Open API Initiative and became the foundation for the OpenAPI Specification. The vulnerability lies in the Swagger Code Generator, and specifically in that parsers for Swagger documents (written in JSON) don't properly sanitize input. Therefore, an attacker can abuse a developer's trust in Swagger to include executable code that will run once it's in the development environment.

Comments

Re:That's what you get for using OSS

[NotInHere]

Have you heard of von neumann architectures? Did you know that nearly every computer in use today is such a device?

was it intended to be secure?

[ooloorie]

I hadn't see Swagger before, but it looks like a nicer design than previous web service description languages.

The "vulnerability" related to Swagger in some tools that the REST API specification (in Swagger format) into a library that talks to that API. Specifically, malicious specifications can inject code into the library. I don't think this is a major problem in practice. These translation tools are invoked by people who want to write clients for specific services; usually, that means that you know the service provider and understand your trust relationship. In addition, this is not a fully automatic process, since you'll be programming against the library that the tool generates anyway.

Keep in mind that the alternative to a REST specification that the service provider gives you a bunch of REST client libraries, and it's far easier to hide malicious code in those client libraries than in a REST specification.

I don't think it's fair to call this a significant "vulnerability", although it might still be nice if Swagger tools detected these cases and alerted the developer to it.

Re:was it intended to be secure?

[cjonslashdot]

Swagger is nice but it is a workaround for what is really a mess: REST. HTTP was not intended to be used an an application level API, nor were XML or JSON. These are all bastard approaches. Compare these with the elegance of remote procedure call approaches such as CORBA and gRPC, where one specifies a method interface just like in a normal computer language, and the marshalling and unmarshalling code is generated by a compiler. The compiler is then the subject of rigorous validation based on the language spec, which leads to a much more robust toolset - a far better situation than someone's hack (i.e., tools like swagger). Also, an API specified in gRPC or CORBA's IDL that is one page will generally be 50 pages if specified as REST - even using Swagger - and the REST spec will have more ambiguity and complexity.

Re:was it intended to be secure?

[cjonslashdot]

Yes, that has been the argument. But it has proven to be a red herring. Systems are semantically coupled if they interoperate. The syntax of that coupling can either help to maintain consistency, or not. REST does not help: it is entirely up to the programmer to check everything and make sure though tons of testing that everything still works. In contract, a compiler based approach helps enormously. Real real way to decouple systems is to _logically_ decouple them, so that, e.g., backward compatibility is intentionally retained, and API methods are designed to be general purpose instead of special purpose - and those issues are independent of the syntax.

Re:was it intended to be secure?

[hey!]

Swagger is nice but it is a workaround for what is really a mess: REST. HTTP was not intended to be used an an application level API, nor were XML or JSON. These are all bastard approaches.

This is (a) a matter of opinion and (b) completely irrelevant to the bug in question, which is a problem with input sanitation which is a perennial source of security bugs recognized as far back as 1974 in the first edition of Elements of Programming Style.

Now as to the bastard-y of HTML as an API -- having actually read RFC 2616 myself and implemented some of it in raw TCP sockets for some very early mobile to server data connections, I beg to differ. REST is precisely what HTTP was designed to do. People who didn't read the RFCs simply went with what seemed simplest to them, which by in large was using GET and PUT interchangeably since they seemed to be just two ways of doing the same thing. That was very common practice in 2000 when Roy Fielding wrote his famous doctoral dissertation, the arguably most significant contribution of which is simply pointing out what had been the intended semantics of HTTP all along.

  Having tried my hand at SOAP and XML-RPC, I can also say why REST over JSON has been so successful: they make the programmer's job easier, which is what architecture is supposed to do.

"Architecture" has almost become a synonym for making things awkward and unnecessarily complicated, but what good architecture does is separate concerns so you don't have to deal with overwhelming amounts of detail at once. Of course good architecture has never stopped anyone from bolluxing themselves up and handing a steaming pile of logic turds over to someone else.

Re:was it intended to be secure?

[hhas]

Well I must misunderstand REST then!

Very likely. It's not about "APIs"; never has been. The web was original designed to be a vastly distributed document publishing system, where everyone could read and everyone could write. The first "web browser" was actually a WYSIWYG editor, kinda like Word except that instead of opening and saving documents on your local drive it opened and saved them across the internet. HTTP was the transport mechanism for that, and crucially it made no statements on what those documents were or how they were encoded; all it did was carry them between web server and web client. HTML was simply conceived as a new document format designed to be particularly well suited to the web, as established document formats back then were rather lacking in hyperlinking support; but there was nothing in the conception, design, or implementation of the web that said HTML was anything special or by any means the only document format that could be used.

So all the groundwork was done and all the pieces correctly in place to build a world-wide web as it was intended to be.

But TBL was lazy and impatient, and rather than making the time and effort port his entire "web browser" application from NeXT to Windows &co he just ported the read part only, because that was the simplest bit. Of course, back then there weren't any other apps (e.g. Word) that knew how to open and save documents across the web, so everyone who saw this read-only web browser in action naturally assumed that that was how the web was intended to work. Nobody piped up to say that actually, the other 80%'s still lying on a workbench in Cern waiting for Timmy to finish his tea, and Version 2.0 will be out Real Soon Now so wait for that before going too far, because if you think that 20%'s great then the full 100% will blow you away!

And then of course the likes of Netscape and Microsoft took this initial idea and codified and standardized and productized and turned it into a whole new "vision" of the web, a horribly crippled, gelded web where everyone could still read from it, but nobody could write directly to it; and the only people who could write to it at all were the tiny tech priesthood who knew how to manually transcode documents to HTML format, then stick them manually onto a web server by arcane backdoor FTP.

...

From that point forward, our entire World-Wide Web was officially Fucked Up Beyond All Recognition, with a constantly diminishing chance of ever being put right again before it could get worse. And then, of course, because nobody outside of TBL's original circle even realized - or was ever told - that the web was specifically designed to let you shift any kind of information from A to B (even automatically transcoding it if B told A it would prefer it in a specific format), it was only a matter of time till Ingeniously Clever And Inventive People like Dave Winer rolled in and decided what the web really needed now was a brilliant New Feature that would allow it to transmit data other than HTML - and hence gave birth to XML-RPC and SOAP and ultimately the ad-hoc RPC-over-HTTP-with-XML/JSON-encoded-parameters that is what today's so-called "REST APIs" are actually doing.

So now we have this utterly bizarre situation where ever web app has this schizophrenic split personality, where HTML-based information exchange is treated as this one huge special case over here, under /..., while information exchange conducted in any other format is conducted way over there, in /api/v2.1/..., each with a totally different data graph and verbs (or pseudo-verbs) for interacting with those graphs. And yet it's all the same bloody information! Refactoring 101 Fail, or What? There should just be one graph, one set of verbs (solely for getting and setting), and the only thing that ever changes is the MIME types that are attached to requests and responses (as Accept

REST and security are orthogonal concerns

[hhas]

"The fundamental problem with RPC is coupling. RPC clients become tightly coupled to service implementation in several ways and it becomes very hard to change service implementation without breaking clients"

Which is why RESTful HTTP isn't RPC, because we already know it's the wrong tool for this job. The fundamental problem is that today's web has an entire programming cult[ure] raised on OOP to the point where they're pathologically incapable of imagining any kind of interaction model except synchronous local message passing, so instead of bothering to RTFM until they understand correctly how REST works, the lazy toads simply reinterpret "REST" to mean what they already know. Which is 180 the opposite to what it actually is.

Actually, the best way to think about RESTful interactions is as a form of declarative programming, where you say how you want the state of a remote application to look, and then leave that application to figure out for itself how to transition into that state. That's why HTTP only has verbs for performing state changes; any other behaviors a RESTful application might manifest arise purely as side-effects to those state transitions.

But you try explaining this to a modern industry web developer, not only will they not believe you they won't even understand what words you just said. Dunning-Kruger wept.

Re:Would Rust have prevented this?

[davester666]

From my fairly basic reading of the issue, it is NOT a problem of ANY of the listed languages, but a problem with using/integrating the Swagger API in your web app using any language.