14.04: applying security update of supervisor didn't start it

According to the changelog, there was a security update pushed a few days ago:

supervisor (3.0b2-1ubuntu0.1) trusty-security; urgency=medium

  • SECURITY UPDATE: Arbitrary code injection through XML-RPC
    • debian/patches/CVE-2017-11610.patch: disabling object traversal in XML-RPC dispatch in supervisor/test/test_xmlrc.py, supervisor/xmlrcp.py.
    • CVE-2017-11610

-- Leonidas S. Barbosa Thu, 17 May 2018 15:59:12 -0300

This is the package I had installed:

$ dpkg -p supervisorO
Package: supervisor
Priority: extra
Section: admin
Installed-Size: 1485
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architecture: all
Version: 3.0b2-1
Depends: python, python-meld3, python-pkg-resources (>= 0.6c7)
Size: 313972
Description: A system for controlling process state
 Supervisor is a system for controlling and maintaining process state,
 similar to what init does, but not intended as an init replacement.
 .
 It will manage individual processes or groups of processes that
 need to be started and stopped in order, and it is possible to
 control individual process state via an rpc mechanism, thus allowing
 ordinary users to restart processes.
Original-Maintainer: Qijiang Fan <fqj1994@gmail.com>
Homepage: http://supervisord.org/

This is how I updated and how the process went:

$ sudo apt-get install supervisor
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
  supervisor
1 upgraded, 0 newly installed, 0 to remove and 33 not upgraded.
Need to get 244 kB of archives.
After this operation, 67.6 kB disk space will be freed.
Get:1 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/universe supervisor all 3.0b2-1ubuntu0.1 [244 kB]
Fetched 244 kB in 0s (281 kB/s)
(Reading database ... 73862 files and directories currently installed.)
Preparing to unpack .../supervisor_3.0b2-1ubuntu0.1_all.deb ...
Stopping supervisor: supervisord.
Unpacking supervisor (3.0b2-1ubuntu0.1) over (3.0b2-1) ...
Processing triggers for ureadahead (0.100.0-16) ...
ureadahead will be reprofiled on next reboot
Setting up supervisor (3.0b2-1ubuntu0.1) ...
Starting supervisor: invoke-rc.d: initscript supervisor, action "start" failed.
dpkg: error processing package supervisor (--configure):
 subprocess installed post-installation script returned error exit status 1
E: Sub-process /usr/bin/dpkg returned an error code (1)

At this point the service was not running.

Manually starting worked though: sudo service supervisor start

I found this in the dpkg.log:

2018-05-22 10:18:19 startup archives unpack
2018-05-22 10:18:19 upgrade supervisor:all 3.0b2-1 3.0b2-1ubuntu0.1
2018-05-22 10:18:19 status half-configured supervisor:all 3.0b2-1
2018-05-22 10:18:20 status unpacked supervisor:all 3.0b2-1
2018-05-22 10:18:20 status half-installed supervisor:all 3.0b2-1
2018-05-22 10:18:20 status triggers-pending ureadahead:amd64 0.100.0-16
2018-05-22 10:18:20 status half-installed supervisor:all 3.0b2-1
2018-05-22 10:18:20 status half-installed supervisor:all 3.0b2-1
2018-05-22 10:18:20 status unpacked supervisor:all 3.0b2-1ubuntu0.1
2018-05-22 10:18:20 status unpacked supervisor:all 3.0b2-1ubuntu0.1
2018-05-22 10:18:20 trigproc ureadahead:amd64 0.100.0-16 0.100.0-16
2018-05-22 10:18:20 status half-configured ureadahead:amd64 0.100.0-16
2018-05-22 10:18:20 status installed ureadahead:amd64 0.100.0-16
2018-05-22 10:18:20 startup packages configure
2018-05-22 10:18:20 configure supervisor:all 3.0b2-1ubuntu0.1 <none>
2018-05-22 10:18:20 status unpacked supervisor:all 3.0b2-1ubuntu0.1
2018-05-22 10:18:20 status unpacked supervisor:all 3.0b2-1ubuntu0.1
2018-05-22 10:18:20 status unpacked supervisor:all 3.0b2-1ubuntu0.1
2018-05-22 10:18:20 status unpacked supervisor:all 3.0b2-1ubuntu0.1
2018-05-22 10:18:20 status half-configured supervisor:all 3.0b2-1ubuntu0.1

I looked up the supervisor logs too, but didn't find anything conclusive:

2018-05-22 10:18:19,944 WARN received SIGTERM indicating exit request
2018-05-22 10:18:19,947 INFO waiting for laravel-daemon-es-posts_00, laravel-daemon-es-comments_00, laravel-horizon_00 to die
2018-05-22 10:18:22,008 INFO stopped: laravel-horizon_00 (exit status 0)
2018-05-22 10:18:23,014 INFO waiting for laravel-daemon-es-posts_00, laravel-daemon-es-comments_00 to die
2018-05-22 10:18:23,066 INFO stopped: laravel-daemon-es-posts_00 (terminated by SIGKILL)
2018-05-22 10:18:23,066 INFO stopped: laravel-daemon-es-comments_00 (terminated by SIGKILL)

2018-05-22 10:18:39,745 CRIT Supervisor running as root (no user in config file)
2018-05-22 10:18:39,745 WARN Included extra file "/etc/supervisor/conf.d/laravel.conf" during parsing
2018-05-22 10:18:39,764 INFO RPC interface 'supervisor' initialized
2018-05-22 10:18:39,764 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2018-05-22 10:18:39,765 INFO daemonizing the supervisord process
2018-05-22 10:18:39,765 INFO supervisord started with pid 9923
2018-05-22 10:18:40,771 INFO spawned: 'laravel-daemon-es-posts_00' with pid 9933
2018-05-22 10:18:40,773 INFO spawned: 'laravel-daemon-es-comments_00' with pid 9934
2018-05-22 10:18:40,775 INFO spawned: 'laravel-horizon_00' with pid 9935
2018-05-22 10:18:44,523 INFO success: laravel-daemon-es-posts_00 entered RUNNING state, process has stayed up for > than 3 seconds (startsecs)
2018-05-22 10:18:44,523 INFO success: laravel-daemon-es-comments_00 entered RUNNING state, process has stayed up for > than 3 seconds (startsecs)
2018-05-22 10:18:44,523 INFO success: laravel-horizon_00 entered RUNNING state, process has stayed up for > than 3 seconds (startsecs)

I made an artificial space gap where I paused to look at the situation and then started it manually.

Did I do anything wrong? I usually just perform sudo apt-get upgrade however I heard from a co-worker already about this problem but she didn't record the specifics so I used a test machine to perform this.

thanks!

Answers 1

  • Well, I ran into the same problem and uninstalling/reinstalling fixed the problem. If you need to run it on many machines, apt-get remove supervisor --yes && apt-get install supervisor --yes is helpful.

    Edit: so the conclusion is that they somehow messed up the update, nothing wrong from your side.

    Edit2: the bug seem to be known for a while. There're a couple of bug reports already