在 PHP / Apache / Linux 上下文中，为什么 chmod 777 是危险的？

In a PHP / Apache / Linux context, why exactly is chmod 777 dangerous?

提问by Pekka

Inspired by the discussion in this question, a maybe stupid question.

受到这个问题中讨论的启发，一个可能很愚蠢的问题。

We have all been taught that leaving directories or files on Linux-based web hosting with the permission level of 777is a bad thing, and to set always as little permissions as necessary.

我们都被教导将目录或文件留在基于 Linux 的 Web 主机上的权限级别777是一件坏事，并且总是根据需要设置尽可能少的权限。

I am now curious as to where exactlylies the danger of exploitation, specifically in a PHP / Apache context.

我现在好奇的地方正是在于剥削的危险，特别是在一个PHP / Apache的环境。

After all, a PHP script file can be executed from the outside (i.e. through a call to the web server, and subsequently to the interpreter) no matter whether it is marked as "executable", can't it? And the same applies to files called through the command-line phpinterpreter, right?

毕竟，一个 PHP 脚本文件可以从外部执行（即通过调用 Web 服务器，然后调用解释器），无论它是否标记为“可执行”，不是吗？这同样适用于通过命令行php解释器调用的文件，对吗？

So where exactly is the vulnerability with 777? Is it the fact that other users on the same machine can access files that are made world writable?

那么漏洞究竟在哪里777呢？同一台机器上的其他用户是否可以访问世界可写的文件？

采纳答案by Mike Sherov

Here's one scenario:

这是一种场景：

1. You have an unprotected directory that users can upload to.
2. They upload two files: a shell script, and a php file that has a system()call in it to the shell script.
3. they access the php script they just uploaded by visiting the url in their browser, causing the shell script to execute.

1. 您有一个用户可以上传到的未受保护的目录。
2. 他们上传了两个文件：一个 shell 脚本和一个 php 文件，其中system()调用了 shell 脚本。
3. 他们通过访问浏览器中的 url 来访问他们刚刚上传的 php 脚本，从而导致 shell 脚本执行。

If this directory is 777, that means that anybody (including the user apache, which is what php script will execute as) can execute it! If the execute bit is not set on that directory and presumably the files inside the directory, then step 3 above would do nothing.

如果此目录为 777，则表示任何人（包括用户 apache，即 php 脚本将执行的内容）都可以执行它！如果没有在该目录上设置执行位，并且可能是目录中的文件，那么上面的第 3 步将什么都不做。

edit from the comments: it's not the PHP file's permissions that matter, it's the system()call inside the PHP file that will be executed as a linux system call by the linux user apache (or whatever you have apache set to run as), and that is PRECISELY where the execution bit matters.

从评论中编辑：重要的不是 PHP 文件的权限，而是system()PHP 文件内部的调用，该调用将由 linux 用户 apache（或任何您将 apache 设置为运行的方式）作为 linux 系统调用执行，那就是正是执行位重要的地方。

回答by Eric J.

It greatly increases the vulnerability profile of your website to malicious activity because it's only necessary to break into one account.

它极大地增加了您的网站对恶意活动的漏洞配置文件，因为只需闯入一个帐户即可。

Anyone that gains access to your system with any login can do whatever they want to your pages, including changing them to read "This website is really insecure so please give me your credit card info."

任何以任何登录名访问您系统的人都可以对您的页面做任何他们想做的事情，包括将它们更改为“这个网站真的不安全，所以请给我您的信用卡信息。”

EDIT: (To clarify and address comments)

编辑：（澄清和解决评论）

Many servers have more than one purpose in life. They run multiple services. If you carefully isolate those services from each other by assigning each a unique user and managing file permissions accordingly, yes, you are still in hot water if someone compromises the credentials for an account, but the damage they can do is limited to that one service. If you just have one generic account and set the whole file system to 777, one compromised account jeopardizes everything on the machine.

