[BUG] Multiple Intra-Object Overflows in LISP-CP Plugin API Handlers

[neosys007]

I am reporting two critical memory safety vulnerabilities (intra-object overflows) discovered in the LISP-CP plugin. These vulnerabilities occur when the LISP control
plane generates API reply messages containing HMAC keys.

1. Root Cause Analysis
   The vulnerabilities stem from an inconsistent handling of the hmac_key data type defined in lisp_types.api.
   Data Structure (lisp_types.api):
   1 typedef hmac_key {
   2 vl_api_hmac_key_id_t id;
   3 u8 key[64]; // Fixed-size array of 64 bytes
   4 };

In the implementation of LISP and ONE API handlers, the HMAC key is stored as a VPP dynamic vector (u8 *key). When the driver prepares a reply message (rmp), it uses
vec_len() to determine the copy length without validating it against the fixed destination size of 64 bytes.

2. Vulnerable Locations
   Location Fixed: ip6_fib_dump #1: ONE API (src/plugins/lisp/lisp-cp/one_api.c:874)
   In the function handling EID table details:

1 // rmp->key.key is 64 bytes. mapit->key is a dynamic vector.
2 // No check: if (vec_len(mapit->key) > 64)
3 memcpy (rmp->key.key, mapit->key, vec_len (mapit->key));

Location #2: LISP API (src/plugins/lisp/lisp-cp/lisp_api.c:660)
The same pattern exists in the legacy LISP API handler:
1 // Potential overflow of rmp->key.key if vector length > 64.
2 memcpy (rmp->key.key, mapit->key, vec_len (mapit->key));

3. Impact & Exploitation
   An attacker or a misconfigured control plane entity could set an HMAC key longer than 64 bytes (VPP vectors can be significantly larger). When an administrator or a
   management tool calls the "dump" or "details" API for LISP mappings:

4. Memory Corruption: The memcpy will overflow the key[64] boundary in the heap-allocated rmp message.

5. Heap Overflow: Since rmp messages are typically allocated with vl_msg_api_alloc() based on the exact size of the structure, this overflow will corrupt subsequent
   memory blocks in the heap.

6. Information Leak: Corrupted pointers or adjacent metadata in the heap could lead to crashes or potential code execution in the context of the VPP process.

7. Suggested Fix
   A bounds check must be added before the memcpy to ensure that only a maximum of 64 bytes are copied, or the API should return an error if the stored key is invalidly long.

1 u32 key_len = clib_min (vec_len (mapit->key), 64);
2 memcpy (rmp->key.key, mapit->key, key_len);

Best regards,
Pengpeng Hou
ISCAS

[florincoras]

Hi Pengpeng,

Thanks for the report. So this is purely a dump api not a configuration api. For the issue to be exploitable vpp must accept keys that are larger than 64B, which it shouldn't over the binary api. Still, to avoid potential issues, here's the fix https://gerrit.fd.io/r/c/vpp/+/45238