Some people just can’t stop achieving! Not content with introducing breaking, backwards-incompatible changes into the Ruby 1.8 branch with 1.8.7, the Ruby Core team have shot for the moon, gone for gold, and doubled down all their bets - and made Ruby 1.8.6-p230 incompatible with Ruby 1.8.6-p(any other version). Of course, there is an URGENT!!!111ONE zero days exploit or something in any version of 1.8.6 that’s not the one released today - the incompatible one.
So let’s sum this up:
Ruby 1.9.0 = incompatible with Ruby 1.8.x
Ruby 1.8.7 = incompatible with Ruby 1.8.6
Ruby 1.8.6-p230 = incompatible with Ruby 1.8.6-p(<230)
Ruby 1.8.6-p(<230) = UR SERVER IZ OWNED LOL
Well that is just fucking great. Well, I guess if your app won't start, no one can hack it! Can't get more secure than that! Mission accomplished!
It seems like this Ruby Spec project is arriving not a fucking moment too soon. When the core team can’t even keep Ruby 1.8.6 compatible with, uh, Ruby 1.8.6, we got problems.
June 22nd, 2008 at 8:15 pm
Hmm, yes, well… Read about this latest p230 cherry on top a little earlier. And all I can say is: WTF?
As a certified “Ruby newbie” genuinely interested in some insight, is it likely that I have more of this japery to look forward to?
I’ve already pinned my Ruby Debian packages to 1.8.6 (I track Debian testing on my main dev lappy), now even that is potentially not enough and I need lock it down even further… Not that much of a hassle I suppose, it’s just more funny that one would need to entertain the idea. But not so much, “ha ha” funny, as Gary Busy funny (which is pretty “ha ha” funny anyway, but with slightly disturbing overtones… I’m getting off track now).
Should I just pack my bags and high tail it back to PHP-ville right now (this question is rhetorical)?
But seriously, I know it’s not just Ruby that has these kind of things happening from time to time. As long as it’s generally not any more often than other projects, then that’s cool I guess.
Though is it just me, or is there a little more noticeable hysteria in the intertubes when this stuff hits Ruby as opposed to some other languages?
June 23rd, 2008 at 12:17 am
Jonny-さん,
“WTF” is a pretty appropriate response. I think if these “japes” become too common then you won’t be the only person wondering what the point is and heading back to $MORE_RELIABLE_LANGUAGE.
I do think that perhaps a disproportionate amount of noise is being made about this; perhaps everyone is just used to vulnerabilities being found in PHP et al, and Ruby is still kind of the flavour of the month. And having had a shallow look at the problems found, I can’t see why it’s all that urgent anyway, hence the sarcasm in my post.
The main problems seem to be overflows in strings and array processing, but any decent program will be suspicious of user input and be treating it with kid gloves anyway. It looks to me like you would have to be directly accepting and manipulating data of those types from the user. Any developer with any sort of clue will not be doing this and certainly Rails does not encourage that sort of thing. It is actually pretty difficult for me, at least, to see how any exploit could work on a decently set up system.
Your typical Ruby app is also a pretty far cry from PHP; most Ruby apps are deployed using a secondary app server (eg Mongrel) which is attached somehow to the primary web server (eg Apache). Even if you did succeed in crashing Mongrel and putting it into a vulnerable state you still have to go through Apache; there is no direct access. So it’s pretty hard to imagine how even if you succeeded in exploiting the problem somehow that you’d have anything other than a one-off shot at getting anything done. Or another possible vector of attack could be in handing the app malformed requests for files; again, you would have to have a pretty badly broken app in the first place to be accepting filenames without any checking at all.
Anyway, let’s see, I haven’t seen anything really interesting yet but maybe something will come up. Personally I am waiting for either a known-good update with NO problems, or a feasible proof of concept exploit before moving. If you look at Zed Shaw’s walkthrough of the changes you’ll see he pays special attention to the changes in Eval and Class, and speculates that is where the real problems are, since the others mentioned above seem to be pretty weak and non-urgent. It’s possible the real vulnerability has not yet been announced.
The thing about the upgrade incompatibility though is completely different and totally unacceptable. I hope we can write that off to “growing pains” and that it won’t happen again. If it becomes a regular occurrence then like I said you won’t be the only person jumping ship.
June 23rd, 2008 at 11:16 am
Yeah, I did take a look at that page from Zed Shaw, read through it and tried to absorb what I could, it was amusingly inflammatory as usual, though I don’t think he’ll ever be able to top that original “coming out” rant he did.
However, I’ve never really done any lower level C type stuff, so while I get the overall gist of it (and were I so inclined to put the time in to really follow along with him, I could probably get a bit more out of it), much of the detail may as well be in swahili to me.
But I agree with what you seem to allude to, which is that I am actually more annoyed about the upgrade incompatibility than I am about these security issues. Chain of events for me was kind of like:
a) Ah, Ruby 1.9 is coming out some time… But I’ll be OK I just have to sit on my 1.8 packages, surely they won’t introduce any incompatibilities before 1.9, don’t even need to pin anything. Sweet.
b) Ah, Ruby 1.8.7 has incompatibility issues, bit weird, no matter, I’ll just pin my packages to 1.8.6, surely then I’ll be fine. What else would I possibly need to do?
c) Ah, 1.8.6 has incompatibility issues with its self?? OMG!!!11 WTF??!1! ARE THEY FUCKING SERIOUS!?
But I think that the “growing pains” thing is a fair point also, I mean it’s not even up to version 2 yet.
Ruby, the Gary Busy of scripting languages.
June 23rd, 2008 at 11:58 am
Programming Skill, or lack of
Ha, don’t worry, I’m not a “real programmer” either. For me programming is a means to an end - I want X to exist, no-one else is gonna do it, so I have to. My real passion is music!
Buffer Overflows
That said, you don’t really need to be a real programmer, or even be able to read the C, to understand what’s going on. The buffer overflow problems are to do with how Ruby manages memory - it hadn’t set proper limits on where the memory for an array or a string was allocated, and there was the possibility that a malformed array or string could “overflow” where Ruby thought the memory for those objects was going to be, and thus either crash it or, worse, write new stuff in, presumably malicious. Ruby wouldn’t have any way of telling that this new stuff wasn’t just the nice program it read from disk and would happily execute whatever was there - Zed speculated that, for example, a well-crafted malformed array could possibly inject a new method into a class, for example.
Ruby vulnerabilities
That sounds suitably scary until you remember that all input to a web application is via a web server, then mongrel/whatever. It seems like it would actually be pretty freaking difficult to somehow pass this malicious array in from HTTP so it was being evaluated directly inside Ruby. Sure, fix the problems, that’s great, but it doesn’t sound like a “drop everything and update now now NOW” vulnerability to me - unless there’s something we’re not being told. Judging by the tone of the Ruby-lang and Riding Rails announcements, that actually seems quite likely - Ruby-Security is a private list, who knows what was actually disclosed to them. All will be revealed, no doubt.
Anyway, like I said I’m hardly an expert on this kind of thing. I have very little inclination to dive in and sort through it myself, especially when we have showoffs like Zed to do it for us! Just kidding, Zed’s a nice guy (and he always follows trackbacks - hi!).
Ruby Versioning Is Completely Fucked Up
Your reactions to the 1.9/1.8.7/1.8.6-230 SNAFU are basically identical to mine. I have no idea what the Ruby guys are thinking with these version numbers.
They want to make a lot of changes, leading in to 2.0. Well, that’s fine. Great! Major version numbers are just the place to make sweeping changes, cleaning up a lot of stuff, progressing wherever they want. That is exactly the right thing to do.
Hang on .. they want to, uh, declare 1.9 their kind of “work branch” for 2.0. Uh .. right. What was wrong with using, say, a 2.0 beta branch? But .. hm, ok, well, it’s still OK, I guess, to make reasonable changes in a minor version .. kind of. Kind of negates the whole point of having the major version number in the first place, unless it’s just counting up in .1 increments, but whatever, they’re in charge. Personally I would have thought that 1.9 should be 1.8 on YARV, but whatever, it’s their ball game.
But 1.8.7? Incompatibilities from backported features from 1.9 - which is itself a kind of “future backport” of 2.0? What the fuck? Why the fucking hell are they backporting shit from 1.9 into 1.8 when it is not completely compatible?! Do they even understand the point of these version numbers?!
Major version number: do whatever the hell you want!
Minor version number: well .. shouldn’t break stuff if you can help it but if you REALLY need to, OK .. kind of.
Tiny version number: for tweaks, fixes and optimisations only; ok to add (small) new features, should NOT break anything backwards
Patchlevel: absolutely should fucking not break anything backwards and to be perfectly honest should not even exist, and the fact that it does exist is a sign of bad release practises
They should not have made major (read: incompatible) changes in 1.8.7. They absolutely should NOT under any fucking circumstances have made incompatible changes in 1.8.6-p230!! What the hell is going on?
The Ruby team need to basically shift all their versioning one decimal point to the left. They are putting shit in patchlevel which should be in tiny - and there are WAY too many patchlevels. They should wait a bit and then roll up changes from trunk every few months, only levelling up when they’ve got something important or urgent. As it stands they’ve been going through one every few days, it’s ridiculous. May as well just use the checkin number. They are making changes in tiny which should be in minor. And for 1.9 they are using minor when they should be in major. Why the hell are they acting like this? It’s not like new numbers cost anything?!
As much as it pains me to say it, Ruby could learn from Rails here. Ditch the fucking patchlevel bullshit. 1.8.6 should equal 1.8.6, no questions asked, no possibility for difference, no fucking patchlevels or anything else. If you need a new version, 1.8.7, which is always backwards compatible. *Never* break backwards compatibility in a minor branch. And if you need more than 10 tiny versions in a minor branch, then just keep going - if 10.4.11 is good enough for Apple 1.8.11 is good enough for Ruby.
This security update should be 1.8.7. And what about the current 1.8.7? It should not even exist! What is the purpose of 1.8.7? To get us ready for 1.9? NO! 1.8.7 should be a straight progression, bugfixes and security updates for 1.8.6! The current 1.8.7 should be 1.9, which is getting us ready for 2.0!
The other day, I needed to install 1.8.6 on a new server. I installed the latest version of 1.8.6 from Ruby-lang, which was patchlevel 114. They have skipped over a hundred patchlevels in the last couple of days and now insist 230 is the minimum. Hint: if over a hundred of these patchlevels were not important enough to be bundled into the downloadable tarball, maybe they should not be patchlevels at all. Go look at http://ftp.ruby-lang.org. Look at their tarballs in 1.8 branch. There is *no* tarball between 114 and 230. So, uh, why isn’t p114 called 1.8.7 and p230 called 1.8.8?? Or 1.8.9, or whatever?
Sorry for the rant, I should turn this into a proper post. I don’t think enough people are criticising this aspect of Ruby, their versioning is completely insane.
Looking at the Riding Rails blog article the number of people experiencing show-stopper problems with 1.8.6-p230 keeps growing. RSpec segfaults, huh? Well that’s fucking great, I use RSpec intensively. I’m scared to upgrade to a new patchlevel of the same fucking version, and that should NEVER happen.
I’ll be watching this pretty closely over the next few days. The yanks are still mostly off on weekend, so only the very keen types have been paying attention. They’ll get back to work later tonight and might start having problems en masse so I expect it to start hotting up in the next 24 hours or so.
June 23rd, 2008 at 12:42 pm
So you’re a musician hey? Me too. I used to play bass in a band for a few years. Sadly haven’t had much time for music these last few years. I try and keep in practice when I can though.
Thanks for the round up. I have done a little reading on buffer overflows and stuff in the past, again from the POV of a non C programmer, so I get the idea of how the lower level languages are a lot more manual in terms of memory allocation etc. and the general overall idea. But I think it will be a long time (if ever) before I can peruse a C source file, point at a line and say “There’s your problem!”, if you know what I mean.
I too will be watching developments closely.
June 23rd, 2008 at 12:45 pm
Lol. My response turned into a full-fledged page-length thousand-word rant!
Don’t you love blogs. I am going to make that rant about version numbers into a proper post since it’s what I sincerely believe!
June 23rd, 2008 at 11:48 pm
Well, there’s some more discussion here.
And I note a new patchlevel (231) is out already, although a user on the above page is still able to reproduce segfaults with what looks to be perfectly valid code. Also, the tarballs are still at 230 so to get 231 you’d have to check out using SVN - hardly the preferred way of doing things with a language install …
No idea if an actual working exploit has been disclosed yet.
June 24th, 2008 at 8:27 am
Hmm, so is Rails 2.1 compatible with Ruby 1.8.7 or no? I’ve read conflicting reports around the place.
June 24th, 2008 at 8:31 am
I believe Rails 2.1 is compatible with 1.8.7, the problem would probably be with any plugins you use. Mongrel is compatible though.
In testing I ran a couple of Rails 2.1 applications on a RHEL install (from source) of 1.8.7-1 without issue. I had to downgrade because of plugins, basically. Radiant, the CMS system, is a particular offender since it actually bundles 2.0.x Rails - not compatible.
June 24th, 2008 at 12:48 pm
Thanks.
Hmm, that’s interesting about Radiant, I have a Radiant powered site (first hands on RoR thing I ever did) on a shared hosting environment that last time I checked, had already moved to Ruby 1.8.7 and the site still seems to be working as far as I can tell.
Though it must be a pretty old version of Radiant, as I haven’t done anything with the site since some time last year. Could this be why the site hasn’t died when my hosting provider upgraded to 1.8.7?
June 25th, 2008 at 6:32 pm
I read the Zed Shaw article and thought, this is “analysis”? He basically pokes around the diffs and points at bits of code which might be problematic, but there is no real identification of problems (”that line is broken because”) nor explanation of how such problems might be exploited. It’s basically just hand-waving. I was frankly unimpressed.
At last the wraps are off the CVE’s and you can actually read about the exact nature of the vulnerabilities:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2662
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2663
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2725
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2726
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2664
Haven’t done so yet, but I am about to.
Am I worried about any of this? Not really. Red Hat will back port the relevant patches to the Ruby 1.8.5 installation that comes with RHEL 5.1 and I am certain that there will be no compatibility breakages.
Do I think this is an indication that Ruby is a joke and I should switch to Python? If this were to start happening regularly then it would be disappointing, but this is the first time this has happened since I’ve been using Ruby and I’m not worried yet.
June 25th, 2008 at 7:27 pm
Wincent:
Those CVEs go through the already mentioned nature of the defects - buffer overflows, etc. They say “network exploitable” with a severity rating of 10 (the maximum) but I am yet to see any actual exploit examples in a common Rails scenario.
The most obvious vector would be in malformed URLs with the long strings which can trigger overflows - but Mongrel supposedly has hardcoded limits on URL parameters, so one wonders how they could get past that. If the URL is unavailing the next obvious vector would be in a malformed POST. That seems the likely attack everyone’s concerned about, and maybe there’s no easy fix in Rails or Mongrel.
I agree with your assessment of the Zed Shaw article. It seemed to be first and foremost about how kewl Zed Shaw is, secondly to remind the world that he wrote Mongrel, then last and least a vague and inadequate account of thoughts he had about various lines in Ruby which have been updated. One wonders what the point was; I can look up the changelog myself if I want to look at the code; I don’t need a few copy-and-pastes accompanied by lengthy reminders of Zed’s brilliance. Well, whatever.
Anyway, I’ll update when I am satisfied there won’t be any problems. Your point about the RHEL5 update is a good example of what is good about using RH - there will indeed be no problems, although if the problems is as critical as all the hype implies, one would think they would have done it already…
June 25th, 2008 at 7:33 pm
Jonny:
Well, I have no explanation as to why your Radiant site is still fine but mine failed. I assure you, however, it did fail - my post from a couple of days ago about Rails sessions failing in 1.8.7 was because of that. I eventually got sick of hacking it to work and reverted to 1.8.6. Maybe your Radiant version is so old it avoids the Rails problems (they only moved to Rails fairly recently)?
You have restarted the Radiant app since upgrading, right?
June 26th, 2008 at 8:21 am
I believe you Sho.
I guess I’m just lucky. Just logged in to the site to take a poke around and see if anything actually is broken.
The site is running Radiant version 0.6.2 and appears to be functioning. I have not restarted it recently and could not say exactly when it was that my hosting provider upgraded to Ruby 1.8.7, only that I noticed they had done so some time in the last couple of weeks. Possibly, they may have even upgraded, pissed a whole bunch of people off when their Rails broke, and then downgraded again… I haven’t checked the Ruby version on the shared server more recently. I might do this tonight when I get home.
Hopefully, Debian will handle this Ruby issue as well as you guys expect RH to and I won’t have to pin stuff on my dev laptop too much.