关于dlink878的复现问题

[FallinSlee]

您好！CVE-2019-8316命令注入漏洞发生在librcm.so的tw_add_url_filter_iptables_rule，SaTC已经找到了这个关键词，但是请问为什么result-librcm.so-ref2sink_cmdi-XXXX.txt文件最后的结果都是Not found呢？

[FallinSlee]

作者您好，我发现了问题所在，这个漏洞并不是由关键词allow产生的，而是在prog.cgi中添加到nvram，然后在librcm.so中获取。我运行了命令：
time python satc.py -d /home/satc/SaTC/SaTC_data/dlink878 -o /home/satc/SaTC/SaTC_data/output/dlink878_tmp3 --ghidra_script=share2sink --ref2share_result=/home/satc/SaTC/SaTC_data/output/dlink878_tmp3/ghidra_extract_result/prog.cgi/prog.cgi_ref2share.result --ghidra_script=ref2sink_cmdi -b librcm.so --taint_check
prog.cgi的ref2share文件中可以看到识别出来了关键词

但是librcm.so却没有分析出结果，请问这是哪里出错了？

[smile0304]

导致这个问题是因为污点传播并不止实在一个二进制程序中传播的，需要执行比较多的步骤。我在这个issue中回答了类似的问题：
#9

[qijiale]

您好@FallinSlee ，我使用 binwalk -Me 解析 DIR_878_FW120B05_decode.BIN时，并没有得到任何的可执行文件。我应该如何来解析这个BIN文件呢

[FallinSlee]

您好@FallinSlee ，我使用 binwalk -Me 解析 DIR_878_FW120B05_decode.BIN时，并没有得到任何的可执行文件。我应该如何来解析这个BIN文件呢

您是否尝试了命令 sudo binwalk -Me DIR_878_FW120B05_decode.BIN --run-as=root ？

[qijiale]

@FallinSlee 显示错误 General Error: Cannot open file : [Errno 2] No such file or directory: '--run-as=root'

[Summermu]

作者您好，我发现了问题所在，这个漏洞并不是由关键词allow产生的，而是在prog.cgi中添加到nvram，然后在librcm.so中获取。我运行了命令： time python satc.py -d /home/satc/SaTC/SaTC_data/dlink878 -o /home/satc/SaTC/SaTC_data/output/dlink878_tmp3 --ghidra_script=share2sink --ref2share_result=/home/satc/SaTC/SaTC_data/output/dlink878_tmp3/ghidra_extract_result/prog.cgi/prog.cgi_ref2share.result --ghidra_script=ref2sink_cmdi -b librcm.so --taint_check prog.cgi的ref2share文件中可以看到识别出来了关键词 但是librcm.so却没有分析出结果，请问这是哪里出错了？

您好，我也是这样理解的并按此步骤执行的，最终结果也和您的结果一样，参考了作者的回复后，仍觉得意思就是应当这样先对prog.cgi使用ref2share提取nvram_set参数，再对librcm.so使用share2sink和ref2sink_cmdi分析，想请问您最后成功复现了CVE-2019-8316该漏洞吗？应当怎么做呢？

[qijiale]

我也没有复现成功

…

---- 回复的原邮件 ---- | 发件人 | ***@***.***> | | 发送日期 | 2025年02月26日 21:39 | | 收件人 | NSSL-SJTU/SaTC ***@***.***> | | 抄送人 | qijiale ***@***.***>, Comment ***@***.***> | | 主题 | Re: [NSSL-SJTU/SaTC] 关于dlink878的复现问题 (Issue #33) | 作者您好，我发现了问题所在，这个漏洞并不是由关键词allow产生的，而是在prog.cgi中添加到nvram，然后在librcm.so中获取。我运行了命令： time python satc.py -d /home/satc/SaTC/SaTC_data/dlink878 -o /home/satc/SaTC/SaTC_data/output/dlink878_tmp3 --ghidra_script=share2sink --ref2share_result=/home/satc/SaTC/SaTC_data/output/dlink878_tmp3/ghidra_extract_result/prog.cgi/prog.cgi_ref2share.result --ghidra_script=ref2sink_cmdi -b librcm.so --taint_check prog.cgi的ref2share文件中可以看到识别出来了关键词 但是librcm.so却没有分析出结果，请问这是哪里出错了？ 您好，我也是这样理解的并按此步骤执行的，最终结果也和您的结果一样，参考了作者的回复后，仍觉得意思就是应当这样先对prog.cgi使用ref2share提取nvram_set参数，再对librcm.so使用share2sink和ref2sink_cmdi分析，想请问您最后成功复现了CVE-2019-8316该漏洞吗？应当怎么做呢？ — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***> Summermu left a comment (NSSL-SJTU/SaTC#33) 作者您好，我发现了问题所在，这个漏洞并不是由关键词allow产生的，而是在prog.cgi中添加到nvram，然后在librcm.so中获取。我运行了命令： time python satc.py -d /home/satc/SaTC/SaTC_data/dlink878 -o /home/satc/SaTC/SaTC_data/output/dlink878_tmp3 --ghidra_script=share2sink --ref2share_result=/home/satc/SaTC/SaTC_data/output/dlink878_tmp3/ghidra_extract_result/prog.cgi/prog.cgi_ref2share.result --ghidra_script=ref2sink_cmdi -b librcm.so --taint_check prog.cgi的ref2share文件中可以看到识别出来了关键词 但是librcm.so却没有分析出结果，请问这是哪里出错了？ 您好，我也是这样理解的并按此步骤执行的，最终结果也和您的结果一样，参考了作者的回复后，仍觉得意思就是应当这样先对prog.cgi使用ref2share提取nvram_set参数，再对librcm.so使用share2sink和ref2sink_cmdi分析，想请问您最后成功复现了CVE-2019-8316该漏洞吗？应当怎么做呢？ — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>