A stack-based buffer overflow vulnerability exists in the httpd manage_request functionality of Yifan YF325 v1.0_20221108. A specially crafted network request can lead to stack-based buffer overflow. An attacker can send a network request to trigger this vulnerability.

**SUMMARY**

A stack-based buffer overflow vulnerability exists in the httpd manage\_request functionality of Yifan YF325 v1.0\_20221108. A specially crafted network request can lead to stack-based buffer overflow. An attacker can send a network 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.

Yifan YF325 v1.0\_20221108

**PRODUCT URLS**

YF325 - https://yifanwireless.com/entry-level-wifi-router/yf325-series-gprs/3g/4g-wifi-router-with-sim-card-slot.html

**CVSSv3 SCORE**

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

**CWE**

CWE-121 - Stack-based Buffer Overflow

**DETAILS**

The Yifan YF325 is an industrial cellular router. This device is designed for M2M and IOT applications, allowing remote management, offering several VPN services and many other features.

The YF325 router provides a series of APIs. The initial function that parses the request before dispatching it to the right function, based on the requested API, is manage_request:

    void manage_request(void)
    
    {
        [...]
        memset(request_method,0,10000);
        is_equal = wfgets(request_method,10000,(char *)CLIENT_REQUEST_FD);
        [... performs some checks and parse the received data ...]
    
        URL_path = request_method;
        strsep(&URL_path," ");
        [... performs some checks and parse the received data ...]
        URL_path_no_root = URL_path + 1;
        [...]
        is_equal = strncmp(URL_path_no_root,"tmp/sd",6);
        if (is_equal == 0) {                                                                                        [1]
            memset(tmp_buff,0,0x80);
            sprintf(tmp_buff,"/%s",URL_path_no_root);                                                               [2]
            strcpy(URL_path_no_root,tmp_buff);                                                                      [3]
        }
        [...]
    }
    

This function receives and parses the head of the request. The manage_request function navigates through an array of API structures, each of which contain the URL endpoints that the API manages. Once matched with the correct URL, the request will be dispatched to the matching API. However, for some URL paths, there is a “pre-processing” part. For instance, at [1], there is the code block used to manage the requests that starts with /tmp/sd. The variable URL_path_no_root corresponds to the request’s URL path without the first /.

The block of code that manages the request that has a URL path that starts with tmp/sd will, at [2], copy the URL_path_no_root into tmp_buff, a static buffer, to add the previously removed first /. Then at [3] the tmp_buff is copied into URL_path_no_root to complete the process. This process is performed because later on the the URL_path_no_root, for this specific case, is going to be used to fetch a file from the filesystem. This “pre-processing” is performed using using sprintf to add the a slash as first character and store the result in a temporary buffer. Because no checks are performed on the length of the URL path provided, the manage_request function is vulnerable to a buffer overflow that can occur at [2]. This code is reached prior to authentication.

**TIMELINE**

2023-06-28 - Initial Vendor Contact  
2023-07-06 - Vendor Disclosure  
2023-10-11 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2023-34426: TALOS-2023-1766 || Cisco Talos Intelligence Group

A buffer overflow vulnerability exists in the httpd next_page functionality of Yifan YF325 v1.0_20221108. A specially crafted network request can lead to command execution. An attacker can send a network request to trigger this vulnerability.This buffer overflow is in the next_page parameter in the gozila_cgi function.

**SUMMARY**

A buffer overflow vulnerability exists in the httpd next\_page functionality of Yifan YF325 v1.0\_20221108. A specially crafted network request can lead to command execution. An attacker can send a network 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.

Yifan YF325 v1.0\_20221108

**PRODUCT URLS**

YF325 - https://yifanwireless.com/entry-level-wifi-router/yf325-series-gprs/3g/4g-wifi-router-with-sim-card-slot.html

**CVSSv3 SCORE**

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

**CWE**

CWE-121 - Stack-based Buffer Overflow

**DETAILS**

The Yifan YF325 is an industrial cellular router. This device is designed for M2M and IOT applications, allowing remote management, offering several VPN services and many other features.

