Zend Framework

Security BUG - LFI is possible, with wrong configuration Zend_View

Details

  • Type: Docs:  Improvement Docs: Improvement
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: Zend_View
  • Labels:
    None

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:

http://my_website.com/module/controller/action

LFI:

http://my_website.com/..%2F..%2F..%2F..%2F..%2F..%2Fetc..%2Fpasswd%00

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);
        }
    }

Issue Links

Activity

Hide
Matthew Weier O'Phinney added a comment -

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.

Show
Matthew Weier O'Phinney added a comment - 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.
Hide
Grzegorz Nowicki added a comment -

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.

Show
Grzegorz Nowicki added a comment - 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.
Hide
Matthew Weier O'Phinney added a comment -

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.

Show
Matthew Weier O'Phinney added a comment - 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.
Hide
Matthew Weier O'Phinney added a comment -

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.
Show
Matthew Weier O'Phinney added a comment - 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.
Hide
Matthew Weier O'Phinney added a comment -

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

Show
Matthew Weier O'Phinney added a comment - I've created a new issue, ZF-5748, to cover the render() LFI exploit, and am closing this issue.
Hide
Matthew Weier O'Phinney added a comment -

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

Show
Matthew Weier O'Phinney added a comment - Marking as a documentation improvement, as the issue would be in userland code providing unfiltered input used to configure the view object.
Hide
Matthew Weier O'Phinney added a comment -

Documentation note added in r14050

Show
Matthew Weier O'Phinney added a comment - Documentation note added in r14050

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: