CVE-2023-33613: [axtls-general] [Bug Report] heap buffer overflow when parsing private key

• Summary
• Files
• Reviews
• Support
• Mailing Lists
• Tickets ▾
  • Patches
  • Feature Requests
  • Bugs
• News
• Discussion
• Code

Menu ▾ ▴

From: Xm Chen <xichi…@gm…> - 2023-05-11 16:00:09

Hi, we found a bug in the latest version of axtls(v2.1.5) when parsing private key.

Here’s how we trigger the bug and the error log from AddressSanitizer.

``` ./axssl s_server -accept 15001 -pass abcd -key POC10 -cert ./a.pem ================================================================= ==436778==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000000bf at pc 0x5583a5a5a903 bp 0x7fffb8107e00 sp 0x7fffb8107df0 READ of size 1 at 0x6020000000bf thread T0 #0 0x5583a5a5a902 in bi_import ./axtls-code/crypto/bigint.c:631 #1 0x5583a5a61912 in RSA_priv_key_new ./axtls-code/crypto/rsa.c:66 #2 0x5583a5a6d786 in asn1_get_private_key ./axtls-code/ssl/asn1.c:299 #3 0x5583a5a430d4 in add_private_key ./axtls-code/ssl/tls1.c:648 #4 0x5583a5a3d21b in do_obj ./axtls-code/ssl/loader.c:134 #5 0x5583a5a3d0b7 in ssl_obj_load ./axtls-code/ssl/loader.c:92 #6 0x5583a5a3a8a3 in do_server ./axtls-code/samples/c/axssl.c:232 #7 0x5583a5a39dcd in main ./axtls-code/samples/c/axssl.c:90 #8 0x7f51816ce082 in __libc_start_main …/csu/libc-start.c:308 #9 0x5583a5a39b4d in _start (axssl+0x8b4d)

0x6020000000bf is located 13 bytes to the right of 2-byte region [0x6020000000b0,0x6020000000b2) allocated by thread T0 here: #0 0x7f518194c527 in __interceptor_malloc …/…/…/…/src/libsanitizer/asan/asan_malloc_linux.cpp:145 #1 0x5583a5a6cbbd in asn1_get_big_int ./axtls-code/ssl/asn1.c:168 #2 0x5583a5a6d559 in asn1_get_private_key ./axtls-code/ssl/asn1.c:292 #3 0x5583a5a430d4 in add_private_key ./axtls-code/ssl/tls1.c:648 #4 0x5583a5a3d21b in do_obj ./axtls-code/ssl/loader.c:134 #5 0x5583a5a3d0b7 in ssl_obj_load ./axtls-code/ssl/loader.c:92 #6 0x5583a5a3a8a3 in do_server ./axtls-code/samples/c/axssl.c:232 #7 0x5583a5a39dcd in main ./axtls-code/samples/c/axssl.c:90 #8 0x7f51816ce082 in __libc_start_main …/csu/libc-start.c:308

SUMMARY: AddressSanitizer: heap-buffer-overflow ./axtls-code/crypto/bigint.c:631 in bi_import Shadow bytes around the buggy address: 0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 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 00 00 fa fa 02 fa fa fa 02 fa fa fa 02 fa =>0x0c047fff8010: fa fa 05 fa fa fa 02[fa]fa fa 02 fa fa fa 02 fa 0x0c047fff8020: fa fa 00 fa fa fa 04 fa fa fa 00 fa fa fa fd fa 0x0c047fff8030: fa fa 00 00 fa fa 00 04 fa fa fd fa fa fa 00 00 0x0c047fff8040: fa fa fd 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 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 ==436778==ABORTING ```

We triaged the crash, and found that the bug locates at ./ssl/asn1.c. Firstly, when invoking `RSA_priv_key_new`, function `asn1_get_private_key` uses the values from `asn1_get_big_int` as arguments without any check. Secondly, when calling `bi_import` from `RSA_priv_key_new`, the data and its len may not match. Finally, there might be an out-of-bound access in function `bi_import` at line 631 within the loop.

You can use the attached files and the following compile command to reproduce the bug. ``` LDFLAGS="-fsanitize=address" CFLAGS="-g -O0 -fsanitize=address" CXXFLAGS="-g -O0 -fsanitize=address" make ```

Thank you for your work. We are prepared to provide more information and looking forward for your reply!

Xingman Chen

View entire thread