The YF325 offers several APIs. A few of them offer the possibility of redirecting the client to a specific page after the API is performed. The piece of code that does this is the following:

    [...]
    next_page = (char *)websGetVar(fd,"next_page",0);
    if (next_page != (char *)0x0) {
      strcpy(URL_path,next_page);
    }
    [...]
    

The URL_path is a char pointer to a static buffer that lives in the stack of the first function that receives the HTTP request.

Because the next_page is fetched from the request’s data and then used directly in a strcpy, this pattern is vulnerable to a stack buffer overflow.

**CVE-2023-35055 - gozila\_cgi**

The gozila_cgi function is affected by this vulnerable pattern. Following the API function that calls the gozila_cgi function:

    void cgi_handler(undefined mime,char *URL_path,dword fd,char *query_string)
    
    {
      [...]
    
      if (post == 1) {
        request_data = POST_DATA;
      }
      else {
        request_data = URL_path;
        query_string = strsep(&request_data,"?");
        if (query_string != (char *)0x0) {
          URL_path = query_string;
        }
        init_cgi(request_data);
      }
      request_data_ = request_data;
      need_reboot = (char *)websGetVar(fd,"need_reboot","0");
      need_rebot_value = atoi(need_reboot);
      change_action = (char *)websGetVar(fd,"change_action","");
      if ((change_action != (char *)0x0) && (is_gozila = strcmp(change_action,"gozila_cgi"), is_gozila == 0)) {
        gozila_cgi(fd,0,URL_path);                                                                                  [1]
        goto RET;
      }
      [...]
    }
    

At [1] the gozila_cgi function is called, and eventually the pattern shown above is reached:

    int gozila_cgi(undefined4 fd,undefined param_2,char *URL_path)
    
    {
        [...]
    
        nvram_set("gozila_action","1");
        next_page = '\0';
        submit_button = websGetVar(fd,"submit_button",0);
        submit_type = websGetVar(fd,"submit_type",0);
        godzila_ptr = (godzila_object *)handle_gozila_action(submit_button,submit_type);
        [...]
        next_page = (char *)websGetVar(fd,"next_page",0);
        if (next_page != (char *)0x0) {
          strcpy(URL_path,next_page);
        }
        [...]
    }
    

This vulnerability can be reached without authentication.

**CVE-2023-35056 - cgi\_handler**

The cgi_handler function is the entry point for different APIs. This function is affected by this vulnerable pattern:

    void cgi_handler(undefined mime,char *URL_path,dword fd,char *query_string)
    
    {
      [...]
    
      if (post == 1) {
        request_data = POST_DATA;
      }
      else {
        request_data = URL_path;
        query_string = strsep(&request_data,"?");
        if (query_string != (char *)0x0) {
          URL_path = query_string;
        }
        init_cgi(request_data);
      }
      request_data_ = request_data;
      need_reboot = (char *)websGetVar(fd,"need_reboot","0");
      need_rebot_value = atoi(need_reboot);
      change_action = (char *)websGetVar(fd,"change_action","");
      if ((change_action != (char *)0x0) && (is_gozila = strcmp(change_action,"gozila_cgi"), is_gozila == 0)) {
        gozila_cgi(fd,0,URL_path);
        goto RET;
      }
      [...]
      next_page = (char *)websGetVar(fd,"next_page",0);
      if (next_page != (char *)0x0) {
        strcpy(URL_path,next_page);
      }
      [...]
    }
    

This vulnerability can be reached without authentication.

**TIMELINE**

2023-06-28 - Initial Vendor Contact  
2023-07-06 - Vendor Disclosure  
2023-10-11 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2023-35055: TALOS-2023-1761 || Cisco Talos Intelligence Group

Two heap-based buffer overflow vulnerabilities exist in the httpd manage_post functionality of Yifan YF325 v1.0_20221108. A specially crafted network request can lead to a heap buffer overflow. An attacker can send a network request to trigger these vulnerabilities.This integer overflow result is used as argument for the malloc function.

**SUMMARY**

Two heap-based buffer overflow vulnerabilities exist in the httpd manage\_post functionality of Yifan YF325 v1.0\_20221108. A specially crafted network request can lead to a heap buffer overflow. An attacker can send a network request to trigger these vulnerabilities.

