Bug 23346 - python-dulwich new security issue CVE-2017-16228
Summary: python-dulwich new security issue CVE-2017-16228
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: MGA6-64-OK
Keywords: advisory, validated_update
Depends on:
Blocks:
 
Reported: 2018-07-24 18:35 CEST by David Walser
Modified: 2018-11-11 22:40 CET (History)
8 users (show)

See Also:
Source RPM: python-dulwich-0.12.0-1.mga6.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2018-07-24 18:35:19 CEST
SUSE has issued an advisory today (July 24):
http://lists.suse.com/pipermail/sle-security-updates/2018-July/004303.html

The SUSE bug lists several other CVEs which may also affect this (CVE-2017-9800, CVE-2017-12836, CVE-2017-12976, CVE-2017-1000116, and CVE-2017-1000117):
https://bugzilla.suse.com/show_bug.cgi?id=1066430

It looks like the issue is fixed in 0.18.5, but I don't know how many old versions are affected.
David Walser 2018-07-24 18:35:49 CEST

CC: (none) => geiger.david68210, shlomif, smelror

Comment 1 David Walser 2018-08-06 21:59:49 CEST
openSUSE has issued an advisory for this today (August 6):
https://lists.opensuse.org/opensuse-updates/2018-08/msg00028.html
Comment 2 Bruno Cornec 2018-10-27 04:34:23 CEST
python-dulwich-0.12.0-1.1.mga6 uploaded which contains the upstream patch for CVE-2017-16228

CC: (none) => bruno
Assignee: python => qa-bugs
Status: NEW => ASSIGNED

Comment 3 David Walser 2018-10-27 05:12:00 CEST
python-dulwich-0.12.0-1.1.mga6
python3-dulwich-0.12.0-1.1.mga6

from python-dulwich-0.12.0-1.1.mga6.src.rpm

Since you patched it instead of updating it, what's the status of the other CVEs mentioned in Comment 0 for this version?

Keywords: (none) => feedback

Comment 4 Bruno Cornec 2018-10-29 18:24:55 CET
Well I thought the policy was trying to keep versions on stable branches, thus I didn't updated, and also individual patches were mentioned, so that ease patching, and minimize risks.

In SUSE BR https://bugzilla.suse.com/show_bug.cgi?id=1066430 they mention the git commit id to be used to fix all the CVEs they mention (CVE-2017-9800, CVE-2017-12836, CVE-2017-12976, CVE-2017-1000116, and CVE-2017-1000117) and I used that patch as the base for ours.

I realized I had missed a portion of the patch, which is now fixed, thanks for making me look at it again! So python-dulwich-0.12.0-1.2.mga6 on its way and IMO it should contain everything needed (except if the SUSE BR is incomplete)
Comment 5 David Walser 2018-10-30 12:05:16 CET
Advisory:
========================

Updated python-dulwich packages fix security vulnerability:

Dulwich, when an SSH subprocess is used, allowed remote attackers to execute
arbitrary commands via an ssh URL with an initial dash character in the hostname
(CVE-2017-16228).

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16228
https://lists.opensuse.org/opensuse-updates/2018-08/msg00028.html
========================

Updated packages in core/updates_testing:
========================
python-dulwich-0.12.0-1.2.mga6
python3-dulwich-0.12.0-1.2.mga6

from python-dulwich-0.12.0-1.2.mga6.src.rpm

Keywords: feedback => (none)

Comment 6 Herman Viaene 2018-11-08 11:25:19 CET
MGA6-32 MATE on IBM Thinkpad R50e
No installation issues.
Clean install OK and no side effects noted, that's as far as my knowledge goes.

CC: (none) => herman.viaene

Comment 7 Len Lawrence 2018-11-09 13:52:33 CET
Mageia 6, x86_64

Familiarization:
This is a python based interface for accessing git repositories.  Installing it gives you /usr/bin/dulwich and /usr/bin/dulwich3 but I could not figure out how to run them but there is an introductory tutorial at https://www.dulwich.io/docs/tutorial/remote.html with a script which works as it is when run line by line using the python command-line interface, remembering to maintain the indentation structure.
e.g.
$ python
>>> from dulwich.repo import Repo
and so on.
stackoverflow contains some discussion on fetch using python dulwich.
https://stackoverflow.com/questions/34609308/how-to-fetch-using-dulwich-in-python

