Tuesday, February 17. 2009

Zend Framework 1.7.5 Released - Important Note Regarding Zend_View

Yesterday, we released Zend Framework 1.7.5. It contains a somewhat controversial security fix to Zend_View that could potentially affect some use cases of the component; I'm providing details on that security fix as well as how to work around it here.

A user filed an issue report showing a potential Local File Inclusion vulnerability in Zend_View's setScriptPath() method: if user input were used to specify the script path, then it was possible to trigger the LFI. The vulnerability was completely contrived; no sane developer should ever configure the view script paths using user input. However, it pointed out another very real LFI attack vector.

The attack vector is, once again, a situation of trusting unfiltered input, but this time it's a much more likely scenario. In this particular case, let's say we had Zend_View configured as follows:


$view->addScriptPath('/var/www/application/views/scripts');
 

We then accepted the following input, and passed it to the render() method: "../../../../etc/passwd".

The LFI vector was then triggered, as render() actually allowed for parent directory traversal.

ZF 1.7.5 now has a check for such notation ('../' or '..\'), and throws an exception when detected.

On #zftalk.dev, several contributors noted that this could potentially break some of their applications. In their situations, they were using parent directory traversal, but not from user input. In such a situation, since they have control over the value, they felt the check was better left to userland code.

To accomodate this, we introduced a flag, "lfiProtectionOn". By default, this flag is true, enabling the check. You may turn it off in one of two ways:


// At instantiation:
$view = new Zend_View(array(
    'lfiProtectionOn' => false,
));

// Programmatically, at any time:
$view->setLfiProtection(false);
 

Including this security fix was a hard decision. On the one hand, we try very hard to keep backwards compatibility between versions. On the other, there's also a very real responsibility to our users to keep them secure. Hopefully, the addition of the LFI protection flag above will help ease the migration issues.

For more information on this change, you can read the relevant manual page.

Posted by Matthew Weier O'Phinney at 11:33 | Comments (12) | Trackbacks (3)

Trackbacks
Trackback specific URI for this entry

Zend Framework 1.7.5 erschienen
Wie Matthew Weier O’Phinney in seinem Blog schreibt, ist das Zend Framework in der Version 1.7.5 erschienen. Er führt auf, das es in dieser Version ein Security Fix für Zend_View gibt, welches dafür sorgt, das dieses Release unter Umständen n...
Weblog: guenti's blog
Tracked: Feb 17, 17:19
Zend Framework 1.7.5 and Security Fix
Just a little information: Zend released Zend-Framework 1.7.5, which is again a bugfix release. It also fixes a (serious?) security issue regarding Zend_View. You can read all about it on Matthew Weier O'Phinney Blog. I'm preparing the packa
Weblog: sourcecode.de
Tracked: Feb 19, 03:38
Zend Framework 1.7.5 Released
Zend Framework 1.7.5 was released just a short while ago.  While there’s not much with regards to features, there’s an interesting update to the view renderer and local file injection attacks. I’m guilty of using this style of inclus...
Weblog: Darryl E. Clarke
Tracked: Feb 22, 15:10

Comments
Display comments as (Linear | Threaded)

Just a thought, but wouldn't using realpath() to translate any relative paths and then doing a simple string comparison to see if they are outside of the path set by addScriptPath() a better alternative? This would break less code, and offer the same level of security. No?
#1 Ken on 2009-02-17 13:52 (Reply)
That approach could potentially work, but requires then a stat call for each script path as it is loaded, plus a stat call for each directory searched (realpath does stat calls). The current implementation makes explicit the intention that rendering view scripts should occur beneath the paths provided, and bails as early as possible.

The net result would be the same, regardless: LFI protection, at the expense of those who have legitimate use (well, uses that don't trust user input) for rendering outside the view script path.

The primary breakages I've seen for users fall in two categories: failure to add a view script path they should have, or rendering view scripts from other modules. The second case is legitimate; currently, you either have to manually add the script path before calling it, or you have to use partial(). partial(), unfortunately, will not work if you want to retain the scope of the current view object. However, this can be easily remedied with another view helper, and we will likely do so soon.
#1.1 Matthew Weier O'Phinney (Link) on 2009-02-17 14:49 (Reply)
I can understand the reluctance of having stat calls, but there is always going to be some sort of trade off. I just see the stat call as accceptable, in comparison to the developer having to write more code around the lfiProtection. Especially if it means having to duplicate code, or work harder. But, that is simply my preference. To each their own. Thank you for listening. :-)
#1.1.1 Ken on 2009-02-17 14:58 (Reply)
Well, the issue persists even with your solution: people are, for one reason or another, rendering scripts that fall outside the script path. If we check to see if the script path is part of the final qualified path, we get the same effect as if we simply bailed early on detecting the parent directory traversal in the requested view script. Adding the lfiProtection flag and making it toggleable alleviates that problem -- but that's where the BC break is introduced.

The trade-off is BC versus security. I choose to err on the side of security here.
#1.1.1.1 Matthew Weier O'Phinney (Link) on 2009-02-17 15:29 (Reply)
This is not a security task for ZF - it is a security task for PHP which could be solved by using "open_basedir" in the correct way, so that PHP has no access outside the scope defined in open_basedir!
#2 Dennis Becker on 2009-02-18 02:57 (Reply)
Out of interest, why wasn't the flag called something like "allowParentDirectoryTraversal" or similar?

Regards,

Rob...
#3 Rob... (Link) on 2009-02-18 03:27 (Reply)
I agree. The flag name is kind of hard to remember and even read :-P "lfi"

allowParentDirectoryTraversal or something similar would have been easier on the eyes
#3.1 wenbert (Link) on 2009-02-18 04:03 (Reply)
Mainly because I was focussed on what I was fixing, not in terms of what I was breaking. :-)

