Skip to content
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

Is CVE-2020-14153 present in libjpeg-turbo? #445

Closed
AdrianBunk opened this issue Jul 27, 2020 · 2 comments
Closed

Is CVE-2020-14153 present in libjpeg-turbo? #445

AdrianBunk opened this issue Jul 27, 2020 · 2 comments
Assignees

Comments

@AdrianBunk
Copy link
Contributor

https://nvd.nist.gov/vuln/detail/CVE-2020-14153
https://security-tracker.debian.org/tracker/CVE-2020-14153

My best guess is that this is fixed in the following change in jpeg 9d:

       /* Precalculate which table to use for each block */
       entropy->dc_cur_tbls[blkn] = entropy->dc_derived_tbls[compptr->dc_tbl_no];
-      entropy->ac_cur_tbls[blkn] = entropy->ac_derived_tbls[compptr->ac_tbl_no];
+      entropy->ac_cur_tbls[blkn] =     /* AC needs no table when not present */
+       cinfo->lim_Se ? entropy->ac_derived_tbls[compptr->ac_tbl_no] : NULL;

Is this any vulnerability that is or was present in libjpeg-turbo?

@dcommander
Copy link
Member

Unclear. I cannot find any information on how to reproduce the bug. I can tell you that the lim_Se field is only present when libjpeg-turbo is compiled with libjpeg v8+ API/ABI support, which is not the default, so the bug may only be present in libjpeg-turbo when built with libjpeg v8+ API/ABI support.

@dcommander
Copy link
Member

Analysis

The array access in question occurs in start_pass_huff_decoder(), which is called after a start-of-scan (SOS) marker is encountered in a Huffman-coded JPEG image. The array in question is a static 4-deep array of pointers, allocated in jinit_huff_decoder() (which is called within the body of jinit_start_decompress() or jpeg_read_coefficients() if a Huffman-coded JPEG is being decompressed) as part of the private (opaque from the calling application's point of view) huff_entropy_decoder struct. The array elements are initially NULL. The array index in question is a field in the jpeg_component_info struct, an exposed array of which is part of the main jpeg_decompress_struct instance. The array of jpeg_component_info structs is allocated whenever a start-of-frame marker is read from the JPEG image being decompressed. The value of the ac_tbl_no field for a particular component is initially undefined but will get set when a start-of-scan marker is read from the JPEG image, which is guaranteed to occur prior to start_pass_huff_decoder() being called. If the value of ac_tbl_no for a particular component is > 4, then the bounds check in jpeg_make_d_derived_tbl() will throw an error prior to ac_tbl_no being used as an array index (which would occur later in start_pass_huff_decoder().) In libjpeg-turbo, jpeg_make_d_derived_tbl() is always called for the AC table, meaning that that bounds check always occurs. In libjpeg v8+, however, jpeg_make_d_derived_tbl() is only called for the AC table if cinfo->lim_Se is non-zero. It's unclear to me exactly why cinfo->lim_Se would be 0 in libjpeg, but it appears to be a by-product of the SmartScale feature, which libjpeg-turbo has never implemented.

Thus, as near as I can determine, the circumstances under which this issue could occur are present only in libjpeg v8-v9c (inclusive) and not in libjpeg-turbo. Those circumstances are:

  1. The presence of the cinfo->lim_Se field, which is only the case in libjpeg-turbo if it is compiled with libjpeg v8 API/ABI emulation

    and

  2. cinfo->lim_Se == 0, which can never occur during the natural course of decompressing a JPEG image in libjpeg-turbo, due to the lack of support for SmartScale

    and

  3. The invocation of jpeg_make_d_derived_tbl() for the AC table being conditioned on cinfo->lim_Se != 0, which is not the case in libjpeg-turbo even if the cinfo->lim_Se field exists.

Conclusion

This issue appears to have been introduced solely in libjpeg. However, it's incredible that the Security Powers That Be(TM) would assign a CVE to it without providing any information regarding how to reproduce it. It appears that they are merely citing the Gentoo bug report as evidence, but that bug report just accepted the vulnerability as a given, which seems like a circular argument to me. It is unclear to me how an end user could reproduce this issue in libjpeg, so it is unclear to me why it is even a real (as opposed to hypothetical) vulnerability. Without that knowledge, I can only base my conclusion on a review of the code. That code review strongly suggests that the issue in question cannot be encountered in libjpeg-turbo, but that conclusion would be stronger if it could be demonstrated that a specific input image triggers the alleged security vulnerability in libjpeg v8-v9c but not in libjpeg-turbo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants