6 ms·

Just run the following command as root to install the server. # wget http://shortfin.io/install.sh && sh install.sh What? Are they serious? Is this becoming

by jfb 13y ago

Just run the following command as root to install the server. # wget http://shortfin.io/install.sh && sh install.sh What? Are they serious? Is this becoming a thing? Please don't tell me that this is a thing.

chrissnell 13y ago
This has been a thing since the mid-90s when you could execute 'telnet sci.dixie.edu 1 | sh' to install an IRC client. It preys on the clueless and one of these days, some project that uses this install method is going to get owned and a bunch of machines will get malware. Then again, most of us blindly run what we assume to be GNU autoconf scripts and never read Makefiles before we 'make install' as root. Nor do most of us read or audit source code, even for security-sensitive applications.
ripter 13y ago
a lot of times it's curl instead of wget.
chc 13y ago
I don't see any rational basis for this. If you weren't vetting the code you downloaded before, you don't lose anything by blindly running the commands on one line instead of three. And if you do want to vet the code, you know what to do. Practically no installation instructions include a "vet the code" step, so you aren't losing anything here. The lack of TLS is worrisome, but that's not so much "becoming a thing" as it is "a bad thing we're just finally starting to get rid of."
- rsync 13y ago
  Although this isn't new, it should make you throw up in your mouth a little bit. Malicious compromise is not the only way that an install script can become broken, or corrupted, on a remote site. The ability to checksum what you're running is a very useful sanity check and you should be doing it with all downloaded scripts/packages. I suppose this is tilting at windmills, though.
  - chc 13y ago
    > Malicious compromise is not the only way that an install script can become broken, or corrupted, on a remote site. The ability to checksum what you're running is a very useful sanity check and you should be doing it with all downloaded scripts/packages. Yes, and you still can do that. But the standard installation instructions almost never include it. For example, nginx's build instructions boil down to "run configure, possibly with some flags, and then run make and/or make install". That includes the exact same vulnerability you complain of here — it never tells you to checksum anything. This is true for essentially all the software I've ever downloaded. So again, still not "becoming a thing." The assumption is that if you're the sort of person who customarily checks code before they install it, you know how to inject that step.
- eksith 13y ago
  >"If you weren't vetting the code you downloaded before, you don't lose anything by blindly running the commands on one line instead of three." Nginx is included in the OpenBSD base system (as of 5.2) and it does get vetted.
  - chc 13y ago
    I am not seeing the relevance.
    - eksith 13y ago
      Your assertion is that if we want to vet the code, there are steps to do that and no conventional installation includes these steps, correct? Well, getting the "trust us, this is easy" type installation instructions here isn't terribly comforting from a brand new project. That's the sort of thing I'd expect from a source I know. Not from this project that I didn't even know existed before this post. It's unrealistic to expect those who take security seriously to do so in the first place. Regardless of how often it's done elsewhere. OTOH, there's a well known and trusted software distributor that does the vetting for you, which this project doesn't have, and I'd much rather do the "vetting-skipped install" if you will for something they distribute instead.
      - chc 13y ago
        That's all true, but I don't see what it adds to the conversation. It's just a plug for nginx. "Conservative, security-conscious people like older projects with large, trusted organizations backing them" is something of a tautology.
        eksith 13y ago
        This conversation started when you said you don't see any rational basis for the criticism of running wget/install as root when no vetting takes place on conventional installations. My post wasn't a plug for Nginx, but an imploring to know what you install. Since I can't know everything that's running on my system, I'd trust that from some place that actually does vetting. It doesn't need to be OpenBSD, but some competent source with an established record for security. That's not tautology. It's sane practice that I wish more people followed. The wget/shell install as root is presumptuous in the extreme for a young project with no history. In fact, many young projects, whose security we know nothing about, have similar installations and that's a bad precedent to set and continue.
tlrobinson 13y ago
Yes, it's a thing, and aside from the lack of HTTPS it's not much worse than your standard "./configure", "make", "make install" install flow of the last 20-whatever years of open source. If you don't trust the developer to serve you a safe install.sh script you shouldn't trust the rest of their code either. If you don't trust them you should audit the code no matter what the install process looks like. That said, if you're going to do this, you should do the following: 1. HTTPS only. No excuses. 2. No URL shorteners, which make or may not use HTTPS, and introduce another point of failure. 3. Ideally serve directly from Github repo. Eliminate another point of failure. The user can be reasonably confident that the install script is the same one that's in the Github repo.
- ebbv 13y ago
  It's a lot worse than the standard configure, make and make install. For one, it's only requiring one simple script to get compromised and replaced to compromise your entire machine. At least when I download the tarball, unpack it, etc. I've got several steps before I even get to the make install that I would run as root. And I might not even do that depending on my install target. If I do, I have ample opportunity to verify the package in question and examine the script I'll be running via sudo before I do so. With the instructions provided by this site, not only is there no opportunity to verify the script I've received is the one I wanted to (HTTPS alone is not enough for this, the site or domain may have been compromised) but they're instructing me to just run it immediately as root without any examination. This is a terrible practice, and while yes it has been around for a long time in the past it was something only done and encouraged by idiots, it seems to be gaining popularity. This is a bad idea, stop doing this people. Provide an install tarball and provide a checksum of it that we can verify.
  - tlrobinson 13y ago
    "Provide an install tarball and provide a checksum of it that we can verify." https://github.com/timothyej/Shortfin https://github.com/timothyej/Shortfin My point was the people who are going to blindly run curl/sh commands are also going to blindly download the source tarball and run configure/make/make install, and the people who want to do more verification are certainly free to do so.
