CVE-2019-5418 – File Content Disclosure on Rails | Hacker News Reader

CVE-2019-5418 – File Content Disclosure on Rails

github.com

133 pointskryptiskt37 comments

Open articleView on HN

This was fixed in 6.0.0.beta3, 5.2.2.1, 5.1.6.2, 5.0.7.2, 4.2.11.1 one week ago.

https://weblog.rubyonrails.org/2019/3/13/Rails-4-2-5-1-5-1-6...

The two HN posts didn't get many upvotes though: https://hn.algolia.com/?query=https:%2F%2Fweblog.rubyonrails...

Admittedly there is probably a lot of applications out there running outdated versions.

edit: Kind of surprising this gets upvoted while we rarely see things from exploit-db / fulldisclosure

I'm a bit confused here, perhaps because I don't really understand Rails (possibly also the HTML spec).

I was under the impression the 'Accept:' header is a list of media types, so why would that be making filesystem calls? Or does Rails implicitly organize assets in a filesystem structure (something like ~/assets/audio or ~/assets/text)?

The technical analysis (from the article), complete with a step by step trace walkthrough, is here:

https://chybeta.github.io/2019/03/16/Analysis-for%E3%80%90CV...

Also, if interested, direct link to patch fix:

https://github.com/rails/rails/commit/f4c70c2222180b8d9d924f...

Thanks for that, I was missing the step that assets are named $filename.$mime-type.erb in Rails. I was missing the high-level view

Because the media types are parsed and used to select layout templates (layout.html.erb vs layout.xml.erb, etc).

So why wouldn't we just have a mapping between mime-types and extensions for look ups? Why bother examining the accept header beyond splitting and searching within the list? Like in such a way that we're opening arbitrary files with it?

That's essentially what the patch does; the "symbol" call only resolves for known-good mime types.

Where would this code be in the rails code base? I usually don't touch ruby. I'm mildly curious what was there originally.

In the template resolver in ActionView. It's spread over multiple files and a bit hard to follow, which no doubt contributed to the problem.

Unfortunately a lot of rails internals are like this :(.

Aaaah Thankyou!

So it's a problem in ActionView, and fixed in 5.1.6.2...then why does the changelog for ActionView for 5.1.6.2 say "No changes"?

https://github.com/rails/rails/blob/5-1-stable/actionview/CH...

It's actually in ActionPack / Railties but I've raised the issue:

https://github.com/rails/rails/issues/35702

Great, thank you! Do most people just follow the blog instead of checking the changelog?

It's kind of all other the place but there is: blog, twitter, mailling list, github, brakeman, and all the little rails communities informing each others.

This is a really bad bug. Arbitrary file read on Rails applications can be pretty close to RCE. Worse still, it's present in all the mainstream versions of Rails, so it'll be lurking in commercial Rails applications for years to come. It's pretty amazing that the bug lasted as long as it did.

Good call, I went through the top results on Google and edited the answers/posted a comment to signal this vulnerability.

Also as others pointed out, this is a pretty rare use of `render` (but any application large enough might have it).

Notably, though, this only impacts calls which use the `file:` option on render calls, which in my experience is a relatively little-used feature. Not sure how many commercial Rails app this actually impacts in practice.

I'm not sure why people think this feature is so rare. It's like the Stack Overflow answer for "how do I render a static 404 page that doesn't go through Rails layout templating".

You have to do something wrong to have the bug --- render a file without specifying the format --- but you have to do something extra to avoid that mistake, and the feature works just fine if you don't, so I'm not surprised that we've found it in real applications.

Were I evil, I'd be looking at anyone who has upvoted or commented on such SO posts, and then looking at what companies they work for, and trying to run attacks against every site/repo/app they are linked to to see if they use this technique.

Or just, you know, looking in Github for anyone doing this and open sourcing their site.

It requires a specific usage of `render` that is extremely rare. I've never seen it in a real application.

All it requires is "render :file" without the optional format argument. We found it immediately in applications, and other people on our Slack found it in theirs as well (though not necessarily exploitable, situationally).

I'm aware of the trigger, `render file:` is, in my experience, extremely rare. I can't recall ever wanting to render a template file located outside the application directory.

Does the code fixing this feel a little too innocuous to other people? Reading the code it seems really unlikely I'd see this and realize that deleting it would create a severe security vulnerability:

    v = v.select do |format|
      format.symbol || format.ref == "*/*"
    end

https://github.com/rails/rails/blob/efb706daad0e2e1039c6abb4...

Ya, that's one reason I rewrite the commit message to add the CVE. Hopefully people will view the blame before changing.

I'm curious — is it not normal to add in-line explanatory comments in the Rails codebase?

I'm thinking if I were writing this code in an application, and it looked this cryptic, I might at least add a comment noting what it was for. Not that people shouldn't look in git. But inline is easier to notice, no?

Don't we have tests for this?

The tests are far from obvious too https://github.com/rails/rails/commit/f4c70c2222180b8d9d924f...

Why would you randomly remove code from ActionView? It's some of the least user-serviceable code in Rails.

We're working to improve it. It's actually why jhawthorn found this issue.

I put on my white hat, found a site that is probably still vulnerable with a bug bounty program, tried to run a modified query, only this time pointed at `/dev/random` and....

"Sorry, you have been blocked"

"This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data."

Apparently, Cloudflare's great at detecting threats. Bummer.

You could get the origin IP and bypass Cloudflare, there are many many ways to do this.

Thank you for the idea! But in general, it'd nice to be less mysterious when helping people ;) but you're right, there really are many ways to uncover the origin IP[0]

[0]: https://www.secjuice.com/finding-real-ips-of-origin-servers-...

They all depend on mistakes. Common ones, sure.

My thanks to the original reporter of the vulnerability, and to the Rails folks for fixing it.

I strongly recommend using at least one tool to help you know when a publicly known vulnerability is reported in a component you use. Then you can update, run your automated test, and immediately ship. Modern systems are typically mostly reused code. Being unprepared for vulnerabilities in them is a little crazy, because you know that such things will happen.

I was looking forward to reading the technical breakdown here:

https://chybeta.github.io/2019/03/16/Analysis-for%E3%80%90CV...

But I could not without my fans blasting and overheating my laptop. The page is using js to continuously render a moving background.

The background on https://chybeta.github.io/2019/03/16/Analysis-for%E3%80%90CV... is extremely distracting (especially on mobile).

Having things wandering across the screen draws the eye away from the content you are trying to read.

Reply on news.ycombinator.com