SLES 12 — portus — multiple vulnerabilities (11 CVEs) — patch and remediation guide

📖 ~4 min read  •  Source: SUSE advisory SUSE-SU-2016:0435-1 (see also SUSE bugzilla)

Related CVEs: CVE-2015-7576 CVE-2015-7577 CVE-2015-7578 CVE-2015-7579 CVE-2015-7580 CVE-2015-7581 CVE-2016-0752 CVE-2016-0753  +3 more

Upstream summary: The http_basic_authenticate_with method in actionpack/lib/action_controller/metal/http_authentication.rb in the Basic Authentication implementation in Action Controller in Ruby on Rails before 3.2.22.1, 4.0.x and 4.1.x before 4.1.14.1, 4.2.x before 4.2.5.1, and 5.x before 5.0.0.beta1.1 does not use a constant-time algorithm for verifying credentials, which makes it easier for remote attackers to bypass authentication by measuring timing differences.

Table of contents

1. Symptom & Impact
2. Environment & Reproduction
3. Root Cause Analysis
4. Quick Triage
5. Step-by-Step Diagnosis
6. Solution – Primary Fix
7. Solution – Alternative Approaches
8. Verification & Acceptance Criteria
9. Rollback Plan
10. Prevention & Hardening
11. Related Errors & Cross-Refs
12. References & Further Reading

Symptom & Impact

portus runs when an image is pulled, unpacked, inspected or a container is started, so a defect here is normally reached through untrusted image content or a registry response rather than inbound traffic to a listening port. On SLES 12 that shows up as escapes from the container’s namespaces, files written outside the intended root during buildah or podman build, mount and capability handling that grants more than was requested, and images produced before the update carrying the defect onward to every host that pulls them. portus is container tooling — command-line binaries invoked per operation, though a node runtime such as cri-o does run as a unit — so restart steps apply to that runtime and to containers still running the old code, not to portus itself.

Environment & Reproduction

Reproduction targets SLES 12. Confirm release, registration, and installed package:

cat /etc/os-release
SUSEConnect --status-text
SUSEConnect --list-extensions 2>/dev/null | head -30
rpm -q portus
zypper info portus | head -20

Exercise the workload that uses portus while collecting:

sudo zypper ps  # NATIVE SUSE TOOL, no extra package: every running process still using deleted/replaced files, plus the owning service name
sudo zypper ps -s  # short table (PID, PPID, UID, login, command, service) without the per-file detail
sudo zypper ps -sss  # service names ONLY, one per line - safe to pipe straight into systemctl
sudo journalctl -xe --no-pager | tail -200
sudo tail -200 /var/log/zypp/history
sudo tail -200 /var/log/audit/audit.log
# For SUSE support, bundle evidence with supportconfig:
sudo supportconfig -R /var/tmp -B portus

Root Cause Analysis

Root cause is documented in SUSE advisory SUSE-SU-2016:0435-1. SUSE security maintainers shipped fixes in the corresponding portus update for SLES 12; running an outdated build leaves the host exposed to the failure modes described in the advisory. Correlate zypper history with system logs:

sudo zypper history | grep portus
sudo zypper history --since='-7 days' | tail -40
sudo journalctl -k | grep -i apparmor | tail -100
cat /proc/sys/kernel/tainted   # non-zero = tainted kernel / out-of-tree modules

Quick Triage

Run these on SLES 12 to capture the current state of portus:

rpm -q portus                              # installed NVR
rpm -V portus                              # verify shipped files
sudo zypper patch-check                    # open patches
sudo zypper lp -r SUSE-SLE-Server-12-* 2>/dev/null | head
systemctl --failed --no-pager
sudo firewall-cmd --list-all 2>/dev/null || sudo SuSEfirewall2 status 2>/dev/null
sudo aa-status                              # AppArmor profiles
rpm -ql portus | grep -E '^/(usr/lib|etc)/systemd/(system|user)/[^/]+\.(service|socket|timer|path|target|mount)$'  # the units portus REALLY ships - NO OUTPUT means it ships no service at all, so never run systemctl on it
rpm -ql portus | grep -E '^/usr/sbin/rc[^/]+$'  # SUSE-only rcNAME compat symlink (it points at /usr/sbin/service, not at a unit): the NAME after 'rc' IS the service name - bind ships /usr/sbin/rcnamed, so the unit is named.service

