about
blog
tutorials
TYPO3 CMS 4.0 (showUid) exploit - not a vulnerability
Posted in exploit/TYPO3/ on August 06, 2009 by .
Today, a "TYPO3 exploit" appeared on a well-known exploits platform/database website.
The title is TYPO3 CMS 4.0 (showUid) Remote SQL Injection Vulnerability.
Quote:
Vulnerability:
http://www.host.com/index.php?id=[xxx][showUid]=[SQL-injection]&cHash=[xxx]
SQL-injection:
-1+union+select+username,2,password,4,5,6,7+from+be_users--
Admin Panel: /typo3/index.php
The fact that I'm actually writing on it once again prooves that there is no such vulnerability.
In detail:
First of all, the TYPO3 4.0 branch is quite old but still supported in regards to security fixes. If you are using a TYPO3 4.0.X version, you might consider to upgrade to at least 4.1 branch. Soon, the new TYPO3 minor version 4.3.0 will be published which means end of support for TYPO3 4.0.
The showUid parameter is generally used in third-party TYPO3 extensions - not in TYPO3 Core. Together with the tslib_pibase library, showUid is used to display single (database) record details. The library provides access to the parameter value; it's up to the extension developer to sanitize all user-supplied input before they are used in e.g. database queries. The TYPO3 Security Team section on the typo3.org website provides several tutorials on this topic.
The exploit request example does not and will not work as such - not on one single TYPO3 installation out there. It always needs a TYPO3 third-party extension to be involved.
Additionally, a blackhat has to be really lucky because he needs to find a vulnerable TYPO3 extension first. Good luck with that - the TYPO3 Security Team does its best to keep the official TYPO3 extension repository clean.
If I were the guy who has uploaded this useless piece of "exploit code", I'd be pretty embarrassed now.
Considering above mentioned facts, the "exploit code" is more like a general article on SQL injection. Nothing more.
Conclusion: TYPO3 users don't have to worry about it.
Whitepaper "Selecting a secure Open Source CMS"
Posted in TYPO3/ on August 03, 2009 by .
In the last week, ZION Security - a company that is "securing web applications" - has published a whitepaper on "Selecting a secure Open Source Content Management System".
In my opinion, some information is missing in this document, some information is wrong.
Following are my personal comments (page-based on the PDF):
PAGE 5:
Drupal - "High quality platform"
This positive criteria is only mentioned for Drupal. As reader I'm asking myself what does this exactly means and why only Drupal qualifies for it.
Drupal - Extensive documentation
TYPO3 also offers extensive Core documentation. Please have a look at
http://typo3.org/documentation/document-library/core-documentation/!
Drupal - Real multi-site-feature
This is a default core feature in all currently supported TYPO3 versions, too.
(1 installation in file system manages different domains)
Drupal - Powerful templating system. Any [...] template can be easily converted to Drupal.
IMHO, the easiest solution in TYPO3 is by using the widely known TemplaVoila extension. With an existing layout - one HTML file with referenced css/js files - and sample content on it, it's a matter of minutes to create a basic "mapping". There's no need to modify this html document, it just needs to be uploaded as is. With a wizard you decide which CMS records (menu, columns, teaser, etc..) are to be shown where. This is graphical based (TemplaVoila understands the html structure); you click on the sample content of the above mentioned html page and tell, what is generally to be displayed at this location.
TYPO3: missing ECMS features
All currently officially supported TYPO3 versions provide (aka "what makes TYPO3 different from the other CMS")
- versioning
- localization
- workspaces (different draft workspaces, live workspace)
- customizable publishing workflow ("copy the publishing process of printing media")
- tree-based website structure
- really extensive very granular user (rights) management
- clear separation between TYPO3 frontend (website as shown to website users) and TYPO3 backend (administration interface)
- extension management in TYPO3's administration interface (installing/upgrading extensions from the central TYPO3 extension repository [TER] is a matter of seconds; you don't have to manually download modules/extensions and to upload them to the website file system)
PAGE 6:
TYPO3 - development lifecycle for extensions is complicated
I cannot follow this argument at all. The only restriction in development lifecycle is the need to set version numbers of extensions.
PAGE 11f:
Any mentioned time offset between the disclosure of a vulnerability and
the available fix is completely wrong.
Example 1 - civserv extension:
- fix available: June 16, 2009 (ext:civserv v4.3.3)
- bulletin/advisory available: June 16, 2009 (TYPO3-SA-2009-007)
Fix and advisory have been published at the same time - I did it myself.
I guess the mentioned time offset is based on time difference between secunia's release date and last update (Secunia SA35479). I furthermore guess that on April 19, Secunia only added the CVE ID.
I'd really like to see this information fixed in the whitepaper. The whitepaper author failed to actually look up the mentioned example issues and is therefore publishing wrong data. Then you additionally have to slightly modify the red-box conclusion on page 20.
To my knowledge - I can only say this for sure from beginning 2008 when I joined the Security Team - in the history of TYPO3 there was never a vulnerability disclosed before a security fix was available. Why that you might ask - choose one:
- security researchers don't care about TYPO3 (probably not)
- security researchers do contact us first (responsable disclosure)
I consider this to be a sign of appreciation. We're kindly working together with any vulnerability reporter, keep them up-to-date, give them proper credits. We communicate in a nicely way, reporters and extension developers do not hesitate to contact us in case of questions.
At conferences I often hear that the TYPO3 Security Team has a good reputation among the TYPO3 Community.
Here's a quote from a vulnerability reporter (employee of Raiffeisen Informatik Austria):
"The Typo3 Security Team were very quick to respond to the issue, and I found them very good to work with during the disclosure process. If only some larger companies were so easyto work with, and responsive."
(http://c22blog.wordpress.com/2009/01/20/typo3-weak-encryption-key/)
PAGE 15:
You're right about the password policy. Thanks for pointing to this problem. As a result of this whitepaper, this problem is about to be addressed in the near future.
PAGE 16:
In the TYPO3 Security Team website section there's a page that points to ressources about secure coding in regards to TYPO3.
http://typo3.org/teams/security/resources/
PAGE 20:
Quote: "[...] more importantly the vulnerabilities in Drupal have lesser impact when compared to TYPO3 and Joomla! vulnerabilities."
Well, it depends what kind of rating you apply. If you're using the Common Vulnerability Scoring System (CVSS) [the higher, the worse] and doing it for CMS Core only issues in 2008 it makes
- a total score of 167.2 for Drupal vs. 19.4 for TYPO3
- an average score of 5.57 for Drupal vs. 4.85 for TYPO3
Source: Comparison of PHP-based CMS
In the end I'd like to add that I'm not happy that the author is also considering third-party modules in this whitepaper (or at least the way the whitepaper author is mixing them up in the vulnerability issue examples). For TYPO3 and AFAIK also for Drupal, there are no restrictions in place that prevent uploads of insecure/insuffciently secure extensions/modules to the central third-party module repository. It's the Security Teams' task to keep the repositories safe.
I'd rather see a whitepaper on CMS Cores only.
Reasons for bugs being introduced with security fixes
Posted in advisory/TYPO3/ on July 31, 2009 by .
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 .
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!
New TYPO3 releases (patch versions)
Posted in TYPO3/ on July 16, 2009 by .
No security fixes but security improvements
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:
- file deny pattern is applied to jumpurl (4-0, 4-1, 4-2)
- automatic deletion of ENABLE_INSTALL_TOOL file (4-1, 4-2)
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.