The link in the advisory; https://www.dulwich.io/code/dulwich/
shows a "getting started" exercise.  That does not work because it references a local repository unique to the author, as far as I can see.

CVE-2017-16228
There does not appear to be any exploit files posted for this bug.  Suse marks it as "in progress".

Updated the two packages - no problems.
Tried to run the introductory scripts interactively with python.

Discovered that the example given in "Getting started" fails because it relies on having already established a local repository.
$ python
Python 2.7.15 (default, May  1 2018, 17:08:05) 
[GCC 5.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from dulwich.repo import Repo
>>> r = Repo('.')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/site-packages/dulwich/repo.py", line 676, in __init__
    "No git repository was found at %(path)s" % dict(path=root)
dulwich.errors.NotGitRepository: No git repository was found at .
>>> exit()

The tutorial exercise also fails because  'repo' had already been defined before updating.  If you leave out the
>>> repo = Repo.init("remote", mkdir=True)
command then repo is undefined.
Next line:
>>> cid = repo.do_commit(b"message", committer=b"Jelmer <jelmer@samba.org>")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'repo' is not defined
>>>

Moving on to the second part of the tutorial, Tagging, did not work either.
>>> tree.add(tag, permissions, blob.id)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'tag' is not defined

The first tutorial script worked fine before the update so the moral of this story is to test it afterwards only.

None of this helps to confirm that the packages work so it is not clear where we should go from here.  There must be something else that we need to know to get started.

CC: (none) => tarazed25

Comment 8 Len Lawrence 2018-11-10 19:38:26 CET
Continuing from comment #7 on another machine - what was needed was closer inspection of the code.
Installed and updated the two packages.

Referred to the tutorial at https://www.dulwich.io/docs/tutorial/remote.html.
Ran the  example on the first page, changing name strings where necessary to avoid clashes with names used in earlier trials.  See the worksheet below; all tests worked without errors.

$ python
Python 2.7.15 (default, May  1 2018, 17:08:05) 
[GCC 5.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from dulwich.repo import Repo
>>> from dulwich.server import DictBackend, TCPGitServer
>>> import threading
>>> repo = Repo.init("repox", mkdir=True)
>>> cid = repo.do_commit(b"message", committer=b"Jelmer <jelmer@samba.org>")
>>> backend = DictBackend({b'/': repo})
>>> dul_server = TCPGitServer(backend, b'localhost', 0)
>>> threading.Thread(target=dul_server.serve).start()
>>> server_address, server_port=dul_server.socket.getsockname()
>>> from dulwich.client import TCPGitClient
>>> client = TCPGitClient(server_address, server_port)
>>> def determine_wants(refs):
...    return refs.values()
... 
>>> class DummyGraphWalker(object):
...     def ack(self, sha): pass
...     def next(self): pass
...     def __next__(self): pass
... 
>>> from io import BytesIO
>>> f = BytesIO()
>>> result = client.fetch_pack(b"/", determine_wants, DummyGraphWalker(), pack_data=f.write)
>>> print(f.getvalue()[:4].decode('ascii'))
PACK
>>> from dulwich.repo import Repo
>>> local = Repo.init("here", mkdir=True)
>>> remote_refs = client.fetch(b"/", local)
>>> dul_server.shutdown()

Tried to guess at a restart command and got into trouble.
All tries gave errors but the following seemed to detach it from the terminal:
>>> dul_server.serve()
and it needed to be killed from another terminal.
Normally one would exit from interactive mode by typing exit().

Repeated the whole exercise under python3 with identical results.

Decided not to take this any further because it is rather time-consuming and in view of the well-behaved tests it is safe to say that this is fine for 64-bits.

Whiteboard: (none) => MGA6-64-OK

Comment 9 Len Lawrence 2018-11-10 19:46:52 CET
Addendum to comment #8.  The local "repositories" appear as empty directories in the current directory so they need to be removed after testing.
Comment 10 Len Lawrence 2018-11-10 19:49:37 CET
Ahem.  Not quite empty;

$ ls -a remote/.git
./   branches/  description*  hooks/  objects/
../  config*    HEAD*         info/   refs/
Comment 11 Lewis Smith 2018-11-11 21:45:07 CET
Advisory from comment 5.
Saw no reason not to validate this after Len's great efforts. (You could have).

Keywords: (none) => advisory, validated_update
CC: (none) => lewyssmith, sysadmin-bugs

Comment 12 Mageia Robot 2018-11-11 22:40:01 CET
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2018-0445.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.