CVE-2007-2448: "security flaw in 'svn prop*' commands"

Debian Bug report logs - #428194
CVE-2007-2448: "security flaw in 'svn prop*' commands"

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Florian Weimer <fw@deneb.enyo.de>

To: submit@bugs.debian.org

Subject: CVE-2007-2448: "security flaw in 'svn prop*' commands"

Date: Sat, 09 Jun 2007 21:00:36 +0200

Package: subversion
Version: 1.4.2dfsg1-2
Tags: security
Severity: grave

Subversion 1.4.4 has been released, containing some security fixes:

    * fixed: security flaw in 'svn prop*' commands [CVE-2007-2448] 
          (r25095, -099, -104, -105, -10)

I haven't yet figured out, what the exact problem is, and
subversion.tigris.org appears to be down.  Sorry.

Please mention the name CVE-2007-2448 in the changelog when fixing
this bug.

Message #10 received at 428194@bugs.debian.org (full text, mbox, reply):

From: Peter Samuelson <peter@p12n.org>

To: Florian Weimer <fw@deneb.enyo.de>, 428194@bugs.debian.org

Subject: Re: Bug#428194: CVE-2007-2448: "security flaw in 'svn prop*' commands"

Date: Sat, 9 Jun 2007 15:22:16 -0500

[Message part 1 (text/plain, inline)]

[Florian Weimer]
> Subversion 1.4.4 has been released, containing some security fixes:
> 
>     * fixed: security flaw in 'svn prop*' commands [CVE-2007-2448] 
>           (r25095, -099, -104, -105, -10)
> 
> I haven't yet figured out, what the exact problem is, and
> subversion.tigris.org appears to be down.  Sorry.

I'm pretty sure this is Debian bug #419348.  The security implication
is that a user who has SVN repository access but not shell access can
screw up a repository beyond what is usually possible, making a big
mess for someone to clean up, especially if you are using the old 'bdb'
backend.  I am not sure whether that counts as a security issue that
should be fixed in sarge and etch.  (After all, the user _is_ already
trusted to commit to the repository.)  But if so, we have patches for
both.

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 428194@bugs.debian.org (full text, mbox, reply):

From: Florian Weimer <fw@deneb.enyo.de>

To: Peter Samuelson <peter@p12n.org>

Cc: 428194@bugs.debian.org, control@bugs.debian.org

Subject: Re: Bug#428194: CVE-2007-2448: "security flaw in 'svn prop*' commands"

Date: Sat, 09 Jun 2007 22:29:38 +0200

severity 428194 minor
thanks

* Peter Samuelson:

> [Florian Weimer]
>> Subversion 1.4.4 has been released, containing some security fixes:
>> 
>>     * fixed: security flaw in 'svn prop*' commands [CVE-2007-2448] 
>>           (r25095, -099, -104, -105, -10)
>> 
>> I haven't yet figured out, what the exact problem is, and
>> subversion.tigris.org appears to be down.  Sorry.
>
> I'm pretty sure this is Debian bug #419348.  The security implication
> is that a user who has SVN repository access but not shell access can
> screw up a repository beyond what is usually possible, making a big
> mess for someone to clean up, especially if you are using the old 'bdb'
> backend.  I am not sure whether that counts as a security issue that
> should be fixed in sarge and etch.  (After all, the user _is_ already
> trusted to commit to the repository.)  But if so, we have patches for
> both.

It turns out that this is a different bug, albeit a minor one as well.
From the log:

------------------------------------------------------------------------
r25095 | cmpilato | 2007-05-22 02:44:48 +0200 (Tue, 22 May 2007) | 41 lines
Changed paths:
   M /trunk/subversion/include/svn_repos.h
   M /trunk/subversion/libsvn_repos/fs-wrap.c
   M /trunk/subversion/libsvn_repos/log.c
   M /trunk/subversion/tests/cmdline/svnsync_tests.py

Add new 'svn_repos_check_revision_access' public function which does
the same kind of access checks that, say, svn_repos_get_logs() does,
determining if a repository revision is fully readable, fully
unreadable, or something in-between.

This is more for the benefit of third party tools like ViewVC and hook
scripts than for Subversion's own internal usage.

As is turns out, this also fixes a minor, edge-case security flaw in
the public functions svn_repos_fs_change_rev_prop(),
svn_repos_fs_revision_prop(), and svn_repos_fs_revision_proplist()
which previously failed to factor in changed-path copyfrom source
paths in their revision readability determination like
svn_repos_get_logs() does.  Those aware of the issue think it's a *very
minor* one, and that the benefits of public revisitation of our policy
of including copyfrom-sources in the access determination outweigh the
benefits of secrecy in this case.  We have, however, reserved
CVE-2007-2448 for the tracking of this inconsistency (which is, again,
fixed by this commit).

* subversion/include/svn_repos.h
  (svn_repos_revision_access_level_t): New (copied with mods from fs-wrap.c).
  (svn_repos_check_revision_access): New.

* subversion/libsvn_repos/log.c
  (svn_repos_check_revision_access): New.

* subversion/libsvn_repos/fs-wrap.c
  (rev_readability_level): Moved (and renamed) to svn_repos.h.  All
    users updated to match the new public values.
  (get_readability): Removed.
  (svn_repos_fs_change_rev_prop3, svn_repos_fs_revision_prop,
   svn_repos_fs_revision_proplist): Use svn_repos_check_revision_access() 
    instead of get_readability().

* subversion/tests/cmdline/svnsync_tests.py
  (copy_from_unreadable_dir, copy_with_mod_from_unreadable_dir,
   copy_with_mod_from_unreadable_dir_and_copy): Tweak tests to not
    expect log messages in revisions for which a path is readable but
    its copyfrom-path is not.

------------------------------------------------------------------------

Message #22 received at 428194@bugs.debian.org (full text, mbox, reply):

From: Peter Samuelson <peter@p12n.org>

To: Florian Weimer <fw@deneb.enyo.de>, 428194@bugs.debian.org

Subject: Re: Bug#428194: CVE-2007-2448: "security flaw in 'svn prop*' commands"

Date: Sat, 9 Jun 2007 16:00:33 -0500

[Message part 1 (text/plain, inline)]

tags 428194 pending
thanks

[Florian Weimer]
> It turns out that this is a different bug, albeit a minor one as well.

Well, in any case, we uploaded 1.4.4 yesterday, so I guess I'll
retroactively add the CVE-2007-2448 identifier to the changelog in the
next upload.

I agree that it's a minor issue - how common is it that someone would
copy a file from a restricted part of the repository to an unrestricted
part, then expect the revision properties of that commit to remain
(partially) restricted?  So it doesn't seem worth backporting to etch
or sarge.

Thanks for looking this up.

[signature.asc (application/pgp-signature, inline)]

Message #31 received at 428194-done@bugs.debian.org (full text, mbox, reply):

From: Peter Samuelson <peter@p12n.org>

To: 428194-done@bugs.debian.org

Subject: minor bug CVE-2007-2448 fixed a long time ago, subversion 1.4.4

Date: Fri, 4 Jul 2008 03:33:04 -0500

Version: 1.4.4dfsg1-1

This bug was fixed a long time ago, though I forgot to put the CVE
ident in the changelog.  I've retroactively done that now.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/

Send a report that this bug log contains spam.