[MIR] python-pyelftools

Bug #1630073 reported by Steve Langasek on 2016-10-04
24
This bug affects 2 people
Affects Status Importance Assigned to Milestone
dpdk (Ubuntu)
High
ChristianEhrhardt
python-pyelftools (Ubuntu)
Low
Unassigned

Bug Description

[MIR]
Listing MIR requirements that are fulfilled IMHO:

0. First of all - this is for the Z* release, no rush into Yakkety,
   but starting to do it right for Z* now instead of late in the next
   cycle.

1. Availability: Is already in Ubuntu universe and builds for the
   architectures it is designed to work on.

2. Rationale: having this python extension available would allow us to
   ship a dpdk helper tool that can help debugging it in case uncommon
   network cards are used. DPDK is in main, so this would be a runtime
   dependency.

3. Security: There were no open CVEs reported against it in the past.
   No Binaries, services or anything like it - just py files to include
   and a readme.

4. Quality assurance: Being a python extension there is no config needed
   that would make usability complex.
   The code is well myintained upstream. Currently there is no Ubuntu
   Delta to Debian and so far there are zero bugs against the package at
   https://bugs.launchpad.net/ubuntu/+source/python-pyelftools
   Neither are there in Debian:
   https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=python-pyelftools
   It has a set of integrated tests ran on build in override_dh_auto_test.

5. UI Standards: No UI

6. Dependencies:
   Runtime dependencies are on python2/3 only which already is in main.
   Build dependencies are on python, dh-python and debhelper. Again a
   small list and all already in main.

7. Standards compliance: Packaging is small and easy to understand as it
   is almost "just" calling dh with pybuild. It has a watch file and also
   FHS/Debian compliance is given. Lintian reports no open issues.

8. Maintenance: As said so far no open bugs and no delta. Since it doesn't
   expose anything to the network the risk of security issues is medium.
   It is medium and not low as it is used to process elf data on e.g.
   shared libraries - that means reading arbitrary data. Since it is in
   python a lot of the protection e.g. for buffer overflows comes from the
   runtime environment. There is no owning Team yet as it falls in the MIR
   prerequisites quote of "Simple packages (e.g. language bindings, simple
   Perl modules, small command-line programs, etc.) might not need very
   much maintenance effort, and if they are maintained well in Debian we
   can just keep them synced"

----

The latest upload of dpdk introduces a dependency on python-pyelftools. MIR, or dropping of the dependency, needed.

Steve Langasek (vorlon) on 2016-10-04
Changed in python-pyelftools (Ubuntu):
assignee: nobody → Christian Ehrhardt (der-schoenne)
Steve Langasek (vorlon) on 2016-10-04
Changed in python-pyelftools (Ubuntu):
status: New → Incomplete
Steve Langasek (vorlon) on 2016-10-04
Changed in python-pyelftools (Ubuntu):
assignee: Christian Ehrhardt (der-schoenne) → ChristianEhrhardt (paelzer)
ChristianEhrhardt (paelzer) wrote :

Hi Steve, you were 6 hours earlier than me since we had public holiday yesterday.

So far the tool is optional and we are too late IMHO to MIR that in.

I'll prep an upload that drops this particular tool for Yakkety and revisit that later on.
Dup'ing my report now.

Changed in dpdk (Ubuntu):
status: New → Triaged
importance: Undecided → High
assignee: nobody → ChristianEhrhardt (paelzer)
ChristianEhrhardt (paelzer) wrote :

As I said the tool is optional, used almost only for debugging new Cards so far (which PCI IDs of cards match which driver - I mean you poit it at .so files, so not the most day-to-day task) and it is new (no regression to "take it away" from anybody).

If users want to use it, it is "just" a python script. They still can use it by installing dependencies on their own. To allow that we just drop linking the tool into /usr/bin/.
That way it is out of scope at first, but still keeps it available for those who really want/need to use it in /usr/share/dpdk/tools/dpdk-pmdinfo.py.

The error for missing the python-elftools if using the tool from /usr/share is relatively user-friendly (it identifies what is missing exactly).

The error for the hwdata dependency would be much more unreadable, but we are fine to keep the hwdata dependency as that causes no component mismatch.

For the following release we can take the time to properly consider a MIR for python-elftools.

ChristianEhrhardt (paelzer) wrote :

FYI - Upload in the unapproved queue now

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package dpdk - 16.07-0ubuntu5

