How the trust chain works

In a recent article “VPN into every home” it is proposed to do a lot of stupidity, namely, go to your VPS and enter this:

curl -sS https://sockeye.cc/instavpn.sh | sudo bash

As I wrote in the commentary on that article, this is very big stupidity. You blindly run code from the Internet that you have not even seen, and here it is even completely unimportant from under sudo or not.

The main reasons are as follows:

• You accustom yourself to the fact that you can do this. This is the biggest problem here, and you can compare this action with the user who opens the executable file from the letter that came to him. We all know the consequences of such actions through the huge botnets on Windows, as well as various types of leaked private data.
• You do not check checksums and thus cannot say whether you are launching what you think you are running. The script can be replaced by a large number of ways, including the substitution of the DNS record by the provider, as this week was with the github, hacking the site from which the download is made, etc.
• You do not use the long-standing practice of using checksums to verify running code, which is one of the main reasons for the relatively high security of UNIX and the like.

To understand, consider the correct way to install programs, first in a general way:

• You are looking for information about the author, and trying to understand whether you can trust him. Such information is usually found even about the authors of small programs.
• Download your program, it doesn’t matter in what form, this package, archive or iso image.
• Using sha256sum (or at least md5sum), consider the checksum of what you downloaded.
• Go to the developer's site and see if what you counted matches what is written there.
• Drive the checksum into Google and find another source.
• We are convinced that most likely you downloaded exactly what the author of the program wanted to provide you.
• Now you have enough reason to install the software package and not worry too much .

Again. Absolutely all security is built on your trust in certain people or companies, be it Linus Torvalds, the Ubuntu Security Team or the author of a small useful utility. You need to make sure that 1. the author is trustworthy, and 2. you run what the author posted.

Now, let's look at the application of the above method using the Ubuntu Desktop installation example on April 14, 01. Absolutely the same method is used when installing everything else, but you are not downloading a disk image but, for example, an archive.

• Canonical is a relatively well-known company, you can trust with caution. You can always trust only with caution.
• You download the disk image from any mirror: wget whatever / ubuntu-14.04.1-desktop-amd64.iso It doesn’t matter at all whether the mirror is cracked or if the connection is secure.
• Next, consider the checksum, sha256 they do not have on the site, so md5 will go: "md5sum ubuntu-14.04.1-desktop-amd64.iso"
• Go to their site and see this “ help.ubuntu.com/community/UbuntuHashes ”. Everything is in order, the checksum is the same.
• Looking for this checksum in google. At a minimum, make sure that it is the same on other mirrors, ideally find the Canonical mailing list in which it is mentioned.
• Now you are convinced that the downloaded image is not a fake, and you can set it.

Now let's see how the package manager works using the apt-get example:

• When installing the system, you already have some repositories configured.
• These repositories contain files with a list of all packages and their checksums.
• These files, in turn, are signed by the private key of the developers.
• After installation, the public key is already sewn into the distribution kit.
• Thus, when you install a new package, you download the corresponding lists of all packages (if there was an update in the repository), then the package itself, and you can be sure that the trust chain will be traced: {checksum of the package} - {list of packages with checksums} - {signature with the private key of the package list} - {public key sewn into your distribution kit} .

As you can see, verification takes place at all levels. No unsigned executable code will crawl into your system. In cases similar to those described in a recent article, all these checks are not performed. You have no reason to trust such a code. Therefore, the rule:

Never run obscure code from the Internet! Either make sure that it is safe on your own, or make sure that the author can be trusted, and this is his code. If you do not have enough knowledge to check the code yourself, use only the official repositories, there is a special team of specialists who tries (and usually works well for her) to do it for you.

Addition. The only correct way to open access to self-written control panels from the Internet

In a web application, many elements may be vulnerable, the most vulnerable of them is, of course, the code of the application itself. Use http basic authentication over https to minimize risks . In this way, you shift vulnerability concerns to the powerful shoulders of the web server.

Of course, this only works if it is an internal site, end users need more convenient ways to log in. But self-written control panels and other tools are usually designed specifically for internal use.

Offtop. The challenge.

Attention! Do not do this on your working machine or server, it will break!
The task is simply formulated, I assume you have a 64-bit system:

chmod -x /lib64/ld-linux-x86-64.so.2

There are several solutions, in the most difficult case you have no loopholes. I will not clarify so as not to help with the decision.

UPD: The problem was solved in the comments by a person with the login kay , I don’t bring a solution in case you want to break your brain yourself.

UPD2: As correctly observed amarao , if you do not understand exactly what you are doing, use only the official repositories.