Open pdreiter opened 1 year ago
You can easily reproduce this with jasper REDTEAM-CVE-2020-27828
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?
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
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.
@pdreiter can you elaborate on the inconsistency in details?
@rshariffdeen - Is not producing output consistent with the expected sanitizer failures not a problem for CrashRepair?
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 inC*FLAG
s. 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
.