AuroraOS移动操作系统的开发人员 （Sailfish操作系统的一个分支，由Open Mobile Platform公司开发） 共享了一个漏洞修复程序 他们在memcpy中检测到。 消除严重漏洞（CVE-2020-6096) 在Glibc中，仅在ARMv7平台上表现出来。
有关该漏洞的信息已于XNUMX月披露。，但直到最后几天，这些修补程序仍无法使用，尽管该漏洞被指定为高度危险，并且 有一个可以利用的漏洞利用原型 可以组织代码的执行。
漏洞利用已准备就绪 在处理过程中在memcpy（）和memmove（）函数中起作用 对于某些格式化的数据。
Glibc的重要性在于，除了几乎所有程序都使用该库之外，该库还定义了系统调用和其他基本功能。
关于问题
表现出脆弱性 在执行memcpy（）和memmove（） ARMv7的汇编语言 这是由于对确定区域大小的参数的负值处理不正确引起的。
开始开发补丁程序的问题 当SUSE和Red Hat宣布他们的平台不受影响时 因为这个问题，因为它们没有为7位ARMv32系统编译，也没有参与创建补丁。
许多嵌入式发行版的开发人员显然都信任Glibc团队，他们也没有积极参与补丁的准备。
解决方案
华为提供了一个选择 补丁 马上解决问题， 它试图用无符号的类似物（blo和bhs）替换对有符号的操作数（bge和blt）进行操作的汇编程序指令。
Glibc维护者开发了一个测试套件 在发生错误后测试不同的条件 原来华为的补丁不适合 并且它不会处理输入数据的所有可能组合。
考虑到 AuroraOS具有用于ARM的32位版本，其 开发人员决定自行关闭漏洞 并向社区提出解决方案。
困难在于，有必要编写一个有效的实施方案 函数的汇编程序，并考虑输入参数的几个选项。
使用未签名的指令重写了实现。 补丁虽然很小，但主要问题是保持执行速度并消除了memcpy和memmove函数的性能下降，同时保持了与输入值所有组合的兼容性。
在XNUMX月初，准备了两种解决方案， 通过了Glibc的维护测试框架和Aurora的内部测试套件。 3月XNUMX日，选择并提交了一个选项 到Glibc邮件列表。
一周后，又提出了另一种类似的方法，该方法解决了华为先前试图解决的多体系结构实施中的问题。 考虑到补丁的重要性，经过一个月的测试和认证。
8月XNUMX日，主分支接受了修复程序 即将发布的glibc 2.32版本。 该应用程序包括两个补丁：
- 第一个用于内存建立的ARMv7 Multiarch应用程序
- 第二个用于ARM的memcpy（）和memmove（）的通用汇编程序实现。
该问题影响数百万个ARMv7 Linux设备 如果没有适当的更新，则所有者有将它们连接到网络的风险（接受不受大小限制的输入的网络上可用的服务和应用程序可能会受到攻击）。
例如，一个准备好的漏洞利用 由研究人员 发现该漏洞显示了如何攻击http服务器 通过传输非常大的GET请求并获得对该系统的root访问权限，将其集成到汽车信息系统中。
Debian和Ubuntu的软件包解决方案尚未发布 y 漏洞仍未得到纠正 从公开披露之日起将近两个月，从Glibc开发人员收到通知之日起将近五个月。