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

Issue Type:
Docs: Improvement
Created:
2009-02-10T06:05:54.000+0000
Last Updated:
2009-02-11T12:07:54.000+0000
Status:
Resolved
Fix version(s):
    Reporter:
    Grzegorz Nowicki (gnowicki)
    Assignee:
    Matthew Weier O'Phinney (matthew)
    Tags:
    • Zend_View
    Related issues:
    Attachments:

    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

    Posted by Matthew Weier O'Phinney (matthew) on 2009-02-10T06:58:13.000+0000

    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.

    Posted by Grzegorz Nowicki (gnowicki) on 2009-02-10T07:27:38.000+0000

    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.

    Posted by Matthew Weier O'Phinney (matthew) on 2009-02-10T07:32:36.000+0000

    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.

    Posted by Matthew Weier O'Phinney (matthew) on 2009-02-11T11:33:44.000+0000

    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.

    Posted by Matthew Weier O'Phinney (matthew) on 2009-02-11T11:41:04.000+0000

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

    Posted by Matthew Weier O'Phinney (matthew) on 2009-02-11T11:42:38.000+0000

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

    Posted by Matthew Weier O'Phinney (matthew) on 2009-02-11T12:06:18.000+0000

    Documentation note added in r14050