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

[Eric Desrochers]

[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