Posts tagged yaml
As some of you are likely aware by now, Ruby On Rails posted a security advisory concerning critical remote code execution (RCE) vulnerabilities in its Action Pack for all versions of Rails since 2.0.
This vulnerability can likely be used in a wide variety of potential attacks so you should immediately update any Rails applications you are currently running. There’s a good analysis of the issue over on http://www.insinuator.net/2013/01/rails-yaml/ and it raises the very real risk that the global nature of this vulnerability may make automated attacks or worms feasible. A concrete POC has not been released to give folk more time to update their applications before attackers figure out how to take advantage of this.
Yes, but HOOEY! How does this relate to PHP, Paddy?!
Code execution vulnerabilities are, by definition, hideous monsters. The ability for external inputs to enter an execution context (i.e. injecting or manipulating code that is executed on the server) can be difficult to spot through the haze of convenience that such machinations are often designed to deliver. In Rail’s case, that convenience was to automatically cast data entries in XML or YAML inputs into Ruby types including, unfortunately, Symbols and Objects.
These types of “buried” code execution vulnerabilities are still easy to locate in PHP, at least, because you are still restricted to normal code execution pathways in the absence of Ruby’s dark magic, e.g. eval(), include(), require_once(), system() and, let’s not forget, unserialize(). Anyone can perform a mini-audit using grep searches just by checking for instances of these and similar functions and then identifying whether they are in unusual places or accepting variable inputs that could be exploited. For example, a few years back many applications were found to be unserializing user inputs which allowed for code execution attacks by manipulating parameters to __wakeup() and __destruct() method calls.
Rails is a battle hardened framework but all frameworks will suffer from unanticipated security vulnerabilities. You just won’t see them become as well publicised as Rails! It’s the nature of programming for programmers to err or fail to foresee unintended uses for their code. PHP applications and libraries are already suffering from any number of obviously pervasive ills including three security problems I called the Three Ugly Sisters in my recent article for December’s Web Advent series (SSL Peerjacking, XMl Injection and Cross-Site Scripting). We all have the capacity to do better on the security front.
No PHP project is immune to security vulnerabilities simply because of its size, user base, or funding. Even a good security audit is not immune to the blind spots of the reviewer, emerging security issues still flying under the radar and the continuing assault by researchers on practices and techniques we take for granted.
One part of being prepared for unexpected vulnerabilities is to find common ground with your competitors. Ruby on Rails is a web application framework. If you are a PHP framework developer and not monitoring Rails’ or Django’s security woes then it’s time to start. We can learn a lot because, despite the barrier of a different programming language, many security problems are universal. Frameworks in Ruby, PHP, Java and Python can all run afoul of very similar vulnerabilities. Using that knowledge can lead into avenues of investigation you did not previously consider. Within PHP itself, monitoring frameworks like Zend Framework and Symfony can reveal security advisories that, in all probability, are not unique to those frameworks.
As a case in point, the Rails vulnerability I opened this article with led me to wonder if something similar might be possible in a PHP framework. So, I took a look at Symfony 2′s YAML component. Johannes Schmitt apparently had the same thought! As it happens, there are two possible points in the YAML classes where code execution could potentially be manipulated by untrusted input. The component is generally used to parse local configuration files (so typical Symfony applications will not be vulnerable) but there is nothing to stop it from being used as a generic YAML parser for other use cases such as user submitted files or YAML output from a remote API. As always, Fabien promptly set the Elves in his North Pole hideout on red alert and has already released fresh versions of Symfony 2.0 and 2.1 to rectify these issues. You can read the official advisory at http://symfony.com/blog/security-release-symfony-2-0-22-and-2-1-7-released.
The code execution vulnerabilities in Symfony’s YAML component relied on calls to include() and unserialize(). One included a file as PHP and parsed its output as YAML (disabled by default since Symfony 2.1 but still enabled by default on Symfony 2.0 versions) and the other unserialised objects stored to a YAML scalar value (enabled by default in all versions). As I mentioned earlier, grep can be really helpful in locating these types of problems – so get cracking on the command line!
Pay attention to competing applications or frameworks – their problems may also be your problems. If you’re worried about arbitrary code execution vulnerabilities then audit your code. You can even, as a sanity check, use grep to find uses of functions like eval(), unserialize(), etc and analyse where their parameters’ might originate from. The answer “somewhere out there” or “how the heck am I supposed to know what crazy users will do” usually means it’s untrusted by definition. Keep in mind that code execution vulnerabilities can also appear in the form of arbitrary object instantiation, i.e. the constructor and destructors being executed for any object targeted even if there are no other method calls made. Manipulating code execution can be just as bad as arbitrary code execution.
- Analysis of Rails XML Parameter Parsing Vulnerability (insinuator.net)
- Extremely crtical Ruby on Rails bug threatens more than 200,000 sites (arstechnica.com)
After my previous blog entry about escaping the trap of being overworked to the point I was failing to maintain a respectable sense of responsibility for getting things done in my open source life, I’ve been going through all those open source projects and cutting the dead weight. It should pay dividends before the weekend with such achievements as completing development of PHPSpec_Context_Zend, PHPMock 0.1, and committing Zend_Service_Yadis before I start writing its belated unit tests.
One of the victims of this review has been Zend_Yaml. Earlier this morning I found an odd comment on the Zend_Translate_Yaml proposal by Thomas Weidner that he was erasing his proposal on the basis that there had been no progress on Zend_Yaml. Now enough is enough, so I read through the past comments and found Zend’s review. The review dated 2 January 2008 stated:
• Work with Padraic Brady to ensure that Zend_Translate_Yaml’s syntax will be supported by Zend_Yaml.
• If Padraic is unable to move Zend_Yaml forward, create Zend_Yaml with support for parsing the syntax subset necessary for Zend_Translate_Yaml; future development could then take care of any other portion of the syntax we wish to support.
To remove any similar confusion and perhaps stem the tide of emails over YAML, I have erased Zend_Yaml from the proposal page once and for all, and here’s why.
On the 15th November 2007, I received an email indicating that Zend_Yaml had been reviewed, and some concerns had been raised. Notably, the component required adherence to the YAML 1.1 specification and it was pointed out this would not perform well unless an extension existed supporting YAML 1.1. On this basis it was recommended the proposal await a future YAML 1.1 extension.
I replied that I agreed a full parser was no longer viable, esp. since in between the original proposal and it’s eventual review, the Syck extension for YAML had been accepted into PECL which was a huge push towards YAML support in PHP. I suggested a lightweight subset of YAML be supported.
I did not receive a response, so the status from my perspective was that Zend_Yaml had been effectively turned down until support for YAML 1.1 was available via an extension for PHP. Since that was unlikely to happen soon – Zend_Yaml was pretty much dead in the water.
So for those not paying attention – Zend_Yaml has been out of the picture since November 2007.
In December 2007, Eric Coleman posted a question about the status of Zend_Yaml and Zend_Service_Yadis. ZSY is easy to explain – overworked Paddy fumbled the ball horribly and rather disappointingly on that one so it’s currently released on PEAR, but not yet in the ZF. Wil Sinclair responded with the following on December 20th:
We just haven’t scheduled a team meeting to go over them yet. As you’ve probably noticed, we’ve been pretty busy working on the 1.5 release. [...] but the fact is they are still there because we’ve got a lot on our plates. If Paddy were a squeakier wheel they would probably get through faster.
I got a bit “squeaky” after reading it, though honestly I’m only getting around to applying a little oil to remove squeaks this month, and pointed out Zend_Yaml was already reviewed, and I had responded with suggestions. Predictably, there was nothing further. Which goes right back to a blog post I made sometime ago about the Zend Framework’s idea of a proposal process.
Now this is twice my name has been dropped as the ignoramous holding up Zend’s YAML support. I fully confess to being an irresponsible ass over Zend_Service_Yadis which has sat in PEAR for months without a Zend Framework migration as I struggled between work and other stuff, but pointing the finger at the author of a rejected proposal nobody else at Zend seem to realise has been rejected is a bit tiresome .
So guys, just to clarify things…I’ve deleted the proposal. This will ensure everyone figures out it’s been rejected and I’m not holding it up, and that using it as a review point for future YAML using proposals is thereby pointless. Maybe someone can now re-review Thomas’ Zend_Translate_Yaml proposal and give it a second lease on life before it too joins the Great Dodo in the sky…