I also think naming it 'lfiProtection' better indicates what you're opening yourself up to if you toggle the flag, and forces you to consider the security implications. The examples I was provided were, without exception, examples of improper filtering of user input.
#3.2 Matthew Weier O'Phinney (Link) on 2009-02-18 06:50 (Reply)
Hey Matthew,

that fix is very welcome. No BC issues should stand in the way of fixing a potential security hole.

What I do miss tremendously with the ZF releases is a decent changelog. Whenever a new release is out, we start looking into the Issue tracker to find out about what changed, and very rarely do you understand the full implications of the new release from the issue titles. The new PHP version requirements (>5.2.4) for instance pose a real problem for upgrading in Debian environments where no stable > 5.2.0 is available. That change was included rather silently with some 1.7.x release, and we only find out if we carefully watch the personal blogs of the contributors. Please consider adding a CHANGES and VERSION file to the distributions or postponing new releases for a day or to add them to the ZF docs site.

Thanks,
Bernd
#4 Bernd Matzner on 2009-02-18 03:47 (Reply)
Some ZF-users found out that 5.2.0 is the highest PHP version needed in ZF at the moment - they only have announced 5.2.4 because to be sure ZF really works without any problem.
#4.1 Dennis Becker on 2009-02-18 03:50 (Reply)
Hopefully this will be good news, then: on the download page itself, we're now including a 'Read Me' pane (that you have to expand) that has the release notes. While this doesn't currently include a change list, it likely will in the future.
#4.2 Matthew Weier O'Phinney (Link) on 2009-02-18 06:52 (Reply)
Hi Dennis,

thanks. Yes, ZF works for me on Debian w/ PHP 5.2.0 even when using Zend_File (which seems to require it for progress bar etc.)

Till put together a requirements list here:
http://till.klampaeckel.de/blog/archives/3-ZendFramework-version-requirements.html

If they want "to be sure ZF really works without any problem", then that's the standard. I do too, so I'd have to stick with older versions fit for my environment - if I ever find out that this is the case.

My point is that the notification about such change needs to be made more public, most notably for deprecations, requirement changes, significant enhancements. A lot of OSS projects have a simple changes file in their packages which is put together by copy-pasting their tracker's list of issues resolved and a few words about notable changes. That should suffice and keep extra work to a minimum.

Bernd
#5 Bernd Matzner on 2009-02-18 04:08 (Reply)

Add Comment

Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA