Kakadu: JPX fragmented list vulnerability

### Summary Rec. ITU-T T.801 | ISO/IEC 15444-2 specifies the JPX file format, which can store images encoded using a variety of image codecs. The Fragment List (flst) box is optional feature of JPX that allows image data and metadata to be fragmented within the same file, across multiple files, or across multiple URLs on the internet. This feature, as currently described in the specification, is inherently vulnerable. This feature becomes dangerous when a server accepts JPEG 2000 images from untrusted users and displays processed images back to them. In such cases, an attacker can exfiltrate local and remote files reachable by the server processing the image. In this report, we provide multiple Proof-of-Concepts for exfiltrating local files.  This image contains parts of the contents of /proc/self/exe. We used Kakadu's kdu_expand binary to generate this image. ### Severity High - allows an attacker to exfiltrate local and remote files reachable by a server if the server allows the attacker to upload a specially-crafted the image that is displayed back to the attacker. ### Proof of Concept This proof-of-concept is based on Fragment Table boxes and uses the Kakadu's kdu_expand program, which decodes JPX files containing JPEG 2000 images as specified in Rec. ITU-T T.800 | ISO/IEC 15444-1. Other implementations of the JPX file format using other image codecs might be vulnerable. #### Dimension-Based File-Read The size of the image (height, width and number of colors) is provided by the SIZ Segment Marker. The marker also determines the height and width of the tiles. Its layout is shown below:  The most important fields are: * Xsiz: Width of the decompressed image as a 4-byte field * Ysiz: Height of the decompressed image as a 4-byte field * XTsiz: Width of one tile as a 4-byte field * YTsiz: Height of one tile as a 4-byte field We decided to inject bytes from a local file into the SIZ segment marker, since we assume a setup where an attacker can see the image’s output dimensions. Since neither the width or the height of an image can be zero, and they are 32-bit unsigned integers, we encoded each as (0x00, 0x00, 0x01, <read byte>), thus each would end up being 0x100 + the value of the respective read byte, giving us a range from 0x100 to 0x1FF. <read byte> represents the injected byte. We can inject this byte both into the Xsiz and Ysiz field, where Xsiz contains the first byte and Ysiz the second byte to leak. This allows an attacker to leak 2 bytes of a local file with a single image. Since an attacker can control the offset of the bytes within the local file, they can repeatedly upload the file with increasing offsets to leak the full file contents. #### Dynamic Tile Read To leak more data in a single image, we needed to either find a single segment marker with a large array of data that could be reliably decoded from the output image OR find a segment marker that could be repeated in the image to have some noticeable effect. One tempting target is the tile data itself. What if we created an image with a single large tile, and then used a large number of leaked bytes in the compressed pixel data within this tile. Unfortunately, the compression applied to tiles made this impossible. The tile data is encoded using a variable length encoding technique, and does not permit the 0xFF byte in the stream. Additionally, the compression used in JPEG 2000 is incredibly complex, using wavelet transforms with dynamic coefficients. The length of the tile and meaning of the tile changed based on the data that we leaked, and changed in such a way that almost guaranteed parsing errors. We set out looking for a segment marker that could be

Severity from

GitHub (reviewed advisory)

• github.com/google/security-research/security/advisories/GHSA-g6qc-fhcq-vhf9
• github.com/google/security-research