No preannouncements for TYPO3 security advisories

Posted in advisory/TYPO3/ on March 04, 2010 by Marcus.

Every once in a while the TYPO3 Security Team is being asked to generally use preannouncements. Such preannouncements, to be published days before the actual TYPO3 Security bulletin, seem to be a nice way to be prepared for a necessary update of the TYPO3 Core, the base platform.

We discussed this suggestions but came to the conclusion that we better stick to the current procedure. Following is a list of points you need to understand.

• Preannouncements for third-party TYPO3 extensions seem to be not necessary. Most time, you won't be affected by extension issues as you aren't using any of the mentioned extensions.
• We believe and know that upgrading (w/o testing) alone of the TYPO3 Core won't take longer than 5 minutes per server.
• We are not aware of any other Open Source project that has preannouncements in general use.
• Preannouncements will become useless again, if we need to late-postpone or pre-release a new TYPO3 Core version. Valid reasons would be regressions or exploits in the wild.
• Your TYPO3 installation might not be vulnerable because of not using an extension in question (recent openid vulnerability etc..) or the exploitability risk is very low (e.g. XSS in the backend with another vulnerability as mandatory prerequisite).

Last but not least, preannouncements would be another task to be done by the TYPO3 Security Team. The creation/review/publication of the bulletin takes hours (not taking any work on the issue itself into account). We're mostly interested in reducing our work load; after all, most of us do this work for free. However, preannouncements would mean the contrary and the overhead does not compensate the to be expected benefits.

Nonethless, for critical security issues we will of course proceed with preannouncements which has been done several times in the past.

TYPO3 as good as its competitors in web application security

Posted in TYPO3/ on March 01, 2010 by Marcus.

IBM has recently released its X-Force 2009 Trend and Risk Report. This report summarizes reported web application vulnerabilities in 2009. TYPO3's overall "performance" is as good as its Open Source competitors like Drupal, and Joomla!. The number of vulnerabities in the CMS cores are more or less equally; when taking third-party addons/extensions/modules into account choosing TYPO3 seems to be slightly better than Drupal or Joomla!. However, this might also be caused by different total numbers of available third party plugins.

 

Percent of all vulnerability disclosures in 2009

Product	Base Platform	Plug-ins	Total
Drupal	0.2%	2.5%	2.7%
Joomla!	0.2%	2.5%	2.6%
TYPO3	0.3%	1.2%	1.5%

 

The report additionally considers vulnerabilities w/ and w/o patches. In regards to this, TYPO3 numbers seem to be odd. I'm not aware what IBM considers as unpatched. For TYPO3 core there weren't and aren't vulnerabilities disclosed for the base platform without providing patches. Either IBM is taking versions into account that aren't officially supported any longer or wrongly considers a non-issue issue I covered in a previous blog post.

 

Percent of vulnerabilities without patches in 2009

Platform	Base Platform	Plug-ins
Drupal	18%	13%
Joomla!	8%	80%
TYPO3	5%	51%

We see a relatively high percentage of unpatched vulnerabilities in plug-ins (Joomla! and TYPO3 specifically). At least for TYPO3, this can be explained. TYPO3 is on the market for years now. Plug-ins are an essential part of a TYPO3 installation to bring missing functionalities. Therefore we have really old and no longer maintained plug-ins in the TYPO3 extension repository. Besides, security awareness wasn't that good in the good old days.

There's a high change that extensions with unpatched vulnerabilities are no longer in use or even aren't working anymore. Also, if the maintainer decides to stop support for an extension, TYPO3 security team won't provide patches. Providing patches in such cases would mean that the TYPO3 Security Team is responsable for these extensions forever and ever. Nonetheless, we encourage the TYPO3 community to contact the TYPO3 Security Team to take over maintainership of unpatched vulnerable extensions. Then a fixed version of the extension might again appear in the TYPO3 extension repository.

Still, I'm curious why Drupal has a significantly lower number of unpatched vulnerabilities in their plugins. Enlighten me!

Providing third-party plugins is always a tradeoff between security and user-friendlyness. You want to keep burdens low to provide additional functionalities and so help spreading the product. Then, overall quality of third-party plug-ins is definitely not as good as the base platform. So choose your plug-ins wisely and make a basic check by having a first or second glance on the code.

 

What I believe is more important, all mentioned CMS vendors above have professionally working teams that take care of security in the base product and third-party plug-ins. Every software product contains bugs. If you need to choose one CMS over other ones, check out the vendor's security awareness. If there's one CMS product without any disclosed vulnerabilities, it's either brand-new, not widely spread or doesn't care of security issues. If in doubt, better avoid such product.

In regards to security, Drupal, Joomla! and TYPO3 seem to be equal. In the end, functionality matters. You won't make a security mistake by choosing one over the others.

I'd like to take this posting as a change to say thanks to the TYPO3 Association. The Association cares about the security in their baby at least as much as the TYPO3 Security team does. They are giving us - the TYPO3 Security Team - a decent budget to cope with security issues. Thanks again. By being a TYPO3 Association Member you help to have a secure CMS. If you ever asked yourself, where your fees are spent on - not only on development but also partly on the TYPO3 Security Team. And it's definitely worth it.

One additional figure from the TYPO3 Security Team:
In 2009 we have handled 317 reports in total; starting with suggestions on how to improve security, over support requests on hacked servers and of course vulnerability reports in third-party plug-ins and TYPO3 core. That's an impressive number considering the small number of security team members.

 

Disclaimer:
X-Force statistical data are used as are. I personally do not warrent their correctness. IBM and X-Force are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both.

Frontend login password recovery

Posted in TYPO3/ on February 20, 2010 by Marcus.

In TYPO3 4.3, system extension felogin comes with a rewritten password recovery functionality. With saltedpasswords it's no longer possible to send you the password you've originally chosen. And of course, sending passwords by mail is generally not a good idea.

In case of a forgotten password, felogin now asks you for your mail address or username you've initially chosen. Then it will send you an email with a link that, when being followed, allows to set a new password.

Steffen Müller has written a detailed article on this procedure: Enhanced password recovery for Frontend users in TYPO3 4.3. It's worth reading. One pitfall he mentions is using an outdated template file. So check if it's working on your website!

TYPO3 4.3 Multimedia Cookbook - a new book in english

Posted in book/TYPO3/ on February 06, 2010 by Marcus.

TYPO3 4.3 system extension saltedpasswords - manual available

Posted in TYPO3/ on February 05, 2010 by Marcus.

TYPO3 version 4.3 has brought a lot of new features. It's out since December 2009 and you've probably tried it or you're already familiar with all the new gimmicks.

I'm glad that the new system extension saltedpasswords has made it into the core. It allows to store passwords of TYPO3 user accounts as salted hash. With all these web sites that allow to "retrieve" the origin of a md5 hash, it's important that TYPO3 keeps up with the progress in security industry. With salted passwords we catch up with other content management systems like Drupal or Wordpress.

The main advantage of salted hashes is the fact that it makes pre-computed rainbow tables useless. Someone who's interested in retrieving the original password for a salted hash is basically cursed to run a brute-force attack. This is much more expensive in terms of time and computing power than looking up a hash in a pre-computed table.

What makes salted hashes so special? Every to be hashed plain-text password will concatenated with a random string (the salt). This salt is different of each user password stored in the CMS's database. Then, the hashing and concatenation will be done multiple times. By default, TYPO3 does that exactely 16384 times for each password. You now understand that dealing with salted passwords is a lot more secure than a typical md5 hash. Still, you're advised to wisely choose your password. Don't use a dictionary word; in best case it's a passphrase consisting of upper- and lowercase letters, numbers and special characters.