Linux sudo Baron Samedit（CVE-2021-3156）本地提权漏洞排查、验证与修复

背景

CVE-2021-3156，又称 Baron Samedit，是 sudo 在命令行参数转义处理中的堆缓冲区溢出漏洞。攻击者只要获得 Linux 主机上的普通本地账户，通常无需拥有 sudo 权限，即可能将权限提升至 root。

该漏洞适合放在内网攻防链路中评估：入口可能只是低权限 Web Shell、泄露的 SSH 凭据或受限运维账户，后续通过本地提权突破权限边界。以下内容仅用于授权环境中的资产排查、无害验证、日志取证与修复，不提供武器化利用代码。

漏洞信息

上游确认的典型受影响范围包括 1.8.2 至 1.8.31p2，以及 1.9.0 至 1.9.5p1。不能只根据版本字符串下结论，因为 Debian、Ubuntu、RHEL 等发行版经常在保持主版本号不变的情况下回移安全补丁。

问题定位

sudo 在 shell 模式下解析以反斜杠结尾的参数时，转义长度计算与实际复制行为不一致。通过 sudoedit 方式进入相关处理路径后，特制参数可能造成堆内存越界写入。漏洞发生在 setuid root 程序内部，因此一旦成功控制执行流程，进程天然处于高权限上下文。

需要特别注意：用户执行 sudo -l 被拒绝，并不代表不受影响。此漏洞利用的是 sudo 二进制本身的内存破坏问题，而不是 sudoers 策略配置错误。

资产排查步骤

首先确认 sudoedit 的实际路径、文件权限、软件包版本和发行版安全公告状态。以下命令只读取系统信息，不会触发漏洞利用。

command -v sudo sudoedit
sudo --version | head -n 1
ls -l "$(command -v sudo)" "$(command -v sudoedit)" 2>/dev/null
cat /etc/os-release

# Debian / Ubuntu
dpkg-query -W -f='${Package} ${Version}\n' sudo 2>/dev/null
apt-cache policy sudo 2>/dev/null

# RHEL / CentOS / Rocky / AlmaLinux
rpm -q sudo 2>/dev/null
rpm -q --changelog sudo 2>/dev/null | grep -i -m 3 'CVE-2021-3156\|Baron Samedit'

# Fedora / RHEL 8+
dnf updateinfo info --cves CVE-2021-3156 2>/dev/null

# SUSE
zypper lp --cve CVE-2021-3156 2>/dev/null

正常情况下，sudo 主程序通常带有 root 所有者和 setuid 位，例如权限中出现 s。删除 setuid 位只能作为极短期隔离措施，会直接影响依赖 sudo 的运维流程，不能替代安装安全更新。

无害验证方法

生产环境不建议运行公开 PoC。验证应优先采用“软件包状态加发行版公告”的方式，而不是观察程序是否崩溃。部分历史探测方式会向 sudoedit 传入异常参数并根据报错推断漏洞状态，但错误信息会受到本地化、补丁实现和内存布局影响，既可能误报，也可能造成进程崩溃。

在隔离靶场中如需确认补丁前后的行为差异，应先制作虚拟机快照，并通过 coredump、审计日志和软件包校验记录全过程。验证成功标准应是“补丁状态已确认”，不应以获取 root shell 作为生产验证目标。

# 检查二进制是否来自已安装软件包，并验证完整性
# Debian / Ubuntu
dpkg -S "$(command -v sudo)"
dpkg -V sudo

# RPM 系发行版
rpm -qf "$(command -v sudo)"
rpm -V sudo

# 检查是否启用了崩溃转储；生产排查时注意转储可能包含敏感信息
sysctl kernel.core_pattern
coredumpctl list sudo 2>/dev/null
coredumpctl list sudoedit 2>/dev/null

内网攻防链路中的风险

该漏洞本身不能远程进入主机，但会明显放大初始访问的影响。典型链路是：攻击者先通过 Web 应用漏洞获得 www-data 等低权限身份，或利用弱口令进入普通账户；随后在主机上枚举 sudo 版本并实施本地提权；取得 root 后读取 SSH 私钥、服务凭据、配置文件和令牌，再横向访问数据库、缓存或其他 Linux 节点。

• Web 服务器：重点检查 Web 进程账户是否执行过 sudo、sudoedit、编译器或异常 ELF 文件。
• 运维节点：重点检查 root 的 SSH authorized_keys、shell 启动文件和计划任务。
• 容器宿主机：容器内存在漏洞不等于可以直接控制宿主机，但高权限容器、宿主目录挂载或 Docker Socket 会扩大后果。
• 集中认证环境：提权后可能接触 Kerberos keytab、LDAP 绑定密码或自动化部署凭据。

日志留痕与取证

sudo 的正常审计日志位置因发行版和 rsyslog、journald 配置而异。应同时检查认证日志、systemd 日志、auditd、崩溃记录以及用户目录中的临时文件。单纯没有 sudo 成功记录，不能排除漏洞利用，因为攻击行为可能在 sudoers 鉴权前后异常退出。

# Ubuntu / Debian 常见日志
grep -Ei 'sudo(edit)?|segfault|core dumped' /var/log/auth.log /var/log/syslog 2>/dev/null

# RHEL 系常见日志
grep -Ei 'sudo(edit)?|segfault|core dumped' /var/log/secure /var/log/messages 2>/dev/null

# systemd 日志
journalctl --since '2021-01-01' | grep -Ei 'sudo(edit)?|segfault|core dumped'
journalctl _COMM=sudo --since '7 days ago'
journalctl _COMM=sudoedit --since '7 days ago'

# auditd 记录
ausearch -x sudo -ts recent 2>/dev/null
ausearch -x sudoedit -ts recent 2>/dev/null
ausearch -m ANOM_ABEND,SEGV -ts recent 2>/dev/null

# 检查近期新增的高权限文件
find / -xdev -type f -perm -4000 -mtime -30 -ls 2>/dev/null
find /etc/cron.d /etc/systemd/system /root/.ssh -type f -mtime -30 -ls 2>/dev/null

发现 sudo 或 sudoedit 崩溃只能视为线索。还需关联调用用户、父进程、终端来源、SSH 登录、文件创建和网络连接。若父进程是 Web 服务、脚本解释器或位于 /tmp、/dev/shm 的临时程序，应提高事件优先级。

建议的 auditd 监控规则

在尚未完成全量升级的过渡期，可以增加执行审计。规则中的路径应根据 command -v 输出调整；大量终端服务器部署前应先评估日志量。

# 临时加载，重启后失效
auditctl -a always,exit -F path=/usr/bin/sudo -F perm=x -k sudo_exec
auditctl -a always,exit -F path=/usr/bin/sudoedit -F perm=x -k sudoedit_exec

# 查询结果
ausearch -k sudo_exec -i
ausearch -k sudoedit_exec -i

# 持久化可写入 /etc/audit/rules.d/sudo-monitor.rules
-w /usr/bin/sudo -p x -k sudo_exec
-w /usr/bin/sudoedit -p x -k sudoedit_exec

修复与缓解建议

• 首选措施是通过发行版官方仓库升级 sudo，并重启可能长期驻留的管理会话。不要用自行编译版本直接覆盖包管理器文件。
• 升级后再次查询软件包版本、厂商安全公告和变更日志，确认已包含 CVE-2021-3156 修复。
• 暂时无法升级时，可在评估业务影响后移除 sudo 的 setuid 位或限制普通用户登录，但这只是应急隔离，可能导致自动化任务和运维流程中断。
• 检查 sudoers 中不必要的 NOPASSWD、通配符命令、可写脚本和环境变量继承。即使 CVE 已修复，这些配置错误仍可能形成独立提权路径。
• 如果已有异常崩溃或可疑执行记录，应按失陷主机处理：隔离网络、保全日志、轮换主机可访问的密码与密钥，并检查同凭据覆盖的其他节点。

# Debian / Ubuntu
apt-get update
apt-get install --only-upgrade sudo

# RHEL / CentOS / Rocky / AlmaLinux
dnf update sudo

# 更新后复核
sudo --version | head -n 1
stat "$(command -v sudo)"

# 检查高风险 sudoers 配置；不要直接用普通编辑器修改
visudo -c
grep -RniE 'NOPASSWD|SETENV|\*' /etc/sudoers /etc/sudoers.d 2>/dev/null

总结

CVE-2021-3156 的关键风险不在于远程入口，而在于它能把普通本地账户迅速转化为 root 权限。漏洞验证应以发行版补丁状态、软件包完整性和审计证据为主，避免在生产环境直接运行公开利用程序。完成升级后，还应继续排查异常 sudoedit 执行、进程崩溃、新增 SUID 文件、计划任务、SSH 密钥和敏感凭据访问记录，防止只修补漏洞而遗漏已经发生的入侵。

排查时不要只拿 sudo --version 和上游版本号硬比。很多发行版会保留旧版本号并回补补丁，是否受影响应以发行版安全公告和包的 changelog 为准。上游受影响范围大致为 1.8.2～1.8.31p2、1.9.0～1.9.5p1，1.9.5p2 起修复，但厂商包可能例外。

建议先收集版本、包来源和补丁记录：

sudo --version | head -n 1

# Debian / Ubuntu
dpkg-query -W -f='${Package} ${Version} ${Status}\n' sudo
apt-cache policy sudo
zgrep -iE 'CVE-2021-3156|Baron Samedit' \
  /usr/share/doc/sudo/changelog.Debian.gz 2>/dev/null

# RHEL / CentOS / Rocky / Alma / Fedora
rpm -q sudo
rpm -q --changelog sudo | grep -i -m1 -B2 -A3 CVE-2021-3156
dnf updateinfo info --cves CVE-2021-3156 2>/dev/null ||
yum updateinfo info --cves CVE-2021-3156 2>/dev/null

# SUSE
rpm -q sudo
zypper lp --cve CVE-2021-3156

网上常见的 sudoedit -s 异常输出或崩溃测试只能作为线索，不能作为最终结论：不同编译选项、glibc 版本和厂商补丁会改变表现，而且可能留下 core dump。生产机上不建议运行公开 PoC，更不要通过“是否拿到 root shell”来验证。优先依据厂商修复版本；确需动态验证时，应在同版本、同架构的隔离快照中进行。

修复直接升级发行版提供的安全包，不建议自行覆盖 /usr/bin/sudo：

# Debian / Ubuntu
apt-get update
apt-get install --only-upgrade sudo

# RHEL 系
dnf upgrade sudo
# 老系统可用：
yum update sudo

# SUSE
zypper update sudo

# 升级后复核文件确实来自包管理器
dpkg -V sudo 2>/dev/null || rpm -V sudo
stat /usr/bin/sudo /usr/bin/sudoedit

sudo 通常按次启动，包升级后一般不需要重启系统；但应重新执行版本和 changelog 检查，并确认自动化镜像、离线节点、救援环境及容器基础镜像也同步更新。仅删除 sudoedit、修改 sudoers 或取消普通用户的 sudo 授权都不是可靠修复，因为漏洞位于 sudo 的参数解析路径，关键是替换已修补的二进制。

如果暂时无法升级，可把临时措施放在降低本地登录面：禁用不必要的 shell 账号、收紧 SSH 登录、检查异常 SUID 文件和近期提权痕迹。但这只是风险缓解，不能代替安装安全更新。