No one expects command execution | Hacker News Reader

No one expects command execution

0x90909090.blogspot.com

88 pointswglb85 comments

I don't get it, it's not really unexpected if you pass the name of the executable (which just happens to be a script) via a flag... used explicitly for passing an executable to run.

I mean, is it unexpected if `./my_command --execute-this-right-now=somescript.sh` executes somescript.sh?

I agree. Every single example in this article makes perfect sense to me.

I think he wants to bring to peoples attention that if you give someone sudo rights for a specific program chances are that they will be able to elevate their privilegies.

I guess the author's point is don't ever, ever, ever mix shells and unsanitized user inputs, even if you think it can't possibly be harmful.

In other words, even if it's not obvious, doing this creates a security vulnerability:

    tar bla bla ${user input}

Perl has a special "taint" mode (Ruby does, too, I think, but I don't know about the differences or similarties), where any data coming from outside the program - environment variables, network connections, files, etc. - is considered "tainted", i.e. treated as bad, until you validate it using regular expressions (or something along those lines). I have to admit I never tried it, but it sounds like a good idea, assuming it works as advertised, when dealing with potentially malicious input or paranoia.

Rails has ActiveSupport::SafeBuffer for doing XSS protection, but ruby doesn't track external strings as dirty like that.

> but ruby doesn't track external strings as dirty like that.

It does:

  irb(main):001:0> gets.tainted?
  foo
  => true

You can even set $SAFE to 1 or higher to disallow the use of tainted strings in potentially dangerous commands:

  freya:~ flgr$ ruby -e '$SAFE = 1; system "tar bla bla #{gets}"'
  foo
  -e:1:in `system': Insecure operation: -r (SecurityError)
	  from -e:1:in `<main>'

See http://phrogz.net/programmingruby/taint.html for more information.

> but ruby doesn't track external strings as dirty like that.

Yes, it does. E.g:

    x = STDIN.gets
    puts x.tainted?
    y = "hello "+x
    puts y.tainted?
    z = "foo"
    puts z.tainted?

The two first will return "true", and the last will print "false". If you set the safe-level appropriately some methods will be disallowed for x and y above (e.g. eval()), though I would not trust that as comprehensive, but it's a lot better than nothing.

But if you're plugging in input like that, couldn't the malicious user just pass in something like

    && sudo rm -rf /

anyway? Which would render the whole point of the article moot.

Not every command gets run through the shell, and not using the shell was one of the prerequisites in the article.

There's simple ways to "escape" user input (as in, ensure the whole input string is interpreted as a single argument to this program) in ways that ensure you can't do simple &&'s or ;'s and execute a totally different command. But the point of the article is even if it's properly escaped, users can still do malicious things when input is passed to lots of standard UNIX utilities.

What I wish, I wish there was a flag in unicode to declare characters as 'unsafe user input' so that system utilizes and databases can recognize unsafe user input and barf on it.

It would be a very rare case where a vulnerability related to in-band signalling can be fixed with more in-band signalling.

You can if your encoding is explicit about what's in band and out of band. I get the feeling you've never written a protocol ever.

I don't think you even understand the concept of in-band and out-of-band, that's not a function of the encoding. And I've written protocols aplenty in the days when not everything ran on top of HTTP, high speed serial links, with and without virtual circuits (so mux-demux) and a whole slew of others.

Just to make sure you are on the same page as the rest of us here: in-band and out-of-band is a way to distinguish sending meta information about the data stream through the same channel as the original data. You need an escape mechanism for that, so control characters and such.

Out-of-band signalling indicates that all meta information about the data stream travels through a different (virtual) circuit, in which case there can never be confusion about whether a given chunk is data or meta info.

I now understand that your point here is to be insulting.

With the GNU tools you can generally use the `--` option to signal that no more options. That combined with quotes is usually enough:

    tar c -- "$directory_to_tar"

This is a point that should have been made in the author's article. As it is, it presents a poorly defined problem without offering solutions (other than "be afraid").

It isn't much different from something like

    echo `somescript.sh`

Yes, it's unexpected and less commands should do that.

Did you read the manpage of every utility on your computers to know that they won't execute a user supplied program? If you didn't you are up to nasty surprises.

That $HOME trick alone would give privilege escalation to anybody that gets a user-level access to a server of mine. Gota change it.

How so? I might be missing something but as far as I can tell it's just executing the runme.sh as the user who ran the bash command. It would be virtually identical to ./runme.sh

I've seen a lot of novice sysadmins do silly things like rely on sudo's command restrictions, expecting this to actually contain a user.

For those sysadmins, yeah, it's unexpected.

All security is a matter of degree, be it computing or physical.

the most determined of attackers will always find a way in.

There's been a bit of attention recently on these things. The big issue is people using " * " on the command line without prefixing with an "--" argument or simply "./*". If someone has managed to sneak in particularly evil filenames (that look like -options), then the unsuspecting user may be in for a surprise, for example tar'ing up a public upload directory.

This way around is perfectly obvious. But assume that you are writing a website that prints a man page, for example by piping the output of man $URLPARAMETER to the user. In that case it is only obvious to check if man can execute arbitrary commands if you already know that man is not just a cat for man pages.

And yet another interesting GNU tar "feature", also noteworthy is remote tar:

https://www.gnu.org/software/tar/manual/html_section/tar_46....

> "If the archive file name includes a colon (`:'), then it is assumed to be a file on another machine. If the archive file is `user@host:file', then file is used on the host host. The remote host is accessed using [rsh]."

and

> "If you need to use a file whose name includes a colon, then the remote tape drive behavior can be inhibited by using the `--force-local' option."

On many systems, rsh is aliased to ssh, so if you don't properly sanitize your archive names, GNU tar will make network connections.

Wow... I'm starting to get really scared of the shell, and how much hidden complexity there is waiting to trap the unwary. Feels like best practice for shellscripts is to only ever use them for one-offs. And that tar and friends should never be used as "helpers" by other programs.

Welcome to life.

What you are, rudely, implying is that what I am saying is already well known. I'd argue that isn't so.

Until recently shell-scripts was the way you inited a system. I still have almost 2000 shell scripts on my machine that I didn't write myself.

People got owned during shellshock, which means they did run helper programs, in web-facing applications even.

No, life is stuffed full of hidden complexities.

Complexities that are ready to bite the hand of the unwary at the slightest of chances.

Honesty i think the biggest lie in modern times is the MS/Apple lie that computing can be made so simple that even the proverbial aunt Tillie can do it without reading any sort of manual.

It's amazing how many programs that most people would consider "core unix utilities" totally eschew the (alleged) unix philosophy of "do one thing well."

That's probably a GNU thing. GNU's Not Unix, after all.

None of the BSD tar implementations support remote tar.

touché

If your ~/.bashrc is a SYMLINK to a bash or sh script, bash will AUTOMATICALLY EXECUTE that script on login.

If you give rsync command a source or destination with an unescaped colon, it will read an ENVIRONMENT VARIABLE to figure out a command to run to AUTOMATICALLY CONNECT TO ARBITRARY NETWORK RESOURCES. If you have keys, it will even SKIP PASSWORD ENTRY, and with default Kerberos, it will not only skip password, but make a network connections to a login server:port specified by a DNS ENTRY.

Seriously, who is this guy, and why is this trainwreck #1 on HN?

Did this article make you angry? Why do you call it a trainwreck?

The article is literally "If you tell these utilities to execute this script, they'll execute this script". NONE of these should be "unexpected".

Not the point. Of course it's not surprising that these utilities will execute scripts if you tell them to. The unexpected fact is that you can tell them to -- and that this is documented behavior which probably isn't going away.

If your argument was that no programmer should be surprised that you can tell an archive utility to execute an arbitrary script, then you and the author of the post are in complete agreement. The remaining difference is that the article actually does something to fix the problem while you merely hurl an implicit insult at anyone who hasn't seen this type of privilege escalation yet. One of these actions is more constructive than the other.

> you merely hurl an implicit insult at anyone who hasn't seen this type of privilege escalation yet

You and I have vastly different opinions on what constitutes privilege escalation.

I'm not a security researcher. Care to recommend a more appropriate term for the data -> execution stage as opposed to the user -> root stage which is more commonly associated with the term "privilege escalation"?

I don't disagree, but, as a relative novice with shell scripts, I definitely did not realize so many tools could execute arbitrary code.

The parent post's anger and disgust is misplaced, though. This article is informative at a novice level, and well-written to that level. Not a trainwreck.

Because it is treating all of these intended side-effects of using a shell as though they are security vulnerabilities.

The problem is that there is a way for untrusted user input to ever touch a shell in the first place.

Seriously, I challenge you to find a language reference that doesn't decry the use of their version of system(3)---because all that does is run the given command under the user's shell.

Sure, fine, but why the anger? Why the 'trainwreck'? that's not constructive at all. The article definitely didn't claim these were security vulnerabilities - only that they were surprising. Some of these were surprising to me too. Am I an idiot for not knowing these? (no, I'm not, I'm just a novice).

It's really aggravating to learn something from an article that is making someone more knowledgeable this angry without explanation.

I think the point is that this is an entire class of vulnerability that most people may never have thought about, but could very easily result in some nasty remote code execution and/or privilege escalation via setuid.

Yes, that thing that is designed to execute commands could possibly result in commands being executed. Similarly, the intended use of a setuid binary is to escalate your privileges.

I'm asking you why you thought the knife would stop cutting things when it hit your hand instead of the loaf of bread.

So what is your opinion of this method of install? http://brew.sh/

I think anyone who follows that method has no idea how things work. I was actually personally offended when Ximian started handing that out as a way to install Mono a decade+ ago, because it is absolutely the worst practice you can imagine: go pull [expective] from a URL, and throw it directly from the network into system(). I will "strong no" candidates who think it's a good idea, and I reject any PRs that do [expletive] like it.

All that said, between Gmail's spam filter, my avoidance of all things bitcoin, and common sense with passwords (don't ever re-use them), most of the damage caused by this doesn't affect me.

I will note, however, that this are why "when you hit return in the URL bar, what actually happens," is a valid interview question, in the same unfortunate sense that FizzBuzz is a valid interview question.

This might be related to another article about OLE execution, to cast a shadow of doubt that it is not an isolated habit. Having outside stuff executed when not meaning to is always bad. I for one would be badly disappointed, if tar xvf unexpectedly run some code. Luckily, that is not the case.

UNIX got battle-hardened during its college years, the cases of unexpected execution are few and far between. One of them is post-install, never run dpkg -i unless you trust the packager.

> UNIX got battle-hardened during its college years

Is that when it finally gave up making shar archives?

For the unitiated: A shar is a "shell archive", or a shell script which (typically) makes heavy use of 'here documents' to do what tarballs do, only they're shell scripts so you have to execute them and then they can potentially execute arbitrary code unless you read through them very closely and actually understand them.

Yes, people actually made these. Yes, people actually ran these. Yes, they still exist on some old archive FTP servers and so on.

It's amazing how clever you can be when you don't think you'll ever have to care about security or The Sufficiently Stupid User (because sufficiently advanced stupidity is indistinguishable from malice).

I loved shars. It was a carefree time. Nothing to worry about.

Also there used to be services based on

telnet somehost someport | sh

(I remember an IRC client installer script hosted on sci.dixie.edu like that.)

Unfortunately we still have

curl http://somehost/somepath | bash

which is not very safe even if somehost is not malicious.

But it was kind of awesome when the Internet was friendly!

I don't really understand how a shar is more dangerous than the still-incredibly-common "./configure; make".

You really don't need the "./configure" there. make alone can obviously run arbitrary commands - but then again, so can the program whose source code you probably downloaded in order to run it.

In general, all the hype about not executing stuff from the web has a point but is largely confused about where the risks are and aren't (e.g. the "don't pipe wget into the shell" meme).

And even without any other source of trust, anyone who is willing to go through the automake/config hell, already scored some initial trust points. I rest my case.

Yes, that is one of the things that turned out to be a bad idea. That's why it was dropped.

Look, it's all about trust management. If you trust everyone's good will, like in an academic community, it's fine. If not, you need to manage trust. There are three models for it AFAIK: initial trust, as in SSH; trust to the authorities, as in X.509; and the web of trust, as in PGP/GPG.

They all have their use cases. I like the opportunity to choose.

It's been a while but I thought the real reason shars existed was because they were 7 bit clean, meaning they could be traded on usenet (or ftp in ascii mode) without needing any external program like uudecode…

> …only they're shell scripts so you have to execute them and then they can potentially execute arbitrary code unless you read through them very closely and actually understand them.

> Yes, people actually made these. Yes, people actually ran these.

Running something you downloaded is how every installer works. Self extracting zips are still a thing, too. At least with shars you could read the source.

Oh yeah, even today people still do `curl http://example.com | bash` (If someone were truly evil they'd make the first download from an IP clean and inject bad code into the second. That would catch all the people who `curl | less` first and then run it again piped to bash). :-)

All you needed to undo a shar (shell archive) was a fairly common Bourne shell. We had uuencode to make things 7-bit clean. Some programs to make shar files uuencoded the archived files, but some didn't.

"shar" files existed because "tar" wasn't particularly standardized. As late as 1990, SGI Irix "tar" did bytes in reverse order from SunOS "tar". You had to convert bytes to untar a SunOS archive on Irix.

> That would catch all the people who `curl | less` first and then run it again piped to bash

Are many people security-conscious enough to do the former but security-unconscious enough to do the latter? I would assume that one would do `curl http://example.com > evilscript; vim evilscript` and then `bash evilscript` if necessary.

Command execution is overrated. How about having tar download an arbitrary tar file over the network, from a server you control? http://bugs.debian.org/290435

That's a bit of a surprise!

What I find interesting is the thread title being a pun from a 40 year old movie. Back in the 70s, there wasn't any interest in movies, music, etc. from the 30s. And there still isn't interest in 30s culture, but plenty in the 70s.

I wonder why.

My guess: Because it's Monty Python. They weren't around in the 1930s, but they are still funny today.

Great question. Hypotheses:

a) 70s culture was a brief moment where geek culture was also pop culture, e.g. Monty Python. So geeks will forever adore that moment

b) mass culture underwent a big shift when TV emerged, so that people after TV cannot easily understand culture before TV

c) the disillusionment and paranoia of the 70s is especially relevant today

> Back in the 70s, there wasn't any interest in movies, music, etc. from the 30s.

I don't know, Hawkeye Pierce did a pretty good impression of Groucho Marx.

I think it's down to numbers: There are a Hell of a lot more people born who know about the 1970s alive now compared to people who knew about the 1930s alive in the 1970s. It was a Baby Boom, after all.

I think you're in a bubble. Lots of people have interest in the 30s given it was the golden age of Hollywood: Gone with the Wind references have entered the cultural lexicon, so have The Wizard of Oz references.

A movie from the 70s that compares with TWoO and GWTW in stature would be Star Wars, certainly not MPatHG.

I find it unremarkable that people today quote SW.

Yeah but even then, you have The Three Stooges, The Marx Brothers, and Charlie Chaplin. All 30s-era comedy groups similar in notoriety to Monty Python.

In high school and college in the 70s, people did not go around quoting the Marx Bros. They were generally regarded as belonging to their grandparents' generation. It's just not like Python quotes today, which seem to be just as pervasive as in the 70s.

Can you even think of a MB quote without looking one up? If I made a pun on one, would you recognize it?

Yeah, like I said, I think you're living in a bubble and/or this is confirmation bias. I grew up in the 00s and, from my perspective, I see Monty Python as belonging to my grandparent's generation. No one in my age group commonly quotes Monty Python.

If people still do quote Monty Python, I think it's a culty minority or people who study media. The same status as the Marx Brothers and other comedians of bygone eras.

But we can agree to disagree :)

> 40 year old movie

spanish inquisition was flying circus, not holy grail

but my theory is that the vcr, and now the internet, has a lot to do with it, just like you'd expect references to books to increase with the printing press and general increase of literacy

Are there any real examples of how this could be used to do something malicious?

Probably strictfp's example above of allowing someone to run specific commands with sudo.

In the past there were also various implementations of a "restricted shell"; it's conceivable that some of these could bypass a restricted shell's restrictions, depending on how they were implemented.

Sure: any attempt to build a "sandboxed" command line interface with a shell, or any web app that shells out to one of these commands and passes user input as an argument.

In one case, I could have used tcpdump to elevate privileges on a customer's router.

They had an x86 box running RHEL as their firewall/router and I was hired to resolve an (IPSec) issue they were having. I asked for a capture of some specific traffic but their I.T. guys (small company w/ only two technical staff) weren't "fluent" with bpf filters, so they created a user account for me, provided me with access via SSH, and granted me the ability to run tcpdump via sudo.

From the example given, I could have used the "-z" flag to run arbitrary commands and escalate to root (although, in this case, I likely could have gained root simply by asking nicely).

There must be a bug in my OpenBSD, because none of these work...

Oh for explicity typed IO.

(Sadly command-line programs have yet to pass the threshold of even having a types system at all.)

Or, you know, a proper capability-based security model.

Powershell!

Seriously, MS doesn't do everything great, but Powershell has typed pipes (typed everything, actually, it's not just stringly like *sh) which are seriously awesome.

I've used a "shell" that had a type system. Just before Control Data Corporation (CDC) dried up and blew away, they put out a mainframe OS called "NOS/VE". Yes, "VE", not "BE" - "NOS/BE" was a somewhat unrelated OS for CDC mainframes.

The NOS/VE shell had string types and integer types at least. The experience was absolutely horrible. It's hard for me to remember much other than the difficulty of getting anything practical to work, and that may be a consequence of CDC's incredibly poor design choices for the "shell" rather than the types. But I personally have never said "Oh, for a type system in this darn shell!" since then.

Oh my god! Who would have ever expected that command line utilities might be able to execute external programs?!

Quick! Everyone! Run in circles!

Well geez, it's almost like the tools were designed with flexibility and pluggability in mind before the advent of the internet and the fear of remote shell exploits...

Hey guys! Did you know you can actually execute a script with date by running date && ./myscript.sh

WOW! I better get on going writing my blog post "executing abitrary code with 'date'".

Doesn't count, a setuid date wouldn't get you root with that command.

How many people have setuid tar? Or man, or zip, or git, or ftp?

You didn't expect command execution.

Reply on news.ycombinator.com