7 ms·

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

28 points by mplewis 11y ago

dotdi 11y ago
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.
- draz 11y ago
  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.
  - dotdi 11y ago
    "What if OP inspected the script and highlighted potential harmful commands?" OP doesn't. Look at the code.
    - dewey 11y ago
      That's exactly what he says, he agrees with you and just offers a suggestion on how to improve the script.
joepvd 11y ago
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/ https://joeyh.name/blog/entry/moreutils/
ams6110 11y ago
Why not just: curl ... | less
- bbrazil 11y ago
  One potential issue is that you don't know you'll get the same HTTP response next time.
  - ams6110 11y ago
    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.
- deleted 11y ago
  [deleted]
- SmirkingRevenge 11y ago
  `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.
- thrownaway122 11y ago
  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.
  - hartator 11y ago
    Can you provide an example?
    - thrownaway122 11y ago
      EDIT found link http://seclists.org/fulldisclosure/2014/Nov/74 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.
jordanpg 11y ago
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.
Xavi 11y ago
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?
- sean-duffy 11y ago
  You mean like... a package manager?
  - Xavi 11y ago
    Well a package manager does much more than verify downloads, but sure you can think of it as a single featured package manager.
- mekazu 11y ago
  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.
hawski 11y ago
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 http://whatever | sh' With predefined permission profiles or interactive permission system.
- seanp2k2 11y ago
  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.
  - hawski 11y ago
    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.
spb 11y ago
Interesting. I wrote a similar script, in Bash, for my meta.sh project: http://meta.sh/index.sh http://meta.sh/index.sh
- danieltillett 11y ago
  There is a nice simple version here too https://gist.github.com/sunaku/f5f79e20b6f92ab1e524 https://gist.github.com/sunaku/f5f79e20b6f92ab1e524

28 points by mplewis 11y ago

dotdi 11y ago

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.

draz 11y ago
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.
- dotdi 11y ago
  "What if OP inspected the script and highlighted potential harmful commands?" OP doesn't. Look at the code.
  - dewey 11y ago
    That's exactly what he says, he agrees with you and just offers a suggestion on how to improve the script.

joepvd 11y ago

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/ https://joeyh.name/blog/entry/moreutils/

ams6110 11y ago

Why not just: curl ... | less

bbrazil 11y ago
One potential issue is that you don't know you'll get the same HTTP response next time.
- ams6110 11y ago
  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.
deleted 11y ago
[deleted]
SmirkingRevenge 11y ago
`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.
thrownaway122 11y ago
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.
- hartator 11y ago
  Can you provide an example?
  - thrownaway122 11y ago
    EDIT found link http://seclists.org/fulldisclosure/2014/Nov/74 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.

jordanpg 11y ago

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.

Xavi 11y ago

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?

sean-duffy 11y ago
You mean like... a package manager?
- Xavi 11y ago
  Well a package manager does much more than verify downloads, but sure you can think of it as a single featured package manager.
mekazu 11y ago
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.

hawski 11y ago

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 http://whatever | sh' With predefined permission profiles or interactive permission system.

seanp2k2 11y ago
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.
- hawski 11y ago
  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.

spb 11y ago

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

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