OpUtils in Zoho ManageEngine OpManager 12.5 before 125490 mishandles authentication for a few audit directories.

CVE-2021-44514: Read me | OpManager Help

A command execution vulnerability exists in the wifi_country_code_update functionality of the home_security binary of Anker Eufy Homebase 2 2.1.6.9h. A specially-crafted set of network packets can lead to arbitrary command execution.

**Summary**

A command execution vulnerability exists in the wifi\_country\_code\_update functionality of the home\_security binary of Anker Eufy Homebase 2 2.1.6.9h. A specially-crafted set of network packets can lead to arbitrary command execution.

**Tested Versions**

Anker Eufy Homebase 2 2.1.6.9h

**Product URLs**

https://us.eufylife.com/products/t88411d1

**CVSSv3 Score**

9.9 - CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

**CWE**

CWE-78 - Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)

**Details**

The Eufy Homebase 2 is the video storage and networking gateway that enables the functionality of the Eufy Smarthome ecosystem. All Eufy devices connect back to this device, and this device connects out to the cloud, while also providing assorted services to enhance other Eufy Smarthome devices.

The Eufy Homebase 2’s home_security binary is a central cog in the device, spawning an inordinate amount of pthreads immediately after executing, each with their own little task. For the purposes of this advisory, we care solely about the pthread in charge of a particular cloud connectivity occurring with IP address 18.224.66.194 on UDP port 8006. An example of such traffic is shown below:

    // device -> cloud
    0000   58 5a fe b9 0b 00 00 00 59 5e 42 61 01 00 00 00   XZ......Y^Ba....
    0010   00 00 01 00 54 38 30 31 30 4e 31 32 33 34 35 36   ....T8010N123456
    0020   37 48 39 3A 00                                    789A.
    

