Posted in advisory/TYPO3/ on July 24, 2009 by .
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
The TYPO3 Security Team has created an Extension Security Policy some time ago. Please make sure you've read it!
Posted in TYPO3/ on July 16, 2009 by .
By today, new TYPO3 releases (patch versions 4.0.13, 4.1.12, 4.2.8) have been published.
Although there are no security fixes in them, they contain desirable security improvements as listed below:
Before, jumpurl allowed to download any file ressource (if you provide the correct validation hash). Now, by default PHP files are no longer able to be downloaded and access to files below typo3conf directory is completely denied.
A lot of TYPO3 admins forgot to delete the ENABLE_INSTALL_TOOL file after using the install tool which exposes a risk. I've covered that by a blog post and recommended to set up a cronjob for it. Now, this file is automatically deleted if it's older than one hour. During development you can suppress this behaviour by setting the file content to "KEEP_FILE".
Update: Michael Stucki has written a nice posting about this new behaviour on buzz.typo3.org.
Posted in others/ on July 15, 2009 by .
After having canceled one of my mobile phone contracts I took the change to actual check recent bills. That was quite surprising (should have done this earlier!).
o2 Germany by default offers two different billing methods (there are further packages that require a monthly fee); per volume and per time. It seems in March 2008 I canceled an addon package (email stuff) and accidentally switched to volume based billing.
This made me pay 9,22 EUR per MB (1 MB could be one page on a website with a few images). Curious as I am, I calculated that for this 1 MB I could be online with time based billing for 102 minutes (billing is 0,09 EUR per minute). 102 minutes would result in 5,5 GB transfer with offered (theoretical) maximum speed of 7,2 MBit/s.
Paying about 9 EUR and getting 1 MB with volume based billing versus 5,5 GB in time based billing!! What would you choose? Interesting business model, isn't it?
I still wonder if there's any use case where choosing volume based billing is cheaper than time based billing? Like connecting to a web server and sending keepalive packets only every two minutes?
At least, after presenting the figures (1 MB vs. 5,5 GB), o2's Customer Care gave me a little refund. I'm now using a package with a monthly fee but "unlimited traffic". Stupid me.
Posted in advisory/ on July 07, 2009 by .
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.
Posted in TYPO3/ on July 05, 2009 by .
Some days ago, we've restructured the TYPO3 Security Team section on typo3.org. In specific we reduced the number of menu items to a minimum. Additionally there's a new page called Resources with all kind of helpful information for TYPO3 administrators and developers. You'll find, among others, references to security related tutorials, slides and videos.
If you are interested in TYPO3 security this page is now a nice starting point.
What's your opinion? What is still missing? Are there any resources on the internet that should be referenced to from the TYPO3 Security Team pages? Also helping hands on improving the (slightly outdated but still valid) Security Cookbook are highly appreaciated.
Please help us to support you on TYPO3 security!