What to do after TYPO3 security update from 13.09.2016?

Question

I don't understand the security patch from last week: https://typo3.org/teams/security/security-bulletins/typo3-core/typo3-core-sa-2016-022/ . I have an old TYPO3 6.2 installation. I have truncated all cf_* tables and opened the pages with UID 2-6. No cHash. As a result I see 13 cf_cache_hash-entries. Now I have opened a detail page from a listing page in frontend. I see some parameters in URL like action, controller, the UID of the current displayed record and of cause a cHash. Then I have copied these parameters (excluding id=x) to the URL of my pages 2-6. In cf_cache_hash I have still 13 records. So, there is no cache flooding.

Or how I have to interprete this quote:

Links with a valid cHash argument lead to newly generated page cache entries. Because the cHash is not bound to a specific page, attackers could use valid cHash arguments for multiple pages, leading to additional useless page cache entries.

Next problem:

If extensions like realurl are used, it is required to flush their caches (and TYPO3 caches as well)

Can you please tell me WHICH tables I/we should clear?

tx_realurl_urldecodecache
tx_realurl_urlencodecache

are maybe OK. But what about tx_realurl_pathcache? Of cause, I can clear that, but what about older entries for earlier realurl configuration? If I truncate that table, these old entries are not valid anymore and they were not builded again. So, old Search Engine Results are invalid.

Question from one of our customers: Is it enough to clear system cache in backend or should he click on Clear all Cache in Installtool? Nice. IMO, it is not enough and the tables have to be truncated on DB directly. Right.

Next one:

This means if such URLs are indexed by a search engine, visitors from this search engine will end up on a not properly working page.

Hey cool. And now? What is the solution? Keep it as it is? IMO it depends on an InstallTool setting called: pageNotFoundOnCHashError. Right?

Please tell us what to do and please add some more details how to handle that.

Stefan

These are multiple questions at once. 1. "In cf_cache_hash I have still 13 records" The cache_hash cache has absolutely nothing to do with cHash in the URL. A valid cHash triggers new cache entries in cache_pages. Previously a link like index.php?id=1&foo=bar&cHash=abc could be modified to index.php?id=2&foo=bar&cHash=abc, given the cHash was valid and page with id 2 existed, a new cache_pages cache entry is created — helhum

DerSchreiner DerSchreiner · Accepted Answer · 2016-09-20T14:06:17

For me it boils down to (after installing the updated TYPO3 version):

If you don't use realurl: enable

$GLOBALS['TYPO3_CONF_VARS']['FE']['cHashIncludePageId'] = true;

& and you are probably "done". Of course all old google hits will be done for, but on a "public" site it's quite probable you never cared about google anyway if you didn't run realurl (or similar)

If you use realurl 1.X on a 6.2

Don't enable the config (there'll probably never be a proper patch)

Two options:

take the risk of a DDOS
use the 1.x version from https://github.com/mogic-le/typo3-realurl If I understand it correctly it will set TYPO3 to no_cache mode if there is no hit on the caching table; While that is a performance issue, it will prevent cache table entries being made (as a side effect)

If you run 7.6+ and realurl 2

Wait for realurl 2.1 (and take the risk?)
Change the caching framework to something like memcached (it's somewhat suggested between the lines: If you have a caching backend that cannot be used for a DDOS, you don't really have to care)
Use the fork from helhum (though I think that won't help you one bit regarding old links)

What to do after TYPO3 security update from 13.09.2016?

2 Answers