bugtraq - Re: DotClear Full Path Disclosure Vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1171357839.28815.43.camel@anduril.intranet.cartel-securite.net>
Date: Tue, 13 Feb 2007 10:10:39 +0100
From: Cedric Blancher <blancher@...tel-securite.fr>
To: Raphaël HUCK <raphael.huck@...e.fr>
Cc: bugtraq@...urityfocus.com
Subject: Re: DotClear Full Path Disclosure Vulnerability

Le mardi 13 février 2007 à 08:34 +0100, Raphaël HUCK a écrit :
> But you can use secure software (or modify the unsecure ones you have)

We agree on the fact DotClear must be fixed on this, as for most people,
neither changing the PHP conf nor modify the scripts is an option. Don't
forget who this kind of apps is targetting...

> I said "for example", as I know this is how MediaWiki does:
> if ( ! defined( 'MEDIAWIKI' ) )
>      die( 1 );
> How would you do it?

If you look at the way thoses script are used, they actually need a
specific context, starting with function calls that need variables to be
set. Therefore, I think a more sustainable way of handling this could be
to actually check this very context consistency. You can do this by
testing needed variables value, add success test to funtions, etc. For
instance, adding a test condition around fetch() call in list.php should
do the trick...
Another way of dealing with this could be ye old htaccess trick as
recommended in layout or share directories for instance. But it's just a
workaround to me.

Now, to share my view from a broader point of vue, one should wonder why
hostings does not provide offline repositories. I mean on most of them
your FTP/SCP/whatever root _is_ your webroot. This means any object put
there is accessible online. The fact is not all your webiste contents
need to be directly accessible. Thus, if you shift your webroot to a
dedicated directory, then you can start having PHP script offline.
Take your example: none of the scripts you mention are refered as an
URL. They're all included from other scripts, and thus are safe to put
offline, as inclusion can refer scripts out of webroot. And this way, no
one can call them directly. Period.

I agree this kind of setting is not available to everyone, juste like
PHP configuration. But for thoses who can handle this, it can be a good
security measure. If you have a look at previous DotClear advisories,
you'll understand clearly what it brings ;)
The bad side of this lies in the fact that DotClear and many other apps
are not written with this kind of setting in mind and it's not easy to
achieve (not to mention additional plugins). It's already time consuming
to adapt the application to thoses needs, and a real pain to maintain
it, patching everything each time you have to update...

-- 
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!