Show HN: Inspect questionable scripts before piping them to sh or bash | Hacker News Reader

Show HN: Inspect questionable scripts before piping them to sh or bash

github.com

28 pointsmplewis24 comments

I am sorry, but I fail to see how this would be of any help.

It is known that piping unknown scripts to bash is a bad thing. So when somebody decides to pipe into bash, they are either (1) sure of the source or (2) completely clueless about what the hell they are doing. In case (1) there is no need for the tool, and in case (2) asking "do you really want to run this?" will not make any difference since they just typed 'curl <whatever> | sh' into their shell.

This. What if OP inspected the script and highlighted potential harmful commands? Changes in security configurations, manipulation in critical libraries, start-up scripts, and so forth. Not sure how much that would help to the novice, but it's at least actionable (user can look the commands up and understand the implications.

"What if OP inspected the script and highlighted potential harmful commands?" OP doesn't. Look at the code.

That's exactly what he says, he agrees with you and just offers a suggestion on how to improve the script.

vipe[0] from moreutils is a bit more general purpose command than this. It does not dictate the receiving end. So you can quickly check and correct data between pipes. Nifty stuff...

[0]: https://joeyh.name/blog/entry/moreutils/

Just brain storming... could another possible solution be to create a public list of hashes of well known scripts, and then write a small `sh` wrapper that verifies that hash of the script it's about to execute?

You mean like... a package manager?

Well a package manager does much more than verify downloads, but sure you can think of it as a single featured package manager.

You shouldn't always trust even 'trusted' scripts due to the potential for various types of man in the middle attacks. True, though, that with all things being equal some scripts are more trustworthy than others, but if you're on a compromised network then you can't trust any.

Interesting. I wrote a similar script, in Bash, for my meta.sh project: http://meta.sh/index.sh

There is a nice simple version here too https://gist.github.com/sunaku/f5f79e20b6f92ab1e524

I can't wait for a time when simple and universal sandboxing will be available with no need for root.

Just: $ sandbox 'curl http://whatever | sh'

With predefined permission profiles or interactive permission system.

What would it do which can't already be done with normal nix permissions and/or ACLs? The solution is to create a user account, like www-run or redis or Postgres or any of the other tons of things which already do this.

An even better idea is jails, or something like Docker.

What you present is not simple or universal. Nix permissions and ACLs are for file system access and sadly in Linux "everything is a file" is a lie.

Jails or Docker are practically heavyweight sandboxes and they need root access.

Why not just:

  curl ... | less

One potential issue is that you don't know you'll get the same HTTP response next time.

From within less, you can save to a file or pipe to a command, once you've inspected the payload to whatever degree you desire.

`curl ... | <your favorite code editor, like vim or emacs> -` should work too.

Thats generally what I do when I encounter the curl -> bash instructions on the web.

I'm not sure that this is as safe as you may think.

EDIT More info. Yes this is better than curl ... | sh. But less has a lot of functionality (more than you'd expect) and a carefully written script could exploit some of this.

Can you provide an example?

EDIT found link http://seclists.org/fulldisclosure/2014/Nov/74

Basically the tldr is that gnu less is a program that has been engineered to do a lot of things over the years and this has created attack surfaces which mean that if someone was to curl .... | less on a carefully designed payload it could allow the payload to obtain a shell.

I wasn't saying that it isn't safer just that it isn't totally safe.

Would that really be any different that downloading the script, then opening it with less/vim/whatever locally, which is typically going to be pretty safe, unless the script is accidentally executed somehow.

Well it is exactly the same.

I like the sentiment, but I kinda doubt that the group of folks who would inspect the script before running if only it wasn't so inconvenient to do so has many members.

We live in an era of unsigned images and arbitrary code. This is about time and money, and I don't think any amount of astonishment from the larger community is going to reverse that trend.

Reply on news.ycombinator.com