about
blog
tutorials
TYPO3 Association 2nd Quarterly Report 2009
Posted in TYPO3/ on August 18, 2009 by .
I'd like to use this posting to point to an unfortunately underestimated or even unknown possibility to get to know what's going on in the TYPO3 world.
Every three months, the TYPO3 Association is publishing (or at least is supposed to be) a Quarterly Report. It's a nice way to get informed about what several (official) TYPO3 Committees / Teams are currently doing or planning.
Today, the T3A has published the 2nd Quarterly Report for 2009. The TYPO3 Security Team is also mentioned in this document.
In detail:
- Several TYPO3 Security Team members met at the TYPO3 Developer Days 2009. Such official TYPO3 events are welcome possibility to feel again the community / team spirit that might got missing during the year. It also allows to discuss things that are better to be addressed in face-to-face meetings.
- The TYPO3 Security Team lacks of new members. New ones should be security-minded people with a deeper knowledge in TYPO3 and willing to regularily spend a certain amount of time on the team work.
- A newly created page called resources has been added to the TYPO3 Security Team section on typo3.org. It already keeps several documents that help to stay up-to-date on TYPO3 Security - and it keeps growing.
- New team internal project called Incident Handling System (IHS).
Especially the last item needs a bit of explanation:
The TYPO3 Extension Repository (TER) is constantly growing. With about 4000 different extensions, the TYPO3 Security Team spends almost 100% of its time on extension vulnerabilities.
The bulletin publishing process alone can eat up several hours for a single bulletin. The bulletin is a standard content element. It needs to be in a common form. Every mentioned extension and linked resource has to be manually inserted, links need to be double-checked. Vulnerable extension versions need to be removed from the repository. Bulletin information must be reflected in the according issue in the separate TYPO3 Security Team Trouble Ticket System. The bulletins then will be proof read, comments reflected in the bulletin. New extension versions with the security fixes need to be uploaded. Besides to the bulletin, a dedicated mailing list posting and news item has to be created.
You certainly understand that we really like to reduce the time spend on such tasks. The planned Incident Handling System will change that. Bulletins by default will be in a common structure, extensions and their versions can be selected, automatically added and vulnerable extension versions marked insecure. Mailing list posting and news item are instantly created when publishing the bulletin.
I hope to see it implemented soon.
If you or your company is able to contribute resources (manpower or money) to this IHS project, please don't hesitate to contact the TYPO3 Security Team! Any help is appreciated.
WAF blacklist rules - an idea to follow?
Posted in TYPO3/ on August 15, 2009 by .
The TYPO3 Security Team currently asks for your opinion on providing WAF blacklist rules that address vulnerabilities in TYPO3 Core and TYPO3 third-party extension.
If you are a TYPO3 agency or a TYPO3 hoster, this might be an instant help to protect against newly published vulnerabilities.
An use case would be the immediate installation of such rules when a new TYPO3 bulletin has been published. You then would be protected against upcoming exploits in no time. Afterwards, you have plenty of time to upgrade e.g. a vulnerable extension version in each of your TYPO3 installations.
So please help the TYPO3 Security Team and decide if it's worth to put further efforts into it. Participate in this kind of survey!
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.
