风险分析：Linux Kernel权限提升漏洞（CVE-2023-32233）以及个人思考

原创

infrado开荒运维 2023-05-29 11:01:58 ©著作权

文章标签 cve linux 文章分类 网络安全

©著作权归作者所有：来自51CTO博客作者infrado开荒运维的原创作品，如需转载，请与作者联系，否则将追究法律责任

前言

过去几年由于从业需要，笔者每日保持关注数个领域相关的安全漏洞，并在所处的相关小圈子内建立了完全公益性质的通知渠道，公开为一切需要的订阅用户无偿提供短信、电话、电子邮件方式的及时提醒；然而，xx都凉了，说这个还有个x用。虽然还在持续关注安全领域相关的信息，但是此类“说人话”的通知已经不再提供。近期有圈子力几个人通过各种方式咨询笔者CVE-2023-32233这玩意儿是什么情况，会不会导致被提权root，虚拟主机、docker等容器是不是存在安全隐患，甚至三年不联系的人依然通过OICQ问我这漏洞需要怎么处理，作为一个曾经日理万核的开荒运维，因此特作此文。

至于如何比较全面的高效及时的获取这类信息，而不是像脏牛漏洞、心脏出血这种漏洞达到人尽皆知规模而我们作为互联网安全最前线的却从完全不关心的朋友问起才知道这些，日后有机会就单独起一篇文章介绍一些常见的订阅地址，以及搜寻这些信息的方式。授人以鱼不如授人以渔，不过我也会把我需要用到的列表、新闻门户之类的都列出来，基本覆盖了虚拟主机、云服务器、SAAS、常见的WindowsLinux以及运维、日常办公常用软件的安全信息，手头没有比较原始的，就等有机会吧。毕竟VMware ESXi，kvm虚拟化，Office，Xshell之类的曾经很常用的相关资料我近些年不再需要也没有关注。

我主要关注并运用常见虚拟化kvm\hyper-v\vmware以及常用操作系统windows\linux，以及Java、python、php运行环境存在的风险，类似从业者例如IDC相关可以直接跟我一样，订阅相同的信息来源，应该够了，至少从无到有嘛，如果有大佬们有更好的建议补充下自然更好。Java、交换机之类的平时不会有什么重大的问题，一出问题就是大事，交换机这种为发包而生的基础设施一旦再来一个远程大洞，还是免不了深受其害，圈子里有人说那玩意儿十年了，不过如果是log4j这种呢？这玩意儿横扫的破坏力仿佛还在昨日吧。

我承诺，搞上服务器这十来年，我没有丢过任何不该被损坏的他人数据，而且我也会尽我所能的保持。0day我解决不了，不过就拿印象深刻的log4j来说，至少我这第一时间处理，木有被利用上。

新闻摘要

<?php
$withad='';//各厂商一般都在这里打了广告，笔者不喜欢特来调侃下。教育性质的可能没有，也可能有
$withwaf='hei_ke_gong_ji';//溜一下关键字
echo '近日'.$withad.'监测到Linux Kernel权限提升漏洞（CVE-2023-32233）的PoC/EXP在互联网上公开。
Linux内核某些受影响版本中，由于匿名集处理不当，当处理批处理请求时
Netfilter nf_tables(net/netfilter/nf_tables_api.c)中存在use-after-free漏洞，可利用该漏洞对
内核内存执行任意读写操作，成功利用该漏洞的本地用户可获得root权限或导致系统崩溃。
建议受影响用户做好资产自查以及预防工作，以免遭受'.$withwaf.'。';

天下文章一大抄，可能存在一些“Linux Kernel是一款由Linux Kernel组织开发维护的免费开源操作系统内核。”类似的开头。至于受到影响的内核版本，从各家文章的出处“不太严谨”的字体来说，显然是有多个版本。

部分编辑格式化了内容，呈现为“v5.1-rc1 <= Linux Kernel 版本<= 6.3.1”，而不少作者并没有，“Linux Kernel 版本<= 6.3.1”部分采用的是宋体，而到了“v5.1-rc1 <= ”部分字样，就变成了微软雅黑，甚至字体大小不同，显然这是有至少两个版本形成的描述。而且此后续增加的这段描述，其实相当不严谨不负责任。至少相当的热心折腾玩家门分享反馈2.6.32/3.10之类的成熟的旧内核，以及4.4/4.9之类的相对新一些的内核也能复现出漏洞，从RH\DEB系相对权威的渠道也都能找到低版本存在问题的表述。比如这里：https://security-tracker.debian.org/tracker/CVE-2023-32233

风险分析与应对