Step-by-Step Diagnosis

1. List failed systemd units.

   systemctl --failed --no-pager

2. Tail the journal for portus and the system bus.

   sudo journalctl -xe -f --no-pager

3. Inspect firewall posture. This release uses firewalld; SuSEfirewall2 may still be present on SLES 12 GA.

   sudo firewall-cmd --list-all-zones
   sudo SuSEfirewall2 status 2>/dev/null   # legacy, only present on early SLES 12
   sudo iptables -L -n -v | head -30

4. Surface AppArmor denials and switch the profile to complain mode if needed.

   sudo journalctl -k | grep -i 'apparmor="DENIED"' | tail -30
   sudo aa-status

5. Verify portus integrity and reinstall if anything is altered.

   sudo rpm -V portus
   sudo zypper verify
   sudo zypper install --force portus

6. Correlate findings with /var/log/zypp/history, zypper history, and SUSE advisory SUSE-SU-2016:0435-1 to pin the change that introduced the regression.

Solution – Primary Fix

Apply the corrective zypper transaction referenced by SUSE advisory SUSE-SU-2016:0435-1, then reload affected systemd units:

sudo zypper ref                        # refresh repos
sudo zypper -n patch                   # apply ALL open patches (recommended)
# Or target a single package:
sudo zypper -n update portus
sudo systemctl daemon-reload
# Unit name may differ from pkg name; check first:
rpm -qa --qf '%{VENDOR}\t%{BUILDHOST}\t%{BUILDTIME:date}\t%{NAME}-%{VERSION}-%{RELEASE}\n' | awk -F'\t' '$1 !~ /SUSE/'  # packages NOT built by SUSE are your own builds - these were compiled with the vulnerable portus and need rebuilding
readelf -p .comment /usr/local/bin/YOURAPP  # prints e.g. 'GCC: (SUSE Linux) 7.5.0' - the compiler that actually built it (binutils; empty output just means the section was stripped)
objdump -s -j .comment /usr/local/bin/YOURAPP  # the same evidence via objdump (binutils)
rpm -q portus                           # confirm new NVR

For kernel / glibc / systemd / openssl advisories a reboot is required (or SLE Live Patching where licensed):

sudo zypper ps -s                      # services using deleted libs
sudo systemctl reboot                  # or: sudo shutdown -r now
# SUSE Live Patching (kgraft / klp) avoids reboot for kernel CVEs:
sudo zypper install -y kernel-livepatch-$(uname -r | tr - _)
klp -v patches                         # active livepatches

Solution – Alternative Approaches

If the primary patch is not viable, choose from these:

• Roll back via Snapper (Btrfs snapshots taken automatically before zypper transactions on SLES 12):

  sudo snapper list
  sudo snapper undochange <pre>..<post>  # diff between two snapshot numbers
  sudo snapper rollback <pre>            # boot the host into the chosen snapshot

• Lock the package so zypper cannot upgrade it:

  sudo zypper al portus                   # add lock
  zypper ll | grep portus                 # list locks
  sudo zypper rl portus                   # remove lock

• Install an older NVR if a regression is suspected:

  zypper se -s portus                     # show all available versions
  sudo zypper install --oldpackage portus-<older-NVR>

• If SuSEfirewall2 is still in use (rare on modern SLES 12), migrate to firewalld:

  sudo zypper install -y firewalld
  sudo systemctl disable --now SuSEfirewall2
  sudo systemctl enable --now firewalld