toupeira 13y ago
This has indeed become so established that chocolatey.org can offer the following command with a straight face and call it "Easy Install!": @powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin

by jfb 13y ago

chrissnell 13y ago

This has been a thing since the mid-90s when you could execute 'telnet sci.dixie.edu 1 | sh' to install an IRC client. It preys on the clueless and one of these days, some project that uses this install method is going to get owned and a bunch of machines will get malware. Then again, most of us blindly run what we assume to be GNU autoconf scripts and never read Makefiles before we 'make install' as root. Nor do most of us read or audit source code, even for security-sensitive applications.

ripter 13y ago

a lot of times it's curl instead of wget.

chc 13y ago

I don't see any rational basis for this. If you weren't vetting the code you downloaded before, you don't lose anything by blindly running the commands on one line instead of three. And if you do want to vet the code, you know what to do. Practically no installation instructions include a "vet the code" step, so you aren't losing anything here. The lack of TLS is worrisome, but that's not so much "becoming a thing" as it is "a bad thing we're just finally starting to get rid of."

rsync 13y ago
Although this isn't new, it should make you throw up in your mouth a little bit. Malicious compromise is not the only way that an install script can become broken, or corrupted, on a remote site. The ability to checksum what you're running is a very useful sanity check and you should be doing it with all downloaded scripts/packages. I suppose this is tilting at windmills, though.
- chc 13y ago
  > Malicious compromise is not the only way that an install script can become broken, or corrupted, on a remote site. The ability to checksum what you're running is a very useful sanity check and you should be doing it with all downloaded scripts/packages. Yes, and you still can do that. But the standard installation instructions almost never include it. For example, nginx's build instructions boil down to "run configure, possibly with some flags, and then run make and/or make install". That includes the exact same vulnerability you complain of here — it never tells you to checksum anything. This is true for essentially all the software I've ever downloaded. So again, still not "becoming a thing." The assumption is that if you're the sort of person who customarily checks code before they install it, you know how to inject that step.
eksith 13y ago
>"If you weren't vetting the code you downloaded before, you don't lose anything by blindly running the commands on one line instead of three." Nginx is included in the OpenBSD base system (as of 5.2) and it does get vetted.
- chc 13y ago
  I am not seeing the relevance.
  - eksith 13y ago
    Your assertion is that if we want to vet the code, there are steps to do that and no conventional installation includes these steps, correct? Well, getting the "trust us, this is easy" type installation instructions here isn't terribly comforting from a brand new project. That's the sort of thing I'd expect from a source I know. Not from this project that I didn't even know existed before this post. It's unrealistic to expect those who take security seriously to do so in the first place. Regardless of how often it's done elsewhere. OTOH, there's a well known and trusted software distributor that does the vetting for you, which this project doesn't have, and I'd much rather do the "vetting-skipped install" if you will for something they distribute instead.
    - chc 13y ago
      That's all true, but I don't see what it adds to the conversation. It's just a plug for nginx. "Conservative, security-conscious people like older projects with large, trusted organizations backing them" is something of a tautology.
      - eksith 13y ago
        This conversation started when you said you don't see any rational basis for the criticism of running wget/install as root when no vetting takes place on conventional installations. My post wasn't a plug for Nginx, but an imploring to know what you install. Since I can't know everything that's running on my system, I'd trust that from some place that actually does vetting. It doesn't need to be OpenBSD, but some competent source with an established record for security. That's not tautology. It's sane practice that I wish more people followed. The wget/shell install as root is presumptuous in the extreme for a young project with no history. In fact, many young projects, whose security we know nothing about, have similar installations and that's a bad precedent to set and continue.

tlrobinson 13y ago

Yes, it's a thing, and aside from the lack of HTTPS it's not much worse than your standard "./configure", "make", "make install" install flow of the last 20-whatever years of open source. If you don't trust the developer to serve you a safe install.sh script you shouldn't trust the rest of their code either. If you don't trust them you should audit the code no matter what the install process looks like. That said, if you're going to do this, you should do the following: 1. HTTPS only. No excuses. 2. No URL shorteners, which make or may not use HTTPS, and introduce another point of failure. 3. Ideally serve directly from Github repo. Eliminate another point of failure. The user can be reasonably confident that the install script is the same one that's in the Github repo.

ebbv 13y ago
It's a lot worse than the standard configure, make and make install. For one, it's only requiring one simple script to get compromised and replaced to compromise your entire machine. At least when I download the tarball, unpack it, etc. I've got several steps before I even get to the make install that I would run as root. And I might not even do that depending on my install target. If I do, I have ample opportunity to verify the package in question and examine the script I'll be running via sudo before I do so. With the instructions provided by this site, not only is there no opportunity to verify the script I've received is the one I wanted to (HTTPS alone is not enough for this, the site or domain may have been compromised) but they're instructing me to just run it immediately as root without any examination. This is a terrible practice, and while yes it has been around for a long time in the past it was something only done and encouraged by idiots, it seems to be gaining popularity. This is a bad idea, stop doing this people. Provide an install tarball and provide a checksum of it that we can verify.
- tlrobinson 13y ago
  "Provide an install tarball and provide a checksum of it that we can verify." https://github.com/timothyej/Shortfin https://github.com/timothyej/Shortfin My point was the people who are going to blindly run curl/sh commands are also going to blindly download the source tarball and run configure/make/make install, and the people who want to do more verification are certainly free to do so.

toupeira 13y ago

This has indeed become so established that chocolatey.org can offer the following command with a straight face and call it "Easy Install!": @powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin