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 security fixes for phpmyadmin (PMASA-2009-6)

Posted in advisory/ on October 15, 2009 by Marcus.

On October 13, 2009 developers of phpMyAdmin have published an advisory (PMASA-2009-6) for XSS and SQL Injection vulnerabilities in their product.

Today, on October 15, agency mehrwert - the maintainer of TYPO3 extension phpMyAdmin - has published new packages that fix above mentioned vulnerabilities:

• for TYPO3 4.2, extension version 4.0.5 has been uploaded to the TYPO3 Extension Repository
• for TYPO3 < 4.2, please download extension version 3.5.0 directly from mehrwert webserver

 

(Source: mehrwert's original news item [DE])

Reasons for bugs being introduced with security fixes

Posted in advisory/TYPO3/ on July 31, 2009 by Marcus.

This posting is mainly addressing TYPO3 extensions.

If you are using TYPO3 extension CoolURI and you've followed the TYPO3 Security Team's advice to upgrade in latest advisory (TYPO3-SA-2009-010), you might notice problems with calling a website without parameters.

I'm picking this specific issue to explain why such problems happen from time to time.

 

If you already had to deal with the TYPO3 Security Team, you might remember we are stressing that a small numbers of rules are being followed. Important ones are:

• Do only least necessary modifications to the code to fix a vulnerability!
• Do only integrate security modifications in the new extension version that is going to be uploaded to the TER - no normal bugfixes, no new features.

With these rules we're trying to make sure that every TYPO3 user is able to upgrade/install the new extension version. In a perfect world users won't recognize any change to the previous version - only a security hole would be closed.

So why bugs still appear although such rules are in place?

• Once being informed, extension developers on their own fix a vulnerability and upload the new extension version without further communication/discussion/consulting with the TYPO3 Security Team.
• Extension developers aren't reading our mails and are sneaking in further non-security related code changes with the newly released extension version.
• Security fixes might have side effects. With a complex extension the Security Team is unable to test every functionality the extension is providing.
• Humans do make errors.

We're basically depending on the goodwill of extension developers and hope that they understand their extensions and have well-tested their security-fix in the scope of the complete extension. We make sure that the reported vulnerability is fixed.

I hope you understand and accept the above mentioned reasons for such bugs. We're doing our best to prevent these bugs. Please do never hesitate to follow our advices in TYPO3 Security bulletins - you would risk a compromised TYPO3 installation.

 

Btw., the CoolURI issue happened because the extension developer did not only fix the security vulnerability but also integrated further code changes and did the fixing on his own.

Policy of least disclosure explained

Posted in advisory/TYPO3/ on July 24, 2009 by Marcus.

On the TYPO3 Security Team website section you'll find a paragraph on incident handling. There it is mentioned that the TYPO3 Security Team does follow a policy of least disclosure. Have you ever asked yourself what this actually means?

For the TYPO3 Security Team this means that the team will publish bulletins/advisories for every vulnerability in TYPO3 Core or in TER listed extensions that has been reported and finally fixed. The bulletin itself will only contain the least necessary facts of vulnerabilities that are needed to know if a user might be affected and what the possible impact would be.

The TYPO3 Security Team will not publish exploit or proof of concept code; such critical information is only exchanged between the reporter of the vulnerability, the TYPO3 Security Team itself and either the TYPO3 Core Team or the extension maintainer.

 

The benefits for TYPO3 user:
By subscribing to the announce mailinglist (more on basic steps in my first things first blog post) you'll be informed about any vulnerability found in TYPO3 Core or TER listed extensions. There's no ready-to-be-used exploit code which means that a Black Hat needs to put some efforts in thinking and coding before he's able to exploit a vulnerability.

Needs and expectations by the TYPO3 Security Team:
In order to maintain this least disclosure policy, the TYPO3 Security Team expects to get involved in every vulnerability fixing process. So please contact us if

• you've discovered a vulnerability in TYPO3 Core or a TER listed extension
• you've been reported or found by yourself a vulnerability in your own extension

The TYPO3 Security Team has created an Extension Security Policy some time ago. Please make sure you've read it!

VIGILANCE-VUL-8839 - not a vulnerability

Posted in advisory/ on July 07, 2009 by Marcus.

Today, I stumbled across VIGILANCE-VUL-8839, a newly published to-be advisory covering TYPO3 bugtracker issue #0011369.
Attentive readers of this blog are aware that I've covered exactly this issue in my recent posting on new TYPO3 releases. I also mentioned that this is not a vulnerability. It seems somebody is of different opinion. Challenge accepted.

So why is this not a vulnerability:

The file deny pattern is generally only applied when uploading files onto the TYPO3 system. Such user files matching this pattern won't exist on a TYPO3 installation. The pattern itself is able to be modified by a TYPO3 administrator; by default it prevents php files to be uploaded.
Jumpurl would allow to access all files the web server user account has access to. Prerequisite: a mandatory token is supplied with such request that matches the one TYPO3 is expecting.

Therefore you will only be able to access files with jumpurl if the system is configured to expose such files. AFAIK, this is only used for e.g. PDF documents referenced by newsletters. Such jumpurl links with a valid token are only created by TYPO3 when an author/admin consciously decides to make specific files available.

Independent from that, a typical author will never be able to create jumpurl links to the central TYPO3 configuration file (php file ).

What the core team (with TYPO3 Security Team's approval) has decided:
There's no need at all to (theoretically) allow to create links to this configuration file or configuration directory.

Your system is not more secure after applying the patch! Also the TYPO3 Security Team didn't fix a known vulnerability by that patch. The Security Team is very focused on TYPO3 Security. If we would have considered this to be a vulnerability, we would have published an advisory.

I hope this is more clear for you now. No need to worry! Thanks for listening.