29

After weeks of waiting for the patch today (27.10.2015) it was released: SUPEE-6788

A lot of things were patched and also is encouraged to review installed modules for possible vulnerabilities.

I open this post in order to get some insights about how to apply the patch. What are the steps to apply the patch? To my understanding this are the steps:

  1. Fix modules with admin functionality that is not under the admin URL
  2. Fix modules that use SQL statements as field names or escape fields
  3. White list blocks or directives that uses variables like {{config path=”web/unsecure/base_url”}} and {{bloc type=rss/order_new}}
  4. Addressing potential Exploit with Custom Option File Type (no idea how to do this)
  5. Apply the patch

Is this the correct procedure?

Improve this question
10
  • 1
    Current listed CE versions 1.7.0.0 through 1.9.2.0
    – Fiasco Labs
    Oct 27, 2015 at 15:59
  • 5
    The patch changes .htaccess.sample as well as .htaccess. The latter is customized in most shops, this will make the patch fail => You need to temporarily replace it with the original file from Magento, apply the patch, restore your own .htaccess and apply the change which protects access to cron.php manually (don't use the production system for this process of course!)
    – Fabian Schmengler
    Oct 27, 2015 at 16:28
  • 1
    what about those using nginx?
    – lloiacono
    Oct 27, 2015 at 16:29
  • 4
    I'm voting to close this question as off-topic because there's no question. Please move discussions to chat
    – 7ochem
    Oct 27, 2015 at 19:14
  • 2
    There is a question in the very title of the post, also in the last paragraph I'm more specific. Regardless this, this sort of post are very useful in my opinion to centralize comments and best practices when applying a newly released patch.
    – lloiacono
    Oct 27, 2015 at 19:53

4 Answers 4

Reset to default
33

In general, you can apply the patch as all previous ones. Have a look at the official documentation and check this SE post. But yes, there are some additional points you should check when applying this patch. Byte/Hypernode has a nice post about it.

  1. Check if your theme has a custom template/customer/form/register.phtml or custom template/persistent/customer/form/register.phtml. If this is the case, make sure that it includes a form_key.
  2. Check if your theme has a custom layout/customer.xml. If this is the case, make sure to apply the necessary changes from the patch (customer_account_resetpassword has been changed to customer_account_changeforgotten).
  3. Do you use non-standard variables in CMS pages, static blocks or email templates? Then make sure that you whitelist them. See this SE question to learn how to whitelist variables/blocks.
  4. Do you run the cron.php via HTTP? Make sure that you better use cron.sh. If this is not possible, at least make sure that you call cron.php via CLI PHP. If for some reason you can not configure a real cronjob and need to run it via HTTP, see this SE question
  5. Make sure that all your extensions use the "new" admin routing. You can use this n98-magerun plugin to check. You can also use this CLI script. You can also have a look at this related SE question.
    1. When all your extensions use the proper admin routing, make sure to disable "Enable Admin routing compatibility mode" under System - Configuration - Admin - Security.
  6. If you use M2ePro, update it to the latest version since old versions do not work with the new patch.

When updating, make sure that you delete the file dev/tests/functional/.htaccess. It is not present any more in Magento 1.9.2.2. Keeping it means you are still vulnerable.

In any case, check your page with MageReport after updating to see if everything went well.

There is also a technical blog post by Piotr, which describes the critical changes.

Improve this answer
5
  • Just a little note, the CLI script mentions to 'Verify all is well, then disable the admin controller compatibility mode'. I think they mean the opposite, to enable it. Is that right?
    – MW Millar
    Oct 29, 2015 at 11:21
  • 1
    @kaska If all your extensions are okay, you have to disable the compatibility mode.
    – Simon
    Oct 29, 2015 at 11:35
  • in a production environment shouldn't you remove /dev completely?
    – paj
    Oct 29, 2015 at 12:55
  • 1
    @paj theoretically yes. But with version 1.9.2.2, it is protected with a .htaccess, so it should be okay to keep it. Just make sure to follow my .htaccess advise above.
    – Simon
    Oct 29, 2015 at 12:59
  • Thank you for the completeness, they should let you write the condensed release notes next time! Super helpful!
    – asherrard
    Oct 29, 2015 at 21:23
6

There is a check file which helps you to identify issues: https://github.com/gaiterjones/magento-appsec-file-check

I made a CLI script out of it. https://github.com/Schrank/magento-appsec-file-check

Improve this answer
0
3

For Nginx, make sure you block access to cron.php and the dev folder. We use this block:

location ~ ^/(app|includes|media/downloadable|pkginfo|report/config.xml|var|magmi|cron.php|dev)/? { deny all; }
Improve this answer
4
  • your regex will not work, cause you check against directory only, . so "report/config.xml , cron.php" do not match, and you have a vertical bar or pipe symbol at the end.. copy-paste? also do not mess regex together with /app/ , if you misplace something, it will be hacked.
    – MagenX
    Oct 27, 2015 at 18:40
  • Bad copy and paste job, sorry. Added in the ? at the end so the trailing slash is optional. Tested it just now and it is working as it should.
    – Adam L.
    Oct 27, 2015 at 18:42
  • also this regex is vulnerable, you have ^/ , make sure you dont copy your source files into top folder, like /old/ , /upgrade/ etc
    – MagenX
    Oct 27, 2015 at 18:47
  • @MagenX So you're saying that if you don't use version control or standard system administration BCP, that this regex is to blame?
    – user4351
    Oct 28, 2015 at 8:05
1

I just applied the patch on my 1.10.1 EE and this causes side effects on native screens because the core is not APPSEC-1063 compliant:

Example:

In app/code/core/Mage/Customer/Model/Entity/Attribute/Collection.php

You can find 2 addFieldToFilter calls not APPSEC-1063 compliant.

This is breaking the Customer > Attribute grids, so you have to patch the patch, using the trick they recommend in the pdf "SUPEE-6788-Technical%20Details%20.pdf" in APPSEC-1063 section

Changing the several

    $this->addFieldToFilter($field, 0);

(where $field contains complex (CASE .. WHEN THEN...) sql statements )

into 

    $resultCondition = $this->_getConditionSql($field, 0);
    $this->_select->where($resultCondition);

Both rhoerr's supee-6788-toolbox and gaiterjones' didn't detect this kind of issues, I checked all the others ->addFieldToFilter($ and none seem to be causing the issue.

Other affected 1.10 core files: (found by rhoerr's supee-6788-toolbox)

app/code/core/Mage/Bundle/Model/Mysql4/Option/Collection.php

There may be more.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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