Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Heap-buffer-overflow in ucl_maybe_parse_number function of ucl_parser.c:182:11 #275

Closed
HotSpurzzZ opened this issue Oct 19, 2023 · 2 comments

Comments

@HotSpurzzZ
Copy link

When I use tests/fuzzers/ucl_add_string_fuzzer.c for fuzz testing, I found Heap-buffer-overflow in ucl_maybe_parse_number function of ucl_parser.c:882:11
This seems similar toissue263 but has not been fixed in the latest version.

Verification steps

CC = clang
CFLAGS = -O1 -fno-omit-frame-pointer -gline-tables-only -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -fsanitize=address -fsanitize-address-use-after-scope -fsanitize=fuzzer-no-link
LIB_FUZZING_ENGINE="-fsanitize=fuzzer"

cd libucl 
./autogen.sh && ./configure
make

$CC $CFLAGS $LIB_FUZZING_ENGINE tests/fuzzers/ucl_add_string_fuzzer.c \
    -DHAVE_CONFIG_H -I./src -I./include src/.libs/libucl.a -I./ \
    -o $OUT/ucl_add_string_fuzzer
./ucl_add_string_fuzzer $poc

POC file

poc_hof.zip

AddressSanitizer output

INFO: Seed: 686354357
INFO: Loaded 1 modules   (3173 inline 8-bit counters): 3173 [0x602950, 0x6035b5),
INFO: Loaded 1 PC tables (3173 PCs): 3173 [0x5b12d8,0x5bd928),
./ucl_add_string_fuzzer: Running 1 inputs 1 time(s) each.
Running: ../libucl_heap_overflow_ucl_maybe_parse_number
=================================================================
==1214584==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61b000000d41 at pc 0x00000054f029 bp 0x7fffffffd450 sp 0x7fffffffd448
READ of size 1 at 0x61b000000d41 thread T0
    #0 0x54f028 in ucl_maybe_parse_number /home/libucl/src/ucl_parser.c:882:11
    #1 0x5635dc in ucl_lex_number /home/libucl/src/ucl_parser.c:1055:8
    #2 0x55c7aa in ucl_parse_value /home/libucl/src/ucl_parser.c:1928:10
    #3 0x554d62 in ucl_state_machine /home/libucl/src/ucl_parser.c:2538:29
    #4 0x553a7d in ucl_parser_add_chunk_full /home/libucl/src/ucl_parser.c:3026:12
    #5 0x557352 in ucl_parser_add_chunk_priority /home/libucl/src/ucl_parser.c:3061:9
    #6 0x5577af in ucl_parser_add_string_priority /home/libucl/src/ucl_parser.c:3124:9
    #7 0x557804 in ucl_parser_add_string /home/libucl/src/ucl_parser.c:3136:9
    #8 0x54d97e in LLVMFuzzerTestOneInput /home/libucl/tests/fuzzers/ucl_add_string_fuzzer.c:17:2
    #9 0x4586e1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/libucl/ucl_add_string_fuzzer+0x4586e1)
    #10 0x443e52 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/libucl/ucl_add_string_fuzzer+0x443e52)
    #11 0x449906 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/libucl/ucl_add_string_fuzzer+0x449906)
    #12 0x4725c2 in main (/home/libucl/ucl_add_string_fuzzer+0x4725c2)
    #13 0x7ffff7a6a082 in __libc_start_main /build/glibc-iA3wr8/glibc-2.31/csu/../csu/libc-start.c:308:16
    #14 0x41e51d in _start (/home/libucl/ucl_add_string_fuzzer+0x41e51d)

0x61b000000d41 is located 0 bytes to the right of 1473-byte region [0x61b000000780,0x61b000000d41)
allocated by thread T0 here:
    #0 0x51e24d in malloc (/home/libucl/ucl_add_string_fuzzer+0x51e24d)
    #1 0x432907 in operator new(unsigned long) (/home/libucl/ucl_add_string_fuzzer+0x432907)
    #2 0x443e52 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/libucl/ucl_add_string_fuzzer+0x443e52)
    #3 0x449906 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/libucl/ucl_add_string_fuzzer+0x449906)
    #4 0x4725c2 in main (/home/libucl/ucl_add_string_fuzzer+0x4725c2)
    #5 0x7ffff7a6a082 in __libc_start_main /build/glibc-iA3wr8/glibc-2.31/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/libucl/src/ucl_parser.c:882:11 in ucl_maybe_parse_number
Shadow bytes around the buggy address:
  0x0c367fff8150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fff8160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fff8170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fff8180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fff8190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c367fff81a0: 00 00 00 00 00 00 00 00[01]fa fa fa fa fa fa fa
  0x0c367fff81b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c367fff81c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c367fff81d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c367fff81e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c367fff81f0: 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
==1214584==ABORTING

@vstakhov
Copy link
Owner

vstakhov commented Feb 1, 2024

Strange, I cannot reproduce this issue.

vstakhov added a commit that referenced this issue Feb 1, 2024
@vstakhov
Copy link
Owner

vstakhov commented Feb 1, 2024

I think this patch should fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants