Hunting for Unauthenticated n-days in Asus Routers

TL;DR TL;博士

After reading online the details of a few published critical CVEs affecting ASUS routers, we decided to analyze the vulnerable firmware and possibly write an n-day exploit. While we identified the vulnerable piece of code and successfully wrote an exploit to gain RCE, we also discovered that in real-world devices, the “Unauthenticated Remote” property of the reported vulnerability doesn’t hold true, depending on the current configuration of the device.
在在线阅读了一些影响华硕路由器的已发布关键 CVE 的详细信息后，我们决定分析易受攻击的固件，并可能编写一个 n 天漏洞。虽然我们识别了易受攻击的代码段并成功编写了漏洞以获取 RCE，但我们还发现，在实际设备中，报告漏洞的“未经身份验证的远程”属性不成立，具体取决于设备的当前配置。

Intro 介绍

Last year was a great year for IoT and router security. A lot of devices got pwned and a lot of CVEs were released. Since @suidpit and I love doing research by reversing IoT stuff, and most of those CVEs didn’t have much public details or Proof-of-Concepts yet, we got the chance to apply the CVE North Stars approach by clearbluejar.
去年是物联网和路由器安全的伟大一年。很多设备被破坏了，很多CVE被释放了。由于@suidpit和我喜欢通过逆转物联网的东西来做研究，而且大多数CVE还没有太多的公开细节或概念验证，我们有机会应用clearbluejar的CVE北极星方法。

In particular, we selected the following CVEs affecting various Asus SOHO routers:
具体而言，我们选择了以下影响各种华硕SOHO路由器的CVE：

• CVE-2023-39238
• CVE-2023-39239
• CVE-2023-39240

The claims in the CVEs descriptions were pretty bold, but we recalled some CVEs published months before on the same devices (eg. CVE-2023-35086) that described other format string in the same exact scenario:
CVE 描述中的声明非常大胆，但我们回顾了几个月前在同一设备上发布的一些 CVE（例如。CVE-2023-35086），描述了相同场景中的其他格式字符串：

“An unauthenticated remote attacker can exploit this vulnerability without privilege to perform remote arbitrary code execution”
“未经身份验证的远程攻击者无需权限即可利用此漏洞执行远程任意代码”

Take careful note of those claims cause they will be the base of all our assumptions from now on!
请仔细注意这些说法，因为从现在开始，它们将成为我们所有假设的基础！

From the details of the CVEs we can already infer some interesting information, such as the affected devices and versions. The following firmware versions contain patches for each device:
从CVE的详细信息中，我们已经可以推断出一些有趣的信息，例如受影响的设备和版本。以下固件版本包含每个设备的补丁：

• Asus RT-AX55: 3.0.0.4.386_51948 or later
  Asus RT-AX55：3.0.0.4.386_51948 或更高版本
• Asus RT-AX56U_V2: 3.0.0.4.386_51948 or later
  Asus RT-AX56U_V2：3.0.0.4.386_51948 或更高版本
• Asus RT-AC86U: 3.0.0.4.386_51915 or later
  华硕 RT-AC86U：3.0.0.4.386_51915 或更高版本

Also, we can learn that the vulnerability is supposedly a format string, and that the affected modules are set_iperf3_cli.cgi, set_iperf3_srv.cgi, and apply.cgi.
此外，我们可以了解到该漏洞应该是一个格式字符串，并且受影响的模块是 set_iperf3_cli.cgi 、 set_iperf3_srv.cgi 和 apply.cgi 。

Since we didn’t have any experience with Asus devices, we started by downloading the vulnerable and fixed firmware versions from the vendor’s website.
由于我们没有任何使用华硕设备的经验，因此我们首先从供应商的网站下载易受攻击和修复的固件版本。

Patch Diffing with BinDiff
使用 BinDiff 进行补丁比较

Once we got hold of the firmware, we proceeded by extracting them using Unblob.
一旦我们掌握了固件，我们就继续使用 Unblob 提取它们。

By doing a quick find/ripgrep search we figured out that the affected modules are not CGI files as one would expect, but they are compiled functions handled inside the /usr/sbin/httpd binary.
通过快速 find / ripgrep 搜索，我们发现受影响的模块不是人们所期望的CGI文件，而是在 /usr/sbin/httpd 二进制文件中处理的编译函数。

We then loaded the new and the old httpd binary inside of Ghidra, analyzed them and exported the relevant information with BinDiff’s BinExport to perform a patch diff.
然后，我们在 Ghidra 中加载了新的和旧的 httpd 二进制文件，对其进行了分析，并使用 BinDiff 的 BinExport 导出了相关信息以执行补丁差异。

A patch diff compares a vulnerable version of a binary with a patched one. The intent is to highlight the changes, helping to discover new, missing, and interesting functionality across various versions of a binary.
补丁差异将二进制文件的易受攻击版本与已修补的二进制文件进行比较。其目的是突出显示这些更改，帮助发现二进制文件的各种版本中新的、缺失的和有趣的功能。

Patch diffing the httpd binary highlights some changes, but none turned out to be interesting to our purpose. In particular, if we take a look at the handlers of the vulnerable CGI modules, we can see that they were not changed at all.
对 httpd 二进制文件进行补丁比较突出显示了一些变化，但没有一个对我们的目的感兴趣。特别是，如果我们看一下易受攻击的 CGI 模块的处理程序，我们可以看到它们根本没有改变。

Interestingly, all of them shared a common pattern. The input of the notify_rc function was not fixed and was instead coming from the user-controlled JSON request. :money_with_wings:
有趣的是，他们都有一个共同的模式。该 notify_rc 函数的输入不是固定的，而是来自用户控制的 JSON 请求。：money_with_wings：

The notify_rc function is defined in /usr/lib/libshared.so: this explains why diffing the httpd binary was ineffective.
该 notify_rc 函数定义在 /usr/lib/libshared.so ： 中，这解释了为什么差异 httpd 二进制是无效的。

Diffing libshared.so resulted in a nice discovery: in the first few lines of the notify_rc function, a call to a new function named validate_rc_service was added. At this point we were pretty much confident that this function was the one responsible to patch the format string vulnerability.
diffing libshared.so 带来了一个很好的发现：在 notify_rc 函数的前几行中，添加了对一个名为的新 validate_rc_service 函数的调用。在这一点上，我们非常有信心这个函数是负责修补格式字符串漏洞的函数。

The validate_rc_service function performs a syntax check on the rc_service JSON field. The Ghidra decompiled code is not trivial to read: basically, the function returns 1 if the rc_service string contains only alphanumeric, whitespace, or the _ and ; characters, while returns 0 otherwise.
该 validate_rc_service 函数对 rc_service JSON 字段执行语法检查。Ghidra 反编译代码阅读起来并不容易：基本上，如果 rc_service 字符串仅包含字母数字、空格或 _ and ; 字符，则函数返回 1，否则返回 0。

Apparently, in our vulnerable firmware, we can exploit the format string vulnerability by controlling what ends up inside the rc_service field. We didn’t have a device to confirm this yet, but we didn’t want to spend time and money in case this was a dead-end. Let’s emulate!
显然，在我们易受攻击的固件中，我们可以通过控制 rc_service 最终进入字段的内容来利用格式字符串漏洞。我们还没有设备来确认这一点，但我们不想花费时间和金钱，以防万一这是一个死胡同。让我们效仿吧！

Enter the Dragon, Emulating with Qiling
进入龙，模仿麒麟

If you know us, we bet you know that we love Qiling, so our first thought was “What if we try to emulate the firmware with Qiling and reproduce the vulnerability there?”.
如果你了解我们，我们敢打赌你知道我们喜欢麒麟，所以我们的第一个想法是“如果我们尝试用麒麟模拟固件并在那里重现漏洞会怎样？

Starting from a Qiling skeleton project, sadly httpd crashes and reports various errors.
从一个麒麟骨架项目开始，可悲的是 httpd 崩溃并报告了各种错误。

In particular, the Asus devices use an NVRAM peripheral to store many configurations. The folks at firmadyne developed a library to emulate this behavior, but we couldn’t make it work so we decided to re-implement it inside of our Qiling script.
特别是，华硕设备使用 NVRAM 外设来存储许多配置。firmadyne 的人开发了一个库来模拟这种行为，但我们无法让它工作，所以我们决定在我们的麒麟脚本中重新实现它。

