#2539 Public ACE 0day

[M P]

Hello
This may have been reported already but I have come across an ACE vulnerability which has recently been uploaded online which appears to be legitimate from the replies
Links: https://archive.ph/E5tbn
https://archive.ph/iKm4P

[Igor Pavlov]

This report on Twitter is fake.
And I don't understand why this Twitter user did this.

There is no such ACE vulnerability in 7-Zip / LZMA.

[Deez n]

https://pastebin.com/gtnwfrim

[Igor Pavlov]

The common conclusion is that this fake exploit code from Twitter was generated by LLM (AI).

The comment in the "fake" code contains the statement:

This exploit targets a vulnerability in the LZMA decoder of the 7-Zip software. It uses a crafted .7z archive with a malformed LZMA stream to trigger a buffer overflow condition in the RC_NORM function."

But there is no RC_NORM function in LZMA decoder.
Instead, 7-Zip contains RC_NORM macro in LZMA encoder and PPMD decoder. Thus, the LZMA decoding code does not call RC_NORM. And the statement about RC_NORM in the exploit comment is not true.

[Deez n]

The claim that the exploit comment is false is technically correct but misleading. While RC_Norm is a macro, not a function used in the LZMA encoder and PPMD decodern. However it is not present in LzmaDec.c. However, this does not invalidate the possibility of vulnerabilities in the the decoder because issues like pointer arithmetic and buffer handling could still be exploited. The comment does inaccurately references RC_NORM, but the broader claim about malformed LZMA streams causing vulnerabilities remains very plausible to me. How do you deny the rest of their claims? Can you provide source code to back it up?

[Igor Pavlov]

Are you related to the original user @NSA_Emploee39 X user?

Are you suggesting that I discuss this "fake" exploit with LLM?
It seems pointless to me.

[Deez n]

No, I'm not even claiming the 'exploit' is real or fake or a troll or whatever. I'm asking you to verify the impossibility of an exploit using the same methodology.

[Deez n]

Can you confirm that the LZMA decoder has strict enough bounds checking for all pointer manipulations/dictionary buffer writes/range coder operations to prevent potential overflows or underflows caused by malicious crafted LZMA streams? Does the decoder validate all LZMA stream properties like lc and lp and guarantee that bufLimit and dictionary size constraints are enforced at every decoding step? Otherwise I just see it as an valid exploit, but poorly written.

[Igor Pavlov]

Did you use LLM to create the text and questions for this LZMA related problem?
How long (exact number of days or years) have you been working on the details of the LZMA code?
How long (exact number of days or years) have you known about NSA_Emploee39 X user?