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)?
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?
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.
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.
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
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?
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.
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]
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.
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