#368 Private security report contact request: DjVuLibre stack overflows in metadata/text parsing

[姉歯幸村]

Hello DjVuLibre maintainers,

I found two security-relevant crash issues in DjVuLibre involving crafted DjVu files that trigger uncontrolled recursion and stack exhaustion in metadata/text parsing paths.

I reproduced the issues against the current SourceForge DjVuLibre Git tree:

• commit: 03e6abd7295c74f795ed70a7118294b25351e0f4
• tag/description: release.3.5.30
• build: plain Release build, no sanitizers

The affected paths are:

1. ANTa annotation parsing

2. function: GLParser::parse()

3. source location observed under ASan: libdjvu/DjVuAnno.cpp:562

4. plain Release result: Segmentation fault / rc=139

5. TXTa text layer parsing

6. function: DjVuTXT::Zone::decode()

7. source location observed under ASan: libdjvu/DjVuText.cpp:295
8. plain Release result: Segmentation fault / rc=139

AddressSanitizer also reports stack-overflow for both cases. The demonstrated impact is denial of service / process crash via crafted DjVu files. I am not claiming code execution.

Could you please let me know the preferred private security reporting contact or channel? I can provide the full report, minimized PoCs, SHA256 hashes, build details, plain crash logs, and sanitizer logs privately.

Thank you.

[Leon Bottou]

The stack overflow issue for txt chunks has been fixed with commit https://sourceforge.net/p/djvu/djvulibre-git/ci/aacf21be31119f6d436d2e6a5e995c928b633167/ which ensures proper nesting of the zone types.

The stack overflow issue for ant chunks has been left along because the DjVuAnno.cpp parser is mostly deprecated. The print_meta command in djvused is its main residual use. Modern code uses the miniexp parser instead which is a lot less stack intensive (but can still overflow given enough parentheses). I am not too concerned.

[Leon Bottou]

Todo: maybe remove DjVuAnno from djvused.