正在阅读:

安全团队怒斥手机厂商,系统漏洞为何被有意忽视

扫一扫下载界面新闻APP

安全团队怒斥手机厂商,系统漏洞为何被有意忽视

事实上,系统更新一直以来都是Android生态中的一个痛点。

文|三易生活

如果有留意过手机厂商的系统更新日志,想必就会发现,“修复漏洞”是一个会高频率出现的词。而对于经常关注科技资讯的朋友来说,对于“XX公司被爆在XX软件上存在漏洞,导致XX人或设备受到影响”这类消息,应该也是熟悉得不能再熟悉了。

此前在今年夏季,来自谷歌的互联网安全团队ProjectZero发现了多个来自ARM Mali GPU的漏洞。看起来这只是网络安全领域平平无奇的一件小事,但在数月后的却引发了不小的波澜。

日前,在ProjectZero团队发布的最新博客中,将矛头指向了Android手机厂商,并措辞严厉地谴责了这些厂商的偷懒行为,其中甚至就连谷歌自家的Pixel系列机型也没有放过。而原因其实也很简单,因此Android手机厂商并没有严肃对待这一系列的漏洞,在安全更新上“偷奸耍滑”了。

此前,ProjectZero团队陆续发现了5个有关ARM处理器中Mali GPU的漏洞,其中编号为CVE-2022-36449的漏洞可以让非特权用户获得对只读存储器的写入权限。用相关研究人员的话来说,成功利用该漏洞可以允许攻击者获得执行本机代码的权限,进而获得对系统的完全访问,并绕过Android的权限模型,允许更广泛的访问用户数据。

在收到了来自ProjectZero的漏洞报告后,ARM方面在今年7-8月期间修复了这些问题,发布了安全公告、并公布了修复的源代码。然而在ARM做到了应该做的事情后,手机厂商却几乎都无动于衷。Project Zero团队日前表示,在ARM修复了这些漏洞几个月后,他们使用搭载了Mali GPU的测试设备仍然会受到这些问题的影响,CVE-2022-36449在几乎任何手机厂商的安全公告中都没有被提到。

要知道,CVE-2022-36449漏洞影响的是ARM过去三代的Mali GPU架构(Midgard、Bifrost,以及Valhall),其范围覆盖了从目前出货的谷歌Pixel 7系列,一直可以向前追溯到2016年的三星Galaxy S7,除了使用自研GPU的高通外,其他面向Android手机厂商供货的芯片厂商均牵涉其中。换而言之,几乎每一个Android手机厂商旗下可能都有数以百万量级的受影响设备存在。

如此看来,这次的事件不就是Android手机厂商将用户设备的安全当作儿戏吗。但其实谷歌估计也很无奈,目前Android系统的安全补丁更新是以月为单位,并且Android的月度安全更新也是公开发布的。然而Android手机厂商也有话要说,月度安全更新归更新,但将安全更新应用到自家的产品上则又是另外一回事。

事实上,系统更新一直以来都是Android生态中的一个痛点,核心原因就是相比于封闭的苹果iOS体系,Android阵营的参与者要多得多,这既是当年Android得以快速铺开的优势,也是如今限制Android机型及时更新的问题所在。抛开双方都要面对的开发者适配应用问题,Android阵营在系统更新上就有谷歌、芯片厂商,以及手机厂商三方加入,并且后面两者的产品线都相当复杂,所以也造成了Android大版本更新的难度要远胜过iOS。

尽管谷歌多年前就开始着手提升Android机型的系统更新速度,从Android 8开始,新增的Project Treble就将硬件驱动与系统分离,从此手机厂商可以为手机单独推送新的Android版本、而不需要重新适配驱动。而在Android 10中引入的Project Mainline更是将系统功能模块化,让更上游的供应商可以更细化地提供具体的功能更新。