有一些不太严谨的但是相当权威性质的发布渠道已经描述此漏洞为“已修复状态”，并没有给出一些可行性的操作，或者只是简单的说了升级操作系统内核的版本不低于多少。但是绝大多数Linux操作系统都是使用特定的发行版，而不是自行攒一个操作系统出来，大厂能自行维护一个相对安全可靠的发行版内部使用或者对外提供，但是普通小用户，包括不少商业用户的运维技能、对安全风险防范的意识甚至不及笔者一个小小的开荒运维的零头，受影响的情况列在下方了，如果你正在运行中的操作系统完全匹配以下全部条款，不要犹豫，对你的计算机安全来说属于致命安全风险，请立刻解决：

内核没有经过修复的，比如国内比较喜闻乐见的RHEL 7并不安全
顾虑普通用户提权，获取到root权限后格盘、关机、加backdoor等一些行为
普通用户能运行一些程序，类似虚拟主机这种
操作系统内核模块 nf_tables 已加载
用户命名空间可用。跟上面一条一样看不懂的别急，往下看

A 内核

笔者大量使用RH系操作系统，但是对待此漏洞的处理上，红帽没有什么处理，截至目前，官方bugzilla最后一条内容如下。官方地址：https://bugzilla.redhat.com/show_bug.cgi?id=2196105

Hi, is there any available forecast on when fixes will be issued? The mitigation of disabling userns is not an option for us.
Are we talking days or weeks?

当前截图在文章结尾。由于完整截图较长。

实际上红帽并没有无视，但是本身就已经处于延长支持状态的，国内使用相当普遍的RHEL 7，红帽明确此版本操作系统受到影响，但是并没有给予修复，只是提供了两个缓解策略。用大白话来说，就是不修复内核的情况下，提供了避免漏洞被利用的两个方式。参见官方地址： https://access.redhat.com/security/cve/CVE-2023-32233

风险分析：Linux Kernel权限提升漏洞（CVE-2023-32233）以及个人思考_cve

表格注释含义：如果未经测试，则默认为受到影响。

由上图可以得知，RHEL 6的内核是确定不受影响的，相对可以推导centos6就像曾经很多漏洞一样，因为使用了历史悠久的2.6.32内核躲过一劫。当然，2.6.32内核已经在七年前已经结束支持，而使用这些内核的主流操作系统也已经全部结束一切技术支持了，对我们一般场景来说一般没有特殊的支持、付费的支持等例外。而RHEL7，或者centos 7本身的内核实际上是否有风险（3.10）？系统内置但是没有启用的ML（main-line） RT内核是不是有风险？从图片我们不得而知。而DEB系发行版可能会相对安全，当然这是相对的，从我的经验来说debian以及armbian之类的内核版本比较新，同时在提供内核修补更新的速度上来说也不慢，一般来说能吃上更新。而红帽只是解决了RHEL 8以及RHEL 9的顾虑，如果有保持内核更新的话。

风险分析：Linux Kernel权限提升漏洞（CVE-2023-32233）以及个人思考_cve_02

图源：debian官方https://security-tracker.debian.org/tracker/CVE-2023-32233

如果你愿意，你也可以参考SUSE，或者乌班图。

B 损失

如果你不会有后果，那么可以直接往C章节。

基于RHEL7的下游操作系统例如CentOS 7类似的RH7系操作系统，当然从可行性的角度来说，中小企业场景可能比centos7更加普遍，甚至是centos7.0?centos6.5?centos5.11?centos5.8?全国进那么多IDC机房托管过机器，通过机房常用什么光盘，目前还流行什么系统光盘、做什么系统，显然对更多的用户而言，计算机安全并没有那么重要。甚至不少机房，留言“做系统”的默认含义仍然是通过一些来路不明的U盘启动来路不明的PE，用不知道什么版本的GHOST方式往操作系统的C分区写入来路不明的2003系统镜像文件，部署完系统之后，3389端口不做任何防护，整个机房全部的客户默认用相同的一个，或者多个常用密码选一个。对于这部分用户来说，此类文章没有任何意义。从我听说的情况来说，无非就是服务器被控制，出现以下的一些情况，并没有意料之外的太出格的事情，至于会不会出现更严重的情况，欢迎大佬们补充：

