Out-of-Bound Read in parseAarePdu /src/libiec61850/src/mms/iso_acse/acse.c:215:17

[gnbon]

Summary

An Out-of-Bound Read vulnerability was discovered in the parseAarePdu function of the acse.c file in the libiec61850 library through fuzzing. This vulnerability is triggered when parsing the 0xbe tag.

Details

The vulnerability occurs in the parseAarePdu function when processing the 0xbe tag. When bufPos index used to read from the input buffer is not properly validated, leading to an out-of-bounds read.

Let's consider when the execution reaches the following code:

libiec61850/src/mms/iso_acse/acse.c

Lines 184 to 188 in 790e3e6

	while (bufPos < maxBufPos) {
	uint8_t tag = buffer[bufPos++];
	int len;
	bufPos = BerDecoder_decodeLength(buffer, &len, bufPos, maxBufPos);

If the end of the file contains bytes like be 00, the tag variable will be set to 0xbe, and bufPos will point to the end of the file + 1. Due to the lack of proper boundary checks after this point, an out-of-bound read vulnerability can occur.
For example, when processing the 0xbe tag:

libiec61850/src/mms/iso_acse/acse.c

Lines 214 to 215 in 790e3e6

	case 0xbe: /* user information */
	if (buffer[bufPos] != 0x28) {

Impact:

An attacker can use this vulnerability to leak data by sending deliberately crafted input data to trigger abnormal behavior in the program. This can potentially lead to information disclosure or other unintended consequences.

Recommendation:

To mitigate this vulnerability, it is crucial to perform thorough boundary checks regardless of the size of the input data. The code should be modified to ensure that bufPos never exceeds the valid range of the buffer. Additionally, proper input validation and error handling should be implemented to gracefully handle cases where the input data size is unexpected or malformed.

PoC

A proof-of-concept exploit has been provided in the attached file. This PoC demonstrates how the vulnerability can be triggered by sending specially crafted input data to the affected functions.
acse-crash-be.zip

Address Sanitizer

==60912==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x50d0000000c3 at pc 0x55989ba2470d bp 0x7ffe4fa0d270 sp 0x7ffe4fa0d268
READ of size 1 at 0x50d0000000c3 thread T0
    #0 0x55989ba2470c in parseAarePdu /src/libiec61850/src/mms/iso_acse/acse.c:215:17
    #1 0x55989ba2470c in AcseConnection_parseMessage /src/libiec61850/src/mms/iso_acse/acse.c:457:22
    #2 0x55989ba22364 in LLVMFuzzerTestOneInput /src/libiec61850/build/../fuzz/fuzz_acse_parse.c:10:5
    #3 0x55989ba22209 in ExecuteFilesOnyByOne /src/aflplusplus/utils/aflpp_driver/aflpp_driver.c:255:7
    #4 0x55989ba22005 in LLVMFuzzerRunDriver /src/aflplusplus/utils/aflpp_driver/aflpp_driver.c
    #5 0x55989ba21bbd in main /src/aflplusplus/utils/aflpp_driver/aflpp_driver.c:311:10
    #6 0x7fef531b0d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #7 0x7fef531b0e3f in __libc_start_main csu/../csu/libc-start.c:392:3
    #8 0x55989b9475cd in _start (/home/user/oss-fuzz/build/out/libiec61850/fuzz_acse_parse+0x6d5cd)

0x50d0000000c3 is located 0 bytes after 131-byte region [0x50d000000040,0x50d0000000c3)
allocated by thread T0 here:
    #0 0x55989b9e2b88 in calloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:77:3
    #1 0x55989ba2dcb9 in Memory_calloc /src/libiec61850/hal/memory/lib_memory.c:44:20
    #2 0x55989ba224c2 in ByteBuffer_create /src/libiec61850/src/common/byte_buffer.c:34:28
    #3 0x55989ba22347 in LLVMFuzzerTestOneInput /src/libiec61850/build/../fuzz/fuzz_acse_parse.c:8:30
    #4 0x55989ba22209 in ExecuteFilesOnyByOne /src/aflplusplus/utils/aflpp_driver/aflpp_driver.c:255:7

SUMMARY: AddressSanitizer: heap-buffer-overflow /src/libiec61850/src/mms/iso_acse/acse.c:215:17 in parseAarePdu
Shadow bytes around the buggy address:
  0x50cffffffe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x50cffffffe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x50cfffffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x50cfffffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x50d000000000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
=>0x50d000000080: 00 00 00 00 00 00 00 00[03]fa fa fa fa fa fa fa
  0x50d000000100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x50d000000180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x50d000000200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x50d000000280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x50d000000300: 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
==60912==ABORTING

CVE Assignment Request:

I kindly request the assignment of a Common Vulnerabilities and Exposures (CVE) identifier for the Out-of-Bound Read vulnerability

[gnbon]

In fix d0f52a2, there is still an issue similar to the one mentioned in #512 .
poc-oobr-61.zip