`gosh` is security theater for piped shell scripts | Hacker News Reader

`gosh` is security theater for piped shell scripts

github.com

48 pointssstephenson26 comments

Do people actually run bash scripts from the internet without reviewing them first?

Next thing you know they'll be running binaries without sending them through IDA Pro.

(Which isn't to say that I disagree with the security concerns raised of a curl|sh. Just that of course many people don't vet their various source code/shell scripts/executables. None the less, you should give them the opportunity to - a tarball and a detached signature seems to be a pretty friendly approach)

Or even the laughable idea of downloading a tarball and running a configure script without first examining it for trojans. Such folly!

“Concerned about theoretical man-in-the-middle attacks when piping scripts from curl to your shell?”

This case is where you know what's at the URL you specified, but since it was/will be downloaded over HTTP, in principle a MITM could change the content when it's downloaded by curl, so you're running a different script than the one you reviewed/uploaded.

Yeah, but if you pipe the curl output to your shell anyway, this is the same thing.

Unless of course it's some sort of "timing attack" (advance apology to purists if I'm using this term incorrectly) and the server knows you've downloaded this once (with gosh perhaps) and then sends you the malignant stuff the second or subsequent times.

Edit: sorry, the above makes no sense because you will have reviewed it with gosh and probably wouldn't download it again.

You mean a "race condition", not timing attack.

There are lots of ways you can get bad data from a given server over curl, even if using HTTPS and the attacker does not have full control over the server:

* Typo in URL and typosquatter sends you whatever commands they want

* XSS in server-side scripts leads to injection of commands via unescaped tags

There may be others I haven't thought of. Perhaps a DNS glue record can be used to inject shell metacharacters where the server has an error handler that reports the client hostname? The fact that any of these are even possible shows how fragile this mechanism is.

I'm guilty of this: `wget mysqltuner.pl && perl mysqltuner.pl`.

I am amused that the examples on the README are all https, where gosh wouldn't be needed in the first place.

Unless your tinfoil hat is nailed firmly to your head, and you're worried about state-sponsored CA attacks that break HTTPS; or if you're running code from a site you don't trust, for... some reason.

No tinfoil hat needed here. Not only states can compromise CAs, scriptkiddies and hackers can too. As every CA can produce a certificate for every site, only one has to be weak/exploitable and you're screwed.

HTTPS is no replacement for proper code signing and checking. The hacker of the latest CA fiasco also produced a certificate for "plugins.mozilla.org", for example.

However, less funny is that curl doesn't work with https without a lengthy process of creating a CA bundle from Mozilla. This process happens to be much harder than installing a proper package manager that supports signed packages.

Is a ruby gem really needed instead of just wget'ing a file, vi'ing it and either rm'ing or ./running it?

This is a good start.

I don't know ruby but if I did I'd change the sha256 stuff to GPG. Could support searching for local GPG keys with URL and/or the username out of the github URL. Asks which to use if multiple matches are found, should remember the choice. If there isn't a local key already, support querying specific known keyservers. mit's and ubuntu's come to mind.

Might poke around with this in bash in a week or two.

Pun observed and appreciated.

My two-hundredths-of-a-dollar on this whole 'debate' is that if you can't modify the curl pipe command so that it writes a file instead of running it immediately (as someone other than root. Right? RIGHT?) then you really deserve that Trojan you just piped into your shell.

curl -O <URL> writes the file to the local disk, and then what? bash <file> right to run it?

...

`gosh` is already the name of the Gauche Scheme interpreter. Just in case anyone gets a repl :-)

I am cursed with the affliction of seeing both sides in many situations. Sam is without a doubt right, in that an attack on the users of pow, presumably being small in number, is unlikely. Thomas is also right, in that a situation like this is almost the epitome of low hanging fruit to an attacker with the means and motivation to attack someone installing pow.

I think both parties need to be cut some slack. Sam is in a position where he's just trying to get some things done and make it easy on the user to run some great software. Laudable, without a doubt. Thomas is in a situation where he sees the evil that men do, and just wants to point out a tweak that could potentially head off problems for people wanting to opt in to said great software. Also laudable, without a doubt.

Where I will come down on one side is the release of gosh, which is difficult to interpret as anything but an attempt to mock one of their positions. The adjective theoretical is perhaps one of the sticking points. The problem here is that the transformation from theoretical to actual in terms of a threat is unfortunately just a couple of hours of coding on my part, and I say this with full knowledge that most participants at HN far exceed my skill level. I would use bog standard tools, all of which are already installed on my laptop - even though I am not in the habit of doing such things. For a myriad of reasons, the least of which being industry health, it shouldn't be necessary for me to pull an Eric Butler in the next few hours for this topic to go from theoretical to actual threat.

At the heart of things, there is a disconnect between those in the security industry and those who aren't. If you attempt to be totally secure you'll find yourself in a recursion loop that never exits. If you attempt to just get things done, you can find yourself employing practices that are quite simply horrifying to those who are stuck in said recursion loop. If you attempt to take a moderating view, 9 out of 10 times you'll find yourself agreed with yet your suggestions will mostly go unfollowed. Until some common exploit comes about, at which point those same 9 out of 10 folks will mention that this vulnerability has been known about since the beginning of time.

In my view, we all need to meet on some common ground. Sure, if you don't have http-->sh executions going on there are still 10^10 other attack vectors out there. But for right now, that's more or less the only solution the security industry has to offer. Keep plugging away at low hanging fruit. It raises the bar.

Bottom line here is that Thomas doesn't seem like too bad a guy to me, and I doubt he's looking to tarnish the reputation of a great piece of software. But he's bringing up a good point that is refreshingly actionable. It's an opportunity to make things just a wee bit better with a minimal amount of disruption. I'd suggest that you mock it at everyone's peril.

Reply on news.ycombinator.com