Is it particularly worse than downloading and blindly running the code in separate steps? I don't think the majority of users have ever extensively audited the software they run, so it's not exactly a new trend. If you are capable of evaluating this script, you already know how to do it.
I know this is considered a bad practice - but how is it worse than downloading it first and then running it? It's only better if someone is going to inspect the script before running it and how many people actually do that? Or will do it if they were forced to?
How many people are this careful about install scripts, but then allow the installed code to run with just the same permissions as the install script would have run? Is that a meaningful difference? Is it more difficult to audit install scripts than to audit the rest of the code?
the problem is mainly that the script is executed without leaving a trace. if you downloaded the script then executed it, you would have something to inspect in case something goes wrong.
it's too easy, and people with very scarce knowledge could develop a habit of doing this without asking questions and not even leaving any trace for a senior to inspect in case of a problem happening
Absolutely. I wrote such a script as a proof-of-concept and was yelled at because it was considered a 'security risk' for me to use company tools to write code (as a not-hired-for-programming employee) even though I already had access to literally all the company's data and their security practices were such that exfiltrating their data without being caught would have been trivial even if I never placed any code on their systems. The place was extremely dysfunctional and there were significant trust issues that were completely irrational and inconsistent. So a script that did this job was largely out of the question.
You're running a script that you've never seen on your machine with your user account. It's a dangerous habit at best. At worst you're exposed to poor code and man-in-the-middle attacks.
As someone else pointed out, it also makes versioning difficult.
I suppose the difference is iff people do very script before they run, this could bypass it. But I think, those people would definitely download it, inspect it, then run the downloaded script.
I'm not OK with the modern practice of recommending end-users download and execute a script from the big, bad web without first reading it.
I guess I'm just an old fuddy-duddy, and if you feel it's OK, knock yourself out. But I really think software developers should know better than to rely on this practice simply because it makes their install process into a one-liner. I'm sure they could do better than recommending users execute random scripts from the intarwebs, sight-unseen.
Yes, that's the point. You can, and probably should do that, but the guides don't bother with what is essentially making one command two because two commands is one more for someone to screw up.
I think the trade off they are taking is fundamentally a bad one with respect to security and accountability. It's not even about checking the script ahead of time. It's about checking what was actually run at a later date to see what happened. If the script is never stored to disk, determining whether a short lived hack of the script source affected you is much harder.
Yes. Not because you're doing anything wrong yourself, but because the cost to the user of allowing third party scripts is too high to tolerate nowadays.
Well, you're going to run the thing the script downloaded with exactly the same user and privileges as the script you're running.
Unless you're doing a full audit on all the code and not only a cursory look on the installation script, this looks to me more like security theatre.
"a knowledgable user will most likely check the content first.". Really? I'm knowledgeable in that I understand that the script may contain evil, but I'm lazy as hell so I don't bother to check 99% of the time. Like I clone, build and run repos without checking every SLoC.
C’mon. The scripts are public, you can inspect them before running them. The other alternative is to explain line by line the hundreds of lines in the scripts. Not very practical.
Fortunately it’s not common, so they don’t. If it became common and they did, I could inspect the script using automated tools that check for obfuscation, etc.
I think it’s not about eliminating, but making a little better. With lots of this stuff, it’s just about being faster than the other guys that the bear is chasing.
It’s kind of moot because all this is solved by “don’t download and run scripts from strangers.” Then you just have to worry about someone rooting homebrew.
I don’t like this line of thought because it ultimately gets us to a Microsoft world where everything is signed and there’s still tons of crap getting through.
I’d rather have it where scripts can be individually assessed and run without lots of expensive stuff in the middle. Even if that means some risk.
Hey, I use inspect! I've run untrusted code every computing day of my life, so I guess that makes me a script kiddie. My advice, keep on script kiddie'ing, because it will definitely pay off.
reply