Integer Overflow in num_images

[NigelX]

Hello openjpeg2 team,
I found an integer overflow vulnerability in the command line options.

-ImgDir

If there are many files in the imgdir directory The number of files read by opj_compress will overflow.

openjpeg2(tested with revision * master 0bda718).

run commd

./opj_compress -ImgDir testcase/ -OutFor outcase/t.jp2 

asan info

Folder opened successfully
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==1852564==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000001183310 (pc 0x7ffff764cefa bp 0x0000000fffff sp 0x7fffffff3988 T1852564)
==1852564==The signal is caused by a WRITE memory access.
    #0 0x7ffff764cefa  /build/glibc-eX1tMB/glibc-2.31/string/../sysdeps/x86_64/multiarch/strcpy-avx2.S:630
    #1 0x42d9a5 in load_images /home/test/Downloads/openjpeg/src/bin/jp2/opj_compress.c:508:9
    #2 0x429366 in main /home/test/Downloads/openjpeg/src/bin/jp2/opj_compress.c:1924:13
    #3 0x7ffff74e70b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    #4 0x408c7d in _start (/home/test/Downloads/openjpeg/fast_build64/bin/opj_compress+0x408c7d)

UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV /build/glibc-eX1tMB/glibc-2.31/string/../sysdeps/x86_64/multiarch/strcpy-avx2.S:630 
==1852564==ABORTING

When num_images is equal to 1048576, multiplying with OPJ_PATH_LEN will produce an overflow result of 0

poc.zip

---

HX from Topsec alpha Security Team

[carnil]

This appears to have been assigned CVE-2021-29338

[Abhishek-sin]

Is there any manual fix we can use/apply here till we get an patch update ??

[stevebeattie]

It looks like the pull request #1346 is intended to cover this issue as well; I believe Alpine Linux has already released an update for the issue with an earlier iteration of the proposed pull request.

[tony--]

#1346 was replaced with f0629cb. Does that mean CVE-2021-29338 is fixed in master, @rouault?

[rouault]

#1346 was replaced with f0629cb. Does that mean CVE-2021-29338 is fixed in master, @rouault?

I don't think so. I don't see f0629cb changing the code path pointed above

[baparham]

now that we might be back after some time away, I'll ping again but over in this issue. @rouault or @kaniini are there any plans or PRs in the works to fix this cve since it was not included in f0629cb and #1346 wasn't merged fully?

[rouault]

are there any plans or PRs in the works to fix this cve since it was not included in f0629cb and #1346 wasn't merged fully?

if you believe there's something left to fix, please issue a pull request to fix it. That's the effective way to make changes happen

[baparham]

I understand and agree, but I am not really good at c these days. Since you and @kaniini have previously made changes in this area, I figured either of you two would be the quickest at making such a PR, and ensuring that it actually is correct. A PR from me would basically be trying to copy and paste code from @kaniini where it fits the latest master code, which seems inappropriate and bug prone.

Either way, it sounds like the answer is no, so I'll try and cobble something together (just what you want to hear when fixing a CVE :-) ) and see if the CI and reviewers like it.

[baparham]

Is it possible to confirm that this issue doesn't affect the lib code? I'm not really sure how they are intertwined, but for example, pdfium in the chromium project seems to just makes use of the code under lib (reference) which to me seems to indicate that it is not vulnerable to this CVE.

thoughts?

[rouault]

Is it possible to confirm that this issue doesn't affect the lib code?

if the code source changes are in src/bin/ only, it means that it affects only the utilities