This particular packet is the CMD_DEVICE_HEARTBEAT_CHECK, and the server’s response is seen below:

    // cloud -> device response
    0000   58 5a 32 b2 0b 00 1d 00 59 5e 42 61 01 00 01 00   XZ2.....Y^Ba....
    0010   00 00 01 00 54 38 30 31 30 4e 31 32 33 34 35 36   ....T8010N123456
    0020   38 48 39 3a 00 7b 22 64 65 76 69 63 65 5f 69 70   789a.{"device_ip
    0030   22 3a 22 37 31 2e 31 36 32 2e 32 33 37 2e 33 34   ":"71.162.237.34
    0040   22 7d                                             "}
    

While there is some interesting information already visible, reversing the protocol and viewing with a decoder is much more informative:

    [>_>] ---Pushpkt---
    Magic       : 0x5a58
    CRC         : 0x1234
    Opcode      : 0x000b (CMD_DEVICE_HEARTBEAT_CHECK)
    Bodylen     : 0x0000
    Time (unix) : 1632154786
    msg_ver     : 0x0001
    is_resp     : 0x00
    idk_lol     : 0x00
    idk_lol2    : 0x0000
    non_zero    : 0x0001
    Hub SN      : T8010N123456789a\x00
    
    [<_<] response pkt:
    [>_>] ---Pushpkt---
    Magic       : 0x5a58
    CRC         : 0x5678
    Opcode      : 0x000b (CMD_DEVICE_HEARTBEAT_CHECK)
    Bodylen     : 0x001d
    Time (unix) : 1632154746
    msg_ver     : 0x0001
    is_resp     : 0x01
    idk_lol     : 0x00
    idk_lol2    : 0x0000
    non_zero    : 0x0001
    Hub SN      : T8010N123456789a\x00
    Msgbody      : {"device_ip":"71.162.237.34"}
    

While this specific command doesn’t particularly do much, there does exist a decent amount of other opcodes to interact with:

    opcode_dict = {
        0xb   :  "CMD_DEVICE_HEARTBEAT_CHECK",
        0xc   :  "CMD_DEVICE_GET_SERVER_LIST_REQUEST",
        0xd   :  "CMD_DEVICE_GET_RSA_KEY_REQUEST",
        0x22  :  "CMD_SERVER_GET_AES_KEY_INFO",
        0x3ea :  "zx_app_unbind_hub_by_server",
        0x3eb :  "zx_start_stream",
        0x3ec :  "zx_stream_delete",
        0x3f1 :  "zx_set_dev_storagetype_by_SN",
        0x40a :  "APP_CMD_HUB_REBOOT",
        0x410 :  "zx_unbind_dev_by_sn",
        0x464 :  "APP_CMD_GET_EXCEPTION_LOG",
        0x46d :  "CMD_GET_HUB_UPGRADE",
        0xbb8 :  "turn_on_facial_recognition?",
        0xfa0 :  "wifi_country_code_update",     // [1]
        0xfa1 :  "wifi_channel_update",
        0x1388 : "CMD_SET_DEFINE_COMMAND_VALUE",
        0x1770 : "CMD_SET_DEFINE_COMMAND_STRING"
    }
    

For this advisory we’ll be discussing opcode 0xfa0, the wifi_country_code_update command \[1\]. It’s worth noting that this request does require authentication, but this can be achieved via one of the authentication bypass vulnerabilities that we’ve previously discovered (TALOS-2021-1379 and TALOS-2021-1380). Continuing on, this command’s code is very simple:

    005a2f5c  if (opcode_mb == 0xfa0)
    005a4520      start_stream_ret = 1
    005a4548      cjson = cJSON_Parse(&resppkt.msg) // [2]
    005a4554      if (cjson == 0)
    005a4670          some_str[0].d = 0x4f534a63
    005a4674          some_str[4].d = 0x61505f4e
    005a4678          some_str[8].d = 0x20657372
    005a467c          some_str[0xc].d = 0x66207369
    005a4680          some_str[0x10].d = 0x756c6961
    005a4690          some_str[0x14].w = 0x6572
    005a469c          char var_716_5 = 0
    005a457c      else
    005a457c          char* country_code = zx_Json_GetString(obj: cjson, string: "country_code", output_ptr: &tmp_json_ptr) // [3]
    005a4594          if (country_code == 0)
    005a4624              some_str[0].d = 'cJSO'
    005a4628              some_str[4].d = 'N_Ge'
    005a462c              some_str[8].d = 'tStr'
    005a4630              some_str[0xc].d = 'ing '
    005a4634              some_str[0x10].d = 'fail'
    005a4638              some_str[0x14].d = 'ure'
    005a45b4          else
    005a45b4              zx_set_nvram(0x79d738, country_code)  {"CountryCode"}
    005a45d8              zx_do_system(0x79d744, country_code)  {"iwpriv ra0 set CountryCode=%s"} // [4]
    005a45e4              start_stream_ret = 0
    

At \[2\], the server takes our packet’s data and parses it as a JSON, returning it into a cjson object. The value of the country_code field is then pulled out of this json at \[3\] and vsprintf‘ed directly into the "iwpriv ra0 set CountryCode=%s" string at \[4\] inside zx_do_system. Without going too much into the implementation of zx_do_system, it suffices to say that there is no sanitation inside, and the command provided is passed directly into a busybox shell, resulting in command injection as root. To see an example of this in action:

    [>_>] ---Pushpkt---
    Magic       : 0x5a58
    CRC         : 0x1234
    Opcode      : 0x0fa0 (wifi_country_code_update)
    Bodylen     : 0x0028
    Time (unix) : 1632328711
    msg_ver     : 0x0001
    is_resp     : 0x00
    idk_lol     : 0x00
    err_code    : 0x0000
    non_zero    : 0x0000
    Hub SN (enc): [...]
    Msgbody     : {"country_code":"`touch /mnt/boop.txt`"} // [5]
    
    [>_>] ---Pushpkt---
    Magic       : 0x5a58
    CRC         : 0x3456
    Opcode      : 0x0fa0 (wifi_country_code_update)
    Bodylen     : 0x0028
    Time (unix) : 1632328711
    msg_ver     : 0x0001
    is_resp     : 0x01
    idk_lol     : 0x00
    err_code    : 0x0000
    non_zero    : 0x0000
    Hub SN      : [...]
    

At \[5\] we can clearly see the desired command injection, touch /mnt/boop.txt, and if we then look upon the device after the fact, we can see the created file:

    BusyBox v1.12.1 (2020-12-08 19:52:46 CST) built-in shell (ash)
    Enter 'help' for a list of built-in commands.
    
    # ls /mnt
    DataDisk                hk_setupcode.sh         ocean.sh
    FlashKeyValueStore.dat  hub_time.dat            zx_udp_push_config.ini
    base_param.dat          nv-simulation.bin
    boop.txt                nv-simulation.bin.bak
    

**Timeline**

2021-09-28 - Vendor Disclosure  
2021-11-22 - Vendor Patched  
2021-11-29 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2021-21954: TALOS-2021-1381 || Cisco Talos Intelligence Group

An authentication bypass vulnerability exists in the get_aes_key_info_by_packetid() function of the home_security binary of Anker Eufy Homebase 2 2.1.6.9h. Generic network sniffing can lead to password recovery. An attacker can sniff network traffic to trigger this vulnerability.

**Summary**

An authentication bypass vulnerability exists in the get\_aes\_key\_info\_by\_packetid() function of the home\_security binary of Anker Eufy Homebase 2 2.1.6.9h. Generic network sniffing can lead to password recovery. An attacker can sniff network traffic to trigger this vulnerability.

**Tested Versions**

Anker Eufy Homebase 2 2.1.6.9h

**Product URLs**

https://us.eufylife.com/products/t88411d1

**CVSSv3 Score**

7.7 - CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:H

**CWE**

CWE-334 - Small Space of Random Values

**Details**

The Eufy Homebase 2 is the video storage and networking gateway that enables the functionality of the Eufy Smarthome ecosystem. All Eufy devices connect back to this device, and this device connects out to the cloud, while also providing assorted services to enhance other Eufy Smarthome devices.

The Eufy Homebase 2’s `home_security` binary is a central cog in the device, spawning an inordinate amount of pthreads immediately after executing, each with their own little task. For the purposes of this advisory, we care solely about the pthread in charge of a particular cloud connectivity occurring with IP address `18.224.66.194` on UDP port 8006. An example of such traffic is shown below:

    // device -> cloud
    0000   58 5a fe b9 0b 00 00 00 59 5e 42 61 01 00 00 00   XZ......Y^Ba....
    0010   00 00 01 00 54 38 30 31 30 4e 31 32 33 34 35 36   ....T8010N123456
    0020   37 48 39 3A 00                                    789A.
    

This particular packet is the `CMD_DEVICE_HEARTBEAT_CHECK`, and the server’s response is seen below:

    // cloud -> device response
    0000   58 5a 32 b2 0b 00 1d 00 59 5e 42 61 01 00 01 00   XZ2.....Y^Ba....
    0010   00 00 01 00 54 38 30 31 30 4e 31 32 33 34 35 36   ....T8010N123456
    0020   38 48 39 3a 00 7b 22 64 65 76 69 63 65 5f 69 70   789a.{"device_ip
    0030   22 3a 22 37 31 2e 31 36 32 2e 32 33 37 2e 33 34   ":"71.162.237.34
    0040   22 7d                                             "}
    

While there is some interesting information already visible, reversing the protocol and viewing with a decoder is much more informative:

    [>_>] ---Pushpkt---
    Magic       : 0x5a58
    CRC         : 0x1234
    Opcode      : 0x000b (CMD_DEVICE_HEARTBEAT_CHECK)
    Bodylen     : 0x0000
    Time (unix) : 1632154786
    msg_ver     : 0x0001
    is_resp     : 0x00
    idk_lol     : 0x00
    idk_lol2    : 0x0000
    non_zero    : 0x0001
    Hub SN      : T8010N123456789a\x00
    
    [<_<] response pkt:
    [>_>] ---Pushpkt---
    Magic       : 0x5a58
    CRC         : 0x5678
    Opcode      : 0x000b (CMD_DEVICE_HEARTBEAT_CHECK)
    Bodylen     : 0x001d
    Time (unix) : 1632154746
    msg_ver     : 0x0001
    is_resp     : 0x01
    idk_lol     : 0x00
    idk_lol2    : 0x0000
    non_zero    : 0x0001
    Hub SN      : T8010N123456789a\x00
    Msgbody      : {"device_ip":"71.162.237.34"}
    

While this specific command doesn’t particularly do much, there does exist a decent amount of other opcodes to interact with:

    opcode_dict = {
        0xb   :  "CMD_DEVICE_HEARTBEAT_CHECK",
        0xc   :  "CMD_DEVICE_GET_SERVER_LIST_REQUEST",
        0xd   :  "CMD_DEVICE_GET_RSA_KEY_REQUEST", // [1]
        0x22  :  "CMD_SERVER_GET_AES_KEY_INFO",
        0x3ea :  "zx_app_unbind_hub_by_server",
        0x3eb :  "zx_start_stream",
        0x3ec :  "zx_stream_delete",
        0x3f1 :  "zx_set_dev_storagetype_by_SN",
        0x40a :  "APP_CMD_HUB_REBOOT",
        0x410 :  "zx_unbind_dev_by_sn",
        0x464 :  "APP_CMD_GET_EXCEPTION_LOG",
        0x46d :  "CMD_GET_HUB_UPGRADE",
        0xbb8 :  "turn_on_facial_recognition?",
        0xfa0 :  "wifi_country_code_update",
        0xfa1 :  "wifi_channel_update",
        0x1388 : "CMD_SET_DEFINE_COMMAND_VALUE",
        0x1770 : "CMD_SET_DEFINE_COMMAND_STRING"
    }
    

This advisory deals with the fact that some of these opcodes require authentication, whilst others don’t. Any opcodes greater that 0x10 (i.e. below \[1\]) require authentication. These authenticated commands are rather powerful and some of them can be exploited for further escalation, but this is a digression, for we now discuss exactly how this authentication occurs. To start, we first visit the `zx_push_receiver_msg_process` function, called on boot to initialize the device’s cloud communication server:

    005a10a0  int32_t zx_push_receiver_msg_process()
    005a1114      dzlog(0x79c99c, 0x17, 0x79dcc4, 0x1c, 0x1d7, 0x28, 0x79cf78, getpid(), 0x83bdb0)  {"src/zx_push_interface.c"}  {"enter PID=%d"}  {"zx_push_receiver_msg_process"}
    005a1120      init_udp_server_domain()
    005a112c      update_udp_push_config_file()
    005a113c      s_aes_key = 0 
    005a1178      rand_str(&s_aes_key, rand_len: 0x10) // [2]
    

The only thing worth noting is that the `s_aes_key` static variable is initialized to a random secret on boot by the `rand_str` function:

    004ec5a4  void* rand_str(void* arg1, int32_t rand_len)
    004ec5c4      int32_t var_20 = 0
    004ec5e4      void var_18
    004ec5e4      void var_10
    004ec5e4      gettimeofday(&var_18, &var_10)  // [3]
    004ec5f8      int32_t var_14
    004ec5f8      int32_t var_1c = var_14
    
    004ec608      // seeded with usec
    004ec614      srand(var_1c)        // [4]
    004ec698      for (int32_t ctr = 0; ctr s< rand_len; ctr = ctr + 1) // [5]
    004ec674          *(arg1 + ctr) = *((rand_r(&var_1c) & 0x3f) + 0x7895a4)  {"0123456789ABCDEFGHIJKLMNOPQRSTUV…"}  // [6]
    004ec6b0      *(arg1 + rand_len) = 0
    004ec6c4      return arg1
    

We can see the `tv.tv_usec` field of `gettimeofday` \[3\] being used to seed `srand` at \[4\], which is totally fine. At \[5\] we start looping and putting random characters into the output at \[6\]. The full keyspace looks as such:

    >>> len("0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz~_")
    64
    

Up until this point, the secret generation seems relatively normal, but let us now examine how this secret is utilized in the `process_msg` function, which handles validation and authentication:

    005a28a0  int32_t aes_key_len = strlen(s_aes_key, pkttime)
    005a28b4  if (aes_key_len != 0x10)
    005a2d60      $v0_9 = dzlog(0x79c99c, 0x17, 0x79dc6c, 0xb, 0x33b, 0x28, 0x79d3f0)  {"src/zx_push_interface.c"}  {"process_msg COMM_RANDOM_AES_ENCR…"}  {"process_msg"}
    005a28c0  else
    005a28c0      int32_t inp_key_str = 0
    005a2924      if (get_aes_key_info_by_packetid(str: s_aes_key, packetid: devpkt_arg1->time, output: &inp_key_str) != 0) // [7]
    005a2d0c          $v0_9 = dzlog(0x79c99c, 0x17, 0x79dc6c, 0xb, 0x337, 0x28, 0x79d39c)  {"src/zx_push_interface.c"}  {"process_msg COMM_RANDOM_AES_ENCR…"}  {"process_msg"}
    005a2948      else
    005a2948          struct aes_key_st* preexpanded
    005a2948          int_aes_decryptkey(inputkey: &inp_key_str, aeskey: &preexpanded) // [8]
    005a2978          void some_output_s0x448_l0x401
    005a2978          memset(&some_output_s0x448_l0x401, 0, 0x401)
    005a2984          int32_t var_bb8_1 = 0
    005a29b4          int32_t declen = aes_decrypt(key: &preexpanded, inp_enc: &devpkt_arg1->hub_sn, inplen: 0x10, decbytes: &some_output_s0x448_l0x401) // [9]
    005a29cc          int32_t sn_enc_strncmp
    005a29cc          if (declen == 0x10)
    005a29f0              sn_enc_strncmp = strncmp(g_hub_sn, &some_output_s0x448_l0x401, 0x10) // [10]
    005a29cc              if (sn_enc_strncmp != 0)
    005a2a58                  dzlog(0x79c99c, 0x17, 0x79dc6c, 0xb, 0x310, 0x28, 0x79d2f0, &some_output_s0x448_l0x401, 0x881c30)  {"src/zx_push_interface.c"}  {"process_msg COMM_RANDOM_AES_ENCR…"}  {"process_msg"}
    005a2a68                  $v0_9 = send_device_packet_by_command_id(opcode: 0xd)
    

After getting through some basic validation of the packet length, packet time, etc, we get to the authentication. This process starts at \[7\], where the previously generated `s_aes_key` is taken, modified and then thrown into the `inp_key_str` stack variable at \[7\]. We’ll skip the actual implementation of `get_aes_key_info_by_packetid` for a second and continue looking at this function. This new key is utilized as the secret for `AES_set_decrypt_key` inside `int_aes_decryptkey`\[8\], and then the decryption of our input packet’s `hub_sn` field occurs at \[9\]. This decrypted string is then compared against the device’s serial number at \[10\]. If it’s a match, we’ve successfully authenticated. At first glance this might appear secure, but there are two very important facets of this code that we must examine further.

While the `hub_sn` eventually is encrypted for authenticated packets, as long as we can sniff the wire, this string flows periodically to the cloud servers unencrypted. Take for example the previously posted example push packet:

    [>_>] ---Pushpkt---
    Magic       : 0x5a58
    CRC         : 0x1234
    Opcode      : 0x000b (CMD_DEVICE_HEARTBEAT_CHECK)
    Bodylen     : 0x0000
    Time (unix) : 1632154786
    msg_ver     : 0x0001
    is_resp     : 0x00
    idk_lol     : 0x00
    idk_lol2    : 0x0000
    non_zero    : 0x0001
    Hub SN      : T8010N123456789a\x00  // [11]
    

We can clearly see this `hub_sn` value \[11\] over the wire all the time, so this is a known value. Keeping this in mind, the second facet exists within the glossed-over `get_aes_key_info_by_packetid` function:

    00551658  int32_t get_aes_key_info_by_packetid(char *inpstr, int32_t packetid, char* output)
    00551680      void pktid_str
    00551680      int32_t pktidlen
    00551680      if (str != 0 && output != 0)
    005516cc          strncpy(output, str, strlen(str))               // [12]
    005516fc          sprintf(&pktid_str, 0x79071c, packetid) // "%d" // [13]
    0055171c          pktidlen = strlen(&pktid_str)
    

To start and reiterate, the input secret is our randomly generated 0x10 length `s_aes_key`, and the `packetid` field is the `devpkt->time` field that we provide in our packet. At \[12\] the input secret is appropriately `strncpy`‘ed to the output, and then at \[13\] we take the decimal format of the `devpkt->time`. For a quick example of what this would look like:

    >>> str(time.time()).split(".")[0]
    '1632411932'
    

It’s important to note that the input `devpkt->time` field must be within 60 seconds of the unix time of the Eufy Homebase device, or else it is considered invalid and we never get to the authentication. Thus, since enough time has passed since epoch, the length of this string will always be 10 bytes. Also, to see the Eufy device’s time, it suffices to sniff network traffic and pull it from one of the outbound packets. Continuing on within `get_aes_key_info_by_packetid`:

    00551680      if (str != 0 && output != 0)
    005516cc          strncpy(output, str, strlen(str))               
    005516fc          sprintf(&pktid_str, 0x79071c, packetid) // "%d" // [14]
    0055171c          pktidlen = strlen(&pktid_str)
    00551680      int32_t ret
    00551680      if (str == 0 || (str != 0 && output == 0) || (str != 0 && output != 0 && pktidlen s>= 0x10))
    0055178c          ret = 0xffffffff
    00551680      if (str != 0 && output != 0 && pktidlen s< 0x10)
    00551774          memcpy(&output[0x10 - pktidlen], &pktid_str, pktidlen) // [15]
    00551780          ret = 0
    00551798      return ret
    

After the `pktid_str` is generated at \[14\], it is then `memcpy`‘ed on top of our `s_aes_key` copy at \[15\]. Since this occurs in an overlapping fashion and not in an appending fashion, the output secret will look something like `aC01_?` + `1632411932`, i.e. the first bytes of our randomly generated `s_aes_key` and then the unix time as a string. While the output secret is the same length as we had before, 0x10, this function reduces entropy of our AES encryption from 0x10 bytes to 0x6 bytes, and our keyspace goes from 64^16 (79228162514264337593543950336 combinations) to 64^6 (68719476736 combinations).

To summarize all this into a final vulnerability: Since we know what the decrypted authentication string is supposed to be (our device’s `g_hub_sn`, `T8010N123456789a`), and we also know the last 10 bytes of the encryption key that’s used for a given packet (the unix time), then it easily becomes possible to offline bruteforce the first six bytes of the AES secret that’s actually used to encrypt the `g_hub_sn`. Once we know these first 6 bytes, it does not matter what the current unix time is, we can simply append the first six bytes of the bruteforced `s_aes_key` to the current unix time and gain privileges, resulting in an authentication bypass.

**Timeline**

2021-09-30 - Vendor Disclosure  
2021-11-22 - Vendor Patched

2021-11-29 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2021-21955: TALOS-2021-1382 || Cisco Talos Intelligence Group

**Summary**

A command execution vulnerability exists in the wifi\_country\_code\_update functionality of the home\_security binary of Anker Eufy Homebase 2 2.1.6.9h. A specially-crafted set of network packets can lead to arbitrary command execution.

**Tested Versions**

Anker Eufy Homebase 2 2.1.6.9h

**Product URLs**

https://us.eufylife.com/products/t88411d1

**CVSSv3 Score**

9.9 - CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

**CWE**

CWE-78 - Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)

**Details**

The Eufy Homebase 2 is the video storage and networking gateway that enables the functionality of the Eufy Smarthome ecosystem. All Eufy devices connect back to this device, and this device connects out to the cloud, while also providing assorted services to enhance other Eufy Smarthome devices.

The Eufy Homebase 2’s `home_security` binary is a central cog in the device, spawning an inordinate amount of pthreads immediately after executing, each with their own little task. For the purposes of this advisory, we care solely about the pthread in charge of a particular cloud connectivity occurring with IP address `18.224.66.194` on UDP port 8006. An example of such traffic is shown below:

    // device -> cloud
    0000   58 5a fe b9 0b 00 00 00 59 5e 42 61 01 00 00 00   XZ......Y^Ba....
    0010   00 00 01 00 54 38 30 31 30 4e 31 32 33 34 35 36   ....T8010N123456
    0020   37 48 39 3A 00                                    789A.
    

This particular packet is the `CMD_DEVICE_HEARTBEAT_CHECK`, and the server’s response is seen below:

    // cloud -> device response
    0000   58 5a 32 b2 0b 00 1d 00 59 5e 42 61 01 00 01 00   XZ2.....Y^Ba....
    0010   00 00 01 00 54 38 30 31 30 4e 31 32 33 34 35 36   ....T8010N123456
    0020   38 48 39 3a 00 7b 22 64 65 76 69 63 65 5f 69 70   789a.{"device_ip
    0030   22 3a 22 37 31 2e 31 36 32 2e 32 33 37 2e 33 34   ":"71.162.237.34
    0040   22 7d                                             "}
    

While there is some interesting information already visible, reversing the protocol and viewing with a decoder is much more informative:

    [>_>] ---Pushpkt---
    Magic       : 0x5a58
    CRC         : 0x1234
    Opcode      : 0x000b (CMD_DEVICE_HEARTBEAT_CHECK)
    Bodylen     : 0x0000
    Time (unix) : 1632154786
    msg_ver     : 0x0001
    is_resp     : 0x00
    idk_lol     : 0x00
    idk_lol2    : 0x0000
    non_zero    : 0x0001
    Hub SN      : T8010N123456789a\x00
    
    [<_<] response pkt:
    [>_>] ---Pushpkt---
    Magic       : 0x5a58
    CRC         : 0x5678
    Opcode      : 0x000b (CMD_DEVICE_HEARTBEAT_CHECK)
    Bodylen     : 0x001d
    Time (unix) : 1632154746
    msg_ver     : 0x0001
    is_resp     : 0x01
    idk_lol     : 0x00
    idk_lol2    : 0x0000
    non_zero    : 0x0001
    Hub SN      : T8010N123456789a\x00
    Msgbody      : {"device_ip":"71.162.237.34"}
    

While this specific command doesn’t particularly do much, there does exist a decent amount of other opcodes to interact with:

    opcode_dict = {
        0xb   :  "CMD_DEVICE_HEARTBEAT_CHECK",
        0xc   :  "CMD_DEVICE_GET_SERVER_LIST_REQUEST",
        0xd   :  "CMD_DEVICE_GET_RSA_KEY_REQUEST",
        0x22  :  "CMD_SERVER_GET_AES_KEY_INFO",
        0x3ea :  "zx_app_unbind_hub_by_server",
        0x3eb :  "zx_start_stream",
        0x3ec :  "zx_stream_delete",
        0x3f1 :  "zx_set_dev_storagetype_by_SN",
        0x40a :  "APP_CMD_HUB_REBOOT",
        0x410 :  "zx_unbind_dev_by_sn",
        0x464 :  "APP_CMD_GET_EXCEPTION_LOG",
        0x46d :  "CMD_GET_HUB_UPGRADE",
        0xbb8 :  "turn_on_facial_recognition?",
        0xfa0 :  "wifi_country_code_update",     // [1]
        0xfa1 :  "wifi_channel_update",
        0x1388 : "CMD_SET_DEFINE_COMMAND_VALUE",
        0x1770 : "CMD_SET_DEFINE_COMMAND_STRING"
    }
    

For this advisory we’ll be discussing opcode 0xfa0, the `wifi_country_code_update` command \[1\]. It’s worth noting that this request does require authentication, but this can be achieved via one of the authentication bypass vulnerabilities that we’ve previously discovered (TALOS-2021-1379 and TALOS-2021-1380). Continuing on, this command’s code is very simple:

    005a2f5c  if (opcode_mb == 0xfa0)
    005a4520      start_stream_ret = 1
    005a4548      cjson = cJSON_Parse(&resppkt.msg) // [2]
    005a4554      if (cjson == 0)
    005a4670          some_str[0].d = 0x4f534a63
    005a4674          some_str[4].d = 0x61505f4e
    005a4678          some_str[8].d = 0x20657372
    005a467c          some_str[0xc].d = 0x66207369
    005a4680          some_str[0x10].d = 0x756c6961
    005a4690          some_str[0x14].w = 0x6572
    005a469c          char var_716_5 = 0
    005a457c      else
    005a457c          char* country_code = zx_Json_GetString(obj: cjson, string: "country_code", output_ptr: &tmp_json_ptr) // [3]
    005a4594          if (country_code == 0)
    005a4624              some_str[0].d = 'cJSO'
    005a4628              some_str[4].d = 'N_Ge'
    005a462c              some_str[8].d = 'tStr'
    005a4630              some_str[0xc].d = 'ing '
    005a4634              some_str[0x10].d = 'fail'
    005a4638              some_str[0x14].d = 'ure'
    005a45b4          else
    005a45b4              zx_set_nvram(0x79d738, country_code)  {"CountryCode"}
    005a45d8              zx_do_system(0x79d744, country_code)  {"iwpriv ra0 set CountryCode=%s"} // [4]
    005a45e4              start_stream_ret = 0
    

At \[2\], the server takes our packet’s data and parses it as a JSON, returning it into a cjson object. The value of the `country_code` field is then pulled out of this json at \[3\] and `vsprintf`‘ed directly into the `"iwpriv ra0 set CountryCode=%s"` string at \[4\] inside `zx_do_system`. Without going too much into the implementation of `zx_do_system`, it suffices to say that there is no sanitation inside, and the command provided is passed directly into a busybox shell, resulting in command injection as root. To see an example of this in action:

    [>_>] ---Pushpkt---
    Magic       : 0x5a58
    CRC         : 0x1234
    Opcode      : 0x0fa0 (wifi_country_code_update)
    Bodylen     : 0x0028
    Time (unix) : 1632328711
    msg_ver     : 0x0001
    is_resp     : 0x00
    idk_lol     : 0x00
    err_code    : 0x0000
    non_zero    : 0x0000
    Hub SN (enc): [...]
    Msgbody     : {"country_code":"`touch /mnt/boop.txt`"} // [5]
    
    [>_>] ---Pushpkt---
    Magic       : 0x5a58
    CRC         : 0x3456
    Opcode      : 0x0fa0 (wifi_country_code_update)
    Bodylen     : 0x0028
    Time (unix) : 1632328711
    msg_ver     : 0x0001
    is_resp     : 0x01
    idk_lol     : 0x00
    err_code    : 0x0000
    non_zero    : 0x0000
    Hub SN      : [...]
    

At \[5\] we can clearly see the desired command injection, `touch /mnt/boop.txt`, and if we then look upon the device after the fact, we can see the created file:

    BusyBox v1.12.1 (2020-12-08 19:52:46 CST) built-in shell (ash)
    Enter 'help' for a list of built-in commands.
    
    # ls /mnt
    DataDisk                hk_setupcode.sh         ocean.sh
    FlashKeyValueStore.dat  hub_time.dat            zx_udp_push_config.ini
    base_param.dat          nv-simulation.bin
    boop.txt                nv-simulation.bin.bak
    

**Timeline**

2021-09-28 - Vendor Disclosure  
2021-11-22 - Vendor Patched  
2021-11-29 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

A privilege escalation vulnerability exists in the Remote Server functionality of Dream Report ODS Remote Connector 20.2.16900.0. A specially-crafted command injection can lead to elevated capabilities. An attacker can provide a malicious file to trigger this vulnerability.

**Summary**

A privilege escalation vulnerability exists in the Remote Server functionality of Dream Report ODS Remote Connector 20.2.16900.0. A specially-crafted command injection can lead to elevated capabilities. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

Dream Report ODS Remote Connector 20.2.16900.0

**Product URLs**

https://dreamreport.net/

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

**CWE**

CWE-276 - Incorrect Default Permissions

**Details**

Dream Report is an automation platform designed to facilitate collection and parsing of real-time information between various devices in industrial environments.

The service ‘RTM Reporting System Runtime Manager’ is installed during stand-alone installation of ODS Remote Connector and starts with the following command (with high integrity):

     c:\program files (x86)\ods\remote connector\system\rtm.exe" -control -runMode svc
    

After above command line is executed, another binary is also started and runs throughout lifecycle of the main service process:

    "C:\Program Files (x86)\ODS\Remote Connector\System\Rdxa.exe"
    

RTM Reporting System Runtime Manager allows any user on the system to replace a binary located in the default installation folder, as seen below, to execute code with privilege of NT SYSTEM with high integrity:

    c:\program files (x86)\ods\remote connector\system\Rtm.exe:
    BUILTIN\Administrators:(ID)F
    Everyone:(ID)F
                                                 
    C:\Program Files (x86)\ODS\Remote Connector\System\Rdxa.exe:
    BUILTIN\Administrators:(ID)F
    Everyone:(ID)F
    

In addition, due to permission weaknesses, other components such as DLL libraries, used by any of the applications above, can be used to sideload code from the following folder:

    C:\Program Files (x86)\ODS\Remote Connector\System
    

These can be, for example:

    BatchManager.dll
    ChangeManager.dll
    FontManagerDll.dll
    

Note that initial exploitation would result in access to the same privilege as a default virtual service user nt service\rtm reporting system runtime manager. A full exploitation chain would need to take advantage of the SeImpersonatePrivilege privilege assigned to the RTM Reporting System Runtime Manager service to achieve reliable execution with NT SYSTEM privilage.

**Vendor Response**

Fixed in Dream Report Remote Connector 20.2.16900.1011

**Timeline**

2021-10-05 - Vendor Disclosure  
2021-12-02 - Vendor patched  
2021-12-06 - Public Release

Discovered by Yuri Kramarz of Cisco Talos.

CVE-2021-21957: TALOS-2021-1384 || Cisco Talos Intelligence Group

**Summary**

A privilege escalation vulnerability exists in the Remote Server functionality of Dream Report ODS Remote Connector 20.2.16900.0. A specially-crafted command injection can lead to elevated capabilities. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

Dream Report ODS Remote Connector 20.2.16900.0

**Product URLs**

https://dreamreport.net/

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

**CWE**

CWE-276 - Incorrect Default Permissions

**Details**

Dream Report is an automation platform designed to facilitate collection and parsing of real-time information between various devices in industrial environments.

The service ‘RTM Reporting System Runtime Manager’ is installed during stand-alone installation of ODS Remote Connector and starts with the following command (with high integrity):

     c:\program files (x86)\ods\remote connector\system\rtm.exe" -control -runMode svc
    

After above command line is executed, another binary is also started and runs throughout lifecycle of the main service process:

    "C:\Program Files (x86)\ODS\Remote Connector\System\Rdxa.exe"
    

RTM Reporting System Runtime Manager allows any user on the system to replace a binary located in the default installation folder, as seen below, to execute code with privilege of NT SYSTEM with high integrity:

    c:\program files (x86)\ods\remote connector\system\Rtm.exe:
    BUILTIN\Administrators:(ID)F
    Everyone:(ID)F
                                                 
    C:\Program Files (x86)\ODS\Remote Connector\System\Rdxa.exe:
    BUILTIN\Administrators:(ID)F
    Everyone:(ID)F
    

In addition, due to permission weaknesses, other components such as DLL libraries, used by any of the applications above, can be used to sideload code from the following folder:

    C:\Program Files (x86)\ODS\Remote Connector\System
    

These can be, for example:

    BatchManager.dll
    ChangeManager.dll
    FontManagerDll.dll
    

Note that initial exploitation would result in access to the same privilege as a default virtual service user `nt service\rtm reporting system runtime manager`. A full exploitation chain would need to take advantage of the `SeImpersonatePrivilege` privilege assigned to the RTM Reporting System Runtime Manager service to achieve reliable execution with NT SYSTEM privilage.

**Vendor Response**

Fixed in Dream Report Remote Connector 20.2.16900.1011

**Timeline**

2021-10-05 - Vendor Disclosure  
2021-12-02 - Vendor patched  
2021-12-06 - Public Release

Discovered by Yuri Kramarz of Cisco Talos.

An out-of-bounds write vulnerability exists in the CMD_DEVICE_GET_SERVER_LIST_REQUEST functionality of the home_security binary of Anker Eufy Homebase 2 2.1.6.9h in function recv_server_device_response_msg_process. A specially-crafted network packet can lead to code execution.

**Summary**

An out-of-bounds write vulnerability exists in the CMD\_DEVICE\_GET\_SERVER\_LIST\_REQUEST functionality of the home\_security binary of Anker Eufy Homebase 2 2.1.6.9h. A specially-crafted network packet can lead to code execution.

**Tested Versions**

Anker Eufy Homebase 2 2.1.6.9h

**Product URLs**

https://us.eufylife.com/products/t88411d1

**CVSSv3 Score**

10.0 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

**CWE**

CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer

**Details**

The Eufy Homebase 2 is the video storage and networking gateway that enables the functionality of the Eufy Smarthome ecosystem. All Eufy devices connect back to this device, and this device connects out to the cloud, while also providing assorted services to enhance other Eufy Smarthome devices.

The Eufy Homebase 2’s `home_security` binary is a central cog in the device, spawning inordinate amount of pthreads immediately after executing, each with their own little task. For the purposes of this advisory, we care solely about the pthread in charge of a particular cloud connectivity occurring with IP address `18.224.66.194` on UDP port 8006. An example of such traffic is shown below:

    // device -> cloud
    0000   58 5a fe b9 0b 00 00 00 59 5e 42 61 01 00 00 00   XZ......Y^Ba....
    0010   00 00 01 00 54 38 30 31 30 4e 31 32 33 34 35 36   ....T8010N123456
    0020   37 48 39 3A 00                                    789A.
    

This particular packet is the `CMD_DEVICE_HEARTBEAT_CHECK`, and the server’s response is seen below:

    // cloud -> device response
    0000   58 5a 32 b2 0b 00 1d 00 59 5e 42 61 01 00 01 00   XZ2.....Y^Ba....
    0010   00 00 01 00 54 38 30 31 30 4e 31 32 33 34 35 36   ....T8010N123456
    0020   38 48 39 3a 00 7b 22 64 65 76 69 63 65 5f 69 70   789a.{"device_ip
    0030   22 3a 22 37 31 2e 31 36 32 2e 32 33 37 2e 33 34   ":"71.162.237.34
    0040   22 7d                                             "}
    

While there is some interesting information already visible, reversing the protocol and viewing with a decoder is much more informative:

    [>_>] ---Pushpkt---
    Magic       : 0x5a58
    CRC         : 0x1234
    Opcode      : 0x000b (CMD_DEVICE_HEARTBEAT_CHECK)
    Bodylen     : 0x0000
    Time (unix) : 1632154786
    msg_ver     : 0x0001
    is_resp     : 0x00
    idk_lol     : 0x00
    idk_lol2    : 0x0000
    non_zero    : 0x0001
    Hub SN      : T8010N123456789a\x00
    
    [<_<] response pkt:
    [>_>] ---Pushpkt---
    Magic       : 0x5a58
    CRC         : 0x5678
    Opcode      : 0x000b (CMD_DEVICE_HEARTBEAT_CHECK)
    Bodylen     : 0x001d
    Time (unix) : 1632154746
    msg_ver     : 0x0001
    is_resp     : 0x01
    idk_lol     : 0x00
    idk_lol2    : 0x0000
    non_zero    : 0x0001
    Hub SN      : T8010N123456789a\x00
    Msgbody      : {"device_ip":"71.162.237.34"}
    

While this specific command doesn’t particularly do much, there does exist a decent amount of other opcodes to interact with:

    opcode_dict = {
        0xb   :  "CMD_DEVICE_HEARTBEAT_CHECK",
        0xc   :  "CMD_DEVICE_GET_SERVER_LIST_REQUEST", // [1]
        0xd   :  "CMD_DEVICE_GET_RSA_KEY_REQUEST",     // [2]
        0x22  :  "CMD_SERVER_GET_AES_KEY_INFO",
        0x3ea :  "zx_app_unbind_hub_by_server",
        0x3eb :  "zx_start_stream",
        0x3ec :  "zx_stream_delete",
        0x3f1 :  "zx_set_dev_storagetype_by_SN",
        0x40a :  "APP_CMD_HUB_REBOOT",
        0x410 :  "zx_unbind_dev_by_sn",
        0x464 :  "APP_CMD_GET_EXCEPTION_LOG",
        0x46d :  "CMD_GET_HUB_UPGRADE",
        0xbb8 :  "turn_on_facial_recognition?",
        0xfa0 :  "wifi_country_code_update",
        0xfa1 :  "wifi_channel_update",
        0x1388 : "CMD_SET_DEFINE_COMMAND_VALUE",
        0x1770 : "CMD_SET_DEFINE_COMMAND_STRING"
    }
    

While some of these opcode names look tantalizing, only the opcodes less than 0x10 require no authentication, so we’re limited to `CMD_DEVICE_GET_SERVER_LIST_REQUEST` \[1\] and `CMD_DEVICE_GET_RSA_KEY_REQUEST` \[2\]. For the purposes of this advisory, we only need one of these: `CMD_DEVICE_GET_SERVER_LIST_REQUEST`. Since the same vulnerable code pattern is found in two different functions, we’ll discuss them separately.

**CVE-2021-21950 - recv\_server\_device\_response\_msg\_process**

In function `recv_server_device_response_msg_process`, the `CMD_DEVICE_GET_SERVER_LIST_REQUEST` request is parsed as shown below:

    05a1748  uint32_t recv_server_device_response_msg_process(struct dev_packet* devpkt, int32_t inp_msglen, struct sockaddr* dstaddr, int32_t sockfd)
    
    005a179c      uint32_t opcode = zx.d((zx.d(devpkt->opcode:1.b) << 8).w | zx.w(devpkt->opcode.b))
    005a17c8      struct dev_packet_full resp_buf
    005a17c8      memset(&resp_buf, 0, 0x425)
    005a17d8      uint32_t scratch = opcode
    005a17e0      struct aes_key_st scratchbuf
    
    005a17e0      if (scratch == 0xc)
    005a1acc          m_heart_timemout_nums = 0
    005a1ad8          m_udp_server_connect = 1
    
    005a1ae8          int32_t resp_time = 0
    005a1b0c          memcpy(&resp_buf, devpkt, inp_msglen)
    005a1b30          struct cJSON* jsonobj = cJSON_Parse(&resp_buf.msg)  
    
    005a1b48          if (jsonobj != 0)
    005a1b6c              uint32_t udp_server_num = zx_Json_GetInt(jsonobj, "nums", 0)  // [3]
    005a1ba4              resp_time = zx_Json_GetInt(jsonobj, "utc_time", 0)            // [4]
    // [...]
    005a1c84              s_udp_server_total_nums = udp_server_num
    005a1e9c              for (int32_t ctr = 0; ctr s< udp_server_num; ctr = ctr + 1)  
    005a1cb8                  memset(&scratchbuf, 0, 0x80)
    005a1cf8                  sprintf(&scratchbuf, 0x79ca14, 0x79ca1c, ctr + 1, var_798, var_794, var_790, var_78c, var_788)  {"%s%d"}  {"domain"}
    005a1d20                  char* str_value = zx_Json_GetString(obj: jsonobj, string: &scratchbuf, output_ptr: nullptr)    // [5]
    005a1d38                  if (str_value != 0 && strlen(str_value) u< 0x80)
    005a1da0                      memset((ctr << 7) + 0x88287c, 0, 0x80)
    005a1e00                      memcpy(0x88287c + (ctr << 7), str_value, strlen(str_value))
    // [...]
    005a1eb4              cJSON_Delete(cjson: jsonobj)
    005a1ec0              int32_t var_768_4 = 0
    005a1ed0              if (s_udp_server_total_nums s> 0)
    005a1ed8                  update_udp_push_config_file()
    005a1ee8          scratch = send_device_packet_by_command_id(opcode: 0xd)
    

Utilizing the cJSON library to pull out the `nums` field \[3\], the `utc_time` field \[4\], and also a list of domains from the json of the server’s response \[5\], the `CMD_DEVICE_GET_SERVER_LIST_REQUEST` opcode then stores this server list information inside of the `zx_udp_push_config.ini` file. When valid, the file might look like so:

    /~ cat /mnt/zx_udp_push_config.ini 
    [NET]
    domain_total=3
    current_index=2
    app_server_domain=security-app.eufylife.com
    domain1=p2p-vir-6.eufylife.com
    domain2=p2p-vir-7.eufylife.com
    domain3=mediaserver-usa3.eufylife.com
    

We now have enough context to discuss the vulnerability, so let us go back to a particular subset of the above `recv_server_device_response_msg_process` code:

    005a1b48          if (jsonobj != 0)
    005a1b6c              uint32_t udp_server_num = zx_Json_GetInt(jsonobj, "nums", 0)   // [6]
    005a1ba4              resp_time = zx_Json_GetInt(jsonobj, "utc_time", 0)           
    // [...]
    005a1c84              s_udp_server_total_nums = udp_server_num
    005a1e9c              for (int32_t ctr = 0; ctr s< udp_server_num; ctr = ctr + 1)    // [7]
    005a1cb8                  memset(&scratchbuf, 0, 0x80)
    005a1cf8                  sprintf(&scratchbuf, 0x79ca14, 0x79ca1c, ctr + 1, var_798, var_794, var_790, var_78c, var_788)  {"%s%d"}  {"domain"}
    005a1d20                  char* str_value = zx_Json_GetString(obj: jsonobj, string: &scratchbuf, output_ptr: nullptr)    // [8]
    005a1d38                  if (str_value != 0 && strlen(str_value) u< 0x80)                 // [9]
    005a1da0                      memset((ctr << 7) + 0x88287c, 0, 0x80)                       // [10]
    005a1e00                      memcpy(0x88287c + (ctr << 7), str_value, strlen(str_value))  // [11]
    

When pulling the `nums` field, which serves as the total number of UDP server domains, we must note the total lack of validation on this field anywhere thereafter \[6\]. Thus, the amount of iterations for the loop at \[7\] is entirely attacker-controlled, along with the `int32_t ctr` variable at \[7\] as well. If the search for `domain1`, `domain2`, … `domain%d` field from our packet JSON fails at \[8\], or if the string length of the value is greater than 0x80, we skip the branch at \[9\] but stay within our loop at \[7\]. The `ctr` variable keeps incrementing. With all this in mind we can reason that the lines at \[10\] and \[11\] can be hit with whatever value inside of `ctr` that an attacker chooses. While there is a total packet length limit of 0x425 bytes found much earlier in the codebase, there’s no requirement for our JSON to have `domain1` and `domain2` and so on and so forth. We would quickly run out of bytes before we could write outside of the `char s_udp_server_list[0x80][8]` at 0x88287c. Thus, simply by inserting something like `"domain100000":aaaaaaaaaaaaaaa...` and `"nums":100001` into a `CMD_DEVICE_GET_SERVER_LIST_REQUEST`, one can write 0x80 bytes to `0x88287c + (100000 << 7)`, something applicable to any address in memory, resulting in a write-what-where and subsequent code execution.

**Crash Information**

    Terminated with signal SIGSEGV, Segmentation fault.
    #0  0x77226a84 in memset () from /lib/libc.so.0
    
    [Current thread is 1 (LWP 5768)]
    
    Backtrace stopped: frame did not save the PC
    <(^.^)>#info reg
              zero       at       v0       v1       a0       a1       a2       a3
     R0   00000000 1100ff00 0216207c 0216207c 02162084 00000000 00000000 021620fc
                t0       t1       t2       t3       t4       t5       t6       t7
     R8   00000000 00000000 00000200 00000100 00000807 00000800 00000400 00000008
                s0       s1       s2       s3       s4       s5       s6       s7
     R16  6148b52a 7fe43468 00000036 771de280 7c6c0000 00000000 00000007 0000e436
                t8       t9       k0       k1       gp       sp       s8       ra
     R24  00000001 77226a30 00000000 00000000 0083bdb0 7c6fe498 00000000 005a1da8
                sr       lo       hi      bad    cause       pc
          0100ff13 00000000 00000002 0216207c 0080000c 77226a84
               fsr      fir
          00000000 00000000
    <(^.^)>#x/4i $pc
    => 0x77226a84 <memset+84>:      sw      a1,-8(a0)
       0x77226a88 <memset+88>:      bne     a0,a3,0x77226a80 <memset+80>
       0x77226a8c <memset+92>:      sw      a1,-4(a0)
       0x77226a90 <memset+96>:      andi    t0,a2,0x4
    <(^.^)>#bt
    #0  0x77226a84 in memset () from /lib/libc.so.0
    #1  0x005a1da8 in recv_server_device_response_msg_process (p_data=0x7c6ff8ec, data_len=175, server_sin=0x7c6ff8d8, socket_id=22) at src/zx_push_interface.c:633
    #2  0x005a6584 in process_msg (p_data=0x7c6ff8ec, data_len=175, server_sin=0x7c6ff8d8, socket_id=22) at src/zx_push_interface.c:1507
    #3  0x005a108c in zx_push_recv_packet (socket_id=22) at src/zx_push_interface.c:462
    #4  0x005a05b4 in init_udp_server_domain () at src/zx_push_interface.c:340
    #5  0x005a1128 in zx_push_receiver_msg_process (argv=0x0) at src/zx_push_interface.c:473
    #6  0x771c3264 in pthread_start_thread () from /lib/libpthread.so.0
    #7  0x772007f8 in __thread_start () from /lib/libc.so.0
    
    <(^.^)>#info reg a0
    a0: 0x2162084
    
    <(^.^)>#info proc map
    Mapped address spaces:
            Start Addr   End Addr       Size     Offset objfile
              0x400000   0x7f8000   0x3f8000        0x0 /bin/home_security
              0x808000   0x837000    0x2f000   0x3f8000 /bin/home_security
    

**CVE-2021-21951 - read\_udp\_push\_config\_file**

The previously-mentioned bug is also found in a second function, `read_udp_push_config_file`, in the same code pattern. After reading the `CMD_DEVICE_GET_SERVER_LIST_REQUEST` in `recv_server_device_response_msg_process`, these values are then written into the `/mnt/zx_udp_push_config.ini` file. On reboot, `read_udp_push_config_file` is hit and we read the `/mnt/zx_udp_push_config.ini` config file, all the same vulnerability principles being applicable.

    0059f2f4                  if (zx_file_readcfg(file: "/mnt/zx_udp_push_config.ini", char *section: 0x79c980, headername: "domain_total", output: &var_110_0x80_size) != 0)  {"[NET]"}  // [1]
    0059f348                      $v0_1 = 0xffffffff
    0059f324                  else
    0059f324                      s_udp_server_total_nums = atoi(&var_110_0x80_size)
    0059f334                      if (s_udp_server_total_nums == 0) 
    0059f33c                          $v0_1 = 0xffffffff
    0059f378                      else
    0059f378                          memset(&var_110_0x80_size, 0, 0x80)
    0059f3bc                          if (zx_file_readcfg(file: "/mnt/zx_udp_push_config.ini", char *section: 0x79c980, headername: "current_index", output: &var_110_0x80_size) != 0)  {"[NET]"}
    0059f400                              $v0_1 = 0xffffffff
    0059f3ec                          else
    0059f3ec                              s_current_udp_server_index = atoi(&var_110_0x80_size) 
    
    0059f6bc                              while (true)
    0059f6bc                                  if (ctr s>= s_udp_server_total_nums) // [2]
    0059f6bc                                      if (s_udp_server_total_nums u>= s_current_udp_server_index && sx.d(*((s_current_udp_server_index << 7) + 0x88287c)) != 0)
    0059f6e8                                          memset(0x8827f4, 0, 0x80)
    0059f72c                                          strncpy(0x8827f4, 0x88287c + (s_current_udp_server_index << 7), 0x7f) /
    // [...]
    0059f7a8                                      $v0_1 = 0
    0059f7a8                                      break
    0059f430                                  memset(&var_110_0x80_size, 0, 0x80)
    0059f460                                  void var_90
    0059f460                                  memset(&var_90, 0, 0x80)
    0059f4a0                                  sprintf(&var_90, 0x79ca14, 0x79ca1c, ctr + 1, var_138, var_134, var_130, var_12c, var_128)  {"%s%d"}  {"domain"}
    0059f648                                  if (zx_file_readcfg(file: "/mnt/zx_udp_push_config.ini", char *section: 0x79c980, headername: &var_90, output: &var_110_0x80_size) != 0)  {"[NET]"}
    0059f648                                      $v0_1 = 0xffffffff
    0059f64c                                      break
    0059f524                                  memset((ctr << 7) + 0x88287c, 0, 0x80)
    0059f554                                  if (strlen(&var_110_0x80_size) u< 0x80)
    0059f5b4                                      strncpy((ctr << 7) + 0x88287c, &var_110_0x80_size, strlen(&var_110_0x80_size) - 1) //[3]
    0059f5dc                                  var_138 = 0xb2
    0059f5e4                                  var_134 = 0x28
    0059f5f0                                  var_130 = 0x79ca24  {"%s:%s"}
    0059f5f8                                  var_12c = &var_90
    0059f5fc                                  var_128 = (ctr << 7) + 0x88287c
    0059f624                                  dzlog(0x79c99c, 0x17, 0x79dd8c, 0x19, 0xb2, 0x28, 0x79ca24, var_12c, var_128)  {"src/zx_push_interface.c"}  {"%s:%s"}  {"read_udp_push_config_file"}
    0059f63c                                  ctr = ctr + 1  
    

At \[1\], we see the `domain_total` field being pulled out of the config file. This value serves as an upper-bound loop condition for the loop at \[2\]. As our `ctr` variable increments until it reaches `s_udp_server_total_nums`, the `domain%d` fields are again searched for. If a match is found, then we again write to `((ctr << 7) + 0x88287c`, an arbitrary value since we control the contents of the file. Thus, for example, with a `domain100000=aaaaaaaaaaaaaa...` inside of the config file, an out-of-bounds write occurs, resulting in code execution.

**Timeline**

2021-09-30 - Vendor Disclosure

2021-11-22 - Vendor Patched  
2021-11-29 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2021-21950: TALOS-2021-1378 || Cisco Talos Intelligence Group

A code execution vulnerability exists in the dwgCompressor::decompress18() functionality of LibreCad libdxfrw 2.2.0-rc2-19-ge02f3580. A specially-crafted .dwg file can lead to an out-of-bounds write. An attacker can provide a malicious file to trigger this vulnerability.

**Summary**

A code execution vulnerability exists in the dwgCompressor::decompress18() functionality of LibreCad libdxfrw 2.2.0-rc2-19-ge02f3580. A specially-crafted .dwg file can lead to an out-of-bounds write. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

LibreCad libdxfrw 2.2.0-rc2-19-ge02f3580

**Product URLs**

https://librecad.org/

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer

**Details**

Libdfxfw is an opensource library facilitating the reading and writing of .dxf and .dwg files, the primary vector graphics file formats of CAD software. Libdxfrw is contained in and primarily used by LibreCAD for the aforementioned purposes, but c

Libdxfrw is capable of reading many different versions of .dwg files. The backwards compatibility is quite extensive, and likewise the particulars for each version are quite extensive. For today’s vulnerability, we deal with the AC1024 version, the AutoCAD .dwg standard from 2010 through 2012. At least for Librecad and libdxfrw, this AC1024 version oddly ends up hitting the same code as the AC1018 version, the AutoCAD .dwg standard from 2004 through 2007. Even if a function ends in 18 (e.g. dwgReader18::readFileHeader), this vulnerability is applicable to both versions for libdxfrw.

To start, the dwgReader24::readFileHeader function is a good place to begin:

    bool dwgReader24::readFileHeader() {
        DRW_DBG("dwgReader24::readFileHeader\n");
        bool ret = dwgReader18::readFileHeader();
        DRW_DBG("dwgReader24::readFileHeader END\n");
        return ret;
    }
    

Simple and easy, this function immediately calls into dwgReader18::readFileHeader, which is a bit of a doozy. The below version of it is with all the DRW_DBG logging code removed :

    bool dwgReader18::readFileHeader() {
    
        if (! fileBuf->setPosition(0x80))  // [1]
            return false;
    
        //    genMagicNumber(); DBG("\n"); DBG("\n");
        duint8 byteStr[0x6C];
        int size =0x6C;
        for (int i=0, j=0; i< 0x6C;i++) {
            duint8 ch = fileBuf->getRawChar8(); 
    
            byteStr[i] = DRW_magicNum18[i] ^ ch;
        }
    
       //[ ... ]
    
        dwgBuffer buff(byteStr, 0x6C, &decoder);
    

The first part of this function simply reads file offsets (0x80,0x10C) and then xors them against a hardcoded magic set of bytes:

    static const int DRW_magicNum18[] = {
        0x29, 0x23, 0xbe, 0x84, 0xe1, 0x6c, 0xd6, 0xae,
        0x52, 0x90, 0x49, 0xf1, 0xf1, 0xbb, 0xe9, 0xeb,
        0xb3, 0xa6, 0xdb, 0x3c, 0x87, 0x0c, 0x3e, 0x99,
        0x24, 0x5e, 0x0d, 0x1c, 0x06, 0xb7, 0x47, 0xde,
        0xb3, 0x12, 0x4d, 0xc8, 0x43, 0xbb, 0x8b, 0xa6,
        0x1f, 0x03, 0x5a, 0x7d, 0x09, 0x38, 0x25, 0x1f,
        0x5d, 0xd4, 0xcb, 0xfc, 0x96, 0xf5, 0x45, 0x3b,
        0x13, 0x0d, 0x89, 0x0a, 0x1c, 0xdb, 0xae, 0x32,
        0x20, 0x9a, 0x50, 0xee, 0x40, 0x78, 0x36, 0xfd,
        0x12, 0x49, 0x32, 0xf6, 0x9e, 0x7d, 0x49, 0xdc,
        0xad, 0x4f, 0x14, 0xf2, 0x44, 0x40, 0x66, 0xd0,
        0x6b, 0xc4, 0x30, 0xb7, 0x32, 0x3b, 0xa1, 0x22,
        0xf6, 0x22, 0x91, 0x9d, 0xe1, 0x8b, 0x1f, 0xda,
        0xb0, 0xca, 0x99, 0x02
    };
    

To proceed:

    bool dwgReader18::readFileHeader() {
       // [...]
    
        dint32 secPageMapId = buff.getRawLong32();
    
        duint64 secPageMapAddr = buff.getRawLong64()+0x100;
    
        duint32 secMapId = buff.getRawLong32();
    
        //TODO: verify CRC
        for (duint8 i = 0x68; i < 0x6c; ++i)
            byteStr[i] = '\0';
        duint32 crcCalc = buff.crc32(0x00,0,0x6C);
    
        // At this point are parsed the first 256 bytes
    
        if (! fileBuf->setPosition(secPageMapAddr))  // 
            return false;
        duint32 pageType = fileBuf->getRawLong32();
        duint32 decompSize = fileBuf->getRawLong32();
        if (pageType != 0x41630e3b){  // [2]
            return false;
        }
        std::vector<duint8> tmpDecompSec(decompSize);
        parseSysPage(tmpDecompSec.data(), decompSize);
    

Without getting too in-depth into the code here, the important thing to note is that certain types of “pages” are expected at offsets given by our file headers. As shown above at \[2\], a pageType of 0x41630e3b is expected, which corresponds to a SysPage. We now delve into dwgReader18::parseSysPage, who’s arguments are an allocated buffer with its size, which we control:

    //called: Section page map: 0x41630e3b
    void dwgReader18::parseSysPage(duint8 *decompSec, duint32 decompSize){
    
        duint32 compSize = fileBuf->getRawLong32();  //[3]
    
        duint8 hdrData[20];
        fileBuf->moveBitPos(-160);             
        fileBuf->getBytes(hdrData, 20);         
        for (duint8 i= 16; i<20; ++i)
            hdrData[i]=0;
        duint32 calcsH = checksum(0, hdrData, 20);
    
        std::vector<duint8> tmpCompSec(compSize);  //[4]
        fileBuf->getBytes(tmpCompSec.data(), compSize); //[5]
        duint32 calcsD = checksum(calcsH, tmpCompSec.data(), compSize);
    
        dwgCompressor comp;
        comp.decompress18(tmpCompSec.data(), decompSec, compSize, decompSize); // [6]
    }
    

At \[3\] we grab the size of the compressed data, and at \[4\] we allocate a temporary buffer of that size. At \[5\] we populate the buffer with our compressed data from our file, and then at \[6\] we do the decompression. Please note the lack of comparison of the decompSize to the compSize before we continue on into dwgReader18::decompress18():

    void dwgCompressor::decompress18(duint8 *cbuf, duint8 *dbuf, duint32 csize, duint32 dsize){
        bufC = cbuf;
        bufD = dbuf;
        sizeC = csize -2;
        sizeD = dsize;
        sizeC = csize;
    
        duint32 compBytes;
        duint32 compOffset;
        duint32 litCount;
    
        pos=0; //current position in compresed buffer
        rpos=0; //current position in resulting decompresed buffer
        litCount = litLength18();              // [7]
        //copy first lileral lenght
        for (duint32 i=0; i < litCount; ++i) {
            bufD[rpos++] = bufC[pos++];          // [8]
        }
    
        while (pos < csize && (rpos < dsize+1)){//rpos < dsize to prevent crash more robust are needed
            duint8 oc = bufC[pos++]; //next opcode
            if (oc == 0x10){
                compBytes = longCompressionOffset()+ 9;
                compOffset = twoByteOffset(&litCount) + 0x3FFF;
                if (litCount == 0)
                    litCount= litLength18();
            } else if (oc > 0x11 && oc< 0x20){
                compBytes = (oc & 0x0F) + 2;
                compOffset = twoByteOffset(&litCount) + 0x3FFF;
                if (litCount == 0)
                    litCount= litLength18();
                    
                // [...]
            }
            //copy "compresed data", TODO Needed verify out of bounds
            duint32 remaining = sizeD - (litCount+rpos);
            if (remaining < compBytes){
                compBytes = remaining;
            }
            for (duint32 i=0, j= rpos - compOffset -1; i < compBytes; i++) {
                bufD[rpos++] = bufD[j++];
            }
            //copy "uncompresed data", TODO Needed verify out of bounds
            for (duint32 i=0; i < litCount; i++) {
                bufD[rpos++] = bufC[pos++];
            }
        }
    

Needless to say, basically every line in this function can be either an out-of-bounds read or an out-of-bounds write on the heap, but we’re going to keep things short and only look at \[7\] and \[8\] (since the rest is the same anyways). Remember that both the size of our compressed and uncompressed buffers are controlled entirely by the file, and then let us examine the litLength18() function at \[7\]:

    duint32 dwgCompressor::litLength18(){
        duint32 cont=0;
        duint8 ll = bufC[pos++];
        //no literal length, this byte is next opCode
        if (ll > 0x0F) {
            pos--;
            return 0;
        }
    
        if (ll == 0x00) {
            cont = 0x0F;
            ll = bufC[pos++];
            while (ll == 0x00){//repeat until ll != 0x00
                cont +=0xFF;
                ll = bufC[pos++];
            }
        }
        cont +=ll;
        cont +=3; //already sum 3
        return cont;
    }
    

The length returned from this function is also completely arbitrary. So back up to dwgCompressor::decompress18():

    void dwgCompressor::decompress18(duint8 *cbuf, duint8 *dbuf, duint32 csize, duint32 dsize){
        bufC = cbuf;
        bufD = dbuf;
        sizeC = csize -2;
        sizeD = dsize;
        sizeC = csize;
    
        duint32 compBytes;
        duint32 compOffset;
        duint32 litCount;
    
        pos=0; //current position in compresed buffer
        rpos=0; //current position in resulting decompresed buffer
        litCount = litLength18();              // [9]
        //copy first lileral lenght
        for (duint32 i=0; i < litCount; ++i) { // [10]
            bufD[rpos++] = bufC[pos++];          
        }
    

Since there’s no check on the size of the length from \[9\] to \[10\], there’s a trivial out-of-bounds write on the heap, fully controlled by the input file.

**Crash Information**

\==1043701==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62c000007600 at pc 0x7f6d842ee9cb bp 0x7fffea9c2c10 sp 0x7fffea9c2c08 WRITE of size 1 at 0x62c000007600 thread T0 #0 0x7f6d842ee9ca in dwgCompressor::decompress18(unsigned char_, unsigned char_, unsigned int, unsigned int) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgutil.cpp:208:26 #1 0x7f6d842c39b7 in dwgReader18::parseDataPage(dwgSectionInfo) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader18.cpp:168:14 #2 0x7f6d842d0c54 in dwgReader18::readDwgHeader(DRW\_Header&) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader18.cpp:410:16 #3 0x7f6d8432b37b in dwgReader24::readDwgHeader(DRW\_Header&) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader24.cpp:33:29 #4 0x7f6d83da7189 in dwgR::processDwg() /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/libdwgr.cpp:241:19 #5 0x7f6d83da6410 in dwgR::read(DRW\_Interface_, bool) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/libdwgr.cpp:158:20 #6 0x55073c in LLVMFuzzerTestOneInput /root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/./dwg\_harness.cpp:65:9 #7 0x4587e1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const_, unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x4587e1) #8 0x443f52 in fuzzer::RunOneTest(fuzzer::Fuzzer_, char const_, unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x443f52) #9 0x449a06 in fuzzer::FuzzerDriver(int_, char__\*, int (_)(unsigned char const\*, unsigned long)) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x449a06) #10 0x4726c2 in main (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x4726c2) #11 0x7f6d833c10b2 in \_\_libc\_start\_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16 #12 0x41e61d in \_start (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x41e61d)

0x62c000007600 is located 0 bytes to the right of 29696-byte region \[0x62c000000200,0x62c000007600) allocated by thread T0 here: #0 0x54da9d in operator new(unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x54da9d) #1 0x7f6d8423838b in \_\_gnu\_cxx::new\_allocator::allocate(unsigned long, void const\*) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/ext/new\_allocator.h:114:27 #2 0x7f6d842382b8 in std::allocator\_traits<std::allocator >::allocate(std::allocator&, unsigned long) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/bits/alloc\_traits.h:444:20 #3 0x7f6d8423785f in std::\_Vector\_base<unsigned char, std::allocator >::\_M\_allocate(unsigned long) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/bits/stl\_vector.h:343:20 #4 0x7f6d84236d46 in std::vector<unsigned char, std::allocator >::\_M\_default\_append(unsigned long) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/bits/vector.tcc:635:34 #5 0x7f6d84202342 in std::vector<unsigned char, std::allocator >::resize(unsigned long) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/bits/stl\_vector.h:937:4 #6 0x7f6d842c0bc2 in dwgReader18::parseDataPage(dwgSectionInfo) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader18.cpp:111:13 #7 0x7f6d842d0c54 in dwgReader18::readDwgHeader(DRW\_Header&) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader18.cpp:410:16 #8 0x7f6d8432b37b in dwgReader24::readDwgHeader(DRW\_Header&) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader24.cpp:33:29 #9 0x7f6d83da7189 in dwgR::processDwg() /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/libdwgr.cpp:241:19 #10 0x7f6d83da6410 in dwgR::read(DRW\_Interface\*, bool) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/libdwgr.cpp:158:20 #11 0x55073c in LLVMFuzzerTestOneInput /root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/./dwg\_harness.cpp:65:9 #12 0x4587e1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const\*, unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x4587e1) #13 0x443f52 in fuzzer::RunOneTest(fuzzer::Fuzzer\*, char const\*, unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x443f52) #14 0x449a06 in fuzzer::FuzzerDriver(int\*, char\*\*\*, int (\*)(unsigned char const\*, unsigned long)) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x449a06) #15 0x4726c2 in main (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x4726c2) #16 0x7f6d833c10b2 in \_\_libc\_start\_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: heap-buffer-overflow /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgutil.cpp:208:26 in dwgCompressor::decompress18(unsigned char_, unsigned char_, unsigned int, unsigned int) Shadow bytes around the buggy address: 0x0c587fff8e70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c587fff8e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c587fff8e90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c587fff8ea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c587fff8eb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c587fff8ec0:\[fa\]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c587fff8ed0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c587fff8ee0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c587fff8ef0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c587fff8f00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c587fff8f10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc ==1043701==ABORTING

**Timeline**

2021-08-04 - Vendor Disclosure

2021-11-10 - Vendor Patched  
2021-11-17 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2021-21898: TALOS-2021-1349 || Cisco Talos Intelligence Group

**Summary**

A code execution vulnerability exists in the dwgCompressor::decompress18() functionality of LibreCad libdxfrw 2.2.0-rc2-19-ge02f3580. A specially-crafted .dwg file can lead to an out-of-bounds write. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

LibreCad libdxfrw 2.2.0-rc2-19-ge02f3580

**Product URLs**

https://librecad.org/

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer

**Details**

Libdfxfw is an opensource library facilitating the reading and writing of .dxf and .dwg files, the primary vector graphics file formats of CAD software. Libdxfrw is contained in and primarily used by LibreCAD for the aforementioned purposes, but c

Libdxfrw is capable of reading many different versions of .dwg files. The backwards compatibility is quite extensive, and likewise the particulars for each version are quite extensive. For today’s vulnerability, we deal with the `AC1024` version, the AutoCAD .dwg standard from 2010 through 2012. At least for Librecad and libdxfrw, this `AC1024` version oddly ends up hitting the same code as the `AC1018` version, the AutoCAD .dwg standard from 2004 through 2007. Even if a function ends in `18` (e.g. dwgReader18::readFileHeader), this vulnerability is applicable to both versions for libdxfrw.

To start, the `dwgReader24::readFileHeader` function is a good place to begin:

    bool dwgReader24::readFileHeader() {
        DRW_DBG("dwgReader24::readFileHeader\n");
        bool ret = dwgReader18::readFileHeader();
        DRW_DBG("dwgReader24::readFileHeader END\n");
        return ret;
    }
    

Simple and easy, this function immediately calls into `dwgReader18::readFileHeader`, which is a bit of a doozy. The below version of it is with all the `DRW_DBG` logging code removed :

    bool dwgReader18::readFileHeader() {
    
        if (! fileBuf->setPosition(0x80))  // [1]
            return false;
    
        //    genMagicNumber(); DBG("\n"); DBG("\n");
        duint8 byteStr[0x6C];
        int size =0x6C;
        for (int i=0, j=0; i< 0x6C;i++) {
            duint8 ch = fileBuf->getRawChar8(); 
    
            byteStr[i] = DRW_magicNum18[i] ^ ch;
        }
    
       //[ ... ]
    
        dwgBuffer buff(byteStr, 0x6C, &decoder);
    

The first part of this function simply reads file offsets (0x80,0x10C) and then xors them against a hardcoded magic set of bytes:

    static const int DRW_magicNum18[] = {
        0x29, 0x23, 0xbe, 0x84, 0xe1, 0x6c, 0xd6, 0xae,
        0x52, 0x90, 0x49, 0xf1, 0xf1, 0xbb, 0xe9, 0xeb,
        0xb3, 0xa6, 0xdb, 0x3c, 0x87, 0x0c, 0x3e, 0x99,
        0x24, 0x5e, 0x0d, 0x1c, 0x06, 0xb7, 0x47, 0xde,
        0xb3, 0x12, 0x4d, 0xc8, 0x43, 0xbb, 0x8b, 0xa6,
        0x1f, 0x03, 0x5a, 0x7d, 0x09, 0x38, 0x25, 0x1f,
        0x5d, 0xd4, 0xcb, 0xfc, 0x96, 0xf5, 0x45, 0x3b,
        0x13, 0x0d, 0x89, 0x0a, 0x1c, 0xdb, 0xae, 0x32,
        0x20, 0x9a, 0x50, 0xee, 0x40, 0x78, 0x36, 0xfd,
        0x12, 0x49, 0x32, 0xf6, 0x9e, 0x7d, 0x49, 0xdc,
        0xad, 0x4f, 0x14, 0xf2, 0x44, 0x40, 0x66, 0xd0,
        0x6b, 0xc4, 0x30, 0xb7, 0x32, 0x3b, 0xa1, 0x22,
        0xf6, 0x22, 0x91, 0x9d, 0xe1, 0x8b, 0x1f, 0xda,
        0xb0, 0xca, 0x99, 0x02
    };
    

To proceed:

    bool dwgReader18::readFileHeader() {
       // [...]
    
        dint32 secPageMapId = buff.getRawLong32();
    
        duint64 secPageMapAddr = buff.getRawLong64()+0x100;
    
        duint32 secMapId = buff.getRawLong32();
    
        //TODO: verify CRC
        for (duint8 i = 0x68; i < 0x6c; ++i)
            byteStr[i] = '\0';
        duint32 crcCalc = buff.crc32(0x00,0,0x6C);
    
        // At this point are parsed the first 256 bytes
    
        if (! fileBuf->setPosition(secPageMapAddr))  // 
            return false;
        duint32 pageType = fileBuf->getRawLong32();
        duint32 decompSize = fileBuf->getRawLong32();
        if (pageType != 0x41630e3b){  // [2]
            return false;
        }
        std::vector<duint8> tmpDecompSec(decompSize);
        parseSysPage(tmpDecompSec.data(), decompSize);
    

Without getting too in-depth into the code here, the important thing to note is that certain types of “pages” are expected at offsets given by our file headers. As shown above at \[2\], a pageType of 0x41630e3b is expected, which corresponds to a `SysPage`. We now delve into `dwgReader18::parseSysPage`, who’s arguments are an allocated buffer with its size, which we control:

    //called: Section page map: 0x41630e3b
    void dwgReader18::parseSysPage(duint8 *decompSec, duint32 decompSize){
    
        duint32 compSize = fileBuf->getRawLong32();  //[3]
    
        duint8 hdrData[20];
        fileBuf->moveBitPos(-160);             
        fileBuf->getBytes(hdrData, 20);         
        for (duint8 i= 16; i<20; ++i)
            hdrData[i]=0;
        duint32 calcsH = checksum(0, hdrData, 20);
    
        std::vector<duint8> tmpCompSec(compSize);  //[4]
        fileBuf->getBytes(tmpCompSec.data(), compSize); //[5]
        duint32 calcsD = checksum(calcsH, tmpCompSec.data(), compSize);
    
        dwgCompressor comp;
        comp.decompress18(tmpCompSec.data(), decompSec, compSize, decompSize); // [6]
    }
    

At \[3\] we grab the size of the compressed data, and at \[4\] we allocate a temporary buffer of that size. At \[5\] we populate the buffer with our compressed data from our file, and then at \[6\] we do the decompression. Please note the lack of comparison of the `decompSize` to the `compSize` before we continue on into `dwgReader18::decompress18()`:

    void dwgCompressor::decompress18(duint8 *cbuf, duint8 *dbuf, duint32 csize, duint32 dsize){
        bufC = cbuf;
        bufD = dbuf;
        sizeC = csize -2;
        sizeD = dsize;
        sizeC = csize;
    
        duint32 compBytes;
        duint32 compOffset;
        duint32 litCount;
    
        pos=0; //current position in compresed buffer
        rpos=0; //current position in resulting decompresed buffer
        litCount = litLength18();              // [7]
        //copy first lileral lenght
        for (duint32 i=0; i < litCount; ++i) {
            bufD[rpos++] = bufC[pos++];          // [8]
        }
    
        while (pos < csize && (rpos < dsize+1)){//rpos < dsize to prevent crash more robust are needed
            duint8 oc = bufC[pos++]; //next opcode
            if (oc == 0x10){
                compBytes = longCompressionOffset()+ 9;
                compOffset = twoByteOffset(&litCount) + 0x3FFF;
                if (litCount == 0)
                    litCount= litLength18();
            } else if (oc > 0x11 && oc< 0x20){
                compBytes = (oc & 0x0F) + 2;
                compOffset = twoByteOffset(&litCount) + 0x3FFF;
                if (litCount == 0)
                    litCount= litLength18();
                    
                // [...]
            }
            //copy "compresed data", TODO Needed verify out of bounds
            duint32 remaining = sizeD - (litCount+rpos);
            if (remaining < compBytes){
                compBytes = remaining;
            }
            for (duint32 i=0, j= rpos - compOffset -1; i < compBytes; i++) {
                bufD[rpos++] = bufD[j++];
            }
            //copy "uncompresed data", TODO Needed verify out of bounds
            for (duint32 i=0; i < litCount; i++) {
                bufD[rpos++] = bufC[pos++];
            }
        }
    

Needless to say, basically every line in this function can be either an out-of-bounds read or an out-of-bounds write on the heap, but we’re going to keep things short and only look at \[7\] and \[8\] (since the rest is the same anyways). Remember that both the size of our compressed and uncompressed buffers are controlled entirely by the file, and then let us examine the `litLength18()` function at \[7\]:

    duint32 dwgCompressor::litLength18(){
        duint32 cont=0;
        duint8 ll = bufC[pos++];
        //no literal length, this byte is next opCode
        if (ll > 0x0F) {
            pos--;
            return 0;
        }
    
        if (ll == 0x00) {
            cont = 0x0F;
            ll = bufC[pos++];
            while (ll == 0x00){//repeat until ll != 0x00
                cont +=0xFF;
                ll = bufC[pos++];
            }
        }
        cont +=ll;
        cont +=3; //already sum 3
        return cont;
    }
    

The length returned from this function is also completely arbitrary. So back up to `dwgCompressor::decompress18()`:

    void dwgCompressor::decompress18(duint8 *cbuf, duint8 *dbuf, duint32 csize, duint32 dsize){
        bufC = cbuf;
        bufD = dbuf;
        sizeC = csize -2;
        sizeD = dsize;
        sizeC = csize;
    
        duint32 compBytes;
        duint32 compOffset;
        duint32 litCount;
    
        pos=0; //current position in compresed buffer
        rpos=0; //current position in resulting decompresed buffer
        litCount = litLength18();              // [9]
        //copy first lileral lenght
        for (duint32 i=0; i < litCount; ++i) { // [10]
            bufD[rpos++] = bufC[pos++];          
        }
    

Since there’s no check on the size of the length from \[9\] to \[10\], there’s a trivial out-of-bounds write on the heap, fully controlled by the input file.

**Crash Information**

\==1043701==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62c000007600 at pc 0x7f6d842ee9cb bp 0x7fffea9c2c10 sp 0x7fffea9c2c08 WRITE of size 1 at 0x62c000007600 thread T0 #0 0x7f6d842ee9ca in dwgCompressor::decompress18(unsigned char_, unsigned char_, unsigned int, unsigned int) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgutil.cpp:208:26 #1 0x7f6d842c39b7 in dwgReader18::parseDataPage(dwgSectionInfo) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader18.cpp:168:14 #2 0x7f6d842d0c54 in dwgReader18::readDwgHeader(DRW\_Header&) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader18.cpp:410:16 #3 0x7f6d8432b37b in dwgReader24::readDwgHeader(DRW\_Header&) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader24.cpp:33:29 #4 0x7f6d83da7189 in dwgR::processDwg() /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/libdwgr.cpp:241:19 #5 0x7f6d83da6410 in dwgR::read(DRW\_Interface_, bool) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/libdwgr.cpp:158:20 #6 0x55073c in LLVMFuzzerTestOneInput /root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/./dwg\_harness.cpp:65:9 #7 0x4587e1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const_, unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x4587e1) #8 0x443f52 in fuzzer::RunOneTest(fuzzer::Fuzzer_, char const_, unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x443f52) #9 0x449a06 in fuzzer::FuzzerDriver(int_, char__\*, int (_)(unsigned char const\*, unsigned long)) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x449a06) #10 0x4726c2 in main (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x4726c2) #11 0x7f6d833c10b2 in \_\_libc\_start\_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16 #12 0x41e61d in \_start (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x41e61d)

0x62c000007600 is located 0 bytes to the right of 29696-byte region \[0x62c000000200,0x62c000007600) allocated by thread T0 here: #0 0x54da9d in operator new(unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x54da9d) #1 0x7f6d8423838b in \_\_gnu\_cxx::new\_allocator::allocate(unsigned long, void const\*) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/ext/new\_allocator.h:114:27 #2 0x7f6d842382b8 in std::allocator\_traits<std::allocator >::allocate(std::allocator&, unsigned long) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/bits/alloc\_traits.h:444:20 #3 0x7f6d8423785f in std::\_Vector\_base<unsigned char, std::allocator >::\_M\_allocate(unsigned long) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/bits/stl\_vector.h:343:20 #4 0x7f6d84236d46 in std::vector<unsigned char, std::allocator >::\_M\_default\_append(unsigned long) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/bits/vector.tcc:635:34 #5 0x7f6d84202342 in std::vector<unsigned char, std::allocator >::resize(unsigned long) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/bits/stl\_vector.h:937:4 #6 0x7f6d842c0bc2 in dwgReader18::parseDataPage(dwgSectionInfo) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader18.cpp:111:13 #7 0x7f6d842d0c54 in dwgReader18::readDwgHeader(DRW\_Header&) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader18.cpp:410:16 #8 0x7f6d8432b37b in dwgReader24::readDwgHeader(DRW\_Header&) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader24.cpp:33:29 #9 0x7f6d83da7189 in dwgR::processDwg() /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/libdwgr.cpp:241:19 #10 0x7f6d83da6410 in dwgR::read(DRW\_Interface\*, bool) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/libdwgr.cpp:158:20 #11 0x55073c in LLVMFuzzerTestOneInput /root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/./dwg\_harness.cpp:65:9 #12 0x4587e1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const\*, unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x4587e1) #13 0x443f52 in fuzzer::RunOneTest(fuzzer::Fuzzer\*, char const\*, unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x443f52) #14 0x449a06 in fuzzer::FuzzerDriver(int\*, char\*\*\*, int (\*)(unsigned char const\*, unsigned long)) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x449a06) #15 0x4726c2 in main (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x4726c2) #16 0x7f6d833c10b2 in \_\_libc\_start\_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: heap-buffer-overflow /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgutil.cpp:208:26 in dwgCompressor::decompress18(unsigned char_, unsigned char_, unsigned int, unsigned int) Shadow bytes around the buggy address: 0x0c587fff8e70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c587fff8e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c587fff8e90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c587fff8ea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c587fff8eb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c587fff8ec0:\[fa\]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c587fff8ed0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c587fff8ee0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c587fff8ef0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c587fff8f00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c587fff8f10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc ==1043701==ABORTING

**Timeline**

2021-08-04 - Vendor Disclosure

2021-11-10 - Vendor Patched  
2021-11-17 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

A code execution vulnerability exists in the dxfRW::processLType() functionality of LibreCad libdxfrw 2.2.0-rc2-19-ge02f3580. A specially-crafted .dxf file can lead to a use-after-free vulnerability. An attacker can provide a malicious file to trigger this vulnerability.

**Summary**

A code execution vulnerability exists in the dxfRW::processLType() functionality of LibreCad libdxfrw 2.2.0-rc2-19-ge02f3580. A specially-crafted .dxf file can lead to a use-after-free vulnerability. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

LibreCad libdxfrw 2.2.0-rc2-19-ge02f3580

**Product URLs**

https://librecad.org/

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-416 - Use After Free

**Details**

Libdfxfw is an opensource library facilitating the reading and writing of .dxf and .dwg files, the primary vector graphics file formats of CAD software. Libdxfrw is contained in and primarily used by LibreCAD for the aforementioned purposes.

The .dxf file fomat itself is rather simple, consisting solely of groupCode and groupValue pairs, separated by a newline. For example:

    0        // groupCode:  0 => new entity
    SECTION  // groupValue: 'SECTION' => type of the new entity
    2        // groupCode
    HEADER   // groupValue
    9        // groupCode
    $ACADVER // groupValue
    

Each groupCode acts like an opcode, and the groupValue is put to an opcode-specific purpose. See the following for an example .dxf:

    0
    SECTION
    2
    TABLES
    0
    TABLE
    2
    LTYPE
    

We end up processing the data via the following backtrace:

    #0  0x00007f0c9723307b in dxfRW::processLType (this=0x7ffc1037c5b0) at/libdxfrw.cpp:2055
    #1  0x00007f0c9722fcad in dxfRW::processTables (this=0x7ffc1037c5b0) at/libdxfrw.cpp:2010
    #2  0x00007f0c9718e332 in dxfRW::processDxf (this=0x7ffc1037c5b0) at/libdxfrw.cpp:1918
    #3  0x00007f0c9718c79a in dxfRW::read (this=0x7ffc1037c5b0, interface_=?, ext=64) at/libdxfrw.cpp:100
    

So to start, let us examine how LTypes are processed in dxfRW::processLType:

    bool dxfRW::processLType() {
        DRW_DBG("dxfRW::processLType\n");
        int code;
        std::string sectionstr;
        bool reading = false;
        DRW_LType ltype;
        while (reader->readRec(&code)) {     // [1] 
            DRW_DBG(code); DRW_DBG("\n");
            if (code == 0) { // [2]
                if (reading) {
                    ltype.update();
                    ////iface->addLType(ltype);
                }
                sectionstr = reader->getString();  // [3]
                DRW_DBG(sectionstr); DRW_DBG("\n");
                if (sectionstr == "LTYPE") {
                    reading = true;
                    ltype.reset(); 
                } else if (sectionstr == "ENDTAB") {
                    return true;  //found ENDTAB terminate
                }
            } else if (reading) {
                ltype.parseCode(code, reader);  // [4]
            }
        }
    
        return setError(DRW::BAD_READ_TABLES);
    }
    

The readRec(&code) function at \[1\] grabs the groupCode from our input .dxf file, and then based on the LType\-specific opcode, different actions occur. In this case, in order to hit any further code, our opcode must be 0. Assuming this to be true, we hit the branch at \[2\], which causes us to read in the groupValue at \[3\], which must be LTYPE if we want to go any further. Once we’ve set reading to true, we can finally hit the DRW_LTYPE::parseCode(code, reader) function at \[4\], which we now look at:

    void DRW_LType::parseCode(int code, dxfReader *reader){
        switch (code) {
            case 3:
                desc = reader->getUtf8String();
                break;
            case 73:
                size = reader->getInt32();
                path.clear();
                path.reserve(size);
                break;
            case 40:
                length = reader->getDouble();
                break;
            case 49:
                path.push_back(reader->getDouble());
                pathIdx++;
                break;
        /*    case 74:
                haveShape = reader->getInt32();
                break;*/
            default:
                DRW_TableEntry::parseCode(code, reader);  // [5]
                break;
        }
    }
    

As mentioned before, the opcodes become object-specific after a certain point, and this is where all the nonzero opcodes begin. None of these are really useful, so let’s continue into the DRW_TableEntry::parseCode(code, reader); function at \[5\]:

    void DRW_TableEntry::parseCode(int code, dxfReader *reader){
        switch (code) {
        case 5:
            handle = reader->getHandleString();
            break;
        case 330:
            parentHandle = reader->getHandleString();
            break;
        case 2:
            name = reader->getUtf8String();
            break;
        case 70:
            flags = reader->getInt32();
            break;
        case 1000:
        case 1001:
        case 1002:
        case 1003:
        case 1004:
        case 1005:
            extData.push_back(new DRW_Variant(code, reader->getString()));
            break;
        case 1010:
        case 1011:
        case 1012:
        case 1013:
            curr = new DRW_Variant(code, DRW_Coord(reader->getDouble(), 0.0, 0.0)); // [6]
            extData.push_back(curr);
            break;
        case 1020:
        case 1021:
        case 1022:
        case 1023:
            if (curr)
                curr->setCoordY(reader->getDouble());  // uaf here, why?
        case 1030:
        case 1031:
        case 1032:
        case 1033:
            if (curr)
                curr->setCoordZ(reader->getDouble());
            curr=NULL;
            break;
        case 1040:
        case 1041:
        case 1042:
            extData.push_back(new DRW_Variant(code, reader->getDouble()));
            break;
        case 1070:
        case 1071:
            extData.push_back(new DRW_Variant(code, reader->getInt32() ));
            break;
        default:
            break;
        }
    }
    

While lengthy, the main point of this function is to populate the std::vector<DRW_Variant*> extData; member of our current DRW_TableEntry. Another useful facet of this function is at line \[6\], where we assign the DRW_Variant* curr {nullptr}; pointer to the current DRW_Variant that we are dealing with. This is necessary when populating coordinates into the current datapoint, as shown by opcodes 1020-1023 and 1030-1033.

Since we hopefully now have a basic understanding of how the DRW_TableEntry works, let us now examine a particular .dxf file:

    0
    SECTION
    2
    TABLES
    0
    TABLE
    2
    LTYPE
    0
    LTYPE  // [7]
    1013   // [8]
    0
    0      // [9]
    LTYPE
    1023
    

The groupCode,groupValue pair of (0, LTYPE) causes us to enter the DRW_LType::parseCode code path that we just covered by switching on the reading mode. Thus when we get to the opcode at \[8\] (who’s groupValue doesn’t matter), we hit that population of the curr variable mentioned before:

        case 1013:
            curr = new DRW_Variant(code, DRW_Coord(reader->getDouble(), 0.0, 0.0)); 
            extData.push_back(curr);
            break;
    

A curious thing occurs however when we hit the 0x0 opcode at \[9\]:

       bool dxfRW::processLType() {
             // [...] 
             
             if (code == 0) { 
                if (reading) {
                    ltype.update();  
                    ////iface->addLType(ltype);
                }
                sectionstr = reader->getString();  
                DRW_DBG(sectionstr); DRW_DBG("\n");
                if (sectionstr == "LTYPE") { // [10]  
                    reading = true; 
                    ltype.reset();  // [11]
                } else if (sectionstr == "ENDTAB") {
                    return true;  //found ENDTAB terminate
                }
            } else if (reading) {
                ltype.parseCode(code, reader); 
            }
    

If our groupValue for our 0x0 opcode is LTYPE, like in the above example, then we enter the branch at \[10\] and hit the DRW_LType::reset function at \[11\], denoting that we’re entering a new LTYPE object. Let us dive into what this ltype.reset() function does by examining the DRW_LType class definition:

     class DRW_LType : public DRW_TableEntry {
        SETOBJFRIENDS
    public:
        DRW_LType() { reset();}
    
        void reset(){
            tType = DRW::LTYPE;
            desc = "";
            size = 0;
            length = 0.0;
            pathIdx = 0;
            DRW_TableEntry::reset();  // [12]
        }
    
    protected:
        void parseCode(int code, dxfReader *reader);
        bool parseDwg(DRW::Version version, dwgBuffer *buf, duint32 bs=0);
        void update();
    
    public:
        UTF8STRING desc;           /*!< descriptive string, code 3 */
    //    int align;               /*!< align code, always 65 ('A') code 72 */
        int size;                 /*!< element number, code 73 */
        double length;            /*!< total length of pattern, code 40 */
    //    int haveShape;      /*!< complex linetype type, code 74 */
        std::vector<double> path;  /*!< trace, point or space length sequence, code 49 */
    private:
        int pathIdx;
    };
    

Okay, pretty simple, it just calls the parent object’s reset function, DRW_TableEntry::reset() at \[12\]:

    class DRW_TableEntry {
        // [...]
     
        void reset(){
            flags =0;
            for (std::vector<DRW_Variant*>::iterator it=extData.begin(); it!=extData.end(); ++it) 
                delete *it;     // [13]
            extData.clear();
        }
    
    
    public:
        enum DRW::TTYPE tType;     /*!< enum: entity type, code 0 */
        duint32 handle;            /*!< entity identifier, code 5 */
        int parentHandle;          /*!< Soft-pointer ID/handle to owner object, code 330 */
        UTF8STRING name;           /*!< entry name, code 2 */
        int flags;                 /*!< Flags relevant to entry, code 70 */
        std::vector<DRW_Variant*> extData; /*!< FIFO list of extended data, codes 1000 to 1071*/ /// <----- /// [14] 
    
    }
    

So in all, the .reset() function causes a DRW_TableEntry object to walk its own std::vector<DRW_Variant*> extData\[14\] and delete each entry \[13\] . So coming back to our .dxf example:

     0
    SECTION
    2
    TABLES
    0
    TABLE
    2
    LTYPE
    0
    LTYPE  
    1013   // [14]
    0
    0      // [15]
    LTYPE
    1023   // [16]
    0
    

The opcode at \[14\] causes an extData entry to be added to our DRW_TableEntry, and it also assigns the DRW_TableEntry’s curr pointer to that object. After this, the opcode at \[15\] causes each extData entry in our DRW_TableEntry to be freed. We’re left with the opcode at \[16\], 1023, which causes the following code to be executed:

        case 1023:
            if (curr)
                curr->setCoordY(reader->getDouble()); // [17]
    

The reader object reads another double from our input file and passes it to curr->setCoordY() \[17\]. To refresh the reader’s memory, curr points to an entry from our DRW_TableEntry’s std::vector<DRW_Variant*> extData member, and since we called DRW_TableEntry::reset, all of these extData objects have been freed. The more subtle issue here is that the DRW_TableEntry::reset() function never zeros the object’s curr pointer, so we bypass the if (curr) line and cause a UAF, the use being on a function pointer who’s first argument we fully control. This easily leads to code execution.

It’s worth noting that, aside from opcodes 1020-1023, opcodes 1030-1033 can also be used to trigger this UAF.

        case 1033:
            if (curr)
                curr->setCoordZ(reader->getDouble());
            curr=NULL;
            break;
    

**Crash Information**

\==1066896==ERROR: AddressSanitizer: heap-use-after-free on address 0x607000000300 at pc 0x7f88e3d0cb2f bp 0x7ffc5f76f5e0 sp 0x7ffc5f76f5d8 READ of size 4 at 0x607000000300 thread T0 #0 0x7f88e3d0cb2e in DRW\_Variant::setCoordY(double) librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/../drw\_base.h:237:36 #1 0x7f88e3ec227b in DRW\_TableEntry::parseCode(int, dxfReader_) librecad/LibreCAD\_master/libraries/libdxfrw/src/drw\_objects.cpp:61:19 #2 0x7f88e3ed2de1 in DRW\_LType::parseCode(int, dxfReader_) librecad/LibreCAD\_master/libraries/libdxfrw/src/drw\_objects.cpp:445:25 #3 0x7f88e3c90c1a in dxfRW::processLType() librecad/LibreCAD\_master/libraries/libdxfrw/src/libdxfrw.cpp:2060:19 #4 0x7f88e3c8dcac in dxfRW::processTables() librecad/LibreCAD\_master/libraries/libdxfrw/src/libdxfrw.cpp:2010:25 #5 0x7f88e3bec331 in dxfRW::processDxf() librecad/LibreCAD\_master/libraries/libdxfrw/src/libdxfrw.cpp:1918:33 #6 0x7f88e3bea799 in dxfRW::read(DRW\_Interface_, bool) librecad/LibreCAD\_master/libraries/libdxfrw/src/libdxfrw.cpp:100:16 #7 0x550789 in LLVMFuzzerTestOneInput librecad/fuzzing/dxf/./dxf\_harness.cpp:65:9 #8 0x4587e1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const_, unsigned long) (librecad/fuzzing/dxf/dxf\_fuzzer.bin+0x4587e1) #9 0x443f52 in fuzzer::RunOneTest(fuzzer::Fuzzer_, char const_, unsigned long) (librecad/fuzzing/dxf/dxf\_fuzzer.bin+0x443f52) #10 0x449a06 in fuzzer::FuzzerDriver(int_, char__\*, int (_)(unsigned char const\*, unsigned long)) (librecad/fuzzing/dxf/dxf\_fuzzer.bin+0x449a06) #11 0x4726c2 in main (librecad/fuzzing/dxf/dxf\_fuzzer.bin+0x4726c2) #12 0x7f88e324b0b2 in \_\_libc\_start\_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16 #13 0x41e61d in \_start (librecad/fuzzing/dxf/dxf\_fuzzer.bin+0x41e61d)

0x607000000300 is located 64 bytes inside of 72-byte region \[0x6070000002c0,0x607000000308) freed by thread T0 here: #0 0x54e2fd in operator delete(void_) (librecad/fuzzing/dxf/dxf\_fuzzer.bin+0x54e2fd) #1 0x7f88e3cc2c5b in DRW\_TableEntry::reset() librecad/LibreCAD\_master/libraries/libdxfrw/src/drw\_objects.h:96:13 #2 0x7f88e3c958ab in DRW\_LType::reset() librecad/LibreCAD\_master/libraries/libdxfrw/src/drw\_objects.h:250:25 #3 0x7f88e3c9107a in dxfRW::processLType() librecad/LibreCAD\_master/libraries/libdxfrw/src/libdxfrw.cpp:2055:23 #4 0x7f88e3c8dcac in dxfRW::processTables() librecad/LibreCAD\_master/libraries/libdxfrw/src/libdxfrw.cpp:2010:25 #5 0x7f88e3bec331 in dxfRW::processDxf() librecad/LibreCAD\_master/libraries/libdxfrw/src/libdxfrw.cpp:1918:33 #6 0x7f88e3bea799 in dxfRW::read(DRW\_Interface_, bool) librecad/LibreCAD\_master/libraries/libdxfrw/src/libdxfrw.cpp:100:16 #7 0x550789 in LLVMFuzzerTestOneInput librecad/fuzzing/dxf/./dxf\_harness.cpp:65:9 #8 0x4587e1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const_, unsigned long) (librecad/fuzzing/dxf/dxf\_fuzzer.bin+0x4587e1) #9 0x443f52 in fuzzer::RunOneTest(fuzzer::Fuzzer_, char const_, unsigned long) (librecad/fuzzing/dxf/dxf\_fuzzer.bin+0x443f52) #10 0x449a06 in fuzzer::FuzzerDriver(int_, char_\*\*, int (_)(unsigned char const\*, unsigned long)) (librecad/fuzzing/dxf/dxf\_fuzzer.bin+0x449a06) #11 0x4726c2 in main (librecad/fuzzing/dxf/dxf\_fuzzer.bin+0x4726c2) #12 0x7f88e324b0b2 in \_\_libc\_start\_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16

previously allocated by thread T0 here: #0 0x54da9d in operator new(unsigned long) (librecad/fuzzing/dxf/dxf\_fuzzer.bin+0x54da9d) #1 0x7f88e3ec17de in DRW\_TableEntry::parseCode(int, dxfReader_) librecad/LibreCAD\_master/libraries/libdxfrw/src/drw\_objects.cpp:53:16 #2 0x7f88e3ed2de1 in DRW\_LType::parseCode(int, dxfReader_) librecad/LibreCAD\_master/libraries/libdxfrw/src/drw\_objects.cpp:445:25 #3 0x7f88e3c90c1a in dxfRW::processLType() librecad/LibreCAD\_master/libraries/libdxfrw/src/libdxfrw.cpp:2060:19 #4 0x7f88e3c8dcac in dxfRW::processTables() librecad/LibreCAD\_master/libraries/libdxfrw/src/libdxfrw.cpp:2010:25 #5 0x7f88e3bec331 in dxfRW::processDxf() librecad/LibreCAD\_master/libraries/libdxfrw/src/libdxfrw.cpp:1918:33 #6 0x7f88e3bea799 in dxfRW::read(DRW\_Interface_, bool) librecad/LibreCAD\_master/libraries/libdxfrw/src/libdxfrw.cpp:100:16 #7 0x550789 in LLVMFuzzerTestOneInput librecad/fuzzing/dxf/./dxf\_harness.cpp:65:9 #8 0x4587e1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const_, unsigned long) (librecad/fuzzing/dxf/dxf\_fuzzer.bin+0x4587e1) #9 0x443f52 in fuzzer::RunOneTest(fuzzer::Fuzzer_, char const_, unsigned long) (librecad/fuzzing/dxf/dxf\_fuzzer.bin+0x443f52) #10 0x449a06 in fuzzer::FuzzerDriver(int_, char__\*, int (_)(unsigned char const\*, unsigned long)) (librecad/fuzzing/dxf/dxf\_fuzzer.bin+0x449a06) #11 0x4726c2 in main (librecad/fuzzing/dxf/dxf\_fuzzer.bin+0x4726c2) #12 0x7f88e324b0b2 in \_\_libc\_start\_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: heap-use-after-free librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/../drw\_base.h:237:36 in DRW\_Variant::setCoordY(double) Shadow bytes around the buggy address: 0x0c0e7fff8010: fa fa fd fd fd fd fd fd fd fd fd fa fa fa fa fa 0x0c0e7fff8020: fd fd fd fd fd fd fd fd fd fa fa fa fa fa fd fd 0x0c0e7fff8030: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd fd 0x0c0e7fff8040: fd fd fd fd fd fa fa fa fa fa fd fd fd fd fd fd 0x0c0e7fff8050: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fd =>0x0c0e7fff8060:\[fd\]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0e7fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0e7fff8080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0e7fff8090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0e7fff80a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0e7fff80b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb

**Timeline**

2021-08-04 - Vendor Disclosure  
2021-11-10 - Vendor Patched

2021-11-17 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

Tag

#cisco