Talos Vulnerability Report

TALOS-2024-2019

Wavlink AC3000 login.cgi Goto_chidx() buffer overflow vulnerability

January 14, 2025
CVE Number

CVE-2024-36290

SUMMARY

A buffer overflow vulnerability exists in the login.cgi Goto_chidx() functionality of Wavlink AC3000 M33A8.V5030.210505. A specially crafted HTTP request can lead to stack-based buffer overflow. An attacker can make an unauthenticated HTTP request to trigger this vulnerability.

CONFIRMED VULNERABLE VERSIONS

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Wavlink AC3000 M33A8.V5030.210505

PRODUCT URLS

Wavlink AC3000 - https://www.wavlink.com/en_us/product/WL-WN533A8.html

CVSSv3 SCORE

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

CWE

CWE-120 - Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)

DETAILS

The Wavlink AC3000 wireless router is predominately one of the most popular gigabit routers in the US, in part due to both its potential wireless and wired speed capabilities and extremely low price point (costing at the time of this writing ~$60 USD). Among the configuration options, it’s also able to act as a standalone wireless gateway, a basic network router, or a wireless repeater.

When interacting with and configuring the Wavlink AC3000 wifi router, as is typical of most wifi routers, an administrator logs in via some web portal and configures appropriate options via the HTTP interface. In the case of this particular router, and in another somewhat common execution pattern, these HTML pages can invoke .cgi binaries due to how the lighttpd server is configured. Since all of these .shtml and .cgi files are located in the web root, anyone with network access to the device doesn’t actually need to log in to the device to interact with these .cgi files, and it usually is the responsibility of the .cgi binary to check if the authentication is completed successfully. On this device, one will see a check_valid_user() function in each individual .cgi binary which will check the session cookie of the HTTP request to see if it’s coming from a validly logged in user.

When dealing with the login.cgi binary however, this login check does not exist, since the login.cgi is normally in charge of doing authentication, as such all login.cgi vulnerabilities are unauthenticated. Regardless of this, the basic code flow is the same, and our HTTP Post page parameter determines the code flow within our .cgi binary:

004010d0              int32_t contlen_int = strtol(getenv("CONTENT_LENGTH"), 0, 0xa)
004010e4              if (contlen_int - 1 u>= 0x1f3)
004014cc                  sprintf(&var_418, "http://%s/login.shtml?login=0", nvram_bufget(0, "lan_ipaddr"))
004014e4                  web_redirect_wholepage(&var_418)
   // [...]
004018ac              else if (strcmp(page_decoded, "Goto_chidx") == 0)
00401948                 Goto_chidx(inpbuf: malloc_contlen)

It’s worth noting that our Content-Length must be less than 0x1f3, but assuming so, if we provide page=Goto_chidx, we appropriately enter the Goto_chidx function and our provided POST data is further parsed therein:

004044c8  int32_t Goto_chidx(char* inpbuf)
0040450c      int32_t wlanIdxNum_strdup = strdup(web_get("wlanIdxNum", inpbuf, 0))
00404544      int32_t wlanUrl_strdup = strdup(web_get("wlanUrl", inpbuf, 0))       // [1]
0040454c      int32_t wlanurl = wlanUrl_strdup
00404558      int32_t wlanidx = 0
00404554      if (wlanIdxNum_strdup != 0)
00404570          wlanurl = wlanUrl_strdup
00404574          wlanidx = atoi(wlanIdxNum_strdup)
00404584      void var_90
00404584      sprintf(&var_90, "%s?wlanidx=%d", wlanurl, wlanidx)  // [2]
004045ac      if (access("/tmp/web_log", 0) == 0)
004045e0          int32_t $v0_2 = fopen("/dev/console", &data_4072c0)
004045ec          if ($v0_2 != 0)
00404620              fprintf($v0_2, "%s:%s:%d:%s\n", "login.c", "Goto_chidx", 0x22b, &var_90, 0x429d20)
00404638              fclose($v0_2)
004045cc      return web_redirect(&var_90)