文件被加锁。而且比较重要，甚至几十个几百GB。不贵的，0.05-0.5个BTC不等的价格。有些公司被锁住的文件看起来还比较重要，如果不给，实际直接损失也就上千万而已，顶多老板不干了。一般嘛找个大佬，花个几万，甚至花个几百几千就解决了（很可能几百块解决的大佬就是用网上很容易就下载的软件就能解锁的，当然被锁定了也不要乱找，无责任描述，下载到风险程序后果自负）非IDC从业者，但是向我求助的熟悉或者不熟悉的网友真的有点多。我给解决了一些，但是不要期望我能解决全部的加密方式。有一些折腾起来还是比较费劲的。至于最原始的版本我是没见过的，以及腾讯电脑管家/360提供的LSZ解密工具其实应该只能对这玩意儿有效。我也只成功过小一半，大部分还是没什么法子的。至于其他人是怎么解决的我说不好。毕竟都是义务帮忙，我再也不想大半夜帮人折腾到通宵天亮，事后还听人背地里说我坑、技术差、慢了。能解决的基本上都是加密逻辑设计上有漏洞，或者保护密钥考虑不周能获得密钥或者变相一些方式得到原始文件或者压根就没有真正加密。还有一些是设计精良的非对称加密保护着的对称密钥，用这玩意儿保护住的数据，如果不是持有私钥，那么大概是帮你解密的人能通过公钥推导出私钥吧，只不过大佬比较低调跟我们不是一个世界的。毕竟在我们这个世界对撞出MD5 SHA1原文与结果相同都需要科学家绞劲脑汁，我们这个世界公开可知能操纵的量子也只是几十个而已，也或者大佬已经掌握了具有相当能力的量子计算机，已经能够轻易的颠覆现有的计算机体系，我们理解的固若金汤对他们不过是探囊取物罢了。
文件被删除。我听身边人的遭遇，顶多被删除了不到100TB的数据，全格而已，我想你也没有那么多数据。也有赔了不到30万的，东山再起罢了，还年轻。
挖上了门罗的。CPU100%而已，删不掉，一般没动数据，我见到的这种都没删。
服务器上行跑满的。不解释，甚至被机房断网了。如果是海外托管的服务器可能更严重。帮你送机器到机房的人惹上麻烦了。
其他情况我个人就没听说过了。

举个例子：比如说你的场景是类似提供SAAS，而多租户是通过cgroup、多用户、LXC、容器或者类似的方式实现隔离的，你完全可以接受一些不怀好意的用户通过这个、或者类似的漏洞获取到你的服务器root权限进行任何操作，以及接受一切后果，那么这类漏洞对你就不造成任何影响。

如果考虑损失，会产生实际损失，仅仅这一篇文章当然不够，如何养成一个相对安全的计算机卫生习惯是系统性而庞大的工程，后面有机会笔者专门写一批文章来阐述，如何真正还算安全的为有破坏力的用户提供IAAS或者SAAS所需要的安全流程准备。从这篇文章来说，可以了解一些这些关键词：计算机等保 docker逃逸漏虚拟机逃逸零信任

C 解决

内核的漏洞当然是找内核解决喽。最成熟可靠的方式就是升级内核，如果你的发行版能够提供的话。而个人维护编译内核工作量哪怕有CI之类的自动构建，在总流程上仍然是相当繁琐的，总要考虑到有总有特殊情况。至于红帽官方的评级上来看，这个漏洞其实并不致命，虽然我觉得红帽算是“不太积极”的“解决好了”，而且有“持续在跟进”，当然有大佬不满意。如果得到了内核更新的debian之类的操作系统，可以通过各自的更新方式更新内核。至于因为某些原因不得不“冻结内核”的用户，也可以考虑是否是自行维护内核对漏洞进行补丁，或者更新，也或者不受这个漏洞影响不做处理。

内核是否有漏洞查询资料可以知道，而用户是否能够运行程序就靠各位运维自己分析了。以infrado开荒运维本人的情况来说，有相当的服务器对外提供了用户运行程序的能力，从我能防范的角度来说目前用户也无法逃逸运行额外的程序，但是谁知道呢。并不是用户非root登录到系统本身才算是普通用户，举个例子如果你运行一个PHP虚拟主机，而用户自传的，或者你安装的PHP程序内置，或者有可利用的接口，不要忘了PHP可是执行在www或者apache用户下的，或者多用户，虽然是普通用户，但是已经满足了“普通用户执行程序”这一条件。

内核是否有执行条件，以及本身是否有普通用户能在你的服务器执行命令已经分析完了，接下来就直接来放上红帽官方给的两条缓解措施吧，顺带着分析下难懂，却鲜有文章提起的普通用户所需要的权限到底是什么。

给圈子的熟人门来句痛快话，没事的别慌。圈子里的熟人们内核角度肯定中招，而运行条件可能很多曾经同行的环境比我的环境充分了不知道多少倍，甚至用户能自由的运行ping之类的程序甚至任意程序只是没有root？不过正常来说大家的用户肯定是没有CAP_NET_ADMIN权限的。绝大多数情况下大家安装的后端，以及后端本身为每个用户创建的普通用户账号没这个权限，而用户如果没有root也没什么方法给自己上传的恶意程序文件赋予这个危险的权限，没什么好担心的，如果有，你更应该找出用户是怎样取得了sudo，或者类似的方式临时获得root权限给文件增加这个权限。