The script creates a structure in the heap and then hijacks all the functions used by httpd to read/write the NVRAM redirecting the to the heap structure.
该脚本在堆中创建一个结构，然后劫持用于 httpd 读取/写入 NVRAM 的所有函数，从而将 NVRAM 重定向到堆结构。

After that we only had to fix some minor syscalls’ implementation and hooks, and voilà! We could load the emulated router web interface from our browsers.
在那之后，我们只需要修复一些小的系统调用的实现和钩子，瞧！我们可以从浏览器加载模拟的路由器 Web 界面。

In the meantime we reversed the do_set_iperf3_srv_cgi/do_set_iperf3_cli_cgi functions to understand what kind of input should we send along the format string.
同时，我们反转 do_set_iperf3_srv_cgi 了 / do_set_iperf3_cli_cgi 函数，以了解我们应该沿格式字符串发送什么样的输入。

Turns out the following JSON is all you need to exploit the set_iperf3_srv.cgi endpoint:
事实证明，以下 JSON 是利用 set_iperf3_srv.cgi 端点所需的全部内容：

1
2
3
4

{
    'iperf3_svr_port': '8888',
    'rc_service': '%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p'
}

And we were welcomed with this output in the Qiling console:
我们在麒麟控制台中看到了这样的输出：

At this point, the format string vulnerability was confirmed, and we knew how to trigger it via firmware emulation with Qiling. Moreover, we knew that the fix introduced a call to validate_rc_message in the notify_rc function exported by the libshared.so shared library. With the goal of writing a working n-day for a real device, we purchased one of the target devices (Asus RT-AX55), and started analyzing the vulnerability to understand the root cause and how to control it.
至此，格式字符串漏洞得到确认，我们知道如何通过麒麟固件仿真来触发它。此外，我们知道该修复程序在 libshared.so 共享库导出的 notify_rc 函数中引入了对的 validate_rc_message 调用。为了为真实设备编写工作 n 天，我们购买了其中一台目标设备（华硕 RT-AX55），并开始分析漏洞以了解根本原因以及如何控制它。

Root Cause Analysis 根本原因分析

Since the fix was added to the notify_rc function, we started by reverse engineering the assembly of that function in the old, vulnerable version. Here follows a snippet of pseudocode from that function:
由于修复程序已添加到函数中 notify_rc ，因此我们首先在旧的易受攻击的版本中对该函数的汇编进行逆向工程。下面是来自该函数的伪代码片段：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

int notify_rc(char *message)

{
    // ...
    pid = getpid();
    psname(pid,proc_name,0x10);
    pid = getpid();
    cprintf("<rc_service> [i:%s] %d:notify_rc %s\n",proc_name,pid,message);
    pid = getpid();
    logmessage_normal("rc_service","%s %d:notify_rc %s",proc_name,pid,message);
    // ...
}

The function seems responsible for logging messages coming from various places through a single, centralized output sink.
该函数似乎负责通过单个集中式输出接收器记录来自不同位置的消息。

The logmessage_normal function is part of the same library and its code is quite simple to reverse engineer:
该 logmessage_normal 函数是同一库的一部分，其代码的逆向工程非常简单：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

void logmessage_normal(char *logname, char *fmt, ...)

{
  char buf [512];
  va_list args;
  va_start(args, fmt);

  vsnprintf(buf,0x200,fmt_string,args);
  openlog(logname,0,0);
  syslog(0,buf); // buf can be controlled by the user!

  closelog();
  va_end(args);
  return;
}

While Ghidra seems unable to recognize ✨automagically✨ the variable arguments list, the function is a wrapper around syslog, and it takes care of opening the chosen log, sending the message and finally closing it.
虽然 Ghidra 似乎无法自动✨识别✨变量参数列表，但该函数是一个包装 syslog 器，它负责打开所选日志、发送消息并最终关闭它。

The vulnerability lies in this function, precisely in the usage of the syslog function with a string that can be controller by the attacker. To understand why, let us inspect the signature of it from the libc manual:
漏洞在于此函数，恰恰在于将 syslog 该函数与可由攻击者控制的字符串一起使用。为了理解原因，让我们从 libc 手册中检查一下它的签名：

void syslog(int priority, const char *format, ...);