索尼方面在Android 8发布后就绘制了Android系统升级的流程图,并强调Project Treble能够将系统升级推送的流程再减少3-4步。但他们没有告诉用户的是,即便减少了这几步,Android系统更新的流程依然十分复杂。就以此次的ARM驱动为例,在ARM完成了漏洞修复、并公开源代码后,手机厂商并不能像我们接收系统OTA更新那样简单的进行修复,而是需要调试驱动以适配自己修改过的ROM。

毕竟Project Treble也只是让手机厂商可以为手机单独推送新的Android版本,而不需要重新适配驱动,可这一次恰恰是驱动出了问题。涉及到GPU驱动这样底层的功能,Android手机厂商是需要调试BSP(板级支持包)的,这是因为Android系统的HAL(硬件抽象)层需要加载BootLoader,而加载BootLoader则依赖于BSP。但需要注意的是,HAL中关于各硬件的参数是十分重要的商业机密,所以也导致HAL往往存在于User Space中,而非在内核中。

更为遗憾的是,在解耦硬件驱动与系统的Project Treble扩展项目上,谷歌方面选择了与高通合作、而非联发科。Project Treble的“无追溯性原则”目前只能影响到高通骁龙移动平台,为此高通开发了自己的通用系统映像系统“QSSI”,其能够与谷歌的AOSPGSI一样与不同的SoC兼容。换而言之,如果此次是高通SoC的Adreno GPU出现漏洞,可能情况都要好得多。

除此之外,就算是同型号机型往往还会有不同的版本,例如三星的Galaxy S系列在中国、日本、美国和南美是使用高通骁龙平台,但在欧洲和韩国则使用的是自家的Exynos主控。再加上运营商定制版本的存在,仅仅一款设备就足以让手机厂商的运维团队焦头烂额,更别提此次Mali GPU影响的是过去整整5年间的产品,如此大的规模也足以让手机厂商感到绝望。

所以只能说,如此庞大的工作量让手机厂商不得不选择“摆烂”。而想要杜绝类似的事件再次发生,只能是谷歌与ARM方面加强合作,效仿高通来建立一个自己的通用镜像系统,以此来加快更新的部署才行。

本文为转载内容,授权事宜请联系原著作权人。

评论

暂无评论哦,快来评价一下吧!

下载界面新闻

微信公众号

微博

安全团队怒斥手机厂商,系统漏洞为何被有意忽视

事实上,系统更新一直以来都是Android生态中的一个痛点。

文|三易生活

如果有留意过手机厂商的系统更新日志,想必就会发现,“修复漏洞”是一个会高频率出现的词。而对于经常关注科技资讯的朋友来说,对于“XX公司被爆在XX软件上存在漏洞,导致XX人或设备受到影响”这类消息,应该也是熟悉得不能再熟悉了。

此前在今年夏季,来自谷歌的互联网安全团队ProjectZero发现了多个来自ARM Mali GPU的漏洞。看起来这只是网络安全领域平平无奇的一件小事,但在数月后的却引发了不小的波澜。

日前,在ProjectZero团队发布的最新博客中,将矛头指向了Android手机厂商,并措辞严厉地谴责了这些厂商的偷懒行为,其中甚至就连谷歌自家的Pixel系列机型也没有放过。而原因其实也很简单,因此Android手机厂商并没有严肃对待这一系列的漏洞,在安全更新上“偷奸耍滑”了。

此前,ProjectZero团队陆续发现了5个有关ARM处理器中Mali GPU的漏洞,其中编号为CVE-2022-36449的漏洞可以让非特权用户获得对只读存储器的写入权限。用相关研究人员的话来说,成功利用该漏洞可以允许攻击者获得执行本机代码的权限,进而获得对系统的完全访问,并绕过Android的权限模型,允许更广泛的访问用户数据。

在收到了来自ProjectZero的漏洞报告后,ARM方面在今年7-8月期间修复了这些问题,发布了安全公告、并公布了修复的源代码。然而在ARM做到了应该做的事情后,手机厂商却几乎都无动于衷。Project Zero团队日前表示,在ARM修复了这些漏洞几个月后,他们使用搭载了Mali GPU的测试设备仍然会受到这些问题的影响,CVE-2022-36449在几乎任何手机厂商的安全公告中都没有被提到。

