CN115268983A - 一种针对嵌入式物联网设备漏洞的热修复方法及装置 - Google Patents

一种针对嵌入式物联网设备漏洞的热修复方法及装置 Download PDF

Info

Publication number
CN115268983A
CN115268983A CN202210948370.2A CN202210948370A CN115268983A CN 115268983 A CN115268983 A CN 115268983A CN 202210948370 A CN202210948370 A CN 202210948370A CN 115268983 A CN115268983 A CN 115268983A
Authority
CN
China
Prior art keywords
code
repair
bug
function
vulnerability
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202210948370.2A
Other languages
English (en)
Other versions
CN115268983B (zh
Inventor
李琦
何艺
徐恪
张晗
刘卓涛
邹振华
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tsinghua University
Original Assignee
Tsinghua University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tsinghua University filed Critical Tsinghua University
Priority to CN202210948370.2A priority Critical patent/CN115268983B/zh
Publication of CN115268983A publication Critical patent/CN115268983A/zh
Application granted granted Critical
Publication of CN115268983B publication Critical patent/CN115268983B/zh
Priority to US18/446,227 priority patent/US20240053978A1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/658—Incremental updates; Differential updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y30/00—IoT infrastructure
    • G16Y30/10—Security thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Stored Programmes (AREA)

Abstract

本发明公开了一种针对嵌入式物联网设备漏洞的热修复方法及装置，其中，该方法包括：获取物联网设备待修复的漏洞信息；基于漏洞信息不同的漏洞类型选择对应的漏洞修复模式，根据漏洞修复模式从服务器中获取第一修复代码和第一修复代码配置文件；基于第一修复代码和第一修复代码配置文件对第一代码进行编译，生成第二修复代码和第二修复代码的配置信息；以及，基于配置信息和漏洞修复模式，对第二修复代码执行不同的指令进行漏洞信息的修复。本发明能够在不中断软件服务或重启***的情况下自动、快速地完成固件漏洞修复工作，适用于各类物联网设备的实时操作***，且具有较小的开销。

Description

一种针对嵌入式物联网设备漏洞的热修复方法及装置
技术领域
本发明涉及物联网设备的漏洞修复，特别是涉及一种针对嵌入式物联网设备固件漏洞的热修复方法。
背景技术
搭载有传感器的嵌入式物联网设备是物联网生态***的重要组成部分，它们实现了网络与现实世界的连接。由于此类设备通常算力有限，因此又被称作受限物联网设备或嵌入式物联网设备。嵌入式物联网设备使用的操作***大部分属于实时操作***(RTOS)，然而，目前提供服务的实时操作***在设计之初往往缺乏安全考量，因此在***内核或网络通信等子***中存在大量漏洞。为防止这些漏洞被攻击者恶意利用，有必要对已投入使用的存在漏洞的物联网设备进行相应的固件修复和更新。
目前主流的嵌入式物联网设备固件更新修复方法可以分为两类：第一类是由物联网设备厂商发布修复漏洞后的新固件，设备使用者下载新固件，手动擦除设备Flash并重写固件。这种方式需要物联网设备的使用者具备手动更新固件所需的专业知识和能力；第二类是让物联网设备联网，通过OTA(On-The-Air)的方式自动进行在线固件更新。由于发布一次OTA更新之前可能需要物联网设备厂商对开源实时操作***或第三方软件库的更新进行同步与适配，还需要针对不同设备进行充分测试，因此OTA更新无法频繁发布，这种方式容易造成额外的攻击窗口。同时，两种方法都需要暂停物联网设备的服务、重启设备以完成更新修复。综上所述，嵌入式物联网设备固件目前尚缺乏能部署快速、不中断设备服务的有效漏洞修复手段。
热修复(Hotpatch)技术是一种让软件在更新过程中仍然保持正常工作的修复技术，这种修复技术无需中断软件服务或者重启***，在Linux服务器等传统软件领域已经得到了广泛的使用，近来也有少量研究将热修复技术应用于Android领域和嵌入式物联网设备领域。现有主流热修复策略可分为以下四类：
(1)代码植入(Instrumentation)。代码植入要求对可执行内存的改写，通过这种方式有效实现对原漏洞代码段的修改、删除或替换。这种方案的难点在于，可执行内存改写过程中，如果原CPU刚好执行到漏洞代码段，那么此时程序很容易进入不一致的状态，从而造成更严重的运行错误，失去热修复的意义。因此，目前最常见的一种策略是，替换漏洞代码段的入口指令为一条跳转指令或分支指令，从而跳转到漏洞修复流程，单条指令改写本身保证了修复过程的原子性。然而，嵌入式物联网设备的可执行程序通常存放于Flash中，Flash并不支持指令粒度的擦写。
(2)A/B***。又名增量更新技术，指的是官方通过OTA等形式将升级补丁下发到设备，设备利用补丁和旧***镜像后台构建新***镜像，构建过程中旧***可以保持正常工作。构建完成后，挑选一个合适的时间点从旧***切换到新***。Android的OTA更新采用的就是这种模式。A/B***其实算不上真正的热修复，因为从旧***切换到新***的过程中设备仍然需要停止工作，造成非工作时间。此外，同时在存储器中保留两个版本的***也将造成较大的设备存储压力，这对于存储资源受限的嵌入式物联网设备来说是不可行的。
(3)可重定位的可执行文件。这种方式要求修改可执行文件的二进制链接结构，依赖于动态链接。动态链接库指的是不被包含于可执行文件的编译链接过程中，而在运行时根据需求进行动态加载和符号解析的代码。在诸如Linux和Windows的很多现代操作***中，由于大量库可能被多个应用所共享，而且应用执行也没有严格的时间限制，动态链接技术被广泛采用来节省***的存储空间。如果操作***底层支持动态链接的话，用动态链接来实现热修复是很直观的，只需要运行时对符号链接进行修改，因此任何动态链接的***组件都可以进行运行时替换，完成组件更新或漏洞修复。然而，动态链接技术会带来额外的***运行时开销和负担，也会破坏实时操作***的时间限制和任务响应延迟的可控性，因此目前嵌入式物联网设备所采用的实时操作***主流的链接方式仍然是静态链接，因此用可定位的可执行文件实现的热修复技术在物联网设备固件修复场景下可行性较低。
(4)基于硬件特性的热修复技术。在无法修改可执行内存的情况下，少数热修复研究将目光转向了CPU本身的硬件设施，依托CPU的硬件调试原件实现在指定地址对程序执行流进行拦截，达成和单条指令改写类似的拦截效果，这种方式是最适用于嵌入式物联网设备漏洞的热修复技术。已有工作基于ARM平台的特性及硬件调试原件提出了相应的热修复方案，然而，目前并没有适用于嵌入式物联网设备上实时操作***的基于硬件特性的热修复方案。
eBPF(Extended Berkeley Packet Filter)是Linux内核中的一种通用的执行机，具有低开销的特点，支持***检查和内核扩展，如今被越来越多地应用于性能分析、网络加速、安全入侵检测***的开发等不同场景下的操作***安全问题，这种强大扩展使得eBPF能够用于实现对嵌入式物联网设备的基于硬件特性的热修复。然而，由于eBPF程序来自用户空间却在内核执行，其本身具有过于严格的内存访问限制和循环禁止，严重限制了其漏洞修复能力。目前尚不存在一个安全的、易于使用的、兼容性强的***，可用于对实时性要求较高的嵌入式物联网设备应用进行热修复。
发明内容
本发明旨在至少在一定程度上解决相关技术中的技术问题之一。
为此，本发明提出一种适用于嵌入式物联网设备的漏洞热修复方法，针对上述嵌入式物联网设备存在的安全问题，弥补现有漏洞修复技术的不足，能够在不中断软件服务或重启***的情况下自动、快速地完成固件漏洞修复工作，适用于各类物联网设备的实时操作***，且具有较小的开销。
为达上述目的，本发明一方面提出一种适用于嵌入式物联网设备的漏洞热修复方法，包括：
获取物联网设备待修复的漏洞信息；
基于所述漏洞信息不同的漏洞类型选择对应的漏洞修复模式，根据所述漏洞修复模式从服务器中获取第一修复代码和第一修复代码配置文件；
基于所述第一修复代码和第一修复代码配置文件对所述第一代码进行编译，生成第二修复代码和所述第二修复代码的配置信息；以及，
基于所述配置信息和所述漏洞修复模式，对所述第二修复代码执行不同的指令进行所述漏洞信息的修复。
另外，根据本发明上述实施例的针对嵌入式物联网设备漏洞的热修复方法还可以具有以下附加的技术特征：
进一步地，在本发明的一个实施例中，所述漏洞修复模式，包括：第一修复模式和第二修复模式，所述第一修复模式包括对所述第一修复代码执行漏洞函数检查参数是否合法，若是，则退出所述第一修复代码，继续执行漏洞函数；所述第二修复模式包括对所述漏洞函数或代码段进行替换。
进一步地，在本发明的一个实施例中，所述基于不同的漏洞修复模式从服务器中获取第一修复代码和第一修复代码配置文件，包括：利用所述第一修复模式进行第一修复代码编写，在所述第一修复代码执行时根据不同的操作码进行对应操作处理；以及，利用所述第二修复模式进行第一修复代码编写，替换原有函数或漏洞代码段，修复代码将原市代码的函数调用部分进行替换，同时调用本地C函数获取信息。
进一步地，在本发明的一个实施例中，所述触发指令，包括：固定修复代码触发指令：通过在漏洞函数入口插桩以对漏洞函数执行流的拦截，拦截成功后进入对应的处理函数，在所述处理函数中调用执行第二修复代码；动态触发指令：在硬件调试寄存器中的地址被匹配中后进行地址重映射，通过REMAP Table进行指令替换，将目标指令替换为跳转指令，并跳转到对应的处理函数；以及，在硬件调试寄存器中的地址匹配中后，不进行指令替换，触发硬件异常处理流程，对异常数据进行处理，将中断时的CPU寄存器状态压栈，之后再执行第二修复代码。
进一步地，在本发明的一个实施例中，所述方法，还包括：当检测到漏洞信息时调用漏洞函数，在执行第一条指令之前拦截漏洞信息，触发第二修复代码，将产生的控制流导入修复代码的加载模块，将压栈保存漏洞函数调用时的寄存器状态信息，并通过漏洞函数入口地址查找Patch List，得到对应的第二修复代码、漏洞修复模式和执行指令，最后执行第二修复代码。
为达上述目的，本发明另一方面提出一种针对嵌入式物联网设备漏洞的热修复装置，包括：
信息获取模块，用于获取物联网设备的操作***中待修复的漏洞信息；
代码获取模块，用于基于所述漏洞信息不同的漏洞类型选择对应的漏洞修复模式，根据所述漏洞修复模式从服务器中获取第一修复代码和第一修复代码配置文件；
代码编译模块，用于基于所述第一修复代码和第一修复代码配置文件对所述第一代码进行编译，生成第二修复代码和所述第二修复代码的配置信息；以及，
漏洞修复模块，用于基于所述配置信息和所述漏洞修复模式，对所述第二修复代码执行不同的指令进行所述漏洞信息的修复。
本发明实施例的针对嵌入式物联网设备漏洞的热修复方法及装置，针对上述嵌入式物联网设备存在的安全问题，弥补现有漏洞修复技术的不足，能够在不中断软件服务或重启***的情况下自动、快速地完成固件漏洞修复工作，适用于各类物联网设备的实时操作***，且具有较小的开销。
本发明的有益效果为：
1)本发明在保障修复代码安全性的同时大大加速了修复代码的部署进程。本发明中修复代码的编写无需同步开源实时操作***或第三方库的更新，针对一个漏洞只需编写一份eBPF修复代码，随后即可用Toolchain给所有存在该漏洞的固件自动适配编译出对应的二进制eBPF修复代码，无需手工对每一个设备和固件适配修复代码。本发明中修复代码的适配编译和传统的整个固件的适配编译不同：本发明修复代码的适配编译仅需一份现成的固件镜像来辅助修复代码中的全局符号解析，可以由Toolchain自动完成；而传统的整个固件的适配编译则需要完整搭建原固件的编译环境，包括编译配置和编译参数选择，而且较大体量的代码同步很可能导致编译过程中频繁出错，需要人工去一一调整。
2)本发明提出的漏洞修复方案是操作***无关的。当新的漏洞被披露时，不管该漏洞来自于嵌入式物联网设备厂商自己开发的***、开源的实时操作***或是开源的第三方库，只要设备厂商可以获取到漏洞细节及漏洞代码，就可以应用本发明提出的热修复框架及时开展漏洞热修复。
本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。
附图说明
本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
图1为根据本发明实施例的针对嵌入式物联网设备漏洞的热修复方法的流程图；
图2为根据本发明实施例的针对嵌入式物联网设备漏洞的热修复架构图；
图3为根据本发明实施例的使用Filter Patch模式生成修复代码的示意图，包括CVE-2020-17443的漏洞代码及eBPF filter代码示意图；
图4为根据本发明实施例的使用Code Replace Patch模式生成修复代码的示意图，包括CVE-2020-10023的漏洞代码及eBPF replace代码示意图；
图5为根据本发明实施例的修复代码配置文件的格式示意图；
图6为根据本发明实施例的描述修复代码的验证，使用eBPF JIT执行循环检查植入的示例图；
图7为根据本发明实施例的描述Runtime模块进行修复代码部署与运行的架构及工作流程示意图；
图8为根据本发明实施例的描述Patch Trigger三种修复代码触发方式原理的示意图；
图9为根据本发明实施例的描述Patch Trigger三种修复代码触发方式的对比示意图；
图10为根据本发明实施例的描述Patch Loader执行的上下文切换的示意图；
图11为根据本发明实施例的针对嵌入式物联网设备漏洞的热修复装置的结构示意图。
具体实施方式
需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。
为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。
下面参照附图描述根据本发明实施例提出的针对嵌入式物联网设备漏洞的热修复方法和装置。
图1是本发明实施例的针对嵌入式物联网设备漏洞的热修复方法的流程图。
如图1所示，该方法包括但不限于以下步骤：
S1，获取物联网设备待修复的漏洞信息。
S2，基于漏洞信息不同的漏洞类型选择对应的漏洞修复模式，根据漏洞修复模式从服务器中获取第一修复代码和第一修复代码配置文件。
可以理解的是，获取固件的漏洞报告，针对漏洞信息进行修复。
本发明实施例提供了两种修复漏洞的基本思路，一是在漏洞函数入口处或者漏洞触发关键代码点拦截程序执行，过滤掉可能触发漏洞的有害输入；二是直接进行函数替换或基本块粒度的代码段替换。两种修复思路分别对应Filter Patch和Code Replace Patch修复模式，两种修复模式下的修复代码也不同，开发者需要首先根据漏洞修复需求选择修复模式，进而根据选择的漏洞修复模式编写相应的eBPF修复代码和修复代码配置文件，辅助本发明的Toolchain完成eBPF代码的自动适配编译、验证检查以及最后的安装配置。如果修复代码中涉及到全局变量的访问，开发者无需关心该全局变量在具体固件中的地址，只需要用特定格式的宏替换该全局变量，并在修复代码配置文件中记录宏和全局变量名的对应关系。eBPF代码配置文件中还需注明修复模式，方便eBPF VM执行修复代码时采取不同的限制。
可以理解的是，eBPF修复代码的开发基于设备厂商获取到的最新漏洞报告细节和漏洞软件代码。考虑到修复不同的漏洞所需要的漏洞代码执行能力不同，本发明设计了两种不同的修复模式：FilterPatch和CodeReplacePatch模式，开发者可以根据实际漏洞修复需求选择相应的修复模式编写修复代码。除了修复代码外，开发者还需要为修复代码编写相应的配置文件，以供修复代码编译验证阶段使用。本发明框架，如图2所示。
(1)FilterPatch模式
可以理解的是，大部分嵌入式物联网设备的固件漏洞原因都是函数对于传入的部分参数缺乏合法性检查，进而可能导致程序缓冲区溢出、内存错误、死循环等问题。FilterPatch修复模式即用于修复这类漏洞，只需在函数入口或者漏洞代码段的入口处拦截程序执行流，重定向到修复代码处，在修复代码中解析获取到目标参数的值，并进一步过滤非法输入。具体来说，也就是在修复代码中检查参数是否合法，如果合法就退出修复代码，继续执行漏洞函数；如果不合法就通过直接给Caller返回错误码或者跳转到漏洞函数内错误处理流程的形式提前结束漏洞函数的执行。
具体地，以AMNESIA33漏洞报告中披露的一个来自PicoTCP协议栈的漏洞CVE-2020-17443为例。如图3所示，图中“VulnerableC Code”部分显示CVE-2020-17443漏洞的根源在于PicoTCP协议栈的pico_icmp6_send_echoreply函数在处理ICMPv6 echo请求时，没有判断请求包的ICMPv6包头长度是否合法，即代码中没有检查echo->transport_len变量的大小是否大于等于8，因此可能在图3Vulnerable C Code第10行阴影标出的运算处发生整数下溢出，通过memcpy函数造成内存错误。ICMPv6 echo请求包的内容和大小完全受控于网络输入，因此攻击者很容易构造非法ICMPv6echo请求达成攻击目的。官方修复代码是图3中第3-5行阴影标注的代码部分，即在函数中增加了对应字段检查。
本发明中为CVE-2020-17443编写的eBPF Filter Patch代码如图3中的“eBPFFilter Patch”部分所示。filter函数的参数frame是进行上下文切换时预先准备好的拦截时(也就是刚进入漏洞函数，执行第一条指令之前)CPU寄存器的状态信息。结合漏洞代码中的结构体定义，可以在filter函数中通过指针运算获取到了transport_len变量的值，进而检查该值是否合法，即是否可能触发上述漏洞。如果检测出会触发漏洞的恶意输入，eBPF filter代码会返回错误操作码和可选的返回地址。在Filter Patch修复模式下，修复代码执行逻辑判断仅涉及到eBPF栈外内核内存的读，因此可以在Runtime模块中对Filter Patch禁止修复代码写eBPF栈外的内核内存或调用本地C函数。此外，修复代码的返回值将被严格限制为OP_PASS、OP_REDIRECT和OP_DROP三种操作码：OP_PASS表示输入合法，漏洞不会触发；OP_REDIRECT和OP_DROP均表示输入非法，需要跳转到函数内错误处理流程或Caller函数，在修复代码执行之后，Runtime模块中的Patch Loader模块会接收到这三种操作码之一，然后进行不同的处理。
上述对Filter Patch模式下的修复代码实施的限制保证了Filter Patch修复代码的安全性，因此Filter Patch修复代码无需额外的修复代码测试，从而加速了修复代码的部署和传播。上述限制可由本发明提供的离线验证器和eBPF VM运行时动态检查保证。
(2)Code Replace Patch模式
有一部分嵌入式物联网设备固件的漏洞并不能通过在漏洞函数入口增加参数检查完成修复，一个典型的例子是来自Zephyr OS的CVE-2020-10023，其漏洞代码点细节如图4左侧所示。该漏洞的根本原因是Zephyr OS的Shell子***的shell_spaces_trim函数在调用memmove函数时，第三个参数传错了(j传成了shift)，因此即便是合法的shell输入也可能造成缓冲区溢出。本发明中，将类似的和函数输入无关的漏洞归结为Logical Bugs，这类漏洞源自函数内或函数间调用逻辑的错误，无法通过过滤有害输入来防止漏洞利用，唯一的解决方案是对漏洞函数或特定的代码段进行替换。
此外，存在一部分漏洞的修复需要调用固件本地C函数获取关键信息。以蓝牙协议栈中著名的秘钥协商DownGrade攻击，KNOB(Key Negotiation ofBluetooth,CVE-2019-9506)漏洞为例，修复过程中必须检测秘钥长度过小的蓝牙连接，而获取蓝牙秘钥长度则必须调用底层的HCI API，也就是调用本地C函数。
Code Replace Patch模式即用于修复上述两个例子体现出的部分特殊漏洞，这类漏洞的修复代码的两个重要功能需求：一是替换原有函数或漏洞代码段，二是调用本地C函数获取信息。替换原有漏洞函数或代码段，就需要赋予修复代码和本地代码相同的执行能力，包含C函数调用和eBPF栈外内核内存写。继续以CVE-2020-10023为例来说明CodeReplacePatch修复模式下的修复代码格式。如图4右侧所示，Code Replace Patch模式在修复代码中使用了eBPF_spaces_trim函数来替换原有的漏洞函数shell_spaces_trim。由于eBPF是类C的语言，Code Replace Patch事实上几乎完全照搬了原漏洞函数，而仅仅修改了参数解析逻辑，将函数调用部分替换成了helper函数。由此可见，CodeReplace Patch修复模式下修复代码的开发是很简单和直观的。本发明在后续的Runtime模块中通过helper函数的形式实现了一个简单的FFI(foreign function interface)，从而支持在eBPF代码中调用本地C函数。
进一步地，修复代码的开发者在编写修复代码时无需关心具体的固件信息，对于修复代码中涉及的全局变量名和固件函数名，可以使用特定格式的宏替换，并将全局变量名和固件函数名的宏对应关系记录在修复代码配置文件中。本发明使用YAML编写修复代码配置文件，其格式如图5所示。其中，patch_type指定了修复模式；trigger_point则声明拦截位点，其中function_position是拦截的目标函数名，statement_position作为可选项，用于索引目标基本块入口；run_type是修复代码的运行方式；variable_map则给出修复代码中涉及的宏与全局变量名或函数名的对应关系。
S3，基于第一修复代码和第一修复代码配置文件对第一代码进行编译，生成第二修复代码和第二修复代码的配置信息。
可以理解的是，修复代码的编译与验证，由本发明中的Toolchain模块完成。设备厂商开发者针对存在漏洞的特定固件利用本发明的Toolchain进行自动的修复代码适配编译与验证。eBPF配置文件中会记录存在漏洞的实时操作***或软件库版本范围，如果设备厂商对于特定固件中包含的实时操作***和软件库版本、使用的编译参数和配置有良好的记录，就可以直接判断该固件是否包含有对应漏洞。而如果少量固件的上述信息丢失，本发明在Toolchain中也提供了二进制文件函数比对工具来辅助判断一个固件中是否包含目标漏洞函数。对于存在漏洞的特定(针对特定设备采用特定版本和特定编译配置)固件，Toolchain需要其符号表信息来定位函数地址，并在编译修复代码时自动完成对全局符号的地址替换。修复代码自动编译结束后，会生成二进制eBPF修复代码以及修复代码的部署配置信息，配置信息中包含目标漏洞函数地址、修复代码的大小、修复模式、执行方式、触发方式。此外，Toolchain中定制的验证器会离线检查二进制eBPF修复代码是否存在可能引入安全隐患的行为，比如eBPF栈外内存写、循环、函数调用，如果存在的话将会给开发者予以具体提示，开发者需要根据该提示对修复代码做进一步测试以确保其安全性。
具体地，Toolchain的两个核心组件是Patch Generator和Patch Verifier，即二进制eBPF修复代码的生成器和验证器。Patch Generator将用户编写的固件无关的修复代码结合具体固件的符号信息编译生成能够部署到设备上运行的二进制eBPF修复代码，而Patch Verifier则在部署之前进行对二进制eBPF修复代码的安全性检查。
作为一种示例，修复代码的编译(Patch Generator)，由于嵌入式物联网设备的固件在编译时通常采用静态链接，不同编译配置的固件中相同的函数和变量一般具有不同的地址。本发明能够使得修复代码开发者无需关心特定设备上的具体固件信息。详细而言，使用eBPF编写修复代码时，开发者可以使用宏来替代全局变量的地址或函数地址，并在eBPF修复代码的配置文件中记录宏和全局符号名的对应关系。Patch Generator在编译修复代码前会据此查询漏洞固件的符号表，将对应的全局变量名或是函数名替换成全局地址，然后再编译eBPF修复代码。此外，查询漏洞固件的符号表时，Patch Generator还会根据eBPF代码配置文件中的漏洞函数名和基本块标签来查找漏洞代码段的入口地址，并记录在修复代码部署配置信息中，给Patch Installer后续用于安装和启用修复代码。
作为一种示例，修复代码的验证(Patch Verifier)，Patch Generator生成出来的二进制eBPF修复代码可以通过Patch Verifier进行安全检查。该验证器可以识别出修复代码中的不安全行为，即循环、栈外内存访问和C函数调用。没有上述不安全行为的修复代码，在Filter Patch模式下可以直接部署，免于后续的测试。否则，Patch Verifier将会通过自动的指令分析标注出对应的不安全指令，帮助开发者做进一步检查测试，之后再部署到设备。开发者可以利用Patch Verifier确保Filter Patch修复代码的安全性，从而跳过后续测试，直接完成部署。
由于Linux内核中所提供的eBPF验证器执行了过于严格的循环限制和内存访问范围限制，不能满足实际的漏洞修复需求，并不能直接用于本发明的框架中。此外，Linux内核中的eBPF验证器所能容许的循环必须是可预见能终止的循环。然而，即便在Filter Patch修复模式下，过滤恶意输入也可能需要全局变量的读取或由输入参数控制的循环，但这在Linux内核的eBPF验证器中也是被禁止的。同时，Linux内核的eBPF验证器在安装filter代码的时候执行检查，确保不符合要求的eBPF程序完全不能在***中执行，但这对算力受限的嵌入式物联网设备来说并不可行，在设备上进行修复代码验证会浪费过多的设备资源。因此本发明改变思路，实现了一个离线的、部署修复代码前的eBPF验证器——PatchVerifier，并且仅将验证结果提供给开发者参考，具体是否部署该修复代码由开发者决定。Patch Verifier和Linux***中的eBPF验证器主要有两方面不同：首先，在Filter Patch修复模式下，我们仅允许eBPF代码写eBPF程序对应的栈内内存，但我们不限制eBPF代码可读的内存空间范围，Linux***eBPF验证器则仅允许eBPF程序读写特定的包缓冲区；其次，Linux***eBPF验证器会进行循环展开，确保eBPF程序的循环可以结束，而Patch Verifier则只检测是否存在循环并提示开发者。
可以理解的是，即使是目前最先进的eBPF验证器也无法准确判断循环是否是可终止的。静态分析方法并不可行，因为循环条件可能依赖于输入数据。因此本发明选择在eBPFVM中执行eBPF二进制代码时防止程序陷入死循环。解释执行模式下，对于执行的每条跳转指令，本发明所述框架会检查其跳转偏移量，如果偏移量是负数，说明会调转到前面的基本块，可能形成回环。同时，利用全局计数器来记录经过这种指令的次数，并对跳转次数进行限制。而对于JIT执行，本发明所述框架会在JIT编译的时候对循环植入检查点，如图6所示，完成对循环次数的限制。上述两种循环限制方法确保了目标漏洞应用不会因为启用本发明生成的修复代码而进入死循环，破坏任务的实时性限制。
S4，基于配置信息和漏洞修复模式，对第二修复代码执行不同的指令进行漏洞信息的修复。
可以理解的是，修复代码的部署与运行，由本发明中的Runtime模块完成。修复代码验证完成后，设备厂商可以通过加密网络通信或安全的设备外置接口等方式完成修复代码的传输。对于已经支持安全OTA更新的实时操作***，厂商开发者可以沿用原有的OTA网络通信通道进行修复代码的传输。为了不影响对实时性要求较高的高优先级事务，设备上接收和安装启用修复代码的线程运行在较低的优先级中。Patch Installer将接收到的修复代码存储到Patch List中，记录每个修复代码的修复模式和执行方式，最后根据接收到的修复代码部署配置信息启用不同的修复代码触发方式。本发明的Runtime模块同时支持固定修复代码触发点和动态修复代码触发点。固定修复代码触发点即软件hook点，动态修复代码触发点通过硬件调试原件支持，包含FPB(Flash Patch Point)触发和DebugMonitor触发。需要注意的是，在已经实现的ARM Cortex-M4场景下，FPB触发模式和DebugMonitor触发模式同时只能启用一个，依赖于不同的CPU配置。修复代码触发点即Runtime中的Patch Trigger模块，用于拦截漏洞函数。漏洞函数调用被拦截后，Patch Loader查找到对应修复代码，并根据Patch Installer记录的相应执行模式与执行方式对修复代码进行不同的处理。Filter Patch修复模式下，在Patch Loader调用的eBPF VM中执行的修复代码的eBPF栈外内存写和函数调用是完全被禁止的：解释执行会进行修复代码运行时检查，而JIT执行则会在JIT编译的时候完成检查，直接丢弃不符合要求的修复代码。
具体地，本发明中的Runtime模块是一个静态软件库，需要在编译时集成到固件中，负责在固件运行时完成对修复代码的安装和执行。Runtime中包含四个核心组件：PatchInstaller负责修复代码的安装和启用，Patch Trigger负责修复代码执行流程的触发，Patch Loader负责程序执行上下文的切换以及修复代码的加载，Patch Executor(eBPFVM)则由Patch Loader调用来完成修复代码的执行。Runtime的架构及工作流程如图7所示，如下将具体介绍Runtime各个组件的设计与功能。
进一步地，修复代码的安装(Patch Installer)。本发明通过加密网络传输或设备的其他可靠外部接口完成修复代码的接收，之后用Patch Installer完成修复代码的安装。Patch Installer将接收到的Patch根据修复代码部署信息中记录的Patch拦截地址追加到全局Patch List中，该全局Patch List是基于每个Patch的拦截地址从小到大排序的。Patch List中还会记录每个Patch修复代码的执行模式和修复模式。后续由Patch Loader加载执行修复代码时，会先根据拦截地址在Patch List进行二分查找，并依照其中记录的修复模式和执行方式做相应处理。
Patch Installer还需要处理和Patch Loader的并发。本发明所述框架中，通过RCU(Read Copy Update)机制来保证Patch Loader加载执行修复代码时无需等待。具体实现方法是，先在一个单独的线程任务中完成Patch List的更新，该线程会先拷贝全局PatchList得到一份临时Patch List，然后对该临时Patch List进行更新操作，之后通过CAS(Compare and Swap)原子操作同步到全局Patch List中。这期间Patch Loader可以持续对全局Patch List进行访问。
Patch Installer在Patch List中存储了修复代码及相关信息之后，对于基于硬件调试原件触发的修复代码，还需要对硬件调试原件进行配置，才能启用修复代码，我们将在下一小节中具体介绍。对于需要JIT执行的修复代码，Patch Installer还负责JIT编译，将二进制eBPF修复代码翻译成本地的机器代码。
进一步地，修复代码的触发(Patch Trigger)。Patch Trigger实现了对漏洞函数执行流的拦截，并通过Patch Loader将执行流重定向到修复代码中。总的来说，我们支持两类修复代码触发方式，一是固定修复代码触发点，二是动态修复代码触发点。固定触发点包含一种软件触发方式，动态触发点包含两种硬件触发方式，三种触发方式如图8所示。
固定修复代码触发点和LSM(Linux Security Modules)在Linux***中植入的hook点类似，通过在函数入口插桩实现对函数执行流的拦截。在本发明所述框架内，该函数入口hook点可以由设备厂商在开发固件的时候手工加入，也可以由开发者给出需要插桩的关键函数列表，通过Toolchain模块支持的工具自动进行固件编译阶段插桩。如图8所示，软件hook点拦截成功后，会进入对应的处理函数，在处理函数中尝试调用Patch Loader执行修复代码，如果Patch Loader没有查询到对应的修复代码，那么就返回原函数继续执行，否则将执行修复代码。由于FreeRTOS和Ripple 20中披露的大多网络协议栈的漏洞，尽管位于网络协议栈的不同层，其原因都是缺乏对函数输入的合法性检查，固定修复代码触发点结合Filter Patch修复模式可以很容易地过滤掉非法出入，从而避免漏洞被触发，同时也严格保证了修复代码的安全性。
动态修复代码触发点则基于设备CPU所支持的硬件调试原件拦截函数执行流。由于硬件调试寄存器中可以写入的地址是任意的，因此动态修复代码触发点的拦截地址也是任意的。如图8，本发明目前在ARM Cortex-M4平台支持了两种硬件触发方式。一种是FPB(Flash Patch Point)触发，在该模式下，硬件调试寄存器中的地址被匹配中后，会进行地址重映射，通过REMAP Table进行指令替换，将目标指令替换成一条跳转指令，跳转到PatchLoader中对应的处理函数。另一种硬件触发方式同样需要利用硬件调试寄存器，区别在于，硬件调试寄存器中的地址匹配中后，并不进行指令替换，而是触发一个硬件异常，由PatchLoader中的Debug Monitor对该异常进行处理，将中断时的CPU寄存器状态压栈，之后再执行修复代码。由于两种硬件触发方式均需要硬件调试寄存器支持，而CPU配置只支持同时启用两种调试寄存器工作模式中的一种，因此两种硬件触发方式在同一设备上也只能选择一种。硬件调试寄存器的启用和工作模式的配置均由Patch Installer完成。此外，FPB模式仅在ARM Cortex-M3/M4平台上存在支持，而类似Debug Monitor的硬件中断异常处理流程则被大多主流CPU采用，因此第二种硬件触发方式更具有通用性。
三种修复代码触发方式各有其优势劣势，详细对比如图9。软件实现的固定触发点在固件编译时***，拦截位点通常位于函数入口，无法在固件运行期间修改；通过硬件支持的动态触发点则可以在固件运行时启用和取消，其拦截位点是任意的。在同时可安装的修复代码数量上，软件触发仅仅受限于设备的内存大小，而硬件触发则主要受限于CPU上的硬件调试寄存器的数量，比如ARM平台中该数量的范围是6～8。软件触发可以在任意处理器平台上应用，而两种硬件触发方式则具有不同程度的硬件依赖性。在未安装修复代码的情况下，两种硬件触发方式完全没有额外执行开销。而软件触发方式由于在每个固定hook点均需要检查是否存在对应修复代码，因此具有一定的执行开销。
进一步地，修复代码的加载(Patch Loader)。Patch Loader负责修复代码被触发后的上下文保存、修复代码的加载、eBPF VM的调用、修复代码执行结束后的上下文恢复。为了更清晰地说明Patch Loader模块、漏洞函数、漏洞函数的Caller、eBPF VM之间的交互，本发明Runtime的架构和工作流程呈现在图7中。如图所示，漏洞函数的Caller事先进行参数准备，然后调用漏洞函数。我们在漏洞函数的入口处，即漏洞函数执行第一条指令之前进行拦截，或者说触发修复代码的执行。拦截方式可以是上述固定修复代码触发点或动态修复代码触发点之一。拦截漏洞函数后，控制流被导入Patch Loader。Patch Loader将首先压栈保存漏洞函数调用时的寄存器状态等上下文信息，然后通过漏洞函数入口地址查找PatchList，得到对应的eBPF修复代码及修复模式、执行方式。接下来，Patch Loader调用PatchExecutor(eBPF VM)执行修复代码，Patch Executor根据传入的不同修复模式、执行方式配置来对修复代码做限制性运行，eBPF修复代码根据运行结果会返回给Patch Loader不同的操作码和可选的附加返回地址。
与现有工作检测到会触发漏洞的恶意输入时选择直接杀死漏洞函数所在的进程不同，本发明中的Runtime模块选择了更为精细的处理机制来防止漏洞利用，并同时保障实时操作***的关键任务不受影响，能继续执行。具体而言，根据接收到的操作码的不同，Patch Loader后续有三种执行路线：继续正常执行漏洞函数；跳转到漏洞函数内的错误处理流程中；放弃漏洞函数执行并提前给漏洞函数的Caller返回错误码，由Caller执行错误处理流程。三种执行路线分别对应修复代码执行返回的三种操作码，即图7中的OP_PASS、OP_REDIRECT和OP_DROP。OP_REDIRECT和OP_DROP的处理机制设计均来源于我们对大量实时操作***或开源第三方库代码的分析。由于嵌入式***的C代码函数通常会返回状态码来告诉Caller该函数是否执行成功，如果失败的话状态码中将包含错误信息，因此方便了Caller执行不同的错误处理流程。此外，如果多个函数通过全局变量进行协作，那么每个函数中通常会包含专门的代码片段来进行错误处理，将错误信息记录在全局变量中、方便其他函数判断决策，或者恢复上下文数据，该代码片段可以被灵活利用来辅助Patch Loader进行错误处理。
需要注意的是，无论是Code Replace Patch修复模式还是Filter Patch修复模式，我们都限制修复代码返回的操作码仅可以是OP_PASS、OP_REDIRECT和OP_DROP三种。为防止修复代码被恶意利用，Runtime模块并不允许重定向时指定任意的地址，该地址必须是原漏洞函数的返回地址或漏洞函数内的基本块入口之一。
Patch Loader负责的修复代码执行流程中的上下文切换操作包含两部分，即执行修复代码前存储原函数的上下文和执行修复代码后恢复上下文。如图10，修复代码触发后，Patch Loader首先将原函数的寄存器状态压栈，然后将栈指针传给_patch_dispatch函数，该函数将完成修复代码的查询和执行，之后根据修复代码返回的不同操作码，选择是否更改LR寄存器以改变返回地址。之后Patch Loader恢复原函数的寄存器状态，结束修复代码执行流。
进一步地，修复代码的执行(Patch Executor)。Patch Executor是Runtime模块中负责执行修复代码的组件。本发明不仅通过移植Linux内核中的eBPF VM支持了修复代码的解释执行，此外还单独实现了ARM THUMB指令集上的eBPF JIT执行。
两种执行方式在不同的修复模式下采用不同的策略对修复代码实施限制。FilterPatch修复模式下，解释执行在修复代码运行时开展动态检查，禁止eBPF栈外内存写操作和过多的循环次数；JIT执行则在修复代码JIT编译时就丢弃存在eBPF栈外内存写操作的修复代码，对存在循环的修复代码则植入额外指令限制循环次数。Code Replace Patch修复模式下，eBPF VM对于两种执行方式仍将采取循环限制措施，而内存访问和本次C函数调用的安全性则需要由开发者自行离线测试保证。
eBPF Map是Linux***的eBPF VM中的重要数据结构，帮助实现了用户空间和内核空间的eBPF数据交互。本发明在移植eBPF VM的同时也移植了其中的eBPF Map，并发现了eBPF Map在固件漏洞修复中的重要用途。我们注意到一类漏洞的修复需要在不同的函数间共享状态。以FreeRTOS中的CVE-2018-16528为例，其漏洞根源在于TCP协议栈的prvSetupConnection函数在尝试建立Socket连接时，并不知道连接建立失败是否是TLShandshake失败造成的，也就是TLS context object是否已经准备好。而在随后进行的连接失败处理流程中，prvSetupConnection函数会尝试访问可能尚未准备好的TLS contextobject，就会出现内存错误。为了修复该漏洞，本发明在socket连接建立时利用eBPF Map记录TLS context object的状态，方便连接失败处理流程中据此进行不同的处理。
综上，本发明提出了一个用于缓解嵌入式物联网设备固件漏洞的热修复框架，该框架同时具有通用性、及时性、安全性和灵活性。通用性体现在本发明使用操作***及硬件无关的编程语言eBPF来编写修复代码，通过本发明所述框架内包含的Toolchain模块和Runtime模块实现只编写一份修复代码，即可自动适配编译和部署到各种实时操作***中。该修复过程也避免了对开源实时操作***或第三方软件库代码更新的同步和适配，无需开发者手动重复适配编译整个固件，加速了修复代码部署进程，从而实现了修复的及时性。本发明通过对不同原因和类型的漏洞应用不同的修复模式来提升框架的安全性，不同修复模式下的修复代码具有不同的执行能力，执行能力则通过eBPF VM内的解释器或JIT编译器实现严格限制。此外，Toolchain模块中还包含一个我们基于漏洞修复需求定制的离线eBPF验证器，用于检测eBPF修复代码中存在安全隐患的行为。至于修复框架的灵活性，本发明同时支持了两种动态修复代码触发点和一种静态修复代码触发点，还同时支持修复代码的解释执行和JIT编译执行。本发明框架的使用者可以根据实际的漏洞修复需求和操作***、设备条件灵活选择和组合不同的触发方式、执行方式、修复模式，高效完成漏洞修复任务。
根据本发明实施例提出的针对嵌入式物联网设备漏洞的热修复方法，首先拦截漏洞函数，通过加密网络通信或安全的设备外置接口等方式完成对已验证修复代码的传输，进而根据不同修复代码的修复模式和执行方式触发修复代码执行。本发明提出的嵌入式物联网设备漏洞修复方法具有显著的通用性、及时性、安全性和灵活性，能够对现有的物联网***提供实质性帮助。
为了实现上述实施例，如图11所示，本实施例中还提供了针对嵌入式物联网设备漏洞的热修复装置10，该装置10包括，信息获取模块100、代码获取模块200、代码编译模块300和漏洞修复模块400。
信息获取模块100，用于获取物联网设备中待修复的漏洞信息；
代码获取模块200，用于基于漏洞信息不同的漏洞类型选择对应的漏洞修复模式，根据漏洞修复模式从服务器中获取第一修复代码和第一修复代码配置文件；
代码编译模块300，用于基于第一修复代码和第一修复代码配置文件对第一代码进行编译，生成第二修复代码和所述第二修复代码的配置信息；以及，
漏洞修复模块400，用于基于配置信息和漏洞修复模式，对第二修复代码执行不同的指令进行漏洞信息的修复。
进一步地，上述漏洞修复模式，包括：第一修复模式和第二修复模式，第一修复模式包括对第一修复代码执行漏洞函数检查参数是否合法，若是，则退出第一修复代码，继续执行漏洞函数；第二修复模式包括对漏洞函数或代码段进行替换。
进一步地，上述代码获取模块200，还用于：
利用第一修复模式进行第一修复代码编写，在第一修复代码执行时根据不同的操作码进行对应操作处理；以及，
利用第二修复模式进行第一修复代码编写，替换原有函数或漏洞代码段，修复代码将原市代码的函数调用部分进行替换，同时调用本地C函数获取信息。
进一步地，上述代码编译模块300，包括：
固定触发指令子模块，用于通过在漏洞函数入口插桩以对漏洞函数执行流的拦截，拦截成功后进入对应的处理函数，在处理函数中调用执行第二修复代码；
动态触发指令子模块，用于在硬件调试寄存器中的地址被匹配中后进行地址重映射，通过REMAP Table进行指令替换，将目标指令替换为跳转指令，并跳转到对应的处理函数；以及，在硬件调试寄存器中的地址匹配中后，不进行指令替换，触发硬件异常处理流程，对异常数据进行处理，将中断时的CPU寄存器状态压栈，之后再执行第二修复代码。
进一步地，上述装置10，还包括，代码加载模块，用于当检测到漏洞信息时调用漏洞函数，在执行第一条指令之前拦截漏洞信息，触发第二修复代码，将产生的控制流导入修复代码的加载模块，将压栈保存漏洞函数调用时的寄存器状态信息，并通过漏洞函数入口地址查找Patch List，得到对应的第二修复代码、漏洞修复模式和执行指令，最后执行第二修复代码。
根据本发明实施例提出的针对嵌入式物联网设备漏洞的热修复装置，首先拦截漏洞函数，通过加密网络通信或安全的设备外置接口等方式完成对已验证修复代码的传输，进而根据不同修复代码的修复模式和执行方式触发修复代码执行。本发明提出的嵌入式物联网设备漏洞修复方法具有显著的通用性、及时性、安全性和灵活性，能够对现有的物联网***提供实质性帮助。
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

