RGR denial-of-service attack vulnerability.

[jhuff-ccsw]

I tried reporting this through other channels, but got no traction, so I'm submitting it as a public issue now.

NOTE: This can only occur if you configure ION with the following flags, which enables processing RGR extension blocks:

./configure --enable-unibo-cgr CPPFLAGS='-DRGREB=1'

I don't know if anyone actually uses unibo-cgr, but it's probably best to sort out any major bugs in it or somehow mark the --enable-unibo-cgr flag as experimental.

Anyway, here's the description of the bug:

In the function bpv7/library/ext/rgr/rgr_utils.c::decode_rgr , ION will blindly call MTAKE with value of the CBOR int encoded length field WITHOUT checking the actual length of the CBOR string that was sent.

This allows an attacker to make the target allocate a large amount of memory by sending a small bundle with a malformed RGR extension block.

What's worse, the function rgr_acquire calls decode_rgr and returns if there is a decoding error without releasing the memory that was allocated. This means that if you can cause the decoding to fail after the buffer is allocated, you've just caused a massive memory leak with very little effort. decode_rgr will return an error if the CBOR text string fails to decode, which happens after the buffer is allocated. So by encoding a malformed CBOR text string or by encoding a CBOR integer in its place, the decoding will fill and the program will leak memory.

This also causes the CLA to crash, as the rgr_acquire function returns a negative value rather than returning 0. Extension block functions should return 0 if the extension block is malformed. This allows ION to quietly discard the bundle. However, the RGR functions seem to return negative values which should only be used to indicate a much larger issue like OOM.

If you would like to try this yourself, here's a hex string of a cbor encoded bundle with a malformed RGR block:

9f8807184000820282020882028203018202820301821b000000b5595d907d001a05265c0085060210004582028203008518c1030100458400010000850704010041008518c405010049821a02625a0019053985010101004c68656c6c6f20776f726c640aff

The block type specific data is CBOR with the following data:

[40000000, 1337]

This causes an allocation of 40MB, and then having the integer 1337 instead of a byte string causes the leak/crash.

I'm guessing there are other such bugs in the rgr and cgrr functions, as this code makes liberal use of MTAKE and MRELEASE.

Solutions

The memory leak can be fixed by simply ensuring to call MRELEASE when a processing error occurs. The crash can be fixed by ensuring that the rgr extension block functions return 0 when malformed CBOR is encountered instead of returning a negative value.

It might be advisable to mark the --enable-unibo-cgr as an experimental feature, as this part of the codebase is likely vulnerable to similar bugs.

[iondev33]

Thanks @jhuff-ccsw!!

Sorry we are under staffed here and not quite keeping up with all the good issues you have reported.

It's a good idea to mark unibo-cgr option as experimental since I don't get any feedback that it is widely used. I will also try to get the fix you recommended into ION.