2

I have updated Magento to 1.9.2.2 via Connect Manager in my dev environment and so far I can't say that I am noticing any bugs related to the various changes outlined here: http://magento.com/security/patches/supee-6788-technical-details

However, before updating my live store I want to be perfectly sure, that no issues exist and am therefore looking for the best approach to modify all extensions with the new requirements.

1) APPSEC-1034, addressing bypassing custom admin URL

I have about 10 extensions in use which are not under the admin url, doing a search via FileExpress for

custom_module after="Mage_Adminhtml"

within these extension yielded no results so I will have to modify all these extensions as described in the documentation.

2) APPSEC-1063, addressing possible SQL injection

Doing a search via FileExpress for

$collection->addFieldToFilter('`

within all my extensions yielded a couple of results within the Ess M2E Pro extension, however an updated version has already been released which fixes this.

Doing a search via FileExpress for

$collection->addFieldToFilter('(

within all my extensions yielded no results, so this shouldn't be a problem in my case.

3) APPSEC-1057, template processing method allows access to private information

Doing a search via FileExpress for

{{config path=

within all my extensions yielded no results.

Doing a search via FileExpress for

{{block type=

yielded a couple of results within the german locale pack. A few email templates will have to be modified.

EDIT:

All these blocks are core/template blocks so no modification should be required.

4) APPSEC-1079, addressing potential Exploit with Custom Option File Type

"This change will affect any customization that uses product custom options to save information as a PHP object. Such approach will no longer be possible."

I doubt this is the case with any of my extensions, but is there any way I can actually confirm this?

  • Please note that I have seen that there are problems with the "create account" forms that no longer submit properly, following the 6788 patch. This might be down to the fact that we have customised forms. The reason is that we are missing form_key field that is now required. Just a pointed. – Jon Holland Oct 29 '15 at 13:16
  • 1
    Don't forget to search for $collection->addFieldToFilter("{$var} and all of its ugly cousins. – Luke A. Leber Oct 29 '15 at 19:51
  • 1
    Check out the diffs between 1.9.2.2 and 1.9.2.1 here gist.github.com/gwillem/dd421fef3a6370097a93 in particular have a look at the template changes and check if this affects any of your custom template files, i.e. the registration form change where you will see a session key has been added to the default template file. – paj Oct 30 '15 at 15:01
5

I would recommend using the https://github.com/rhoerr/supee-6788-toolbox tool from Paradox Labs. It scans your codebase for each of the issues listed in your question.

  • The above tool does not check for SQL injection points (#2). – Luke A. Leber Oct 29 '15 at 19:50
  • 1
    @LukeA.Leber The README for the extension says: "APPSEC-1063, possible SQL injection: This script attempts to identify any such cases by checking all modules and templates for a specific REGEX pattern. Any instances found must be analyzed (and if needed, fixed) manually. (Thanks @timvroom) NOTE: There is no guarantee that all possible instances will be found, nor that all instances found will be affected." Are you saying it doesn't do this? – Erik Hansen Oct 30 '15 at 20:44
  • I was mistaken, there are 5 lines in there that do check. – Luke A. Leber Oct 30 '15 at 21:36
2

The Paradox Labs toolbox is useful but it is hard to use it on multiple environments as the whitelists have to be updated on each manually. The file fixes are good though.

For whitelist fix I recommend this - http://supee6788.magebit.com/ It is an extension that whitelists all current blocks and then sets itself as disabled (so the security is not impacted this way).

It is also possible to re-enable the extension and set autodisable time. For example, you need to whitelist everything till site launch date so you can set the launch date there and all problems are solved. :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.