Scriptorama.nl

Het populaire Ruby On Rails heeft een kritieke bug in haar framework, zo ernstig dat de RoR core developers niet willen prijsgeven wat de bug precies is.

This is a MANDATORY upgrade for anyone not running on a very recent edge (which isn’t affected by this). If you have a public Rails site, you MUST upgrade to Rails 1.1.5. The security issue is severe and you do not want to be caught unpatched. The issue is in fact of such a criticality that we’re not going to dig into the specifics. No need to arm would-be assalients.

Er is een officiele statement waarin wordt geadviseerd om zo snel mogelijk te updaten naar 1.1.6. Alle releases 1.0 en onder zijn niet kwetsbaar, de volgende releases wel: 1.1.0, 1.1.1, 1.1.2 en 1.1.4. Wij zijn natuurlijk geinteresseerd wat de kritieke bug precies inhoudt.

Bug onderzoeken

Een simpele manier om dit te onderzoeken is de verschillen vinden in code tussen releases 1.1.4 en 1.1.5 (1.1.6 bevat enkele patches voor backport problemen). Een manier is met een diff utitilty, diff -r op een *nix bak is voldoende. Gelukkig hebben anderen dat al voor ons gedaan, zoals hier en hier te lezen valt.

Het blijkt dat het simpel is om de bug te triggeren door een HTTP header te manipuleren, waardoor je de mogelijkheid krijgt om willekeure code uit te voeren.

It looks like, for example, that if your Rails installation is in /www/rails/, passing a string such as /www/rails/../../tmp/ would pass the old validation, and if you had managed to upload a file such as hax_controller.rb to /tmp/, a route request to /hax/ would force Rails to run your arbitrary code. Apparently, the browser-submittable header field $HTTP_LOAD_PATH would get rewritten to $LOAD_PATH during certain requests, so if you could predict the landing-place of an uploaded .rb file, you could compromise the system.

Kritiek Ruby On Rails

Ruby On Rails is een open source project en daarbij komt dus automatisch een full disclosure policy.

Full disclosure policy houdt in dat alle gegevens omtrend updates en patches publiekelijk besproken worden. Iedereen kan immers de bron code lezen, dan hoor je ook alles te bespreken.

Dit keer hebben de Ruby On Rails core developers besloten om niet de bug te bespreken. In hun optiek is het beter iedereen de kans te geven om zo snel mogelijk te updaten en naderhand de bug uitvoerig te bespreken.

Once ample time for upgrading has been given and we have investigated this matter to its depth, we’ll release a complete report detailing all our findings.

Op het Ruby forum en bij het commentaar bij de officiele statement wordt kritiek geuit op het beleid. RoR zou niet klaar zijn voor enterprise gebruik als er zo wordt omgegaan met kritieke bugs. Hoe denken jullie erover?