Why the Recent Linux Vulnerability Means it’s Time to Finally Replace sudo

A few weeks ago, we learned of a newly-discovered Linux security hole that enables a sudoer to gain complete access to a Linux box. This hole applies to systems with SELinux enabled. And while this might not be the first sudo-centric vulnerability, this one has wide-ranging impacts. The security hole exists in sudo 1.7.10 through 1.7.10p9, and in sudo 1.8.5 through 1.8.20p1. All Linux distros released in the last five years are vulnerable to this attack. The good news is, there are a couple basic steps you can take to ensure this vulnerability doesn’t have business-impacting consequences. The first is replacing sudo! The second step (if you can’t replace it) is to patch. In this blog, I will first review reasons that lead to exploits using sudo, and what you can do to remediate these vulnerabilities.

How sudo Comes up Short – Open Source Support and Local Auditing

It is always a philosophical debate as to whether to use open source software in a regulated environment. Open source software is crowd-sourced and developers from all over the world contribute to packages that are later included in OS distributions. In the case of sudo, a package designed to provide privileged access included in many Linux distributions, the debate is whether it meets the requirements of an organization, and to what level it can be relied upon to deliver compliance information to auditors. The sudo package is installed locally on individual servers, and configuration files are maintained on each server individually. There are some tools such as Puppet or Chef that can monitor these files for changes, and replace files with known good copies when a change is detected, but those tools only work after a change takes place. These tools usually operate on a schedule, often checking once or twice per day, so if a system is compromised, or authorization files are changed, it may be several hours before the system is restored to a known good state. The question is, what can happen in those hours? Since sudo is an open source package, there is no official service level for when packages must be updated to respond to identified security flaws, or vulnerabilities. By mid-2017, there have already been two vulnerabilities identified in ‘sudo’ with a CVSS score greater than six (CVE Sudo Vulnerabilities ). Over the past several years, there have been a number of vulnerabilities discovered in sudo that took as many as three years to patch (CVE-2013-2776, CVE-2013-2777, CVE-2013-1776 ). The question here is, what exploits have been used in the past several months or years? There is logging within sudo, but by default these sudo logs are stored locally on servers. When advanced users are granted administrative access on servers, it is possible that log data can be modified, or deleted, and all evidence of their activities erased with very little indication that events took place. Now, the question is, has this happened, or is it continuing to happen? Large organizations typically collect a tremendous amount of data, including system logs, access information, and other system information from all their systems. This data is then sent to a SIEM for analytics, and reporting. SIEM tools do not usually deliver ‘real-time’ alerting when uncharacteristic events happen on systems, and often configuration of events is difficult and time consuming. For this reason, SIEM solutions are rarely relied upon for alerting within an enterprise environment. Here the question is, what is an acceptable delay from the time an event takes place until someone is alerted?

Although sudo is a low-cost solution, it may come at a high price in a security program, and when an organization is delivering compliance data to satisfy auditors.

Commercial solutions provide an effective way to mitigate the general issues related to sudo:

1. Solutions that offer centralized management ease the pressure on monitoring and maintaining remote systems, centralized logging of events, and keystroke recording are the cornerstone of audit expectations for most enterprises.
2. Commercial solutions usually have a regular release cycle, and can typically deliver patches in response to vulnerabilities in hours or days from the time they’re reported.
3. Commercial solutions like PowerBroker for Unix & Linux provide event logging on separate infrastructure that is inaccessible to privileged users, and this eliminates the possibility of log tampering.
4. Commercial solutions provide strong, centralized policy controls that are managed within an infrastructure separate from systems under management; this eliminates the possibility of rogue changes to privileged access policies in server environments. Strong policy control also moves security posture from ‘Respond’ to ‘Prevent’, and advanced features provide the ability to integrate with other enterprise tools, and conditionally alert when privileged access sessions begin, or end.

For organizations that are serious about incorporating a strong privileged access management solution into their security program, there is no question that a commercial product such as PowerBroker delivers much better than an open source offering such as sudo. Eliminating the possibility of malicious behavior using strong controls, centralized log file collection, and centralized policy management is far better than relying on questionable, difficult to manage controls delivered within sudo.

Patching the Holes

Until you can replace sudo, patches are available for almost all significant server Linux distros to respond to this particular set of vulnerabilities just recently announced. If you haven’t done so, patch them immediately using Retin Enterprise Vulnerability Management. Below are the audits that map to the vulnerability, CVE-2017-1000367. These audits are available with Audit revision 3279.

• CentOS: 64062 - CESA-2017:1382 - sudo Security Update
• Debian: 64041 - DSA-3867-1 sudo
• Gentoo: 64037 - GLSA 201705-15: sudo - Privilege Escalation
• Ubuntu: 64068 - USN-3304-1: Sudo vulnerability
• Slackware: 64073 - SSA:2017-150-01: sudo - Local Privilege Escalation
• RedHat: 64124 - RHSA-2017:1382 - sudo security update and 64125 - RHSA-2017:1381 - sudo security update
• Fedora: 64090 - FEDORA-2017-54580efa82 – sudo
• Arch Linux: 64048 - ASA-201705-25: sudo

For more on how to replace sudo with a solution that helps you eliminate credential sharing, limit root access, and ensure accountability for compliance on Unix & Linux systems – without hurting productivity and without relying on native tools or sudo – contact us today.