According to its signature, syslog expects a list of arguments that resembles those of the *printf family. A quick search shows that, in fact, the function is a known sink for format string vulnerabilities.
根据其签名， syslog 期望有一份类似于 *printf 家庭的论点清单。快速搜索显示，实际上，该函数是格式字符串漏洞的已知接收器。

Exploitation – Living Off The Land Process
剥削 – 以土地为生的过程

Format string vulnerabilities are quite useful for attackers, and they usually provide arbitrary read/write primitives. In this scenario, since the output is logged to a system log that is only visible to administrators, we assume an unauthenticated remote attacker should not be able to read the log, thus losing the “read” primitive of the exploit.
格式字符串漏洞对攻击者非常有用，它们通常提供任意读/写基元。在这种情况下，由于输出被记录到仅对管理员可见的系统日志中，因此我们假设未经身份验证的远程攻击者应该无法读取日志，从而丢失漏洞利用的“读取”原语。

ASLR is enabled on the router’s OS, and the mitigation implemented at compile-time for the binary are printed below:
ASLR 在路由器的操作系统上启用，并且在编译时为二进制文件实现的缓解措施如下所示：

Arch:     arm-32-little
RELRO:    Partial RELRO
Stack:    No canary found
NX:       NX enabled
PIE:      No PIE (0x10000)

According to this scenario, a typical way of developing an exploit would consist in finding a good target for a GOT Overwrite, trying to find a function that accepts input controlled by the user and hijacking it to system.
根据这种情况，开发漏洞利用的典型方法包括为 GOT Overwrite 找到一个好的目标，尝试找到一个接受用户控制的输入并将其劫持到 system .

Nevertheless, in pure Living Off The Land fashion, we spent some time looking for another approach that wouldn’t corrupt the process internals and would instead leverage the logic already implemented in the binary to obtain something good (namely, a shell).
尽管如此，在纯粹的 Living Off The Land 方式中，我们花了一些时间寻找另一种方法，它不会破坏流程内部，而是利用二进制文件中已经实现的逻辑来获得一些好东西（即 shell）。

One of the first things to look for in the binary was a place where the system function was called, hoping to find good injection points to direct our powerful write primitive.
在二进制文件中首先要寻找的一件事是调用 system 函数的位置，希望找到好的注入点来指导我们强大的写入原语。

Among the multiple results of this search, one snippet of code looked worth more investigation:
在这次搜索的多个结果中，有一段代码看起来值得进一步研究：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

void sys_script(char *script)
{
  int cmp;
  char *pcVar1;
  char buf [64];
  char *cmd;
  undefined4 local_10c;

  snprintf(buf,0x40,"/tmp/%s",script);
  cmp = strcmp(script,"syscmd.sh");
  if (cmp == 0) {
    if (SystemCmd[0] != '\0') {
      snprintf((char *)&cmd,256,
               "%s > /tmp/syscmd.log 2>&1 && echo \'XU6J03M6\' >> /tmp/syscmd.log &\n",SystemCmd);
      system((char *)&cmd);
      strlcpy(SystemCmd,&DAT_0007e451,0x80);
      return;
    }
    f_write_string("/tmp/syscmd.log",&DAT_0007e451,0);
    return;
  }
  // ...
}

Let’s briefly comment this code to understand the important points:
让我们简要注释一下这段代码，以了解要点：

• SystemCmd is a global variable which holds a string.
  SystemCmd 是保存字符串的全局变量。
• sys_script, when invoked with the syscmd.s argument, will pass whatever command is present in SystemCmd to the system function, and then it will zero out the global variable again.
  sys_script ，当与 syscmd.s 参数一起调用时，会将存在的任何命令传递 SystemCmd 给 system 函数，然后它将再次将全局变量清零。

This seems a good target for the exploit, provided we can, as attackers:
这似乎是一个很好的攻击目标，前提是我们可以，作为攻击者：

1. Overwrite the SystemCmd content.
   覆盖 SystemCmd 内容。
2. Trigger the sys_script("syscmd.sh") function.
   触发该 sys_script("syscmd.sh") 功能。

