9 ms·
Show HN: Run unknown shell script with a line-by-line confirmation prompt
- opk 5y agoYou can also do this with bashdb which is possibly also a more robust solution.
- e40 5y agoWhy isn't this solution robust? Seems like using the DEBUG trap would be very robust.
- qiqitori 5y agoSeconded. It's crazy that so few people seem to know about bashdb. I don't know of many other languages that are commonly used without using a debugger.
- tessellated 5y agoYes, I was instantly reminded of the time I implemented the core functionality of the 'time' command in shellscript, only to find out about it months later.
- barbazoo 5y ago> Useful for running unknown scripts Or just, you know, read them before you run them.
- klyrs 5y agoOne complication is that websites can hijack your copy buffer, and the text you paste isn't the text you copied. I avoid this by pasting into an editor, not directly into a shell.
- jjnoakes 5y agoExcuse my ignorance but when are you copying commands from a site you don't trust? If I don't trust a site I don't run anything it suggests to me, copy hijacking or no.
- klyrs 5y agoI distrust every site. What sites do you trust, and why do you assume they haven't been hacked or xss'd?
- junon 5y agoBecause that's an unrealistic threat model for most users.
- deleted 5y ago[deleted]
- ipsin 5y agoI think the most realistic threat model right now is "subverted browser extension", which is effectively equivalent to internet-wide XSS. Luckily I've only been hit once, and with adware, but it's a risk.
- junon 5y agoA browser extension is not a threat model, I'm not sure what you mean.
- klyrs 5y agoBrowser extensions are an attack surface, examination of which is a key aspect of threat modeling.
- krageon 5y agoIt depends on whether or not your threat model includes threats likely to exploit this attack surface. I'm assuming this is why GP said that a browser extension isn't a threat model.
- amlib 5y agonewer versions of gnome-terminal have a feature where it will hold your paste buffer in the linefeed before executing anything, does not matter how long or how many line breaks there are. You can then inspect what you just paste into the terminal, even edit it, before actually executing it.
- scaladev 5y agoOpen your shell prompt, press ^X^E, paste the script into the opened editor. Check it for anything malicious, save and exit (or exit without saving if you don't want to execute it). The shell will execute the script.
- dang 5y ago"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith." "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- m463 5y agoaccept_whatsapp_terms_and_conditions="true" Run command? [Y/n]
- jdeaton 5y agoCan I use it to run itself?
- wlib 5y agoNot without some modifications, which I did not make because the complexity would get crazy with shell scripting
- cratermoon 5y agoWould you trust it on itself? https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
- aufhebung 5y agoReflections on trusting trust wouldn't really apply here. The script is not a compiler, is not even compiled, and can be easily understood by reading it. Unless you think there is some vulnerability specific to /bin/sh and this script the citation is just wrong.
- rhizome 5y agoPossibly relevant, the bash restricted shell (bash -r): https://www.gnu.org/software/bash/manual/html_node/The-Restricted-Shell.html https://www.gnu.org/software/bash/manual/html_node/The-Restr...
- comboy 5y ago> When a command that is found to be a shell script is executed (see Shell Scripts), rbash turns off any restrictions in the shell spawned to execute the script. Can you provide example of a scenario where this restricted shell is useful?
- rhizome 5y agoOh, I'd say when you're running your own stuff, it's only guardrails. I don't think anybody's gonna say it should be any account's login shell or anything. Sure, there's the idea that attackers could break out of it with such a simple featurebug, but it's nice to be able to shed functionality when automating things that could go very wrong.
- eurasiantiger 5y agoIt’s probably possible to craft a script that looks innocuous line-by-line, but does something malicious as a whole.
- LinuxBender 5y agoIndeed. If the person does not understand why/what is encoded by things like xxd or base64 or using tr to swap/filter characters, then one should hopefully pull the eject lever. When in doubt, one can sandbox scripts and see what they are in effect trying to do.
- cratermoon 5y agoOr LFS=
- tyingq 5y agoYou can fool it with ^H (Insert with ^V^H in vim) #!/bin/sh rm not ^H^H^H^H expected Gives: -> rm expected Run command? [Y/n] rm: cannot remove 'not': No such file or directory rm: cannot remove ''$'\b\b\b\b': No such file or directory rm: cannot remove 'expected': No such file or directory
- wlib 5y agoI updated to fix that, thanks for pointing it out. It had to do with echo printing the command with your backspace characters escaped. See if you can break it now, it's interesting how many weird cases exist in tty's.
- tyingq 5y agoHeredocs are a little odd, because you can't see what they might be piping to. This script, for example looks sort of innocuous when run through your tool because it's not obvious the HEREDOC is going to the stdin of a Perl interpreter. Your tool shows them like they are two separate things that don't do much by themselves. Looking at the script itself, it's more obvious. #!/bin/sh cat<<'EOF'|perl -nE'BEGIN{shift(@ARGV)}s#(.*)#$1#ee' /dev/null say "hello"; #arbitrary perl code EOF That's probably a nit, really, though. I don't know that anyone would target it on purpose.
- wlib 5y agoYup, at that point it's within the scope of bash's debugger. It shows the command that is actually being run, so it expands globs, shows the command within if predicates, and so on. If bash shows a command that isn't actually about to run, that is a bash bug.
- protomyth 5y agoIt would be interesting to have a shell that allowed transactions like a database and could list what files have been affected while in the transaction.
- Skunkleton 5y agoYou could snapshot your filesystem, then run the script and diff against the snapshot. Isolating executables (even shell scripts) is really outside the scope of what a shell normally provides.
- kevincox 5y agoThis sort of provides rollbacks but not isolation. You would have to rollback all chances that happened to the filesystem (or the whole system if you don't know what filesystems were touched by the program) during the period between snapshot and when you finish your inspection. It would be interesting if you could mount the snapshot then attempt to merge in the changes to the live system once approved. I don't know if any filesystems that support merges though.
- Skunkleton 5y agoYeah, a shell is never going to provide isolation. If you want isolation, then snapshot your filesystem, assign it to a VM and run the script there. But this isn't actually useful because: 1. You probably will need network to run whatever script this is. Once you give the script network access, you are open to a whole bunch of issues. Perhaps your ssh private keys leave your system for example. 2. If you don't give it network access, it probably won't do anything malicious. Most of these scripts exist just to download some "thing", install it, maybe run it, and maybe update an RC file. The malicious code might be in the executables downloaded by the script rather than the script itself. 3. Just because a script does something reasonable in a VM doesn't mean it isn't malicious and won't do something else when it is run on bare metal. In the end, you have to trust whatever software you decide to run (scripts included). How you gain that trust is up to you. I would steer away from gaining that trust by running the script and seeing what happens. Personally, I just rely on the reputation of the source of the software. Verifying that some script doesn't screw up the configuration of my machine is a different story. I hate it when some script decides to run "pip install" or some other thing that subverts my package manager. Here, taking a snapshot is a reasonable choice.
- scintill76 5y agoI’ll nitpick. I think > # Ask for only a single character of input, so the user does not need to type an extra enter plus > echo "Please answer by typing n (for no), y (for yes), or Enter (also for yes)" seem like it will lead to “y[enter]” so you accidentally accept a second line before you read it.
- macintux 5y agoIn addition, for security reasons I think you’d want the default behavior to be no, not yes. Seems like dropping enter entirely is the right choice.
- dumpsterdiver 5y agoIf you are considering using this tool, then I would suggest that you seriously reevaluate your life choices. You should never run shell scripts without reading them first, ever. That is so irresponsible. Validating shell scripts will make you a more competent and informed worker. Tools like this breed incompetence, and encourage carelessness.
- GauntletWizard 5y agoI want this to run my own shell scripts. I have a bunch of scripts that are halfway between "documentation" and "automation"; mostly the record of the last time I did X. Add a prompt to eval a command or two or change variables that are hard coded, and it's ipython for shell.
- dumpsterdiver 5y ago> I want this to run my own shell scripts. That's really the only use case for this tool that I could get behind, and I commend you for your diligence.
- martinald 5y agoI assume you also read all the source code for every program you run too?
- dataflow 5y ago> You should never run shell scripts without reading them first, ever. That is so irresponsible. Do you run on Gentoo? and presumably read the millions of lines of code your machine is running on? People have been downloading and running executables almost pretty much as as the internet has been around... and the world is still going 'round.
- dumpsterdiver 5y agoI understand your point, but there is a big difference between running a 20 year old program written in C and running a shell script that someone with one or two years of experience hacked out in ten minutes. To answer your question, I do fuzz many of the GNU utilities that I use regularly, and I have discovered vulnerabilities that way. Of course it is unreasonable to read all of the code that runs in our operating systems, but it is not unreasonable to read shell scripts before you run them.
- cookiengineer 5y agoWhat would be amazing is a tool that analyses the script first, figures out folders and files (and networking) it influences and allows to sandbox it accordingly. This script wants to modify: - /usr/local/program/* - /etc/program/* - $HOME/.program Do you want to execute this? [Yes/No] ..because you know, what happens when you execute a script that does rm -rf /usr in the 100th step?
- mlyle 5y agoVery difficult to do in any kind of robust way. A script can run all kinds of things and use myriad forms of obfuscation, causing all kinds of obscure side effects.
- cookiengineer 5y agoWhen trying OPs code out, I had all the "linux binaries" in mind, aka all the shitty self-unpacking installers that concat their binaries and dump it in /tmp before executing it. (you know, like proprietary drivers almost always do) It would be a huge improvement for sysadmins if a linter could be run in advance of executing a shell script, and use chroot and other sandboxing like creating a user without net cap rights etc in case it found something potentially malicious.
- vanviegen 5y agoI imagine this could be done by actually running the script in some sort of sandbox, having file changes written to overlayfs at first. This would still allow the script to steal data though, as installer script generally require internet access.
- dwohnitmok 5y agoThis would still be defeated by any script that is nondeterministic which is a real possibility if you're trying to defend against malicious scripts or against very poorly written scripts.
- 5y ago
- deleted 5y ago[deleted]
- searchableguy 5y agoThis is exactly what deno is useful for. Write your script in typescript and then run it with deno --prompt. I made a little demonstration script. deno run --prompt https://crux.land/4Lc2E2 Spoiler: https://share.getcloudapp.com/ApuYR00w https://share.getcloudapp.com/ApuYR00w if you can't run above.