Just a word of warning to anybody who has compilation enabled on their Magento site for performance reasons:
We applied SUPEE-5345 to our Magento 1.7.1 install over a week ago. Last night we were hacked via the vulnerability that was supposed to be fixed. It appears that flushing the Magento cache after patching was not enough - we should have also recompiled the files. Recompiling makes sense in retrospect but I think it should be documented somewhere with the patch or on the downloads page.
Now we're going through the very difficult process of identifying whether or not any credit card details may have been leaked.
This goes for any sort of code update, module install or upgrade.
The cache is assembled out of the compiled code base.
Always disable the compiler, cache before applying the code changes, trigger the installers, then reenable the cache, test for proper operation and only after that, recompile and then reenable the compiler.
I agree whole-heartedly about the notification needing to be in the patch.
A couple of points perhaps worth noting, though. At is most basic level, the compilation system is rather simple - it takes all current source files, runs them through the Magento Autoloader and concatenates / copies them in a single directory to avoid having to do this at runtime - that's referencing EE but the core behavior is the same in CE.
As such, re-compilation has to be performed every time you make ANY changes to the source files, including installing any updates, patches, even 3rd Party Extensions (and their associated updates, patches, etc...).
I agree this also isn't covered well in the base Documentation, but unless you haven't installed any other updates to your environment prior to the patch, you would have had to run the compilation process or the Class Autoloader would have thrown errors when it couldn't find the updated files in the compilation source folder....
As a general rule, though I agree with the StackExchange discussion over at http://magento.stackexchange.com/questions/12996/when-should-i-use-the-magento-compiler
You at MOST only save a few MS of performance with this system. It seem like there's a lot of other things you might do to improve performance that would generate a better return on your time without dealing with the problems it may bring....the worst of which (at least from my limited experience) the many issues 3rd party plugins seem to have when compilation is enabled.
That's probably more about the code quality of those plugins, but still creates headaches...
On a related note i wanted to share that I've been working with a few of my fellow team members who pretty muchcknocked most of the open issues currenlty logged for mage hero in the last two days or so. I'm reubmitting themas pull requests ad will follow up when complete.
Just to let you know -- our instructions do include a specific step to recompile the store. You can find it in the online user guide for each product. Here are the links:
Thank you for pointing thta out, CCondra, the latest 1.9..1.1 User Guide does indeed include instructions to recompile after a patch installaiton!
Well....That IS true, but at least speaking for myself, I think my confusion came about a bit because those instructions are not included on the patch page as of today. To be completely fair, it does appear that a link to specific patch instructions was added to the page between April 15 & Today, which shows that Magento is listening to the pain and frustration of the community who supports the software, for which I know I'm grateful.
But it's also true that this wasn't available even two full months after the first disclosureof SUPEE 5344 :
And though it is good that the latest User Guide has been updated to include this information, the 1.7 User Guide doesn't even contain the word "Patch" in it - which was the verison the OP was running and patched....
It's not the end of world, of course. We all run Magento and support it because it solves our needs and those of our clients. But the timeliness and quality of the documentaton particularly relating to Security issues has been a challenge for users of CE for some time now. It's getting better, and for that we are appreciative.
Perhaps the shell script ought to error out if it detects the installation has compilation enabled, or at least clearly warn during the install that the files will need to be recompiled and cache cleaned etc?
I tihink those are both pretty good suggestions.
As a follow up, I wanted to share that we've remediated many sites since these exploits were released and to assist the community in responding to them we've documented our research to provide a list of 18 known attack signatures so that you can check your systems for evidence of them and respond accordingly. Keep in mind we've never seen two compromises that are exactly the same, so there's a chance your particular system might be slightly different - if you discover anything on your system that we don't already have documeted, please share that with us so we can update the attack signature guide.
We're working on a toolkit to automate the remediation of these item but it may be a week or two until it's ready for distribution. In the meantime, we're sharing the knowledge we've acquired working through these compromises with everyone in the community in an effort to make sure everyone is as safe as can be expected.
I'm including a 3-Step Compromise Response Process below that we've worked over and over again to get consistent results. The key assumption you're going to have to make is that you can't know what has or hasn't been compromised until you diff the files in your system against the default source code provided by Magento or a copy you have made in your (Git / Mercurial / SVN) repository. YOU SHOULD ASSUME that your database and logins have been compromised and go change them all.
We provide a link to a guide we've uploaded to our GitHub repo that is tracking the 18 signatures we have been able to clearly identify in the wild that relate to these most recent security announcements. You should go through each and every one of them to see if you can find anything that matches. If so, you can follow the instructions to either delete or replace the compromised file or delete or update your database to replace the affected data. It's in PDF format now, but we should have it converted to Markdown by tomorrow.
CRITICAL NOTE: Installing the patches from Magento WILL NOT help you if you have already been compromised. At best, it will stop ADDITIONAL compromises of the known types, but if you are already compromised then you'll have to BOTH install the patches and remediate your system as we highlight below.
Let me know if you discover anything not included already in that guide - we're trying our best ot keep up with the latest developments on this topic and happily welcome any contributions from the community.
Phase 1: Identify the scope of your compromise. Each and every one of the items I list below are signatures we've discovered on compromised Magento sites specicifally relating to the SUPEE-5344 and SUPEE-5994 vulnerability announcenments. You need to go through each one and check to see if you find any evidence on it on your system. Many of them are enough by themselves to allow an attacker to re-enter your systen after you patch it, so you'll have to be dilligent and make sure you don't skip anything or fail to remediate it.
Phase 2: Delete what you must, and replace what you can : use the original files from your repository or the Magento source files. If you're not running one of the latest versions, you can still use the Magento download page to grab older version sources from their download page on the Release Archive Tab.
Phase 3: RESET Credentials: Inventory every use of a login name and password remotely related to your deployment and reset them all, including
- You can be reasonably sure that the preceding steps will help you purge infected fies but you can not know if passwords have been sniffed or key logged or the victim of some other attack, so resetting all related credentials is the safest option if you are going to attempt to remediate a compromised system.
The guide is too long to post in this response but the PDF can be downloded immediately at our GitHub reopsitiory.
Bryan “BJ” Hoffpauir
<< Signature to be setup in your profile >>
Compilation improves the page loading speed. It stores the class path in includes /src and /stat. This is for auto loading. But now a days php has default cache like opCache. So there is no need to enable Compilation in magento. The folder is in the root path and easy to see the path of class files which is a security issue which we might be inviting. So always disable compilation.