cancel
Showing results for 
Search instead for 
Did you mean: 

after installing SUPEE-7405 can no longer add or change images in Categories

SOLVED

Re: after installing SUPEE-7405 can no longer add or change images in Categories

Hi @sherrie

 

Can you please advise what specifically this was designed to address, and what part of the PCI requirements it relates to?

 

Thanks

Re: after installing SUPEE-7405 can no longer add or change images in Categories

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

 

 

Re: after installing SUPEE-7405 can no longer add or change images in Categories

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: Smiley Indifferent Smiley Surprised Smiley Mad

Re: after installing SUPEE-7405 can no longer add or change images in Categories

The problem I see with the advice/help in this forum is that so many people
are myopic. Not all of the world has its own server to run the Magento
shopping cart, or has to deal with the idiosyncrasies of a shared hosting
environment. It would be nice if we could meet in the middle (like the rest
of the world is now doing) and provide solutions that will work in all
environments. It might take a little more brain power, but only then will we
have a mature forum that we can all rely on. I would like to thank everyone
for all of the help and encouragement they have given all of us here.

Re: after installing SUPEE-7405 can no longer add or change images in Categories

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.

Re: after installing SUPEE-7405 can no longer add or change images in Categories

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.

Re: after installing SUPEE-7405 can no longer add or change images in Categories

I had the same problem. This is what I found to correct the double login
effect.

In the control panel you will need to go to: System>
Configuration>Web>Session Cookie Management>

The fields "Cookie Path and Cookie Domain" need to be set as / and
www.yourdomain.com respectively. Being left blank causes the double sign in
effect because it is looking for the cookies in multiple places. Be careful
though. Be sure to use the www if everything else is set to www. If not,
just use yourdomain.com. You always need to have consistency in everything
you do. Hope this helps.

Re: after installing SUPEE-7405 can no longer add or change images in Categories

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. 

--

Developer Relations, Adobe Experience Cloud
Problem solved? Click Accept as Solution!
Still stuck? Check out our documentation: https://magento.com/resources/technical

Re: after installing SUPEE-7405 can no longer add or change images in Categories

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.

Re: after installing SUPEE-7405 can no longer add or change images in Categories

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)