CrashRepair build/compilation does not support standard static sanitizer libraries when they are required to express exploit failure

[pdreiter]

GNUTOOLS supports -static-lib*san to enable static linking of sanitizer libraries. Particularly, these static versions of the sanitizer libraries are required when -fsanitize=<SAN> -static is provided in C*FLAGs.
This same support is missing from the /CrashRepair/compiler/crepair-cc build infrastructure, which results in a build failure, specifically a linking failure as the required sanitizer library functions are missing from build.
This prevents the expression of exploit failures when sanitizers are necessary.

CrashRepair should at a minimum support -static-libubsan and -static-libasan.

[pdreiter]

You can easily reproduce this with jasper REDTEAM-CVE-2020-27828

[rshariffdeen]

Hi @pdreiter
I had a look at the scenario jasper REDTEAM-CVE-2020-27828

The configuration file bug.json has the binary path incorrect, it should be src/src/appl/jasper there is a l missing
The cmake command is missing the flag -DJAS_ENABLE_SHARED=OFF

In order to run with klee the binary needs to be built as a statically linked binary.

In addition, I checked the exploit command built with the UBSan it didn't crash or have any errors, not sure if the exploit or exploit command is correct?

[pdreiter]

Yes, original butrs-red-team-evaluation docker environment for this scenario generates both ubsan failures as well as asan failures:

interpolating test command: __BINARY__  --input /workspace/exploit.pgx --output ./out --output-format jpc -O numrlvls=40
interpolated test command: /workspace/source/build/src/appl/jasper  --input /workspace/exploit.pgx --output ./out --output-format jpc -O numrlvls=40
executing test via command:  /workspace/source/build/src/appl/jasper  --input /workspace/exploit.pgx --output ./out --output-format jpc -O numrlvls=40
/workspace/source/src/libjasper/jpc/jpc_enc.c:628:3: runtime error: index 33 out of bounds for type 'uint_fast16_t [33]'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /workspace/source/src/libjasper/jpc/jpc_enc.c:628:3 in 
/workspace/source/src/libjasper/jpc/jpc_enc.c:629:3: runtime error: index 33 out of bounds for type 'uint_fast16_t [33]'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /workspace/source/src/libjasper/jpc/jpc_enc.c:629:3 in 
=================================================================
==71==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x617000000350 at pc 0x7f3f97d78c2a bp 0x7ffd37874f10 sp 0x7ffd37874f08
WRITE of size 8 at 0x617000000350 thread T0
    #0 0x7f3f97d78c29 in cp_create /workspace/source/src/libjasper/jpc/jpc_enc.c:629:32
    #1 0x7f3f97d6f348 in jpc_encode /workspace/source/src/libjasper/jpc/jpc_enc.c:287:13
    #2 0x7f3f97cb0034 in jas_image_encode /workspace/source/src/libjasper/base/jas_image.c:462:33
    #3 0x4fa3f5 in main /workspace/source/src/appl/jasper.c:276:6
    #4 0x7f3f969ed83f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)
    #5 0x41c198 in _start (/workspace/source/build/src/appl/jasper+0x41c198)

0x617000000350 is located 0 bytes to the right of 720-byte region [0x617000000080,0x617000000350)
allocated by thread T0 here:
    #0 0x4b3952 in malloc /tmp/llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
    #1 0x7f3f97ccae2e in jas_malloc /workspace/source/src/libjasper/base/jas_malloc.c:238:11
    #2 0x7f3f97d6faea in cp_create /workspace/source/src/libjasper/jpc/jpc_enc.c:373:13
    #3 0x7f3f97d6f348 in jpc_encode /workspace/source/src/libjasper/jpc/jpc_enc.c:287:13
    #4 0x7f3f97cb0034 in jas_image_encode /workspace/source/src/libjasper/base/jas_image.c:462:33
    #5 0x4fa3f5 in main /workspace/source/src/appl/jasper.c:276:6
    #6 0x7f3f969ed83f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)

SUMMARY: AddressSanitizer: heap-buffer-overflow /workspace/source/src/libjasper/jpc/jpc_enc.c:629:32 in cp_create
Shadow bytes around the buggy address:
  0x0c2e7fff8010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2e7fff8020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2e7fff8030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2e7fff8040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2e7fff8050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c2e7fff8060: 00 00 00 00 00 00 00 00 00 00[fa]fa fa fa fa fa
  0x0c2e7fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2e7fff8080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2e7fff8090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2e7fff80a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2e7fff80b0: 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
==71==ABORTING

[pdreiter]

readelf --symbols src/appl/jasper indicates that asan and ubsan symbols are statically linked in binary image, but does not explain the inconsistent behavior seen in crashrepair vs standard GNUTOOLS build.

[rshariffdeen]

@pdreiter can you elaborate on the inconsistency in details?

[pdreiter]

@rshariffdeen - Is not producing output consistent with the expected sanitizer failures not a problem for CrashRepair?