时间戳

首页 > 解决方案 > /bin/sh 使用假 ls 的权限提升代码 - 为什么会这样？

linux - /bin/sh 使用假 ls 的权限提升代码 - 为什么会这样？

问题描述

我最近在以下网站上看到了这个片段：

https://www.linuxjournal.com/content/writing-secure-shell-scripts

这是脚本：

#!/bin/sh

if [ "$USER" = "root" ] ; then
  /bin/cp /bin/sh /tmp/.secretshell
  /bin/chown root /tmp/.secretshell
  /bin/chmod 4666 root /tmp/.secretshell
fi

exec /bin/ls $*

让我们假设运行此代码的人对系统具有低级访问权限（即他们可以写入/tmp/），并且系统没有“硬化”。

在上面的链接中，代码的作者说：“这个简单的小脚本创建了一个 shell，它始终授予其用户 root 访问 Linux 系统的权限。”

这个想法是攻击者会编写上面的脚本，命名它ls，然后将它放到/tmp/系统的目录中。因此，任何运行ls（而不是/bin/ls） in 的用户/tmp/都会无意中运行此脚本。如果运行的用户ls恰好是root，他/她将触发封闭if/fi块中的（恶意）代码。exec /bin/ls $*为了隐藏发生了任何有害的事情，由于最后一行，用户想要的目录列表仍将按预期执行。

我不太明白的是该if/fi块的最后一行在做什么。这就是我解释该if/fi块的前两行的方式：

在 行/bin/cp /bin/sh /tmp/.secretshell中，脚本将/bin/sh二进制文件复制到/tmp/，并将其重命名为.secretshell，一个隐藏文件。好的。

在该行/bin/chown root /tmp/.secretshell中，脚本将所有者更改.secretshell为root。好的。

我不太明白的是这条线/bin/chmod 4666 root /tmp/.secretshell。据我所知，我认为这条线是为了翻转setuid，.secretshell所以每次.secretshell运行时，它都作为它的所有者运行（现在root）。这将（我想）让任何运行.secretshell的人都能够sh以root. 但是这里有两件事似乎有问题：

1）当在权限参数之后期望目录或文件名时，如何将root其作为第二个参数插入？/bin/chmodchmod

*6662）权限参数的一部分是否通过将其权限掩码转换为.secretshell 不可执行-rwSrw-rw-？如果意图是执行 .secretshell，这怎么可能是可取的？

谢谢你的帮助！

标签： linuxshellsecuritysh

解决方案

这篇文章包含几个关于 shell 脚本的错误和基本误解：

  1. 你是对的 extra root，这可能是一个复制粘贴错误。
  2. 您对缺乏可执行权限是正确的。作者没有测试自己的代码。
  3. sh整个方法在 CentOS 或 macOS where is等非基于 Debian 的系统上失败bash，因为 bash 丢弃了 suid。
  4. 作者声称ls -l $namewherename='. ; /bin/rm -Rf /'将执行rm. 这是错误的。
  5. 作者似乎进一步声称将ls -l "$name"在哪里name='. `/bin/rm -Rf /`'执行该命令。这也是错误的。

我建议对整篇文章持保留态度。

推荐阅读