**CONFIRMED VULNERABLE VERSIONS**

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

Yifan YF325 v1.0\_20221108

**PRODUCT URLS**

YF325 - https://yifanwireless.com/entry-level-wifi-router/yf325-series-gprs/3g/4g-wifi-router-with-sim-card-slot.html

**CVSSv3 SCORE**

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

**CWE**

CWE-190 - Integer Overflow or Wraparound

**DETAILS**

The Yifan YF325 is an industrial cellular router. This device is designed for M2M and IOT applications, allowing remote management, offering several VPN services and many other features.

The YF325 router provides a series of APIs. Many of those APIs, which expect to receive a POST request, use the manage_post function to manage the received POST data:

    void manage_post(undefined4 param_1,FILE **fd,int content_length)
    
    {
      [...]
      if (post == 1) {
        if (POST_DATA == (char *)0x0) {
          POST_DATA = (char *)malloc(content_length + 1U);                                                          [1]
        }
        else {
          POST_DATA = (char *)realloc(POST_DATA,content_length + 1U);                                               [2]
        }
        if ((POST_DATA != (char *)0x0) &&
           (data_end = wfread(POST_DATA,1,content_length,fd), [...])) {                                             [3]
          [...]
        }
      }
      [...]
    }
    

The first thing checked, after confirming that the request is actually a POST, is if the POST_DATA global variable has already been initialized. Based on the answer, a malloc or a realloc is called to accommodate the actual request’s Content-Length.

