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

Buffer Overflow vulnerability in fmt_entry function in progs/dump_entry.c:1116 in ncurses 6.1 allows remote attackers to cause a denial of service via crafted command.

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

CVE-2020-19188: fuzzpoc/infotocap_poc4.md at master · zjuchenyuan/fuzzpoc

Buffer Overflow vulnerability in postprocess_terminfo function in tinfo/parse_entry.c:997 in ncurses 6.1 allows remote attackers to cause a denial of service via crafted command.

CVE-2020-19189: fuzzpoc/infotocap_poc5.md at master · zjuchenyuan/fuzzpoc

Buffer Overflow vulnerability in _nc_find_entry in tinfo/comp_hash.c:70 in ncurses 6.1 allows remote attackers to cause a denial of service via crafted command.

CVE-2020-19190: fuzzpoc/infotocap_poc6.md at master · zjuchenyuan/fuzzpoc

An issue was discovered in function _libssh2_packet_add in libssh2 1.10.0 allows attackers to access out of bounds memory.

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2020-22218: fix use-of-uninitialized-value by ltx2018 · Pull Request #476 · libssh2/libssh2

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.

read_ints in plistlib.py in Python through 3.9.1 is vulnerable to a potential DoS attack via CPU and RAM exhaustion when processing malformed Apple Property List files in binary format.

Created on **2020-10-21 00:25** by **wessen**, last changed **2022-04-11 14:59** by **admin**. This issue is now **closed**.

Pull Requests

URL

Status

Linked

Edit

PR 22882

merged

serhiy.storchaka, 2020-10-22 09:27

PR 23115

merged

miss-islington, 2020-11-02 21:02

PR 23116

merged

serhiy.storchaka, 2020-11-02 21:17

PR 23117

merged

serhiy.storchaka, 2020-11-02 21:26

PR 23118

merged

serhiy.storchaka, 2020-11-02 21:40

Messages (12)

msg379175 - (view)

Author: Robert Wessen (wessen)

Date: 2020-10-21 00:25

In versions of Python from 3.4-3.10, the Python core plistlib library supports Apple's binary plist format. When given malformed input, the implementation can be forced to create an argument to struct.unpack() which consumes all available CPU and memory until a MemError is thrown as it builds the 'format' argument to unpack().

This can be seen with the following malformed example binary plist input:

