group.of.nepali.translators team mailing list archive

[Eric Desrochers <eric.desrochers@xxxxxxxxxxxxx>]

** Changed in: pciutils (Ubuntu Cosmic)
     Assignee: Eric Desrochers (slashd) => (unassigned)

** Changed in: pciutils (Ubuntu Cosmic)
     Assignee: (unassigned) => Mark Thomas (markthomas)

** Changed in: pciutils (Ubuntu)
     Assignee: Eric Desrochers (slashd) => (unassigned)

** Changed in: pciutils (Ubuntu)
     Assignee: (unassigned) => Mark Thomas (markthomas)

** Changed in: pciutils (Ubuntu Cosmic)
     Assignee: Mark Thomas (markthomas) => (unassigned)

** Also affects: pciutils (Ubuntu Disco)
   Importance: Low
     Assignee: Mark Thomas (markthomas)
       Status: In Progress

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1815237

Title:
  stop shipping "update-pciids" in /usr/sbin

Status in pciutils package in Ubuntu:
  In Progress
Status in pciutils source package in Precise:
  Invalid
Status in pciutils source package in Trusty:
  In Progress
Status in pciutils source package in Xenial:
  In Progress
Status in pciutils source package in Bionic:
  In Progress
Status in pciutils source package in Cosmic:
  In Progress
Status in pciutils source package in Disco:
  In Progress

Bug description:
  [IMPACT]

  pciutils contains a script called 'update-pciids' which offer to user the possibilty to download new version of the PCI ID list 
  from 'http:pciids.sourceforge.net/v2.2/pci.ids' and update the file '/usr/share/misc/pci.ids' accordingly.

  After a discussion with foundation/security about what would be the
  best practice between (a) simply use update-pciids script or (b) do an
  sru to update the list.

  Option (b) was unanimously judge more viable. (see the irc discussion
  in the [ORIG DESCRIPTION] section.

  That brought up another aspect, should Ubuntu keep that script
  available for user. Foundation/Security team ACK on moving the script
  to '/usr/share/doc/pciutils/examples/'

  The motivation behind this is the following :
  - Injection attack where intentionally-corrupted pci.ids data exploits something goofy in a library that reads it.
  - It alters a dpkg-managed file in /usr/share
  - Uncheck download over http
  - ....

  
  [TEST CASE]

  1) Install pciutils (if not installed already)
  # apt-get install pciutils

  The package come with a pre-define pci.ids vendor list, freeze at the end time it was last SRU'd, merge, sync from Debian. 
  If you perform a 'dmidecode' on a system with recent HW, dmidecode may not know about this new HW since the pci.ids list can have been updated before the HW exist, or got added to the upstream pci vendor list.

  2) Check pci.ids (pre-update)
  # stat /usr/share/misc/pci.ids 
    File: /usr/share/misc/pci.ids
    Size: 1062022   	Blocks: 2080       IO Block: 4096   regular file
  Device: 10302h/66306d	Inode: 8916914     Links: 1
  Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
  ==> Access: 2019-03-13 16:46:34.208000193 -0400
  ==> Modify: 2017-04-24 14:35:32.000000000 -0400
  ==> Change: 2019-03-04 15:19:41.001315621 -0500
   Birth: -

  3) Update pci.ids
  # update-pciids 
  Downloaded daily snapshot dated 2019-03-14 03:15:02

  4) Check pci.ids (pre-update)
  # stat /usr/share/misc/pci.ids 
    File: /usr/share/misc/pci.ids
    Size: 1169201   	Blocks: 2288       IO Block: 4096   regular file
  Device: 10302h/66306d	Inode: 8916466     Links: 1
  Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
  ==> Access: 2019-03-14 03:15:02.000000000 -0400
  ==> Modify: 2019-03-14 03:15:02.000000000 -0400
  ==> Change: 2019-03-15 12:32:25.489581638 -0400
   Birth: -

  At this point the pci.ids is updated.

  After this SRU, the above step won't be available ^.

  [REGRESSION POTENTIAL]

  User used to update their PCI vendor list using 'update-pciids' won't have it available anymore out of the box as it was before this SRU.
  (Unless they do the necessary manual intervention by taking the script from 'pciutils/examples' set the executable bit and run it, as user could still use that way but they have to be aware of the potential risk that may or may not come with it.)

  At this point, it will be at user discretion to use it or not and
  judge/evaluate the risk, but the package itself will no longer offer
  the option out of the box.

  We need to file a debian bug about it, but I don't know if Debian will
  be willing to follow our chain of thought. If not we will divert from
  pciutils debian package at that aspect.

  [OTHER INFORMATION]

  For more information :
  # man update-pciids

  [ORIG DESCRIPTION]
  [Freenode #ubuntu-release discussion]

  [13:51:02] <slashd> vorlon, I also puzzle what would be the good practice, SRU an update of pci.ids or leave the user the decision to use update-pciids which does it automatically
  [13:52:13] <infinity> slashd: That second option isn't a great one, for many reasons.
  [13:52:21] <vorlon> slashd: ^^ I concur
  [13:52:55] <infinity> slashd: The two that come to mind is (a) it alters a dpkg-managed file in /usr/share and (b) it's an entirely unchecked random download over http.
  [13:53:17] <infinity> In fact, I'm a bit shocked we even ship that script at all, or haven't at least neutered it in some way.
  [13:54:40] <infinity> That's just begging for an injection attack where intentionally-corrupted pci.ids data exploits something goofy in a library that reads it.
  [13:55:00] <slashd> infinity, good point
  [13:56:05] <infinity> If we were to give that as an option, we'd need to alter the script (and things that read that data) to use a second user-writable location in /var, and we'd need upstream to provide a signed/verifiable source we can pull from.
  [13:56:23] <infinity> But I think "stop shipping the script on the PATH" is a saner plan.
  [13:58:26] <infinity> slashd: Maybe get some input from someone like mdeslaur or sarnold to see if they think I'm being overly paranoid, but I think having a script on path that downloads random junk over http and slams it in a file in /usr/share that gets read by dozens of other binaries is pretty sketchy.
  [13:58:40] <infinity> slashd: So I'd be +1 on just nuking it.
  [13:59:08] <slashd> infinity, ack will try to have a ACK for security team as well, but sound like a good plan
  [13:59:14] <infinity> slashd: Or moving it to /use/share/doc/pciutils/examples
  [14:00:23] <slashd> infinity, vorlon ok thanks a lot for your help
  [14:00:28] <mdeslaur> oh ew ew ew ew
  [14:01:01] <mdeslaur> yeah, moving it to examples would be a good idea
  [14:01:21] <slashd> mdeslaur, ack tks

  SRU team: +1
  Security team: +1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pciutils/+bug/1815237/+subscriptions