blog.Resource
July 30, 2011

Breaking changes in the latest TYPO3 Security Release

Category: Security

By: Helmut Hummel

Since some people contacted us with questions regarding the latest release, this post will elaborate on the changes in that release and why they have been done that way.

Update: The compatibility issue has been fixed in between (see release notes)

In the latest TYPO3 release the following breaking changes have been introduced:

  1. Changed TypoScript for headline rendering
  2. Added requirement for ExtDirect components to be reigistered through a newly introduced API

1. Changed TypoScript rendering for headlines

As mentioned in the security bulletin, "getText" parsing (insertData = 1) was enabled for the complete headline, leading to an uneccessary and unwanted information disclosure possibility. But we could not fix this by simply turning it off (insertData = 0) because the default headline rendering relies on it to add style and CSS class information to the headline wrapping and the "fontTag" property does not support such a thing.

So we had to move the headline wrapping to the "dataWrap" property, which is a breaking change, because many people already modified the headline rendering in their installations.

We discussed two options how to cope with this:

  1. Deliver an unchanged (and insecure) TypoScript by default and informing the people in the bulletin to manually fix their installations to make them secure.
  2. Deliver the changed (secure) TypoScript and informing the people to manually fix the rendering in their installations.

As you see, both options require manual interaction and because of the "nature" of this security issue, we could not provide an automatic update/upgrade path.

We chose the second option here: Security over possibly breaking the headline rendering.

2. Introducing new API for ExtDirect components

As also mentioned in the bulletin, there was unfortunately a desing error in the ExtDirect components API, that no access control had been (and could have been) applied for them. So we needed to introduce an API which makes it possible to apply and check the access to ExtDirect consumers. Like above we had two possibilities:

  1. Allow "old" ExtDirect components to still work (insecure if third party modules have been installed), throwing only a deprecation message, but at least modify all core components to use the new API.
  2. Disable Access for components which have not been properly registered through the new registering API (secure).

As you see, this also requires manual interaction on the user/ administrator side to fix both security and functionality issues.

In this case we chose the first option. Here is why:

First of all, a breaking change here would have caused much more trouble than a wrong rendering. It would have completely disabled the functionality, which an administrator probably could not even fix without involving a third party. Secondly we assumed that not too many third party modules using ExtDirect are existing, so the security impact for the vast majority of the TYPO3 users would just not exist. Last but not least, we could easily fix the core modules to be secure.

What do we learn from this?

We, the Security Team, learned that it might be not enough to mention breaking changes in the bulletin only and we strive to communicate such things (in case of necessity) more prominent in the future.

But we also kindly ask you to carefully read the advisories we write, as we really put a lot of effort in writing them as clearly as possible for you to have all required information to fix the issues. As well we're trying to give the least information on how to exploit the issues, to also give you more time for the update and all necessary steps to take, to make your TYPO3 installation secure again.

Thank you for your patience and your understanding.


comments

comment #1
Gravatar: Xavier Perseguers Xavier Perseguers July 31, 2011 10:24
Breaking changes are always a problem as it (often) cannot be transparently upgraded. I like the way you carefully chose how to handle the situation by either forcing the administrators to adapt their possible modification or by logging a (now) deprecated usage of the API.

When it comes to security, this is worth the minor hassle.

Thanks to the whole security team!

comment #2
Gravatar: Charles Coleman Charles Coleman August 2, 2011 17:34
Right on guys! I agree with the approach you took as well. Thanks for the communication!

comment #3
Gravatar: Tobias Daur Tobias Daur August 18, 2011 11:55
Well done. Thanks for the blog entry.

Sorry, comments are closed for this post.