Issues

ZF-5724: Security BUG - LFI is possible, with wrong configuration Zend_View

Description

I've got something like this: Zend_Controller_Plugin for initialize view:


(...)
$view = new Zend_View();
$view->setScriptPath(APP_PATH . '/views/0');
$view->addScriptPath(APP_PATH . '/views/modules/' . $this->_reguest->getModuleName() . '/0');
(...)
$helper_view = Zend_Controller_Action_HelperBroker::getExistingHelper('viewRenderer');
$helper_view->setView($view);
(...)

Zend_Router like:



LFI:

http://my_website.com/..%2F..%2F..%2F..%2F..%2F..%…



LIF is possible, because scripts should not be loaded in this way:

Zend_View: /** * Includes the view script in a scope with only public $this variables. * * @param string The view script to execute. */ protected function _run() { if ($this->_useViewStream && $this->useStreamWrapper()) { include 'zend.view://' . func_get_arg(0); } else { include func_get_arg(0); } } ```

Comments

I understand the ramifications of the local file include attack, and feel that we should definitely patch Zend_View to disallow using the '..' specification. That said, in most cases you should not be trusting user input in order to determine the view script to render; it should be based on very narrow criteria, and the path should be filtered prior to passing to Zend_View's render() method.

Of course, filtering of the user input is an important thing, but this example shows that for specific cases (incorrectly) use, application becomes "open source". I think that loading scripts without filtering path is not a good solution.

Agreed, and I'm recommending we patch Zend_View to disallow such usage.

However, the use case that exposes the issue is one that is limited primarily to userland code which does not properly filter the path passed to the render() method.

We will issue a patch with our next mini release, which should be Monday.

I've been in discussion with other developers about this issue, and need to note two things:

  • While I understand the vulnerability as reported, you should never set script paths based on unfiltered user input. As it's actually common for the paths specified to include parent reference notation, even when hardcoded, there's not a good, clean way for us to address this reasonably (without a taint mode in PHP, that is) -- other than to note, "Don't do it."
  • There is a potential vulnerability in the render() method, as it currently allows parent reference notation. We feel there is distinct benefit to doing some automatic filtering here, as view scripts should only ever match under a view script path, not elsewhere in the filesystem.

I've created a new issue, ZF-5748, to cover the render() LFI exploit, and am closing this issue.

Marking as a documentation improvement, as the issue would be in userland code providing unfiltered input used to configure the view object.

Documentation note added in r14050