Bug 22589 - puppet new security issue CVE-2017-10689
Summary: puppet new security issue CVE-2017-10689
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 MGA6-64-OK MGA5-64-OK
Keywords: advisory, validated_update
Depends on:
Reported: 2018-02-14 12:12 CET by David Walser
Modified: 2018-04-13 22:09 CEST (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

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

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

Comment 13 Len Lawrence 2018-04-06 10:15:35 CEST
Mageia 6, x86_64

Moved to a Plasma based partition and installed puppet packages before updating.  The puppet-server installation showed a problem which indicates that the fault reported above was not a regression.
      1/4: facter
      2/4: puppet
      3/4: emacs-puppet
      4/4: vim-puppet
$ sudo urpmi puppet-server
installing puppet-server-4.2.1-4.mga6.noarch.rpm from /var/cache/urpmi/rpms
Preparing...                     #############################
      1/1: puppet-server         #############################
Warning: Problems encountered when activating services.
  Please check and enable manually if necessary.
  Service units affected: puppetmaster.service
$ id puppet
uid=963(puppet) gid=962(puppet) groups=962(puppet)
$ sudo systemctl start puppet.service
$ systemctl status puppet.service
● puppet.service - Puppet agent
   Loaded: loaded (/usr/lib/systemd/system/puppet.service; enabl
   Active: failed (Result: exit-code) since Fri 2018-04-06 08:49
  Process: 8296 ExecStart=/opt/puppetlabs/puppet/bin/puppet agen
 Main PID: 8296 (code=exited, status=203/EXEC)
$ cd /etc/puppet
$ ll
total 16
-rw-r--r-- 1 root root 1462 Jun  4  2017 fileserver.conf
drwxr-xr-x 2 root root 4096 Jun  4  2017 manifests/
drwxr-xr-x 2 root root 4096 Jun  4  2017 modules/
-rw-r--r-- 1 root root  457 Jun  4  2017 puppet.conf

puppet.conf is empty and implies that the default settings are being used and puppet agent would be run from /opt.
$ cat puppet.conf
# This file can be used to override the default puppet settings.
# See the following links for more details on what settings are available:
# - https://docs.puppetlabs.com/puppet/latest/reference/config_important_settings.html
# - https://docs.puppetlabs.com/puppet/latest/reference/config_about_settings.html
# - https://docs.puppetlabs.com/puppet/latest/reference/config_file_main.html
# - https://docs.puppetlabs.com/references/latest/configuration.html

$ cd ../puppetlabs/puppet
$ cat puppet.conf
This echoes the output above; in other words the configuration reverts to default settings.

We could populate those two files after consulting the links but since this was not necessary in earlier tests it is a regression as far as QA testing is concerned.  It looks like the server is started automatically during installation so the configuration has to be set earlier.
Comment 14 Len Lawrence 2018-04-06 10:32:27 CEST
The implication from comment 13 is that some change was made to the puppet package(s) in Core release between the previous time that QA handled puppet and this current attempt to test.
Comment 15 Thomas Backlund 2018-04-06 10:39:25 CEST
Ah, sorry ... I forgot this needed to be fixed... fixed packages for mga6 will come tonight
Comment 16 Len Lawrence 2018-04-06 12:04:52 CEST
Thanks Thomas.
Comment 17 Thomas Backlund 2018-04-07 00:44:19 CEST
Mga6 and Cauldron puppet fixed according to the fileystem layout puppet 4.x expects
(but replacing "/opt" with "/var/lib" as it should be on packaged rpms...)



Keywords: feedback => (none)

Comment 18 Thomas Backlund 2018-04-07 00:52:31 CEST
for testing simplicity, in order for puppet to find puppetmaster, add the line puppet

to /etc/hosts

note that /etc/puppetlabs/puppet/puppet.conf is empty by default as we dont want it to do anything else than start ...

Its up to the sysadmin to write configs according to what (s)he wants puppet to do...
Comment 19 Len Lawrence 2018-04-07 10:04:19 CEST
Mageia6, x86_64

Modified /etc/hosts as directed in comment 18.
Installed the puppet packages and saw the puppetmaster problem reported earlier.

Upgraded the packages without any problem and noted that puppet agent was enabled.
Started the puppet service OK.
● puppet.service - Puppet agent
   Loaded: loaded (/usr/lib/systemd/system/puppet.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2018-04-07 08:38:15 BST; 10s ago
 Main PID: 1075 (puppet)
   CGroup: /system.slice/puppet.service
           └─1075 /usr/bin/ruby /usr/bin/puppet agent  --no-daemonize

Apr 07 08:38:15 difda systemd[1]: Started Puppet agent.
Apr 07 08:38:17 difda puppet-agent[1075]: Could not request certificate: Connection refused - connect(2) for "puppet" port 8140"

The lack of configuration may be to blame for the problem there.
Referred to earler test report: https://bugs.mageia.org/show_bug.cgi?id=18640
$ puppet --version
$ facter
architecture => x86_64
blockdevice_sda_model => KINGSTON SV300S3
blockdevice_sda_size => 240057409536
blockdevice_sda_vendor => ATA
blockdevice_sdb_model => Samsung SSD 850
timezone => BST
uniqueid => a8c06701
uptime => 21:38 hours
uptime_days => 0
uptime_hours => 21
uptime_seconds => 77908
virtual => physical

Created mynode.pp using vim (vim-puppet is not an executable so I would gusess it is an extension to vi).  Syntax highlighting was apparent.
$ cat mynode.pp
        ensure => 'directory'}
        ensure => 'present', content => 'look at me', require => File['/tmp/pup']}
$ puppet apply mynode.pp
Notice: Compiled catalog for difda in environment production in 0.18 seconds
Notice: /Stage[main]/Main/File[/tmp/pup]/ensure: created
Notice: /Stage[main]/Main/File[/tmp/pup/et]/ensure: defined content as '{md5}5b82b5632d581e0e0ab63832bb828204'
Notice: Applied catalog in 0.01 seconds
$ cat /tmp/pup/et
look at me

At this simple level puppet works and in view of the reports that this version is working successfully in the Mageia infrastructure we can pass it on.

Mageia5 tests later today.

Whiteboard: MGA5TOO => MGA5TOO MGA6-64-OK

Comment 20 Len Lawrence 2018-04-07 15:01:16 CEST
Mageia5, x86_64

No problems installing puppet-server before the update.

No follow-up on CVE-2017-10689.  This would involve a deeper knowledge of operating puppet than this tester has.  AFAICS it would mean using the Puppet Module Tool in conjunction with something like minitar to unpack a tar file.
minitar is a ruby gem:
$ sudo gem install minitar
$ sudo gem install minitar-cli

The test would be to ensure that the tar file contained files with "weird permissions" and confirm that these were preserved by unpacking and then run the test again after the update to see what happens to those permissions.

A clean update for the four packages.
$ rpm -qa | grep puppet

Started the server and ran similar tests to those outlined in comment 19, with similar results.
$ puppet --version

Looks good for 64-bits on Mageia5.
Shall look into the PMT stuff in the background; no need to hold this up though.

Whiteboard: MGA5TOO MGA6-64-OK => MGA5TOO MGA6-64-OK MGA5-64-OK

Comment 21 Len Lawrence 2018-04-07 19:02:23 CEST
A rider to the previous two comments.  /var/lib/puppet is populated and the puppetmaster service can be started.

$ systemctl status puppetmaster.service
● puppetmaster.service - Puppet master
   Loaded: loaded (/usr/lib/systemd/system/puppetmaster.service; enabled)
   Active: active (running) since Sat 2018-04-07 17:59:37 BST; 11s ago
 Main PID: 32617 (puppet)
   CGroup: /system.slice/puppetmaster.service
           └─32617 /usr/bin/ruby /usr/bin/puppet master --no-daemonize

$ systemctl status puppet.service
● puppet.service - Puppet agent
   Loaded: loaded (/usr/lib/systemd/system/puppet.service; enabled)
   Active: active (running) since Sat 2018-04-07 13:50:48 BST; 4h 9min ago
 Main PID: 26953 (puppet)
   CGroup: /system.slice/puppet.service
           └─26953 /usr/bin/ruby /usr/bin/puppet agent --no-daemonize
Comment 22 Lewis Smith 2018-04-08 19:46:30 CEST
@Len : heroic work yet again. Validating (you could have done so).

(In reply to David Walser from comment #4)
> Advisory to come later.
Please do. Note new M6 version in c17. M5 version in c4.

Keywords: (none) => validated_update

Comment 23 David Walser 2018-04-09 00:21:05 CEST

Updated puppet packages fix security vulnerability:

It was discovered that Puppet incorrectly handled permissions when unpacking
certain tarballs. A local user could possibly use this issue to execute
arbitrary code (CVE-2017-10689).

Comment 24 Lewis Smith 2018-04-10 09:06:07 CEST
Advisory from comments 4, 17, 23.

Keywords: (none) => advisory

Comment 25 Mageia Robot 2018-04-13 22:09:45 CEST
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

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