• Disable the AppArmor profile briefly to confirm policy is the cause, then re-enable:

  # reproduce, capture denials in the journal:
  sudo journalctl -k | grep apparmor | tail

• Where SLE Live Patching is licensed, apply kernel fixes without reboot:

  klp -v patches                         # active livepatches
  sudo zypper install -y kernel-livepatch-$(uname -r | tr - _)

Verification & Acceptance Criteria

All of these should pass after the fix:

rpm -q portus                                            # expected fixed NVR
sudo zypper patch-check                                  # 0 critical patches outstanding
sudo firewall-cmd --list-services
sudo aa-status | head -5
sudo zypper ps -s                                        # any services still using deleted libs

The conditions described in the advisory must no longer be reported for portus across two consecutive runs.

Rollback Plan

Capture state before any change:

rpm -qa > /root/rpm-pre.txt
sudo zypper history list > /root/zypper-history-pre.txt
# Snapper takes pre/post snapshots automatically on Btrfs root.
sudo snapper create -d 'pre-patch-portus'   # explicit named snapshot
sudo snapper list | head

To revert if the patch is bad:

# Preferred on Btrfs root — boot the prior snapshot:
sudo snapper rollback <snapshot-id>
sudo systemctl reboot
# Or downgrade just the package:
sudo zypper install --oldpackage portus-<older-NVR>
sudo systemctl daemon-reload
# Custom security policy cleanup:

Prevention & Hardening

Reduce the chance of this recurring on SLES 12:

• Enable automatic patch installation:

  sudo zypper install -y zypper-automatic
  sudo systemctl enable --now zypper-automatic.timer
  # Or use YaST: yast2 online_update_configuration

• Subscribe to sle-security-updates and watch suse.com/support/update.

• Mirror through SUSE Manager or RMT (Repository Mirroring Tool) for controlled rollouts:

  sudo zypper install -y rmt-server rmt-cli
  sudo rmt-cli sync
  sudo rmt-cli products enable SLES/12/x86_64

• Lock sensitive packages so they cannot be auto-upgraded:

  sudo zypper al portus

• Ensure Snapper is enabled on the root subvolume and pre/post hooks run for every zypper transaction:

  sudo snapper -c root get-config | head
  # Default zypper plugin: /usr/lib/zypp/plugins/commit/snapper.zypp-commit-plugin

• Monitor file integrity with AIDE:

  sudo zypper install -y aide
  sudo aide --init && sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
  sudo aide --check

• Subscribe to SUSE Live Patching so kernel CVEs can be remediated without reboot:

  sudo SUSEConnect -p sle-module-live-patching/12.0/x86_64
  sudo zypper install -y kernel-livepatch-$(uname -r | tr - _)
  klp -v patches

• Keep AppArmor profiles in enforce; review /etc/apparmor.d/ after every package upgrade.

• Apply CIS SUSE Linux Enterprise Server Benchmark hardening.

Related Errors & Cross-Refs

Issues that commonly surface alongside a portus update: zypper lock contention, systemd unit ordering cycles, AppArmor denials, firewalld zone drift, and kernel taint flags. Useful triage:

sudo zypper ps -s
systemd-analyze critical-chain
sudo journalctl -k | grep apparmor | tail
sudo firewall-cmd --get-active-zones
cat /proc/sys/kernel/tainted

View all sles-12 tutorials on the Tutorials Hub →

Browse all common problems & solutions on the Tutorials Hub.

References & Further Reading

Primary reference: SUSE advisory SUSE-SU-2016:0435-1 (see also SUSE bugzilla). Manual pages useful on SLES 12:

man zypper
man zypper.conf
man systemctl
man journalctl
man firewall-cmd
man snapper
man apparmor
man aa-status
man SUSEConnect
man klp

Other resources: SUSE Linux Enterprise Server 12 documentation, suse.com/security, SUSE security blog, and per-package notes in /usr/share/doc/packages/portus/ for components implicated in this advisory.