Tag Archive for Linux

GitHub Releases Key Findings of an Easy-to-Exploit Linux flaw

 

Kevin Backhouse, a researcher at GitHub Security Lab revealed the details of an easy-to-exploit Linux flaw that can be exploited to escalate privileges to root on the targeted system. The vulnerability, classified as highly critical and termed as CVE-2021-3560, affects polkit, a system service installed by default on many Linux distributions.

On Thursday, Kevin published a blog post explaining his findings, as well as a short video detailing the exploit in polkit. A local, unprivileged attacker can use the flaw to escalate privileges to root with only a few commands executed in the terminal. 

Security researchers have admitted the vulnerability termed CVE-2021-3560 impacts some versions of Red Hat Enterprise Linux, Fedora, Debian, and Ubuntu. On June 3, a patch for CVE-2021-3560 was released. 

“The bug I found was quite old. It was introduced seven years ago in commit bfa5036 and first shipped with polkit version 0.113. However, many of the most popular Linux distributions didn’t ship the vulnerable version until more recently,” Backhouse stated.

“The bug has a slightly different history on Debian and its derivatives (such as Ubuntu) because Debian uses a fork of polkit with a different version numbering scheme. In the Debian fork, the bug was introduced in commit f81d021 and first shipped with version 0.105-26. The most recent stable release of Debian, Debian 10 (“buster”), uses version 0.105-25, which means that it isn’t vulnerable, ”Backhouse further added. 

Polkit is a system service developed for controlling system-wide privileges, creating a way for non-privileged processes to communicate with privileged processes. Backhouse described it as a service that plays the role of a judge, determining whether an action initiated by a user — specifically one that requires higher privileges — can be carried out directly or requires additional authorization, such as entering a password.

The vulnerability identified by the researcher is easy to manipulate, with just a few commands in the terminal. However, due to some timing requirements, it normally takes a few attempts for the exploit to be successful.

CVE-2021-3560 allows an unprivileged local hacker to gain root privileges. It’s very simple and quick to exploit, so users must update their installations as quickly as possible. Any system that has polkit version 0.113 (or later) installed is vulnerable. That includes popular distributions such as RHEL 8 and Ubuntu 20.04.

Linux System Service Bug Allows You to Gain Root Access

 

An authentication bypass vulnerability in the polkit auth system service, which is installed by default on many recent Linux distributions, allows unprivileged attackers to gain a root shell. On June 3, 2021, the polkit local privilege escalation flaw (CVE-2021-3560) was officially identified, and a fix was released. Polkit is used by systemd, hence it's included in any Linux distribution that uses systemd. 

Kevin Backhouse, a GitHub security researcher, detailed how he discovered the bug (CVE-2021-3560) in a systemd service called polkit in a blog post on Thursday. The problem, which was first introduced in commit bfa5036 seven years ago and first shipped in polkit version 0.113, took various pathways in different Linux distributions. Despite the fact that many Linux distributions did not ship with the vulnerable polkit version until recently, any Linux machine with polkit 0.113 or later installed is vulnerable to attacks. 

Polkit, formerly known as PolicyKit, is a service that determines whether certain Linux tasks require more privileges than there are currently available. It comes into play when you want to establish a new user account, for example. According to Backhouse, exploiting the issue is shockingly simple, needing only a few commands utilizing common terminal tools such as bash, kill, and dbus-send. 

"The vulnerability is triggered by starting a dbus-send command but killing it while polkit is still in the middle of processing the request," explained Backhouse. Polkit asks for the UID of a connection that no longer exists, therefore killing dbus-send — an interprocess communication command – in the middle of an authentication request creates an error (because the connection was killed). 

"In fact, polkit mishandles the error in a particularly unfortunate way: rather than rejecting the request, it treats the request as though it came from a process with UID 0," explains Backhouse. "In other words, it immediately authorizes the request because it thinks the request has come from a root process."

Because polkit's UID query to the dbus-daemon occurs numerous times throughout different code paths, this doesn't happen all of the time. According to Backhouse, those code pathways usually handle the error correctly, but one is vulnerable, and if the disconnection occurs while that code path is running, privilege escalation occurs. It's all about timing, which varies in unanticipated ways due to the involvement of various processes. Backhouse believes the bug's intermittent nature is why it went unnoticed for seven years.

Linux, MacOS Malware Hidden in Fake Browserify NPM Package

 

Over the course of the weekend, Sonatype's automated malware detection system spotted a serious exceptional malware sample published to the NPM registry. NodeJS engineers working with Linux and Apple macOS operating systems were targeted by a brand-new malicious package recognized on the NPM (Node Package Manager) registry. The malignant package, named "web-browserify" looks like the well-known Browserify NPM component which has been downloaded in excess of 160 million times all through its lifecycle, with over 1.3 million weekly downloads on NPM alone, being utilized by 356,000 GitHub repositories. 

Evidently, the malignant component has been downloaded around 50 times before it was taken out from the NPM within two days of its publishing. The package, made by a pseudonymous creator portraying themselves to be Steve Jobs, consolidates many approved open-source components and executes extensive surveillance actions on a contaminated system. Besides, up to this point, none of the main antivirus engines had the option to identify the ELF malware contained with the component. The way that it utilizes genuine software applications to perform dubious exercises could be one of the reasons. 