Point 1 is granted by the format string vulnerability: since the binary is not position-independent, the address of the SystemCmd global variable is hardcoded in the binary, so we do not need leaks to write to it. In our vulnerable firmware, the offset for the SystemCmd global var is 0x0f3ecc.
第 1 点是由格式字符串漏洞授予的：由于二进制文件与位置无关， SystemCmd 因此全局变量的地址在二进制文件中是硬编码的，因此我们不需要泄漏来写入它。在我们易受攻击的 SystemCmd 固件中，全局 var 的偏移量为 0x0f3ecc 。

Regarding point 2, some endpoints in the web UI are used to legitimately execute commands through the sys_script function. Those endpoints will call the following function named ej_dump whenever a GET request is performed:
关于第 2 点，Web UI 中的某些端点用于通过 sys_script 函数合法地执行命令。每当执行 GET 请求时，这些终结点将调用名为以下函数 ej_dump 的函数：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

int ej_dump(int eid,FILE *wp,int argc,char **argv)

{
  // ...
  ret = ejArgs(argc,argv,"%s %s",&file,&script);
  if (ret < 2) {
    fputs("Insufficient args\n",wp);
    return -1;
  }
  ret = strcmp(script,"syscmd.sh");
  if (ret == 0) {
    sys_script(script);
  }
  // ...
}

So once the SystemCmd global variable is overwritten, simply visiting Main_Analysis_Content.asp or Main_Netstat_Content.asp will trigger our exploit.
因此， SystemCmd 一旦全局变量被覆盖，只需访问 Main_Analysis_Content.asp 或 Main_Netstat_Content.asp 将触发我们的漏洞利用。

A Shell for Your Thoughts
一个你思想的外壳

We will spare you a format string exploitation 101, just remember that with %n you can write the number of characters written so far at the address pointed by its offset.
我们将为您节省格式字符串开发 101，请记住，您可以使用 %n 它来写到目前为止在其偏移量所指向的地址上写入的字符数。

It turned out we had a few constraints, some of them typical of format string exploits, while others specific to our scenario.
事实证明，我们有一些限制，其中一些是典型的格式字符串漏洞，而另一些则特定于我们的方案。

The first problem is that the payload must be sent inside a JSON object, so we need to avoid “breaking” the JSON body, otherwise the parser will raise an error. Luckily, we can use a combination of raw bytes inserted into the body (accepted by the parser), double-encoding (%25 instead of % to inject the format specifiers) and UTF-encode the nullbyte terminating the address (\u0000).
第一个问题是有效负载必须在 JSON 对象内部发送，因此我们需要避免“破坏”JSON 正文，否则解析器会引发错误。幸运的是，我们可以使用插入到正文中的原始字节（被解析器接受）、双重编码（ %25 而不是 % 注入格式说明符）和 UTF 编码终止地址的 nullbyte （ \u0000 ）的组合。

The second one is that, after being decoded, our payload is stored in a C string so null-bytes will terminate it early. This means we can only have one null-byte and it must be at the end of our format string.
第二个是，在被解码后，我们的有效负载存储在一个 C 字符串中，因此 null 字节会提前终止它。这意味着我们只能有一个空字节，并且它必须位于格式字符串的末尾。

The third one is that there is a limit on the length of the format string. We can overcome this by writing few bytes at a time with the %hn format.
第三个是格式字符串的长度有限制。我们可以通过一次写入几个字节来克服这个问题。 %hn

The fourth one (yes, more problems) is that in the format string there is a variable number of characters before our input, so this will mess with the number of characters that %hn will count and subsequently write at our target address. This is because the logmessage_normal function is called with the process name (either httpd or httpsd) and the pid (from 1 to 5 characters) as arguments.
第四个（是的，更多问题）是，在格式字符串中，在我们的输入之前有一个可变数量的字符，因此这将扰乱 %hn 将计数并随后写入我们的目标地址的字符数。这是因为调用 logmessage_normal 函数时，进程名称（或 httpd httpsd ）和 pid（1 到 5 个字符）作为参数。

Finally, we had our payload ready, everything was polished out perfectly, time to perform the exploit and gain a shell on our device…
最后，我们准备好了有效载荷，一切都完美地打磨好了，是时候执行漏洞利用并在我们的设备上获得外壳了……

Wait, WAT??? 等等，WAT???

To Be or Not To Be Authenticated
认证与否认证