要知道,CVE-2022-36449漏洞影响的是ARM过去三代的Mali GPU架构(Midgard、Bifrost,以及Valhall),其范围覆盖了从目前出货的谷歌Pixel 7系列,一直可以向前追溯到2016年的三星Galaxy S7,除了使用自研GPU的高通外,其他面向Android手机厂商供货的芯片厂商均牵涉其中。换而言之,几乎每一个Android手机厂商旗下可能都有数以百万量级的受影响设备存在。

如此看来,这次的事件不就是Android手机厂商将用户设备的安全当作儿戏吗。但其实谷歌估计也很无奈,目前Android系统的安全补丁更新是以月为单位,并且Android的月度安全更新也是公开发布的。然而Android手机厂商也有话要说,月度安全更新归更新,但将安全更新应用到自家的产品上则又是另外一回事。

事实上,系统更新一直以来都是Android生态中的一个痛点,核心原因就是相比于封闭的苹果iOS体系,Android阵营的参与者要多得多,这既是当年Android得以快速铺开的优势,也是如今限制Android机型及时更新的问题所在。抛开双方都要面对的开发者适配应用问题,Android阵营在系统更新上就有谷歌、芯片厂商,以及手机厂商三方加入,并且后面两者的产品线都相当复杂,所以也造成了Android大版本更新的难度要远胜过iOS。

尽管谷歌多年前就开始着手提升Android机型的系统更新速度,从Android 8开始,新增的Project Treble就将硬件驱动与系统分离,从此手机厂商可以为手机单独推送新的Android版本、而不需要重新适配驱动。而在Android 10中引入的Project Mainline更是将系统功能模块化,让更上游的供应商可以更细化地提供具体的功能更新。

索尼方面在Android 8发布后就绘制了Android系统升级的流程图,并强调Project Treble能够将系统升级推送的流程再减少3-4步。但他们没有告诉用户的是,即便减少了这几步,Android系统更新的流程依然十分复杂。就以此次的ARM驱动为例,在ARM完成了漏洞修复、并公开源代码后,手机厂商并不能像我们接收系统OTA更新那样简单的进行修复,而是需要调试驱动以适配自己修改过的ROM。

毕竟Project Treble也只是让手机厂商可以为手机单独推送新的Android版本,而不需要重新适配驱动,可这一次恰恰是驱动出了问题。涉及到GPU驱动这样底层的功能,Android手机厂商是需要调试BSP(板级支持包)的,这是因为Android系统的HAL(硬件抽象)层需要加载BootLoader,而加载BootLoader则依赖于BSP。但需要注意的是,HAL中关于各硬件的参数是十分重要的商业机密,所以也导致HAL往往存在于User Space中,而非在内核中。

更为遗憾的是,在解耦硬件驱动与系统的Project Treble扩展项目上,谷歌方面选择了与高通合作、而非联发科。Project Treble的“无追溯性原则”目前只能影响到高通骁龙移动平台,为此高通开发了自己的通用系统映像系统“QSSI”,其能够与谷歌的AOSPGSI一样与不同的SoC兼容。换而言之,如果此次是高通SoC的Adreno GPU出现漏洞,可能情况都要好得多。

除此之外,就算是同型号机型往往还会有不同的版本,例如三星的Galaxy S系列在中国、日本、美国和南美是使用高通骁龙平台,但在欧洲和韩国则使用的是自家的Exynos主控。再加上运营商定制版本的存在,仅仅一款设备就足以让手机厂商的运维团队焦头烂额,更别提此次Mali GPU影响的是过去整整5年间的产品,如此大的规模也足以让手机厂商感到绝望。

所以只能说,如此庞大的工作量让手机厂商不得不选择“摆烂”。而想要杜绝类似的事件再次发生,只能是谷歌与ARM方面加强合作,效仿高通来建立一个自己的通用镜像系统,以此来加快更新的部署才行。

本文为转载内容,授权事宜请联系原著作权人。