DjVuLibre 3.5.29 版本修复了 CVE-2025-53367 漏洞，该漏洞存在于 MMRDecoder::scanruns 方法中的越界写入问题。该漏洞可能被利用，当用户尝试打开恶意制作的 DjVu 文件时，在 Linux 桌面上执行代码。文章详细介绍了漏洞细节、PoC 演示以及修复时间线，强调了及时更新 DjVuLibre 的重要性。

🚨DjVuLibre 的 MMRDecoder::scanruns 方法存在一个越界写入漏洞，该漏洞允许攻击者在用户打开恶意 DjVu 文件时执行代码。

💻该漏洞可能被利用，通过构造一个恶意的 DjVu 文件，触发越界写入，从而导致代码执行。PoC 演示在 Ubuntu 25.04 系统上成功运行，即使启用了标准安全防护。

🛠️该漏洞的具体细节在于 scanruns 方法中，没有检查指针 xr 是否保持在已分配缓冲区的边界内，这可能导致堆损坏。漏洞报告者在 Evince 文档阅读器研究中发现了该漏洞。

⏱️该漏洞于 2025 年 7 月 1 日报告给作者，修复程序在 2025 年 7 月 2 日提交，DjVuLibre 3.5.29 版本于 2025 年 7 月 3 日发布，体现了快速响应和修复的重要性。

DjVuLibre version 3.5.29 was released today. It fixes CVE-2025-53367 (GHSL-2025-055), an out-of-bounds (OOB) write in the MMRDecoder::scanruns method. The vulnerability could be exploited to gain code execution on a Linux Desktop system when the user tries to open a crafted document.

DjVu is a document file format that can be used for similar purposes to PDF. It is supported by Evince and Papers, the default document viewers on many Linux distributions. In fact, even when a DjVu file is given a filename with a .pdf extension, Evince/Papers will automatically detect that it is a DjVu document and run DjVuLibre to decode it.

Antonio found this vulnerability while researching the Evince document reader. He found the bug with fuzzing.

Kev has developed a proof of concept exploit for the vulnerability, as demoed in this video.

The POC works on a fully up-to-date Ubuntu 25.04 (x86_64) with all the standard security protections enabled. To explain what’s happening in the video:

Kev clicks on a malicious DjVu document in his ~/Downloads directory.The file is named poc.pdf, but it’s actually in DjVu format.The default document viewer (/usr/bin/papers) loads the document, detects that it’s in DjVu format, and uses DjVuLibre to decode it.The file exploits the OOB write vulnerability and triggers a call to system("google-chrome https://www.youtube.com/…").Rick Astley appears.

Although the POC is able to bypass ASLR, it’s somewhat unreliable: it’ll work 10 times in a row and then suddenly stop working for several minutes. But this is only a first version, and we believe it’s possible to create an exploit that’s significantly more reliable.

You may be wondering: why Astley, and not a calculator? That’s because /usr/bin/papers runs under an AppArmor profile. The profile prohibits you from starting an arbitrary process but makes an exception for google-chrome. So it was easier to play a YouTube video than pop a calc. But the AppArmor profile is not particularly restrictive. For example, it lets you write arbitrary files to the user’s home directory, except for the really obvious one like ~/.bashrc. So it wouldn’t prevent a determined attacker from gaining code execution.

Vulnerability Details

The MMRDecoder::scanruns method is affected by an OOB-write vulnerability, because it doesn’t check that the xr pointer stays within the bounds of the allocated buffer.

During the decoding process, run-length encoded data is written into two buffers: lineruns and prevruns:

//libdjvu/MMRDecoder.hclass DJVUAPI MMRDecoder : public GPEnabled{...public:  unsigned short *lineruns;...  unsigned short *prevruns;...}

The variables named pr and xr point to the current locations in those buffers. 

scanruns does not check that those pointers remain within the bounds of the allocated buffers.

//libdjvu/MMRDecoder.cppconst unsigned short *MMRDecoder::scanruns(const unsigned short **endptr){...  // Swap run buffers  unsigned short *pr = lineruns;  unsigned short *xr = prevruns;  prevruns = pr;  lineruns = xr;...  for(a0=0,rle=0,b1=*pr++;a0 < width;)    {     ...            *xr = rle; xr++; rle = 0;     ...            *xr = rle; xr++; rle = 0; ...          *xr = inc+rle-a0;          xr++;}

This can lead to writes beyond the allocated memory, resulting in a heap corruption condition. An out-of-bounds read with pr is also possible for the same reason.

We will publish the source code of our proof of concept exploit in a couple of weeks’ time in the GitHub Security Lab repository.

Acknowledgements

We would like to thank Léon Bottou and Bill Riemers for responding incredibly quickly and releasing a fix less than two days after we first contacted them!

Timeline

2025-07-01: Reported via email to the authors: Léon Bottou, Bill Riemers, Yann LeCun.2025-07-01: Responses received from Bill Riemers and Léon Bottou.2025-07-02: Fix commit added by Léon Bottou: https://sourceforge.net/p/djvu/djvulibre-git/ci/33f645196593d70bd5e37f55b63886c31c82c3da/2025-07-03: DjVuLibre version 3.5.29 released: https://sourceforge.net/p/djvu/www-git/ci/9748b43794440aff40bae066132aa5c22e7fd6a3/ 

The post CVE-2025-53367: An exploitable out-of-bounds write in DjVuLibre appeared first on The GitHub Blog.