Browserify's fame comes from it being an open-source JavaScript instrument that permits developers to write cross-platform, NodeJS-style modules that gather for use in the browser. The distinction between the authentic Browserify and the phony one is that the latter abuses legitimate NPM components to bundle inside a malicious, hard to notice Linux and Mac executable. 

The malignant bundle incorporates a manifest file, package.json, a postinstall.js script, and an ELF executable called "run" existing in a compressed archive, run.tar.xz inside the npm component. When a developer is installing the package, the scripts pull out and start the "run" Linux binary from the archive, which demands elevated or root permissions from the user. The extracted "run" binary is immense, around 120 MB in size, and bundles inside itself hundreds of legitimate NPM components. The malware is made totally from open source components and uses these genuine components to organize its extensive surveillance activities. 

The cross-platform “sudo-prompt” module is one of these components and is used by "run" to provoke the client into permitting the malware root privileges on both macOS and Linux distributions.

Google Issues a Warning about Spectre Attacks using JavaScript

 

It's been over a long time since researchers uncovered a couple of security vulnerabilities, known as Spectre and Meltdown, that further revealed fundamental flaws in how most present-day PC processors handle the information to maximize efficiency. While they influence a cosmic number of computing devices, the so-called speculative execution bugs are generally hard to misuse in practice. However, presently researchers from Google have built up a proof-of-concept that shows the risk Spectre assaults pose to the browser—in hopes of motivating a new generation of defenses. 

Google in 2018 detailed two variations of Spectre, one of which – named variation 1 (CVE-2017-5753) – concerned JavaScript exploitation against browsers. Google released the PoC for engineers of web applications to comprehend why it's critical to send application-level mitigations. At a high level, as detailed in a Google document on W3C, a developer's "data must not unexpectedly enter an attacker's process". 

While the PoC shows the JavaScript Spectre assault against Chrome 88's V8 JavaScript engine on an Intel Core i7-6500U 'Skylake' CPU on Linux, Google notes it can without much of a stretch be changed for different CPUs, browser versions, and operating systems. It was even successful on Apple's M1 Arm CPU with minor alterations. The assault can leak information at a pace of 1kB each second. The chief components of the PoC are a Spectre version 1 "device" or code that triggers attacker-controlled transient execution, and a side-channel or "a way to observe side effects of the transient execution". 

"The web platform relies on the origin as a fundamental security boundary, and browsers do a pretty good job at preventing explicit leakage of data from one origin to another," explained Google's Mike West. "Attacks like Spectre, however, show that we still have work to do to mitigate implicit data leakage. The side-channels exploited through these attacks prove that attackers can read any data which enters a process hosting that attackers' code. These attacks are quite practical today, and pose a real risk to users."

Google has likewise released another prototype Chrome extension called Spectroscope that scans an application to discover assets that may require enabling additional defenses.

A Trio of Vulnerabilities in the Linux Kernel Can Give Attackers Root Privileges

 

Linux kernel distributions appear explicitly susceptible to recently uncovered vulnerabilities. In the iSCSI module, which is used for viewing shared data storages, three unearthed vulnerabilities in the Linux kernel would provide administrative privileges to anybody with a user account. Since 2006, the Linux code has no identification of the trio of defects – the CVE-2021-27363, CVE-2021-27364, and CVE-2021-27365 – until GRIMM researchers found them. 

“If you already had the execution on a box, either because you have a user account on the machine, or you’ve compromised some service that doesn’t have repaired permissions, you can do whatever you want basically,” said Adam Nichols, principal of the Software Security practice at GRIMM. 

Although the vulnerabilities that are in code, are not functional remotely, therefore they are not remote exploits but are still troubling. They take “any existing threat that might be there. It just makes it that much worse,” he explained. Referring to the concept that "many eyes make any bug shallow," Linux code doesn't get many eyes so that it seems perfect. But while the code was first published, the bugs have been there, even in the last fifteen years they haven't really modified. 

GRIMM researchers, of course, are trying to dig in to see how often vulnerabilities occur where possible – with open source, a much more feasible solution. It's very much related to the extent of the Linux kernel that the defections drifted away. "It gotten so big," Nichols said, "there's so much code there." “The real strategy is making sure you’re loading as little code as possible.” 

Nichols said that bugs are present in all Linux distributions, but kernel drivers are not enabled by default. If the vulnerable kernel module can be loaded by a regular user or not, may vary. For example, they could be checked by GRIMM in all Red Hat distros. "Even though it's not loaded by default, you can load it and you can exploit it without any trouble," added Nichols. 

Although the hardware is present, other systems such as Debian and Ubuntu “are in the same boat as Red Hat, where the user, depending on what packages are installed, can coerce it into getting loaded; then it’s there to be exploited,” he said. Errors are reported in 5.11.4, 5.10.21, 5.4.103, 4.19.179, 4.14.224, 4.9.260, and 4.4.260. The bugs are not included in the following updates. Although all the old kernels are end-of-life and will not be patched. 

Nichols suggests that the Kernel must be blacklisted as a temporary measure to neutralize defects. “Any system that doesn’t use that module can just say never load this module under any circumstances, and then you’re kept safe,” he said. But “if you’re actually using iSCSI, then you wouldn’t want to do that.”