Sending our payload without any cookie results into a redirect to the login page!
在没有任何cookie的情况下发送我们的有效负载会导致重定向到登录页面！

At this point we were completely in shock. The CVEs report “an unauthenticated remote attacker” and our exploit against the Qiling emulator was working fine without any authentication. What went wrong?
在这一点上，我们完全震惊了。CVE 报告“未经身份验证的远程攻击者”，我们对麒麟模拟器的攻击在没有任何身份验证的情况下工作正常。哪里出了问题？

While emulating with Qiling before purchasing the real device, we downloaded a dump of the NVRAM state from the internet. If the httpd process loaded keys that were not present in the dump, we automatically set them to empty strings and some were manually adjusted in case of explicit crash/Segfault.
在购买真实设备之前，我们用麒麟进行仿真时，从互联网上下载了NVRAM状态的转储。如果 httpd 进程加载了转储中不存在的键，我们会自动将它们设置为空字符串，并在显式崩溃/Segfault 的情况下手动调整一些键。

It turns out that an important key named x_Setting determines if the router is configured or not. Based on this, access to most of the CGI endpoints is enabled or disabled. The NVRAM state we used in Qiling contained the x_Setting key set to 0, while our real world device (regularly configured) had it set to 1.
事实证明，一个名为 x_Setting 的重要键决定了路由器是否已配置。基于此，启用或禁用对大多数 CGI 端点的访问。我们在麒麟中使用的 NVRAM 状态包含 x_Setting 设置为 0 的密钥，而我们的实际设备（常规配置）将其设置为 1。

But wait, there is more!
但是等等，还有更多！

We researched on the previously reported format string CVEs affecting the other endpoints, to test them against our setup. We found exploits online setting the Referer and Origin headers to the target host, while others work by sending plain GET requests instead of POST ones with a JSON body. Finally, to reproduce as accurately as possible their setup we even emulated other devices’ firmware (eg. the Asus RT-AX86U one).
我们研究了之前报告的影响其他端点的格式字符串 CVE，以根据我们的设置对其进行测试。我们发现在线漏洞利用将 Referer 和 Origin 标头设置为目标主机，而其他漏洞则通过发送普通 GET 请求而不是带有 JSON 正文的 POST 请求来工作。最后，为了尽可能准确地再现他们的设置，我们甚至模拟了其他设备的固件（例如华硕RT-AX86U的固件）。

None of them worked against an environment that had x_Setting=1 in the NVRAM.
它们都不适用于 NVRAM 中的环境 x_Setting=1 。

And you know what? If the router is not configured, the WAN interface is not exposed remotely, making it unaccessible for attackers.
你知道吗？如果未配置路由器，则不会远程公开 WAN 接口，从而使攻击者无法访问它。

Conclusions 结论

This research left a bitter taste in our mouths.
这项研究在我们的嘴里留下了苦涩的味道。

At this point the chances are:
在这一点上，机会是：

1. There is an extra authentication bypass vulnerability that is still not fixed 👀 and thus it does not appear in the diffs.
   还有一个额外的身份验证绕过漏洞仍未修复👀，因此它不会出现在差异中。
2. The “unauthenticated remote attacker” mentioned in the CVEs refer to a CSRF-like scenario.
   CVE 中提到的“未经身份验证的远程攻击者”是指类似 CSRF 的方案。
3. All the previous researchers found the vulnerabilities by emulating the firmware without taking in consideration the NVRAM content.
   之前的所有研究人员都通过模拟固件而不考虑NVRAM内容来发现这些漏洞。

Anyway, we are publishing our PoC exploit code and the Qiling emulator script in our poc repository on GitHub.
无论如何，我们将在 GitHub 上的 poc 存储库中发布我们的 PoC 漏洞利用代码和麒麟模拟器脚本。

If you know about an (un)fixed authentication-bypass (😉) in Asus devices drop us a message on X (formerly Twitter) or BlueSky. We would also love to hear a comment from Asus and/or from the researchers that reported the CVEs about their reasoning and considerations.
如果您知道华硕设备中的（未）修复身份验证绕过（😉），请在 X（以前称为 Twitter）或 BlueSky 上给我们留言。我们也希望听到华硕和/或报告CVE的研究人员关于他们的推理和考虑的评论。