Headline
CVE-2021-4034
A local privilege escalation vulnerability was found on polkit’s pkexec utility. The pkexec application is a setuid tool designed to allow unprivileged users to run commands as privileged users according predefined policies. The current version of pkexec doesn’t handle the calling parameters count correctly and ends trying to execute environment variables as commands. An attacker can leverage this by crafting environment variables in such a way it’ll induce pkexec to execute arbitrary code. When successfully executed the attack can cause a local privilege escalation given unprivileged users administrative rights on the target machine.
Qualys Security Advisory pwnkit: Local Privilege Escalation in polkit’s pkexec (CVE-2021-4034) ======================================================================== Contents ======================================================================== Summary Analysis Exploitation Acknowledgments Timeline ======================================================================== Summary ======================================================================== We discovered a Local Privilege Escalation (from any user to root) in polkit’s pkexec, a SUID-root program that is installed by default on every major Linux distribution: “Polkit (formerly PolicyKit) is a component for controlling system-wide privileges in Unix-like operating systems. It provides an organized way for non-privileged processes to communicate with privileged ones. […] It is also possible to use polkit to execute commands with elevated privileges using the command pkexec followed by the command intended to be executed (with root permission).” (Wikipedia) This vulnerability is an attacker’s dream come true: - pkexec is installed by default on all major Linux distributions (we exploited Ubuntu, Debian, Fedora, CentOS, and other distributions are probably also exploitable); - pkexec is vulnerable since its creation, in May 2009 (commit c8c3d83, “Add a pkexec(1) command”); - any unprivileged local user can exploit this vulnerability to obtain full root privileges; - although this vulnerability is technically a memory corruption, it is exploitable instantly, reliably, in an architecture-independent way; - and it is exploitable even if the polkit daemon itself is not running. We will not publish our exploit immediately; however, please note that this vulnerability is trivially exploitable, and other researchers might publish their exploits shortly after the patches are available. If no patches are available for your operating system, you can remove the SUID-bit from pkexec as a temporary mitigation; for example: # chmod 0755 /usr/bin/pkexec This vulnerability is one of our most beautiful discoveries; to honor its memory, we recommend listening to DJ Pone’s “Falken’s Maze” (double pun intended) while reading this advisory. Thank you very much! ======================================================================== Analysis ======================================================================== pkexec is a sudo-like, SUID-root program, described as follows by its man page: ------------------------------------------------------------------------ NAME pkexec - Execute a command as another user SYNOPSIS pkexec [–version] [–disable-internal-agent] [–help] pkexec [–user username] PROGRAM [ARGUMENTS…] DESCRIPTION pkexec allows an authorized user to execute PROGRAM as another user. If PROGRAM is not specified, the default shell will be run. If username is not specified, then the program will be executed as the administrative super user, root. ------------------------------------------------------------------------ The beginning of pkexec’s main() function processes the command-line arguments (lines 534-568), and searches for the program to be executed (if its path is not absolute) in the directories of the PATH environment variable (lines 610-640): ------------------------------------------------------------------------ 435 main (int argc, char *argv[]) 436 { … 534 for (n = 1; n < (guint) argc; n++) 535 { … 568 } … 610 path = g_strdup (argv[n]); … 629 if (path[0] != ‘/’) 630 { … 632 s = g_find_program_in_path (path); … 639 argv[n] = path = s; 640 } ------------------------------------------------------------------------ Unfortunately, if the number of command-line arguments argc is 0 (if the argument list argv that we pass to execve() is empty, i.e. {NULL}), then argv[0] is NULL (the argument list’s terminator) and: - at line 534, the integer n is permanently set to 1; - at line 610, the pointer path is read out-of-bounds from argv[1]; - at line 639, the pointer s is written out-of-bounds to argv[1]. But what exactly is read from and written to this out-of-bounds argv[1]? To answer this question, we must digress briefly. When we execve() a new program, the kernel copies our argument and environment strings and pointers (argv and envp) to the end of the new program’s stack; for example: |---------±--------±----±-----------|---------±--------±----±-----------| | argv[0] | argv[1] | … | argv[argc] | envp[0] | envp[1] | … | envp[envc] | |----|----±—|----±----±----|------|----|----±—|----±----±----|------| V V V V V V “program” "-option" NULL “value” “PATH=name” NULL Clearly (because the argv and envp pointers are contiguous in memory), if argc is 0, then the out-of-bounds argv[1] is actually envp[0], the pointer to our first environment variable, "value". Consequently: - at line 610, the path of the program to be executed is read out-of-bounds from argv[1] (i.e. envp[0]), and points to "value"; - at line 632, this path “value” is passed to g_find_program_in_path() (because “value” does not start with a slash, at line 629); - g_find_program_in_path() searches for an executable file named “value” in the directories of our PATH environment variable; - if such an executable file is found, its full path is returned to pkexec’s main() function (at line 632); - and at line 639, this full path is written out-of-bounds to argv[1] (i.e. envp[0]), thus overwriting our first environment variable. More precisely: - if our PATH environment variable is "PATH=name", and if the directory “name” exists (in the current working directory) and contains an executable file named "value", then a pointer to the string “name/value” is written out-of-bounds to envp[0]; - or, if our PATH is "PATH=name=.", and if the directory “name=.” exists and contains an executable file named "value", then a pointer to the string “name=./value” is written out-of-bounds to envp[0]. In other words, this out-of-bounds write allows us to re-introduce an “unsecure” environment variable (for example, LD_PRELOAD) into pkexec’s environment; these “unsecure” variables are normally removed (by ld.so) from the environment of SUID programs before the main() function is called. We will exploit this powerful primitive in the following section. Last-minute note: polkit also supports non-Linux operating systems such as Solaris and *BSD, but we have not investigated their exploitability; however, we note that OpenBSD is not exploitable, because its kernel refuses to execve() a program if argc is 0. ======================================================================== Exploitation ======================================================================== Our question is: to successfully exploit this vulnerability, which “unsecure” variable should we re-introduce into pkexec’s environment? Our options are limited, because shortly after the out-of-bounds write (at line 639), pkexec completely clears its environment (at line 702): ------------------------------------------------------------------------ 639 argv[n] = path = s; … 657 for (n = 0; environment_variables_to_save[n] != NULL; n++) 658 { 659 const gchar *key = environment_variables_to_save[n]; … 662 value = g_getenv (key); … 670 if (!validate_environment_variable (key, value)) … 675 } … 702 if (clearenv () != 0) ------------------------------------------------------------------------ The answer to our question comes from pkexec’s complexity: to print an error message to stderr, pkexec calls the GLib’s function g_printerr() (note: the GLib is a GNOME library, not the GNU C Library, aka glibc); for example, the functions validate_environment_variable() and log_message() call g_printerr() (at lines 126 and 408-409): ------------------------------------------------------------------------ 88 log_message (gint level, 89 gboolean print_to_stderr, 90 const gchar *format, 91 …) 92 { … 125 if (print_to_stderr) 126 g_printerr ("%s\n", s); ------------------------------------------------------------------------ 383 validate_environment_variable (const gchar *key, 384 const gchar *value) 385 { … 406 log_message (LOG_CRIT, TRUE, 407 “The value for the SHELL variable was not found the /etc/shells file”); 408 g_printerr (“\n” 409 “This incident has been reported.\n”); ------------------------------------------------------------------------ g_printerr() normally prints UTF-8 error messages, but it can print messages in another charset if the environment variable CHARSET is not UTF-8 (note: CHARSET is not security sensitive, it is not an “unsecure” environment variable). To convert messages from UTF-8 to another charset, g_printerr() calls the glibc’s function iconv_open(). To convert messages from one charset to another, iconv_open() executes small shared libraries; normally, these triplets (“from” charset, “to” charset, and library name) are read from a default configuration file, /usr/lib/gconv/gconv-modules. Alternatively, the environment variable GCONV_PATH can force iconv_open() to read another configuration file; naturally, GCONV_PATH is one of the “unsecure” environment variables (because it leads to the execution of arbitrary libraries), and is therefore removed by ld.so from the environment of SUID programs. Unfortunately, CVE-2021-4034 allows us to re-introduce GCONV_PATH into pkexec’s environment, and to execute our own shared library, as root. Important: this exploitation technique leaves traces in the logs (either “The value for the SHELL variable was not found the /etc/shells file” or “The value for environment variable […] contains suscipious content”). However, please note that this vulnerability is also exploitable without leaving any traces in the logs, but this is left as an exercise for the interested reader. For further discussions about pkexec, GLib, and GCONV_PATH, please refer to the following posts by Tavis Ormandy, Jakub Wilk, and Yuki Koike: https://www.openwall.com/lists/oss-security/2014/07/14/1 https://www.openwall.com/lists/oss-security/2017/06/23/8 https://hugeh0ge.github.io/2019/11/04/Getting-Arbitrary-Code-Execution-from-fopen-s-2nd-Argument/ ======================================================================== Acknowledgments ======================================================================== We thank polkit’s authors, Red Hat Product Security, and the members of distros@openwall for their invaluable help with the disclosure of this vulnerability. We also thank Birdy Nam Nam for their inspiring work. ======================================================================== Timeline ======================================================================== 2021-11-18: Advisory sent to secalert@redhat. 2022-01-11: Advisory and patch sent to distros@openwall. 2022-01-25: Coordinated Release Date (5:00 PM UTC).
Related news
Russian organizations have been targeted by a cybercrime gang called ExCobalt using a previously unknown Golang-based backdoor known as GoRed. "ExCobalt focuses on cyber espionage and includes several members active since at least 2016 and presumably once part of the notorious Cobalt Gang," Positive Technologies researchers Vladislav Lunin and Alexander Badayev said in a technical report
The vmwgfx driver contains a local privilege escalation vulnerability that allows unprivileged users to gain access to files opened by other processes on the system through a dangling 'file' pointer.
A new Linux security vulnerability dubbed Looney Tunables has been discovered in the GNU C library's ld.so dynamic loader that, if successfully exploited, could lead to a local privilege escalation and allow a threat actor to gain root privileges. Tracked as CVE-2023-4911 (CVSS score: 7.8), the issue is a buffer overflow that resides in the dynamic loader's processing of the GLIBC_TUNABLES
gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks: - Unbounded memory buffering in the HPACK parser - Unbounded CPU consumption in the HPACK parser The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client. The unbounded memory buffering bugs: - The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb. - HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse. - gRPC’s metadata overflow check was performed per frame, so ...
A new intelligence gathering campaign linked to the prolific North Korean state-sponsored Lazarus Group leveraged known security flaws in unpatched Zimbra devices to compromise victim systems. That's according to Finnish cybersecurity company WithSecure (formerly F-Secure), which codenamed the incident No Pineapple. Targets of the malicious operation included a healthcare research organization
Dell EMC Metro node, Version(s) prior to 7.1, contain a Code Injection Vulnerability. An authenticated nonprivileged attacker could potentially exploit this vulnerability, leading to the execution of arbitrary OS commands on the application.
Vulnerability in the Oracle Web Applications Desktop Integrator product of Oracle E-Business Suite (component: Upload). Supported versions that are affected are 12.2.3-12.2.11. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Web Applications Desktop Integrator. Successful attacks of this vulnerability can result in takeover of Oracle Web Applications Desktop Integrator. CVSS 3.1 Base Score 9.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
By Deeba Ahmed Alchimist is a single-file C2 framework discovered on a server hosting an active file listing on the root directory and a set of post-exploitation tools. This is a post from HackRead.com Read the original post: Linux, Windows and macOS Hit By New “Alchimist” Attack Framework
A previously undocumented command-and-control (C2) framework dubbed Alchimist is likely being used in the wild to target Windows, macOS, and Linux systems. "Alchimist C2 has a web interface written in Simplified Chinese and can generate a configured payload, establish remote sessions, deploy payload to the remote machines, capture screenshots, perform remote shellcode execution, and run
By Chetan Raghuprasad, Asheer Malhotra and Vitor Ventura, with contributions from Matt Thaxton. Cisco Talos discovered a new attack framework including a command and control (C2) tool called "Alchimist" and a new malware "Insekt" with remote administration capabilities. The Alchimist has a web interface in Simplified Chinese with remote administration features. The attack framework is designed to target Windows, Linux and Mac machines. Alchimist and Insekt binaries are implemented in GoLang. This campaign consists of additional bespoke tools such as a MacOS exploitation tool, a custom backdoor and multiple off-the-shelf tools such as reverse proxies. Cisco Talos has discovered a new single-file command and control (C2) framework the authors call "Alchimist [sic]." Talos researchers found this C2 on a server that had a file listing active on the root directory along with a set of post-exploitation tools. Cisco Talos assesses with moderate-high confidence that this framework is being...
Cisco Talos discovered a new attack framework including a command and control (C2) tool called "Alchimist" and a new malware "Insekt" with remote administration capabilities.
A now-patched critical security flaw affecting Atlassian Confluence Server that came to light a few months ago is being actively exploited for illicit cryptocurrency mining on unpatched installations. "If left unremedied and successfully exploited, this vulnerability could be used for multiple and more malicious attacks, such as a complete domain takeover of the infrastructure and the deployment
By Deeba Ahmed The stealthy malware leverages security flaws to gain privilege escalation and establish persistence. This is a post from HackRead.com Read the original post: Stealthy Linux Malware Shikitega Deploying Monero Cryptominer
Categories: News Categories: Threats Researchers from the AT&T Alien Labs Resarch have discovered a stealthy new Linux malware. (Read more...) The post Evasive Shikitega Linux malware drops Monero cryptominer appeared first on Malwarebytes Labs.
The Shikitega malware takes over IoT and endpoint devices, exploits vulnerabilities, uses advanced encoding, abuses cloud services for C2, installs a cryptominer, and allows full remote control.
A new piece of stealthy Linux malware called Shikitega has been uncovered adopting a multi-stage infection chain to compromise endpoints and IoT devices and deposit additional payloads. "An attacker can gain full control of the system, in addition to the cryptocurrency miner that will be executed and set to persist," AT&T Alien Labs said in a new report published Tuesday. The findings add to a
PrinterLogic Windows Client through 25.0.0.676 allows attackers to execute directory traversal. Authenticated users with prior knowledge of the driver filename could exploit this to escalate privileges or distribute malicious content.
Ravie Lakshmanan's recent article CISA warns of active exploitation of 'PwnKit' Linux vulnerability in the wild articulates the vulnerability in Polkit (CVE-2021-4034) and recommends "to mitigate any potential risk of exposure to cyberattacks… that organizations prioritize timely remediation of the issues," while "federal civilian executive branch agencies, however, are required to mandatorily patch the flaws by July 18
Hello everyone! In this episode, I will try to revive Security News with a focus on Vulnerability Management. On the one hand, creating such reviews requires free time, which could be spent more wisely, for example, on open source projects or original research. On the other hand, there are arguments in favor of news reviews. […]
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) this week moved to add a Linux vulnerability dubbed PwnKit to its Known Exploited Vulnerabilities Catalog, citing evidence of active exploitation. The issue, tracked as CVE-2021-4034 (CVSS score: 7.8), came to light in January 2022 and concerns a case of local privilege escalation in polkit's pkexec utility, which allows an
Security considerations are even more important today than they were in the past. Every day we discover new vulnerabilities that impact our computer systems, and every day our computer systems become more complex. With the deluge of vulnerabilities that threaten to swamp our security teams, the question, "How much does it matter?" comes quickly to our minds. This question, "Does it matter?", has two parts: