Talos Vulnerability Report

SUMMARY

Multiple integer overflow vulnerabilities exist in the LXT2 num_dict_entries functionality of GTKWave 3.3.115. A specially crafted .lxt2 file can lead to arbitrary code execution. A victim would need to open a malicious file to trigger these vulnerabilities.

CONFIRMED VULNERABLE VERSIONS

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

GTKWave 3.3.115

PRODUCT URLS

GTKWave - https://gtkwave.sourceforge.net

CVSSv3 SCORE

7.8 - CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

CWE

CWE-190 - Integer Overflow or Wraparound

DETAILS

GTKWave is a wave viewer, often used to analyze FPGA simulations and logic analyzer captures. It includes a GUI to view and analyze traces, as well as convert across several file formats (.lxt, .lxt2, .vzt, .fst, .ghw, .vcd, .evcd) either by using the UI or its command line tools. GTKWave is available for Linux, Windows and MacOS. Trace files can be shared within teams or organizations, for example to compare results of simulation runs across different design implementations, to analyze protocols captured with logic analyzers or just as a reference when porting design implementations.

GTKWave sets up mime types for its supported extensions. So, for example, it’s enough for a victim to double-click on a wave file received by e-mail to cause the gtkwave program to be executed and load a potentially malicious file.

LXT2 (InterLaced eXtensible Trace Version 2) files are parsed by the functions found in lxt2_read.c. These functions are used in the lxt2vcd file conversion utility, rtlbrowse, lxt2miner, and by the GUI portion of GTKwave, which are thus all affected by the issue described in this report.

To parse LXT2 files, the function lxt2_rd_init is called:

     struct lxt2_rd_trace *lxt2_rd_init(const char *name) {
[1]      struct lxt2_rd_trace *lt = (struct lxt2_rd_trace *)calloc(1, sizeof(struct lxt2_rd_trace));
         lxtint32_t i;

[2]      if (!(lt->handle = fopen(name, "rb"))) {
             lxt2_rd_close(lt);
             lt = NULL;
         } else {
             lxtint16_t id = 0, version = 0;
             ...
[3]          if (!fread(&id, 2, 1, lt->handle)) {
                 id = 0;
             }
             if (!fread(&version, 2, 1, lt->handle)) {
                 id = 0;
             }
             if (!fread(&lt->granule_size, 1, 1, lt->handle)) {
                 id = 0;
             }

At [1] the lt structure is initialized. This is the structure that will contain all the information about the input file.
The input file is opened [2] and 3 fields are read [3] to make sure the input file is a supported LXT2 file.

         ...
[4]      rcf = fread(&lt->numfacbytes, 4, 1, lt->handle);
         lt->numfacbytes = rcf ? lxt2_rd_get_32(&lt->numfacbytes, 0) : 0;
         rcf = fread(&lt->longestname, 4, 1, lt->handle);
         lt->longestname = rcf ? lxt2_rd_get_32(&lt->longestname, 0) : 0;
         rcf = fread(&lt->zfacnamesize, 4, 1, lt->handle);
         lt->zfacnamesize = rcf ? lxt2_rd_get_32(&lt->zfacnamesize, 0) : 0;
         rcf = fread(&lt->zfacname_predec_size, 4, 1, lt->handle);
         lt->zfacname_predec_size = rcf ? lxt2_rd_get_32(&lt->zfacname_predec_size, 0) : 0;
         rcf = fread(&lt->zfacgeometrysize, 4, 1, lt->handle);
         lt->zfacgeometrysize = rcf ? lxt2_rd_get_32(&lt->zfacgeometrysize, 0) : 0;
         rcf = fread(&lt->timescale, 1, 1, lt->handle);
         if (!rcf) lt->timescale = 0; /* no swap necessary */
         ...

Several fields are then read from the file [4]:

• numfacs: the number of facilities (elements in facnames)
• numfacbytes: unused
• longestname: keeps the longest length of all defined facilities’ names
• zfacnamesize: compressed size of facnames
• zfacname_predec_size: decompressed size of facnames
• zfacgeometrysize: compressed size of facgeometry

Then, the facnames and facgeometry structures are extracted. Both structures are compressed with gzip.

Right after these two structures, there’s a sequence of blocks that can be arbitrarily long.

     for (;;) {
         ...
[5]      b = calloc(1, sizeof(struct lxt2_rd_block));

[6]      rcf = fread(&b->uncompressed_siz, 4, 1, lt->handle);
         b->uncompressed_siz = rcf ? lxt2_rd_get_32(&b->uncompressed_siz, 0) : 0;
         rcf = fread(&b->compressed_siz, 4, 1, lt->handle);
         b->compressed_siz = rcf ? lxt2_rd_get_32(&b->compressed_siz, 0) : 0;
         rcf = fread(&b->start, 8, 1, lt->handle);
         b->start = rcf ? lxt2_rd_get_64(&b->start, 0) : 0;
         rcf = fread(&b->end, 8, 1, lt->handle);
         b->end = rcf ? lxt2_rd_get_64(&b->end, 0) : 0;
         ...
         if ((b->uncompressed_siz) && (b->compressed_siz) && (b->end)) {
             /* fprintf(stderr, LXT2_RDLOAD"block [%d] %lld / %lld\n", lt->numblocks, b->start, b->end); */
             fseeko(lt->handle, b->compressed_siz, SEEK_CUR);

             lt->numblocks++;
[7]          if (lt->block_curr) {
                 lt->block_curr->next = b;
                 lt->block_curr = b;
                 lt->end = b->end;
             } else {
                 lt->block_head = lt->block_curr = b;
                 lt->start = b->start;
                 lt->end = b->end;
             }
         } else {
             free(b);
             break;
         }

         pos += b->compressed_siz;
     }

At [5] the block structure is allocated on the heap. At [6] some fields are extracted. Finally, the block is saved inside a linked list [7].

From this code we can see the file structure for a block as follows:

• uncompressed_siz - unsigned big endian 32-bit
• compressed_siz - unsigned big endian 32-bit
• start_time - unsigned big endian 64-bit
• end_time - unsigned big endian 64-bit
• compressed data of size compressed_siz

Upon return from the current lxt2_rd_init function, the blocks are parsed inside lxt2_rd_iter_blocks by walking the linked list created at [7].

 int lxt2_rd_iter_blocks(struct lxt2_rd_trace *lt,
                         void (*value_change_callback)(struct lxt2_rd_trace **lt, lxtint64_t *time, lxtint32_t *facidx, char **value),
                         void *user_callback_data_pointer) {
     struct lxt2_rd_block *b;
     int blk = 0, blkfinal = 0;
     int processed = 0;
     struct lxt2_rd_block *bcutoff = NULL, *bfinal = NULL;
     int striped_kill = 0;
     unsigned int real_uncompressed_siz = 0;
     unsigned char gzid[2];
     lxtint32_t i;

     ...
     b = lt->block_head;
     blk = 0;
     ...
     while (b) {
             ...
             fseeko(lt->handle, b->filepos, SEEK_SET);
             gzid[0] = gzid[1] = 0;
             if (!fread(&gzid, 2, 1, lt->handle)) {
                 gzid[0] = gzid[1] = 0;
             }
             fseeko(lt->handle, b->filepos, SEEK_SET);

[8]          if ((striped_kill = (gzid[0] != 0x1f) || (gzid[1] != 0x8b))) {
                ...
             } else {
                 int rc;

                 b->mem = malloc(b->uncompressed_siz);
[9]              lt->zhandle = gzdopen(dup(fileno(lt->handle)), "rb");
                 rc = gzread(lt->zhandle, b->mem, b->uncompressed_siz);
                 gzclose(lt->zhandle);
                 lt->zhandle = NULL;
[10]             if (((lxtint32_t)rc) != b->uncompressed_siz) {
                     fprintf(stderr, LXT2_RDLOAD "short read on block %d vs " LXT2_RD_LD " (exp), ignoring\n", rc, b->uncompressed_siz);
                     free(b->mem);
                     b->mem = NULL;
                     b->short_read_ignore = 1;
                 } else {
                     lt->block_mem_consumed += b->uncompressed_siz;
                 }
             }

             bfinal = b;
             blkfinal = blk;
         }

         if (b->mem) {
[11]         lxt2_rd_process_block(lt, b);
             ...
         }

         blk++;
         b = b->next;
     }

If the block starts with the gzip magic [8], gzdopen is used to decompress the block [9]. If the decompression is successful [10], lxt2_rd_process_block is called to parse the decompressed block contents [11] (which are pointed to by b->mem).

     int lxt2_rd_process_block(struct lxt2_rd_trace *lt, struct lxt2_rd_block *b) {
         char vld;
         char *pnt;
         lxtint32_t i;
         int granule = 0;
         char sect_typ;
         lxtint32_t strtfac_gran = 0;
         char granvld = 0;

         b->num_map_entries = lxt2_rd_get_32(b->mem, b->uncompressed_siz - 4);
[12]     b->num_dict_entries = lxt2_rd_get_32(b->mem, b->uncompressed_siz - 12);

         ...

         if (b->num_dict_entries) {
[13]         b->string_pointers = malloc(b->num_dict_entries * sizeof(char *));
[14]         b->string_lens = malloc(b->num_dict_entries * sizeof(unsigned int));
             pnt = b->dict_start;
[15]         for (i = 0; i < b->num_dict_entries; i++) {
[16]             b->string_pointers[i] = pnt;
[17]             b->string_lens[i] = strlen(pnt);
                 pnt += (b->string_lens[i] + 1);
                 /* fprintf(stderr, LXT2_RDLOAD"%d '%s'\n", i, b->string_pointers[i]); */
             }

At [12] the b->num_dict_entries field is extracted as a 32-bit big endian.
Then, b->string_pointers [13] and b->string_lens [14] arrays are allocated on the heap, using a size calculated by multiplying b->num_dict_entries by the size of the array elements. In 32-bit mode these multiplications can overflow, leading to calling malloc with a smaller size. For this reason, binaries running in 64-bit mode are not affected by this issue.

At [15], a loop iterates over all b->num_dict_entries and writes into both b->string_pointers and b->string_lens. As the arrays were allocated with a size much smaller than b->num_dict_entries, the writes at [16] and [17] will eventually write out-of-bounds.
Note that b is allocated on the heap, just like the buffers that are being overflown. Moreover, the loop iterates on b->num_dict_entries, which is also stored on the heap. With careful heap manipulation, this allows the out-of-bounds write to exit the loop after corrupting heap data, possibly leading to arbitrary code execution.

CVE-2023-39316 - string_pointers allocation

The size for the string_pointers array allocation [13] may wrap around, leading to an out-of-bounds write at [16].

CVE-2023-39317 - string_lens allocation

The size for the string_lens array allocation [14] may wrap around, leading to an out-of-bounds write at [17].

Crash Information

==834371==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf5f00230 at pc 0x5655f05a bp 0xffffd568 sp 0xffffd55c
WRITE of size 4 at 0xf5f00230 thread T0
    #0 0x5655f059 in lxt2_rd_process_block src/helpers/lxt2_read.c:606
    #1 0x565698bb in lxt2_rd_iter_blocks src/helpers/lxt2_read.c:1608
    #2 0x5656b6a2 in process_lxt src/helpers/lxt2vcd.c:299
    #3 0x5656bfd7 in main src/helpers/lxt2vcd.c:458
    #4 0xf7659294 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #5 0xf7659357 in __libc_start_main_impl ../csu/libc-start.c:381
    #6 0x565573a6 in _start (lxt2vcd+0x23a6)

0xf5f00231 is located 0 bytes to the right of 1-byte region [0xf5f00230,0xf5f00231)
allocated by thread T0 here:
    #0 0xf7a55ffb in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x5655eeea in lxt2_rd_process_block src/helpers/lxt2_read.c:601
    #2 0x565698bb in lxt2_rd_iter_blocks src/helpers/lxt2_read.c:1608
    #3 0x5656b6a2 in process_lxt src/helpers/lxt2vcd.c:299
    #4 0x5656bfd7 in main src/helpers/lxt2vcd.c:458
    #5 0xf7659294 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

SUMMARY: AddressSanitizer: heap-buffer-overflow src/helpers/lxt2_read.c:606 in lxt2_rd_process_block
Shadow bytes around the buggy address:
  0x3ebdfff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3ebe0000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3ebe0010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3ebe0020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3ebe0030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x3ebe0040: fa fa 01 fa fa fa[01]fa fa fa fd fa fa fa 00 05
  0x3ebe0050: fa fa fd fd fa fa fd fa fa fa fd fd fa fa fd fa
  0x3ebe0060: fa fa fd fd fa fa fd fa fa fa fd fd fa fa fd fd
  0x3ebe0070: fa fa fd fd fa fa fd fa fa fa fd fd fa fa fd fa
  0x3ebe0080: fa fa fd fd fa fa fd fd fa fa 00 04 fa fa 00 05
  0x3ebe0090: fa fa 00 04 fa fa 00 04 fa fa 00 04 fa fa 00 fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb

VENDOR RESPONSE

Fixed in version 3.3.118, available from https://sourceforge.net/projects/gtkwave/files/gtkwave-3.3.118/

TIMELINE

2023-08-11 - Vendor Disclosure
2023-12-31 - Vendor Patch Release
2024-01-08 - Public Release