Package: python-dulwich Version: 0.8.5-2 Severity: normal Control: tag -1 + security fixed-upstream
This is like CVE-2014-9390, except without the part where it makes any attempt to avoid paths involving ".git/". So if someone uses dulwich to checkout a tree and then does something there with git proper, we get all the problems of CVE-2014-9390, but without any need for a case-insensitive filesystem: this would be directly exploitable on a standard Debian system, assuming you had some program that actually used dulwich to checkout a tree onto the filesystem. I believe this is what the security team calls "local (remote)". I found the problem described in <https://lists.launchpad.net/dulwich-users/msg00827.html>: ,----[ Re: Git vulnerability CVE-2014-9390 ] | To: Andi McClure <andi.m.mcclure@xxxxxxxxx> | From: Gary van der Merwe <garyvdm@xxxxxxxxx> | Date: Fri, 19 Dec 2014 00:57:33 +0200 | Cc: dulwich-users <dulwich-users@xxxxxxxxxxxxxxxxxxx> | In-reply-to: <CAJDLOYLGjkZrFVTYtd=zkaipnzgbs28kktnxwoxyunoz5md...@mail.gmail.com> | | On Thu, Dec 18, 2014 at 11:45 PM, Andi McClure <andi.m.mcclure@xxxxxxxxx> wrote: | > | > News is going around today about a potential-remote-code-execution vulnerability in the standard git clients: | > | > https://github.com/blog/1938-git-client-vulnerability-announced | > | > Is Dulwich potentially affected? | | Yes. And not only on case insensitive file systems, like with git, but | always :-( | | I've attached a file to demonstrate it. It creates a repo with a | commit of a .git/hooks/pre-commit file. Git prevents writing this file | to the working tree, but dulwich happily writes it out. | | /tmp % ./cve-2014-9390-create.py | /tmp % cd cve-2014-9390-repo.git | /tmp/cve-2014-9390-repo.git (git)-[master] % git reset --hard | error: Invalid path '.git/hooks/pre-commit' | HEAD is now at 1c27312 Evil commit | /tmp/cve-2014-9390-repo.git (git)-[master] % dulwich reset --hard | /tmp/cve-2014-9390-repo.git (git)-[master] % git commit -m "test" --allow-empty | You just got cracked! (not really but you could have been!) | [master 29a7100] test | | For my own use cases of dulwich, I'm not affected by this as I only | ever read and write directly to repos with dulwich with out checking | out trees to a working tree. Do other users actually use the dulwich | index module, or porcilian commands. | | How do we fix this? I assume we start by filtering what we write in | dulwich.index.build_index_from_tree? Filtering the case sensitive and | case insensitive cases is easy, but some of the other edge cases | ("git~1" on windows, ".g\u200cit" on HFS+) are a little more tricky. | Do we care about preventing a user from adding these paths to the | index? | | | Gary ... [ Demo scrubbed ] ... `---- And the CVE was assigned at <http://seclists.org/oss-sec/2015/q1/939>: ,---- | > Does the scope of CVE-2014-9390 also include these bits | > from the above: | | > dulwich happily clones a repository which contains commit with invalid | > paths, say .git/hooks/pre-commit, and thus allowing execution of code | > on subsequent commits. | | No, the scope of CVE-2014-9390 does not include that. Use | CVE-2014-9706 for this vulnerability in dulwich. | | The scope of CVE-2014-9390 is currently undefined, in part because | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9390 | intentionally doesn't have any related information. Usage of | CVE-2014-9390 is, very roughly, concerned with "The string .git/ for a | directory name has always been considered Very Special. Therefore, | other strings with equivalence relationships to .git/ must also be | considered Very Special." | | The root cause of the problem in dulwich seems to be "The string .git/ | for a directory name was not considered Very Special." This is | completely distinct conceptually, and is a much simpler case for CVE | coverage. | | There are two types of concerns with CVE-2014-9390. First, | CVE-2014-9390 can only apply to omitted equivalence-relationship | handling in source code that is, or is directly copied from, "Git | before 1.8.5.6, 1.9.x before 1.9.5, 2.0.x before 2.0.5, 2.1.x before | 2.1.4, and 2.2.x before 2.2.1" source code. It is not possible to have | a CVE for a cross-implementation vulnerability class of this | equivalence-relationship handling. Second, usage of CVE-2014-9390 | seems to span multiple types of problems, possibly including all of: | | http://cwe.mitre.org/data/definitions/178.html | http://cwe.mitre.org/data/definitions/180.html | http://cwe.mitre.org/data/definitions/182.html `---- This is fixed upstream in <https://git.samba.org/?p=jelmer/dulwich.git;a=commitdiff;h=091638be3c89f46f42c3b1d57dc1504af5729176>, slated for inclusion in dulwich 0.9.9, though after that CVE-2014-9390 actually applies (to the extent that it's a meaningful vulnerability identifier). -- System Information: Debian Release: 7.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages python-dulwich depends on: ii libc6 2.13-38+deb7u8 ii python 2.7.3-4+deb7u1 ii python2.6 2.6.8-1.1 ii python2.7 2.7.3-6+deb7u2 Versions of packages python-dulwich recommends: ii python-fastimport 0.9.2-1 Versions of packages python-dulwich suggests: pn python-dulwich-dbg <none> -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
