sudo 和 .profile/.bashrc 是否启用微不足道的权限提升?

信息安全 linux 特权升级 重击 须藤 路径注入
2021-09-08 09:08:14

首先,让我提一下,我假设当前 Linux 桌面发行版(例如 Debian、Fedora)设置的配置。我确信有一些方法,如果实施,可以缓解这里描述的问题。我感兴趣的是“开箱即用”的安全性。

在我看来,shell 执行诸如~/.profileor之类的文件~/.bashrc,这些文件允许完全操纵用户的执行环境并归用户所有,这一事实破坏了任何希望像这样的程序sudo可以安全运行的希望。问题是,任何以用户身份运行的恶意程序都可以编辑这些文件,例如,修改PATH环境变量以包含伪造的sudo可执行文件,例如PATH="$HOME/.evil:$PATH"恶意程序也在其中创建了一个文件$HOME/.evil/sudo然后,下次用户sudo在 shell 中键入时,sudo将运行 fake 并记录键入的密码。因此,即使原始恶意程序只有用户权限,伪造sudo者也可以获得权限。root

事实上,.profile我安装的 Ubuntu 创建的默认文件包括以下几行:

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

所以甚至不需要修改.profile- 只需创建$HOME/bin/sudo它就已经是第一个了PATH

我的观点并不是说当任意恶意代码运行时已经“为时已晚”,或者这种攻击可能会被用户注意到(我想它类似于网络钓鱼攻击)。我希望以用户身份运行的恶意程序可以做任何用户可以做的事情。然而,我没想到的是,它可以做的不仅仅是那个用户(root权限)。

我的问题本质上是:

  1. sudo是否可以通过这种方式绕过系统可执行文件?
  2. 为什么桌面 Linux 系统默认设置为如此容易被利用的方式?调用的默认方式不应该sudo确保它实际上是系统提供的可执行文件(没有人会/usr/bin/sudo每次都键入)?由于sudo执行系统关键的安全操作,使用变量来隐藏其位置的可能性PATH似乎带来了很多风险而收益甚微。在这样的环境中,使用似乎sudo从根本上来说是不安全的,最好启用登录身份root并在单独的 TTY 上登录。
2个回答

任何您可以对受损帐户执行的操作,攻击者也可以执行此操作。

从根本上说,这是因为 Linux 提供了用户之间的隔离,而不是作为同一用户运行的各个进程之间的隔离。作为给定用户运行的任何进程都被认为具有与在该用户下运行的任何其他进程相同的功能。

系统 sudo 可执行文件是否可以通过这种方式规避?

是的,在其他方面也是如此。如果您将特权提升到受感染的非特权帐户的 root 权限,那么您就损害了 root 权限。如果您将权限从 root 使用su到非特权帐户,您也会损害 root您永远无法安全地提升不受信任帐户的权限。虽然使用 可以利用系统PATH,但也可以劫持 bash 进程本身以嗅探键输入。禁用执行noexec更没有用,因为解释器(bash、python、perl 等)仍然会运行。noexec选项不是也从未被设计为安全功能,尽管它经常被兜售。

攻击者可能劫持使用sudoor的方式的不完整列表su

  • 在父进程上使用LD_PRELOAD变量(例如bash)。

  • ptrace()用or挂钩父进程process_vm_writev()

  • 使用 X11 协议嗅探或将击键注入终端仿真器。

  • 创建别名或函数来包装实际的sudo可执行文件。

我在回答另一个问题时更详细地解释了这些

为什么桌面 Linux 系统默认设置为如此容易被利用的方式?

提升不受信任帐户的权限不是您应该做的事情。更不用说,桌面 Linux 是通用 *nix 架构的宏伟计划中的一个事后想法。这是安全剧院不断重复同样的坏建议的失败,而不是 Linux 本身安全架构的失败。人们反复说要使用sudoroot,因为许多新用户会以 root 身份运行所有东西,甚至是他们的浏览器!在这种情况下,最好使用sudo. 如果用户已经足够聪明,不会对所有事情都使用 root,这是有害的。

请注意,这sudo是高度可配置的,可以设计为仅允许某些命令。这是它真正闪耀的地方。您可以配置sudo为仅允许您以apt-get updateroot 身份运行(有或没有密码),并拒绝其他一切。这将另外限制攻击者做除了......好吧......进行软件更新以外的任何事情。

重要的是要记住,即使您将其配置为仅允许以 root 身份运行某些命令,如果您将未设计为通过不受信任的用户以 root 身份运行的程序列入白名单,您仍然可以自取其辱。我看到了一个真实的例子,有人试图以这种方式运行 VeraCrypt,并解释了为什么它是不安全的这个想法是 VeraCrypt 以 root 身份运行是安全的,因此将其sudo提升为 root 作为不受信任的非特权用户应该是安全的。事实证明这个想法是有缺陷的,并且允许微不足道的特权升级!

调用 sudo 的默认方式不应该确保它实际上是系统提供的可执行文件(没有人会每次都键入 /usr/bin/sudo)?

输入完整路径不会保护您!您可以轻松创建一个包含前导的函数,/它将覆盖真正的可执行文件。即使可执行文件确实确保它是真实的并试图阻止嗅探,恶意进程也可以劫持该bash进程并独立于 嗅探击键sudo,使其无法从其角度检测。

$ function /usr/bin/sudo { echo '劫持!'; }
$ /usr/bin/sudo 标识
劫持!

在这样的环境中,使用 sudo 似乎从根本上来说是不安全的,最好启用以 root 身份登录并在单独的 TTY 上登录。

情况总是如此。请注意,即使登录另一个 TTY 也不是绝对安全的。您应该使用SAK(安全注意密钥组合)来确保您正在与真正的登录会话(agettylogind,例如)进行交互。SAK 是内核监听的键组合(因此不能被用户空间压制)。当它检测到它时,它将杀死当前 TTY 中的每个进程,从而触发登录提示出现。如果您已切换到真正的、不妥协的 TTY,那么它只会导致提示消失并重新出现。如果您在被劫持的 TTY 上,它将杀死恶意进程并带回真正的登录提示。

首先,更改.profile不会自动实现权限提升。受影响的用户必须已经拥有sudo权限。

1 -sudo没有被规避。您正在运行其他东西来代替它。您可以更改.profile和添加alias sudo=~/.evilsudo并实现相同的效果。

2-您考虑配置的懒惰方式sudo在桌面环境中会出现这种情况,但在服务器环境中则不然。在服务器环境中,/etc/sudoers应仅授予用户执行任务所需的命令。您会期望 Oracle 管理员运行sudo service oracle,所以这将在 sudoers 上。oradmin ALL=(ALL:ALL) ALL例如不是。

如果有人在您的帐户上运行代码,已经太迟了。任何更改您的 .profile 的人都可以启动另一个 shell,以捕获每一次按键,您不仅会丢失密码,还会丢失您在其上键入的所有其他内容。远程 ssh 密码、数据库密码、ftp 密码等等。如果您的 .profile 被盗用,游戏就结束了。

如果您真的想保护用户免受此影响,请将每个用户可写目录挂载为noexec. 这种方式~/bin/tmp其他方式将无权执行任何操作。您略微提高了安全性并大大降低了便利性。