Ubuntu has issued an advisory on February 12: https://usn.ubuntu.com/usn/usn-3567-1/ Mageia 5 and Mageia 6 are also affected.
Whiteboard: (none) => MGA6TOOStatus comment: (none) => 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
CC: (none) => marja11, sysadmin-bugsAssignee: bugsquad => pkg-bugs
openSUSE has issued an advisory for this on February 19: https://lists.opensuse.org/opensuse-updates/2018-02/msg00058.html
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 => 6CC: (none) => tmb
puppet-3.6.2-3.3.mga5 puppet-server-3.6.2-3.3.mga5 vim-puppet-3.6.2-3.3.mga5 emacs-puppet-3.6.2-3.3.mga5 puppet-4.2.1-4.1.mga6 puppet-server-4.2.1-4.1.mga6 vim-puppet-4.2.1-4.1.mga6 emacs-puppet-4.2.1-4.1.mga6 from SRPMS: puppet-3.6.2-3.3.mga5.src.rpm puppet-4.2.1-4.1.mga6.src.rpm Advisory to come later.
Whiteboard: (none) => MGA5TOO
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
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=11019#c10 |_ 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://bugs.mageia.org/show_bug.cgi?id=18640#c7 |_ https://dzone.com/articles/puppet-beginners-concept-guide
@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." Tried: $ 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
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 4.2.1 $ facter 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?
Keywords: (none) => feedback
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. Installed: 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.
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.
Ah, sorry ... I forgot this needed to be fixed... fixed packages for mga6 will come tonight
Thanks Thomas.
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...) SRPMS: puppet-4.2.1-4.4.mga6.src.rpm noarch: emacs-puppet-4.2.1-4.4.mga6.noarch.rpm puppet-4.2.1-4.4.mga6.noarch.rpm puppet-server-4.2.1-4.4.mga6.noarch.rpm vim-puppet-4.2.1-4.4.mga6.noarch.rpm
Keywords: feedback => (none)
for testing simplicity, in order for puppet to find puppetmaster, add the line 127.0.0.1 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...
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 4.2.1 $ 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 file{'/tmp/pup': ensure => 'directory'} file{'/tmp/pup/et': 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
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. Anybody? A clean update for the four packages. $ rpm -qa | grep puppet vim-puppet-3.6.2-3.3.mga5 emacs-puppet-3.6.2-3.3.mga5 puppet-3.6.2-3.3.mga5 puppet-server-3.6.2-3.3.mga5 Started the server and ran similar tests to those outlined in comment 19, with similar results. $ puppet --version 3.6.2 ....... 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
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
@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
Advisory: ======================== 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). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-10689 https://usn.ubuntu.com/3567-1/
Advisory from comments 4, 17, 23.
Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0199.html
Status: NEW => RESOLVEDResolution: (none) => FIXED