1.“NetSarang的源码Xmanager和Xshell多种产品被植入后门事件”分析报告
2.[UVM源代码研究] 聊聊寄存器模型的后门访问
3.知名压缩软件xz被发现有后门,影响有多大?如何应对?
“NetSarang的Xmanager和Xshell多种产品被植入后门事件”分析报告
NetSarang是一家提供安全连接解决方案的公司,产品包括Xmanager Enterprise,中带 Xmanager, Xshell, Xftp, Xlpd等远程连接管理客户端软件。近期,后门官方发布的源码软件版本中被发现nssock2.dll模块源码被植入后门。阿里云应急响应团队随即启动应急分析,中带确认后门会上传敏感数据至服务器,后门统计的程序源码使用该软件的源码IT运维技术人员面临较高安全风险。
受影响版本包括官方发布的中带多个版本。阿里云安全团队深入分析后发现,后门后门代码存在于Xshell相关的源码nssock2.dll中,该DLL具有厂商合法的中带数据签名。通过技术分析,后门发现该后门代码通过申请内存、源码防空警报源码解密并执行一段shellcode来上传用户、中带机器、后门网络相关信息至远程服务器,导致敏感信息泄露,风险严重。
阿里云安全团队建议用户关注并启动自查处理,具体措施参见安全建议部分。进一步的技术分析显示,后门代码通过DGA算法生成C2域名用于数据传输,使用该算法生成的年全年C2域名已公开。后门样本会采集用户、机器信息并发送至指定域名,音乐软件iapp源码存在数据泄露风险。
检测方法包括识别后门代码、检查数据上传行为及分析网络流量。针对安全风险,阿里云提供了安全解决方案,并在检测到后门代码后对外发布全网预警公告。更多技术细节和安全建议请关注云栖社区知乎机构号:阿里云云栖社区 - 知乎。
[UVM源代码研究] 聊聊寄存器模型的后门访问
本文将深入探讨UVM源代码中寄存器模型的后门访问实现,尽管实际工作中这种访问方式相对有限,但在特定场景下其重要性不可忽视。后门访问有助于简化验证流程,特别是大富豪金牌源码在检查阶段需要获取DUT寄存器值时。
在UVM源代码中,后门访问的实现主要围绕write任务展开,核心方法是do_write(),它包括获取uvm_reg_backdoor句柄、等待访问权限和更新期望值等步骤。uvm_reg_backdoor类是用户自定义后门访问的入口,允许通过派生类实现定制化的访问方式。
获取uvm_reg_backdoor句柄的过程会遍历寄存器模型的层次,如果没有自定义backdoor,就会从顶层寄存器模型开始查找。在默认情况下,寄存器模型使用sv语法的高频加热源码DPI方式访问,但可以通过自定义类实现其他形式的访问。
源代码中的get_full_hdl_path函数负责获取寄存器的完整HDL路径,这涉及到uvm_hdl_path_concat和uvm_hdl_path_slice等结构,它们用于描述寄存器的物理信息。通过配置或add_hdl_path操作,可以在寄存器模型中存储和管理多个HDL路径,对应不同的寄存器实例。
后门读写操作会调用uvm_hdl_read()函数,它是一个通过DPI-C实现的外部函数,根据编译选项的不同,可以选择使用C语言访问HDL路径。写操作成功后,会更新寄存器的镜像值并写入实际寄存器。
总结来说,实现寄存器模型后门访问的关键步骤包括设置寄存器的HDL路径,配置单个寄存器的物理信息,并确保与HDL中的实际结构对应。需要注意的是,如果寄存器在HDL中被拆分为多个字段,需正确配置这些字段的访问路径以避免警告。
知名压缩软件xz被发现有后门,影响有多大?如何应对?
知名压缩软件xz被发现存在后门,这一问题的揭露是由Andres Freund发现sshd进程的CPU占用率异常后进行的深入调查所促成的。
对比分析有后门的m4脚本与原版,很难发现其中存在的问题。然而,通过执行命令`grep -aErls "#{ 4}[[:alnum:]]{ 5}#{ 4}$" ./`在源码根目录下,发现执行结果指向了`./tests/files/bad-3-corrupt_lzma2.xz`文件。这个步骤揭示了文件名虽不直接明文出现在构建脚本中,但通过`grep`命令间接匹配并确认了恶意文件的存在。
进一步分析表明,`gl_[$1]_prefix=echo $gl_am_configmake | sed "s/.*\.//g"`这一行代码提取了恶意文件的扩展名`xz`,实际上对应于`xz`命令行工具的名称。这暗示了解压过程需要先安装`xz-utils`包。整个解压命令的执行环境主要针对Linux系统,而非非Linux系统。
该脚本通过寻找并读取`config.status`文件来获取源码的根目录,这一过程考虑到许多发行版在编译时会单独建立`build`目录,因此`srcdir`变量保存了源码的位置。然后通过`export`命令随机读取内容,最终执行了一系列命令,其中包含多个行为,揭示了即使在非Debian或RPM系发行版中,尝试在`make`后再次执行`configure`时,也会通过其他途径执行感染。
对于Debian或RPM系发行版,恶意代码通过将上述恶意脚本注入到`Makefile`中实现,这个过程依赖于源码编译完成后才能进行。而真正感染部分在于将原本应编译自特定源文件的`liblzma_la-crc_fast.o`和`liblzma_la-crc_fast.o`目标文件链接为恶意对象文件,同时替换指令集扩展检测函数。正确的`get_cpuid`原型被故意修改,其中`__builtin_frame_address`旨在获取函数返回地址,这可能在`x_`Linux上用于在寄存器中留下特定地址。
值得注意的是,发布带有后门的作者Jia Tan曾在两个月前与Sam James讨论过与GCC相关的bug导致`ifunc`函数符号覆盖功能不正确的问题,最终确认了这是一个GCC的bug。
提交代码时的实名要求对项目维护具有重要意义,尤其是当代码引发法律问题时。在Linux等重要项目中,有提交权限的人通常被强制要求实名。通过“签核”程序,开发者需在补丁说明末尾添加证明其身份的一行,确保贡献的合法性和追踪性。
项目中采用的签署选项有助于确定提交者和审查者的身份。在更严格的场合,代码提交可能需要使用GPG签名,而线下会议可能举办Key signing party来交换GPG公钥,确保线上身份与现实一致,并获得其他人的承认。实名制是维护代码质量和法律责任的关键,虚拟人物或匿名用户无法承担相应的法律责任。