Drupal 7.27 was released yesterday for SA-CORE-2014-002:
https://drupal.org/SA-CORE-2014-002
There is a minor API change which could break some modules - according to this change record:
https://drupal.org/node/2242663
... this could affect any module which specifies 'delivery callback' => 'ajax_deliver' in hook_menu() and provides a form to anonymous users.
I did a quick grep of Panopoly, and found that these modules specify that in hook_menu():
- panels
- views_ui
- wysiwyg
- admin_menu
- panopoly_magic
However, I don't know if they ever expose forms to anonymous users. In any case, they'll need to be patched! However, the change required (per the change request) is really, really minor.
Comments
Comment #1
mgiffordWould be great to see a 7.x-1.3 release with this included. Hopefully sometime in the next week.
Comment #2
dsnopekI agree. :-) First, we'll need to make patches for all the modules listed above and test that everything works fine with 7.27 and those patches. As always, help is welcome! ;-)
Comment #3
dsnopekComment #4
dsnopekI've been digging in on this issue and I think far fewer modules are affected than I previously thought!
The actual vulnerability affects the form cache with forms that use
'#ajax' => array('path' => '...')for anonymous users. If they use the standard 'path', then they're fine. And the API that has changed is forajax_get_form().ajax_get_form()or the standard Drupla form cache. But the code is pretty complicated. It's the magic happening inajax_*()methods inplugins/display_renders/panels_renderer_editor.class.phpandpanels_ipe/plugins/display_renderers/panels_renderer_ipe.class.php. Certainly neither of those should be used by anonymous users.ajax_get_form(), they useviews_ui_ajax_get_form()which is designed to specifically NOT use the form cache.ajax_get_form()itself - it just routes AJAX requests to plugins*_wysiwyg_dialog()callbacks. None of our bundled wysiwyg plugins have such callbacks!In fact, the only module that does call
ajax_get_form()in the old way, is panopoly_magic, and it doesn't appear to return it's own commands, only reload the form special for ctools multistep forms.So, I'll update panopoly_magic to call
ajax_get_form()in the new way (for when we later read that code or update it), but it won't make any functional difference.Comment #6
dsnopekCommitted!
Comment #7
mgiffordSo no 7.x-1.3 release?
Comment #8
dsnopekWe'll make the 1.3 release as soon as it is possible! :-) There's a number of bugs in the 7.x-1.x branch which I'm trying to fix right now. Not sure how long it will take. If you'd like to follow along, just watch the issue queue updates.
Comment #9
mgiffordOk, so for now we should wait till there is a new 7.x-1.x-dev release?
We've got production sites using Panopoly and would like to update them. To keep up with security releases do we need to use the git version?
Comment #10
dsnopekI'd personally recommend waiting for the 1.3 release which will happen soon. I'm working as fast as I can. :-) Like I said above, there are some bugs in the current 7.x-1.x git branch, so using it on production probably isn't a good idea. However, feel free to test it (with a clone or something) and see if it works for you!
Comment #11
lsolesen commented@dsnopek Out of curiosity, how did your grep look like? Want to do the same for Commerce Kickstart.
Comment #12
dsnopekIn the end, I did several greps to get different information:
After that, I had to read through the code a bit to try and see if the issue applied. Since the API that changed was
ajax_get_form(), you could probably get away with just doing the last one.I hope that helps!
Comment #13
sylus commentedJust attaching the patch that was committed so can use as part of my drush make as I leverage the panopoly_magic module.