Slashdot Mirror
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.
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.
Not Ruby! Say it ain't so, Bertha!
This is what you get for using languages that convert *data* into *instructions*.
No, using Rust would not have prevented this. The vulnerability has nothing to do with memory safety or any of the safety features that Rust includes.
Insert additional puns here.
Never heard of it and not in use in major areas. Nothing to see here. Just overhyped.
Have you heard of von neumann architectures? Did you know that nearly every computer in use today is such a device?
I'd pay for a language that converts instructions into cash!
You should register here, you can be our unofficial anti-editor/humor columnist.
If they aren't taken, I submit these nicknakes as possibilities:
* Coward Anonymous
* leaNwobwoC
* IHateSlashDot
* LaughItsFunnyISaidLaughDammit
*CowboyNealIsMyBigBrother
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Shitty code is shitty.
News at 11.
I never heard of swagger until this post. Is Java alone vulnerable?
I understand you enjoy sucking dick, how much do you charge?
Congratulations to the Swagger team on achieving their impressive goal of officially codifying every RESTful anti-pattern ever invented, and let's wish them all the best in formally implementing every known security hole next.
Save this as a batch file and modify or re-write it for your environment.
Usage:
instructionstocash takes instructions from stdin and outouts the literal string "cash!" to stdout.
--cut here--
#!/bin/sh
#instuctionstocash
echo 'cash!'
--cut here--
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Damn typos. Finding and fixing typos is left as an exercise for the reader.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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.
Where is the real EditorDavid?
Do tell. (they killed him)
Microsoft is open-sourcing their stuff now too. Use Windows 7 and disable updates if you want to be safe.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
"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.
Yes and this is why we have massive security problems. Should have gone with Harvard architecture.
Why would a legitimate, on-topic question like that be modded down?
Because you post it every time?
Now I'm confused. Should we use Windows 7, or should we use hot grits?
Il n'y a pas de Planet B.
:)
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.
Sleep your way to a whiter smile...date a dentist!
na próxima vez que essa filha da puta ficar me perseguindo eu e minha namorada vamos tocar um saco de lixo cheio de merda de cachorro japonês na creche/puteiro que ela se esconde.
Systems are semantically coupled if they interoperate.
This is true, though it should be a one-way coupling. If A subscribes to B then A is coupled to B because it has to know about the data structures (resource representations) that B exposes. However, B should not know anything about A; if it does then one or both are implemented wrong, because it's precisely that two-way coupling that REST is designed to avoid.
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.
That's incorrect. Assuming B a correctly designed RESTful app, B provides public documentation of all the data structures (resource representations) it can understand, and which verbs can be applied to which resources. It doesn't say anything about how A should use that information, nor does it even tell A where to find it.
It's A's job to read the aforementioned documentation to understand how different types of resource interrelate, since one of the things each resource does is to describe the one-to-one and one-to-many relationships it has to other resources in the graph. So, for example, an Employee resource might include a 'manager' attribute that contains the URL to another Employee resource that represents that user's manager. Similarly, it might have a 'contacts' attribute that contains an array of URLs to Contact resources describing phone numbers, postal addresses, etc. Once A knows about these abstract relationships between different resource types, it can recursively GET each resource, extract the appropriate URL attribute, then GET that, and so on, in order to navigate from the application's root resource (/) to the resource it actually wants. (With benefit of hindsight, I think HTTP could've really done with a SEARCH verb for a lot of this navigation stuff, but there you go.)
So already, we've avoided the problem where if B decides to rearrange where particular resources are to be found, this rearrangement is not going to affect A because there's nothing hardcoded in A that relies on any resource being at a specific location. So B is not coupled to A there.
The only thing that is hardcoded in A is knowledge of how B's various resource representations are structured, so B does have to be more careful about screwing around with those, because backwards-incompatible changes to those will break A and rightly piss A off. However, this is where content negotiation comes in: because in a genuinely RESTful system there is absolutely no need to discard established resource representations in order to introduce newer and better ones: instead, you just publish the new representation under a new content type. Thus, if B originally published its Employee resource as a representation of type application/vnd.initrode.employee+xml, its new and improved representation can be published alongside the original as application/vnd.initrode.employee.v2+xml. A and any other existing client that understands the older representation can continue using it as long as they wish; there's no need for them to upgrade to use the v2 representation until/unless they want to access the additional information the newer format contains.
Of course, things can start to get a little sticky for A should B declare that from now on when adding new Employees, the POSTed employee information MUST include the additional fields not supported in the old format, in which case A is not going to be able to add new employees to B until it's updated as well. But that's the sort of change that shouldn't be happening too often in a mature production system, and even when it does happen there's no reason that A and other clients can't continue GETting the old employee representation for as long as they like.
So that's the B-to-A coupling problem all but totally avoided as well - as the only time it does come up is either due to special c
because its not on topic. you would know that if you were an programmer and read the blurb.
Been there, done that, got the scars to prove it.
I've found that compared to the tooling we were all using 15 years ago to build SOAP web services (fond memories of fighting incompatible implementations...), Swagger tooling is far worse, implements far fewer even obvious use cases, and is laden with bugs. In my recent work, Swagger Codegen was the worst I used. It is a flaming piece of shit which appears to be maintained by the same sort of teenagers with short attention spans that brought you crap like "left pad" on npm.
Even before the now-revealed security bugs, I found it was completely unfit for purpose. Attempting to generate Java server stubs, I could not get the piece of garbage to generate code that could COMPILE. It doesn't handle restriction by simple types, which is quite possibly the SIMPLEST thing you can do with a schema.
Angry that I wasted a day on this garbage. And apologies to anybody who worked on that code who might be reading this. I realise I might be looking a gift horse in the mouth -- but anybody who has the cheek to release such a piece of shit even as Free software and pass it off as a working piece of software ought to be fucking ashamed of themselves. It indicates a profound disrespect for the time and energy of potential users.
Specifically, Swagger Code Generator, which FWIW, is a bit crap to begin with.
Oh, right... Python.
(tap tap tap) import cash
People actually use this?
If you're going to use Swagger, might as well use SOAP.
So the vulnerability, is that people who put unknown code in their systems sometimes gets screwed?
Well, we better fix that then.
The OFA outlines this issue. What they are saying is that because the Swagger is a JSON document, if you use a code generator that simply regurgitates its values without validation, you could end up with code executing in the context of whatever is consuming the API. The issue is with code generators, and not the swagger documentation .
An example they give as an attack on HTML is the following (with angle brackets instead of square ones, obviously):
"info": { "description": "[script]alert(1)[/script]",
I guess the idea is that you have used Swagger code generator to create code to call the RESTful APIs you are interested in. The code generator includes this description (which seems kind of odd) in the generated code, giving you an alert when a page including this code is loaded. They also give an example of attacking the "paths" property (which includes information on what URLs can be used to call specific APIs) which would execute code on the back end. I could see this being more a legitimate problem.
A few things though before we all freak out:
Titles like ZDNet's "Severe Swagger vulnerability compromises NodeJS, PHP, Java" are gratuitous hyperbole. Slashdot's title is a little better because it at least refines the panic to "tools", but still not great. There is an issue here, but the internet is not going to go down in flames over this one.