Likes Likes:  0
Resultaten 1 tot 9 van de 9
Geen
  1. #1
    Vietnamese Security Group
    BUG IN APACHE HTTPD SERVER (current version 2.0.47)
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    BUG IN APACHE HTTPD SERVER (current version 2.0.47)



    APACHE HTTPD SERVER (current version 2.0.47):
    ################################################## ########
    How to return files in a Apache Deny All directory.
    The Directives controlling host access may be bypassed even
    if they have not permission to be override.

    11 Jan 2004


    DESCRIPTION

    Apache Web Server allows manage configurations via the main
    httpd.conf file, and via the other configuration files placed
    inside the children web trees, may owned by the user accounts,
    named .htaccess by default. The server administrator further
    controls what Directives may be placed in .htaccess files by
    configuring the AllowOverride Directive in the main httpd.conf
    files.

    If the server admin sets the Deny Directive to All (for example),
    and does not allow the user accounts to modify this Directive in
    their .htaccess file by setting the AllowOverride values without
    the Limit type, his/her users are still able to bypass the Deny
    option by using the ErrorDocument Directive.

    Tested in Apache 2.0.47/RH-Linux/WinXP.


    EXAMPLE

    ################################################## ########
    # In the main httpd.conf file:
    #
    <Directory />
    AllowOverride FileInfo
    Deny From All
    </Directory>
    ################################################## ########

    ################################################## ########
    # In the user's .htaccess file placed in a child directory:

    ErrorDocument 403 /child/dir/fetch.php

    ################################################## ########

    /************************************************** ******/
    <?php
    // In the fetch.php placed in the same directory:

    $url = parse_url( $_SERVER['REQUEST_URI'] );
    @include basename( $url['path'] );

    ?>
    /************************************************** ******/


    In this example, assuming the web server can execute PHP script
    or some scripts/server-includes. By modifying some codes you can
    return other mime file types such as image/gif etc.

    Event if the server does not allow any file parsed (Deny From All),
    the script file fetch.php will still be executed, and it includes
    again and parses any other files in a same directory, which
    indecated by the query variables, to the web client.

    Looking in the source code, I think the missing auth checking is in
    the function ap_process_request_internal() in the file request.c.
    One of the major changes in Apache 2.0 is to the internal redirect
    mechanism. To prevent the code from falling out of sync again in the
    current directory, the configuration comparing between two config
    directories may bypass the authentication checking again. That
    explains why this vulnerability (if any?) can only done if the
    redirect ErrorDocument file is placed in the same request directory.



    FIX

    Do not skip auth checker even if the per_dir_config member value
    doesn't change in the ap_process_request_internal() function.


    NOTE

    I post this issue in the public mailing list, because I think this
    vuln is not exploitable by a remote attacker. If something were
    wrong, drop a line to me.


    Vietnamese Security Group
    Trung - caothuvolam - trungonly@yahoo.com
    http://www.security.com.vn

    31 Nui Truc st. Ba Dinh dist. Ha Noi . Vietnamese
    Phone : 84.4.8465701 / Fax: 84.4.8465701

  2. #2
    Vietnamese Security Group
    BUG IN APACHE HTTPD SERVER (current version 2.0.47)
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: BUG IN APACHE HTTPD SERVER (current version 2.0.47)

    In-Reply-To: <20040131211851.30391.qmail@www.securityfocus.com>

    Note : of course it affected also in the current version 2.0.48 ( tested)

    Vietnamese Security Group
    www.security.com.vn


    >Received: (qmail 2149 invoked from network); 3 Feb 2004 02:12:35 -0000
    >Received: from outgoing3.securityfocus.com (205.206.231.27)
    > by mail.securityfocus.com with SMTP; 3 Feb 2004 02:12:35 -0000
    >Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20])
    > by outgoing3.securityfocus.com (Postfix) with QMQP
    > id 9667FA3153; Mon, 2 Feb 2004 18:23:17 -0700 (MST)
    >Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
    >Precedence: bulk
    >List-Id: <bugtraq.list-id.securityfocus.com>
    >List-Post: <mailto:bugtraq@securityfocus.com>
    >List-Help: <mailto:bugtraq-help@securityfocus.com>
    >List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
    >List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
    >Delivered-To: mailing list bugtraq@securityfocus.com
    >Delivered-To: moderator for bugtraq@securityfocus.com
    >Received: (qmail 31275 invoked from network); 31 Jan 2004 21:08:29 -0000
    >Date: 31 Jan 2004 21:18:51 -0000
    >Message-ID: <20040131211851.30391.qmail@www.securityfocus.com>
    >Content-Type: text/plain
    >Content-Disposition: inline
    >Content-Transfer-Encoding: binary
    >MIME-Version: 1.0
    >X-Mailer: MIME-tools 5.411 (Entity 5.404)
    >From: Vietnamese Security Group <security@security.com.vn>
    >To: bugtraq@securityfocus.com
    >Subject: BUG IN APACHE HTTPD SERVER (current version 2.0.47)
    >
    >
    >
    >APACHE HTTPD SERVER (current version 2.0.47):
    >################################################# #########
    >How to return files in a Apache Deny All directory.
    >The Directives controlling host access may be bypassed even
    >if they have not permission to be override.
    >
    >11 Jan 2004
    >
    >
    >DESCRIPTION
    >
    >Apache Web Server allows manage configurations via the main
    >httpd.conf file, and via the other configuration files placed
    >inside the children web trees, may owned by the user accounts,
    >named .htaccess by default. The server administrator further
    >controls what Directives may be placed in .htaccess files by
    >configuring the AllowOverride Directive in the main httpd.conf
    >files.
    >
    >If the server admin sets the Deny Directive to All (for example),
    >and does not allow the user accounts to modify this Directive in
    >their .htaccess file by setting the AllowOverride values without
    >the Limit type, his/her users are still able to bypass the Deny
    >option by using the ErrorDocument Directive.
    >
    >Tested in Apache 2.0.47/RH-Linux/WinXP.
    >
    >
    >EXAMPLE
    >
    >################################################# #########
    ># In the main httpd.conf file:
    >#
    ><Directory />
    > AllowOverride FileInfo
    > Deny From All
    ></Directory>
    >################################################# #########
    >
    >################################################# #########
    ># In the user's .htaccess file placed in a child directory:
    >
    >ErrorDocument 403 /child/dir/fetch.php
    >
    >################################################# #########
    >
    >/************************************************** ******/
    ><?php
    >// In the fetch.php placed in the same directory:
    >
    >$url = parse_url( $_SERVER['REQUEST_URI'] );
    >@include basename( $url['path'] );
    >
    >?>
    >/************************************************** ******/
    >
    >
    >In this example, assuming the web server can execute PHP script
    >or some scripts/server-includes. By modifying some codes you can
    >return other mime file types such as image/gif etc.
    >
    >Event if the server does not allow any file parsed (Deny From All),
    >the script file fetch.php will still be executed, and it includes
    >again and parses any other files in a same directory, which
    >indecated by the query variables, to the web client.
    >
    >Looking in the source code, I think the missing auth checking is in
    >the function ap_process_request_internal() in the file request.c.
    >One of the major changes in Apache 2.0 is to the internal redirect
    >mechanism. To prevent the code from falling out of sync again in the
    >current directory, the configuration comparing between two config
    >directories may bypass the authentication checking again. That
    >explains why this vulnerability (if any?) can only done if the
    >redirect ErrorDocument file is placed in the same request directory.
    >
    >
    >
    >FIX
    >
    >Do not skip auth checker even if the per_dir_config member value
    >doesn't change in the ap_process_request_internal() function.
    >
    >
    >NOTE
    >
    >I post this issue in the public mailing list, because I think this
    >vuln is not exploitable by a remote attacker. If something were
    >wrong, drop a line to me.
    >
    >
    >Vietnamese Security Group
    >Trung - caothuvolam - trungonly@yahoo.com
    >http://www.security.com.vn
    >
    >31 Nui Truc st. Ba Dinh dist. Ha Noi . Vietnamese
    >Phone : 84.4.8465701 / Fax: 84.4.8465701
    >


  3. #3
    =?ISO-8859-15?Q?Andr=E9?= Malo
    BUG IN APACHE HTTPD SERVER (current version 2.0.47)
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: BUG IN APACHE HTTPD SERVER (current version 2.0.47)

    * Vietnamese Security Group <security@security.com.vn> wrote:

    [snakeoil]

    > Event if the server does not allow any file parsed (Deny From All),
    > the script file fetch.php will still be executed, and it includes
    > again and parses any other files in a same directory, which
    > indecated by the query variables, to the web client.


    Deny from all (in conclusion with some other) denies HTTP access on some
    criteria. It doesn't suppose to protect against access from inside the
    server.


    > I post this issue in the public mailing list, because I think this
    > vuln is not exploitable by a remote attacker. If something were
    > wrong, drop a line to me.


    Next time, try a user support forum first. Thanks.

    nd

  4. #4
    =?ISO-8859-15?Q?Andr=E9?= Malo
    BUG IN APACHE HTTPD SERVER (current version 2.0.47)
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: BUG IN APACHE HTTPD SERVER (current version 2.0.47)

    * langtuhaohoa caothuvolam <trungonly@yahoo.com> wrote:

    > Deny From All: In this way they can access from outside the server.


    You mean: An attacker needs to place such a script on the server, which
    includes the requested uri.
    If he's able to do so, he can

    (a) read the file anyway
    (b) simply open it from inside the script using normal file operations.

    I cannot see a vuln here. If he's able to take the actions described above,
    one has *real* trouble on the server.

    This seems to me the same topic as the mod_perl hijacking. If you don't trust
    your users, don't let them execute code from inside the server.

    nd

  5. #5
    langtuhaohoa caothuvolam
    BUG IN APACHE HTTPD SERVER (current version 2.0.47)
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: BUG IN APACHE HTTPD SERVER (current version 2.0.47)

    In-Reply-To: <20040203063933.12546429.nd@perlig.de>

    >From: =?ISO-8859-15?Q?Andr=E9?= Malo <nd@perlig.de>
    >
    >
    >Deny from all (in conclusion with some other) denies HTTP access on some
    >criteria. It doesn't suppose to protect against access from inside the
    >server.
    >


    Deny From All: In this way they can access from outside the server.
    AllowOverride FileInfo (only): Apache must suppose to protect against .htaccess override from inside the server.
    In fact, Apache should check for config permission again in the ap_process_request_internal() function.


    >
    >> I post this issue in the public mailing list, because I think this
    >> vuln is not exploitable by a remote attacker. If something were
    >> wrong, drop a line to me.

    >
    >Next time, try a user support forum first. Thanks.
    >
    >nd
    >

    I think it's a vuln, in fact I confirmed someones for that. Then I post it into a bug-tracker list instead of in a user support forum. Thanks for your comment.



  6. #6
    Dan Yefimov
    BUG IN APACHE HTTPD SERVER (current version 2.0.47)
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: BUG IN APACHE HTTPD SERVER (current version 2.0.47)

    On Wed, 4 Feb 2004, [ISO-8859-15] André Malo wrote:

    > * langtuhaohoa caothuvolam <trungonly@yahoo.com> wrote:
    >
    > > Deny From All: In this way they can access from outside the server.

    >
    > You mean: An attacker needs to place such a script on the server, which
    > includes the requested uri.
    > If he's able to do so, he can
    >
    > (a) read the file anyway
    > (b) simply open it from inside the script using normal file operations.
    >
    > I cannot see a vuln here. If he's able to take the actions described above,
    > one has *real* trouble on the server.
    >
    > This seems to me the same topic as the mod_perl hijacking. If you don't trust
    > your users, don't let them execute code from inside the server.
    >

    The matter here is not the trust. The matter is that restrictions inflicted by
    server admin shouldn't be able to be avoided by using, for example, the
    described trick. This is of course not a vuln, but this is a design flaw that
    can have some security implications and should be fixed anyway.
    As for mod_perl hijacking. Mod_perl has been designed only to speed up
    perl CGI scripts execution unrelated to whether server admin trusts his/her
    users or not (and mod_php serves the like objective). Thus under mod_perl
    control scripts should be run in the same environment as if they were run in a
    common way (by forking, closing all file handles except for connected socket and
    executing perl interpreter). This means mod_perl must somehow hide all those
    file handles from the script being executed. If mod_perl doesn't do that, it's
    not simply a design flaw, but it's also a serious security flaw.
    --

    Sincerely Your, Dan.



  7. #7
    Seth Arnold
    BUG IN APACHE HTTPD SERVER (current version 2.0.47)
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: BUG IN APACHE HTTPD SERVER (current version 2.0.47)

    --r5Pyd7+fXNt84Ff3
    Content-Type: text/plain; charset=us-ascii
    Content-Disposition: inline
    Content-Transfer-Encoding: quoted-printable

    On Thu, Feb 05, 2004 at 02:55:41AM +0300, Dan Yefimov wrote:
    > This means mod_perl must somehow hide all those file handles from the
    > script being executed. If mod_perl doesn't do that, it's not simply a
    > design flaw, but it's also a serious security flaw.


    Dan, do you have any suggestions how portions of a process should 'hide'
    file handles from other portions of its own address space? [1]

    Please remember that mod_perl, mod_python, mod_php, etc., were all written
    to run scripts inside the address space of apache to help speed execution,
    by removing the fork()/exec() slowdown required to provide a standard
    privilege barrier. This speed comes at a cost that is acceptable for
    some users and is unacceptable for other users.

    Consider, without loss of generality, a server being used to host
    amazon.com. Amazon could run their perl scripts in mod_perl; as the
    only user of the system (and presumably they have internal controls
    to ensure malicious code does not run on their webservers) this is an
    appropriate choice.

    Consider a website hosting provider, such as your favourite commercial
    ISP. They can NOT trust their mutually distrusting users to run code
    in their webserver's address space -- so, they cannot run mod_perl,
    mod_python, mod_php, etc.

    Presumably, the hosting providers can simply buy twice as many machines
    and slightly raise their prices to their customers.

    Whether to use mod_perl, mod_python, mod_php, etc., is strictly a
    per-site decision that every administrator has to make for him or
    herself, based on that site's security policy.

    Thanks


    [1] I'll note that Immunix's Secured Linux Distribution provides exactly
    such a mechanism, in the form of "change_hat Apache", a patch to our
    Apache package that makes a system call specific to Immunix's SubDomain
    mandatory access control mechanism. While this is great for us, it
    certainly isn't portable to all the platforms that Apache may run on.

    --=20
    Immunix Secured Linux Distribution: http://immunix.org/

    --r5Pyd7+fXNt84Ff3
    Content-Type: application/pgp-signature
    Content-Disposition: inline

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.1 (GNU/Linux)

    iD8DBQFAIyjy+9nuM9mwoJkRAnRSAJ0R4/XricudnOpl7mH9n528QmgIPACeN5eS
    1rhC5yNNICLcaq7aDh4PWjI=
    =PfVr
    -----END PGP SIGNATURE-----

    --r5Pyd7+fXNt84Ff3--

  8. #8
    Tyler Larson
    BUG IN APACHE HTTPD SERVER (current version 2.0.47)
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: BUG IN APACHE HTTPD SERVER (current version 2.0.47)

    I can see how this could *possibly* be an issue.

    In theory, a user on a shared system could use an ErrorDocument directive to
    view file that the apache user/group had access to, but the user didn't (such
    as another user's .htaccess file. The directive would look something like this:

    ErrorDocument 404 /~otheruser/.htaccess

    However, in my version of apache (2.0.48) it doesn't work:

    Given a the set of files below:

    -- /www/foo/.htaccess --
    [see below] (no other files in this directory)
    -- EOF --

    -- /www/foo/bar/.htaccess --
    Order Deny, Allow
    Deny from all
    -- EOF --

    -- /www/foo/bar/secret --
    you saw my secret!
    -- EOF --

    And I tried the following values in in /www/foo/.htaccess

    ----
    ErrorDocument 404 /foo/bar/secret
    ----
    ErrorDocument 404 /foo/.htaccess
    ----
    #I knew this one had no chance
    ErrorDocument 404 /etc/passwd
    ----

    For the first two .htaccess files, I got this response:
    -----------
    Not Found
    The requested URL /foo/baz was not found on this server.

    Additionally, a 403 Forbidden error was encountered while trying to use an
    ErrorDocument to handle the request.
    Apache/2.0.48 (Fedora) Server at localhost Port 80
    -----------

    For the last .htaccess file, I got this response:
    -----------
    Not Found
    The requested URL /foo/baz was not found on this server.

    Additionally, a 404 Not Found error was encountered while trying to use an
    ErrorDocument to handle the request.
    Apache/2.0.48 (Fedora) Server at localhost Port 80
    -----------

    The reason why the last one didn't work was because ErrorDocument files are
    relative to the server's DocumentRoot, not the filesystem root.

    The first request didn't work because of my "Deny From All" in
    foo/bar/.htacess, while the second request failed because of the restrictions
    placed by default on files starting with ".ht".

  9. #9
    Todd C. Campbell
    BUG IN APACHE HTTPD SERVER (current version 2.0.47)
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: BUG IN APACHE HTTPD SERVER (current version 2.0.47)

    On Thu, Feb 05, 2004 at 02:55:41AM +0300, Dan Yefimov wrote:
    > On Wed, 4 Feb 2004, [ISO-8859-15] Andr? Malo wrote:
    > The matter here is not the trust. The matter is that restrictions inflicted by
    > server admin shouldn't be able to be avoided by using, for example, the
    > described trick. This is of course not a vuln, but this is a design flaw that
    > can have some security implications and should be fixed anyway.
    > As for mod_perl hijacking. Mod_perl has been designed only to speed up
    > perl CGI scripts execution unrelated to whether server admin trusts his/her
    > users or not (and mod_php serves the like objective). Thus under mod_perl
    > control scripts should be run in the same environment as if they were run in a
    > common way (by forking, closing all file handles except for connected socket and
    > executing perl interpreter). This means mod_perl must somehow hide all those
    > file handles from the script being executed. If mod_perl doesn't do that, it's
    > not simply a design flaw, but it's also a serious security flaw.



    I do not believe this is a function of the web server. For example any
    per script can read in a file that is not contained within the document
    root, as so long as the process has sufficient priviledges to read the
    file. Any files that you do not want to be read by the web
    server should be permissioned as such.

    You argue that the server admin should be able to set restrictions to
    the server. Here I agree, however, that restrictive mechanism lies
    within the filesystem permissions and is not a function of the
    webserver. When it comes down to it, you are trying to restrict read
    access for the files in question, why would it be any different than
    restricting read access for any other user on the system?

    .tidd.

Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics