Magento SUPEE-6482 partial patch released

[chiefair]

The SUPEE-6482 CE patch is a partial patch, it only patches two files in the api

app/code/core/Mage/Api/Model/Server/Adapter/Soap.php
app/code/core/Mage/Catalog/Model/Product/Api/V2.php

It misses applying two more patches which are borne out by running a diff on 1.9.2.0 vs 1.9.2.1

app/code/core/Mage/Core/Controller/Request/Http.php

Compare: (<)V:\Magento\Magento 1.6\Changes\20150804 http\Http-1920.php (15194 bytes)
   with: (>)V:\Magento\Magento 1.6\Changes\20150804 http\Http-1921.php (15462 bytes)

301,305c301,313
<         if ($trimPort) {
<             $host = explode(':', $_SERVER['HTTP_HOST']);
<             return $host[0];
<         }
<         return $_SERVER['HTTP_HOST'];
---
>         $host = $_SERVER['HTTP_HOST'];
>         if ($trimPort) {
>             $hostParts = explode(':', $_SERVER['HTTP_HOST']);
>             $host =  $hostParts[0];
>         }
> 
>         if (strpos($host, ',') !== false || strpos($host, ';') !== false) {
>             $response = new Zend_Controller_Response_Http();
>             $response->setHttpResponseCode(400)->sendHeaders();
>             exit();
>         }
> 
>         return $host;

app/design/frontend/base/default/template/page/js/cookie.phtml

Compare: (<)V:\Transition\magento-1920\app\design\frontend\base\default\template\page\js\cookie.phtml (1229 bytes)
   with: (>)V:\Transition\magento-1921\app\design\frontend\base\default\template\page\js\cookie.phtml (1305 bytes)

37,38c37,38
< Mage.Cookies.path     = '<?php echo $this->getPath()?>';
< Mage.Cookies.domain   = '<?php echo $this->getDomain()?>';
---
> Mage.Cookies.path     = '<?php echo Mage::helper('core')->jsQuoteEscape($this->getPath()) ?>';
> Mage.Cookies.domain   = '<?php echo Mage::helper('core')->jsQuoteEscape($this->getDomain()) ?>';

[hengman]

Hi,

I,ve also compared both MCE versions and I can confirm that issue. The MEE patch file seems to contain all the described fixes.

Please fix it.


Greetings!

[chiefair]

Looks like they're going to fix it by documentation change, not actual patching.

The unvalidated headers patch is now marked as: For Magento Enterprise Edition Only

Yeah, we see what you did there...

[MagenX]

yeah, that sucks when marketing takes precedence over common sense...

[sherrie]

Hi all, as stated here http://community.magento.com/t5/News-Announcements/Magento-Security-Patch-SUPEE-6482-Release-Note-Co... the issue was that the release notes were actually incorrect.

The changes you've noted above in 1.9.2.1 are there in the core for the EE patches. They do not actually address any vulnerabilities present in CE as they relate to Full Page Cache and Gift Registry, both of which are EE specific.

So sorry for the miscommunication.

[toonisaac]

Hi Sherrie, can you please explain why the Full Page Cache vulnerability is not an issue in CE? It looks like something that's not dependent on any caching mechanism to me: an XSS leak is an XSS leak, right?

But if I'm wrong (which I am known to be from time to time ), and this is in fact only a problem if full pages are cached, this leaves you with a vulnerability that occurs if third parties build a full page cache module. This would have been easy to include in the patch, there's no downside to including it in the patch, and yet the Magento team chose not to. Can you elaborate on why the vulnerability was left in?

Finally, I don't understand why is this vulnerability patched in CE version 1.9.2.1 if it's not a vulnerability? In particular, what I find puzzling is that it's in 1.9.2.1 but not in the patches.

[sherrie]

Hi @toonisaac, valid questions and I see Ben has already replied on Twitter, but to reiterate here, according to our tests - Cross-site Scripting Using Unvalidated Headers is NOT a CE vulnerability.

That being said, if you, or anyone else, can provide a POC that there is a CE vulnerability, please go to magento.com/security and report it.

As to why it was included in 1.9.2.1 and not in the patch, as Ben mentioned: post mortem coming. 

[chiefair]

Going out on a limb here, but just because we don't use Magento Enterprise Full Page Cache, doesn't mean we're not using a Full Page Cache on CE that can't be poisoned by bad headers.

There are several FPC modules out there that tap into the hooks provided in the Magento CE codebase, and they get the information from bad code left to remain in Magento CE.

I don't feel like being the POC of some cybercriminal who figures this out. That's why I made my own patch from the 1.9.2.0-1.9.2.1 diff. At least, my customers will be safe from Magento's decision.

[toonisaac]

Hi @sherrie,

Well, Ben's postmortem will provide an answer to the most important question I have: why leave it out of the patches, so I'll wait for that.

Having said that, I don't know what to think of your suggestion that people come up with a proof of concept and report the vulnerability to magento.com/security, because you said that according to the Magento team, it's not a CE vulnerability because it requires fullpage caching to exploit. This suggests that the Magento team doesn't need a POC to become aware of a way in which the vulnerability can be exploited in CE: install a fullpage cache module.

The top two results for "magento full page cache" in Google happen to be CE plugins hosted on magentocommerce.com, but there are probably a bunch of plugins out there. I don't think it's reasonable to assume that none of them are ever used, and I doubt very much that the Magento team is unaware of their existence.

This is why I'm so baffled as to why the fix was left out of the patches. There may be many perfectly good reasons for this (which is why I'm eagerly anticipating the postmortem), but "not applicable to CE until we get a POC" is, in my opinion, not one of them, especially not when the risk is so great and the fix so trivial and unintrusive.

[sherrie]

Hi @toonisaac & @chiefair, looking further as I know this was discussed and tested but don't have a helpful response yet. I will share what I find out as soon as I can.