GCVE-1988-2026-0028

SUMMARY: an authenticated heap buffer overflow in cisco catalyst
c8000v sd-wan allows an attacker with low privileges to corrupt
process memory and achieve remote code execution by sending a crafted
message of type 0x0d (13) with device mode 5.
this was tested on 17.06.03 as it is the only image i had access to.

https://bst.cisco.com/quickview/bug/CSCwu48719

https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-notice-L4XfJg8S

===================== the vuln =====================

the core vuln is in vdaemon. vdaemon is the core control plane binary
used by catalyst to orchestrate stuff like secure tunneling and
joining new devices when they first are introduced to the sd-wan. thus
(again) its a juicy target to get initial access on.

the core vuln is at sub_2A4D0:

lea     rdi, [r12+0F34h] ; peer struct
mov     rbx, [rbp+src]
lea     r15, [rbx+20h]
lea     rsi, [rbx+24h]
mov     edx, [rbx+20h]
call    _memcpy
mov     byte ptr [r14+rax+0F34h], 0   ; null term

the pseudocode, essenetially, is:

memcpy(&peer->f34h, msg->dat, msg->len);
peer->f34h[msg->len] = 0;

i assume you can see the major issue in here lol. we control the
length and src since we control the message. we get a heap buffer
overflow. in this case, we get two overflows:

; second overflow
lea     rdi, [r12+0F86h]
lea     rsi, [rbx+100h]
mov     edx, [rbx+164h]
call    _memcpy
mov     byte ptr [r14+rax+0F86h], 0

this time to 0xf86 in peer.

peer is allocated in sub_21B20 once you xref it:

 peer = (unsigned int *)((__int64 (__fastcall *)(__int64))g_mem)(0x1298);

so the peer struct is 4760 bytes large.

the peer struct looks like:

struct peer {
     void    *list_next;
     void    *list_prev;
     uint8_t  pad_10[16];
     uint32_t peer_state;
     uint32_t field_24;
     uint8_t  pad_28[14];
     uint8_t  flag_36;
     uint8_t  pad_37[101];
     uint32_t msg_counter;
     uint8_t  pad_A0[232];
     uint8_t  addr_info[16];
     uint8_t  pad_198[161];
     uint8_t  tlv_block[128];
     uint8_t  pad_2B9[167];
     uint8_t  addr_data[56];
     uint8_t  field_398[24];
     uint8_t  pad_3B0[256];
     void    *conn_ptr;
     struct timespec last_seen;
     uint8_t  pad_4C8[2668];
     uint8_t  vuln_buf_1[82];  // where we hit
     uint8_t  vuln_buf_2[106];  // where we hit again
     uint8_t  field_FF0[8];
     char     str_FF8[58];
     uint8_t  field_1032;
     uint8_t  pad_1033[12];
     uint8_t  field_103F;
     uint8_t  flag_1040;
     uint8_t  pad_1041[3];
     uint32_t field_1044;
     uint32_t field_1048;
     uint8_t  pad_104C[28];
     void    (*bev_ssl)(...);        // funcptr HIT THIS HIT THIS
     uint8_t  pad_1070[48];
     uint8_t  field_10A0[128];
     uint8_t  field_1120[128];
     char     name1[41];
     char     name2[41];
     uint8_t  pad_11F2[14];
     void    *sub_obj;
     uint8_t  field_1208[144];
};

ideally, we could probably overflow the buffers to hit the function
ptr; put a stack pivot gadget then start ropping in the heap. later
versions of c8000v have pie + aslr obviously, so that would make
exploitation significantly harder but not impossible.

unforutnately the requirements to reach this heap bof mean that it
isnt preauth rce. youd still need a valid cert; but you could send a
message of type 13 (0x0D), or a REGISTER_TO_VMANAGE type, make the
device mode 5 (vManage device mode), then include your payload to hit
the sink.
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

GCVE-1988-2026-0028

Cisco Catalyst SD-WAN C8000V Authenticated Heap Buffer Overflow

Description (en)

References