至于要说CAP_NET_ADMIN权限控制的实现方式有漏洞可以绕过取得？那就又是另外一个话题了，最近一次的应该也十几年了吧，还不如检查检查系统有没有不合适的SID提权文件之类的，或者关注sudo之类的更近一些的漏洞。

Mitigation
1. This flaw can be mitigated by preventing the affected netfilter (nf_tables) kernel module from being loaded. For instructions on how to blacklist a kernel module, please see https://access.redhat.com/solutions/41278.
2. If the module cannot be disabled, on non-containerized deployments of Red Hat Enterprise Linux, the mitigation is to disable user namespaces:

# echo "user.max_user_namespaces=0" > /etc/sysctl.d/userns.conf
# sysctl -p /etc/sysctl.d/userns.conf

On containerized deployments, such as Red Hat OpenShift Container Platform, do not use the second mitigation (disabling user namespaces) as the functionality is needed to be enabled. The first mitigation (blacklisting nf_tables) is still viable for containerized deployments, providing the environment is not using netfilter.

红帽官方给的两条缓解措施。第二条，也就是代码框内的方法，对运行了容器的用户来说并不可行，比如红帽举例的OpenShift容器平台，容器以及类似的虚拟环境之类的实现，本来就是用户空间实现的隔离，而第一条，禁用方法类似折腾玩家们玩ProxmoxVE显卡直通的时候的方法那样，禁用nf_tables，不过这玩意儿就是firewalld的底层，要不要禁用了看运行条件情况吧。

思考

于我而言，我大部分的服务器已经比较早的通过内核升级修补了这个漏洞。内网、非信任域的计算节点可能也根本就不依赖firewalld ufw之类的内部保护；程序本身被容器限制了权限；外部有不同层次级别的，不同权属的抗拒绝清洗，网段间通讯隔离的交换机、路由器、防火墙，以及具体到应用防护层面的精细规则防护，应该大多数一般人的情况都不受这个漏洞的影响吧？

CVE-2023-32233利用条件算是比较苛刻，但是一旦满足利用条件就会获取到root权限的比较严重的漏洞。

主流操作系统相关的团队们其实针对这个漏洞都算是比较活跃的，因为漏洞严重性不低，但是不属于远程利用类，且对基本权限有一定要求，涉及的面不是非常广泛，所以并没有出现某一些漏洞爆出之后有的发行版四个小时内就推送了相关修补，大多数操作系统两天内都提供了修补程序，然后互联网吵翻天的情况，只是引起了小规模的关注。我猜测就像RH的bugzilla上那篇文章现在最后一篇帖子那样，有的人找不到各团队做了什么，而对这个漏洞的描述理解起来又比较深，所以在小范围的圈子里引发了一些“不必要的讨论”（我觉得）。

一个漏洞是否是“紧急”，需要所有运维关注，不仅仅是破坏力，还有可能是利用方式，例如CPU大洞席卷而来，幽灵、熔断，为公有云计算提供运维支持的团队们注意到了么？虽然这玩意儿大家不便利用，但是我搬运一个很久以前的“众所周知”。当年已经验证了比如当时版本的火狐浏览器会受到侵害，怎么说呢，比如说有个人开了个长得像是博客的恶意站点，上面放置了漏洞利用，你浏览了这个博客，而你恰好同时在写你的博客，而那个人能做跟你现在在电脑前干一样能做的事情，配合一些其他的东西，给你关机、抹盘，都可不是不可能，虽然验证的只是获取其他浏览器窗口的数据，然后就可以比如帮你发个帖子，或者提取个cookies。

虽然如此，但是绝大多数计算机并没有这个价值，不像服务器，如果说一个服务器仅仅安装了apache，提供html静态页面，但是恶意程序可以直接通过正常的http直接取得root权限，或者哪怕是提升一点权限例如自由下载执行一些程序，都够可怕的了；或者比如你是一个公有云计算服务商，一个用户能够通过一些程序去访问到另外一些用户的数据，比如一个ECS获取了底层的物理服务器一共跑了几个ECS，关心下邻居都拿ECS跑什么程序；又或许用尽了以为的安全，各种软件安装一通防护远程登陆，设置繁琐的密码，但是在年久失修多年得不到修补的操作系统这最大的隐患面前是多么的徒劳无功。

最基础的安全做的不多，要知道的也不多，不过能拦住绝大多数想要搞破坏的，或者无意破坏的。比如大家出门都锁门吧，虽然就是一锤子的事。