Claims (10)

1.一种针对嵌入式物联网设备漏洞的热修复方法，其特征在于，包括以下步骤：
获取物联网设备待修复的漏洞信息；
基于所述漏洞信息不同的漏洞类型选择对应的漏洞修复模式，根据所述漏洞修复模式从服务器中获取第一修复代码和第一修复代码配置文件；
基于所述第一修复代码和第一修复代码配置文件对所述第一代码进行编译，生成第二修复代码和所述第二修复代码的配置信息；以及，
基于所述配置信息和所述漏洞修复模式，对所述第二修复代码执行不同的指令进行所述漏洞信息的修复。
2.根据权利要求1所述的方法，其特征在于，所述漏洞修复模式，包括：第一修复模式和第二修复模式，所述第一修复模式包括对所述第一修复代码执行漏洞函数检查参数是否合法，若是，则退出所述第一修复代码，继续执行漏洞函数；所述第二修复模式包括对所述漏洞函数或代码段进行替换。
3.根据权利要求2所述的方法，其特征在于，所述基于不同的漏洞修复模式从服务器中获取第一修复代码和第一修复代码配置文件，包括：
利用所述第一修复模式进行第一修复代码编写，在所述第一修复代码执行时根据不同的操作码进行对应操作处理；以及，
利用所述第二修复模式进行第一修复代码编写，替换原有函数或漏洞代码段，修复代码将原市代码的函数调用部分进行替换，同时调用本地C函数获取信息。
4.根据权利要求1所述的方法，其特征在于，所述触发指令，包括：
固定修复代码触发指令：通过在漏洞函数入口插桩以对漏洞函数执行流的拦截，拦截成功后进入对应的处理函数，在所述处理函数中调用执行第二修复代码；
动态触发指令：在硬件调试寄存器中的地址被匹配中后进行地址重映射，通过REMAPTable进行指令替换，将目标指令替换为跳转指令，并跳转到对应的处理函数；以及，
在硬件调试寄存器中的地址匹配中后，不进行指令替换，触发硬件异常处理流程，对异常数据进行处理，将中断时的CPU寄存器状态压栈，之后再执行第二修复代码。
5.根据权利要求1所述的方法，其特征在于，所述方法，还包括：当检测到漏洞信息时调用漏洞函数，在执行第一条指令之前拦截漏洞信息，触发第二修复代码，将产生的控制流导入修复代码的加载模块，将压栈保存漏洞函数调用时的寄存器状态信息，并通过漏洞函数入口地址查找Patch List，得到对应的第二修复代码、漏洞修复模式和执行指令，最后执行第二修复代码。
6.一种针对嵌入式物联网设备漏洞的热修复装置，其特征在于，包括：
信息获取模块，用于获取物联网设备待修复的漏洞信息；
代码获取模块，用于基于所述漏洞信息不同的漏洞类型选择对应的漏洞修复模式，根据所述漏洞修复模式从服务器中获取第一修复代码和第一修复代码配置文件；
代码编译模块，用于基于所述第一修复代码和第一修复代码配置文件对所述第一代码进行编译，生成第二修复代码和所述第二修复代码的配置信息；以及，
漏洞修复模块，用于基于所述配置信息和所述漏洞修复模式，对所述第二修复代码执行不同的指令进行所述漏洞信息的修复。
7.根据权利要求6所述的装置，其特征在于，所述漏洞修复模式，包括：第一修复模式和第二修复模式，所述第一修复模式包括对所述第一修复代码执行漏洞函数检查参数是否合法，若是，则退出所述第一修复代码，继续执行漏洞函数；所述第二修复模式包括对所述漏洞函数或代码段进行替换。
8.根据权利要求7所述的装置，其特征在于，所述代码获取模块，还用于：
利用所述第一修复模式进行第一修复代码编写，在所述第一修复代码执行时根据不同的操作码进行对应操作处理；以及，
利用所述第二修复模式进行所述第一修复代码编写，替换原有函数或漏洞代码段，修复代码将原市代码的函数调用部分进行替换，同时调用本地C函数获取信息。
9.根据权利要求6所述的装置，其特征在于，所述代码编译模块，包括：
固定触发指令子模块，用于通过在漏洞函数入口插桩以对漏洞函数执行流的拦截，拦截成功后进入对应的处理函数，在所述处理函数中调用执行第二修复代码；
动态触发指令子模块，用于在硬件调试寄存器中的地址被匹配中后进行地址重映射，通过REMAP Table进行指令替换，将目标指令替换为跳转指令，并跳转到对应的处理函数；以及，在硬件调试寄存器中的地址匹配中后，不进行指令替换，触发硬件异常处理流程，对异常数据进行处理，将中断时的CPU寄存器状态压栈，之后再执行第二修复代码。
10.根据权利要求6所述的装置，其特征在于，所述装置，还包括，代码加载模块，用于当检测到漏洞信息时调用漏洞函数，在执行第一条指令之前拦截漏洞信息，触发第二修复代码，将产生的控制流导入修复代码的加载模块，将压栈保存漏洞函数调用时的寄存器状态信息，并通过漏洞函数入口地址查找Patch List，得到对应的第二修复代码、漏洞修复模式和执行指令，最后执行第二修复代码。
CN202210948370.2A 2022-08-09 2022-08-09 一种针对嵌入式物联网设备漏洞的热修复方法及装置 Active CN115268983B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202210948370.2A CN115268983B (zh) 2022-08-09 2022-08-09 一种针对嵌入式物联网设备漏洞的热修复方法及装置
US18/446,227 US20240053978A1 (en) 2022-08-09 2023-08-08 Hotpatch method for vulnerabilities in embedded iot devices

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210948370.2A CN115268983B (zh) 2022-08-09 2022-08-09 一种针对嵌入式物联网设备漏洞的热修复方法及装置

