Bug 22589 - puppet new security issue CVE-2017-10689
Summary: puppet new security issue CVE-2017-10689
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
Whiteboard: MGA5TOO
Keywords: feedback
Depends on:
Reported: 2018-02-14 12:12 CET by David Walser
Modified: 2018-03-05 19:33 CET (History)
4 users (show)

See Also:
Source RPM: puppet-4.2.1-4.mga6.src.rpm
Status comment: Patches available from Ubuntu and upstream


Description David Walser 2018-02-14 12:12:47 CET
Ubuntu has issued an advisory on February 12:

Mageia 5 and Mageia 6 are also affected.
David Walser 2018-02-14 12:13:03 CET

Whiteboard: (none) => MGA6TOO
Status comment: (none) => Patches available from Ubuntu and upstream

Comment 1 Marja van Waes 2018-02-14 17:00:24 CET
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

Assignee: bugsquad => pkg-bugs
CC: (none) => marja11, sysadmin-bugs

Comment 2 David Walser 2018-02-24 22:54:54 CET
openSUSE has issued an advisory for this on February 19:
Comment 3 Thomas Backlund 2018-02-26 17:51:30 CET
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

CC: (none) => tmb
Whiteboard: MGA6TOO => (none)
Version: Cauldron => 6

Comment 4 David Walser 2018-02-27 12:21:24 CET

from SRPMS:

Advisory to come later.

Whiteboard: (none) => MGA5TOO

Comment 5 Thomas Backlund 2018-03-02 09:44:30 CET
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)

Assignee: pkg-bugs => qa-bugs

Comment 6 Lewis Smith 2018-03-02 11:25:24 CET
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:
 |_ https://bugs.mageia.org/show_bug.cgi?id=10568#c5
   |_ http://wiki.gentoo.org/wiki/Puppet
 |_ https://bugs.mageia.org/show_bug.cgi?id=10568#c13
Len's lengthy explanation looks valuable:
 |_ https://dzone.com/articles/puppet-beginners-concept-guide
Comment 7 Len Lawrence 2018-03-02 19:22:31 CET
@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.

CC: (none) => tarazed25

Comment 8 Len Lawrence 2018-03-02 19:28:59 CET
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.
Comment 9 Len Lawrence 2018-03-05 18:43:31 CET
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
$ facter
architecture => x86_64
blockdevice_sda_model => Crucial_CT512MX1

Extended description of the system, hardware and operating system.
Comment 10 Len Lawrence 2018-03-05 19:14:04 CET
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.
Comment 11 Len Lawrence 2018-03-05 19:16:07 CET
Darn it - pasted the wrong link there.  Should be https://puppet.com/docs/puppet/5.4/configuration.html#basemodulepath
Comment 12 Len Lawrence 2018-03-05 19:33:34 CET
/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?

Keywords: (none) => feedback

Note You need to log in before you can comment on or make changes to this bug.