\`\`\`
$ xxd binary\_plist\_dos.bplist
00000000: 6270 6c69 7374 3030 d101 0255 614c 6973  bplist00...UaLis
00000010: 74a5 0304 0506 0000 00df 4251 4351 44a3  t.........BQCQD.
00000020: 0809 0a10 0110 0210 0308 0b11 1719 1b1d  ................
00000030: 0000 0101 0000 0000 0000 000b 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0029            ...........)

\`\`\`
The error is reached in the following lines of plistlib.py:
(https://github.com/python/cpython/blob/e9959c71185d0850c84e3aba0301fbc238f194a9/Lib/plistlib.py#L485)

\`\`\`
    def \_read\_ints(self, n, size):
        data = self.\_fp.read(size \* n)
        if size in \_BINARY\_FORMAT:
            return struct.unpack('>' + \_BINARY\_FORMAT\[size\] \* n, data)
\`\`\`
When the malicious example above is opened by plistlib, it results in 'n' being controlled by the input and it can be forced to be very large. Plistlib attempts to build a string which is as long as 'n', consuming excessive resources.

Apple's built in utilities for handling plist files detects this same file as malformed and will not process it.

msg379238 - (view)

Author: Ronald Oussoren (ronaldoussoren) \* 

Date: 2020-10-21 19:44

Thanks for the report. I can reproduce the issue.

msg379243 - (view)

Author: Ronald Oussoren (ronaldoussoren) \* 

Date: 2020-10-21 20:12

One Apple implementation of binary plist parsing is here: https://opensource.apple.com/source/CF/CF-550/CFBinaryPList.c.

That seems to work from a buffer (or mmap) of the entire file, making consistency checks somewhat easier, and I don't think they have a hardcoded limit on the number of items in the plist (but: it's getting late and might have missed that).

An easy fix for this issue is to limit the amount of values read by \_read\_ints, but that immediately begs the question what that limit should be. It is clear that 1B items in the array is too much (in this case 1B object refs for dictionary keys). 

I don't know what a sane limit would be. The largest plist file on my system is 10MB. Limiting \*n\* to 20M would be easily enough to parse that file, and doesn't consume too much memory (about 160MB for the read buffer at most). 

Another thing the current code doesn't do is check that the "ref" argument to \_read\_object is in range. That's less problematic because the code will raise an exception regardless (IndexErrox, instead of the nicer InvalidFileException).

msg379255 - (view)

Author: Serhiy Storchaka (serhiy.storchaka) \* 

Date: 2020-10-21 21:36

There are two issues here.

The simple one is building a large format string for struct.unpack(). It has simple solution: use f'>{n}{\_BINARY\_FORMAT\[size\]}'.

The hard issue is that read(n) allocates n bytes in memory even if there are not so many bytes in the file. It affects not only plistlib and should be fixed in the file implementation itself. There is an open issue for this.

msg379283 - (view)

Author: Ronald Oussoren (ronaldoussoren) \* 

Date: 2020-10-22 09:40

Serhiy, thanks. Just the change in the format string would fix this particular example.

I see you're working on a PR with better validation. The current state of the draft looks good to me, but I haven't checked yet if there are other potential problems that can be added to the list of invalid binary plists.

msg379285 - (view)

Author: Serhiy Storchaka (serhiy.storchaka) \* 

Date: 2020-10-22 09:47

PR 22882 fixes problem in \_read\_ints(), adds validation for string size, and adds many tests for mailformed binary Plists.

There may be problems with recursive collections. I'll try to solve them too.

msg379286 - (view)

Author: Serhiy Storchaka (serhiy.storchaka) \* 

Date: 2020-10-22 09:59

No, with recursive collections all is good.

Then I'll just add a NEWS entry and maybe few more tests.

msg380250 - (view)

Author: Serhiy Storchaka (serhiy.storchaka) \* 

Date: 2020-11-02 21:02

New changeset 34637a0ce21e7261b952fbd9d006474cc29b681f by Serhiy Storchaka in branch 'master':
bpo-42103: Improve validation of Plist files. (GH-22882)
https://github.com/python/cpython/commit/34637a0ce21e7261b952fbd9d006474cc29b681f

msg380252 - (view)

Author: miss-islington (miss-islington)

Date: 2020-11-02 21:34

New changeset e277cb76989958fdbc092bf0b2cb55c43e86610a by Miss Skeleton (bot) in branch '3.9':
bpo-42103: Improve validation of Plist files. (GH-22882)
https://github.com/python/cpython/commit/e277cb76989958fdbc092bf0b2cb55c43e86610a

msg380265 - (view)

Author: Serhiy Storchaka (serhiy.storchaka) \* 

Date: 2020-11-03 07:32

New changeset 547d2bcc55e348043b2f338027c1acd9549ada76 by Serhiy Storchaka in branch '3.8':
\[3.8\] bpo-42103: Improve validation of Plist files. (GH-22882) (GH-23116)
https://github.com/python/cpython/commit/547d2bcc55e348043b2f338027c1acd9549ada76

msg380703 - (view)

Author: Ned Deily (ned.deily) \* 

Date: 2020-11-10 19:54

New changeset 225e3659556616ad70186e7efc02baeebfeb5ec4 by Serhiy Storchaka in branch '3.7':
\[3.7\] bpo-42103: Improve validation of Plist files. (GH-22882) (#23117)
https://github.com/python/cpython/commit/225e3659556616ad70186e7efc02baeebfeb5ec4

msg380704 - (view)

Author: Ned Deily (ned.deily) \* 

Date: 2020-11-10 19:57

New changeset a63234c49b2fbfb6f0aca32525e525ce3d43b2b4 by Serhiy Storchaka in branch '3.6':
\[3.6\] bpo-42103: Improve validation of Plist files. (GH-22882) (GH-23118)
https://github.com/python/cpython/commit/a63234c49b2fbfb6f0aca32525e525ce3d43b2b4

History

Date

User

Action

Args

2022-04-11 14:59:37

admin

set

nosy: + pablogsal  
github: 86269  

2020-11-10 20:17:26

serhiy.storchaka

set

status: open -> closed  
resolution: fixed  
stage: patch review -> resolved

2020-11-10 19:57:41

ned.deily

set

messages: + msg380704

2020-11-10 19:54:25

ned.deily

set

messages: + msg380703

2020-11-03 07:33:40

serhiy.storchaka

set

priority: normal -> release blocker  
nosy: + lukasz.langa  

2020-11-03 07:32:31

serhiy.storchaka

set

messages: + msg380265

2020-11-02 21:40:36

serhiy.storchaka

set

pull\_requests: + pull\_request22035

2020-11-02 21:34:51

miss-islington

set

messages: + msg380252

2020-11-02 21:26:43

serhiy.storchaka

set

pull\_requests: + pull\_request22034

2020-11-02 21:17:38

serhiy.storchaka

set

pull\_requests: + pull\_request22033

2020-11-02 21:02:11

miss-islington

set

nosy: + miss-islington  
pull\_requests: + pull\_request22032  

2020-11-02 21:02:11

serhiy.storchaka

set

messages: + msg380250

2020-10-22 09:59:32

serhiy.storchaka

set

messages: + msg379286

2020-10-22 09:47:54

serhiy.storchaka

set

messages: + msg379285

2020-10-22 09:40:45

ronaldoussoren

set

messages: + msg379283

2020-10-22 09:27:10

serhiy.storchaka

set

keywords: + patch  
stage: patch review  
pull\_requests: + pull\_request21822

2020-10-21 21:36:41

serhiy.storchaka

set

messages: + msg379255

2020-10-21 20:12:55

ronaldoussoren

set

messages: + msg379243

2020-10-21 19:44:21

ronaldoussoren

set

messages: + msg379238

2020-10-21 01:06:46

ned.deily

set

keywords: + security\_issue  
nosy: + ronaldoussoren, ned.deily, serhiy.storchaka

components: + Library (Lib), - Interpreter Core  
title: DoS (MemError via CPU and RAM exhaustion) when processing malformed Apple Property List files in binary format -> \[security\] DoS (MemError via CPU and RAM exhaustion) when processing malformed Apple Property List files in binary format

2020-10-21 00:25:11

wessen

create

CVE-2022-48564: Issue 42103: [security] DoS (MemError via CPU and RAM exhaustion) when processing malformed Apple Property List files in binary format

A use-after-free exists in Python through 3.9 via heappushpop in heapq.

Issue39421

Created on **2020-01-22 15:11** by **dk0n9**, last changed **2022-04-11 14:59** by **admin**. This issue is now **closed**.

Pull Requests

URL

Status

Linked

Edit

PR 18118

merged

pablogsal, 2020-01-22 15:54

PR 18144

closed

miss-islington, 2020-01-23 14:07

PR 18145

merged

miss-islington, 2020-01-23 14:07

PR 18146

merged

miss-islington, 2020-01-23 14:07

PR 18149

merged

miss-islington, 2020-01-23 15:05

Messages (10)

msg360474 - (view)

Author: Dk0n9 (dk0n9)

Date: 2020-01-22 15:13

The variable \`heap\` in heappushpop does not add a reference count

\`\`\`c
    cmp = PyObject\_RichCompareBool(PyList\_GET\_ITEM(heap, 0), item, Py\_LT);
    if (cmp < 0)
        return NULL;
    if (cmp == 0) {
        Py\_INCREF(item);
        return item;
    }
\`\`\`

POC：
\`\`\`python
import heapq

class h(int):
    def \_\_lt\_\_(self, o):
        list1.clear()
        return NotImplemented

list1 = \[\]

heapq.heappush(list1, h(0))
heapq.heappushpop(list1, 1)
\`\`\`


Crash detail with asan:

==62141==ERROR: AddressSanitizer: heap-use-after-free on address 0x6060000fd778 at pc 0x00000049cdce bp 0x7ffe9690f650 sp 0x7ffe9690f640
READ of size 8 at 0x6060000fd778 thread T0
    #0 0x49cdcd in long\_richcompare Objects/longobject.c:3047
    #1 0x4f9495 in do\_richcompare Objects/object.c:802
    #2 0x4f9495 in PyObject\_RichCompare Objects/object.c:846
    #3 0x4f9495 in PyObject\_RichCompareBool Objects/object.c:868
    #4 0x7ff74c523594 in \_heapq\_heappushpop\_impl /home/\*\*\*\*\*\*/Python-3.9.0a2/Modules/\_heapqmodule.c:267
    #5 0x7ff74c523594 in \_heapq\_heappushpop /home/\*\*\*\*\*\*/Python-3.9.0a2/Modules/clinic/\_heapqmodule.c.h:109
    #6 0x854c30 in cfunction\_vectorcall\_FASTCALL Objects/methodobject.c:366
    #7 0x443885 in \_PyObject\_VectorcallTstate Include/cpython/abstract.h:111
    #8 0x443885 in \_PyObject\_Vectorcall Include/cpython/abstract.h:120
    #9 0x443885 in call\_function Python/ceval.c:4850
    #10 0x443885 in \_PyEval\_EvalFrameDefault Python/ceval.c:3306
    #11 0x5e1d76 in \_PyEval\_EvalFrame Include/internal/pycore\_ceval.h:43
    #12 0x5e1d76 in \_PyEval\_EvalCode Python/ceval.c:4142
    #13 0x5e2207 in \_PyEval\_EvalCodeWithName Python/ceval.c:4174
    #14 0x5e2207 in PyEval\_EvalCodeEx Python/ceval.c:4190
    #15 0x5e2207 in PyEval\_EvalCode Python/ceval.c:717
    #16 0x6862fc in run\_eval\_code\_obj Python/pythonrun.c:1125
    #17 0x6862fc in run\_mod Python/pythonrun.c:1147
    #18 0x6862fc in PyRun\_FileExFlags Python/pythonrun.c:1063
    #19 0x6867b2 in PyRun\_SimpleFileExFlags Python/pythonrun.c:428
    #20 0x446495 in pymain\_run\_file Modules/main.c:369
    #21 0x446495 in pymain\_run\_python Modules/main.c:553
    #22 0x446495 in Py\_RunMain Modules/main.c:632
    #23 0x446f86 in pymain\_main Modules/main.c:662
    #24 0x446f86 in Py\_BytesMain Modules/main.c:686
    #25 0x7ff74f34882f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)
    #26 0x444478 in \_start (/home/\*\*\*/Python-3.9.0a2/python+0x444478)

0x6060000fd778 is located 24 bytes inside of 56-byte region \[0x6060000fd760,0x6060000fd798)
freed by thread T0 here:
    #0 0x7ff7500b72ca in \_\_interceptor\_free (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x982ca)
    #1 0x52a5d9 in subtype\_dealloc Objects/typeobject.c:1291
    #2 0x4222a6 in \_Py\_DECREF Include/object.h:478
    #3 0x4222a6 in frame\_dealloc Objects/frameobject.c:636
    #4 0x422088 in \_Py\_DECREF Include/object.h:478
    #5 0x422088 in function\_code\_fastcall Objects/call.c:335
    #6 0x53aac6 in \_PyObject\_VectorcallTstate Include/cpython/abstract.h:111
    #7 0x53aac6 in vectorcall\_unbound Objects/typeobject.c:1459
    #8 0x53aac6 in slot\_tp\_richcompare Objects/typeobject.c:6703
    #9 0x4f921d in do\_richcompare Objects/object.c:796
    #10 0x4f921d in PyObject\_RichCompare Objects/object.c:846
    #11 0x4f921d in PyObject\_RichCompareBool Objects/object.c:868
    #12 0x7ff74c523594 in \_heapq\_heappushpop\_impl /home/\*\*\*\*\*\*/Python-3.9.0a2/Modules/\_heapqmodule.c:267
    #13 0x7ff74c523594 in \_heapq\_heappushpop /home/\*\*\*\*\*\*/Python-3.9.0a2/Modules/clinic/\_heapqmodule.c.h:109
    #14 0x854c30 in cfunction\_vectorcall\_FASTCALL Objects/methodobject.c:366
    #15 0x443885 in \_PyObject\_VectorcallTstate Include/cpython/abstract.h:111
    #16 0x443885 in \_PyObject\_Vectorcall Include/cpython/abstract.h:120
    #17 0x443885 in call\_function Python/ceval.c:4850
    #18 0x443885 in \_PyEval\_EvalFrameDefault Python/ceval.c:3306
    #19 0x5e1d76 in \_PyEval\_EvalFrame Include/internal/pycore\_ceval.h:43
    #20 0x5e1d76 in \_PyEval\_EvalCode Python/ceval.c:4142
    #21 0x5e2207 in \_PyEval\_EvalCodeWithName Python/ceval.c:4174
    #22 0x5e2207 in PyEval\_EvalCodeEx Python/ceval.c:4190
    #23 0x5e2207 in PyEval\_EvalCode Python/ceval.c:717
    #24 0x6862fc in run\_eval\_code\_obj Python/pythonrun.c:1125
    #25 0x6862fc in run\_mod Python/pythonrun.c:1147
    #26 0x6862fc in PyRun\_FileExFlags Python/pythonrun.c:1063
    #27 0x6867b2 in PyRun\_SimpleFileExFlags Python/pythonrun.c:428
    #28 0x446495 in pymain\_run\_file Modules/main.c:369
    #29 0x446495 in pymain\_run\_python Modules/main.c:553
    #30 0x446495 in Py\_RunMain Modules/main.c:632
    #31 0x446f86 in pymain\_main Modules/main.c:662
    #32 0x446f86 in Py\_BytesMain Modules/main.c:686
    #33 0x7ff74f34882f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)

previously allocated by thread T0 here:
    #0 0x7ff7500b7602 in malloc (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x6dbfd5 in \_PyObject\_GC\_Alloc Modules/gcmodule.c:2146
    #2 0x6dbfd5 in \_PyObject\_GC\_Malloc Modules/gcmodule.c:2173
    #3 0x527d20 in PyType\_GenericAlloc Objects/typeobject.c:1014
    #4 0x4b890b in long\_subtype\_new Objects/longobject.c:5132
    #5 0x4b890b in long\_new\_impl Objects/longobject.c:5075
    #6 0x4b890b in long\_new Objects/clinic/longobject.c.h:36
    #7 0x52f606 in type\_call Objects/typeobject.c:973
    #8 0x462b46 in \_PyObject\_MakeTpCall Objects/call.c:189
    #9 0x436b70 in \_PyObject\_VectorcallTstate Include/cpython/abstract.h:109
    #10 0x436b70 in \_PyObject\_Vectorcall Include/cpython/abstract.h:120
    #11 0x436b70 in call\_function Python/ceval.c:4850
    #12 0x436b70 in \_PyEval\_EvalFrameDefault Python/ceval.c:3337
    #13 0x5e1d76 in \_PyEval\_EvalFrame Include/internal/pycore\_ceval.h:43
    #14 0x5e1d76 in \_PyEval\_EvalCode Python/ceval.c:4142
    #15 0x5e2207 in \_PyEval\_EvalCodeWithName Python/ceval.c:4174
    #16 0x5e2207 in PyEval\_EvalCodeEx Python/ceval.c:4190
    #17 0x5e2207 in PyEval\_EvalCode Python/ceval.c:717
    #18 0x6862fc in run\_eval\_code\_obj Python/pythonrun.c:1125
    #19 0x6862fc in run\_mod Python/pythonrun.c:1147
    #20 0x6862fc in PyRun\_FileExFlags Python/pythonrun.c:1063
    #21 0x6867b2 in PyRun\_SimpleFileExFlags Python/pythonrun.c:428
    #22 0x446495 in pymain\_run\_file Modules/main.c:369
    #23 0x446495 in pymain\_run\_python Modules/main.c:553
    #24 0x446495 in Py\_RunMain Modules/main.c:632
    #25 0x446f86 in pymain\_main Modules/main.c:662
    #26 0x446f86 in Py\_BytesMain Modules/main.c:686
    #27 0x7ff74f34882f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)

SUMMARY: AddressSanitizer: heap-use-after-free Objects/longobject.c:3047 long\_richcompare
Shadow bytes around the buggy address:
  0x0c0c80017a90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c80017aa0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c80017ab0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c80017ac0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c80017ad0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c0c80017ae0: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd\[fd\]
  0x0c0c80017af0: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fa
  0x0c0c80017b00: fa fa fa fa fd fd fd fd fd fd fd fd fa fa fa fa
  0x0c0c80017b10: 00 00 00 00 00 00 00 00 fa fa fa fa fd fd fd fd
  0x0c0c80017b20: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fa
  0x0c0c80017b30: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
==62141==ABORTING

msg360475 - (view)

Author: Dong-hee Na (corona10) \* 

Date: 2020-01-22 15:31

Reproducible.

It looks similar to bpo-38588.
We will apply the same solution as we did at bpo-38588?
or do we plan to apply the solution which is suggested on msg359023?

msg360477 - (view)

Author: Pablo Galindo Salgado (pablogsal) \* 

Date: 2020-01-22 15:46

To be honest, given how many ways this bug happens I think its time to consider msg359023.

msg360478 - (view)

Author: Dong-hee Na (corona10) \* 

Date: 2020-01-22 15:49

\> To be honest, given how many ways this bug happens I think its time to consider msg359023.

+1 to me also

msg360479 - (view)

Author: Pablo Galindo Salgado (pablogsal) \* 

Date: 2020-01-22 15:55

AS this discussion will take a while and likely will have deeper consequences, in the meantime I created PR18118 to specifically fix this.

msg360484 - (view)

Author: Dong-hee Na (corona10) \* 

Date: 2020-01-22 16:13

@pablogsal

I agree with hotfix is needed and also for discussion.
I left a comment for PR 18118. Please take a look :)

msg360557 - (view)

Author: Pablo Galindo Salgado (pablogsal) \* 

Date: 2020-01-23 14:07

New changeset 79f89e6e5a659846d1068e8b1bd8e491ccdef861 by Pablo Galindo in branch 'master':
bpo-39421: Fix posible crash in heapq with custom comparison operators (GH-18118)
https://github.com/python/cpython/commit/79f89e6e5a659846d1068e8b1bd8e491ccdef861

msg360558 - (view)

Author: miss-islington (miss-islington)

Date: 2020-01-23 14:25

New changeset 958064f8d2b84062b0582bbae911df8ccfc11fd6 by Miss Islington (bot) in branch '3.7':
bpo-39421: Fix posible crash in heapq with custom comparison operators (GH-18118)
https://github.com/python/cpython/commit/958064f8d2b84062b0582bbae911df8ccfc11fd6

msg360561 - (view)

Author: Ned Deily (ned.deily) \* 

Date: 2020-01-23 14:49

New changeset c563f409ea30bcb0623d785428c9257917371b76 by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-39421: Fix posible crash in heapq with custom comparison operators (GH-18118) (GH-18146)
https://github.com/python/cpython/commit/c563f409ea30bcb0623d785428c9257917371b76

msg360564 - (view)

Author: miss-islington (miss-islington)

Date: 2020-01-23 15:22

New changeset 993811ffe75c2573f97fb3fd1414b34609b8c8db by Miss Islington (bot) in branch '3.8':
bpo-39421: Fix posible crash in heapq with custom comparison operators (GH-18118)
https://github.com/python/cpython/commit/993811ffe75c2573f97fb3fd1414b34609b8c8db

History

Date

User

Action

Args

2022-04-11 14:59:25

admin

set

github: 83602

2020-01-23 15:23:27

pablogsal

set

status: open -> closed  
resolution: fixed  
stage: patch review -> resolved

2020-01-23 15:22:29

miss-islington

set

messages: + msg360564

2020-01-23 15:05:37

miss-islington

set

pull\_requests: + pull\_request17535

2020-01-23 14:49:23

ned.deily

set

nosy: + ned.deily  
messages: + msg360561  

2020-01-23 14:25:34

miss-islington

set

nosy: + miss-islington  
messages: + msg360558  

2020-01-23 14:07:43

miss-islington

set

pull\_requests: + pull\_request17532

2020-01-23 14:07:37

miss-islington

set

pull\_requests: + pull\_request17531

2020-01-23 14:07:29

miss-islington

set

stage: needs patch -> patch review  
pull\_requests: + pull\_request17530

2020-01-23 14:07:16

pablogsal

set

messages: + msg360557

2020-01-23 13:54:44

alex

set

keywords: + security\_issue  
nosy: + alex  

2020-01-22 16:13:21

corona10

set

messages: + msg360484

2020-01-22 15:55:25

pablogsal

set

messages: + msg360479  
stage: patch review -> needs patch

2020-01-22 15:54:31

pablogsal

set

keywords: + patch  
stage: needs patch -> patch review  
pull\_requests: + pull\_request17505

2020-01-22 15:49:45

corona10

set

messages: + msg360478

2020-01-22 15:46:55

pablogsal

set

messages: + msg360477

2020-01-22 15:32:01

corona10

set

nosy: + vstinner  

2020-01-22 15:31:53

corona10

set

stage: needs patch  
versions: - Python 3.6

2020-01-22 15:31:24

corona10

set

nosy: + pablogsal, corona10, methane  
messages: + msg360475  

2020-01-22 15:13:43

dk0n9

set

messages: + msg360474

2020-01-22 15:11:46

dk0n9

create

CVE-2022-48560: Issue 39421: Use-after-free in heappushpop() of heapq module

In Perl 5.34.0, function S_find_uninit_var in sv.c has a stack-based crash that can lead to remote code execution or local privilege escalation.

CVE-2022-48522: perl5/sv.c at 79a7b254d85a10b65126ad99bf10e70480569d68 · Perl/perl5

An issue was discovered in Poppler 22.07.0. There is a reachable abort which leads to denial of service because the main function in pdfunite.cc lacks a stream check before saving an embedded file.

When testing #706 (closed), we found the bug is not completely patched in pdfunite. To reproduce the bug, run pdfunite t.pdf poc 2.pdf.

    (gdb) bt
    #0  0x00007ffff72467bb in raise () from /lib/x86_64-linux-gnu/libc.so.6
    #1  0x00007ffff7231535 in abort () from /lib/x86_64-linux-gnu/libc.so.6
    #2  0x000000000040d7a1 in Object::getDict (this=<optimized out>)
        at /home/users/chluo/poppler/poppler/Object.h:435
    #3  main (argc=<optimized out>, argv=<optimized out>)
        at /home/users/chluo/poppler/utils/pdfunite.cc:200

uni.zip

Edited Jul 28, 2022 by

Tag

#git