Publications (2)

Publication Number Publication Date
CN115268983A true CN115268983A (zh) 2022-11-01
CN115268983B CN115268983B (zh) 2023-04-07

Family

ID=83748514

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210948370.2A Active CN115268983B (zh) 2022-08-09 2022-08-09 一种针对嵌入式物联网设备漏洞的热修复方法及装置

Country Status (2)

Country Link
US (1) US20240053978A1 (zh)
CN (1) CN115268983B (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102982277A (zh) * 2012-12-24 2013-03-20 广东威创视讯科技股份有限公司 一种实现嵌入式***软件补丁的方法和***
CN109117169A (zh) * 2016-12-12 2019-01-01 百度在线网络技术（北京）有限公司 用于修复内核漏洞的方法和装置
CN111967022A (zh) * 2020-09-07 2020-11-20 苏州思必驰信息科技有限公司 安全漏洞修复方法和装置
US20210365567A1 (en) * 2021-08-04 2021-11-25 Haoyu Chen Device and method for repairing security vulnerability of computer application software
CN113760339A (zh) * 2020-07-01 2021-12-07 北京沃东天骏信息技术有限公司 漏洞修复方法和装置
CN114500352A (zh) * 2021-12-28 2022-05-13 创业慧康科技股份有限公司 用于医疗物联网消息路由装置的插件热更新***及方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102982277A (zh) * 2012-12-24 2013-03-20 广东威创视讯科技股份有限公司 一种实现嵌入式***软件补丁的方法和***
CN109117169A (zh) * 2016-12-12 2019-01-01 百度在线网络技术（北京）有限公司 用于修复内核漏洞的方法和装置
CN113760339A (zh) * 2020-07-01 2021-12-07 北京沃东天骏信息技术有限公司 漏洞修复方法和装置
CN111967022A (zh) * 2020-09-07 2020-11-20 苏州思必驰信息科技有限公司 安全漏洞修复方法和装置
US20210365567A1 (en) * 2021-08-04 2021-11-25 Haoyu Chen Device and method for repairing security vulnerability of computer application software
CN114500352A (zh) * 2021-12-28 2022-05-13 创业慧康科技股份有限公司 用于医疗物联网消息路由装置的插件热更新***及方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
RYOHEI KOIZUMI, RYOICHI SASAKI: "Study on Countermeasures Using Mitigation Software against Vulnerability Attacks", 《IEEE》 *

Also Published As

Publication number Publication date
CN115268983B (zh) 2023-04-07
US20240053978A1 (en) 2024-02-15

Similar Documents

Publication Publication Date Title
US10698668B1 (en) Custom code transformations during compilation process
US7784044B2 (en) Patching of in-use functions on a running computer system
US8589889B2 (en) Apparatus and method of detecting errors in embedded software
CN102402427B (zh) 一种Java应用程序的更新方法及装置
Arnold et al. Ksplice: Automatic rebootless kernel updates
US6112025A (en) System and method for dynamic program linking
CN109614165B (zh) 一种com组件的多版本并行运行方法和装置
CN106020873B (zh) 补丁包加载方法及装置
US10795659B1 (en) System and method for live patching processes in user space
US20110307858A1 (en) Pre-compiling hosted managed code
Pukall et al. JavAdaptor—Flexible runtime updates of Java applications
WO2015117434A1 (zh) 补丁的制作方法及装置、补丁的激活方法及装置
WO2012100535A1 (zh) 超级内核组件的升级方法和计算机***
US8549320B2 (en) Verifying loaded module during debugging
CN112099880B (zh) 场景驱动的应用程序约减方法和***
CN111880804A (zh) 应用程序代码的处理方法及装置
US20080127118A1 (en) Method and system for dynamic patching of software
Zhang et al. Embroidery: Patching vulnerable binary code of fragmentized android devices
CN112363726A (zh) 一种内核模块的跨内核版本编译方法及***
CN113454606B (zh) 不同编译的可执行文件之间的软件检查点-恢复
CN111625296B (zh) 一种通过构建代码副本保护程序的方法
US20120222023A1 (en) Automatic runtime dependency lookup
CN115268983B (zh) 一种针对嵌入式物联网设备漏洞的热修复方法及装置
JP2009015428A (ja) プログラム更新方法、情報処理装置、プログラムおよび記録媒体
CN113220303A (zh) 一种内核模块的编译方法和***

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant