Answer: It’s absolutely trivial to detect Rails applications in a scalable fashion, but why bother? Fire four HTTP requests at every server on the Internet: if the server is added to your botnet, it was running a vulnerable version of Ruby on Rails.)I have a few servers with hardly any traffic, and you can see lots of "hack attempts" trying to access goofy URLs and such.
localhost:3000
is only one predictable pathDelmoi: allowing auto-update is just as much a security hole as any other vulnerability. The central distribution point doesn't have to get hacked if it's being run by skeevy outfits to begin with.If the distribution center is skeevy, then you're fucked as soon as you run any code from them at all.
Can you trust Microsoft or Amazon not to use the auto-update hole to inflict stuff you don't want on youYes? I run auto-updates from Microsoft on my windows laptop. I have manual install setup for my desktop but I pretty much install all of the security updates.
Like rubygems.org was this past week?Yup, like that. And that is the main problem with this. I would say that not only should you trust that people are not going to hack you yourself, but also that they're not idiots and are capable of securely running an update site. Mainly they should be cryptographically signing all their updates, on a secure computer not connected to the internet...
Worse, because the gems themselves have no cryptographic signature to ensure integrity and authenticity, it's basically impossible to establish that any version of a gem has not been tampered with, short of a full audit of every version of every gem available.Okay, wow that's pretty stunning. I didn't pay all that much attention to RoR but it's always given off a douchey, amateur-hour vibe. Still that's pretty amazing.
Oh yes. Rails, you see, is omakase.Wow. Yeah. That's pretty douchey. I mean, it's not a bad idea to standardize on certain design patterns but wow is that a douchey, full-of-yourself way to express that. And given the fact their "amazing chefs" just served up a dish of remote code execution for all their users it certainly makes them look pretty ridiculous for writing about how brilliant their choices are.
This is a tangent, but DHH alone is the one reason that I disregarded most things Ruby and everything Rails for years. That guy needs to stop talking in public.Apparently the language is pretty interesting, although I'm not sure if it's any better then python as a scripting language. Kind of sucks for Ruby that it's so closely associated with Rails. On the other it seems pretty similar to Python, which doesn't have any of the negative associations with Rails
Do we *have* to go running to the National Security State to end up providing secure systems? Because I'd really rather not. At the same time, we do have so many small cracks in the infrastructure, that I suppose, it's only a matter of time until *something* happens.I do think for the "average user", even for people running small websites, simply having auto-update be the default, along with decent security for the modules (i.e. digital signatures, keeping the private key offline, etc) would prevent a lot of this stuff.
I know Metafilter has a strong IT contingent, and I'm definitely picking up on how serious this is for software creators and internet services providers. Can someone with the smarts tell the rest of us unwashed masses (i.e. "internet = a place to look at cat pictures" type people) what we should be doing to protect ourselves? It would be greatly appreciated. (Can I offer you a cat picture in return?),This is a thing that's going to let people hack websites. If you're not running a website, using Ruby on Rails, it's not going to be a problem, so long as you always use different passwords on every site.
eval
function is potentially vulnerable to similar attacks. However, I think seeing this as partly a side effect of the Ruby culture of informal hacker-friendly dynamism is correct. The code-is-data paradigm that Lisp enables is only partly from eval
— the other part comes from macros, but since macro expansion is almost always a "compile time" operation, they aren't a security risk in most cases. Plus, my impression of the Lisp community is that they're more disciplined about this kind of thing, and using eval
without a good reason is frowned upon: for example.eval()
in any language is avoided at all costs, and is meticulously scrutinized in cases where it's unavoidable. Why didn't YAML.load()
get the same level of attention?.load()
and .dangerous_load()
methods seems to make a lot of sense, if we think that it's even a good idea for YAML to ever be allowed to parse completely arbitrary objects.That's not to say PHP doesn't have its share of problems. (Uhh... which parameter was the needle and which one was the haystack again?)In twelve years of PHP, I have never used
in_array()
without having to look it up.« Older "The announcement was an honest look at the World... | Going Clear Blocked By UK Libel Laws Newer »
This thread has been archived and is closed to new comments
posted by grubby at 6:18 PM on February 1, 2013 [1 favorite]