Qualys discovered a new vulnerability for Linux that has existed on these machines for 12 years. The vulnerability was found “in a system tool called Polkit, which gives attackers unfettered root privileges on machines running any major distribution of the open source operating system.” *
Similar to most operating systems, Linux provides internal security that controls the permissions granted to users and applications. This is intended to enable organizations to enact a least privileged access posture, support separation of duties, and minimize damages if the system is hacked or accessed by a malicious user.
Within Linux, the PolKit tool enables non-privileged system processes to interact with privileged ones. It also provides an interface that allows authorized users to execute privileged commands. Researchers found that this interface (called pkexec) contains a memory-corruption vulnerability, which when exploited to escalate a user’s privileges to root level access. They also found that “exploiting the flaw is trivial and, by some accounts, 100 percent reliable.” * Once a hacker gains access to a machine with this vulnerability, they gain unfettered access to run any command, upload any payload, or download any data on the machine. This vulnerability can even be exploited when the PolKit daemon is not running. The vulnerability has been nicknamed PwnKit (tracked as CVE-2021-4034).
Introducing Symantec PAM Server Control
Symantec Privileged Access Management (PAM), by Broadcom Software, is designed to prevent security breaches by protecting sensitive administrative credentials, controlling privileged user access, proactively enforcing security policies and monitoring and recording privileged user activity across virtual, cloud and physical environments. Since the 4.0 release, Symantec PAM now also delivers localized, fine-grained protections over operating system-level access and privileged user actions on your servers, including Linux, through the server control agents.
Using centrally managed task delegation and platform-specific software restrictions, the Symantec Privileged Access Management Server Control (PAMSC) agents provide file, directory, and resource-specific, kernel-level controls, registry protection, and other localized granular controls to ensure that high-value assets and resources hosted on critical servers are protected from damages caused either by malicious or accidental insider actions.
How Server Control Agents Address the PwnKit Vulnerability
Hackers gain root access by leveraging the Unix setuid command, one of the most sensitive services provided by the operating system, which allows them to substitute their current ID for root, thereby becoming the root administrator and gaining all the privileges assigned to root. The PAMSC agents can intercept the Unix setuid system call and check whether the user is authorized to perform the substitution.
In addition, the substitute user authority check also includes program pathing, which enforces controls such that users are only permitted to substitute their user IDs through specific programs. Security administrators can test programs that are marked as setuid or setgid executables to ensure that they do not contain any security loopholes that can be used to gain unauthorized access. Programs that pass the test and are considered safe can be defined as “Trusted Programs” within PAMSC, and any program that is not contained in this list can be blocked from performing substitutions. Furthermore, the PAMSC Self-Protection Module (also referred to as the PAMSC “watchdog” ) knows which program is in control at a particular time and checks whether the program has been modified or moved since it was classified as Trusted. If a Trusted program is modified or moved, the program is no longer considered Trusted and PAMSC does not allow it to run. This is critical in controlling who can substitute to root and thereby gain root access.
Combined, these PAMSC security features can be used to protect against the PwnKit vulnerability. For example, using this vulnerability, the attacker uses /usr/bin/pkexec to gain authorized access. PAMSC can prevent attackers from exploiting this attack, but first you need to confirm that it is properly configured. Log into PAM and check the following configurations:
- Verify that the default access of the PROGRAM class is set to none.
- Verify that the utility /usr/bin/pkexec is protected by a program record.
One you have confirmed that these settings are correct, you can confirm that they will work by:
- In the root window, try to modify the utility e.g., touch the pkexec utility. This will cause it to become Untrusted to Access Control.
- In the root window, attempt to execute pkexec.
The program will fail to execute because it is no longer trusted by PAMSC. The resources in the PROGRAM class are monitored by the seoswd daemon. Any alteration of the trusted program will result in the daemon “untrusting” the program and prevent its execution.
Finally, we also have PROCESS class, PAMSC can protect executable programs running in their own address spaces from being killed. You can use this feature to define PROCESS records to protect important daemons and applications against denial of service attacks.
It should be noted that even if a hacker could gain unauthorized access to a Superuser or Root account, the PAMSC agents can still enforce fine-grained access controls over what they could do with that account.
Restrict Uncontrolled Use of Root
The PwnKit vulnerability can provide a means for hackers to gain access to the root account, which has full control of all resources on a Unix server. This includes audit logs, configuration files, and application data. Since root is a shared account, it is not uncommon for a dozen or more users on a server to share the root password to accomplish their tasks. However, with so many users sharing this key account, user accountability becomes difficult. It is important to realize that unauthorized users can obtain root access using various security hacks besides the PwnKit vulnerability (e.g., buffer overflow exploits, trojan horses, and improper file permissions and settings.
Symantec PAMSC can restrict users' access, even when they become root. It addresses this issue by creating roles that define the administrative tasks that can be run by specific users. For example, you could define a role that restricts the user to certain application software to perform management activities on that application, or you could restrict a user to read-only access for system files if their job was simply doing backups. In this fashion, you could also enforce separation of duties through different roles for different users, who have access to the same root account.
Symantec PAMSC can also prevent known exploits in Unix by monitoring setuid and setgid programs. The weak points involve back doors and trojan horses:
- A back door is a setuid program that is owned by root. Thus, for as long as it is running, the program serves as an inconspicuous access (back door) to root privileges for whomever is running it.
- A trojan horse is a destructive program that masquerades as an innocent program. A hacker attacking a Unix system might, for example, replace the su command with a rewritten version that not only performs the command’s proper function but also e-mails the target account-name and its password to a specified address.
Through the PAMSC program and secfile classes, administrators can prevent attacks or control the damage that can happen because of these attacks.
Historically, Symantec as part of Broadcom Software, has offered two PAM architecture frameworks:
- Privileged Access Manager, which protected privileged accounts by vaulting their credentials and forcing privileged users to authenticate themselves to the tool before access was granted. This was an appliance-based product that leveraged a proxy-based approach.
- Privileged Access Manager (formerly Privileged Identity Manager), which enforce fine-grained access controls over privileged users through agents installed on the server operating systems.
With the release of Symantec PAM 4.0, we have brought these two products together as a single consolidated OnePAM solution. Although the PAMSC agents still need to be deployed on the servers to be protected, these agents and their policies can be configured through the PAM appliance user console.
This eliminated the PAMSC Enterprise Manager server and replaced the Distribution Server with a new Utility Appliance to yield a consolidated PAM solution that can address all your privileged access management use cases. For more information on how we can help you, please visit our Symantec PAM product page or contact us here.
*ARS Technica, A bug lurking for 12 years gives attackers root on every major Linux distro, Dan Goodin, January 25, 2022.
We encourage you to share your thoughts on your favorite social platform.