** Description changed: + [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
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1815237 Title: stop shipping "update-pciids" in /usr/sbin To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pciutils/+bug/1815237/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