Without too much examination we can clearly see the wlanUrl parameter being read in without any length checking and then copied to the stack to with sprintf at [2]. Since we can easily provide a buffer of at least 0x90 bytes, we can overflow the return address on the stack, resulting in code execution.

Crash Information

Thread 2.1 "login.cgi" hit Breakpoint 4, 0x00404584 in Goto_chidx ()
(gdb) x/2i $p
   0x0: Cannot access memory at address 0x0
(gdb) Quit
(gdb) x/2i $pc
=> 0x404584 <Goto_chidx+188>:   jalr    t9
   0x404588 <Goto_chidx+192>:   addiu   a1,a1,30628
(gdb) x/1s a2
No symbol "a2" in current context.
(gdb) x/1s $a2
0x7ba0c8:       'A' <repeats 144 times>
(gdb) bt
#0  0x00404584 in Goto_chidx ()
#1  0x0040456c in Goto_chidx ()
Backtrace stopped: frame did not save the PC
(gdb) nexti
0x0040458c in Goto_chidx ()
(gdb) bt
#0  0x0040458c in Goto_chidx ()
#1  0x0040458c in Goto_chidx ()
Backtrace stopped: frame did not save the PC
(gdb) x/100wx $sp
0x7fdcc058:     0x77819750      0x7781ea50      0x007ba0c8      0x00000000
0x7fdcc068:     0xffffffff      0x77a2a000      0x00429d20      0x00000001
0x7fdcc078:     0x41414141      0x41414141      0x41414141      0x41414141
0x7fdcc088:     0x41414141      0x41414141      0x41414141      0x41414141
0x7fdcc098:     0x41414141      0x41414141      0x41414141      0x41414141
0x7fdcc0a8:     0x41414141      0x41414141      0x41414141      0x41414141
0x7fdcc0b8:     0x41414141      0x41414141      0x41414141      0x41414141
0x7fdcc0c8:     0x41414141      0x41414141      0x41414141      0x41414141
0x7fdcc0d8:     0x41414141      0x41414141      0x41414141      0x41414141
0x7fdcc0e8:     0x41414141      0x41414141      0x41414141      0x41414141
0x7fdcc0f8:     0x41414141      0x41414141      0x41414141      0x41414141
0x7fdcc108:     0x616c773f      0x7864696e      0x0000303d      0x00000000
0x7fdcc118:     0x00000000      0x00000000      0x00429d20      0x00000000
0x7fdcc128:     0x00000000      0x00000000      0x00000000      0x00000000
0x7fdcc138:     0x00000000      0x00000000      0x00000000      0x00000000
0x7fdcc148:     0x00000000      0x00000000      0x00000000      0x00000000
0x7fdcc158:     0x00000000      0x00000000      0x00000000      0x00000000
0x7fdcc168:     0x00000000      0x00000000      0x00000000      0x00000000
0x7fdcc178:     0x00000000      0x00000000      0x00000000      0x00000000
0x7fdcc188:     0x00000000      0x00000000      0x00000000      0x00000000
0x7fdcc198:     0x00000000      0x00000000      0x00000000      0x00000000
0x7fdcc1a8:     0x00000000      0x00000000      0x00000000      0x00000000
0x7fdcc1b8:     0x00000000      0x00000000      0x00000000      0x00000000
0x7fdcc1c8:     0x00000000      0x00000000      0x00000000      0x00000000
0x7fdcc1d8:     0x00000000      0x00000000      0x00000000      0x00000000
(gdb) c
Continuing.

Thread 2.1 "login.cgi" received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
TIMELINE

2024-07-25 - Initial Vendor Contact
2024-07-29 - Requesting reply from vendor
2024-07-30 - Vendor confirms receipt
2024-07-30 - Vendor Disclosure
2024-07-30 - Vendor confirms receipt
2024-09-02 - Status update request sent
2024-10-15 - Status update request. Upcoming expiration date announced.
2024-10-22 - Vendor replies product has been discontinued, but patches are being worked on
2024-11-04 - Status update request for patch release dates
2024-11-12 TALOS advisory release date announced
2025-01-14 - Public Release

Credit

Discovered by Lilith >_> of Cisco Talos.