I'm losing my Ruby and Rails faith here; what gives? This is just as bad as leaving SQL injection attacks open.
This is just as bad as leaving SQL injection attacks open.
No, it is much worse.
What The Rails Security Issue Means For Your Startup
91–100 of 183 posts
Re: What The Rails Security Issue Means For Your Startup
#92> The first reported compromise of a production system was in an industry which hit the trifecta of amateurs-at-the-helm, seedy-industry-by-nature, and under-constant-attack. It is imperative that you understand that all Rails applications will eventually be targeted by this and similar attacks, and any vulnerable applications will be owned, regardless of absence of these risk factors.
Who was the first reported compromise of a production system?
Re: What The Rails Security Issue Means For Your Startup
#93All the RubyGems stuff is happening at a high rate and I understand that over 90% of the Gems are now verified and it looks like nothing was backdoored but I couldn't find a good summary of the current situation so I have a couple of questions. 1) Is it currently safe to "bundle update" and be confident that only verified Gems will be provided? I don't mind errors on any unverified ones but don't want to download the…
Pretty good breakdown going on here [1]. To be honest, while the chosen tool to provide the update is odd, it is one of the best post-mordems that I've seen and applaud the volunteers for taking it so seriously. 1. I wouldn't say so. Not until they're all the way through. 2. Not at the moment, but general guidance is that we should all have local gem repos that we maintain ourselves and only rely on external sources…
It is extensive and up to date but it is lacking a brief status of the current situation and whether the site is safe to download from. The answer is currently "no", 90% safe is unsafe.
It's a shame that they seem to have put the service back up in an unsafe mode, I would have hoped that they could have quarantined the unverified Gems.
Edit: Looking at the status page the API is down so it can't be accessed from Bundler so they are doing it the good/safe way.
Re: What The Rails Security Issue Means For Your Startup
#94This quote caught my attention: There are many developers who are not presently active on a Ruby on Rails project who nonetheless have a vulnerable Rails application running on localhost:3000. If they do, eventually, their local machine will be compromised. (Any page on the Internet which serves Javascript can, currently, root your Macbook if it is running an out-of-date Rails on it. No, it does not matter that the I…
Other than ease of setup, I've never understood why you wouldn't develop in the same environment as what you're running in production. Setting up a vm is trivial and allows you to easily open/close access to your application as needed. There is also a lot less headaches once you've decided to move it into production.
I don't think this would be any more secure if you were to enable networking on the VM to allow requests from the host machine, which seems like common behavior so that the developer can access the webapp running on the VM from a browser on the host. Or are people developing inside a VM and then testing with a browser on the VM?
Re: What The Rails Security Issue Means For Your Startup
#95"Any page on the Internet which serves Javascript can, currently, root your Macbook if it is running an out-of-date Rails on it." Why are you running Rails as the root user? This is a bad idea. EDIT: I'm not really into client-side JavaScript these days, but when did browsers start allowing JavaScript to connect to anything except the server from which it came? That would be yet another Bad Idea.
Getting from local user access to root access on an interactively-used Mac is almost trivial. Inject something into the user's bashrc/zshrc that watches their commands and waits for them to successfully use sudo. Then run sudo again immediately and do arbitrary things as root.
There are several tricks that can be used by JavaScript to connect to non-origin servers, in limited ways.
To create a GET, inject an , , , or tag. (Or several others.)
To create a POST, inject a tag, and call form.submit()
Re: What The Rails Security Issue Means For Your Startup
#96Earlier quoted context omitted.
"Yes, everybody has bugs, but most people's bugs aren't an intentional feature that a trained monkey ought to have known was a bad idea." First, given how many times I've seen a deserialization library "helpfully" allow you to deserialize into arbitrary objects in a language that is sufficiently dynamic to turn this into arbitrary code execution, evidence suggests this is not an accurate summary. I'd like to see "Don…
> I'd like to see "Don't deserialize into arbitrary objects" become General Programming Wisdom, but it is not there yet. I think that's pifflesnort's point.
No, his point is that it already is and we can declare anybody who doesn't know to be worse than a "trained monkey". I say the evidence clearly shows that it is not widespread knowledge (IMHO "trained monkey" makes it sound like you could ask a normal college sophomore about this and get the correct response, which is just false, a lot of programmers don't even know what the term "serialization" means), and while it is a great goal we can not act as if it is already true.
Re: What The Rails Security Issue Means For Your Startup
#97This quote caught my attention: There are many developers who are not presently active on a Ruby on Rails project who nonetheless have a vulnerable Rails application running on localhost:3000. If they do, eventually, their local machine will be compromised. (Any page on the Internet which serves Javascript can, currently, root your Macbook if it is running an out-of-date Rails on it. No, it does not matter that the I…
Yep. localhost:3000 is only the most obvious guess you could make, too. You could try redmine:3000 and see who that worked on, or 192.168.[enumerate all IPs], or the top 1,000 host names, or use a Javascript port scanner, or... yeah, lots of bad stuff. (I thought getting into that rabbit hole would make a long and convoluted post even longer. Suffice it to say the world is a grimmer and more dangerous place than we t…
The metasploit folks put a pen-tester's guide to finding Rails-running targets on their own blog here:
https://community.rapid7.com/community/metasploit/blog/2013/...
In addition to common port numbers and stuff like redmine, their tipoffs include looking for Rails-style session cookies, and HTTP response headers emitted by Rails or support machinery. These include "X-Rack-Cache:" and the "X-Powered-By:" header that Phusion Passenger tosses in even if you've configured Apache itself to leave version numbers and component identifiers out of the response. (I'm not sure there's any better way to suppress this stuff than adding mod_headers to the Apache config and using "Header unset")
Re: What The Rails Security Issue Means For Your Startup
#98You do all deploy from your own cache of all the gems you depend on, right? No? Why not?
I'd love to. Any helpful guides on how to proceed?
I just wrote a blog post: http://words.steveklabnik.com/how-to-not-rely-on-rubygemsorg...
Re: What The Rails Security Issue Means For Your Startup
#99Is there no hardened version of Psych which lets you either disable object deserialization, or whitelist classes? That would seem like the safest option right now to guard against coming vulnerabilities in Rails in this regard.
This is currently being discussed on https://github.com/tenderlove/psych/issues/119
There is also https://github.com/dtao/safe_yaml (hat tip @patio11, who also points out that this has not been audited for completeness/correctness)
Re: What The Rails Security Issue Means For Your Startup
#100"Any page on the Internet which serves Javascript can, currently, root your Macbook if it is running an out-of-date Rails on it." Why are you running Rails as the root user? This is a bad idea. EDIT: I'm not really into client-side JavaScript these days, but when did browsers start allowing JavaScript to connect to anything except the server from which it came? That would be yet another Bad Idea.
You have bad assumptions. It is all about leveraging access to higher and higher levels.
1. You load the evil JavaScript.
2. That JavaScript adds an image with a URL pointing at localhost:3000.
3. When you load that URL, it causes code execution, causing your computer to open a connection somewhere and start taking instructions.
4. The instructions that arrive includes downloading and installing software that takes advantage of known local root vulnerabilities in OS X.
5. Congratulations! Someone rooted your machine!
Nothing in this path required Rails to be run as root, or JavaScript to directly connect anywhere.