https://github.com/gpac/gpac/issues/2493

@gpac/gpac Can I get a CVE for this report?

Yes but first could you please review the severity? We still need to explore the issue but 7.8 seems really high with a proof about the risks.

I have reviewed the severity of this issue. But the quantification in detail is too complicated. I calculated the score by refering to other cve reports.

Again there is no issue for us to emit a CVE. It's just that seeing a heap overflow with a score of 7.8 only hurts our open-source project. If no one is able to prove this give access to external data, let's stay conservative until it is proven. Cc @admin. Thanks.

I have reviewed the severity again and agree to evaluate the risk level as Medium (4.4).

I reconsider the risk of the issue. Since heap overflow allows us to write the size and data sections of the next chunk, users could control the chunk allocation in certain cases, thus making them can Write-Anything-Anywhere and control the execution process of the program. So I do think it might be a high severity.

I don't know if you'd agree with me:

• attack vector: local
• attack complexity: low
• privilege required: none
• user interaction: none <= CHANGED
• scope: unchanged
• confidentiality: none
• integrity: low
• availability: none or low <= CHANGED: MP4Box is a command-line stateless tool. It is not a server. So it wouldn't affect a service availability (unless trying to make a DDoS on a server, in which case it depends on the server implementation, not on MP4Box which is always fully functional).

Which parts deserves to be challenged?

I am genuinely trying to understand how people compute these scores. We've had high scores on memory double free() for example. We were unable to justify to Debian's maintainers how the score was computed.

Thanks

Thanks for your sharing. I agree with most of your calculations. But I am wondering if confidentiality could be quantified as low? Out-of-bounds reads and writes caused by heap overflow could lead to information leakage in certain cases.

The CVEs related to MP4Box that I reffered to while doing the calculations, such as CVE 2023 0866, CVE 2023 0819 and CVE 2023 0760, are all related to heap-buffer-overflow. Their vulnerability ratings are all High(7.8 or 7.3) and their impact descriptions are "This vulnerability is capable of crashing software, using unexpected value, or possible code execution". I am wondering if these reports can serve as a reference for calculating scores.

Again I'd like to thank for the work that's being done here.

The CVEs you mention (with a high rating) are the ones causing us troubles with Debian. When they are high level vulnerabilities, Debian asks us to make new releases or we are kicked out. GPAC got kicked out from some older Debian versions because some people run fuzzers, discovered crashes, but the wrong severity was applied. We are trying to fix this.

am wondering if confidentiality could be quantified as low? Out-of-bounds reads and writes caused by heap overflow could lead to information leakage in certain cases.

That's exactly what we are trying to figure out. If which cases can information leak? This is inside an executable where you feed the data in.

During my debugging process, I found that when function id3dmx_flush() in filters/reframe_mp3.c called function gf_realloc() for the third time, both the prev_size and size of the next chunk next to the chunk pointed to by the _buf pointer were destroyed.

Whether it is possible to control the size of the next heap block by arranging appropriate input data to achieve Write Anything Anywhere thus causing code execution remains to be further study.

As you said, it is currently not easy to achieve information leakage - unless the execution flow of the program is fully controlled to achieve RCE.

I have modified the report now.

Debuggin info: <img src="https://gitee.com/FUNctionMain/mypoc/raw/master/debugging.png" alt="debugging_info" style="zoom: 67%;" />

Debuggin info: Debuggin info

During my debugging process, I found that when function id3dmx_flush() in filters/reframe_mp3.c called function gf_realloc() for the third time, both the prev_size and size of the next chunk next to the chunk pointed to by the _buf pointer had already been destroyed.

Whether it is possible to control the prev_size, size, fd and bk of the next chunk by arranging appropriate input data to achieve Write Anything Anywhere thus causing code execution remains to be further study.

As you said, it is currently not easy to achieve information leakage - unless the execution flow of the program is fully controlled to achieve RCE.

I have modified the report now.

Debuggin info: debugging_info

( I have commented again because of some mistakes in the last comment. )

May I ask you to retry on the lastest git? It should have been fixed hours ago, but I am not sure to understand if your last message was part of the initial report, or is an extension of it.

Sorry for taking you so much time here. That's also needed on our side to be better on next reports.

The above content is part of the initial report. I retried in the latest Git and found that this issue has been fixed.