求求了，别再用 curl | sudo bash 了，PLEASE
6 分•作者: b112•3 个月前
使用 `curl -s https://url | sudo bash` 简直是疯了。直接给了 root 权限。我们都知道账户是如何被攻破的，所以很明显，黑客有可能用恶意内容替换那个 URL。我们甚至见过黑客攻破页面，返回标准页面，但只针对少数人（例如，通过地理位置）提供恶意数据。
然而，也有可能返回格式错误的文本。Bash 会乐于执行每一行这样的代码：
```
E#@%SDVsdcvxdsf4a6t4g
erfgrr;rm * regdfgereridbd
4524wfasrfv4
```
很难想象这样的输出？是的。不可能？绝对不是。在典型的 Linux 安装中，Bash 可以访问成千上万个命令。其中许多是具有破坏性的。为什么要冒这个险呢？
除了格式错误之外，还可能存在简单的发布错误。错误消息中可能包含代码行。未知的文本。返回的每一行文本都会被执行。我简直惊呆了，这种事情竟然会存在，无论出于什么原因。我不会在自己的个人 Web 服务器上，在自己的内部局域网中执行这样的命令，更不用说远程了。
当我在项目页面上看到这种荒谬的行为时，对我来说是一个巨大的警示。为了方便而牺牲了最基本的安全，甚至没有对 curl 请求是否出错进行简单的验证。由此产生的信任缺失就像堵在我的喉咙里的胆汁，项目作者还会采取哪些捷径，他们似乎 barely barely 了解最简单的风险评估？
拜托，永远不要执行这个命令。如果你不得不抛开所有理智和谨慎，使用一个建议这种安装方法的项目，好吧……至少使用 curl > file，花 1 秒钟看看结果。
查看原文
Using<p>curl -s https://url | sudo bash<p>is literal insanity. Root given. We know how accounts can be compromised, so obviously there is potential for that url to be replaced by a hacker with something malicious. We've even seen hackers compromise pages, and return the standard page, while targetting only a few people (geolocation, for example) with malicious data.<p>Yet there is also the possibility for malformed text to be returned. Bash will happily execute each and every line of:<p><pre><code> E#@%SDVsdcvxdsf4a6t4g
erfgrr;rm * regdfgereridbd
4524wfasrfv4
</code></pre>
Hard to imagine such output? Yes. Impossible? Absolutely not. There are literally thousands upon thousands of commands bash can access in a typical install of Linux. Many of them are destructive. Why even risk it?<p>And beyond malformed, there could be a simple publishing error. There could be lines of code in the error message. Unknown text. Each and every line of text returned, is executed. I am just gobsmacked that this exists anywhere, ever, for any reason at all. I wouldn't execute such a command from my own personal web server, in my own internal lan, let alone remote.<p>When I see such inanity on a project page, it's a big read flag to me. Convenience over the most basic of security, or even simple validation that something didn't go wrong in a curl request. The evoked lack of trust that arises is as bile in my throat, what other shortcuts are taken by the project authors, which seem to barely understand the simplest of risk assessment?<p>Please, don't ever execute this. If you have to throw all sense and caution to the wind, and use a project which suggests this install method, well... at least curl > file and take 1 second to see the result.