Hi @sherrie
Can you please advise what specifically this was designed to address, and what part of the PCI requirements it relates to?
Thanks
It is to prevent uploading scripts into the media folder tree and then executing them. Administrators are allowed to upload files. PHP scripts disguised as images can be run from other accounts when assigned global read. As in php -f image.jpg or sh image.jpg and the next thing you know, you have a credit card passthrough script collecting customer info and sending it to Romania. Normally, the administrator does not have the ability to touch php files unless they've nabbed your cPanel credentials or scp/sftp login. This allows somebody to hack into the admin panel and create their exploit scripts to do anything they want.
Malicious files can be upload via backend - APPSEC-1306
Type: | Insufficient Protection |
CVSSv3 Severity: | 6.5 (Medium) |
Known Attacks: | None |
Description: | An administrator can upload a file containing executable code to the server as a logo file if they rename the file to a supported image file format. The issue is not exploitable by itself unless the administrator account that has access to configuration is hacked. However, site audits may flag this issue, and it can cause security audits (such as PCI) to fail. |
Product(s) Affected: | Magento CE prior to 1.9.2.3, and Magento EE prior to 1.14.2.3 |
Fixed In: | CE 1.9.2.3, EE 1.14.2.3 |
Reporter: | Magento Merchant |
Right, and so - why this breaks-in-most-environments 'fix' as opposed to say, checking if the uploaded file is actually a valid image file rather than (presumably) previously only relying on mime types (provided by the browser upon upload based on file extension)?
A properly configured environment will not pass jpg/gif/png files through the PHP interpreter for execution, which leaves actual execution of the malicious payload completely dependent on some other mechanism/misconfiguration.
You talk specifically about world-read scripts being executed from other accounts. PHP scripts executed from a different web root or application to the Magento install will only result in PHP executing as the same user as the Magento install if it is installed on an insecure shared environment where PHP executes as the webserver (eg: www-data) which no shared hosting provider (and in fact, nobody running more than one web application on a server) with half a brain has done since like 2001.
World read scripts being executed from another account but somehow as the same system user as the magento installation under attack is not an attack vector Magento should be addressing by making image files 640 - because if someone is able to execute arbitrary files inside the Magento webroot as the same system user that PHP runs as under the Magento install then they can already insert files into folders to which that system user has write access. They don't need to upload some PHP renamed to a jpg inside the admin panel of the Magento installation.
If this is really the vector that is being considered when this change was drawn up: You can't band-aid terrible security practices/configuration on webservers with something like this.
Changing the established security model of a webserver when it comes to filesystem permissions (eg: static content with world-read will be served, static content without world-read is denied) to support this change is a terrible idea precisely because it is non-standard (and likely not possible in any kind of shared environment) - users in a dedicated environment using poor security practices will still be exposed (as they will still be running PHP as a single user).
For everyone else, they're now in a situation where they are being told to modify core files to undo a poorly conceived fix to a problem (poorly secured environment) that wasn't Magento's to address. Advocating for people to make alterations to a core file to undo this is a bad idea for a multitude of reasons, not least of which the fact that a good 20% of people will probably just end up breaking something.
In summary:
One thing that I think hasn't been mentioned, and that is important: Even if the 0640 images approach is the correct one (it isn't), this was supposed to be a MINOR update. Most of the industry is used to minor changes not breaking existing behavior. This one did, and that causes trouble for people running production sites and implementing urgent security patches.
Of course everything needs to be tested, but this behavior is specific enough as to cause problems in the most inopportune time.
Hi,
I did as accordingly but still getting the broken image icon. New images uploaded cannot be seen on both backend and frontend.
Have deleted var/cache including flush cache. What other options? Admin has to also login twice.
Hi all, there is now a new version of 7405 available to add support for PHP 5.3 and address issues with upload file permissions, merging carts, and SOAP APIs experienced with the original release.
Enjoy, SUPEE-7405 v1.1 is out there
Upload File Permissions
The patch restores less restrictive file permissions (0666 for files and 0777 for directories) as more strict permissions introduced by the original SUPEE-7405 patch caused many merchants not to be able to view uploaded product images, depending on hosting provider configuration.
Okay, that's definitely *some kind of change* that will make images work again but why are we now making things world-writeable by default?
What is wrong with 644 (static files) and 755 (directories)? The only people who can't use 644/755 are people using insecure hosting where PHP runs as www-data (and only then where they want to delete or modify files/directories using (S)FTP/SSH that were originally created by PHP and are now owned by www-data).
Making files and directories world writeable (if the directories are in any way predictable/observable from outside the admin area) is not especially great (and seems like an odd response to the problems going 640 will have caused) given that now you expose those directories and files to being modified by third party users on the system in a non-jailed environment.
Ideal solution would probably be a set of configuration options where admins can set the default permissions for files and folders so that Magento stores where PHP can configure Magento whichever way suits their environment in a properly supported manner (and for those to default to 644 static files/755 directories)