许多服务器在生活中的用途不止一个。他们运行多种服务。如果您通过为每个用户分配唯一用户并相应地管理文件权限来小心地将这些服务彼此隔离，是的，如果有人破坏了帐户的凭据，您仍然处于困境，但他们可以造成的损害仅限于该服务. 如果您只有一个通用帐户并将整个文件系统设置为 777，那么一个被盗用的帐户就会危及机器上的所有内容。

If your server is dedicated to only running Apache/PHP and serves no other purpose in life, and there is only one account under which Apache/PHP is being run, having that one account compromised is as good as having the whole machine compromised from the point of view of your application (although you should still have system files protected and non-writable by the account used to run PHP... that should still only be possible for an admin account/root).

如果您的服务器仅用于运行 Apache/PHP 而没有其他用途，并且只有一个帐户在运行 Apache/PHP，那么该帐户被盗与整个机器被盗一样从您的应用程序的角度来看（尽管您仍然应该保护系统文件，并且用于运行 PHP 的帐户不可写......这仍然应该只适用于管理员帐户/root）。

If they can write a file, and it is executable, they can change it to something that executes on your machine (executable or script) and then use PHP's shell_exec to run that executable. If you're configured not to allow shell_exec, they can change your configuration as well

如果他们可以编写一个文件并且它是可执行的，他们可以将它更改为在您的机器上执行的内容（可执行文件或脚本），然后使用 PHP 的 shell_exec 来运行该可执行文件。如果您配置为不允许 shell_exec，他们也可以更改您的配置

回答by anshul

There are many good general reasons to follow minimalism when it comes to permissions, but in the context of a LAMP webhost, the few that come readily to mind are

在权限方面遵循极简主义有很多很好的一般理由，但在 LAMP 虚拟主机的背景下，少数几个容易想到的是

• On a shared hosting platform, other users sharing your host can now read and write to your scripts.
• On a dedicated host, rogue processes can read/write and accidentally delete your files. Let's say there is a custom logging process running in the background as user nobody which has a bug that results in it trying to rm -rf /. Now generally this will be harmless because there would hardly be any file that nobody should have write permissions on but this rogue process will now take your files with it.
• To deface your website, someone needs to only gain access as any user, even say nobodyor some such dummy account. Generally, the attacker would have to do a further user level escalation attack to get to the place where he can do some damage. This is a real threat. Some non-critical services may be running under dummy accounts and might contain a vulnerability.

• 在共享主机平台上，共享您的主机的其他用户现在可以读取和写入您的脚本。
• 在专用主机上，流氓进程可以读/写并意外删除您的文件。假设有一个自定义日志记录进程在后台以用户 nobody 身份运行，该进程存在导致它尝试执行的错误rm -rf /。现在通常这将是无害的，因为几乎没有任何人应该拥有写权限的文件，但是这个流氓进程现在会带走您的文件。
• 要破坏您的网站，某人只需要以任何用户的身份获得访问权限，甚至可以说nobody或某些此类虚拟帐户。通常，攻击者必须进行进一步的用户级别升级攻击才能到达可以造成一些损害的地方。这是一个真正的威胁。一些非关键服务可能在虚拟帐户下运行，并且可能包含漏洞。

回答by D.Snap

Let's suppose you have a software package installed in your server and there is a zero day vulnerability into it, the attacker gains access to your Admin Control Panel with uploading files capabilities, if you set everything to 777 it would be trivial for him to upload a shell script anywhere he wants. However, if you set the permissions properly he can't do it since nobody/www-data/etc won't have write permissions.

假设您的服务器中安装了一个软件包并且其中存在一个零日漏洞，攻击者可以通过上传文件功能访问您的管理控制面板，如果您将所有内容设置为 777，那么他上传一个任何他想要的 shell 脚本。但是，如果您正确设置权限，他将无法执行此操作，因为 nobody/www-data/etc 将没有写入权限。