The Content-Length is parsed in the manage_request function:

    void manage_request(void)
    {
      [... receive and parse the request until the start of the headers ...]
      [... peforms some checks and parse on the received data ... ]
      
      while( true ) {
        [... tmp_buff is a buffer just after current_header buffer ...]
        read_len = wfgets(current_header,(int)tmp_buff - (int)current_header,(char *)CLIENT_REQUEST_FD);
        if (((is_equal == 0) || (is_equal = strcmp(current_header,"\n"), is_equal == 0)) ||
            (is_equal = strcmp(current_header,"\r\n"), is_equal == 0)) break;
        is_equal = strncasecmp(current_header,"Authorization:",0xe);
        if (is_equal == 0) {
          [...]
        }
        else {
          is_equal = strncasecmp(current_header,"Referer:",8);
          if (is_equal == 0) {
            [...]
          }
          else {
            is_equal = strncasecmp(current_header,"Host:",5);
            if (is_equal == 0) {
              [...]
            }
            else {
              is_equal = strncasecmp(current_header,"Content-Length:",0xf);                                         [4]
              if (is_equal == 0) {
                content_length_value_ptr = current_header + 0xf;
                [...]
                content_length_empty_space = strspn(content_length_value_ptr," \t");
                content_length = content_length_value_ptr + content_length_empty_space;
                CONTENT_LENGTH = strtoul(content_length,(char **)0x0,0);
        [...]
      while( true ) {                                                                                               [5]
        URL_path_pattern = (code *)API_entry_cursor->URL_path_pattern;
        [... find the correct API entry based on the URL path pattern ...]
      }
      [...]
      post = 0;
      is_equal = strcasecmp(request_method,"post");
      if (is_equal == 0) {
        post = 1;
      }
      if ((code *)API_entry_cursor->manage_request_data != (code *)0x0) {
        (*(code *)API_entry_cursor->manage_request_data)
                  (request_URL+1,CLIENT_REQUEST_FD,CONTENT_LENGTH,boundary);                                        [6]
      }
      [...]
    }
    

The function will eventually parse, at [4], the Content-Length. Then, at [5], based on the URL path, the correct API entry struct to use is located. At [6], the manage_request_data function of the located API entry, if not null, is called. The manage_request_data struct field, for several APIs, corresponds to the manage_post function.

**CVE-2023-35965 - malloc integer overflow**

Many API URL paths will eventually call the manage_post function. At [1] for the malloc function the requested size is content_length + 1. The + 1 is used to ensure there is enough space for the null terminator. Because the content_length value is never checked, it could correspond to the max unsigned integer, so, an integer overflow vulnerability exists at [1] that can lead to a heap buffer overflow at [3].

**CVE-2023-35966 - realloc integer overflow**

Many API URL paths will eventually call the manage_post function. At [2] for the realloc function the requested size is content_length + 1. The + 1 is used to ensure there is enough space for the null terminator. Because the content_length value is never checked, it could correspond to the max unsigned integer, so, an integer overflow vulnerability exists at [2] that can lead to a heap buffer overflow at [3].

**TIMELINE**

2023-06-28 - Initial Vendor Contact  
2023-07-06 - Vendor Disclosure  
2023-10-11 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2023-35965: TALOS-2023-1787 || Cisco Talos Intelligence Group

A stack-based buffer overflow vulnerability exists in the libutils.so nvram_restore functionality of Yifan YF325 v1.0_20221108. A specially crafted network request can lead to a buffer overflow. An attacker can send a network request to trigger this vulnerability.

**SUMMARY**

A stack-based buffer overflow vulnerability exists in the libutils.so nvram\_restore functionality of Yifan YF325 v1.0\_20221108. A specially crafted network request can lead to a buffer overflow. An attacker can send a network 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.

Yifan YF325 v1.0\_20221108

**PRODUCT URLS**

YF325 - https://yifanwireless.com/entry-level-wifi-router/yf325-series-gprs/3g/4g-wifi-router-with-sim-card-slot.html

**CVSSv3 SCORE**

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

**CWE**

CWE-121 - Stack-based Buffer Overflow

**DETAILS**

The Yifan YF325 is an industrial cellular router. This device is designed for M2M and IOT applications, allowing remote management, offering several VPN services and many other features.

The YF325 router provides a series of APIs. The API that manages the nvram.cgi* endpoints uses the httpd’s parse_nvram_file function to manage the incoming data:

    void parse_nvram_file(undefined4 param_1,int fd,size_t content_length)
      {
        [...]
        do {
          if ((int)content_length < 1) break;
          read_size = 0x400;
          if (content_length + 1 < 0x401) {
            read_size = content_length + 1;
          }
          read_bytes = wfgets(temp_buf,read_size,fd);
          if (read_bytes == 0) {
            return;
          }
          current_len = strlen(temp_buf);
          content_length = content_length - current_len;
          is_equal = strncasecmp(temp_buf,"Content-Disposition:",0x14);
        } while ((is_equal != 0) || (pcVar3 = strstr(temp_buf,"name=\"file\""), pcVar3 == (char *)0x0));
        while (0 < (int)content_length) {
          read_bytes = wfgets(temp_buf,0x400,fd);
          if (read_bytes == 0) {
            return;
          }
          current_len = strlen(temp_buf);
          content_length = content_length - current_len;
          is_equal = strcmp(temp_buf,"\n");
          if ((is_equal == 0) || (is_equal = strcmp(temp_buf,"\r\n"), is_equal == 0)) break;
        }
        [...]
        restore_fd = fopen("/tmp/restore.bin","wb");
        [... read the request's uploaded file and write it into the "/tmp/restore.bin" file ...]
        res = nvram_restore("/tmp/restore.bin");
        [...]
        return;
      }   The `nvram_restore` function is defined in the `libutils.so` library:
      
    undefined4 nvram_restore(char *filepath)
    
    {
      [...]
      restore_fd = fopen(filepath,"rb");
      res = 0xffffffff;
      if (restore_fd != (FILE *)0x0) {
        [... calculate file_size ...]
        is_magic = strcmp(MAGIC,NVRAM_MAGIC);
        if (is_magic == 0) {
          nvram_clear();
          data_size = file_size + -0xc;
          elem_idx = 0;
          nvram_open();
          [... parse the number_of_elements ...]
          local_2c = &key_length;
          nvram_ver = (char *)0x0;
          while ((elem_idx < number_of_elements && (0 < data_size))) {                                              [1]
            key_length = 0;
            fread(&key_length,1,1,restore_fd);                                                                      [2]
            memset(nvram_key,0,0x80);
            fread(nvram_key,(size_t)key_length,1,restore_fd);                                                       [3]
            [...]
            fread(temp_byte,1,1,restore_fd);
            value_len = (uint)temp_byte[0];
            fread(temp_byte,1,1,restore_fd);
            value_len = value_len + (uint)temp_byte[0] * 0x100 & 0xffff;
            value_ptr = (char *)malloc(value_len + 1);                                                              [4]
            fread(value_ptr,value_len,1,restore_fd);                                                                [5]
            value_ptr[value_len] = '\0';
            data_size = data_size - 1 - key_length - 2 - value_len;
            is_nvram_ver = strcmp(nvram_key,"nvram_ver");
            [...]
            elem_idx = elem_idx + 1;
          }
          nvram_close();
          [...]
          nvram_commit();
          fclose(restore_fd);
          res = 0;
        }
        else {
          fclose(restore_fd);
          res = 0xfffffffe;
        }
      }
      return res;
    }
    

The nvram_restore function will open the file specified by the filepath argument, parse the nvram variables defined in the file and commit the new set of nvram variables. The nvram-uploaded file contains several entries, which are parsed in the loop at [1]. Each loop iteration parses one entry. Each entry has the following layout in the file:

    |  Key length | Key string (Key length bytes)  |  Value length |  Value string (Value length bytes) |
    

The entry’s key length is read at [2], this value is then used to read key length bytes into the nvram_key static buffer, at [3]. The read string is the nvram key. The nvram value buffer is dynamically allocated at [4] based on the nvram value’s length read, then at [5] value length bytes are read into the just-allocated buffer to read the nvram value.

Because the buffer used at [2] for the nvram key is a buffer of 128 bytes, but the length can have a value of up to 255, there is a stack-based buffer-overflow through the nvram key parsing. This function is reachable prior to authentication.

**TIMELINE**

2023-06-28 - Initial Vendor Contact  
2023-07-06 - Vendor Disclosure  
2023-10-11 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2023-34365: TALOS-2023-1763 || Cisco Talos Intelligence Group

 A vulnerability of authentication bypass has been found on a Zebra Technologies ZTC ZT410-203dpi ZPL printer. This vulnerability allows an attacker that is in the same network as the printer, to change the username and password for the Web Page by sending a specially crafted POST request to the setvarsResults.cgi file. For this vulnerability to be exploitable, the printers protected mode must be disabled.

Description

INCIBE has coordinated the publication of 1 vulnerability that affects Zebra Technologies ZT410-203dpi ZPL printer, which has been discovered by David Cámara Galindo.

This vulnerability has been assigned the following code, CVSS v3.1 base score, CVSS vector string, and CWE vulnerability type:

*   CVE-2023-4957: CVSS v3.1: 5.4 | CVSS: AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N | CWE-288.

Solution

Zebra Printers running Link-OS v6.0 and later have a protected mode that protects the printer from this vulnerability. Activating this mode disables unauthorized changes and locks the current configuration until an administrator authorizes updates. By default, the secure mode is disabled as it is necessary to generate a password first.

  
NOTE: the ZT410 industrial printer was discontinued on Oct 1st, 2020. The service and Support discontinuation dates are in September and December 2025 depending on region. Further information regarding security settings and best practices, including “Protected Mode”, can be found in the references.

CVE-2023-4957: Authentication Bypass Zebra Ztc | INCIBE-CERT

An Insecure Direct Object Reference (IDOR) vulnerability leads to events profiles access in Elenos ETG150 FM transmitter running on version 3.12.

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

CVE-2023-45396: Vulns/(IDOR) leads to events profiles access - Elenos.md at main · strik3r0x1/Vulns

HCL Digital Experience is susceptible to cross site scripting (XSS). One subcomponent is vulnerable to reflected XSS. In reflected XSS, an attacker must induce a victim to click on a crafted URL from some delivery mechanism (email, other web site).


 

 Loading...

Skip to page contentSkip to chat

Skip to page contentSkip to chat

CVE-2023-37538: Knowledge Article View HCL - Customer Support

 Vulnerability of defects introduced in the design process in the screen projection module.Successful exploitation of this vulnerability may affect service availability and integrity.

CVE-2023-44107

Incorrect Authorization in GitHub repository tiann/kernelsu prior to v0.6.9.

CVE-2023-5521

Out-of-bounds Read in GitHub repository gpac/gpac prior to 2.2.2.

Source

CVE