Geek Answers Handbook

What to do after TYPO3 security update from 09/13/2016?

I do not 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 installation of TYPO3 6.2. I truncated all the cf_ * tables and opened pages with UID 2-6. No. As a result, I see 13 cf_cache_hash entries. Now I opened the details page from the list page in the interface. I see some parameters in the URL, such as the action, the controller, the UID of the currently displayed entry, and the reason for cHash. Then I copied these parameters (excluding id = x) to the URL of my pages 2-6. I have 13 more entries in cf_cache_hash. Thus, there is no cache fill.

Or how should I interpret this quote:

Links with a valid CHash argument lead to the newly created record page cache. Since cHash is not tied to a specific page, attackers can use valid CHash arguments for multiple pages, which results in additional unnecessary page cache entries.

The following problem:

If extensions such as realurl are used, you need to clear their caches (and TYPO3 caches)

Could you tell me which tables I / we need to clear?

  • tx_realurl_urldecodecache
  • tx_realurl_urlencodecache

maybe ok. But what about tx_realurl_pathcache? Because of this, I can understand this, but what about old entries for an earlier realurl configuration? If I truncate this table, these old records are no longer valid and they were not built again. Therefore, old search results are invalid.

Question from one of our clients: is it enough to clear the system cache in the backend or click "Clear all cache in Installtool"? Nice. IMO, this is not enough, and the tables should be truncated directly to the database. Right.

Following:

This means that if such URLs are indexed by the search engine, visitors from this search engine will be on an inoperable page.

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

Please tell us what to do, and please add more details on how to handle this.

Stephen

+5
source share
2 answers

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

If you are not using realurl: enable

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

& and you probably did. Of course, all old google hits will be executed, but on a "public" site it is likely that you never cared about google if you hadn’t run realurl (or the like)

If you are using realurl 1.X on 6.2

Do not enable the configuration (there will probably never be a suitable patch)

Two options:

  • risk of using DDOS
  • use version 1.x 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 in the cache table; Although this is a performance issue, it will prevent the creation of entries in the cache table (as a side effect).

If you run 7.6+ and realurl 2

  • Expect realurl 2.1 (and take risks?)
  • Change frame caching for something like memcached (he suggested a few between the lines: if you have a caching backend that cannot be used for DDOS you really don't need to care)
  • Use a fork from helhum (although I think this will not help you with the link)
+3
source

Realurl> = 2.1.0 supports this basic option. But you are advised to update at least 2.1.4, because it fixes various other cHash problems.

+2
source

More articles:


All Articles