Ubuntu has issued an advisory on February 12:
Mageia 5 and Mageia 6 are also affected.
Patches available from Ubuntu and upstream
Assigning to all packagers collectively, since there is no registered maintainer for this package.
CC'ing sysadmin team, because they'll need the update too
openSUSE has issued an advisory for this on February 19:
Fixed in Cauldron in puppet-4.2.1-5.mga7
Fixed in Mga6 in puppet-4.2.1-4.1.mga6
Fixed in Mga5 & Infra_6 in puppet-3.6.2-3.3.mga5/6
Advisory to come later.
Actually assign to QA...
The fixes for mga5 puppet is running (rebuilt) on mga6 infra (as we will stay with puppet 3 for infra for now)
Looking at M6/64
The fault here is quite specific, and looks as if it could be tested if the way in can be found:
"CVE-2017-10689: Reset permissions when unpacking tar in PMT."
"When installing a module using the system tar, the PMT will filter filesystem permissions to a sane value. This may just be based on the user's umask."
"When using minitar, files are unpacked with whatever permissions are in the
tarball. This is potentially unsafe, as tarballs can be easily created
with weird permissions."
(I cannot find minitar in the puppet pkgs).
As for testing puppet, there is a QA procedure, but this just points to bugs:
Len's lengthy explanation looks valuable:
@Lewis, comment 6.
Had completely forgotten any involvement in puppet. This minitar business is very obscure. Could not find a Mageia version of minitar so installed the minitar and minitar-cli gems and checked it out. And what is PMT? - see below.
First, a quote from https://puppet.com/blog/module-of-week-puppet-module-tool-part-1
"This week we're going to begin our coverage of the Puppet Module Tool (PMT). The PMT is the command-line interface to the Puppet Forge—an online repository for re-usable Puppet modules. As of Puppet 2.7.14 and Puppet Enterprise 2.5 PMT is no longer a separate product; it's now part of Puppet Core. What this means for you is that PMT is ready-to-go out of the box."
$ puppet module search tomcat and received a long list of modules with tomcat as part of their names.
Nothing for minitar:
$ puppet module search minitar
Notice: Searching https://forgeapi.puppetlabs.com ...
No results found for 'minitar'.
Presumably minitar can be referenced in a manifest - no real idea how those work - but it is difficult to see why minitar should be associated with puppet rather than having a separate bug.
Just downloaded an ebook introduction to puppet but that would not help with this minitar business. We need help from the devs I reckon.
Just re-read the CVE and understand now that it is the PMT that has the bug. minitar does what it does. So it is the PMT we have to test. Sorry for the noise.
Not getting very far with this.
Mageia 6 :: x86_64
Trying to get a feel for the puppet environment.
Could not start the puppet service. Noted that there was no /etc/puppet.conf so copied a specimen file to /etc/.
$ id puppet
uid=967(puppet) gid=956(puppet) groups=956(puppet)
$ sudo systemctl start puppet.service
$ systemctl status puppet.service
● puppet.service - Puppet agent
Loaded: loaded (/usr/lib/systemd/system/puppet.service; enabled; vendor pres
Active: failed (Result: exit-code) since Mon 2018-03-05 17:19:56 GMT; 14s ag
Process: 29262 ExecStart=/opt/puppetlabs/puppet/bin/puppet agent $PUPPET_EXTR
Main PID: 29262 (code=exited, status=203/EXEC)
lines 1-5/5 (END)
$ ll /opt/puppetlabs/puppet/
drwxr-xr-x 10 puppet puppet 4096 Mar 2 16:54 cache/
No bin directory so there must be something missing in the initialization.
Note that this is all before the updates.
$ puppet --version
architecture => x86_64
blockdevice_sda_model => Crucial_CT512MX1
Extended description of the system, hardware and operating system.
Following on from comment 9:-
Tried installing from Updates, on another machine and noted this:
Warning: Problems encountered when activating services.
Please check and enable manually if necessary.
Service units affected: puppetmaster.service
Checking status after trying the packages from Updates Testing showed the same error concerning ExecStart=/opt/puppetlabs/puppet/bin/puppet and /opt/puppetlabs/puppet/bin/ does not exist.
# ls /etc/puppet
fileserver.conf manifests/ modules/ puppet.conf
puppet.conf is empty - the comments say it should be used to override defaults.
Checking some setting values at https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.14 indicates that the /opt directory is the base directory by default. The RPM installs puppet at /usr/bin/ so it looks like it might work if the correct options are added to puppet.conf and the server restarted. Shooting in the dark at present.
Darn it - pasted the wrong link there. Should be https://puppet.com/docs/puppet/5.4/configuration.html#basemodulepath
/etc/puppetlabs/puppet/puppet.conf is also empty so the defaults take over at installation time.
Should this file not be populated before we install, i.e. as part of the package?
I do not remember any problems of this kind in earlier puppet bug tests.
server defaults to 'puppet' : localhost?