企业动态

当前位置/ 首页/ 要闻频道/企业动态/ 正文

可以使运行所谓安全的三星Knox安全套件的三星手机受到攻击

谷歌的零项目团队已经验证了许多漏洞,可以使运行所谓安全的三星Knox安全套件的三星手机受到攻击。该博客指出,所有漏洞已传递给三星,三星实际上在一月份的软件更新中为其发布了修复程序。背景作为三星推出的三星Knox安全软件套件的一部分,在Android应用程序和称为Hypervisor的内核之间有一块软件。这可以用作进一步保护Android设备的附加层。三星Knox系统管理程序简称为“ 实时内核保护 ”或RKP,我将在本文的其余部分中引用它。

内核位于Android软件堆栈中的RKP下方,而设备上运行的应用程序位于顶部。RKP背后的想法是为设备提供额外的安全性,因为应用程序向内核发出的所有请求(内存和其他资源)都必须先通过Knox,这会尝试检测应用程序是否在做它不应该做的事情。 t。RKP还通过增加一层模糊性来提供安全性,以隐藏应用程序可能用来破坏设备的敏感信息。

该博客文章 深入探讨了Android内存,RKP和操作系统在一般情况下的工作方式,因此我对其进行了精简和简化,以快速概述所发现的内容。不过,我鼓励您有空的话阅读全文,因为这很有启发性。

利用#1:

KASLR或内核地址空间布局随机化是在启动时以随机数量更改内核代码在内存中的位置的过程。每次启动设备时,内核都会加载到不同的地址空间(内存中的区域)。这样做的想法是使查找内核代码的位置变得更加困难以对其进行攻击,因为每次启动后,内核代码都会在内存中随机“移位”一定数量。这听起来似乎是阻止潜在攻击者的重要一步,但是最近的研究表明,实际上可以无需软件漏洞或漏洞就可以击败它,因为KASLR实际上很难以强大的方式对付本地攻击者。

对于RKP软件,绕过KASLR的能力实际上比上面提到的研究要简单。指针引用所有android设备的内存,并且为了保护设备免受攻击,每当android设备打印或输出(无论是屏幕还是文件以进行日志或调试)时,指针引用均被匿名化,从而无法找到读取输出时指针实际指向的位置。

将内存指针想像成指向某个位置的路牌,然后将匿名化视为模糊了该指针。就像电视一样,匿名化是在拍摄之后进行的,Android也会在输出时且仅在正确配置了匿名化的情况下才应用此匿名化,并且作者声明遇到的每个设备都已正确配置了指针匿名化。这听起来好像很难破解,但是您要做的就是找到一个内核开发人员没有匿名(模糊)的单个指针(认为路牌)(请注意,这不是您的一般Android应用程序开发人员)当指针写入日志或其他位置(例如屏幕或文件)时。

因此,如果您找到未匿名的指针,则可以将内核的随机地址偏移计算为两者之间的差。有趣的是,作者在内核中找不到可利用的指针,但在RPK内找到了它,开发人员忘记了在调试(记录)输出中将指针匿名化,这是通过错字的方式造成的。要匿名化Android中的指针,您必须使用特殊的代码,事实证明RPK开发人员错误地使用了小写的“ k”而不是大写的“ K”。因此,找出内核代码的随机移位量并对其进行攻击是相对简单的。

利用#2:

下一个漏洞利用更为复杂:Samsung Knox通过在设备内存中应用一组规则来阻止恶意代码,从而保护您的设备。规则如下:

除内核代码外,所有页面(内存中的代码)都标记为“ Privileged Execute Never”(意味着此处的代码永远不会运行)

内核数据页(内存中程序使用的数据)永远不会标记为可执行(因此此处的代码永远不会运行)

内核代码页(内存中的代码)永远不会标记为可写(因此,没有恶意代码可以更改它)

在第2阶段转换表(位于应用程序和内核之间的表,以进一步防止应用程序知道真实的内存位置)中,所有内核页面都标记为只读。

对于应用程序,所有内存转换条目都标记为只读。

我们将重点关注规则3,因为这是作者发现上述规则的执行存在问题的地方。RPK实际上确实将内核的内存标记为只读,但是由于对KASL的疏忽,发现了一个漏洞,这导致将代码写入所谓的“只读”部分。为了在启动时混淆内核的位置,将内存分配给内核,但是此内存量比内核的文本段大得多。通过分配更多的内存,将很难找到可能在任何地方的实际内核代码,并且正如我们上面所看到的,它在设备的每次启动时都会随机移动。

作者能够确认内核使用的内存确实标记为“只读”,但是用于隐藏内核的那部分大容量内存的其余部分并未标记为“只读”。这是因为RKP在应用KASLR幻灯片之后仅保护包含内核文本的区域。

利用#3

在第三个漏洞利用中,作者能够访问应限制为只读的另一个内存区域。RKP保护内存,并使用系统管理程序配置寄存器(HCR)控制关键内核操作。HCR的要点是允许有效和真实的内核操作访问寄存器并阻止恶意攻击。它通过检查对控制虚拟化功能的寄存器的调用来实现。HCR被配置为阻止特定的操作,这些操作通常会被处理,从而允许RKP选择是允许还是不允许请求。

在此漏洞利用中,HCR控制并未覆盖两个非常重要的寄存器。作者深入研究了《 ARM参考手册》,发现第一个寄存器使他基本上可以关闭RKP的应用程序。“ 用于EL1的系统控制寄存器(SCTLR_EL1)提供对系统(包括内存系统)的顶级控制。” 在理想情况下,应用程序将使用通过RKP映射的内存,以便RKP可以控制应用程序可以访问的内容。但是,关闭此寄存器可以禁用RKP通过有效地使设备恢复到安装RKP之前的运行方式–意味着该设备无需RKP提供的额外安全性即可映射到物理内存。反过来,这意味着作者可以读写最初被RKP软件正确阻止的内存。

遗漏的第二个寄存器产生了更细微的影响,但最终同样破坏了安全性。EL1的转换控制寄存器(TCR_EL1)寄存器直接与应用程序称为页面的内存量有关。RKP被硬编码为4kb的页面大小,因为AARCH64 Linux内核(例如Android)使用4KB的翻译大小。有问题的寄存器(TCR_EL1)将ARM芯片组设置为要返回的内存大小。事实证明,此寄存器不受HCR保护,因此攻击者可以在作者将其更改为64kb页面大小时对其进行更改。

这意味着当RKP满足请求时,现在可访问的实际内存量为64kb,而不是4kb。原因是ARM芯片组仍控制页面大小,被漏洞利用程序设置为64kb。由于RKP保护内存不被写入(作为漏洞2中列出的规则的一部分),因此实际上仍对内存进行了保护。但是这里有个问题–由于RKP被硬编码为4kb,在更新寄存器时它不会更改为64kb页面大小,因此只有前4kb的存储器受到保护,攻击者可以用剩下的60kb做任何他想做的事情。

利用#4

作者展示的最后一个漏洞是引用RKP软件所在的内存,因此攻击者可以攻击RKP软件本身。阻止此类攻击的一种技巧,Linux内核也使用这种方法,即从虚拟内存地址空间取消映射您的程序,以使任何应用程序都无法对其进行攻击,因为它们无法引用它。

请记住,内存是关于将物理内存映射到虚拟内存的指针和表的。按照这种攻击的常规防御,RKP会取消自身的映射,因此无法对其进行攻击。但是,在内核不提供此类功能的地方,RKP确实允许将一块内存映射并标记为“读/写”。唯一的检查是它不是底层内核本身,因为RKP不会检查请求映射的地址是否是RKP本身驻留在内存中的区域。基本上,RKP 允许其自身重新映射到应用程序可以访问的地址空间,并且作为副作用,内存会自动标记为“读/写”,因此攻击者现在可以根据需要使用内存。

结论

上面列出的四个漏洞利用的最大问题之一是作者提到由于基本的Android内核缺少功能而很难执行这些漏洞。具有讽刺意味的是,安全的RKP虚拟机管理程序提供了执行攻击所需的所有工具。它表明有时好意的软件会导致比解决方案更多的问题,而且我们很幸运,像Gal Beniamini这样的人愿意沾沾自喜,并测试文档是否与软件的实际功能匹配。

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。