在 PHP / Apache / Linux 上下文中,为啥 chmod 777 是危险的?
Posted
技术标签:
【中文标题】在 PHP / Apache / Linux 上下文中,为啥 chmod 777 是危险的?【英文标题】:In a PHP / Apache / Linux context, why exactly is chmod 777 dangerous?在 PHP / Apache / Linux 上下文中,为什么 chmod 777 是危险的? 【发布时间】:2011-01-21 06:31:17 【问题描述】:受this question 中的讨论启发,可能是个愚蠢的问题。
我们都被告知,在基于 Linux 的 Web 主机上保留具有 777
权限级别的目录或文件是一件坏事,并且始终设置尽可能少的权限。
我现在很好奇究竟在哪里存在被利用的危险,特别是在 php / Apache 环境中。
毕竟,无论是否标记为“可执行”,PHP 脚本文件都可以从外部执行(即通过调用 Web 服务器,然后调用解释器),不是吗?这同样适用于通过命令行php
解释器调用的文件,对吗?
那么777
的漏洞究竟在哪里?是不是同一台机器上的其他用户可以访问全世界可写的文件?
【问题讨论】:
它可以让每个人读取、写入和执行代码。 @LiraNuna 是的,但是在这种情况下,每个人的意思是什么?同一台机器上的用户?机器外的用户- 怎么样? “执行”在 PHP 脚本上下文中是什么意思,其中文件本身不可执行,但无论其“可执行”标志如何解释都会被解释? @LiraNuna,假设他的服务器上所有东西都有 777,你能“写”到他的 index.php 吗? 你需要软件让你写作。一旦你能找到一个让你写的错误(不是太难),你就可以使用 apache 执行页面。如果机器上安装了 PHP,或者 perl,... 你可以在文件顶部放置字符来告诉系统自动运行哪个二进制文件。因此,该文件将是字面上可执行的。为了更有趣,您可以先上传解释器(比如珍珠),然后上传要解释的文件(比如 ownme.pl),然后对 ownme.pl 运行珍珠。可悲的是,我是根据经验说的。谢天谢地,这不是我的代码,没有人受伤。 关于“属于 Serverfault”投票 - 这是 100% 的 *** 问题。这是关于我们编写的软件的安全性。 【参考方案1】:它大大增加了您网站对恶意活动的脆弱性,因为它只需要侵入一个帐户。
通过任何登录方式访问您的系统的任何人都可以对您的页面做任何他们想做的事情,包括将它们更改为“这个网站真的不安全,所以请给我您的信用卡信息。”
编辑:(澄清和解决 cmets)
许多服务器的生活目的不止一个。他们运行多种服务。如果您通过为每个用户分配一个唯一的用户并相应地管理文件权限来小心地将这些服务彼此隔离,是的,如果有人破坏了帐户的凭据,您仍然会陷入困境,但他们可以造成的损害仅限于该一项服务.如果您只有一个通用帐户并将整个文件系统设置为 777,那么一个被盗用的帐户会危及计算机上的所有内容。
如果您的服务器专门用于仅运行 Apache/PHP 并且在生活中没有其他用途,并且只有一个帐户在运行 Apache/PHP,那么让该帐户被盗就像拥有整台机器一样好从您的应用程序的角度来看受到了损害(尽管您仍然应该让系统文件受到保护,并且用于运行 PHP 的帐户不可写......这仍然应该只有管理员帐户/root 才有可能)。
如果他们可以编写一个文件并且它是可执行的,他们可以将其更改为在您的机器上执行的东西(可执行文件或脚本),然后使用 PHP 的 shell_exec 来运行该可执行文件。如果您配置为不允许 shell_exec,他们也可以更改您的配置
【讨论】:
@Eric J 通过何种登录方式访问我的系统?一个shell登录?如果有人从外部获得了对我 Linux 服务器上的 shell 的访问权,那么我很可能已经被搞砸了。这就是chmod 777
的全部内容吗?
@Eric J:虽然有效,但如果有人对机器有 shell 访问权有问题,手头的问题不是比随机 chmod'd 777 目录更紧迫吗?
和@Eric J,我正在询问 execution 位。当我的网站的任何内容不是可执行的二进制文件时,为什么它们是否被标记为 executable 在安全方面很重要?这就是我想了解的。
@Pekka:如果您始终应用最少访问原则,您将拥有专门用于特定目的的帐户,并且您会将这些帐户限制为与该目的相关的文件。如果您的服务器的唯一目的是运行 PHP,那么您只有一个帐户用于此目的,影响小于在同一个机器上运行多个服务,每个服务都有一个特定帐户,每个帐户仅限于访问与该服务相关的文件。
@Eric J. 我完全同意。我在这里的问题是关于“7”位,因为我看到人们让他们的(基于 PHP 的)网站受到损害,而其他人则回答“嗯,你到处都有 chmod 777,难怪你被黑客入侵了。”我想了解具体的含义 - 应用最少访问权限是唯一可行的方法,这一点毋庸置疑。【参考方案2】:
这是一个场景:
-
您有一个用户可以上传到的不受保护的目录。
他们上传了两个文件:一个 shell 脚本,一个 php 文件,其中包含对 shell 脚本的
system()
调用。
他们通过访问浏览器中的 url 来访问刚刚上传的 php 脚本,从而导致 shell 脚本执行。
如果这个目录是777,这意味着任何人(包括用户apache,这是php脚本将执行的)都可以执行它!如果没有在该目录上设置执行位,并且可能是目录中的文件,那么上面的步骤 3 将不会执行任何操作。
从 cmets 编辑:重要的不是 PHP 文件的权限,而是 PHP 文件中的 system()
调用将由 linux 用户 apache(或任何您设置 apache 运行的系统调用)执行as),这正是执行位很重要的地方。
【讨论】:
@Mike 这是有道理的,但是我需要设置可执行位来运行 PHP 文件吗?我现在无法测试它,但我认为不会,Apache/PHP 的读取权限不足以运行文件吗? 不,重要的不是 PHP 文件的权限,而是 PHP 文件中的 system() 调用将作为 linux 系统调用执行,而这正是执行位重要的地方。 啊啊我明白了,这是有道理的。干杯! 你好@MikeSherov,很抱歉提出这个老问题和以下愚蠢的问题。你写了“你有一个用户可以上传到的不受保护的目录。” “用户”是什么意思?如果他们没有 FTP 访问权限,他们如何上传该目录中的文件?如果我在专用服务器上,我应该没问题,对吧? 嗨@testermaster AFAIK,网页中文件上传界面的未经处理的图像是将php文件上传到服务器的方法之一。【参考方案3】:在权限方面遵循极简主义有很多很好的一般理由,但在 LAMP 网络主机的上下文中,容易想到的少数是
在共享主机平台上,共享您主机的其他用户现在可以读取和写入您的脚本。 在专用主机上,恶意进程可以读取/写入并意外删除您的文件。假设有一个自定义日志进程在后台运行,用户没有人,它有一个错误导致它尝试rm -rf /
。现在通常这将是无害的,因为几乎没有任何人不应该拥有写权限的任何文件,但这个流氓进程现在会带走你的文件。
要破坏您的网站,某人只需要以任何用户的身份获得访问权限,甚至可以说nobody
或一些类似的虚拟帐户。通常,攻击者必须进行进一步的用户级别升级攻击才能到达他可以造成一些破坏的地方。这是一个真正的威胁。一些非关键服务可能在虚拟帐户下运行,并且可能包含漏洞。
【讨论】:
【参考方案4】:假设您的服务器中安装了一个软件包,并且其中存在零日漏洞,攻击者可以通过上传文件功能访问您的管理控制面板,如果您将所有内容设置为 777,这对他来说将是微不足道的在他想要的任何地方上传一个 shell 脚本。但是,如果您正确设置权限,他将无法执行此操作,因为 nobody/www-data/etc 将没有写入权限。
【讨论】:
以上是关于在 PHP / Apache / Linux 上下文中,为啥 chmod 777 是危险的?的主要内容,如果未能解决你的问题,请参考以下文章
linux下apache不解析php打开网页提示保存怎么办?
Apache 不在 Linux/OpenSuse 中处理 php 文件