---------------
dpdk (16.07-0ubuntu5) yakkety; urgency=medium

  [ Christian Ehrhardt ]
  * Fix component mismatch by dropping the optional dpdk-pmdinfo tool
    (LP: #1630073).

  [ Gowrishankar Muthukrishnan ]
  * update d/p/dpdk-dev-examples-ip_pipeline-fix-pmd-driver-parameter.patch to
    fix dlopen issue (LP: #1630119)

 -- Christian Ehrhardt <email address hidden> Tue, 04 Oct 2016 09:27:54 +0200

Changed in dpdk (Ubuntu):
status: Triaged → Fix Released
ChristianEhrhardt (paelzer) wrote :

Ready for consideration by the MIR Team and an audit by the security Team.
Subscribing both.

But once more to be sure - this is meant for the Z* release.
So take a breath and close out your Yakkety tasks first :-)

description: updated
Michael Terry (mterry) on 2016-10-31
Changed in python-pyelftools (Ubuntu):
assignee: ChristianEhrhardt (paelzer) → Ubuntu Security Team (ubuntu-security)
ChristianEhrhardt (paelzer) wrote :

Hmm, this is accidentally still flagged incomplete without an open question - maybe by that it isn't on the radar for review.
I'd like to get that in this cycle, setting to confirmed again.

Changed in python-pyelftools (Ubuntu):
status: Incomplete → Confirmed
Matthias Klose (doko) wrote :

it doesn't have a bug subscriber

Changed in python-pyelftools (Ubuntu):
status: Confirmed → Incomplete
Scott Moser (smoser) wrote :

subscribed ubuntu-server.

Changed in python-pyelftools (Ubuntu):
status: Incomplete → Confirmed
ChristianEhrhardt (paelzer) wrote :

FYI - here in the bug - we have set a bug subscriber right after doko mentioned it as an issue.
Scott was so kind to set it back to confirmed then to follow the process.

I know there was the usual December rush and Christmas time in between, but since nothing happened since then I wanted to ping for an update on this?

Debian is soon to pick up our DPDK 16.11 packaging which we want to sync then, that would cause this component mismatch on python-elftools so I'd be happy to get this blocker out of the way.

Michael Terry (mterry) wrote :

This is waiting on a review by the security team. They are usually quite busy, with a queue of audits to go through.

ChristianEhrhardt (paelzer) wrote :

Thanks for the info Michael on the Status.

I wanted to let you know that since one of the main goals for DPDK was to become a sync to Debian it is in proposed now this way.
That includes the expected component mismatch on python-pyelftools - and since we have to rebuild openvswitch against that new DPDK API that is in the dependency chain behind it.

So we are kind of waiting on this - let us know when you know more on this.
If you could prioritize this (as it should be a rather small package) that would be great.

ChristianEhrhardt (paelzer) wrote :

Ping, for the sake of nearing dpdk merge on artful I wanted to ask a few days ahead if this review has made progress?

ChristianEhrhardt (paelzer) wrote :

We decupled and made this a suggests in Debian as well.
If it would be ok to take it, it would make users life slightly better - but urgency certainly dropped.

Changed in python-pyelftools (Ubuntu):
importance: Undecided → Low
Seth Arnold (seth-arnold) wrote :

I reviewed python-pyelftools version 0.24-3 as checked into Debian
unstable. This shouldn't be considered a full security audit but rather a
quick gauge of maintainability.

- No CVEs in our database
- python-pyelftools provides a Python API for inspecting ELF objects
  without dependencies upon readelf or binutils

- Build-Depends: debhelper), dh-python, python, python3
- No cryptography
- No networking
- Does not damonize
- automatically generated pre/post inst/rm scripts
- No initscripts
- No dbus services
- No setuid files
- No binaries in PATH
- No sudo fragments
- No udev rules
- Test suite run during package build
- No cronjobs
- Clean build logs

- subprocesses only spawned in test suite, looked good
- Files only manipulated in test suite, looked good
- Almost all logging is in the test suite, looked good
- No environment use
- No privileged functions
- No networking
- No cryptography
- No privileged portions of code
- Temp files only handled in test suite, looked good
- No webkit
- No javascript
- No policykit

ELF files are complicated enough that parsing them has been a frequent
source of security issues in the Linux kernel, binutils, readelf, and
doubtless many other tools. So while a re-implementation of ELF parsing is
bound to reintroduce some of the same bugs already solved elsewhere, the
memory safety of Python means the consequences are probably less severe
than other implementations.

There's one very dangerous idiom used in some of the examples:

- examples load . and .. into sys.path
- scripts/readelf.py loads . into sys.path

This is fine for software that's obviously examples but these examples
look useful enough that they may some day be promoted to 'real tools'.

These tools must not be promoted with the sys.path manipulations in place.

Security team ACK for promoting python-pyelftools to main.

Thanks

Changed in python-pyelftools (Ubuntu):
assignee: Ubuntu Security Team (ubuntu-security) → nobody
ChristianEhrhardt (paelzer) wrote :

Thank you Seth,
it is too late for artful to be meaningful so we will carry it as-is there.
But I'll make the changes in Debian and then on 18.04 merges the component mismatch will show up.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers