[Full-Disclosure] Advisory 08/2004: Subversion remote vulnerability

From: Stefan Esser (s.esser_at_e-matters.de)
Date: 05/19/04

  • Next message: Jason Coombs: "Re: [Full-Disclosure] Slowly down the drain" 
    To: full-disclosure@lists.netsys.com, bugtraq@securityfocus.com
Date: Wed, 19 May 2004 08:39:54 +0200

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

                               e-matters GmbH
                              www.e-matters.de

                          -= Security Advisory =-

         Advisory: Subversion remote vulnerability
     Release Date: 2004/05/19
    Last Modified: 2004/05/19
           Author: Stefan Esser [s.esser@e-matters.de]

      Application: Subversion <= 1.0.2
         Severity: A vulnerability within Subversion allows remote
                   compromise of Subversion servers.
             Risk: Critical
    Vendor Status: Vendor is releasing a bugfixed version.
        Reference: http://security.e-matters.de/advisories/082004.html

    Overview:

       Quote from: http://subversion.tigris.org
       
       "The goal of the Subversion project is to build a version control system
        that is a compelling replacement for CVS in the open source community.
        The software is released under an Apache/BSD-style open source license.
       
        Features of Subversion
        
        * Most current CVS features
        * Directories, renames, and file meta-data are versioned
        * Commits are truly atomic
        * Apache network server option, with WebDAV/DeltaV protocol
        * Standalone server option
        * Branching and tagging are cheap (constant time) operations
        * Natively client/server, layered library design
        * Client/server protocol sends diffs in both directions
        * Costs are proportional to change size, not data size
        * Efficient handling of binary files
        * Parseable output"
        
       Subversion versions up to 1.0.2 are vulnerable to a date parsing
       vulnerability which can be abused to allow remote code execution
       on Subversion servers and therefore could lead to a repository
       compromise.
          
       
    Details:
       
       Similar to the libneon issue a manual scan for common programming errors
       revealed an unsafe call to sscanf() in one of Subversions date parsing
       functions.
       
       When Subversions tries to convert a string into an apr_time_t it falls
       back to the vulnerable sscanf() to decode old-styled date strings.
       This function is exposed to an external attacker through a DAV2 REPORT
       query or a get-dated-rev svn-protocol command.
       
       Both ways have been proven exploitable, but exploiting through the
       DAV2 protocol is somewhat harder because the date string has to be
       in utf-8 format. On the other hand exploiting through the svn-protocol
       is a trivial standard stackoverflow with the exception that whitespace
       and the '\0' character is forbidden.
       
       And as a sidenotice: Exploiting this stackoverflow is even possible
       when Propolice or similar protections are in place because a lot of
       fancy things can be done by overwriting the function parameters.
          

    Proof of Concept:

       e-matters is not going to release an exploit for this vulnerability to
       the public.
       

    Disclosure Timeline:

       02. May 2004 - Subversion developers and vendor-sec were notified
                      by email
       03. May 2004 - Subversion vendor started their own analysis of the issue
                      and started compiling a list of big repositories to
                      receive pre-notifications
       11. May 2004 - Big subversion repositories (not already contacted
                      through vendor-sec) got pre-notified
       19. May 2004 - Coordinated Public Disclosure

       
    CVE Information:

       The Common Vulnerabilities and Exposures project (cve.mitre.org) has
       assigned the name CAN-2004-0397 to this issue.

    Recommendation:

       Exploiting this vulnerability on not heavily protected servers is trivial
       even for beginners, therefore it is strongly recommended to update
       immediately. Even Propolice users aren't safe because overwriting function
       arguments allows some fancy exploits.
       
       
    GPG-Key:

       http://security.e-matters.de/gpg_key.asc
        
       pub 1024D/3004C4BC 2004-05-17 e-matters GmbH - Securityteam
       Key fingerprint = 3FFB 7C86 7BE8 6981 D1DA A71A 6F7D 572D 3004 C4BC

    Copyright 2004 Stefan Esser. All rights reserved.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.0.6 (GNU/Linux)
    Comment: For info see http://www.gnupg.org

    iD8DBQFAqV5Ib31XLTAExLwRAjb6AJ9r+ji0jpYK+idA5Gj3IDRsoLAcFwCgyr2m
    k5m7y6DFOS30aAfJs1p58v8=
    =Ct/a
    -----END PGP SIGNATURE----- 

    -- 
--------------------------------------------------------------------------
 Stefan Esser                                        s.esser@e-matters.de
 e-matters Security                         http://security.e-matters.de/
 GPG-Key                gpg --keyserver pgp.mit.edu --recv-key 0xCF6CAE69 
 Key fingerprint       B418 B290 ACC0 C8E5 8292  8B72 D6B0 7704 CF6C AE69
--------------------------------------------------------------------------
 Did I help you? Consider a gift:            http://wishlist.suspekt.org/
--------------------------------------------------------------------------
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
  • Next message: Jason Coombs: "Re: [Full-Disclosure] Slowly down the drain"

    Relevant Pages