Developers have patched a vulnerability in Sudo, a core command utility for Linux, that could allow a user to execute commands as a root user even if that root access was specifically disallowed.
The patch prevents potential serious consequences within Linux systems. However, the Sudo vulnerability posed a threat only to a narrow segment of the Linux user base, according to Todd Miller, software developer and senior engineer at Quest Software and a maintainer of the open source Sudo project.
“Most Sudo configurations are not affected by the bug. Non-enterprise home users are unlikely to be affected at all,” he told LinuxInsider.
Still, the vulnerability is considered serious. That is why Red Hat rated it almost 8/10 in terms of risk, said Jason David, CEO of Software Portal.
“The only fix at this point is to install the patch in Sudo 1.8.28. In the meantime, you could temporarily remove all users from the sudoers (users) file and replace them after the patch has been installed,” he told LinuxInsider.
Developers released the Sudo patch several days ago. However, it must be packaged for each Linux distribution and distributed through the hundreds of Linux communities that maintain individual Linux operating systems.
What It Does
The Sudo bug is designated CVE-2019-14287 in the Common Vulnerabilities and Exposures database. Joe Vennix from Apple Information Security found and analyzed the bug.
Once the patch is installed, the Sudo bug will affect only Sudo versions prior to 1.8.28. Red Hat rated the flaw with a 7.8 severity score out of 10 on the CvSS scale.
Sudo stands for “superuser do.” Sudo commands are entered into a terminal command line application to carry out routine software management and other Linux system configurations and activities.
Sudo is a system command that allows a user to run applications or commands with the privileges of a different user — such as the system administrator — without switching environments. Most often, Sudo is used for running commands as the root user.
The bug allows users to bypass privilege restrictions to execute commands as root. Basically, it allows attackers to circumvent built-in security options to block root access for specified users.
How It Works
Attackers can use the Sudo exploit merely by specifying the user ID of the person executing commands to be “-1” or “4294967295.” The bug allows both of these user IDs to resolve automatically to the value “0” — the user ID for root access.
Sudo does not require a password to run commands in the context of another user. The exploitation level of difficulty is low, according to Red Hat.
Linux distributions that contain the “ALL” keyword in the RunAs specification in the /etc/sudoers configuration file are affected. The ALL keyword allows all users in a specific group to run any command as any valid user on the system, and usually is present in default configurations of Linux, according to Red Hat.
That bug scenario potentially could have impacted a large user segment, according to some software engineers, but others argued that the problem would not have affected most Linux users.
Pushing the Privilege
Privilege separation is one of the fundamental security paradigms in Linux. In an enterprise setting, administrators can configure a sudoers file to define which users can run what commands.
In a specific scenario in which a user is allowed to run a command as any other user except the root, the vulnerability could allow that user to bypass the security policy and take complete control over the system as root.
Otherwise, the user would have to know the password for root access in order to execute a sudo command. The addition of the parameters -u#-1 or -u#4294967295 to the sudo command is all it would take to gain the extra privileges of root, Miller explained in a post on the Sudo website.
It is always good practice to stay up to date with your distro’s patches and packages. However, unless you have a sudoers file that uses the idiom described above, there is no need to rush to update your Sudo package, noted Miller.
“I am not aware of any vendors who ship a stock sudoers file that would be affected,” he said.
Unique Setup Required
The configuration of the Linux operating system is the critical factor determining whether the Sudo vulnerability can work. The Sudo bug affects only Linux computers that have been configured in a very non-standard way, emphasized Douglas Crawford, tech expert at ProPrivacy.
“It does not affect most Linux systems, and no Linux system is vulnerable by default,” he told LinuxInsider.
The vulnerability affects only systems that have been configured to allow other authorized users to execute a limited set of sudo commands. By exploiting the bug these restricted-access sudoers can execute commands as if they have full sudo (administrator) privileges, Crawford explained.
“Not only is this a very unusual setup, but it is very much not recommended, even without taking the bug into account. It is also only of concern if for some reason you do not trust your restricted-access sudoers not to exploit the situation,” he added. “And if you do not trust your sudoers, then why did you give them any admin privileges in the first place?”
Limited Impact at Worst
The bark seems worse than the bite with this particular Linux vulnerability. It is not really a very critical vulnerability, suggested Chris Morales, head of security analytics at Vectra.
“The system configuration of allowing a user to run a command as any user except does not seem normal to me. This would impact a very specific system with a specific need for that type of configuration,” he told LinuxInsider.
In an enterprise environment, system administrators — and for that matter, other users — can run a quick check to verify if their computers are at risk for the Sudo bug, said Mehul Revankar, senior product manager at SaltStack.
Check sudoers configuration for vulnerable entries by running this command in a terminal: # grep -r ‘!s*root>’ /etc/sudoers /etc/sudoers.d/ | grep -v ‘^s*#’If this command produces no output, then the system is not vulnerable, otherwise configuration needs to be reviewed, Revankar told LinuxInsider. Vulnerable configuration entries will look similar to the following:alice myhost = (ALL, !root) /usr/bin/viIf present, these should be disabled or changed to list allowed target user names explicitly and avoid the “!” syntax.
Loading ...
