New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Openjpeg-2.1.2 DoS vulnerability due to some logic error #863
Comments
|
Dupe to #857? |
|
@attritionorg Among the variables in above check, image->comps[i].dx, image->comps[i].dy, image->comps[i].prec and ncomp can be directly controlled from the input image file (as analyzed in the report of #862 and this report). Some of similar crash points have been described in the attachment report. |
|
I have tested both files in question: PoC1.jp2 and PoC2.j2k. And Could you apply this patch to your library and make some more tests? winfried |
|
@szukw000 Because I saw the following code in function "color_sycc_to_rgb" (called by function "main"): The vulnerability is triggered only when output to ".pnm \ .ppm", i.e. call into function "imagetopnm", why not directly patch it in this function like: I am not sure whether it is needed to make sure comps[0].prec = comps[1].prec = comps[2].prec = comps[3].prec, also comps[i].sgnd. Besides, I find other converter functions either are not necessary to add this limitation or already have it:
I wonder if the added limitation in your patch will cause "imagetopgx", "imagetoraw", "imagetorawl" work incorrectly. I am not familiar with the specification. |
|
@szukw000 @attritionorg For example, sycc422_to_rgb in src/bin/common.c : 130 (called by “color_sycc_to_rgb” by “main”): Why not patch it in function "opj_j2k_decode" or "opj_j2k_deocde_tiles" as analyzed in the report. However, I am not familiar with the specification and not sure whether it is feasible. The attachment is a poc file which can again trigger the above-noted bug, and the related analysis can be found in "Further analysis" section of this report. |
PoC1bin/opj_decompress -i /tmp/PoC1.jp2 -o PoC1.jp2.ppm opj_decompress.c:1497: RGB(0x7fe398bc4010,0x7fe3989c2010,0x7fe3987c0010) Here is the reason (unpatched opj_decompress.c): bin/opj_decompress -i /tmp/PoC1.jp2 -o PoC1.jp2.png I supposed you yourself did create the file PoC1: FILE(/tmp/PoC1.jp2) read_ihdr [2]marker(0xff51) And here the result with the patch: bin/opj_decompress -i /tmp/PoC1.jp2 -o PoC1.jp2.ppm [INFO] Stream reached its end ! PoC2bin/opj_decompress -i /tmp/PoC2.j2k -o PoC2.j2k.ppm [INFO] Start to read j2k main header (0). NAME(/tmp/PoC2.j2k) [2]marker(0xff51) And here is the result with the patch: bin/opj_decompress -i /tmp/PoC2.j2k -o PoC2.j2k.ppm [INFO] Start to read j2k main header (0). The pointer to 'color_sycc_to_rgb()' is OK. And can be consided: the patch should winfried |
PoC1The patch can absolutely solve the crash of #862. I know the reason is comps[3].dy != comps[0].dy and comps[3].dx != comps[0].dx. What my question is whether it is correct to require all images should satisfy First, from the code in function "color_sycc_to_rgb", I guess the following situation is allowed and I did create such sample. Second, "imagetopgx" and "imagetoraw" do not require the image must satisfy last-noted precondition. So I wonder whether the limitation in the patch is too strong. Also all converter functions except "imagetopnm" either have already had the similar check or don't need this. I think it may be better to patch "imagetopnm". PoC2I think the patch should be added before line 1374 (maybe a little different): Otherwise, the crash will happen again when the execution steps into function "sycc422_to_rgb" through "color_sycc_to_rgb", which can be verified by "color_related_sample". The following is the ASAN exception: |
|
Hello @szukw000 , may i know the status? |
|
I have now changed the patch. The test in 'opj_decompress.c' can be shorter in case I am unsure about the test in RAW. winfried |
|
@szukw000 @attritionorg For test in RAW, I think the check code in the patch is not needed and can be deleted. The reason is: On the other hand, I find the allocation length of each comps[compno].data is also "comps[compno].w * comps[compno].h", which can be found with reverse debugging (e.g. rr). The allocation code for each comps[compno].data is shown in the following: From above, I find that for each comps[compno].data the total access length and the allocation length are the same (i.e. comps[compno].w * comps[compno].h). So there is no need to add check in RAW. |
|
the conclusion is not true. RAW must follow the same limitations as e.g. PNG. In the following example I have limited the number of componentes to be WRITTEN to 3. opj_compress -h STEP 1bin/opj_decompress -i /tmp/PoC1.jp2 -o PoC1.jp2.raw [INFO] Stream reached its end ! STEP 2mv PoC1.jp2.raw PoC1.jp2-16416x32x5x3.raw STEP 3bin/opj_compress -i PoC1.jp2-16416x32x5x3.raw -o PoC1.jp2-16416x32x5x3.raw.jp2 -F 16416,32,3,5,u@1x1:1x1:1x1 [INFO] tile number 1 / 1 This means that for an RGB image all dx/dy/prec/sgnd pairs must be the And if the source image has 4 channels the fourth channel must have the Otherwise the creation to RAW fails. PoC1.jp2 succeeds with 3 channels but must fail with 4 channels. winfried |
|
@szukw000 @attritionorg |
Eh, I do not understand. But: somebody should send a final patch to the developers. winfried |
|
Can you send the final patch to the developers? I find you are one of the contributors. |
|
@szukw000 |
|
I believe this has now been addressed by #895 |
Overview
I have found a vulnerability in openjpeg-2.1.2 (an open-source JPEG 2000 codec written in C
language) using AFL (http://lcamtuf.coredump.cx/afl/). The vulnerability exists in code responsible
for decoding the input image. The vulnerability is caused by an improper assumption: if the
decoding process successfully finishes, buffer of each component corresponding to each channel
(Red, Green, Blue, Alpha) has already been allocated and filled with data; however, the assumption
is not always valid, i.e. these buffers has not been allocated when the decoding process successfully
returns. The vulnerability can be viewed as a logic error. The vulnerability can trigger many different
crash points by crafting the PoC image file and cause Denial-of-Service due to Null Pointer
Reference. It’s probably that the vulnerability can cause crashes of some other type and cause
more critical impact by crafting the PoC.
Analysis and PoC
The detail analysis and poc file can be found in the attachment.
report2_+poc.zip
Author
name: twelveand0 @ VARAS of IIE
email: l.bingchang.bc@gmail.com
org: IIE (http://iie.ac.cn)
Notes
I have reported this to RedHat Security Team and they suggested me to report it here before assigning cve id.
The text was updated successfully, but these errors were encountered: